> On May 4, 2020, at 10:30 AM, Eric Snow wrote:
>
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
Congratulations. Regardless of the outcome, you've certainly earned top marks
for vision, tenacity, team pl
On Mon, May 4, 2020 at 1:22 PM Paul Moore wrote:
> One thing I would like to see is a comment confirming that as part of
> the implementation, all stdlib modules will be made
> subinterpreter-safe.
Yeah, I'd meant to put a note. I'll add one. Thanks!
-eric
_
On Mon, 4 May 2020 at 19:19, Eric Snow wrote:
>
> On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> > Further feedback is welcome, though I feel like the PR is ready (or
> > very close to ready) for pronouncement. Thanks again to all.
>
> oops
>
> s/the PR is ready/the PEP is ready/
One thing
On Mon, May 4, 2020 at 9:45 AM Steve Dower wrote:
> For those who haven't looked in a while, the uuid module uses ctypes to
> look up libuuid for uuid_generate_time_safe() and uuid_generate_time()
> functions.
>
> I've run into scenarios where I need to remove this from our own builds,
> but it s
On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
oops
s/the PR is ready/the PEP is ready/
-eric
___
Python-Dev mailin
Hi all,
Thanks for the great feedback. I've updated PEP 554 (Multiple
Interpreters in the Stdlib) following feedback.
https://www.python.org/dev/peps/pep-0554/
Here's a summary of the main changes:
* [API] dropped/deferred the "release" and "close" methods from
RecvChannel and SendChannel (
The PEP is now rejected:
https://www.python.org/dev/peps/pep-0349/
https://github.com/python/peps/commit/fb14d5d81f62f43e7bc78f52f1941cd36e32fd96
Thanks Neil Schemenauer for the interesting PEP ;-) The good news is
that Python 3 basically implements the PEP!
Victor
Le lun. 4 mai 2020 à 16:36,
For those who haven't looked in a while, the uuid module uses ctypes to
look up libuuid for uuid_generate_time_safe() and uuid_generate_time()
functions.
I've run into scenarios where I need to remove this from our own builds,
but it seems like it's probably unnecessary anyway? It's certainly
Thanks, this is what I was looking for and couldn't find. I'm glad it is
something that's been considered and debated before. I'm not sure why I
couldn't find it or anything like it, but I guess the syntax is just a
needle in a haystack.
Em
On Sat, May 2, 2020 at 7:42 AM Henk-Jaap Wagenaar <
wage
Agreed.
On Mon, May 4, 2020 at 07:34 Victor Stinner wrote:
> Hi,
>
> Since Python 3 "str" type already means Unicode, I understand that
> Python 3 made this PEP outdated. Since Python 2 reached it's end of
> life, it seems perfectly safe to reject this PEP now.
>
> Victor
>
> Le lun. 4 mai 2020
Hi,
Since Python 3 "str" type already means Unicode, I understand that
Python 3 made this PEP outdated. Since Python 2 reached it's end of
life, it seems perfectly safe to reject this PEP now.
Victor
Le lun. 4 mai 2020 à 15:26, Henk-Jaap Wagenaar
a écrit :
>
> The following deferred PEP seems t
The following deferred PEP seems to have become obsolete due to time/Python
marching on:
PEP 349 - Allow str() to return unicode strings
https://www.python.org/dev/peps/pep-0349/
As there is now not non-unicode strings anymore (unless I am
misunderstanding the PEP).
What should the state of this
12 matches
Mail list logo
