If things are changing... (Non-capitalized methods/attributes?)

wxPython Users
1

I'm sure this is way to radical (and controversial), but still...

If the wx package is changing the naming convention of wxPython, why
not go all the way and drop the non-standard capitalized method names?
I know there are no official standards in the matter, but it seems
clear to me that method names like onInit() or setCursor() are much
more common in the Python world than method names like OnInit() or
SetCursor(). Do we really have to follow the convention of wxWindows
here?

If wxWindows is also dropping the wx prefix, I guess keeping the
capitalized names will keep the naming more consistent... I've just
been wishing for this sort of naming convention in wxPython for a long
time, and the wx package seems to go half the way, so I thought I'd
air the thought...

I guess I had better put on my asbestos pants now... :wink:

- M

···

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

2

Magnus Lie Hetland wrote:

I'm sure this is way to radical (and controversial), but still...

If the wx package is changing the naming convention of wxPython, why
not go all the way and drop the non-standard capitalized method names?

Please go back to the archives and read the discussion about all this a
few weeks (months?) back. This, and a bunch of other, more
comprehensive, ideas were brought up, such as establishing more
namespaces, putting constants in their own space, etc.

I think the short version of the conclusions is:

1) Keeping compatibility with wxWindows is important.

2) There was no consensus about what is better anyway. For example: I,
for one, prefer LeadingCaps, and use it in my own code.

The only consensus was that "from blah import *" is bad style (and makes
name completion in tools like Pycrust all but impossible), and that
wx.wxSomething is also ugly. Since wxWindows will probably be adding
namespaces and dropping the leading wx, it made sense to do it for
wxPython anyway.

Note also that Patrick and Robin are writing a book, and want to use a
convention that will hold for a while, hense the rush to a change now,
rather than waiting for wxWindows.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

3

This also came up in the discussion a while back.
AFAIK it was agreed to leave the naming in the way the underlying wxWindows
C++ library handles them.

···

On Wednesday 28 May 2003 09:44 am, Magnus Lie Hetland wrote:

I'm sure this is way to radical (and controversial), but still...

If the wx package is changing the naming convention of wxPython, why
not go all the way and drop the non-standard capitalized method names?
I know there are no official standards in the matter, but it seems
clear to me that method names like onInit() or setCursor() are much
more common in the Python world than method names like OnInit() or
SetCursor(). Do we really have to follow the convention of wxWindows
here?

If wxWindows is also dropping the wx prefix, I guess keeping the
capitalized names will keep the naming more consistent... I've just
been wishing for this sort of naming convention in wxPython for a long
time, and the wx package seems to go half the way, so I thought I'd
air the thought...

I guess I had better put on my asbestos pants now... :wink:

- M

--
  UC

--
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

4

Magnus Lie Hetland wrote:

I'm sure this is way to radical (and controversial), but still...

If the wx package is changing the naming convention of wxPython, why
not go all the way and drop the non-standard capitalized method names?
I know there are no official standards in the matter, but it seems
clear to me that method names like onInit() or setCursor() are much
more common in the Python world than method names like OnInit() or
SetCursor(). Do we really have to follow the convention of wxWindows
here?

If wxWindows is also dropping the wx prefix, I guess keeping the
capitalized names will keep the naming more consistent... I've just
been wishing for this sort of naming convention in wxPython for a long
time, and the wx package seems to go half the way, so I thought I'd
air the thought...

It was discussed, but there are a couple reasons that it won't be done. The first is to try and leverage as much as possible the overlap between languages (and "common lingo") so we are on big community instead of several small ones. For example, using "wx.Frame" will be obvious to a C++ wxWindows guru what you are taling about, but using "window.setSize(size)" may lead him to think you have a typo... The second reason is that thinking ahead to the 2nd phase of the transition, I can see a clear path to renaming all the classes and such in the "real" modules, but also doing it for all the methods would be much more difficult and difficult to maintian, if it is possible at all.

I guess I had better put on my asbestos pants now... :wink:

Not necessary. All the fires on this subject have already burned out.

···

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

5

I would call this "the official conclusion" instead of "*the*
conclusion". Quite a few people in the wxPython community, including
myself, have expressed that compatibility with wxWindows C++
examples/email/docs is of zero importance (to us).

I would even say that one of wxPython's disadvantages is the current
constraint that the API not stray too far from how wxWindows/C++ does
things.

···

On Tuesday 27 May 2003 07:55 pm, Chris Barker wrote:

I think the short version of the conclusions is:

1) Keeping compatibility with wxWindows is important.

--
Chuck
http://ChuckEsterbrook.com

6

Chuck Esterbrook wrote:

> I think the short version of the conclusions is:
>
> 1) Keeping compatibility with wxWindows is important.

I would call this "the official conclusion" instead of "*the*
conclusion".

Those were my impressions of the conclusions to that particular
discussion.

I would even say that one of wxPython's disadvantages is the current
constraint that the API not stray too far from how wxWindows/C++ does
things.

As it happens, I agree with you about that, but I think the solution is
not to weedle away at wxPython, but to really build a new framework,
possibly based on wxPython(wxWindows). I think PythonCard may be just
the ticket, though I have not had the time yet to really check it out.
Are you using/contibuting to PythonCard. If not, I'd like to know why
not, because you clearly have some very good ideas about things could be
better structured.

"Better" sometimes being the enemy of "good enough", I think that
wxPython is good enough, and the better, ideal toolkit just has too much
of a start up cost to have happened.

-Chris

···

On Tuesday 27 May 2003 07:55 pm, Chris Barker wrote:

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

7

Chuck Esterbrook wrote:
> > I think the short version of the conclusions is:
> >
> > 1) Keeping compatibility with wxWindows is important.
>
> I would call this "the official conclusion" instead of "*the*
> conclusion".

Those were my impressions of the conclusions to that particular
discussion.

> I would even say that one of wxPython's disadvantages is the
> current constraint that the API not stray too far from how
> wxWindows/C++ does things.

As it happens, I agree with you about that, but I think the solution
is not to weedle away at wxPython, but to really build a new
framework, possibly based on wxPython(wxWindows). I think PythonCard
may be just the ticket, though I have not had the time yet to really
check it out. Are you using/contibuting to PythonCard. If not, I'd
like to know why not, because you clearly have some very good ideas
about things could be better structured.

I started with wxPython in order to learn the "base library". I haven't
had a chance to crack open PythonCard or MindWrapper yet both of which
are on my TO DO list.

However, I think some of the improvements that wxPython could benefit
from are independent of the larger themes that PythonCard and
MindWrapper embrace. In which case, I'd rather see them go in wxPython
direct or a third party package that could be used with any of them.

"Better" sometimes being the enemy of "good enough", I think that
wxPython is good enough, and the better, ideal toolkit just has too
much of a start up cost to have happened.

Agreed.

···

On Tuesday 27 May 2003 10:26 pm, Chris Barker wrote:

> On Tuesday 27 May 2003 07:55 pm, Chris Barker wrote:

--
Chuck
http://ChuckEsterbrook.com

8

Chuck Esterbrook wrote:

I started with wxPython in order to learn the "base library". I haven't
had a chance to crack open PythonCard or MindWrapper yet both of which
are on my TO DO list.

Mine to.

However, I think some of the improvements that wxPython could benefit
from are independent of the larger themes that PythonCard and
MindWrapper embrace. In which case, I'd rather see them go in wxPython
direct or a third party package that could be used with any of them.

hmm. that third party package is a good idea ... sort of a mix-in. It
might be a good way to start the thicker wrapper around wxWindows that
some of us want, without disrupting to much. It seems to me that
wxWindows has settled down to a point where the API is stable enough for
this kind of thing to work now, where it wasn't a couple of years ago.

I'd like to hear some of your ideas. By the way this sounds a little
like the "monty" project that Keven Altis started up a while ago (
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools. ) but it kind oif
died on the vine. He got tied up with Pythoncard, and I guess no one
else picked it up.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer
                                        
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

9

I'll check out the thread. I won't be spewing too many ideas in the next
couple of weeks as I'm about to move.

Thanks for the discussion,

···

On Wednesday 28 May 2003 02:54 am, Chris Barker wrote:

hmm. that third party package is a good idea ... sort of a mix-in. It
might be a good way to start the thicker wrapper around wxWindows
that some of us want, without disrupting to much. It seems to me that
wxWindows has settled down to a point where the API is stable enough
for this kind of thing to work now, where it wasn't a couple of years
ago.

I'd like to hear some of your ideas. By the way this sounds a little
like the "monty" project that Keven Altis started up a while ago (
ActiveState Community - Boosting coder and team productivity with ready-to-use open source languages and tools. ) but it kind
oif died on the vine. He got tied up with Pythoncard, and I guess no
one else picked it up.

--
Chuck
http://ChuckEsterbrook.com

10

That's where it all started in March. Search for UpperUpper
in the mailing list archives at Activestate.

···

At 18:44 2003-05-28 +0200, Magnus Lie Hetland wrote:

If wxWindows is also dropping the wx prefix, I guess keeping the
capitalized names will keep the naming more consistent... I've just
been wishing for this sort of naming convention in wxPython for a long
time, and the wx package seems to go half the way, so I thought I'd
air the thought...

--
Magnus Lycka (It's really Lyckå), magnus@thinkware.se
Thinkware AB, Sweden, www.thinkware.se
I code Python ~ The shortest path from thought to working program