FW: going from UpperUpper to lowerUpper method names

Below are a message I sent to Robin last fall along with his reply and my
response. I think it is worth bringing up on the main list since other
people are likely to have opinions. I'm getting ready to bring up these
points for PythonCard, so raising the issue for wxPython first makes sense.

If we are going to stay with the wx prefix for all wx classes and constants
and keep the UpperUpper naming conventions from C++ then it would be good to
say why and be done with it so if the issue comes up in the future we can
point to this discussion.

The big reasons for sticking with the current style are backwards
compatibility and ease of mixing wxWindows code across a variety of
languages: C++, Python, Perl, Ruby, whatever. I've always hated the naming,
but the benefits of wxPython of course overrode the downsides to the naming.

If the goal was to make wxPython fit normal Python naming conventions then a
switch with wxPython 2.5 or something like that would be a one-time change.
Versions 2.4 and earlier would keep the old style.

It wouldn't be that difficult to automate search and replace of old-style to
new-style names for older code. To avoid name clashes it would be
recommended that people not do

from wxPython.wx import *

but instead use the safer

from wxPython import wx

form for imports. References would then be wx.Frame, wx.Button, etc.

The C++ documentation should not be that relevant to the discussion as
wxPython specific documentation is supposed to be a high priority for this
year and that documentation will be auto-generated. Consider yourself
officially nagged Robin :wink:

ka

···

-----Original Message-----
From: Kevin Altis
To: Robin Dunn
Subject: RE: going from UpperUpper to lowerUpper method names

Well I for one would vote for a move to a more pythonic set of naming
conventions. Obviously there would be a price in backwards compatibility,
but overall I think it would be worth it. I don't think it should change the
basic requirements for Python specific docs, which are going to be
auto-generated for the most part anyway if they are going to be kept
up-to-date..

It would be worth discussing on the list.

ka

-----Original Message-----
From: Robin Dunn
To: Kevin Altis
Subject: Re: going from UpperUpper to lowerUpper method names

I've thought about this in the past, and also removing the wx
from the front
of all names (so you would use wx.Frame instead of wx.wxFrame or wxFrame)
but in the begining of the project it meant a lot of work because I would
have to use SWIG's %name directive everywhere. But now that I have forked
my own version of SWIG things like that and others become possible...

----- Original Message -----
From: "Kevin Altis"
To: "Robin Dunn" <robin@alldunn.com>
Subject: going from UpperUpper to lowerUpper method names

> One of the criticisms of using wxPython is that the method names are C++
> style UpperUpper naming convention, rather than Python style
lowerUpper. I
> was wondering whether it would be possible with SWIG to force
method names
> to lowerUpper? It seems that even that wouldn't fix the problem
since any
> internal calls the methods make to other methods would still be of the
> UpperUpper form, so you need a true replacement of the method
pointer for
> each class.
>
> Anyway, the reason this is relevant is that I need to bring up the
> lowerUpper versus UpperUpper issue for PythonCard. What I
thought might be
> possible if we wanted lowerUpper is that eventually we might
build our own
> wxPython, since I know you wouldn't want to change the main wxPython
> distribution.
>
> Anyway, the various issues are conspiring towards just using UpperUpper
even
> though the rest of the Python code will be lowerUpper
convention and just
> saying screw it.
>
> ka
>
>
>

Although I'd be moderately happy to see wxPython using standard Python naming conventions, I have to admit to being somewhat skeptical that converting old code will be as trouble-free as suggested. (Converting all the older documentation and samples around the net (esp. the Wiki) should also be considered.)

I know there will be _a lot_ of places in my code where it will break (or at least need more documentation) with the new style (I often use lowerUpper vs. UpperUpper to distinguish between GUI/wx-level code and application/internal code). There are also a number of places where I use a module named "wx" to hold a wx-specific implementation of a particular interface (e.g. basictypes.wx, basicproperty.ext.wx) for use in wxPython modules.

That's not a show-stopper (all of the problems can be fixed with effort). I'm a big boy, I can change my code if I'm the only one affected.

Regarding particulars:

    * UpperUpper to lowerUpper -- I see the most benefit with this
      change, as it's a definite "wart" in wxPython from a Python
      programmer's perspective. It does mean that it becomes harder to
      translate between languages, which I see as a significant
      disadvantage (particularly wrt. C++, where it's very useful to
      have the same names on both sides of the divide (I found it very
      useful when converting wxControlContainer, for instance)). All in
      all, I'm -0 on this.
    * Deprecating use of from wxPython.wx import * and renaming
      everything from wxYyy to wx.Yyy -- I don't see this as worth the
      effort, but then I don't really care about the
      module-namespace-pollution issue. It would have been a good
      design decision way back when, but it seems like a quest for
      unnecessary purity at this point. On the other hand, again, it's
      a trivial couple of week's of effort to convert all of the
      applications, re-test them and re-release them, so I guess I'm -0
      on it as well as long as we're not going to some day reverse the
      decision again.
          o Question: when I see the name of a wxFrame object (in
            __repr__), will it now just be "Frame" (it's currently
            "wxFrame")? It would be nice if the __name__ was "wx.Frame"
            to let the user know it's a wxPython object.

Note:

    I'd strongly suggest that a complete API rewrite (which is what's
    proposed) is a major-version change, not an x.y revision change.
     After all, _nothing_ written for 2.x will work with the new
    version, and nothing written with the new version will work with
    2.x. Conversion work will require rewriting/re-testing the entire
    code-base (=weeks to months of work), and people will likely get a
    little annoyed if that's rolled out as a . release.

Enjoy,
Mike

Kevin Altis wrote:

···

Below are a message I sent to Robin last fall along with his reply and my
response. I think it is worth bringing up on the main list since other
people are likely to have opinions. I'm getting ready to bring up these
points for PythonCard, so raising the issue for wxPython first makes sense.

If we are going to stay with the wx prefix for all wx classes and constants
and keep the UpperUpper naming conventions from C++ then it would be good to
say why and be done with it so if the issue comes up in the future we can
point to this discussion.

The big reasons for sticking with the current style are backwards
compatibility and ease of mixing wxWindows code across a variety of
languages: C++, Python, Perl, Ruby, whatever. I've always hated the naming,
but the benefits of wxPython of course overrode the downsides to the naming.

If the goal was to make wxPython fit normal Python naming conventions then a
switch with wxPython 2.5 or something like that would be a one-time change.
Versions 2.4 and earlier would keep the old style.

It wouldn't be that difficult to automate search and replace of old-style to
new-style names for older code. To avoid name clashes it would be
recommended that people not do

from wxPython.wx import *

but instead use the safer

from wxPython import wx

form for imports. References would then be wx.Frame, wx.Button, etc.

The C++ documentation should not be that relevant to the discussion as
wxPython specific documentation is supposed to be a high priority for this
year and that documentation will be auto-generated. Consider yourself
officially nagged Robin :wink:

ka

-----Original Message-----
From: Kevin Altis
To: Robin Dunn
Subject: RE: going from UpperUpper to lowerUpper method names

Well I for one would vote for a move to a more pythonic set of naming
conventions. Obviously there would be a price in backwards compatibility,
but overall I think it would be worth it. I don't think it should change the
basic requirements for Python specific docs, which are going to be
auto-generated for the most part anyway if they are going to be kept
up-to-date..

It would be worth discussing on the list.

ka

-----Original Message-----
From: Robin Dunn
To: Kevin Altis
Subject: Re: going from UpperUpper to lowerUpper method names

I've thought about this in the past, and also removing the wx
from the front
of all names (so you would use wx.Frame instead of wx.wxFrame or wxFrame)
but in the begining of the project it meant a lot of work because I would
have to use SWIG's %name directive everywhere. But now that I have forked
my own version of SWIG things like that and others become possible...

----- Original Message -----
From: "Kevin Altis"
To: "Robin Dunn" <robin@alldunn.com>
Subject: going from UpperUpper to lowerUpper method names

One of the criticisms of using wxPython is that the method names are C++
style UpperUpper naming convention, rather than Python style
     

lowerUpper. I
   

was wondering whether it would be possible with SWIG to force
     

method names
   

to lowerUpper? It seems that even that wouldn't fix the problem
     

since any
   

internal calls the methods make to other methods would still be of the
UpperUpper form, so you need a true replacement of the method
     

pointer for
   

each class.

Anyway, the reason this is relevant is that I need to bring up the
lowerUpper versus UpperUpper issue for PythonCard. What I
     

thought might be
   

possible if we wanted lowerUpper is that eventually we might
     

build our own
   

wxPython, since I know you wouldn't want to change the main wxPython
distribution.

Anyway, the various issues are conspiring towards just using UpperUpper
     

even
   

though the rest of the Python code will be lowerUpper
     

convention and just
   

saying screw it.

ka

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

--
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/

It's interesting that you bring this up today because just yesterday I started thinking seriously about moving back to the standard SWIG and jumping to version 1.3.18. It would still require a few enhancements to SWIG to do everything that I am doing with it now, but I imagine that I can get them rolled in to the main SWIG distribution...

Nothing's set in stone yet though.

--Robin

Kevin Altis wrote:

···

Below are a message I sent to Robin last fall along with his reply and my
response. I think it is worth bringing up on the main list since other
people are likely to have opinions. I'm getting ready to bring up these
points for PythonCard, so raising the issue for wxPython first makes sense.

If we are going to stay with the wx prefix for all wx classes and constants
and keep the UpperUpper naming conventions from C++ then it would be good to
say why and be done with it so if the issue comes up in the future we can
point to this discussion.

The big reasons for sticking with the current style are backwards
compatibility and ease of mixing wxWindows code across a variety of
languages: C++, Python, Perl, Ruby, whatever. I've always hated the naming,
but the benefits of wxPython of course overrode the downsides to the naming.

If the goal was to make wxPython fit normal Python naming conventions then a
switch with wxPython 2.5 or something like that would be a one-time change.
Versions 2.4 and earlier would keep the old style.

It wouldn't be that difficult to automate search and replace of old-style to
new-style names for older code. To avoid name clashes it would be
recommended that people not do

from wxPython.wx import *

but instead use the safer

from wxPython import wx

form for imports. References would then be wx.Frame, wx.Button, etc.

The C++ documentation should not be that relevant to the discussion as
wxPython specific documentation is supposed to be a high priority for this
year and that documentation will be auto-generated. Consider yourself
officially nagged Robin :wink:

ka

-----Original Message-----
From: Kevin Altis
To: Robin Dunn
Subject: RE: going from UpperUpper to lowerUpper method names

Well I for one would vote for a move to a more pythonic set of naming
conventions. Obviously there would be a price in backwards compatibility,
but overall I think it would be worth it. I don't think it should change the
basic requirements for Python specific docs, which are going to be
auto-generated for the most part anyway if they are going to be kept
up-to-date..

It would be worth discussing on the list.

ka

-----Original Message-----
From: Robin Dunn
To: Kevin Altis
Subject: Re: going from UpperUpper to lowerUpper method names

I've thought about this in the past, and also removing the wx
from the front
of all names (so you would use wx.Frame instead of wx.wxFrame or wxFrame)
but in the begining of the project it meant a lot of work because I would
have to use SWIG's %name directive everywhere. But now that I have forked
my own version of SWIG things like that and others become possible...

----- Original Message -----
From: "Kevin Altis"
To: "Robin Dunn" <robin@alldunn.com>
Subject: going from UpperUpper to lowerUpper method names

One of the criticisms of using wxPython is that the method names are C++
style UpperUpper naming convention, rather than Python style

lowerUpper. I

was wondering whether it would be possible with SWIG to force

method names

to lowerUpper? It seems that even that wouldn't fix the problem

since any

internal calls the methods make to other methods would still be of the
UpperUpper form, so you need a true replacement of the method

pointer for

each class.

Anyway, the reason this is relevant is that I need to bring up the
lowerUpper versus UpperUpper issue for PythonCard. What I

thought might be

possible if we wanted lowerUpper is that eventually we might

build our own

wxPython, since I know you wouldn't want to change the main wxPython
distribution.

Anyway, the various issues are conspiring towards just using UpperUpper

even

though the rest of the Python code will be lowerUpper

convention and just

saying screw it.

ka

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

Kevin Altis wrote:

Below are a message I sent to Robin last fall along with his reply and my
response. I think it is worth bringing up on the main list since other
people are likely to have opinions. I'm getting ready to bring up these
points for PythonCard, so raising the issue for wxPython first makes sense.

If we are going to stay with the wx prefix for all wx classes and constants
and keep the UpperUpper naming conventions from C++ then it would be good to
say why and be done with it so if the issue comes up in the future we can
point to this discussion.

The big reasons for sticking with the current style are backwards
compatibility and ease of mixing wxWindows code across a variety of
languages: C++, Python, Perl, Ruby, whatever. I've always hated the naming,
but the benefits of wxPython of course overrode the downsides to the naming.

If the goal was to make wxPython fit normal Python naming conventions then a
switch with wxPython 2.5 or something like that would be a one-time change.
Versions 2.4 and earlier would keep the old style.

It wouldn't be that difficult to automate search and replace of old-style to
new-style names for older code.

So, am I supposed to require all the users of my Python project to update to wxPython 2.5, or am I supposed to maintain two branches of the project, one with the old names and one with the new ones?

Naming conventions may be a nice thing to have, but in the end, they really aren't that important, and certainly aren't sufficient reason to force everyone using a library to modify all their own code. If you want to waste your own time modifying the naming conventions in your own code, fine, but don't waste everyone else's.

David

Thanks for that one. I fully aggree.

  UC

···

On Saturday 01 March 2003 09:15 pm, David C. Fox wrote:

Kevin Altis wrote:
> Below are a message I sent to Robin last fall along with his reply and my
> response. I think it is worth bringing up on the main list since other
> people are likely to have opinions. I'm getting ready to bring up these
> points for PythonCard, so raising the issue for wxPython first makes
> sense.
>
> If we are going to stay with the wx prefix for all wx classes and
> constants and keep the UpperUpper naming conventions from C++ then it
> would be good to say why and be done with it so if the issue comes up in
> the future we can point to this discussion.
>
> The big reasons for sticking with the current style are backwards
> compatibility and ease of mixing wxWindows code across a variety of
> languages: C++, Python, Perl, Ruby, whatever. I've always hated the
> naming, but the benefits of wxPython of course overrode the downsides to
> the naming.
>
> If the goal was to make wxPython fit normal Python naming conventions
> then a switch with wxPython 2.5 or something like that would be a
> one-time change. Versions 2.4 and earlier would keep the old style.
>
> It wouldn't be that difficult to automate search and replace of old-style
> to new-style names for older code.

So, am I supposed to require all the users of my Python project to
update to wxPython 2.5, or am I supposed to maintain two branches of the
project, one with the old names and one with the new ones?

Naming conventions may be a nice thing to have, but in the end, they
really aren't that important, and certainly aren't sufficient reason to
force everyone using a library to modify all their own code. If you
want to waste your own time modifying the naming conventions in your own
code, fine, but don't waste everyone else's.

--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417

From: David C. Fox

So, am I supposed to require all the users of my Python project to
update to wxPython 2.5, or am I supposed to maintain two branches of the
project, one with the old names and one with the new ones?

Naming conventions may be a nice thing to have, but in the end, they
really aren't that important, and certainly aren't sufficient reason to
force everyone using a library to modify all their own code. If you
want to waste your own time modifying the naming conventions in your own
code, fine, but don't waste everyone else's.

Actually, I think they are very important for readability and consistency.
However, in this particular case it is likely that backwards compatability
and continued ease of using the same naming conventions in C++... outweigh
the benefits of more pythonic naming.

The point of the email was to bring up the issue and then put it to rest
unless there was a strong desire to change the class names to drop the wx
prefix and the method names to lowerUpper from UpperUpper. I don't expect
most people will want the pythonic naming, because of the difficulty of
switching.

I certainly wasn't implying that wxPython should change simply because
PythonCard might switch, it is just that this is an old discussion Robin and
I have had in private and I thought it should be public.

ka

names

> From: David C. Fox
>
> So, am I supposed to require all the users of my Python project to
> update to wxPython 2.5, or am I supposed to maintain two branches of the
> project, one with the old names and one with the new ones?
>
> Naming conventions may be a nice thing to have, but in the end, they
> really aren't that important, and certainly aren't sufficient reason to
> force everyone using a library to modify all their own code. If you
> want to waste your own time modifying the naming conventions in your own
> code, fine, but don't waste everyone else's.

Actually, I think they are very important for readability and consistency.
However, in this particular case it is likely that backwards compatability
and continued ease of using the same naming conventions in C++... outweigh
the benefits of more pythonic naming.

The point of the email was to bring up the issue and then put it to rest
unless there was a strong desire to change the class names to drop the wx
prefix and the method names to lowerUpper from UpperUpper. I don't expect
most people will want the pythonic naming, because of the difficulty of
switching.

I am also against switching the current conventions. In a practical sense,
the readability and consistency of the code are important factors, but ones
that matter only to developers and not to end users. Any program, no matter
how it's built, must first strive to provide the best experience possible
for end users. Above and beyond the difficulty of switching, I am concerned
about old code that people will try to run on a new wxPython, or vice versa.
It will just break, and they won't have a clue as to why, unless they
actively try to seek out what the problem was.

Most people, I think, will simply conclude that scripts written in wxPython
don't run even with wxPython installed, so wxPython must be unstable. They
will then try to avoid it and tell their friends to do the same. Using
wxPython, without a doubt, will become more complex and I really doubt that
will help the adoption of wxPython by developers or tech savvy users alike.
It won't necessarily "just work" anymore.

I certainly wasn't implying that wxPython should change simply because
PythonCard might switch, it is just that this is an old discussion Robin

and

I have had in private and I thought it should be public.

No, but you did suggest it as a potential solution to the inconsistency with
Python's naming conventions, and implied that you would support the change.
You also pointed out that such a change would not be too difficult to
automate. (Which I'm not sure would be true, anyways, when you consider all
the different coding styles out there, and the fact that not everyone
adheres to Python's naming conventions.) As a result of all this, you've
started a discussion about whether or not to implement such a change, and I
think have gotten people nervous that such a change may in fact happen.
(Unless you are talking about creating your own, PythonCard-specific,
wxPython?)

I realize you were probably just 'throwing the idea out there', because it
came up in the discussion, but I bet it has a bunch of people thinking very
hard about what they would do if such a change were to occur - how would
they inform their users, what support would they offer for 2.4 vs. 2.5,
whether or not this change will affect how people perceive their program,
etc. The technical issues of automatically converting scripts to the new
syntax are merely the tip of the iceberg, IMHO. It's the amount of time
spent helping people migrate to the new version and the potential lost users
due to unexpected failures that would really be the problem.

Kevin

···

----- Original Message -----
From: "Kevin Altis" <altis@semi-retired.com>
To: <wxPython-users@lists.wxwindows.org>
Sent: Saturday, March 01, 2003 9:29 PM
Subject: RE: [wxPython-users] FW: going from UpperUpper to lowerUpper method

[... on renaming wxPython.wx.wxFoo to wxPython.wx.Foo:]

         o Question: when I see the name of a wxFrame object (in
           __repr__), will it now just be "Frame" (it's currently
           "wxFrame")? It would be nice if the __name__ was "wx.Frame"
           to let the user know it's a wxPython object.

Wouldn't it be better to check the __module__ attribute for "wxPython"?

Note:

   I'd strongly suggest that a complete API rewrite (which is what's
   proposed) is a major-version change, not an x.y revision change.
    After all, _nothing_ written for 2.x will work with the new
   version, and nothing written with the new version will work with
   2.x.

Good point.

···

On Sat, Mar 01, 2003 at 03:30:06PM -0500, Mike C. Fletcher wrote:

--
ALL YOUR BASE ARE BELONG TO US.

> > So, am I supposed to require all the users of my Python project to
> > update to wxPython 2.5, or am I supposed to maintain two branches of the
> > project, one with the old names and one with the new ones?

I suggest that you agree with your customers about what versions of
Python and wxPython to use with the various versions of your code.

I seems reasonable to have both names available during a fairly long
grace period, but to mark the old names as deprecated in the docs.
Something like: (from wx.py)

class wxPyAppPtr(wxEvtHandlerPtr):
     def __init__(self,this):
         self.this = this
         self.thisown = 0
     def __del__(self,wxc=wxc):
         if self.thisown == 1 :
             wxc.delete_wxPyApp(self)
     def getAppName(self, *_args, **_kwargs):
         val = apply(wxc.wxPyApp_GetAppName,(self,) + _args, _kwargs)
         return val
     GetAppName = getAppName
     def getAuto3D(self, *_args, **_kwargs):
         val = apply(wxc.wxPyApp_GetAuto3D,(self,) + _args, _kwargs)
         return val
     GetAuto3D = getAuto3D

...

class PyApp(wxPyAppPtr):
     def __init__(self,*_args,**_kwargs):
         self.this = apply(wxc.new_wxPyApp,_args,_kwargs)
         self.thisown = 1
wxPyApp = PyApp

> > Naming conventions may be a nice thing to have, but in the end, they
> > really aren't that important, and certainly aren't sufficient reason to
> > force everyone using a library to modify all their own code.

Changes are always difficult, but if you are to change something, sooner is
probably better than later, and I think that wxPython is going to be bigger
in the future than it is today. There is still not a single wxPython book
out there, and I imagine Chandler might attract some new people in the
future. It might be about time to remove warts.

If you
> > want to waste your own time modifying the naming conventions in your own
> > code, fine, but don't waste everyone else's.

This reminds me of something Dennis Richie said in 1982:

   "In retrospect it would have been better to go ahead and change the
    precedence of & to higher than ==, but it seemed safer just to split
    & and && without moving & past an existing operator. (After all,
    we had several hundred kilobytes of source code, and maybe 3
    installations....)"

I don't know how many bugs they have caused by the nutty preceedence
rules in C, but it's pretty clear that the cost of letting this stay bad
outweights the cost of correcting (then) availalable code by mangitudes.

A convention where you are forced between "from wxPython.wx import *" or
"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal. The
"from X import *" style means that the object inspectors availible in IDEs
become completely useless, and "wx.wxFrame" sure is ugly. As powerful IDEs
become more common, people will be more and more reluctant to use "from
X import *".

I think we all agree that wx.Frame is the way it should have looked like
from the beginning--in an ideal world.

> Actually, I think they are very important for readability and consistency.
> However, in this particular case it is likely that backwards compatability
> and continued ease of using the same naming conventions in C++... outweigh
> the benefits of more pythonic naming.

This is obviosuly something one might consider. I think the issue of conformity
between wxWindows and wxPython is more important than the fixable issue of
backward compatibility though. It seems to me that it should be possible to
automate conversion of documentation from C++ to Python style though. That
makes the problem smaller.

> The point of the email was to bring up the issue and then put it to rest
> unless there was a strong desire to change the class names to drop the wx
> prefix and the method names to lowerUpper from UpperUpper. I don't expect
> most people will want the pythonic naming, because of the difficulty of
> switching.

Given a reasonable grace period where both versions work, I don't see a
big issue here. Particularly with wxPython's current track record of
API stability.

From a longer time perspective, I certainly see both less namespace
pollution and conventional method names as a clear advantage. If I
had the option to switch to another GUI toolkit that offered the same
features as wxPython, but had fixed these warts, I'd switch for the
next project. Whether I'd port any current project is difficult to
say since there *is* no other GUI toolkit for python that offers the
same features... :slight_smile:

Most people, I think, will simply conclude that scripts written in wxPython
don't run even with wxPython installed, so wxPython must be unstable. They
will then try to avoid it and tell their friends to do the same. Using
wxPython, without a doubt, will become more complex and I really doubt that
will help the adoption of wxPython by developers or tech savvy users alike.
It won't necessarily "just work" anymore.

*After* the transition period is over, I think this change will
make it *easier* for python programmers to adopt wxPython. That's
the entire point with the change!

With all respect to Robin and the other developers, staying with the
current warts won't prevent problems. Just changing from 2.3.2 to 2.3.3
broke my code in several pieces. At least menus and grids changed their
behaviour in ways that weren't backward compatible.

In menus "aMenu.Append(SOME_ID, _("bla bla"), "", checkable=1)"
stopped working and had to be replaced with .AppendCheckItem. I
don't remember the exact changes in wxGrid, but it broke my code...

So, unfortunately, it's my experience that you can't expect a program
developed with one version of wxPython to work with a later version
of wxPython.

I realize that wxPython 2.3 was based on a development version of
wxWindows, and that this is supposed to get better with 2.4, but I
haven't dared upgrading yet. As far as I understood, there have been
some issues with the first versions of 2.4... At least with a change
like this, I'd know exactly what to change and why.

As a result of all this, you've
started a discussion about whether or not to implement such a change, and I
think have gotten people nervous that such a change may in fact happen.

Are you going to send him your psychiatrist bills? :wink:

I think this is a very reasonable discussion. I'm sure I'm not the only
programmer here who have been troubled by legacy code that is really bad
because programmers in the past tried to avoid changing more than they
had to. As Tim Peters wrote:

'''The "ain't broke, don't fix" philosophy is a good guide here, provided
you've got a very low threshold for insisting "it's broke".'''

Don't you think we will be better off in, let's say, a three year
perspective if we get rid of these warts?

I realize you were probably just 'throwing the idea out there', because it
came up in the discussion, but I bet it has a bunch of people thinking very
hard about what they would do if such a change were to occur - how would
they inform their users, what support would they offer for 2.4 vs. 2.5,
whether or not this change will affect how people perceive their program,
etc. The technical issues of automatically converting scripts to the new
syntax are merely the tip of the iceberg, IMHO. It's the amount of time
spent helping people migrate to the new version and the potential lost users
due to unexpected failures that would really be the problem.

Are you saying that you have customers that handle their own Python and
wxPython versions, and you just ship .py files without knowing what
version of Python and wxPython they have, and without instructing them
about what versions they should use? Wow!

Regardless of the changes discussed here, I would honestly advice against
such practice. That sounds dangerous to me. Several python versions out
there have rather nasty busgs. As I have said, wxPython has changed behaviour
in different ways, and I think you will get run into trouble sooner or later.

I realize that it might be difficult to convince users to upgrade sometimes,
especially if they have several Python based systems on their site, but I
think knowing what versions they have, and testing thoroughly with those
versions is required practice to assure product quality.

···

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

But that doesn't mean that it's a very big issue! Maybe my
wording was a bit strong.

It does disturb me. There are times I try to look in the namespace,
and then I get a bit tired that it's full of things that don't belong
there, but I can surely live with it the way it is, even if I would
prefer a change.

···

At 00:20 2003-03-03 +0100, I wrote:

A convention where you are forced between "from wxPython.wx import *" or
"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal.

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

names

[snip]

>If you
> > > want to waste your own time modifying the naming conventions in your

own

> > > code, fine, but don't waste everyone else's.

This reminds me of something Dennis Richie said in 1982:

   "In retrospect it would have been better to go ahead and change the
    precedence of & to higher than ==, but it seemed safer just to split
    & and && without moving & past an existing operator. (After all,
    we had several hundred kilobytes of source code, and maybe 3
    installations....)"

I don't know how many bugs they have caused by the nutty preceedence
rules in C, but it's pretty clear that the cost of letting this stay bad
outweights the cost of correcting (then) availalable code by mangitudes.

Yes, but precedence rules and naming conventions are on totally different
levels in terms of their impact on developers. Logic errors are hard to
catch, and anything that can be done to avoid them should be. Naming
conventions do not introduce bugs into code, except possibly syntax errors,
which in most cases will be caught very quickly. (And syntax errors are of
course not specific to naming conventions)

I think that requiring all wxPython developers to convert all of their
scripts (even with a grace period) would be just as disruptive as some nutty
precedence rules. It requires all these developers to go through and "fix"
their code as if it were broken. If they were happy with the existing code,
they are doing it simply in the hopes that maybe it will help spur adoption
by more Python programmers. However, I can say that the syntax of wxPython
did not at all factor into my decision to choose the toolkit - it was just
technically superior (by far) to anything out there.

A convention where you are forced between "from wxPython.wx import *" or
"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal. The
"from X import *" style means that the object inspectors availible in IDEs
become completely useless, and "wx.wxFrame" sure is ugly. As powerful IDEs
become more common, people will be more and more reluctant to use "from
X import *".

I think we all agree that wx.Frame is the way it should have looked like
from the beginning--in an ideal world.

> > Actually, I think they are very important for readability and

consistency.

> > However, in this particular case it is likely that backwards

compatability

> > and continued ease of using the same naming conventions in C++...

outweigh

> > the benefits of more pythonic naming.

This is obviosuly something one might consider. I think the issue of

conformity

between wxWindows and wxPython is more important than the fixable issue of
backward compatibility though. It seems to me that it should be possible

to

automate conversion of documentation from C++ to Python style though. That
makes the problem smaller.

People tend to talk about the backwards compatibility issue like it's a
simple, automatable procedure. It's not. It involves lots and lots of people
who need to be convinced that this change is right and that they should
update their code. If all of these people don't update their code, then
after the 'transition phase' there will be very real backwards compatibility
problems. And wxPython will only be hurt by it.

> > The point of the email was to bring up the issue and then put it to

rest

> > unless there was a strong desire to change the class names to drop the

wx

> > prefix and the method names to lowerUpper from UpperUpper. I don't

expect

> > most people will want the pythonic naming, because of the difficulty

of

> > switching.

Given a reasonable grace period where both versions work, I don't see a
big issue here. Particularly with wxPython's current track record of
API stability.

Given it's track record, I think doing a complete API rename would only
further strengthen people's perception of the wxPython API as unstable. I
think people would like the API to change *less* than it already is.

From a longer time perspective, I certainly see both less namespace
pollution and conventional method names as a clear advantage. If I
had the option to switch to another GUI toolkit that offered the same
features as wxPython, but had fixed these warts, I'd switch for the
next project. Whether I'd port any current project is difficult to
say since there *is* no other GUI toolkit for python that offers the
same features... :slight_smile:

Exactly. If, and I put this in the "practically impossible" category, some
other toolkit came along that was as good as wxPython and had none of it's
warts, then yes people would switch. Why do I say practically impossible?
Because *everything* has warts - if some toolkit came along, it would just
have different warts, and you could choose which warts you liked better. :slight_smile:
Some people would argue that the fact that wxWindows wraps native controls
rather than making its own is a wart, and those people chose other toolkits.

>Most people, I think, will simply conclude that scripts written in

wxPython

>don't run even with wxPython installed, so wxPython must be unstable.

They

>will then try to avoid it and tell their friends to do the same. Using
>wxPython, without a doubt, will become more complex and I really doubt

that

>will help the adoption of wxPython by developers or tech savvy users

alike.

>It won't necessarily "just work" anymore.

*After* the transition period is over, I think this change will
make it *easier* for python programmers to adopt wxPython. That's
the entire point with the change!

But if everyone thinks that wxPython has an unstable, constantly changing
API once the transition period has ended, how many new Python developers do
you think will be rushing to adopt it? To make this transition seamless,
you'd have to assume that every wxPython script out there is still being
maintained by someone, and that this someone has a vested interest in making
sure that the script gets updated or that the community understands what
version of wxPython needs to be used with it, etc. In an ideal world, that
would be the case. In the real world, I think a significant number of
scripts aren't actively maintained and would just break.

Not to mention, for some people naming conventions are really a non-issue,
so I think we can assume that wxPython will continue to gather more of a
user-base regardless of whether or not the naming conventions are changed.
And no one really knows how much of an impact the naming convention issue
will have on new developers.

With all respect to Robin and the other developers, staying with the
current warts won't prevent problems. Just changing from 2.3.2 to 2.3.3
broke my code in several pieces. At least menus and grids changed their
behaviour in ways that weren't backward compatible.

In menus "aMenu.Append(SOME_ID, _("bla bla"), "", checkable=1)"
stopped working and had to be replaced with .AppendCheckItem. I
don't remember the exact changes in wxGrid, but it broke my code...

So, unfortunately, it's my experience that you can't expect a program
developed with one version of wxPython to work with a later version
of wxPython.

I realize that wxPython 2.3 was based on a development version of
wxWindows, and that this is supposed to get better with 2.4, but I
haven't dared upgrading yet. As far as I understood, there have been
some issues with the first versions of 2.4... At least with a change
like this, I'd know exactly what to change and why.

>As a result of all this, you've
>started a discussion about whether or not to implement such a change, and

I

>think have gotten people nervous that such a change may in fact happen.

Are you going to send him your psychiatrist bills? :wink:

Nah, I've been scarred far worse by Bill Gates, and he has more money to
boot. I've been forwarding my bills along there. :wink:

I think this is a very reasonable discussion. I'm sure I'm not the only
programmer here who have been troubled by legacy code that is really bad
because programmers in the past tried to avoid changing more than they
had to. As Tim Peters wrote:

I also believe it is a very reasonable discussion, but also a very important
one that shouldn't be taken lightly. That's why I get nervous when people
sort of just quickly mention the transition period in a manner such as
"well, the transition will work for the most part and there probably won't
be any real problems". Or "people will just have to deal with it because it
will make wxPython better". I don't think it's really quite that simple.

'''The "ain't broke, don't fix" philosophy is a good guide here, provided
you've got a very low threshold for insisting "it's broke".'''

Don't you think we will be better off in, let's say, a three year
perspective if we get rid of these warts?

Tim Peters also wrote:
"Special cases aren't special enough to break the rules.
Although practicality beats purity."

I think it's an excellent quote - on it's face it is (purposely)
hypocritical, but it actually is a very logical and sensible statement. :wink:
The point being that the practical benefit must always be weighed when
deciding to fix a 'wart'.

The relevance to this situation is that the practical value of changing the
naming conventions is very much debatable. We have no real idea about
whether or not changing the naming convention will spur additional adoption
of wxPython in any real way. What we do know is:

1) Some scripts *will* break (how many, we don't know)

2) Time will need to be spent implementing the change and warning everyone
of the upcoming compatibility problems

3) To ensure a smooth transition, all wxPython developers will need to
modify their code, including possibly needing to manually edit and test
their code to ensure compatibility

In a practical sense, these would all be considered negative consequences of
the change. So making wxPython scripts compatible with future versions will
actually be quite an effort, but it is anyone's guess if this will really
help adoption of wxPython in a real way. The purist viewpoint would say that
the naming conventions *must* be changed to ensure conformity and "remove
warts". The practical viewpoint begs the question - yeah, but is it worth
all the trouble it will cause?

>I realize you were probably just 'throwing the idea out there', because

it

>came up in the discussion, but I bet it has a bunch of people thinking

very

>hard about what they would do if such a change were to occur - how would
>they inform their users, what support would they offer for 2.4 vs. 2.5,
>whether or not this change will affect how people perceive their program,
>etc. The technical issues of automatically converting scripts to the new
>syntax are merely the tip of the iceberg, IMHO. It's the amount of time
>spent helping people migrate to the new version and the potential lost

users

>due to unexpected failures that would really be the problem.

Are you saying that you have customers that handle their own Python and
wxPython versions, and you just ship .py files without knowing what
version of Python and wxPython they have, and without instructing them
about what versions they should use? Wow!

Nah, I'm saying that developers will write web pages with tutorials and
example scripts, that developers will share scripts with one another, that
some developers are indeed writing wxPython extensions/programs geared
towards other wxPython developers, etc. I don't think it's fair to assume
that every wxPython developer is simply going to package their code into a
binary and distribute to end users. In fact, I think there's two major ways
that a developer promotes wxPython:

1) word of mouth and 2) their source code. :slight_smile: In my case, it was #2 that
actually convinced me to adopt wxPython. (I actually used this code as a
basis for learning wxPython.) So I think that downloaded source code not
working is actually a very important and serious issue to be considered.

Regardless of the changes discussed here, I would honestly advice against
such practice. That sounds dangerous to me. Several python versions out
there have rather nasty busgs. As I have said, wxPython has changed

behaviour

in different ways, and I think you will get run into trouble sooner or

later.

I realize that it might be difficult to convince users to upgrade

sometimes,

especially if they have several Python based systems on their site, but I
think knowing what versions they have, and testing thoroughly with those
versions is required practice to assure product quality.

True, but let me ask you this: what justification would you give these
people for the additional time and money they spent re-testing all of their
wxPython code just to ensure it ran under the new naming conventions? (And
it would need to be very thorough testing, as it is like considering the
entire API has changed.) What would be your response when they say that all
their code worked just fine using the old naming conventions?

Kevin

···

----- Original Message -----
From: "Magnus Lycka" <magnus@thinkware.se>
To: <wxPython-users@lists.wxwindows.org>
Sent: Sunday, March 02, 2003 3:20 PM
Subject: Re: [wxPython-users] FW: going from UpperUpper to lowerUpper method

>A convention where you are forced between "from wxPython.wx import *" or
>"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal.

But that doesn't mean that it's a very big issue! Maybe my
wording was a bit strong.

It does disturb me. There are times I try to look in the namespace,
and then I get a bit tired that it's full of things that don't belong
there, but I can surely live with it the way it is, even if I would
prefer a change.

I wouldn't say the wording was too strong -- but then I agree with you.
:slight_smile: The first thing that bugged me when I looked at wxPython was the
recommended syntax of "from wxPython.wx import *" (the exact opposite
recommendation as made by the Python documentation) and I agree that
short-term pain is well worth it, especially since wxPython is still
fairly new and the API is far from stable (as you pointed out).

···

On Sun, 2003-03-02 at 18:34, Magnus Lycka wrote:

At 00:20 2003-03-03 +0100, I wrote:

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

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

--
Anthony Tuininga
anthony@computronix.com

Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838
http://www.computronix.com

Kevin's reply already contains most of what I would have said, so I'll be brief.

Magnus Lycka wrote:

> > So, am I supposed to require all the users of my Python project to
> > update to wxPython 2.5, or am I supposed to maintain two branches of the
> > project, one with the old names and one with the new ones?

I suggest that you agree with your customers about what versions of
Python and wxPython to use with the various versions of your code.

My project is an open source project, so I don't have customers, only users. At this point, the code is changing rapidly, so those users are likely to update via CVS, rather than by downloading a packaged release. If I were to switch naming conventions at some revision, then a user updating from an earlier revision would suddenly find that the code was broken.

A transition period wouldn't help in this case, because my project would have to use one convention or the other. If I stick with the current convention, then my code works fine through the transition period but breaks as soon as the transition period ends. If I move to a new convention, then my code stops working immediately, unless the user updates to a version of wxPython which uses the new convention. The only thing affected by the transition period is exactly when my code breaks.

In menus "aMenu.Append(SOME_ID, _("bla bla"), "", checkable=1)"
stopped working and had to be replaced with .AppendCheckItem. I
don't remember the exact changes in wxGrid, but it broke my code...

So, unfortunately, it's my experience that you can't expect a program
developed with one version of wxPython to work with a later version
of wxPython.

Yes, but this is a *BAD* thing, and therefore something to be avoided whenever possible. I don't see how anyone could interpret this as an argument in favor of making an unnecessary change which breaks backward/forward compatibility.

Are you saying that you have customers that handle their own Python and
wxPython versions, and you just ship .py files without knowing what
version of Python and wxPython they have, and without instructing them
about what versions they should use? Wow!

Regardless of the changes discussed here, I would honestly advice against
such practice. That sounds dangerous to me. Several python versions out
there have rather nasty busgs. As I have said, wxPython has changed behaviour
in different ways, and I think you will get run into trouble sooner or later.

I realize that it might be difficult to convince users to upgrade sometimes,
especially if they have several Python based systems on their site, but I
think knowing what versions they have, and testing thoroughly with those
versions is required practice to assure product quality.

It's an open source project, so I have to ship .py files.

I do test with a variety of versions of Python and wxPython, and tell my users which versions have been tested. However, with only two part-time developers on a 55k line project, there are limits to how much testing I can do.

I do specify a minimum wxPython version, and I can certainly ask users to update to a newer version because it fixes a bug which affects my project, or adds a feature which is useful to my project. However, a change in naming convention matters only to developers, not users, so it is completely unreasonable for me to ask my users to update to accomodate it.

David

Anthony Tuininga wrote:

:slight_smile: The first thing that bugged me when I looked at wxPython was the
recommended syntax of "from wxPython.wx import *" (the exact opposite
recommendation as made by the Python documentation) and I agree that
short-term pain is well worth it, especially since wxPython is still
fairly new and the API is far from stable (as you pointed out).

Going on 6 years is "fairly new"??

Anyway, my final word on class renaming is _if_ it is to be done it would have to use a new module name and the existing module names with the existing class names would be kept for backwards compatibility, and there would be at least a couple phases of the transition. It's unfortunate that the "wx" module name is already used instead of something like "core" because "wx" would be the perfect one to use... So let's assume that there will be a new wxnn.py module, in the first phase it would have things like this in it for all the top-level names:

Window = wx.wxWindow
Frame = wx.wxFrame
DEFAULT_FRAME_STYLE = wx.wxDEFAULT_FRAME_STYLE
etc.

This is easy to do today with some yet to be written tool that will scan all the existing .py files in the wxPython package and write the code needed.

The second phase would move all the real class definitions to wxnn.py and etc. and the old wx.py and etc. files would be the ones generated to be the opposite of the above.

Unfortunatly I see this as being a multi-release (possibly multi-year) transition and although the end-result would be nice, I don't see it as being worth the effort, especially since the peachy "wx" module name would be off limits until no one is using it for the old names any longer. (OTOH, you could always use this: "from wxPython import newnames as wx"...)

···

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

Anthony Tuininga wrote:
> :slight_smile: The first thing that bugged me when I looked at wxPython was the
> recommended syntax of "from wxPython.wx import *" (the exact opposite
> recommendation as made by the Python documentation) and I agree that
> short-term pain is well worth it, especially since wxPython is still
> fairly new and the API is far from stable (as you pointed out).

Going on 6 years is "fairly new"??

Has it been that long already? My time flies when you're having fun...
:slight_smile: Other toolkits have been around for a considerably lengthier period
of time so I guess it depends on which toolkits you are going to compare
with.... :slight_smile: Please don't take this as a denigration of wxPython -- I
certainly didn't mean it that way and I use wxPython quite a bit for a
variety of projects on Linux and Windows and it has done very well for
me.

Anyway, my final word on class renaming is _if_ it is to be done it
would have to use a new module name and the existing module names with
the existing class names would be kept for backwards compatibility, and
there would be at least a couple phases of the transition. It's
unfortunate that the "wx" module name is already used instead of
something like "core" because "wx" would be the perfect one to use...
So let's assume that there will be a new wxnn.py module, in the first
phase it would have things like this in it for all the top-level names:

Window = wx.wxWindow
Frame = wx.wxFrame
DEFAULT_FRAME_STYLE = wx.wxDEFAULT_FRAME_STYLE
etc.

This is easy to do today with some yet to be written tool that will scan
all the existing .py files in the wxPython package and write the code
needed.

The second phase would move all the real class definitions to wxnn.py
and etc. and the old wx.py and etc. files would be the ones generated to
be the opposite of the above.

Unfortunatly I see this as being a multi-release (possibly multi-year)
transition and although the end-result would be nice, I don't see it as
being worth the effort, especially since the peachy "wx" module name
would be off limits until no one is using it for the old names any
longer. (OTOH, you could always use this: "from wxPython import
newnames as wx"...)

So why don't you use the name that you suggested above?

Create wxPython.core to contain all of the stuff that wxPython.wx
currently contains with the new naming convention, first simply renaming
as you showed in step 1 and then actually moving the code as you showed
in step 2.

And then use
from wxPython import core as wx

if you really like to use "wx" as the name of the module imported when
the transition is complete. Once the transition is completed, you can
simply in the __init__.py file have the lines

import core
wx = core

Or the above line

from wxPython import core as wx

could be part of the suggestion if it isn't considered sufficiently
gross.

BTW, since the wx.wxFrame bugs me :-), I would be willing to write the
utility that creates wxPython.core with the method defined above, if you
would like some assistance in that regard.

···

On Mon, 2003-03-03 at 12:48, Robin Dunn wrote:

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

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

--
Anthony Tuininga
anthony@computronix.com

Computronix
Distinctive Software. Real People.
Suite 200, 10216 - 124 Street NW
Edmonton, AB, Canada T5N 4A3
Phone: (780) 454-3700
Fax: (780) 454-3838
http://www.computronix.com

[...]
So why don't you use the name that you suggested above?

Create wxPython.core to contain all of the stuff that wxPython.wx
currently contains with the new naming convention, first simply renaming
as you showed in step 1 and then actually moving the code as you showed
in step 2.

And then use
from wxPython import core as wx

I'm answering here, but I'd like to spend my 2 eurocents also on other
things. If I can say my opinion, I agree with Chris and Jeff,
LeadingUpperCase for method names is certainly better than mixedCase,
which I have always disliked, but I agree that it would be much better to
have "wx.Frame" instead of "wxFrame" and "import *". So I like Anthony's
(or maybe Robin's) proposal to have a wxPython.core that exposes such
names, and is intended to be used like above. The "import as" trick is
certainly not the better thing in the world, but "practicality beats
purity", so I'm definitely +1 for this.

Bye,
Alberto

"Kevin Altis" <altis@semi-retired.com> writes:

> From: David C. Fox
>
> So, am I supposed to require all the users of my Python project to
> update to wxPython 2.5, or am I supposed to maintain two branches of the
> project, one with the old names and one with the new ones?
>
> Naming conventions may be a nice thing to have, but in the end, they
> really aren't that important, and certainly aren't sufficient reason to
> force everyone using a library to modify all their own code. If you
> want to waste your own time modifying the naming conventions in your own
> code, fine, but don't waste everyone else's.

Actually, I think they are very important for readability and consistency.
However, in this particular case it is likely that backwards compatability
and continued ease of using the same naming conventions in C++... outweigh
the benefits of more pythonic naming.

The point of the email was to bring up the issue and then put it to rest
unless there was a strong desire to change the class names to drop the wx
prefix and the method names to lowerUpper from UpperUpper. I don't expect
most people will want the pythonic naming, because of the difficulty of
switching.

-1 for these reasons:

* too late to switch now

* UpperUpper are clearly from the base library, while lowerUpper can
  be used to represent custom methods

* I'm halfway done documenting the existing classes

···

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

Magnus Lycka <magnus@thinkware.se> writes:

Changes are always difficult, but if you are to change something, sooner is
probably better than later, and I think that wxPython is going to be bigger
in the future than it is today. There is still not a single wxPython book
out there, and I imagine Chandler might attract some new people in the
future. It might be about time to remove warts.

Robin and I are writing a book for Manning. So if this is going to
change, it better happen soon.

A convention where you are forced between "from wxPython.wx import *" or
"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal. The
"from X import *" style means that the object inspectors availible in IDEs
become completely useless, and "wx.wxFrame" sure is ugly. As powerful IDEs
become more common, people will be more and more reluctant to use "from
X import *".

I think we all agree that wx.Frame is the way it should have looked like
from the beginning--in an ideal world.

I agree with this, but I'm not sure it is a good enough reason to
change the class/method names. Certainly import * should be
discouraged, imo. In any event, the api documentation will be visible
in PyCrust and any other IDE that uses the decorator code under
development in PyCrust. In a nutshell, it adds docstrings to the
existing classes on the fly, on startup, so that you see the
signatures and docstrings as if the wxPython code was all written in
Python. Get the latest PyCrust from CVS to see what I mean. (Though
the docs are not 100% complete yet.)

> > Actually, I think they are very important for readability and consistency.
> > However, in this particular case it is likely that backwards compatability
> > and continued ease of using the same naming conventions in C++... outweigh
> > the benefits of more pythonic naming.

This is obviosuly something one might consider. I think the issue of conformity
between wxWindows and wxPython is more important than the fixable issue of
backward compatibility though. It seems to me that it should be possible to
automate conversion of documentation from C++ to Python style though. That
makes the problem smaller.

Have you tried to convert the existing docs? It ain't as easy as it
sounds. But I'm still working on it so if you have any tricks up your
sleeves now is the time to join in. Take a look at this part of
PyCrust:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/pycrust/PyCrust/decor/

···

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

Magnus Lycka <magnus@thinkware.se> writes:

···

At 00:20 2003-03-03 +0100, I wrote:
>A convention where you are forced between "from wxPython.wx import *" or
>"from wxPython import wx; frame = wx.wxFrame(..." is far from ideal.

But that doesn't mean that it's a very big issue! Maybe my
wording was a bit strong.

It does disturb me. There are times I try to look in the namespace,
and then I get a bit tired that it's full of things that don't belong
there, but I can surely live with it the way it is, even if I would
prefer a change.

Take a look at the wxPython Docs tab in the PyCrust in CVS. It
provides a wx-like namespace that is much easier on the eyes.

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

Robin Dunn <robin@alldunn.com> writes:

Anyway, my final word on class renaming is _if_ it is to be done it
would have to use a new module name and the existing module names with
the existing class names would be kept for backwards compatibility,
and there would be at least a couple phases of the transition. It's
unfortunate that the "wx" module name is already used instead of
something like "core" because "wx" would be the perfect one to
use...

Great idea. How about wxp? It's still short:

    from wxPython import wxp

    frame = wxp.Frame(...)

So let's assume that there will be a new wxnn.py module, in the
first phase it would have things like this in it for all the top-level
names:

Window = wx.wxWindow
Frame = wx.wxFrame
DEFAULT_FRAME_STYLE = wx.wxDEFAULT_FRAME_STYLE
etc.

This is easy to do today with some yet to be written tool that will
scan all the existing .py files in the wxPython package and write the
code needed.

Nah. Just scan the wx namespace. I've got code for this
already. That's how I'm creating the Python version of the docs.

The second phase would move all the real class definitions to wxnn.py
and etc. and the old wx.py and etc. files would be the ones generated
to be the opposite of the above.

Unfortunatly I see this as being a multi-release (possibly multi-year)
transition and although the end-result would be nice, I don't see it
as being worth the effort, especially since the peachy "wx" module
name would be off limits until no one is using it for the old names
any longer. (OTOH, you could always use this: "from wxPython import
newnames as wx"...)

Seriously, I could have code to do this in less than a day, and it
would allow you to use either style - wxPython proper wouldn't have to
change at all. You just decide if you want to import wx or wxp. But
that only solves the class name issue. The method names are still up
for grabs, and I'm not sure lowerUppper is the right way to go.

···

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