PEP0238 lament

408 views
Skip to first unread message

Arthur...@rsmi.com

unread,
Jul 22, 2001, 12:01:08 PM7/22/01
to pytho...@python.org, edu...@python.org
Before going further in attempting to contribute to the
discussions of Pep238 (or case sensitivty) allow
be to present my credentials.

None, to speak of.

Except that I've been through the program. Guido's
program. His language. His environment. His
tutorials.

I think with some success.

Participate little on python-list, because much of
what goes on is over my head.

But on the question of learning programming with
Python - as I mention, been through the program.

Here the issues are under my nose, not
over my head.

I particpate actively on the edu-sig list, because
I understand my success could be other's success.
Am a big supporter of Guido's CP4E ideals.

Yet despite the gratitude I try to keep in mind,
I clash consistently with Guido on CP4E - sometimes
in unpleasant ways.

Can only hope he appreciates at some level that I
bring some passion to the table on some common
goals.

Because that clash now spills over to the Python list.

Since I have convinced myself that not only do I
object to the rationale and evidence gathering behind
the integer division change - I am going to step up
and be arrogant enough to say that I am against it
as a design feature, in light of the only aspect of Python
design about which I would dare to speak - CP4E goals.

3 / 4 = 0
3.0 / 4 = .75

Something important is going on here. I have a decent
understanding of what that is. Enough to get me by in
the real world.

I came to It - having already understood that I would
only get so far if I expected it all to come to me.

That reckoning has been put off an hour ot two for the
Python 2.2 learner, with a measurable cost.

Pity for the Python2.2 learner.

Quite well realize that I am not saying anything that
hasn't been said before on the issue.

But disappointed to never have heard the counter
argument from Guido - what put the issue over the
top for him?

If I was told that experinced programmers might
appreciate this change for any possible reason -
I'd be quiet as a mouse.

Since I remain convinced that the single most important
factor for Python's acceptance as an educational language is
the growth of its acceptance as a professional language.

It will be interesting to see where Guido chooses to draw
the line on the thought process that lead him to his integer
division conclusion.

Which is the real issue - the integer division thing, stand-alone,
not likely to be a deal breaker for anyone.

Like to believe that there is more real world thinking
than Guido chooses to share publicly.

Alternatively, I'm baffled as hell.

ART

Guido van Rossum

unread,
Jul 22, 2001, 12:22:54 PM7/22/01
to
Arthur Siegel and I seem to be pushing each other's buttons
constantly. I don't know why it is, but ever post of his feels like a
flame or flamebait to me. I always feel that he attacks me as a
person rather than attacking my arguments (usually because he claims
that I haven't given any arguments). Try as I may, this makes it very
hard, almost impossible for me to respond in a meaningful manner to
Arthur's posts. I wonder what I've done to tick him off. I also
wonder how come he is so good at ticking me off.

The reason for wanting / to return a float (or at least a type that
can represent close approximations of numbers like 0.75) has been
discussed many times before. The summary of the argument in the PEP
may not be complete, but I disagree with Arthur's assessment that
integer division is not a problem -- the VPython folks have ample
experience that it is.

Because all Arthur does is tick me off, I'll leave it at this -- maybe
someone else can explain it all to him.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Rainy

unread,
Jul 22, 2001, 1:40:10 PM7/22/01
to
On Sun, 22 Jul 2001 11:01:08 -0500, Arthur...@rsmi.com <Arthur...@rsmi.com> wrote:
>
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.

I don't think they will..

>
> Since I remain convinced that the single most important
> factor for Python's acceptance as an educational language is
> the growth of its acceptance as a professional language.

First of all, it's really ugly. It's the ugliest thing in python for a newbie,
imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
reason for that, just memorize it. Ugh.

If it was just a matter of that, it wouldn't be enough for a change (non-
backwards-compatible one). But, the problem is that people will have strange
bugs because of this and spend hours upon hours trying to figure out what's
wrong. Python may be around during next 10-20 years and userbase may grow
a thousandfold, and having this ugliness on board for all this time is a
big problem.

It's arguable whether the problem is serious enough to break old code, but it's
obvious (to me, anyway) that there *is* a rather big problem here.

--
Cymbaline: intelligent learning mp3 player - python, linux, console.
get it at: http://silmarill.org/cymbaline

Guido van Rossum

unread,
Jul 22, 2001, 1:20:15 PM7/22/01
to Skip Montanaro, pytho...@python.org
> I just reread the PEP at
>
> http://python.sourceforge.net/peps/pep-0238.html
>
> It looks like it hasn't been updated since March. I see no support for the
> argument that the current integer division semantics are confusing, only a
> claim that the current semantics are a problem. Perhaps there's a more
> recent version of the PEP available that hasn't been released to the
> website.

Skip,

I've asked Moshe today to update the rationale based on the discussion
in c.l.py. He said he would. So just be patient.

Skip Montanaro

unread,
Jul 22, 2001, 1:11:09 PM7/22/01
to Guido van Rossum, pytho...@python.org

Guido> The reason for wanting / to return a float (or at least a type
Guido> that can represent close approximations of numbers like 0.75) has
Guido> been discussed many times before. The summary of the argument in
Guido> the PEP may not be complete, but I disagree with Arthur's
Guido> assessment that integer division is not a problem -- the VPython
Guido> folks have ample experience that it is.

Guido,

I just reread the PEP at

http://python.sourceforge.net/peps/pep-0238.html

It looks like it hasn't been updated since March. I see no support for the
argument that the current integer division semantics are confusing, only a
claim that the current semantics are a problem. Perhaps there's a more
recent version of the PEP available that hasn't been released to the
website.

--
Skip Montanaro (sk...@pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/

Moshe Zadka

unread,
Jul 22, 2001, 2:40:49 PM7/22/01
to Skip Montanaro, Guido van Rossum, pytho...@python.org
On Sun, 22 Jul 2001 12:11:09 -0500, Skip Montanaro <sk...@pobox.com> wrote:

> Guido,
>
> I just reread the PEP at
>
> http://python.sourceforge.net/peps/pep-0238.html
>
> It looks like it hasn't been updated since March. I see no support for the
> argument that the current integer division semantics are confusing, only a
> claim that the current semantics are a problem. Perhaps there's a more
> recent version of the PEP available that hasn't been released to the
> website.

Not really. I'm working on the PEP, and hopefully there will be a
new version tommorow with some more meat.
--
gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE
Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE

Tim Peters

unread,
Jul 22, 2001, 2:22:21 PM7/22/01
to pytho...@python.org, edu...@python.org
[Arthur...@rsmi.com]
> ...

> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.

Not all experienced programmers agree. At the last Python Conference, I
moderated a 40-some person group discussion on conceivable changes to
Python's numeric model, not advocating but keeping the participants from
killing each other <wink>. The meaning of integer division wasn't the
focus, but naturally came up. By show of hands, about 3/4ths of the
participants agreed that 3/4 should not return 0, but rather *something* x
such that x*4 had a better chance of being confused with 3 than with 0.
There was no consensus on exactly what 3/4 should return -- rational or HW
float or decimal float were the most popular alternatives.

It shouldn't be so hard to understand why. 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. This isn't about esoteric user overloading of
"/", it's about ordinary arithmetic on builtin numeric types, and many
experienced Python programmers have testified over the years to being burned
in practice by stuff exactly that simple.

I expect that either way is easy enough to *teach*, but I don't accept ease
of teaching as a primary goal: I'm much keener on semantics that, once
*learned*, are hard to forget or to stumble over. Even if such semantics
are 100x harder to teach at first, fine by me: you spend the rest of your
life living with the consequences. I wish the definition of continuity were
easier to teach too, but that doesn't mean I'll settle for an easier
definition that doesn't actually work <wink>.

some-mice-are-surprised-when-thet-divide-up-the-cheese-and-
cheese-mass-mysteriously-disappears-ly y'rs - tim


Moshe Zadka

unread,
Jul 22, 2001, 3:05:17 PM7/22/01
to Tim Peters, pytho...@python.org, edu...@python.org
I'm the last person to avoid going off on a tangent.

On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim...@home.com> wrote:

> I wish the definition of continuity were
> easier to teach too, but that doesn't mean I'll settle for an easier
> definition that doesn't actually work <wink>.

Here is one that is easier to teach, if you just reverse the order
of teaching calculus and first-order logic and basic set theory.

A function is continuous at c if, when embedding the world of Reals
into a saturated model (or, say, 2^{Beth_omega} saturated, if you
don't want to get into subtle assumptions), for every infinitesimal x,
f(c+x)-f(c) is an infintesimal.

Of course, you might think that teaching about saturation is hard --
well, it might be ;-)

i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
with-epsilons-and-deltas-ly y'rs, Z.

David Eppstein

unread,
Jul 22, 2001, 4:07:02 PM7/22/01
to
In article <mailman.995826216...@python.org>,
"Tim Peters" <tim...@home.com> wrote:

> By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.

Well then, float is a very bad choice for what to return, or then how do
we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?

I would be a lot happier with integer / integer = rational (as in
Mathematica's programming lang), but float is just ugly. It is turning
exact values (integers) into approximate ones (float) when I didn't tell it
to. It's almost as bad as if integer subtraction always truncated to 16
bit values -- a lot of the time that would give sort of reasonable answers
but it's a gratuitous approximation where you didn't expect one.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/

David Eppstein

unread,
Jul 22, 2001, 4:08:44 PM7/22/01
to
In article <eppstein-03540D...@news.service.uci.edu>,
David Eppstein <epps...@ics.uci.edu> wrote:

> Well then, float is a very bad choice for what to return, or then how do
> we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10?

Uh, of course I meant 3/10 * 10 != 3...

James Logajan

unread,
Jul 22, 2001, 4:29:45 PM7/22/01
to
Tim Peters wrote:
> By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.

This has probably already been brought up, but perhaps the problem lies not
with the "/" operator, but one step earlier in distinguishing the meaning
of:

x = 3
and
x = 3.

That is subtle difference that can cause quite different results later on.

Or, one may try to teach that when ALL arguments of an operator are in one
"set", such as the set of integers, then one must expect a result that is an
element from THAT set, not another set, such as the set of real numbers or
from the set of complex numbers. Set theory seems to be taught fairly early
on in math, I think.

It has been my observation that people can often quickly grasp and make use
of the common underlying general principles behind things after having seen
only a few examples, provided there is a CONSISTENT underlying principle. A
handful of general rules may be easier to teach than a collection of special
cases. So can and should Python adopt an underlying principle along the
lines where one can grasp the following pattern:

integer = integer operator integer
real = integer operator real
real = real operator integer
real = real operator real
complex = integer operator complex
...

I prefer a handful of general rules, and operators that obey them.

Erik Max Francis

unread,
Jul 22, 2001, 4:24:22 PM7/22/01
to
David Eppstein wrote:

> I would be a lot happier with integer / integer = rational (as in
> Mathematica's programming lang), but float is just ugly. It is
> turning
> exact values (integers) into approximate ones (float) when I didn't
> tell it
> to. It's almost as bad as if integer subtraction always truncated to
> 16
> bit values -- a lot of the time that would give sort of reasonable
> answers
> but it's a gratuitous approximation where you didn't expect one.

I agree. It's turning an otherwise fairly strongly (but dynamically)
typed language on its head. If I want type-changing operations, I'll do
them explicitly.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Wretches hang that jurymen may dine.
\__/ Alexander Pope
Esperanto reference / http://mirror/alcyone/max/lang/esperanto/
An Esperanto reference for English speakers.

Tim Peters

unread,
Jul 22, 2001, 4:01:31 PM7/22/01
to pytho...@python.org, edu...@python.org
[TIm]

> I wish the definition of continuity were easier to teach too, but that
> doesn't mean I'll settle for an easier definition that doesn't actually
> work <wink>.

[Moshe Zadka]


> Here is one that is easier to teach, if you just reverse the order
> of teaching calculus and first-order logic and basic set theory.
>
> A function is continuous at c if, when embedding the world of Reals
> into a saturated model (or, say, 2^{Beth_omega} saturated, if you
> don't want to get into subtle assumptions), for every infinitesimal x,
> f(c+x)-f(c) is an infintesimal.
>
> Of course, you might think that teaching about saturation is hard --
> well, it might be ;-)

Na, they always leave *some* of the foundations in intro calculus courses
fuzzy. H. Jerome Keisler wrote a very good intro calculus text based on
non-standard analysis, unfortunately now out of print. See

http://www.math.wisc.edu/~keisler/books.html

for publication details. He didn't try to explain the intricacies of model
theory, he just spelled out "the rules" for working with infinitesimals and
got on with it. Huge steaming masses of epsilon-delta proofs were
conspicuous by absence, so he was able to get to "the interesting stuff" a
lot quicker that way. A good feel for the flavor of the approach can be
gotten by skipping to the end ("Part IV: Turning Calculus into Algebra") of

http://online.sfsu.edu/~brian271/nsa.pdf

and reading "~=" as "infinitely close to".

> i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
> with-epsilons-and-deltas-ly y'rs, Z.

i-personally-blame-guido-for-letting-it-stand<wink>-ly y'rs - tim


Justin Sheehy

unread,
Jul 22, 2001, 4:53:28 PM7/22/01
to pytho...@python.org
si...@optonline.net (Rainy) writes:

> 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
> reason for that, just memorize it. Ugh.

Of course there is a good reason for it.

It may not be a reason that you personally think is "good enough", but
that does not make it a random, arbitrary aspect of the language.

You don't have to memorize that 1/2 is zero. You just have to learn
the general rule here, that division of two integers produces an integer.

Whether or not you like this feature, presenting it as you have is
incorrect and unfair.

-Justin

Martijn Faassen

unread,
Jul 22, 2001, 5:14:36 PM7/22/01
to
Tim Peters <tim...@home.com> wrote:
> [Arthur...@rsmi.com]
>> ...
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.

> Not all experienced programmers agree. At the last Python Conference, I
> moderated a 40-some person group discussion on conceivable changes to
> Python's numeric model, not advocating but keeping the participants from
> killing each other <wink>. The meaning of integer division wasn't the
> focus, but naturally came up. By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.

> It shouldn't be so hard to understand why.

[snip Tim's reasons]

The audience was entirely self-selected; they were people with an interest
in numeric models. Did Guido ask for a show of hands in the big session
afterwards? I don't recall; I kind of suspect the outcome would've been
different.

> 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. Are we complaining about that?
(yeah, I know the inverse operation is rather hard to define for
string addition :)

[snip]

Of course I claim no expertise in this matter whatsoever. :)
For working with pixels in GUIs and such, integer division can be a useful
thing, though.

Regards,

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

Cliff Crawford

unread,
Jul 22, 2001, 5:41:14 PM7/22/01
to
* Tim Peters <tim...@home.com> menulis:

|
| The meaning of integer division wasn't the
| focus, but naturally came up. By show of hands, about 3/4ths of the
| participants agreed that 3/4 should not return 0, but rather *something*
| [snip]

In other words, nobody raised their hand, since 3/4 == 0. Well, that
settles it, then -- nobody wants this change <0.75 wink>.


--
Cliff Crawford http://www.sowrong.org/
A sign should be posted over every campus toilet:
"This flush comes to you by courtesy of capitalism."
-- Camille Paglia

Moshe Zadka

unread,
Jul 22, 2001, 5:00:53 PM7/22/01
to Erik Max Francis, pytho...@python.org
On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:

> I agree. It's turning an otherwise fairly strongly (but dynamically)
> typed language on its head. If I want type-changing operations, I'll do
> them explicitly.

Be sure to tell math.cos that...it has been "silently" turning integers
into floats for years.

Err.....problem with the URL? I don't think there's a host called "mirror".
A pity, sounded interesting.

Tim Peters

unread,
Jul 22, 2001, 5:05:18 PM7/22/01
to pytho...@python.org
[David Eppstein]

> Well then, float is a very bad choice for what to return, or then how
> do we explain when 3/4 * 4 = 3 (exactly) but 3/10 * 10 != 10? [3
> was intended here]

Using decimal floats, 3/10*10 does equal 3, but a generation raised on
BCD-ish hand calculators wouldn't even blink an eye if 1/3*3 returned
0.999999999999.

> I would be a lot happier with integer / integer = rational (as in
> Mathematica's programming lang),

That view has its fans too; see PEPs 239 and 240; also mounds of prior
discussion on the python-numerics list:

http://sourceforge.net/mail/?group_id=5470

You're probably new enough to this to have missed that Guido had lots of
experience with rationals in the ABC language and didn't like it there.
Speed and memory consumption were unpredictable for non-experts, and could
vary wildly (factors of 1000s) for a fixed algorithm, depending on the
inputs. Rationals aren't a cure-all, and the instant you throw a sqrt or
transcendental into the mix you're back to some form of fp anyway.

> but float is just ugly. It is turning exact values (integers) into
> approximate ones (float) when I didn't tell it to.

If the language defines "/" as returning a float, then you told it to. You
*almost* may as well complain that math.sqrt(2) turns an exact value into an
approximate one; but, e.g., when I use Macsyma, it doesn't lose information
there either. Python isn't going to do symbolic computation by default, so
the question isn't whether to compromise, but where.

> It's almost as bad as if integer subtraction always truncated to 16
> bit values -- a lot of the time that would give sort of reasonable
> answers but it's a gratuitous approximation where you didn't expect
> one.

You don't expect an approximation in that context because Python promises
not to make one in that context. If you expect things a language doesn't
promise, that's not really the language's fault <wink>.


Tim Peters

unread,
Jul 22, 2001, 5:45:02 PM7/22/01
to pytho...@python.org
[James Logajan]

> This has probably already been brought up, but perhaps the problem lies
> not with the "/" operator, but one step earlier in distinguishing the
> meaning of:
>
> x = 3
> and
> x = 3.
>
> That is subtle difference that can cause quite different results later
> on.

Why is that? It's because unlike any other builtin arithmetic operation,
"/" today can cause *catastrophic* loss of information silently, and in
ordinary cases. If code sticks to + - * and **, it usually doesn't matter
much in the end whether someone says

x = 3
or
x = 3.

at the start. But toss in one "/", and radically different results are
common.

> Or, one may try to teach that when ALL arguments of an operator are in
> one "set", such as the set of integers, then one must expect a result
> that is an element from THAT set, not another set, such as the set of
> real numbers or from the set of complex numbers. Set theory seems to
> be taught fairly early on in math, I think.

I think you're missing that the proponents are arguing on pragmatic grounds:
this has mostly to do with that x/y surprises people in real life. It's not
that there aren't clear rules, or that the rules can't be taught, or that
people are too stupid to understand the rules. Guido hears all the
complaints, and he's become convinced that this is a genuine and serious
flaw in the language: the current rules are *unusable* for too many people
too often. If you're not one of them, congratulations <wink>. I'm not
either -- I never get burned by this. But I see plenty of people who are,
and they're neither stupid nor careless; it's a common blind spot, so it
doesn't really matter that it's not one I (or you) suffer.

> ...
> I prefer a handful of general rules, and operators that obey them.

Of course, but computer numerics is a massive exercise in picking the
general rules you want to preserve at the expense of others, and trading all
that off against pragmatics too. Not losing information silently is also a
Very Good General Rule, and even 745 binary fp arithmetic is better at
meeting that one than current "/".


Bengt Richter

unread,
Jul 22, 2001, 6:03:30 PM7/22/01
to
On Sun, 22 Jul 2001 14:22:21 -0400, "Tim Peters" <tim...@home.com> wrote:

>[Arthur...@rsmi.com]
>> ...
>> If I was told that experinced programmers might
>> appreciate this change for any possible reason -
>> I'd be quiet as a mouse.
>

I'd call myself experienced, though not yet with Python (though
I fancy my other experience gives me a leg up on most Python newbies).

I am generally so adaptable it's almost a problem, so I'll
have no big problem with '//' after I accept that this is Rome,
and I should do as the Romans do. It's certainly not going
to put me off Python ;-)

>Not all experienced programmers agree. At the last Python Conference, I
>moderated a 40-some person group discussion on conceivable changes to
>Python's numeric model, not advocating but keeping the participants from
>killing each other <wink>. The meaning of integer division wasn't the
>focus, but naturally came up. By show of hands, about 3/4ths of the
>participants agreed that 3/4 should not return 0, but rather *something* x
>such that x*4 had a better chance of being confused with 3 than with 0.
>There was no consensus on exactly what 3/4 should return -- rational or HW
>float or decimal float were the most popular alternatives.
>
>It shouldn't be so hard to understand why. The current integer division
>loses information silently and without a trace. Combined with that Python

The thing is, current floating point operations also (sometimes, not always,
just as with integer ops) lose "information silently and without a trace."
Just less noticeably, for the most part, if you sanitize output.

Which leads me to wondering if exactness would be a more approachable
concept for CP4E than details of numeric representation alternatives.

For many 'float' is about as relevant to their desired computing experience
as 'hypoid' is to their commuting experience. Why not keep both hidden under
the hood (without welding it shut, of course) ?

>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. This isn't about esoteric user overloading of
>"/", it's about ordinary arithmetic on builtin numeric types, and many
>experienced Python programmers have testified over the years to being burned
>in practice by stuff exactly that simple.
>

I believe you. BTW, is there an efficient type assertion that doesn't go away with
optimization, that one could use to refuse wrong-type arguments?

>I expect that either way is easy enough to *teach*, but I don't accept ease
>of teaching as a primary goal: I'm much keener on semantics that, once

Glad to hear that. <rant>Worst IMHO is when teachers teach what is actually wrong
to children or the otherwise innocently ignorant, with the rationale that
the real truth is too complicated, and even letting on that there is a real
truth will just be confusing. That not letting on part is the real evil.
Of course, many teachers are themselves the product of this methodology,
and pass it on unawares.</rant>

I wonder what K-12 teachers will say about Python float ;-/
Maybe there should be guidelines for teaching what is not understood,
so that bright kids don't get cynical too fast.

>*learned*, are hard to forget or to stumble over. Even if such semantics
>are 100x harder to teach at first, fine by me: you spend the rest of your
>life living with the consequences. I wish the definition of continuity were
>easier to teach too, but that doesn't mean I'll settle for an easier
>definition that doesn't actually work <wink>.
>

You teach that? How many are you, anyway? ;-)

Grant Edwards

unread,
Jul 22, 2001, 6:28:18 PM7/22/01
to
On Sun, 22 Jul 2001 17:40:10 GMT, Rainy <si...@optonline.net> wrote:

>First of all, it's really ugly. It's the ugliest thing in python for a newbie,
>imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
>reason for that, just memorize it. Ugh.

There _is_ a good reason. 1 and 2 are integers. How many 2s
can you fit into a 1?

None.

Zero.

--
Grant Edwards grante Yow! Can you MAIL a BEAN
at CAKE?
visi.com

Grant Edwards

unread,
Jul 22, 2001, 6:31:34 PM7/22/01
to
On Sun, 22 Jul 2001 14:22:21 -0400, Tim Peters <tim...@home.com> wrote:

>It shouldn't be so hard to understand why. The current integer division
>loses information silently and without a trace.

No, it doesn't. Integer division is integer division. The
correct answer for the value of 3/4 is 0. If you wanted the
remainder, you should ask for it. If you want to divide
floating point numbers, you should _use_ floating point numbers.

Perhaps my mind was warped by using nothing but integer
arithmatic in my software for many years because floating point
was simply too slow and too expensive.

--
Grant Edwards grante Yow! Are we THERE yet? My
at MIND is a SUBMARINE!!
visi.com

Tim Peters

unread,
Jul 22, 2001, 6:02:31 PM7/22/01
to pytho...@python.org
[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>.

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

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

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

> ...


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


David Eppstein

unread,
Jul 22, 2001, 7:27:32 PM7/22/01
to
In article <mailman.995839419...@python.org>,
"Tim Peters" <tim...@home.com> wrote:

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

My intuition is that the users who will be surprised that 1/2 = 0 are the
same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
Result: buggier code since the errors are less obvious.

If you have a routine "velocity" in which it doesn't make sense to do
integer truncation, and it doesn't coerce its args to float by adding 0.0,
that's also a bug.

James Logajan

unread,
Jul 22, 2001, 7:37:00 PM7/22/01
to
Tim Peters wrote:
> Guido hears all the
> complaints, and he's become convinced that this is a genuine and serious
> flaw in the language: the current rules are *unusable* for too many people
> too often. If you're not one of them, congratulations <wink>. I'm not
> either -- I never get burned by this. But I see plenty of people who are,
> and they're neither stupid nor careless; it's a common blind spot, so it
> doesn't really matter that it's not one I (or you) suffer.

Well, having learned one set of expectations, I can say that I WILL suffer
some pain if this is changed. And it isn't a case of an expectation carried
over from another language!

Speaking of patterns, it unfortunately appears that Guido has a strong
tendency to take the existing user base for granted, since he continues to
keep the door open to code-breaking changes. There is only so much insult
("well, what you were doing was bad style anyway," or "you shouldn't have
written code that depends on integer division(!)") and injury (the more
Python you've written, the more likely something you wrote wont work with
the latest version and will need to spend hours reviewing,
just-in-case-anyway) before one decides that it just isn't worth the pain.

I do not want to continue to write more Python and expose myself to further
risk of having it either become dependent on an un-maintained and minority
release (e.g. "sorry, you should have upgraded to 3.1 years ago; who writes
stuff on 2.1 these days anyway?") or having a growing body of code to
constantly shepherd along to insure it runs on the next release.

That is the pragmatics from my point of view. And it doesn't give a damn
what real or perceived "flaw" in the language is being addressed.

Jan Dries

unread,
Jul 22, 2001, 8:31:14 PM7/22/01
to pytho...@python.org
Grant Edwards wrote:
> No, it doesn't. Integer division is integer division. The
> correct answer for the value of 3/4 is 0. If you wanted the
> remainder, you should ask for it. If you want to divide
> floating point numbers, you should _use_ floating point numbers.
>
> Perhaps my mind was warped by using nothing but integer
> arithmatic in my software for many years because floating point
> was simply too slow and too expensive.

Upon reading this and other threads on the subject I wondered why
apparently a number of people find 3/4 giving 0 odd, while I don't
remember ever having and certainly don't ever make a mistake against it.
But now I realise why. I too for many years used nothing but integers
because fp was, indeed, simply too slow. I even remember calculating
bezier curves for vector font outlines using only +, >> and << on ints,
because even integer multiplication was too slow.

Jan

Robin Becker

unread,
Jul 22, 2001, 8:23:43 PM7/22/01
to
In article <mailman.995836120...@python.org>, Moshe Zadka
<mos...@zadka.site.co.il> writes

>On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:
>
>> I agree. It's turning an otherwise fairly strongly (but dynamically)
>> typed language on its head. If I want type-changing operations, I'll do
>> them explicitly.
>
>Be sure to tell math.cos that...it has been "silently" turning integers
>into floats for years.
...
coercions and the like are a separate issue. the cos of 1.0 , 1/1 and 1
are all the same so it makes some sense to allow a conversion.

The 1/2 == 0 case is just as good if not better than the 1/2 == 0.5
case, it's probably slightly worse than the rational result case, but we
have many languages which treat integer division like python currently
so I would argue that it has some extra merit.

We hear many criticisms of basic on this list, but Dartmouth basic was
originally a teaching language. When I taught basic, C didn't exist and
Fortran, Algol and the like were considered too hard for non-programmer
university students.

The leadership seems to want to python become more available to a lower
grade of student than first year undergraduates.

I think that is wrong, but I use python in a professional capacity. I
think languages succeed or fail because they work for programmers.
Division in computers is always discrete (unless we ever manage to get
quantum things working).
--
Robin Becker

Erik Max Francis

unread,
Jul 22, 2001, 8:57:45 PM7/22/01
to
Moshe Zadka wrote:

> Be sure to tell math.cos that...it has been "silently" turning
> integers
> into floats for years.

Sure, but that's something different. The domain of math.cos (and so
on) is floats, not ints, so if you pass it an int you very sensibly get
coercion to an float, because that's what you must have really meant.

That's quite different from the current case, where we're talking about
an operation that will return different types depending on the inputs.
I don't see any good reason to change the current behavior; / means
division over the types that are passed in. If you pass in floats, you
want float division. If you pass in ints, you want integer division.

> Err.....problem with the URL?.

Sorry, lazily pasted something into my .sig database. It was meant to
be:

http://www.alcyone.com/max/lang/esperanto/

--
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
REALpolitik / http://www.realpolitik.com/
Get your own customized newsfeed online in realtime ... for free!

Tim Peters

unread,
Jul 22, 2001, 8:10:47 PM7/22/01
to pytho...@python.org
[Tim]

> The current integer division loses information silently and without
> a trace.

[Grant Edwards]
> No, it doesn't.

Of course it does, but note that I'm using "information" in its technical
sense. Current int division is a many-to-one mapping, so necessarily loses
information. Loss of information is often a good thing (like, losing most
of the repetitions of these old arguments would be a good thing <0.5 wink>),
but silent loss by default is generally bad design.

> Integer division is integer division. The correct answer for the
> value of 3/4 is 0.

If Guido has his druthers, the correct answer for 3//4 will be 0. It's not
the *operation* but the *spelling* he's seeking to change.

> If you wanted the remainder, you should ask for it. If you want to
> divide floating point numbers, you should _use_ floating point numbers.

Whether 1/2 would return a float is still open.

> Perhaps my mind was warped by using nothing but integer arithmatic
> in my software for many years because floating point was simply too
> slow and too expensive.

Or maybe you needed integer semantics -- I can't guess. Doesn't much matter
to the current debate. If you bought a hand calculator that truncated
division results to integers, would you be happy with that? That's what
informs the expectations of the generations after us.


Tim Peters

unread,
Jul 22, 2001, 8:27:16 PM7/22/01
to pytho...@python.org
[David Eppstein]

> My intuition is that the users who will be surprised that 1/2 = 0 are
> the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.

Anyone using floats will get bitten eventually; ditto anyone using
rationals, for that matter. This is a "lesser of evils" thing more than a
"good vs evil" thing.

> Result: buggier code since the errors are less obvious.

Perhaps; I don't know of evidence one way or the other, and don't put much
stock in "head arguments" predicting programmer behavior. I've never heard
that, e.g., Pascal programs were especially prone to numerical bugs (a
language in with 1/2 does return 0.5; and I did work on a vector Pascal
compiler for Cray Research, so it's not that I've heard nothing at all about
Pascal in numeric contexts). I haven't heard knocks against Algol 60 on
this count either, which for several years was the de facto standard for
publishing numeric algorithms (and in which int/int also returned a real; it
had a different operator for int division).

> If you have a routine "velocity" in which it doesn't make sense to do
> integer truncation, and it doesn't coerce its args to float by
> adding 0.0, that's also a bug.

According to who? Routines are often *used* in ways authors didn't
anticipate, and a dynamic language (like Python) encourages that. The
current rules for "/" work against it.


Tim Peters

unread,
Jul 22, 2001, 8:39:43 PM7/22/01
to pytho...@python.org
[James Logajan]
> ...

> Speaking of patterns, it unfortunately appears that Guido has a
> strong tendency to take the existing user base for granted, since he
> continues to keep the door open to code-breaking changes.

I'd say it's more the case that people project their particular concerns on
to the entire Python user base, and somehow mistake disagreement for being
ignored. As I said before, Guido hears *all* the complaints, and, believe
it or not, the Python user base is composed of people, and people don't
agree. It's Guido's job to make the best sense he can out of conflicting
desires (including but not limited to his own).

> There is only so much insult ("well, what you were doing was bad style
> anyway," or "you shouldn't have written code that depends on integer
> division(!)") and injury (the more Python you've written, the more
> likely something you wrote wont work with the latest version and will

> need to spend hours reviewing,just-in-case-anyway) before one decides


> that it just isn't worth the pain.

Of course. Do you seriously think Guido is unaware of that? OTOH, do you
seriously think 100% backward compatibility is an absolute criterion, immune
from competition with other claims?

> I do not want to continue to write more Python and expose myself
> to further risk of having it either become dependent on an un-maintained
> and minority release (e.g. "sorry, you should have upgraded to 3.1 years
> ago; who writes stuff on 2.1 these days anyway?") or having a growing
> body of code to constantly shepherd along to insure it runs on the next
> release.

Your choice, but my guess is that Guido has done an excellent job of
maintaining backward compatibility so far (he burned me by changing
str(long) to stop producing a trailing "L", and I must have spent nearly 20
minutes recovering from that -- BFD).

> That is the pragmatics from my point of view. And it doesn't give a
> damn what real or perceived "flaw" in the language is being addressed.

OK, I'll save this msg for the next time you ask for a change <0.9 wink>


Erik Max Francis

unread,
Jul 22, 2001, 9:00:45 PM7/22/01
to
Robin Becker wrote:

> The leadership seems to want to python become more available to a
> lower
> grade of student than first year undergraduates.
>
> I think that is wrong, but I use python in a professional capacity. I
> think languages succeed or fail because they work for programmers.
> Division in computers is always discrete (unless we ever manage to get
> quantum things working).

I couldn't agree more. Certainly there's no reason for a language to be
deliberately opaque, but the goal of the language (except a language
primarily intended for education) should be for programmers to get their
job done.

A good beginning programming language is one that has a simple syntax
and straightforward rules to follow. Python already qualifies in that
capacity very well; I don't see any reasons to "dumb down" Python any
further in order to try to make Python easier for "non-programmers"
(non-programmers won't be programming anyway! :-) to use in areas where
the benefit to non-programmers will be questionable in the first place.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

Grant Edwards

unread,
Jul 22, 2001, 10:46:07 PM7/22/01
to
On Sun, 22 Jul 2001 20:10:47 -0400, Tim Peters <tim...@home.com> wrote:
>[Tim]
>> The current integer division loses information silently and without
>> a trace.
>
>[Grant Edwards]
>> No, it doesn't.
>
>Of course it does, but note that I'm using "information" in its technical
>sense. Current int division is a many-to-one mapping, so necessarily loses
>information.

Right, but the same is true for float division. Therefore, the
fact that integer division loses information isn't a valid
reason to prefer floating point division for the "/" operator
when it is used on two integers.

int + int => int
int * int => int
int - int => int
int & int => int
int | int => int

[so far, so good]

int / int => int
or
int / int => float

Which of the two is the least astonishing? In my mind, the
"int" result is the least astonishing, but like I said, I'm
quite used to using integer arithmetic, and if I want floats,
I use floats.

>Whether 1/2 would return a float is still open.

Right. IMO, having operators coerce their operands like that
is too much like the "magic" that goes on in Perl. I suppose
it's only a bit worse that 1/2.0 coercing the "1" to a float,
but I'm not too kean on _that_ either. ;) Quite a few hours of
debugging time could have been saved over the past 30 years if
1/2.0 wasn't legal in C.

I'd be pretty happy if mixing a float and an int threw an
exception. When I run lint on C programs, I usually want it to
complain about that sort of thing. I don't generally like types
changing "automagically" behind the scenes.

>Or maybe you needed integer semantics -- I can't guess. Doesn't
>much matter to the current debate. If you bought a hand
>calculator that truncated division results to integers, would
>you be happy with that?

Mine does. If it didn't I'd toss it in the trash. Of course
the operands are always integers, so it's not that surprising.
There's a way to get it to do floating point, but I don't do
that very often.

>That's what informs the expectations of the generations after
>us.

Kids these days...

--
Grant Edwards grante Yow! I'm in direct contact
at with many advanced fun
visi.com CONCEPTS.

Steve Williams

unread,
Jul 22, 2001, 10:49:52 PM7/22/01
to
Tim Peters wrote:

> [snip]

>
> > i-always-blamed-cauchy-and-weirstrass-for-tormenting-the-world-
> > with-epsilons-and-deltas-ly y'rs, Z.
>
> i-personally-blame-guido-for-letting-it-stand<wink>-ly y'rs - tim

Yes, yes. Let's stop nattering about wedging division into the ring of
integers (1/2 is undefined, not 0, right?) and get on with adding the
hyperreals to Python.

John W. Baxter

unread,
Jul 22, 2001, 10:59:36 PM7/22/01
to
In article <mailman.995836120...@python.org>, Moshe Zadka
<mos...@zadka.site.co.il> wrote:

> > I agree. It's turning an otherwise fairly strongly (but dynamically)
> > typed language on its head. If I want type-changing operations, I'll do
> > them explicitly.
>
> Be sure to tell math.cos that...it has been "silently" turning integers
> into floats for years.

Not really the same thing, because within the range of int (on most
machines so far), no information is lost (always assuming we mean
double when we say float, which we seem to).

Also unlikely, in that the argument is in radians, and 1 radian (or 1.0
radian) isn't a particularly interesting value (at least for the things
I do..."broad on the starboard quarter" would be my more typical
approximation, although it's perhaps a half point off).

By the way, in .../lib/module-math.html (I keep my own copy on my end
of my 56K frame connection), it is not stated whether the input to
sin() (and the others where it applies) is degrees or radians. An
experiment is necessary, or a reference to my rapidly waning C
knowledge or a visit to the C standard (which I'd rather not do, for
reasons of marginal sanity).

>>> math.sin(1)
0.8414709848078965

is a conclusive experiment...which I had to run before making the "also
unlikely" claim.

--John

John W. Baxter

unread,
Jul 22, 2001, 11:39:32 PM7/22/01
to
In article <mailman.995826216...@python.org>, Tim Peters
<tim...@home.com> wrote:

> Not all experienced programmers agree. At the last Python Conference, I
> moderated a 40-some person group discussion on conceivable changes to
> Python's numeric model, not advocating but keeping the participants from
> killing each other <wink>. The meaning of integer division wasn't the
> focus, but naturally came up. By show of hands, about 3/4ths of the
> participants agreed that 3/4 should not return 0, but rather *something* x
> such that x*4 had a better chance of being confused with 3 than with 0.
> There was no consensus on exactly what 3/4 should return -- rational or HW
> float or decimal float were the most popular alternatives.

I see a fairly strong argument there for starting out with a language
in which int / int --> float (or rational) and int // int --> int (or
int div int --> int).

I don't see it as a strong enough argument to overcome the fact that
the careful programmer will have to inspect every / in all the code,
before installing 2.3 or whatever version this happens in, to see
whether (a) it IS division, as opposed to the / in
'<a href="6/7.html">' (that's contrived...but possible) and if so
whether it has to be respelt as // (or div).

Some of them will; some won't: some of both outcomes indicate latent
errors in the code, so the inspection isn't completely wasted after
all.

And it may not be her code...she could be 3 or 4 people removed from
the creator, who is gone. [Another good thing about finding the latent
errors.]

It's true--as stated elsewhere--that Guido hears all the complaints.
It's also true that until recently there was no reason for Guido to
hear "Guido, thank you for defining int / int to be integer division,
because integer division is natural for my problem space." So he's
been getting a biased sample. Probably a fairly representative one
even so.

--John

Andy Salnikov

unread,
Jul 22, 2001, 11:42:10 PM7/22/01
to

"Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
news:vyIKbWAP...@jessikat.fsnet.co.uk...

>
> I think that is wrong, but I use python in a professional capacity. I
> think languages succeed or fail because they work for programmers.

Yeah, completely agree. Personaly, if this change happens, it will be a big
revolt from Python for me. Not only for aesthetic reasons, simply because I
cannot rely on the language which dares to change the meaning of existing
operators. What do you think will be next? Change assignment to work like a
copy, because there are many people confused with the reference semantic? I
almost hear how manager staff saying: "Do you talk about that sh**ty snake
language which changes its rules every year? Don't even think about it in
our project!"

Guys, if you really need something returning floats for division, make it
new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
0.5.

Cheers,
Andy.


Rainer Deyke

unread,
Jul 22, 2001, 11:56:09 PM7/22/01
to
"Tim Peters" <tim...@home.com> wrote in message
news:mailman.995848124...@python.org...

> [David Eppstein]
> > My intuition is that the users who will be surprised that 1/2 = 0 are
> > the same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
>
> Anyone using floats will get bitten eventually; ditto anyone using
> rationals, for that matter. This is a "lesser of evils" thing more than a
> "good vs evil" thing.

"Good" would be a language without built-in support for non-integer numbers,
and therefore no source of confusion. Those who really need them could use
an extension module.


--
Rainer Deyke (ro...@rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor


Donn Cave

unread,
Jul 23, 2001, 12:06:30 AM7/23/01
to
Quoth "John W. Baxter" <jwba...@spamcop.com>:
...

| By the way, in .../lib/module-math.html (I keep my own copy on my end
| of my 56K frame connection), it is not stated whether the input to
| sin() (and the others where it applies) is degrees or radians. An
| experiment is necessary, or a reference to my rapidly waning C
| knowledge or a visit to the C standard (which I'd rather not do, for
| reasons of marginal sanity).
|
| >>> math.sin(1)
| 0.8414709848078965
|
| is a conclusive experiment...which I had to run before making the "also
| unlikely" claim.

Right! and I don't think it's what the common folk expect either.
Someone should write up a PEP to change these functions to take
degrees (not on my account, but it would seem to be a potential
stumbling block for the uninitiated, wouldn't it?)

Donn Cave, do...@drizzle.com

Terry Reedy

unread,
Jul 23, 2001, 12:22:32 AM7/23/01
to
> It [int/int->int] can be useful for many things; that's not at
issue,

Actually, it did seem to be an issue when a couple of people seemed to
suggest that some of us were mentally unbalanced in thinking that
integer quotients are the right and useful result for int/int.

>and nobody has ever proposed taking away the ability to get an
integer result;
> the issue is how to spell that.

And that issue was *not* spelled out in the PEP.

Actually, as I mention in my article today 'A use for integer
quotients', I thought that one version of the proposal *was* to take
away the current spelling without providing any replacement. That is
what I argued most strenously against.

I know that one version of the proposal was to provide an
*unacceptible* (to me) replacement -- div(i,j). Guido appeared to
maybe even favor it until I pointed out that an infix replacement
would make fixing current code *much* easier.

This gets to the issue of what is a proper PEP. Simply saying 'I
don't like the current situation; lets replace it with something' is
not, in my opinion. The only thing definite that I remember from
reading PEP 238 was to change the result of int/int to float. Then
maybe add div() [awful], div [possible], // [best in my opinion],
something else [???], or, at least by implication, nothing
[horrendous]. It is hard compare something definite (the current
situation, whatever it is) to a nebulosity, especially when the range
of alternatives floating around the nebula range from horrendous to
maybe ok.

If 238 had been written originally something like the following (which
it now is), I would have argued *much* less.

Situation: Python '/' currently overloads and confounds two arithmetic
operations: whole-number result division and fractional result
division. This confuses some people.
Proposal: Make '/' consistently mean fractional division and introduce
a new operator '//' for truncated-result division.
Acknowledgement: This semantic replacement is a bit different from
most any previous change to Python. Extra care will be needed to make
the transition as smooth as possible.

(Just noticed: http://python.sourceforge.net/peps/pep-0238.html
now proposes a *2 year* int/int warning period starting with 2.3. It
still needs a stipulation that someone write an intdiv checker to help
automate replacements.)

Terry J. Reedy

Donn Cave

unread,
Jul 23, 2001, 12:24:58 AM7/23/01
to
Quoth "Tim Peters" <tim...@home.com>:
...

| Of course, but computer numerics is a massive exercise in picking the
| general rules you want to preserve at the expense of others, and trading all
| that off against pragmatics too. Not losing information silently is also a
| Very Good General Rule, and even 745 binary fp arithmetic is better at
| meeting that one than current "/".

So would it make sense to also change the >> and << operators to
rotate shift? I mean, I sure wouldn't find that more useful, but
it does conserve information that the current shifts lose.

Donn Cave, do...@drizzle.com

Terry Reedy

unread,
Jul 23, 2001, 12:52:26 AM7/23/01
to
> Guys, if you really need something returning floats for division,
make it
> new operator, I guess everyone could be made happy with 1/2 == 0 and
1//2 ==
> 0.5.

I can sympathize with the people who have suggested this alternative,
but it strikes me as making things worse in a way. The current
situation is this: '/' mixes two types of division -- fractional
result and integer result. This is fine with me, but I can understand
some having a problem.

Moshe's current proposal cleanly separates the two types: '/' will be
fractional result and '//' will be integer result (including
floor(float/float)). So 8/3 = 8.0/3.0 = 2.33333, while 8//3 = 2 and
8.0//3.0 = 3.0, which is the same to within type, just as 3+8 ==
(withing type) 3.0+8.0. (I am not sure about complex//complex since I
an not sure if floor(complex) is defined -- floor(x) + floor(y)*j?)
This is arguably what Python should have started with.

Adding '//' as a pure fractional division operator while '/' remains a
mixed division operator strikes me an unaesthetic and more confusing
than the current situation. Why the two half redundant operators?
newcomers might rightly wonder.

Terry J. Reedy

Moshe Zadka

unread,
Jul 23, 2001, 12:03:06 AM7/23/01
to David Eppstein, pytho...@python.org
On Sun, 22 Jul 2001 16:27:32 -0700, David Eppstein <epps...@ics.uci.edu> wrote:

> My intuition is that the users who will be surprised that 1/2 = 0 are the
> same ones who would be bitten by roundoff-error bugs if 1/2 = 0.5.
> Result: buggier code since the errors are less obvious.

The thing is, making 1/2=0.5 won't make the problem *worse*. Because
after two days of being baffled by 1/2=0, these newbies will eventually
figure out the solution float(1)/2. So, I'm just getting to show them
the buggy roundoff-error code *faster*, instead of making them suffer
for it. You want to fix *that* problem, you have to give easy to access
rationals.

> If you have a routine "velocity" in which it doesn't make sense to do
> integer truncation, and it doesn't coerce its args to float by adding 0.0,
> that's also a bug.

velocity(1+2j, 3)
--
gpg --keyserver keyserver.pgp.com --recv-keys 46D01BD6 54C4E1FE
Secure (inaccessible): 4BD1 7705 EEC0 260A 7F21 4817 C7FC A636 46D0 1BD6
Insecure (accessible): C5A5 A8FA CA39 AB03 10B8 F116 1713 1BCF 54C4 E1FE

Tim Peters

unread,
Jul 23, 2001, 12:16:19 AM7/23/01
to pytho...@python.org
[Tim]

> Not all experienced programmers agree. At the last Python Conference, I
> moderated a ... group discussion ... By show of hands, about 3/4ths of

> the participants agreed that 3/4 should not return 0, but rather
> *something* x such that x*4 had a better chance of being confused
> with 3 than with 0.

[John W. Baxter]


> I see a fairly strong argument there for starting out with a language
> in which int / int --> float (or rational) and int // int --> int (or
> int div int --> int).

I don't consider a vote an argument. At best, since it was a visible show
of hands, it let everyone know who wasn't worthy to live due to voting the
wrong way <wink>.

> I don't see it as a strong enough argument

It's not an argument at all -- it was in response to Arther asking whether
experienced programmers would favor such a change (and, yes, some would).

> to overcome the fact that the careful programmer will have to inspect
> every / in all the code, before installing 2.3 or whatever version
> this happens in, to see whether (a) it IS division, as opposed to
> the / in '<a href="6/7.html">' (that's contrived...but possible)

Guido suggested building a tool on top of the tokenize module; it reliably
distinguishes "/" as an operator from all other occurrences of "/"; no false
leads.

> and if so whether it has to be respelt as // (or div).

I probably use integer division more than most, and that job looks trivial
to me -- but then I *understand* my algorithms, and "it's obvious" in each
case which I intended. If this happens, the transitional release should
also produce runtime warnings pinpointing lines where "/" is applied to
integer arguments, so if you've got good unit tests nothing will be missed.

> Some of them will; some won't: some of both outcomes indicate latent
> errors in the code, so the inspection isn't completely wasted after
> all.
>
> And it may not be her code...she could be 3 or 4 people removed from
> the creator, who is gone. [Another good thing about finding the latent
> errors.]
>
> It's true--as stated elsewhere--that Guido hears all the complaints.
> It's also true that until recently there was no reason for Guido to
> hear "Guido, thank you for defining int / int to be integer division,
> because integer division is natural for my problem space." So he's
> been getting a biased sample. Probably a fairly representative one
> even so.

Don't forget that this has been debated repeatedly over the course of
several years. Most people drop out of these things after the fifth time
<0.5 wink>.

what-i-can't-tolerate-is-making-division-case-sensitive-ly y'rs - tim


Moshe Zadka

unread,
Jul 23, 2001, 12:13:26 AM7/23/01
to Erik Max Francis, pytho...@python.org
On Sun, 22 Jul 2001 17:57:45 -0700, Erik Max Francis <m...@alcyone.com> wrote:

> That's quite different from the current case, where we're talking about
> an operation that will return different types depending on the inputs.
> I don't see any good reason to change the current behavior; / means
> division over the types that are passed in.

It does? I fail to see why people assume that operations *have* to return
the type of their operands. In this case, succumbing to this rule means
that we violate much more important, IMHO, rules, like

>>> a==b
1
>>> c==d
1
>>> a/c == b/d
0

(the part before that is:
Python 2.1 (#1, Apr 27 2001, 01:24:08)
[GCC 2.95.3 20010219 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> a,b,c,d=1,1.,2,2.

Of course)

> If you pass in ints, you want integer division.

I do?

> Sorry, lazily pasted something into my .sig database. It was meant to
> be:
>
> http://www.alcyone.com/max/lang/esperanto/

Thanks!

Craig Markwardt

unread,
Jul 23, 2001, 1:53:34 AM7/23/01
to

"Tim Peters" <tim...@home.com> writes:
> [John W. Baxter]
> > I see a fairly strong argument there for starting out with a language
> > in which int / int --> float (or rational) and int // int --> int (or
> > int div int --> int).
>
> I don't consider a vote an argument. At best, since it was a visible show
> of hands, it let everyone know who wasn't worthy to live due to voting the
> wrong way <wink>.
> ...

I'll decloak here for a moment. I'm an IDL user, as in Interactive
Data Language by RSI, but I mostly admire Python from afar, and read
the newsgroup. I can relate the community experience of the upgrade
between IDL version 4 and version 5.

In the new version, IDL gained an *optional* language change. IDL 5
allows users to subscript arrays with either the square brackets [] or
the round parentheses (). IDL 4 only allowed the round parentheses.

As a result of this, people began coding both styles. However, the
new style was not backwards compatible, so there was some
fragmentation. Some major standard libraries were, and are still,
maintained in two forms.

Overall, from introduction to acceptance, the change took about 2-3
years. This change was thankfully optional. I am very grateful that
I can still pull up useful IDL archive code from ten or more years
ago, written by someone long gone, and usually have it run
successfully.

Thus, I am dismayed to hear about a Python language change that will
*not* be optional, and which will break the function of existing code.
Doing so will eventually place people in the unenviable quandry of
either upgrading their Python interpreter, or tossing out a tried and
tested library module.

Other language enhancements, like nested scopes, add features at the
expense of resolving language ambiguities. The proposed integer
division change is an outright language change, and impacts a core
functionality: arithmetic. Quite frankly, I am baffled.

Craig

--
--------------------------------------------------------------------------
Craig B. Markwardt, Ph.D. EMAIL: crai...@cow.physics.wisc.edu
Astrophysics, IDL, whatever else
--------------------------------------------------------------------------

Tim Peters

unread,
Jul 23, 2001, 1:08:03 AM7/23/01
to pytho...@python.org
[Tim]

> Of course, but computer numerics is a massive exercise in picking the
> general rules you want to preserve at the expense of others,
> and trading all that off against pragmatics too. Not losing information
> silently is also a Very Good General Rule, and even 745 binary fp
> arithmetic is better at meeting that one than current "/".
>

[Donn Cave]


> So would it make sense to also change the >> and << operators to
> rotate shift? I mean, I sure wouldn't find that more useful, but
> it does conserve information that the current shifts lose.

First explain what bitstring operations have to do with computer numerics.
You may as well as complain that, e.g., "del a[i]" loses information too.
Well, of course it does -- that's its purpose. Same thing with >>. << does
not lose info on longs, and it is indeed a source of bugs that it may lose
info on ints (the result is platform-dependent in Python).


Greg Ewing

unread,
Jul 23, 2001, 2:18:43 AM7/23/01
to
Arthur...@rsmi.com wrote:
>
> If I was told that experinced programmers might
> appreciate this change for any possible reason -
> I'd be quiet as a mouse.

I'm an experienced programmer, and I appreciate the
change on the grounds that different operations on
the same data should be spelled differently.

You may lapse into silence now. :-)

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

Stephen Horne

unread,
Jul 23, 2001, 2:39:07 AM7/23/01
to
On Sun, 22 Jul 2001 16:22:54 GMT, Guido van Rossum <gu...@python.org>
wrote:

>discussed many times before. The summary of the argument in the PEP
>may not be complete, but I disagree with Arthur's assessment that
>integer division is not a problem -- the VPython folks have ample
>experience that it is.

The PEP says virtually nothing. It simply claims that 1/2 giving 0
creates a hump in the learning curve. The only questions answered are
the ones about not creating a div keyword or function - which I don't
believe anyone is contesting.

The bit about coercing to floats rarely if ever happens - if you are
dealing with float values then that is most likely what the variables
you are using hold. If you need a float literal, all it needs is to be
written as a float - simple, clear and it works.

I doubt that anyone ever got through school without learning about
integer division and remainders - most children learn that before they
learn long division, let alone fractions and decimals, so all they
should need is a reminder.

People only experience their first day of something new *once*.
Really, this cannot be considered a problem. A five minute explanation
- if that - says all that needs to be said. Hell - even my mum
understands integer division, and she regularly confuses the size of
her machines RAM and hard disk!

Integer division is claimed to be a major stumbling block in user
testing - what does that mean exactly? Has formal user testing been
done? Just how confused were people? Were these the same people who
tried to put full stops and the end of their 'scentences'? Do you
simply count the frequency that a question is asked, or do you make an
allowance for how easily it is sorted out? Have you done *any* user
testing with the alternate implementation?

As for a few professional programmers occasionally making mistakes -
surely that means the vast majority get it right most of the time,
which suggests the current version is correct. There is a good chance
that those from Pascal and Modula 2 backgrounds who've rarely if ever
used other languages might be temporarily confused, and might get
things wrong a while after from force of habit. But what about all
those from C, C++, Java, Ada, BASIC - and don't forget, Visual BASIC
has been the most popular professional programming language for
several years - not to mention the VBScript and JavaScript used by all
those web developers, and even VBA in Microsoft Excel.

Pascal is a half dead language. It is currently achieving significant
success only as Delphi - a non-standard, single-vendor implementation
that - despite being a commercial product - has to be given away free
on magazine CD ROMs in order to keep people using it. Is that what we
want to emulate?

Surely the professional programmers who expect 1/2==0.5 are a
minority.

Look at all the algorithms that *require* integer division to give an
integer result - anyone who has so much as binary searched an ordered
list or tuple is going to have *BIG* problems.

>Because all Arthur does is tick me off, I'll leave it at this -- maybe
>someone else can explain it all to him.

I have no idea about Arthur, but the PEP explains virtually nothing
about the reasons and the idea that it will actually be done scares
the hell out of me. After the time I spent convincing my employer to
let me use Python internally, you now want me to throw away all the
productivity gains and more trying to sort out the results of this
change - *and* you want me to explain it to my boss! Maybe a slightly
better reason is needed than 'newbies are often a bit confused for
five minutes or so'.

I don't remember ever contributing to threads on this topic before - I
just kind of assumed the idea was laughable on those occasions when
I've seen it, and I expect I usually missed it because I only
occasionally follow the group. I'll bet there are a lot of people like
me who never really believed this would happen, and are going to go
ballistic if it does.

If we can't rely on a fundamental operator to work the same from one
release to the next, then Python is going to be reduced to a joke. It
is going to be causing surprise bugs for years to come as people
upgrade there old 1.5.2 installations - many times, the programmer
will have since left the company and there won't be anyone there to
fix it. Just think of the impact that will have on Pythons reputation.

If there really needs to be a division operator that returns floats
with all-integer arguments, *that* is the new functionality and *that*
should be the new operator. The idea of a division operator that
returns an integer when given float arguments is just plain daft, so
the existing division operator works fine for integers whatever
viewpoint anyone takes.

If this is about people in the pro-PEP0238 camp not wanting to have to
use // for their precious operator - why the hell should it be forced
on the anti-PEP0238 camp?

Stephen Horne

unread,
Jul 23, 2001, 2:39:13 AM7/23/01
to
On Sun, 22 Jul 2001 17:40:10 GMT, si...@optonline.net (Rainy) wrote:

>First of all, it's really ugly. It's the ugliest thing in python for a newbie,
>imho. Yes, 1/2 is 0. You have to type 1.0/2 to get 0.5. No, there is no good
>reason for that, just memorize it. Ugh.

No reason!

Every five-year-old knows that 5 divided by 2 is 2 remainder 1. What
is the problem?

Integer division *is* important. Confusing integers and floats is a
sign of sloppy thinking, and a clue that far more bugs are going to
result.

Furthermore, Python is unlikely to *ever* be the only computer
language, and most Python users use other languages as well - that is
the nature of scripting languages. Surely we should comply with
conventions used in the languages we know are unlikely to die - those
which are already popular multi-vendor languages, and those which have
such powerful single-vendor backing that they are unlikely to
disappear. That means the likes of C, C++, Java and Visual BASIC. And
what about the languages web developers are used to, such as VBScript
and JavaScript.

Stephen Horne

unread,
Jul 23, 2001, 2:39:15 AM7/23/01
to
On Mon, 23 Jul 2001 10:42:10 +0700, "Andy Salnikov"
<saln...@inp.nsk.su> wrote:

>
>"Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
>news:vyIKbWAP...@jessikat.fsnet.co.uk...
>>
>> I think that is wrong, but I use python in a professional capacity. I
>> think languages succeed or fail because they work for programmers.
>
>Yeah, completely agree. Personaly, if this change happens, it will be a big
>revolt from Python for me. Not only for aesthetic reasons, simply because I
>cannot rely on the language which dares to change the meaning of existing
>operators. What do you think will be next? Change assignment to work like a
>copy, because there are many people confused with the reference semantic? I

EXACTLY.

I do, in fact, occasionally get confused by the reference behaviour in
Python - expecting copies and getting references and visa versa,
especially when I havn't used it for a while. I'm used to being
explicit about when I'm dealing with references, and occasionally
having something behave as a reference when I didn't tell it to can be
a surprise. But I wouldn't propose changing this in a million years -
too much code would break.

There is only one other way I'd accept this change quietly. Support
some kind of version declaration in source files - a bit like 'from
__future__ import', but not implying the new behaviour will be
standard in the next version up.

How about...

from __standards__ import v22_base, sloppy_thinking_division

It should not prevent the use of new constructs, but new semantics for
old syntax should only occur if requested.

It would still leave a bad taste, but at least it doesn't mean
spending months debugging code that currently works.

>Guys, if you really need something returning floats for division, make it
>new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>0.5.

Absolutely. I could *ignore* that ;-)

In fact, document '//' as the alternative for the traditional division
sign '÷'. If it really is for the benefit of newbie non-programmers to
delay the integer division lesson until it can really bite them -
maybe when they first learn binary searches and can't figure out why
theirs never terminates, for instance - then they are probably just as
shocked not to have a ÷ symbol anyway.

Stephen Horne

unread,
Jul 23, 2001, 2:39:14 AM7/23/01
to
On Mon, 23 Jul 2001 00:00:53 +0300, Moshe Zadka
<mos...@zadka.site.co.il> wrote:

>On Sun, 22 Jul 2001 13:24:22 -0700, Erik Max Francis <m...@alcyone.com> wrote:
>
>> I agree. It's turning an otherwise fairly strongly (but dynamically)
>> typed language on its head. If I want type-changing operations, I'll do
>> them explicitly.
>
>Be sure to tell math.cos that...it has been "silently" turning integers
>into floats for years.

Implicit typecasting is not the issue. Even C and C++ support implicit
typecasting - that does not mean the integer operations give float
results, which is a completely separate issue.

Erik Max Francis

unread,
Jul 23, 2001, 2:36:51 AM7/23/01
to
Moshe Zadka wrote:

> It does? I fail to see why people assume that operations *have* to
> return
> the type of their operands.

It's not a requirement, but integer division is very frequently used.
An operation that's closed on the types of its arguments is always easy
to understand, consistent with many other programming languages that do
such integer division, and is already the way things work.

--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE

/ \ There is nothing stronger in the world than gentleness.
\__/ Han Suyin
Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/
A highly categorized list of Web links.

Stephen Horne

unread,
Jul 23, 2001, 2:39:16 AM7/23/01
to
On Mon, 23 Jul 2001 04:06:30 -0000, Donn Cave <do...@drizzle.com>
wrote:

Of course - and the chaos that would cause for people working with
engineering or mathematical notations where radians are natural
irrespective of the language or even the use of a computer should of
course be completely ignore ;-)

Stephen Horne

unread,
Jul 23, 2001, 2:39:16 AM7/23/01
to
On Mon, 23 Jul 2001 01:31:14 +0100, Jan Dries <jdr...@mail.com> wrote:

>Grant Edwards wrote:
>> No, it doesn't. Integer division is integer division. The
>> correct answer for the value of 3/4 is 0. If you wanted the
>> remainder, you should ask for it. If you want to divide
>> floating point numbers, you should _use_ floating point numbers.
>>
>> Perhaps my mind was warped by using nothing but integer
>> arithmatic in my software for many years because floating point
>> was simply too slow and too expensive.
>
>Upon reading this and other threads on the subject I wondered why
>apparently a number of people find 3/4 giving 0 odd, while I don't
>remember ever having and certainly don't ever make a mistake against it.
>But now I realise why. I too for many years used nothing but integers
>because fp was, indeed, simply too slow. I even remember calculating
>bezier curves for vector font outlines using only +, >> and << on ints,
>because even integer multiplication was too slow.

Surely it goes deeper than that?

Children learn to count integers very young, and they learn integer
division almost as soon as they start school. They learn about
remainders almost as soon. Fractions, decimals and scientific notation
don't come until much later. The confused expectation about getting
floats as a result instead of integers simply shows that a lot of
children forget the core principles on which their knowledge is based.

Tim Peters

unread,
Jul 23, 2001, 3:11:47 AM7/23/01
to pytho...@python.org
FYI, PEP 42 (the "small feature request" PEP) contains

- New math module radians() and degrees() functions.

Somebody quick add grads before Python becomes obsolete <wink>.


Tim Peters

unread,
Jul 23, 2001, 3:26:52 AM7/23/01
to pytho...@python.org
[]Stephen Horne]
> ...

> And what about the languages web developers are used to, such as
> VBScript and JavaScript.

Good thing you stopped before mentioning Perl (yes, 1/2 is 0.5 there) -- I'm
afraid the "mimic other languages" approach requires picking languages very
carefully if you want the illusion of consistency. By the way, 1/2 is also
0.5 in standard JavaScript:

http://www.el-mundo.es/internet/ecmascript.html

11.5.2 Applying the / operator

The / operator performs division, producing the quotient of
its operands. The left operand is the dividend and the right
operand is the divisor. ECMAScript does not perform integer
division. The operands and result of all division operations
are double-precision floating-point numbers. The result of
division is determined by the specification of IEEE 754
arithmetic:

yadda yadda yadda

produce-enough-frantic-arguments-at-random-and-some-are-likely-
to-backfire<wink>-ly y'rs - tim


Paul Boddie

unread,
Jul 23, 2001, 5:18:29 AM7/23/01
to
"Andy Salnikov" <saln...@inp.nsk.su> wrote in message news:<9jg6ei$ges7$1...@sky.inp.nsk.su>...

> "Robin Becker" <ro...@jessikat.fsnet.co.uk> wrote in message
> news:vyIKbWAP...@jessikat.fsnet.co.uk...
> >
> > I think that is wrong, but I use python in a professional capacity. I
> > think languages succeed or fail because they work for programmers.
>
> Yeah, completely agree. Personaly, if this change happens, it will be a big
> revolt from Python for me. Not only for aesthetic reasons, simply because I
> cannot rely on the language which dares to change the meaning of existing
> operators. What do you think will be next? Change assignment to work like a
> copy, because there are many people confused with the reference semantic?

Indeed. I think there's a significantly underestimated danger of
widespread code breakage in making such a fundamental change to the
language. While it may be disappointing to learn, or even consider,
that numerous working programs today may somehow depend on the
semantics of the / operator as it stands, we must still respect that
this situation exists.

Of course, it is also possible that some programs out there are
actually flawed because integer division is taking place where the
author intended that "floating point division" should occur, and where
arguments to the / operator were not anticipated to be, but can be,
integer. However, it is not up to the language architects to fix
people's programs for them - those programs were written according to
well-defined rules, and it is the obligation of the language
architects to maintain those rules.

> I almost hear how manager staff saying: "Do you talk about that sh**ty snake
> language which changes its rules every year? Don't even think about it in
> our project!"

I can see people seriously suggesting a "pythonfork" project if the
debate gets any more intense. :-O

> Guys, if you really need something returning floats for division, make it
> new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
> 0.5.

The most sensible suggestion yet! I was reading the previous messages
in this thread waiting for someone to suggest this, and it's about
time someone did! There's a lot of weight behind adding a new
operator, yet most people seem to advocate adding the // operator and
then *changing* the / operator... which is madness!

If beginners want an operator which behaves as they expect, they
certainly aren't going to have any preconceptions about what it's
going to look like - they are beginners, after all. Therefore, why
even bother suggesting changing the / operator? Just introduce // and
be done with it! Nothing gets broken, the beginners get their new
operator, and those wanting the C++ comment syntax in Python will just
have to be disappointed. ;-)

Paul

Steve Horne

unread,
Jul 23, 2001, 6:05:26 AM7/23/01
to
On 23 Jul 2001 02:18:29 -0700, pa...@boddie.net (Paul Boddie) wrote:

>I can see people seriously suggesting a "pythonfork" project if the
>debate gets any more intense. :-O

I've had idle thoughts for some time about a language that would allow
you to define - within the language itself - the syntax and semantics
for sublanguages. Only the lexical rules would be fixed, though there
would need to be several built-in sublanguages - grammar and
translation definition, simple compile-time imperative and simple
run-time imperative being the obvious ones. The thought was originally
provoked by wanting to support many different paradigms efficiently
and concisely in the same language - if anyone comes up with a new
paradigm, they just create a library that defines a suitable grammar
and translation and, hey presto, anyone can use it without changing
languages, and without discarding code written for other paradigms.

It suddenly seems so much more like a practical idea.

>> Guys, if you really need something returning floats for division, make it
>> new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>> 0.5.
>
>The most sensible suggestion yet! I was reading the previous messages
>in this thread waiting for someone to suggest this, and it's about
>time someone did! There's a lot of weight behind adding a new
>operator, yet most people seem to advocate adding the // operator and
>then *changing* the / operator... which is madness!

Agreed - I already made the same suggestion in the 'Future division
patch available (PEP 238) thread.

>If beginners want an operator which behaves as they expect, they
>certainly aren't going to have any preconceptions about what it's
>going to look like - they are beginners, after all. Therefore, why
>even bother suggesting changing the / operator? Just introduce // and
>be done with it! Nothing gets broken, the beginners get their new
>operator, and those wanting the C++ comment syntax in Python will just
>have to be disappointed. ;-)

I'll live ;-)

--
Steve Horne
Home : st...@lurking.demon.co.uk
Work : s...@ttsoftware.co.uk

Martijn Faassen

unread,
Jul 23, 2001, 6:47:08 AM7/23/01
to
Tim Peters <tim...@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?