Charles-François Natali added the comment: > Please consider my patches instead; it seems our patches crossed. Merging is > now difficult because I already submitted my version to Tulip.
That's fine, I don't think there's a point into maintaining a standalone patch for now: we can see how it goes with Tulip, flesh out the API and merge it when it's ready (or when Tulip goes in)? > Also my version makes fewer syscalls when unregistering a FD that has both > read and write events registered. It did it on purpose, because I wasn't sure whether kqueue ops can accept more than one filter at a time. If that's the case, then you can do the same thing for register(). > Regarding the _Key return value: I think it's asking for trouble if the > signature of the base class differs from that of the subclass. The return > value may even be useful occasionally. Agreed (but then it might be better to change _Key to Key if it's public). > Given that no spurious FD events are now reported by the unittests, I'm not > sure that it is useful to log and ignore them; it may be better to have the > exception be raised, as it might expose an app bug, and in my experience it > usually ends up in an infinite busy-wait loop once it happens. Sounds good to me. ---------- _______________________________________ 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
