On 22/04/20 4:21 am, Sebastian Berg wrote:
Sure, but this is very different. You can still use NumPy in a project
using asyncio. You are _not_ able to use NumPy in a project using
subinterpreters.
To put it another way, the moment you start using subinterpreters,
the set of extension modules
On 22/04/20 3:57 am, Eric Snow wrote:
The main difference is that the PEP also provides an way to explicitly
release or close a channel. Providing just "close()" would mean one
interpreter could stomp on all other interpreters' use of a channel.
What I'm suggesting is that close() should do
On Tue, Apr 21, 2020 at 9:35 PM Gregory P. Smith wrote:
> Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
> get it out of the stdlib by 3.11 or 3.12?
>
I'm going ahead and tracking the idea in https://bugs.python.org/issue40360.
>
> lib2to3 is the basis of all sorts
Could we go ahead and mark lib2to3 as Pending Deprecation in 3.9 so we can
get it out of the stdlib by 3.11 or 3.12?
lib2to3 is the basis of all sorts of general source code manipulation
tooling. Its name and original reason d'etre have moved on. It is
actively used to parse and rewrite Python
Great! Please submit a PR to update the [lib]2to3 docs and CC me
(@gvanrossum).
While perhaps it wouldn't hurt if the PEP mentioned lib2to3, it was just
accepted by the Steering Council without such language, and I wouldn't want
to imply that the SC agrees with everything I said. So I still think
On Sat, Apr 18, 2020 at 10:38 PM Guido van Rossum wrote:
>
> Note that, while there is indeed a docs page about 2to3, the only docs for
> lib2to3 in the standard library reference are a link to the source code and a
> single "Note: The lib2to3 API should be considered unstable and may change
>
On Tue, 21 Apr 2020 12:05:28 -0700
"Gregory P. Smith" wrote:
> On Tue, Apr 21, 2020 at 10:49 AM Antoine Pitrou wrote:
>
> > On Tue, 21 Apr 2020 18:46:04 +0200
> > Petr Viktorin wrote:
> > > On 2020-04-21 11:01, Antoine Pitrou wrote:
> > > > On Mon, 20 Apr 2020 19:21:21 -0600
> > > > Eric
On Tue, Apr 21, 2020 at 10:49 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 18:46:04 +0200
> Petr Viktorin wrote:
> > On 2020-04-21 11:01, Antoine Pitrou wrote:
> > > On Mon, 20 Apr 2020 19:21:21 -0600
> > > Eric Snow wrote:
> > >> Honest question: how many C extensions have process-global
On Tue, 21 Apr 2020 18:46:04 +0200
Petr Viktorin wrote:
> On 2020-04-21 11:01, Antoine Pitrou wrote:
> > On Mon, 20 Apr 2020 19:21:21 -0600
> > Eric Snow wrote:
> >> Honest question: how many C extensions have process-global state that
> >> will cause problems under subinterpreters? In other
On Tue, 2020-04-21 at 11:21 -0500, Sebastian Berg wrote:
> On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote:
> > Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith a
> > écrit
> > :
>
> As far as I can tell, nobody can or _should_ expect subinterpreters
> to
> actually run most general python
On 2020-04-21 11:01, Antoine Pitrou wrote:
On Mon, 20 Apr 2020 19:21:21 -0600
Eric Snow wrote:
Honest question: how many C extensions have process-global state that
will cause problems under subinterpreters? In other words, how many
already break in mod_wsgi?
A slightly tricky question is
On Tue, Apr 21, 2020 at 10:33 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 09:36:22 -0600
> Eric Snow wrote:
> > Yeah, I had that same realization yesterday and it didn't change after
> > sleeping on it. I suppose the only question I have left is if there
> > is value to users in knowing
Hi,
I'm generally in favour of PEP 554, but I don't think it is ready to be
accepted in its current form.
My main objection is that without per-subinterpeter GILs (SILs?) PEP 554
provides no value over threading or multi-processing.
Multi-processing provides true parallelism and threads
On Tue, 21 Apr 2020 09:36:22 -0600
Eric Snow wrote:
> On Tue, Apr 21, 2020 at 2:18 AM Antoine Pitrou wrote:
> > On Tue, 21 Apr 2020 18:27:41 +1200
> > Greg Ewing wrote:
> > > On 21/04/20 10:23 am, Eric Snow wrote:
> > > > with the current spec channels get automatically closed
> > > >
On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote:
> Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith a écrit
> :
>
>
> > tl;dr: accepting PEP 554 is effectively a C API break, and will
> > force
> > many thousands of people worldwide to spend many hours wrangling
> > with
> >
On Tue, Apr 21, 2020 at 7:25 AM Victor Stinner wrote:
> Would it make sense to start by adding the module as a private
> "_subinterpreters" module but document it? The "_" prefix would be a
> reminder that "hey! it's experimental, there is a no backward
> compatibility warranty there".
I would
On Tue, Apr 21, 2020 at 1:39 AM Greg Ewing wrote:
> I don't get this whole business of channels being associated
> with interpreters, or why there needs to be a distinction
> between release() and close().
>
> To my mind, a channel reference should be like a file
> descriptor for a pipe. When
On Tue, Apr 21, 2020 at 2:18 AM Antoine Pitrou wrote:
> On Tue, 21 Apr 2020 18:27:41 +1200
> Greg Ewing wrote:
> > On 21/04/20 10:23 am, Eric Snow wrote:
> > > with the current spec channels get automatically closed
> > > sooner, effectively as soon as all wrapping objects *that were used*
> > >
On Tue, Apr 21, 2020 at 8:54 AM Paul Moore wrote:
>
> On Tue, 21 Apr 2020 at 15:31, Eric Snow wrote:
> > Here are the options for handling non-compliant extension modules:
> >
> > 1. do nothing (extensions may break in ways that are hard for users to
> > deal with)
> > 2. raise ImportError if an
On Tue, Apr 21, 2020 at 4:11 AM Greg Ewing wrote:
> On 21/04/20 8:34 pm, Ronald Oussoren via Python-Dev wrote:
> > As far as I understand proper support for subinterpreters also requires
> > moving away from static type definition to avoid sharing objects > between
> > interpreters (that is, use
On Tue, Apr 21, 2020 at 3:10 AM Antoine Pitrou wrote:
> On Mon, 20 Apr 2020 19:21:21 -0600
> Eric Snow wrote:
> > Honest question: how many C extensions have process-global state that
> > will cause problems under subinterpreters? In other words, how many
> > already break in mod_wsgi?
>
> A
Thanks for explaining that, Ronald. It sounds like a lot of the
effort would relate to making classes work. I have some comments
in-line below.
-eric
On Tue, Apr 21, 2020 at 2:34 AM Ronald Oussoren wrote:
> > On 21 Apr 2020, at 03:21, Eric Snow wrote:
> > Honest question: how many C
On Tue, 21 Apr 2020 at 15:31, Eric Snow wrote:
> Here are the options for handling non-compliant extension modules:
>
> 1. do nothing (extensions may break in ways that are hard for users to
> deal with)
> 2. raise ImportError if an extension without PEP 489 support is
> imported in a
On Tuesday, April 21, 2020 9:20 AM Victor Stinner [mailto:vstin...@python.org]
wrote
> Hi,
>
> Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou a écrit :
> > Mostly, I hope that by making the
> > subinterpreters functionality available to pure Python programmers
> > (while it was formally an
__future__ imports only have effects on the parser and compiler.
PEP 554 is mostly a Python module, currently named "_xxsubinterpreters".
Victor
Le mar. 21 avr. 2020 à 15:37, Edwin Zimmerman
a écrit :
>
> On Tuesday, April 21, 2020 9:20 AM Victor Stinner
> [mailto:vstin...@python.org] wrote
>
On Tue, Apr 21, 2020 at 7:31 AM Larry Hastings wrote:
> On 4/20/20 8:06 AM, Benjamin Peterson wrote:
>
> I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...]
> Over all those years, CPython's core developers and contributors sedulously
> applied bug fixes to the 2.7
Le mar. 21 avr. 2020 à 00:50, Nathaniel Smith a écrit :
> Why do you believe that subinterpreters will have reduced resource
> usage? I assume you're comparing them to subprocesses here.
> Subinterpreters are "shared-nothing"; all code, data, etc. has to be
> duplicated, except for static C code
On Tue, Apr 21, 2020 at 2:09 AM Antoine Pitrou wrote:
>
> On Mon, 20 Apr 2020 15:30:37 -0700
> Nathaniel Smith wrote:
> >
> > tl;dr: accepting PEP 554 is effectively a C API break, and will force
> > many thousands of people worldwide to spend many hours wrangling with
> > subinterpreter
Hi Nathaniel,
Thanks for your very interesting analysis :-)
Le ven. 17 avr. 2020 à 23:12, Nathaniel Smith a écrit :
> - The asyncio designers (esp. Guido) did a very extensive analysis of
> these libraries' design choices, spoke to the maintainers about what
> they'd learned from hard
On 4/20/20 8:06 AM, Benjamin Peterson wrote:
I'm eudaemonic to announce the immediate availability of Python 2.7.18. [...]
Over all those years, CPython's core developers and contributors sedulously
applied bug fixes to the 2.7 branch, no small task as the Python 2 and 3
branches diverged.
Hi,
Le sam. 18 avr. 2020 à 19:16, Antoine Pitrou a écrit :
> Mostly, I hope that by making the
> subinterpreters functionality available to pure Python programmers
> (while it was formally an advanced and arcane part of the C API), we
> will spur of bunch of interesting third-party
On 21/04/20 8:34 pm, Ronald Oussoren via Python-Dev wrote:
As far as I understand proper support for subinterpreters also requires
moving away from static type definition to avoid sharing objects > between
interpreters (that is, use the PyType_FromSpec to build types).
Which means updating
On Mon, 20 Apr 2020 19:21:21 -0600
Eric Snow wrote:
> Honest question: how many C extensions have process-global state that
> will cause problems under subinterpreters? In other words, how many
> already break in mod_wsgi?
A slightly tricky question is what happens if a PyObject survives
longer
> On 21 Apr 2020, at 03:21, Eric Snow wrote:
>
[…]
> On Mon, Apr 20, 2020 at 4:30 PM Nathaniel Smith wrote:
>
[…]
>>
>> But notice that this means that no-one can use subinterpreters at all,
>> until all of their C extensions have had significant reworks to use
>> the new API, which will
On Tue, 21 Apr 2020 19:45:02 +1200
Greg Ewing wrote:
> On 21/04/20 11:24 am, Edwin Zimmerman wrote:
> > Socket connections could be passed off from the main interpreter to
> > sub-interpreters for concurrent processing that simply isn't possible
> > with the global GIL
>
> I would need
On Tue, 21 Apr 2020 18:27:41 +1200
Greg Ewing wrote:
> On 21/04/20 10:23 am, Eric Snow wrote:
> > with the current spec channels get automatically closed
> > sooner, effectively as soon as all wrapping objects *that were used*
> > are garbage collected (or released).
>
> Maybe I'm missing
On Mon, 20 Apr 2020 15:30:37 -0700
Nathaniel Smith wrote:
>
> tl;dr: accepting PEP 554 is effectively a C API break, and will force
> many thousands of people worldwide to spend many hours wrangling with
> subinterpreter support.
For the record, that's not my reading of the PEP. PEP 554
On 21/04/20 11:24 am, Edwin Zimmerman wrote:
Socket connections could be passed off from the main interpreter to
sub-interpreters for concurrent processing that simply isn't possible
with the global GIL
I would need convincing that the processing involved things
that are truly held up by the
On 21/04/20 10:47 am, Eric Snow wrote:
On Mon, Apr 20, 2020 at 4:23 PM Eric Snow wrote:
As I've gone to update the PEP for this I'm feeling less comfortable
with changing it.
I don't get this whole business of channels being associated
with interpreters, or why there needs to be a
On 21/04/20 10:35 am, Eric Snow wrote:
For the event loop case, what is the downside
to adapting to the API in the existing proposal?
If you mean the suggestion of having async send and receive
methods, that's okay.
My point was that before responding to requests to add
individual features
On 21/04/20 10:23 am, Eric Snow wrote:
with the current spec channels get automatically closed
sooner, effectively as soon as all wrapping objects *that were used*
are garbage collected (or released).
Maybe I'm missing something, but just because an object
hasn't been used *yet* doesn't mean
41 matches
Mail list logo
