[PyQt] PyQt4.Qtcore defines 'hex'
Jim Bublitz
jbublitz at nwinternet.com
Wed Jan 7 18:17:56 GMT 2009
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
More information about the PyQt
mailing list