Re: [Python-ideas] PEP 505: None-aware operators

[Nicholas Chammas]

On Wed, Jul 25, 2018 at 12:12 PM Nicholas Chammas <
nicholas.cham...@gmail.com> wrote:

> On Mon, Jul 23, 2018 at 6:05 PM Giampaolo Rodola' 
> wrote:
>
>> This:
>>
>> v = a?.b
>>
>> ...*implicitly* checks if value is not None [and continues execution].
>> This:
>>
>> v = a
>> if a.b is not None:
>> v = a.b
>>
>> ...*explicitly* checks if value is not None and continues execution.
>>
>
> I think both of those are equally explicit. It's just that one notation is
> more concise than the other. Explicitness and conciseness are related but
> different things.
>
> 
>

It looks like others already discussed this point later in the thread.
Apologies for rehashing the argument.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Nicholas Chammas]

On Mon, Jul 23, 2018 at 6:05 PM Giampaolo Rodola' 
wrote:

> This:
>
> v = a?.b
>
> ...*implicitly* checks if value is not None [and continues execution].
> This:
>
> v = a
> if a.b is not None:
> v = a.b
>
> ...*explicitly* checks if value is not None and continues execution.
>

I think both of those are equally explicit. It's just that one notation is
more concise than the other. Explicitness and conciseness are related but
different things.

When something is "explicit", as I understand it, that means it does what
it says on the cover. There is no unstated behavior. The plain meaning of
`v = a?.b` is that it expands to the longer form (`v = a; if a.b ...`), and
it is just as explicit.

This reminds me of something I read about once called Stroustrup's Rule
 [1]:

> For new features, people insist on LOUD explicit syntax.
> For established features, people want terse notation.

I think the "explicit vs. implicit" part of this discussion is probably
better expressed as a discussion about "loud vs. terse" syntax. None of the
operators in PEP 505 have implicit behavior, to the best of my
understanding. It's just that the operators are new and have terse
spellings.

As a point of comparison, I think a good example of implicit behavior is
type coercion. When you ask Python to add an int to a float

a = 3 + 4.5

all that you've explicitly asked for is the addition. However, Python
implicitly converts the 3 from an int to a float as part of the operation.
The type conversion isn't anywhere "on the cover" of the + operator. It's
implicit behavior.

[1] Bjarne Stroustrup makes the observation in this talk
 at
23:00.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

On Tue, Jul 24, 2018, 9:09 AM Chris Angelico  wrote:

> >>> x = Foo(cfg).user.profile
> >>> x.food
>
> Remember, these lines could be a very long way apart. You could pass
> 'x' to a function unrelated to the line of code that created it. And
> 'x.food' still has to have the magic. You can't mandate that the call
> to Coalesce be on the same line as the attribute access - Python
> doesn't work that way.
>
> So your perfectly ordinary dot operator now does magic in addition to
> normal attribute access. See why it's a dangerous thing?
>

Yes, of course. That's why I would recommend best practice is to unbox or
otherwise use the conditional value as close to the magic code as feasible.

Likewise, as I noted a little while ago, 'x.food' could equally well be a
property that executed arbitrarily slow, magical, obscure, or even
malicious operations. Equally, 'x + y' could do absolutely anything if we
define .__add__() or .__radd__() methods.

Everything in Python is magical in that sense, but we should deliberately
keep the magic constrained to the amount needed.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

I *definitely* don't think a little tool I wrote in a couple hours last
night belongs in the standard library (with most of the heavy lifting
actually done by wrapt—which is really well designed, and is also not in
the standard library). I also don't think PyMaybe belongs there, even
though it's a couple years old.

Now, perhaps, if 'coalescing' is widely used for a year or two. And bugs
are fixed. And the API is tweaked based on experience with it's use. And so
on... At that point, *maybe* something derived from it might be appropriate.

On Tue, Jul 24, 2018, 9:08 AM Rhodri James  wrote:

> On 24/07/18 14:02, David Mertz wrote:
> > On Tue, Jul 24, 2018, 7:38 AM Rhodri James  wrote:
> >> I'm still of the opinion that both approaches are trying to solve a
> >> problem that's too niche to merit them, BTW.
> >>
> >
> > That doesn't make sense to me. You think my little library shouldn't be
> > allowed on PyPI? I don't force the couple classes on anyone, but if they
> > happen to help someone (or PyMaybe, or some other library, does) they
> don't
> > change anything about Python itself. Syntax is a very different matter.
>
> I have no objection to anyone putting anything on PyPI.  Putting it (or
> an equivalent) in the standard library is much more problematical, and
> you were talking about that.  I think your little library is a much
> richer source of bugs than you think it is, and dealing with messy data
> access isn't a good enough reason to put that much temptation in front
> of naive users.
>
> --
> Rhodri James *-* Kynesim Ltd
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Tue, Jul 24, 2018 at 11:02 PM, David Mertz  wrote:
> On Tue, Jul 24, 2018, 7:38 AM Rhodri James  wrote:
>>
>> On 24/07/18 12:02, David Mertz wrote:
>> > Every use I've suggested for the magic proxy is similar to:
>> >
>> >NullCoalesce(cfg).user.profile.food
>> >
>> > Yes, the class is magic. That much more so in the library I published
>> > last
>> > night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in
>> > that an actual*word*  announces that funny stuff is going to happen on
>> > the
>> > same line.
>>
>>   Foo(cfg).user.profile.food
>>
>> Is that explicit that funny stuff is going to happen on the same line? I
>> wouldn't generally assume so, I'd just assume the coder created a throwaway
>> object to get at an attribute.
>
>
> Foo isn't a very indicative name. NoneCoalesce (or NullCoalesce, or
> GreedyAccess) is. But if I had any doubt, I could read the docstring for Foo
> to find out how magical it was, and in what way. I definitely know
> *something* is happening by creating that new instance in the line.
>

Okay. Check this out, then:

>>> x = Foo(cfg).user.profile
>>> x.food

Remember, these lines could be a very long way apart. You could pass
'x' to a function unrelated to the line of code that created it. And
'x.food' still has to have the magic. You can't mandate that the call
to Coalesce be on the same line as the attribute access - Python
doesn't work that way.

So your perfectly ordinary dot operator now does magic in addition to
normal attribute access. See why it's a dangerous thing?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Rhodri James]

On 24/07/18 14:02, David Mertz wrote:

On Tue, Jul 24, 2018, 7:38 AM Rhodri James  wrote:

I'm still of the opinion that both approaches are trying to solve a
problem that's too niche to merit them, BTW.



That doesn't make sense to me. You think my little library shouldn't be
allowed on PyPI? I don't force the couple classes on anyone, but if they
happen to help someone (or PyMaybe, or some other library, does) they don't
change anything about Python itself. Syntax is a very different matter.


I have no objection to anyone putting anything on PyPI.  Putting it (or 
an equivalent) in the standard library is much more problematical, and 
you were talking about that.  I think your little library is a much 
richer source of bugs than you think it is, and dealing with messy data 
access isn't a good enough reason to put that much temptation in front 
of naive users.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

On Tue, Jul 24, 2018, 7:38 AM Rhodri James  wrote:

> On 24/07/18 12:02, David Mertz wrote:
> > Every use I've suggested for the magic proxy is similar to:
> >
> >NullCoalesce(cfg).user.profile.food
> >
> > Yes, the class is magic. That much more so in the library I published
> last
> > night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in
> > that an actual*word*  announces that funny stuff is going to happen on
> the
> > same line.
>
>   Foo(cfg).user.profile.food
>
> Is that explicit that funny stuff is going to happen on the same line? I
> wouldn't generally assume so, I'd just assume the coder created a throwaway
> object to get at an attribute.


Foo isn't a very indicative name. NoneCoalesce (or NullCoalesce, or
GreedyAccess) is. But if I had any doubt, I could read the docstring for
Foo to find out how magical it was, and in what way. I definitely know
*something* is happening by creating that new instance in the line.

I'm still of the opinion that both approaches are trying to solve a
> problem that's too niche to merit them, BTW.
>

That doesn't make sense to me. You think my little library shouldn't be
allowed on PyPI? I don't force the couple classes on anyone, but if they
happen to help someone (or PyMaybe, or some other library, does) they don't
change anything about Python itself. Syntax is a very different matter.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Rhodri James]

On 24/07/18 13:07, Richard Damon wrote:

The fact that you changed NullCoalesce into Foo to show lack of explicitness 
seems a straw-man. Words are FULL of meaning, while symbols are less so. The 
biggest issue I see with the use of ? here is that ? does have some meaning, it 
says we are going to be (or have) asked a question, it doesn’t tell us what the 
question is. Most of the other symbols used have a long history of meaning (yes 
= has the problem that historically it has had two possible meanings). To me, ? 
gives no indication that it is going to ask about Nullness.


Oh, I don't disagree with you about ? not giving any much indication 
that it's about Nullness except for the (relatively short) history of 
using it to mean exactly that in C# etc.  However I don't think that a 
class of whatever name doing something magic is any better.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

Both approaches should not be exposed as core language, but as facilitating 
tools to be used if, in your application, you have to traverse deep 
semi-regular attributes hierarchies.
The operator approach, by definition, is part of the core, so -1
The wrapper does not need to be included in python, so the discussion is 
meaningless: people define the tools they want and use them as they please.
Personally, I think it would be nice to have that in the standard distrib, 
especially wrapt or something as powerful. But I don't really care in fact, 
what good is that now I know about it so I can use it...___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Richard Damon]

> On Jul 24, 2018, at 7:37 AM, Rhodri James  wrote:
> 
>> On 24/07/18 12:02, David Mertz wrote:
>> Every use I've suggested for the magic proxy is similar to:
>>   NullCoalesce(cfg).user.profile.food
>> Yes, the class is magic. That much more so in the library I published last
>> night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in
>> that an actual*word*  announces that funny stuff is going to happen on the
>> same line.
> 
> Foo(cfg).user.profile.food
> 
> Is that explicit that funny stuff is going to happen on the same line? I 
> wouldn't generally assume so, I'd just assume the coder created a throwaway 
> object to get at an attribute.  You have to know that "NullCoalesce" does 
> magic before it is at all explicit that funny stuff will happen.  Thinking 
> about it, NullCoalesce() may be *less* explicit than ?. because at least that 
> doesn't look like ordinary attribute reference.
> 
> I'm still of the opinion that both approaches are trying to solve a problem 
> that's too niche to merit them, BTW.
> 
> -- 
> Rhodri James *-* Kynesim Ltd

The fact that you changed NullCoalesce into Foo to show lack of explicitness 
seems a straw-man. Words are FULL of meaning, while symbols are less so. The 
biggest issue I see with the use of ? here is that ? does have some meaning, it 
says we are going to be (or have) asked a question, it doesn’t tell us what the 
question is. Most of the other symbols used have a long history of meaning (yes 
= has the problem that historically it has had two possible meanings). To me, ? 
gives no indication that it is going to ask about Nullness.

?. has some indication that we are doing an attribute access that is in some 
way conditional, but a?.b could mean that we are conditional on a not being 
null, or it could be asking to suppress any and all error in getting b, even if 
a is an int and thus doesn’t have a b. The words carry a lot more meaning.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Rhodri James]

On 24/07/18 12:56, Grégory Lielens wrote:


On Tuesday, July 24, 2018 at 1:38:42 PM UTC+2, Rhodri James wrote:

-snip-
I'm still of the opinion that both approaches are trying to solve a
problem that's too niche to merit them, BTW.


That's also my impression. Hence the second approach: it does not require
any change to python, it's just a tool for that niche, so imho it's the
right approach.


OK, I'm confused.  Either you agree with me, and think the second 
approach is also wrong, or you think the second approach is right and 
disagree with me.  Which is it?


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

On Tuesday, July 24, 2018 at 1:38:42 PM UTC+2, Rhodri James wrote:
>
> -snip-
> I'm still of the opinion that both approaches are trying to solve a 
> problem that's too niche to merit them, BTW. 


That's also my impression. Hence the second approach: it does not require 
any change to python, it's just a tool for that niche, so imho it's the 
right approach. Such a wrapper can even be provided by the lib that 
produced such nested attributes in the first place. The operator are a tool 
which seems designed to the same niche issue, but is exposed as a core 
language feature. It may be interesting if it provides a lot of side 
benefits, so the tool is so braodly useful it outgrowned it's niche origin. 
At this point, I do not think it does.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Rhodri James]

On 24/07/18 12:02, David Mertz wrote:

Every use I've suggested for the magic proxy is similar to:

   NullCoalesce(cfg).user.profile.food

Yes, the class is magic. That much more so in the library I published last
night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in
that an actual*word*  announces that funny stuff is going to happen on the
same line.


 Foo(cfg).user.profile.food

Is that explicit that funny stuff is going to happen on the same line? 
I wouldn't generally assume so, I'd just assume the coder created a 
throwaway object to get at an attribute.  You have to know that 
"NullCoalesce" does magic before it is at all explicit that funny stuff 
will happen.  Thinking about it, NullCoalesce() may be *less* explicit 
than ?. because at least that doesn't look like ordinary attribute 
reference.


I'm still of the opinion that both approaches are trying to solve a 
problem that's too niche to merit them, BTW.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

On Tue, Jul 24, 2018, 5:50 AM Steven D'Aprano  wrote:

> But what certainly *is* implicity is David Mertz' suggestion for a
> magical None-aware proxy:
>
> x.attribute
>
> The only way to tell whether that was an ordinary attribute lookup or a
> none-aware lookup would be to carefully inspect x and find out whether it
> was an instance of the None-aware proxy class or not.
>

Every use I've suggested for the magic proxy is similar to:

  NullCoalesce(cfg).user.profile.food

Yes, the class is magic. That much more so in the library I published last
night that utilizes wrapt.ObjectProxy. But it's also pretty explicit in
that an actual *word* announces that funny stuff is going to happen on the
same line.

Of course the this could be abused with:

  cfg = NoneCoalesce(cfg)
  ... 1000 lines ...
  do_something(cfg)

But then, I could also write a property that actually started a computation
of the millionth digit of pi while launching a DDoS attack on python.org
when a user accessed 'x.attribute'.

NoneCoalesce or GreedyAccess are magic, but in their intended use, they are
as little magical as possible to deal with messy nested data.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Tue, Jul 24, 2018 at 11:50 AM Steven D'Aprano  wrote:
>
> On Tue, Jul 24, 2018 at 12:05:14AM +0200, Giampaolo Rodola' wrote:
>
> > This:
> >
> > v = a?.b
> >
> > ...*implicitly* checks if value is not None [and continues execution].
>
> Do you agree that:
>
> obj.attribute
> x + 1
> func(arg)
>
> explicitly looks up an attribute on obj, explicitly adds 1 to x, and
> explicitly calls func with a single argument? I don't think that we have
> to write COBOL-esque code to be explicit:
>
> GET ATTRIBUTE "attribute" FROM obj
> ADD 1 TO x
> CALL FUNCTION func WITH ARGUMENT arg
>
> I don't accept that the use of punctuation makes something implicit. But
> if you want to argue that anything with punctuation is "implicit", then
> okay, Python has lots of implicit punctuation.
> By definition, ?. checks for None before doing the attribute lookup.
> That is completely explicit, regardless of how it is spelled:
>
> obj?.attribute

You totally missed my point about explicitness. Nevermind.

> > This
> >
> > v = a
> > if a.b is not None:
> > v = a.b
> >
> > ...*explicitly* checks if value is not None and continues execution.
>
> If you are trying to match the behaviour of a?.b above, it is also
> completely buggy and doesn't do what is intended.
>
> # Equivalent of a?.b
> v = a
> if v is not None:
> v = v.b
>
>
> > If for some reason '?'[ is also going to swallow LookupError
>
> What makes you think that ?[...] will swallow LookupError?
>
> Please don't argue against misfeatures that the PEP doesn't propose.
> Nothing in PEP 505 swallows any exceptions. Swallowing exceptions is
> explicitly rejected, and swallowing LookupError isn't part of the
> proposal.

I know it's not in the PEP. I merely mentioned that as PEP author was
questioning that possibility in previous messages. It was an example
(for you) on how *that* would make things even less explicit.

> [...]
> > One may argue that silently returning None instead of raising
> > AttributeError is also less explicit.
>
> And again, you are arguing against a misfeature which PEP 505 does not
> propose. The ?. operator will not suppress AttributeErrors.
>
> # Wrong! No! This is not what the PEP proposes!
> obj = 1.234
> assert obj?.hexx is None

That is not what I meant at all!
I seriously question whether you really don't understand or you're
just pretending.
What I meat in here was 'a?.b?.c?' returning None in case 'b' is None.

> [...]
> > > It isn't a first. Many existing operators use two adjacent symbols not
> > > interrupted by a space:
> > >
> > > e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.
> >
> > You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> > would be less intuitive anyway). You can't because '.?' is the only
> > couple of contiguous symbols requiring "something" before and after
> > with no spaces in between, and that's a first in the language.
>
> Why do you think spaces aren't allowed? The PEP explicitly says that
> the new operators can be used wherever the regular operators can be
> used.
> [...]
> That tells me that ?. will be legal anywhere . is legal, so if x . y is
> legal (and it is) so will x ?. y be legal.

Yes, I forgot 'a . b' was legal - my bad.

> [...]
> > The difference is that 'a.b.c.d' will result in AttributeError as soon
> > as something is None while 'a?.b?.c?.d' will return None instead.
>
> Correct. Because sometimes you want an AttributeError, and sometimes you
> want None.
>
> You are criticising the operator for doing what it is designed and
> intended to do. You might as well criticise getattr(obj, 'spam', None)
> for returning None.
>
> If you want an AttributeError, then don't use ?. and use ordinary .
> instead.

Again, you missed my point.

> > > Likewise the logical operators "or" and "and" are designed to
> > > short-circuit. If ?? and friends are a mistake because they
> > > short-circuit, why aren't "or" and "and" mistakes?
> > > I'm not asking this as a rhetorical question. If you think there is a
> > > reason why it is okay for or/and to short-circuit, but it is bad for ??
> > > and friends to short-circuit, then please explain why they are
> > > different. I will be very happy to listen to your arguments.
> >
> > The argument about this is that '?.' short-circuits execution
> > *silently*.
>
> Other short-circuit operators also short-circuit execution silently.
> That's what they are designed to do.
>
> # This isn't what actually happens.
> py> x = 0
> py> result = x and 1/x
> __main__:1: UserWarning:
> Short-cut operation occurred, the right hand operand was not
> evaluated!!! Do not panic, this is the expected behaviour!!!
> py> print(result)
> 0
>
>
> > Instead of AttributeError you get None. You may chain ?.
> > in order to lazily traverse a long tree,
>
> Correct, that is what it is designed to do.
>
>
> > inadvertently assign None to
> > a variable, continue code 

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Tue, Jul 24, 2018 at 12:05:14AM +0200, Giampaolo Rodola' wrote:

> This:
> 
> v = a?.b
> 
> ...*implicitly* checks if value is not None [and continues execution]. 

Do you agree that:

obj.attribute
x + 1
func(arg)

explicitly looks up an attribute on obj, explicitly adds 1 to x, and 
explicitly calls func with a single argument? I don't think that we have 
to write COBOL-esque code to be explicit:

GET ATTRIBUTE "attribute" FROM obj
ADD 1 TO x
CALL FUNCTION func WITH ARGUMENT arg

I don't accept that the use of punctuation makes something implicit. But 
if you want to argue that anything with punctuation is "implicit", then 
okay, Python has lots of implicit punctuation.

By definition, ?. checks for None before doing the attribute lookup. 
That is completely explicit, regardless of how it is spelled:

obj?.attribute

NULL-AWARE GET ATTRIBUTE "attribute" FROM obj

null_aware_getattr(obj, "attribute")

getattr_if_not_none(obj, "attribute")

But what certainly *is* implicity is David Mertz' suggestion for a 
magical None-aware proxy:

x.attribute

The only way to tell whether that was an ordinary attribute lookup or a 
none-aware lookup would be to carefully inspect x and find out whether 
it was an instance of the None-aware proxy class or not.


> This
> 
> v = a
> if a.b is not None:
> v = a.b
> 
> ...*explicitly* checks if value is not None and continues execution.

If you are trying to match the behaviour of a?.b above, it is also 
completely buggy and doesn't do what is intended.

# Equivalent of a?.b
v = a
if v is not None:
v = v.b


> If for some reason '?'[ is also going to swallow LookupError 

What makes you think that ?[...] will swallow LookupError?

Please don't argue against misfeatures that the PEP doesn't propose. 
Nothing in PEP 505 swallows any exceptions. Swallowing exceptions is 
explicitly rejected, and swallowing LookupError isn't part of the 
proposal.


[...]
> One may argue that silently returning None instead of raising
> AttributeError is also less explicit.

And again, you are arguing against a misfeature which PEP 505 does not 
propose. The ?. operator will not suppress AttributeErrors.

# Wrong! No! This is not what the PEP proposes!
obj = 1.234
assert obj?.hexx is None


[...]
> > It isn't a first. Many existing operators use two adjacent symbols not
> > interrupted by a space:
> >
> > e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.
> 
> You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> would be less intuitive anyway). You can't because '.?' is the only
> couple of contiguous symbols requiring "something" before and after
> with no spaces in between, and that's a first in the language.

Why do you think spaces aren't allowed? The PEP explicitly says that 
the new operators can be used wherever the regular operators can be 
used:

"The maybe-dot and maybe-subscript operators are added as
trailers for atoms, so that they may be used in all the same
locations as the regular operators"

and explicitly shows the grammar changes required:

trailer: ('(' [arglist] ')' |
  '[' subscriptlist ']' |
  '?[' subscriptlist ']' |
  '.' NAME |
  '?.' NAME)


That tells me that ?. will be legal anywhere . is legal, so if x . y is 
legal (and it is) so will x ?. y be legal.


[...]
> The difference is that 'a.b.c.d' will result in AttributeError as soon
> as something is None while 'a?.b?.c?.d' will return None instead.

Correct. Because sometimes you want an AttributeError, and sometimes you 
want None.

You are criticising the operator for doing what it is designed and 
intended to do. You might as well criticise getattr(obj, 'spam', None) 
for returning None.

If you want an AttributeError, then don't use ?. and use ordinary . 
instead.


> > Likewise the logical operators "or" and "and" are designed to
> > short-circuit. If ?? and friends are a mistake because they
> > short-circuit, why aren't "or" and "and" mistakes?
> > I'm not asking this as a rhetorical question. If you think there is a
> > reason why it is okay for or/and to short-circuit, but it is bad for ??
> > and friends to short-circuit, then please explain why they are
> > different. I will be very happy to listen to your arguments.
> 
> The argument about this is that '?.' short-circuits execution
> *silently*.

Other short-circuit operators also short-circuit execution silently. 
That's what they are designed to do.

# This isn't what actually happens.
py> x = 0
py> result = x and 1/x
__main__:1: UserWarning:
Short-cut operation occurred, the right hand operand was not 
evaluated!!! Do not panic, this is the expected behaviour!!!
py> print(result)
0


> Instead of AttributeError you get None. You may chain ?.
> in order to lazily traverse a long tree, 

Correct, that is what it is designed to do.


> 

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Tue, Jul 24, 2018 at 2:22 AM MRAB  wrote:

> >> > It
> >> > does so by introducing a brand new operator ("?") which can be spelled
> >> > in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
> >> > interrupted by any space, which is an absolute first in the Python
> >> > syntax
> >>
> >> It isn't a first. Many existing operators use two adjacent symbols not
> >> interrupted by a space:
> >>
> >> e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.
> >
> > You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
> > would be less intuitive anyway). You can't because '.?' is the only
> > couple of contiguous symbols requiring "something" before and after
> > with no spaces in between, and that's a first in the language.
>
> You _can_ say 'a ?. b', just as you _can_ say 'a . b'.

You're right. It's so uncommon I forgot this style was valid. Anyway,
as I said 'a ?. b' would be even worse the same way 'a . b' is worse
than 'a.b'. The recommended and broadly used spelling would be 'a?.b'.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Paul Moore]

On 24 July 2018 at 08:38, Grégory Lielens  wrote:
>
>
> On Tuesday, July 24, 2018 at 9:28:02 AM UTC+2, Brice Parent wrote:
>>
>> Le 24/07/2018 à 00:39, Chris Angelico a écrit :
>> > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  wrote:
>> ...
>> > What about:
>> >
>> > 5 < x < 10
>> >
>> > Can you add parentheses to that to "make precedence and evaluation order
>> > clear"?
>> Correct me if I'm wrong, but to my knowledge, this is just a shorthand
>> to `5 < x and x < 10`.
>
>
> I learned something here:
   -5<-2<-1<=-1>-3
> True
>
> I wonder how this works, especially as < and friends have magical __
> methods... How is it expanded in tne AST?

>>> import ast
>>> m = ast.parse('-5<-2<-1<=-1>-3')
>>> ast.dump(m)
'Module(body=[Expr(value=Compare(left=UnaryOp(op=USub(),
operand=Num(n=5)), ops=[Lt(), Lt(), LtE(), Gt()],
comparators=[UnaryOp(op=USub(), operand=Num(n=2)), UnaryOp(op=USub(),
operand=Num(n=1)), UnaryOp(op=USub(), operand=Num(n=1)),
UnaryOp(op=USub(), operand=Num(n=3))]))])'

Looks like there's a Compare node that takes a list of operators - and
indeed the docs say (at
https://docs.python.org/3.7/library/ast.html#abstract-grammar)

Compare(expr left, cmpop* ops, expr* comparators)

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

On Tuesday, July 24, 2018 at 9:28:02 AM UTC+2, Brice Parent wrote:
>
> Le 24/07/2018 à 00:39, Chris Angelico a écrit :
> > On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  > wrote:
> ...
> > What about:
> >
> > 5 < x < 10
> >
> > Can you add parentheses to that to "make precedence and evaluation order 
> clear"?
> Correct me if I'm wrong, but to my knowledge, this is just a shorthand 
> to `5 < x and x < 10`.


I learned something here:
>>>   -5<-2<-1<=-1>-3
True

I wonder how this works, especially as < and friends have magical __ 
methods... How is it expanded in tne AST?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Tue, Jul 24, 2018 at 5:26 PM, Brice Parent  wrote:
> Le 24/07/2018 à 00:39, Chris Angelico a écrit :
>>
>> On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  wrote:
>
> ...
>>
>> What about:
>>
>> 5 < x < 10
>>
>> Can you add parentheses to that to "make precedence and evaluation order
>> clear"?
>
> Correct me if I'm wrong, but to my knowledge, this is just a shorthand to `5
> < x and x < 10`.

Not quite; the chained form will evaluate 'x' only once. It's broadly
the same, but not identical.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Brice Parent]

Le 24/07/2018 à 00:39, Chris Angelico a écrit :

On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  wrote:

...

What about:

5 < x < 10

Can you add parentheses to that to "make precedence and evaluation order clear"?
Correct me if I'm wrong, but to my knowledge, this is just a shorthand 
to `5 < x and x < 10`.


Making the precedence and evaluation order clear doesn't necessarily 
rely on adding parenthesis, it may rely on expanding the expression (you 
may add parenthesis after that, if you think it's needed).

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[MRAB]

On 2018-07-23 23:05, Giampaolo Rodola' wrote:

On Mon, Jul 23, 2018 at 6:53 PM Steven D'Aprano  wrote:


On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote:
> "a?.b" does two and that's a fundamental difference (explicitness).

How is "two things" less explicit than "one thing"?
Comments like the above is why I think that "explicit" and "implicit"
are used to mean "I like it" and "I don't like it" rather than being
objective arguments, or indeed having anything to do with explicitness
or implicitness.


This:

 v = a?.b

...*implicitly* checks if value is not None [and continues execution].


It's no more implicit than 'or' checking for falseness.


This:

 v = a
 if a.b is not None:
 v = a.b

...*explicitly* checks if value is not None and continues execution.
If for some reason '?'[ is also going to swallow LookupError then
*that* would further decrease explicitness, because LookupError would
be nowhere in sight, the same way "if", "is", "not", "None", ":", "new
line" are nowhere in sight in the 'a?.b' example. Some argued "A ?? B"
is less explicit than "A if A is not None else B" for the same reason.
One may argue that silently returning None instead of raising
AttributeError is also less explicit.
This - and this only - is my argument about explicitness. It doesn't
have to do with how many things are hidden behind an import statement
or what happens on sorted() (that's comparing apples and oranges).
I hope it's clear now.


> It
> does so by introducing a brand new operator ("?") which can be spelled
> in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
> interrupted by any space, which is an absolute first in the Python
> syntax

It isn't a first. Many existing operators use two adjacent symbols not
interrupted by a space:

e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.


You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
would be less intuitive anyway). You can't because '.?' is the only
couple of contiguous symbols requiring "something" before and after
with no spaces in between, and that's a first in the language.


You _can_ say 'a ?. b', just as you _can_ say 'a . b'.

Also, it's not a couple of contiguous symbols, it's a single symbol, 
just as '<=' is a single symbol (and you can't put a space in the middle 
of that either).

[snip]
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Thomas Jollans]

On 24/07/18 00:39, Chris Angelico wrote:
> On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  wrote:
>> On 18/07/18 19:43, Steve Dower wrote:
>>> When a ``None``-aware operator is present, the left-to-right evaluation
>>> may be
>>> short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated::
>>>
>>> _v = a
>>> if _v is not None:
>>> _v = _v.b
>>> _v = _v(c)
>>> _v = _v.d
>>> if _v is not None:
>>> _v = _v[e]
>>> await _v
>>
>> ## NB I only skimmed most of this thread after reading the PEP, so I ##
>> ##apologize if this has been discussed before and I missed it.   ##
>>
>> I quite like the general idea, but I'm nervous about a rather
>> fundamental aspect: This adds a special case in which you can't add
>> parentheses to an expression involving a chain of operators to make
>> precedence and evaluation order clear.
>>
>> To use your example,
>> a ?? 2 ** b ?? 3   ===  (a ?? 2) ** (b ?? 3) # fine
>>
>> In the present day,
>> a or 2 + 3 * c()   ===   a or (2 + (3 * (c(
>>
>> a.b(c).d[e]   ===   (((a.b)(c)).d)[e] # silly, but true.
>>
>> Short-circuiting doesn't break this. With and and or, the expression
>> that's short-circuited away is a self-contained expression in imagined
>> (or actual) parentheses.
> 
> What about:
> 
> 5 < x < 10
> 
> Can you add parentheses to that to "make precedence and evaluation order 
> clear"?


Well, no.

TJ wrote:
> [...] becomes one single, long, atomic expression,
> just like a comparison chain. [...]
  

This does leave the question,

> Is introducing the idea of an "attribute reference, call and
> subscription" chain worth it?



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Tue, Jul 24, 2018 at 8:22 AM, Thomas Jollans  wrote:
> On 18/07/18 19:43, Steve Dower wrote:
>> When a ``None``-aware operator is present, the left-to-right evaluation
>> may be
>> short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated::
>>
>> _v = a
>> if _v is not None:
>> _v = _v.b
>> _v = _v(c)
>> _v = _v.d
>> if _v is not None:
>> _v = _v[e]
>> await _v
>
> ## NB I only skimmed most of this thread after reading the PEP, so I ##
> ##apologize if this has been discussed before and I missed it.   ##
>
> I quite like the general idea, but I'm nervous about a rather
> fundamental aspect: This adds a special case in which you can't add
> parentheses to an expression involving a chain of operators to make
> precedence and evaluation order clear.
>
> To use your example,
> a ?? 2 ** b ?? 3   ===  (a ?? 2) ** (b ?? 3) # fine
>
> In the present day,
> a or 2 + 3 * c()   ===   a or (2 + (3 * (c(
>
> a.b(c).d[e]   ===   (((a.b)(c)).d)[e] # silly, but true.
>
> Short-circuiting doesn't break this. With and and or, the expression
> that's short-circuited away is a self-contained expression in imagined
> (or actual) parentheses.

What about:

5 < x < 10

Can you add parentheses to that to "make precedence and evaluation order clear"?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Thomas Jollans]

On 18/07/18 19:43, Steve Dower wrote:
> When a ``None``-aware operator is present, the left-to-right evaluation
> may be
> short-circuited. For example, ``await a?.b(c).d?[e]`` is evaluated::
> 
>     _v = a
>     if _v is not None:
>     _v = _v.b
>     _v = _v(c)
>     _v = _v.d
>     if _v is not None:
>     _v = _v[e]
>     await _v

## NB I only skimmed most of this thread after reading the PEP, so I ##
##apologize if this has been discussed before and I missed it.   ##

I quite like the general idea, but I'm nervous about a rather
fundamental aspect: This adds a special case in which you can't add
parentheses to an expression involving a chain of operators to make
precedence and evaluation order clear.

To use your example,
a ?? 2 ** b ?? 3   ===  (a ?? 2) ** (b ?? 3) # fine

In the present day,
a or 2 + 3 * c()   ===   a or (2 + (3 * (c(

a.b(c).d[e]   ===   (((a.b)(c)).d)[e] # silly, but true.

Short-circuiting doesn't break this. With and and or, the expression
that's short-circuited away is a self-contained expression in imagined
(or actual) parentheses.

With this ?. operator, the chain a?.b(c).d?[e] can no longer be broken
into sub-expressions, but becomes one single, long, atomic expression,
just like a comparison chain. If I try:

(a?.b)(c).d?[e] # TypeError: 'NoneType' object is not callable
a?.(b(c).d?[e]) # SyntaxError, and illogical

Also, where does this end? if a is None, is (a?.b,c()) equal to None or
(None, c())? Presumably the latter because of operator precedence, but
still.

Is introducing the idea of an "attribute reference, call and
subscription" chain worth it?

This could be fixed by adding a maybe-call ?( operator, which would allow

a?.b?(C())?.d?[E()]
   ===
a?.b)
?( C() ))
 ?.d)
   ?[ E() ])

_v = a
_v = _v.b if _v is not None else None
_v = _v(C()) if _v is not None else None
_v = _v.d if _v is not None else None
_v = _v[E()] if _v is not None else None

with None falling all the way through, and the calls to C() and E()
being short-circuited out.

Of course you need either attribute-call-subscription chains or ‘?()’
maybe-calls for ‘?.’ to be worthwhile at all, since otherwise you can't
write None-aware method calls.

Aside:  other languages cited
  From a quick look at the C# docs linked in the PEP [1], I'm guessing
  that C# allows A?.B?.C?.Do(E), but does not allow A?.B?.C.Do(E). Does
  anybody know? Obviously method calls work differently in C# than in
  Python.

  Dart? I dunno. The docs aren't as thorough.


Am I missing something?


Cheers
Thomas


[1]
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-conditional-operators

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Tue, Jul 24, 2018 at 8:05 AM, Giampaolo Rodola'  wrote:
> The argument about this is that '?.' short-circuits execution
> *silently*. Instead of AttributeError you get None. You may chain ?.
> in order to lazily traverse a long tree, inadvertently assign None to
> a variable, continue code execution and fail later rather than sooner:
>
>  email = request?.context?.user?.email  # None
>  ...
>  sendmail(subject, body, email)
>
> Some (Antoine) rightly argued this may even have security implications
> (replace 'email' with 'password').
>

This thread has been long and rambling. Can you elaborate on the
security implications? Normally, I would expect that a password of
None would always fail to validate.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Mon, Jul 23, 2018 at 6:53 PM Steven D'Aprano  wrote:
>
> On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote:
> > "a?.b" does two and that's a fundamental difference (explicitness).
>
> How is "two things" less explicit than "one thing"?
> Comments like the above is why I think that "explicit" and "implicit"
> are used to mean "I like it" and "I don't like it" rather than being
> objective arguments, or indeed having anything to do with explicitness
> or implicitness.

This:

v = a?.b

...*implicitly* checks if value is not None [and continues execution]. This:

v = a
if a.b is not None:
v = a.b

...*explicitly* checks if value is not None and continues execution.
If for some reason '?'[ is also going to swallow LookupError then
*that* would further decrease explicitness, because LookupError would
be nowhere in sight, the same way "if", "is", "not", "None", ":", "new
line" are nowhere in sight in the 'a?.b' example. Some argued "A ?? B"
is less explicit than "A if A is not None else B" for the same reason.
One may argue that silently returning None instead of raising
AttributeError is also less explicit.
This - and this only - is my argument about explicitness. It doesn't
have to do with how many things are hidden behind an import statement
or what happens on sorted() (that's comparing apples and oranges).
I hope it's clear now.

> > It
> > does so by introducing a brand new operator ("?") which can be spelled
> > in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
> > interrupted by any space, which is an absolute first in the Python
> > syntax
>
> It isn't a first. Many existing operators use two adjacent symbols not
> interrupted by a space:
>
> e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.

You say 'a == b'. You can't say 'a ?. b' (not that it matters, it
would be less intuitive anyway). You can't because '.?' is the only
couple of contiguous symbols requiring "something" before and after
with no spaces in between, and that's a first in the language. The
argument about this is that it's ugly and less readable. My additional
argument at the beginning of this thread was that if you add PEP-572
to the mix you dangerously enter into Perl territory:

foo(x=(x := a?.b?[c] ?? d))

> > and that's the second and fundamental difference. I cannot move
> > the same criticism to the "a.b" form: it's simpler, it does one thing
> > and it uses one symbol.
>
> You criticised ?. because it can interupt left-to-right execution:
>
> a?.b?.c?.d
>
> True. But so can a single dot:
>
> a.b.c.d
>
> is no more guaranteed to execute all the way to the right.

The difference is that 'a.b.c.d' will result in AttributeError as soon
as something is None while 'a?.b?.c?.d' will return None instead.

> Likewise the logical operators "or" and "and" are designed to
> short-circuit. If ?? and friends are a mistake because they
> short-circuit, why aren't "or" and "and" mistakes?
> I'm not asking this as a rhetorical question. If you think there is a
> reason why it is okay for or/and to short-circuit, but it is bad for ??
> and friends to short-circuit, then please explain why they are
> different. I will be very happy to listen to your arguments.

The argument about this is that '?.' short-circuits execution
*silently*. Instead of AttributeError you get None. You may chain ?.
in order to lazily traverse a long tree, inadvertently assign None to
a variable, continue code execution and fail later rather than sooner:

 email = request?.context?.user?.email  # None
 ...
 sendmail(subject, body, email)

Some (Antoine) rightly argued this may even have security implications
(replace 'email' with 'password').

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Sun, Jul 22, 2018 at 11:54:19AM +1000, Steven D'Aprano wrote:

> In my opinion, writing
> 
> expression if expression is None else default
> 
> is the *opposite* of Pythonic, it is verbose and the DRY violation is 
> inelegant (as well as inefficient). I'd much rather use:
> 
> expression ?? default
> 
> although with PEP 572 approved, there is an alternative:
> 
> temp := expression if temp is None else default


I was mistaken. That would need to be written as:

temp if (temp := expression) is None else default

which is obscure enough for me to prefer the ?? syntax again.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[MRAB]

On 2018-07-23 13:04, Giampaolo Rodola' wrote:

On Mon, Jul 23, 2018 at 3:12 AM Steven D'Aprano  wrote:

> ? has no spaces, it's literally "variable names interrupted by
> question marks" and evaluation can stop at any time while scanning the
> line from left to right.

Just like ordinary attribute access.

This is the point I was making earlier: you accept existing punctuation
doing these things:

try:
obj.spam.egsg.tomato.cheese  # oops a typo
except AttributeError:
# evaluation can stop at any time
...

while demanding a higher standard for new punctuation.

All of your criticisms of ? punctuation applies to . as well.


I don't think they do. For once, "a.b" does one and one thing only,
"a?.b" does two and that's a fundamental difference (explicitness). It
does so by introducing a brand new operator ("?") which can be spelled
in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
interrupted by any space, which is an absolute first in the Python
syntax and that's the second and fundamental difference. I cannot move
the same criticism to the "a.b" form: it's simpler, it does one thing
and it uses one symbol.


[snip]
I think you're misunderstanding something: we're not talking about a 
special operator "?" that somehow combines with existing operators, 
we're talking about completely new and separate operators "?.", "?[", 
etc., which resemble the existing ".", "[", etc.

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Mon, Jul 23, 2018 at 02:04:17PM +0200, Giampaolo Rodola' wrote:

[I wrote this]
> > This is the point I was making earlier: you accept existing punctuation
> > doing these things:
> >
> > try:
> > obj.spam.egsg.tomato.cheese  # oops a typo
> > except AttributeError:
> > # evaluation can stop at any time
> > ...
> >
> > while demanding a higher standard for new punctuation.
> >
> > All of your criticisms of ? punctuation applies to . as well.

[Giampaolo] 
> I don't think they do. For once, "a.b" does one and one thing only,

Attribute lookup is a bit more complex than just "one thing only", but 
okay, I'll accept that for a sufficiently complex "thing", dot access 
does one thing.


> "a?.b" does two and that's a fundamental difference (explicitness).

How is "two things" less explicit than "one thing"?

Comments like the above is why I think that "explicit" and "implicit" 
are used to mean "I like it" and "I don't like it" rather than being 
objective arguments, or indeed having anything to do with explicitness 
or implicitness.

If this PEP is approved, then *by definition* the ?? operator will mean 

return the first operand if it isn't None
otherwise evaluate and return the second

making it just as explicit as:

   +  # add or concatenate the two operands

   ==  # return True if the two operands are equal otherwise False

   sorted(x)  # make a list copy of x and sort it

etc. Just because the spelling is short doesn't make it implicit.


> It
> does so by introducing a brand new operator ("?") which can be spelled
> in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
> interrupted by any space, which is an absolute first in the Python
> syntax 

It isn't a first. Many existing operators use two adjacent symbols not 
interrupted by a space:

e.g.  ==  <=  >=  !=  **  //  << >> +=  -=  *= etc.



> and that's the second and fundamental difference. I cannot move
> the same criticism to the "a.b" form: it's simpler, it does one thing
> and it uses one symbol.

You criticised ?. because it can interupt left-to-right execution:

a?.b?.c?.d

True. But so can a single dot:

a.b.c.d

is no more guaranteed to execute all the way to the right.

Likewise the logical operators "or" and "and" are designed to 
short-circuit. If ?? and friends are a mistake because they 
short-circuit, why aren't "or" and "and" mistakes?

I'm not asking this as a rhetorical question. If you think there is a 
reason why it is okay for or/and to short-circuit, but it is bad for ?? 
and friends to short-circuit, then please explain why they are 
different. I will be very happy to listen to your arguments.


> > > Multiple "?" can live on the same line so
> > > that's incentive to write one-liners, really, and to me one-liners are
> > > always less explicit than the same logic split on multiple lines.
> >
> > Explicit is not always better.
> >
> > import this
> >
> > is much better than:
> >
> > for location in sys.path:
> > try:
> > for file in os.listdir(location):
> > if os.splitext(file) in ('.pyc', '.py', '.so'):
> > ...
> 
> I honestly don't see how this example is related with anything discussed so 
> far.

You keep saying that the proposed ?? etc operators aren't explicit and 
you criticise them for doing "two things". The import statement does 
at least ten things:

- searches the cache of modules;
- if not found, traverse the search path looking for not one kind of
  file, but multiple kinds of files that the user has no control over;
- if a matching file is found, check for a pre-compiled version;
- or compile it;
- save the compiled byte-code in a new file;
- load the compiled byte-code into a module object;
- execute that code;
- add the module object to the cache;
- create a new name in the local namespace;
- bind the module object to the name.

If doing "two things" is bad, then doing "ten things" is five times 
worse. If ?? is too implicit, then what is importing? Why is it okay for 
importing to be "implicit" but ?? needs to be written out over two 
lines?

If behaviour that is acceptable, even desirable in existing features is 
harmful in these new ? operators, then please tell us how and why.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Mikhail V]

I personally do almost only classical programming, and I am somewhat
opposed to OOP in general. So here my somewhat outlandish view,
(and I am biased becase I will probably never need this feature).

First thoughts after reading the PEP: what is so super-special and fundamental
about None value?
Is it more special and required to treat more often than "true" or
"false" values in
similar manner?
Is there statistics for occurence of code checking 'None' versus 'not None'?

So:

if x is None:
   x = 10

converts to:

x ??= 10

But what if one need to do something else than just return a value?
E.g. I want to insert `print(x)` in the first example?
Or check against other value than 'None'?
Supposed to write it so then rewrite it so, then if I need it other way -
again rewrite it so.

So from the PEP I understand only two things:
1) de-facto None became special in some contexts.
2) one may need to short-circuit an expression if None pops up.

So it is syntax good only for special kind of applications I suppose.
It seems motivating examples come mainly from situations where
one has a Python script serving some database framework or something alike.
So it smells like specialized usage and design-specific pattern.
It looks (from a passer-by POV) like the proposed syntax tries to
treat some sticking out
parts of something that may not be necessarily present in an application at all.
Of course that maybe argued easily because many concepts that
does not directly belong to programming are sometimes appearing in form of
dedicated syntax. Though such cases not so common in Python.

I don't know whether the feature adressed by '?.' is often in those contexts,
but first thing that comes to mind - it regards only experts and NOT
intended for reading the code that I am not familiar with.

E.g. this "improved" code in examples:

def find_module(self, fullname, path):
return getattr(self, 'find_spec', None)?.__call__(fullname, path)?.loader

I could not decipher this and I have tried for a while.

I could probably understand the motivation better if it were some
more or less fundamental or general pattern, but is it? IDK


-

More important that the syntax part is really worrying.
Does everybody realize that there are only 2 or 3 ASCII characters left free?
IIRC those are question mark "?", exclamation mark "!" and dollar sign "$".

Imagine that in some time someone comes up with a good general syntax feature
that would require new symbol - and there is nothing left. That's not
funny actually.
This makes decisions about symbols into agony and heats up discussions
to extreme
because some PEP authors maybe hoping for a better-looking symbol for
their 'child' while other proposals and possible future proposals may
be more important.

At this time point I think one should first consider exploring the
possibility to
add non-ASCII characters to syntax. I think it is resonable because Unicode
became standard.
It should at least help to relax the atmosphere around syntax proposals.

'Niche' features IMO should be better added as functions, or, if non-ASCII
symbols could be added, as some '2nd class' symbols (i.e. not so nice looking).
And nicely looking symbols should be reserved for future proposals for
general syntax features which are potentially useful for wider user groups.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 23Jul2018 1530, David Mertz wrote:
Of course I don't mean that if implemented the semantics 
would be ambiguous... rather, the proper "swallowing" of different kinds 
of exceptions is not intuitively obvious, not even to you, Steve.  And 
if some decision was reached and documented, it would remain unclear to 
new (or even experienced) users of the feature.


As written in the PEP, no exceptions are ever swallowed. The translation 
into existing syntax is very clearly and unambiguously shown, and there 
is no exception handling at all. All the exception handling discussion 
in the PEP is under the heading of "rejected ideas".


This email discussion includes some hypotheticals, since that's the 
point - I want thoughts and counter-proposals for semantics and 
discussion. I am 100% committed to an unambiguous PEP, and I believe the 
current proposal is most defensible. However, I don't want to have a 
"discussion" where I simply assume that I'm right, everyone else is 
wrong, and I refuse to discuss or consider alternatives.


So sorry for letting you all think that everything I write is actually 
the PEP. I had assumed that because my emails are not the PEP that 
people would realise that they are not the PEP. I'm going to duck out of 
the discussions here now, since they are not as productive as I'd hoped, 
and once we have a BDFL-replacement I'll reawaken it and see what is 
required at that point.


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[C Anthony Risinger]

On Mon, Jul 23, 2018 at 7:46 AM, Grégory Lielens 
wrote:

>  Paul Moore wrote:
>>
>> This is my impression, as well. It seems like something that's helpful
>> in dealing with unstructured object hierarchies with lots of optional
>> attributes - which is where JSON tends to be used.
>>
>> But given that, I'm really much more interested in seeing the new
>> operators compared against a well-written "JSON object hierarchy
>> traversal" library than against raw Python code.
>>
>
> Good point, I did not think about that when suggesting to give some
> context, but indeed if it's linked to a library in particular, there is
> always the possibility to choose another object than None as the "nothing
> here" marker.
>
>From what I gather, disallowing reassignment all but cements None as the
"nothing here" marker (the originally intent?), _especially_ when "nothing
here" is candidate for replacement by a more appropriate, type- or domain-
or context-specific "nothing here" marker. Imbuing None with any other
meaning brings nothing but headache. It's an attractive nuisance. None is
None is None, there can be only one! You don't know what it is, only that
it's not anything else. What possible meaning can such an object usefully
have in an application built on disparate libraries with their own ideas on
the matter?

Every API I've used (apologies for coming up blank on a concrete example!)
granting None meaning is awkward to consume. `.get()` interfaces are less
useful (must carry your own internal sentinels) or more try/except blocks
are required to achieve the same end (not a bad thing per se, but
a diminished experience to be sure). Early APIs I wrote in this "well it's
None, but but but, with this convenient meaning, see?! SEE??"-style were
later regarded -- quite thoroughly -- as a bad idea by myself, my peers,
and downstream consumers.

I'd personally use these new operators both frequently and judiciously.
They align very well with a "set 'em up and knock 'em down"-style I use:
normalized, progressively conditioned input values fast-followed by
aggressive short-circuits and clear early returns. IME this pattern
generates clean, readable, and performant code. Honestly the
short-circuiting capability alone is enough to sell me :-) This PEP would
find legitimate use by me every day. I'm not 100% sold on `?[` (then again,
attributes are pulled from an object namespace via `?.` and namespaces are
containers by definition) but `?.` and `??` deliver immense value.

Not sure if useful, but this discussion reminds me of a pattern prevalent
in the Elixir community. They use `?` and `!` in function definitions to
denote variants differing only on return behavior (not function clauses!
This is by convention only, they're entirely new functions with a symbol in
their name). It looks something like this:

# Default function.
# Return a tuple {interesting-or-nil, error-or-nil}.
def open(path) do ... end

# Maybe variant.
# Return a boolean, or less often, interesting-or-nil (replaces `is_` or
`can_` methods in Python).
def open?(path) do ... end

# Forceful variant.
# Return interesting or die trying (inverse of `.get()` methods in Python;
raising is not the default expectation in Elixir).
def open!(path) do ... end

The `?.`-operator reminds me of this. It offers to perform an extremely
common operation (simple attribute access) while short-circuiting on the
most frequently triggered guard condition (AttributeError).

I don't think the utility here is restricted to deeply nested JSON
`loads()` or one-off scripts. It better aligns the community on semantics,
encouraging more idiomatic -- and uniform! -- interactions with None.

-- 

C Anthony
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Mon, Jul 23, 2018 at 12:09:00PM +0100, Steve Dower wrote:
> On 23Jul2018 1145, Antoine Pitrou wrote:
> >
> >Le 23/07/2018 à 12:38, Steve Dower a écrit :
> >>
> >>General comment to everyone (not just Antoine): these arguments have
> >>zero value to me. Feel free to keep making them, but I am uninterested.
> >
> >So you're uninterested in learning from past mistakes?
> >
> >You sound like a child who thinks their demands should be satisfied
> >because they are the center of the world.
> 
> Sorry if it came across like that, it wasn't the intention. 

Steve, I don't think you should apologise to somebody who has just 
quoted you out of context and insulted you for no good reason.

In context, your comment about "these arguments" was a perfectly 
reasonable thing to say. You didn't say you were uninterested in *all* 
arguments, only certain kinds of low-value arguments that keep getting 
made over and over again. Antoine snipped the context, unfairly accused 
you on zero evidence of being "uninterested in learning from past 
mistakes", and described you as a self-centred child.

I think Antoine should be apologising to you, not the other way around.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Mon, Jul 23, 2018 at 11:52 AM Steve Dower  wrote:

> I'm borderline on ?[] right now. Honestly, I think it works best if it
> also silently handles LookupError (e.g. for traversing a loaded JSON
> dict), but then it's inconsistent with ?. which I think works best if it
> handles None but allows AttributeError.

That would easily make typos pass unnoticed:

request.context.user.usernme  # raises AttributeError
request?.context?.user?.usernme  # return None

Same goes for LookupError: if a key or index is missing on 'a?[b]' I
do want an exception. If I don't, which should be the exception rather
than the rule, I will simply take the risk myself and do:

default = ''
try:
name = d['user']['details']['name'] or default
except KeyError:
name = default

But certainly there should be no native syntax encouraging me to do
any of that. Talking about arbitrarily swallowing exceptions is the
worst direction this proposal can take as it breaks yet another
fundamental Python Zen: "errors should never pass silently". IMO this
shows how fundamentally detached from the base philosophy of the
language this whole idea is.

--
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

On Mon, Jul 23, 2018 at 5:52 AM Steve Dower  wrote:

> The PEP author is unsure about how it works
> ---
> I wish this statement had come with some context, because the only thing
> I'm unsure about is what I'm supposed to be unsure about.
>

In general—as I haven't been shy of saying—I find the entire idea awful.  I
recognize you have done sincere and high quality work in arguing for it; it
just feels like a very wrong direction for Python.

But bracketing that, I'm probably the person you have in mind in that
comment.  And it's funny that you write you are unsure what you are
supposed to be unsure about, but the very next section is exactly what I
had in mind.  Of course I don't mean that if implemented the semantics
would be ambiguous... rather, the proper "swallowing" of different kinds of
exceptions is not intuitively obvious, not even to you, Steve.  And if some
decision was reached and documented, it would remain unclear to new (or
even experienced) users of the feature.

I'm borderline on ?[] right now. Honestly, I think it works best if it
> also silently handles LookupError (e.g. for traversing a loaded JSON
> dict), but then it's inconsistent with ?. which I think works best if it
> handles None but allows AttributeError.
>

Moreover, at a couple points in your clarification, you say "ignoring
descriptors." But ultimately, the language cannot do that.  When a
programmer writes `obj?.descriptor?.other_descriptor` SOMETHING has to
happen (no matter what actually happens within the code of the property).

This can certainly be specified in some unambiguous way, but I believe that
any decision made will be strongly counter-intuitive for certain concrete
code.

-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Andre Roberge]

On Mon, Jul 23, 2018 at 6:52 AM Steve Dower  wrote:

> Responding to a few more ideas that have come up here.
>


​Thank you for the clarifications.​

​I'm trying to wrap my head around the various facets of None aware
operators proposal after reading the whole discussion - as well as having
read the PEP a few times.  Below is a
summary of what I gathered from the discussion, with a few added other
points that I have not seen addressed.

1. It is an operator present in other languages (e.g. C#, Dart), that uses
the same notation

a) This demonstrates that such an operator has been found to be useful and
is
definitely worth considering.

b) The fact that it uses the same notation is a plus for people that know
these other languages but it does not mean that the notation is necessarily
the best choice for Python. To wit, Python does not use the combination of
? and
: for ternary operator; instead it reuses existing keywords.

c) Some people use languages (e.g. Ruby) that allow ? to be part of an
identifier,
which means that one could, in principle, write something like

a = b?.c

in Ruby with a completely different meaning than what it would mean in C#
or Dart,
or as proposed for Python.Thus, I don't think that that language X uses
this operator written this way is,
**on its own**, a valid justification for using the exact same syntax for
Python.

d) Dart is given as an example. Reading from the link mentioned in the PEP,
I was lead to https://www.dartlang.org/guides/language/language-tour#classes
where the only mention of ?. was the following:

===
// If p is non-null, set its y value to 4.
p?.y = 4;
===

However, PEP 505 mentions that something like the above would raise a
SyntaxError.
Given that Dart's operator has a different semantics than that proposed for
Python,
I do not think that mentioning Dart in this context without any qualifier
is a valid supportive justification for this proposal.

2. On the specific choices of ??, ??=, ?., ?[]

a) Trying to find what Csharp ?? means by doing a quick internet search is
not exactly
productive.  By comparison, if one were to use a new keyword (say ifnone
instead
of ??) or keywords, it would make it easier to find their meaning. The
problem with new
keywords is that they may introduce some backwards incompatibility.

b) Admitedly, there are very few remaining symbols in Python that can be
used for defining new operators. Introducing operators using ? does not
cause problems with existing code.

c) While using a new keyword for ?? and ??= might work, it is less clear,
at least to me, how this could extend to ?. and ?[]

d) ? and ?? are already used by IPython with a totally different meaning.
I almost never use IPython I have no idea what problems this might cause
for IPython users.

3. On some examples given

PEP 505 gives these examples from Request:

data = [] if data is None else data
files = [] if files is None else files
headers = {} if headers is None else headers
params = {} if params is None else params
hooks = {} if hooks is None else hooks

It then argues that this is undesirable and that it could have been written
instead
as

data = data if data is not None else []
files = files if files is not None else []
headers = headers if headers is not None else {}
params = params if params is not None else {}
hooks = hooks if hooks is not None else {}

which, as written in PEP 505, is deemed to be "more intuitive" - but longer.

Having looked at the code in the Request module, I would argue that it
could have been written instead as

if data is None: data = []
if files is None: files = []
if headers is None: headers = {}
if params is None: params = {}
if hooks is None: hooks = {}

which gives the same result and is shorter than the original - but
admittedly longer than
the proposed notation. I do not think that this specific example as
currently written
in PEP 505 gives a fair picture of what is currently possible with Python.

4) On comparisons with other "domain specific operators", like @ and
the bitwise operators.

I do not remember the exact words that were used in the discussions, but
I seem to recall people saying that operators like ??, ?., etc. are no
more "mysterious" than @ or the bitwise operators might be: users should
not be surprised to have to learn new operators.

Anyone that does numerical work knows that matrix multiplications do not
obey the same rules as multiplications of numbers. If you don't do numerical
work, you are almost certain not to encounter @ as an operator (but only
as a symbol for decorator), so there won't be any mystery to solve.
A similar situation exists for bitwise operators.
Having dedicated operators to represent special methods on these types of
objects makes the code easier to read for people working in these fields.
I also note that these operators have corresponding dunder methods.

By contrast, code like

if a is None:
   a = []

can occur in pretty much any type of program and is, arguably, already very

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Mon, Jul 23, 2018 at 10:48:23AM +0100, Steve Dower wrote:
> On 23Jul2018 0151, Steven D'Aprano wrote:
> >What if there was a language
> >supported, non-hackish way to officially delay evaluation of
> >expressions until explicitly requested?
> 
> The current spelling for this is "lambda: delayed-expression" and the 
> way to request the value is "()". :)
> 
> (I'm not even being that facetious here. People ask for delayed 
> expressions all the time, and it's only 7 characters, provided the 
> callee knows they're getting it, and the semantics are already well 
> defined and likely match what you want.)

I know you not being facetious, and delaying computation through a 
function call is not an awful solution. But its not a great solution 
either. Contrast the elegance of syntax with delayed evaluation:

1/x if x != 0 else func(y)

versus the lambda solution:

if_else(lambda: 1/x, x != 0, lambda: func(y))()


For clarity, or perhaps the opposite *wink* I've kept the same order of 
arguments. It's not just the extra seven characters (plus spaces) per 
delayed expression, or the extra parentheses at the end to force 
evaluation, but the ease at which we can forget and write this:

if_else(1/x, x != 0, func(y))


Anyway, it was just an idle thought, not in a state to compete with this 
PEP. And even if it were, I'd still prefer to see at least ?? as a 
dedicated operator rather than a function.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Nicholas Cole]

On Mon, Jul 23, 2018 at 2:37 PM Mark E. Haase  wrote:

>> What does a scan through the existing core library say?
>
>
> Please read the PEP before you shoot it down. It answers this _exact_ 
> question.

My apologies.  I'd missed the line where it says the examples were
taken from the core library. So then a couple of points. Given the
size of the core library, 678 seems like a very low number to me for a
proposal like this -- but then I don't know quite what the threshold
number would be for something like this.  I guess I had expected that
if None really were used in this way that there would be thousands of
places where it might be used in the core libraries.   Secondly (and I
mean this with no animus at all), in some of the examples given I
really struggle to see that the new version is more readable /
maintainable / obvious than the old version.  I can see the point in a
couple of others.  You'll say this is subjective as a test, and it is,
I suppose.

N.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Mark E. Haase]

On Mon, Jul 23, 2018 at 2:23 AM Nicholas Cole 
wrote:

> One issue for me is that the trivial case is already a one-liner:
>
> if a is None: a = 10
>

Yes, if you have no indentation and a 1-character name, then it fits on a
single line. If you have a longer expression and/or side effects, then it's
not a one-liner anymore.


> And that leads to a simple question: how many times does this actually
> occur in real-world by python code? -- i.e. how many times do I want
> to check the value of an existing label, and, finding it is None (and
> None specifically), then assign it a value?
>
> What does a scan through the existing core library say?


Please read the PEP before you shoot it down. It answers this _exact_
question.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

 Paul Moore wrote:
>
> This is my impression, as well. It seems like something that's helpful
> in dealing with unstructured object hierarchies with lots of optional
> attributes - which is where JSON tends to be used.
>
> But given that, I'm really much more interested in seeing the new
> operators compared against a well-written "JSON object hierarchy
> traversal" library than against raw Python code.
>

Good point, I did not think about that when suggesting to give some 
context, but indeed if it's linked to a library in particular, there is 
always the possibility to choose another object than None as the "nothing 
here" marker. 

One that will absorb getitems and  getattr accesses so that ?.  and ?[] 
behavior is reproduced by plain . and []. Guard/NoValues should be chosen 
so that typical lib use is easier. 


Anyway, addressing partially-populated nodes would need lib support: 
None-coalescence will not help when you traverse a dict/attribute hierarchy 
where some nodes implement some attributes/keys but not others. It help 
only when a node is either regular, or a guard object without any 
attributes...So an irregular tree, but not too irregular ;-)... 


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Mon, Jul 23, 2018 at 3:12 AM Steven D'Aprano  wrote:
> > ? has no spaces, it's literally "variable names interrupted by
> > question marks" and evaluation can stop at any time while scanning the
> > line from left to right.
>
> Just like ordinary attribute access.
>
> This is the point I was making earlier: you accept existing punctuation
> doing these things:
>
> try:
> obj.spam.egsg.tomato.cheese  # oops a typo
> except AttributeError:
> # evaluation can stop at any time
> ...
>
> while demanding a higher standard for new punctuation.
>
> All of your criticisms of ? punctuation applies to . as well.

I don't think they do. For once, "a.b" does one and one thing only,
"a?.b" does two and that's a fundamental difference (explicitness). It
does so by introducing a brand new operator ("?") which can be spelled
in two forms ("a?.b" and "a?[b]") by using two adjacent symbols not
interrupted by any space, which is an absolute first in the Python
syntax and that's the second and fundamental difference. I cannot move
the same criticism to the "a.b" form: it's simpler, it does one thing
and it uses one symbol.

Your argument is basically a revisitation of "it's just another
symbol" and "it's like a + b" which you have being pulling different
times in this thread already. You want to imply that since symbols are
already used in the grammar (and "." in particular) then it's
perfectly fine to also have "?" and its spell variants (which are 4 in
total). I don't think that's how changes of such importance should be
discussed.

> > Multiple "?" can live on the same line so
> > that's incentive to write one-liners, really, and to me one-liners are
> > always less explicit than the same logic split on multiple lines.
>
> Explicit is not always better.
>
> import this
>
> is much better than:
>
> for location in sys.path:
> try:
> for file in os.listdir(location):
> if os.splitext(file) in ('.pyc', '.py', '.so'):
> ...

I honestly don't see how this example is related with anything discussed so far.

> If punctuation is unreadable and Perlish, so is "." and ":" punctuation.
> If ?? is bad because it is "implicit", then so is import or sorted.

I'm not even sure how to reply to this.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Paul Moore]

On 23 July 2018 at 12:39, Grégory Lielens  wrote:
> Maybe it would help if you mention in which context you will benefit the
> most? If the python sub-community related to this context agree "?? and
> friends" is a good idea, then it will add weight to the proposal. Else,
> probably better to forget it.
>
> It seems related to JSON, but as I have never used it, it's a wild guess.

This is my impression, as well. It seems like something that's helpful
in dealing with unstructured object hierarchies with lots of optional
attributes - which is where JSON tends to be used.

But given that, I'm really much more interested in seeing the new
operators compared against a well-written "JSON object hierarchy
traversal" library than against raw Python code. I'll happily agree
that traversing JSON-style data in current Python is pretty
unpleasant. But I don't honestly think that anyone has explored how
far a well-written library can go in making it easy to handle such
data (well, I certainly haven't, and I haven't found any particularly
good examples on PyPI). And until that's been tried, I think it's
premature to propose a syntax change (if it *has* been tried, adding
references to the PEP would be useful).

Again, this is more about ?. and ?[. I can see general uses for ??
(and its augmented assignment form ??=), but the None-aware attribute
and item access operators seem to me to be the most domain-specific
aspects of the PEP (as well as being the ugliest IMO ;-)). So
comparing against domain-specific libraries rather than against "write
your own" raw Python code seems reasonable to me.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

Maybe it would help if you mention in which context you will benefit the 
most? If the python sub-community related to this context agree "?? and 
friends" is a good idea, then it will add weight to the proposal. Else, 
probably better to forget it.

It seems related to JSON, but as I have never used it, it's a wild guess.

Anyway, it's a special pattern with deep attribute hierarchies, whose 
traversal is shortcutted when one attribute happen to be None.
This is common, with 2 exception:
 -it's rare it's really deep, or then it is arbitrarily deep and you need a 
procedural descent, not a fixed expression.
 -None break the descend, but then so does missing attributes.
You address the first with special syntax. not the second, so I suspect in 
your case the second does not happen. Or rarely happen.

Hope this will help finding why some finds the ? operators add little, 
while some others think they add enough to overcome python traditional 
operator-averse nature.


On Monday, July 23, 2018 at 1:10:03 PM UTC+2, Steve Dower wrote:
>
> On 23Jul2018 1145, Antoine Pitrou wrote:
> > 
> > Le 23/07/2018 à 12:38, Steve Dower a écrit :
> >>
> >> General comment to everyone (not just Antoine): these arguments have
> >> zero value to me. Feel free to keep making them, but I am uninterested.
> > 
> > So you're uninterested in learning from past mistakes?
> > 
> > You sound like a child who thinks their demands should be satisfied
> > because they are the center of the world.
>
> Sorry if it came across like that, it wasn't the intention. A bit of 
> context on why you think it's a mistake would have helped, but if it's a 
> purely subjective "I don't like the look of it" (as most similar 
> arguments have turned out) then it doesn't add anything to enhancing the 
> PEP. As a result, I do not see any reason to engage with this class of 
> argument.
>
> I hope you'll also notice that I've been making very few demands in this 
> thread, and have indicated a number of times that I'm very open to 
> adjusting the proposal in the face of honest and useful feedback.
>
> Cheers,
> Steve
> ___
> Python-ideas mailing list
> python...@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/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

Le 23/07/2018 à 13:09, Steve Dower a écrit :
> On 23Jul2018 1145, Antoine Pitrou wrote:
>>
>> Le 23/07/2018 à 12:38, Steve Dower a écrit :
>>>
>>> General comment to everyone (not just Antoine): these arguments have
>>> zero value to me. Feel free to keep making them, but I am uninterested.
>>
>> So you're uninterested in learning from past mistakes?
>>
>> You sound like a child who thinks their demands should be satisfied
>> because they are the center of the world.
> 
> Sorry if it came across like that, it wasn't the intention.

Thanks for your apologies, and I apology for being a bit abrasive too.

Regards

Antoine.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Nicholas Cole]

On Mon, Jul 23, 2018 at 8:08 AM Grégory Lielens
 wrote:
>
>
>
> On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote:
>
>> And that leads to a simple question: how many times does this actually
>> occur in real-world by python code? -- i.e. how many times do I want
>> to check the value of an existing label, and, finding it is None (and
>> None specifically), then assign it a value?
>
>
> The PEP present a few examples.
>
> I think the compactness and clarity is really gained when doing a descent 
> into an "attribute tree", where any (or selected) members can be None, like 
> getting back to the  example by Steven (spell-corrected, and expanded):
>
>  meal = obj?.spam?.eggs.tomato?.cheese ?? "Mozzarella"
>
> Where, to put the proposal in even better light, I have assumed that eggs 
> instances always have a tomato attributes (i.e. are never None).
>
> This is indeed much more compact that the current version, and arguably more 
> readable (it's easier to parse once you know the syntax...but you have to 
> know the special syntax that will be used for this kind of stuff only). The 
> more you deepen the attribute access, the more you gain, but of course deep 
> attribute access is not so common. The new operators may make deep attribute 
> hierarchies (or deeply nested dicts/lists) slightly more common, and there 
> also I do not think it's a good thing.
>

That above example looks terrible to read (to me).  Yes, that's a
subjective statement.  This example from the PEP is even worse:

Example:

if entry.is_dir():
dirs.append(name)
if entries is not None:
entries.append(entry)
else:
nondirs.append(name)

After updating to use the ?. operator:

if entry.is_dir():
dirs.append(name)
entries?.append(entry)
else:
nondirs.append(name)


In the first, it's totally clear to me when entries would be appended
to and when it wouldn't.  The second I had to read several times
before I could see what was going on.  The fact that it is already
embedded in an if...else statement perhaps made it harder to
understand.

I guess people will say that we will just get used to the new syntax,
but I don't see the benefit of making that particular "if" statement
more compact, and leaving all the others in place.  Or to put it
another way, I'm just not convinced that "None" is sufficiently
special.

N.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 23Jul2018 1145, Antoine Pitrou wrote:


Le 23/07/2018 à 12:38, Steve Dower a écrit :


General comment to everyone (not just Antoine): these arguments have
zero value to me. Feel free to keep making them, but I am uninterested.


So you're uninterested in learning from past mistakes?

You sound like a child who thinks their demands should be satisfied
because they are the center of the world.


Sorry if it came across like that, it wasn't the intention. A bit of 
context on why you think it's a mistake would have helped, but if it's a 
purely subjective "I don't like the look of it" (as most similar 
arguments have turned out) then it doesn't add anything to enhancing the 
PEP. As a result, I do not see any reason to engage with this class of 
argument.


I hope you'll also notice that I've been making very few demands in this 
thread, and have indicated a number of times that I'm very open to 
adjusting the proposal in the face of honest and useful feedback.


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

Le 23/07/2018 à 12:38, Steve Dower a écrit :
> 
> General comment to everyone (not just Antoine): these arguments have 
> zero value to me. Feel free to keep making them, but I am uninterested. 

So you're uninterested in learning from past mistakes?

You sound like a child who thinks their demands should be satisfied
because they are the center of the world.

Regards

Antoine.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 23Jul2018 1129, Antoine Pitrou wrote:


Le 23/07/2018 à 12:25, Steve Dower a écrit :

On 23Jul2018 , Antoine Pitrou wrote:

On Mon, 23 Jul 2018 10:51:31 +0100
Steve Dower  wrote:


Which is the most important operator?
-

Personally, I think '?.' is the most valuable.


For me, it's the most contentious.  The fact that a single '?' added to
a regular line of Python code can short-circuit execution silently is a
net detriment to readability, IMHO.


The only time it would short-circuit is when it would otherwise raise
AttributeError for trying to access an attribute from None, which is
also going to short-circuit.


But AttributeError is going to bubble up as soon as it's raised, unless
it's explicitly handled by an except block.  Simply returning None may
have silent undesired effects (perhaps even security flaws).


You're right that the silent/undesired effects would be bad, which is 
why I'm not proposing silent changes to existing code (such as 
None.__getattr__ always returning None).


This is a substitute for explicitly checking None before the attribute 
access, or explicitly handling AttributeError for this case (and 
unintentionally handling others as well). And "?." may be very small 
compared to the extra 3+ lines required to do exactly the same thing, 
but it is still an explicit change that can be reviewed and evaluated as 
"is None a valid but not-useful value here? or is it an indication of 
another error and should we fail immediately instead".


Cheers,
Steve


This whole thing reminds of PHP's malicious "@" operator.


General comment to everyone (not just Antoine): these arguments have 
zero value to me. Feel free to keep making them, but I am uninterested. 
Perhaps whoever gets to decide on the PEP will be swayed by them?

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

Le 23/07/2018 à 12:25, Steve Dower a écrit :
> On 23Jul2018 , Antoine Pitrou wrote:
>> On Mon, 23 Jul 2018 10:51:31 +0100
>> Steve Dower  wrote:
>>>
>>> Which is the most important operator?
>>> -
>>>
>>> Personally, I think '?.' is the most valuable.
>>
>> For me, it's the most contentious.  The fact that a single '?' added to
>> a regular line of Python code can short-circuit execution silently is a
>> net detriment to readability, IMHO.
> 
> The only time it would short-circuit is when it would otherwise raise 
> AttributeError for trying to access an attribute from None, which is 
> also going to short-circuit.

But AttributeError is going to bubble up as soon as it's raised, unless
it's explicitly handled by an except block.  Simply returning None may
have silent undesired effects (perhaps even security flaws).

This whole thing reminds of PHP's malicious "@" operator.

Regards

Antoine.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 23Jul2018 , Antoine Pitrou wrote:

On Mon, 23 Jul 2018 10:51:31 +0100
Steve Dower  wrote:


Which is the most important operator?
-

Personally, I think '?.' is the most valuable.


For me, it's the most contentious.  The fact that a single '?' added to
a regular line of Python code can short-circuit execution silently is a
net detriment to readability, IMHO.


The only time it would short-circuit is when it would otherwise raise 
AttributeError for trying to access an attribute from None, which is 
also going to short-circuit. The difference is that it short-circuits 
the expression only, and not all statements up until the next except 
handler.


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

On Mon, 23 Jul 2018 10:51:31 +0100
Steve Dower  wrote:
> 
> Which is the most important operator?
> -
> 
> Personally, I think '?.' is the most valuable.

For me, it's the most contentious.  The fact that a single '?' added to
a regular line of Python code can short-circuit execution silently is a
net detriment to readability, IMHO.

In a code review, this means I must be careful about '?' sigils lest I
miss important bug magnets.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

Responding to a few more ideas that have come up here. Again, apologies 
for not directing them to the original authors, but I want to focus on 
the ideas that are leading towards a more informed decision, and not 
getting distracted by providing customised examples for people or 
getting into side debates.


I'm also going to try and update the PEP text today (or this week at 
least) to better clarify some of the questions that have come up (and 
fix that embarrassingly broken example :( )


Cheers,
Steve

False: '?.' should be surrounded by spaces
--

It's basically the same as '.'. Spell it 'a?.b', not 'a ?. b' (like 
'a.b' rather than 'a + b').


It's an enhancement to attribute access, not a new type of binary 
operator. The right-hand side cannot be evaluated in isolation.


In my opinion, it can also be read aloud the same as '.' as well (see 
the next point).


False: 'a?.b' is totally different from 'a.b'
-

The expression 'a.b' either results in 'a.b' or AttributeError (assuming 
no descriptors are involved).


The expression 'a?.b' either results in 'a.b' or None (again, assuming 
no descriptors).


This isn't a crazy new idea, it really just short-circuits a specific 
error that can only be precisely avoided with "if None" checks (catching 
AttributeError is not the same).


The trivial case is already a one-liner
---

That may be the case if you have a single character variable, but this 
proposal is not intended to try and further simplify already simple 
cases. It is for complex cases, particularly where you do not want to 
reevaluate the arguments or potentially leak temporary names into a 
module or class namespace.


(Brief aside: 'a if (a := expr) is not None else None' is going to be 
the best workaround. The suggested 'a := expr if a is not None else 
None' is incorrect because the condition is evaluated first and so has 
to contain the assignment.)


False: ??= is a new form of assignment
--

No, it's just augmented assignment for a binary operator. "a ??= b" is 
identical to "a = a ?? b", just like "+=" and friends.


It has no relationship to assignment expressions. '??=' can only be used 
as a statement, and is not strictly necessary, but if we add a new 
binary operator '??' and it does not have an equivalent augmented 
assignment statement, people will justifiably wonder about the 
inconsistency.


The PEP author is unsure about how it works
---

I wish this statement had come with some context, because the only thing 
I'm unsure about is what I'm supposed to be unsure about.


That said, I'm willing to make changes to the PEP based on the feedback 
and discussion. I haven't come into this with a "my way is 100% right 
and it will never change" mindset, so if this is a misinterpretation of 
my willingness to listen to feedback then I'm sorry I wasn't more clear. 
I *do* care about your opinions (when presented fairly and constructively).


Which is the most important operator?
-

Personally, I think '?.' is the most valuable. The value of '??' arises 
because (unless changing the semantics from None-aware to False-aware) 
it provides a way of setting the default that is consistent with how we 
got to the no-value value (e.g. `None?.a ?? b` and `""?.a ?? b` are 
different, whereas `None?.a or b` and `""?.a or b` are equivalent).


I'm borderline on ?[] right now. Honestly, I think it works best if it 
also silently handles LookupError (e.g. for traversing a loaded JSON 
dict), but then it's inconsistent with ?. which I think works best if it 
handles None but allows AttributeError. Either way, both have the 
ability to directly handle the exception. For example, (assuming e1, e2 
are expressions and not values):


v = e1?[e2]

Could be handled as this example (for None-aware):

_temp1 = (e1)
v = _temp1[e2] if _temp1 is not None else None

Or for silent exception handling of the lookup only:

_temp1 = (e1)
_temp2 = (e2)
try:
v = _temp1[_temp2] if _temp1 is not None else None
except LookupError:
v = None

Note that this second example is _not_ how most people protect against 
invalid lookups (most people use `.get` when it's available, or they 
accept that LookupErrors raised from e1 or e2 should also be silently 
handled). So there would be value in ?[] being able to more precisely 
handle the exception.


However, with ?. being available, and _most_ lookups being on dicts that 
have .get(), you can also traverse JSON values fairly easily like this:


d = json.load(f)
name = d.get('user')?.get('details')?.get('name') ?? ''

With ?[] doing the safe lookup as well, this could be:

d = json.load(f)
name = d?['user']?['details']?['name'] ?? ''

Now, my *least* favourite part of this is that (as 

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 23Jul2018 0151, Steven D'Aprano wrote:

What if there was a language
supported, non-hackish way to officially delay evaluation of
expressions until explicitly requested?


The current spelling for this is "lambda: delayed-expression" and the 
way to request the value is "()". :)


(I'm not even being that facetious here. People ask for delayed 
expressions all the time, and it's only 7 characters, provided the 
callee knows they're getting it, and the semantics are already well 
defined and likely match what you want.)


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

On Monday, July 23, 2018 at 8:24:45 AM UTC+2, Nicholas Cole wrote:

And that leads to a simple question: how many times does this actually 
> occur in real-world by python code? -- i.e. how many times do I want 
> to check the value of an existing label, and, finding it is None (and 
> None specifically), then assign it a value? 
>

The PEP present a few examples.

I think the compactness and clarity is really gained when doing a descent 
into an "attribute tree", where any (or selected) members can be None, like 
getting back to the  example by Steven (spell-corrected, and expanded):

 meal = obj?.spam?.eggs.tomato?.cheese ?? "Mozzarella"

Where, to put the proposal in even better light, I have assumed that eggs 
instances always have a tomato attributes (i.e. are never None).

This is indeed much more compact that the current version, and arguably 
more readable (it's easier to parse once you know the syntax...but you have 
to know the special syntax that will be used for this kind of stuff only). 
The more you deepen the attribute access, the more you gain, but of course 
deep attribute access is not so common. The new operators may make deep 
attribute hierarchies (or deeply nested dicts/lists) slightly more common, 
and there also I do not think it's a good thing.

For me the issue is that you gain little, each operator is very limited in 
scope, but at the same it's a operator, and those are introduced very 
carefully in Python (the resistance to line noise is high, it's one of the 
defining aspect of Python since forever).

Each of them do not do enough IMHO, it's too special case and do not unlock 
especially powerfull/elegant/generalization reuse of other part of Python 
syntax. If you add something, it should play nice with the existing feature 
and solve nagging issues that broaden its appeal, or be powerful/general 
enough to justify it's existence on its own, or be so self-evident for a 
python user that it feels it's solving a bug.

It's not the case for ?? and friends imho, far from it.

Also, what happen if you want to modify your deep nested tree, not only 
access it?

obj?.spam?.eggs.tomato?.cheese = "Mozzarella"

will not work, and the proposal will not really help there (Or will it? I 
am not the proposer, I am strongly against it, so I could easily miss 
capabilities).
If it's not possible, you lose a kind of symmetry, and that I do not like 
(orthogonality and symmetries are really nice in in a computer language, it 
helps quickly remembering the syntax as you are not cluttered by special 
cases and exceptions)

Steven wrote:


The Python community has always been conservative and resistant to 
change, but the level of conservativeness is now pushing towards fear 
of change rather than justifiable caution about adding new features that 
cannot easily be reverted. 

That's probably because you like this proposal. Really, compared to the 2.0 
days, it seems that Python has became much less resistant to change. You 
have resistance even when proposing changes in standard library, or even 
the C interpreter internal, unseen in the Python layer, and imho it's often 
justified (what can be discussed is how arbitrary the actual selection of 
change is, but a general resistance is not a bad thing)
It is a little bit optimistic to expect ?? and friends will be a walk in 
the park, especially after := ...


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Nicholas Cole]

On Mon, Jul 23, 2018 at 2:38 AM Steven D'Aprano  wrote:
>
> On Mon, Jul 23, 2018 at 12:59:20AM +0200, Giampaolo Rodola' wrote:
>
> > You're back at "since we have X that justifies the addition of Y" [1]
> > and AFAICT that's the only argument you have provided so far in a 100+
> > messages discussion.
>
> The PEP itself justifies the addition of Y.

This thread seems to be unnecessarily heated.

Other languages have these operators, and so they aren't a wild idea.
That said, from what I've seen, Swift optionals are very different
things, and Python really has nothing like them.

In Python, is None really special enough to need an operator like this?

One issue for me is that the trivial case is already a one-liner:

if a is None: a = 10

And it works for other things too:

if a is -1: a = 10

if not a: a = 10

Again, is None special enough in Python to need this operator? I don't know.

And that leads to a simple question: how many times does this actually
occur in real-world by python code? -- i.e. how many times do I want
to check the value of an existing label, and, finding it is None (and
None specifically), then assign it a value?

What does a scan through the existing core library say?

I'm +0 on this proposal.

Best wishes,

N
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Mon, Jul 23, 2018 at 12:59:20AM +0200, Giampaolo Rodola' wrote:

> You're back at "since we have X that justifies the addition of Y" [1]
> and AFAICT that's the only argument you have provided so far in a 100+
> messages discussion.

The PEP itself justifies the addition of Y.

Chris' argument, and mine, is countering *your* arguments in opposition. 
It is not a positive argument for Y, since the PEP does an admirable job 
at that. It is a response to the FUD (Fear, Uncertainty, Doubt) that 
Python is becoming "Perl-like", or even more ludicrously, like APL and 
J. (That's David Mertz' position.)

To my eyes, your opposition basically comes down to "it is new, and I 
don't like it because it is new". It looks to me like pure resistance to 
change simply due to dislike of change. See also David's response that 
he is against the changes made to Python over the last five years.

The concrete arguments you are making against this change apply equally 
to existing features. If your (and others') arguments are valid now, 
they would have been equally valid back in Python 1.5. If punctuation is 
unreadable and Perlish, so is "." and ":" punctuation. If ?? is bad 
because it is "implicit", then so is import or sorted.

Arguments by slogan ("explicit is better than implicit") are rarely good 
arguments -- especially when nobody seems to be able to define implicit 
and explicit explicitly.

As for the argument that Python is "mature" and so we should resist 
change, we could have said the same thing going all the way back to 
Python 1.5 and probably beyond. Have you tried using Python 1.5 
recently? Or even Python 2.4. I have. I wonder how I managed to get 
anything useful done.

Some of us think that Python 3.6 or 3.7 is fantastic and so good that 
every addition to the language can only make it worse. I suggest that 
when we have Python 4.5 or 4.6, we will wonder how on earth we managed 
to get any useful work done with Python 3.7.

The Python community has always been conservative and resistant to 
change, but the level of conservativeness is now pushing towards fear 
of change rather than justifiable caution about adding new features that 
cannot easily be reverted.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Sun, Jul 22, 2018 at 05:09:39PM +0200, Giampaolo Rodola' wrote:

> > > I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
> > > but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
> > > Perl-ish to me, non pythonic and overall not explicit, no matter what
> > > the chosen symbol is gonna be.
> >
> > Please explain what is not explicit about it. "a?.b" is very simple
> > and perfectly explicit: it means "None if a is None else a.b". What
> > does "not explicit" mean, other than "I don't like this code"?
> 
> I find it less explicit mainly because it does 3 things at once: check
> if attribute is None, use it if it's not None and continue the
> evaluation from left to right. I find that logic to be more explicit
> when living on different lines or is clearly delimited by keywords and
> spaces.

Does this mean that instead of writing:

result = obj.attr + 1

you prefer to be "explicit" and split it over multiple lines?

# named functions are always better than punctuation
from operator import add  
# explicit is better than punctuation
value = getattr(obj, "attr")  
result = add(value, 1)


> ? has no spaces, it's literally "variable names interrupted by
> question marks" and evaluation can stop at any time while scanning the
> line from left to right.

Just like ordinary attribute access.

This is the point I was making earlier: you accept existing punctuation 
doing these things:

try:
obj.spam.egsg.tomato.cheese  # oops a typo
except AttributeError:
# evaluation can stop at any time
...

while demanding a higher standard for new punctuation.

All of your criticisms of ? punctuation applies to . as well. Do you 
think that Python is a worse language than it should have been because 
we use . for attribute access?


> Multiple "?" can live on the same line so
> that's incentive to write one-liners, really, and to me one-liners are
> always less explicit than the same logic split on multiple lines.

Explicit is not always better.

import this

is much better than:


for location in sys.path:
try:
for file in os.listdir(location):
if os.splitext(file) in ('.pyc', '.py', '.so'):
...


etc. There is a HUGE amount of implicit complexity and work done behind 
the scenes in every import, and we're happy to keep it that way.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Sun, Jul 22, 2018 at 11:26:15PM +1000, Chris Angelico wrote:

> You forget that the operator will *short-circuit*. It will not
> evaluate the second argument if the first argument is None. You cannot
> do this with a function, other than with a hack like a lambda
> function.

We keep running up to this issue. What if there was a language 
supported, non-hackish way to officially delay evaluation of 
expressions until explicitly requested?

That would allow us to write a function:

func(arg, default = delayed-expression)

and avoid new punctuation. Then the only bike-shedding will be where the 
function should live and what it is called and how many arguments it 
ought to take...


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Mon, Jul 23, 2018 at 12:08 AM Chris Angelico  wrote:
>
> On Mon, Jul 23, 2018 at 7:51 AM, Giampaolo Rodola'  wrote:
> > On Sun, Jul 22, 2018 at 10:55 PM Chris Angelico  wrote:
> >>
> >> On Mon, Jul 23, 2018 at 6:43 AM, Giampaolo Rodola'  
> >> wrote:
> >> > On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
> >> >>
> >> >> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
> >> >> wrote:
> >> >> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  
> >> >> > wrote:
> >> >> > I find it less explicit mainly because it does 3 things at once: check
> >> >> > if attribute is None, use it if it's not None and continue the
> >> >> > evaluation from left to right. I find that logic to be more explicit
> >> >> > when living on different lines or is clearly delimited by keywords and
> >> >> > spaces. ? has no spaces, it's literally "variable names interrupted by
> >> >> > question marks" and evaluation can stop at any time while scanning the
> >> >> > line from left to right. Multiple "?" can live on the same line so
> >> >> > that's incentive to write one-liners, really, and to me one-liners are
> >> >> > always less explicit than the same logic split on multiple lines.
> >> >>
> >> >> Ah, I see what you mean. Well, think about what actually happens when
> >> >> you write "lst.sort()". In terms of "hidden behaviour", there is far
> >> >> FAR more of it in existing syntax than in the new proposals.
> >> >
> >> > I am not sure I'm following you (what does lst.sort() have to do with 
> >> > "?"?).
> >>
> >> The "." in "lst.sort" is an operator. How much hidden behaviour is
> >> there in that? Do you actually even know every possible thing that can
> >> happen? Don't feel bad if you don't - it's not an indictment of your
> >> quality as a programmer, but an acknowledgement that Python's
> >> attribute access is incredibly complicated.
> >
> > I'm [not] going to engage into a discussion about the analogy between "?"
> > and "." because simply there is none. It doesn't prove anything except
> > that you're not really interested in having a serious discussion about
> > the pros and cons of this PEP: you just want it to happen no matter
> > what.
>
> That's because the dot already exists in the language, and you have
> become so accustomed to it that you don't see it any more. You've just
> proven my point.

You're back at "since we have X that justifies the addition of Y" [1]
and AFAICT that's the only argument you have provided so far in a 100+
messages discussion.

[1] https://mail.python.org/pipermail/python-ideas/2018-July/052068.html

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Mon, Jul 23, 2018 at 7:51 AM, Giampaolo Rodola'  wrote:
> On Sun, Jul 22, 2018 at 10:55 PM Chris Angelico  wrote:
>>
>> On Mon, Jul 23, 2018 at 6:43 AM, Giampaolo Rodola'  
>> wrote:
>> > On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
>> >>
>> >> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
>> >> wrote:
>> >> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
>> >> > I find it less explicit mainly because it does 3 things at once: check
>> >> > if attribute is None, use it if it's not None and continue the
>> >> > evaluation from left to right. I find that logic to be more explicit
>> >> > when living on different lines or is clearly delimited by keywords and
>> >> > spaces. ? has no spaces, it's literally "variable names interrupted by
>> >> > question marks" and evaluation can stop at any time while scanning the
>> >> > line from left to right. Multiple "?" can live on the same line so
>> >> > that's incentive to write one-liners, really, and to me one-liners are
>> >> > always less explicit than the same logic split on multiple lines.
>> >>
>> >> Ah, I see what you mean. Well, think about what actually happens when
>> >> you write "lst.sort()". In terms of "hidden behaviour", there is far
>> >> FAR more of it in existing syntax than in the new proposals.
>> >
>> > I am not sure I'm following you (what does lst.sort() have to do with 
>> > "?"?).
>>
>> The "." in "lst.sort" is an operator. How much hidden behaviour is
>> there in that? Do you actually even know every possible thing that can
>> happen? Don't feel bad if you don't - it's not an indictment of your
>> quality as a programmer, but an acknowledgement that Python's
>> attribute access is incredibly complicated.
>
> I'm [not] going to engage into a discussion about the analogy between "?"
> and "." because simply there is none. It doesn't prove anything except
> that you're not really interested in having a serious discussion about
> the pros and cons of this PEP: you just want it to happen no matter
> what.

That's because the dot already exists in the language, and you have
become so accustomed to it that you don't see it any more. You've just
proven my point.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 10:55 PM Chris Angelico  wrote:
>
> On Mon, Jul 23, 2018 at 6:43 AM, Giampaolo Rodola'  wrote:
> > On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
> >>
> >> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
> >> wrote:
> >> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
> >> > I find it less explicit mainly because it does 3 things at once: check
> >> > if attribute is None, use it if it's not None and continue the
> >> > evaluation from left to right. I find that logic to be more explicit
> >> > when living on different lines or is clearly delimited by keywords and
> >> > spaces. ? has no spaces, it's literally "variable names interrupted by
> >> > question marks" and evaluation can stop at any time while scanning the
> >> > line from left to right. Multiple "?" can live on the same line so
> >> > that's incentive to write one-liners, really, and to me one-liners are
> >> > always less explicit than the same logic split on multiple lines.
> >>
> >> Ah, I see what you mean. Well, think about what actually happens when
> >> you write "lst.sort()". In terms of "hidden behaviour", there is far
> >> FAR more of it in existing syntax than in the new proposals.
> >
> > I am not sure I'm following you (what does lst.sort() have to do with "?"?).
>
> The "." in "lst.sort" is an operator. How much hidden behaviour is
> there in that? Do you actually even know every possible thing that can
> happen? Don't feel bad if you don't - it's not an indictment of your
> quality as a programmer, but an acknowledgement that Python's
> attribute access is incredibly complicated.

I'm going to engage into a discussion about the analogy between "?"
and "." because simply there is none. It doesn't prove anything except
that you're not really interested in having a serious discussion about
the pros and cons of this PEP: you just want it to happen no matter
what.

> Imagine if we were talking about people, rather than features in a
> language; imagine if, to join the Warriors Guild, you had to first
> slay a red dragon with nothing but a rusty dagger, despite none of the
> existing members having done so. Is that reasonable to ask? Can you
> say "well, the guild is mature now, so yeah, it's a good thing"?

Ditto.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 11:51 PM Giampaolo Rodola'  wrote:
>
> On Sun, Jul 22, 2018 at 10:55 PM Chris Angelico  wrote:
> >
> > On Mon, Jul 23, 2018 at 6:43 AM, Giampaolo Rodola'  
> > wrote:
> > > On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
> > >>
> > >> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
> > >> wrote:
> > >> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  
> > >> > wrote:
> > >> > I find it less explicit mainly because it does 3 things at once: check
> > >> > if attribute is None, use it if it's not None and continue the
> > >> > evaluation from left to right. I find that logic to be more explicit
> > >> > when living on different lines or is clearly delimited by keywords and
> > >> > spaces. ? has no spaces, it's literally "variable names interrupted by
> > >> > question marks" and evaluation can stop at any time while scanning the
> > >> > line from left to right. Multiple "?" can live on the same line so
> > >> > that's incentive to write one-liners, really, and to me one-liners are
> > >> > always less explicit than the same logic split on multiple lines.
> > >>
> > >> Ah, I see what you mean. Well, think about what actually happens when
> > >> you write "lst.sort()". In terms of "hidden behaviour", there is far
> > >> FAR more of it in existing syntax than in the new proposals.
> > >
> > > I am not sure I'm following you (what does lst.sort() have to do with 
> > > "?"?).
> >
> > The "." in "lst.sort" is an operator. How much hidden behaviour is
> > there in that? Do you actually even know every possible thing that can
> > happen? Don't feel bad if you don't - it's not an indictment of your
> > quality as a programmer, but an acknowledgement that Python's
> > attribute access is incredibly complicated.
>
> I'm going to engage into a discussion [...]

s/I'm going/I'm not going

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[David Mertz]

On Sun, Jul 22, 2018, 4:56 PM Chris Angelico  wrote:

> It means people place crazily high demands on new proposals.
>

I think the bar has been much too low for introducing new features over the
last 5 years or so. Internal changes like the new dictionary implementation
are fine, but user-facing changes should be exceedingly rare in the base
language. This proposal doesn't come remotely close to such a good standard.

I was consistently +0 on the 572 idea, as long as its worst excesses were
trimmed, as in the final PEP. But after reading this discussion, I almost
reconsider that opinion since its social effect seems to be a move towards
accepting wild and unnecessary changes that "might be useful" for a few
unusual programming patterns.

Honestly, if you want Perl, and as many different ways to approach each
problem as there are programmers (each with their own syntax niche), that
language continues to be fully working. I'm not even writing that to be
dismissive... There are actually some pretty and interesting ideas over
there. But I very much want Python not to be like that, and to do most of
my work in a readable language with as few special characters/signils as
feasible.

>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

On Mon, 23 Jul 2018 06:53:53 +1000
Chris Angelico  wrote:
> 
> >> Which is back to what Steven said: people demand such a high
> >> bar for new syntax that few existing pieces of syntax would pass it.  
> >
> > Probably. That's what happens when a language is mature. Personally I
> > don't think that's a bad thing.  
> 
> I do. It means people place crazily high demands on new proposals.

"Crazy" is just a personal judgement.  I do think high (and even very
high) demands are entirely justified by the language's maturity.

> Imagine if we were talking about people, rather than features in a
> language; imagine if, to join the Warriors Guild, you had to first
> slay a red dragon with nothing but a rusty dagger, despite none of the
> existing members having done so.

This is the silliest analogy I have seen on this list for a very long
time.

If someone thinks getting their PEP accepted is like belonging to a
« Warriors Guild » (whatever that is in the real world), I'd question
their motivations for contributing.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Peter J. Holzer]

On 2018-07-22 10:33:23 -0700, Michael Selik wrote:
> On Sat, Jul 21, 2018, 6:55 PM Steven D'Aprano  wrote:
> On Sun, Jul 22, 2018 at 01:56:35AM +0200, Giampaolo Rodola' wrote:
> > On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano 
> > wrote:
> > > Tens of thousands of non-English speakers have had to learn the 
> meaning
> > > of what might as well be meaningless, random sets of symbols (to them)
> > > like "class", "import", "while" and "True". If they can do so, perhaps
> > > we English-speakers should stop complaining about how hard it is to
> > > memorise the meaning of a couple of symbols like ??.
> >
> > "class", "import", "while" and "True" are keywords, not symbols.
> 
> They are only key WORDS if you are an English speaker.

They are also words if you are not an English speaker. I don't speak
Chinese, but "Pǔtonghuà" is certainly a word for me (although I wouldn't
recognize 普通话 as that word).

> If your language
> doesn't use the Latin script, they don't even look like words. They look
> like gibberish: ∌≇⊅∇∫
> 
> 
> Are you familiar with how people who don't speak English code? I'm curious how
> they teach and use Python.

I know a few people who don't know enough English to read English
documentation. But AFAIK they didn't have a problem memorizing a few
dozen keywords. Learning the semantics of a programming language is a
much larger task than learning a few words, and having familiar keywords
probably doesn't really help much (they still don't mean what they mean
in English).

Of course we do use the Latin alphabet, I don't know how somebody who
had to learn the Latin alphabet specifically for programming would cope.
It's probably like programming in APL.

I guess I could learn PerlYuYan[1] to find out ;-).

hp

[1] https://metacpan.org/pod/Lingua::Sinica::PerlYuYan


-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Mon, Jul 23, 2018 at 6:43 AM, Giampaolo Rodola'  wrote:
> On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
>>
>> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
>> wrote:
>> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
>> > I find it less explicit mainly because it does 3 things at once: check
>> > if attribute is None, use it if it's not None and continue the
>> > evaluation from left to right. I find that logic to be more explicit
>> > when living on different lines or is clearly delimited by keywords and
>> > spaces. ? has no spaces, it's literally "variable names interrupted by
>> > question marks" and evaluation can stop at any time while scanning the
>> > line from left to right. Multiple "?" can live on the same line so
>> > that's incentive to write one-liners, really, and to me one-liners are
>> > always less explicit than the same logic split on multiple lines.
>>
>> Ah, I see what you mean. Well, think about what actually happens when
>> you write "lst.sort()". In terms of "hidden behaviour", there is far
>> FAR more of it in existing syntax than in the new proposals.
>
> I am not sure I'm following you (what does lst.sort() have to do with "?"?).

The "." in "lst.sort" is an operator. How much hidden behaviour is
there in that? Do you actually even know every possible thing that can
happen? Don't feel bad if you don't - it's not an indictment of your
quality as a programmer, but an acknowledgement that Python's
attribute access is incredibly complicated.

>> Which is back to what Steven said: people demand such a high
>> bar for new syntax that few existing pieces of syntax would pass it.
>
> Probably. That's what happens when a language is mature. Personally I
> don't think that's a bad thing.

I do. It means people place crazily high demands on new proposals.
Imagine if we were talking about people, rather than features in a
language; imagine if, to join the Warriors Guild, you had to first
slay a red dragon with nothing but a rusty dagger, despite none of the
existing members having done so. Is that reasonable to ask? Can you
say "well, the guild is mature now, so yeah, it's a good thing"?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Antoine Pitrou]

On Sun, 22 Jul 2018 22:43:15 +0200
"Giampaolo Rodola'" 
wrote:

> On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
> >
> > On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  
> > wrote:  
> > > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
> > > I find it less explicit mainly because it does 3 things at once: check
> > > if attribute is None, use it if it's not None and continue the
> > > evaluation from left to right. I find that logic to be more explicit
> > > when living on different lines or is clearly delimited by keywords and
> > > spaces. ? has no spaces, it's literally "variable names interrupted by
> > > question marks" and evaluation can stop at any time while scanning the
> > > line from left to right. Multiple "?" can live on the same line so
> > > that's incentive to write one-liners, really, and to me one-liners are
> > > always less explicit than the same logic split on multiple lines.  
> >
> > Ah, I see what you mean. Well, think about what actually happens when
> > you write "lst.sort()". In terms of "hidden behaviour", there is far
> > FAR more of it in existing syntax than in the new proposals.  
> 
> I am not sure I'm following you (what does lst.sort() have to do with "?"?).
> 
> > Which is back to what Steven said: people demand such a high
> > bar for new syntax that few existing pieces of syntax would pass it.  
> 
> Probably. That's what happens when a language is mature. Personally I
> don't think that's a bad thing.

Agreed with Giampaolo.  The opportunities for syntax additions should
become rarer and rarer.

Regards

Antoine.


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 10:01 PM Chris Angelico  wrote:
>
> On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  wrote:
> > On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
> > I find it less explicit mainly because it does 3 things at once: check
> > if attribute is None, use it if it's not None and continue the
> > evaluation from left to right. I find that logic to be more explicit
> > when living on different lines or is clearly delimited by keywords and
> > spaces. ? has no spaces, it's literally "variable names interrupted by
> > question marks" and evaluation can stop at any time while scanning the
> > line from left to right. Multiple "?" can live on the same line so
> > that's incentive to write one-liners, really, and to me one-liners are
> > always less explicit than the same logic split on multiple lines.
>
> Ah, I see what you mean. Well, think about what actually happens when
> you write "lst.sort()". In terms of "hidden behaviour", there is far
> FAR more of it in existing syntax than in the new proposals.

I am not sure I'm following you (what does lst.sort() have to do with "?"?).

> Which is back to what Steven said: people demand such a high
> bar for new syntax that few existing pieces of syntax would pass it.

Probably. That's what happens when a language is mature. Personally I
don't think that's a bad thing.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Mon, Jul 23, 2018 at 1:09 AM, Giampaolo Rodola'  wrote:
> On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
>>
>> On Sun, Jul 22, 2018 at 11:35 PM, Giampaolo Rodola'  
>> wrote:
>> > On Sun, Jul 22, 2018 at 2:10 PM Steven D'Aprano  
>> > wrote:
>> >>
>> >> On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
>> >> > On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  
>> >> > wrote:
>> >> [...]
>> >> > > I don't think that "+" is harder to read than
>> >> > > "standard_mathematics_operators_numeric_addition"
>> >> >
>> >> >
>> >> > Please let's drop the argument that + - * / = and ? are the same.
>> >> [...]
>> >> But if we insist that every symbol we use is instantly recognisable and
>> >> intuitively obvious to every programmer, we're putting the bar for
>> >> acceptance impossibly high.
>> >
>> > I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
>> > but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
>> > Perl-ish to me, non pythonic and overall not explicit, no matter what
>> > the chosen symbol is gonna be.
>>
>> Please explain what is not explicit about it. "a?.b" is very simple
>> and perfectly explicit: it means "None if a is None else a.b". What
>> does "not explicit" mean, other than "I don't like this code"?
>
> I find it less explicit mainly because it does 3 things at once: check
> if attribute is None, use it if it's not None and continue the
> evaluation from left to right. I find that logic to be more explicit
> when living on different lines or is clearly delimited by keywords and
> spaces. ? has no spaces, it's literally "variable names interrupted by
> question marks" and evaluation can stop at any time while scanning the
> line from left to right. Multiple "?" can live on the same line so
> that's incentive to write one-liners, really, and to me one-liners are
> always less explicit than the same logic split on multiple lines.

Ah, I see what you mean. Well, think about what actually happens when
you write "lst.sort()". In terms of "hidden behaviour", there is far
FAR more of it in existing syntax than in the new proposals. Which is
back to what Steven said: people demand such a high bar for new syntax
that few existing pieces of syntax would pass it.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Clément Pit-Claudel]

On 2018-07-22 08:10, Steven D'Aprano wrote:
> Indeed. And I think we ought to think carefully about the benefits and 
> costs of all of those variants separately.
> 
> To me, the ?? operator seems like a clear and obvious win. The other 
> variants are more complex and the benefit is not as obvious to me, so I 
> haven't decided where I stand on them.

I like the ?? operator too; I like the short circuiting behavior a lot, and the 
semantics are simple.

I guess I'd use the other operators fairly often, too, mostly in quick-n-dirty 
scripts.  The one place where I miss them is when browsing through dictionaries 
that I get by querying a remote server and deserializing the resulting JSON.  I 
foten have situation where the value I'm interested in is e.g. either in 
response[0]["addresses"]["workplace"]["email"], or in 
response["records"][0]["contactInfo"]["emails"][0], and any of these subrecords 
may be missing.

Rewriting these using the ?[…] and ?. operators, I guess I would write 
something like this:

tmp = response?.get("records")
try:
tmp = tmp?[0]
except IndexError:
tmp = None
tmp = tmp?.get("contactInfo")?.get("emails")
try:
tmp = tmp?[0]
except IndexError:
tmp = None

Is there a shorter way to write these with the "?[…]" and "?." operators?  I 
guess the difficulty is that I need to swallow index and key errors, not just 
the type errors that come from indexing into None.

For cases like the one above, I usually use something like nget(response, 
["records"], [0], ["contactInfo"], ["emails"], [0]), where nget is defined as 
shown below (in this use case, the lack of short-circuiting isn't an issue):

def nget(obj, *fields, default=None):
for field in fields:
if obj is None:
return default
if isinstance(field, str):
obj = getattr(obj, field, None)
elif isinstance(field, list):
try:
obj = obj.__getitem__(field[0])
except (TypeError, KeyError, IndexError):
obj = None
return obj

class Test():
def __init__(self):
self.x = [{"y": 42, "z": ["aBc", "def"]}, [1]]

a = Test()
print(nget(a, "x", [0], ["z"], [0], [1]))  # B
print(nget(a, "x", [0], ["y"]))# 42
print(nget(a, "z", [0], ["y"], default="not found"))   # not found
print(nget(a, "z", [57], ["y"], default="not found"))  # not found

It would probably not be hard to wrap this into a special object, to be able to 
write something like 
wrap(response)["records"][0]["contactInfo"]["emails"][0].unwrap(). "wrap" would 
change its argument into a proxy returning a special indexable variant of None 
on key errors, and that dictionary would also call "wrap" on the results of 
__getitem__.  Something like this:

class wrap():
SENTINEL = object()

def __init__(self, obj):
self.obj = obj

def unwrap(self):
return self.obj

def __getitem__(self, key):
try:
return wrap(self.obj.__getitem__(key))
except (TypeError, AttributeError, KeyError):
return wrap(None)

a = [{"y": 42, "z": ["aBc", "def"]}, [1]]
print(wrap(a)[0]["z"][0][1].unwrap())

I think that's more or less what pymaybe does, in fact.

Cheers,
Clément.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Michael Selik]

On Sat, Jul 21, 2018, 6:55 PM Steven D'Aprano  wrote:

> On Sun, Jul 22, 2018 at 01:56:35AM +0200, Giampaolo Rodola' wrote:
> > On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano 
> wrote:
> > > Tens of thousands of non-English speakers have had to learn the meaning
> > > of what might as well be meaningless, random sets of symbols (to them)
> > > like "class", "import", "while" and "True". If they can do so, perhaps
> > > we English-speakers should stop complaining about how hard it is to
> > > memorise the meaning of a couple of symbols like ??.
> >
> > "class", "import", "while" and "True" are keywords, not symbols.
>
> They are only key WORDS if you are an English speaker. If your language
> doesn't use the Latin script, they don't even look like words. They look
> like gibberish: ∌≇⊅∇∫
>

Are you familiar with how people who don't speak English code? I'm curious
how they teach and use Python.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Peter J. Holzer]

On 2018-07-22 09:01:58 -0400, David Mertz wrote:
> On Sun, Jul 22, 2018, 8:11 AM Steven D'Aprano  wrote:
> To me, the ?? operator seems like a clear and obvious win. The other
> variants are more complex and the benefit is not as obvious to me, so I
> haven't decided where I stand on them.
> 
> 
> Yes, that is the only one I'm merely -0 on. The others I'm -1000.

For me it's the opposite. ?? is +0: While I use the equivalent // in
Perl quite frequently, the benefit isn't all that great.

But ?. and ?[] are really useful.

Sequences like request.context.user.email occur quite frequently in
code, and I find 

request?.context?.user?.email

much more readable than

email = None
context = request.context
if context is not None:
user = context.user
if user is not None:
email = user.email

Note that 

request and request.context and request.context.user and 
request.context.user.email

is not equivalent even if you assume that None is the only possible
falsey value in this context. It evaluates request 4 times,
request.context 3 times, and request.context.user 2 times.

hp


-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: PGP signature
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 3:38 PM Chris Angelico  wrote:
>
> On Sun, Jul 22, 2018 at 11:35 PM, Giampaolo Rodola'  
> wrote:
> > On Sun, Jul 22, 2018 at 2:10 PM Steven D'Aprano  wrote:
> >>
> >> On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
> >> > On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  
> >> > wrote:
> >> [...]
> >> > > I don't think that "+" is harder to read than
> >> > > "standard_mathematics_operators_numeric_addition"
> >> >
> >> >
> >> > Please let's drop the argument that + - * / = and ? are the same.
> >> [...]
> >> But if we insist that every symbol we use is instantly recognisable and
> >> intuitively obvious to every programmer, we're putting the bar for
> >> acceptance impossibly high.
> >
> > I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
> > but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
> > Perl-ish to me, non pythonic and overall not explicit, no matter what
> > the chosen symbol is gonna be.
>
> Please explain what is not explicit about it. "a?.b" is very simple
> and perfectly explicit: it means "None if a is None else a.b". What
> does "not explicit" mean, other than "I don't like this code"?

I find it less explicit mainly because it does 3 things at once: check
if attribute is None, use it if it's not None and continue the
evaluation from left to right. I find that logic to be more explicit
when living on different lines or is clearly delimited by keywords and
spaces. ? has no spaces, it's literally "variable names interrupted by
question marks" and evaluation can stop at any time while scanning the
line from left to right. Multiple "?" can live on the same line so
that's incentive to write one-liners, really, and to me one-liners are
always less explicit than the same logic split on multiple lines.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > In my opinion, writing
 > 
 > expression if expression is None else default
 > 
 > is the *opposite* of Pythonic, it is verbose and the DRY violation is 
 > inelegant (as well as inefficient). I'd much rather use:
 > 
 > expression ?? default

Sure, if "expression or default" won't do.  But in my code, I can't
recall encountering a case where it wouldn't.

That is, in the vast majority of my code, the point of using None as
the "oops, try again" sentinel is not that it's a different *value*
from a falsie of the expected type, it's that it's a different *type*.
It has very few attributes, and so will most likely eventually raise
if I forget the "or default" clause and a falsie escapes from the
enclosing code, rather than silently doing an erroneous computation.

Of course "in my code" is very anecdotal, and we do have testimony
from many people that these cases are important to them.  I'd still
like to know, not how much code looks better with "expr ?? default"
vs. spelling it out as a conditional statement or expression, but
rather how much code *must* be expressed as "expr ??  default" (or
"expr ?. attr ?? default", as Steve Dower reminds us) because the
falsie of expected type is a useful value of expr (or expr.attr).

 > although with PEP 572 approved, there is an alternative:
 > 
 > temp := expression if temp is None else default
 > 
 > which avoids the DRY violation but is more verbose than even the first 
 > version.

No, it somewhat obfuscates the DRY violation, but you've still used
"temp" twice.  (Consider "var if var is None else default".)  I also
don't agree that it's more verbose than the first version if
"expression" is more complex than a variable reference, not to mention
the possibility of side effects in expression.

Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

Short circuit if the first argument is NOT None, I guess? ;-)

Yes, so a short circuit is sometimes good. Not often imho, for a default 
triggered by None, but sometimes...
In the case it is, do you want it to be hidden in an expression? Usually it 
would be better to draw attention, when the default is either costly to 
compute, or worse, it's evaluation have side effect. I would use an old 
fashioned if in those cases...___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Sun, Jul 22, 2018 at 11:35 PM, Giampaolo Rodola'  wrote:
> On Sun, Jul 22, 2018 at 2:10 PM Steven D'Aprano  wrote:
>>
>> On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
>> > On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  
>> > wrote:
>> [...]
>> > > I don't think that "+" is harder to read than
>> > > "standard_mathematics_operators_numeric_addition"
>> >
>> >
>> > Please let's drop the argument that + - * / = and ? are the same.
>> [...]
>> But if we insist that every symbol we use is instantly recognisable and
>> intuitively obvious to every programmer, we're putting the bar for
>> acceptance impossibly high.
>
> I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
> but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
> Perl-ish to me, non pythonic and overall not explicit, no matter what
> the chosen symbol is gonna be.

Please explain what is not explicit about it. "a?.b" is very simple
and perfectly explicit: it means "None if a is None else a.b". What
does "not explicit" mean, other than "I don't like this code"?

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 2:10 PM Steven D'Aprano  wrote:
>
> On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
> > On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  wrote:
> [...]
> > > I don't think that "+" is harder to read than
> > > "standard_mathematics_operators_numeric_addition"
> >
> >
> > Please let's drop the argument that + - * / = and ? are the same.
> [...]
> But if we insist that every symbol we use is instantly recognisable and
> intuitively obvious to every programmer, we're putting the bar for
> acceptance impossibly high.

I personally don't find "a ?? b" too bad (let's say I'm -0 about it)
but idioms such as "a?.b", "a ??= b" and "a?[3] ?? 4" look too
Perl-ish to me, non pythonic and overall not explicit, no matter what
the chosen symbol is gonna be. It looks like they want to do too much
for the sole reason of allowing people to write more compact code and
save a few lines. Compact code is not necessarily a good thing,
especially when it comes at the expense of readability and
explicitness, as I think is this case.

> All the obvious operators are already in use. Anything we add now is
> going to be a little bit niche, a little bit unusual.

That's basically my point. And I know I'll sound very conservative
here but to me that is a valid enough reason to not take action or be
extremely careful at the very least. Not to state the obvious but it's
not that we *have to* use the remaining unused symbols just because
they're there.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Sun, Jul 22, 2018 at 11:22 PM, Grégory Lielens
 wrote:
> The ?? operator is probably the less scary one regarding legibility, and in 
> guessing (or remembering) what it exactly does...
> Well, at least I think I understand what it does exactly, but if I'm not 
> wrong there, what it does is also quite simple and minimal.
>
> A function returning it's first non-None argument (or None, if all args are 
> None) will provide the same functionality, with not much typing. You have 
> parenthesis for the call, but you will probably need them anyway to group 
> things, for correcting precedence, or helping the reader to parse your 
> expression even if precedence was right.
> You have an extra call, so ?? may be more efficient...maybe.
>
> Is that a reason enough, together with a few letters saved typing, to 
> introduce ?? ? Not for me...

You forget that the operator will *short-circuit*. It will not
evaluate the second argument if the first argument is None. You cannot
do this with a function, other than with a hack like a lambda
function.

THAT is reason enough for an operator.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

The ?? operator is probably the less scary one regarding legibility, and in 
guessing (or remembering) what it exactly does...
Well, at least I think I understand what it does exactly, but if I'm not wrong 
there, what it does is also quite simple and minimal.

A function returning it's first non-None argument (or None, if all args are 
None) will provide the same functionality, with not much typing. You have 
parenthesis for the call, but you will probably need them anyway to group 
things, for correcting precedence, or helping the reader to parse your 
expression even if precedence was right.
You have an extra call, so ?? may be more efficient...maybe. 

Is that a reason enough, together with a few letters saved typing, to introduce 
?? ? Not for me...___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Sun, Jul 22, 2018 at 10:10 PM, Steven D'Aprano  wrote:
> As a community, we're risk-adverse. I understand why we should be
> conservative in what we add to the language (once added, it cannot
> easily be removed if it turns out to be a mistake) but on Python-Ideas
> we regularly demand levels of obviousness and "readability" that
> existing syntax does not reach.
>
> (For example, the dot operator for attribute access fails the "syntax
> should not look like grit on Tim's monitor" test.)

My understanding of that test is, more or less: "syntax should not be
such that grit on Tim's monitor can make it ambiguous". Which would
mean that attribute access does pass, since there's no logical meaning
for "list sort()" or "random randint" with just a space between them.
But otherwise, yes, I absolutely agree.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Sun, Jul 22, 2018 at 12:13:04PM +0200, Giampaolo Rodola' wrote:
> On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  wrote:
[...]
> > I don't think that "+" is harder to read than
> > "standard_mathematics_operators_numeric_addition"
> 
> 
> Please let's drop the argument that + - * / = and ? are the same.

In context, the argument was that non-word symbols are not always worse 
than words, not that all symbols are "the same".

Obviously symbols that we use regularly will be more familiar and easier 
to recognise than symbols we use rarely. I still have to make a 
conscious action to recall which of ∩ and ∪ is set union and 
intersection, and don't ask me what set symmetric difference is. And 
even after 20 years of Python I still occasionally write ^ for 
exponentiation instead of **.

But if we insist that every symbol we use is instantly recognisable and 
intuitively obvious to every programmer, we're putting the bar for 
acceptance impossibly high.


> They clearly are not. Anybody learned those symbols at elementary 
> schools, all programming languages have them and using math in 
> programming is common enough to justify a symbol over a keyword. "a + 
> b" is literally just an addition and nothing else.

That's not quite correct: '+' in Python is used for both addition and 
sequence concatenation. And with operator overloading, it can be 
anything at all. But it is *usually* addition, or concatenation.

I don't know what it is like in your country, but here in Australia, I 
don't know any school that teaches * for multiplication except in 
programming classes, which is not a core subject. The usual symbol we 
have for multiplication is × and sometimes ⋅ (dot operator).

This is a good point: after learning * for multiplication, it becomes so 
familiar that most of us forget that we haven't been using it forever. 
It becomes second-nature. In the same way that @ for decorators has 
become second nature, or slice notation. Both of which are terribly 
mysterious to people just starting out.

We shouldn't judge proposals on how mysterious they are the first time 
we see them, because everything is mysterious the first time. We should 
try to look forward to when we've seen them ten or twenty times. How 
will the "usefulness versus surprise" trade-off appear when, let's say, 
50% of the surprise has been worn away with experience?

As a community, we're risk-adverse. I understand why we should be 
conservative in what we add to the language (once added, it cannot 
easily be removed if it turns out to be a mistake) but on Python-Ideas 
we regularly demand levels of obviousness and "readability" that 
existing syntax does not reach.

(For example, the dot operator for attribute access fails the "syntax 
should not look like grit on Tim's monitor" test.)

I believe that it is fine to prefer that new syntax is no harder to 
learn or use than (for example) // or ** (neither of which is taught in 
maths class), or slice notation. But I don't think it is fair, or 
desirable, to demand levels of readability greater than what we already 
have in the less common corners of the language.

All the obvious operators are already in use. Anything we add now is 
going to be a little bit niche, a little bit unusual. It's not like 
we're going to suddenly realise we forgot to include a "subtract" 
operator. So it is perfectly natural that any new operators won't be as 
familiar as + or - operators. But it might become as familiar as ** or 
<< operators, or some of the less common regex patterns, and that's 
okay. Not everything needs to be as recognisable as the plus sign.


> The "?" variants have multiple meanings, spellings and implications:
[...]

Indeed. And I think we ought to think carefully about the benefits and 
costs of all of those variants separately.

To me, the ?? operator seems like a clear and obvious win. The other 
variants are more complex and the benefit is not as obvious to me, so I 
haven't decided where I stand on them.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

Except that the third possibility is not possible...if a is None, a[2] will 
throw an exception...
For now at least ;-)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 12:26 PM Paul Moore  wrote:

> On 22 July 2018 at 11:13, Giampaolo Rodola'  wrote:
> > - "a?[2] ?? 3" means "index 2 of list a is picked up if a is not None,
> else
> > use 3"
>
> Actually, doesn't it mean
>
> if a is not None, pick up index 2 of the list.
> If a is None, OR IF a[2] IS NONE, then use 3.
> If a is None but a[2] is not None, use a[2].
>
> ?
>
> Which is subtly different, and probably at least as prone to
> "accidental" errors as some of the constructs the None-aware operators
> are intended to replace.
>
> Paul
>

Yes, I think you're right.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Paul Moore]

On 22 July 2018 at 11:13, Giampaolo Rodola'  wrote:
> - "a?[2] ?? 3" means "index 2 of list a is picked up if a is not None, else
> use 3"

Actually, doesn't it mean

if a is not None, pick up index 2 of the list.
If a is None, OR IF a[2] IS NONE, then use 3.
If a is None but a[2] is not None, use a[2].

?

Which is subtly different, and probably at least as prone to
"accidental" errors as some of the constructs the None-aware operators
are intended to replace.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Sun, Jul 22, 2018 at 3:55 AM Steven D'Aprano  wrote:

> Indeed we do. But we also say:
>
> - we say "+" instead of "add"
> - we say "//" instead of "floor division"
> - we say "**" instead of "exponentiation"
> - we say "&" instead of "bitwise AND"
> - we say "f( ... )" instead of "call f with arguments ..."

[...]

I don't think that "+" is harder to read than

"standard_mathematics_operators_numeric_addition"


Please let's drop the argument that + - * / = and ? are the same. They
clearly are not. Anybody learned those symbols at elementary schools, all
programming languages have them and using math in programming is common
enough to justify a symbol over a keyword. "a + b" is literally just an
addition and nothing else. The "?" variants have multiple meanings,
spellings and implications:

- "a ?? b" means "b is chosen over a if a is None"

- "a ??= b" means "a is set to b if a is None"

- "a?.b" means "a.b is executed but only if a is not None"

- "a?[2] ?? 3" means "index 2 of list a is picked up if a is not None, else
use 3"

"a?.b"and "a?[2]" in particular go way beyond the mere "it's not pretty"
argument which, I concur, can be subjective, as you don't know where
evaluation stops. Even "a ??= b" goes beyond that as it introduces yet
another assignment operator (the third, as we now have = and :=). So again,
I don't think it's fair to dismiss the whole thing as "it's just another
symbol" or "it's like a + b".

As for bitwise operators: they are kinda obscure and low-levelish and when
I bump into them I still have to pause to reason what's going on. The
difference with ? though is that you basically have no other way to do the
same thing. Also they are much more rare and also are present in many other
languages since... forever.

-- 
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Grégory Lielens]

To get rid of the two other ( ?. And ?[] ), we could also define getitem and 
getattr for None to always return None...;-)

I'm joking, although such an "absorbing" None may have been a good choice when 
None was introduced, and maybe a way to do an absorbing-None per-statement 
maybe nice...Nice enough to add more subtleties to python? I don't think so, 
but it would be readable...___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Paul Moore]

On 22 July 2018 at 02:54, Steven D'Aprano  wrote:

> I'll admit that the number and variety of new operators gives me some
> reason to pause, but for the simplest and most obvious case, the
> proposed ?? operator, I think that the fears about readability are
> grossly exaggerated.

Certainly *my* concerns about readability are around the other
proposed operators (?[ and ?. in particular).

> In my opinion, writing
>
> expression if expression is None else default
>
> is the *opposite* of Pythonic, it is verbose and the DRY violation is
> inelegant (as well as inefficient). I'd much rather use:
>
> expression ?? default

Agreed. But the PEP proposes three other operators, and it's not at
all clear to me that those are such clear wins.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Chris Angelico]

On Sun, Jul 22, 2018 at 11:54 AM, Steven D'Aprano  wrote:
> If we gained a function
> or even a keyword from Italian, let's say "ripetere", would that really
> change the nature of Python? I don't think so. English speakers are
> adaptable, we don't so much borrow words from other languages as chase
> them down the alley and mug them for new vocabulary.

"lambda" would like to have a word with you. Or maybe a letter. I'm
not really sure.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Sun, Jul 22, 2018 at 01:56:35AM +0200, Giampaolo Rodola' wrote:
> On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano  wrote:
> > Tens of thousands of non-English speakers have had to learn the meaning
> > of what might as well be meaningless, random sets of symbols (to them)
> > like "class", "import", "while" and "True". If they can do so, perhaps
> > we English-speakers should stop complaining about how hard it is to
> > memorise the meaning of a couple of symbols like ??.
> 
> "class", "import", "while" and "True" are keywords, not symbols.

They are only key WORDS if you are an English speaker. If your language 
doesn't use the Latin script, they don't even look like words. They look 
like gibberish: ∌≇⊅∇∫


> A symbol is more cryptic than a keyword

I was using "symbol" in its most general sense, "a visible sign or 
representation of an idea". Words, letters, icons, emblems etc are all 
symbols. Sorry for being unclear.


> hence it comes at a higher cost in terms of readability. 

It is not clear to me that this is always true even when it comes to 
non-word symbols. I don't think that "+" is harder to read than 
"standard_mathematics_operators_numeric_addition" for example.

It is possible to be too verbose as well as too terse. This is why we 
aren't copying COBOL.


> which is the reason why conditionals use
> keywords instead symbols:
> 
> - we say "and" instead of "&&"
[...]

Indeed we do. But we also say:

- we say "+" instead of "add"
- we say "//" instead of "floor division"
- we say "**" instead of "exponentiation"
- we say "&" instead of "bitwise AND"
- we say "f( ... )" instead of "call f with arguments ..."

etc. Python has no shortage of non-word symbols:

  == != ~ - + * ** / // @ % ^ & | << >> < <= > >= [] ()


[...]
> > *Its just spelling*. If it is a useful and well-defined feature, we'll
> > get used to the spelling soon enough.
> 
> Such an argument may apply to other languages but not Python.

I disagree. I think it applies equally to Python. Python functions and 
keywords are usually English words, but not always:

  def elif

have to be memorised even by English speakers. If we gained a function 
or even a keyword from Italian, let's say "ripetere", would that really 
change the nature of Python? I don't think so. English speakers are 
adaptable, we don't so much borrow words from other languages as chase 
them down the alley and mug them for new vocabulary.

The same applies to non-word symbols. Look at how quickly and easily 
people adapted to @ (the commercial "at" sign, a variation of 
multiplication) as a separator in emails, not to mention #hashtags.

I'll admit that the number and variety of new operators gives me some 
reason to pause, but for the simplest and most obvious case, the 
proposed ?? operator, I think that the fears about readability are 
grossly exaggerated.


> The philosophy of the language is all about readability and beauty since
> day 1, and the main reason why Python got so successful despite being
> slow. 

Let's talk about Python's readability: the first time I saw Python code, 
I had *no idea* how to read it. This was Python 1.5, long before 
comprehensions, @ decorator syntax, etc. I could read Pascal, Forth, 
Hypertalk, BASIC and Fortran, and I looked at Python and couldn't make 
heads or tails of it. It was full of cryptic idioms like:

for i in range(len(sequence))

which is meaningless until you learn what range does and learn to read 
it as a for loop:

for i = 0 to len(sequence) - 1

And as for slice notation:

suffix = word[n:]

that might as well have been advanced quantum mechanics transliterated 
into Korean by a native Navaho speaker for all I could read it. I knew 
round brackets were used for function calls f() but the only experience 
I had with square and curly brackets was in mathematics, where they are 
used as second and third levels of brackets:

x = {[a (b+1)][b (a - 1)] - 1}/2

Now *that* I understood. What on earth was this mysterious {'a': 1} 
syntax that I keep seeing in Python code?

My initial experience with this bizarre, cryptic language Python was so 
off-putting that I put it aside for literally three or four years before 
coming back to it.

Of course I believe that Python is, generally speaking, a beautiful and 
elegant language, extremely readable. But readability doesn't exist in a 
vacuum. We still need to learn the symbols of the language, not just 
operators like ** % and // but words as well. To appreciate the elegance 
of the language, we need to know the common idioms, as well as the 
semantics of keywords and functions.

Unfortunately, ?? does have one disadvantage: even though it is used as 
an operator in a number of languages, Google doesn't seem to have 
indexed it. Goggling for "??" is unhelpful. But then googling for "@ 
python" is similarly unhelpful. Clearly decorators was a mistake. /s


> That's why we have mandatory indentation, to say one. We don't
> *have to* get used to idioms 

Re: [Python-ideas] PEP 505: None-aware operators

[Giampaolo Rodola']

On Thu, Jul 19, 2018 at 3:39 PM Steven D'Aprano  wrote:
> Tens of thousands of non-English speakers have had to learn the meaning
> of what might as well be meaningless, random sets of symbols (to them)
> like "class", "import", "while" and "True". If they can do so, perhaps
> we English-speakers should stop complaining about how hard it is to
> memorise the meaning of a couple of symbols like ??.

"class", "import", "while" and "True" are keywords, not symbols. A
symbol is more cryptic than a keyword hence it comes at a higher cost
in terms of readability. Which is the reason why conditionals use
keywords instead symbols:

- we say "and" instead of "&&"
- we say "or" instead of "||"
- we say "not" instead of "!"
- we say "is" instead of "==="

AFAICT "?" would be the first one breaking this rule for conditionals
[1], and not only for them since it can also arbitrarily appear in
non-conditionals (x.?y).

[1] I know, we say "==" instead of "equal" and "!=" instead of
"different" but the equal sign implies an equality. "?" does not imply
"None-ness": it's arbitrary. Furthermore "==" and "!=" are much more
common than testing for "None", hence they have more reason to exist.

> Surely its no more
> difficult than learning the various meanings of ** and [] which we've
> already done.

It is more difficult if you consider that ? has different spellings
(?, ??, a?.b, ??=, ...), each spelling with a different meaning.

> *Its just spelling*. If it is a useful and well-defined feature, we'll
> get used to the spelling soon enough.

Such an argument may apply to other languages but not Python. The
philosophy of the language is all about readability and beauty since
day 1, and the main reason why Python got so successful despite being
slow. That's why we have mandatory indentation, to say one. We don't
*have to* get used to idioms which can decrease readability. When we
do there must be a good reason and the spelling should matter (I
remember the debates about decorators' syntax).

--
Giampaolo - http://grodola.blogspot.com
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Ivan Levkivskyi]

I think I am with Michael here. I like the parallel between `??` and `or`,
we don't have `or=`, so `??=` is also not needed.

Although I understand a parallel between `obj.attr` and `obj['attr']`, I
think there is an additional point (in addition to two valid points by
Michael) why I don't like `?[`: in many situations
in my experience optional container attributes were results of suboptimal
APIs, so I would not encourage this pattern.

FWIW, I am rather -0 on adding all proposed operators, but I would be +1 on
adding just the two essential ones: ?? and ?.

--
Ivan



On 20 July 2018 at 01:40, Michael Lee  wrote:

> Hi -- I'm a new voice here, though I've been lurking for a while now.
>
> How do people feel about removing "??=" and "foo?[bar]" from the PEP and
> sticking with just "foo?.bar" and "foo ?? bar"?
>
> Reasons for not implementing "??=":
>
>1. I think the other operators are useful in that they can be chained
>together to shrink many different lines of code. In contrast, ??= can
>shrink at most one line of code: we get to remove a single 'if foo is
>None'. If the rest of the PEP is implemented, we can also just express
>this by doing "foo = foo ?? some_expr" which I think is still
>relatively concise.
>
>2. None of the other short-circuiting operators have an augmented
>assignment form -- e.g. we can do "foo = foo or bar", but there's no
>such thing as "foo or= bar". I don't really see why ?? in particular
>deserves to have an augmented assignment form.
>
>3. We already have two different kinds of assignment operators with
>the inclusion of PEP 572 -- in the interests of keeping Python as simple as
>possible, I think it'd be a good idea not to add a third one.
>
>
> Reasons for not implementing "foo?[bar]":
>
>1. It seems like "foo?[bar]" could be easily confused with "foo??[bar]".
>I don't think it's immediately obvious to a newcomer which spelling
>corresponds to which usage, and getting the two mixed up seems like the
>sort of thing that could cause all sorts of subtle bugs.
>
>2. We can already easily get the same functionality using standard
>Python. E.g., instead of doing foo?["bar"]?[0]?["baz"], we could do 
> lookup(foo,
>"bar", 0, "baz") where lookup is a function that looks roughly like
>this:
>
>def lookup(item, *parts):
>for part in parts:
>if item is None:
>return None
>item = item[parts]
>return item
>
>Of course, we could probably create the same sort of function to
>replace foo?.bar (albeit less ergonomically), but unlike foo?[bar],
>there's no possibility for confusion: doing foo??.bar will never be a
>valid Python expression.
>
>3. One counter-argument against removing foo?[bar] is that it would
>make expression that need both safe index and attribute lookups look weird
>-- you'd sometimes be using the "lookup" function described above (or
>something similar) and sometimes using ".?". However, I'd argue that these
>sorts of scenarios are relatively rare in practice, and that if you really
>need to deal with a bunch of code that requires you to use both forms of
>safe navigation, your code is likely already becoming pretty unreadable and
>should be rewritten -- maybe split up into multiple lines or something, or
>maybe just redesigned from scratch so you don't need to constantly manage a
>mess of Nones.
>
>
> More broadly, I think I agree with the sentiment some other people have
> that Python has acquired a lot of new features in a relatively short period
> of time, and that it would be nice to have some cooldown to let tooling and
> other implementations catch up. In that regard, I'd personally be happy if
> we didn't implement this PEP or just deferred it again. But if we *are*
> moving forward with it, I think it's worth trying to simplify it as much as
> possible/try and make it orthogonal with existing Python features.
>
> (But of course, I'm just some random person on the internet, so IDK if my
> opinion counts for much.)
>
> Regards,
> -- Michael
>
>
> On Thu, Jul 19, 2018 at 5:06 PM, Chris Angelico  wrote:
>
>> On Fri, Jul 20, 2018 at 10:03 AM, Greg Ewing
>>  wrote:
>> > Rhodri James wrote:
>> >>
>> >> If anyone can think of a good word for "if it isn't None, otherwise",
>> I'd
>> >> be all for it :-)
>> >
>> >
>> > I don't think there's any single Engish word that captures
>> > all of that, so we'd have to invent one.
>> >
>> > Some suggestions:
>> >
>> > inno (If Not None, Otherwise)
>> >
>> > oft  (Or, Failing That)
>>
>> Iunno, that'd oft be confusing.
>>
>> Kappa
>>
>> ChrisA
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> 

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

On 20Jul2018 1119, Brendan Barnwell wrote:
In this situation I lean toward "explicit is 
better than implicit" --- if you want to compare against None, you 
should do so explicitly --- and "special cases aren't special enough to 
break the rules" --- that is, None is not special enough to warrant the 
creation of multiple new operators solely to compare things against this 
specific value.


"The rules" declare that None is special - it's the one and only value 
that represents "no value". So is giving it special meaning here 
breaking the rules or following them? (See also the ~50% of the PEP 
dedicated to this subject, and also consider proposing a non-special 
result for "??? if has_no_value(value) else value" in the 'True' case.)


Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Brendan Barnwell]

On 2018-07-20 10:52, Steven D'Aprano wrote:

The problem is that `A else B` looks like it ought to be the same as
"else B" in if...else statements and the ternary if operator. That is,
"if the condition is false", and in this case there is nothing that
even hints that the condition is "A is None" rather than just A.


	Personally I consider this a problem with the whole null-coalescing 
idea.  Although it's true that the proposed null-coalescing operators 
don't look like existing syntax, it's also true that there's nothing 
about them that suggests to the uninitiated that they have anything to 
do with comparing to None.  In this situation I lean toward "explicit is 
better than implicit" --- if you want to compare against None, you 
should do so explicitly --- and "special cases aren't special enough to 
break the rules" --- that is, None is not special enough to warrant the 
creation of multiple new operators solely to compare things against this 
specific value.


--
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is no 
path, and leave a trail."

   --author unknown
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Fri, Jul 20, 2018 at 12:03:47PM +1200, Greg Ewing wrote:
> Rhodri James wrote:
> >If anyone can think of a good word for "if it isn't None, otherwise", 
> >I'd be all for it :-)
> 
> I don't think there's any single Engish word that captures
> all of that, so we'd have to invent one.
> 
> Some suggestions:
> 
> inno (If Not None, Otherwise)
> 
> oft  (Or, Failing That)

How about pttpciseano?

("pity that the python community is so edgy about new operators")

*wink*

Remember that adding a new keyword risks breaking code that uses that 
keyword as a variable. Adding a new operator does not.


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Thu, Jul 19, 2018 at 10:33:21AM +0200, Antoine Pitrou wrote:

>  def insort_right(a, x, lo=0, hi=None):
>  # ...
>  hi = hi else len(a)

I read that as "hi, if it is truthy, else len(a)".

The advantage of ?? as None-aware operator is that it cannot possibly be 
misread as applying to arbitrary falsey objects:

- for those familiar with the equivalent from other languages, 
  the use of ?? to check for nil/null/None is familiar and obvious;

- for those who aren't, the ?? syntax avoids leading them to guess
  the wrong behaviour, as "else" would do.


P.S. I just had to delete 40+ screenfuls of irrelevant quoted text. Come 
on folks, please trim your posts! Don't blame your tools.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Thu, Jul 19, 2018 at 08:57:50PM -0400, Michael Selik wrote:

> Try/except also looks decent.
> 
> try:
> x = foo['bar'][0]
> except TypeError:
> x = 'default'

Consider the case that foo['bar'] is supposed to return either a 
collection (something that can be indexed) or None. But due to a bug, it 
returns a float 1.234. Now the try...except will *wrongly* catch the 
exception from 1.234[0] and return the default.

The problem here is that the try...except block is NOT equivalent to the 
None-aware pattern:

obj = foo['bar']  # avoid time-of-check-to-time-of-use bugs
if obj is None:
x = 'default'
else:
   x = obj[0]

except in the special case that we can guarantee that foo['bar'] can 
only ever return a collection or None and will never, ever be buggy.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Mark E. Haase]

On Thu, Jul 19, 2018 at 2:36 PM Brendan Barnwell 
wrote:

> People keep saying that this null-coalescing behavior is so common
> and
> useful, etc., but that hasn't been my experience at all.  In my
> experience, the desire to shortcut this kind of logic is more often a
> sign of corner-cutting and insufficiently specified data formats, and is
> likely to cause bugs later on.  Eventually it has to actually matter
> whether something is None or not, and these operators just kick that can
> down the road.  In terms of their abstract meaning, they are not
> remotely close to as common or useful as operators like & and |.
>
>
Brendan,

I am sure you didn't intend any offense, but the phrase "corner-cutting" is
pejorative, especially when stated as a generalization and not as a
critique of a specific example. I have used these operators in professional
projects in other languages (i.e. Dart), and I used them because they
seemed like the best tool for the job at hand, not because I was shirking
effort or short on time.

There are accepted PEPs that I don't find useful, e.g. PEP-465 (infix
matrix multiplication operator). It's not because it's a bad PEP; it's just
aimed at a type of programming that I don't do. That PEP had to address
some of the same criticisms that arise from PEP-505: there's no precedent
for that spelling, it's a small niche, and we can already to that in pure
python.[1] But I trust the Python numeric computing community in their
assertion that the @ syntax is valuable to their work.

In the same way that PEP-465 is valuable to a certain type of programming,
None-coalescing (as an abstract concept, not the concrete proposal in
PEP-505) is valuable to another type of programming. Python is often used a
glue language.[2] In my own experience, it's very common to request data
from one system, do some processing on it, and send it to another system.
For example, I might run a SQL query, convert the results to JSON, and
return it in an HTTP response. As a developer, I may not get to choose the
database schema. I may also not get to choose the JSON schema. My job is to
marshal data from one system to another. Consider the following example:

def get_user_json(user_id):
  user = user_table.find_by_id(user_id)
  user_dict = {
# Username is always non-null in database.
'username': user['username'],

# Creation datetime is always non-null in database; must be ISO-8601
string in JSON.
'created_at': user['created'].isoformat(),

# Signature can be null in database and null in JSON.
'signature': user['signature'],

# Background color can be null in database but must not be null in JSON.
'background_color': user.get('background_color', 'blue')

# Login datetime can be null in database if user has never logged in.
Must either
# be null or an ISO-8601 string in JSON.
'last_logged_in_at': user['last_logged_in_at'].isoformat() if
user['last_login'] is not None else None,

# Remaining fields omitted for brevity
  }
  return json.dumps(user_dict)

Python makes a lot of the desired behavior concise to write. For example,
the DBAPI (PEP-249) states that null and None are interchanged when reading
and writing from the database. The stdlib json module also converts between
None and null. This makes a lot of the mappings trivial to express in
Python. But it gets tricky for cases like "last_logged_in_at", where a null
is permitted by the business rules I've been given, but if it's non-null
then I need to call a method on it. As written above, it is over 100
characters long. With safe-navigation operators, it could be made to fit
the line length without loss of clarity:

'last_logged_in_at': user['last_logged_in_at'] ?. isoformat(),

Many people in this thread prefer to write it as a block:

  if user['last_logged_in_at'] is None:
user_dict['last_logged_in_at'] = None
  else:
user_dict['last_logged_in_at'] = user['last_logged_in_at'].isoformat()

I agree that the block is readable, but only because my made-up function is
very short. In real-world glue code, you may have dozens of mappings, and
multiplying by 4 leads to functions that have so many lines of code that
readability is significantly worse, and that highly repetitive code
inevitably leads to typos.

It's not just databases and web services. An early draft of PEP-505
contains additional examples of where None arises in glue code.[4] And it's
not even just glue code: the standard library itself contains around 500
examples of none-coalescing or safe-navigation![5] I certainly don't think
anybody here will claim that stdlib authors have cut hundreds of corners.



[1] https://www.python.org/dev/peps/pep-0465/
[2] https://www.python.org/doc/essays/omg-darpa-mcc-position/
[3] https://www.python.org/dev/peps/pep-0249/
[4]
https://github.com/python/peps/blob/c5270848fe4481947ee951c2a415824b4dcd8a4f/pep-0505.txt#L63
[5] https://www.python.org/dev/peps/pep-0505/#examples

Re: [Python-ideas] PEP 505: None-aware operators

[Steve Dower]

Just for fun, I decided to go through some recently written code by some 
genuine Python experts (without their permission...) to see what changes would 
be worth taking. So I went to the sources of our github bots.

Honestly, I only found three places that were worth changing (though I'm now 
kind of leaning towards ?[] eating LookupError, since that seems much more 
useful when traversing the result of json.loads()...). I'm also not holding up 
the third one as the strongest example :)


>From 
>https://github.com/python/miss-islington/blob/master/miss_islington/status_change.py:

async def check_status(event, gh, *args, **kwargs):
if (
event.data["commit"].get("committer")
and event.data["commit"]["committer"]["login"] == "miss-islington"
):
sha = event.data["sha"]
await check_ci_status_and_approval(gh, sha, leave_comment=True)

After:

async def check_status(event, gh, *args, **kwargs):
if event.data["commit"].get("committer")?["login"] == "miss-islington":
sha = event.data["sha"]
await check_ci_status_and_approval(gh, sha, leave_comment=True)


>From https://github.com/python/bedevere/blob/master/bedevere/__main__.py:

try:
print('GH requests remaining:', gh.rate_limit.remaining)
except AttributeError:
pass

Assuming you want to continue hiding the message when no value is available:
if (remaining := gh.rate_limit?.remaining) is not None:
print('GH requests remaining:', remaining)

Assuming you want the message printed anyway:
print(f'GH requests remaining: {gh.rate_limit?.remaining ?? "N/A"}')


>From https://github.com/python/bedevere/blob/master/bedevere/news.py (this is 
>the one I'm including for completeness, not because it's the most compelling 
>example I've ever seen):

async def check_news(gh, pull_request, filenames=None):
if not filenames:
filenames = await util.filenames_for_PR(gh, pull_request)

After:
async def check_news(gh, pull_request, filenames=None):
filenames ??= await util.filenames_for_PR(gh, pull_request)


On 19Jul2018 , Steven D'Aprano wrote:
> In other words, we ought to be comparing the expressiveness of
> 
>  process(spam ?? something)
> 
> versus:
> 
> process(something if spam is None else spam)

Agreed, though to make it a more favourable comparison I'd replace "spam" with 
"spam()?.eggs" and put it in a class/module definition where you don't want 
temporary names leaking ;)

Cheers,
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505: None-aware operators

[Steven D'Aprano]

On Thu, Jul 19, 2018 at 12:57:01PM +0100, Jonathan Fine wrote:

> > Possibly this is exactly the wrong time to propose the next big syntax
> > change, since we currently have nobody to declare on it, but since we're
> > likely to argue for a while anyway it probably can't hurt [...]
> 
> Perhaps "argue" is not the right word here. It sounds too much for or
> against. And it has implications of being heated and angry.

You're new here, aren't you?

*wink*


-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/