[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