I'm starting a new thread to continue the discussion about ways to
clean up the current wxPython.wx namespace, the possibility of
introducing a new package with a cleaner namespace, and the
possibility of dropping the wx prefix from class names (all while
maintaining backward compatibility).
In the next day or two I'll write up a summary wxPEP so that we've can
memorialize this issue for future generations. In the mean time here
are some highlights:
* we should be able to drop the wx prefix from class names, but
probably won't be able to change their __name__ attribute to match,
unless we used a completely dynamic approach (getattr/setattr),
rather than modifying the name attribute of the real class.
* the names of helper event functions (EVT_SOMETHING) need to remain
the same for effective communication with the wxWindows folks, and
may remain in the main wx namespace. The event constants
(wxEVT_SOMETHING) could be moved to a submodule (wx.const, perhaps)
* the wx namespace is quite large (it breaks the namespace tree and
autocomplete lists under PyCrust, for example).
Can we get some opinions of possibly dividing up the wx namespace?
Constants are an easy target for moving and dividing. Anyone have
suggestions?
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
As I said in the beginning of the discussion, I think object
inspectors and more feature rich IDEs etc are things we will
see more of in the future. My *main* issue is to keep stuff
out of *my* global and local namespaces, so that I can view
*my*own* objects at least. But obviously, it's a Good Thing
if the wx namespaces can be inspected and autocompletion etc
works.
Look at how people use tools like Visual Basic. (Not that
it's easier to use than Python in general.) Interactive IDE
features like autocomplete and parameter lists etc will become
more and more common and expected by new developers. <rant>But
please, pretty please, never ever ever write a soruce code
editor that whips up a captive dialog box with a "compilation
error" when you leave a line of code with a syntax error, so
that typing part of a line, and then going to another line to
copy some code that you want to paste into the line you were
editing, is interrupted by fending off stupid error messages.
I'm sooo tired of VBA, and really hope that my mantra that
Excel might work for a prototype, but move to Python when this
is for real sinks in for this customer... Particularly since
he is putting the stuff into production...</rant>
···
At 14:16 2003-03-04 -0600, Patrick K. O'Brien wrote:
* the wx namespace is quite large (it breaks the namespace tree and
autocomplete lists under PyCrust, for example).
I'm starting a new thread to continue the discussion about ways to
clean up the current wxPython.wx namespace, the possibility of
introducing a new package with a cleaner namespace, and the
possibility of dropping the wx prefix from class names (all while
maintaining backward compatibility).
In the next day or two I'll write up a summary wxPEP so that we've can
memorialize this issue for future generations. In the mean time here
are some highlights:
Isn't it possible also to get rid of the ugly static methods translation?
I mean something like this:
OLD:
from wxPython.wx import *
wxWindow_FindFocus()
NEW:
import wx
wx.Window.FindFocus()
If you are concerned about compatibility with python < 2.2 ('cos the
previous thing presupposes the usage of staticmethod), there's a recipe
in the Cookbook that solves this very easily.
Isn't it possible also to get rid of the ugly static methods translation?
I mean something like this:
OLD:
from wxPython.wx import *
wxWindow_FindFocus()
NEW:
import wx
wx.Window.FindFocus()
If you are concerned about compatibility with python < 2.2 ('cos the
previous thing presupposes the usage of staticmethod), there's a recipe
in the Cookbook that solves this very easily.
I don't understand enough about C to understand exactly why these were
done the way they were, but why couldn't we just have wx.FindFocus()?
The current implementation is just a simple function:
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
Isn't it possible also to get rid of the ugly static methods translation?
I mean something like this:
OLD:
from wxPython.wx import *
wxWindow_FindFocus()
NEW:
import wx
wx.Window.FindFocus()
If you are concerned about compatibility with python < 2.2 ('cos the
previous thing presupposes the usage of staticmethod), there's a recipe
in the Cookbook that solves this very easily.
I don't understand enough about C to understand exactly why these were
done the way they were,
Because they are static methods of wxWindow (or whatever class) and so are logically associated with the class eventhough they don't need an instance of the class to opperate upon.
but why couldn't we just have wx.FindFocus()?
I think that the logical association is important and should be kept. For example, dropping the wxLog_ (or Log_ with the new names) from the wxLog_IsEnabled function makes absolutly no sense at all.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I think that the logical association is important and should be
kept. For example, dropping the wxLog_ (or Log_ with the new names)
from the wxLog_IsEnabled function makes absolutly no sense at all.
I see. Yes, that would be silly.
···
--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------