Bug in init.py of the wx pkg + other remarks

Jean-Michel_Fauth · May 31, 2003, 9:29am

Hi all,

I am already in front of my screen, while america is still
sleeping, but anyway.

1) The renaming process in the __init__.py is not complete.
It renames wx*** names but it forgets to rename WX*** names.
Bug or feature?

2) It has been said
from wxPython.wx import * pollutes the name space
This is true, but a good pyhoneer (pythonist?) had
introduced an __all__ = [...] statement in the wx.py.
(Not completely sure that this had resolved all the
problems).

3) Thanks Robin. The 'wx.py' in the remark 2) is a file, not
a package.

4) Already said, wxSTC_CONSTANTS are now,
STC_CONSTANTS, which leads to some
stc.STC_CONSTANTS in the code. !?

5) Not to do with the wx pkg. The assert statements in the
wxmsw240h.dll produce sometimes unclear error messages.
I mean error, that are no more intercepted by the python
interpreter. A single line, something like:
Assert error: e:\projects\robins\python\stuff Unregister
class....
Sorry for this stupid example, but I don't succeed to
reproduce the error!

6) I would really appreciate comments about my previous
post 'When the new wx package reveals some wxPython
weakness'.

Jean-Michel Fauth, Switzerland

Patrick_K_O_Brien · May 31, 2003, 4:03pm

"Jean-Michel Fauth" <jmfauth@bluewin.ch> writes:

Hi all,

I am already in front of my screen, while america is still
sleeping, but anyway.

1) The renaming process in the __init__.py is not complete.
It renames wx*** names but it forgets to rename WX*** names.
Bug or feature?

You tell me. Can you give an example and suggest whether you
think the WX form should be renamed or not?

2) It has been said
from wxPython.wx import * pollutes the name space
This is true, but a good pyhoneer (pythonist?) had
introduced an __all__ = [...] statement in the wx.py.
(Not completely sure that this had resolved all the
problems).

In my opinion you're still playing with fire if you import *.

4) Already said, wxSTC_CONSTANTS are now,
STC_CONSTANTS, which leads to some
stc.STC_CONSTANTS in the code. !?

Propose a solution, get feedback from the community, etc. Since the
stc package is a separate module, Robin might be more willing to
rename the objects in that namespace. I don't remember having any
issues when I converted all the PyCrust stuff, which makes heavy use
of stc.

6) I would really appreciate comments about my previous
post 'When the new wx package reveals some wxPython
weakness'.

My comment would be that you are in as good a position to make
specific recommendations as anyone else. The wx renaming modules are
very simple, and pretty well documented. They can be changed if you
can suggest an improvement that has the support of the wxPython
community and doesn't get vetoed by Robin. (And don't be offended if
a suggestion does get vetoed - I can't count the number of times Robin
has vetoed my ideas. <wink>)

I hope that helps. Sorry I can't do better than that, but I've got
very little free time these days.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Chuck_Esterbrook1 · May 31, 2003, 8:13pm

Wouldn't there still be hundreds and hundreds of names? My source files
each tend to use around a dozen names from wx so the extra ones
creation the pollution. I strongly prefer:

from wxPython import wx
wx.Frame

···

On Saturday 31 May 2003 02:29 am, Jean-Michel Fauth wrote:

2) It has been said
from wxPython.wx import * pollutes the name space
This is true, but a good pyhoneer (pythonist?) had
introduced an __all__ = [...] statement in the wx.py.
(Not completely sure that this had resolved all the
problems).

--
Chuck
http://ChuckEsterbrook.com

Magnus_Lie_Hetland · May 31, 2003, 9:05pm

Chuck Esterbrook <ChuckEsterbrook@yahoo.com>:

[snip]

from wxPython import wx
wx.Frame

Is wxPythoh.wx going to change? Or is the new wx package going to
remain separate (as now), i.e.

import wx
wx.Frame

?

···

--
Magnus Lie Hetland "In this house we obey the laws of
http://hetland.org thermodynamics!" Homer Simpson

Patrick_K_O_Brien · May 31, 2003, 9:16pm

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:

> 2) It has been said
> from wxPython.wx import * pollutes the name space
> This is true, but a good pyhoneer (pythonist?) had
> introduced an __all__ = [...] statement in the wx.py.
> (Not completely sure that this had resolved all the
> problems).

Wouldn't there still be hundreds and hundreds of names? My source files
each tend to use around a dozen names from wx so the extra ones
creation the pollution. I strongly prefer:

And I wouldn't want to be the one that had to maintain the __all__
attribute for any module the size of wxPython, unless that attribute
was automatically generated by SWIG. Even then, I like to be able to
look at my code and see what module objects came from.

from wxPython import wx
wx.Frame

Just a small nit. The "official" (ie, non-Esterbrook-forked-wx
<wink>) forms are either:

from wxPython import wx
wx.wxFrame

Or:

import wx
wx.Frame

In other words, the new wx namespace stands on its own and isn't part
of the wxPython package.

···

On Saturday 31 May 2003 02:29 am, Jean-Michel Fauth wrote:

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Patrick_K_O_Brien · June 1, 2003, 12:29am

Magnus Lie Hetland <magnus@hetland.org> writes:

Chuck Esterbrook <ChuckEsterbrook@yahoo.com>:
>
[snip]
>
> from wxPython import wx
> wx.Frame

Is wxPythoh.wx going to change? Or is the new wx package going to
remain separate (as now), i.e.

import wx
wx.Frame

The wxPython.wx module can't change, due to the need to support
existing apps. The new wx package will remain separate, as it is now.
I think this was just a simple typo on Chuck's part.

···

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Chuck_Esterbrook1 · June 1, 2003, 12:42am

wxPython.wx *can* change and does for me: At run time I simply run
through the dir() of that module adding "Foo" for any "wxFoo". I even
tried out the demo with this enhancement and everything works.

I didn't know until now how future wxPython versions were going to
handle this, so I just typed out what I have been using.

···

On Saturday 31 May 2003 05:29 pm, Patrick K. O'Brien wrote:

Magnus Lie Hetland <magnus@hetland.org> writes:
> Chuck Esterbrook <ChuckEsterbrook@yahoo.com>:
>
> [snip]
>
> > from wxPython import wx
> > wx.Frame
>
> Is wxPythoh.wx going to change? Or is the new wx package going to
> remain separate (as now), i.e.
>
> import wx
> wx.Frame

The wxPython.wx module can't change, due to the need to support
existing apps. The new wx package will remain separate, as it is
now. I think this was just a simple typo on Chuck's part.

--
Chuck
http://ChuckEsterbrook.com

Robin · June 1, 2003, 3:19am

Jean-Michel Fauth wrote:

Hi all,

I am already in front of my screen, while america is still
sleeping, but anyway.

1) The renaming process in the __init__.py is not complete.
It renames wx*** names but it forgets to rename WX*** names.
Bug or feature?

I don't know, we'll see.

2) It has been said
from wxPython.wx import * pollutes the name space
This is true, but a good pyhoneer (pythonist?) had
introduced an __all__ = [...] statement in the wx.py.
(Not completely sure that this had resolved all the
problems).

Yes, but you'd still have to put almost every name that is currently in the module into __all__

5) Not to do with the wx pkg. The assert statements in the
wxmsw240h.dll produce sometimes unclear error messages.
I mean error, that are no more intercepted by the python
interpreter. A single line, something like:
Assert error: e:\projects\robins\python\stuff Unregister
class....
Sorry for this stupid example, but I don't succeed to
reproduce the error!

The messages are generated in C++ in wxASSERT statements and such. I catch them further downstream before they are turnined into a message dialog and turn them into Python exceptions which are raised the next time control returns to Python. The wxASSERTs are really meant for C++ programmers but usually they are helpful for Python programmers too. I leave the file and line numbers in so that it can be helpful to me when the Ptyhon programmers can't figure out what is wrong.

···

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

Patrick_K_O_Brien · June 1, 2003, 3:23pm

Chuck Esterbrook <ChuckEsterbrook@yahoo.com> writes:

> Magnus Lie Hetland <magnus@hetland.org> writes:
> > Chuck Esterbrook <ChuckEsterbrook@yahoo.com>:
> >
> > [snip]
> >
> > > from wxPython import wx
> > > wx.Frame
> >
> > Is wxPythoh.wx going to change? Or is the new wx package going to
> > remain separate (as now), i.e.
> >
> > import wx
> > wx.Frame
>
> The wxPython.wx module can't change, due to the need to support
> existing apps. The new wx package will remain separate, as it is
> now. I think this was just a simple typo on Chuck's part.

wxPython.wx *can* change and does for me: At run time I simply run
through the dir() of that module adding "Foo" for any "wxFoo". I even
tried out the demo with this enhancement and everything works.

While technically correct, you are just muddying the waters. Any
Python namespace can be mangled.

I didn't know until now how future wxPython versions were going to
handle this, so I just typed out what I have been using.

Sure you did. I posted these weeks ago:

http://www.orbtech.com/www/wxPythonDocs.html

http://www.orbtech.com/www/wxPackage.html

http://www.orbtech.com/www/wxPythonExamples.html

···

On Saturday 31 May 2003 05:29 pm, Patrick K. O'Brien wrote:

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------

Chuck_Esterbrook1 · June 1, 2003, 8:45pm

To over emphasize the clarity point, would this mailing list become
Python-users@lists.windows.org, or possibly just users@lists.org?

If mailing lists had namespaces, then it would be something like
python.wx.users@lists.org.

Python *does* have namespaces which makes the prefixes redundant. And if
you want to know where a class comes from, you can just ask for its
module:
someClass.__module__
which you can then ask for its __path__

I already use wxPython without the prefixes and it works fine. Keep in
mind the prefix is still highly visible in the source:

old style: wxFrame
new style: wx.Frame

> Sorry to be a differ-begger, but I would be in favor of keeping the
> wx prefixes.

Then don't use the new wx package. It's your choice.

It's not much of a choice. I assume that the old style of wxFoo will be
first deprecated and then eventually eliminated. And using deprecated
features for new code is high undesireable for all the obvious reasons.

In any case, we should definitely axe the prefix and start using Python
like it's Python and not C++.

···

On Sunday 01 June 2003 07:05 am, Dan Cherry wrote:
On Sunday 01 June 2003 08:16 am, Patrick K. O'Brien wrote:

On Sunday 01 June 2003 07:05 am, Dan Cherry wrote:

On Sunday 01 June 2003 08:23 am, Patrick K. O'Brien wrote:

> > The wxPython.wx module can't change, due to the need to support
> > existing apps. The new wx package will remain separate, as it is
> > now. I think this was just a simple typo on Chuck's part.
>
> wxPython.wx *can* change and does for me: At run time I simply run
> through the dir() of that module adding "Foo" for any "wxFoo". I
> even tried out the demo with this enhancement and everything works.

While technically correct, you are just muddying the waters. Any
Python namespace can be mangled.

I wasn't muddying the waters. You said "The wxPython.wx module can't
change, due to the need to support existing apps." and I was addressing
that statement. It's false.

The changed version I'm using *does* support existing apps as well as
"new ones".

It's all crystal clear-ly yours,
--
Chuck
http://ChuckEsterbrook.com

Dan_Cherry · June 1, 2003, 10:22pm

Thanks Chuck/Patrick, -- and all points are well taken.

To avoid spending any longer beating on dead horse issues, forget my
opinion (as I gain understanding of what's being changed, I agree,
module namespace will likely be a better Pythonesque approach still
giving ample clarity), but I'd still like to understand what's being
planned overall, since I'm making a commitment to learning a GUI
development system that I'm now finding will be offered in a new format.

I tried searching the archives for material about the changes, but could
only find tidbits scattered thorough a number of emails (this would be
on the ActiveState website). I checked wxpython.org, and didn't see
anything jump out about a new format or any major changes in the works.

Is there a white paper, proposal, or general description of what's being
done to the libraries, or is it necessary to follow all the threads of
email on this user/list to put it all together? (if the latter, just
tell me to wait for the final release - I'm not THAT curious)

Is there a best source or two, where I (and other newcomers) can bring
ourselves up to speed? If so, could you share that with us? (I've only
been on this mailing list for a week, and obviously am still too sober
to know where everybody keeps things).

I can also appreciate how frustrating it must be to keep bringing
everyone like me up to date on things over and over. So a sincere
'thanks' for your patience (that goes for all of you who seem to be the
key players in providing wxPython).

Dan Cherry

···

-----Original Message-----
From: Chuck Esterbrook [mailto:ChuckEsterbrook@yahoo.com]
Sent: Sunday, June 01, 2003 4:46 PM
To: wxPython-users@lists.wxwindows.org
Subject: Re: [wxPython-users] Bug in __init__.py of the wx pkg + other
remarks

On Sunday 01 June 2003 07:05 am, Dan Cherry wrote:

To over emphasize the clarity point, would this mailing list become
Python-users@lists.windows.org, or possibly just users@lists.org?

If mailing lists had namespaces, then it would be something like
python.wx.users@lists.org.

Python *does* have namespaces which makes the prefixes redundant. And if

you want to know where a class comes from, you can just ask for its
module:
someClass.__module__
which you can then ask for its __path__

I already use wxPython without the prefixes and it works fine. Keep in
mind the prefix is still highly visible in the source:

old style: wxFrame
new style: wx.Frame

On Sunday 01 June 2003 08:16 am, Patrick K. O'Brien wrote:

On Sunday 01 June 2003 07:05 am, Dan Cherry wrote:
> Sorry to be a differ-begger, but I would be in favor of keeping the
> wx prefixes.

Then don't use the new wx package. It's your choice.

It's not much of a choice. I assume that the old style of wxFoo will be
first deprecated and then eventually eliminated. And using deprecated
features for new code is high undesireable for all the obvious reasons.

In any case, we should definitely axe the prefix and start using Python
like it's Python and not C++.

On Sunday 01 June 2003 08:23 am, Patrick K. O'Brien wrote:

> > The wxPython.wx module can't change, due to the need to support
> > existing apps. The new wx package will remain separate, as it is
> > now. I think this was just a simple typo on Chuck's part.
>
> wxPython.wx *can* change and does for me: At run time I simply run
> through the dir() of that module adding "Foo" for any "wxFoo". I
> even tried out the demo with this enhancement and everything works.

While technically correct, you are just muddying the waters. Any
Python namespace can be mangled.

I wasn't muddying the waters. You said "The wxPython.wx module can't
change, due to the need to support existing apps." and I was addressing
that statement. It's false.

The changed version I'm using *does* support existing apps as well as
"new ones".

It's all crystal clear-ly yours,
--
Chuck
http://ChuckEsterbrook.com

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

Bug in __init__.py of the wx pkg + other remarks

Bug in init.py of the wx pkg + other remarks