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] slice[] to get more complex slices

[Serhiy Storchaka]

22.07.18 22:03, Todd пише:
For basic slices, the normal "slice(start, stop, step)" syntax works 
well.  But it becomes much more verbose to create more complicated 
slices that you want to re-use for multiple multidimensional data 
structures, like numpy, pandas, xarray, etc.


One idea I had was to allow creating slices by using indexing on the 
slice class.  So for example:


     x = slice[5:1:-1, 10:20:2, 5:end]

Would be equivalent to:

     x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None))

Note that this wouldn't be done on a slice instance, it would be done on 
the slice class.  The basic idea is that it would simply return whatever 
is given to __getitem__.


See https://bugs.python.org/issue24379 .

___
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] slice[] to get more complex slices

[Stefan Behnel]

Todd schrieb am 22.07.2018 um 21:03:
> For basic slices, the normal "slice(start, stop, step)" syntax works well.
> But it becomes much more verbose to create more complicated slices that you
> want to re-use for multiple multidimensional data structures, like numpy,
> pandas, xarray, etc.
> 
> One idea I had was to allow creating slices by using indexing on the slice
> class.  So for example:
> 
> x = slice[5:1:-1, 10:20:2, 5:end]
> 
> Would be equivalent to:
> 
> x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None))
> 
> Note that this wouldn't be done on a slice instance, it would be done on
> the slice class.  The basic idea is that it would simply return whatever is
> given to __getitem__.

Personally, I always likes that idea, but it would be worth looking up the
previous discussions in the list archive to find out if they lead to any
conclusion. AFAICT, "slice.literal" was the latest such proposal that was
discussed.

Stefan

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

[Python-ideas] slice[] to get more complex slices

[Todd]

For basic slices, the normal "slice(start, stop, step)" syntax works well.
But it becomes much more verbose to create more complicated slices that you
want to re-use for multiple multidimensional data structures, like numpy,
pandas, xarray, etc.

One idea I had was to allow creating slices by using indexing on the slice
class.  So for example:

x = slice[5:1:-1, 10:20:2, 5:end]

Would be equivalent to:

x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None))

Note that this wouldn't be done on a slice instance, it would be done on
the slice class.  The basic idea is that it would simply return whatever is
given to __getitem__.
___
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/

[Python-ideas] Add function readbyte to asyncio.StreamReader

[Jörn Heissler]

Hello,

I'm implementing a protocol where I need to read individual bytes until
a condition is met (value & 0x80 == 0).

My current approach is: value = (await reader.readexactly(1))[0]

To speed this up, I propose that a new function is added to
asyncio.StreamReader: value = await reader.readbyte()

I duplicated readexactly and stripped out some parts. Below code appears
to work:

async def readbyte(self):
if self._exception is not None:
raise self._exception

while not self._buffer:
if self._eof:
raise EOFError()
await self._wait_for_data('readbyte')

data = self._buffer[0]
del self._buffer[0]
self._maybe_resume_transport()
return data

For comparing the speed, I'm receiving a 50 MiB file byte-by-byte.

cpython-3.7.0:
readexactly: 42.43 seconds
readbyte   : 22.05 seconds
speedup: 92.4%

pypy3-v6.0.0:
readexactly: 3.21 seconds
readbyte   : 2.76 seconds
speedup: 16.3%

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

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

[Paul Moore]

Aargh, I hate Google Groups with a vengeance. If people *have* to post
from there, can they please change reply-to so that replies don't get
messed up. Or is that not possible, and yet another way that GG is
just broken?
Paul


-- Forwarded message --
From: Paul Moore 
Date: 22 July 2018 at 12:05
Subject: Re: [Python-ideas] PEP 505: None-aware operators
To: Grégory Lielens 
Cc: python-ideas 


On 22 July 2018 at 11:54, Grégory Lielens  wrote:
> Except that the third possibility is not possible...if a is None, a[2] will 
> throw an exception...
> For now at least ;-)

Doh. True, I should have said "If a is not None and a[2] is not None, use a[2]".

But my point about unintended behaviour if a[2] is None stands. And
the wider point that these operators are hard to reason correctly
about is probably emphasised by my mistake.

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]

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/