[Python-Dev] Re: [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

[moshin ali]

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

[Python-Dev] Re: PEP 622 railroaded through?

[Rob Cliffe via Python-Dev]

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 been unfair to Guido and the other developers (and it seems 
that I probably have), I apologise.

Thank you.

FWIW:
    I am not against the PEP.
    I do not have a personal axe to grind, in the form of my own pet 
idea which I want to see incorporated.
    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.
    I'm not keen on special treatment of the '_' variable, and would 
prefer to be able to use 'else:' after 'match'.


Best wishes
Rob Cliffe

On 03/07/2020 15:56, Chris Angelico wrote:


The PEP is still a draft and has not been accepted. Don't worry, the
normal process is still happening :)

Having a reference implementation is a HUGE help, because people can
play around with it. There's a fork running an interactive playground
so you can go right now and get a feel for the way the syntax works.

The implementation has *not* been merged into the CPython trunk. It's
not a fait accompli - it's a tool to help people evaluate the proposal
(and all of the different variants of the proposal as it evolves).

Speaking with my PEP Editor hat on, I would be *thrilled* if more
proposals came with ready-to-try code. Only a very few have that
luxury, and a lot of the debating happens with nothing but theory -
people consider what they *think* they'd do, without actually being
able to try it out and see if it really does what they expect. Having
a reference implementation isn't necessary, of course, but it's
definitely a benefit and not a downside. Also, there HAVE been
proposals with full reference implementations that have ended up
getting rejected; it's not a guarantee that it'll end up getting
merged.

Hope that lessens your fears a bit :)

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Henk-Jaap Wagenaar]

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 treatment of the '_' variable, and would
> prefer to be able to use 'else:' after 'match'.
>

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 have to either have to come up with new
names (Point(unused_1, unused_2)) or use the "_" as currently instituted
(Point(_, _)) and "else:" does not cover that insofar as I can tell.

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? Not sure that makes its
use more/less/equal consistent with the previous suggestion.

Apologies if this has been discussed, I have followed the thread(s) but I
might well have forgotten or missed something!
___
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/XRG7DTFZKBY6E373QKB3TBEBB7D6FWWF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622

[Federico Salerno]

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.
    I'm not keen on special treatment of the '_' variable, and would 
prefer to be able to use 'else:' after 'match'.


+1

I think using else would be sensible since it has similar behaviour in 
the rest of Python and it would immediately make sense to anyone seeing 
the syntax for the first time (provided they understood what the rest of 
the match block does).
If objections were moved against it I seem to have missed them (in my 
defence, the discussion on PEP622 has been quite fragmented and I 
haven't been on this list for very long).


I also don't like the .name syntax and for what little it's worth, I 
personally would have a hard time getting used to it if it were adopted.
Has anyone proposed introducing ` ` quotes for this purpose? They could 
enclose references without ambiguity and could even be used elsewhere in 
Python to enclose identifiers, for example to allow spaces and symbols 
in them (which I wouldn't regard as particularly good style, but it may 
still come in handy). They are used in MySQL, bash and Markdown to 
enclose expressions or identifiers, so I feel no experienced programmer 
would have a hard time wrapping their head around it. Though I'd 
understand if it were problematic for Python's parser.


Another option would be to wrap references in {} in a similar way to 
what happens in fstrings.


Another option still could be to wrap references in quotes, like 
strings, and require use of str("some string") to catch literal strings, 
but I don't know if I like this myself.


Either way, I seem to prefer symmetric marks to signal references; I 
don't know if anyone else shares this sentiment.


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

[Python-Dev] PEP 624: Remove Py_UNICODE encoder APIs

[Inada Naoki]

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): https://www.python.org/dev/peps/pep-0624/

---

PEP: 624
Title: Remove Py_UNICODE encoder APIs
Author: Inada Naoki 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 06-Jul-2020
Python-Version: 3.11


Abstract


This PEP proposes to remove deprecated ``Py_UNICODE`` encoder APIs in
Python 3.11:

* ``PyUnicode_Encode()``
* ``PyUnicode_EncodeASCII()``
* ``PyUnicode_EncodeLatin1()``
* ``PyUnicode_EncodeUTF7()``
* ``PyUnicode_EncodeUTF8()``
* ``PyUnicode_EncodeUTF16()``
* ``PyUnicode_EncodeUTF32()``
* ``PyUnicode_EncodeUnicodeEscape()``
* ``PyUnicode_EncodeRawUnicodeEscape()``
* ``PyUnicode_EncodeCharmap()``
* ``PyUnicode_TranslateCharmap()``
* ``PyUnicode_EncodeDecimal()``
* ``PyUnicode_TransformDecimalToASCII()``

.. note::

   `PEP 623  `_ propose to remove
   Unicode object APIs relating to ``Py_UNICODE``. On the other hand, this PEP
   is not relating to Unicode object. These PEPs are split because they have
   different motivation and need different discussion.


Motivation
==

In general, reducing the number of APIs that have been deprecated for
a long time and have few users is a good idea for not only it
improves the maintainability of CPython, but it also helps API users
and other Python implementations.


Rationale
=

Deprecated since Python 3.3
---

``Py_UNICODE`` and APIs using it are deprecated since Python 3.3.


Inefficient
---

All of these APIs are implemented using ``PyUnicode_FromWideChar``.
So these APIs are inefficient when user want to encode Unicode
object.


Not used widely
---

When searching from top 4000 PyPI packages [1]_, only pyodbc use
these APIs.

* ``PyUnicode_EncodeUTF8()``
* ``PyUnicode_EncodeUTF16()``

pyodbc uses these APIs to encode Unicode object into bytes object.
So it is easy to fix it. [2]_


Alternative APIs


There are alternative APIs to accept ``PyObject *unicode`` instead of
``Py_UNICODE *``. Users can migrate to them.


=
==
Deprecated APIAlternative APIs
=
==
``PyUnicode_Encode()````PyUnicode_AsEncodedString()``
``PyUnicode_EncodeASCII()``   ``PyUnicode_AsASCIIString()`` \(1)
``PyUnicode_EncodeLatin1()``  ``PyUnicode_AsLatin1String()`` \(1)
``PyUnicode_EncodeUTF7()``\(2)
``PyUnicode_EncodeUTF8()````PyUnicode_AsUTF8String()`` \(1)
``PyUnicode_EncodeUTF16()``   ``PyUnicode_AsUTF16String()`` \(3)
``PyUnicode_EncodeUTF32()``   ``PyUnicode_AsUTF32String()`` \(3)
``PyUnicode_EncodeUnicodeEscape()``   ``PyUnicode_AsUnicodeEscapeString()``
``PyUnicode_EncodeRawUnicodeEscape()``
``PyUnicode_AsRawUnicodeEscapeString()``
``PyUnicode_EncodeCharmap()`` ``PyUnicode_AsCharmapString()`` \(1)
``PyUnicode_TranslateCharmap()``  ``PyUnicode_Translate()``
``PyUnicode_EncodeDecimal()``  \(4)
``PyUnicode_TransformDecimalToASCII()``\(4)
=
==

Notes:

(1)
   ``const char *errors`` parameter is missing.

(2)
   There is no public alternative API. But user can use generic
   ``PyUnicode_AsEncodedString()`` instead.

(3)
   ``const char *errors, int byteorder`` parameters are missing.

(4)
   There is no direct replacement. But ``Py_UNICODE_TODECIMAL``
   can be used instead. CPython uses
   ``_PyUnicode_TransformDecimalAndSpaceToASCII`` for converting
   from Unicode to numbers instead.


Plan


Python 3.9
--

Add ``Py_DEPRECATED(3.3)`` to following APIs. This change is committed
already [3]_. All other APIs have been marked ``Py_DEPRECATED(3.3)``
already.

* ``PyUnicode_EncodeDecimal()``
* ``PyUnicode_TransformDecimalToASCII()``.

Document all APIs as "will be removed in version 3.11".


Python 3.11
---

These APIs are removed.

* ``PyUnicode_Encode()``
* ``PyUnicode_EncodeASCII()``
* ``PyUnicode_EncodeLatin1()``
* ``PyUnicode_EncodeUTF7()``
* ``PyUnicode_EncodeUTF8()``
* ``PyUnicode_EncodeUTF16()``
* ``PyUnicode_EncodeUTF32()``
* ``PyUnicode_EncodeUnicodeEscape()``
* ``PyUnicode_EncodeRawUnicodeEscape()``
* ``PyUnicode_EncodeCharmap()``
* ``PyUnicode_TranslateCharmap()``
* ``PyUnicode_EncodeDecimal()``
* ``PyUnicode_TransformDecimalToASCII()``


Alternative ideas
=

Instead of just removing deprecated APIs, we may be able to use thier
names with different signature.


Make some private APIs public
--

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Rhodri James]

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 (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 have to either have to come up with new
names (Point(unused_1, unused_2)) or use the "_" as currently instituted
(Point(_, _)) and "else:" does not cover that insofar as I can tell.


There are two things here, the specialness of "_" and using "else:" as 
the catch-all clause.


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.


On the other hand "else:" would have exactly the effect of "case _:", so 
we're into arguments about there preferably being only one obvious way 
to do things.  I'd maintain that "else:" is obvious :-)


--
Rhodri James *-* Kynesim Ltd
___
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/EIBEIZ7QLBO3RBH253D7ZK5WTRNKHSYD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

[Victor Stinner]

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.


> Python 3.9
> --
>
> Add ``Py_DEPRECATED(3.3)`` to following APIs. This change is committed
> already [3]_. All other APIs have been marked ``Py_DEPRECATED(3.3)``
> already.
>
> * ``PyUnicode_EncodeDecimal()``
> * ``PyUnicode_TransformDecimalToASCII()``.
>
> Document all APIs as "will be removed in version 3.11".

I guess that if the release manager is not ok to add the two remaining
Py_DEPRECATED() warnings, they can be added to 3.10 instead.


> Make some private APIs public
>
> ``PyUnicode_EncodeUTF7()`` doesn't have public alternative APIs.
>
> Some APIs have alternative public APIs. But they are missing
> ``const char *errors`` or ``int byteorder`` parameters.

If needed, new functions can be added independently of this PEP.



> Using runtime warning
> -
>
> These APIs doesn't release GIL for now. Emitting a warning from
> such APIs is not safe. See this example.
>
> .. code-block::
>
>PyObject *u = PyList_GET_ITEM(list, i);  // u is borrowed reference.
>PyObject *b = PyUnicode_EncodeUTF8(PyUnicode_AS_UNICODE(u),
>PyUnicode_GET_SIZE(u), NULL);
>// Assumes u is still living reference.
>PyObject *t = PyTuple_Pack(2, u, b);
>Py_DECREF(b);
>return t;
>
> If we emit Python warning from ``PyUnicode_EncodeUTF8()``, warning
> filters and other threads may change the ``list`` and ``u`` can be
> a dangling reference after ``PyUnicode_EncodeUTF8()`` returned.
>
> Additionally, since we are not changing behavior but removing C APIs,
> runtime ``DeprecationWarning`` might not helpful for Python
> developers. We should warn to extension developers instead.

DeprecationWarning is hidden by default: users would not be impacted.

I don't think that encoding functions are special enough to skip these
warnings. I think that it's reasonable to change the behavior on these
deprecated functions to emit a warning.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Paul Moore]

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.
>
>
> +1(000)

There's been traffic on the PEP repository which suggests that there
is a new version of the PEP incoming which responds to these types of
concern. I'm not willing to read raw rst diffs, so I haven't checked
any of the details.

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.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Emily Bowman]

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 time with it in my head and in the actual testbed, it
seems like a reasonable compromise. case Point(x,x): being illegal while
x,x=(1,2) is perfectly legal is a bit of contention, but grammar also
doesn't need to be perfectly consistent in order to learn to speak a
language, it just needs to minimize the context-switching. It'd be so
simple if we could use case *:, but alas.
___
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/GD4XNSAW463J2U3P546UO6NFFENC3RUW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Henk-Jaap Wagenaar]

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 the meaning). [...] But I don't know what syntax (where
> necessary) to suggest.
> >
> >
> > +1(000)
>
> There's been traffic on the PEP repository which suggests that there
> is a new version of the PEP incoming which responds to these types of
> concern. I'm not willing to read raw rst diffs, so I haven't checked
> any of the details.
>

"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 later!):
https://github.com/python/peps/commit/f1de4f169d762cbb46fbfe94d2c01839db9b2f07

In there, it makes a good point that namespaced constants are good,
especially for this kind of thing (you probably want to e.g. match over a
bunch of possible constants which you can then put in an enum or some other
namespace).
___
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/2AP7CECCWKAGXBL27T6MNTRKPS4PS2OH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Eric Fahlgren]

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   Look about two character
spaces left of "I don't like..."

As I read this part of Rob's post this morning, I thought he was
surreptitiously making a point about grit on the screen, when I noticed it
was *literally grit on the screen*.  I cannot convey how long it took me to
recover.
___
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/XRHUZGM7HP6S6Z7UQTYTIE7GO64S7LIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Paul Sokolovsky]

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 later!):
> https://github.com/python/peps/commit/f1de4f169d762cbb46fbfe94d2c01839db9b2f07
> 
> In there, it makes a good point that namespaced constants are good,
> especially for this kind of thing (you probably want to e.g. match
> over a bunch of possible constants which you can then put in an enum
> or some other namespace).

That's probably a nice move, but requiring constants to be
extra-namespaced seems like a pretty arbitrary and limiting "rule"
either.

This touches on the sentiment which I was too shy to share for a long
time even on python-ideas, but would like to take a chance to bring up
here now:

With the advent of Lua 5.4, Python appears to be **the only** of the
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"


The closest Python has is:

---
from typing import Final
foo: Final = 1
--- 

which is done on the level of an arbitrary external module, and doesn't
enforce or employ const'ness on the language core level (unlike other
languages above).

If there were constants on the level of the core language, it would
*also* allow to elegantly resolve issue with the usage in match patterns
(in addition to baseline benefits of allowing programmers to express
programs more clearly and perform low-hanging optimizations). E.g.:

---
from __future__ import const

FOO: const = 1

match val:
case FOO:  # obviously matches by constant's value
---


-- 
Best regards,
 Paul  mailto:pmis...@gmail.com
___
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/YPP2TWYONFL4BOR3MJHGTHWSPMQNP7J7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Guido van Rossum]

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

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

[Python-Dev] Re: [OT] I'm unsubscribing from this tire fire (formerly known as python-dev)

[Sean Pedigo]

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 perhaps I don't have a horse in this race but in my personal opinion I
think heavier moderation of the mailing list may be warranted.
Conversations need to be quashed if they don't fit within the topic of the
list. Perhaps python-dev@python.org needs to have messages held in a queue
and only sent when they fit within the spirit of the discussion. I know
that pep8 is part of the language, but as it is style related maybe it
doesn't even have a place within Python-dev. In my opinion style guides are
always inherently political to begin with. If political discussion is
something that some readers want then maybe a mailing list about
administration and community should be a separate mailing list. Then those
discussions that end up here can be redirected there instead. It is my hope
that we can do something about the current state of the conversations in
python-dev. Whether or not you agree with the current style changes, I
think we can all agree that it has created a great deal of toxicity. Those
conversations have rarely ever been technically related and they especially
have not been helpful.

On Tue, Jul 7, 2020 at 9:59 AM moshin ali 
wrote:

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Paul Moore]

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.
>
>
> Please consider that the PEP authors also are struggling with the traffic 
> here.

Sorry! I didn't intend to imply otherwise. Mostly I was just hoping
you'd be more aware of what you'd changed and could offer a "these are
the high spots of what's changed" overview when you post the new
version. But absolutely don't feel that I'm suggesting you're obliged
to do so!

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Greg Ewing]

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 would work better if ? were used to mark assigned names instead
of values. Then '?' on its own would be a special case of '?name'
where you leave out the name.

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

[Python-Dev] Re: PEP 622 railroaded through?

[Daniel Moisset]

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 the context. `x` may mean "the value bound to x"
in code like `print(x)`, or "the name x inside some scope" when doing `x =
3`. `x[0]` may mean "calling `__getitem__(x, 0)` in the type of x" , or it
may mean a call to `__setitem__(x, 0, something)` instead if you do `for
x[0] in some_iter`.  `[a, *b]` may mean "build a list with a, and all the
elements that come from iterating b" in some contexts, in other it might
mean "extract one element from an iterator and bind it to a. Then build a
list with the other elements of the same iterator, put them into a new list
, and bind that to b" if you are doing `[a, *b] = myiter`.

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. It's so NOT confusing, that people even forget that exists :) It
works because the two meanings are not completely unrelated, and that's
what PEP622 is trying to achieve.

It may be surprising the first time you read the PEP in the air. The
question to answer is if it will be confusing after we've seen this
statement half a dozen of times in our codebases.

Best,
D.




>   But I don't know
> what syntax (where necessary) to suggest.
>  I'm not keen on special treatment of the '_' variable, and would
> prefer to be able to use 'else:' after 'match'.
>
> Best wishes
> Rob Cliffe
>
> On 03/07/2020 15:56, Chris Angelico wrote:
> >
> > The PEP is still a draft and has not been accepted. Don't worry, the
> > normal process is still happening :)
> >
> > Having a reference implementation is a HUGE help, because people can
> > play around with it. There's a fork running an interactive playground
> > so you can go right now and get a feel for the way the syntax works.
> >
> > The implementation has *not* been merged into the CPython trunk. It's
> > not a fait accompli - it's a tool to help people evaluate the proposal
> > (and all of the different variants of the proposal as it evolves).
> >
> > Speaking with my PEP Editor hat on, I would be *thrilled* if more
> > proposals came with ready-to-try code. Only a very few have that
> > luxury, and a lot of the debating happens with nothing but theory -
> > people consider what they *think* they'd do, without actually being
> > able to try it out and see if it really does what they expect. Having
> > a reference implementation isn't necessary, of course, but it's
> > definitely a benefit and not a downside. Also, there HAVE been
> > proposals with full reference implementations that have ended up
> > getting rejected; it's not a guarantee that it'll end up getting
> > merged.
> >
> > Hope that lessens your fears a bit :)
> >
> > ChrisA
> > ___
> > 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/E5U5Z6RRWSWHGXTZEQ6CBPORVXS3CPWD/
> > 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/NWNG5KII3ZJAUZ2J7X7SFV2MIBORIDJR/
> 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/OAJZFHLBY6EF5RIOVQBSU4JWZ54CMIYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

[Greg Ewing]

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 operator, either = or :=.
The PEP proposes to intermingle them, with only very subtle clues,
such as the presence or absence of dots, to distinguish them.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Greg Ewing]

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
choose names which "look constant-like" somehow.

It also has the general problem of const-declarations in Python.
Currently the compiler only has to analyse one module at a time;
this would require it to also look inside imported modules to
determine whether things were declared const.

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

[Python-Dev] Re: PEP 622 railroaded through?

[Chris Angelico]

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 always been clearly separated by
> being on the left of an assignment operator, either = or :=.
> The PEP proposes to intermingle them, with only very subtle clues,
> such as the presence or absence of dots, to distinguish them.
>

Part of the point of the post you responded to is that assignment
targets can be found in other contexts too - "for x[0] in iter:" uses
x[0] as an assignment target, and there's no equals sign to be seen.
You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching [was: PEP 622 railroaded through?]

[Guido van Rossum]

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 constant's value
>
> This would make it *more* difficult to distinguish constants from
> assignment targets when looking at the match statement, unless you
> choose names which "look constant-like" somehow.
>
> It also has the general problem of const-declarations in Python.
> Currently the compiler only has to analyse one module at a time;
> this would require it to also look inside imported modules to
> determine whether things were declared const.
>
> --
> Greg
> ___
> 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/ACJJV65BQNZ2LMNUBGJJLBR7AI3EO4SU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
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/GFMOZ6XFIJKQ4ST7TFTCMRUGICZASE5G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 railroaded through?

[Greg Ewing]

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 be arbitrarily
intermingled with other expression-like stuff.


You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.


It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.

Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.

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

[Python-Dev] Re: PEP 622 railroaded through?

[MRAB]

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", etc.)

But in match statements, they can be arbitrarily
intermingled with other expression-like stuff.


You're right about the presence/absence of a dot being very subtle,
but hang tight, wait for the next publication of the PEP; its authors
are working on that exact problem.


It looks like the only thing they're doing is dropping
the *leading* dot case -- without providing any replacement
for it. That only addresses one small part of my concern,
since I think the non-leading dot is nearly as subtle.
Maybe even more so, since at least the leading dot was
obviously something different.

Also I don't like the idea of being *forced* to use
a namespace for my constants, regardless of how good an
idea the PEP authors think it is.

Prefixing values with "==" might be the clearest, an idea that, I think, 
Ethan came up with. It might not look elegant, but...

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

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Rob Cliffe via Python-Dev]

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 AFAICS naturally extend to specifying a 
range, i.e. an upper and lower bound, which might be a desirable thing 
to do.

Perhaps someone can think of a way of doing it).

Whether
    case =42:
    case 42:
would both be allowed would be one issue to be decided.
Rob Cliffe
___
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/MENII4GJ66JHWBKNTNJSJOYCMSMLSIRO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

[Steven Barker]

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 filter, vs binding to something from the matched object.
>

The constructor-like syntax for class patterns is the part I like least
about this proposal. It seems to expect that there is a one-to-one
correspondence between constructor arguments and instance attributes. While
that might be common, especially for DataClass-like types, it's certainly
not always the case. Some attributes might be computed from multiple
arguments (or looked up elsewhere), and some arguments may never be saved
in their original form. I fear it will be extremely confusing if an
attribute being matched by a class pattern doesn't correspond at all to an
argument in a valid constructor call. For example, this class would make
things very confusing:

class Foo:
def __init__(self, a, b):
self.c = a + b

You could match an instance of the class with `case Foo(c=x)` and it would
work, but that might come as a surprise to anyone familiar with the class
constructor's argument names.

Even when attributes and constructor arguments do line up, the class
pattern syntax also seems a bit awkward when you are not required to match
against all of the non-optional constructor arguments. I imagine `case
datetime.datetime(year=2020):` would be a valid (and even useful!) class
pattern, but you can't construct a datetime instance in that way since the
class has three required arguments.

To sum up, I feel like using constructor and keyword-argument syntax to
access attributes is an abuse of notation. I'd much prefer a new syntax for
matching classes and their attributes that was not so likely to be
confusing due to imperfect parallels with class construction.
___
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/7LXFWX5LPLJBRVUK7OEPB3KGJQNB3AO6/
Code of Conduct: http://python.org/psf/codeofconduct/