[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sun, 7 Feb 2021 04:53:43 +0300
Ivan Pozdeev  wrote:

> On 07.02.2021 0:24, Paul Sokolovsky wrote:
> > Hello,
> >
> > On Sun, 7 Feb 2021 00:00:41 +0300
> > Ivan Pozdeev via Python-Dev  wrote:
> >  
> >> Who said "__future__"?  
> > Other people said __future__. And yet other said "it's ok the way it
> > is, it's better to have it like that then keep not having it". And
> > yet other said something else (multiple else's).
> >  
> >> I said "3rd-party library". Independent from
> >> the CPython project. Maybe even a few of them -- to try out
> >> conflicting visions that emerged in the discussions.  
> > Such libraries exist for decade(s). MacroPy is a venerable,
> > well-known macro-capabilities-for-Python solution, which offers a
> > kind of pattern matching:
> > https://macropy3.readthedocs.io/en/latest/pattern.html . There're a
> > bunch of other, grep github.
> >
> > https://github.com/MegaIng/syntax-extensions-pep634 specifically
> > advertises itself as pure-Python implementation of PEP634 (using a
> > newer macro library), though I'm not sure how well it's development.
> > It also of course represents the right way to develop Python - in
> > Python itself. Sadly, "C" in "CPython" is stuck too deep in many
> > minds...
> >
> >
> > Bottom line is however: given the decade(s) old history of pattern
> > matching in *Python* (usual warning: don't mix up Python and
> > CPython!), arguing that very resourceful attempt to add pattern
> > matching to the reference implementation (that's where *CPython*
> > finally pops up), should be flushed down the toilet and the Python
> > community should be brought back into decade-long waiting state
> > without a reference implementation for pattern matching - umm,
> > suggesting that doesn't seem to be very productive.  
> 
> That's not the impression I got from looking through the discussiuon
> and the PEP.

I pretty closely followed "second half" of patter matching discussion -
after it became clear that there're a lot of criticism (and I shared
some criticism too). And I've got somewhat different impression than
yours. 

> I don't see references to any of those existing implementations
> anywhere in the PEP as well as a summary of various existing
> approaches and solutions, their pros and cons etc. which the proposal
> proper would derive its particulars from.

Well, a PEP is not "annals of Python history as related to area XXX".
It's a proposal for a specific change. Which should have good
argumentation, but still doesn't have to start with "When the Earth was
ball of flame, ...". There can be "too much" too.

You can see that very well with pattern matching proposal: its started
as PEP622, but was deemed too long and wide-scoped, and split into
*three* of PEP634/PEP635/PEP636 - all to ease community review. There
was also a proposal to add "other possible options" to PEP622, which
was rejected, and spawned into separate PEP642.

So, there quite a work was done, and saying "it's not enough" is not
helpful and not appreciating of authors' efforts (pretty titanic
efforts from mere Python user PoV).

> Both the PEPs and the
> discussion look like they are trying to write the functionality
> completely from sctratch, by the seat of their pants.

The authors of the PEPs are definitely aware of pre-history of pattern
matching in Python. Heck, that's why they went ahead with their
proposal - because they know that people wanted pattern matching in
Python for decades!

Designing "completely from scratch" isn't a bad choice in situation
with multiple choices and complex enough systems. And it wasn't
"completely from scratch", on multiple occasions authors said "that's
done similar to pattern matching in other languages".

Authors of alternative patmatching impls also provided feedback (I'm
not sure how well that was heard). 

> And from how much discord there is about syntax and semantics,

And that's where my impressions differ. There's a strong sentiment that
various aspects of pattern matching could "easily" be made better right
from the start than described in PEP634/PEP635/PEP636. But from people
who're interested in pattern matching, there're hardly valuation like
"PEP634 is so bad that we'd rather punish ourselves and live without
it, than with PEP634".

If anything, PEP642 showed that things can be much worse. And it's
ironic, because it exactly started with "small obvious improvements to
PEP634", but decided to replay the "road to hell is paved with good
intentions" proverb, and from small obvious things went to pretty
tangled speculations.

> I conclude that these are far from being well-established and
> practice-proven. So if the existing solutions really have a
> "decades-long history" as you claim, that history must be
> spectacularly uneventful -- which suggests that the feature is either
> in low demand or was ultimately proven by practice to be inadequate
> for real-world use.

Let me continue the story of MacroPy. His authors barely maintains 

[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sat, 6 Feb 2021 23:05:19 -0800
Guido van Rossum  wrote:

> That’s incorrect. __future__ is used when something new and
> *incompatible* is being introduced (and the old way is being
> deprecated at the same time). For experimental modules we use the
> term provisional. There’s no official term for experimental syntax
> (since we’ve never had any), but we could call that provisional as
> well.

Thanks, I'm aware. Thus the nature of my proposal is: redefine (extend)
cases when __future__ is used, e.g. when a PEP itself says something
like "There're many more could be done, but good things come in
pieces, and wise men know when to stand back and relax before
continuing. So, see ya next time!"

My argument that such usage of __future__ would correspond more to the
expectations of the Python end users ("feature is not fully developed
yet, and there could be small incompatible changes going forward").

> 
> On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky 
> wrote:
> 
> > Hello,
> >
> > On Sun, 7 Feb 2021 01:17:31 +
> > Paul Bryan  wrote:
> >  
> > > On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> > >  
> > > > A __future__ import would make clear to all that the feature is
> > > > experimental, and maybe there could be __future__ imports for
> > > > different parts of the proposal.  
> > >
> > > That's not my understanding. My understanding is __future__ is
> > > meant for  features that potentially break existing code, and
> > > allows code to opt-in in a release earlier than when it will
> > > behave that way by default. From what I can tell with this PEP,
> > > existing code can continue working the way it always has.  
> >
> > And that's not understanding of the majority of Python users. For
> > majority of "mere" users, __future__ is a marker that something new
> > (and thus experimental, for these categories are again equivalent
> > for most users) is being used in the current module.
> >
> > So, "from __future__ import with_statement" didn't mean to people
> > "you can't use variable named 'with' in this module" (because
> > majority of people never used such a variable name, so didn't
> > care), but instead meant "this module uses the new 'with'
> > statement, keep your ear sharp".
> >
> > And the current excuses go along the lines of "now that we've got a
> > parser with exponential memory usage, we can use __future__ like...
> > umm, never".
> >
> > Don't do that, keep using __future__ like it always was - to mark
> > experimental features.
> >
> >  
> > >
> > > Paul
> > >  
> >
> >
> > --
> > Best regards,
> >  Paul  mailto:pmis...@gmail.com
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-dev@python.org/message/2O3ZSLNOKZABQD4FIX7KAGM6JSF7JFYC/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >  
> -- 
> --Guido (mobile)



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BBXIQE6LKQQQOTWR3SO5K5OLJIOIQ33E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Guido van Rossum]

That’s incorrect. __future__ is used when something new and *incompatible*
is being introduced (and the old way is being deprecated at the same time).
For experimental modules we use the term provisional. There’s no official
term for experimental syntax (since we’ve never had any), but we could call
that provisional as well.

On Sat, Feb 6, 2021 at 22:44 Paul Sokolovsky  wrote:

> Hello,
>
> On Sun, 7 Feb 2021 01:17:31 +
> Paul Bryan  wrote:
>
> > On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> >
> > > A __future__ import would make clear to all that the feature is
> > > experimental, and maybe there could be __future__ imports for
> > > different parts of the proposal.
> >
> > That's not my understanding. My understanding is __future__ is meant
> > for  features that potentially break existing code, and allows code to
> > opt-in in a release earlier than when it will behave that way by
> > default. From what I can tell with this PEP, existing code can
> > continue working the way it always has.
>
> And that's not understanding of the majority of Python users. For
> majority of "mere" users, __future__ is a marker that something new (and
> thus experimental, for these categories are again equivalent for most
> users) is being used in the current module.
>
> So, "from __future__ import with_statement" didn't mean to people "you
> can't use variable named 'with' in this module" (because majority of
> people never used such a variable name, so didn't care), but instead
> meant "this module uses the new 'with' statement, keep your ear sharp".
>
> And the current excuses go along the lines of "now that we've got a
> parser with exponential memory usage, we can use __future__ like... umm,
> never".
>
> Don't do that, keep using __future__ like it always was - to mark
> experimental features.
>
>
> >
> > Paul
> >
>
>
> --
> Best regards,
>  Paul  mailto:pmis...@gmail.com
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/2O3ZSLNOKZABQD4FIX7KAGM6JSF7JFYC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3Q5XXWVIKKOD36YLUJWCDPFKPI455VAX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sun, 07 Feb 2021 13:32:17 +1300
Greg Ewing  wrote:

> On 7/02/21 9:58 am, Steve Holden wrote:
> > My suggestion that it be introduced via __future__ due to its 
> > contentious nature met immediate resistance.  
> 
> __future__ is for things that are changing in incompatible ways.
> This is an entirely new feature that doesn't conflict with anything
> existing, so it doesn't need __future__.

We rented a time machine, went to the future (multiple plausible
futures, as modern time machines allow, unlike the older crippled linear
models, as shown in 1980is movies), saw that there were many good things
missed, some requiring slightly incompatible changes, and decided to
use __future__ right away.

> -- 
> Greg


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UTTMX7UISATDPFMXGIF7HMIEVF4HOOY7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sun, 7 Feb 2021 13:21:08 +1100
Steven D'Aprano  wrote:

> On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote:
> > On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico 
> > wrote:  
> > > How will a __future__ import help here? Are there syntactic or
> > > behavioural changes that would be worth applying to some modules
> > > and not others? The entire point of a __future__ import is to
> > > maintain backward compatibility by, for instance, not introducing
> > > a keyword, unless it is explicitly requested. What advantage
> > > would there be here?  
> > 
> > The fact that a __future__ import only affects a single module is
> > precisely the point: we may not want the feature in our code
> > initially, but maybe we don't mind using third-party libraries that
> > use it.  
> 
> It's not compulsory to use syntactic features if your code doesn't
> need them. I have many scripts and modules that don't use while
> loops, or try...except blocks, or with statements.
> 
> A feature doesn't need to be a `__future__` import for you to just
> not use it.

Right, and the talk is about the opposite - early adopters of
PEP634-style pattern matching should mark the modules in which they
*use* PEP-634-style pattern matching, so it will be easy in the future
to spot such modules, if we get updated pattern matching style.

> > A __future__ import would make clear to all that the feature is
> > experimental,  
> 
> It certainly would not. There is nothing experimental about
> `__future__` imports. I cannot think of a single example of an
> experimental feature added via the future mechanism:
> 
> https://docs.python.org/3/library/__future__.html

All features added via __future__ were new, and thus experimental. For
example, they contained long trail of bugs and issues, which were
haunting their users for a long time, but at least the users knew what
to expect, seeing the __future__ import.

Sadly, the converse is not true - not all new and experimental features
were added using it, which caused users additional frustration in
dealing with them.

The proposal is to mend that sad practice, and consistently use
__future__ imports for experimental things (e.g. those which are "good
enough to go in, but definitely not fully ready, from the perspective
of 5-year timeframe of the language evolution").

A complimentary proposal is for "CPython core developers" to
redefine in their minds what __future__ import means, to look at it
from PoV of the end users, not from PoV of a Python language lawyer,
throwing links to formal docs which miss updates to correspond to
the actual programming language/software project reality. 




-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NYWURNPR7YPWZIRNP4CBWNFQ2HPSHCW5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sun, 7 Feb 2021 01:17:31 +
Paul Bryan  wrote:

> On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:
> 
> > A __future__ import would make clear to all that the feature is
> > experimental, and maybe there could be __future__ imports for
> > different parts of the proposal.  
> 
> That's not my understanding. My understanding is __future__ is meant
> for  features that potentially break existing code, and allows code to
> opt-in in a release earlier than when it will behave that way by
> default. From what I can tell with this PEP, existing code can
> continue working the way it always has.

And that's not understanding of the majority of Python users. For
majority of "mere" users, __future__ is a marker that something new (and
thus experimental, for these categories are again equivalent for most
users) is being used in the current module.

So, "from __future__ import with_statement" didn't mean to people "you
can't use variable named 'with' in this module" (because majority of
people never used such a variable name, so didn't care), but instead
meant "this module uses the new 'with' statement, keep your ear sharp".

And the current excuses go along the lines of "now that we've got a
parser with exponential memory usage, we can use __future__ like... umm,
never".

Don't do that, keep using __future__ like it always was - to mark
experimental features.


> 
> Paul
> 


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2O3ZSLNOKZABQD4FIX7KAGM6JSF7JFYC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Steven D'Aprano]

On Sat, Feb 06, 2021 at 10:00:16PM -0300, Luciano Ramalho wrote:
> On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico  wrote:
> > How will a __future__ import help here? Are there syntactic or
> > behavioural changes that would be worth applying to some modules and
> > not others? The entire point of a __future__ import is to maintain
> > backward compatibility by, for instance, not introducing a keyword,
> > unless it is explicitly requested. What advantage would there be here?
> 
> The fact that a __future__ import only affects a single module is
> precisely the point: we may not want the feature in our code
> initially, but maybe we don't mind using third-party libraries that
> use it.

It's not compulsory to use syntactic features if your code doesn't need 
them. I have many scripts and modules that don't use while loops, or 
try...except blocks, or with statements.

A feature doesn't need to be a `__future__` import for you to just not 
use it.


> A __future__ import would make clear to all that the feature is
> experimental,

It certainly would not. There is nothing experimental about `__future__` 
imports. I cannot think of a single example of an experimental feature 
added via the future mechanism:

https://docs.python.org/3/library/__future__.html


-- 
Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QSCVO26VXM32CK3VOL572UKYWQVU4UE5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

On 07.02.2021 0:24, Paul Sokolovsky wrote:

Hello,

On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev  wrote:


Who said "__future__"?

Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other said something else (multiple else's).


I said "3rd-party library". Independent from
the CPython project. Maybe even a few of them -- to try out
conflicting visions that emerged in the discussions.

Such libraries exist for decade(s). MacroPy is a venerable, well-known
macro-capabilities-for-Python solution, which offers a kind of pattern
matching: https://macropy3.readthedocs.io/en/latest/pattern.html .
There're a bunch of other, grep github.

https://github.com/MegaIng/syntax-extensions-pep634 specifically
advertises itself as pure-Python implementation of PEP634 (using a
newer macro library), though I'm not sure how well it's development.
It also of course represents the right way to develop Python - in
Python itself. Sadly, "C" in "CPython" is stuck too deep in many
minds...


Bottom line is however: given the decade(s) old history of pattern
matching in *Python* (usual warning: don't mix up Python and CPython!),
arguing that very resourceful attempt to add pattern matching to the
reference implementation (that's where *CPython* finally pops up),
should be flushed down the toilet and the Python community should be
brought back into decade-long waiting state without a reference
implementation for pattern matching - umm, suggesting that doesn't seem
to be very productive.


That's not the impression I got from looking through the discussiuon and the 
PEP.

I don't see references to any of those existing implementations anywhere in the PEP as well as a summary of various existing approaches and 
solutions, their pros and cons etc. which the proposal proper would derive its particulars from.

Both the PEPs and the discussion look like they are trying to write the 
functionality completely from sctratch, by the seat of their pants.

And from how much discord there is about syntax and semantics, I conclude that these are far from being well-established and 
practice-proven. So if the existing solutions really have a "decades-long history" as you claim, that history must be spectacularly 
uneventful -- which suggests that the feature is either in low demand or was ultimately proven by practice to be inadequate for real-world use.






On 06.02.2021 23:58, Steve Holden wrote:

My suggestion that it be introduced via __future__ due to its
contentious nature met immediate resistance. No point going down
that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev
mailto:python-dev@python.org>> wrote:

 With such a large new area of functionality that's at odds with
existing syntax and semantics and a lack of clear vision and
agreement, it sounds like this would be better first added as a
3rd-party library to let the syntax and semantics mature. (To allow
new syntax, it'll probably be parsing strings in that special
syntax.)

 (At https://www.python.org/dev/peps/pep-0634/
, there's no indication
that this option was considered.)


[]


--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RH4CZLZCY2O42NB6JI5ZUUFC5KGKRIIX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Inada Naoki]

I send a pull request https://github.com/python/peps/pull/1799

* Add Backward/Forward Compatibility section
* Add How to teach this section
* Remove io.LOCALE_ENCODING constant


-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TRIGYFRJSVSUWFQDYIUZI64BB4J323UN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Bryan]

On Sat, 2021-02-06 at 22:05 -0300, Luciano Ramalho wrote:

> The initial pattern matching syntax and semantics with its many
> corner
> cases may be incompatible with a future way of doing pattern matching
> that is better.

Then that future incompatible way should be marked with __future__, not
this PEP implementation.

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DNDPEXQXLHGXX4ZCUIZIDHEKCWIFY6LY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Bryan]

On Sat, 2021-02-06 at 22:00 -0300, Luciano Ramalho wrote:

> A __future__ import would make clear to all that the feature is
> experimental, and maybe there could be __future__ imports for
> different parts of the proposal.

That's not my understanding. My understanding is __future__ is meant
for  features that potentially break existing code, and allows code to
opt-in in a release earlier than when it will behave that way by
default. From what I can tell with this PEP, existing code can continue
working the way it always has.

Paul

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XYES63LQIVXZAX53B6MWT6UCIPLS2JGY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Luciano Ramalho]

On Sat, Feb 6, 2021 at 9:34 PM Greg Ewing  wrote:
> __future__ is for things that are changing in incompatible ways.
> This is an entirely new feature that doesn't conflict with anything
> existing, so it doesn't need __future__.

The initial pattern matching syntax and semantics with its many corner
cases may be incompatible with a future way of doing pattern matching
that is better.

Best,

Luciano


>
> --
> Greg
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/T3CJQWO7DQEJPECHUYJH655D75LMVOVM/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/QDOY4PN6MC5KPGWM5Z6TAWQUPFVSEYIQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Luciano Ramalho]

On Sat, Feb 6, 2021 at 6:23 PM Chris Angelico  wrote:
> How will a __future__ import help here? Are there syntactic or
> behavioural changes that would be worth applying to some modules and
> not others? The entire point of a __future__ import is to maintain
> backward compatibility by, for instance, not introducing a keyword,
> unless it is explicitly requested. What advantage would there be here?

The fact that a __future__ import only affects a single module is
precisely the point: we may not want the feature in our code
initially, but maybe we don't mind using third-party libraries that
use it.

A __future__ import would make clear to all that the feature is
experimental, and maybe there could be __future__ imports for
different parts of the proposal.

> > AND it should be documented as provisional for several
> > releases, like asyncio was (and remember: the asyncio API had lots of
> > breaking changes and prompted the addition of the async/await
> > keywords, a great improvement that forced the renaming of the very
> > fundamental async function from the original API).
>
> Documenting as "provisional" means that its behaviour can change.
> Again, how will that make things easier here?

Telling everyone that the behaviour can change allows you to change
the behaviour if you realize the behavior is unhelpful in some way.

Again, that's just a huge feature and I believe we should consider one
or more ways of making its adoption gradual and to make it easier to
fix oversights if needed.

Best,

Luciano







> ChrisA
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/VC3IV5XDTMKYZME75WQAHAEAWGOYTOBI/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Luciano Ramalho
|  Author of Fluent Python (O'Reilly, 2015)
| http://shop.oreilly.com/product/0636920032519.do
|  Technical Principal at ThoughtWorks
|  Twitter: @ramalhoorg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OYXS7YTGJWI6S5VMQJD7A3STTF64DXBA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Greg Ewing]

On 7/02/21 9:58 am, Steve Holden wrote:
My suggestion that it be introduced via __future__ due to its 
contentious nature met immediate resistance.


__future__ is for things that are changing in incompatible ways.
This is an entirely new feature that doesn't conflict with anything
existing, so it doesn't need __future__.

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/T3CJQWO7DQEJPECHUYJH655D75LMVOVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Steve Holden]

Good luck in your quest.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 9:00 PM Ivan Pozdeev  wrote:

> Who said "__future__"? I said "3rd-party library". Independent from the
> CPython project.
> Maybe even a few of them -- to try out conflicting visions that emerged in
> the discussions.
> On 06.02.2021 23:58, Steve Holden wrote:
>
> My suggestion that it be introduced via __future__ due to its contentious
> nature met immediate resistance. No point going down that road.
>
> Kind regards,
> Steve
>
>
> On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
>> With such a large new area of functionality that's at odds with existing
>> syntax and semantics and a lack of clear vision and agreement, it
>> sounds like this would be better first added as a 3rd-party library to
>> let the syntax and semantics mature. (To allow new syntax, it'll
>> probably be parsing strings in that special syntax.)
>>
>> (At https://www.python.org/dev/peps/pep-0634/, there's no indication
>> that this option was considered.)
>>
>> On 06.02.2021 18:44, Mark Shannon wrote:
>> > Hi,
>> >
>> > Since a decision on PEP 634 is imminent, I'd like to reiterate some
>> concerns that I voiced last year.
>> >
>> > I am worried about the semantics and implementation of PEP 634.
>> > I don't want to comment on the merits of pattern matching in general,
>> or the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>> >
>> > Semantics
>> > -
>> >
>> > 1. PEP 634 eschews the object model, in favour of adhoc instance
>> checks, length checks and attribute accesses.
>> >
>> > This is in contrast to almost all of the the rest of the language,
>> which uses special (dunder) methods:
>> >   All operators,
>> >   subscripting,
>> >   attribute lookup,
>> >   iteration,
>> >   calls,
>> >   tests,
>> >   object creation,
>> >   conversions,
>> >   and the with statement
>> >
>> > AFAICT, no justification is given for this.
>> > Why can't pattern matching use the object model?
>> >
>> > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
>> to the object model, and that works very well.
>> >
>> >
>> > 2. PEP 634 deliberately introduces a large area of undefined behaviour
>> into Python.
>> >
>> >
>> https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
>> >
>> > Python has, in general, been strict about not having undefined
>> behaviour.
>> > Having defined semantics means that you can reason about programs, even
>> non-idiomatic ones.
>> > [This is not unique to Python, it is really only C and C++ that have
>> areas of undefined behaviour]
>> >
>> > I can see no good reason for adding undefined behaviour. It doesn't
>> help anyone.
>> >
>> > The lack of precise semantics makes programs harder to understand, and
>> it makes the language harder to implement.
>> > If the semantics aren't specified, then the implementation becomes the
>> specification.
>> > This bakes bugs into the language and makes it harder to maintain,
>> > as bug-for-bug compatibility must be maintained.
>> >
>> >
>> > 3. Performance
>> >
>> > PEP 634 says that each pattern must be checked in turn.
>> > That means that multiple redundant checks must be performed on (for
>> example) a sequence if there are several mapping patterns.
>> > This is unnecessarily slow.
>> >
>> >
>> > Implementation
>> > --
>> >
>> > My main concern with the implementation is that it does too much work
>> into the interpreter.
>> > Much of that work can and should be done in the compiler.
>> > For example, deep in the implementation of the MATCH_CLASS instruction
>> is the following comment:
>> > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
>> >
>> > Such complex control flow should be handled during compilation, rather
>> than in the interpreter.
>> > Giant instructions like MATCH_CLASS are likely to have odd corner cases,
>> > and may well have a negative impact on the performance of the rest of
>> the language.
>> > It is a lot easier to reason about a sequence of simple bytecodes, than
>> one giant one with context-dependent behaviour.
>> >
>> > We have spent quite a lot of effort over the last few years
>> streamlining the interpreter.
>> > Adding these extremely complex instructions would be a big backward
>> step.
>> >
>> >
>> > Cheers,
>> > Mark.
>> > ___
>> > Python-Dev mailing list -- python-dev@python.org
>> > To unsubscribe send an email to python-dev-le...@python.org
>> > https://mail.python.org/mailman3/lists/python-dev.python.org/
>> > Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>> --
>> Regards,
>> Ivan
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> 

[Python-Dev] Re: Concerns about PEP 634

[Chris Angelico]

On Sun, Feb 7, 2021 at 8:14 AM Luciano Ramalho  wrote:
>
> On Sat, Feb 6, 2021 at 6:04 PM Steve Holden  wrote:
> >
> > My suggestion that it be introduced via __future__ due to its contentious 
> > nature met immediate resistance. No point going down that road.
>
> This is really unfortunate.
>
> I agree this is a huge language change and it should only be approved
> with some mechanism requiring explicit opt-in (such as __future__
> import)

How will a __future__ import help here? Are there syntactic or
behavioural changes that would be worth applying to some modules and
not others? The entire point of a __future__ import is to maintain
backward compatibility by, for instance, not introducing a keyword,
unless it is explicitly requested. What advantage would there be here?

> AND it should be documented as provisional for several
> releases, like asyncio was (and remember: the asyncio API had lots of
> breaking changes and prompted the addition of the async/await
> keywords, a great improvement that forced the renaming of the very
> fundamental async function from the original API).

Documenting as "provisional" means that its behaviour can change.
Again, how will that make things easier here?

ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VC3IV5XDTMKYZME75WQAHAEAWGOYTOBI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Paul Sokolovsky]

Hello,

On Sun, 7 Feb 2021 00:00:41 +0300
Ivan Pozdeev via Python-Dev  wrote:

> Who said "__future__"?

Other people said __future__. And yet other said "it's ok the way it
is, it's better to have it like that then keep not having it". And yet
other said something else (multiple else's). 

> I said "3rd-party library". Independent from
> the CPython project. Maybe even a few of them -- to try out
> conflicting visions that emerged in the discussions.

Such libraries exist for decade(s). MacroPy is a venerable, well-known
macro-capabilities-for-Python solution, which offers a kind of pattern
matching: https://macropy3.readthedocs.io/en/latest/pattern.html .
There're a bunch of other, grep github.

https://github.com/MegaIng/syntax-extensions-pep634 specifically
advertises itself as pure-Python implementation of PEP634 (using a
newer macro library), though I'm not sure how well it's development.
It also of course represents the right way to develop Python - in
Python itself. Sadly, "C" in "CPython" is stuck too deep in many
minds...


Bottom line is however: given the decade(s) old history of pattern
matching in *Python* (usual warning: don't mix up Python and CPython!),
arguing that very resourceful attempt to add pattern matching to the
reference implementation (that's where *CPython* finally pops up),
should be flushed down the toilet and the Python community should be
brought back into decade-long waiting state without a reference
implementation for pattern matching - umm, suggesting that doesn't seem
to be very productive.


> 
> On 06.02.2021 23:58, Steve Holden wrote:
> > My suggestion that it be introduced via __future__ due to its
> > contentious nature met immediate resistance. No point going down
> > that road.
> >
> > Kind regards,
> > Steve
> >
> >
> > On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev
> > mailto:python-dev@python.org>> wrote:
> >
> > With such a large new area of functionality that's at odds with
> > existing syntax and semantics and a lack of clear vision and
> > agreement, it sounds like this would be better first added as a
> > 3rd-party library to let the syntax and semantics mature. (To allow
> > new syntax, it'll probably be parsing strings in that special
> > syntax.)
> >
> > (At https://www.python.org/dev/peps/pep-0634/
> > , there's no indication
> > that this option was considered.)
> >

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DSQAFJNKNB5RN44R5TFX6FNGAGTZBPTF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Luciano Ramalho]

On Sat, Feb 6, 2021 at 6:04 PM Steve Holden  wrote:
>
> My suggestion that it be introduced via __future__ due to its contentious 
> nature met immediate resistance. No point going down that road.

This is really unfortunate.

I agree this is a huge language change and it should only be approved
with some mechanism requiring explicit opt-in (such as __future__
import) AND it should be documented as provisional for several
releases, like asyncio was (and remember: the asyncio API had lots of
breaking changes and prompted the addition of the async/await
keywords, a great improvement that forced the renaming of the very
fundamental async function from the original API).

Scala is recognized as an overly complex language [1], in part because
the designers like to experiment with new features all the time. It's
not a great benchmark for Python IMHO, but if we are going to leverage
the new PEG parser with huge language choices changes more often than
we have in the past, then we should consider adopting the feature
toggles like the Scala compiler [2], so that individual teams can
decide which features they want to use and which they don't.

[1] 
https://www.thoughtworks.com/radar/languages-and-frameworks/scala-the-good-parts
[2] https://docs.scala-lang.org/overviews/compiler-options/index.html
(look for options with the -language prefix)

Cheers,

Luciano


>
> Kind regards,
> Steve
>
>
> On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev 
>  wrote:
>>
>> With such a large new area of functionality that's at odds with existing 
>> syntax and semantics and a lack of clear vision and agreement, it
>> sounds like this would be better first added as a 3rd-party library to let 
>> the syntax and semantics mature. (To allow new syntax, it'll
>> probably be parsing strings in that special syntax.)
>>
>> (At https://www.python.org/dev/peps/pep-0634/, there's no indication that 
>> this option was considered.)
>>
>> On 06.02.2021 18:44, Mark Shannon wrote:
>> > Hi,
>> >
>> > Since a decision on PEP 634 is imminent, I'd like to reiterate some 
>> > concerns that I voiced last year.
>> >
>> > I am worried about the semantics and implementation of PEP 634.
>> > I don't want to comment on the merits of pattern matching in general, or 
>> > the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>> >
>> > Semantics
>> > -
>> >
>> > 1. PEP 634 eschews the object model, in favour of adhoc instance checks, 
>> > length checks and attribute accesses.
>> >
>> > This is in contrast to almost all of the the rest of the language, which 
>> > uses special (dunder) methods:
>> >   All operators,
>> >   subscripting,
>> >   attribute lookup,
>> >   iteration,
>> >   calls,
>> >   tests,
>> >   object creation,
>> >   conversions,
>> >   and the with statement
>> >
>> > AFAICT, no justification is given for this.
>> > Why can't pattern matching use the object model?
>> >
>> > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods to 
>> > the object model, and that works very well.
>> >
>> >
>> > 2. PEP 634 deliberately introduces a large area of undefined behaviour 
>> > into Python.
>> >
>> > https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
>> >
>> > Python has, in general, been strict about not having undefined behaviour.
>> > Having defined semantics means that you can reason about programs, even 
>> > non-idiomatic ones.
>> > [This is not unique to Python, it is really only C and C++ that have areas 
>> > of undefined behaviour]
>> >
>> > I can see no good reason for adding undefined behaviour. It doesn't help 
>> > anyone.
>> >
>> > The lack of precise semantics makes programs harder to understand, and it 
>> > makes the language harder to implement.
>> > If the semantics aren't specified, then the implementation becomes the 
>> > specification.
>> > This bakes bugs into the language and makes it harder to maintain,
>> > as bug-for-bug compatibility must be maintained.
>> >
>> >
>> > 3. Performance
>> >
>> > PEP 634 says that each pattern must be checked in turn.
>> > That means that multiple redundant checks must be performed on (for 
>> > example) a sequence if there are several mapping patterns.
>> > This is unnecessarily slow.
>> >
>> >
>> > Implementation
>> > --
>> >
>> > My main concern with the implementation is that it does too much work into 
>> > the interpreter.
>> > Much of that work can and should be done in the compiler.
>> > For example, deep in the implementation of the MATCH_CLASS instruction is 
>> > the following comment:
>> > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
>> >
>> > Such complex control flow should be handled during compilation, rather 
>> > than in the interpreter.
>> > Giant instructions like MATCH_CLASS are likely to have odd corner cases,
>> > and may well have a negative impact on the performance of the rest of the 
>> > language.
>> > It is a lot easier to reason about a sequence of simple 

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

Who said "__future__"? I said "3rd-party library". Independent from the CPython 
project.
Maybe even a few of them -- to try out conflicting visions that emerged in the 
discussions.

On 06.02.2021 23:58, Steve Holden wrote:

My suggestion that it be introduced via __future__ due to its contentious 
nature met immediate resistance. No point going down that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote:

With such a large new area of functionality that's at odds with existing 
syntax and semantics and a lack of clear vision and
agreement, it
sounds like this would be better first added as a 3rd-party library to let 
the syntax and semantics mature. (To allow new syntax, it'll
probably be parsing strings in that special syntax.)

(At https://www.python.org/dev/peps/pep-0634/ 
, there's no indication that this 
option was
considered.)

On 06.02.2021 18:44, Mark Shannon wrote:
> Hi,
>
> Since a decision on PEP 634 is imminent, I'd like to reiterate some 
concerns that I voiced last year.
>
> I am worried about the semantics and implementation of PEP 634.
> I don't want to comment on the merits of pattern matching in general, or 
the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>
> Semantics
> -
>
> 1. PEP 634 eschews the object model, in favour of adhoc instance checks, 
length checks and attribute accesses.
>
> This is in contrast to almost all of the the rest of the language, which 
uses special (dunder) methods:
>   All operators,
>   subscripting,
>   attribute lookup,
>   iteration,
>   calls,
>   tests,
>   object creation,
>   conversions,
>   and the with statement
>
> AFAICT, no justification is given for this.
> Why can't pattern matching use the object model?
>
> PEP 343 (the "with" statement) added the __enter__ and __exit__ methods 
to the object model, and that works very well.
>
>
> 2. PEP 634 deliberately introduces a large area of undefined behaviour 
into Python.
>
> 
https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior


>
> Python has, in general, been strict about not having undefined behaviour.
> Having defined semantics means that you can reason about programs, even 
non-idiomatic ones.
> [This is not unique to Python, it is really only C and C++ that have 
areas of undefined behaviour]
>
> I can see no good reason for adding undefined behaviour. It doesn't help 
anyone.
>
> The lack of precise semantics makes programs harder to understand, and it 
makes the language harder to implement.
> If the semantics aren't specified, then the implementation becomes the 
specification.
> This bakes bugs into the language and makes it harder to maintain,
> as bug-for-bug compatibility must be maintained.
>
>
> 3. Performance
>
> PEP 634 says that each pattern must be checked in turn.
> That means that multiple redundant checks must be performed on (for 
example) a sequence if there are several mapping patterns.
> This is unnecessarily slow.
>
>
> Implementation
> --
>
> My main concern with the implementation is that it does too much work 
into the interpreter.
> Much of that work can and should be done in the compiler.
> For example, deep in the implementation of the MATCH_CLASS instruction is 
the following comment:
> https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981

>
> Such complex control flow should be handled during compilation, rather 
than in the interpreter.
> Giant instructions like MATCH_CLASS are likely to have odd corner cases,
> and may well have a negative impact on the performance of the rest of the 
language.
> It is a lot easier to reason about a sequence of simple bytecodes, than 
one giant one with context-dependent behaviour.
>
> We have spent quite a lot of effort over the last few years streamlining 
the interpreter.
> Adding these extremely complex instructions would be a big backward step.
>
>
> Cheers,
> Mark.
> ___
> Python-Dev mailing list -- python-dev@python.org 

> To unsubscribe send an email to python-dev-le...@python.org 

> https://mail.python.org/mailman3/lists/python-dev.python.org/ 

> Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/

[Python-Dev] Re: Concerns about PEP 634

[Steve Holden]

My suggestion that it be introduced via __future__ due to its contentious
nature met immediate resistance. No point going down that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> With such a large new area of functionality that's at odds with existing
> syntax and semantics and a lack of clear vision and agreement, it
> sounds like this would be better first added as a 3rd-party library to let
> the syntax and semantics mature. (To allow new syntax, it'll
> probably be parsing strings in that special syntax.)
>
> (At https://www.python.org/dev/peps/pep-0634/, there's no indication that
> this option was considered.)
>
> On 06.02.2021 18:44, Mark Shannon wrote:
> > Hi,
> >
> > Since a decision on PEP 634 is imminent, I'd like to reiterate some
> concerns that I voiced last year.
> >
> > I am worried about the semantics and implementation of PEP 634.
> > I don't want to comment on the merits of pattern matching in general, or
> the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
> >
> > Semantics
> > -
> >
> > 1. PEP 634 eschews the object model, in favour of adhoc instance checks,
> length checks and attribute accesses.
> >
> > This is in contrast to almost all of the the rest of the language, which
> uses special (dunder) methods:
> >   All operators,
> >   subscripting,
> >   attribute lookup,
> >   iteration,
> >   calls,
> >   tests,
> >   object creation,
> >   conversions,
> >   and the with statement
> >
> > AFAICT, no justification is given for this.
> > Why can't pattern matching use the object model?
> >
> > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
> to the object model, and that works very well.
> >
> >
> > 2. PEP 634 deliberately introduces a large area of undefined behaviour
> into Python.
> >
> >
> https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
> >
> > Python has, in general, been strict about not having undefined behaviour.
> > Having defined semantics means that you can reason about programs, even
> non-idiomatic ones.
> > [This is not unique to Python, it is really only C and C++ that have
> areas of undefined behaviour]
> >
> > I can see no good reason for adding undefined behaviour. It doesn't help
> anyone.
> >
> > The lack of precise semantics makes programs harder to understand, and
> it makes the language harder to implement.
> > If the semantics aren't specified, then the implementation becomes the
> specification.
> > This bakes bugs into the language and makes it harder to maintain,
> > as bug-for-bug compatibility must be maintained.
> >
> >
> > 3. Performance
> >
> > PEP 634 says that each pattern must be checked in turn.
> > That means that multiple redundant checks must be performed on (for
> example) a sequence if there are several mapping patterns.
> > This is unnecessarily slow.
> >
> >
> > Implementation
> > --
> >
> > My main concern with the implementation is that it does too much work
> into the interpreter.
> > Much of that work can and should be done in the compiler.
> > For example, deep in the implementation of the MATCH_CLASS instruction
> is the following comment:
> > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
> >
> > Such complex control flow should be handled during compilation, rather
> than in the interpreter.
> > Giant instructions like MATCH_CLASS are likely to have odd corner cases,
> > and may well have a negative impact on the performance of the rest of
> the language.
> > It is a lot easier to reason about a sequence of simple bytecodes, than
> one giant one with context-dependent behaviour.
> >
> > We have spent quite a lot of effort over the last few years streamlining
> the interpreter.
> > Adding these extremely complex instructions would be a big backward step.
> >
> >
> > Cheers,
> > Mark.
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> Regards,
> Ivan
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 

[Python-Dev] Re: Concerns about PEP 634

[Ivan Pozdeev via Python-Dev]

With such a large new area of functionality that's at odds with existing syntax and semantics and a lack of clear vision and agreement, it 
sounds like this would be better first added as a 3rd-party library to let the syntax and semantics mature. (To allow new syntax, it'll 
probably be parsing strings in that special syntax.)


(At https://www.python.org/dev/peps/pep-0634/, there's no indication that this 
option was considered.)

On 06.02.2021 18:44, Mark Shannon wrote:

Hi,

Since a decision on PEP 634 is imminent, I'd like to reiterate some concerns 
that I voiced last year.

I am worried about the semantics and implementation of PEP 634.
I don't want to comment on the merits of pattern matching in general, or the 
proposed syntax in PEP 634 (or PEP 640 or PEP 642).

Semantics
-

1. PEP 634 eschews the object model, in favour of adhoc instance checks, length 
checks and attribute accesses.

This is in contrast to almost all of the the rest of the language, which uses 
special (dunder) methods:
  All operators,
  subscripting,
  attribute lookup,
  iteration,
  calls,
  tests,
  object creation,
  conversions,
  and the with statement

AFAICT, no justification is given for this.
Why can't pattern matching use the object model?

PEP 343 (the "with" statement) added the __enter__ and __exit__ methods to the 
object model, and that works very well.


2. PEP 634 deliberately introduces a large area of undefined behaviour into 
Python.

https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior

Python has, in general, been strict about not having undefined behaviour.
Having defined semantics means that you can reason about programs, even 
non-idiomatic ones.
[This is not unique to Python, it is really only C and C++ that have areas of 
undefined behaviour]

I can see no good reason for adding undefined behaviour. It doesn't help anyone.

The lack of precise semantics makes programs harder to understand, and it makes 
the language harder to implement.
If the semantics aren't specified, then the implementation becomes the 
specification.
This bakes bugs into the language and makes it harder to maintain,
as bug-for-bug compatibility must be maintained.


3. Performance

PEP 634 says that each pattern must be checked in turn.
That means that multiple redundant checks must be performed on (for example) a 
sequence if there are several mapping patterns.
This is unnecessarily slow.


Implementation
--

My main concern with the implementation is that it does too much work into the 
interpreter.
Much of that work can and should be done in the compiler.
For example, deep in the implementation of the MATCH_CLASS instruction is the 
following comment:
https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981

Such complex control flow should be handled during compilation, rather than in 
the interpreter.
Giant instructions like MATCH_CLASS are likely to have odd corner cases,
and may well have a negative impact on the performance of the rest of the 
language.
It is a lot easier to reason about a sequence of simple bytecodes, than one 
giant one with context-dependent behaviour.

We have spent quite a lot of effort over the last few years streamlining the 
interpreter.
Adding these extremely complex instructions would be a big backward step.


Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
Code of Conduct: http://python.org/psf/codeofconduct/


--
Regards,
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Daniel Moisset]

Hi Mark,

I think some of these issues have already been raised and replied (even if
no agreement has been reached). but this is a good summary, so let me reply
with a summary of responses for this.

On Sat, 6 Feb 2021 at 15:51, Mark Shannon  wrote:

> Hi,
>
> Since a decision on PEP 634 is imminent, I'd like to reiterate some
> concerns that I voiced last year.
>
> I am worried about the semantics and implementation of PEP 634.
> I don't want to comment on the merits of pattern matching in general, or
> the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>
> Semantics
> -
>
> 1. PEP 634 eschews the object model, in favour of adhoc instance checks,
> length checks and attribute accesses.
>
> This is in contrast to almost all of the the rest of the language, which
> uses special (dunder) methods:
>All operators,
>subscripting,
>attribute lookup,
>iteration,
>calls,
>tests,
>object creation,
>conversions,
>and the with statement
>
> AFAICT, no justification is given for this.
> Why can't pattern matching use the object model?
>

No one has said that "we can't". It's just that "we don't have to". The
underlying mechanisms used by pattern matching (instance check, length,
attribute access) already have their defined protocols and support within
the object model. It's analogous as the way in which  iterable unpacking
didn't need to define it's own object model special methods, because the
existing iteration mechanism used in for loops was sufficient.

This does not exclude possible future extensions to the object model to
include a richer protocol like described in
https://www.python.org/dev/peps/pep-0622/#custom-matching-protocol (where
it also describes why we're not proposing that *now*, why it can be done
later, and why we think it's best to do it later)


>
> PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
> to the object model, and that works very well.
>
>
> 2. PEP 634 deliberately introduces a large area of undefined behaviour
> into Python.
>
>
> https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
>
> Python has, in general, been strict about not having undefined behaviour.
> Having defined semantics means that you can reason about programs, even
> non-idiomatic ones.
> [This is not unique to Python, it is really only C and C++ that have
> areas of undefined behaviour]
>

The C standard uses a very peculiar definition of "undefined behaviour"
(I'm not familiar with the C++ one to assert anything, I'll assume it's the
same), where for certain set of programs, any resulting behaviour is valid,
even at compile time (so a compiler that deletes all your files when trying
to compile "void f() {int a[10]; a[10]=0;}" is standard compliant).
Comparing that with the use of the term "undefined behaviour" in the PEP is
not very useful, because even if they are the same words, they don't have
the same meaning

If you want to compare it with the C standards, the term we'd use would be
"implementation defined behaviour". Python has a lot of those. For example,
the output of all these python programs can change between implementations
(And some of these even change between versions of cpython):

   - print({3,2,1})
   - print(hash("hello"))
   - if id(1) == id(1): print("hello")
   - import sys; print(sys.getsizeof([]))

Some order of operations is also implementation dependent for example in
def foo():
   print(open("/etc/passwd")).read()
foo()

The moment where file closing happens is implementation dependent.

The section you linked to introduces behaviour in similar lines to all of
the above.


> I can see no good reason for adding undefined behaviour. It doesn't help
> anyone.
>
>
It helps for the point 3 that you mention (See below)


> The lack of precise semantics makes programs harder to understand, and
> it makes the language harder to implement.
> If the semantics aren't specified, then the implementation becomes the
> specification.
> This bakes bugs into the language and makes it harder to maintain,
> as bug-for-bug compatibility must be maintained.
>
>
> 3. Performance
>
> PEP 634 says that each pattern must be checked in turn.
> That means that multiple redundant checks must be performed on (for
> example) a sequence if there are several mapping patterns.
> This is unnecessarily slow.
>

What PEP 634 says about this(unless we're reading different sections, a
quote could help here) is that the semantics are the one of selecting
the *first
case block whose patterns succeeds matching it and whose guard condition
(if present) is "truthy"*.

As long as the semantics are respected, a smart compiler could reduce some
of the redundant checks (and that's *precisely* why the order of the checks
is left as implementation dependent).

It's important here to separate "sequential semantics" vs "implemented as
sequential checks". For an analogy, look at the "serializable" concept in
databases, where the outcome of 

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Stefano Borini]

Yes. It's already supported in the branch. You can do
MyType[whatever=5]. One could possibly change dict to allow both the
specification dict[str, int] and dict[key=str, value=int], but this
specific change of the dict class is not part of the implementation
nor the PEP (nor I expect it to happen, for what matters, and I would
not request it).

On Sat, 6 Feb 2021 at 11:10, Larry Hastings  wrote:
>
>
> On 2/5/21 4:25 PM, Stefano Borini wrote:
>
> dicts and lists will keep working as before. They will not support
> keyword arguments (probably ever, as there is no clear semantic for
> them) and the current implementation simply throws an error if the
> user tries to.
>
>
> Is the plan to add PEP 637 support to type objects, so they allow 
> constructing type hints using named parameters, as suggested in the PEP?
>
>
> Thanks,
>
>
> /arry



-- 
Kind regards,

Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R2WISH5AJHNIUPVTFXFCTN7E2IIIBKHR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PR review request: shutil permission errors

[Winson Luk]

Hey everyone,

Just following up on this PR since it's been quiet for the last week. We've
added test cases to confirm that this is still an issue in the latest build
which needs fixing.

We've also determined that this bug affects moving immutable directories
too, though only on darwin (MacOS). I'd appreciate a review+merge when
possible.

Best,
Winson

On Thu, Jan 28, 2021 at 1:19 PM Winson Luk  wrote:

> Hi folks,
>
> I've had an open PR for a few weeks that still needs a review:
> https://github.com/python/cpython/pull/24001
>
> This PR fixes a shutil.move() bug when permission to a directory is denied.
>
> Thanks,
> Winson
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GAEHLNMVEC2IHORBPUV42GR3TMBMH2XZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Guido van Rossum]

On Sat, Feb 6, 2021 at 03:13 Larry Hastings  wrote:

> On 2/5/21 4:25 PM, Stefano Borini wrote:
>
> dicts and lists will keep working as before. They will not support
> keyword arguments (probably ever, as there is no clear semantic for
> them) and the current implementation simply throws an error if the
> user tries to.
>
>
> Is the plan to add PEP 637 support to type objects, so they allow
> constructing type hints using named parameters, as suggested in the PEP?
>

>From time to time we have situations in the typing system where this would
be useful, and once it exists I expect we will use it

We have an immediate use for x[*y], see pep 646.

—Guido
-- 
--Guido (mobile)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CUULNR4DWKXN6FWKAL5EGDIPLCYQNLCH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Concerns about PEP 634

[Mark Shannon]

Hi,

Since a decision on PEP 634 is imminent, I'd like to reiterate some 
concerns that I voiced last year.


I am worried about the semantics and implementation of PEP 634.
I don't want to comment on the merits of pattern matching in general, or 
the proposed syntax in PEP 634 (or PEP 640 or PEP 642).


Semantics
-

1. PEP 634 eschews the object model, in favour of adhoc instance checks, 
length checks and attribute accesses.


This is in contrast to almost all of the the rest of the language, which 
uses special (dunder) methods:

  All operators,
  subscripting,
  attribute lookup,
  iteration,
  calls,
  tests,
  object creation,
  conversions,
  and the with statement

AFAICT, no justification is given for this.
Why can't pattern matching use the object model?

PEP 343 (the "with" statement) added the __enter__ and __exit__ methods 
to the object model, and that works very well.



2. PEP 634 deliberately introduces a large area of undefined behaviour 
into Python.


https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior

Python has, in general, been strict about not having undefined behaviour.
Having defined semantics means that you can reason about programs, even 
non-idiomatic ones.
[This is not unique to Python, it is really only C and C++ that have 
areas of undefined behaviour]


I can see no good reason for adding undefined behaviour. It doesn't help 
anyone.


The lack of precise semantics makes programs harder to understand, and 
it makes the language harder to implement.
If the semantics aren't specified, then the implementation becomes the 
specification.

This bakes bugs into the language and makes it harder to maintain,
as bug-for-bug compatibility must be maintained.


3. Performance

PEP 634 says that each pattern must be checked in turn.
That means that multiple redundant checks must be performed on (for 
example) a sequence if there are several mapping patterns.

This is unnecessarily slow.


Implementation
--

My main concern with the implementation is that it does too much work 
into the interpreter.

Much of that work can and should be done in the compiler.
For example, deep in the implementation of the MATCH_CLASS instruction 
is the following comment:

https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981

Such complex control flow should be handled during compilation, rather 
than in the interpreter.

Giant instructions like MATCH_CLASS are likely to have odd corner cases,
and may well have a negative impact on the performance of the rest of 
the language.
It is a lot easier to reason about a sequence of simple bytecodes, than 
one giant one with context-dependent behaviour.


We have spent quite a lot of effort over the last few years streamlining 
the interpreter.

Adding these extremely complex instructions would be a big backward step.


Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 597: Add optional EncodingWarning

[Inada Naoki]

On Tue, Feb 2, 2021 at 1:40 PM Inada Naoki  wrote:
>
> On Tue, Feb 2, 2021 at 12:23 AM Victor Stinner  wrote:
> >
> >
> > > Add ``io.LOCALE_ENCODING = "locale"`` constant too. This constant can
> > > be used to avoid confusing ``LookupError: unknown encoding: locale``
> > > error when the code is run in old Python accidentally.
> >
> > I'm not sure that it is useful. I like a simple "locale" literal
> > string. If there is a constant is io, people may start to think that
> > it's specific and will add "import io" just to get the string
> > "locale".
> >
> > I don't think that we should care too much about the error message
> > rased by old Python versions.
> >
>
> This constant not only for replacing "locale" litera. As example code
> in the PEP, it can be used to test wheather TextIOWrapper supports
> `encoding="locale"` .
>
> `open(fn, encoding=getattr(io, "LOCALE_ENCODING", None))` works both
> for Python ~3.9 and Python 3.10~.
>

I changed my mind. Since there is no plan to change the default
encoding for now,
no need to encourage `encoding="locale"` soon.

Until users can drop Python 3.9 support, they can use EncodingWarning
only for finding missing `encoding="utf-8"` or `encoding="ascii"`.

I will remove the io.LOCALE_ENCODING.

-- 
Inada Naoki  
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4SRSQQXRLQSXG4RLZGXHFEFTTBVDKPWK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Larry Hastings]

On 2/5/21 4:25 PM, Stefano Borini wrote:

dicts and lists will keep working as before. They will not support
keyword arguments (probably ever, as there is no clear semantic for
them) and the current implementation simply throws an error if the
user tries to.



Is the plan to add PEP 637 support to type objects, so they allow 
constructing type hints using named parameters, as suggested in the PEP?



Thanks,


//arry/

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FW2NE352IFTVRJ3TJSURQAZOLVCGQGES/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Stefano Borini]

On Sat, 6 Feb 2021 at 08:56, Batuhan Taskaya  wrote:
>
> Lurking around the discussions I started to wonder whether this syntax
> actually worths the burden it introduces.

It has been discussed for weeks on py-ideas.

> As you have commented out
> earlier, there are no use cases in the built-in types, perhaps a
> research would be great regarding possible use cases of keyword
> arguments in and out of the stdlib.

Nor there is for the @ operator, but it is still relevant for external
libraries.

> Now looking at PEP 637, even with
> the theoretical examples given, it seems like we are introducing a
> redundant syntax that has no other value than just complicating the
> already complex subscript notation and becoming a bad alternative to
> function call syntax.

you can't do:

f(x, y=3) = 5

but you can do

a[x, y=3] = 5

pandas has relied on workarounds like iloc() to work around the lack
of an indexing operator with keyword arguments, and we need them
anyway for specifying types, now that the indexing operator is "abused
of notation" all the time for typing.

Of course the meaning of a[x, y=3] = 5 is up to the implementation of
a. We don't prescribe anything on that.

>
> On Tue, Feb 2, 2021 at 2:40 PM Stefano Borini  
> wrote:
> >
> > Hi all,
> >
> > I would like to request feedback by python-dev on the current
> > implementation of PEP 637 - Support for indexing with keyword
> > arguments.
> >
> > https://www.python.org/dev/peps/pep-0637/
> >
> > The PEP is ready for SC submission and it has a prototype
> > implementation ready, available here (note, not reviewed, but
> > apparently fully functional)
> >
> > https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
> >
> > (note: not sure if there's a preference for the link to be to the diff
> > or to the branch, let me know if you prefer I change the PEP link)
> >
> > Thank you for your help.
> >
> >
> > --
> > Kind regards,
> >
> > Stefano Borini
> > ___
> > Python-Dev mailing list -- python-dev@python.org
> > To unsubscribe send an email to python-dev-le...@python.org
> > https://mail.python.org/mailman3/lists/python-dev.python.org/
> > Message archived at 
> > https://mail.python.org/archives/list/python-dev@python.org/message/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> > Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Kind regards,

Stefano Borini
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MX7YSGRP25KZ2LXW3CCQDRVAEKQ3WLNM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What's up with assignment expression and tuples?

[Paul Sokolovsky]

Hello,

On Sat, 6 Feb 2021 10:46:54 +0200
Serhiy Storchaka  wrote:

> 05.02.21 09:51, Paul Sokolovsky пише:
> > a0 = 0
> > b0 = 10
> > while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> > a2 = a1 + 1
> > b2 = b1 + 1  
> 
> Such code quickly becomes unreadable. Especially if in real code
> function has additional arguments and names are longer that 2-3
> characters.

But at least it fully corresponds to the original statements and control
flow of the program, that's the point!

> The following code is not much larger but more clear and extensible:
> 
> a0 = 0
> b0 = 10
> while True:
> a1, b1 := phi([a0, a2], [b0, b2]))
> if b1 >= 5:
> break
> a2 = a1 + 1
> b2 = b1 + 1

As I mentioned in other replies, that's what I've been doing. But that
does *NOT* correspond to the original program, or SSA conversion of it.
Instead, it's SSA + random munging. And when debugging SSA, you may
argue what's worse: to look at 3-stories phi's, or to look at the code
structure which doesn't correspond to the input code.


But that's not the point. I now in https://bugs.python.org/issue43143
gave more down to earth example:

For as long as you agree that following is acceptable:

func(a := val)

, then I'd say it really doesn't make much sense to argue that
following should not be acceptable:

min((b, a) := (a, b))



-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GBEIWEZGULUXJMSNILMNUF2WGOZQA46N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What's up with assignment expression and tuples?

[Paul Sokolovsky]

Hello,

On Sat, 06 Feb 2021 12:35:09 +1300
Greg Ewing  wrote:

> On 5/02/21 8:51 pm, Paul Sokolovsky wrote:
> > a = 0
> > while a < 5:
> >  a += 1
> > 
> > 
> > becomes:
> > 
> > 
> > a0 = 0
> > while (a1 := phi(a0, a2)) < 5:
> >  a2 = a1 + 1  
> 
> SSA seems to be something intended for compilers to use as an
> intermediate representation, not something to actually write
> code in. So I'm puzzled as to why you would want to do this.

Let's summarize what I've written so far:

1. I draw attention to the case that "=" can do parallel assignments,
while ":=".

If I would stop here, there would be immediate questions: "But
where/how you would use that?". So I at once presented:

2. A usecase, and even not a manual once-off usecase, but a usecase
which would affect every "while", again, and again.


Now you definitely can question *the usecase*, but please keep in mind
that my point was to show a gap in walrus functionality, and just show
an example for that.

But back to the specific SSA usecase:

1. Before compilers can "use it as an intermediate representation",
humans should code up those compilers. For that, they would need to
learn how SSA looks and play with it. And I for example was very excited
at the perspective that Python is *the* language which would allow to
express pure SSA form on the high-level language level (without
additional patchings, not related to SSA per se).
2. Even after compilers produce SSA as IR, humans still need to have
insight into it and verify it. Again, ability to do *just SSA* and not
"munge code and do SSA" is a benefit.

Note that "but how that will work on a millions lines of generated
code" is not infrequent question when discussing various Python
proposals, so please don't dismiss the SSA case just because it's
supposed to be "auto-generated IR". It's still need to be legible and
debuggable for humans.

> Also, what definition do you have in mind for phi? It doesn't
> seem to be something you can implement as a real function.

With the above notes, I guess discussing the SSA encoding case in more
detail specifically on python-dev doesn't make much sense. But you're
absolutely right, I simplified snippets for the presentation here. Real
"executable SSA" code requires more arguments to phi, and is available
in this repo:
https://github.com/pfalcon/python-ssa/blob/master/example_while1_ssa.py

(As you can see, I exactly was doing "conversion to the infinite loop"
transformation, as also suggested by Terry Reedy. But I'd like to use
the SSA usecase to try to address accidental gap in the walrus operator
functionality, that's the point).

> -- 
> Greg

[]

-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W5WNAAPP3ZGUWBAIXLUBBJN6NMQ7TPWL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Batuhan Taskaya]

Lurking around the discussions I started to wonder whether this syntax
actually worths the burden it introduces. As you have commented out
earlier, there are no use cases in the built-in types, perhaps a
research would be great regarding possible use cases of keyword
arguments in and out of the stdlib. Here is an example:
https://www.python.org/dev/peps/pep-0572/#examples-from-the-python-standard-library
that was done for PEP 572, which actually helped me a lot to
understand/comprehend the proposal.  Now looking at PEP 637, even with
the theoretical examples given, it seems like we are introducing a
redundant syntax that has no other value than just complicating the
already complex subscript notation and becoming a bad alternative to
function call syntax.

On Tue, Feb 2, 2021 at 2:40 PM Stefano Borini  wrote:
>
> Hi all,
>
> I would like to request feedback by python-dev on the current
> implementation of PEP 637 - Support for indexing with keyword
> arguments.
>
> https://www.python.org/dev/peps/pep-0637/
>
> The PEP is ready for SC submission and it has a prototype
> implementation ready, available here (note, not reviewed, but
> apparently fully functional)
>
> https://github.com/python/cpython/compare/master...stefanoborini:PEP-637-implementation-attempt-2
>
> (note: not sure if there's a preference for the link to be to the diff
> or to the branch, let me know if you prefer I change the PEP link)
>
> Thank you for your help.
>
>
> --
> Kind regards,
>
> Stefano Borini
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/E3AMOIB3GKYAGN6IVSLEEKVP4VUEC2V3/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MO57TTSZGEBXAG2RMHEGLRO4Z72Z2GZC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: What's up with assignment expression and tuples?

[Serhiy Storchaka]

05.02.21 09:51, Paul Sokolovsky пише:
> a0 = 0
> b0 = 10
> while ((a1, b1) := phi([a0, a2], [b0, b2]))[0] < 5:
> a2 = a1 + 1
> b2 = b1 + 1

Such code quickly becomes unreadable. Especially if in real code
function has additional arguments and names are longer that 2-3 characters.

The following code is not much larger but more clear and extensible:

a0 = 0
b0 = 10
while True:
a1, b1 := phi([a0, a2], [b0, b2]))
if b1 >= 5:
break
a2 = a1 + 1
b2 = b1 + 1
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6YILI7IW3HYPMZSPH3DJYWMNHJKZ2CXN/
Code of Conduct: http://python.org/psf/codeofconduct/