Skip to content
This repository was archived by the owner on Nov 23, 2017. It is now read-only.
This repository was archived by the owner on Nov 23, 2017. It is now read-only.

The API is unpythonic #8

@GoogleCodeExporter

Description

@GoogleCodeExporter
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

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions