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
<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/
<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
<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
<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
<mailto:python-dev@python.org>
> To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
> https://mail.python.org/mailman3/lists/python-dev.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/
<https://mail.python.org/archives/list/python-dev@python.org/message/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/>
> Code of Conduct: http://python.org/psf/codeofconduct/
<http://python.org/psf/codeofconduct/>
--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto:python-dev-le...@python.org>
https://mail.python.org/mailman3/lists/python-dev.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/
<https://mail.python.org/archives/list/python-dev@python.org/message/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/>
Code of Conduct: http://python.org/psf/codeofconduct/
<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/42EAR6ECHWE5OG25QHHP56XOH7IFWPAA/
Code of Conduct: http://python.org/psf/codeofconduct/
