This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients christian.heimes, felipecruz, giampaolo.rodola, gvanrossum, meador.inge, neologix, pitrou, rosslagerwall, sbt
Date 2013-08-06.23:55:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAP7+vJ+XOepU-wuJw5ii2jxKQpFM1tK-Ljj2-LT=gFk0e1hO3w@mail.gmail.com>
In-reply-to <1375456613.31.0.987002581332.issue16853@psf.upfronthosting.co.za>
Content
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.
History
Date User Action Args
2013-08-06 23:55:39gvanrossumsetrecipients: + gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, neologix, rosslagerwall, sbt, felipecruz
2013-08-06 23:55:39gvanrossumlinkissue16853 messages
2013-08-06 23:55:39gvanrossumcreate