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
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
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.
>>
>>
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
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.
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
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
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
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.
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
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
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
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
13 matches
Mail list logo
