Very strange PEP. Most `??` cases can be covered with simple `or`.
[deleted]
PEP 505: Bringing None-Aware Operators to Python
21–30 of 80 posts
Re: PEP 505: Bringing None-Aware Operators to Python
#22Earlier 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...
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...
Re: PEP 505: Bringing None-Aware Operators to Python
#23Here's a write up of the chilly reception this recently received on the python-ideas mailing list: https://lwn.net/Articles/760993/
The whole endeavor seems a bit quixotic to me. This kind of change would no doubt cause such a stir that there’d be a fork before long.
Re: PEP 505: Bringing None-Aware Operators to Python
#24Earlier quoted context omitted.
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...
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] ;-)
Re: PEP 505: Bringing None-Aware Operators to Python
#25We 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:
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')
From PEP description:
From bisect.py:
def insort_right(a, x, lo=0, hi=None):
# ...
if hi is None:
hi = len(a)
# ...
After updating to use the ??= augmented assignment statement:
def insort_right(a, x, lo=0, hi=None):
# ...
hi ??= len(a)
# ...
Finally, The Zen of Python
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Re: PEP 505: Bringing None-Aware Operators to Python
#26sigh 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 incur upon themselves so much trouble by lacking such a simple thing as the monad abstraction?
Re: PEP 505: Bringing None-Aware Operators to Python
#27Please don’t do this, Python!
I agree that the common patterns used for None values can be verbose; but, they’re readable and clear. PEP 505 syntax looks like Martian.
IMHO, core developers should spend the next two years focusing on performance.
If they can just make cPython 50% faster (avg) and use 25% less memory (avg), Python can capture so much more marketshare; this increases the value of the ecosystem and economies of scale therein.
The language itself needs no changes.
Re: PEP 505: Bringing None-Aware Operators to Python
#28Earlier 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#
Option is bubkes if the language itself still has the billion-dollar mistake; that's why F# and Scala are far less practical than OCaml. Python also has it with "None" (though since it is dynamically typed, it's arguable that from the perspective of any given type, every value of every other type is a fresh instance of the billion-dollar mistake).
And sadly, removing None from Python and replacing it by Option - let alone removing Exception and letting Result (aka Either) take its rightful place - would cause huge amount of Python code to need rewriting. And it wouldn't even be worth it because of dynamic typing.
Re: PEP 505: Bringing None-Aware Operators to Python
#29Earlier 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…
> 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.
The solution is for them to fire up the time-machine, go back to when the code-base was just leaving the prototype stage, and assault their earlier selves with clue-by-fours while chanting something to the effect of "use a real language for real problems!".
Re: PEP 505: Bringing None-Aware Operators to Python
#30Earlier quoted context omitted.
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.
I would really just write `if x is None: x = []`