Guido van Rossum added the comment: Sorry, replying to some direct questions in the bug:
> I also made the following changes: > - BaseSelector is an abstract base class (so one could imagine user code > implementing its own selector on top of it) Fine (though I had to work around this for some tulip tests). > - SelectorKey is a named tuple: I think that's better than a class, > because SelectorKeys can be returned to the user (register(), get_info(), > etc), and we don't want him to mess with them. Also, we get a nice repr() > for free Fine. > - since SelectorKey is immutable, I added a get_keys() method, which > returns all the keys registered. Since it's a dict values, the user can't > mess with it Fine. (I missed this in the code review.) > This get_keys() method superseedes the registered_count() method, which > can be simply replaced with len(selector.get_keys()). We could probably > remove it? It also sort of superseedes the get_info() method: I don't > remember, why was it needed? registered_count() is only used internally so you can kill it. get_info() is important for Tulip, please keep it. > Would it be possible to get it into 3.4? I think so, if Antoine agrees. The next alpha would be at your service. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16853> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
