Since Patrick is going to summarize, I want to clarify the issue of one
namespace or many. It seems like Robin is in favor of continuing to have one
large wx namespace rather than splitting up the library like:
wx.bindings
wx.constants
wx.dialogs
wx.html
wx.printing
...
Regardless of whether you use 'from wxPython import wx' or 'from wxPython.wx
import *' the namespace is large enough to be almost useless in the shell
for autocomplete.
from wxPython import wx
len(dir(wx))
2733
Splitting up the namespace would make it easier to use interactively and may
improve organization of documentation, but it may also just make the lib
more difficult to use unless it is clearly documented. Yes, much of these
discussions hinge on improved, wxPython-specific documentation.
Most of the large Python packages seem to be split up into a hierarchy.
A complication with wxPython, is that there is stuff from wxWindows, of
which some are in a separate lib, plus there are the user-contributed
modules that are already in separate libs, usually wxPython.lib.something
though html is wxPython.html, stc is wxPython.stc, etc. The point is that we
have a huge wxPython namespace, but not everything is in it, but if we were
to re-organize so the organization is more logical, it will require
evaluating if we want to clearly identify user-contribs and make sure that
the dependencies make sense so you don't end up loading everything if you
don't need to.
Changing the module organization may lead to quicker load times. A
reorganization would make the overall wxPython package size larger due to
keeping the backwards compatible modules. Would it have any impact on the
.pyd files or compiled DLLs and such?
ka