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
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?
[...]
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.
I don't recall seeing this mentioned, but pls forgive if it was.
It is correct that "import wxPython.wx" accomplishes the same as
"import wx" in certain ways, but using the old libs, this would lead
to code like this:
import wxPython.wx
[...]
myFrame = wx.wxFrame(None, -1)
[...]
Using 'wx.wxFrame' is pretty awkward and tends to clobber readability
a bit. So part of the big namespace shift involved stripping that
prefix off.
Also, 'wx' is the package, not 'wxPython.wx', which does tend to be
confusing about just what IS the top level package? In the new
namespace, it's 'wx' with no ambiguity. Bonus on readability again.
I believe also that the changes are being made in the wxPython
namespaces to mirror planned changes in the wxWidgets library.
I believe also that the changes are being made in the wxPython
namespaces to mirror planned changes in the wxWidgets library.
Unfortunatly the wx C++ namespace change got dropped. There were many different proposals, but none offered a way to stay compatible with non-namespace usign apps without making a maintenance nightmare.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Unfortunatly the wx C++ namespace change got dropped. There were many different proposals, but none offered a way to stay compatible with non-namespace usign apps without making a maintenance nightmare.
Darn. Backward compatibility is a major impediment to progress! Why "stay compatible with non-namespace using apps" anyway.
I'm pretty limited in my C++ knowledge, but given how easy it ws in Python, I think a search and replace of:
"wx" with "wx::"
shouldn't be that hard!
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Unfortunatly the wx C++ namespace change got dropped. There were many different proposals, but none offered a way to stay compatible with non-namespace usign apps without making a maintenance nightmare.
Darn. Backward compatibility is a major impediment to progress! Why "stay compatible with non-namespace using apps" anyway.
The wx C++ folks take breaking source compatibility pretty seriously and require a very good reason to break it ans usually a migration path as well. Using C++ namespaces wasn't good enough to cause a break since it doesn't really provide anything that a 'wx' prefix doesn't also provide, and there was no easy way to provide a migration path anyway.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!