Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PEP 505: Bringing None-Aware Operators to Python

python.org

Post reply on HN
Print view View original

11–20 of 80 posts

Re: PEP 505: Bringing None-Aware Operators to Python

#11

Post by CurlyJefferson »

makecheck wrote: post #8

I’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…

"Stop trying to shorten code by 2 lines."

Agreed. Python code tends to be concise as is. There's no need to add little tricks to cut out a line or two at the expense of readability.

Along those lines, in a recent code review a developer balked at some proposed code and boasted how he could do the same thing in fewer lines. His "improved" code had a keyword parameter where the default was set to a lambda function containing nested list comprehensions plus a zip function... I voted against his "improvement" since it was the most unpythonic thing I'd ever seen. I'll take added readability and simplicity at the expense of a few extra lines.

Re: PEP 505: Bringing None-Aware Operators to Python

#13

Post by gaius »

catdog wrote: post #7
Waterluvian wrote: post #2

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…

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...

Re: PEP 505: Bringing None-Aware Operators to Python

#14

Post by agumonkey »

catdog wrote: post #7
Waterluvian wrote: post #2

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…

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(":")

do people use

    x = x or []
or is it considered non idiomatic in python ?

Re: PEP 505: Bringing None-Aware Operators to Python

#15

Post by tomchristie »

agumonkey wrote: post #14
catdog wrote: post #7

Earlier quoted context omitted.

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(":")

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.

Re: PEP 505: Bringing None-Aware Operators to Python

#16

Post by G2kyd7 »

Another +1 for rejection. Python is popular because it is easy to write idiomatic code that is easy to understand by humans, which I think is one of the features that separates bad from good code. This proposal would only add non-intuitive syntax (e.g. extensive operator chaining) that will make code more complicated to read, even if you are not a beginner, only to save 1-2 lines of code.

Re: PEP 505: Bringing None-Aware Operators to Python

#17

Post by singularity2001 »

Waterluvian wrote: post #2

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.

Re: PEP 505: Bringing None-Aware Operators to Python

#18

Post by msl09 »

mlevental wrote: post #6
Waterluvian wrote: post #2

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…

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.

Re: PEP 505: Bringing None-Aware Operators to Python

#20

Post by vinceguidry »

Null-awareness is something that, once you start relying on it, you really start to miss not having it. I think having idiomatic and easy ways to shuffle nulls out of the system is practically required for any dynamically-typed language.

You need terse ways to do it because once your codebase reaches that point where the behavior is sketched out and now you need more correctness, you're going to be using it everywhere, at least until you've discovered all the main sources of ambiguity so you can gateway those separately.

I'm a Rubyist, being dragged kicking and screaming into NodeJs world, so I don't have a dog in this fight, but this kind of thing and the reaction I'm seeing to it in this article makes me happy with my language choice.

Python seems to be seeking out a middle ground between a structured programming language and the web world. Which is fine and all, but it seems to be taking the worst part of both worlds. The verbosity and finickiness of syntax of structured languages and the performance of dynamic ones.

Post reply on HN