libpaths = paths.split(":") if paths else []
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).
if node and node.child and node.child.attribute:
… for child in node.children or []:
for attrib in child.attributes or []:
… for child in node.children if node.children else []:
for attrib in child.attributes if child.attributes else []:
...
libpaths = paths.split(":") if paths is not None else []
libpaths = [] if libpaths is None else libpaths.split(":")Of course in Python [] is False and in Ruby it's true...
[1]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
[2]: https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Why not go the whole hog then, and do a Option[1] ;-)
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.
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.
No, it's nothing like the Ruby convention. It's much more like th C# operators.
x = x or []
Using `x = [] if x is None else x` is more precise.
if a is not None and a.b is not None:
c = a.b.c
else:
c = None
c = a?.b?.c
(libpaths or '').split(":")
(libpaths or '').split(":")
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...
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# question mark dot
It doesn’t really seem to be a problem.
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.
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.
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.
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!".
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.
> 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.
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.