This repository was archived by the owner on Nov 23, 2017. It is now read-only.
-
-
Notifications
You must be signed in to change notification settings - Fork 180
This repository was archived by the owner on Nov 23, 2017. It is now read-only.
The API is unpythonic #8
Copy link
Copy link
Closed
Description
I’ll replicate a Mail to or benevolent dictator below.
This bug is about the fact that the tulip API isn’t pythonic, as it uses
Java-style code: The most +1’d comment in GvR’s post about needing experts
in async is by me:
https://plus.google.com/u/0/115212051037621986145/posts/fnb8pqsGGb2
I begged him not to add more java code to the Python stdlib, but unfortunately
PEP 3156 is exactly that in parts.
E.g. “ev.add_signal_handler”. Python has __get/setitem__, so why don’t we
use it? also the “add” part is extremely misleading as it’s in reality
“set”, since the old handler is replaced. it’s a setter → unpythonic.
why not “ev.signal_handlers[sig] = callback” (call without arguments) and
“ev.signal_handlers[sig] = (callback, *args)”, as well as “del
ev.signal_handlers[sig]”? that would be so much more pythonic. also we could
easily get a dict of currently registered handlers via
“ev.signal_handlers”, and one registered handler via
“ev.signal_handlers[sig]”.
The same for readers and writers. It seems that the current API is the
equivalent of “Programmer art” and not intended for general consumption.
I’d strongly hope for a pythonificating revision.
Original issue reported on code.google.com by trueflyi...@gmail.com
on 18 Mar 2013 at 9:08