A startup puzzle

[Erik Max Francis]

I could agree with you if using "from leoGlobals import *" had ever
caused
me the slightest ache. Aside from this startup problem, now
completely
solved, it never has.

Anyone else detect a whiff of irony? "It's never caused me a problem!
Well, except for the problem I just had, but that doesn't count."

 

[John J. Lee]

The problem isn't so much the present namespace pollution, the problem is
that the technique doesn't extend well. There comes a point at which there
are just too many names to keep track of. So if I were managing a group of

[...]

Um, that *is* a form of namespace pollution, isn't it, Edward?

Still, I don't see a perfect alternative. For sure I wouldn't like to put a
g. in front of hundreds or thousands of function calls. I suppose that this
is the kind of thing one would be forced to do in slightly larger
projects...Any other ideas?

Qt names everything with an initial Q (QWidget, QObject, QLineEdit,
....), so from qt import * with PyQt works very well. Only one saved
character, I know, and it doesn't help you given that you've already
named everything without such a convention...


John

 

[Albert Hofkamp]

The more I think about this remark, the more I tend to agree with you. What
I said about not having trouble with "from leoGlobals import *" is true, and
yet...

The problem isn't so much the present namespace pollution, the problem is
that the technique doesn't extend well. There comes a point at which there
are just too many names to keep track of. So if I were managing a group of
programmers (thank goodness I'm not I would tend to disapprove of what I
have done.

Still, I don't see a perfect alternative. For sure I wouldn't like to put a
g. in front of hundreds or thousands of function calls. I suppose that this

Afterwards, yes I agree, it is not fun to do. The lesson is thus don't
get there

While writing code I don't see why adding a module-prefix is a problem,
I do that as standard coding practice. In my experience, typing is not
the problem, the design of the code, and reading code afterwards (by
others!) is the real problem.

I think the benefits of prefixing with module-names are:
- I will NEVER have to search for duplicate function-names imported from
different modules (this alone is reason enough for me, if I can
prevent this search once, I have already saved more time than I have
spent typing a few characters extra).
- In my mind, I don't have a very large collection of function names
without ordering, I have a collection of modules, and within modules a
collection of function names, ie in my mind, I use the module structure.
This is a better scalable structure for remembering functions and what
they do.
- The module name helps understanding what the code is doing.
ie timer.start() is much more helpful than start()
- I have a clear seperation between function calls to my own code and
other people's code, ie the system/module boundaries are very clearly
visible.

However, if you think these benefits do not exist, or are too small,
then by all means, use the "from .... import *" form.


Albert

 

[Edward K. Ream]

My apologies if this is a duplicate. There was a glitch in sending this...

Anyone else detect a whiff of irony? "It's never caused me a problem!
Well, except for the problem I just had, but that doesn't count."

The short answer is: "no, the problem doesn't count".

As I said elsewhere, I am rethinking importing *, and the reason has to do
with scalability. At some point the problems of keeping track of the
globals (pollution, if you must) outweighs the convenience and clarity in
the code. This is essentially a management issue unrelated to the technical
problem I originally posed.

Sure, not importing * solves that technical problem too, but so what?
Initialization is always tricky, but solving initialization problems really
should have little or no bearing on overall design questions. So maybe I'll
eliminate * and maybe I won't. For sure I won't be influenced by whether it
makes initialization easier. And no doubt I'll keep the proxy class: I
really like being able to write app.gui.x instead of app().gui.x. Hmm. If
I eliminate * I could just put a __call__ method in the leoApp class...

Edward

 

[Aahz]

Still, I don't see a perfect alternative. For sure I wouldn't like
to put a g. in front of hundreds or thousands of function calls. I
suppose that this is the kind of thing one would be forced to do in
slightly larger projects...Any other ideas?

Note that it is certainly reasonable to do this:

def foo():
dialog = g.dialog
d1 = dialog()
d2 = dialog()
d3 = dialog()
d4 = dialog()

OTOH, it's a Bad Idea to do this:

def bar():
dialog = g.dialog
d = dialog()

There's plenty of wiggle room for judgement calls of elision while still
keeping the purity of the namespace.