Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Here's an example the PEP provides:

    if libpaths is None:
        libpaths = []
    else:
        libpaths =  libpaths.split(":")

After updating:

    libpaths = libpaths?.split(":") ?? []

Python is great for beginners for many reasons, two of which are: code is obvious when read, and we all write the same way so you can go read expert code and learn from it. There is so much more to programming and Python than just optimizing keystrokes and lines of code.

In my opinion, the PEP 505 version is entirely illegible to a reasonable python beginner. And this hurts the language more than spreading the instructions across a few extra lines.

I am concerned that PEPs are always written by experts who will, intentionally or not, bias towards an expert-friendly language.

View on HN

I agree. This idea sacrifices readability in favor of terseness which is hostile to the beginner and to the professional. It results in less legible code for everyone. I hope this PEP is rejected.

Another voice in support of rejection.

It can already be written nicely as

   libpaths = paths.split(":") if paths else []

Please don't adopt unnecessary sigil junk from other languages.

I think a better example to show why you might want a ?. operator would involve nested lookups. If you have something like node.child.attribute.value, handling potential Nones at each lookup with ifs would get very verbose very quickly (and that verbosity would be bad, as it would make it much harder to make out the main point of the code).

You could surround the nested lookups in try/except and catch the AttributeError, but that could mask other errors - for instance, if you misspelled the name of one of the nested attributes (arguably, it would be better if trying to look up an attribute on None raised a different exception, rather than AttributeError).

I don't think the existing pythonic way is not too verbose:

   if node and node.child and node.child.attribute: 
      …

for nested loop you can do

   for child in node.children or []:
      for attrib in child.attributes or []:
         …

That's generally considered unpythonic though. A more pythonic way to write that is

    for child in node.children if node.children else []:
        for attrib in child.attributes if child.attributes else []:
            ...

Which, granted, is a lot more verbose and probably not any more readable but at least it's not abusing the or operator.

This is subtly incorrect. Correctly, it should be:

    libpaths = paths.split(":") if paths is not None else []

or else falsey values of paths (0, [], False) can still cause an error.

If your path variable is set to 0, [], False then it's best to fail early anyways.

Not just for beginners, the proposed syntax looks horrible in general. It's moreover already possible to put this into one line:

  libpaths = [] if libpaths is None else libpaths.split(":")

Yes, this PEP looks like it is trying to turn Python into Ruby where the ? suffix is common for a function that returns a bool. Also weird syntactic magic that you can't really figure out, you have to be told about. I wonder if the original author of the PEP is a "rubyist".

Of course in Python [] is False and in Ruby it's true...

Looks exactly like adding the ?? [1] and ?. [2] operators from C#.

[1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

[2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

operators from C#

Why not go the whole hog then, and do a Option[1] ;-)

[1] https://en.wikipedia.org/wiki/Option_type#F#

Option is bubkes if the language itself still has the billion-dollar mistake; that's why F# and Scala are far less practical than OCaml. Python also has it with "None" (though since it is dynamically typed, it's arguable that from the perspective of any given type, every value of every other type is a fresh instance of the billion-dollar mistake).

And sadly, removing None from Python and replacing it by Option - let alone removing Exception and letting Result (aka Either) take its rightful place - would cause huge amount of Python code to need rewriting. And it wouldn't even be worth it because of dynamic typing.

What does you gain from optionals if you can't determine types at compile time?

> What does you gain from optionals if you can't determine types at compile time?

As well as type checking (which is relevant because Python has AOT checkers even if they are optional), Options, compared to bills, give you nestability, which is a runtime advantage not dependent on static type checking.

> Yes, this PEP looks like it is trying to turn Python into Ruby where the ? suffix is common for a function that returns a bool.

No, it's nothing like the Ruby convention. It's much more like th C# operators.

do people use

    x = x or []

or is it considered non idiomatic in python ?

It’s okay-ish. You do need to be careful about what falsey values `x` might be tho, as it could introduce edge-case bugs.

Using `x = [] if x is None else x` is more precise.

I would really just write `if x is None: x = []`

`if-else` for this will get messy quickly the more layers down you want to go.

  if a is not None and a.b is not None:
      c = a.b.c
  else:
      c = None

  c = a?.b?.c

The safe navigation operator is useful enough that beginners ought to be introduced to them anyway. I will admit that adding `??` may be too much though, we could easily just use an `or` (although the PEP does have some justifications for adding it).

If you really need it to be short you could write:

  (libpaths or '').split(":")

I would be in favor of just using an if-else though, if the None case is special, to emphasize that. If it isn't, then you shouldn't be writing this in the first place and just make sure that libpaths is always a string; otherwise you'd be expressing the same state in two ways.

    (libpaths or '').split(":")

This isn't quite the same: if libpaths is None, the above will evaluate to [''], while the original evaluated to [].

Of course, the original code was rather awkward itself, redefining the same variable to have a completely different meaning, as well as potentially involving four different representations of nothingness. I'm not sure the syntax is the biggest problem here...

are python devs the most curmudgeonly/conservative devs in the world? syntax is never a barrier to legibility of code because code is not meant to be parsed one character at a time (by programmers). the legibility always comes down to the semantics and abstraction. in my opinion a conciser ternary has very clear semantics and therefore is intelligible. I'm also of the opinion that it's very useful to save on things like `get(get(a, None), None)`

Yea good luck trying to pick that line apart as a beginner.

I could imagine myself as a beginner to python looking at that and thinking things like: Why does 'libpaths?' end in a '?'? What is the ??, is it an operator or something else? Neither would be particularly easily searchable things (e.g. <your fav. search engine>: "python ??" )

> libpaths = libpaths?.split(":") ?? []

> !google c# two question marks

> !google c# question mark dot

It doesn’t really seem to be a problem.

I think that a lot of the discussion of python problems is steered by the infinitely many python book writers and course instructors that have profited significantly by the current trend of "everyone must learn to code!".

If the recent changes to python syntax were to python educators would be the most affected ones since they would have to update their material or see it obsoleted. Of course there's the moral issue that they would have been misleading students if they were to say that python is as simple as it can be.

Every developer whom I spoke have similar feelings about the changes, they are minimal and if they use it, very frequent boiler-plate code could be dropped. These are of course developers that have been working with python for years and have significant code bases to maintain, novices are likely to feel otherwise.

> Every developer whom I spoke have similar feelings about the changes, they are minimal and if they use it, very frequent boiler-plate code could be dropped. These are of course developers that have been working with python for years and have significant code bases to maintain, novices are likely to feel otherwise.

The solution is for them to fire up the time-machine, go back to when the code-base was just leaving the prototype stage, and assault their earlier selves with clue-by-fours while chanting something to the effect of "use a real language for real problems!".

Your conspiracy theory is mistaken; if anything instructors profit handsomely by language churn, as people are forced to come back after this or that update.

No, the problem is simple featuritis spurred by adoption. Python has reached a point where the language is basically feature-complete, but adoption keeps growing. That means that more and more programmers arrive to the ecosystem from other fields, and advocate for constructs they are familiar with or that map more closely to their problem domains. This influence is a good thing in some cases, and a bad one in others.

Operators in particular are a minefield. Python is traditionally inclined not to use special operators, which helps readability quite dramatically. There are very few exceptions (basically only @ for decorators, which is outside code flow anyway). This is why people hate new operators so much: we work with Python to stay away from unreadable, write-only code full of special characters. I understand the frustration of rote in some areas, and any professional is free to sharpen his own tools in the way he prefers -- just don't force the ecosystem at large to lower its code quality just so you can check out 10 minutes earlier from your 9-to-5 large-codebase CRUD job.

I think you're being pretty uncharitable with that interpretation of educator's incentives.

That said, I think valuing relative beginners and non-programmers into the fold is and will be a strong point of the python ecosystem. It has fewer of R's excentricities and some of Java's straight forwardness while remaining relatively terse and to the point.

I think this addition would absolutely cut down on very frustrating boilerplate. The question is the cost to the ecosystem which is going to come down to speculation in any direction.

My opinion: no one change like this hurts a language much at all but the fear comes from the death of a thousand cuts.

This feature does two things: adds slightly crypic syntax which is very obvious to career programmers but somewhat opaque and unmemorable to anyone else.

Worse, it makes bad patterns convenient. Deep None filled object hierarchies (though occasionally unavoidable) will always be problematic in some way. This only serves to make those idiomatic.

I have a different view on this. I’m not a book writer or anything of the sort.

> Syntax is never a barrier to legibility of code

I’m not sure many would admit it even if they agree, but I don’t know if “legibility” wholly describes the concern. I think there’s something more like feng shui, or aesthetics at play. A lot of Python idioms are hard to defend on legibility alone, but the result has ultimately been a language that is comfortable to read more often than not.

There are very few code bases I would want to read in bed as I fall asleep. When I realized I was generally comfortable doing that with most Python code bases, I decided this language might add a subtle quality to my life if I worked with it every day.

Programming in the real world rarely cooperates with this ideal, but I think the ideal still has some meaning. To me, what you call curmudgeon/conservative efforts of Python devs is more a humurous pseudo-enlightenment mentality, so more a humanist project.

For the record, I have no plans to rigidly defend this view and can see how it might sound ridiculous. At the end of the day, I guess I just appreciate the passion, for whatever that is worth.

> syntax is never a barrier to legibility of code

Whatever theory you have about why it shouldn't be, in practice it can be. To also seem to confuse legibility, intelligibility, and mechanical lack of ambiguity; these are all related but not identical topics.

Reading Python involves a lot less mental translation than reading Haskell. I wonder why...

Reply on news.ycombinator.com