31–40 of 80 posts
Here's a write up of the chilly reception this recently received on the python-ideas mailing list: https://lwn.net/Articles/760993/
The whole endeavor seems a bit quixotic to me. This kind of change would no doubt cause such a stir that there’d be a fork before long.
Not supporting the change, but let's not be dramatic
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 l…
It can already be written nicely as libpaths = paths.split(":") if paths else [] Please don't adopt unnecessary sigil junk from other languages.
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).
Swift uses this syntax and I got quite used to reading and writing it.
I’m all in favor of it.
We have a lot of Django-based code similar to if getattr(obj, 'foreign_obj') is not None and getattr(obj.foreign_obj, 'field_name') is not None: Would this turn into: if obj?.foreign_obj?.field_name ? Does is look shorter? - YES!. Is it more readable? Arguably yes. Would I vote to see this feature in Python? HELL NO! In most of cases, we can have an in-house "maybe()" function, like maybe(obj, 'foreign_obj.field_name…
some.object.other.method();
if (some && some.object && some.object.other && some.object.other.method) {
some.object.other.method();
}
This is even more cumbersome/ugly when needing to assign the result to a constant:
const foo = some && some.method && some.method();
My main issue with syntax like:
const foo = some?.object?.other?.method();
Earlier quoted context omitted.
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 l…
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…
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.
It will be interesting to see how this PEP is handled by the community with Guido off on a permanent vacation, and the mood among Python core devs seemingly "no major changes to syntax for the next little while" . Personally, some of the examples using the new operators are in fact easier to read, but others border on illegibility, and I don't think the tradeoff is wise. Then again, I felt the same way about Python's…
It was created three years ago, and it's still just a draft. Hopefully it won't go anywhere, with or without Guido around.
EDIT: Raymond Hettinger is on the ball as always: "This PEP also shares some traits with PEP 572 in that it solves a somewhat minor problem with new syntax and grammar changes that affect the look and feel of the language in a way that at least some of us (me for example) find to be repulsive. This PEP is one step further away from Python reading like executable pseudo-code. That trait is currently a major draw to the language and I don't think it should get tossed away just to mitigate a minor irritant"
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 l…
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 l…
> 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.