On Wed, Apr 29, 2020, 22:05 Greg Ewing wrote:
> > Furthermore, IMHO "release" is better at communicating the
> > per-interpreter nature than "close".
>
> Channels are a similar enough concept to pipes that I think
> it would be confusing to have "close" mean "close for all
> interpreters". Everyo
On 29/04/20 2:12 pm, Eric Snow wrote:
One of the main inspirations for the
proposed channels is CSP (and somewhat relatedly, my in-depth
experience with Go). Channels are more than just a thread-safe data
transport between interpreters.
It's a while since I paid attention to the fine details
o
Even then, disconnect seems like the primary use case, with a
channel.kill_for_all being a specialized subclass. One argument for leaving it
to a subclass is that it isn't clear what other interpreters should do when
that happens. Shut down? Start getting exceptions if they happen to use it
On Tue, Apr 21, 2020 at 11:21 PM Greg Ewing wrote:
> What I'm suggesting is that close() should do what the
> PEP defines release() as doing, and release() shouldn't
> exist.
>
> I don't see why an interpreter needs the ability to close
> a channel for any *other* interpreter. There is no such
> a
On Wed, Apr 22, 2020 at 2:13 AM Kyle Stanley wrote:
> If you'd like an example format for marking a section of the docs as
> provisional w/ reST, something like this at the top should suffice
> (with perhaps something more specific to the subinterpreters module):
>
>
> .. note::
> This section
Eric Snow wrote:
> We will mark it "provisional" in the docs, which I expect will include
> info on what that means and why it is provisional.
If you'd like an example format for marking a section of the docs as
provisional w/ reST, something like this at the top should suffice
(with perhaps somet
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 wh
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 which
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
> > > > soone
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 ex
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 you'
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 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 advance
__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
>
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 experimentatio
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 somet
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 distinction
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 suc
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 it
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.
Also, the resulting text of the PEP makes it a little harder to follow
when an interpreter gets associated. However, this is partly an
artifact of the struc
On Mon, Apr 20, 2020 at 4:19 PM Greg Ewing wrote:
>
> On 21/04/20 8:29 am, Eric Snow wrote:
> > * Would a low-level channel implementation based on callbacks or locks
> > be better (simpler, faster, etc.) than one based on buffering?
>
> Depends on what you mean by "better". Callbacks are more
> v
On Mon, Apr 20, 2020 at 2:22 PM Eric Snow wrote:
> On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> > * The "association" timing seems quirky and potentially annoying: an
> > interpreter only becomes associated with a channel the first time it
> > calls recv() or send(). How about, i
On 21/04/20 8:29 am, Eric Snow wrote:
* Would a low-level channel implementation based on callbacks or locks
be better (simpler, faster, etc.) than one based on buffering?
Depends on what you mean by "better". Callbacks are more
versatile; a buffered channel just does buffering, but
with callba
On Mon, 20 Apr 2020 14:22:03 -0600
Eric Snow wrote:
>
> > The appeal of the PEP for experimentations is multiple:
> > 1) ability to concurrently run independent execution environments
> >without spawning child processes (which on some platforms and in some
> >situations may not be very de
On Sat, Apr 18, 2020 at 6:50 PM Greg Ewing wrote:
> On 19/04/20 5:02 am, Antoine Pitrou wrote:
> > * How hard would it be, in the current implementation, to add buffering
> >to channels?
> >
> > * In the same vein, I think channels should allow adding readiness
> >callbacks
>
> Of these, I
Thanks for the feedback, Antoine. I've responded inline below and
will be making appropriate changes to the PEP. One point I'd like to
reinforce before my comments is the PEP's emphasis on minimalism.
>From PEP 554:
This proposal is focused on enabling the fundamental capability of
mult
On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou wrote:
> * I do think a minimal synchronization primitive would be nice.
> Either a Lock (in the Python sense) or a Semaphore: both should be
> relatively easy to provide, by wrapping an OS-level synchronization
> primitive. Then you can recre
On 19/04/20 5:02 am, Antoine Pitrou wrote:
* How hard would it be, in the current implementation, to add buffering
to channels?
* In the same vein, I think channels should allow adding readiness
callbacks
Of these, I think the callbacks are more fundamental. If you
have a non-buffered ch
On Sat, 18 Apr 2020 19:02:47 +0200
Antoine Pitrou wrote:
>
> * I do think a minimal synchronization primitive would be nice.
> Either a Lock (in the Python sense) or a Semaphore: both should be
> relatively easy to provide, by wrapping an OS-level synchronization
> primitive. Then you can
29 matches
Mail list logo
