On Wednesday 07 January 2009 05:27:06 am Sundance wrote: > Adeodato Simó wrote: > >If you see in the middle of a program hex_(foo), you may wonder > > where that came from, whereas qhex(foo) is going to be rather > > obvious. > > Greetings all, > > Might I humbly second this motion? I do understand the usual > reservations about star-imports (being the kind of guy that often > gets to debug other people's work...), but I also do appreciate the > relative ease of getting away with it in PyQt's case, thanks to the > prevalence of the Q prefix in its class names and its relative > absence of module-level functions. > > With this in mind, using the same prefix for the three problematic > functions makes good sense to me. Are there reservations about this > approach that I may not be aware of?
One problem I'd see is that 'qhex' doesn't sort alphabetically the same as 'hex' or 'hex_' does. Also, other bindings - like PyKDE - have the same problem. In the case of PyKDE, it's in a lot more than three places. That makes it a lot harder for people to find it in the docs, especially if they're coming from or reconciling with Qt or KDE docs and method names. The 'q*' convention doesn't make a lot of sense for other bindings packages, and the underscore seems less likely to clash with other people's naming schemes, although in the case of PyQt a clash seems to have a fairly low probability either way. As to the ugliness factor, I somewhat agree, but then we're talking about a language that uses things like __init__ or __main__ all over the place. As to '*' imports - having done a lot of C/C++ where you have to declare every variable, declaring objects in an import statement isn't that difficult. And IIRC, PyKDE4 inherits name clashes between modules from KDE itself in a couple of places. Jim _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
