PEP0238 lament AND Re: Case (In)sensitivity

[Chris Barker]

Chris Gonnerman wrote:
> Both of these changes fall in the same group IMHO... they
> break a lot of code.

Yes, they do. That's why I proposed a versioning sytem in an earlier
post (see:
A way to accommodate laguage changes) Ithink it could reduce the pain a
lot.

> Don't tell me that newbies need this to learn the language,
> as we know they don't.  We were all newbies once; which of
> us had a problem with either int division or case sensitivity.

I think the issues with newbies bring it to light, but neither of these
are newbie-only issues. I know it's a big time sink, but READ THE POSTS,
it's all there! I'm not going to comment on case sensitivity, but as for
the int/int thing:

This has been said a number of times, but I'll put it here as anyway,
since it pretty difficult to sift through the enormous number of posts
about this. There are a couple of issues with / as it is:

1)  1/2 == 0

(constant values) This is an issue for newbies mostly, but it can be
learned, and perhaps should be anyway, integers and floats are different
inside the computer, the sooner you learn that, the better.

2) def velocity(distance,time):
       return distance/time

This, I think, is a MUCH bigger issue. For the first time, I see why
some folks are so gung ho on static type declarations. Clearly the
author of this function intends floating point division. (or maybe
complex!) It is possible, however, for a couple of integers to get
passed in, perhaps from user input. Granted, this isn't biting us all
the time because most of us think to wrap the input in a float() or
something. There are other solutions, such as putting float() , or *1.0
or +0.0 or something in there, but there are problems and limitations to
all of these. There are also limiations to always using float division,
and then wrapping a int(), or int(floor()) or whatever around it. See
various previous posts for the details. Note that this in NOT an issue
with a statically typed language float velocity( float distance, float
time) could not have this problem, so the fact that a number of
statically typed laguages use the current system successfully is not
very relevant.

Since Python is dynamically typed, you don't know for sure what the
types  will be that are input to your function. Yes, that applies to
strings (or whatever) getting passed in when you expect a number, but
that usually creates an obvious error much sooner thatn an int when you
expect a float. Given this, it makes a whole lot more sense to have the
programmer specify what kind of division is desired, thus the desire for
two operators. It seems that most folks (not all!) do agree that the two
operator approach is a good one, the question is whether it is worth
introducing backward compatability in order to do it.

By the way, just adding "//" as the new operator (returning a float
divide, even with all integer inputs) is not a perfect solution either.
The current "/" behaves differently depending on input. Some have
scoffed at the idea of 1.0/2.0 returning 0, but I do think that is very
useful, just like you might get two ints when you expect a float, you
could get one or more floats when you expect two ints. AGin,you could
write (int(floor(a/b)) or  int(divmod(1.0,2.0)[0]), and I do write code
like that all the time, but it would be great if I didn't have to!

So: the ideal solution is two have two different division operators: one
that is as close as we can get to real number (and complex) division,
and one that is integer division. The real question here is:

Is it worth introducing a backward compatable change to get it ???

My answer is yes, but only if a way to handle backwards compatable
changes is introduced: some kind of versioning system. We'll see what
Guido decides, but I'd be very surprised if he is still reading these
posts!


-Chris


-- 
Christopher Barker,
Ph.D.                                                           
ChrisHBarker at home.net                 ---           ---           ---
http://members.home.net/barkerlohmann ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------
------------------------------------------------------------------------