PEP 505: Bringing None-Aware Operators to Python
1–10 of 80 posts
Re: PEP 505: Bringing None-Aware Operators to Python
#2Here's an example the PEP provides:
if libpaths is None:
libpaths = []
else:
libpaths = libpaths.split(":") libpaths = libpaths?.split(":") ?? []
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.
Re: PEP 505: Bringing None-Aware Operators to Python
#3Here'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…
[deleted]
Re: PEP 505: Bringing None-Aware Operators to Python
#4Here'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…
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.
Re: PEP 505: Bringing None-Aware Operators to Python
#5Here'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…
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.
Re: PEP 505: Bringing None-Aware Operators to Python
#6Here'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 like `get(get(a, None), None)`
Re: PEP 505: Bringing None-Aware Operators to Python
#7Here'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…
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(":")Re: PEP 505: Bringing None-Aware Operators to Python
#8I’ve found that operators boil down to saving time writing (once) at the expense of later readability. They are also almost impossible to trace if operators are overloaded. And you have to hope that the overloaded operator has a meaning consistent with other uses of the operator.
Stop trying to shorten code by 2 lines. It’s not that bad to write it out. If it helps, think ahead to the 1st or 5th revision of the code you’re about to write and imagine where you’d even be able to add new code, given magical operators. In a case like this, it’s easy to imagine a single “else” case with “?” needing to change into multiple else-if cases, requiring the entire fancy operator expression to be rewritten. No real saving.
Re: PEP 505: Bringing None-Aware Operators to Python
#9Here'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…
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. : "python ??" )
> libpaths = libpaths?.split(":") ?? []
Re: PEP 505: Bringing None-Aware Operators to Python
#10It 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 decorator syntax (ie. @) when it was proposed, and I still find it jarring.