[Python-Dev] Re: The semantics of pattern matching for Python
On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon wrote: > > > On Thu, Nov 19, 2020 at 5:16 AM Steve Holden wrote: > >> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset >> wrote: >> >>> [sorry for the duplicate, meant to reply-all] >>> >>> Thank you for this approach, I find it really helpful to put the >>> conversation in these terms (semantics and guiding principles). >>> >>> It does help to rationalise discussion ;-) >> >>> [...] >>> 4. "Objects should be able determine which patterns they match." >>> This is something that you and I, and most of the authors of 622 agree >>> on. What we found out when discussing this is that we didn't have clear >>> what and how to open that customization. Some customization options added a >>> lot of complexity at the cost of performance, some others were very simple >>> but it wasn't clear that they would be actually useful, or extensible in >>> the future. This has a lot to do with this being a somewhat new paradigm in >>> Python, and our lack of knowledge on what the user community may do with it >>> beyond what we imagined. So the decision was "pattern matching as it is >>> presented without extensibility is useful, let's get this in, and once we >>> see how it is used in the wild we'll understand better what kind of >>> extensibility is valuable". For a crude analogy, imagine trying to get the >>> descriptor protocol right when the basic python object model was being >>> implemented. These things happened as different times as the use of the >>> language evolved, and my opinion is that customization of the match >>> protocol must follow a similar path. >>> >>> >> I haven't so far understood whether the change proposed is intended to >> start out in __future__. Given the preliminary nature of this development, >> it would seem wise to retain the option to withdraw it or modify it >> radically before production code depends on it. >> > > The current proposal is not for it to be put behind a __future__ statement > as it doesn't conflict with or break any pre-existing source code. > Ok, thanks for the clarification. 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." The discussion to date suggests that such a breathing space would be useful. ___ 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/TUO5S5UZJ3SLNCM2DNCEJ5KTGYNDCAFD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Nick Coghlan doesn't want to ever be having conversations about why "case True:" doesn't behave the same way as "case some.attr.referring.to.true:". Guido thinks that it strange enough that you won't see it. I agree that it is odd to define a complicated alias for True, but it isn't so odd to have a config variable that is boolean, or even one that is essentially always defined to the same value. I'm not sure this is worth bending over backwards for, but it does exist. -jJ ___ 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/YJUNHA72NIOYNVTSLNAMSCEEWHGAXB37/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Review patch fixing packed bitfields in ctypes struct/union
Hi folks, I know this is a high-volume list so sorry for being yet another voice screaming into your mailbox, but I do not know how else to handle this. A few months ago, I opened a pull request fixing packed bitfields in ctypes struct/union, which right now are being incorrectly created. The offsets and size are all wrong in some cases, fields which should be packed end up with padding between them. bpo: https://bugs.python.org/issue29753 PR: https://github.com/python/cpython/pull/19850 Since ctypes has no maintainer it has been very hard tracking down someone who is up to review this. So, if this issue sparks some interest to you, or you just want to help me out, please have a look :) Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part ___ 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/UG3ZYA2MODMBM7WDEC5FC4LWI4ZBDDB5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The semantics of pattern matching for Python
On Thu, Nov 19, 2020 at 5:16 AM Steve Holden wrote: > On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset > wrote: > >> [sorry for the duplicate, meant to reply-all] >> >> Thank you for this approach, I find it really helpful to put the >> conversation in these terms (semantics and guiding principles). >> >> It does help to rationalise discussion ;-) > >> [...] >> 4. "Objects should be able determine which patterns they match." >> This is something that you and I, and most of the authors of 622 agree >> on. What we found out when discussing this is that we didn't have clear >> what and how to open that customization. Some customization options added a >> lot of complexity at the cost of performance, some others were very simple >> but it wasn't clear that they would be actually useful, or extensible in >> the future. This has a lot to do with this being a somewhat new paradigm in >> Python, and our lack of knowledge on what the user community may do with it >> beyond what we imagined. So the decision was "pattern matching as it is >> presented without extensibility is useful, let's get this in, and once we >> see how it is used in the wild we'll understand better what kind of >> extensibility is valuable". For a crude analogy, imagine trying to get the >> descriptor protocol right when the basic python object model was being >> implemented. These things happened as different times as the use of the >> language evolved, and my opinion is that customization of the match >> protocol must follow a similar path. >> >> > I haven't so far understood whether the change proposed is intended to > start out in __future__. Given the preliminary nature of this development, > it would seem wise to retain the option to withdraw it or modify it > radically before production code depends on it. > The current proposal is not for it to be put behind a __future__ statement as it doesn't conflict with or break any pre-existing source code. ___ 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/BN4HQBX72L5GMVNEBGQDOSF6F3L4VRTS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: How Cpython repository has a pre-commit hook ? (as in PEP8)
On Thu, Nov 19, 2020 at 10:47 AM Nilo César Teixeira < nilo.teixe...@gmail.com> wrote: > Hello, > > I'm not a Python contributor but I have a question which (I believe) can > be answered here, so I've subscribed. > > The question is at stackoverflow: > https://stackoverflow.com/questions/64912716/are-pre-commit-hooks-clonable > > After some research the only thing similtar to a git pre-commit hook I > could find on the cpython repo was the patchcheck.py script on > github.com/python/cpython/tree/master/Tools/scripts (patchcheck.py), > which runs in Travis. > > Is this the pre-commit hook PEP8 talks about ? > Yep, that's it. -Brett > > Thanks for your help and attention. > > -- > *Nilo César Teixeira* > nilo.teixe...@gmail.com > (55) (11) 98571-5314 > ___ > 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/DKLD2VLHZ3F54WTKZ7JHKWBMOZ4N5TK7/ > 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/26IPP7DNNXT7V765QI2SVQTZU5B7ESKG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Questions about about the DLS 2020
A notorious example here of the "not many" is this proposal (i.e. not part of the language yet) for C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1371r0.pdf . I think it's an interesting example given that this is a very mature language, not originally designed with pattern matching in mind, where _ is normally an identifier. Best, D. On Tue, 17 Nov 2020 at 19:30, Brett Cannon wrote: > > > On Mon, Nov 16, 2020 at 9:03 AM Tobias Kohn wrote: > >> Hi Mark, >> >> Thank you for your interest and the questions. >> >> >> 1. This really comes down to how you look at it, or how you define >> pattern matching. The issue here is that the concept of pattern matching >> has grown into a large and somewhat diverse flock of interpretations and >> implementations (as a side note: interestingly enough, some of the only >> universally agreed-upon standards are to use `_` as a wildcard and not to >> mark names that capture/bind values---which are quite exactly the points >> most fiercely debatted here). >> > How many of those languages added pattern matching *later* and not at the > earliest stages of the language (if not from the beginning)? And for those > that added it later, how many of those didn't already have a convention > surrounding "_"? My suspicion is "not many" and "not many". > > -Brett > ___ > 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/VZHF7GJ637YULIU53MCCH26T4LWJ2YP6/ > 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/RBVIQ3WG4AFNJ7WKMNSXISR5X3LSJ2KO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] How Cpython repository has a pre-commit hook ? (as in PEP8)
Hello, I'm not a Python contributor but I have a question which (I believe) can be answered here, so I've subscribed. The question is at stackoverflow: https://stackoverflow.com/questions/64912716/are-pre-commit-hooks-clonable After some research the only thing similtar to a git pre-commit hook I could find on the cpython repo was the patchcheck.py script on github.com/python/cpython/tree/master/Tools/scripts (patchcheck.py), which runs in Travis. Is this the pre-commit hook PEP8 talks about ? Thanks for your help and attention. -- *Nilo César Teixeira* nilo.teixe...@gmail.com (55) (11) 98571-5314 ___ 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/DKLD2VLHZ3F54WTKZ7JHKWBMOZ4N5TK7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?
On Wed, Nov 18, 2020 at 7:45 PM Brett Cannon wrote: > > > On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing > wrote: > >> On 18/11/20 4:36 pm, Larry Hastings wrote: >> > >> > But, >> > the thinking went, you'd never want to examine the last value from a >> > list generator, so it was more convenient if it behaved as if it had >> its >> > own scope. >> >> List comprehensions used to leak, but apparently that was considered >> surprising by enough people that it was changed. >> >> Generator expressions are a bit different -- the only sane way to >> implement them was to make the body implicitly a separate function, >> and non-leaking behaviour naturally fell out of that. Making them >> leak would have taken extra work just to get something that nobody >> really had a good use case for. >> >> The desire to make list comprehensions and generator expressions >> behave consistently may have contributed to the decision to change >> list comprehensions to be non-leaking. >> > > It did if I remember correctly. > > For me, generator expressions are small functions like you say (see, > people did get the equivalent of multi-line lambdas, just in a very > specific format ), and all the comprehensions are just passing a > generator expression to the appropriate constructor, e.g. list(), set(), > and dict(). In that regard the scoping is consistent to me. > > -Brett > > If match were to create a scope, would making names in that scope nonlocal by default work? (Obvs we'd then need a local declaration, but given global's long-standing presence in the language and the more recent addition of nonlocal it seems like a fairly natural extension). ___ 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/BL5BGPFOJ25FVPC7KI4QPEEHUIR5L2RC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The semantics of pattern matching for Python
On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset wrote: > [sorry for the duplicate, meant to reply-all] > > Thank you for this approach, I find it really helpful to put the > conversation in these terms (semantics and guiding principles). > > It does help to rationalise discussion ;-) > [...] > 4. "Objects should be able determine which patterns they match." > This is something that you and I, and most of the authors of 622 agree on. > What we found out when discussing this is that we didn't have clear what > and how to open that customization. Some customization options added a lot > of complexity at the cost of performance, some others were very simple but > it wasn't clear that they would be actually useful, or extensible in the > future. This has a lot to do with this being a somewhat new paradigm in > Python, and our lack of knowledge on what the user community may do with it > beyond what we imagined. So the decision was "pattern matching as it is > presented without extensibility is useful, let's get this in, and once we > see how it is used in the wild we'll understand better what kind of > extensibility is valuable". For a crude analogy, imagine trying to get the > descriptor protocol right when the basic python object model was being > implemented. These things happened as different times as the use of the > language evolved, and my opinion is that customization of the match > protocol must follow a similar path. > > I haven't so far understood whether the change proposed is intended to start out in __future__. Given the preliminary nature of this development, it would seem wise to retain the option to withdraw it or modify it radically before production code depends on it. ___ 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/EBFOBAFOJPMKDFEQGT7ZN46R6QVM5UH3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
.. Also will matching ever extend into the Typing universe? In what way do you have in mind? With protocol support baked into PEP 634 that already ties into type hints. -Brett . thanks for the answers; the only one missing is whether there is an actual bestiary of examples, but I guess the PEPs will have to do for now. It's unlikely I will need any of this for a while so examples will appear over time. -- Robin Becker ___ 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/6JNN4AEI6DJYNUQM7MJADZDII7KXEJPX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Yet another idea for pattern matching syntax
I'm sorry, I've been skipping around the discussion a bit, but I'm fairly certain this suggestion hasn't been proposed yet. It's perhaps a bit too different from what has been proposed thus far but maybe that's exactly what's needed to convince the minds, since as far as I see it most of the parties who have an opinion on marking either assignments or lookups would at this point have changed their mind, if they were going to at all. What about declaring the identifiers that are going to be lookups in advance? Something like: match obj with some_var, something: case x, some_var: # here x binds, but some_var is a lookup I'm just throwing it out there because it occurred to me that this may solve the aesthetic issues while being clear on what identifier has what role. I'm sorry if this ends up just being more noise. ___ 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/QPZYIHDRIBTLEFWFGE3P7D5Y5EUU467Z/ Code of Conduct: http://python.org/psf/codeofconduct/
