[PyQt] Symbol naming system for PyQt under Python 3

Giovanni Bajo rasky at develer.com
Sat Dec 13 12:08:57 GMT 2008


On ven, 2008-12-12 at 22:57 +0000, Paul A. Giannaros wrote:
> On Fri, Dec 12, 2008 at 10:28 PM, Giovanni Bajo <rasky at develer.com> wrote:
> > On 12/12/2008 11:18 PM, Paul A. Giannaros wrote:
> >>
> >> On Fri, Dec 12, 2008 at 6:27 PM, Phil Thompson
> >> <phil at riverbankcomputing.com> wrote:
> >>>
> >>> On Fri, 12 Dec 2008 18:09:56 +0000, "Paul A. Giannaros"
> >>> <paul at giannaros.org> wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> When there was a discussion regarding PyQt wishes for Python 3.0 I
> >>>> proposed changing the mechanism by which you refer to symbols[1] .
> >>>> Thus something like "QtGui.QApplication" could be refered to as
> >>>> "Qt.Application".
> >>>> As Qt does not use namespaces itself, there would be no conflicts of
> >>>> names. The idea is that you'd then import any module and its symbols
> >>>> would then be added to the Qt namespace when you've done so. This
> >>>> system would therefore save on redundant typing while sidestepping
> >>>> namespace pollution.
> >>>>
> >>>> Any thoughts on this?
> >>>
> >>> Nothing printable ;)
> >>>
> >>> You can already do Qt.QApplication is you really want to, so you are
> >>> saving
> >>> yourself one character.
> >>
> >> "from PyQt4 import Qt" imports every module if I'm not mistaken.
> >> Wanting a sane way of referencing Qt's symbols is not the same as
> >> wanting every symbol from every module to be imported.
> >
> > How is it possible to implement your proposal without importing every module
> > at the same time, and without playing magic tricks?
> >
> >> Surely losing that one character is great if it's unnecessary. The
> >> QtRuby guys seem to use exactly the same naming system that I propose
> >> and it works fine for them and looks much better.
> >
> > In the number-of-character race, I win with star-imports:
> >
> > from PyQt4.QtCore import *
> > from PyQt4.QtGui import *
> >
> > w = QWidget()
> >
> > Since 99.999% of the names in there starts with "Q", I never ever have a
> > conflict. The code is easy on the eye, and resembles its C++ equivalent.
> 
> Way out, I'm afraid. ~60% of QtCore symbols start with a "Q", and a
> further ~21% start with a "q". That still leaves around 32 symbols
> (16%) once you weed out __doc__ etc. Some have ridiculously common
> names ("center", "flush", "bin"), and some conflict with basic Python
> builtins ("hex" and "oct"). QtGui is much better but still has a
> "Display" class.

If you put Qt modules together, you get more than 90% of the symbols
which are either "q" (followed by a capital letter) or "Q" or are "full
caps", which I call "a namespace".

There are just a few symbols that escape it, and you know what, I don't
care. Many people seem to assume that putting stuff into a namespace is
a guilty that should be sentenced for life, but they fail to come up
with a reason why. The "ridiculously common names" are really
unimportant: if you need them, don't override them; otherwise, go ahead
and define your own "center", it doesn't matter.

The *only* thing that I will agree that is a problem is the builtin
overrides (which reduces to hex and bin, AFAIK). In 4 years of PyQt and
star-imports, I have been confused 2 or 3 times by hex (I wasted
probably 2 minutes all in all).

If those could be removed from the symbols that are star-imported, I
would be happy. If not, I still believe that the benefits of not having
to pollute all your code with stuff like "QtCore.QCoreApplication"
instead of "QCoreApplication" greatly overweights a couple of minor
builtins being hidden.

> Anyways, I believe I've seen it mentioned on this list that "import *"
> with PyQt method is frowned upon.

Probably by someone it is. On the other hand, I still suggest it as the
best way of writing PyQt code to all our customers and all the people I
meet and in the conferences I do on the subject. People are usually very
happy to use shorter names which are still fully readable and face no
side effects at all. All the objections I have heard are only
hypothetical ("what if there is a conflict") or philosophical ("they
pollute my namespace" -- so what?), while star-imports in this case are
really really pragmatics.

Anyway, it's a coding convention, so it's really a useless debate. 

I just wanted to say that, since star-imports are live, kicking, and
used in much production code with PyQt, I don't see a point to introduce
yet another name import convention in PyQt just to save one character
over the longer version.

> > Doh, so you're proposing that importing a module has the side effect of
> > populating a different namespace. This is absolutely implicit and
> > counter-intuitive, and has no equivalent in the standard library nor any
> > external library I can think of.
> 
> No, my proposal is dropping the leading Q and using a Qt namespace
> that doesn't require loading all modules. That way does seem
> particularly odd, though. Perhaps a less counter-intuitive method
> would be something like
> 
> from pyqt4 import Qt
> Qt.load('core', 'gui', 'svg')

Surely better than your previous suggestion.
-- 
Giovanni Bajo
Develer S.r.l.
http://www.develer.com




More information about the PyQt mailing list