Will Sadkin <wsadkin@nameconnector.com> writes:
Robin Dunn wrote:
[...]
> A few issues to still be resoved:
[..]
> 3. What to do about all the modules in wxPython.lib with classes and
> such that have a wx prefix.
Thanks Robin; from the lack of response to my post, I wasn't
sure anyone had read it... good to know you did!
So what to *do*? At this point, I think it's safe to say
that there is a ton of code out there that may be using
wxBlah classes defined in the lib directory...
That's not a problem. The "wx" prefix can be stripped off them at
runtime the same way we are doing for all the other modules, like stc,
html, etc.
I see two possible alternatives:
1) Add aliases inside each of the relevant code modules,
for both the old and new symbol names. This shouldn't
be *too* bad; by my count there are only 52 classes
defined there of the form wxBlah, and 7 functions,
all of which are of the form wxPyBlah, so this
shouldn't pollute the namespace that badly.
(for the latter, we could just eliminate the wxPy
altogether in the alias.)
-100 on aliases in the same namespace. (Just to be clear about it 
Questions re: this approach:
- Can you then rewrite these modules to internally
use the new import scheme whilst being imported
themselves the old way?
- If so, will this cause name conflicts?
- Or must the existing lib files always use the old
import and naming scheme to ensure viability?
(I'm not an internals guy enough to know...)
If someone wants to, they can revise the internals to use the new
module structure, but they must not change their public api (class and
method names) due to backward compatibility. For example, here is a
class from lib.dialogs:
Before
ยทยทยท
======
from wxPython import wx
from layoutf import Layoutf
class wxScrolledMessageDialog(wx.wxDialog):
def __init__(self, parent, msg, caption, pos = wx.wxDefaultPosition, size = (500,300)):
wx.wxDialog.__init__(self, parent, -1, caption, pos, size)
x, y = pos
if x == -1 and y == -1:
self.CenterOnScreen(wx.wxBOTH)
text = wx.wxTextCtrl(self, -1, msg, wx.wxDefaultPosition,
wx.wxDefaultSize,
wx.wxTE_MULTILINE | wx.wxTE_READONLY)
ok = wx.wxButton(self, wx.wxID_OK, "OK")
text.SetConstraints(Layoutf('t=t5#1;b=t5#2;l=l5#1;r=r5#1', (self,ok)))
ok.SetConstraints(Layoutf('b=b5#1;x%w50#1;w!80;h!25', (self,)))
self.SetAutoLayout(1)
self.Layout()
After
import wx
from layoutf import Layoutf
class wxScrolledMessageDialog(wx.Dialog):
def __init__(self, parent, msg, caption, pos = wx.DefaultPosition, size = (500,300)):
wx.Dialog.__init__(self, parent, -1, caption, pos, size)
x, y = pos
if x == -1 and y == -1:
self.CenterOnScreen(wx.BOTH)
text = wx.TextCtrl(self, -1, msg, wx.DefaultPosition,
wx.DefaultSize,
wx.TE_MULTILINE | wx.TE_READONLY)
ok = wx.Button(self, wx.ID_OK, "OK")
text.SetConstraints(Layoutf('t=t5#1;b=t5#2;l=l5#1;r=r5#1', (self,ok)))
ok.SetConstraints(Layoutf('b=b5#1;x%w50#1;w!80;h!25', (self,)))
self.SetAutoLayout(1)
self.Layout()
At some distant point in the future we may change the class name from
wxScrolledMessageDialog to ScrolledMessageDialog. Or not. We'll see.
2) Duplicate the code for the new package, rewriting
it all to use the new scheme. This would be cleaner,
but maintenance would then become a nightmare...
(NOT my personal preference.)
I think this would be far too painful compared to the example I just
showed. And keep in mind, the example is optional. The only reason to
revise the internals is to practice what we preach. Technically, all
existing library code should continue to work under the new package
scheme without modification. Users of the new scheme will be able to
do:
from wx.lib.dialogs import ScrolledMessageDialog
In fact, now you can. I just implemented it:
>>> from wx.lib.dialogs import ScrolledMessageDialog
>>> ScrolledMessageDialog
<class wxPython.lib.dialogs.wxScrolledMessageDialog at 0x88a6f24>
>>>
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------