Language change and code breaks
Terry Reedy
--with particular reference to Python and recent discussions in
comp.lang.python
Terry J. Reedy, tjr...@udel.edu
July 10, 2001
Summary: After discussing two generals issues (type and audience), I
particularly look at the effect on new programmers and the effect of
replacement changes.
Types of Change: As in other realms, such as text editing, we can
categorize programming language changes as addition, deletion, and
replacement. While replacement can be modeled by or reduced to deletion
and addition (see Keywords below), replacement in the specific sense of
changing the meaning of a construct legal both before and after is
qualitatively different in its effect on programmers and code. It should
therefore be kept as a separate category.
Audience: Each type of change will have different effects on old and new
code (defined as that written for the the old and new versions of the
language) when run on the 'wrong' version on the language interpreter.
Programmers will also see the change differently depending on whether they
learn the language before or after the change . Existing users who pay
attention to the change will have to upgrade their knowledge and maybe
their code. New users who initially learn only the new version of the
language and then read old code or run code on old interpreters without
backdating their knowledge may be surprised.
Deletions: If a feature is directly deleted, it presumably is rare used and
not too useful. When present in code run on a new system, there should be
a syntax error and the programmer will have to remove it and maybe do
something else. New users reading old code will seldom see deleted
features. (I have never, for instance, seen an access statement.) If and
when they do, they may ignore it, guess its meaning, or find its meaning in
old documentation.
Additions: Old code runs fine in new interpreters. New users will never
see the new feature they learned in old code. If they try to use it with
an old interpreter, they will get an error message and either work around
its absence or stick with new interpreters.
Keywords: Addition of a word as a keyword implicitly deletes its previous
usage as a name. As long as the legal usages before and after are
disjoint, any wrong usages will be flagged as errors. This combination of
deletion and addition is different from replacement in the narrow sense I
use here. Example: The statement 'yield <expression>' is disjoint from
any current legal use of 'yield' as, for instance, a name for bond yield.
Replacements: These are the most troublesome changes since they amount to a
silent code break. There will be no error message (at least not at the
point of misinterpretation) when code is run under the wrong interpreter.
Similarly, there is no reason for a flag to raised in the mind of a new
user who only knows the new meaning of the construct.
A further complication is that incompatibility is bidirectional. Old code
that does not use a deleted feature and new code that does not use an
added feature can run on both old and new interpreters. After a
replacement, code must avoid the changed-meaning syntax entirely, in both
old and new meanings, to achieve the same flexibility.
For various reasons, transitions may take several years before everyone
upgrades their interpreters to any particular release level. Last I knew,
for instance, some Linux distributions still install Python 1.5.2.
Code-breaking replacements probably inhibit ungrades more that
non-code-breaking additions
Example 1 - nested scooping: As I understand it, the value assigned to y
in
x = 1
def f():
x = 'one'
def g():
y = x
is changing from 1 to 'one'. This transition is eased by the fact that
duplicate intermediate names are currently unnecessary (just change the
spelling) and rare. As a transition measure, the compiler can detect this
usage and emit a warning, strongly suggestion a name change before the
scope-hiding meaning is deleted by being replaced. As for newcomers, those
few who really delve into into the advanced topic of nested functions and
name scoping can also read an included warning about the older two-level
rule.
Example 2 - integer (int+long) division: This transition is more involved
and will be harder even with extra planning.
a. While it is fairly easy to write the future meaning of int/int in the
current language, using '.0' and float() as people do now, the currently
possible rewrite of the current meaning so it will remain valid --
divmod(e1,e2)[0]) -- is more complex and slower to run. Therefore, a
simultaneous (or preceeding) addition of something like infix 'div' is
desirable (and already planned).
b. Nested scoping applies to all nested functions; its uses are detectable
at compile time, which makes warnings about deprecated usages easy. The
change in meaning of e1 / e2 is partial in that it only affects
integer-integer division. While the case of two literal constants could be
detected at compile time, detection generally awaits the run-time
dispatching in the function that implements '/'. A warning mechanism will
have to include run-time warnings. A mechanism to turn warnings on and off
on a per-statement basis would be helpful.
c. Nested scoping was intended to be an addition until someone noticed the
existence of a foolish-but-legal conflict. The change in meaning of
integer / integer is a true bidirectional replacement that will invalidate
actual and not just theoretically possible code. To make code
cross-compitible, one will generally (without specific program analysis)
have to avoid all occurrence of integer-integer division in any form, with
either / or div or with constants or variables.
d. If the change in meaning brought about by a replacement is large, one
may hope that the uncaught error introduced by a legal but incorrect
cross-usage will bring about an exception sometime later in the
computation. However, the division change may only change the type of the
result, which may well change but not crash further computation. And, of
course, the value error, if not zero, may be small and similarly hard to
detect.
e. Almost everyone who does much of any programming will use division
sometime, so everyone should be taught how to program it. So this change
affect beginners and not just advanced programmers. For years after the
change, anyone who might use an older system that they do not control, such
as at a school campus or workplace, should also be taught that 'integer /
integer' used to mean 'interger div integer', and that subtle and
hard-to-detect errors can arise from erroneous cross-usage.
Guido van Rossum
integer division -- maybe it's better to leave well enough alone, and
try to fix areas of the language that could really stand some fixing
(such as subclassing built-in types).
--Guido van Rossum (home page: http://www.python.org/~guido/)
Steve Holden
news:cplmlvh...@cj20424-a.reston1.va.home.com...
[muted cheering is heard in the background]
I regard your ability to recognize and respond to intelligent criticism as
an even better demonstration of your greatness than the excellent language
design and implementation abilities you continue to put into Python.
That fact that *I* was unable to convince you leaves me feeling somewhat
chastened about the qualities of my own criticism, however :-)
regards
Steve
--
http://www.holdenweb.com/
Nick Perkins
"Guido van Rossum" <gu...@python.org> wrote in message
news:cplmlvh...@cj20424-a.reston1.va.home.com...
If changing int/int->int to int/int->float is going to break too much code,
then why not use another operator?
I have seen // suggested as a replacement for int/int->int,
ie. int//int->int,..
but why not leave int/int->int alone,
and use // for int//int->float.
No code breaks, and it is almost as easy for the newbies.
1/2 -> 0
1//2 -> 0.5
That way we still have / = div, % = mod,
and we add // = float-divide.
No need for a 'div' operator or anything like that.
p.s.
Would it be possible to allow operators to be used as first-class functions,
eg:
reduce(+,mylist)
instead of:
import operator
reduce(operator.__add__,mylist)
Dirck Blaskey
"Guido van Rossum" <gu...@python.org> wrote in message
news:cplmlvh...@cj20424-a.reston1.va.home.com...
Glad you're having second thoughts, I'm on my third or fourth.
At one point you even had me convinced, but then...
to someone maintaining a large code base, dealing with
a change this subtle could be somewhere between 'intimidating'
and 'terrifying', especially since there are no type declarations.
I don't think I agree with the spirit of PEP 228, either.
Hardware is a fact of life.
Anyway, Just another point to consider:
In all the examples cited that show why this is a problem,
it's not integer division that causes the confusion,
it's division of integer *literals*. Anyone using literal '1/2'
in a program has probably made a mistake. I don't know how smart the
compiler is in pre-processing constant expressions, but if it is,
it could be smart enough to issue warnings for constant integer division
yielding quotient == 0 or remainder != 0.
Just a thought.
d
Steven D. Majewski
On Wed, 11 Jul 2001, Guido van Rossum wrote:
> Very good sumary, Terry. I'm beginning to get second thoughts about
> integer division -- maybe it's better to leave well enough alone, and
> try to fix areas of the language that could really stand some fixing
> (such as subclassing built-in types).
Is it possible that changes to built-in types to allow subclassing could
be made to also allow redefining operators for built-in types ?
Then "/" could be mapped to either behaviour, and gradual introduction
could be a matter of changing the default behaviour in a future version.
I know some folks will object to the idea of redefining basic function,
but Python already allows that for a lot of built-in functions (import
and others).
[I haven't had the stamina to read every message in this thread, so please
forgive me if this has already been suggested.]
-- Steve Majewski
Guido van Rossum
> be made to also allow redefining operators for built-in types ?
>
> Then "/" could be mapped to either behaviour, and gradual introduction
> could be a matter of changing the default behaviour in a future version.
I'm currently working on subclassing built-in types, but redefining
operations for existing built-in types is not part of my agenda, for
various reasons (most of which have to do with boring implementation
details, but are real showstoppers nevertheless).
So alas, no relief from that angle. Maybe we'll have to accept a
directive.
Konrad Hinsen
> but why not leave int/int->int alone,
> and use // for int//int->float.
>
> No code breaks, and it is almost as easy for the newbies.
Sounds like a good idea. Just the existence of two division operators
would help newbies to recognize that there is a nontrivial problem.
And a//b definitely beats (a+0.)/b, which does the trick, but is not
at all evident.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
David Bolen
> Sounds like a good idea. Just the existence of two division operators
> would help newbies to recognize that there is a nontrivial problem.
> And a//b definitely beats (a+0.)/b, which does the trick, but is not
> at all evident.
Well, I'd probably suggest using "float(a)/b" instead which at least
makes it a little easier to see what's going on :-)
--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/
Skip Montanaro
Konrad> And a//b definitely beats (a+0.)/b, which does the trick, but is
Konrad> not at all evident.
I'm not sure that the purpose of a//b would be all that evident to a new
Python programmer, especially one whose first programming language is
Python. I've never seen // used as an operator before other than to
introduce comments in C++ and that ilk. I suppose it means something in
APL, and I wouldn't be that surprised if it had some meaning in Perl. ;-)
At the very least C, C++ and Java programmers should be familiar with the
purpose of
(a+0.0)/b
or
float(a)/b
--
Skip Montanaro (sk...@pobox.com)
(847)971-7098
Peter Hansen
> That fact that *I* was unable to convince you leaves me feeling somewhat
> chastened about the qualities of my own criticism, however :-)
Take heart: I suspect it was more than the one posting which had this effect!
Perhaps one could say Terry's posting represented a crystallization of a
number of concerns various people have had. It worked for me too, and
Guido's comments had previously already convinced me of the value of
the change, in spite of my own concern of what it would mean in my area.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Fredrik Lundh
>
> > And a//b definitely beats (a+0.)/b, which does the trick, but is not
> > at all evident.
>
> Well, I'd probably suggest using "float(a)/b" instead which at least
> makes it a little easier to see what's going on :-)
except that it doesn't do the right thing if a is a complex
number.
</F>
David Bolen
Hmm, good point - I hadn't thought of that.
Of course, if a was complex then we wouldn't be worried about a/b
truncating anything either. But definitely something to keep in mind
if working on code that might receive either complex or integer
parameters.
"Jürgen A. Erhard"
Peter> Steve Holden wrote re BDFL and int/int:
>> That fact that *I* was unable to convince you leaves me feeling somewhat
>> chastened about the qualities of my own criticism, however :-)
Peter> Take heart: I suspect it was more than the one posting
Peter> which had this effect!
Peter> Perhaps one could say Terry's posting represented a
Peter> crystallization of a number of concerns various people have
Peter> had. It worked for me too, and Guido's comments had
Peter> previously already convinced me of the value of the change,
Peter> in spite of my own concern of what it would mean in my
Peter> area.
[Yeah, yeah, I can't shut up ;-)]
I hope the change does get done, with an appropriate use of the
__future__ statement as Guido outlined.
I had a script recently where I wanted to pass in a command line param
that could be a numeric ratio, s.th. like
thescript --ratio=1/3
Now, what do I do with that? I can't use 1/3, because that eval'd is
0. So... either people need to specify a float (--ratio=.3333... not
very good looking) or I have to do some magic inside the script (look
whether the ratio contains a /, split, float() on part, and merge)
If 1/3 gave the obvious result, all would be well.
Bye, J
PS: Guido said he has "second thoughts" and that "maybe" it's better
to leave it as is. I still have hope ;-)
--
Jürgen A. Erhard (juergen...@gmx.net, j...@users.sourceforge.net)
My WebHome: http://members.tripod.com/Juergen_Erhard
George Herrimann's Krazy Kat (http://www.krazy.com)
I wish I had more energy -- or less ambition.
--pgp-sign-Multipart_Thu_Jul_12_02:23:43_2001-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjtM7hcACgkQN0B+CS56qs02IgCgoj7KAphSbSA5r1Xhm1OG8jnB
oAkAnisAh/VB/miOYG6otAWAoiDj719G
S+Zx
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Jul_12_02:23:43_2001-1--
Terry Reedy
"Guido van Rossum" <gu...@python.org> wrote in message
news:cplmlvh...@cj20424-a.reston1.va.home.com...
---
Thanks for the response. My specific comments (for today) on int division
are in the PEP 0238 thread. My general view on arithmetic change is this:
while your design for Python's arithmetic has served well for a decade,
without any change that I can think of, there are several dissatifactions
and proposals for modification. Many involve semantic replacement, with
its accompanying problems. If you are not going to reject them all
indefinitely, then we should discuss, debate, plan, and experiment for
several months to a year to come up with a coherant new design for Python
arithmetic that we can install all at once and then live with for several
more years without further change. Piecemeal change release after release
could become very messy.
Terry J. Reedy
Greg Ewing
>
> In all the examples cited that show why this is a problem,
> it's not integer division that causes the confusion,
> it's division of integer *literals*.
That's only because the examples have deliberately
been made very concise, to show the essence of
what's going on.
The problem occurs when / is applied to integer
*objects*, which can arise from any number of
sources.
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Greg Ewing
>
> I'm not sure that the purpose of a//b would be all that evident to a new
> Python programmer
So they'd have to look it up. What's so bad about that?
If Guido is not courageous enough to change the
meaning of /, this seems like a good alternative
plan to me.
Mikael Olofsson
On 11-Jul-2001 Nick Perkins wrote:
> but why not leave int/int->int alone,
> and use // for int//int->float.
>
> No code breaks, and it is almost as easy for the newbies.
>
> 1/2 -> 0
> 1//2 -> 0.5
>
> That way we still have / = div, % = mod,
> and we add // = float-divide.
Being in EE, I would immediately interprete a//b as two resistors, a and
b, in parallel. Thus, I would expect 1//2 to return 0.666666...
just-half-joking-ly y'rs
/Mikael
-----------------------------------------------------------------------
E-Mail: Mikael Olofsson <mik...@isy.liu.se>
WWW: http://www.dtr.isy.liu.se/dtr/staff/mikael
Phone: +46 - (0)13 - 28 1343
Telefax: +46 - (0)13 - 28 1339
Date: 12-Jul-2001
Time: 08:33:18
/"\
\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \
This message was sent by XF-Mail.
-----------------------------------------------------------------------
Mikael Olofsson
On 11-Jul-2001 Nick Perkins wrote:
> and use // for int//int->float.
>
> No code breaks, and it is almost as easy for the newbies.
>
> 1/2 -> 0
> 1//2 -> 0.5
>
> That way we still have / = div, % = mod,
> and we add // = float-divide.
Being in EE, I would immediately interprete a//b as two resistors, a and
Dirck Blaskey
news:3B4D3622...@cosc.canterbury.ac.nz...
> Dirck Blaskey wrote:
> >
> > In all the examples cited that show why this is a problem,
> > it's not integer division that causes the confusion,
> > it's division of integer *literals*.
>
> That's only because the examples have deliberately
> been made very concise, to show the essence of
> what's going on.
>
> The problem occurs when / is applied to integer
> *objects*, which can arise from any number of
> sources.
The problem occurs when the programmer doesn't realize there is a problem,
not because of something fundamentally wrong with integer math.
It's a problem with expectations and the law of least astonishment.
Which audience would you rather astonish, and how much?
After I thought about it some more:
"of course the examples show literals,
or they wouldn't be very good examples, would they?"
though I still assume this example:
(x+y)**(1/2)
is verbatim.
Detecting and reporting the case for literals wouldn't break code,
and might provide enough help to some novice programmers so
they would realize this is something they have to be aware of,
and perhaps learn, and maybe even remember in the cases where they're
not using literals. It is a burden.
"Might"+"some"+"perhaps"+"maybe" is far too vague for Guido's tastes.
Of course, it was just a thought, if not necessarily a good one.
d
Thomas Wouters
> Very good sumary, Terry. I'm beginning to get second thoughts about
> integer division -- maybe it's better to leave well enough alone, and
> try to fix areas of the language that could really stand some fixing
> (such as subclassing built-in types).
Wow, Terry! Remind me to buy you a beer at the next Python conference, or
whenever we're more or less on the same continent ;) I never was too hot
about the CP4A reason to change int division, and your post not only
reminded my on why, it even made Guido reconsider, and he's been thinking
about it for years! :)
--
Thomas Wouters <tho...@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Konrad Hinsen
> Of course, if a was complex then we wouldn't be worried about a/b
> truncating anything either. But definitely something to keep in mind
> if working on code that might receive either complex or integer
> parameters.
Whenever you know the type of your objects there is no problem. But
often you want to write a mathematical expression which accepts any
reasonable type, even Python classes with a number interface. An
explicit cast to float() is very undesirable in such situations, and
a hack such as (a+0.)/b is not obvious to the uninitiated.
A special operator, // or whatever, with the meaning of "the best
approximation to standard artihmetic division that is available" is
the best way to express this, in my opinion. Perhaps some number-like
classes could even reimplement it in some clever way.
Konrad Hinsen
> I'm not sure that the purpose of a//b would be all that evident to a new
> Python programmer, especially one whose first programming language is
Certainly not, but it would be evident that it has some special meaning
and that you better find out what it is.
> Python. I've never seen // used as an operator before other than to
So what?
> At the very least C, C++ and Java programmers should be familiar with the
> purpose of
Any experienced programmer will probably figure out what that means.
Still, it's a hack. The code doesn't say what you want to do, it says
what you *don't* want to do (i.e. integer division).
Clive Page
Mikael Olofsson <mik...@isy.liu.se> wrote:
>Being in EE, I would immediately interprete a//b as two resistors, a and
>b, in parallel. Thus, I would expect 1//2 to return 0.666666...
While a Fortran programmer would expect to see character concatenation.
--
Clive Page c...@le.ac.uk
pf...@mmm.com
one week coding every few months. I *always* forget the 1/3 == 0 thing
between programming bursts. OTOH, I also quickly remember after making the
mistake the first time. It's not a problem when I'm using C, because I'm
more conscious of type when I'm working in C. But, I think it's very
unpythonic to have to worry about integer vs float types when doing simple
math.
Tom Fenn
Bjorn Pettersen
[snip]
> I had a script recently where I wanted to pass in a command line param
> that could be a numeric ratio, s.th. like
>
> thescript --ratio=1/3
>
> Now, what do I do with that? I can't use 1/3, because that eval'd is
> 0. So... either people need to specify a float (--ratio=.3333... not
> very good looking) or I have to do some magic inside the script (look
> whether the ratio contains a /, split, float() on part, and merge)
If you're eval'ing random strings the user types in you really deserve
whatever you get <1/3 wink>.
>>> r = '1/3'
>>> import re
>>> tmp = r.split('/')
>>> assert len(tmp) == 2
>>> a, b = tmp
>>> assert re.match(r'[0-9]+', a) != None
>>> assert re.match(r'[0-9]+', b) != None
>>> x, y = map(int, [a,b])
>>> ratio = (x + 0.0) / y
>>> ratio
0.33333333333333331
>>>
Nothing magic about it...
-- bjorn
Skip Montanaro
Tom> I *always* forget the 1/3 == 0 thing between programming bursts.
Tom> OTOH, I also quickly remember after making the mistake the first
Tom> time.
What is it that reminds you of the mistake? Is it something glaring like
using the result of 1/3 as a divisor and getting a divide-by-zero error, or
is it something more subtle like getting slightly incorrect results and
having to dig through your code to find the problem?
pf...@mmm.com
--
Skip Montanaro (sk...@pobox.com)
It's usually easy to find using the primitive tests I set up. Typically,
data starts out as floating point, so this behavior won't cause incorrect
results. Instead, I get incorrect graph labeling, etc. However, this
issue is going to keep coming up as a problem because it's not what an
occasional user, even an experienced occasional user expects to happen,
particularly with a dynamically typed language like Python. This is the
only point on which I consider Visual Basics behavior to be "better" than
Python's.
Is there really much code that depends on 1/3 == 0 being true?
Tom Fenn
Emile van Sebille
<pf...@mmm.com> wrote in message
news:mailman.994958301...@python.org...
>
<snip>
>
> Is there really much code that depends on 1/3 == 0 being true?
I use it. I imagine that for as long as it's been that way, if everyone
were constantly writing some form of float(x)/y or 1.0*x/y or x/7.0 all the
time and never using is as integer math, it likely would have been changed
long before I started with python... ;-)
--
Emile van Sebille
em...@fenx.com
---------
Grant Edwards
>
>> I *always* forget the 1/3 == 0 thing between programming
>> the first time.
>
>Is there really much code that depends on 1/3 == 0 being true?
I regulary depend on integer division working the way it does.
--
Grant Edwards grante Yow! I had a lease on an
at OEDIPUS COMPLEX back in
visi.com '81...
"Jürgen A. Erhard"
>> From: "Jürgen A. Erhard" [mailto:juergen...@gmx.net]
Bjorn> [snip]
>> I had a script recently where I wanted to pass in a command
>> line param that could be a numeric ratio, s.th. like
>> thescript --ratio=1/3
>> [...]
Bjorn> If you're eval'ing random strings the user types in you
Bjorn> really deserve whatever you get <1/3 wink>.
Oops, you're right... though there's no security hole in there if the
script only runs *as that user*. And I generally trust the users of
these scripts anyway (= I trust myself ;-)
>>>> r = '1/3'
>>>> import re
>>>> tmp = r.split('/')
>>>> assert len(tmp) == 2
>>>> a, b = tmp
>>>> assert re.match(r'[0-9]+', a) != None
>>>> assert re.match(r'[0-9]+', b) != None
>>>> x, y = map(int, [a,b])
>>>> ratio = (x + 0.0) / y
>>>> ratio
Bjorn> 0.33333333333333331
>>>>
Bjorn> Nothing magic about it...
And nothing readable. ;-}
Bye, J
--
Jürgen A. Erhard (juergen...@gmx.net, j...@users.sourceforge.net)
My WebHome: http://members.tripod.com/Juergen_Erhard
Stop the execution of Mumia Abu-Jamal! (http://www.freemumia.org)
I have a firm grip on reality, now I can strangle it.
--pgp-sign-Multipart_Thu_Jul_12_21:06:42_2001-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iEYEABECAAYFAjtN9UoACgkQN0B+CS56qs02GACfbEmuwYSHnxqGYVz31DxVX3z3
n3MAn2GQYOXVdwnU4KUqPwUuupn/bhT/
SIqG
-----END PGP SIGNATURE-----
--pgp-sign-Multipart_Thu_Jul_12_21:06:42_2001-1--
Greg Ewing
>
> In article <mailman.994958301...@python.org>, pf...@mmm.com wrote:
> >
> >Is there really much code that depends on 1/3 == 0 being true?
>
> I regulary depend on integer division working the way it does.
The point is whether there is any code which relies
on polymorphically deciding between integer and float
division at run time. I find it very difficult to
imagine what sort of application would *need* that.
Peter Hansen
Unfortunately, while code a chemist writes is very likely never
going to rely on the current integer division behaviour, code
written by those of us in computers who tend to work closely
with the hardware (where we are constantly thinking in terms
of bytes, words, signed and unsigned, memory locations, bits
and nybbles, etc.) will fairly often write code which depends
on the current behaviour. (By the way, no, we would never
write 1/3 and expect 0, but 99% of the time we are not talking
about constant expressions such as this... but you knew that.)
I can't see a simple answer to this. It looks as though there
are two camps, to both of whom it is absolutely essential that
Python act in a specific way. And the two ways are completely
incompatible.
Doesn't that mean that the only solution that can be accepted
without causing serious complications is to make the change,
but clearly support a command line option (or some other
configuration setting) to enable the current behaviour,
so those who have depended on integer division can continue
to run old code under the new engine without fear of
breakage?
(I know, it's not perfect, but with a little more design
thought it can probably come pretty close. For example,
code that might have to run on someone else's system, which
might not have the correct setting for integer division,
can use a sys.setIntegerDivision(1) call to force the
desired behaviour. Or does this have to be on a module-
by-module basis? Anyway, that's not my problem. :-)
So, O' BDFL, why not take the most Pythonic approach
and use a solution which *pragmatically* achieves a good
practical balance but which causes purists always to feel
a little uneasy and which can lead to perpetual discussion
about "warts" and why other languages are better and.... ;)
Greg Ewing
>
> It's a problem with expectations and the law of least astonishment.
> Which audience would you rather astonish, and how much?
Depends on what you understand "the problem" to
be. To me, it's the fact that I have to write
something ludicrously convoluted just to tell
Python what sort of division I want to do.
This has nothing to do with astonishment.
Grant Edwards
>Grant Edwards wrote:
>>
>> In article <mailman.994958301...@python.org>, pf...@mmm.com wrote:
>> >
>> >Is there really much code that depends on 1/3 == 0 being true?
>>
>> I regulary depend on integer division working the way it does.
>
>The point is whether there is any code which relies on
>polymorphically deciding between integer and float division at
>run time.
That may have been the point, but that wasn't what was asked.
>I find it very difficult to imagine what sort of application
>would *need* that.
Not many, but since Python isn't statically typed, it's a moot
point.
--
Grant Edwards grante Yow! ... I think I'm
at having an overnight
visi.com sensation right now!!
Dirck Blaskey
> Dirck Blaskey wrote:
> >
> > It's a problem with expectations and the law of least astonishment.
> > Which audience would you rather astonish, and how much?
>
> Depends on what you understand "the problem" to
> be. To me, it's the fact that I have to write
> something ludicrously convoluted just to tell
> Python what sort of division I want to do.
> This has nothing to do with astonishment.
The law of least astonishment:
A software program should always respond to
the user in the way that astonishes him the least.
It sounds like you find Python's integer division 'astonishing',
and yet I would be 'astonished' if it did anything else.
Therein lies the conundrum.
Guido van Rossum
> Unfortunately, while code a chemist writes is very likely never
> going to rely on the current integer division behaviour, code
> written by those of us in computers who tend to work closely
> with the hardware (where we are constantly thinking in terms
> of bytes, words, signed and unsigned, memory locations, bits
> and nybbles, etc.) will fairly often write code which depends
> on the current behaviour.
Ah, but you professional programmers can easily be trained. Just the
fact that you can already juggle all those concepts in your head means
that you won't have much trouble learning the additional fact that i/j
returns a float and that integer division must be spelled as i div j.
> I can't see a simple answer to this. It looks as though there
> are two camps, to both of whom it is absolutely essential that
> Python act in a specific way. And the two ways are completely
> incompatible.
No, that's not it.
The problem is that you have written much more Python code than the
chemists of the world, and if I were to change the language, you would
have to go through all that code to find out which slashes to replace
with 'div'.
> Doesn't that mean that the only solution that can be accepted
> without causing serious complications is to make the change,
> but clearly support a command line option (or some other
> configuration setting) to enable the current behaviour,
> so those who have depended on integer division can continue
> to run old code under the new engine without fear of
> breakage?
This has been said many times in other contexts: command line options
to change a particular behavior are evil. It would mean that library
modules could't depend on either behavior.
If we're going to give users a choice, it's going to be some kind of
per-module switch.
> (I know, it's not perfect, but with a little more design
> thought it can probably come pretty close. For example,
> code that might have to run on someone else's system, which
> might not have the correct setting for integer division,
> can use a sys.setIntegerDivision(1) call to force the
> desired behaviour. Or does this have to be on a module-
> by-module basis?
Yes, this has to be on a per-module basis.
> Anyway, that's not my problem. :-)
Yes it is! Unless we find a solution that *works* you will be
affected.
> So, O' BDFL, why not take the most Pythonic approach
> and use a solution which *pragmatically* achieves a good
> practical balance but which causes purists always to feel
> a little uneasy and which can lead to perpetual discussion
> about "warts" and why other languages are better and.... ;)
Believe me, I'm trying.
Fredrik Lundh
>
> Tom> I *always* forget the 1/3 == 0 thing between programming bursts.
> Tom> OTOH, I also quickly remember after making the mistake the first
> Tom> time.
>
> What is it that reminds you of the mistake? Is it something glaring like
> using the result of 1/3 as a divisor and getting a divide-by-zero error, or
> is it something more subtle like getting slightly incorrect results and
> having to dig through your code to find the problem?
depending on what you do, the results may not be just
"slightly" incorrect... :-)
(yes, I mess up on this several times each year. if you do
complex things, it's not always obvious that the real problem
is an integer division hidden somewhere in there)
</F>
phil hunt
>Peter Hansen <pe...@engcorp.com> writes:
>
>> Unfortunately, while code a chemist writes is very likely never
>> going to rely on the current integer division behaviour, code
>> written by those of us in computers who tend to work closely
>> with the hardware (where we are constantly thinking in terms
>> of bytes, words, signed and unsigned, memory locations, bits
>> and nybbles, etc.) will fairly often write code which depends
>> on the current behaviour.
>
>Ah, but you professional programmers can easily be trained. Just the
>fact that you can already juggle all those concepts in your head means
>that you won't have much trouble learning the additional fact that i/j
>returns a float and that integer division must be spelled as i div j.
Indeed we can easily learn that. However, we cannot easily go back
and fix all the old Python code that would become broken. I've
just done a quick check and there's 7200 lines of Python code
on my HD I've written. Of those, I use / 3 times. Twice require
integer division, and the other is clearly marked float(x)/y.
Assuming that's a good sample, one line in every 3600 of Python
code will have to be changed. So any change would likely cause
around 30 bugs in a 100,000 line Python program.
>> I can't see a simple answer to this. It looks as though there
>> are two camps, to both of whom it is absolutely essential that
>> Python act in a specific way. And the two ways are completely
>> incompatible.
>
>No, that's not it.
>
>The problem is that you have written much more Python code than the
>chemists of the world, and if I were to change the language, you would
>have to go through all that code to find out which slashes to replace
>with 'div'.
Indeed.
>This has been said many times in other contexts: command line options
>to change a particular behavior are evil. It would mean that library
>modules could't depend on either behavior.
>
>If we're going to give users a choice, it's going to be some kind of
>per-module switch.
Have you thought of forking the Python codebase for this and
any other more radical changes you propose? I for one would
like to see what sort of CP4E design you can come up with --
including case-insensitive identifiers, etc -- but such changes
couldn't be added to Python itself.
>> Anyway, that's not my problem. :-)
>
>Yes it is! Unless we find a solution that *works* you will be
>affected.
Consider forking the codebase. Keep the .pyc format, so the new
language will be link-compatible with the old one.
--
## Philip Hunt ## ph...@comuno.freeserve.co.uk ##
Peter Hansen
> > are two camps, to both of whom it is absolutely essential that
> > Python act in a specific way. And the two ways are completely
> > incompatible.
>
> No, that's not it.
>
> The problem is that you have written much more Python code than the
> chemists of the world, and if I were to change the language, you would
> have to go through all that code to find out which slashes to replace
> with 'div'.
Therein (perhaps) lies the sign for which path to take.
*I* would only have to make that change to code which I wanted
and needed to support under newer versions of Python.
Many programs would not need changing at all, as they would
just continue to run under older versions of Python. (Zope could
be frozen in time, capable of running only under Python 1.5.2,
were it not maintained.)
Maintained code can relatively easily be refactored to deal
with the new situation. This isn't rocket science, and
automated solutions that handle 95% of the cases could likely
be written. (If many people are concerned about the
potential code breakage, there must therefore be many
ready-made test cases for such a utility in the form of
their jeopardized code.)
Large, complex applications -- those for which the scan
would most likely miss some cases -- should have
sizable regression test suites which surely will catch
the remaining problems. If someone has such a program and
insists it "must" run under the newer Python, but does
not have a test suite, are you really going to try to keep
that person happy too?
> > Doesn't that mean that the only solution that can be accepted
> > without causing serious complications is to make the change,
> > but clearly support a command line option (or some other
> > configuration setting) to enable the current behaviour,
> > so those who have depended on integer division can continue
> > to run old code under the new engine without fear of
> > breakage?
>
> This has been said many times in other contexts: command line options
> to change a particular behavior are evil. It would mean that library
> modules could't depend on either behavior.
>
> If we're going to give users a choice, it's going to be some kind of
> per-module switch.
So in the transition period, a per-module switch is available. It
can be enabled globally in some way to apply either to old code
which knows nothing about this but which hasn't been fixed to account
for the change, or to new code which might require the new
behaviour. Make the new behaviour the (global) default, which is
something we "professional programmers" can live with provided we
have a convenient way (site.py, environment, what-have-you) of
disabling it for programs we know won't work or in environments
where we haven't had the time to do the full transition.
After the transition period, screw the professional programmers
who won't take the time to modify their existing code and yet
who selfishly insist that their wonderful program *must* be
allowed to continue running under the new Python without
problem.
I don't think this truly covers all the cases, but we have
to draw the line somewhere. Maybe before the gavel drops
on this one, we can develop the proposed "div-scan" utility
and test it out for those of us most concerned. After it
has been proven in the field, we go ahead and break things
and take our lumps for a while. Things settle down, the
problem fades into history, and c.l.p swarms with happy
newbies. :-)
> > Anyway, that's not my problem. :-)
>
> Yes it is! Unless we find a solution that *works* you will be
> affected.
Well, quite true. If I'd been thinking better, I might have
said "this is not really a problem in my particular case,
because my code base is small enough and we are new enough
to Python that we can bite the bullet and scan/fix all
several hundred modules we have written. Not the end of the
world for me, but not exactly nice to rub it in anyone else's
face. Apologies.
As you said, we are professional programmers: we have to do this
kind of thing all the time in other environments, especially
to deal with API changes by the large-evil-software-manufacturing
empire-which-must-not-be-named. We regularly upgrade
C compilers for embedded systems, for example, in a never-ending
and usually unsuccessful attempt to get away from the bugs
of one version but we always encounter new bugs and have
code breakage etc. as a result. We live with it. If it really
bothered us, we wouldn't upgrade. Same solution works here.
It really isn't the end of the world, and I think many of us,
(I'm sure I don't speak for all, however) can agree with the
basic premise ("least astonishment") that the current behaviour
is overly surprising to newcomers, etc., therefore likely to
dilute the potential user base, etc., and therefore overall a
negative thing to the strength of the Python movement,
and therefore likely over the long term to negatively impact
the value of Python to us.
(Those who disagree with that would perhaps need to explain
why, if they aren't really interested in the benefits that
continued expansion of the Python user base brings to the table,
they however insist they cannot just freeze their environment
with the current version of Python and therefore not be
affected by this change in any way. If you *have* to upgrade
but you *won't* maintain your code, maybe you're just being
selfish. (Flame bait, but controversial statements
can bring out some worthwhile points of view... :)
> > So, O' BDFL, why not take the most Pythonic approach
> > and use a solution which *pragmatically* achieves a good
> > practical balance but which causes purists always to feel
> > a little uneasy and which can lead to perpetual discussion
> > about "warts" and why other languages are better and.... ;)
>
> Believe me, I'm trying.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
Clearly you are trying, hard. And believe me, we appreciate it
immensely. I'm trying too... :)
Tim Churches
>
> Guido van Rossum wrote:
-----8<----snip---------
[ discussion of ways of preventing changes to Python breaking existing
code ]
-----8<----snip---------
I'm just about to head off to a 1 week statistics workshop in which the
Stata package (see http://www.stata.org) will be used for teaching, so I
thought I had better crack open the Stata manual...
Although Stata is a proprietary, closed source package, Stata Corp. has
actively encouraged end users to write their own extensions to Stata
using the Stata scripting language (about which the less said the
better...), so there is a large body of work written using various
versions of Stata from 1.0 to 7.0 (in 0.2 or 0.5 version increments, it
seems). Stata Corp actively distributes these extensions via a built-in
download facility or via CD-ROMs.
The first thing which caught my eye in the manual was the "version"
statement. This statement modifies the behaviour of Stata to mimic the
specified version, thus allowing old scripts to run unchanged under new
versions. Not only that, it does so at run-time, allowing old and new
code to be combined, such as, in a single script:
version 2.1 /* emulate Stata 2.1 */
...assorted old Stata code....
version 6.5 /* emulate Stata 6.5 */
...newer code...
version 7.0 /* revert to current version behaviour */
...code to take advantage of latest changes to syntax...
This behaviour modification seems to extend not just to the Stata
kernel, in which the core syntax is defined, but also to Stata
libraries, so that if you specify "Version 2.1" you even get the old
style random number generator instead of the better one introduced in a
later version.
This seems like both an excellent solution and a very neat trick. Having
never looked into the bowels of the Python bytecode compiler or VM, I
have no idea whether such a thing would be feasible, but it is an
attractive idea, at least superficially. It appears to have worked well
for Stata.
Tim C
Sydney, Australia
Guido van Rossum
transitioning):
> After the transition period, screw the professional programmers
> who won't take the time to modify their existing code and yet
> who selfishly insist that their wonderful program *must* be
> allowed to continue running under the new Python without
> problem.
Well, I don't know about you, but *I* am reluctant to say "screw you"
to all those people who depend on Python script written by
professional programmers who no longer work there.
I also don't want to fork the code base. There are *still* folks
using Perl4 scripts who can't upgrade. I don't want to do that to the
community.
So indeed, we'll need to be *very* careful with this kind of
transition, providing tools, warnings, anything we can think of.
Guido van Rossum
> version 2.1 /* emulate Stata 2.1 */
> ...assorted old Stata code....
> version 6.5 /* emulate Stata 6.5 */
> ...newer code...
> version 7.0 /* revert to current version behaviour */
> ...code to take advantage of latest changes to syntax...
I have no doubt that we *could* implement this. It would be fine to
only accept one version statement per module, as long as modules using
different versions could be used together. The __future__ statement
does this.
But it's butt-ugly, and encourages keeping unmaintained code around.
It also becomes a burden on the programmer, who has to maintain all
this cruft and has to keep old manuals around etc.
I find it a last resort. The nice thing about __future__ statements
is that eventually you will be able to take them out, unlike version
statements.
Peter Hansen
>
> Peter Hansen <pe...@engcorp.com> writes (after much good stuff about
> transitioning):
>
> > After the transition period, screw the professional programmers
> > who won't take the time to modify their existing code and yet
> > who selfishly insist that their wonderful program *must* be
> > allowed to continue running under the new Python without
> > problem.
>
> Well, I don't know about you, but *I* am reluctant to say "screw you"
> to all those people who depend on Python script written by
> professional programmers who no longer work there.
"Screw you" might have been a little strong. (And for those just
joining, I _am_ one of those professional programmers about which
I was making the suggestion...)
Nevertheless, I want to make the clear point (if I haven't already)
that I'm not suggesting screwing every such programmer... just
those who are actively using code which would be broken, who will
not take the time (however small we might make it) to modify the
source, and yet who "must" have their code work under the new Python.
Are there really any people like that? Enough to make it
a key factor? I'm not sure I can even think of any realistic
cases where anyone like that exists (he said, trolling for
someone to point out an obvious example or two).
I thought all the rpm stuff from RedHat might be an example. But
it runs with its own 1.5.2 installation, as far as I can tell.
No obvious problem there.
There are all those users (presumably) who are using Python code
somewhere but don't even realize it. They most likely aren't going
to be the sort to upgrade their installation any time soon, so their
environment is secure.
There are us types using Python in commercial/industrial
environments. Probably we suffer the biggest impact for
several reasons, and yet we are also in the best position to
cope with the damage (most resources, typically much newer
to Python than the scientific community, probably actively
maintaining our code already, most likely aware of this issue
and maybe directly involved).
There's the lot of us active in c.l.p, but we know about the
change, have access to the tools, have participated in the
preparation phase, and have taken the time to be ready before
the change even hits (that is, before the _end_ of the transition
period during which code breakage doesn't happen).
What other classes of users have I missed? One of the first
steps in requirements engineering is to identify use cases,
which requires understanding the various user roles involved.
Let's just finish defining the types of users, analyze each
one in terms of risk (probability of impact, extent of impact,
quantity of users involved), possible mitigating steps (warnings,
tools, etc.), and perhaps contingency plans.
> I also don't want to fork the code base. There are *still* folks
> using Perl4 scripts who can't upgrade. I don't want to do that to the
> community.
Maybe this can be a practical example of how much more maintainable
Python code is than Perl code. I can't imagine anyone suggesting
that people using Perl scripts should go through all their source
(or someone else's) and change it to make it compatible with the
latest Perl. I actually *can* imagine suggesting that seriously
in the case of Python code. (Forget imagination, I *am* suggesting
it!)
> So indeed, we'll need to be *very* careful with this kind of
> transition, providing tools, warnings, anything we can think of.
>
> --Guido van Rossum (home page: http://www.python.org/~guido/)
--
phil hunt
>Peter Hansen <pe...@engcorp.com> writes (after much good stuff about
>transitioning):
>
>> After the transition period, screw the professional programmers
>> who won't take the time to modify their existing code and yet
>> who selfishly insist that their wonderful program *must* be
>> allowed to continue running under the new Python without
>> problem.
>
>Well, I don't know about you, but *I* am reluctant to say "screw you"
>to all those people who depend on Python script written by
>professional programmers who no longer work there.
>
>I also don't want to fork the code base.
Does that imply that you sare no longer interested in making
radical changes to Python, such as case-insensitive identifiers
mentioned in CP4E?
>There are *still* folks
>using Perl4 scripts who can't upgrade.
Sure they can, they can upgrade to python :-)
Bjorn Pettersen
>
> Guido van Rossum wrote:
> >
> > Peter Hansen <pe...@engcorp.com> writes (after much good stuff about
> > transitioning):
> >
> > > After the transition period, screw the professional programmers
> > > who won't take the time to modify their existing code and yet
> > > who selfishly insist that their wonderful program *must* be
> > > allowed to continue running under the new Python without
> > > problem.
> >
> > Well, I don't know about you, but *I* am reluctant to say
> "screw you"
> > to all those people who depend on Python script written by
> > professional programmers who no longer work there.
>
> joining, I _am_ one of those professional programmers about which
> I was making the suggestion...)
>
> Nevertheless, I want to make the clear point (if I haven't already)
> that I'm not suggesting screwing every such programmer... just
> those who are actively using code which would be broken, who will
> not take the time (however small we might make it) to modify the
> source, and yet who "must" have their code work under the new Python.
>
> Are there really any people like that? Enough to make it
> a key factor? I'm not sure I can even think of any realistic
> cases where anyone like that exists (he said, trolling for
> someone to point out an obvious example or two).
Well, I for one wrote several thousands of lines of Python code in my
last job, and I obviously have no influence on when they're going to
upgrade to a newer version of Python. You can probably safely assume
that they're not going to put a programmer on fixing programs that are
running without any problems. More likely they would upgrade Python,
realize that "a bunch" of Python scripts stopped working, and either
roll back the Python upgrade, rewrite them in Perl/Java, or find someone
with enough Python skills to fix the problems. Neither solution would be
good PR for Python...
-- bjorn
Bjorn Pettersen
> >
[snip]
> >
> > Well, I for one wrote several thousands of lines of Python
> code in my
> > last job, and I obviously have no influence on when they're going to
> > upgrade to a newer version of Python. You can probably safely assume
> > that they're not going to put a programmer on fixing
> programs that are
> > running without any problems. More likely they would upgrade Python,
> > realize that "a bunch" of Python scripts stopped working, and either
> > roll back the Python upgrade, rewrite them in Perl/Java, or
> find someone
> > with enough Python skills to fix the problems. Neither
> solution would be
> > good PR for Python...
>
> is having division which doesn't behave as newcomers expect.
> We're trying to choose the lesser of two evils.
Yes, we're chosing between people who currently doesn't use Python (but
might in the future), and people who have significant investments in
Python...
> Anyway, if your previous employer upgrades Python for no good
> reason and without checking the Change History where they will
> see all the warnings in BIG PRINT about how existing code might
> break and that they should run "divscan.py" to see if their code
> is safe or not, how can we protect them against themselves?
What if they change because some package they use is no longer supported
with the older version (or has a bugfix that isn't backported, etc.)? In
theory it's always possible to remain with an earlier version, but in
practice it ain't always so <wink>.
"divscan.py" would be a good idea, but since Python is a dynamic
language, all it could do would be to point out all occurrences of
division in your code. You would still have to manually examine each and
every one of them to figure out whether it needed change or not...
> I'm trying to point out that this kind of hypothetical example,
> where some group might upgrade (but not be aware of this issue
> even after lengthy publicity during the transition period)
> even though they will not actively maintain their code, is
> not likely, or not worth worrying about for long.
I would hardly call it hypothetical. I'm sure a lot of companies are in
this boat, and most probably don't read c.l.py (the volume is just too
great). The first warning they're probably going to get that a new
version of Python is available is when they call the developer of foo.py
with a problem and he says: "yeah, that's fixed in the latest version --
but it requires Python 2.x". Besides, a minor point change would in most
context indicate minor, source-compatible changes only.
> And that's where the contingency plans come into play: we've
> provided adequate notice, tools, etc., and yet somebody chose
> to ignore us and got punished. Big deal.
Getting Python accepted in an organization as a viable alternative to
Perl requires a lot of hard work. Once you've got a foothold it seems
stupid to shoot yourself in the foot by introducing random
incompatibilities that may or may not provide better traction for
non-users (not to mention the hackish solutions to long division that
would be introduced).
I'm not against making this change per se, however, I think it should be
in the context of an overhaul of the entire numerical system, and it
definitely deserves a 3.0 labelling since that would indicate that there
are incompatible changes involved with upgrading.
-- bjorn
Peter Hansen
> > that I'm not suggesting screwing every such programmer... just
> > those who are actively using code which would be broken, who will
> > not take the time (however small we might make it) to modify the
> > source, and yet who "must" have their code work under the new Python.
> >
> > Are there really any people like that? Enough to make it
> > a key factor? I'm not sure I can even think of any realistic
> > cases where anyone like that exists (he said, trolling for
> > someone to point out an obvious example or two).
>
> last job, and I obviously have no influence on when they're going to
> upgrade to a newer version of Python. You can probably safely assume
> that they're not going to put a programmer on fixing programs that are
> running without any problems. More likely they would upgrade Python,
> realize that "a bunch" of Python scripts stopped working, and either
> roll back the Python upgrade, rewrite them in Perl/Java, or find someone
> with enough Python skills to fix the problems. Neither solution would be
> good PR for Python...
I agree it wouldn't be good PR for Python, but presumably neither
is having division which doesn't behave as newcomers expect.
We're trying to choose the lesser of two evils.
Anyway, if your previous employer upgrades Python for no good
reason and without checking the Change History where they will
see all the warnings in BIG PRINT about how existing code might
break and that they should run "divscan.py" to see if their code
is safe or not, how can we protect them against themselves?
I'm trying to point out that this kind of hypothetical example,
where some group might upgrade (but not be aware of this issue
even after lengthy publicity during the transition period)
even though they will not actively maintain their code, is
not likely, or not worth worrying about for long.
And that's where the contingency plans come into play: we've
provided adequate notice, tools, etc., and yet somebody chose
to ignore us and got punished. Big deal.
-Peter Hansen
Guido van Rossum
> >I also don't want to fork the code base.
>
> Does that imply that you sare no longer interested in making
> radical changes to Python, such as case-insensitive identifiers
> mentioned in CP4E?
I still have the same end goal, but I believe there must be a way to
obtain it without too much disturbance. Case-sensitivity, for
example, may be a tool feature rather than a language feature, or it
may be a user option or a langage-level choice. (Not that I've
figured out exactly how to do this, but TeachScheme makes this an
option.) Note that case-sensitivity is also controversial: the Alice
folks found it a problem, but the VPython folks have not confirmed
this (while they did confirm the integer division trap).
Nick Efford
Bjorn Pettersen <BPett...@NAREX.com> wrote:
> Getting Python accepted in an organization as a viable alternative to
> Perl requires a lot of hard work. Once you've got a foothold it seems
> stupid to shoot yourself in the foot by introducing random
> incompatibilities that may or may not provide better traction for
> non-users (not to mention the hackish solutions to long division that
> would be introduced).
IIRC, aren't Perl-ers contemplating incompatibilities of
a similar degree for Perl 6? (albeit with some kind of
automated Perl 5 --> 6 conversion tool provided to ease
the transition...)
> I'm not against making this change per se, however, I think it should be
> in the context of an overhaul of the entire numerical system, and it
> definitely deserves a 3.0 labelling since that would indicate that there
> are incompatible changes involved with upgrading.
Yes - I also like the idea of using a 3.0 version number
to signal the importance of these changes.
Nick
Peter Hansen
>
> On Mon, 16 Jul 2001 10:48:42 -0600,
> Bjorn Pettersen <BPett...@NAREX.com> wrote:
>
> > Getting Python accepted in an organization as a viable alternative to
> > Perl requires a lot of hard work. Once you've got a foothold it seems
> > stupid to shoot yourself in the foot by introducing random
> > incompatibilities that may or may not provide better traction for
> > non-users (not to mention the hackish solutions to long division that
> > would be introduced).
>
> IIRC, aren't Perl-ers contemplating incompatibilities of
> a similar degree for Perl 6? (albeit with some kind of
> automated Perl 5 --> 6 conversion tool provided to ease
> the transition...)
I would think that even with Python's dynamic nature, it would
be possible to make a "Pareto scanner" which would uncover
80% of the possible problems with 20% of the work it would
take to make something more sophisticated. I think "divscan.py"
could work...
> > I'm not against making this change per se, however, I think it should be
> > in the context of an overhaul of the entire numerical system, and it
> > definitely deserves a 3.0 labelling since that would indicate that there
> > are incompatible changes involved with upgrading.
>
> Yes - I also like the idea of using a 3.0 version number
> to signal the importance of these changes.
That would be the point of a transition period, I think. Starting
in the near future there would be support for the new style of
division (future statement?) which would be optionally enabled
for new code. Later on, when all the real work has been done,
version 3.0 would be released: this would be the first version
actually to *break* code, not the 2.3 or whatever release...
Roman Suzi
Probably, case{non,}sensitive and integer/fp division are the same analogy
as simple vs. engineer/scientific vs. programmable calculator (we recently
discussed in the other c.l.p thread: "Re: Bug in __imul__").
Python is in no way simple calculator ;-) It is in the "programmable"
category for sure.
Then it must be real programming language. So the beginners
will join real programming. Not just some funny Logo. ;-)
imul vs. fmul aren't necessary example here, but case sensitivity is.
I noted that Alice is Windows-only project and their view could
be narrowed.
Windows is case-insensitive and thus "easy to use" only before one needs
to put web-pages on the real (UNIX) web-server. Then they understand all
the troubles with mised case, national-charset filenames, abbr~ted
filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
So, certain degree of wisdom must be preserved. CP4E is not
"dumb P to nothing and it will be 4E".
If the product has internal integrity thus inherent simplicity it is
simpler than the product which ADDS something for "easy of use"
to hairly and underthought core.
Easiness/complexity must match problems under solution. DNS is complex
because NS is overly complex system. So, attempts to build better BIND
failed so far, because NS *is* BIND ;-)
Python is externally and internally simple and does not do special hook
for "easy of use". Lets leave it simple and coherent.
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:r...@onego.ru -
Guido van Rossum
> Windows is case-insensitive and thus "easy to use" only before one needs
> to put web-pages on the real (UNIX) web-server. Then they understand all
> the troubles with mised case, national-charset filenames, abbr~ted
> filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
But it's still open for debate whether the problem here is Windows or
Unix! All programming languages and file systems used to be
case-insensitive, until the designers of Unix and C decided that it
was too much work to write and use a case-insensitive comparison
routine. It wasn't necessarily intended to be better, just easier to
implement. But times have changed, and that's a lousy excuse.
Steve Holden
news:cpvgkq1...@cj20424-a.reston1.va.home.com...
which is what Windows NT ended up being. I would rather have a
case-sensitive filesystem, properly implemented, than the mess you get with
Posix primitives layered on top of a rather poorly-implemented
case-insensitive filesystem. Using Posix utilities it is possible under NT
4.0 to have two files with the "same" name, but (of course) then impossible
to use native NT files to say which file you want to read!
In the CP4E world, do you feel it is better to educate everybody to
understand that capitaisation has meaning, or dumb down the systems to allow
those without a finer appreciation of language to get what *they* expect,
thereby annoying the literate minority? I've never been quite sure how
inclusive the "E" in "CP4E" is intended to be, but you may find that spoken
natural language is the only acceptable user interface, given the literacy
problems of even "advanced" societies. Now, even I couldn't disagree that
there's no upper case spoken language, unless it's the traditional British
device of
S-H-O-U-T-I-N-G S-L-O-W-L-Y A-T F-O-R-E-I-G-N-E-R-S
which-i-wouldn't-even-do-about-print->>-ly y'rs - steve
--
http://www.holdenweb.com/
Alex Martelli
news:_bh57.32695$d4.10...@e420r-atl1.usenetserver.com...
...
> In the CP4E world, do you feel it is better to educate everybody to
> understand that capitaisation has meaning, or dumb down the systems to
allow
> those without a finer appreciation of language to get what *they* expect,
> thereby annoying the literate minority? I've never been quite sure how
I consider myself a member of the literate minority (well
within the upper centile on all relevant demographics), and
having a recently-invented typographic prettiness, such as
letter-cd tcase, affect meaning, has always struck me as a deeply
flawed idea. I hated it when I first met it in C and Unix,
and a quarter of a century hasn't reconciled me to it.
Alex
Bengt Richter
Are you sure that was the reason? I would have guessed that at a transition
from ALL UPPERCASE ASSEMBLY LANGUAGE PROGRAMMING they would have said to
themselves, "Let's not deny programmers the use of 7-bit distinctions, now
that we have 7-bit characters."
If you want to cater to windows case insensitivity, maybe W"do it like this"
-- but please don't even think about eliminating case sensitivity from Python ;-)
Roman Suzi
>"Guido van Rossum" <gu...@python.org> wrote in message
>news:cpvgkq1...@cj20424-a.reston1.va.home.com...
>> Roman Suzi <r...@onego.ru> writes:
>>
>> > Windows is case-insensitive and thus "easy to use" only before one needs
>> > to put web-pages on the real (UNIX) web-server. Then they understand all
>> > the troubles with mised case, national-charset filenames, abbr~ted
>> > filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
>>
>> But it's still open for debate whether the problem here is Windows or
>> Unix! All programming languages and file systems used to be
>> case-insensitive, until the designers of Unix and C decided that it
>> was too much work to write and use a case-insensitive comparison
>> routine. It wasn't necessarily intended to be better, just easier to
>> implement. But times have changed, and that's a lousy excuse.
Maybe case-sensitiveness is an atavism, but I think that the Man and the
man are too _different_ words. And MAN is yet another. Case-sensitivity is
simple. Having one 0x0A is also simpler than 0x0A 0xD and thus having two
different file types. Unix is simpler, that is why it survived for so
long.
>In the CP4E world, do you feel it is better to educate everybody to
>understand that capitaisation has meaning, or dumb down the systems to allow
>those without a finer appreciation of language to get what *they* expect,
>thereby annoying the literate minority? I've never been quite sure how
>inclusive the "E" in "CP4E" is intended to be, but you may find that spoken
>natural language is the only acceptable user interface, given the literacy
Even spoken language will not help, because people just plainly do not
know how things are called even on their GUI systems. They hardly know
what OS is and they talk strictly about what they see, without
understanding of underlying processes. More than that, many 'puter users
are lame enough not to learn things! (believe me, I am working at
ISP tech. support...)
So probably CP4E is Utopia or "E" != humankind, but some part of it.
And thus there is no need to make thing too complex in trying to do them
simple. I think that CP is for everyone who is open to learn things as
they are, without overly simplification or complication.
If I give variable name 'Name', then I mean to call it so. And I will not
be disappointed when I try to call it by 'name' and it will not answer.
These are basic things even from pre-Eve times, when Adam called things.
>problems of even "advanced" societies. Now, even I couldn't disagree that
>there's no upper case spoken language, unless it's the traditional British
>device of
>
> S-H-O-U-T-I-N-G S-L-O-W-L-Y A-T F-O-R-E-I-G-N-E-R-S
There are no spoken language IDEs yet. And if I am not mistaken, there
will never be. Because it is much simpler to program more or
less complex things with written language.
Spoken command language could be of use with some AI systems or simple
systems which know some set of prescribed commands. Otherwise, it is too
easy for computer to give patients metil. when the doctor wanted etil.
Sincerely yours, Roman Suzi
--
_/ Russia _/ Karelia _/ Petrozavodsk _/ r...@onego.ru _/
_/ Wednesday, July 18, 2001 _/ Powered by Linux RedHat 6.2 _/
_/ "Hard work never killed anyone, but why chance it?" _/
Erik Max Francis
> I consider myself a member of the literate minority (well
> within the upper centile on all relevant demographics), and
> having a recently-invented typographic prettiness, such as
> letter-cd tcase, affect meaning, has always struck me as a deeply
> flawed idea. I hated it when I first met it in C and Unix,
> and a quarter of a century hasn't reconciled me to it.
Makes perfect sense to me. What's the point of having differing
capitalization if it isn't meaningful?
Otherwise every programmer can use their own capitalization for each
identifier, which is just confusing.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ When the solution is simple, God is answering.
\__/ Albert Einstein
Computer science / http://www.alcyone.com/max/reference/compsci/
A computer science reference.
Michael Chermside
> > Windows is case-insensitive and thus "easy to use" only before one needs
> > to put web-pages on the real (UNIX) web-server. Then they understand all
> > the troubles with mised case, national-charset filenames, abbr~ted
> > filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
GvR:
> But it's still open for debate whether the problem here is Windows or
> Unix!
>
I'm very surprised to hear this. Yes, I've taught lots of beginners, and
I've found that they often complain about the case sensitivity. But I
tell them that "Computers are EXTREMELY literal", and "you must be VERY
precise when programming", and they get it. I also get complaints (not
so many) about the computer not understanding a mis-spelled system call.
It seems to me that whether the language requires case sensitivity or
not, it is still very poor style to vary the capitalization of a given
identifier. It's kind of like indentation... and (in Pascal, C, Basic,
and other non-Python languages) I mark my student's programs WRONG if
they don't use consistant indenting.
Don't encourage sloppy habits: require case sensitivity.
Besides... if you make identifiers NOT case sensitive, then when they
try opening files or URLs and find that those ARE... they'll REALLY
have problems.
-- Michael Chermside
Konrad Hinsen
> case-insensitive, until the designers of Unix and C decided that it
> was too much work to write and use a case-insensitive comparison
> routine. It wasn't necessarily intended to be better, just easier to
> implement. But times have changed, and that's a lousy excuse.
Whatever the original reason was, many people have put case
sensitivity to good use for implementing naming conventions. For
example, I find it useful in my Python code to capitalize class names
(and nothing else), and then use a lower-case name otherwise identical
to a class name to indicate the expected type of a parameter to a
function.
If computing were to start from scratch, I'd perhaps favour a
case-insensitive approach everywhere. But I can't say I ever had a
problem with case sensitivity.
Konrad.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hin...@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------
phil hunt
>ph...@comuno.freeserve.co.uk (phil hunt) writes:
>
>> >I also don't want to fork the code base.
>>
>> Does that imply that you sare no longer interested in making
>> radical changes to Python, such as case-insensitive identifiers
>> mentioned in CP4E?
>
>I still have the same end goal, but I believe there must be a way to
>obtain it without too much disturbance.
Hmmm. I'm not sure about that, it feels to me like its opening up a
can of worms.
>Case-sensitivity, for
>example, may be a tool feature rather than a language feature, or it
>may be a user option or a langage-level choice.
Say I write a module in the current (case-sensitive) Python. Then
you write one in case-insensitive python. Your code calls one of my
routines or variables; how does it get the case-sensitivity right?
Does it do so at run time or compile time? Compile time might
be difficult, for example if I have an object that dynamically
creates instance variables for itself. What if I have an object
ob with both ob.variable and ob.VARIABLE? What does your code
use when it resolves philsModule.ob.variable?
Case matching up at run-time is likely to make the language slower.
(One way I might consider fixing it would be to have the new
language explicitly say when it is dealing with old-python modules
and be case sensitive there; consider C++'s name mangling and the
extern keyword they used to link to C code.)
> (Not that I've
>figured out exactly how to do this, but TeachScheme makes this an
>option.) Note that case-sensitivity is also controversial: the Alice
>folks found it a problem, but the VPython folks have not confirmed
>this (while they did confirm the integer division trap).
Who are the Alice people?
--
#===== Philip Hunt == ph...@comuno.freeserve.co.uk ======#
Herbivore: effort-free public key encryption. See:
<http://www.vision25.demon.co.uk/oss/herbivore/intro.html>
** First software release coming soon! **
phil hunt
One question that's just occurred to me.
In normal Python:
class C: pass
c = C()
c.__dict__['h'] = 'hello'
Now, c.h is 'hello' but c.H is an exception.
Will keys in dictionaries have to be case-insensitive in
cae-insensitive python?
Grant Edwards
>Alex Martelli wrote:
>
>> I consider myself a member of the literate minority (well
>> within the upper centile on all relevant demographics), and
>> having a recently-invented typographic prettiness, such as
>> letter-cd tcase, affect meaning, has always struck me as a deeply
>> flawed idea.
Seems quite intuitive to me. When I was learning to write
English, incorrect case was considered a spelling error just
like using the wrong letter. Having a computer language act
that way makes sense to me.
>> I hated it when I first met it in C and Unix,
>> and a quarter of a century hasn't reconciled me to it.
>
>Makes perfect sense to me. What's the point of having
>differing capitalization if it isn't meaningful?
>
>Otherwise every programmer can use their own capitalization for
>each identifier, which is just confusing.
I think using inconsistent case for identifiers should be
considered an error whether or not the compiler cares about it.
--
Grant Edwards grante Yow! If elected, Zippy
at pledges to each and every
visi.com American a 55-year-old
houseboy...
Steve Lamb
>All programming languages and file systems used to be case-insensitive, until
>the designers of Unix and C decided that it was too much work to write and
>use a case-insensitive comparison routine. It wasn't necessarily intended to
>be better, just easier to implement. But times have changed, and that's a
>lousy excuse.
Eh, preference is for case sensitivity. Besides, I far prefer case
sensitivity with tab completion than case insensitivity without. :)
--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
ICQ: 5107343 | main connection to the switchboard of souls.
To email: Don't despair! | -- Lenny Nero, Strange Days
-------------------------------+---------------------------------------------
Bruce Sass
[Ok, I'll bite]
I don't see either Windows or Unix as the problem, they are just
different. Problems only arise when you try to move between the two
possible worlds without a mapping function.
Mapping from Windows to Unix is trivial because case-insensitivity is
a subset of case-sensitivity; mapping from Unix to Windows with the
same 1:1 rule is impossible for the same reason... so you need a more
complicated mapping function, and will end up with a longer string of
characters in the Windows world than in the Unix world. In the
very least, case-sensitive Unix can convey information more succinctly
than case-insensitive Windows, and I would go so far to say that Unix
is more expressive than Windows in this aspect.
I don't think the question is "whether the problem here is Windows or
Unix!", but rather...
Would a less expressive programming environment be better for programs
or programmers?
or if you prefer...
Would restricting program text to a subset of the available symbols be
better for programs or programmers?
The way I see it, going case-insensitive would be like ripping the
"shift" key out of the keyboard... such a move would not even be
considered in the real world; since programming is an effort to
simulate what goes on in the real world, and it seems to have been
found to take more than 36 symbols and some punctuation to express
real world ideas, it seems counter-productive to artificially restrict
the expressiveness of programmers.
Someone who has trouble figuring out case-sensitivity is going to have
a hard time with programming <period>. If such a person is looking at
programming it will be within a restricted domain, so there should be
a language tailored to that audience and that domain. Languages
intended for wider domains should be as expressive as the natural
language used to describe them. There is nothing stopping a small
domain language from being a subset of that used in a larger domain,
but the requirements of the subset should not limit the expressiveness
of the whole language.
Exposing Python to a non-programmer, so the non-programmer can (say)
program their cell phone, does not require any aspect of Python be
designed to make things easy for the non-programmer... all that is
required is that a subset of Python can be made to appear to be
non-programmer friendly.
Maybe PyChecker should grow an option to check for mixed case
labels in programs, or perhaps rexec should be able to force
case-insensitivity.
- Bruce
Alex Martelli
news:mailman.995479471...@python.org...
...
> I'm very surprised to hear this. Yes, I've taught lots of beginners, and
> I've found that they often complain about the case sensitivity. But I
> tell them that "Computers are EXTREMELY literal", and "you must be VERY
> precise when programming", and they get it. I also get complaints (not
I guess you're lucky that your beginners don't have a smattering of
Pascal or DOS, or other case-insensitive computers and programming
environments, or they'd challenge your generalization. Of course you
must be very precise when programming in Pascal, say, but that
precision doesn't have to be artificially extended to case sensitivity.
> Don't encourage sloppy habits: require case sensitivity.
First time I heard that Pascal "encourages sloppy habits" -- with all
the valid criticisms one can level at it, this one seems ridiculous.
Alex
John W. Baxter
Rossum <gu...@python.org> wrote:
Well, let's see. The first machines I used didn't have a case problem:
they only had upper case. Is that case sensitive or case insensitive?
[They also had identifiers of 3 or fewer characters.]
Then I used some machines with upper and lower case, which were case
sensitive in the language processors I used (favoring lower case).
For that matter, they didn't have a file naming problem...they didn't
use file names.
Times do change.
I happen to prefer case-sensitive languages (that could be the only
aspect of C that I prefer to the related aspect of the Pascals I
used...which had reacted to the advent of readily available lower case
in mid-life by being case insensitive).
So I think Python is currently right in this area, but it isn't
important enough to me to cause me to stop upgrading Python versions
when it changes. Or argue about.
[The direction the Unicode source threads are taking might well, but we
still have the BDFL (or bdfl, or bDFL, or bDFl ...) to conrol that...I
hope.]
I also hope that after the change to case-insensitive Python, we don't
also go through a change to diacriticals-don't-matter Python.
--John
Neil Hodgson
> I also hope that after the change to case-insensitive Python,
> we don't also go through a change to diacriticals-don't-matter
> Python.
I'm hoping we can move to vowel-insensitive Python to increase ease of
use in Hebrew. And allow for non-deterministic pronunciation of g*d.
Neil
Delaney, Timothy
> before one needs
> > to put web-pages on the real (UNIX) web-server. Then they
> understand all
> > the troubles with mised case, national-charset filenames, abbr~ted
> > filenames, local file references "C:\Mydocs\lalala", bmp-images etc.
>
> But it's still open for debate whether the problem here is Windows or
> Unix! All programming languages and file systems used to be
> case-insensitive, until the designers of Unix and C decided that it
> was too much work to write and use a case-insensitive comparison
> routine. It wasn't necessarily intended to be better, just easier to
> implement. But times have changed, and that's a lousy excuse.
>
This is very true. I grew up with Apple IIs and Macintoshes.
Case-insensitive but case-preserving file systems work (IMO) very well.
However, I *also* like case-sensitive file systems. I do *not* like
Case-insensitive, non-preserving filesystems - that's just plain wrong.
However, what is applicable to filesystems is not necessarily applicable to
programming.
I know I personally prefer having the discipline of case-sensitivity forced
on me by the language. When I see a function call (for example), it is the
same in every situation.
With case-insensitive languages, you either need the editor to enforce
case-sensitivity or you need to force everyone on the team to enforce it.
Look at (yuk) VB (why do I keep using this as an example? Probably because
it's one of the worst languages I've ever seen). *Keywords* are written in
different case in different sources. Every time I look at
For Each foo In far
Next
I need to mentally translate that to my version of
for each foo in bar
next
and likewise, people who like the former need to translate my code.
Python follows "there should be one (obvious) way to do it". Most of all, I
think this should apply to the syntax. All Python code should have a similar
look. IMO the most important aspect of this is case.
Tim Delaney
Arthur Siegel
>example, may be a tool feature rather than a language feature, or it
>figured out exactly how to do this, but TeachScheme makes this an
>option.) Note that case-sensitivity is also controversial: the Alice
>folks found it a problem, but the VPython folks have not confirmed
>this (while they did confirm the integer division trap).
But it should be noted, in fairness, that neither the Alice or
VPython anecdotals were made in the context of
teaching programming.
VPython's (of which I happen to be a fan) findings were in the
context of a class in physics.
I don't recall hearing either issue raised by anyone using
Python to teach or to learn programming concepts.
There have been a number of reports from learning novices -
including my own - that the issues are, in context, negligible.
Difficult for someone in my position to ignore the hand in
front of my face.
Guido's more recent post at least gives some insight into his
deeper thinking.
Seems to me many of us would agree that we prefer
a language with a minimum of affection.
Many of us feel, I believe, that case insensitivity is such
an affection. Guido seems to be saying that he views it
otherwise - that it is case sensitivity that is an affect.
Which to me is the beginning of a real discussion.
Not meaning to be nasty at all, but these issues have
been on the table for quite some time - and I do think
it a tactical error to try to trump deeper discussion
by pointing to selective anecdotal reports from
near random sources, taken out of any meaningful
context, that happen to support a predilection.
Sorry to harp.
ART
Steven D. Majewski
On Wed, 18 Jul 2001, Guido van Rossum wrote:
> But it's still open for debate whether the problem here is Windows or
> Unix! All programming languages and file systems used to be
> case-insensitive, until the designers of Unix and C decided that it
> was too much work to write and use a case-insensitive comparison
> routine. It wasn't necessarily intended to be better, just easier to
> implement. But times have changed, and that's a lousy excuse.
Now that we're in a new century, I think it's time to update to a
new excuse! How about:
Now that everyone's making the transition to multiple language support,
unicode and multiple encodings, how to you portably define/implement
case-insensitive comparison?
-- sdm
Peter Hansen
I'm greatly bothered by language-sensitive Python. I'd much
prefer using my native Esperanto, for example, in place of the
cryptic (to newbies) English-language keywords.
Since some newcomers to the language (like, say, most of the
population of the planet) might not understand the keywords
as they are or why they don't work in a more "logical"
language (i.e. the newbie's own), we should change Python to
support any language (including a mixture, for polyglots).
Luckily, the proposed move to case-insensitive Python is a
clear step in this very reasonable direction, so I fully
support it.
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
:-)
Greg Ewing
>
> having a recently-invented typographic prettiness, such as
> letter-cd tcase, affect meaning, has always struck me as a deeply
> flawed idea.
If you asked a mathematician, I doubt he'd regard
it as either "recent" or "flawed". Mathematicians
have been using case-, font-, style- and alphabet-
sensitive identifiers for centuries...
--
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
http://www.cosc.canterbury.ac.nz/~greg
Alex Martelli
news:3B566ED8...@cosc.canterbury.ac.nz...
> Alex Martelli wrote:
> >
> > having a recently-invented typographic prettiness, such as
> > letter-cd tcase, affect meaning, has always struck me as a deeply
> > flawed idea.
>
> If you asked a mathematician, I doubt he'd regard
> it as either "recent" or "flawed". Mathematicians
> have been using case-, font-, style- and alphabet-
> sensitive identifiers for centuries...
I think it was a 19th century fancy, to start with. Extremely
recent when compared to the amount of time mathematics
has been written about.
Alex
Clive Page
>But it's still open for debate whether the problem here is Windows or
>Unix! All programming languages and file systems used to be
>case-insensitive, until the designers of Unix and C decided that it
>was too much work to write and use a case-insensitive comparison
>routine. It wasn't necessarily intended to be better, just easier to
>implement. But times have changed, and that's a lousy excuse.
As this thread has shown, nearly everyone has an opinion on this. For what
it's worth, I've been using Unix for nearly 20 years and I still get caught
regularly by its case sensitivity, and I don't like it at all. Of course
my opinion is worth almost nothing, but there are some facts worth noting:
I'm pretty sure I've seen a study in one of the reputable computer science
journals reporting a trial of two sets of users with two invented computer
languages, identical except that one was case-blind and the other was case
sensitive. It showed that people made significantly more mistakes with a
case-sensitive language. Unfortunately I didn't keep the reference -
maybe someone else remembers it too? To me the results of that study
were pretty conclusive.
--
Clive Page c...@le.ac.uk
Mirko Liss
On Wed, 18 Jul 2001, Steve Lamb wrote:
[..case-sensitivity..]
> Eh, preference is for case sensitivity. Besides, I far prefer case
> sensitivity with tab completion than case insensitivity without. :)
What about case-sensitive Python combined with case-insensitive
tab-completion in IDLE? With an option to switch it off, of course.
That way, beginners won't be bound to the 'case-sensitivity' discipline
by endless error messages but they'll be gently reminded when typing the
code.
Since that IDE is written in python, that function could be easily
extended to handle diacritics, umlauts, even smilies &c, if one
really thinks the students need this.
And if one doesn't like it, he or she can switch it off.
Let's keep Python really simple. We can always provide conveniences in
external tools which are not necessary for the functioning of the core
language.
Friendly regards,
Mirko Liss
Guido van Rossum
> new excuse!
I didn't mean it as an excuse!
> How about:
>
> Now that everyone's making the transition to multiple language support,
> unicode and multiple encodings, how to you portably define/implement
> case-insensitive comparison?
Sorry, no problem. The Unicode standard defines for each character
whether it is upper or lower case, and what the corresponding
character is in the other case (if any).
Nick Efford
Interesting. Was the study done with programming novices, or with
experienced programmers? If the latter, did they have experience of
case-sensitive or case-insensitive languages? I wouldn't want to
draw firm conclusions without knowing more...
I can appreciate some of the arguments made in favour of a case-
insensitive Python, but there are times when we give meaning to case
in written English: "python" is the snake, but "Python" is the
programming language; "latex" is a material, "LaTeX" is a markup
language for document typesetting; "mud" is something you get on your
shoes, but a "MUD" is something entirely different. I would much
prefer it if Python continued to allow the distinctions we make in
written language to be preserved when coding.
Also, I'm not entirely convinced by the argument that "foo" and
"FOO" are perceived the same way when humans parse source code
visually. In pattern recognition terms, they are surely different
entities. It is only when natural language processing kicks in
that our brains can make the decision to treat the two the same.
So it may be that we can grok code quicker in a case-sensitive
language.
My other worry over case insensitivity is that it creates
opportunities for poor style by allowing the inconsistent use
of case. This seems a strange path to follow for a language
that made the inspired decision to avoid using block delimiters,
thereby denying users the "freedoms" of inconsistent or
non-existent indentation.
Nick
Bruce Sass
> > Now that we're in a new century, I think it's time to update to a
> > new excuse!
>
> I didn't mean it as an excuse!
>
> > How about:
> >
> > Now that everyone's making the transition to multiple language support,
> > unicode and multiple encodings, how to you portably define/implement
> > case-insensitive comparison?
>
> Sorry, no problem. The Unicode standard defines for each character
> whether it is upper or lower case, and what the corresponding
> character is in the other case (if any).
Hehe, so, if both case-insensitivity and multiple encodings were
adopted...
the easy to distinguish between "a" and "A" would not be allowed, but
the hard to read versions of "a" with diacritical marks would be...
...ya, that makes sense. :-/
- Bruce
Guido van Rossum
> adopted...
>
> the easy to distinguish between "a" and "A" would not be allowed, but
> the hard to read versions of "a" with diacritical marks would be...
>
> ...ya, that makes sense. :-/
If that's your whole argument against case insensitivity, I don't find
it very convincing. Certainly this issue has been solved before?
Tim Hochberg
I expect there will always be people who come to python expecting it to be
case sensitive as well as those new programers who supposedly expect it to
be case insensitive. Making the language purely case insensitive,
particularly given its dynamic nature, seems like a recipe for disaster. On
the other hand, if this does turn out to be a real impediment to new
programers, a variation on case sensitivity -- prefereably activated by a
flag to the interpreter -- might be useful. I'm not sure what to call this
variation, except that it would flag as an error using a name that differed
from another only by case.
Hmmm. Since all variables with the same name would have the same case, I
guess we could call it 'case consistency' instead of 'case insensitivity.
Let's look at an example for why case sensitivity could be a problem. It's
common practice to use all caps to designate constants, so consider the
following code:
class Contrived:
HAS_SPAM = 1
HAS_EGGS = 2
#....
def has_spam(self):
if self.flags & self.HAS_SPAM:
return 1
else:
return 0
For pure case sensitivity this would fail rather mysteriously (with an
attribute error for HAS_SPAM, I believe). For the second type of case
insensitivity described above, this would instead fail during compilation
with an error something like:
CaseMismatchError: Case of 'has_spam' doesn't match previous usage (did you
mean 'HAS_SPAM').
With a carefully designed error message, I think it could be made obvious to
both beginner and expert alike where the error was and how to fix it. In
addition, since case consistent programs would be a subset of case
sensitive programs, this could be implemented as a flag to the interpreter
that would cause the interpreter to behave this way so that beginners and
others who prefer case consistency could have it, while us sensitive folks
could continue using Python with its current case sensitivity.
There would, admittedly, be some trickiness in calling out to case sensitive
modules from from case consistent ones, but I don't think these would be
insurmountable.
sensitive-to-change-ly yours,
-tim
Bruce Sass
> > Hehe, so, if both case-insensitivity and multiple encodings were
> > adopted...
> >
> > the easy to distinguish between "a" and "A" would not be allowed, but
> > the hard to read versions of "a" with diacritical marks would be...
> >
> > ...ya, that makes sense. :-/
>
> If that's your whole argument against case insensitivity, I don't find
> it very convincing. Certainly this issue has been solved before?
I wouldn't even consider it an argument, but it could probably be
worked into a reductio ad absurdum strategy.
<shrug> I dunno (if the issue has been solved)
I'm still wondering what advantage there is to crippling the
expressivity of a language for the sake of a small group of
non-programmers.
- Bruce
Bjorn Pettersen
>
> > I'm still wondering what advantage there is to crippling the
> > expressivity of a language for the sake of a small group of
> > non-programmers.
>
>
> (1) The expressivity of the language is not crippled.
>
> (2) Potentially, the group of non-programmers is much larger than the
> group of programmers (and it's easier to teach programmers an
> arbitrary rule than non-programmers).
TRuE, tHe ExPRESsiVity oF ThE lANGuaGE is ProBAbLY nOt cRipPled,
hOWEvEr, tHere ARe SigNIficantLy FeweR ideNtIFIeRs AVaILABlE whICh mEAns
iT is LESs eXPRessIvE. IN pArTicULar, cOMmON Idioms liKE naMiNg CLASseS
stArTiNg WiTh UppER cASE lETtERS, AND instaNCeS OF THose cLAsSes
begINNiNG with A lOwER caSE LettER CaN NO LongeR Be usED.
AS fAR aS thE Size Of thE VARious camPs, I haVE YeT tO sEe a coMPeLLinG
aRGuMeNt thAT THE grOup of noN-pRoGRaMmeRS THat WILl taKe up
pRoGRAmmInG, ANd wiLL DO sO in PYTHon InsTEad oF VisUal BasiC, Is any
LARGeR Than The groUp of ProgRAmmERs.
-- bJoRn
Guido van Rossum
> expressivity of a language for the sake of a small group of
> non-programmers.
IMO there are two non-truths in this statement.
(1) The expressivity of the language is not crippled.
(2) Potentially, the group of non-programmers is much larger than the
group of programmers (and it's easier to teach programmers an
arbitrary rule than non-programmers).
--Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum
> Many of us feel, I believe, that case insensitivity is such
> an affection. Guido seems to be saying that he views it
> otherwise - that it is case sensitivity that is an affect.
I apologize for my poor English -- I don't know what you mean by "an
affection" or "an affect". Consulting a dictionary didn't help, but
I'm guessing that you mean something that gets in your way when
programming.
> Which to me is the beginning of a real discussion.
Fair enough. So let's begin the real discussion.
> Not meaning to be nasty at all, but these issues have
> been on the table for quite some time - and I do think
> it a tactical error to try to trump deeper discussion
> by pointing to selective anecdotal reports from
> near random sources, taken out of any meaningful
> context, that happen to support a predilection.
Here we go again -- I had to use a dictionary to find out what
"predilection" means (it's a "preference").
Anyway, I wasn't trying to do anything of the sort -- I was indicating
I have a right to be torn over this issue, since strong arguments can
be made for both cases.
Several people whom I respect have strongly suggested that if Python
wants to appeal to non-programmers, it should be case-insensitive.
(Leaving apart details of how to implement that; I agree that it
should be case-preserving.) Others, whome I respect just as much,
feel that it should be case-sensitive.
Unfortunately there isn't a lot of scientific evidence to help decide
this. There may be old reports that case-sensitivity hurts beginners.
I know that many other designers of programming languages aimed at
non-programmers have consciously choses case-insensitivity
(e.g. hypertalk, REXX).
TeachScheme is an interesting case -- Scheme is a case-sensitive
language, but in "beginner mode", TeachScheme is case-insensitive. I
can't find it on the web, but I bet the TeachScheme folks have a
rationale for this decision.
My own intuition and experience tells me that there seem to be two
kinds of people: some folks think case-sensitively, others think
case-insensitively. Myself, I am a case-sensitive person, but I can
easily learn to work with case-insensitive systems. It's possible
that most programmers have case-sensitive minds, but I think that most
non-programmers probably have case-insensitive minds. And
non-programmers are quite the majority. *If* there is any hard
scientific evidence that case-sensitivity is a hindrance to learning
to program (for most people), that would confirm my hunch.
It has been argued that making Python case-insensitive would be
"dumbing it down". I find this a strange argument. It doesn't take
any power away (as long as there's a way to link to external systems
that require case-sensitivity). I see it as lowering the bar --
what's wrong with that? (If you really feel that being a programmer
makes you part of an elite and you want to keep others out of that
elite, I pity you.)
It has been argued that case-sensitivity is a minor wart that's easily
explained. I find that a weak argument. Lots of minor problems can
be explained and gotten used to, but that doesn't mean we shouldn't
try to get rid of them if we can. Historically, this argument has
been used as an excuse for poor compilers or linkers.
It's been argued that making string, String, STRING and StRiNg mean
the same thing makes for less readable programs. I agree. A good
programming environment should silently correct the case of
identifiers as you type to conform to the definition. This also means
that you can still use different case conventions to hint about what
type of identifier it is, e.g. MACRO, Class, variable.
It's been argued that it's convenient to be able to write c = C(),
where C is a class and c is an instance of that class. Surely there
are other conventions we can use.
To me, the only real important question is, how can we introduce
case-sensitivity for novices without breaking the millions of lines of
existing Python code. One option could be: forget it, it's too late.
Another: put the case-insensitivity in the tools.
James Logajan
I'M TELLING THERE IS NO SEMANTIC DIFFERENCE BETWEEN UPPER AND LOWER CASE!
anything you see that may suggest otherwise is merely a figment of your
imagination. it has been proven with case studies and geometric logic that
there were strawberries, er, i mean indications that understanding mutable
versus immutable, class versus instance variables, slice assignment,
threading, slicing, and dicing were child's play for new programmers
compared to the agonizing difficulty of remembering that on line 3 they used
mySum and on line 6 they used mysum (but on line 9 they used
my_sum...nevermind!)
it has also been shown that the words "their", "there", and "they're" (among
many homonyms) are easily confused even in written form and theirfore the
english language should be changed to accommodate people knew to the english
language. yeah, write.
Note to the humor impaired: :-)
Tim Randolph
news:mailman.995571273...@python.org...
>
> (2) Potentially, the group of non-programmers is much larger than the
> group of programmers (and it's easier to teach programmers an
> arbitrary rule than non-programmers).
I think the distinction between programmers and non-programmers misses a
third important group: "sometime programmers" -- people who code
occasionally to for fun or to solve problems, but aren't in the trenches (or
the cubes) day in and day out.
As a member of this group, who is especially fond of Python for how easy it
is to pick up where I left off days or weeks before, I would very much
prefer a case *insensitive* language with tools that enforce *uniform* case
usage.
Nobody wants to see fOo and FOO and foo with the same meaning, but nobody
wants to see foo and FOO and foo at all in the same program with distinct
meanings. I also don't think the cutesy c=C() makes for readable code -- at
least for this sometime programmer.
little-logs-can-make-for-warm-fires-ly yrs,
Tim Randolph
Guido van Rossum
> hOWEvEr, tHere ARe SigNIficantLy FeweR ideNtIFIeRs AVaILABlE whICh mEAns
> iT is LESs eXPRessIvE. IN pArTicULar, cOMmON Idioms liKE naMiNg CLASseS
> stArTiNg WiTh UppER cASE lETtERS, AND instaNCeS OF THose cLAsSes
> begINNiNG with A lOwER caSE LettER CaN NO LongeR Be usED.
Very funny (not). You misunderstood the intention. The programming
environment should be case-preserving, and automatically correct
identifiers to use the same case as used when they were defined.
> AS fAR aS thE Size Of thE VARious camPs, I haVE YeT tO sEe a coMPeLLinG
> aRGuMeNt thAT THE grOup of noN-pRoGRaMmeRS THat WILl taKe up
> pRoGRAmmInG, ANd wiLL DO sO in PYTHon InsTEad oF VisUal BasiC, Is any
> LARGeR Than The groUp of ProgRAmmERs.
With your atttude, it will never happen.
Bjorn Pettersen
> > hOWEvEr, tHere ARe SigNIficantLy FeweR ideNtIFIeRs
> AVaILABlE whICh mEAns
> > iT is LESs eXPRessIvE. IN pArTicULar, cOMmON Idioms liKE
> naMiNg CLASseS
> > stArTiNg WiTh UppER cASE lETtERS, AND instaNCeS OF THose cLAsSes
> > begINNiNG with A lOwER caSE LettER CaN NO LongeR Be usED.
>
> Very funny (not). You misunderstood the intention. The programming
> environment should be case-preserving, and automatically correct
> identifiers to use the same case as used when they were defined.
I'm not sure I understand what this means. Are you proposing a
"non-programmer" IDE that automatically corrects incorrectly cased
identifiers and keywords, or are you still suggesting that the language
itself be case insensitive, but with a "non-programmer" IDE that just
makes code look consistent?
I don't think anyone would be opposed to an auto-correcting IDE.
> > AS fAR aS thE Size Of thE VARious camPs, I haVE YeT tO sEe
> a coMPeLLinG
> > aRGuMeNt thAT THE grOup of noN-pRoGRaMmeRS THat WILl taKe up
> > pRoGRAmmInG, ANd wiLL DO sO in PYTHon InsTEad oF VisUal
> BasiC, Is any
> > LARGeR Than The groUp of ProgRAmmERs.
>
> With your atttude, it will never happen.
What attitude is that? The one where I'd rather write new programs than
making sure the tens of thousand lines of Python I've allready written
work with a case insensitive interpreter? I don't think I'm the only one
with that attitude... :-)
-- bjorn
Bruce Sass
> > I'm still wondering what advantage there is to crippling the
> > expressivity of a language for the sake of a small group of
> > non-programmers.
>
> IMO there are two non-truths in this statement.
>
> (1) The expressivity of the language is not crippled.
I defined what I mean by "exressivity" in a previous post, no one
complained, so I continue to use it...
With a case-insensitive language "a" == "A", so you would need to do
"a_first" and "a_second" (whatever); the ideas represented by "a" and
"A" can be referred to more succinctly in a case-sensitive language,
so I went so far as to say case-sensitive is more expressive than
case-insensitive.
...feel free to s/expressive/<something>/
The short of it is... ya got less symbols to work with, therefore it
is less <something>... why is that good for programmers?
> (2) Potentially, the group of non-programmers is much larger than the
> group of programmers (and it's easier to teach programmers an
> arbitrary rule than non-programmers).
Ok... it is not the group that is small, but the amount of programming
done by the individuals in the group... why should a general purpose
programming language cater to a group who rarely program? Surely that
is best left to a specialized language that addresses the concerns of
that group, and not foisted upon those who use the language everyday.
- Bruce
Bruce Sass
<...>
> CaseMismatchError: Case of 'has_spam' doesn't match previous usage (did you
> mean 'HAS_SPAM').
That looks case-sensitive to me.
If it was case-insensitive... hi == Hi == hI == HI
so, has_spam == HAS_SPAM
By generating an error you are recognizing case, and enforcing rules
about the allowed case of a label... clearly, not being
case-insensitive.
- Bruce
Guido van Rossum
> The short of it is... ya got less symbols to work with, therefore it
> is less <something>... why is that good for programmers?
You flunked math, right? The number of available identifiers is still
infinite...
Guido van Rossum
> > (2) Potentially, the group of non-programmers is much larger than
> > the group of programmers (and it's easier to teach programmers
> > an arbitrary rule than non-programmers).
>
> I think the distinction between programmers and non-programmers
> misses a third important group: "sometime programmers" -- people who
> code occasionally to for fun or to solve problems, but aren't in the
> trenches (or the cubes) day in and day out.
Thanks for reminding me! This is in fact the group I have in mind
when I say non-programmer -- true non-programmers of course wouldn't
be using Python... :-). In my usage, a "programmer" is someone who
is a professional code-slinger, 8-12 hours a day. A "non-programmer"
is someone whose profession is something else (e.g. chemist, or
webdesigner, or rocket scientist) but who occasionally needs to
program.
> As a member of this group, who is especially fond of Python for how
> easy it is to pick up where I left off days or weeks before, I would
> very much prefer a case *insensitive* language with tools that
> enforce *uniform* case usage.
And that's of course what I have in mind.
> Nobody wants to see fOo and FOO and foo with the same meaning, but
> nobody wants to see foo and FOO and foo at all in the same program
> with distinct meanings. I also don't think the cutesy c=C() makes
> for readable code -- at least for this sometime programmer.
Exactly.
Delaney, Timothy
>
> Very funny (not). You misunderstood the intention. The programming
> environment should be case-preserving, and automatically correct
> identifiers to use the same case as used when they were defined.
However, this *does* rely on the tools to do the case-preservation.
I use a text editor for just about all my programming. The one I happen to
like most is unable to warn me about inconsistent-case.
Yes - it can be caught at compile-time ...
Except (and here comes the meat of my argument against this) ...
a = 1
def f()
A = 2
print a
What should happen here? Should there be a compile-time error? Does this
mean that I can't have a local variable with the same name as a global
variable, but differing only in case? But the following code is legal ...
a = 1
def f()
a = 2
print a
What happens if I do 'from something import *' (no, I don't actually do
that, but a lot of code does) and it imports into my global namespace a
bunch of names which conflict with names in my functions *only in case*?
Suddely my code breaks for no apparent reason.
I think introducing this would be *very* dangerous.
Tim Delaney
Arthur Siegel
>I apologize for my poor English -- I don't know what you mean by "an
>affection" or "an affect". Consulting a dictionary didn't help, but
>I'm guessing that you mean something that gets in your way when
>programming.
The poor English is all mine, for which I apologize.
The correct word is affectation, which I used in the sense of:
"manner of speech or behavior not natural to one's actual
personality or behavior"
Implies artificial.
>To me, the only real important question is, how can we introduce
>case-sensitivity for novices without breaking the millions of lines of
>existing Python code. One option could be: forget it, it's too late.
>Another: put the case-insensitivity in the tools.
But I have also been trying to ask you to define a term - "novice".
Seems to me it is clear that the needs of someone with an interest
in learning programming is a novice in a whole different sense
than someone with no such interest.
That seems obvious, but you do seem to point time and
again to circumstances in which the goal is for the subject
to accomplish something specific - and the set-up is specifically
to insulate them from an understanding of programming. *Not*
to motivate them to achieve it.
Anything you might *continue* to do to make an understanding
of programming accessible to those interested in such an
understanding, I would certainly support. I happen not to
believe focusing on case-sensitivity is at all a core issue
for that audience. But that, as they say, is me.
To spend any significant energy to cater to the novice in
the other sense - the novice who combines a lack of
experience with a lack of interest in the subject matter
of programming... well if I were you, I'd let myself off
that hook.
ART
Erik Max Francis
> Bruce Sass <bs...@freenet.edmonton.ab.ca> writes:
>
> > The short of it is... ya got less symbols to work with, therefore it
> > is less <something>... why is that good for programmers?
>
> You flunked math, right? The number of available identifiers is still
> infinite...
And is, in fact, corresponds to the same transfinite cardinal number.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Music washes away from the soul the dust of everyday life.
\__/ Berthold Auerbach
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
Greg Ewing
>
> I apologize for my poor English -- I don't know what you mean by "an
> affection" or "an affect".
I think he meant "affectation", about which
www.wordsmyth.net has this to say:
Pronunciation ae fihk te shEn
Definition 1. falseness or superficiality of appearance or behavior;
pretense.
Synonyms pretense (3) , artificiality {artificial (3)} ,
affectedness
{affected (2)} , pretentiousness {pretentious (1)}
Crossref. Syn. show , mannerism , air
Similar Words sham , show , unnaturalness {unnatural} , posturing
{posture (vi)}
Definition 2. a specific instance of such pretense.
Synonyms mannerism (2) , airs (5) , pose1 (2) , show (4)
Crossref. Syn. act
Similar Words imposture
Related Words camp , pomp , cant , pretense , claptrap
Greg Ewing
>
> I think it was a 19th century fancy, to start with. Extremely
> recent when compared to the amount of time mathematics
> has been written about.
It's still a lot longer than computers have been around.
And the fact that they *did* adopt it suggests they
found it useful in some way. Perhaps because it let
them express things more succinctly?
They seem to be satisified with the decision, too.
I've never heard a group of mathematicians debating
whether mathematics should go back to being
case-insensitive (if it ever really was to begin
with).
Quinn Dunkan
>To me, the only real important question is, how can we introduce
>case-sensitivity for novices without breaking the millions of lines of
>existing Python code. One option could be: forget it, it's too late.
>Another: put the case-insensitivity in the tools.
Given that changing the language itself at this point is too late (and I think
it is), the question is "for newcomers, does the additional complexity added
by a layer of indirection in the tools cancel out the benefit of case
insensitivity?" Obviously, that's assuming there is a benefit and it's
significant (and just how significant is what no one agrees on). But if I
were I newbie, I wouldn't like to hear "these are just training wheels, the
real language has slightly different rules". Don't underestimate the newbie
appeal of "what you see is all there is" (not that it ever is in python, given
magic methods etc., but we shouldn't make it worse).
An editor that optionally gives warnings about names with only case
differences seems pretty innoccuous, though. Giving people a friendly editor
is in the same spirit of avoiding "ok, well, to learn python first you need to
learn the unix shell, to be able to manage your source files and run vi, oh
yes, then you need to learn to use vi, just memorize this table of commands,
ok, then..."
So I'd say, please don't change the language itself, but it would be
interesting to see experiments on a friendly python-oriented editing
environment (to simplify things like finding modules and documentation,
importing, reloading, etc.).
Sheila King
Dunkan) wrote in comp.lang.python in article
<slrn9lfcea...@regurgitate.ugcs.caltech.edu>:
:On Thu, 19 Jul 2001 20:30:15 GMT, Guido van Rossum <gu...@python.org> wrote:
:>To me, the only real important question is, how can we introduce
:>case-sensitivity for novices without breaking the millions of lines of
:>existing Python code. One option could be: forget it, it's too late.
:>Another: put the case-insensitivity in the tools.
:
:Given that changing the language itself at this point is too late (and I think
:it is), the question is "for newcomers, does the additional complexity added
:by a layer of indirection in the tools cancel out the benefit of case
:insensitivity?" Obviously, that's assuming there is a benefit and it's
:significant (and just how significant is what no one agrees on). But if I
:were I newbie, I wouldn't like to hear "these are just training wheels, the
:real language has slightly different rules". Don't underestimate the newbie
:appeal of "what you see is all there is" (not that it ever is in python, given
:magic methods etc., but we shouldn't make it worse).
:
:An editor that optionally gives warnings about names with only case
:differences seems pretty innoccuous, though.
I think this would be an excellent idea. Instead of just giving a "name
error", generate a list of names that it might be close to? Or, if one
appears to be a match excepting for case, ask if that other name might
have been the intended one? A friendly error message!
: Giving people a friendly editor
:is in the same spirit of avoiding "ok, well, to learn python first you need to
:learn the unix shell, to be able to manage your source files and run vi, oh
:yes, then you need to learn to use vi, just memorize this table of commands,
:ok, then..."
:
:So I'd say, please don't change the language itself, but it would be
:interesting to see experiments on a friendly python-oriented editing
:environment (to simplify things like finding modules and documentation,
:importing, reloading, etc.).
Good points!
--
Sheila King
http://www.thinkspot.net/sheila/
http://www.k12groups.org/