On Sun, Jun 28, 2020 at 8:44 AM Jim J. Jewett wrote:
> I actually like that it looks like instantiation; it seems to be saying
> "Do we have the sort of object we would get from this instantiation?"
>
> Unfortunately, this does aggravate the confusion over whether a variable
> is being used as a
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:
case Point(x, >y):
(although the syntax doesn't
On 2020-07-08 02:20, Greg Ewing wrote:
On 8/07/20 12:48 pm, Chris Angelico wrote:
"for x[0] in iter:" uses
x[0] as an assignment target,
You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import",
On 8/07/20 12:48 pm, Chris Angelico wrote:
"for x[0] in iter:" uses
x[0] as an assignment target,
You're right, there are some others, but I think they're
equally clear -- all the ones I can think of are directly
after a keyword ("for", "as", "import", etc.)
But in match statements, they can
Please move this subtopic to a subject that doesn’t have “PEP 622” in its
topic.
On Tue, Jul 7, 2020 at 17:54 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
On Wed, Jul 8, 2020 at 10:45 AM Greg Ewing wrote:
>
> On 8/07/20 12:24 pm, Daniel Moisset wrote:
> > Many people in this thread have argued that the double meaning in the
> > PEP might be confusing, but Python already has a double meaning in other
> > places.
>
> But assignment targets have
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 distinguish constants from
assignment targets when looking at the match statement, unless you
On 8/07/20 12:24 pm, Daniel Moisset wrote:
Many people in this thread have argued that the double meaning in the
PEP might be confusing, but Python already has a double meaning in other
places.
But assignment targets have always been clearly separated by
being on the left of an assignment
On Tue, 7 Jul 2020 at 15:07, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> (...) Nor am I keen on "expressions" being interpreted
> differently after 'case' than elsewhere in Python.
Python already has "expressions" (intentional quotes) that are interpreted
differently depending
On 8/07/20 2:31 am, Henk-Jaap Wagenaar wrote:
Would it be possible here to use a syntax/symbol that is illegal instead
of _? I think this has been mooted but my favourite (so far) would be
"?" so you have "case ?:" and "Point(?, ?)".
Would ?name then work instead of ".name" as well?
It
On Tue, 7 Jul 2020 at 18:35, Guido van Rossum wrote:
>
> On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote:
>>
>> Hopefully the PEP authors intend to post an updated version
>> (preferably with a summary of changes, for people struggling to keep
>> up with the traffic here!) sometime soon.
>
>
>
As someone who also just subscribed to the mailing list about a month ago
to be kept abreast of what is going on within the Python development
community I have already stopped reading the mailing list as well. Every
time I look there is rarely ever technical discussion. As a new person I
know
On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote:
> Hopefully the PEP authors intend to post an updated version
> (preferably with a summary of changes, for people struggling to keep
> up with the traffic here!) sometime soon.
>
Please consider that the PEP authors also are struggling with the
Hello,
On Tue, 7 Jul 2020 17:22:28 +0100
Henk-Jaap Wagenaar wrote:
[]
> > >> I don't like the .name syntax (grit on Tim's monitor; does
[]
> "PEP 622: Ditch leading dots for name loads": this is now an
> ex-syntax, it is bereft of life (for this, draft, of the PEP, might
> come back
On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I don't like the .name syntax (grit on Tim's monitor; does not
>> suggest the meaning). [...] But I don't know what syntax (where
>> necessary) to suggest.
>
>
https://photos.app.goo.gl/xN68s3QMMBTPTLD47
On Tue, 7 Jul 2020 at 17:09, Paul Moore wrote:
> On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar
> wrote:
> >
> > On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
> python-dev@python.org> wrote:
> >>
> >> I don't like the .name syntax (grit on Tim's monitor; does not
> >> suggest
On Tue, Jul 7, 2020 at 8:37 AM Rhodri James wrote:
> I'm not quite convinced about making "_" non-binding, mostly because of
> the knock-on effects in the PEP for other types of patterns. It seems
> to breed more special cases, and I can't help but feel that's a bad sign.
>
After spending some
On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar
wrote:
>
> On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev
> wrote:
>>
>> I don't like the .name syntax (grit on Tim's monitor; does not
>> suggest the meaning). [...] But I don't know what syntax (where necessary)
>> to suggest.
>
>
Le mar. 7 juil. 2020 à 17:21, Inada Naoki a écrit :
> This PEP proposes to remove deprecated ``Py_UNICODE`` encoder APIs in
> Python 3.11:
Overall, I like the plan. IMHO 3.11 is a reasonable target version,
since on the top 4000 projects, only 2 are affected and it is easy to
fix them.
>
On 07/07/2020 15:31, Henk-Jaap Wagenaar wrote:
On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
I'm not keen on special treatment of the '_' variable, and would
prefer to be able to use 'else:' after 'match'.
I used to be in this "camp", however, a
Hi, folks.
Since the previous discussion was suspended without consensus, I wrote
a new PEP for it. (Thank you Victor for reviewing it!)
This PEP looks very similar to PEP 623 "Remove wstr from Unicode",
but for encoder APIs, not for Unicode object APIs.
URL (not available yet):
On 03/07/2020 21:55, Rob Cliffe wrote:
I don't like the .name syntax (grit on Tim's monitor; does not
suggest the meaning). Nor am I keen on "expressions" being
interpreted differently after 'case' than elsewhere in Python. But I
don't know what syntax (where necessary) to suggest.
On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> I don't like the .name syntax (grit on Tim's monitor; does not
> suggest the meaning). [...] But I don't know what syntax (where necessary)
> to suggest.
+1(000)
> I'm not keen on special
I would like to thank everyone who responded to me for their civilised
and courteous replies. I actually expected to get a lot of slagging
off, but was prepared to accept that for what seemed to me at the time
to be a legitimate concern.
If my fears were unfounded, I am delighted.
If I have
The community point is a factor which allowed us to stand out across tech
stack groups in our own country but if upstream the situation is
unfavourable i fear it will make Python lose one of it's greatest allies.
Kind Regards,
ezikweb
https://ezikweb.com/
25 matches
Mail list logo
