[PyKDE] PyQt v4 Roadmap

[Giovanni Bajo]

Ulrich Berning <ulrich.berning at t-online.de> wrote:

> Using from ... import * in normal code is (and was) always a bad
> idea. I have avoided it whenever possible. You pollute your local
> namespace with
> all names from the imported modules and name clashes are are likely to
> occur.

You probably did not carefully read my message. I am not saying that
namespaces are bad. Namespaces are good (they a "honking great idea"
somebody would say). But the fact is that Qt already imposes its own
namespace, it is just not a namespace in the Python sense, but just a
common prefix to names as we used to do in C. All Qt names have the form
Q+english word(s). If I were to name a class of mines "QListView" within a
Qt application I would be totally dumb. I would never allow such a class
to pass even the simplest review, because it would be totally confusing,
no matter how many namespaces you put in front of it. The same would apply
for other libraries. If all wxWindows symbols begin with "wx", it does not
make sense to say wxWindow.wxListView. The "wx" is already a namespace.

Also, let's say you use "import qt". Then, why should I not be allowed to
have a module named "qt" in my project? You would forbid that to me saying
that the namespace "qt" is already reserved for the Qt library. For the
very same reason, I disallow to name a class Q+english word. I don't see
any difference.


> Are you always absolutely sure, that a name defined in any of
> the qt modules is never defined in any other module that you import?

I would never allow a class named Q + english word in an application using
Qt. That's the only kind of names exported by PyQt that I'm aware of. All
the global constants are within the class Qt (such as Qt.red) so they have
sort of namespace already. I would be surprised if you prefer "qt.Qt.red"
to "Qt.red". I cannot see how the former is any better than the latter.


> important than saving a few character typings. Reading
> qtsql.QDateTable and qttable.QCheckTableItem is as clear
> as possible, because I can see, where both names belong to.

Are you really saying that qtsql.QDateTable is more readable than
QDateTable? I totally disagree. I would agree that Qt.DateTable is clearer
than DateTable.

And I really do not need to know whether a name comes from qttable or
qtsql, really, I don't care. It is just something in the way: I have to
remember every time which sub-part of Qt is exporting that class. I don't
really want to know that.

> Reading QDataTable and
> QCheckTableItem, I
> always have to worry where the names come from (I would guess qttable,
> because the word 'Table' occurs in both names).

Why should you worry? In my applicatons, we are using Qt professional, we
have access to both those classes, so we really do not care. As far as I
know, they are both part of Qt proper, and that's enough for me.

> When you have to maintain a large amount of code for a long time,
> readability is one of the most important things.

I never debated that.

> Try to maintain such applications if you make heavy use of
> import *. Your best
> friends will become 'grep' and 'find', always searching for the one
> module where this damned function 'foo' is defined.

I strongly believe you used a regexp match on my mail and posted a standard
reply (possibly tuned for the average Python newbie). I never advocated
"heavy use of import*". In fact, it is a construct I rarely use. PyQt is
one of the case where the construct really turns out to be useful.

Giovanni Bajo