[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[M.-A. Lemburg]

Hi Inada-san,

as you may remember, I wasn't happy with the deprecations of the
APIs in PEP 393, since there are no C API alternatives for
the encoding APIs deprecated in the PEP, which allow direct
encoding provided by these important codecs.

AFAIK, the situation hasn't changed since then.

We can't just remove access to one half of a codec (the decoding
part) without at least providing an alternative for C extensions
to use.

Py_UNICODE can be removed from the API, but only if there are
alternative APIs which C extensions can use to the same effect.

Given PEP 393, this would be APIs which use wchar_t instead of
Py_UNICODE.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jun 28 2020)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/


On 28.06.2020 04:35, Inada Naoki wrote:
> Hi, all.
> 
> I proposed PEP 623 to remove Unicode APIs deprecated by PEP 393.
> 
> In this thread, I am proposing removal of Py_UNICODE (not Unicode
> objects) APIs deprecated by PEP 393.
> Please reply for any comments.
> 
> 
> ## Undocumented, have Py_DEPRECATED
> 
> There is no problem to remove them in Python 3.10.  I will just do it.
> 
> * Py_UNICODE_str*** functions -- already removed in
> https://github.com/python/cpython/pull/21164
> * PyUnicode_GetMax()
> 
> 
> ## Documented and have Py_DEPRECATED
> 
> * PyLong_FromUnicode
> * PyUnicode_AsUnicodeCopy
> * PyUnicode_Encode
> * PyUnicode_EncodeUTF7
> * PyUnicode_EncodeUTF8
> * PyUnicode_EncodeUTF16
> * PyUnicode_EncodeUTF32
> * PyUnicode_EncodeUnicodeEscape
> * PyUnicode_EncodeRawUnicodeEscape
> * PyUnicode_EncodeLatin1
> * PyUnicode_EncodeASCII
> * PyUnicode_EncodeCharmap
> * PyUnicode_TranslateCharmap
> * PyUnicode_EncodeMBCS
> 
> These APIs are documented.  The document has ``.. deprecated:: 3.3
> 4.0`` directive.
> They have been `Py_DEPRECATED` since Python 3.6 too.
> 
> Plan: Change the document to ``.. deprecated:: 3.0 3.10`` and remove
> them in Python 3.10.
> 
> 
> ## PyUnicode_EncodeDecimal
> 
> It is not documented.  It has not been deprecated by Py_DEPRECATED.
> 
> Plan: Add Py_DEPRECATED in Python 3.9 and remove it in 3.11.
> 
> 
> ## PyUnicode_TransformDecimalToASCII
> 
> It is documented, but doesn't have ``deprecated`` directive. It is not
> deprecated by Py_DEPRECATED.
> 
> Plan: Add Py_DEPRECATED and ``deprecated 3.3 3.11`` directive in 3.9,
> and remove it in 3.11.
> 
> 
> ## _PyUnicode_ToLowercase, _PyUnicode_ToUppercase
> 
> They are not deprecated by PEP 393, but bpo-12736.
> They are documented as deprecated, but don't have ``Py_DEPRECATED``.
> 
> Plan: Add Py_DEPRECATED in 3.9, and remove them in 3.11.
> 
> Note: _PyUnicode_ToTitlecase has Py_DEPRECATED. It can be removed in 3.10.
> 
> 
___
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/RFVZQJIM3AZ4IJDC6QKWFH4PQZYQGRQD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: (PEP 620) C API for efficient loop iterating on a sequence of PyObject** or other C types

[Serhiy Storchaka]

23.06.20 12:18, Victor Stinner пише:

For example, we can consider continuing to provide raw access to a
PyObject** array, but an object can reply "sorry, I don't support this
PyObject** protocol". Also, I expect to have a function call to notify
the object when the PyObject** view is not longer needed. Something
like Py_buffer protocol PyBuffer_Release(). Maybe an object can
generate a temporary PyObject** view which requires to allocate
resources (like memory) and the release function would release these
resources.

Pseudo-code:

void iterate(PyObject *obj)
{
PyObjectPP_View view;

if (PyObjectPP_View_Get(&view, obj)) {
   // fast-path: the object provides a PyObject** view
   for (Py_ssize_t i=0; i < view.len; i++ {
 PyObject *item = view.array[i];
 ...
   }
   PyObjectPP_View_Release(&view);
}
else {
   // slow code path using PySequence_GetItem() or anything else
   ...
}

Maybe PyObjectPP_View_Get() should increment the object reference
counter to ensure that the object cannot be destroyed in the loop (if
the loop calls arbitrary Python code), and PyObjectPP_View_Release()
would decrement its reference counter.


It is not enough. A list can change content and size during iteration. 
You need either add the "export" count which prevent list mutating, or 
copy the list, or use such tricks as temporary swapping its content with 
the empty list for the time of iteration. In all cases it is a user 
visible change in behavior.



"PyObjectPP_View" protocol looks like PySequence_Fast() API, but IMO
PySequence_Fast() is not generic enough. For example, the first issue
is that it cannot reply "no, sorry, the object doesn't support
PyObject**". It always creates a temporary list if the object is not a
tuple or a list, that may be inefficient for a large sequence.


If you want to avoid conversion to a list, you can check that the object 
is a tuple or a list before using PySequence_Fast*() API. I don't see a 
need for new API for this.



Also, the "view" protocol should be allowed to query other types than
just PyObject**. For example, what if I would like to iterate on a
sequence of integers? bytes, array.array and memoryview can be seen as
sequences of integers.


Were not the buffer protocol and the memoryview object designed for 
this? In Python you can call `memoryview(obj).cast('I')` and then 
iterate integers. I think there is something similar in C.

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

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Inada Naoki]

Hi, Lamburg.

Thank you for quick response.

>
> We can't just remove access to one half of a codec (the decoding
> part) without at least providing an alternative for C extensions
> to use.
>
> Py_UNICODE can be removed from the API, but only if there are
> alternative APIs which C extensions can use to the same effect.
>
> Given PEP 393, this would be APIs which use wchar_t instead of
> Py_UNICODE.
>

Decoding part is implemented as `const char *` -> `PyObject*` (Unicode object).
I think this is reasonable since `const char *` is perfect to abstract
the encoded string,

In case of encoding part, `wchar_t *` is not perfect abstraction for
(decoded) unicode
string.  Converting from Unicode object into `wchar_t *` is not zero-cost.
I think `PyObject *` (Unicode object) -> `PyObject *` (bytes object)
looks better signature than
`wchar_t *` -> `Pyobject *` (bytes object) because for encoders.

* Unicode object is more important than `wchar_t *` in Python.
* All PyUnicode_EncodeXXX APIs are implemented with PyUnicode_FromWideChar.

For example, we have these private encode APIs:

* PyObject* _PyUnicode_AsAsciiString(PyObject *unicode, const char *errors)
* PyObject* _PyUnicode_AsLatin1String(PyObject *unicode, const char *errors)
* PyObject* _PyUnicode_AsUTF8String(PyObject *unicode, const char *errors)
* PyObject* _PyUnicode_EncodeUTF16(PyObject *unicode, const char
*errors, int byteorder)
...

So how about making them public, instead of undeprecate Py_UNICODE* encode APIs?

1. Add PyUnicode_AsXXXBytes public APIs in Python 3.10.
   Current private APIs can become macro (e.g. #define
_PyUnicode_AsAsciiString PyUnicode_AsAsciiBytes),
   or deprecated static inline function.
2. Remove Py_UNICODE* encode APIs in Python 3.12.

Regards,

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

[Python-Dev] [RELEASE] Python 3.7.8 and 3.6.11 now available - last 3.7.x bugfix release

[Ned Deily]

https://discuss.python.org/t/python-3-7-8-and-3-6-11-now-available-last-3-7-x-bugfix-release/4583

--
  Ned Deily
  n...@python.org -- []
___
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/MBTONIO2OG46TZ5AMEUX2ATQF45LUQ4C/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[salernof11]

What about `case for Point(x, 0):`? It reads very naturally, the presence of 
"for" hints against Point() being a call to the class, and "for" is an existing 
keyword that would make no other sense in that position.
Examples with other formats such as `case for [x, 0]:` seem to work just as 
well.
___
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/RAKL3WGR3CJLRVNGZQUAWSJAR3TT4VDE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[salernof11]

In my humble opinion, this doesn't warrant the creation of a new structure, but 
rather a restructuring of PEPs.

As mentioned by others, we have a "Rejected Ideas" section already, but that 
seems to somewhat miss the point. It captures only the arguments that have won, 
arguments moved against specific parts of the PEP which have managed to 
overthrow that specific part.

I propose to expand this into a section (call it Anti-PEP if you like, though 
I'd prefer something less arcane myself) that systematically approaches every 
argument moved against the PEP as a whole and any specific part of it, 
signalling the state of each objection (updated on a schedule, perhaps).

This would achieve:
- Keeping everyone informed at a glance on every objection.
- Prevent duplicate objections, as you'd be aware of similar objections to the 
one you want to raise and have your voice be heard there.
- Put all the pros and cons in one place, clearly labelled.
- Give a better overview of the objective arguments for and against: I believe 
subjective and emotional motivations would end up being compressed by the 
format in a way that would make it clear whether there is any value to them.
___
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/WP4NP36TFXUWTJPMPU7KR6IFZ4VTK5E7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Anti-PEP

[Chris Angelico]

On Mon, Jun 29, 2020 at 12:53 AM  wrote:
>
> In my humble opinion, this doesn't warrant the creation of a new structure, 
> but rather a restructuring of PEPs.
>
> As mentioned by others, we have a "Rejected Ideas" section already, but that 
> seems to somewhat miss the point. It captures only the arguments that have 
> won, arguments moved against specific parts of the PEP which have managed to 
> overthrow that specific part.
>

"Rejected Ideas" is more about alternatives, not about why this entire
proposal should be rejected.

> I propose to expand this into a section (call it Anti-PEP if you like, though 
> I'd prefer something less arcane myself) that systematically approaches every 
> argument moved against the PEP as a whole and any specific part of it, 
> signalling the state of each objection (updated on a schedule, perhaps).
>

Yep! A number of PEPs have "Objections" sections. I think that'd be a
good title for it.

> This would achieve:
> - Keeping everyone informed at a glance on every objection.
> - Prevent duplicate objections, as you'd be aware of similar objections to 
> the one you want to raise and have your voice be heard there.
> - Put all the pros and cons in one place, clearly labelled.
> - Give a better overview of the objective arguments for and against: I 
> believe subjective and emotional motivations would end up being compressed by 
> the format in a way that would make it clear whether there is any value to 
> them.
>

Agreed.

If a PEP author doesn't feel s/he can do justice to the Objections
section, it would make very good sense to collaborate with someone of
opposing view for that purpose. And if someone feels that the PEP
author isn't properly representing the opposing views, raise the
matter and ask the author to expand that section.

I don't think we need any concept of "Anti-PEP", but I would
definitely support a push to have a better "Objections" section in
controversial PEPs.

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

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Inada Naoki]

On Sun, Jun 28, 2020 at 11:24 PM Inada Naoki  wrote:
>
>
> So how about making them public, instead of undeprecate Py_UNICODE* encode 
> APIs?
>
> 1. Add PyUnicode_AsXXXBytes public APIs in Python 3.10.
>Current private APIs can become macro (e.g. #define
> _PyUnicode_AsAsciiString PyUnicode_AsAsciiBytes),
>or deprecated static inline function.
> 2. Remove Py_UNICODE* encode APIs in Python 3.12.
>

More aggressive idea: override current PyUnicode_EncodeXXX() apis.
Change from `Py_UNICODE *object` to `PyObject *unicode`.

This idea might look crazy.  But PyUnicode_EncodeXXX APIs are
deprecated for a long time, and there are only a few users.
I grepped from 3874 source packages in top 4000 downloaded packages.
(126 packages are wheel-only)

$ rg -w PyUnicode_EncodeASCII
Cython-0.29.20/Cython/Includes/cpython/unicode.pxd
424:bytes PyUnicode_EncodeASCII(Py_UNICODE *s, Py_ssize_t size,
char *errors)

$ rg -w PyUnicode_EncodeLatin1
Cython-0.29.20/Cython/Includes/cpython/unicode.pxd
406:bytes PyUnicode_EncodeLatin1(Py_UNICODE *s, Py_ssize_t size,
char *errors)

$ rg -w PyUnicode_EncodeUTF7
(no output)

$ rg -w PyUnicode_EncodeUTF8
subprocess32-3.5.4/_posixsubprocess_helpers.c
38:return PyUnicode_EncodeUTF8(PyUnicode_AS_UNICODE(unicode),

pyodbc-4.0.30/src/params.cpp
1932:bytes = PyUnicode_EncodeUTF8(source, cb, "strict");

pyodbc-4.0.30/src/cnxninfo.cpp
45:Object bytes(PyUnicode_EncodeUTF8(PyUnicode_AS_UNICODE(p),
PyUnicode_GET_SIZE(p), 0));
50:Object bytes(PyUnicode_Check(p) ?
PyUnicode_EncodeUTF8(PyUnicode_AS_UNICODE(p), PyUnicode_GET_SIZE(p),
0) : 0);

Cython-0.29.20/Cython/Includes/cpython/unicode.pxd
304:bytes PyUnicode_EncodeUTF8(Py_UNICODE *s, Py_ssize_t size, char *errors)

Note that subprocess32 is Python 2 only project.  Only pyodbc-4.0.30
use this API.
https://github.com/mkleehammer/pyodbc/blob/b4ea03220dd8243e452c91689bef34823b2f7d8f/src/params.cpp#L1926-L1942
https://github.com/mkleehammer/pyodbc/blob/master/src/cnxninfo.cpp#L45

Anyway, current PyUnicode_EncodeXXX APis are not used commonly.
I don't think it's worth enough to undeprecate.

Regards,

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

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

[Jim J. Jewett]

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

[Python-Dev] Re: The Anti-PEP

[Richard Damon]

On 6/28/20 11:02 AM, Chris Angelico wrote:
> Yep! A number of PEPs have "Objections" sections. I think that'd be a
> good title for it.

Yes, that was my thought. Have the PEP author include a summary of the
major objections, and their defense to those objections. (The presence
of the defense doesn't mean that the object HAS been overcome, but
documents the authors opinion of why the PEP should be able to be accept
dispite that objection, the final decision still will rest on the
Steering Committee or their delegate).

If the Objections section is well written, then opponents can refer to
the section and simply restate their objection, and it will somewhat
organize the opposition. If the Objections section is NOT well written,
that might be a sign that the PEP needs work as the author doesn't seem
to have understood some of the objections, and cleaning up that section
may bring more clarity to the PEP as a whole.

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

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

[Eric Nieuwland]

I wrote:
> 
> Guido van Rossum wrote:
> 
>> Eric Nieuwland wrote:
>> 
>>> I have some doubt about the keyword: ‘match' seems to be at odds with
>>> 'for', 'while', 'with', 'if' as it is more of an action.
>>> It's more like 'try' but that statement has a completely different
>>> structure.
>> 
>> Well, 'try' is also an action. :-) Many people have tried to come up with a
>> different keyword here, but nothing has been found that comes even close to
>> the simplicity of match. Plus, several other languages (Scala, Rust) use it
>> too (which is further evidence that it's a natural fit).
> 
> It may also be evidence for not being able to come up with a more accurate 
> keyword.
> 
> Reading through the PEP once more I noticed I was understanding
> 
>   match X:
>   case Y:
>   Z
> 
> as
> 
>   when X:
>   matches Y:
>   Z
> 
> which also to me seems to reflect the close relation to an if-elif-elif… 
> construction.
> 
> This would almost naturally imply the possibility of:
> 
>   when X:
>   matches Y:
>   Z
>   ...
>   else:
>   Q
> 
> And maybe also an additional operator:
> 
>   if X matches Y:
>   Z
> 
> 
>>> Not a native speaker I don't have a reasonable alternative, though.
>> 
>> Me neither, but I speak it quite fluently now, and 'match' really feels
>> like it fits well here.
> 
> Trying ;-)


Thinking of this over the weekend, I think the following might be even more 
flexible and powerful:


when X:
 Y1:
Z1
 Y2:
Z2
…
else:
Q

which would be the same as:

if X  Y1:
Z1
elif X  Y2:
Z2
…
else:
Q

Furthermore

when X:
 Y1 if C1:
Z1
 Y2 if C2:
Z2
…
else:
Q

would be the same as:

if X  Y1 and C1:
Z1
elif X  Y2 and C2:
Z2
…
else:
Q

and so the PEP would need to define:
- the 'when’ keyword
- the 'matches' comparison


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

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

[Daniel Moisset]

I've been going over the PEP this weekend, trying to get a
deeper understanding of what are its main ideas and consequences, and wrote
some notes. I'm not posting the notes directly to this list because it's a
bit of a long read, but I also tried to make it helpful as an analysis for
people involved in the discussion. So here's a link:
https://github.com/dmoisset/notebook/blob/811side
of thingsbf66/python/pep622/understanding-pep-622.md

.
I may update this in master, but for clarity I'm permalinking the current
version.

I'll soon switch to "proposing solutions" mode (rather than "analysis mode"
as this text is) soon, but needed to do this first, and hopefully this
helps someone else in this list organise ideas.

Best,

D.


On Tue, 23 Jun 2020 at 17:04, Guido van Rossum  wrote:

> I'm happy to present a new PEP for the python-dev community to review.
> This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and
> Talin.
>
> Many people have thought about extending Python with a form of pattern
> matching similar to that found in Scala, Rust, F#, Haskell and other
> languages with a functional flavor. The topic has come up regularly on
> python-ideas (most recently yesterday :-).
>
> I'll mostly let the PEP speak for itself:
> - Published: https://www.python.org/dev/peps/pep-0622/ (*)
> - Source: https://github.com/python/peps/blob/master/pep-0622.rst
>
> (*) The published version will hopefully be available soon.
>
> I want to clarify that the design space for such a match statement is
> enormous. For many key decisions the authors have clashed, in some cases we
> have gone back and forth several times, and a few uncomfortable compromises
> were struck. It is quite possible that some major design decisions will
> have to be revisited before this PEP can be accepted. Nevertheless, we're
> happy with the current proposal, and we have provided ample discussion in
> the PEP under the headings of Rejected Ideas and Deferred Ideas. Please
> read those before proposing changes!
>
> I'd like to end with the contents of the README of the repo where we've
> worked on the draft, which is shorter and gives a gentler introduction than
> the PEP itself:
>
>
> # Pattern Matching
>
> This repo contains a draft PEP proposing a `match` statement.
>
> Origins
> ---
>
> The work has several origins:
>
> - Many statically compiled languages (especially functional ones) have
>   a `match` expression, for example
>   [Scala](
> http://www.scala-lang.org/files/archive/spec/2.11/08-pattern-matching.html
> ),
>   [Rust](https://doc.rust-lang.org/reference/expressions/match-expr.html),
>   [F#](
> https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching
> );
> - Several extensive discussions on python-ideas, culminating in a
>   summarizing
>   [blog post](
> https://tobiaskohn.ch/index.php/2018/09/18/pattern-matching-syntax-in-python/
> )
>   by Tobias Kohn;
> - An independently developed [draft
>   PEP](
> https://github.com/ilevkivskyi/peps/blob/pattern-matching/pep-.rst)
>   by Ivan Levkivskyi.
>
> Implementation
> --
>
> A full reference implementation written by Brandt Bucher is available
> as a [fork]((https://github.com/brandtbucher/cpython/tree/patma)) of
> the CPython repo.  This is readily converted to a [pull
> request](https://github.com/brandtbucher/cpython/pull/2)).
>
> Examples
> 
>
> Some [example code](
> https://github.com/gvanrossum/patma/tree/master/examples/) is available
> from this repo.
>
> Tutorial
> 
>
> A `match` statement takes an expression and compares it to successive
> patterns given as one or more `case` blocks.  This is superficially
> similar to a `switch` statement in C, Java or JavaScript (an many
> other languages), but much more powerful.
>
> The simplest form compares a target value against one or more literals:
>
> ```py
> def http_error(status):
> match status:
> case 400:
> return "Bad request"
> case 401:
> return "Unauthorized"
> case 403:
> return "Forbidden"
> case 404:
> return "Not found"
> case 418:
> return "I'm a teapot"
> case _:
> return "Something else"
> ```
>
> Note the last block: the "variable name" `_` acts as a *wildcard* and
> never fails to match.
>
> You can combine several literals in a single pattern using `|` ("or"):
>
> ```py
> case 401|403|404:
> return "Not allowed"
> ```
>
> Patterns can look like unpacking assignments, and can be used to bind
> variables:
>
> ```py
> # The target is an (x, y) tuple
> match point:
> case (0, 0):
> print("Origin")
> case (0, y):
> print(f"Y={y}")
> case (x, 0):
> print(f"X={x}")
> case (x, y):
> print(f"X={x}, Y={y}")
> case _:
> raise ValueError("Not a point")
> ```

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Paul Sokolovsky]

Hello,

Shouldn't such feedback be also cross-posted to the python-dev mailing
list? Also note the original pull request,
https://github.com/python/peps/pull/1470, and differences of what was
written in the pull request description and what went in the commit
message.


On Sun, 28 Jun 2020 22:10:14 +0200
"Giampaolo Rodola'"  wrote:

> From:
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
> 
> > Instead of requiring that comments be written in Strunk & White
> > Standard  
> English, require instead that English-language comments be clear and
> easily understandable by other English speakers. This accomplishes
> the same goal without upholding relics of white supremacy. Many
> native English speakers do not use Standard English as their native
> dialect, so requiring conformation to Standard English centers
> whiteness in an inappropriate and unnecessary way, and can alienate
> and put up barriers for people of color and those whose native
> dialect of English is not Standard English. This change is a simple
> way to correct that while maintaining the original intent of the
> requirement.
> 
> This has nothing to do with making the wording "clear and
> understandable" (I agree on that). It's about, once again, bringing
> race-based politics into Python, and spreading hate towards a
> specific group of people: whites. Whether you're aware of it or not,
> there is a term for this: it's racism. I want to remind everyone that
> most of us here simply want to contribute code. We do it for free,
> and don't want to be involved in "this", because frankly it's
> disgusting. Doing something out of passion and for free, and at the
> same time seeing these sorts of things happening on a regular basis,
> looks and feels like an insult, and will only lead to people leaving
> this place.
> 
> On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin 
> wrote:
> 
> > Hi all, this is a very small change, but I thought I would field it
> > here to see if anyone has suggestions or ideas. Instead of
> > requiring that comments be written in Strunk & White Standard
> > English, PEP-8 should require instead that English-language
> > comments be clear and easily understandable by other English
> > speakers. This accomplishes the same goal without alienating or
> > putting up barriers for people (especially people of color) whose
> > native dialect of English is not Standard English. This change is a
> > simple way to correct that while maintaining the original intent of
> > the requirement. This change may even make the requirement more
> > clear to people who are not familiar with Strunk & White, since for
> > programmers, the main relevant aspect of that standard is "be clear
> > and concise;" simply saying that instead of referencing Strunk &
> > White may communicate this more effectively. Here is the current
> > line in PEP-8: "When writing English, follow Strunk and White."
> > I propose changing this line to "When writing English, ensure that
> > your comments are clear and easily understandable to other English
> > speakers." ___
> > Python-ideas mailing list -- python-id...@python.org
> > To unsubscribe send an email to python-ideas-le...@python.org
> > https://mail.python.org/mailman3/lists/python-ideas.python.org/
> > Message archived at
> > https://mail.python.org/archives/list/python-id...@python.org/message/AE2M7KOIQR37K3XSQW7FSV5KO4LMYHWX/
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >  
> 
> 
> -- 
> Giampaolo - gmpy.dev 



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

[Python-Dev] Re: Plan to remove Py_UNICODE APis except PEP 623.

[Inada Naoki]

On Mon, Jun 29, 2020 at 12:17 AM Inada Naoki  wrote:
>
>
> More aggressive idea: override current PyUnicode_EncodeXXX() apis.
> Change from `Py_UNICODE *object` to `PyObject *unicode`.
>

This is a list of PyUnicode_Encode usage in top4000 packages.
https://gist.github.com/methane/0f97391c9dbf5b53a818aa39a8285a29

Scandir use PyUnicode_EncodeMBCS only in `#if PY_MAJOR_VERSION < 3 &&
defined(MS_WINDOWS)` block.
So it is false positive.

Cython has prototype of these APIs.  pyodbc uses PyUnicode_EncodeUTF16
and PyUnicode_EncodeUTF8.
But pyodbc is converting Unicode Object into bytes object.  So current
API is very inefficient.

That's all.
Now I think it is safe to override deprecated APIs with private APIs
accepts Unicode Object.

* _PyUnicode_EncodeUTF7 -> PyUnicode_EncodeUTF7
* _PyUnicode_AsUTF8String -> PyUnicode_EncodeUTF8
* _PyUnicode_EncodeUTF16 -> PyUnicode_EncodeUTF16
* _PyUnicode_EncodeUTF32 -> PyUnicode_EncodeUTF32
* _PyUnicode_AsLatin1String -> PyUnicode_EncodeLatin1
* _PyUnicode_AsASCIIString -> PyUnicode_EncodeASCII
* _PyUnicode_EncodeCharmap -> PyUnicode_EncodeCharmap

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