On Thu, Jul 9, 2020 at 1:42 PM Eric Nieuwland
wrote:
> Much of the discussion seems to focus on how to distinguish between a
> variable as a provider of a value and a variable as receiver of a matched
> value.
>
> In normal Python syntax a variable in an expression provides a value,
> please
Yes, you’ve got that exactly right! I think the pep has an example for
tuple((x, y)).
On Thu, Jul 9, 2020 at 13:08 Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> One thing I don't understand about the PEP:
>
> case [x,y]:
>
> IIUC matches any 2-element sequence.
> How would you
> On 9 Jul 2020, at 17:49, Federico Salerno wrote:
>
> On 09/07/2020 01:27, Ethan Furman wrote:
>> 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
One thing I don't understand about the PEP:
case [x,y]:
IIUC matches any 2-element sequence.
How would you match specifically a 2-item list (say)?
Would it be
case list([x,y]):
I would appreciate it if some kind person could enlighten me.
TIA
Rob Cliffe
Much of the discussion seems to focus on how to distinguish between a variable
as a provider of a value and a variable as receiver of a matched value.
In normal Python syntax a variable in an expression provides a value, please
let’s keep that unchanged.
So it seems to me we should explicitly
On 09/07/2020 01:27, Ethan Furman wrote:
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
```
On Wed, Jul 8, 2020 at 7:23 PM Rob Cliffe wrote:
> *Use '==' to mark* (when necessary) *load-and-compare items*:
> match t:
> case (==USE_RECT, real, imag):
> return complex(real, imag)
> case (==USE_POLAR, r, phi):
> return complex(r * cos(phi), r *
On Thu, Jul 9, 2020 at 10:13 PM Jim J. Jewett wrote:
>
> Unless I'm missing something, part of M.-A. Lemburg's objection is:
>
> 1. The wchar_t type is itself an important interoperability story in C.
> (I'm not sure if this includes the ability, at compile time, to define
> wchar_t as either
Unless I'm missing something, part of M.-A. Lemburg's objection is:
1. The wchar_t type is itself an important interoperability story in C. (I'm
not sure if this includes the ability, at compile time, to define wchar_t as
either of two widths.)
2. The ability to work directly with wchar_t
On 08/07/2020 12:30, Rhodri James wrote:
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
thing being matched, but "dummy" does bind to it.
I meant catch-all as in "case _:" (or "else:"). I apologise for the
Hi,
Would someone be kind enough to review
https://github.com/python/cpython/pull/20803, please?
It cleans up tracking and introspection of frame state.
Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email
11 matches
Mail list logo
