This general API discussion is veering off-topic for the subject line. If
people would like to continue to discuss it then please start a new thread
(if you feel it impacts your view of a null-coalescing operator then please
discuss in the new thread and come back to this one).
On Tue, 13 Sep 2016
On 2016-09-13 16:27, Rob Cliffe wrote:
On 13/09/2016 12:37, Nick Coghlan wrote:
On 13 September 2016 at 21:15, Rob Cliffe wrote:
On 13/09/2016 04:43, Guido van Rossum wrote:
Yeah, that's exactly my point. PEP 463 gives you a shorter way to
catch an exception, so it gives you less motivation
On Wed, Sep 14, 2016 at 1:27 AM, Rob Cliffe wrote:
> And sorry to repeat myself, but we seemed to be having a *general*
> discussion about null-coalescing operators, which moved on to PEP 463, then
> suddenly Guido is talking about APIs. A lot of the time when I'm coding,
> I'm not writing an API
On 13/09/2016 12:37, Nick Coghlan wrote:
On 13 September 2016 at 21:15, Rob Cliffe wrote:
On 13/09/2016 04:43, Guido van Rossum wrote:
Yeah, that's exactly my point. PEP 463 gives you a shorter way to
catch an exception, so it gives you less motivation to find a way to
write your code (or de
On Wed, Sep 14, 2016 at 12:14 AM, Random832 wrote:
> On Tue, Sep 13, 2016, at 07:37, Nick Coghlan wrote:
>> P.S. There are also some use cases where Look-Before-You-Leap is
>> inherently subject to race conditions,
>
> Which use cases *aren't*?
Ones in which no external force can affect things. F
On Tue, Sep 13, 2016, at 08:44, Michel Desmoulin wrote:
> You won't see very complex usages, mostly things like:
>
> val = foo[-1] except IndexError: "bar"
> doh = val.attr.other except AttributeError: "default"
It occurs to me that if lambda were more lightweight [whether it's the
syntax or the
On Tue, Sep 13, 2016, at 07:37, Nick Coghlan wrote:
> P.S. There are also some use cases where Look-Before-You-Leap is
> inherently subject to race conditions,
Which use cases *aren't*?
> and for those, exceptions are the only reliable signaling mechanism.
It's entirely possible to design a non
I doubt very much it will be used for very complexe cases. Just like
comprehensions or ternary expressions, they are a good fit for some
specific use cases, and people will quickly catch on which one.
You rarely see nested comprehensions or ternary expressions while it's
possible to do so, because
On 13 September 2016 at 21:15, Rob Cliffe wrote:
> On 13/09/2016 04:43, Guido van Rossum wrote:
>> Yeah, that's exactly my point. PEP 463 gives you a shorter way to
>> catch an exception, so it gives you less motivation to find a way to
>> write your code (or define your API) that doesn't involve
On 13/09/2016 04:43, Guido van Rossum wrote:
On Mon, Sep 12, 2016 at 5:45 PM, Rob Cliffe wrote:
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify
On 13 September 2016 at 07:13, Paul Moore wrote:
> If I understand the proposal, f is actually intended to be equivalent to:
>
> def f(spam):
> spam_val = spam()
> if spam_val is None:
> return None
> eggs_val = spam_val.eggs()
> if eggs_val is None:
On Mon, Sep 12, 2016 at 5:45 PM, Rob Cliffe wrote:
>
>
> On 12/09/2016 16:37, Guido van Rossum wrote:
>>
>> For the record, I still really don't like PEP 463. We should strive to
>> catch fewer exceptions, not make it easier to catch them.
>
> Can you please clarify what you are saying in the last
On 13/09/2016 01:45, Rob Cliffe wrote:
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify what you are saying in the last sentence?
The first tim
On 09/12/2016 08:37 AM, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
I certainly agree with the first part, slightly reworded: we should strive to
generate fewer exceptions that we have
On 12/09/2016 16:37, Guido van Rossum wrote:
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
Can you please clarify what you are saying in the last sentence?
The first time I read it, my brain parsed it as "People
On Mon, Sep 12, 2016 at 3:13 PM, Paul Moore wrote:
> From previous explanations in this thread, that's *not* the behaviour at all.
Gah, you're right. I knew better too. The diversion back to PEP 463
crossed some wires in my brain. :)
>
> If I understand the proposal, f is actually intended to
On 09/12/2016 02:13 PM, Paul Moore wrote:
On 12 September 2016 at 21:47, Eric Snow wrote:
Note that there's a subtle difference here when multiple lookups are
involved. Given:
def f(spam):
return spam().eggs().ham
With null-coalescing:
def f(spam):
return spam()
On 12 September 2016 at 21:47, Eric Snow wrote:
> Note that there's a subtle difference here when multiple lookups are
> involved. Given:
>
> def f(spam):
> return spam().eggs().ham
>
> With null-coalescing:
>
> def f(spam):
> return spam()?.eggs()?.ham
>
> This is roughly
On Mon, Sep 12, 2016 at 1:05 AM, Michel Desmoulin
wrote:
> 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"
Note tha
For the record, I still really don't like PEP 463. We should strive to
catch fewer exceptions, not make it easier to catch them.
On Mon, Sep 12, 2016 at 7:09 AM, Chris Angelico wrote:
> On Tue, Sep 13, 2016 at 12:03 AM, Rob Cliffe
> wrote:
>> Assuming you can't break existing code that already
On Tue, Sep 13, 2016 at 12:03 AM, Rob Cliffe wrote:
> Assuming you can't break existing code that already traps TypeError,
> AttributeError, etc., I don't see how you can do this without
> having separated kinds of NoneError which were subclasses of TypeError,
> AttributeError, etc.
class NoneErr
On 12/09/2016 11:01, Ivan Levkivskyi wrote:
On 12 September 2016 at 09:05, Michel Desmoulin
mailto:desmoulinmic...@gmail.com>> wrote:
In the form of:
val = do_thing() except ThingError: "default"
[...]
But it also can deal with many common operations in Python without the
On Mon, Sep 12, 2016, at 06:01, Ivan Levkivskyi wrote:
> I like this idea, I would propose a (maybe crazy) addition to it. What
> about a special exception NoneError, that will catch TypeError,
> AttributeError etc. but only when it was caused by None(),
> None.attr, None[1], etc. With this one ca
On 12/09/2016 08:05, Michel Desmoulin wrote:
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 th
On 12 September 2016 at 09:05, Michel Desmoulin
wrote:
> In the form of:
>
> val = do_thing() except ThingError: "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: "defau
On 09/12/2016 12:05 AM, Michel Desmoulin wrote:
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 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: "de
On Sun, Sep 11, 2016 at 6:11 PM, Guido van Rossum wrote:
> On Sun, Sep 11, 2016 at 6:00 PM, David Mertz wrote:
> > None if a is None else a.foo
>
> This is the crux of the matter to me. It's just too verbose, and the
> `if` and `else` keywords are lost in the noise of all the other words
> o
On Sun, Sep 11, 2016 at 6:00 PM, David Mertz wrote:
> None if a is None else a.foo
This is the crux of the matter to me. It's just too verbose, and the
`if` and `else` keywords are lost in the noise of all the other words
on the line. Plus the big win when it applies) is that if `a` is in
fac
On 2016-09-12 01:26, Guido van Rossum wrote:
On Sun, Sep 11, 2016 at 12:44 PM, Daniel Moisset
wrote:
Both this discussion, PEP 505, and the one a year ago, tend to mix up 2
related but separate proposals:
I don't think there's that much of a mix-up. PEP 505 clearly describes
each proposal sep
On Sun, Sep 11, 2016 at 12:44 PM, Daniel Moisset
wrote:
> 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 go
On Sun, Sep 11, 2016 at 12:44 PM, Daniel Moisset
wrote:
> Both this discussion, PEP 505, and the one a year ago, tend to mix up 2
> related but separate proposals:
I don't think there's that much of a mix-up. PEP 505 clearly describes
each proposal separately and even gives a choice to accept or
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 "?.", "?()"
On Sat, Sep 10, 2016 at 6:02 PM, David Mertz 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 hypo
For kicks I looked at the code in a commercial product that we are open
sourcing very soon at Continuum Analytics. It has about 27k lines of
Python and Cython. I checked it just by running `grep -C3 'if.*None'` over
the source code and eyeballing.
Obviously, this code might be refactored if othe
On Sat, Sep 10, 2016, at 20:15, David Mertz wrote:
> On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
> >
> > There seems to be a major misunderstanding here. A None-coalescing
> > operator is not for catching AttributeError, it's a shortcut similar
> > to "a or b" except that it checks for "a i
On Sat, Sep 10, 2016, at 19:38, David Mertz wrote:
> x2 = x?.foo
>
> x3 = x?.bar?.baz?[x2]
A. if you're doing three different things with x, why are you using this
instead of wrapping it in an if statement?
B. Under some of the proposals, unless x.bar might be None independently
of x not
How much of the time is a branch of the None check a single fallback value
or attribute access versus how often a suite of statements within the
not-None branch?
I definitely check for None very often also. I'm curious what the breakdown
is in code I work with.
On Sep 10, 2016 7:10 PM, "Guido van
To the contrary. I read and write code that performs explicit checks
for None all the time. Catching AttributeError is often a code smell
or at least a measure of last resort.
On Sat, Sep 10, 2016 at 6:46 PM, David Mertz wrote:
> Ok, I have been thinking of the behavior too broadly. I realize now
Ok, I have been thinking of the behavior too broadly. I realize now that
`x?.foo` might still simply raise an AttributeError if x is neither None
nor a thing with a foo attribute.
The class I wrote is definitely too aggressive for the behavior described.
On the other hand, by being narrower in beh
On 2016-09-11 02:02, David Mertz wrote:
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum mailto:gu...@python.org>> wrote:
No. PEP 505 actually solves the problem without ever catching
AttributeError. Please read it.
I read it again (I did a year ago, but reviewed it now). I hadn't be
On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum wrote:
> No. PEP 505 actually solves the problem without ever catching
> AttributeError. Please read it.
>
I read it again (I did a year ago, but reviewed it now). I hadn't been
thinking that the *mechanism* of a new None-coalescing operator wou
No. PEP 505 actually solves the problem without ever catching
AttributeError. Please read it.
On Sat, Sep 10, 2016 at 5:15 PM, David Mertz wrote:
> On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
>>
>> There seems to be a major misunderstanding here. A None-coalescing
>> operator is not for c
On Sep 10, 2016 4:45 PM, "Guido van Rossum" wrote:
>
> There seems to be a major misunderstanding here. A None-coalescing
> operator is not for catching AttributeError, it's a shortcut similar
> to "a or b" except that it checks for "a is None" rather than bool(a).
That's exactly what the wrapper
There seems to be a major misunderstanding here. A None-coalescing
operator is not for catching AttributeError, it's a shortcut similar
to "a or b" except that it checks for "a is None" rather than bool(a).
On Sat, Sep 10, 2016 at 4:38 PM, David Mertz wrote:
> Sorry, I sent this accidentally as p
Sorry, I sent this accidentally as private reply, then tried to fix it on
phone. The latter produced horrible formatting. Please just read this
version.
On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum wrote:
> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
> `x?.bar`...
46 matches
Mail list logo
