[Python-Dev] Re: The semantics of pattern matching for Python

[Terry Reedy]

Mark, did you get the response I sent to hotpy.org 4 days ago?  Is that 
a real address?  I ask because the typos I reported are still there and 
trying to visit hotpy.org fails.


--
Terry Jan Reedy
___
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/TX7W5TVIJT5BAMP3ZEIS6QSOVJNHFDQA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Guido van Rossum]

On Wed, Nov 18, 2020 at 11:39 AM Brett Cannon  wrote:

> Now obviously "practicality beats purity" as well, but the argument "other
> languages do it this way" doesn't hold well for a language that doesn't use
> curly braces for scoping delineation. 
>

I see your smiley, and I believe I've addressed this point before, but I
feel I have to point out once again that Python's design *does* actually
try to follow other languages in many (most) ways, lest people think there
is something wrong with following other languages' example, or that they
get bonus points for being different.

This is not a case of "feature envy" (often seen when people propose a
feature that they like in another language without understanding Python).
Pattern matching fills a real need and the design is about as Pythonic as
it gets.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/GMAECRLY6NFXQ5Y5F4DU7W3ZLK4CBPEA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Tobias Kohn]

 Hi Brett,

Thanks for your replies.

_> But you can write `123 .bit_length()`.  That's a parser limitation  
more than human understanding._


Touché.  I took this ambiguity of the dot so much for granted that I  
would not have thought of trying that.


_> Yep, but PEP 634 not only changes the convention, it special-cases  
"_" to be different in how it can be used anywhere else in Python.  
[...]_


I feel this is a bit of a misunderstanding, though: the underscore is  
really only special as a pattern.  Nothing in the PEP is changing  
anything outside of pattern matching.  I think it is quite important  
that such a complex feature is kind of separate from the rest of the  
language.


_> Welcome to worrying about every little detail in language design. _

Cheers ^_^.  To be fair, I learned a lot in this regard during the  
past months and I feel extremely lucky to have benefitted so much from  
working with these very smart and highly experienced team mates.  At  
the same token, we researched and approached the topic from so many  
different angles that I feel quite comfortable with the result and  
think this turned out to be a solid proposal.


_> [...]  Now obviously "practicality beats purity" as well, but the  
argument "other languages do it this way" doesn't hold well for a  
language that doesn't use curly braces for scoping delineation. _


I completely get that I fully agree with the intent of it.  We  
obviously have to concentrate much more on OCaml, Pascal, and Basic,  
which do not use curly braces for scoping delineation, either ;-)  
;-P.  Honestly, though, I guess there is a certain grey area here.  I  
am thinking, for instance, of things like a for-loop, which indicates  
iteration in about every language known(*), although there is research  
indicating that the keyword ``for`` itself is a rather bad choice.  At  
some point, it just becomes so much a standard that it transcendents  
into some kind of "meta-language".  I would argue that in this case,  
the burden of proof kind of reverses: you then need a very good  
argument why /_not_/ to stick to a universal standard.  And somehow,  
"Python only sticks superficially and by convention to the standard  
but we want to be able to break the rules even in this case whenever  
we fancy" strikes me as particularly convincing... :)


_> My question about adding pattern matching later was more to comment  
on the fact that the languages that use "_" for a wildcard pattern did  
it from early on, not later on; it had nothing to do with the proposal  
proposing pattern matching late in Python's history._


Hmm, yes I understand.  Still, it is probably hard to make a solid  
argument either way, because only few languages really added pattern  
matching later, with most of them being statically typed, functional,  
and so on.  So, there is not really much to go for I guess.  It is  
probably Python's burden now to embark on adventures to seek out new  
worlds, new possibilities and boldly go where no snake has gone  
before... :)


Kind regards,
Tobias

(*)  And yes, I am fully aware of assembly, purely functional  
languages, brainf*, etc.


Quoting Brett Cannon :


 

   On Tue, Nov 17, 2020 at 1:16 PM Tobias Kohn  
 wrote:



_Hi Brett,

Without having really looked at the history of all the languages we  
mention in the PEPs, I have a hunch that most of them had pattern  
matching from quite the beginning or an early stage on, indeed.   
That being said, I think the question itself does not really make  
much sense, though.  Programming languages are rarely if ever just  
invented out of the blue these days, but evolve from other  
languages that have gone before them.  So, sure C++ and Objective-C  
both had objects and classes from the very beginning on, but if we  
take into consideration that they strongly build on C, we could  
argue just as well that OOP was a later addition to C.  It really  
depends on your point of view.


But since we are talking about different languages here, there is  
one example I could bring up.  In C#, the underscore is a perfectly  
legal variable name.  And yet, it is also used as a 'discard' [1]  
in newer versions.  Moreover, F#, which certainly uses the  
underscore as a wildcard, runs on the same platform as C# and thus  
has to deal with this, too.  Somehow, Microsoft and its developers  
seem able to cope with it.


If I may widen the topic here a bit and seize the opportunity to go  
beyond just answering your email: I must admit that I find this  
entire discussion about the wildcard pattern rather mind-boggling.   
We seem all to accept the reality that ``match`` and ``case`` are  
context-sensitive keywords (i.e. they are both keywords and legal  
names)_


 
_Yes, because that's new syntax that's unambiguously new even if  
you have been programming in Python for decades._

_ _

_and that you cannot write ``123.bit_length()`` because the dot has  
several different 

[Python-Dev] Re: The semantics of pattern matching for Python

[Tobias Kohn]

 Hi Daniel and Mark,

Sorry for being slightly late to the party, but please let me add a  
few remarks of my own to the discussion here.


1. MUST HAVE PRECISELY DEFINED SEMANTICS

Yes, there are some aspects that we left open intentionally.  Most  
prominently the question of how often the pattern matching engine will  
check whether the subject is an instance of a particular class.  Take  
the following trivial example::


  match some_data:
  case Pair(12, 34):
  ...
  case Triple(12, 34, z):
  ...
  case Pair(12, y):
  ...
  case Pair(x, y):
  ...

In a perfect world, the compiler discovers that it must check whether  
``some_data`` is an instance of ``Pair`` exactly once and not three  
times.  This, of course, plays right into Mark's second point on  
efficiency and seems obvious enough.  Yet, as soon as we are  
considering nested patterns, it turns much less obvious whether the  
compiler is supposed to cache repeated isinstance-checks.  Can we  
really expect that the compiler must discover that in both case  
clauses the first element is checked against the same class?  Or would  
it make more sense to simply expect the compiler to potentially  
perform this ``Num`` instance check twice::


  match some_data:
  case [ Num(), 12 ]:
  ...
  case [ Num(), y, *z ]:
  ...

It is easy to think of cases where we accidentally end up calling an  
isinstance check more than once because the compiler could not prove  
that they are equal.  Still, whenever possible we want to give the  
compiler the freedom to optimise the pattern matching statement by  
caching.


In a static language, all of this would not be an issue at all, of  
course.  In Python, however, we end up being caught between its  
dynamic features and the desire to make pattern matching reasonably  
efficient.  So, we ended up leaving the question open as how often the  
pattern matching engine is allowed or supposed to check instances.   
Naturally, if you go and write some isinstance-check on a class with  
side-effects, you can break it.


2. USERS SHOULD NOT HAVE TO PAY AN UNNECESSARY PERFORMANCE PENALTY TO  
USE PATTERN MATCHING


To quote Mark [1] here:

/> Users should not have to pay an unnecessary performance penalty to  
use pattern matching./


Alright, what does this even mean?  What is an unnecessary performance  
penalty?  How should that be measured or compared?


Pattern matching is not just fancy syntax for an if-elif-statement,  
but a new way of writing and expressing structure.  There is currently  
nothing in Python that fully compares to pattern matching (which is  
obviously why we propose to add in the first place).  So, do you want  
to compare a pattern matching structure to an if-elif-chain or rather  
an implementation using reflection and/or the visitor pattern?  When  
implementing pattern matching, would we be allowed to trade off a  
little speed handling the first pattern for moving faster to patterns  
further down?


Do our PEPs really read to you like we went out of our ways to make it  
slow or inefficient?  Sure, we said let's start with an implementation  
that is correct and worry about optimising it later.  But I thought  
this is 101 of software engineering, anyway, and am thus rather  
surprised to find this item on the list.


3. FAILED MATCHES SHOULD NOT POLLUTE THE ENCLOSING NAMESPACE

 This is a slightly wider issue that has obviously sparked an entire  
discussion on this mailing list on scopes.


If there is a good solution that only assigns variables once the  
entire pattern matched, I would be very happy with that.  However, I  
think that variables should be assigned in full before evaluating any  
guards---even at the risk of the guard failing and variables being  
assigned that are not used later on.  Anything else would obviously  
introduce a mini-scope and lead to shadowing, which hardly improves  
anything with respect to legibility.


4. OBJECTS SHOULD BE ABLE DETERMINE WHICH PATTERNS THEY MATCH

Short version: no!

Class patterns are an extension of instance checks.  Leaving out the  
meta-classes at this point, it is basically the class that is  
responsible for determining if an object is an instance of it.   
Pattern matching follows the same logic, whereas Mark suggests to put  
that upside-down.  Since you certainly do not want to define the  
machinery in each instance, you end up delegating the entire thing to  
the class, anyway.


I find this suggestion also somewhat strange in light of the history  
of our PEPs.  We started with a more complex protocol that would allow  
for customised patterns, which was then ditched because it was felt as  
being too complicated.  There is still a possibility to add it later  
on, of course.  But here we are with Mark proposing to introduce a  
complex protocol again.  It would obviously also mean that we could  
not rely as much on Python's existing 

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-11-13 - 2020-11-20)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7593 (-35)
  closed 46562 (+103)
  total  54155 (+68)

Open issues with patches: 3061 


Issues opened (52)
==

#25710: zipimport is not PEP 3147 or PEP 488 compliant
https://bugs.python.org/issue25710  reopened by brett.cannon

#41561: test_ssl fails in Ubuntu 20.04: test_min_max_version_mismatch
https://bugs.python.org/issue41561  reopened by christian.heimes

#42296: Infinite loop uninterruptable on Windows in 3.10
https://bugs.python.org/issue42296  reopened by eryksun

#42352: A string representation of slice objects with colon syntax
https://bugs.python.org/issue42352  opened by rossbar

#42353: Proposal: re.prefixmatch method (alias for re.match)
https://bugs.python.org/issue42353  opened by gregory.p.smith

#42355: symtable: get_namespace doesn't check whether if there are mul
https://bugs.python.org/issue42355  opened by BTaskaya

#42356: Dict inline manipulations
https://bugs.python.org/issue42356  opened by tomek.hlawiczka

#42357: Wrong Availability for signal.SIGCHLD
https://bugs.python.org/issue42357  opened by myzhang1029

#42358: Python 3.9.0 unable to detect ax_cv_c_float_words_bigendian va
https://bugs.python.org/issue42358  opened by blastwave

#42360: In the namedtuple documentation, mention that typename should 
https://bugs.python.org/issue42360  opened by alegonz

#42361: Use Tcl/Tk 8.6.10 in build-installer.py when building on recen
https://bugs.python.org/issue42361  opened by ronaldoussoren

#42362: Switch to clang as default compiler in build-installer.py
https://bugs.python.org/issue42362  opened by ronaldoussoren

#42363: I think it will be better to output self._state for debugging
https://bugs.python.org/issue42363  opened by jimlinntu

#42367: Restore os.makedirs ability to apply mode to all directories c
https://bugs.python.org/issue42367  opened by gregory.p.smith

#42369: Reading ZipFile not thread-safe
https://bugs.python.org/issue42369  opened by Thomas

#42370: test_ttk_guionly: test_to() fails on the GitHub Ubuntu job
https://bugs.python.org/issue42370  opened by vstinner

#42371: datetime.fromisoformat(): Omitted colon in timezone suffix rai
https://bugs.python.org/issue42371  opened by Bengt.Lüers

#42373: PEP 626 does not specify behavior of tracing for keywords.
https://bugs.python.org/issue42373  opened by Mark.Shannon

#42375: subprocess DragonFlyBSD build update
https://bugs.python.org/issue42375  opened by devnexen

#42376: Add helpers to populate modules in C
https://bugs.python.org/issue42376  opened by christian.heimes

#42377: allow typing.cast with TYPE_CHECKING
https://bugs.python.org/issue42377  opened by dpinol

#42378: logging reopens file with same mode, possibly truncating
https://bugs.python.org/issue42378  opened by ecatmur2

#42380: Build windows binaries with MS VS2019 16.8+ / MSVC 19.28+
https://bugs.python.org/issue42380  opened by h-vetinari

#42382: No easy way to get the distribution which provided a importlib
https://bugs.python.org/issue42382  opened by s0undt3ch

#42383: Pdb does not correclty restart the target if it changes the cu
https://bugs.python.org/issue42383  opened by hexagonrecursion

#42384: Inconsistent sys.path between python and pdb
https://bugs.python.org/issue42384  opened by hexagonrecursion

#42385: Should enum.auto's behavior be adjusted for StrEnum to return 
https://bugs.python.org/issue42385  opened by Antony.Lee

#42386: Update icons for macOS 11
https://bugs.python.org/issue42386  opened by 17jiangz1

#42387: Pdb should restore the execution environment before reexecutin
https://bugs.python.org/issue42387  opened by hexagonrecursion

#42388: subprocess.check_output(['echo', 'test'], text=True, input=Non
https://bugs.python.org/issue42388  opened by ThiefMaster

#42389: test_multiprocessing: @requires_hashdigest() prevents test dis
https://bugs.python.org/issue42389  opened by christian.heimes

#42390: Other Python implementations may not expose the module name in
https://bugs.python.org/issue42390  opened by wmeehan

#42391: Clarify documentation of TestCase.assertIs
https://bugs.python.org/issue42391  opened by cool-RR

#42392: remove the 'loop' parameter from __init__ in all classes in as
https://bugs.python.org/issue42392  opened by yselivanov

#42393: Raise overflow errors iso. deprecation warnings in socket.hton
https://bugs.python.org/issue42393  opened by erlendaasland

#42395: aclosing was not added to __all__ in contextlib
https://bugs.python.org/issue42395  opened by tomgrin10

#42401: Plislit does not handle date timezone correctly
https://bugs.python.org/issue42401  opened by jcbertin

#42402: Termios module documentation is extremely lacking
https://bugs.python.org/issue42402  opened by dan.merillat

#42404: clinic: add option to pass module object to 

[Python-Dev] Re: Questions about about the DLS 2020

[Guido van Rossum]

But none of those limitations are there under our proposal. You can write
this if you want:

match =  1
match match:
case case: print(case, match)

And you can use _(“...”) anywhere in the case block and even in the guard.
Just not as a pattern, but you can’t use f(1) there either...


On Fri, Nov 20, 2020 at 09:44 Jim J. Jewett  wrote:

> Not being able to use a particular variable name (such as match or case)
> in the limited context of matching is only a minor wart.  Unfortunately, _
> for internationalization is already a well-established convention for
> something that you might well want to do within each separate case.  It
> isn't just that you can't call your variable match; it is that you can't do
> output without renaming what seems like a standard library function.
>
> Not insurmountable, but also not trivial.
> ___
> 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/PVETCKEWNZI5LCI7BSXKRIHYD77734MJ/
> 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/CWB2TFRY6OKANNG6FOX5AY7VG2DVHYS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Questions about about the DLS 2020

[Jim J. Jewett]

Not being able to use a particular variable name (such as match or case) in the 
limited context of matching is only a minor wart.  Unfortunately, _ for 
internationalization is already a well-established convention for something 
that you might well want to do within each separate case.  It isn't just that 
you can't call your variable match; it is that you can't do output without 
renaming what seems like a standard library function.

Not insurmountable, but also not trivial.
___
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/PVETCKEWNZI5LCI7BSXKRIHYD77734MJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Preconditions for accepting any pattern matching PEP

[Mark Shannon]

Hi,

I'd like to request that any pattern matching PEP and its implementation
meet certain standards before acceptance.

As one of the maintainers of the AST-to-bytecode part of the compiler 
and the bytecode interpreter, I don't want to be in the situation where 
we are forced to accept a sub-standard implementation because a PEP has 
been accepted and the PEP authors are unable, or unwilling, to produce 
an implementation that is of a sufficiently high standard.


Therefore, I would ask the steering committee to require the following 
as a minimum before formal acceptance of any pattern matching PEP.


1. The semantics must be well defined.
2. There should be no global side-effects in the bytecode.
3. Each bytecode should perform a single, reasonably limited, operation.
4. There should be a clear path, using known compiler optimization 
techniques to making it efficient, if it is not initially so.


1.

We want to be able to change the implementation.

The current (3.9+) compiler produces quite clean bytecode for 
"try-finally" and "with" statements.
Earlier implementations of the compiler were simplistic and required 
quite convoluted bytecodes in the interpreter.


We were able to make these improvements because the "try-finally" and 
"with" statements are well specified, so we could reason about changes 
to the implementation.
Should the old and new implementations have differed, it was possible to 
refer to the language documentation to determine which was correct.


Without well defined semantics, the first implementation of pattern 
matching becomes the de-facto semantics, with all of its corner cases. 
Reasoning about changes becomes almost impossible.


2.

The implementation of PEP 634 can import "abc.collections" mid bytecode. 
I don't look forward to the bug reports when the module can't be 
imported for some unrelated reason and pattern matching fails.


We recently added the `LOAD_ASSERTION_ERROR` bytecode to ensure that 
asserts work even after `del builtins.AssertionError`. We should 
maintain this level of robustness.


3.

This comes down to reasoning about whether the compiler is correct, and 
interpreter performance.


Admittedly, the current bytecodes don't always adhere to the above rule, 
but they mostly do and I don't want the situation to deteriorate.


The implementation of PEP 634 includes a number of bytecodes that 
implement their own mini-interpreters within. It is the job of the 
compiler, not the interpreter, to handle such control flow.


4.

If pattern matching is added to the language, and it becomes popular, we 
don't want it to be slow. Knowing that there exists an efficient 
implementation, and how to achieve it, is important. Ideally the initial 
implementation should be efficient, but knowing that it could be is 
sufficient for acceptance.



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/RUMVGTKTMSNDOT3LTWN4ZLVFN2F6E4YO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Matching syntax and semantics

[Eric Nieuwland]

Hi all,

Some days back Mark Shannon posted his view/proposal pattern matching on github.
While reading it I realised an intermediate step between matching and variable 
assignment might do away with part of the discussion.
I wrote it in an issue with the view/proposal 
(https://github.com/markshannon/pattern-matching/issues/1)

Thinking about it a bit longer, it really might be worth exploring the idea 
more, so let me repeat it here:
1. In a pattern the values to match are marked with a special symbol (‘$’, ‘!’ 
or ‘?’ seem candidates).
2. A matching case produces a tuple of matched values. The tuple may be nested 
to reflect the matched structure.
3. The tuple may be deconstructed according to the usual rules.


As an example:

example_value = Example("bar", Embedded(None, "foo"), 42, "baz")

match example_value:
case Example($, Embedded($, "foo"), 42, $) as t:
# t = ("bar”, (None, ), "baz”)
pass
case Example($, Embedded($, "foo"), 42, $) as pre, *rest:
# pre = "bar", rest = ((None, ), "baz”)
pass


alternatively:

match example_value:
case pre, *rest = t = Example($, Embedded($, "foo"), 42, $):
# pre = "bar", rest = ((None, ), "baz”)
# t = ("bar”, (None, ), "baz”)
pass


Just my $0.02


—eric
___
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/XSRGCA6L3GYKKHQHZYKMPOM3KTI72STC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Mark Shannon]

Hi Daniel,

On 20/11/2020 10:50 am, Daniel Moisset wrote:
Hello again Mark, I took some time looking in more detail at your 
proposal, and these are my thoughts. I'm writing with the assumption 
that this proposal describes some "internal" representation of match 
statements which is never exposed to the users (so I'd mostly steer away 
from lexical/syntactic preferences).


My first general thought is that this is a useful way to describe and 
discuss implementation, although I wouldn't wait on refinement of this 
to choose whether to accept/reject PEP 634 (or 642, or your favourite 
alternative), work can be done on parallel. It may be a good idea to 
wait for your proposal to be refined before landing a specific 
implementation into CPython (including how the chosen implementation, 
assuming it's accepted, desugars into your semantics).


Going into more details, here's a list of thoughts on more specific points:

 1. You mention a goal about "erroneous patterns" (which I'm still not
sure I agree on), and your proposal addresses that by forcing
classes to be explicit (via __atributes__ and __deconstruct__) about
what attributes are accepted as matches. This is against one design
principle that's not in your list but it was (at least implicitly)
in PEP622 and 634: "pattern matching must allow matching objects on
types not specifically designed for it"; this will allow to apply
this feature to classes that you can not modify (like instances
created by a 3rd party library ). That's why PEP634 relies on
getattr() ; that could be extended in the feature (providing some
override using attributes like yours) but that wouldn't be required
by default


Why force pattern matching onto library code that was not designed for 
pattern matching? It seems risky.


Fishing arbitrary attributes out of an object and assuming that the 
values returned by attribute lookup are equivalent to the internal 
structure breaks abstraction and data-hiding.


An object's API may consist of methods only. Pulling arbitrary 
attributes out of that object may have all sorts of unintended side-effects.


PEP 634 and the DLS paper assert that deconstruction, by accessing 
attributes of an object, is the opposite of construction.

This assertion seems false in OOP.

You might consider OOP as a hangover of the 1990s and that FP is the way 
forward, and you may well be right, but the vast majority of Python 
libraries have a distinctly OO flavor, and we need to respect that.


When we added the "with" statement, there was no attempt to force 
existing code to support it. We made the standard library support it, 
and let the community add support as and when it suited them.


We should do the same with pattern matching.


 2. We considered and discussed something similar to the __deconstruct__
approach (as an override for getattr()), and also noted is
potentially expensive, requiring to allocate an object and evaluate
*all* attributes, even if only one is required. That is against the
principle of " it should perform at least as well as an equivalent
sequence of if, elif statements."


The majority of cases will want more than one attribute, and evaluating 
all attributes at once may well be more efficient than doing so one at a 
time, especially for builtin classes.


I assure you that this is not going to be a performance bottleneck until 
the implementation is a lot slicker than the PEP 634 "reference 
implementation".



 3. You removed or patterns, and added multiple "case P" for each case
body. This easily covers cases where the multiple options are at top
level in the pattern, but if the or-pattern is in a subpattern you
have to duplicate much of the outer context. And this "duplication"
is actually exponential on the number of or patterns, so for
matching the pattern "[0|1, 0|1, 0|1, 'foo'|'bar'|'baz']" you need
to desugar this into 24 case clauses.


Why is this a problem? The compiler can handle millions of cases without 
it being a problem. The number of tests to distinguish N cases is 
log(N), so the number of tests remains the same.



 4. Something else about decomposing patterns into multiple case clauses
is that it makes it harder to express the constraint that all
alternatives must bind the same variable.


Why? It is a mechanical transformation.


 5. I found a bit confusing to read the multiple cases on top. It looks
like C switch statements, which fall-through by default, but in a
context where some case clauses do fall-through (if empty) and
others aren't (if they have a body, even if it's "pass"). I know
this is not user exposed syntax so it's not that important, but this
made the description harder to read for me.


You'll just have to let go of your C-based preconceptions ;)


 6. Given the previous points, added to not seeing the gains of not
putting the or patterns into the desugared version, I'd 

[Python-Dev] Re: The semantics of pattern matching for Python

[Steve Holden]

Fair enough.


On Fri, Nov 20, 2020 at 11:45 AM Thomas Wouters  wrote:

>
>
> On Fri, Nov 20, 2020 at 8:38 AM Steve Holden  wrote:
>
>> On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon  wrote:
>>
>> All I will say is just because we aren't *required* to implement it in
>> __future__ that doesn't mean we can't or shouldn't. Everything should be
>> done to underline the tentative nature of these developments, or we risk
>> the potential of functionality frozen because "we're already using it in
>> production."
>>
>
> On the other hand, __future__ imports have never been provisional, and it
> was never the *intent *of __future__ imports to be provisional. PEP 236,
> which introduced __future__ imports after a vigorous debate on backward
> compatibility, explicitly states "fully backward- compatible additions
> can-- and should --be introduced without a corresponding future_statement".
> I think it would be very surprising if a feature introduced under a future
> import turned out to go away rather than become the default.
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
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/OD7YGKBLJFFMXYFMYWQZIX7UPHZG5ZR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Thomas Wouters]

On Fri, Nov 20, 2020 at 8:38 AM Steve Holden  wrote:

> On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon  wrote:
>
> All I will say is just because we aren't *required* to implement it in
> __future__ that doesn't mean we can't or shouldn't. Everything should be
> done to underline the tentative nature of these developments, or we risk
> the potential of functionality frozen because "we're already using it in
> production."
>

On the other hand, __future__ imports have never been provisional, and it
was never the *intent *of __future__ imports to be provisional. PEP 236,
which introduced __future__ imports after a vigorous debate on backward
compatibility, explicitly states "fully backward- compatible additions
can-- and should --be introduced without a corresponding future_statement".
I think it would be very surprising if a feature introduced under a future
import turned out to go away rather than become the default.

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
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/D7HWCZR2VXU3QWBPSCOP5PMW4E2XFA7D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Daniel Moisset]

Hello again Mark, I took some time looking in more detail at your proposal,
and these are my thoughts. I'm writing with the assumption that this
proposal describes some "internal" representation of match statements which
is never exposed to the users (so I'd mostly steer away from
lexical/syntactic preferences).

My first general thought is that this is a useful way to describe and
discuss implementation, although I wouldn't wait on refinement of this to
choose whether to accept/reject PEP 634 (or 642, or your favourite
alternative), work can be done on parallel. It may be a good idea to wait
for your proposal to be refined before landing a specific implementation
into CPython (including how the chosen implementation, assuming it's
accepted, desugars into your semantics).

Going into more details, here's a list of thoughts on more specific points:


   1. You mention a goal about "erroneous patterns" (which I'm still not
   sure I agree on), and your proposal addresses that by forcing classes to be
   explicit (via __atributes__ and __deconstruct__) about what attributes are
   accepted as matches. This is against one design principle that's not in
   your list but it was (at least implicitly) in PEP622 and 634: "pattern
   matching must allow matching objects on types not specifically designed for
   it"; this will allow to apply this feature to classes that you can not
   modify (like instances created by a 3rd party library ). That's why PEP634
   relies on getattr() ; that could be extended in the feature (providing some
   override using attributes like yours) but that wouldn't be required by
   default
   2. We considered and discussed something similar to the __deconstruct__
   approach (as an override for getattr()), and also noted is potentially
   expensive, requiring to allocate an object and evaluate *all* attributes,
   even if only one is required. That is against the principle of " it should
   perform at least as well as an equivalent sequence of if, elif statements."
   3. You removed or patterns, and added multiple "case P" for each case
   body. This easily covers cases where the multiple options are at top level
   in the pattern, but if the or-pattern is in a subpattern you have to
   duplicate much of the outer context. And this "duplication" is actually
   exponential on the number of or patterns, so for matching the pattern
   "[0|1, 0|1, 0|1, 'foo'|'bar'|'baz']" you need to desugar this into 24 case
   clauses.
   4. Something else about decomposing patterns into multiple case clauses
   is that it makes it harder to express the constraint that all alternatives
   must bind the same variable.
   5. I found a bit confusing to read the multiple cases on top. It looks
   like C switch statements, which fall-through by default, but in a context
   where some case clauses do fall-through (if empty) and others aren't (if
   they have a body, even if it's "pass"). I know this is not user exposed
   syntax so it's not that important, but this made the description harder to
   read for me.
   6. Given the previous points, added to not seeing the gains of not
   putting the or patterns into the desugared version, I'd prefer it to be
   included in the desugaring.
   7. I think there's some surprising behaviour in the assignments being
   done after a successful match but before the guard is evaluated. In your
   proposal the guard has no access to the variables, so it has to be compiled
   differently (using $0, $1, ... rather than the actual names that appear in
   the expression). And if this guard calls a function which exposes those
   variables in any way (for example if the variable is in a closure) I think
   the behaviour may be unexpected /surprising; same if I stop a debugger
   inside that function and try to inspect the frame where the matching
   statement is.
   8. I like your implementation approach to capture on the stack and then
   assign. I was curious if you considered, rather than using a variable
   number of stack cells using a single object/dict to store those values. The
   compiler and the generated bytecode could end up being simpler, and you
   need less stack juggling and possibly no PEEK operation. a small list/array
   would suffice, but a dict may provide further debugging opportunities (and
   it's likely that a split table dict could make the representation quite
   compact). I know this is less performant but I'm also thinking of
   simplicity.
   9. I think your optimisation approaches are great, the spec was made lax
   expecting for people like you to come up with a proposal of this kind :) I
   don't think the first implementation of this should be required to
   optimize/implement things in a certain way, but if the spec is turned into
   implementation dependent and then fixed, it shouldn't break anything (it's
   like the change in dictionary order moving to "undefined/arbitrary" to
   "preserving insertion order") and can be done later one

Thanks 

[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union

[Simon Cross]

The PR already has a fair amount of good review and discussion. Me
doing a superficial review is not going to help get it merged.
___
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/B72DDTOXEZQ57GC2C2PWDOJ436IOLWR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union

[Terry Reedy]

On 11/20/2020 4:03 AM, Simon Cross wrote:


Thank you for this [cttpes] patch! > I can't help land it, but it looks sane to 
me.


If you have a github account, you can help by reviewing it.  Check the 
spelling, grammar, and clarity of comments, docstrings, and news item. 
Can the code be improved.  If you have a local cpython clone, make a 
branch from the PR and test it.  Does it really fix the issue?



--
Terry Jan Reedy
___
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/BTPRQXSISHLLA6KXGASQTL3XPVTHUEWU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Review patch fixing packed bitfields in ctypes struct/union

[Simon Cross]

Hello!

Thank you for this patch! I can't help land it, but it looks sane to me.

I fear you have discovered a fundamental truth about ctypes though --
it tries to mimic what C compilers do and this inevitably leads to
many discrepancies. E.g. if a C structure you're trying to use is
wrapped in an #ifdef, one has to then try to mimic that ifdef in
Python, which may be impossible or very fragile.

If you're encountering such issues, you might save yourself future
pain and bugs by switching to an alternative approach (cython, CFFI,
struct module -- it depends on what problem you're trying to solve).

Will hold thumbs that you find someone to review and merge the patch!

Yours sincerely,
Simon Cross
___
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/HGU2WTLRHTCIR6D5VLSV7A5I3MW3PI5L/
Code of Conduct: http://python.org/psf/codeofconduct/