<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 15, 2014 at 4:02 AM, Giampaolo Rodola' <span dir="ltr"><<a href="mailto:g.rodola@gmail.com" target="_blank">g.rodola@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div class="">On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I don't think so. asyncio depends on selectors but not vice versa. The selectors module was not part of PEP 3156. It is solid and I don't see any reason why it should get a reprieve from the usual strict backwards compatibility standards.</blockquote>



<div><br></div></div><div>One part which can be improved is that right now the selectors module doesn't take advance of e/poll()'s modify() method: instead it just unregister() and register() the fd every time, which is of course considerably slower (there's also a TODO in the code about this). </div>



<div>I guess that can be fixed later in a safely manner.</div></div></div></div></blockquote><div><br></div><div>Yes, it doesn't change the API so doesn't require provisional status.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra">Another concern I have is that we should probably rename self._epoll, self._select, self._kqueue to just "self._poller": that would make subclassing easier (see patch in issue <a href="http://bugs.python.org/issue18931" target="_blank">http://bugs.python.org/issue18931</a>) and would provide a unified interface for those users who want to reference the underlying poller object for some reason.</div>

</div></blockquote></div><br></div><div class="gmail_extra">Oh, but I don't want to make subclassing easier! And I don't want to open up backdoors for "advanced" users. Plus, the object they'd get is different enough that they should probably know what kind of object it is. If there's a missing API on the selector, we should add that, not tell people to help themselves. There lies madness (like the monkey-patching of asyncore in the past).<br>

<br>The only people subclassing the Selector clases should be people proposing changes to the stdlib. Otherwise, if someone wants to write a Selector-like class for a new platform as a 3rd party class, they should  write it from scratch (even using copy/paste!) rather than making a subclass of one of the existing stdlib classes, because otherwise they would (perhaps unintentionally) constrained future evolution of the latter (like the optimization you proposed above).<br>

<br></div><div class="gmail_extra">This downside of using subclassing as an API should be well known by now and widely warned against.<br clear="all"></div><div class="gmail_extra"><br>-- <br>--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)
</div></div>