wxPython - wx package (new style wxPython?)

[Logan]

Would you recommend to use the wx package of wxPython?

From the documentation:

Provides a way to drop the wx prefix from wxPython objects by
dynamically loading and renaming objects from the real wxPython
package. This is the first phase of a transition to a new style
of using wxPython. For example:

import wx
class MyFrame(wx.Frame):
...

instead of:

from wxPython.wx import *
class MyFrame(wxFrame):
...

What does 'this is the first phase of a transition to a new style
using wxPython' in the above mean? Will this new style become the
only way to use wxPython in future releases?

Thanks in advance for any answers.

--
mailto: logan@phreaker(NoSpam).net

[Ben Finney]

On Wed, 26 Nov 2003 01:01:59 +0100, Logan wrote:

Would you recommend to use the wx package of wxPython?
Because it removes the redundancy in the module object names, yes. As
for any other qualities the 'wx' package might have, I can't say; if
it's exactly the same functionality and call styles as the existing
wxPython.wx then I can't see a reason not to use it.
From the documentation:

Provides a way to drop the wx prefix from wxPython objects by
dynamically loading and renaming objects from the real wxPython
package. This is the first phase of a transition to a new style
of using wxPython.

What does 'this is the first phase of a transition to a new style
using wxPython' in the above mean? Will this new style become the
only way to use wxPython in future releases?

'from foo import *' is heavily deprecated in any case; this "new style
of using wxPython" is merely saying (AIUI) that the 'wx' package allows
a more natural usage of wxPython objects without needing to use a
deprecated import style.

--
\ "Quidquid latine dictum sit, altum viditur." ("Whatever is |
`\ said in Latin, sounds profound.") -- Anonymous |
_o__) |
Ben Finney <http://bignose.squidly.org/>

[James Tanis]

Bah, I think they are just over-glorifying the change. In my
mind, it's the same exact thing. The only real different is when you
"from wxPython.wx import *" it reads everything into your local
namespace which is traditionally considered not the best thing to do.
I really have no idea if the "transition" when finished will remain
backwards compatible, but I'm guessing from the description of the
implementation that it is.

BTW, In the future you may want to use a real email address so that you
can receive an answer.

On Tue, 2003-11-25 at 19:01, Logan wrote:

Would you recommend to use the wx package of wxPython?

From the documentation:

Provides a way to drop the wx prefix from wxPython objects by
dynamically loading and renaming objects from the real wxPython
package. This is the first phase of a transition to a new style
of using wxPython. For example:

import wx
class MyFrame(wx.Frame):
...

instead of:

from wxPython.wx import *
class MyFrame(wxFrame):
...

What does 'this is the first phase of a transition to a new style
using wxPython' in the above mean? Will this new style become the
only way to use wxPython in future releases?

Thanks in advance for any answers.

--
mailto: logan@phreaker(NoSpam).net

[Logan]

On Tue, 25 Nov 2003 19:20:08 -0500, James Tanis wrote:

BTW, In the future you may want to use a real email address
so that you can receive an answer.

Thanks for your comments regarding my question.

About the 'real email address':

I do use a real address! You can find the address in the
signatures of my postings; just remove the part saying '(NoSpam)'.

I don't use the real address in the headers of my postings
(but: lo***@phreaker.nospam) because the last time (about a
month ago) I used my real address, I got thousands and thousands
of SPAM mails, viruses etc. per week. This was really annoying.

--
mailto: logan@phreaker(NoSpam).net

[Mark Hahn]

I just finished a moderate sized wxPython app from scratch using wx and I'm
happy I did. There were a few times I had to put my thinking cap on, but it
worked out well.

"Logan" <lo***@phreaker.nospam> wrote in message
news:pa****************************@phreaker.nospa m...

Would you recommend to use the wx package of wxPython?

From the documentation:

Provides a way to drop the wx prefix from wxPython objects by
dynamically loading and renaming objects from the real wxPython
package. This is the first phase of a transition to a new style
of using wxPython. For example:

import wx
class MyFrame(wx.Frame):
...

instead of:

from wxPython.wx import *
class MyFrame(wxFrame):
...

What does 'this is the first phase of a transition to a new style
using wxPython' in the above mean? Will this new style become the
only way to use wxPython in future releases?

Thanks in advance for any answers.

--
mailto: logan@phreaker(NoSpam).net

[Mel Wilson]

In article <pa****************************@phreaker.nospam> ,
Logan <lo***@phreaker.nospam> wrote:

Would you recommend to use the wx package of wxPython?

From the documentation:

Provides a way to drop the wx prefix from wxPython objects by
dynamically loading and renaming objects from the real wxPython
package. This is the first phase of a transition to a new style
of using wxPython. For example:

import wx
class MyFrame(wx.Frame):
...

instead of:

from wxPython.wx import *
class MyFrame(wxFrame):
...

What does 'this is the first phase of a transition to a new style
using wxPython' in the above mean? Will this new style become the
only way to use wxPython in future releases?

I think it's on the whole an improvement. One thing I've
found with the current version is that in a sub-module, only
the old style works, that is in a two-file program, the
setup:

File dbmaint.pyw:

import wx
import personalcontact
....
File personalcontact.py:

from wxPython.wx import *
....
is the only arrangement that works for me. I suspect that
the wx.py file contrives to build the wx symbol structure in
the invokers namespace, and only operates once. I assume
(if I'm right) that that's something to be fixed when the
new scheme becomes standard.

Regards. Mel.

[David Bolen]

James Tanis <jt****@charter.net> writes:

Bah, I think they are just over-glorifying the change. In my
mind, it's the same exact thing. The only real different is when you
"from wxPython.wx import *" it reads everything into your local
namespace which is traditionally considered not the best thing to do.
I really have no idea if the "transition" when finished will remain
backwards compatible, but I'm guessing from the description of the
implementation that it is.

To be honest, for a while now I've often been doing:

from wxPython import wx

and putting up with duplicated references to wx (e.g., wx.wxWindow).
That avoids both the pollution of the local namespace and the overhead
of pulling in the several thousand names (I got a noticeable
performance speed up in an application with many plugins since each
plugin no longer needed to make extra references for all the wx
objects in the plugin's local namespace).

One reason why I haven't moved to the new wx package yet is that it's
implemented as a lazy evaluation approach (probably for performance),
which means it doesn't play nice with interface tools that need
introspection (e.g., IDE completion) which some of my other developers
use. Once wx becomes a full fledged normal module I'd definitely
consider moving to it for the same reasons that I use the above
approach now.

-- David