On 08/07/2020 16:02, Guido van Rossum wrote:
```
USE_POLAR = "polar"
USE_RECT = "rect"
```
Now we would like to be able to replace those literals with the
corresponding names throughout our code and have everything work like
before:
```
match t:
case (USE_RECT, real,
On 9/07/20 3:30 am, Luciano Ramalho wrote:
I strongly favor the option of aligning the `else` clause with
`match`, because `else` is a special clause therefore it should look
special.
But on the other hand, it's semantically equivalent to 'case _:',
so it's not all that special.
--
Greg
On 07/08/2020 10:44 AM, Ethan Furman wrote:
So namespaced variables only... is there a recommendation on handling global()
and local() type variables?
Okay, some off-list discussion clarified that for me:
- easiest way is to use a guard
```
def foo(x, spam):
match x:
On Thu, Jul 9, 2020 at 5:46 AM M.-A. Lemburg wrote:
> - the fact that the encode APIs encoding from a Unicode buffer
> to a bytes object; this is an important fact, since the removal
> removes access to this codec functionality for extensions
>
> - PyUnicode_AsEncodedString() is not a proper
On 9/07/20 3:26 am, Brandt Bucher wrote:
match :
case | : ...
case | if : ...
case | : ...
```
It's safe to use the same decision tree for through , but it must be rebuilt for
and , since could have done literally *anything*.
I think you're being overly cautious here.
On Wed, Jul 8, 2020, 1:50 PM Paul Sokolovsky
> > I admit I do not really understand what gain dynamic languages get from
> constants. I pretty uniformly use a common convention of ALLCAPS for
> constant names
>
> > I can easily imagine that a VM might gain speed with that information,
> but that
> Date: Wed, 8 Jul 2020 20:00:44 +0300
> From: Paul Sokolovsky
> Subject: [Python-Dev] Re: Python is the only language with lack of
[ munch ]
> Right. So, if someone would like to add something to this thread, I'd
> humbly suggest to concentrate on the lack of, and need for, of
> const-ness in
On Wed, 8 Jul 2020 at 21:44, Guido van Rossum wrote:
> It works for me. Did you click on the box where the logs are supposed to
> appear? It will only show the logs when you click there.
>
>
I did click on that before, but I suddenly had a thought (I should have had
long ago): it seems my
Hi Inada-san,
I am currently too busy with EuroPython to participate in longer
discussions. FWIW: I intend to continue after EuroPython.
In any case, thanks for writing up the PEP. Could you please add my
points about:
- the fact that the encode APIs encoding from a Unicode buffer
to a bytes
It works for me. Did you click on the box where the logs are supposed to
appear? It will only show the logs when you click there.
On Wed, Jul 8, 2020 at 1:36 PM Henk-Jaap Wagenaar <
wagenaarhenkj...@gmail.com> wrote:
> On Wed, 1 Jul 2020 at 17:09, Guido van Rossum wrote:
>
>> If you are
On Wed, 1 Jul 2020 at 17:09, Guido van Rossum wrote:
> If you are interested in learning more about how PEP 622 would work in
> practice, but don't feel like compiling a Python 3.10 fork from source,
> here's good news for you.
>
> In a hurry?
>
On Wed, 8 Jul 2020 20:08:34 +0200
Antoine Pitrou wrote:
> On Wed, 8 Jul 2020 18:38:12 +0100
> Rhodri James wrote:
> > 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.
> >
> >
On 08/07/2020 19:27, Gustavo Carneiro wrote:
Forgive the intrusion, in case this wasn't already mentioned (I only read a
fraction of emails on this), we could say that name enclosed in parenthesis
would mean loading a constant, instead of storing in a variable:
It's discussed as the third
On 08/07/2020 19:08, Antoine Pitrou wrote:
On Wed, 8 Jul 2020 18:38:12 +0100
Rhodri James wrote:
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.
Thank you very much to everyone who has been
*facepalm* this is right there in the PEP, already, as one possible
alternative. Apologies for the noise. :-/
On Wed, 8 Jul 2020 at 19:27, Gustavo Carneiro wrote:
>
>
> On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote:
>
>> Today I’m happy (and a little trepidatious) to announce the next
Ethan Furman wrote:
> Why is this no longer an issue? My apologies if I missed it in the PEP.
This problem was an artifact of the default `object.__match__` implementation,
which allowed one positional argument by default when `__match_args__` was
missing or `None`. Since we've removed
On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote:
> Today I’m happy (and a little trepidatious) to announce the next
> version of PEP 622, Pattern Matching. As authors we welcome Daniel F
> Moisset in our midst. Daniel wrote a lot of the new text in this
> version, which introduces the
On Wed, 8 Jul 2020 18:38:12 +0100
Rhodri James wrote:
> 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.
>
> Thank you very much to everyone who has been working on this, it is much
>
On 07/08/2020 08:02 AM, Guido van Rossum wrote:
Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching.
All in all I like it a lot!
As authors we welcome Daniel F
Moisset in our midst
Welcom, Daniel, and thank you!
That said, the new
Hello,
On Wed, 8 Jul 2020 13:15:19 -0400
David Mertz wrote:
> On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky
>
> > Right. So, if someone would like to add something to this thread,
> > I'd humbly suggest to concentrate on the lack of, and need for, of
> > const-ness in the Python language core
One microscopic point:
[Guido]
> ...
> (if `.x` is unacceptable, it’s unclear why `^x` would be any
> better),
As Python's self-appointed spokesperson for the elderly, there's one
very clear difference: a leading "." is - literally - one microscopic
point, all but invisible. A leading caret is
> Le 8 juil. 2020 à 19:15, David Mertz a écrit :
>
> On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky
> Right. So, if someone would like to add something to this thread, I'd humbly
> suggest to concentrate on the lack of, and need for, of const-ness in the
> Python language core (in comparison
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.
Thank you very much to everyone who has been working on this, it is much
appreciated. I have one suggestion for the text: could the section on
On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky
> Right. So, if someone would like to add something to this thread, I'd
> humbly suggest to concentrate on the lack of, and need for, of
> const-ness in the Python language core (in comparison to other languages
> or not), and usecases it enables, and
Hello,
On Wed, 8 Jul 2020 12:37:05 -0400
David Mertz wrote:
> On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky
>
> > popular VHLL/scripting languages which doesn't support defining of
> > constants in the core language:
> >
> > JavaScript has "const foo = 1;"
> > PHP has "const foo = 1;"
> > Perl
On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky
> popular VHLL/scripting languages which doesn't support defining of
> constants in the core language:
>
> JavaScript has "const foo = 1;"
> PHP has "const foo = 1;"
> Perl has "use constant foo => 1;"
> Lua has "local foo = 1"
> -
>
> > -
Hello,
On Thu, 9 Jul 2020 01:22:48 +1000
Steven D'Aprano wrote:
> Whenever someone says "Python is the only language..." it really
Yeah, the original message in this sub-thread was
https://mail.python.org/archives/list/python-dev@python.org/message/YPP2TWYONFL4BOR3MJHGTHWSPMQNP7J7/
,
and
On Thu, Jul 09, 2020 at 01:22:48AM +1000, Steven D'Aprano wrote:
> Whenever someone says "Python is the only language..." it really turns
> out to be the case. Python is very rarely as unusual as people often
> make out.
Gah, embarrasing typo! That was meant to be *rarely* turns out to be the
On 07/08/2020 08:30 AM, Luciano Ramalho wrote:
As I first read a `match` statement, and I see an `else` clause, I
know for sure that *something* will happen. If no `else` clause is
present, I know it's possible nothing will happen. It's the same thing
with `else` in `if`, `while`, `for`, `try`
[... snip explanation of key sticking points ...]
Thank you for an excellent write-up combining background context with
possible solutions. Now I need to actually read the PEP ;)
TJG
___
Python-Dev mailing list -- python-dev@python.org
To
Thanks for explaining the open issues so well, Guido.
My 2¢ on the `else` matter:
On Wed, Jul 8, 2020 at 12:05 PM Guido van Rossum wrote:
> [...] it’s unclear whether the `else` should be aligned with `case`
> or `match`.
I strongly favor the option of aligning the `else` clause with
`match`,
On Wed, Jul 8, 2020 at 7:03 AM Kerwin Sun wrote:
> I tried with this code:
>
[...]
> def whereis(point):
> case w:
> print("Not the answer, local w")
> case z:
> print("The answer")
> case _:
> print("other")
> whereis(42)
w, z
Inada Naoki wrote:
> Since this is very new system, can we have some restriction to allow
> aggressive optimization than regular Python code?
The authors were just discussing a related question yesterday (more
specifically, can the compiler fold `C() | C()` -> `C( | )`).
The answer we arrived
Whenever someone says "Python is the only language..." it really turns
out to be the case. Python is very rarely as unusual as people often
make out.
To my knowledge, there are quite a few other languages that don't have
constants, some of them are even moderately well known languages:
-
On 2020-07-08 03:08, Rob Cliffe via Python-Dev wrote:
Why not use '=' to distinguish binding from equality testing:
case Point(x, =y): # matches a Point() with 2nd parameter equal to
y; if it does, binds to x.
This would allow a future (or present!) extension to other relative
operators:
Today I’m happy (and a little trepidatious) to announce the next
version of PEP 622, Pattern Matching. As authors we welcome Daniel F
Moisset in our midst. Daniel wrote a lot of the new text in this
version, which introduces the subject matter much more gently than the
first version did. He also
Henk-Jaap Wagenaar wrote:
> The not binding is there only to allow the main way in which "_" is special
> in match/case: ...
The non-binding behavior is useful in other ways:
match range(HUGE_INT):
case [*_, last]:
print(last)
___
On Wed, Jul 08, 2020 at 07:53:00AM -, Kerwin Sun wrote:
> I tried with this code:
> ```
> from dataclasses import dataclass
>
> @dataclass
> class Point:
> x: int
> y: int
>
> z = 41
>
> def whereis(point):
> w = 23
> match point:
> case Point(0, 0):
>
I tried with this code:
```
from dataclasses import dataclass
@dataclass
class Point:
x: int
y: int
z = 41
def whereis(point):
w = 23
match point:
case Point(0, 0):
print("Origin")
case Point(0, y):
print(f"Y={y}")
case Point(x,
I tried with this code:
```
from dataclasses import dataclass
@dataclass
class Point:
x: int
y: int
z = 41
def whereis(point):
w = 23
match point:
case Point(0, 0):
print("Origin")
case Point(0, y):
print(f"Y={y}")
case Point(x,
On Wed, 8 Jul 2020 at 14:30, Paul Svensson wrote:
> On Wed, 8 Jul 2020, Rhodri James wrote:
>
> > On 08/07/2020 11:05, Federico Salerno wrote:
> >> What I don't like is the use of _ as catch-all, which is different and
> not
> >> interdependent with its use as throwaway.
> >
> > Any name used as
On Wed, 8 Jul 2020, Rhodri James wrote:
On 08/07/2020 11:05, Federico Salerno wrote:
What I don't like is the use of _ as catch-all, which is different and not
interdependent with its use as throwaway.
Any name used as a pattern is a catch-all. The only difference between "case
dummy:" and
On 7/7/20 10:08 PM, Rob Cliffe via Python-Dev wrote:
> Why not use '=' to distinguish binding from equality testing:
> case Point(x, =y): # matches a Point() with 2nd parameter equal to
> y; if it does, binds to x.
>
> This would allow a future (or present!) extension to other relative
>
On Wed, Jul 8, 2020 at 8:56 PM Inada Naoki wrote:
>
> On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote:
> >
> >
> > These two I would be less averse to, but the trouble is that they make
> > the semantics a bit harder to explain. "Dotted names are looked up if
> > not already looked up,
On Wed, Jul 8, 2020 at 6:14 PM Chris Angelico wrote:
>
>
> These two I would be less averse to, but the trouble is that they make
> the semantics a bit harder to explain. "Dotted names are looked up if
> not already looked up, otherwise they use the same object from the
> previous lookup". If you
Hello,
On Wed, 08 Jul 2020 12:45:09 +1200
Greg Ewing wrote:
> On 8/07/20 5:30 am, Paul Sokolovsky wrote:
> > from __future__ import const
> >
> > FOO: const = 1
> >
> > match val:
> > case FOO: # obviously matches by constant's value
>
> This would make it *more* difficult to
On 08/07/2020 11:05, Federico Salerno wrote:
What I don't like is the use of _ as catch-all, which is different and
not interdependent with its use as throwaway.
Any name used as a pattern is a catch-all. The only difference between
"case dummy:" and "case _:" is that "_" doesn't bind to the
On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote:
I used to be in this "camp", however, a (I think valid) point was
raised that "else:" is not a (full) alternative. Due to the
restriction on repeated names (e.g. Point(x, x) is illegal), if you
want to "throw away" intermediate matches, you will
On Wed, Jul 8, 2020 at 6:17 PM Inada Naoki wrote:
>
> Since this is very new system, can we have some restriction
> to allow aggressive optimization than regular Python code?
>
> # Class Pattern
>
> Example:
>
> match val:
> case Point(0, y): ...
> case Point(x, 0): ...
>
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
Since this is very new system, can we have some restriction
to allow aggressive optimization than regular Python code?
# Class Pattern
Example:
match val:
case Point(0, y): ...
case Point(x, 0): ...
case Point(x, y): ...
* Can VM lookup "Point" only once per
51 matches
Mail list logo
