Reverse renamers?

Robin,

I was discussing the conversion process with one of the library contributors
and he had a question:

"I have some questions though: Shouldn't the lib files also be converted
as well, and either way, are there guidelines on how to do these
conversions? ie. what should I convert to make the code be "model code"?
What is the "backward-compatible" strategy for 2.5? Will the existing
idioms/syntax still work? (I would expect so, or there will be a lot
of very unhappy people out there with old code who can't upgrade their
copies of wxPython without a ton of effort!) If I convert the lib
files, then what should I do by way of namespace issues to preserve
backward compatibility? ie. the demos refer to the classes
wxMaskedTextCtrl, wxMaskedComboBox, wxTimeCtrl, etc. Will these
need to be wx.lib.MaskedTextCtrl, wx.lib.MaskedComboBox etc, and if
so, what idiom should I use so that code using the old names won't
break?"

From what I was reading in an earlier mail from you, there seems to be a

plan to have a reverse renaming scheme implemented for backwards
compatability, am I reading that correctly?

Jeff Grimmett wrote:

Robin,

I was discussing the conversion process with one of the library contributors and he had a question:

I've just responded to the same message. Just for the record, here is
my responses:

Will Sadkin wrote:

I have some questions though: Shouldn't the lib files also be converted as well,

Yes. It hasn't been organized yet but we will need to do similar things
to the library modules.

and either way, are there guidelines on how to do these conversions?

Yes. They're in the wiki for the demo modules, and the lib modules will
be mostly the same.

ie. what should I convert to make the code be "model code"?

It boils down to two things for lib modules: a. Use the wx namespace,
b. expect to live in the wx namespace (so no "wx" prefixes on global names.)

What is the "backward-compatible" strategy for 2.5? Will the existing
idioms/syntax still work? (I would expect so, or there will be a lot of very unhappy people out there with old code who can't upgrade their copies of wxPython without a ton of effort!)

Yep.

If I convert the lib files, then what should I do by way of namespace
issues to preserve backward compatibility? ie. the demos refer to the classes wxMaskedTextCtrl, wxMaskedComboBox, wxTimeCtrl, etc. Will
these need to be wx.lib.MaskedTextCtrl, wx.lib.MaskedComboBox etc,

Actually, it would be wx.lib.maskedctrl.MaskedTextCtrl, but that is a
bit long-winded so perhaps better code for the demo would be:

     from wx.lib.maskedctrl import MaskedTextCtrl
or maybe
     from wx.lib import maskedctrl

and if so, what idiom should I use so that code using the old names won't break?

There is a set of hand-made "reverse renamer" modules in the
wxPython.lib package that imports the module from the wx.lib package and
then assigns its global names into the local namespace. If the names
had a 'wx' prefix before then the assignment should put it back on. For
example:

http://cvs.wxwindows.org/viewcvs.cgi/wxWindows/wxPython/wxPython/lib/buttons.py?rev=1.16&content-type=text/vnd.viewcvs-markup

I've generated a bunch of those for the existing lib modules, but they
will need to be tweaked when the wx.lib module is converted, and some
of them may not have all the right globals in them yet.

ยทยทยท

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!