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

[Guido van Rossum]

That's a strawman argument. I am done arguing about this.

On Fri, Jul 31, 2020 at 7:47 PM Nick Coghlan  wrote:

>
>
> On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum,  wrote:
>
>> Trust me, the PEP authors are well aware. If we hadn't been from the
>> outset, a hundred different proposals to "deal" with this would have. And
>> many of those proposals actually made it into the list of rejected ideas.
>> Moreover, we rewrote a huge portion of the PEP from scratch as a result
>> (everything from Abstract up to the entire Rationale and Goals section).
>>
>> Apart from your insistence that we "acknowledge" an "inconsistency", your
>> counter-proposal is not so different from the others.
>>
>
> Right, there are several ways the PEP could be adjusted so that assignment
> target syntax and pattern matching syntax had consistent semantics whenever
> they share syntax, just as other name binding syntaxes are already strict
> subsets of the full assignment target syntax. I personally like "Use '?' as
> an explicit constraint expression prefix", but it's far from being the only
> possibility.
>
> But if we don't even agree that common syntax in a name binding context
> should either always mean the same thing, or else be a syntax error, then
> we're not going to agree that there's a problem to be solved in the first
> place.
>
> Let's agree to disagree on the best syntax for patterns
>>
>
> I think our disagreement is more fundamental than that, as I believe there
> should be a common metasyntax for imperative name binding (i.e. everything
> except function parameters) that all actual name binding contexts allow a
> subset of, while the PEP authors feel it's OK to treat pattern matching as
> a completely new design entity that only incidentally shares some common
> syntax with assignment targets.
>
> Prior to PEP 622, the apparent design constraint that I had inferred was
> implicitly met by the fact that all the imperative name binding operations
> accept a subset of the full assignment target syntax, so it's never
> actually come up before whether this is a real design goal for the
> language, or just a quirk of history.
>
> PEP 622 is forcing that question to be answered explicitly, as accepting
> it in its current form would mean telling me, and everyone else that had
> inferred a similar design concept, that we need to adjust our thinking.
>
> I'd obviously prefer it if the PEP chose a different syntax that avoided
> the semantic conflict with assignment for dotted names, but in the absence
> of that, I'd settle for the explicit statement that we're wrong and
> inferred a design principle that never actually existed.
>
> Cheers,
> Nick.
>
>
>
>
>>
>>

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

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

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

[Nick Coghlan]

On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum,  wrote:

> Trust me, the PEP authors are well aware. If we hadn't been from the
> outset, a hundred different proposals to "deal" with this would have. And
> many of those proposals actually made it into the list of rejected ideas.
> Moreover, we rewrote a huge portion of the PEP from scratch as a result
> (everything from Abstract up to the entire Rationale and Goals section).
>
> Apart from your insistence that we "acknowledge" an "inconsistency", your
> counter-proposal is not so different from the others.
>

Right, there are several ways the PEP could be adjusted so that assignment
target syntax and pattern matching syntax had consistent semantics whenever
they share syntax, just as other name binding syntaxes are already strict
subsets of the full assignment target syntax. I personally like "Use '?' as
an explicit constraint expression prefix", but it's far from being the only
possibility.

But if we don't even agree that common syntax in a name binding context
should either always mean the same thing, or else be a syntax error, then
we're not going to agree that there's a problem to be solved in the first
place.

Let's agree to disagree on the best syntax for patterns
>

I think our disagreement is more fundamental than that, as I believe there
should be a common metasyntax for imperative name binding (i.e. everything
except function parameters) that all actual name binding contexts allow a
subset of, while the PEP authors feel it's OK to treat pattern matching as
a completely new design entity that only incidentally shares some common
syntax with assignment targets.

Prior to PEP 622, the apparent design constraint that I had inferred was
implicitly met by the fact that all the imperative name binding operations
accept a subset of the full assignment target syntax, so it's never
actually come up before whether this is a real design goal for the
language, or just a quirk of history.

PEP 622 is forcing that question to be answered explicitly, as accepting it
in its current form would mean telling me, and everyone else that had
inferred a similar design concept, that we need to adjust our thinking.

I'd obviously prefer it if the PEP chose a different syntax that avoided
the semantic conflict with assignment for dotted names, but in the absence
of that, I'd settle for the explicit statement that we're wrong and
inferred a design principle that never actually existed.

Cheers,
Nick.




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

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

[Guido van Rossum]

Trust me, the PEP authors are well aware. If we hadn't been from the
outset, a hundred different proposals to "deal" with this would have. And
many of those proposals actually made it into the list of rejected ideas.
Moreover, we rewrote a huge portion of the PEP from scratch as a result
(everything from Abstract up to the entire Rationale and Goals section).

Apart from your insistence that we "acknowledge" an "inconsistency", your
counter-proposal is not so different from the others.

Let's agree to disagree on the best syntax for patterns.

On Fri, Jul 31, 2020 at 5:21 PM Nick Coghlan  wrote:

>
>
> On Fri., 31 Jul. 2020, 3:14 am Guido van Rossum,  wrote:
>
>> 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."
>>
>
> I don't really like that future possibility either - I think it would be
> much better for PEP 622 to let "_" be a binding throwaway variable as
> normal, and allow a bare "?" as the "match any expression without binding
> it" marker.
>
> But unlike the reuse of attribute assignment syntax for a different
> purpose, it's a conflict that I don't think matters very much (as it's
> incredibly rare to care whether binding "_" actually creates a reference or
> not, so having it bind sometimes and not others isn't likely to present any
> major barriers to learning).
>
>>
>> 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.
>>
>
> That's conceding my point, though: aside from iterable unpacking, the PEP
> isn't currently even trying to keep pattern matching syntax consistent with
> assignment target syntax, as the PEP authors haven't even considered the
> idea of pursuing a higher level of consistency as a design goal.
>
> A section titled "Match patterns are not assignment targets" that explains
> that even though match patterns bind names and do iterable unpacking the
> same way assignment targets do, it is nevertheless incorrect for a reader
> to think of them as assignment targets would address my concern (it
> wouldn't convince me that it is a good idea to view the design problem that
> way, but I would accept that the argument had been heard and addressed in a
> context where the future PEP delegate will necessarily see it).
>
> (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.)
>>
>
> Right, I just use "lvalue" as a shorthand for "syntax that can bind a
> name". All the others are strict subsets of the full assignment target
> syntax, though, mostly falling into either "simple names only" or "simple
> names and iterable unpacking, but no attributes or subscripts". I'll use
> "name binding context" for the full set of those below.
>
> This PEP is the first time it has been proposed to accept valid assignment
> target syntax in a name binding context, but have it mean something
> different.
> The fact that the PEP doesn't even acknowledge that this is a potential
> problem is the biggest part of the problem. If the problem was
> acknowledged, and addressed, the

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

[Nick Coghlan]

On Fri., 31 Jul. 2020, 3:14 am Guido van Rossum,  wrote:

> 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."
>

I don't really like that future possibility either - I think it would be
much better for PEP 622 to let "_" be a binding throwaway variable as
normal, and allow a bare "?" as the "match any expression without binding
it" marker.

But unlike the reuse of attribute assignment syntax for a different
purpose, it's a conflict that I don't think matters very much (as it's
incredibly rare to care whether binding "_" actually creates a reference or
not, so having it bind sometimes and not others isn't likely to present any
major barriers to learning).

>
> 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.
>

That's conceding my point, though: aside from iterable unpacking, the PEP
isn't currently even trying to keep pattern matching syntax consistent with
assignment target syntax, as the PEP authors haven't even considered the
idea of pursuing a higher level of consistency as a design goal.

A section titled "Match patterns are not assignment targets" that explains
that even though match patterns bind names and do iterable unpacking the
same way assignment targets do, it is nevertheless incorrect for a reader
to think of them as assignment targets would address my concern (it
wouldn't convince me that it is a good idea to view the design problem that
way, but I would accept that the argument had been heard and addressed in a
context where the future PEP delegate will necessarily see it).

(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.)
>

Right, I just use "lvalue" as a shorthand for "syntax that can bind a
name". All the others are strict subsets of the full assignment target
syntax, though, mostly falling into either "simple names only" or "simple
names and iterable unpacking, but no attributes or subscripts". I'll use
"name binding context" for the full set of those below.

This PEP is the first time it has been proposed to accept valid assignment
target syntax in a name binding context, but have it mean something
different.
The fact that the PEP doesn't even acknowledge that this is a potential
problem is the biggest part of the problem. If the problem was
acknowledged, and addressed, then readers could evaluate the merits of PEP
authors' arguments against it.

As it is, unless the reader identifies the conflict on their own, they may
not realise what is bugging them about it, and make the same mistake I
initially did and believe it's the binding syntax that's inconsistent (when
that's actually entirely consistent with for loops, for example), rather
than the constraint lookup syntax (which has never previously been allowed
in a name binding context).

We know the PEP authors don't see patterns as assignment targets beyond
sharing the iterable unpacking syntax, but my concern is for everyone
*else* that is either learning pattern matching as an existing Python
developer, or learning Python in general aft

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

[Rob Cliffe via Python-Dev]

On 31/07/2020 17:24, Rik de Kort via Python-Dev wrote:
1. Semantic operator overloading in generic contexts is very different 
from this use case. It's surrounded by a clear context.
2. Python programmer intuition varies across python programmers, and I 
would find it hella unintuitive if I had to explicitly capture every 
variable. I just want to write down what the thing looks like and have 
the interpreter figure out the correct bindings. Extra binding syntax 
will get in the way rather than be helpful.


Until you want to do something slightly different, and the interpreter's 
choice is not what you want.


Python Dev  wrote:

+10. See

https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262
for concrete evidence where another semantically inconsistent
operator overloading caused trouble and what Stroustroup has to
say on the matter.


On 31.07.2020 13:42, Larry Hastings wrote:





On 7/31/20 12:36 AM, Tobias Kohn wrote:

And since pattern matching is really
 a new feature to be introduced to Python, a feature that can
 be seen in different lights, there is no 'Python-Programmer
 intuition' that would apply in this case.


It's not fair to say "intuition doesn't apply because it's new
syntax".  There are plenty of examples of intuition serving a
Python programmer well when encountering new syntax.  A Python
programmer's intuition is informed by existing syntax and
conventions in the language.  When they see a new construct,
its similarity to existing constructs can make understanding
the new syntax quite intuitive indeed.

Take for example list comprehensions.  Python 1 programmers
hadn't seen

a = [x for x in y]


But they knew what square brackets meant in that context, it
meant "creates a new list".  And they knew what "for x in y"
meant, that meant iteration.  Understanding those separate two
concepts, a Python 1 programmer would be well on their way to
guessing what the new syntax meant--and they'd likely be
right.  And once they understood list comprehensions, the
first time they saw generator expressions and set and dict
comprehensions they'd surely intuit what those did immediately.


The non-intuitiveness of PEP 622, as I see it, is that it
repurposes what looks like existing Python syntax but
frequently has wholly different semantics.  For example, a
"class pattern" looks like it's calling a function--perhaps
instantiating an object?--but the actual semantics and
behavior is very different.  Similarly, a "mapping pattern"
looks like it's instantiating a dict, but it does something
very different, and has unfamiliar and seemingly arbitrary
rules about what is permitted, e.g. you can't use full
expressions or undotted-identifiers when defining a key.  Add
the "capture pattern" to both of these, and a Python
programmer's intuition about what this syntax traditionally
does will be of little help when encountering a PEP 622 match
statement for the first time.


Cheers,





//arry/




___

Python-Dev mailing list --python-dev@python.org  


To unsubscribe send an email topython-dev-le...@python.org  


https://mail.python.org/mailman3/lists/python-dev.python.org/

Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/

Code of Conduct:http://python.org/psf/codeofconduct/


-- 
 Regards,

 Ivan


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


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/54TQPNOPDIPTCBBY6XJVI5RBSUWUQ6XH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2020-07-24 - 2020-07-31)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7584 (+15)
  closed 45608 (+48)
  total  53192 (+63)

Open issues with patches: 3084 


Issues opened (48)
==

#41388: IDLE fails to detect corresponding opening parenthesis
https://bugs.python.org/issue41388  opened by Alexey Burdin

#41390: Errors and warnings on generate bytecode files
https://bugs.python.org/issue41390  opened by kloczek

#41391: Make test_unicodedata pass when running without network
https://bugs.python.org/issue41391  opened by yan12125

#41394: Document '_' in interpreter tutorial
https://bugs.python.org/issue41394  opened by wyz23x2

#41395: pickle and pickletools cli interface doesn't close input and o
https://bugs.python.org/issue41395  opened by xtreak

#41396: pystate.c:_PyCrossInterpreterData_Release() does not clear py 
https://bugs.python.org/issue41396  opened by Tomasz Pytel

#41397: Restore default implementation of __ne__ in Counter
https://bugs.python.org/issue41397  opened by serhiy.storchaka

#41398: cgi module, parse_multipart fails
https://bugs.python.org/issue41398  opened by Magnus Johnsson

#41399: Add stacklevel support for exceptions
https://bugs.python.org/issue41399  opened by wyz23x2

#41400: Remove references to nonexisting __ne__ methods
https://bugs.python.org/issue41400  opened by serhiy.storchaka

#41401: Using non-ascii that require UTF-8 breaks AIX testing
https://bugs.python.org/issue41401  opened by Michael.Felt

#41402: email: ContentManager.set_content calls nonexistent method enc
https://bugs.python.org/issue41402  opened by joreiff

#41403: Uncaught AttributeError in unittest.mock._get_target
https://bugs.python.org/issue41403  opened by webisteme

#41404: IDLE: test iomenu
https://bugs.python.org/issue41404  opened by terry.reedy

#41406: BufferedReader causes Popen.communicate losing the remaining o
https://bugs.python.org/issue41406  opened by Frost Ming

#41410: Opening a file in binary mode makes a difference on all platfo
https://bugs.python.org/issue41410  opened by bkline

#41411: Improve and consolidate f-strings docs
https://bugs.python.org/issue41411  opened by ezio.melotti

#41412: After installation on Windows7, 64bit Python 3.9.0b5 reports "
https://bugs.python.org/issue41412  opened by Martin Borus

#41413: IDLE: exit at input() prompt is not complete
https://bugs.python.org/issue41413  opened by IrvKalb

#41415: duplicated signature of dataclass in help()
https://bugs.python.org/issue41415  opened by sir-sigurd

#41416: Restore default implementation of __ne__ in mixins Set and Map
https://bugs.python.org/issue41416  opened by serhiy.storchaka

#41419: Path.mkdir and os.mkdir don't respect setgid if its parent is 
https://bugs.python.org/issue41419  opened by Xophmeister

#41420: Academic Free License v. 2.1 link is not found and is obsolete
https://bugs.python.org/issue41420  opened by DmytroLitvinov

#41421: Random.paretovariate sometimes raises ZeroDivisionError for sm
https://bugs.python.org/issue41421  opened by David MacIver

#41422: C Unpickler memory leak via memo
https://bugs.python.org/issue41422  opened by kale-smoothie

#41423: `multiprocessing.Array` and `multiprocessing.managers.SyncMana
https://bugs.python.org/issue41423  opened by jthistle

#41424: [tkinter] Grammatical error in "Packer" docs
https://bugs.python.org/issue41424  opened by brett.cannon

#41425: [tkinter] "Coupling Widget Variables" example missing code
https://bugs.python.org/issue41425  opened by brett.cannon

#41428: PEP 604 -- Allow writing union types as X | Y
https://bugs.python.org/issue41428  opened by maggiemoss

#41429: Let fnmatch.filter accept a tuple of patterns
https://bugs.python.org/issue41429  opened by adelfino

#41430: Document C docstring behavior
https://bugs.python.org/issue41430  opened by jameshcorbett

#41431: Optimize dict_merge for copy
https://bugs.python.org/issue41431  opened by inada.naoki

#41432: IDLE: Handle bad highlight tab color config
https://bugs.python.org/issue41432  opened by terry.reedy

#41433: Logging libraries BufferingHandler flushed twice at shutdown
https://bugs.python.org/issue41433  opened by adamist521

#41434: IDLE: Option to warn user on "Run Module" if file is not Pytho
https://bugs.python.org/issue41434  opened by wyz23x2

#41435: Allow to retrieve ongoing exception handled by every threads
https://bugs.python.org/issue41435  opened by jd

#41437: SIGINT blocked by socket operations like recv on Windows
https://bugs.python.org/issue41437  opened by zmwangx

#41438: TimeoutError behavior changes on async.wait_for from python3.7
https://bugs.python.org/issue41438  opened by Yerken Tussupbekov

#41439: some test cases in test_uuid.py and test_ssl.py fail on some o
https://bugs.python.org/issue41439  opened by pxinwr

#41440: os.cpu_count doesn't work on Vx

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

[Rik de Kort via Python-Dev]

1. Semantic operator overloading in generic contexts is very different from 
this use case. It's surrounded by a clear context.
2. Python programmer intuition varies across python programmers, and I would 
find it hella unintuitive if I had to explicitly capture every variable. I just 
want to write down what the thing looks like and have the interpreter figure 
out the correct bindings. Extra binding syntax will get in the way rather than 
be helpful.
Python Dev  wrote:
“+10. See 
https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262
 for concrete evidence where another semantically inconsistent operator 
overloading caused trouble and what Stroustroup has to say on the matter.
 

On 31.07.2020 13:42, Larry Hastings wrote:

“

 

On 7/31/20 12:36 AM, Tobias Kohn wrote:“And since pattern matching is really
 a new feature to be introduced to Python, a feature that can
 be seen in different lights, there is no 'Python-Programmer
 intuition' that would apply in this case.
 ”

It's not fair to say "intuition doesn't apply because it's new syntax".  There 
are plenty of examples of intuition serving a Python programmer well when 
encountering new syntax.  A Python programmer's intuition is informed by 
existing syntax and conventions in the language.  When they see a new 
construct, its similarity to existing constructs can make understanding the new 
syntax quite intuitive indeed.

Take for example list comprehensions.  Python 1 programmers hadn't seen

“a = [x for x in y]
 ”

But they knew what square brackets meant in that context, it meant "creates a 
new list".  And they knew what "for x in y" meant, that meant iteration.  
Understanding those separate two concepts, a Python 1 programmer would be well 
on their way to guessing what the new syntax meant--and they'd likely be right. 
 And once they understood list comprehensions, the first time they saw 
generator expressions and set and dict comprehensions they'd surely intuit what 
those did immediately.
 

The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks 
like existing Python syntax but frequently has wholly different semantics.  For 
example, a "class pattern" looks like it's calling a function--perhaps 
instantiating an object?--but the actual semantics and behavior is very 
different.  Similarly, a "mapping pattern" looks like it's instantiating a 
dict, but it does something very different, and has unfamiliar and seemingly 
arbitrary rules about what is permitted, e.g. you can't use full expressions or 
undotted-identifiers when defining a key.  Add the "capture pattern" to both of 
these, and a Python programmer's intuition about what this syntax traditionally 
does will be of little help when encountering a PEP 622 match statement for the 
first time.
 

Cheers,
 


 

/arry
 



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to 
python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
Code of Conduct: http://python.org/psf/codeofconduct/
-- 
 Regards,
 Ivan””

[attachment.txt]
___
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/4L7LXGVYTMHPF5I54Z2DVSIKSL75ES6H/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Ivan Pozdeev via Python-Dev]

+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for 
concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter.


On 31.07.2020 13:42, Larry Hastings wrote:



On 7/31/20 12:36 AM, Tobias Kohn wrote:


And since pattern matching is really
a new feature to be introduced to Python, a feature that can
be seen in different lights, there is no 'Python-Programmer
intuition' that would apply in this case.

It's not fair to say "intuition doesn't apply because it's new syntax".  There are plenty of examples of intuition serving a Python 
programmer well when encountering new syntax.  A Python programmer's intuition is informed by existing syntax and conventions in the 
language.  When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.


Take for example list comprehensions.  Python 1 programmers hadn't seen

a = [x for x in y]

But they knew what square brackets meant in that context, it meant "creates a new list".  And they knew what "for x in y" meant, that 
meant iteration.  Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new 
syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and 
set and dict comprehensions they'd surely intuit what those did immediately.


The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly 
different semantics.  For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual 
semantics and behavior is very different.  Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very 
different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or 
undotted-identifiers when defining a key.  Add the "capture pattern" to both of these, and a Python programmer's intuition about what this 
syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.


Cheers,


//arry/


___
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/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
Code of Conduct: http://python.org/psf/codeofconduct/
--
Regards,
Ivan
___
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/CGJFIX6APEH76NASM6KDFF5GUDEZRK5T/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Larry Hastings]

On 7/31/20 12:36 AM, Tobias Kohn wrote:


And since pattern matching is really
a new feature to be introduced to Python, a feature that can
be seen in different lights, there is no 'Python-Programmer
intuition' that would apply in this case.

It's not fair to say "intuition doesn't apply because it's new syntax".  
There are plenty of examples of intuition serving a Python programmer 
well when encountering new syntax.  A Python programmer's intuition is 
informed by existing syntax and conventions in the language.  When they 
see a new construct, its similarity to existing constructs can make 
understanding the new syntax quite intuitive indeed.


Take for example list comprehensions.  Python 1 programmers hadn't seen

   a = [x for x in y]

But they knew what square brackets meant in that context, it meant 
"creates a new list".  And they knew what "for x in y" meant, that meant 
iteration.  Understanding those separate two concepts, a Python 1 
programmer would be well on their way to guessing what the new syntax 
meant--and they'd likely be right. And once they understood list 
comprehensions, the first time they saw generator expressions and set 
and dict comprehensions they'd surely intuit what those did immediately.


The non-intuitiveness of PEP 622, as I see it, is that it repurposes 
what looks like existing Python syntax but frequently has wholly 
different semantics.  For example, a "class pattern" looks like it's 
calling a function--perhaps instantiating an object?--but the actual 
semantics and behavior is very different. Similarly, a "mapping pattern" 
looks like it's instantiating a dict, but it does something very 
different, and has unfamiliar and seemingly arbitrary rules about what 
is permitted, e.g. you can't use full expressions or 
undotted-identifiers when defining a key. Add the "capture pattern" to 
both of these, and a Python programmer's intuition about what this 
syntax traditionally does will be of little help when encountering a PEP 
622 match statement for the first time.


Cheers,


//arry/

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

[Python-Dev] Re: Python code coverage for integration Tests

[Tal Einat]

Hello Magesh,

This mailing list is for discussing the development of the Python language
itself.

For questions regarding developing with Python, please try other channels,
such as the #python IRC channel on freenode
 or the python-list
 mailing list.

Good luck,
- Tal Einat

On Fri, Jul 31, 2020 at 8:07 AM Magesh Sundar 
wrote:

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

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

[Tobias Kohn]

 Hi Caleb,

I will only answer to the second part, as the wildcard issue has
been brought up and discussed time and again, and the `np`
analogue is quite a stretch and far-fetched, really.

 One thing that stood out a bit to me as I feel to have seen it a
couple of times is the question of intuition, so I will add a few
more general thoughts to that...

 > [...] but it  seems quite unintuitive to me [...]


[...] don't necessarily make it intuitively clear [...]


  

 Intuition (or lack thereof) has already been brought forward
as an argument a couple of times.  I would just like to briefly
point out that there is no such thing as universal intuition in
the field of programming.  We all have different training,
skills, preferences and experiences, which make up what
we call 'intuition'.  But what is intuitive is usually something
completely different to C-programmer than to a Haskell- or
Lisp-Programmer, say.  And since pattern matching is really
a new feature to be introduced to Python, a feature that can
be seen in different lights, there is no 'Python-Programmer
intuition' that would apply in this case.

As for beginners, virtually every part of programming is
unintuitive at first.  Even something innocuous-looking like
assignment is often reason for confusion because `3 + 4 = x`
would probably be more 'intuitive'.  But there is good reason
with regards to the bigger picture to stick to `x = 3 + 4`.

A Python-programmer (at any level) not familiar with pattern
matching will most likely not understand all subtlety of the
syntax---but this is alos true of features like `async` or the
`/` in parameters, say.  I would argue, though, that the clear
choice of keywords allow anyone to quickly look pattern
matching up and get informed on what it does.  So, we do
not need to come with something that is entirely 'intuitive'
and 'self-evident'.  But by sticking to common convention
like `_` as wildcard, we can help quickly build the correct
intuition.

In your examples, for instance, it is perfectly obvious to me
that you cannot directly assign to attributes and it would in
fact look very weird to my eyes if you could.  Your use case
is quite similar to initialisers and you are arguing that you
would like being able to write:
```
CLASS Point:
    DEF __init__(self, self.x, self.y):
    PASS
```
rather than the more verbose:
```
CLASS Point:
    DEF __init__(self, x, y):
    self.x, self.y = x, y
```
I do not think that this would be a good idea for either
parameters or patterns.  After all, pattern matching is
*/not/* assignment, even though it is related to it, of
course.

Kind regards,
Tobias

Quoting 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  

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

[Larry Hastings]

On 7/30/20 4:31 PM, Caleb Donovick wrote:
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 ... |



I like this proposal, using = to explicitly specify when capturing.  I 
see it as a big improvement over the current PEP where dotted names are 
never assigned to and non-dotted names usually are.  It also leads 
directly to an alternate proposal for the wildcard pattern: a "=" not 
prefaced with an lvalue.  This has the benefit of having no conflict 
with i18n, etc.



Explicit is better than implicit,


//arry/

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