[Python-Dev] Re: Heap types (PyType_FromSpec) must fully implement the GC protocol
On Sat, 9 Jan 2021 02:02:17 +0100 Victor Stinner wrote: > > It's an hard problem and I don't see any simple/obvious solution right > now, except of *workarounds* that I dislike. Maybe the only good > solution is to fix all heap types, one by one. Ok. Why are we adding heap types to the stdlib exactly? Is the goal to have exactly zero shared objects between subinterpreters? Regards Antoine. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/4LSSGCFUUTPCIZTT6NDRUCYWSZ7CZKA6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
Hello, On Sat, 9 Jan 2021 12:27:45 +1000 Nick Coghlan wrote: > On Sat, 9 Jan 2021, 7:07 am Joseph Martinot-Lagarde, > wrote: > > > Paul Sokolovsky wrote: > > > Hello, > > > On Tue, 5 Jan 2021 20:37:27 +1000 > > > Nick Coghlan [email protected] wrote: > > > > object(host=as host, port=as port}:", but that > > > > couldn't ever be > > > > I'd like to point out the weirdness of the "as" syntax when > > > > applied > > > to > > > positional arguments, e.g.: > > > case [as x, as y]: > > > case Cls(as x, as y): > > > That feels unnatural, and the fact behind that intuitive feeling > > > is that "as" never used like that in Python so far. Where it's > > > used now, there's explicit "what" is available before "as": > > > import org_name as alias_name > > > with expr as var: > > > So again, standalone "as" feels weird. > > > > It's a matter of taste, I like the compacity of the standalone as. > > It describe clearly the variable name, and the order matches the > > positional arguments so I don't find it surprising. If it's not the > > positional value, what else can it be ? What would be clearer by > > using an underscore, which itself corresponds to nothing ? > > The fact that it was never used like this it not an argument per se, > > because that's the point of new syntax... > > > It's also a pure syntactic shortcut, so anyone that really dislikes it > could favour the "__ as name" form. The extra leading "__" doesn't > convey any information that the leading "as" doesn't convey on its > own, but YMMV. > > The key difference relative to PEP 634 is that even when the code > author uses the shorthand form, *readers* will still get at least the > "as" keyword as a prompt, Ok, so let's summarize the alternatives: 1. PEP634, which says that "case Cls(a, b):", etc. is not worse than other languages. 2. PEP642, which says that taking existing "as" and using it (and it's also an English word with a specific meaning) with rather different meaning in pattern matching is ok. 3. Alternative proposal sounded on the list, which says that taking existing punctuational operator like ">" or "->" (and they're also graphemes depicturing arrows) and using them (still with rather different meaning) in pattern matching is ok. PEP642 never mentions 3rd alternative. And it actually starts its presentation with things like: > case {"host" as host, "port" as port}: There're 2 obvious problems with it: a) In Python, {} with things inside it, but no ":" inside it, is a set, set. b) Everywhere else in Python, thing on the left of "as" gets into thing on the right of "as", behold: import foo as bar # original module "foo" gets into "bar". with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c" Then based on the existing Python syntax, the meaning of '{"host" as host, "port" as port}' is: a set, whose contained, constant in this case, values "host" and "port" get captured as variables host and port. In pattern matching context (with 'case' in front), it means: match using a set, check for presence on constant "host" and "port" elements, and capture those constants to variables host and port (that capturing doesn't make much sense, yeah. And yet syntax tells just that. You propose to assign to it completely different meaning.). So, the "dict pattern shortcut syntax" proposed by PEP642 is rather ambiguous and confusing, and represent climax of PEP642's "fixing too many things at once", where it goes over the summit and onto the dark side. And even looking at: case {"host": as host, "port": as port} I'm personally tripped by the meaning of "as" in English, and think that it does something about thing on the left of it, i.e. the dictionary *key*, not the *value*, as it really does. To get around that effect, I'd need to write it as: case {"host": (as host), "port": (as port)} That finally looks pretty unambiguous to me. Again, an alternative is: case {"host": ->host), "port": ->port} Which is pretty self-expressive and unambiguous right away IMHO. (Of course, there's a fine distinction between "arrow points from A to B" vs "arrow points into B", I bet on the last meaning). Also, the distinction between "as" vs "->" in patterns is of the same nature as distinction between "or" vs "|" in them (there're reasons why "|" is used for alternatives, and not "or", right?) > rather than having to just know that "name" > appearing in a pattern means "__ as name", But PEP634 doesn't have no "__ as name"! It has "_ as name". And that's another case of PEP642's "too much at once". While that change is pretty clearly presented in the PEP642, I find that discussion here rather downplays it. Specifically, you use "__" even in the context talking about PEP634, as if you take it for granted. Instead, each time you mention "__", you'd rather say "which is another alternative syntax PEP642 propose". Because you see, I'm almost sure that readers of just this thread don't even pay enough attention th
[Python-Dev] Re: Unification of the Mac builds?
> On 8 Jan 2021, at 20:38, Chris Barker via Python-Dev > wrote: > > Sorry if I'm out of the loop here, but with Apple's new chip coming out, we > need new a build configuration (which I think has already been started, if > not done). > > Perhaps we could take this opportunity to better modularize / unify the build > setup? > > As it was last I checked, you really had only two options: > > 1) Ignore anything mac specific, and get a "unix" build. > > 2) Get a full "Framework" build, optionally with Universal support. > > It would be nice to keep the Framework structure independent of the > Mac-specific features, if possible. > > In particular, I'd love to get be able to get the "pythonw" executable > wrapper in an otherwise standard unix build [*]. That’s a feature of the framework build. The unix build is exactly the same as a unix build on other platform. Adding the same feature to the unix build should be possible, but would complicate the build. I have no interest to work on this, but would be willing to review PRs, as long as those aim for feature parity with the framework build. That is, both pythonw(1) and python(1) should redirect through an embedded app bundle. > > It would also be nice if it were possible to get universal binaries in a > "unix style" build. Let me sneak away in Guido’s time machine for a while. … Done, just configure “—enable-universalsdk —with-universal-archs=universal2” without specifying a framework build. > > (option 3 would be to simply abandon the Framework Build altogether -- it's > still not clear to me what this really buys mac users) In some ways this is historic, but frameworks are still the way to build a self-contained library on macOS. A major thing this buys us is having side-by-side installs of Python. > > Any chance of this happening? I'm afraid I know nothing of autoconf, so can't > be much help, but I'd be willing to help out with testing, or documenting, or > anything else that I have the skills to do. That’s not really something I intend to work on. Something I would like to work on, but don’t have enough free time for, is an alternative installation with an application bundle on the top level instead of a framework. Installation would then entail dropping “Python X.Y.app” into your application folder, and uninstallation would be to drop the same bundle into the bin. This might also make it possible to distribute Python through the Mac App Store, although I haven’t checked recently if sandboxing requirements have been relaxed enough to make that worthwhile. > > Thanks, > > -Chris > > [*] The pythonw issue has been a thorn in the side of conda for years. conda > uses a standard unix build on the Mac, for consistency with other unix > systems. But there is no configuration set up to build the pythonw wrapper > outside of a "Framework" build. So instead, conda has creates its own > "pythonw" wrapper -- but that is a bash script that re-directs to a different > executable. This works fine on the command line (or #! line), but it does not > work with setuptools' entry_points. And the setuptools community hasn't shown > any interest in hacking around it. Anyway, few enough people develop Desktop > apps (particularly with conda) so this has lingered, but it would be nice to > fix. Just don’t use conda ;-). To be blunt, doing this properly is trivial. Ronald — Twitter / micro.blog: @ronaldoussoren Blog: https://blog.ronaldoussoren.net/ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/P62REKQYYJ2I66PL7AC5MHH4OHXQ5JMM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky wrote:
> > case {"host" as host, "port" as port}:
>
> There're 2 obvious problems with it:
>
> a) In Python, {} with things inside it, but no ":" inside it, is a set,
> set.
> b) Everywhere else in Python, thing on the left of "as" gets into
> thing on the right of "as", behold:
>
> import foo as bar # original module "foo" gets into "bar".
> with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c"
>
> Then based on the existing Python syntax, the meaning of '{"host" as
> host, "port" as port}' is: a set, whose contained, constant in this
> case, values "host" and "port" get captured as variables host and port.
> In pattern matching context (with 'case' in front), it means: match
> using a set, check for presence on constant "host" and "port" elements,
> and capture those constants to variables host and port (that
> capturing doesn't make much sense, yeah. And yet syntax tells just
> that. You propose to assign to it completely different meaning.).
This analysis nicely captures my reservations with the proposal here.
It claims to be addressing the problems with PEP 634, where the syntax
proposed there is specialised to matching, but it then proceeds to
introduce another syntax, which is *also* unlike existing usage, just
in different ways.
You may say that the PEP 642 syntax is "better", but that's a matter
of opinion. Having {...} without a colon be a dict-style unpacking is
very uncomfortable to me. Having "as" not assign the result of what's
on the left of it to the right hand name is uncomfortable to me. The
PEP 634 equivalents do *not* feel uncomfortable in the same way.
I'm mostly just repeating myself here, though. I'm on record already
as saying that I feel PEP 642 is strictly worse than PEP 634. My main
worry is that the two competing PEPs turn the question into "let's
assume pattern matching is a good thing, which is the better syntax" -
which is *not* the question. Each PEP should be considered on its own
merits, and people who like pattern matching but don't like the PEP
634 syntax should be *at least* as strict in their analysis of PEP 642
(possibly even more so, because PEP 642 makes a bunch of unverified -
and in my view, unjustified - assumptions about the desirability of
potential adoption of the syntax in wider contexts).
To be honest, though, I think that we're now at the point where we
have to rely on the SC for a decision. Pretty much everyone has made
their views clear, so the final decision is going to be down to
"design instinct". Ultimately, that's the basis on which we all voted
for SC members, after all.
Paul
PS This situation is particularly special, of course, because it's a
direct comparison of Guido's design instincts (PEP 634) and the SC's.
So whatever the result, it'll be interesting!
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/2FZFQMBHDBELMQJRMC526OV2UQ5N4QSU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: unittest of sequence equality
On 1/8/2021 2:50 PM, Chris Barker via Python-Dev wrote: If there are other common types this helps with, sure. But for numpy, as pointed out elsewhere in this thread, it would still fail for numpy arrays of > 1 dimension. Personally I think this is really an issue with the structure of unitest -- having a custom assertion for every possibility is intractable. If you want to test numpy arrays, use the utilities provided by numpy. This comment misses the key point, which is: `assertSequenceEqual` should not rely on behavior that is not ensured for typing.Sequence, but it currently does. The failure on a numpy array simply exposes this problem. The array-dimension consideration is also a red herring. For example, `unittest.TestCase().assertSequenceEqual([1,2,3],(1,2,3))` pasess but `unittest.TestCase().assertSequenceEqual([[1,2,3]],[(1,2,3)])` raises. This behavior remains unchallenged. Alan Isaac ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2JGP3J7V4XVBS6KDFWNUZCVKIC3HO4YO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sat, 9 Jan 2021 12:17:32 +
Paul Moore wrote:
> On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky wrote:
> > > case {"host" as host, "port" as port}:
> >
> > There're 2 obvious problems with it:
> >
> > a) In Python, {} with things inside it, but no ":" inside it, is a set,
> > set.
> > b) Everywhere else in Python, thing on the left of "as" gets into
> > thing on the right of "as", behold:
> >
> > import foo as bar # original module "foo" gets into "bar".
> > with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c"
> >
> > Then based on the existing Python syntax, the meaning of '{"host" as
> > host, "port" as port}' is: a set, whose contained, constant in this
> > case, values "host" and "port" get captured as variables host and port.
> > In pattern matching context (with 'case' in front), it means: match
> > using a set, check for presence on constant "host" and "port" elements,
> > and capture those constants to variables host and port (that
> > capturing doesn't make much sense, yeah. And yet syntax tells just
> > that. You propose to assign to it completely different meaning.).
>
> This analysis nicely captures my reservations with the proposal here.
> It claims to be addressing the problems with PEP 634, where the syntax
> proposed there is specialised to matching, but it then proceeds to
> introduce another syntax, which is *also* unlike existing usage, just
> in different ways.
Introducing a new syntax is not a problem, it's the solution. The
problem with PEP 634 is precisely that it reuses existing syntax and
gives it a different meaning, thereby producing confusion.
It's erroneous to claim that `{"host" as host, "port" as port}` is a
set. It's currently invalid syntax due to the `as`:
>>> {"host" as host, "port" as port}
File "", line 1
{"host" as host, "port" as port}
^
SyntaxError: invalid syntax
So, opposing Nick's proposal on the basis that it "looks like a set" is
just like opposing set literals on the basis they they "look like a
dict".
Regards
Antoine.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/BZOIB3NTXICLJYCIE6GSMUPWVI4DG3UG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
> So, opposing Nick's proposal on the basis that it "looks like a set" is
> just like opposing set literals on the basis they they "look like a
> dict".
That's not what I was doing (I can't comment on what Paul S intended,
though). My position is that the lack of a colon makes this not look
like a dictionary destructuring to me. The "as" keyword doesn't have
the same feeling of describing the *form* of a data structure,
possibly because structure in fundamental data types is more often
indicated by punctuation than keywords.
As a larger point, I'm saying that Nick's proposal has just as many of
these "doesn't feel quite right" compromises as the original proposal
(actually, *to me* it has far *more* of them, but there's a level of
subjectivity here). As a result, I'm unmoved by the arguments that
"it's pattern matching, but with a nicer syntax".
The dictionary destructuring can act as an example. We know Nick's position:
case {"text": message, "color": c}:
1. There's nothing (other than the fact that it's in a case clause) to
indicate that message and c are assigned to.
2. It "binds to the right without using as", (as far as I can see,
based on the premise that "as" is the only valid way of binding names
where the name is on the right, which was asserted without any
justification).
But the PEP 642 form:
case {"text" as message, "color" as c}:
is essentially identical except for using "as" rather than a colon. My view is:
1. Nowhere else in Python does "as" indicate a dictionary, and braces
alone don't (because sets use them too).
2. It loses the "match looks like the input" aspect, while only
gaining some sort of theoretical "as is how we bind to the right"
property that's never been a design principle in Python before now.
3. It's entirely new syntax, where the PEP 634 form is similar to
existing Python syntax for dictionaries, and to other languages'
matching constructs.
What I'm saying here is simply that looked at (relatively)
objectively, there are similar numbers of debatable points on both
sides of the argument.
Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CIFLROSUOK3TET2Q6LWVDEHH3C2DAIAL/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
Le 09/01/2021 à 15:18, Paul Moore a écrit :
>
> But the PEP 642 form:
>
> case {"text" as message, "color" as c}:
>
> is essentially identical except for using "as" rather than a colon. My view
> is:
>
> 1. Nowhere else in Python does "as" indicate a dictionary, and braces
> alone don't (because sets use them too).
Admittedly. But *something* has to be found, right?
> 2. It loses the "match looks like the input" aspect, while only
> gaining some sort of theoretical "as is how we bind to the right"
> property that's never been a design principle in Python before now.
Is there an official catalog of Python design principles? "... as y" is
already (optionally) used in `import` and `with` statements, so this is
not an innovation in Nick's PEP.
> 3. It's entirely new syntax, where the PEP 634 form is similar to
> existing Python syntax for dictionaries, and to other languages'
> matching constructs.
As I said, using new syntax to denote a new semantics seems like the
right thing to do.
Regards
Antoine.
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/VOQMNHBJ44Q2OMQJTDFHVZS2DI3CRL2B/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
Hello,
On Sat, 9 Jan 2021 14:49:19 +0100
Antoine Pitrou wrote:
> On Sat, 9 Jan 2021 12:17:32 +
> Paul Moore wrote:
>
> > On Sat, 9 Jan 2021 at 10:52, Paul Sokolovsky
> > wrote:
> > > > case {"host" as host, "port" as port}:
> > >
> > > There're 2 obvious problems with it:
> > >
> > > a) In Python, {} with things inside it, but no ":" inside it, is
> > > a set, set.
> > > b) Everywhere else in Python, thing on the left of "as" gets into
> > > thing on the right of "as", behold:
> > >
> > > import foo as bar # original module "foo" gets into "bar".
> > > with Cls(a, b) as c: # original expression "Cls(a, b)" gets into
> > > "c"
> > >
> > > Then based on the existing Python syntax, the meaning of '{"host"
> > > as host, "port" as port}' is: a set, whose contained, constant in
> > > this case, values "host" and "port" get captured as variables
> > > host and port. In pattern matching context (with 'case' in
> > > front), it means: match using a set, check for presence on
> > > constant "host" and "port" elements, and capture those constants
> > > to variables host and port (that capturing doesn't make much
> > > sense, yeah. And yet syntax tells just that. You propose to
> > > assign to it completely different meaning.).
> >
> > This analysis nicely captures my reservations with the proposal
> > here. It claims to be addressing the problems with PEP 634, where
> > the syntax proposed there is specialised to matching, but it then
> > proceeds to introduce another syntax, which is *also* unlike
> > existing usage, just in different ways.
>
> Introducing a new syntax is not a problem, it's the solution. The
> problem with PEP 634 is precisely that it reuses existing syntax and
> gives it a different meaning, thereby producing confusion.
>
> It's erroneous to claim that `{"host" as host, "port" as port}` is a
> set. It's currently invalid syntax due to the `as`:
>
> >>> {"host" as host, "port" as port}
> File "", line 1
> {"host" as host, "port" as port}
> ^
> SyntaxError: invalid syntax
>
>
> So, opposing Nick's proposal on the basis that it "looks like a set"
> is just like opposing set literals on the basis they they "look like a
> dict".
No, it's different kind of opposition. Consider for example the syntax
"2+2". One can say that it doesn't make sense, everyone knows that two
plus two is four, so everyone would write "4" right away. So, let's
take "2+2" and assign to it a different meaning, let's say that it means
"5". Or let's say that it means a dict.
That's exactly what PEP642 does - it takes set *syntax* and
appropriates it for dict *semantics*, hence the opposition. Compare
that to what PEP634 does: it takes tuple syntax, and defines sequence
pattern matching based on it; it also takes dict syntax and defines
mapping pattern matching based on it; finally, it takes object
construction syntax, and defines object pattern matching syntax based
on it.
In all 3 cases, PEP634 defines *new semantics* based on *existing
syntax* (by putting it into new higher-level syntactic construct, the
"case" clause), and does so in consistent way. PEP634 later could be
extended with set patterns, e.g.:
match [1, 2]:
case {1, 2}: # matches
match [1, 2]:
case {2, 1}: # also matches
match {1, 2}:
case {2, _ as another}: # matches and assigns 1 to 'another'
Whereas again, PEP642 tries to appropriate such set pattern syntax for
completely different purpose, only because its author thought that it's
ok in the mapping pattern syntax to suddenly drop ":" operator.
--
Best regards,
Paul mailto:[email protected]
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/4AHGIRAYYMXCRXLGCDUG44C46KDMBA4K/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote:
> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
>
> > So, opposing Nick's proposal on the basis that it "looks like a set" is
> > just like opposing set literals on the basis they they "look like a
> > dict".
>
> That's not what I was doing (I can't comment on what Paul S intended,
> though). My position is that the lack of a colon makes this not look
> like a dictionary destructuring to me. The "as" keyword doesn't have
> the same feeling of describing the *form* of a data structure,
> possibly because structure in fundamental data types is more often
> indicated by punctuation than keywords.
>
And I've already said I'd be fine with making the colon mandatory if the SC
share that view.
> As a larger point, I'm saying that Nick's proposal has just as many of
> these "doesn't feel quite right" compromises as the original proposal
> (actually, *to me* it has far *more* of them, but there's a level of
> subjectivity here). As a result, I'm unmoved by the arguments that
> "it's pattern matching, but with a nicer syntax".
>
> The dictionary destructuring can act as an example. We know Nick's
> position:
>
> case {"text": message, "color": c}:
>
> 1. There's nothing (other than the fact that it's in a case clause) to
> indicate that message and c are assigned to.
> 2. It "binds to the right without using as", (as far as I can see,
> based on the premise that "as" is the only valid way of binding names
> where the name is on the right, which was asserted without any
> justification).
>
What other syntax do we have that binds to the right without "as"? Allowing
it at all is only as old as with statements, but that's still more
precedence than ":" and "=" have for being used that way.
> But the PEP 642 form:
>
> case {"text" as message, "color" as c}:
>
> is essentially identical except for using "as" rather than a colon. My
> view is:
>
> 1. Nowhere else in Python does "as" indicate a dictionary, and braces
> alone don't (because sets use them too).
> 2. It loses the "match looks like the input" aspect, while only
> gaining some sort of theoretical "as is how we bind to the right"
> property that's never been a design principle in Python before now.
> 3. It's entirely new syntax, where the PEP 634 form is similar to
> existing Python syntax for dictionaries, and to other languages'
> matching constructs.
>
> What I'm saying here is simply that looked at (relatively)
> objectively, there are similar numbers of debatable points on both
> sides of the argument.
>
Except that many of the PEP 642 ones are optional shorthand that the SC can
selectively reject or defer if they want to - for example, always requiring
the use of ":" in both mapping patterns and instance attribute patterns
would only increase verbosity, it wouldn't reduce expressivity.
PEP 634 is more constrained than that. For example, mapping keys have to be
restricted to just literals and attributes, because allowing bare names or
more complex expressions would make the pattern name bindings too hard to
pick out.
Cheers,
Nick.
> Paul
> ___
> Python-Dev mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/CIFLROSUOK3TET2Q6LWVDEHH3C2DAIAL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/SZHIT23BFSLIVRKZU3CNUTXS35ISJLBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sun, 10 Jan 2021, 12:54 am Nick Coghlan, wrote:
>
>
> On Sun, 10 Jan 2021, 12:22 am Paul Moore, wrote:
>
>> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou wrote:
>>
>>
>> The dictionary destructuring can act as an example. We know Nick's
>> position:
>>
>> case {"text": message, "color": c}:
>>
>> 1. There's nothing (other than the fact that it's in a case clause) to
>> indicate that message and c are assigned to.
>> 2. It "binds to the right without using as", (as far as I can see,
>> based on the premise that "as" is the only valid way of binding names
>> where the name is on the right, which was asserted without any
>> justification).
>>
>
> What other syntax do we have that binds to the right without "as"?
> Allowing it at all is only as old as with statements, but that's still more
> precedence than ":" and "=" have for being used that way.
>
Correcting myself: the import statement usage has been around much longer
than that.
With statements were just the case that took 'as name' from being an import
specific syntax to being a bit more general than that.
Cheers,
Nick.
>>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/CSW5HIN3WBEXYECBFZ7ZRH4KLXODLZTD/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky, wrote:
> >
> > The key difference relative to PEP 634 is that even when the code
> > author uses the shorthand form, *readers* will still get at least the
> > "as" keyword as a prompt,
>
> Ok, so let's summarize the alternatives:
>
> 1. PEP634, which says that "case Cls(a, b):", etc. is not worse than
> other languages.
> 2. PEP642, which says that taking existing "as" and using it (and it's
>also an English word with a specific meaning) with rather different
>meaning in pattern matching is ok.
>
I don't follow this objection. It's being used the same way it is used
elsewhere in Python: binding a name given on the right based on information
given on the left.
The shorthand to omit "__" is the only novelty that doesn't strictly follow
that precedent.
3. Alternative proposal sounded on the list, which says that taking
>existing punctuational operator like ">" or "->" (and they're also
>graphemes depicturing arrows) and using them (still with rather
>different meaning) in pattern matching is ok.
>
> PEP642 never mentions 3rd alternative.
Because PEP 634 doesn't propose it either.
And it actually starts its
> presentation with things like:
>
> > case {"host" as host, "port" as port}:
>
> There're 2 obvious problems with it:
>
> a) In Python, {} with things inside it, but no ":" inside it, is a set,
> set.
> b) Everywhere else in Python, thing on the left of "as" gets into
> thing on the right of "as", behold:
>
> import foo as bar # original module "foo" gets into "bar".
> with Cls(a, b) as c: # original expression "Cls(a, b)" gets into "c"
>
> Then based on the existing Python syntax, the meaning of '{"host" as
> host, "port" as port}' is: a set, whose contained, constant in this
> case, values "host" and "port" get captured as variables host and port.
> In pattern matching context (with 'case' in front), it means: match
> using a set, check for presence on constant "host" and "port" elements,
> and capture those constants to variables host and port (that
> capturing doesn't make much sense, yeah. And yet syntax tells just
> that. You propose to assign to it completely different meaning.).
>
Yep, this is why I'd be entirely OK with the SC saying they'd prefer the
colon to be mandatory, even when parsing is unambiguous without it.
I personally like the idea of being able to leave it out as redundant, but
I definitely agree that the omission has the potential to make mapping
patterns harder to interpret for readers.
> So, the "dict pattern shortcut syntax" proposed by PEP642 is rather
> ambiguous and confusing, and represent climax of PEP642's "fixing too
> many things at once", where it goes over the summit and onto the dark
> side.
>
> And even looking at:
>
> case {"host": as host, "port": as port}
>
> I'm personally tripped by the meaning of "as" in English, and think
> that it does something about thing on the left of it, i.e. the
> dictionary *key*, not the *value*, as it really does.
It is as closely related to the key as the binding in with statements is to
the context manager expression (in mapping patterns, it would bind the
result of looking up the key, in with statements it binds the result of the
__enter__ method).
>
> > rather than having to just know that "name"
> > appearing in a pattern means "__ as name",
>
> But PEP634 doesn't have no "__ as name"! It has "_ as name". And
> that's another case of PEP642's "too much at once". While that change
> is pretty clearly presented in the PEP642, I find that discussion here
> rather downplays it. Specifically, you use "__" even in the context
> talking about PEP634, as if you take it for granted. Instead, each time
> you mention "__", you'd rather say "which is another alternative syntax
> PEP642 propose".
>
> Because you see, I'm almost sure that readers of just this thread don't
> even pay enough attention that you use double-underscore instead of the
> original underscore. That leads us to the obvious concern:
>
> 1. The difference between "__" and "_" isn't visible enough.
>
> People should start saying "OMG" and "horror!" now, not when PEP642 gets
> implemented and they finally notice that they need to type _ twice.
Which leads us to:
>
> 2. Both PEP642 and discussion here should elaborate explicitly what
> happens when people still use "_" in patterns.
>
It's a syntax error, because PEP 642 patterns don't allow the use of bare
names.
So, you see, it says "many people prefer __", and then immediately says
> "linters recognize _ as a special case". So, 10 years later, how many
> linters recognize double-underscore as a special case too?
>
pylint does. I haven't checked the others, as pylint is the one I typically
use.
> Other general comments on PEP642v3 text:
>
> > * allow an initial form of pattern matching to be developed and
> > released without needing to decide up front on the best default
> > options for handling bare names, attribute lookups, and lite
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
Hello,
On Sun, 10 Jan 2021 01:42:25 +1000
Nick Coghlan wrote:
> On Sat, 9 Jan 2021, 8:50 pm Paul Sokolovsky,
> wrote:
>
> > >
> > > The key difference relative to PEP 634 is that even when the code
> > > author uses the shorthand form, *readers* will still get at least
> > > the "as" keyword as a prompt,
> >
> > Ok, so let's summarize the alternatives:
> >
> > 1. PEP634, which says that "case Cls(a, b):", etc. is not worse than
> > other languages.
> > 2. PEP642, which says that taking existing "as" and using it (and
> > it's also an English word with a specific meaning) with rather
> > different meaning in pattern matching is ok.
> >
>
> I don't follow this objection. It's being used the same way it is used
> elsewhere in Python: binding a name given on the right based on
> information given on the left.
Where's "left" in the case of your proposed syntax:
case [as a, as b]:
?
There's no "left". And that's the whole point, in your PEP642
proposal, "as" applies to implicitly given term, encoded by position in
the match pattern. That's ... unusual. And ... confusing, at least at
first. As I said, maybe we could get used to it, but I always bring
that matter in comparison to the alternative syntax, which IMHO avoids
confusion implied by both English and current Python meaning of "as":
case [>a, >b]:
> The shorthand to omit "__" is the only novelty that doesn't strictly
> follow that precedent.
>
>
> 3. Alternative proposal sounded on the list, which says that taking
> >existing punctuational operator like ">" or "->" (and they're
> > also graphemes depicturing arrows) and using them (still with rather
> >different meaning) in pattern matching is ok.
> >
> > PEP642 never mentions 3rd alternative.
>
>
> Because PEP 634 doesn't propose it either.
Well, PEP622 did have it:
https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern
,
quoting (last bullet point there):
>>> There was also an idea to make lookup semantics the default, and
>>> require $ or ? to be used in capture patterns:
Then we know the issues with PEP622/PEP634, that requests/proposals for
various clarifications to them were denied. That's how PEP642 was born,
according to its own text. The more strange that it continues that
cycle of hushing/avoiding mentioning alternative ideas.
> And it actually starts its
> > presentation with things like:
> >
> > > case {"host" as host, "port" as port}:
> >
> > There're 2 obvious problems with it:
> >
> > a) In Python, {} with things inside it, but no ":" inside it, is a
> > set, set.
> > b) Everywhere else in Python, thing on the left of "as" gets into
> > thing on the right of "as", behold:
> >
> > import foo as bar # original module "foo" gets into "bar".
> > with Cls(a, b) as c: # original expression "Cls(a, b)" gets into
> > "c"
> >
> > Then based on the existing Python syntax, the meaning of '{"host" as
> > host, "port" as port}' is: a set, whose contained, constant in this
> > case, values "host" and "port" get captured as variables host and
> > port. In pattern matching context (with 'case' in front), it means:
> > match using a set, check for presence on constant "host" and "port"
> > elements, and capture those constants to variables host and port
> > (that capturing doesn't make much sense, yeah. And yet syntax tells
> > just that. You propose to assign to it completely different
> > meaning.).
>
> Yep, this is why I'd be entirely OK with the SC saying they'd prefer
> the colon to be mandatory, even when parsing is unambiguous without
> it.
That's great, thanks for considering it!
But in the formal review process what we have is:
1) It's v3 of PEP642, which still has such an issue.
2) Its author doesn't admit that there's objective ambiguity between
mapping pattern syntax in PEP642 and would-be set patterns, and treat
that issue as subjective, saying that he'd make a change if SC asks for
it, not because he has seen the issue with it, based on the community
feedback.
> I personally like the idea of being able to leave it out as
> redundant, but I definitely agree that the omission has the potential
> to make mapping patterns harder to interpret for readers.
>
>
> > So, the "dict pattern shortcut syntax" proposed by PEP642 is rather
> > ambiguous and confusing, and represent climax of PEP642's "fixing
> > too many things at once", where it goes over the summit and onto
> > the dark side.
> >
> > And even looking at:
> >
> > case {"host": as host, "port": as port}
> >
> > I'm personally tripped by the meaning of "as" in English, and think
> > that it does something about thing on the left of it, i.e. the
> > dictionary *key*, not the *value*, as it really does.
>
>
> It is as closely related to the key as the binding in with statements
> is to the context manager expression (in mapping patterns, it would
> bind the result of looking up the key, in with statements it binds
> the result of the __enter__ method).
Sorry, we ta
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sat, 9 Jan 2021 at 14:54, Nick Coghlan wrote:
[...]
> And I've already said I'd be fine with making the colon mandatory if the SC
> share that view.
So the response to my comment that omitting the colon makes it hard to
see that it's a dictionary unpacking is either "don't use that form if
you don't like it" (which as we all know doesn't account for the
problem of dealing with other people's code) or "the SC can make the
colon mandatory" which seems to me to be extending the SC's role to
designing the syntax rather than just approving the proposal. And
means that the PEP we're debating might not be what gets accepted.
Which isn't how I understood the process to work, but OK.
And if the colon is mandatory, the syntax is {"text": as message,
"color": as c}. Which is essentially the same as PEP 634 with an
additional "as". Which basically makes this a somewhat disguised
version of "add a marker to indicate the variable to be bound". Meh.
We've been down this route, some people want bindings to be explicitly
marked, other people don't. I don't feel compelled to have explicit
markers, I like the "match pattern looks like what's being matched"
feature of PEP 634, and don't have a huge difficulty understanding
what's bound and what's matched in the sort of real-world cases that
have been presented. The nearest to a problem I've seen is "case
CONSTANT", which I acknowledge is a potential bug magnet, but I think
the "solution" proposed by PEP 642 is far worse than the problem.
> What other syntax do we have that binds to the right without "as"? Allowing
> it at all is only as old as with statements, but that's still more precedence
> than ":" and "=" have for being used that way.
None at the moment, but that's not my point. My point is that patterns
are more like expressions than statements, and all current uses of
"as" for binding are in statements. Expressions typically use
punctuation rather than keywords, so there's no compelling argument
that the syntax for "binding the RHS" *in expressions* has to be "as".
You say "we use as in statements, so let's re-use that", I say "we use
punctuation in expressions, and a keyword looks clumsy and verbose". I
don't believe that point has ever been addressed directly, which is
why I get frustrated that arguments about "as" seem to be getting
redirected into arguments about binding to the right all the time.
> Except that many of the PEP 642 ones are optional shorthand that the SC can
> selectively reject or defer if they want to - for example, always requiring
> the use of ":" in both mapping patterns and instance attribute patterns
> would only increase verbosity, it wouldn't reduce expressivity.
So based on that comment, PEP 642 isn't a proposal so much as a
selection of options the SC can pick between. And attempts like this
to discuss specifics of the proposal are hard to have, because "well,
the SC can drop that bit if they don't like it" is always an option. I
don't like that, and I'm not sure it's the right way to use the PEP
process. I'm inclined to suggest the SC should reject the proposal
simply because it leaves too much undecided, and doesn't take a firm
position ;-)
But whatever. To restate my position (which hasn't changed much) - I
like the idea of pattern matching in Python. PEP 634 seems like a
"natural" syntax to me, even though it's somewhat "do what I mean" in
terms of the exact details (in other words, I find it a good practical
approach even if it frustrates the rulebook lawyer in me). I dislike
PEP 642, although I can't honestly put my finger on why - mainly, it
seems like it prioritises rules (ease of implementation, keeping the
spec concise) over usability. I don't think pattern matching is
important enough to accept the usability compromises that I feel PEP
642 requires, but I *do* think it's sufficiently important to mean
that I'm comfortable accepting the edge cases (specification
compromises) in PEP 634. If PEP 642 were accepted, I'd use pattern
matching a *lot* less than if PEP 634 were accepted (and I'd argue
against its use more often on projects I contribute to). I'm glad I'm
not on the SC and having to make this decision.
Paul
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/3RJG5FDUJVV5GCNPXTCWQQVUQXICYDWB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 642 v3: Explicit patterns for structured pattern matching
On Sun, 10 Jan 2021, 2:55 am Paul Moore, wrote:
> On Sat, 9 Jan 2021 at 14:54, Nick Coghlan wrote:
>
> [...]
> > And I've already said I'd be fine with making the colon mandatory if the
> SC share that view.
>
> So the response to my comment that omitting the colon makes it hard to
> see that it's a dictionary unpacking is either "don't use that form if
> you don't like it" (which as we all know doesn't account for the
> problem of dealing with other people's code) or "the SC can make the
> colon mandatory" which seems to me to be extending the SC's role to
> designing the syntax rather than just approving the proposal. And
> means that the PEP we're debating might not be what gets accepted.
> Which isn't how I understood the process to work, but OK.
>
It's the same process any PEP goes through: comments from the PEP delegate
carry more weight than general review comments, as ignoring them risks
getting the PEP rejected.
>
The SC haven't provided any feedback on the submitted version of 642 yet,
so I don't know at this point if they share the concern that allowing
omitting the key/value separating colon to be omitted pushes mapping &
instance attribute patterns too close to looking like a variation on set
syntax instead of mapping syntax.
I do accept that it's a legitimate concern, it's just also a feature that's
easy to drop if the SC agrees it is problematic.
> And if the colon is mandatory, the syntax is {"text": as message,
> "color": as c}. Which is essentially the same as PEP 634 with an
> additional "as". Which basically makes this a somewhat disguised
> version of "add a marker to indicate the variable to be bound".
It isn't disguised at all, as I state it in the PEP's Design Discussion
section:
"""... instead requiring that all uses of bare simple names for anything
other than a variable lookup be qualified by a preceding sigil or keyword"""
(from
https://www.python.org/dev/peps/pep-0642/#requiring-explicit-qualification-of-simple-names-in-match-patterns
)
Meh.
> We've been down this route, some people want bindings to be explicitly
> marked, other people don't. I don't feel compelled to have explicit
> markers, I like the "match pattern looks like what's being matched"
> feature of PEP 634,
PEP 634 doesn't have that feature for class patterns in general, only for
classes like data classes, where the constructor signature is carefully
aligned with the match arguments.
For positional args, PEP 642 would also align in those carefully
constructed cases, so it's only the new syntax for attribute matching where
things differ.
For mapping patterns, I think you've made a reasonable case that the colon
should be required even when unconditionally binding names, so it wouldn't
surprise me at all if the shorthand to omit them gets rejected by the SC
(or at least moved to the "Deferred Ideas" section).
> What other syntax do we have that binds to the right without "as"?
> Allowing it at all is only as old as with statements, but that's still more
> precedence than ":" and "=" have for being used that way.
>
> None at the moment, but that's not my point. My point is that patterns
> are more like expressions than statements, and all current uses of
> "as" for binding are in statements. Expressions typically use
> punctuation rather than keywords, so there's no compelling argument
> that the syntax for "binding the RHS" *in expressions* has to be "as".
>
But PEP 634 uses "PTRN as NAME" as well.
The only difference in this regard between the two PEPs is that 634 allows
"_ as NAME" to be shortened to just "NAME" (omitting both the pattern and
the keyword), while 642 only allows "__ as NAME" to be shortened to "as
NAME" (omitting only the pattern).
You say "we use as in statements, so let's re-use that", I say "we use
> punctuation in expressions, and a keyword looks clumsy and verbose". I
> don't believe that point has ever been addressed directly, which is
> why I get frustrated that arguments about "as" seem to be getting
> redirected into arguments about binding to the right all the time.
>
I didn't realise it was an argument you were trying to make.
Cheers,
Nick.
> >
>
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/4YGNYB44PXEHD3WFX6DKQI3LHOAYUC5S/
Code of Conduct: http://python.org/psf/codeofconduct/
