[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On Tue, 3 Nov 2020, Greg Ewing wrote: On 3/11/20 11:01 am, Ethan Furman wrote: I believe supporting case x, x # look ma! no guard! is a possible future enhancement. In which case there will be a need for *some* kind of true "don't care" placeholder. If it's not "_" then it will have to be something else like "?". And we need to decide about it now, because once people start using "_" as a wildcard in patterns, it will be too late to go back. But will it, really ? It seems to me, that if we leave the "_" magic out, and leave "case x, x" to the linters, that leaves a clear path forward for whatever can be decided whenever it can be decided. /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/J4CWDENPN2BSMQQN2OQEAVYA4U7GA27E/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622: Structural Pattern Matching
On Thu, 25 Jun 2020, Richard Damon wrote: On 6/25/20 10:42 AM, Greg Ewing wrote: On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it were treated as an ordinary name, it would still have the effect of matching anything. Actually, you could make _ less special by still binding the value to it, just make it special in that you allow several values to be bound, and maybe just define that the result will be just one of the values, maybe even specify which if you want. We already allow (x, x) = (1, 2) So, why do we need to disallow binding several values to the same name ? Without the restriction, there's no need for _ to be special, and anyone using _ for something else, can use some other dummy for matching. /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/IWEBLCNUPONLTVXXENX4MU2JHX6LP2EZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Why does _ need to be special ?
On Wed, 8 Jul 2020, Rhodri James wrote: On 08/07/2020 11:05, Federico Salerno wrote: What I don't like is the use of _ as catch-all, which is different and not interdependent with its use as throwaway. Any name used as a pattern is a catch-all. The only difference between "case dummy:" and "case _:" is that "_" doesn't bind to the thing being matched, but "dummy" does bind to it. Does "_" really deserve that special treatment ? If you don't want to bind to it, you can just use some other dummy, same way you don't use "case print:" if you don want to bind that. /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/KGCQDEFXKOPKPXFF7F6LYZKYFCHGVW5X/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 622 and fitting the pieces together
Having followed this discussion for a while, I'm trying to put my finger on why I feal uneasy about it. The major features I see in this proposal are: * New syntax for trying multiple assignments until one matches. * Extending destructuring assignment to match constants in the LHS. * Adding syntax to tell constants from targets. * Extending destructuring assignment to match isinstance and properties. * Making _ a special variable that doesn't always gets assigned a value. I see the other features are only discussed as part of the first one. I think each feature has (some) value on its own, could be implemented without the others, so really should stand or fall on it's own merit. And there I found the root of my uneasiness - the supporting cast is stronger than the main actor. To me, that suggest we should change focus, to look at the usefulness of these extensions in themselves, relegating the match/case statement to syntactic sugar. /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/UG4IHD4O2X2STD2L3YAHZRI4YH7YLA5Z/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)
On Fri, 17 Jul 2020, Ethan Furman wrote: The problem with any kind of sigil/keyword is that it becomes line noise -- we would have to train ourselves to ignore them in order to see the structure and variables we are actually interested in. Once we become adept at ignoring them, we will again have difficulties when debugging as we won't easily see them. Besides which, the problem is solved: - namespace.var is a lookup - var is a store Regardless how hard this is being pushed, I beg to disagree. Matching is easy to think of as an extension of destructuring assignment, and could easily be that, if we just don't introduce incompatible rules. Everything currently allowed in an assignment is a store, so it follows that the markup for lookups must be something that is not currently allowed in an assignment. Besides literal constants, my preference is for ``` == x ```, with the obvious opening for future extension. /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/GASEWDEUNW7WNEDRD4JBF2HJ3AU26OJY/ Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-Dev] Octal literals
On Wed, 1 Feb 2006, Barry Warsaw wrote: > The proposal for something like 0xff, 0o664, and 0b1001001 seems like > the right direction, although 'o' for octal literal looks kind of funky. > Maybe 'c' for oCtal? (remember it's 'x' for heXadecimal). Shouldn't it be 0t644 then, and 0n1001001 for binary ? That would sidestep the issue of 'b' and 'c' being valid hexadecimal digits as well. Regarding negative numbers, I think they're a red herring. If there is any need for a new literal format, it would be to express ~0x0f, not -0x10. 1xf0 has been proposed before, but I think YAGNI. /Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
