PEP0238 lament

[Martijn Faassen]

Tim Peters <tim.one at home.com> wrote:
> [Martijn Faassen]
>> ...
>> The audience was entirely self-selected;

> Unlike, say, the participants in this discussion?  Hmm.  You set a rather
> high standard here, Martijn <wink>.

This discussion is entirely self selected too. What I'm pointing out is that
your 3/4 number is fairly meaningless in this discussion.

> ? they were people with an interest in numeric models.

> Or uninterested in Stackless (its "competition" in that time slot).  I
> suppose the next time we want advice about Unicode, we should just ask
> Americans.

No, next time you want to point out why Unicode should be removed from the
language, you should mention that in a session with mostly Americans *about*
removing Unicode from the language (because it confuses newbies) that
3/4th of the people present wanted it removed.

>> Did Guido ask for a show of hands in the big session afterwards?

> No, not on this issue.

>> I don't recall; I kind of suspect the outcome would've been different.

> I actually think 1/2==0 bothers "the general" population more than those
> with a keen interest in numerics.  Indeed, nobody with a keen interest in
> numerics has bugged Guido about this except Moshe, that I know of; the most
> visible repeated pressures have come from educators using Python as a means
> to some other end.

It bothers this member of the "general population" more that the semantics
of '/' will be changed rather radically at this point in the development of a
language. I don't see / as an educationally difficult concept compared to,
say, "all names in Python are references. Assignment is name rebinding, not
copying".

I wouldn't be arguing about this if we were designing a new language.

>>> The current integer division loses information silently and without a
>>> trace combined with that Python is not a statically typed language,
>>> there's simply no telling what e.g.
>>>
>>>  def velocity(distance, time):
>>>      return distance / time
>>>
>>> will compute by inspection.

>> There's no telling what:
>>
>> def add_stuff(a, b):
>>    return a + b
>>
>> will compute by inspection either, though.

> You chopped all my following text, saying that the velocity() example wasn't
> about user-defined overloadings but about ordinary arithmetic on the builtin
> numeric types.  A user trying e.g. velocity(3, 2) is simply going to be
> surprised -- as countless newbies have testified on c.l.py over the years.

I'm talking about string concatenation versus addition; no user-defined
overloading. "+" involves information loss when you use string concatenation;
the converse "-" operator isn't even defined for string concatenation.

"+" does two different things depending on what you pass in (strings or
numbers). "*" does so too. They both can be said to lose information.

Of course here we'd make the counter argument that "+" and "*" are entirely
different operations when we apply them to strings. But we can make a similar
argument for "/" (integers versus floats). That by itself is pretty common
in OO languages. 

Anyway, this only to point out that "/" is not *that* specially weird.
My main argument has nothing to do with it, but everything about not wanting
to break a rather large amount of existing code. This isn't the makefile
scenario, either. 

>> ...
>> For working with pixels in GUIs and such, integer division can be a
>> useful thing, though.

> It can be useful for many things; that's not at issue, and nobody has ever
> proposed taking away the ability to get an integer result; the issue is how
> to spell that.

The issue is also on whether you want to break all the existing integer division
code by changing the spelling, or not. You aren't designing a language in
a void here and this is a rather fundamental change to the core semantics. 

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?