471,310 Members | 1,069 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,310 software developers and data experts.

wxPython - wx package (new style wxPython?)

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

Jul 18 '05 #1
6 2087
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/>
Jul 18 '05 #2
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

Jul 18 '05 #3
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

Jul 18 '05 #4
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

Jul 18 '05 #5
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.
Jul 18 '05 #6
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
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by wang xiaoyu | last post: by
1 post views Thread by mdk.R | last post: by
25 posts views Thread by BJörn Lindqvist | last post: by
5 posts views Thread by Daniel Bickett | last post: by
9 posts views Thread by amhoov | last post: by
reply views Thread by Robin Dunn | last post: by
6 posts views Thread by Robin Dunn | last post: by
3 posts views Thread by SMALLp | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.