[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Re: symbol for lookup Whatever happened to the proposal of using . as prefix? If memory serves, the main objection was about it being hard to see, but is it really? We use fixed width fonts for a reason, and there are other places a dot is quite critical (has any php programmer ever mistaken a .= for a = ?) without it's size ever causing issues. I think . is visible enough while being aesthetically inoffensive. Am i missing some problem or important past objection to 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/CQH465FPZP3IIN2TNAZRXQKUG5XYCANI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
Hello,
On Tue, 3 Nov 2020 10:30:22 +0100
Federico Salerno wrote:
> Re: symbol for lookup
>
> Whatever happened to the proposal of using . as prefix?
I guess, the same that happened with the proposals to use "+" as a
prefix, or proposals to change sides and use
"->"
(https://mail.python.org/archives/list/python-dev@python.org/thread/F22RLCDGKVMIBQKIJZAQYV3YCD45R2IQ/)
or ">" to mark variables to be bound.
>
> If memory serves, the main objection was about it being hard to see,
> but is it really? We use fixed width fonts for a reason, and there
> are other places a dot is quite critical (has any php programmer ever
> mistaken a .= for a = ?) without it's size ever causing issues.
>
> I think . is visible enough while being aesthetically inoffensive. Am
> i missing some problem or important past objection to it?
It's logically rather offensive. Dot is "structural sub-element"
operator.
Given things like:
from .foo import bar
a.b = 1
something like:
sth = "currently, I'm going to match by this value"
match foo:
case .sth:
print("This looks really weird!")
looks really weird.
--
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/4NHQGHBMIOOTHPSC4H22K4UWNUCW34XN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On Mon, Nov 02, 2020 at 03:31:44PM +0100, Thomas Wouters wrote:
> On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano
> wrote:
>
> >
> > I really don't get why so many people are hung up over this minuscule
> > issue of giving `_` special meaning inside match statements. IMO,
> > consistency with other languages' pattern matching is more useful than
> > the ability to capture using `_` as a variable name.
> >
>
> Allow me to explain, then: structured pattern matching is (even by
> admission of PEPs 634-363) an extension of iterable unpacking. The use of
> '_' as a wildcard pattern is a sharp break in that extension. In the
> structured pattern matching proposal, '_' is special syntax (and not in any
> way less so than '?') but *only* in cases in match statements, not in
> iterable unpacking. It *already* isn't consistent with '_' in other
> languages, and we can't fix that without breaking uses of _ for gettext,
> not to mention other situations existing code uses '_' as something other
> than an assign-only variable.
Right. This is a small inconsistency in the meaning of `_` between match
statements and other statements:
1. In a `case` statement (but not the block following the case line?),
`_` is a soft keyword with special meaning as a wildcard match.
2. Elsewhere, `_` is an ordinary name but special by convention.
We've had soft keywords before, like `as`, `async` and `await`, and the
world didn't end. The intention is to have them again in the future:
https://docs.python.org/3/library/keyword.html#keyword.issoftkeyword
Is it your intention to argue against all soft keywords, or just this
one?
> Using '_' in structured pattern matching means any use of '_' becomes an
> extra burden -- you have to know whether it's a name or not based on the
> surrounding context.
We've had this burden ever since Python introduced strings:
x = a + _ # It's a name.
x = a + '_' # It's a string.
And f-strings have added to that burden:
x = a + f'_{_}' # It's both a string and a name!
I don't think this is a heavy burden, and I don't fear this will be a
heavy burden either:
case _: # It's a wildcard pattern.
if _: # It's a name.
If I can cope with strings, with our without an f-prefix, I can cope
with underscore being context-dependent.
I agree that your statement is objectively true:
> The use of something else, like '?', leaves existing uses of '_'
> unambiguous, and allows structured pattern matching and iterable
> unpacking to be thought of the same.
but your argument still doesn't convince me. Using `?` would solve that
problem, but I don't think that's a problem that needs solving, and
furthermore it would introduce other problems in its place:
- `?` as a wildcard token is ugly (that's a personal, subjective
judgement);
- it's confusable with it's use in regexes (things that are different
should not look the same);
- and it clashes with the wildcard used in most(?) other languages with
pattern matching.
I have not done a full review, but I believe that `_` is a wildcard
pattern in Clojure, Kotlin, Haskell, Scala, Ocaml, F# and Rust, among
others.
We have no obligation to make Python look like other languages, but by
the same token we need not be different just for the sake of being
different. There's value in picking the same syntax, or at least similar
syntax, as other languages.
I expect to spend a long time learning how to read pattern matches
before I am as fluent with them as I am with other Python code, but the
wildcard pattern is probably one of the simplest parts to grasp. And the
beauty is that I can look at (say) Haskell pattern matching code, and
even if I can recognise nothing else, I can recognise the underscore and
the `|` used for alternatives, and that gives me a toe-hold to start
deciphering what I am reading.
So while I acknowledge the issues you mention, I just don't think they
are important. To me, the benefit of using underscore outweighs the
negatives.
--
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/7MSBGM7HGS324V4I3FCRYIW3FDH6GZ25/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On 11/3/20 1:30 AM, Federico Salerno wrote: Re: symbol for lookup Whatever happened to the proposal of using . as prefix? I think . is visible enough while being aesthetically inoffensive. Am i missing some problem or important past objection to it? Many people think . is not visible enough, myself included. -- ~Ethan~ ___ 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/47MX5RW2SBKOQSMEWIGWHTH4GRL6ATJG/ Code of Conduct: http://python.org/psf/codeofconduct/
[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 642: Constraint Pattern Syntax for Structural Pattern Matching
On 11/2/20 2:01 PM, Brandt Bucher wrote: Glenn Linderman wrote: So what _is_ the syntax for "a tuple of two equal values" ? If you’re asking about PEP 634: ``` case x, y if x == y: ``` Which is much clearer, in my opinion. Yeah, I've come 'round to this opinion as well. Let's get basic pattern matching in (by which I mean PEPs 634-636) and we can add bells and whistles later if there is need/demand for it. -- ~Ethan~ ___ 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/FBEFPYIVBYXT7XZGHMKN5O54B3CD3OPJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] [RELEASE] Python 3.10.0a2 available for testing
The engines of the secret release manager machine have finished producing a new pre-release. Go get it here: https://www.python.org/downloads/release/python-3100a2/ *Major new features of the 3.10 series, compared to 3.9* Python 3.10 is still in development. This releasee, 3.10.0a2 is the second of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2021-05-03) and, if necessary, may be modified or deleted up until the release candidate phase (2021-10-04). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.10 are still being planned and written. Among the new major new features and changes so far: PEP 623 -- Remove wstr from Unicode PEP 604 -- Allow writing union types as X | Y PEP 612 -- Parameter Specification Variables PEP 626 -- Precise line numbers for debugging and other tools. (Hey, fellow core developer, if a feature you find important is missing from this list, let Pablo know.) The next pre-release of Python 3.10 will be 3.10.0a3, currently scheduled for 2020-12-07. *And now for something completely different * The cardinality (the number of elements) of infinite sets can be one of the most surprising results of set theory. For example, there are the same amount of even natural numbers than natural numbers (which can be even or odd). There is also the same amount of rational numbers than natural numbers. But on the other hand, there are more real numbers between 0 and 1 than natural numbers! All these sets have infinite cardinality but turn out that some of these infinities are bigger than others. These infinite cardinalities normally are represented using aleph numbers. Infinite sets are strange beasts indeed. Regards from cold London, Pablo Galindo Salgado ___ 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/EYPALIF2V25SI4LBH5THTY2IM4VWDGXJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching
On 4/11/20 4:36 am, Paul Svensson wrote: On Tue, 3 Nov 2020, Greg Ewing wrote: 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. If "_" is a non-binding wildcard, linters will have to allow "case _, _" otherwise it might as well not be there. And then if it is later changed to be binding, "case _, _" will either become invalid or start forcing the two occurrences to be equal, depending on which change is made, thus breaking existing code. The only way I can see to keep our future options open in this area is not to have a wildcard at all, and make people use a different throwaway name for each don't-care position in a pattern. -- 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/RVTWRZ7NM2OWLCXFXJLNYA66GKXYHADN/ Code of Conduct: http://python.org/psf/codeofconduct/
