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

51–60 of 80 posts

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

#51

Post by dragonwriter »

gaius wrote: post #13
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(":")

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

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

No, it's nothing like the Ruby convention. It's much more like th C# operators.

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

#52

Post by theelous3 »

shawnz wrote: post #47

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.

You have been deeply disconnected from beginners if you believe this. I absolutely assure you, someone new to programming will have no idea what in the name of god this is, and will struggle with it.

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

#54

Post by Silhouette »

thijsvandien wrote: post #48
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.

    (libpaths or '').split(":")
This isn't quite the same: if libpaths is None, the above will evaluate to [''], while the original evaluated to [].

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

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

#55

Post by bvrmn »

UncleEntity wrote: post #53
bvrmn wrote: post #19

Very strange PEP. Most `??` cases can be covered with simple `or`.

Not necessarily... x = 0 y = (x or 42) isn't the same as x = None y = (x or 42)

Yes, it isn't the same in a generic sense. But can be applied in many practical cases.

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

#56

Post by bvrmn »

mmirate wrote: post #26

sigh no, what Python should actually have is a way to compose fallible computations such that if any one should fail, the entire composition short-circuits and returns the error; while not needing each one to check its input for such a case. It could even be generalized so that it would work properly even for things other than the ad hoc union-type formed by the billion-dollar mistake... Why must so many languages in…

Monad abstraction is a mere crutch to fulfill compiler greed. It is not needed in dynamically typed langs.

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

#57

Post by shawnz »

theelous3 wrote: post #52
shawnz wrote: post #47

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.

You have been deeply disconnected from beginners if you believe this. I absolutely assure you, someone new to programming will have no idea what in the name of god this is, and will struggle with it.

How can you say that with such certainty? Do you have an example of a similar construct where you've experienced beginners being confused by it, or are you just dismissing my opinion based on your opinion?

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

#58

Post by pjz »

singularity2001 wrote: post #17
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.

This is subtly incorrect. Correctly, it should be:

    libpaths = paths.split(":") if paths is not None else []
or else falsey values of paths (0, [], False) can still cause an error.

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

#59

Post by pjz »

basicwolf wrote: post #25

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…

...why does everyone forget that `getattr()` has an optional `default` argument? It's helpful for stuff like this.

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

#60

Post by pjz »

mmirate wrote: post #26

sigh no, what Python should actually have is a way to compose fallible computations such that if any one should fail, the entire composition short-circuits and returns the error; while not needing each one to check its input for such a case. It could even be generalized so that it would work properly even for things other than the ad hoc union-type formed by the billion-dollar mistake... Why must so many languages in…

...isn't that called a `try` block?
Post reply on HN