[Python-Dev] Re: Latest PEP 554 updates.
> 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 play, and overcoming adversity. May your sub-interpreters be plentiful, Raymond ___ 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/TD26ZW2EKO2Q4OFHRHEEF2MQPLXAGHL6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Latest PEP 554 updates.
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 ___ 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/CVGSOKANMSIGPZKRL6IQDOYJYZRZ3NE2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Latest PEP 554 updates.
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 I would like to see is a comment confirming that as part of the implementation, all stdlib modules will be made subinterpreter-safe. I know we talked about this, and you seemed OK with the idea, so if it's already in the document I apologise. (I'm reading the raw rst in a proportional font - not the best way of making sure I don't miss things! :-() 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/23RWSNSFVRTC4MCCRWSRZVTAHW4YFIZX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Remove ctypes from uuid
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 seems like it's probably unnecessary anyway? It's certainly a > security risk, though in most cases the _uuid module should provide them > anyway. > > I'm proposing to remove the ctypes fallbacks: > https://bugs.python.org/issue40501 > > If anyone knows that they are reliant on not having libuuid at compile > time, but being able to load it later via ctypes, it would be great if > you could drop by the issue and explain the scenario. > > Thanks, > Steve > That seems like a good idea. The ctypes code has been in there since the module was added in 2006. The _uuid extension module only landed in 2017 for Python 3.7. I can't imagine a normal scenario where the _uuid extension module would not exist unless we're talking maybe special needs for PyPy. (I doubt they want ctypes either these days) -gps ___ 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/LW5CZQZ3RW5EDNKWRBZVPJHWPPZ6WLFU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Latest PEP 554 updates.
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 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/D36JNZMMA2O746KLWBBWMGN2F7MQHVWM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Latest PEP 554 updates.
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 (they were unnecessary and the "association" stuff was too confusing) * [API] dropped RecvChannel/SendChannel.interpreters * [API] dropped/deferred SendChannel.send_buffer() * [API] renamed Interpreter.destroy() to Interpreter.close() * [API] added a per-interpreter "isolated" mode (default: on) * added a section about "Help for Extension Module Maintainers" * added a section about documentation * added many entries to the "deferred" and "rejected" sections Further feedback is welcome, though I feel like the PR is ready (or very close to ready) for pronouncement. Thanks again to all. -eric -- PEP: 554 Title: Multiple Interpreters in the Stdlib Author: Eric Snow BDFL-Delegate: Antoine Pitrou Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017-09-05 Python-Version: 3.9 Post-History: 07-Sep-2017, 08-Sep-2017, 13-Sep-2017, 05-Dec-2017, 09-May-2018, 20-Apr-2020, 01-May-2020 Abstract CPython has supported multiple interpreters in the same process (AKA "subinterpreters") since version 1.5 (1997). The feature has been available via the C-API. [c-api]_ Subinterpreters operate in `relative isolation from one another `_, which facilitates novel alternative approaches to `concurrency `_. This proposal introduces the stdlib ``interpreters`` module. The module will be `provisional `_. It exposes the basic functionality of subinterpreters already provided by the C-API, along with new (basic) functionality for sharing data between interpreters. A Disclaimer about the GIL == To avoid any confusion up front: This PEP is unrelated to any efforts to stop sharing the GIL between subinterpreters. At most this proposal will allow users to take advantage of any results of work on the GIL. The position here is that exposing subinterpreters to Python code is worth doing, even if they still share the GIL. Proposal The ``interpreters`` module will be added to the stdlib. To help authors of extension modules, a new page will be added to the `Extending Python `_ docs. More information on both is found in the immediately following sections. The "interpreters" Module - The ``interpreters`` module will provide a high-level interface to subinterpreters and wrap a new low-level ``_interpreters`` (in the same way as the ``threading`` module). See the `Examples`_ section for concrete usage and use cases. Along with exposing the existing (in CPython) subinterpreter support, the module will also provide a mechanism for sharing data between interpreters. This mechanism centers around "channels", which are similar to queues and pipes. Note that *objects* are not shared between interpreters since they are tied to the interpreter in which they were created. Instead, the objects' *data* is passed between interpreters. See the `Shared data`_ section for more details about sharing between interpreters. At first only the following types will be supported for sharing: * None * bytes * str * int * PEP 554 channels Support for other basic types (e.g. bool, float, Ellipsis) will be added later. API summary for interpreters module --- Here is a summary of the API for the ``interpreters`` module. For a more in-depth explanation of the proposed classes and functions, see the `"interpreters" Module API`_ section below. For creating and using interpreters: +-+--+ | signature | description | +=+==+ | ``list_all() -> [Interpreter]`` | Get all existing interpreters. | +-+--+ | ``get_current() -> Interpreter``| Get the currently running interpreter. | +-+--+ | ``get_main() -> Interpreter`` | Get the main interpreter.| +-+--+ | ``create(*, isolated=True) -> Interpreter`` | Initialize a new (idle) Python interpreter. | +-+--+ | ++-+ | signature | description
[Python-Dev] Re: PEP 349 --- deferred but now obsolete?
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, Guido van Rossum a écrit : > > 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 à 15:26, Henk-Jaap Wagenaar >> a écrit : >> > >> > 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 PEP be updated to? >> > >> > Henk-Jaap >> > >> > >> > ___ >> > 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/GF5D3F4MGA6SD2TBABSDUEDZYWXXFT6V/ >> > Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >> >> -- >> 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/M2Y3PUFLAE23NPRJPVBYF6P5LW5LVN6F/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > -- > --Guido (mobile) -- 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/HU6WMGXVDA6CFLQR66RU7YBNX4LMXDDH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Remove ctypes from uuid
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 a security risk, though in most cases the _uuid module should provide them anyway. I'm proposing to remove the ctypes fallbacks: https://bugs.python.org/issue40501 If anyone knows that they are reliant on not having libuuid at compile time, but being able to load it later via ctypes, it would be great if you could drop by the issue and explain the scenario. Thanks, Steve ___ 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/EVM6NU7FXKENNEVOZJWO7HLV57CLVEUE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: For-If syntax
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 < wagenaarhenkj...@gmail.com> wrote: > We seem to be, once again, rehashing about this. For example, I proposed > this in 2017, which was not the first time: > > > https://mail.python.org/archives/list/python-id...@python.org/thread/GFZFJAI4WGFYFFVQTF7DORHMY7F45XZZ/ > > (Gary's suggestion, and (counter) counter points to it are in the linked > discussion) > > Would it maybe be time for someone to write a PEP for this (if they can be > found), so it can then be rejected (or not)? > > I think there is no bikeshedding to be done on the idea, though in terms > of parsing there might be (though as I mentioned in that thread, there > should be no difference to generator expression parsing). > > On Fri, 1 May 2020 at 19:52, Gary Herron wrote: > >> >> On 5/1/20 9:19 AM, silverback...@gmail.com wrote: >> >> I hope this isn't too noobish, nothing on the list comes up in Google, >> but I'm curious why the construct >> >> for x in y if x.is_some_thing: >> # do a thing >> >> But this is probably clearer (and has the same syntax): >> >> for x in y: >> if x.is_some_thing: >> # do a thing >> >> >> Cramming two separate thoughts onto a single line is probably *not* >> clearer. >> >> >> >> isn't legal. That seems a very Pythonic symmetry with lambdas. The >> equivalent syntax required right now is, >> >> for x in [x for x in y if x.is_some_thing]: >> # do a thing >> >> Of course there's more flexibility in the full syntax, but is there any >> interest in the simpler, more performant one-line syntax? >> >> Em >> >> ___ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to >> python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/VHFUQFEF3TCI6LHLBAUEKMFM2A6V3CQO/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> -- >> Dr. Gary Herron >> Professor of Computer Science >> DigiPen Institute of Technology >> (425) 895-4418 >> >> ___ >> 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/T3VQGGAHYR4AOKMVPL5NDTAV2GB6BIAH/ >> 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/SBEKOAFBUNVFXR5UXCSFF6HPEE4GEE6O/ > 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/7E4CK5GBA2F4WLVECHOCJFY54L5WRCLI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 349 --- deferred but now obsolete?
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 à 15:26, Henk-Jaap Wagenaar > a écrit : > > > > 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 PEP be updated to? > > > > Henk-Jaap > > > > > > ___ > > 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/GF5D3F4MGA6SD2TBABSDUEDZYWXXFT6V/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > 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/M2Y3PUFLAE23NPRJPVBYF6P5LW5LVN6F/ > 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/4NOVOZZ3NLTOWDNYEH2N3YOMAWZTBLF2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 349 --- deferred but now obsolete?
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 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 PEP be updated to? > > Henk-Jaap > > > ___ > 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/GF5D3F4MGA6SD2TBABSDUEDZYWXXFT6V/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- 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/M2Y3PUFLAE23NPRJPVBYF6P5LW5LVN6F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] PEP 349 --- deferred but now obsolete?
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 PEP be updated to? Henk-Jaap ___ 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/GF5D3F4MGA6SD2TBABSDUEDZYWXXFT6V/ Code of Conduct: http://python.org/psf/codeofconduct/
