Message
Is it not done for the same reasons as the “using namespace” statement in Standard C++? Isn’t it to prevent name collisions by localizing the names of identifiers?
The replies to this so far have been absolutely about avoiding ‘from X import *’ – as I can testify after commiting that sin for so long and then having to rewrite all my import statements in quite a large application.
However, so far as I can see, they don’t answer the fundamental question that was asked: What is the value of the new name space conventions?
Using the old name space conventions, one does not need to say ‘from wxpython.wx import *’, and using the new name space conventions you can say ‘from wx import *’. So the answer doesn’t seem to lie in the direction of the answers given so far.
My guess is that the real answer lies somewhere in the area of source and library organization for wxWindows. But I’d be interested in more details as well.
Gary H. Merrill
Director and Principal Scientist, New Applications
Data Exploration Sciences
GlaxoSmithKline Inc.
(919) 483-8456
Is it not done for the same reasons
as the “using namespace” statement in Standard C++? Isn’t it
to prevent name collisions by localizing the names of identifiers?
The replies to this so far have been absolutely about avoiding ‘from X
import *’ – as I can testify after commiting that sin for so long and
then having to rewrite all my import statements in quite a large application.
However, so far as I can see, they don’t answer the fundamental question
that was asked: What is the value of the new name space conventions?
Using the old name space conventions, one does not need to say ‘from
wxpython.wx import *’, and using the new name space conventions you can
say ‘from wx import *’. So the answer doesn’t seem to lie in the
direction of the answers given so far.
My guess is that the real answer lies somewhere in the area of source and
library organization for wxWindows. But I’d be interested in more
details as well.
Gary H. Merrill
Director and Principal Scientist, New Applications
But keep in mind that using the old namespace, you'd be doing wx.wxWhatever, vs. new-style wx.Whatever.
I haven't been paying attention lately, but IIRC from the original discussions about this, there were several reasons for the changes. Having all of the wxPython namespace at the global level makes life *really* difficult for a lot of introspective code (like source code browsers and RAD tools, for example), which have to search through that namespace. I believe there was also some discussion that wxWindows, now wxWidgets, was intending to introduce their own (C++) namespace soon anyhow, so that this wxPython would mirror that. (I don't know, however, whether this has actually come about.) Also, I believe that wxPython defined a True/False which, under newer versions of Python and using the "import *" scheme, shadowed the newly-introduced Python booleans True and False. (Whether this presented a particular problem for particular applications is irrelevant -- it's a sign of the potential for problems created by polluting the global namespace with a few hundreds (or thousands) of additional names.)
Once the decision was made to encourage people to avoid "import *", then it was a small step to see that it made it better to remove the wx from (almost) all of the identifiers in the library, to avoid the typing duplication (wx.wxX). The overall effect on code in use was to introduce a period in between the wx and the rest of the identifier (i.e., switching from wxFrame to wx.Frame), a task that can mostly be done with a simple search-and-replace.
Jeff Shannon
Technician/Programmer
Credit International
···
gary.h.merrill@gsk.com wrote:
But you can accomplish the same thing with the old name space, can't you?
Jeff’s comments seem to be pretty much to
the point. And as I opined and Vicki seems to think, the real reason
has to do with issues of the underlying C++ implementation.
I did notice the potential True/False problems
myself some time ago.
However in the “mostly be done with
a simple search and replace” the emphasis in my experience (about
20,000 lines of code) should definitely be on the “mostly”. Some
minor pains that I recall pertained to how to handle imports of (and references
within) various packages, getting True and False correctly referenced (is
there any guarantee that wx.True and True correspond in any way at all?),
and changing to new versioni of exception designators. Aside from
that, it was mostly tedious but well worth the effort.
···
Gary H. Merrill
Director and Principal Scientist, New Applications
(is there any guarantee that wx.True and True correspond in any way at all?),
There is no wx.True any longer (with the new wx namespace anyway) unless you are running on Python 2.2.0 which doesn't have True/False built-in.
And while I don't think there was ever a "guarantee" that they would correspond, there is a guarantee about how True/False are defined, and that does (seem to, AFAICT) match how wx.True and wx.False were defined. I believe (though I haven't tested) that the transition from 'import *; True' to 'import wx; True' should be transparent except under Python 2.2.[1+], where you get a warning that you're shadowing the builtin True.
Jeff Shannon
Technician/Programmer
Credit International
is like