Both this discussion, PEP 505, and the one a year ago, tend to mix up 2
related but separate proposals:
w
(A) Add a None-coalescing operator (like C# a ?? b, what you would write in
Python as "a or b" if it didn't have the falsy gotcha)
(B) Add some None-aware navigation operators ( The "?.", "?()", "?[]", or
what you would write in python as "a and a.attribute" if it didn't have the
falsy gotcha)
Both are things that can be already done in python, so the purpose here is
to add some convenience (aka "syntax sugar"). IMO, this kind of syntax
sugar proposals should be weighed with the frequency of the coding pattern
where the sugar can be applied. And from the stats presented in PEP-505 (B)
is one order of magnitude less usual than (A); that matches most of the
examples I see in the threads and FWIW my personal experience.
So, as a counterproposal I would like to suggest:
* Add an "a ?? b" operator which is equivalent to "a if a is None else b"
(but evaluating a once)
* Do not add none-aware navigation; in the less usual scenario where you
need to do it AND ALSO the "and" operator is not usable (it frequently is,
given that by default classes are truish), well, you can use a ternary
operator
* I don't care if it's an alternate syntax (I'm surprised nobody suggested
"||" which is also used in other languages for similar purpose)
Would this satisfy most of the people requesting this? (and, would it
satisfy the people making the decision?)
On Sun, Sep 11, 2016 at 4:45 AM, Bruce Leban <br...@leban.us> wrote:
>
> On Sat, Sep 10, 2016 at 6:02 PM, David Mertz <me...@gnosis.cx> wrote:
>
>> What I was getting at with "essentially" was that it would *do the same
>> thing* that an AttributeError does. That is, if `x.foo` can't be evaluated
>> (i.e. x doesn't have an attribute 'foo'), then access is informally "an
>> error." The hypothetical "x?.foo" catches that "error" and substitutes a
>> different value. The particular implementation under-the-hood is less
>> important for most programmers who might use the construct (and I think
>> documentation would actually give an informal equivalent as something
>> similar to what I put in the NoneCoalesce class).
>>
>
> That's not a good way to think about it. This new operator is only
> checking for None and not actually checking for AttributeErrors. Consider:
>
> (3).x # AttributeError
> {}.x # AttributeError
>
> None.x # AttributeError
>
>
> (3)?.x # still AttributeError
>
> {}?.x # still AttributeError
>
> None?.x # None
>
>
> And also:
>
> None.__class__ # <type 'NoneType'>
>
> None?.__class__ # None
>
>
> And it's certainly not the case that those values don't accept any
> attributes:
>
> (3).real # 3
> {}.values # <built-in method ...>
> None.__class__ #<type 'NoneType'>
>
> --- Bruce
> Check out my puzzle book and get it free here:
> http://J.mp/ingToConclusionsFree (available on iOS)
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Daniel F. Moisset - UK Country Manager
www.machinalis.com
Skype: @dmoisset
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
