[Python-Dev] Confirming status of new modules in 3.4

[Guido van Rossum]

On Sat, Mar 15, 2014 at 4:02 AM, Giampaolo Rodola' <g.rodola at gmail.com>wrote:

>
> On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum <guido at python.org>wrote:
>
>> 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.
>
>
> 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).
> I guess that can be fixed later in a safely manner.
>

Yes, it doesn't change the API so doesn't require provisional status.


> 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 http://bugs.python.org/issue18931)
> and would provide a unified interface for those users who want to reference
> the underlying poller object for some reason.
>

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).

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).

This downside of using subclassing as an API should be well known by now
and widely warned against.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140315/faa2113e/attachment.html>