[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rik de Kort via Python-Dev]

I'm very new to this mailing list so I'm not sure it's my place to email, but 
I'd like to weigh in and maybe it will be useful. If not you can always ignore 
;)

I think adding the Walrus operator is trying to solve a problem that doesn't 
exist. Compare the example from the PEP:
def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
To the one without:
def make_point_3d(pt):
match pt:
case (x := _, y := _):
return Point3d(x, y, 0)
case (x := _, y := _, z := _):
return Point3d(x, y, z)
case Point2d(x := _, y := _):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
It's a lot more typing, it's a lot more ugly, and I'd argue it's not any more 
explicit than the earlier one. We still have all the same variables, except now 
we have to follow them with a ritualistic ":= _" to capture them. Normally we 
use the underscore to discard or hide something (at least that's how I've 
always used it), and suddenly it is used when we want to keep the thing it 
stands for?!

Also, I understand Python doesn't look like Haskell or Rust or whatever, but 
you also have people coming from those languages to Python, and people going to 
those languages from Python. Having a different syntax from what literally 
everybody else does will lead to a lot of confusion. I think the default option 
should be to have it like the current proposal (and everybody else), and update 
it only if there is a good reason to do so. "We don't want to look like the 
rest" should not be an argument. I think Python not looking like anything else 
is a result of the readability and simplicity goals of Python, not because the 
goal was to look different.

Finally, I asked an actual Python newbie (our trainee) about his opinion, and 
he said he didn't think the walrus example was any more useful. Of course, N=1, 
not an experiment, doesn't measure mistakes in practice, etc. But let's make 
sure it's an actual problem before we go complicate the syntax.

Again, first time mailing here and I don't know if it's my place (can I even 
mail into this list?), but I hope the perspective is of some use.

Rik

P.S. I never had issues with list comprehensions, because it's basically how 
you write down sets in mathematics (which is what I studied). 
"Joao S. O. Bueno"  wrote:
“”


“On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano  wrote:”

“On Sat, Jul 18, 2020 at 09:25:45AM -, emmanuel.coir...@caissedesdepots.fr 
wrote:


> This approach, for me, seems to come from functionnal languages where

> pattern matching is a thing. The proposed "match" clause tends to 

> mimic this approach, and it can be a good thing. But the Python's 

> function definition has not been inspired by functionnal programming 

> from the ground, and I think it would be an error to reason this way, 

> because people not used to pattern matching in functionnal programming 

> won't understand anything (imagine that comprehension lists are a big 

> thing for many learners).


It is true that beginners sometimes struggle a bit to grok comprehension 

syntax. I know I did.


And yet, despite that, comprehensions have turned out to be one of the 

most powerful and popular features of Python, sometimes *too* popular. 

It is sometimes hard to convince both beginners and even experienced 

devs that comprehensions are not the only tool in their toolbox, and not 

every problem is a nail.


You say: "people not used to pattern matching in functionnal programming

won't understand anything" but people using Haskell weren't born knowing 

the language. They had to learn it.


It's been sometimes said that functional programmers are smarter, elite 

programmers a level above the average OOP or procedural programmer, but 

that's mostly said by functional programmers :-) and I'm not entirely 

sure that its true. In any case, I don't think that any (actual or 

imaginary) gap between the ability of the average Haskell programmer and 

the average Python programmer is so great that we should dismiss pattern 

matching as beyond the grasp of Python coders.


In any case, functional languages like Haskell, F# and ML are not the 

only languages with pattern matching. Non-FP languages like C#, Swift, 

Rust and Scala have it, and even Java has an extension providing pattern 

matching:”
“
You do a nice job arguing that matching is a nice feature to have - and I guess 
we are past this point.

But I don't see one thing in the above characters pointing thatusing an 
undifferentiated name by itself in the match/case constructwill be better than 
trying to find a 

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Guido van Rossum]

On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan  wrote:

> I'm still only intermittently keeping up on python-dev, but my main
> concern with the first iteration remains in this version, which is that it
> doesn't even *mention* that the proposed name binding syntax inherently
> conflicts with the existing assignment statement lvalue syntax in two areas:
>

I don't see why the PEP would be required to mention this. You make it
sound like it's a bad thing (a "conflict"), whereas the PEP authors'
position is that it is irrelevant.


> * dotted names (binds an attribute in assignment, looks up a constraint
> value in a match case)
> * underscore targets (binds in assignment, wildcard match without binding
> in a match case)
>
> The latter could potentially be made internally consistent in the future
> by redefining "_" and "__" as soft keywords that don't get bound via normal
> assignment statements either (requiring that they be set via namespace dict
> modification instead for use cases like il8n).
> https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard
> presents a reasonable rationale for the usage, so it's only flaw is failing
> to mention the inconsistency.
>

That solution is outside the scope of the PEP -- it would be a big backward
incompatibility with little payoff. Your repeated mention of consistency
makes me want to quote PEP 8 (quoting Emerson, though I didn't even know
who that was when I put it in my style guide :-): "A foolish consistency is
the hobgoblin of little minds."


> The former syntactic conflict presents a bigger problem, though, as it
> means that we'd be irrevocably committed to having two different lvalue
> syntaxes for the rest of Python's future as a language.
>

Things become much less "conflict-y" if you stop seeing patterns as
lvalues. They just aren't, and any argument based on the idea that they are
is inherently flawed. (Also note that the concept of lvalue isn't even
defined in Python. There are a variety of assignment targets with different
syntactic constraints depending on context, and several other syntactic
constructs that bind names.)


>
> https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern
> is nominally about this problem, but it doesn't even *mention* the single
> biggest benefit of putting a common prefix on value constraints: it leaves
> the door open to unifying the lvalue syntax again in the future by keeping
> the proposed match case syntax a strict superset of the existing assignment
> target syntax, rather than partially conflicting with it.
>

That's because the PEP authors disagree with you that this goal is worthy
of pursuit, and hence we don't see care about this benefit at all.


> More incidentally, the latest write-up also leaves out "?" as a suggested
> constraint value prefix, when that's the single character prefix that best
> implies the question "Does the runtime value at this position equal the
> result of this value constraint expression?" without having any other
> existing semantic implications in Python.
>

In the discussion pretty much all non-alphanumeric ASCII characters have
been proposed by various people as sigils to mark either capture patterns
or value patterns. We didn't think it was necessary to enumerate all
proposed characters and write up reasons why we reject them, since the
reasons for rejection are pretty much always the same -- it looks strange,
and there's no need for sigils at all.

Honestly, it doesn't help the case for `?` that it's been proposed as a
mark for both capture patterns and value patterns (by different people,
obviously :-).


> Cheers,
> Nick.
>
> P.S. I feel I should mention that the other reason I like "?" as a
> potential prefix for value constraints is that if we require it for all
> value constraint expressions (both literals and name lookups) I believe it
> could offer a way to unblock the None-aware expressions PEP by reframing
> that PEP as a shorthand for particular case matches.
>
> None coalescence ("a ?? b") for example:
>
> match a:
>case ?None:
>   _expr_result = b
>case _match:
>   _expr_result = _match
>
> Or a None-severing attribute lookup ("a?.b"):
>
> _match_expr = a
> match _match_expr:
>case ?None:
>   _expr_result = _match_expr
>case _match:
>   _expr_result = _match.b
>
> Since these operations would be defined in terms of *equality* (as per PEP
> 622), rather than identity, it would also allow other sentinels to benefit
> from the None-aware shorthand by defining themselves as being equal to None.
>

This sounds like a huge stretch. Trying to forge a connection between two
separate uses of the same character sounds like arguing that the `*` in `a
* b` and the `*` in `*args` are really the same operator.

I am actually rather in favor of PEP 505, but that doesn't make any
difference for how I see marking value patterns in PEP 622.

--Guido


> On Thu., 9 Jul

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rik de Kort via Python-Dev]

Hi Rob, thank you! :)
I think I understand the point, but I still don't agree with it. I find it hard 
to come up with a concrete use case where you would like to name a parameter 
without specifying it. Suppose we want
case Status(user, n_messages, replies, unicode:=_)
Then it might be a little useful for us to type the non-captured arguments 
explicitly because it's easier to remember the signature that way. 
Alternatively, if you want to capture an arg like this and you have more than a 
few positional arguments, you should probably just match on a keyword argument 
(or refactor your code so your API's are simpler).
Also, what would we type if we wanted to capture a keyword argument? Something 
like this?
case Status(user, n_messages, replies, unicode=unicode:=_)
Surely that must be a horrible joke! (N.B. I suppose this is an argument 
against this specific syntax rather than capturing)

Additional potentials I came up with are checking for the number of arguments 
(when it's a lot, so typing all the underscores becomes hard to count), like:
match pt:
case (a, b, c, d, e, f, g, h):
manage_len_8(pt)
case (a, b, c, d, e, f, g, h, i, j, k):
manage_len_11(pt)
But in that case why not use an if-else, like so.
if len(pt)==8:
manage_len_8(pt)
elif len(pt)==11:
manage_len_11(pt)
There must be use cases I haven't thought of, but I think they will all fall 
prey to similar objections as the above two. I'm open to being proven wrong, 
though!

The thing about explicitness is, sure, it is better than implicitness. But 
beautiful is also better than ugly, and simple better than complex, etc. etc. I 
think they mean nothing without specific use cases to know what it actually 
means for this thing in this context.
I think case(x:=_, y:=_, z) is exactly as explicit as case(x, y, _) (it names x 
and y explicitly), with the added drawbacks of
- Confusing the meaning of "_", which (at least in my mind) means "discard".
- Deviating from other languages with pattern matching (which, presumably, also 
have bikeshedded on this point), increasing the surprise level for people who 
are either coming to Python from there, or going from Python to there.
- Requiring extra (weird-looking) syntax for the default case of capturing 
variables.

Again, maybe I'm just having trouble finding good use cases (either that, or I 
have no intuition for programming :P). Let me know if you have some!

Rik

P.S. If I'm out of line or violating etiquette with anything, please let me 
know. I'm open to help.
___
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/N4H42GTG237PBG5B4N6ZF4DQAX4X3HEE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

[Sumana Harihareswara]

A new pip is out. Please see below, upgrade, and let us know if you/your 
users start to have trouble. In particular, we need your feedback on the 
beta of the new dependency resolver, because we want to make it the 
default in the October release.


best,
Sumana Harihareswara, pip project manager


 Forwarded Message 
Subject: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3
Date: Thu, 30 Jul 2020 11:24:58 -0400
From: Sumana Harihareswara 
Reply-To: distutils-...@python.org
Organization: Changeset Consulting
To: pypi-annou...@python.org

On behalf of the Python Packaging Authority, I am pleased to announce 
the release of pip 20.2. Please upgrade for speed improvements, bug 
fixes, and better logging. You can install it by running python -m pip 
install --upgrade pip.


We make major releases each quarter, so this is the first new release 
since 20.1 in April.


NOTICE: This release includes the beta of the next-generation dependency 
resolver. It is significantly stricter and more consistent when it 
receives incompatible instructions, and reduces support for certain 
kinds of constraints files, so some workarounds and workflows may break. 
Please test it with the `--use-feature=2020-resolver` flag. Please see 
our guide on how to test and migrate, and how to report issues

.

The new dependency resolver is *off by default* because it is *not yet
ready for everyday use*.

For release highlights and thank-yous, please see 
 . 
The full changelog is at .


Future:

We plan to make pip's next quarterly release, 20.3, in October 2020. We 
are preparing to change the default dependency resolution behavior and 
make the new resolver the default in pip 20.3.


--
Sumana Harihareswara
project manager for pip, on contract with Python Software Foundation
Changeset Consulting, https://changeset.nyc
___
pypi-announce mailing list -- pypi-annou...@python.org
To unsubscribe send an email to pypi-announce-le...@python.org
https://mail.python.org/mailman3/lists/pypi-announce.python.org/
___
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/7XWTH5PIE3ZLQ32GM7UZQOKMIECTUBJY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

[Steve Dower]

Do you think we should be updating the version of pip bundled with 
Python 3.9 at this stage (for the first RC)?


Similarly, is there a need to update Python 3.8 for its next release?

Thanks,
Steve

On 30Jul2020 2119, Sumana Harihareswara wrote:
A new pip is out. Please see below, upgrade, and let us know if you/your 
users start to have trouble. In particular, we need your feedback on the 
beta of the new dependency resolver, because we want to make it the 
default in the October release.


best,
Sumana Harihareswara, pip project manager


 Forwarded Message 
Subject: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3
Date: Thu, 30 Jul 2020 11:24:58 -0400
From: Sumana Harihareswara 
Reply-To: distutils-...@python.org
Organization: Changeset Consulting
To: pypi-annou...@python.org

On behalf of the Python Packaging Authority, I am pleased to announce 
the release of pip 20.2. Please upgrade for speed improvements, bug 
fixes, and better logging. You can install it by running python -m pip 
install --upgrade pip.


We make major releases each quarter, so this is the first new release 
since 20.1 in April.


NOTICE: This release includes the beta of the next-generation dependency 
resolver. It is significantly stricter and more consistent when it 
receives incompatible instructions, and reduces support for certain 
kinds of constraints files, so some workarounds and workflows may break. 
Please test it with the `--use-feature=2020-resolver` flag. Please see 
our guide on how to test and migrate, and how to report issues
. 



The new dependency resolver is *off by default* because it is *not yet
ready for everyday use*.

For release highlights and thank-yous, please see 
 . 
The full changelog is at .


Future:

We plan to make pip's next quarterly release, 20.3, in October 2020. We 
are preparing to change the default dependency resolution behavior and 
make the new resolver the default in pip 20.3.



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

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Rob Cliffe via Python-Dev]

On 08/07/2020 16:02, Guido van Rossum wrote:

Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.
After all the discussion on the issue, I can still not stop thinking 
that there needs to be a visual distinction between "capture" and 
"match" variables.
Having rules ("plain names are capture, dotted names are match") is one 
more thing to be learnt.  One more bit of mystery when (a near newbie 
is) reading code.


Possible compromise: *two* sigils - one for capture, one for match. Both 
would be optional, only required when the default is not what is wanted, 
but could be added regardless if the author felt it added clarity.


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

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

[Sumana Harihareswara]

Good question. I've asked it in https://github.com/pypa/pip/issues/6536 
because I want to check with other pip maintainers.


On a separate note: the error messaging improvements in 20.2 available 
with the new beta resolver (such as pointing to this conflict resolution 
guide 
https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies ) 
are going to be very helpful to you as you and your users while 
debugging ResolutionImpossible errors. Enjoy! Insamuch as such a 
situation is enjoyable.


--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
___
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/O7UJ7JONBIQQSLUB3XDLOEBVJRPSWLZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Caleb Donovick]

Adding this feature would be a giant quality of life improvement for me and
I really hope it succeeds.  So I have been trying to keep up on the debate
in this and related thread.

While I do want this feature,  I agree with a lot of the issues people are
raising.

First I agree that _ should not be the wildcard symbol.  Or rather the
hobgoblins in my mind think that if _ is to be the wildcard symbol it would
be more consistent with assignment if it was bound to the last value it was
matched with (as should other repeated identifiers) e.g.,

match pt:
   case (x, _, _):
   assert _ == pt[2]

I understand the authors rationalize the decision based on conventions with
the gettext module.  I find these arguments very unconvincing.  It's like
saying the identifier np should be forbidden from appearing in cases
because it's frequently used as the name of numpy.  If there is to be a
wildcard symbol (that does not bind and is repeatable) it should not be a
valid identifier.

Second,  the distinction between a capture and constant value pattern
should be more explicit.  I don't have any great insight into the color of
the shed beyond the numerous suggestions already made (name=, ?name,
etc...), but it  seems quite unintuitive to me that I can't capture into a
namespace nor match a constant without a namespace.  It is also unclear to
me why it would be so terrible to add a new token or abuse an existing one.

> Honestly, it doesn't help the case for `?` that it's been proposed as a
mark for both capture patterns and value patterns (by different people,
obviously :-).

I agree that most of the proposed sheds don't necessarily make it
intuitively clear what is a capture variable vs what is a constant.
However they do give the programmer the ability to choose.

For example if I want to modify the motivating example from the PEP
slightly to copy attributes from one point to another I can't express it
concisely:

def update_point_3d(p: Point3d, pt):
match pt:
case (x, y):
p.x, p.y = x, y
case Point2d(x, y):
p.x, p.y = x, y
...


(Okay I could have just called the original make_point_3d and unpacked the
results but it would require the creation of an unnecessary temporary.)

However if the capture was explicit and any valid target could be used as a
capture variable then I could express this cleanly:

def update_point_3d(p: Point3d, pt):
match pt:
case (p.x=, p.y=):
pass
case Point2d(p.x=, p.y=):
pass
...


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

[Python-Dev] Python code coverage for integration Tests

[Magesh Sundar]

Hi There,

Which is the best tool to run the code coverage for python integration
tests? I tried running with Code Coverage but no data is getting collected
when I run my test using pytest command.

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