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

61–70 of 80 posts

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

#61

Post by mmirate »

pjz wrote: post #60
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?

Yes, except for things that helpfully return "None" instead of raising an exception, on account of "not finding something is not exceptional behavior" or something like that.

And since "raise" is a statement, you have to write your own "raise_if_none" function and sprinkle it everywhere...

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

#62

Post by mmirate »

bvrmn wrote: post #56
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.

> compiler greed

What good compilers require, they repay hundredsfold in exhaustively eliminating entire categories of mistakes from every program that compiles without error.

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

#64

Post by kjeetgill »

tosser wrote: post #63

On small trick that Pythonistas hate: x = x if None else x Saves a ton of CPU time and is beautiful.

Huh, what's that do? It seems to assign x = x which is reminiscent of my pet "ugly" optimization: adding x = x to the top of a nested scope. It binds the x from a global scope to x in a local one. Local variable lookup can be substantialy faster given a hot enough loop.

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

#65

Post by kjeetgill »

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…

> Does is look shorter? - YES!. Is it more readable? Arguably yes. Would I vote to see this feature in Python? HELL NO!

No one has quite summed up my thoughts better than you.

Hell, I would love it and love to use it but I thing it's relatively out of place in Python. Python just has many more ways to solve what should be a rare discouraged situation.

I think it has a better place in languages like C#/Java that tend to have deeper, more rigid object hierarchies and more reasons for using nulls.

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

#66

Post by bvrmn »

mmirate wrote: post #62
bvrmn wrote: post #56

Earlier quoted context omitted.

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

> compiler greed What good compilers require, they repay hundredsfold in exhaustively eliminating entire categories of mistakes from every program that compiles without error.

> they repay hundredsfold

Most python apps is simple data proxies. Glue dicts from multiple sources into more complex dicts and pass further. If you will try to do proper modeling here you never accomplish a task.

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

#67

Post by mmirate »

bvrmn wrote: post #66
mmirate wrote: post #62

Earlier quoted context omitted.

> compiler greed What good compilers require, they repay hundredsfold in exhaustively eliminating entire categories of mistakes from every program that compiles without error.

> they repay hundredsfold Most python apps is simple data proxies. Glue dicts from multiple sources into more complex dicts and pass further. If you will try to do proper modeling here you never accomplish a task.

On the contrary. A simple data proxy involves not much computation, but mostly reshaping; what kind of thing you have becomes more important than what thing you have, and eliminating confusion in the former realm is precisely what static-typed code with proper modelling, excels at. And any competent static-typed language will have enough macro-like capabilities to generate the model code (along with as much of the boilerplate as possible) from a JSON Schema or similar.

(Confusion in the latter realm, on the other hand, is one of the most common sources of remaining bugs once typing errors and other footguns are eliminated-with-prejudice.)

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

#68

Post by kjeetgill »

msl09 wrote: post #18
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…

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…

I think you're being pretty uncharitable with that interpretation of educator's incentives.

That said, I think valuing relative beginners and non-programmers into the fold is and will be a strong point of the python ecosystem. It has fewer of R's excentricities and some of Java's straight forwardness while remaining relatively terse and to the point.

I think this addition would absolutely cut down on very frustrating boilerplate. The question is the cost to the ecosystem which is going to come down to speculation in any direction.

My opinion: no one change like this hurts a language much at all but the fear comes from the death of a thousand cuts.

This feature does two things: adds slightly crypic syntax which is very obvious to career programmers but somewhat opaque and unmemorable to anyone else.

Worse, it makes bad patterns convenient. Deep None filled object hierarchies (though occasionally unavoidable) will always be problematic in some way. This only serves to make those idiomatic.

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

#69

Post by mezzode »

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-else` for this will get messy quickly the more layers down you want to go.

  if a is not None and a.b is not None:
      c = a.b.c
  else:
      c = None
vs

  c = a?.b?.c
The safe navigation operator is useful enough that beginners ought to be introduced to them anyway. I will admit that adding `??` may be too much though, we could easily just use an `or` (although the PEP does have some justifications for adding it).

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

#70

Post by bvrmn »

mmirate wrote: post #67
bvrmn wrote: post #66

Earlier quoted context omitted.

> they repay hundredsfold Most python apps is simple data proxies. Glue dicts from multiple sources into more complex dicts and pass further. If you will try to do proper modeling here you never accomplish a task.

On the contrary. A simple data proxy involves not much computation, but mostly reshaping; what kind of thing you have becomes more important than what thing you have, and eliminating confusion in the former realm is precisely what static-typed code with proper modelling, excels at. And any competent static-typed language will have enough macro-like capabilities to generate the model code (along with as much of the bo…

If you will do proper modeling in each intermidiate processing unit you never accomplish a task. It is software design 101. We check invariants on the endpoints not in the middle.
Post reply on HN