I messed up my answer and replied to one person instead of the list, so
I'll post it again.
There is also an alternative to this operator, and it's allowing a
shortcut to do:
try:
val = do_thing()
except ThingError:
val = "default"
In the form of:
val = do_thing() except ThingError: "default"
I was debated, and rejected, but I feel like mentioning it again because
it has some strong benefits.
First, it handles the null coalescing very quite well:
val = obj.foo.bar.hey except AttributeError: "default"
But it also can deal with many common operations in Python without the
need to add more operators or variants:
val = my_list[0] except IndexError: "default"
val = iterable[0] except TypeError: next(iter(iterable))
val = int(param) except ValueError: man.nan
It's quite readable, in the same vein of val = foo if bar else
"default", but also familiar since it's using known keyword. And it
doesn't require to add a new operator support in the parser.
Another serious benefits is that it fits current use cases, AND futur
use cases. Indeed, since it leverages Python exception mechanism, any
lib implementing a clean error model can immediately let the users
benefit from it without having to implement, tests and document lots of
helper methods with "default" keywords and the like, while not being
limited to a set of values some operators would only care about, such as
None.
Plus, since EAFP is a popular and handy pattern, it makes sense.
At last, it has the same characteristic as the null coalescing operator:
it's lazy, and hence has a small performance interest too compared to
functional equivalent.
Did I mention it's also easy to expend to a full try/except when you
need something more complicated ? And then you benefit from else and
finally immediately.
I already have many code that would benefit from such a syntax, and I'd
like to hear again what you think about it.
Le 11/09/2016 à 21:44, Daniel Moisset a écrit :
> 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
> <mailto:br...@leban.us>> wrote:
>
>
> On Sat, Sep 10, 2016 at 6:02 PM, David Mertz <me...@gnosis.cx
> <mailto: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
> <http://J.mp/ingToConclusionsFree> (available on iOS)
>
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org <mailto:Python-ideas@python.org>
> https://mail.python.org/mailman/listinfo/python-ideas
> <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/
> <http://python.org/psf/codeofconduct/>
>
>
>
>
> --
> Daniel F. Moisset - UK Country Manager
> www.machinalis.com <http://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/
>
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
