On Mon, Apr 20, 2020 at 2:22 PM Eric Snow <ericsnowcurren...@gmail.com> wrote:
> On Sat, Apr 18, 2020 at 11:16 AM Antoine Pitrou <solip...@pitrou.net> 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, instead, associating an
> > interpreter with a channel as soon as that channel is given to it
> > through `Interpreter.run(..., channels=...)` (or received through
> > `recv()`)?
>
> That seems fine to me. I do not recall the exact reason for tying
> association to recv() or send(). I only vaguely remember doing it
> that way for a technical reason. If I determine that reason then I'll
> bring it up. In the meantime I'll update the PEP to associate
> interpreters when the channel end is sent.
>
> FWIW, it may have been influenced by the automatic channel closing
> when no interpreters are associated. If interpreters are associated
> when channel ends are sent (rather than when used) then interpreters
> will have to be more careful about releasing channels. That's just a
> guess as to why I did it that way. :)
As I've gone to update the PEP for this I'm feeling less comfortable
with changing it. There is a subtle difference which concretely
manifests in 2 ways.
Firstly, the programmatic exposure of "associated"
(SendChannel.interpreters and RecvChannel.Interpreters) would be
different. With the current specification, "associated" means "has
been used by". With your recommendation it would mean "is accessible
by". Is it more useful to think about them one way or the other?
Would there be value in making both meanings part of the API
separately ("associated" + "bound") somehow?
Secondly, with the current spec channels get automatically closed
sooner, effectively as soon as all wrapping objects *that were used*
are garbage collected (or released). With your recommendation it only
happens as soon all all wrapping objects are garbage collected (or
released). In the former case channels could get auto-closed before
you expect them to. In the latter case they could leak if users
forget to release them when unused. Is there a good way to address
both downsides?
-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/VZQFVSXP3JFZGNOTINZKMFPCRINQX4U6/
Code of Conduct: http://python.org/psf/codeofconduct/
