Message194593
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. |
|
Date |
User |
Action |
Args |
2013-08-06 23:55:39 | gvanrossum | set | recipients:
+ gvanrossum, pitrou, giampaolo.rodola, christian.heimes, meador.inge, neologix, rosslagerwall, sbt, felipecruz |
2013-08-06 23:55:39 | gvanrossum | link | issue16853 messages |
2013-08-06 23:55:39 | gvanrossum | create | |
|