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

[Federico Salerno]

On 13/07/2020 19:17, Guido van Rossum wrote:
I find it debatable that we should have this at all, since there are 
other interpretations possible, and honestly I doubt that it’s a 
common use case. That’s why we’re holding off.


Fair enough. All it would do would be save code in a guard condition 
after all.



Thanks for offering, but we’ve got that under control.

I wasn't trying to imply otherwise. :)
___
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/UABDA4IMDLUT63VHDUM5XGEAAZPI7EOC/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Mark Shannon]

Hi,

As I wrote in an earlier email:


For a PEP to succeed it needs to show two things.

1. Exactly what problem is being solved, or need is to be fulfilled, and that 
is a sufficiently large problem, or need, to merit the proposed change.

2. That the proposed change is the best known solution for the problem being 
addressed.

IMO, PEP 622 fails on both counts.



This email addresses point 1 (for version 2).

Abstract


Why the use of "shape" in "scare quotes"?
It worries me that the abstract can't explain what PEP 622 does directly.

Could you use a real example in the abstract?
Using a contrived example like this seems like a straw man.
It feels like it is constructed to favour the PEP, whilst being unlike 
any real code.


Rationale and Goals
---

Python programs frequently need to handle data which varies in type, presence of attributes/keys, or number of elements. Typical examples are operating on nodes of a mixed structure like an AST, handling UI events of different types, processing structured input (like structured files or network messages), or “parsing” arguments for a function that can accept different combinations of types and numbers of parameters. 


AST, and UI objects usually (pretty much always) form a class hierarchy, 
making is easy to add utility matching methods to the base class.
Where matching *might* have some value is when unrelated types are 
involved, but you need to show that enhanced destructuring would be 
insufficient.



In fact, the classic 'visitor' pattern is an example of this, done in an OOP 
style -- but matching makes it much less tedious to write.


This might be true of the "classic" visitor pattern, but that's a straw man.
The Python visitor pattern is a joy to use.
Each case gets its own self contained method, clearly named, which is 
much better than a giant `match` statement.



Much of the code to do so tends to consist of complex chains of nested if/elif 
statements, including multiple calls to len(), isinstance() and 
index/key/attribute access. Inside those branches users sometimes need to 
destructure the data further to extract the required component values, which 
may be nested several objects deep.


There seem to be three things you want to enhance here:
Unpacking; to avoid calls to `len`
Type checking; to avoid calls to `isinstance`.
To avoiding nesting by using complex lvalues.

You fail to justify why the first two cannot be handled separately with 
much simpler extensions to the language and why complex lvalues are 
better than nesting.


The examples


There are only three examples, none of which are compelling.
In fact, two of them serve as a warning against the additional 
complexity this PEP entails.


Django example:
'''

Saves two lines of code, but introduces two bugs!
(Assuming that the original behavior should be preserved)

If the authors of the PEP cannot use this feature correctly in the first 
example they give, what chance do the rest of us have?



is_tuple example:
'

(Repeating my earlier email)
Python's support for OOP provides an alternative to ADTs.
For example, by adding a simple "matches" method to Node and Leaf, 
`is_tuple` can be rewritten as something like:


def is_tuple(node):
if not isinstance(node, Node):
return False
return node.matches("(", ")") or node.matches("(", ..., ")")


The "switch on http response codes" example.


This clearly demonstrates the value of symbolic constants for 
readability and the serious flaw in the PEP that I cannot use them.


I really don't see you how you can claim that
`case 406:`
is more readable than
`elif response == HTTP_UPGRADE_REQUIRED:`
?

Preventing the use of symbolic constants or other complex rvalues is a 
impairment to usability.

Silently failing when symbolic constants are used is terrible.

I do see the value of a `switch` statement for repeated tests against 
the same value; its intent is clearer than repeated `elif`s. But there 
is no need for it to be so hard to use.



Cheers,
Mark.


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

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

[Larry Hastings]

On 7/12/20 3:20 PM, Guido van Rossum wrote:
On Sun, Jul 12, 2020 at 12:12 PM Larry Hastings > wrote:


Having thought about it some, I propose it'd be acceptable to do
dead store optimization if-and-only-if optimizations are
explicitly enabled, e.g. with "-O".  Allowing explicitly-enabled
optimizations to observably affect runtime behavior does have some
precedent, e.g. "-OO" which breaks doctest, docopt, etc.  It'd be
a shame if the existence of locals() et al meant Python could
never ever perform dead store optimization.


Assuming you're still talking about how to implement wildcards, it 
really sounds like you're willing to add a lot of complexity just to 
have a "consistent" treatment of `_`. But why would you care so much 
about that consistency?


I'm a fan of the Zen guidance here: "special cases aren't special enough 
to break the rules".


More on this topic in a moment--rather than reorder paragraphs, let me 
return to this below.



Using the same character in patterns makes intuitive sense to anyone 
who is familiar with this convention in Python. Furthermore it also 
makes sense to anyone who is familiar with patterns in other 
languages: *all* languages with structural pattern matching that we 
found at uses `_` -- C#, Elixir, Erlang, Scala, Rust, F#, Haskell, 
Mathematica, OCaml, Ruby, and Swift. (That's a much stronger precedent 
than the use of `?` in shell and regular expressions IMO. :-)


Python hasn't been afraid to go its own way syntactically in the past.  
Consider the conditional (ternary) operator.  Most languages I've 
encountered with a conditional operator just copy C's syntax, with '?' 
and ':' (PHP, C#, Java).  Some languages don't need a conditional 
operator, as their existing flow control already works just fine (FORTH, 
Rust).  Python's syntax for the conditional operator was neither, and 
was AFAIK unique--but this syntax was judged the most Pythonic, so it won.


Similarly, AFAIK Python's "None" is unique.  Most other languages I've 
seen use the word "null", albeit with varying capitalization.


So I'm unconcerned about Python using a different token for the wildcard 
pattern.  Python already doesn't look like other languages, Python's 
proposed syntax for pattern matching isn't exactly like the pattern 
matching syntax of other languages.  I don't understand why it's so 
important that it look like other languages in this one specific respect.


As for leveraging the convention of using '_' for values you don't care 
about in Python--that's actually why I /don't/ like it as the wildcard 
pattern.  To date, everyone who uses '_' understands it's just an 
identifier, no different from any other identifier.  I imagine I18N 
programmers avoid this convention for exactly that reason--there's 
nothing special about '_', so they need to take care to not overwrite or 
occlude it with a don't-care value.


However, if I understand PEP 622 correctly, the places you use '_' as 
the wildcard pattern are also places where you could put an identifier.  
But in this one context, '_' doesn't behave like the other identifiers, 
even though in every other context in Python it still does.  This is the 
"special case" that "breaks the rules" I alluded to above.


Consistency with the longstanding semantics of '_', and consistency with 
other identifiers, is much more important to me than consistency with 
other languages for the pattern matching wildcard token.



Using `?` as the wildcard has mostly disadvantages: it requires 
changes to the tokenizer, it could conflict with other future uses of 
`?` (it's been proposed for type annotations as a shorter version of 
Optional, and there's PEP 505, which I think isn't quite dead yet), 
and Python users have no pre-existing intuition for its meaning.


One reason I prefer '?' for the wildcard pattern is precisely /because/ 
users have no pre-existing intuition as to its meaning.  Unlike '_', the 
user would have no preconceived notion about its semantics to unlearn.  
Also, it doesn't behave like an identifier, and accordingly it doesn't 
look like an identifier.  This strikes me as harmonious.


Is changing the tokenizer to support '?' as a token a big deal? You 
mention two other existing proposals to use it as a token--surely this 
is a bridge we'll have to cross sooner or later.



My goal in starting this discussion was to see if we could find a 
compromise everyone could live with.  People who want to use '_' for 
wildcard pattern could do so, people who didn't like '_' having a 
special meaning in this one context would be appeased. The message I'm 
getting is "this compromise won't work".  Okay, fair enough.  I don't 
plan to pursue it any further.



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

[Python-Dev] BPO-41182 - Update

[Abhijeet Kasurde]

Hi Team,

I am waiting for a review on https://github.com/python/cpython/pull/21257.

It would be great if someone can take a look at it and move PR forward.
Thanks in advance.

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

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

[Jim J. Jewett]

Larry Hastings wrote:

> As for leveraging the convention of using '_' for values you don't care 
> about in Python--that's actually why I /don't/ like it as the wildcard 
> pattern.  To date, everyone who uses '_' understands it's just an 
> identifier, no different from any other identifier.

Not quite... I understand it more like a file in /tmp 
I don't use it for anything I will want later, just in case.

> However, if I understand PEP 622 correctly, the places you use '_' as 
> the wildcard pattern are also places where you could put an identifier.  
> But in this one context, '_' doesn't behave like the other identifiers, 
> even though in every other context in Python it still does.  This is the 
> "special case" that "breaks the rules" I alluded to above.
> Consistency with the longstanding semantics of '_', and consistency with 
> other identifiers, is much more important to me than consistency with 
> other languages for the pattern matching wildcard token.

If a normal variable name is re-used, I would expect it to have the same 
meaning.

I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been 
postponed, but it could still happen later, and it would be a problem if that 
ever became legal without requiring the two bindings to match.  I do NOT assume 
that they will match if the variable happens to be _, though I suppose others 
might.

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

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

[Tobias Kohn]

Hi Mark,

Thank you for your message.  I might be able to answer some of the  
questions and also address some issues with the underlying assumptions  
in your email---after all, we would most certainly want to avoid  
discussing and reasoning about straw men, as you yourself have  
repeatedly pointed out.



Why the use of "shape" in "scare quotes"?


Because the `shape' of an object is not something that is a  
well-defined term, but rather addresses the intuitive understanding to  
explain what we are talking about.  It is usually the intention of the  
abstract to give a rough overview, before delving into the details and  
more formal descriptions.


Using a contrived example like this seems like a straw man.  It  
feels like it is constructed to favour the PEP, whilst being unlike  
any real code.


It is a trait of many (good) tutorials to present a new structure with  
an example that highlights its feature in an approachable way rather  
than coming up with `real code'---particularly given that real code is  
always surrounded by a larger context, which rather clouds any  
understanding.  And it would only be a straw man had we constructed a  
contrived example of unrealistic code that we then showed to be  
simplified by pattern matching.  That's not the case: it really is  
just a simple educational example to present the idea.


BTW: as a matter of course, it is constructed in favour of the PEP!


There seem to be three things you want to enhance here:
Unpacking; to avoid calls to `len`
Type checking; to avoid calls to `isinstance`.
To avoiding nesting by using complex lvalues.


Actually, no.  Pattern matching is not about _avoiding_ anything, it  
is about a more concise syntax.  The suggestion that we wanted to  
avoid calls to `len` or `isinstance` is similar to the idea of using a  
lambda to avoid a function.  The objective of pattern matching is to  
introduce a more succinct and readable way to express structure.  It's  
all still there but we want to focus on the structure rather than  
`isinstance` calls.


Pattern matching already exists in some limited way in Python.  Even  
today you can write:

  `a, b = value`

instead of:
  `a = value[0]
   b = value[1]`
   
The idea of this is, of course, not so much about avoiding item  
access, but about having a more concise syntax for it.  Moreover,  
saying this only saves a single line and is therefore rather useless  
is quite beside the point.  It is about a better representation of  
what the code is supposed to do and not about saving lines.



Saves two lines of code, but introduces two bugs!
(Assuming that the original behavior should be preserved)


Thank you for pointing out the bug in our example.  This highlights,  
however, rather the difficulty of refactoring (did I already mention  
the issue of the 'context' that real code is embedded in?), than any  
shortcoming of pattern matching as a tool.  And by the way:  
constructive critisism would perhaps include explicitly naming the two  
bugs.


For example, by adding a simple "matches" method to Node and Leaf,  
`is_tuple` can be rewritten as something like:


This assumes that you have full control over the entire code.  But if  
you are using some third-party library, you cannot "simply add a  
`matches` method" (without some substantial trickery).  Moreover,  
there is quite some work needed to define such a `matches` function as  
you propose it (including support for the ellipsis as wildcard).  In  
effect, you would have to implement large parts of the pattern  
matching for just this simple example.  Whereas we believe that it has  
merit enough to have the compiler do it for a wide range of possible  
use cases.



I really don't see you how you can claim that
`case 406:`
is more readable than
`elif response == HTTP_UPGRADE_REQUIRED:`
?
Preventing the use of symbolic constants or other complex rvalues is  
a impairment to usability.


First, let me quote what the PEP has to say on that exact example:

Although this will work, it's not necessarily what the proposal is  
focused on.


Moreover, it is usually a good idea to put constants into a separate  
namespace that further describes their meaning and intended use.  And  
that is fully supported by the syntax as proposed in the PEP.

```
match response.status:
    case HTTP_RESPONSE.UPGRADE_REQUIRED:
    ...
```


For a PEP to succeed it needs to show two things.

1. Exactly what problem is being solved, or need is to be fulfilled,  
and that is a sufficiently large problem, or need, to merit the  
proposed change.


2. That the proposed change is the best known solution for the  
problem being addressed.


IMO, PEP 622 fails on both counts.


This seems fair enough as far as the two issues are concerned.  It  
might seem indeed as if pattern matching does not add anything that  
could not be done already in Python.  Part of the problem is that  
pattern matching starts to really shine when the objects and data ge

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

[Ethan Furman]

On 07/14/2020 09:22 AM, Jim J. Jewett wrote:

Larry Hastings wrote:


As for leveraging the convention of using '_' for values you don't care
about in Python--that's actually why I /don't/ like it as the wildcard
pattern.  To date, everyone who uses '_' understands it's just an
identifier, no different from any other identifier.

However, if I understand PEP 622 correctly, the places you use '_' as
the wildcard pattern are also places where you could put an identifier.
But in this one context, '_' doesn't behave like the other identifiers,
even though in every other context in Python it still does.  This is the
"special case" that "breaks the rules" I alluded to above.
Consistency with the longstanding semantics of '_', and consistency with
other identifiers, is much more important to me than consistency with
other languages for the pattern matching wildcard token.


Looking at other languages for inspiration is great, but like Larry I think we 
should make sure our constructs fit with Python, not with them.
 

I know that "case x, x:" as shorthand for "case x, __x if x == __x:" has been 
postponed, but it could still happen later, and it would be a problem if that ever became legal 
without requiring the two bindings to match.  I do NOT assume that they will match if the variable 
happens to be _, though I suppose others might.


If we use `?` instead of `_`, then repeated `?` won't be a problem, and 
repeated `_` should be disallowed.

Since `_` is a normal variable name, the requirement for their values to match (when that 
is finally implemented) would make sense, and shouldn't be a burden to remember given 
that that the "don't care" symbol is a `?`.

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

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

[Mark Shannon]

Hi Tobias,

In future, could you avoid editing emails when replying to them?
A lot of context can get lost.

On 14/07/2020 5:25 pm, Tobias Kohn wrote:

Hi Mark,

Thank you for your message.  I might be able to answer some of the 
questions and also address some issues with the underlying assumptions 
in your email---after all, we would most certainly want to avoid 
discussing and reasoning about straw men, as you yourself have 
repeatedly pointed out.



 > Why the use of "shape" in "scare quotes"?

Because the `shape' of an object is not something that is a well-defined 
term, but rather addresses the intuitive understanding to explain what 
we are talking about.  It is usually the intention of the abstract to 
give a rough overview, before delving into the details and more formal 
descriptions.


You ignore my point about explaining PEP 622 directly. Sure, the 
abstract must give a high level overview, but it should be able to do 
that without so much hand waving.





 > Using a contrived example like this seems like a straw man.  It feels 
like it is constructed to favour the PEP, whilst being unlike any real code.


It is a trait of many (good) tutorials to present a new structure with 
an example that highlights its feature in an approachable way rather 
than coming up with `real code'---particularly given that real code is 
always surrounded by a larger context, which rather clouds any 
understanding.  And it would only be a straw man had we constructed a 
contrived example of unrealistic code that we then showed to be 
simplified by pattern matching.  That's not the case: it really is just 
a simple educational example to present the idea.


The example given in the PEP does seems like a "contrived example of 
unrealistic code", as you put it. Is there real code like this?




BTW: as a matter of course, it is constructed in favour of the PEP!


 > There seem to be three things you want to enhance here:
 > Unpacking; to avoid calls to `len`
 > Type checking; to avoid calls to `isinstance`.
 > To avoiding nesting by using complex lvalues.

Actually, no.  Pattern matching is not about _avoiding_ anything, it is 
about a more concise syntax.  The suggestion that we wanted to avoid 
calls to `len` or `isinstance` is similar to the idea of using a lambda 
to avoid a function.  The objective of pattern matching is to introduce 
a more succinct and readable way to express structure.  It's all still 
there but we want to focus on the structure rather than `isinstance` calls.


I should have been clearer. Avoiding *explicit* calls to `len` and 
`isinstance`. Yes, the pattern matching syntax is more concise in some 
circumstances, but there still needs to be justification why a 
combination of simpler language changes is insufficient.




Pattern matching already exists in some limited way in Python.  Even 
today you can write:

   `a, b = value`


I think most of us are aware of unpacking in Python ;)



instead of:
   `a = value[0]
    b = value[1]`

The idea of this is, of course, not so much about avoiding item access, 
but about having a more concise syntax for it.  Moreover, saying this 
only saves a single line and is therefore rather useless is quite beside 
the point.  It is about a better representation of what the code is 
supposed to do and not about saving lines.


How do you quantify "better representation" then?




 > Saves two lines of code, but introduces two bugs!
 > (Assuming that the original behavior should be preserved)

Thank you for pointing out the bug in our example.  This highlights, 
however, rather the difficulty of refactoring (did I already mention the 
issue of the 'context' that real code is embedded in?), than any 
shortcoming of pattern matching as a tool.  And by the way: constructive 
critisism would perhaps include explicitly naming the two bugs.


I'm not sure it would be more constructive, this is not a bug report or 
code review after all.

The point I am making is this:
It is far too easy to make mistakes using the constructs proposed in PEP 
622.





 > For example, by adding a simple "matches" method to Node and Leaf, 
`is_tuple` can be rewritten as something like:


This assumes that you have full control over the entire code.  But if 
you are using some third-party library, you cannot "simply add a 
`matches` method" (without some substantial trickery).  Moreover, there 
is quite some work needed to define such a `matches` function as you 
propose it (including support for the ellipsis as wildcard).  In effect, 
you would have to implement large parts of the pattern matching for just 
this simple example.  Whereas we believe that it has merit enough to 
have the compiler do it for a wide range of possible use cases.


You wouldn't have to implement large parts of the pattern matching,
because this would be specific to one class. There are only two or three 
cases to deal with.
If you don't have access to the original source, then it can be made a 
function, no

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

[Ethan Furman]

On 07/14/2020 11:05 AM, Mark Shannon wrote:

On 14/07/2020 5:25 pm, Tobias Kohn wrote:

On 07/14/2020, Mark Shannon wrote:



In future, could you avoid editing emails when replying to them?
A lot of context can get lost.


I appreciate posters who take the time to trim the parts of an email that they 
are not replying to.


Why the use of "shape" in "scare quotes"?


Because the `shape' of an object is not something that is a well-defined term, 
but rather addresses the intuitive understanding to explain what we are talking 
about.  It is usually the intention of the abstract to give a rough overview, 
before delving into the details and more formal descriptions.


You ignore my point about explaining PEP 622 directly. Sure, the abstract must 
give a high level overview, but it should be able to do that without so much 
hand waving.


I find the PEP abstract concrete enough.  Perhaps you could write a replacement 
that you think does a better job?


Actually, no.  Pattern matching is not about _avoiding_ anything, it is about a 
more concise syntax.  The suggestion that we wanted to avoid calls to `len` or 
`isinstance` is similar to the idea of using a lambda to avoid a function.  The 
objective of pattern matching is to introduce a more succinct and readable way 
to express structure.  It's all still there but we want to focus on the 
structure rather than `isinstance` calls.


I should have been clearer. Avoiding *explicit* calls to `len` and 
`isinstance`. Yes, the pattern matching syntax is more concise in some 
circumstances, but there still needs to be justification why a combination of 
simpler language changes is insufficient.


My apologies if I missed it, but do you have some ideas of these simpler 
language changes that would do the job?


Pattern matching already exists in some limited way in Python.  Even today you 
can write:
   `a, b = value`


I think most of us are aware of unpacking in Python ;)


Yes, but not everyone recognizes that unpacking is a form of pattern matching.




instead of:
   `a = value[0]
    b = value[1]`

The idea of this is, of course, not so much about avoiding item access, but 
about having a more concise syntax for it.  Moreover, saying this only saves a 
single line and is therefore rather useless is quite beside the point.  It is 
about a better representation of what the code is supposed to do and not about 
saving lines.


How do you quantify "better representation" then?


You mean, without large study groups and lots of money and/or time?  Not easily.

I can tell you that

   a, b = value

is much more informative, and easier to read and process, than the alternative 
of using item assignment.


Saves two lines of code, but introduces two bugs!
(Assuming that the original behavior should be preserved)


Thank you for pointing out the bug in our example.  This highlights, however, 
rather the difficulty of refactoring (did I already mention the issue of the 
'context' that real code is embedded in?), than any shortcoming of pattern 
matching as a tool.  And by the way: constructive critisism would perhaps 
include explicitly naming the two bugs.


I'm not sure it would be more constructive, this is not a bug report or code 
review after all.


It should be.  If the PEP is to be decided on it should be as correct as 
possible.


The point I am making is this:
It is far too easy to make mistakes using the constructs proposed in PEP 622.


You're point is false.  They weren't crafting new code, they were refactoring.


For example, by adding a simple "matches" method to Node and Leaf, `is_tuple` 
can be rewritten as something like:


This assumes that you have full control over the entire code.  But if you are using some 
third-party library, you cannot "simply add a `matches` method" (without some 
substantial trickery).  Moreover, there is quite some work needed to define such a 
`matches` function as you propose it (including support for the ellipsis as wildcard).  
In effect, you would have to implement large parts of the pattern matching for just this 
simple example.  Whereas we believe that it has merit enough to have the compiler do it 
for a wide range of possible use cases.


You wouldn't have to implement large parts of the pattern matching,
because this would be specific to one class. There are only two or three cases 
to deal with.
If you don't have access to the original source, then it can be made a 
function, not a method.


So, a few lines for that example, another few for a different example, some 
more for that example over there -- how many times do we have to write similar 
code before we let Python do the grunt work for us?


Preventing the use of symbolic constants or other complex rvalues is a 
impairment to usability.


First, let me quote what the PEP has to say on that exact example:


Although this will work, it's not necessarily what the proposal is focused on.


So why does the PEP include it as one of just three examples?


To s

[Python-Dev] Re: I plan to accept PEP 623 "Remove wstr from Unicode" next week

[Victor Stinner]

Hi,

I have the pleasure of announcing that I accept the PEP 623 "Remove wstr
from Unicode", congratulations INADA-san!

I see this PEP as a good way to better communicate on incoming backward
incompatible C API changes. The PEP is a good document to explain the
Motivation, the Rationale and also to list affected C functions. It can
also be used and referenced in What's New in Python documents.

INADA-san: I let you update the PEP status. You may also announce the PEP
approval on the capi-sig mailing list.

Victor

Le mer. 8 juil. 2020 à 10:56, Victor Stinner  a écrit :

> Hi,
>
> As the PEP delegate of the PEP 623, I plan to accept PEP 623 "Remove
> wstr from Unicode" next week. As far as I know, all previous remarks
> have been taken in account.
>
> https://www.python.org/dev/peps/pep-0623/
>
> I worked with INADA-san to adjust his PEP 623 plan:
>
> * DeprecationWarning warnings will be emitted as soon as Python 3.10
> to help developers detect the deprecation at runtime, rather than only
> announcing the deprecation with compiler warnings and in the
> documentation.
>
> * Developers have two Python releases (3.10 and 3.11) with these
> runtime warnings before functions are removed
>
> * The PEP lists all APIs which will be removed in Python 3.12.
>
> * The PEP gives links to past discussions and issues.
>
> About the "size > 0" condition in "PyUnicode_FromUnicode(NULL, size)
> and PyUnicode_FromStringAndSize(NULL, size) emit DeprecationWarning
> when size > 0". INADA-san made sure that Cython avoids
> PyUnicode_FromUnicode(NULL, 0) to create an empty string: it's already
> fixed! The fix will be part of the next Cython 0.29.x release (it
> should be 0.29.21). But it will take time until popular extension
> modules using Cython will distribute a new release with updated
> generated C code.
>
> INADA-san checked popular PyPI projects. The majority of projects
> impacted by the PEP are using Cython and so are easy to fix: just
> regenerate C code with the fixed Cython. He added: "A few projects,
> pyScss and Genshi are not straightforward. But it is not too hard and
> I will help them." We have time before Python 3.12 final to update
> these projects.
>
> The PEP 623 is backward incompatible on purpose. If needed, it remains
> possible to use a single code base working on Python 2.7 and Python
> 3.12 using #ifdef. But Python 3.12 will not be released before 2023:
> three years after Python 2 end of life, so I think that it's
> reasonable for extension modules to consider dropping Python 2 support
> to implement the PEP 623 (stop using these deprecated C APIs).
>
> Victor
> --
> Night gathers, and now my watch begins. It shall not end until my death.
>
___
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/YAX5DP7IBDJOEAAFJRND26OIRR6Y6APA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: I plan to accept PEP 623 "Remove wstr from Unicode" next week

[Inada Naoki]

Thank you Victor for PEP-Delegating and accepting.

Reducing 8bytes per str object (or 16bytes per non-ASCII str object)
will be a significant
win for all Python users.

On Wed, Jul 15, 2020 at 8:20 AM Victor Stinner  wrote:
>
> Hi,
>
> I have the pleasure of announcing that I accept the PEP 623 "Remove wstr from 
> Unicode", congratulations INADA-san!
>
> I see this PEP as a good way to better communicate on incoming backward 
> incompatible C API changes. The PEP is a good document to explain the 
> Motivation, the Rationale and also to list affected C functions. It can also 
> be used and referenced in What's New in Python documents.
>
> INADA-san: I let you update the PEP status. You may also announce the PEP 
> approval on the capi-sig mailing list.
>
> Victor
>
> Le mer. 8 juil. 2020 à 10:56, Victor Stinner  a écrit :
>>
>> Hi,
>>
>> As the PEP delegate of the PEP 623, I plan to accept PEP 623 "Remove
>> wstr from Unicode" next week. As far as I know, all previous remarks
>> have been taken in account.
>>
>> https://www.python.org/dev/peps/pep-0623/
>>
>> I worked with INADA-san to adjust his PEP 623 plan:
>>
>> * DeprecationWarning warnings will be emitted as soon as Python 3.10
>> to help developers detect the deprecation at runtime, rather than only
>> announcing the deprecation with compiler warnings and in the
>> documentation.
>>
>> * Developers have two Python releases (3.10 and 3.11) with these
>> runtime warnings before functions are removed
>>
>> * The PEP lists all APIs which will be removed in Python 3.12.
>>
>> * The PEP gives links to past discussions and issues.
>>
>> About the "size > 0" condition in "PyUnicode_FromUnicode(NULL, size)
>> and PyUnicode_FromStringAndSize(NULL, size) emit DeprecationWarning
>> when size > 0". INADA-san made sure that Cython avoids
>> PyUnicode_FromUnicode(NULL, 0) to create an empty string: it's already
>> fixed! The fix will be part of the next Cython 0.29.x release (it
>> should be 0.29.21). But it will take time until popular extension
>> modules using Cython will distribute a new release with updated
>> generated C code.
>>
>> INADA-san checked popular PyPI projects. The majority of projects
>> impacted by the PEP are using Cython and so are easy to fix: just
>> regenerate C code with the fixed Cython. He added: "A few projects,
>> pyScss and Genshi are not straightforward. But it is not too hard and
>> I will help them." We have time before Python 3.12 final to update
>> these projects.
>>
>> The PEP 623 is backward incompatible on purpose. If needed, it remains
>> possible to use a single code base working on Python 2.7 and Python
>> 3.12 using #ifdef. But Python 3.12 will not be released before 2023:
>> three years after Python 2 end of life, so I think that it's
>> reasonable for extension modules to consider dropping Python 2 support
>> to implement the PEP 623 (stop using these deprecated C APIs).
>>
>> Victor
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>
> ___
> 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/YAX5DP7IBDJOEAAFJRND26OIRR6Y6APA/
> Code of Conduct: http://python.org/psf/codeofconduct/



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