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