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

41–50 of 80 posts

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

#41

Post by thijsvandien »

I am quite concerned about the kinds of PEPs that come up lately (edit: I now noticed it's three years old). Python is drifting farther and farther away from its nature and strength. The amount of complexity is constantly going up and I don't think it's a good thing. Please let this language be what is is.

A small amount of boilerplate in cases like this is fine and motivates you to restructure the code rather than hiding the mess in this way.

Why write

  data = data if data is not None else []
as

  data = data ?? []
if you could simply use

  data = data or []
which already exists and for all intents and purposes should achieve the same thing?

Need to make sure you can always append to something so you can drop some conditions?

  lst = get_log_list()
  lst?.append('A log message')
would have been

  lst = get_log_list() or []
  lst.append('A log message')
right now. In terms of reconsidering the structure of your code, I wonder if a log list not existing or being empty is a meaningful distinction. Perhaps it could return an empty list to begin with.

Even

  libpaths = libpaths?.split(":") ?? []
is fairly easy to deal with already if you absolutely want to it be short:

  libpaths = (libpaths or '').split(":")
Then again, if it is going to be treated as a string, why would it ever be None rather than an empty string? Is that distinction important? Being able to shove it under the rug by sprinkling some question marks over it, allows you to never stop and wonder about that, when in fact, you should.

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

#42

Post by chrisoverzero »

craftyguy wrote: post #9
mlevental wrote: post #6

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…

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

> !google c# two question marks

> !google c# question mark dot

It doesn’t really seem to be a problem.

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

#43

Post by AlexeyMK »

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. It’s not that bad to write it out.

That brings me back to Blub.

"""

After a certain age, programmers rarely switch languages voluntarily. Whatever language people happen to be used to, they tend to consider just good enough.

[...] I don't want to hurt anyone's feelings, so to explain this point I'm going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language.

And in fact, our hypothetical Blub programmer wouldn't use either of them. Of course he wouldn't program in machine language. That's what compilers are for. And as for Cobol, he doesn't know how anyone can get anything done with it. It doesn't even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn't realize he's looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.

- http://www.paulgraham.com/avg.html

"""

Being able to express an idea concisely (IE, "save two lines") is a big part of why we bother to innovate on programming languages. It's what it means for one language to be more powerful or expressive than another.

None-aware operators can help express an idea more concisely (IE, make python more powerful a language). I've used them to that effect in Ruby and CoffeeScript.

I agree there is potential for terseness. Every project needs to have a sense of where the team stands on terseness versus time - probably don't use `??` much if you're creating tutorials or teaching, but also avoid other pitfalls - picking unclear variable names, writing deeply nested logic (cyclomatic complexity), or clunky nested list comprehensions.

Avoiding needless terseness is the job of the programmer or the code reviewer, not the language. The job of the language is to provide power, or the ability to concisely describe intent. None-aware operators have helped me with that in other languages, and would be great to have in python.

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

#44

Post by marcosdumay »

gaius wrote: post #24
hnra wrote: post #22

Earlier quoted context omitted.

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#

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

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

#45

Post by dragonwriter »

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…

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

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

#46

Post by dragonwriter »

marcosdumay wrote: post #44
gaius wrote: post #24

Earlier quoted context omitted.

operators from C# Why not go the whole hog then, and do a Option[1] ;-) [1] https://en.wikipedia.org/wiki/Option_type#F#

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.

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

#47

Post by shawnz »

I'm disappointed to see that everyone hates this PEP. I think null-conditional operators are pretty self explanatory even to beginners and they have the potential to remove a lot of boilerplate which actually could improve code readability in many cases. I wonder if this massively negative response isn't just a reaction to everyone having been burned by the PEP 572 debacle.

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

#48

Post by thijsvandien »

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…

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.

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

#49

Post by thijsvandien »

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…

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

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

#50

Post by talltimtom »

CurlyJefferson wrote: post #11
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 cont…

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

I must say I agree fully, and even so, in cases where you really want to cut down verbose sections or boilerplate, there is so much you can do through defining your own classes and functions and overloading operators. Even then there is little need for new fundamental syntax.

Post reply on HN