proposed language change to int/int==float (was: PEP0238 lament)

229 views
Skip to first unread message

Skip Montanaro

unread,
Jul 23, 2001, 10:46:20 AM7/23/01
to Tim Peters, pytho...@python.org

(I changed the subject to make sure that people reading c.l.py are aware of
the ramifications of PEP 238 in case they haven't read it or this thread.)

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

Tim> If the language defines "/" as returning a float, then you told it
Tim> to.

The problem is all those places in my existing code I already told it to
divide two integers and return another integer. It's like George Bush
changing personal translators and starting to get subtly different meanings
from the statements Vladimir Putin makes. At first blush they may seem the
same, but every once in awhile the message comes out wrong.

I really don't understand the problem with teaching people new to Python
right from the get-go that when you divide two ints it works like grade
school long division. Unless my kids' educations were aberrant in some way
(they weren't raised on Mars), I think long division is still taught to
everyone in school somewhere along the way. It's not like it's a concept
completely foreign to people. After years of bit rot in their brains due to
calculator crutches they may need a minute to refresh, that should be all.

If Python had int/int==float from day one, nobody would be bitching about
it. It's just that there's all this code out there that already assumes
int/int==int that will have to be picked over if people are to upgrade to a
Python that says int/int==float. Probably nobody new to the language will
bitch about it, because they haven't got a lot of code to maintain that
makes the int/int==int assumption. To those of us who have to go back and
fiddle all our code, the proposed change seems very much like gratuitous
breakage. It's a bird-in-the-hand sort of thing. You're pissing off a
fairly significant fraction of the language's existing constituency in hopes
of attracting some non-programmers to the language who may not come anyway
for various other reasons.

Moshe, please make sure that when you update PEP 238 it includes this
problem and that it seems to be shared by many opponents to this change.

Skip

Steve Horne

unread,
Jul 23, 2001, 2:15:34 PM7/23/01
to
On Mon, 23 Jul 2001 09:46:20 -0500, Skip Montanaro <sk...@pobox.com>
wrote:

>completely foreign to people. After years of bit rot in their brains due to
>calculator crutches they may need a minute to refresh, that should be all.

My calculator supports integers - and not with a second integer
button, I just set the mode and it all works happy. I think it has
separate modulo and remainder functions as well - but the battery died
five years ago and I don't really remember.

At school, I once took a calculators test despite having forgot my
calculator that day. I finished in half the time anyone else did, and
was the only person to get a perfect result.

Intellectual decline is not what it used to be ;-) - apparently the
avarage childs IQ these days (I forget the exact age range) is around
120. Must it's all the TV and video games ;-)

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

Grant Edwards

unread,
Jul 23, 2001, 2:53:28 PM7/23/01
to
In article <tclolt053o18f8q0n...@4ax.com>, Steve Horne wrote:

>On Mon, 23 Jul 2001 09:46:20 -0500, Skip Montanaro
><sk...@pobox.com> wrote:
>
>>completely foreign to people. After years of bit rot in their
>>brains due to calculator crutches they may need a minute to
>>refresh, that should be all.
>
>My calculator supports integers - and not with a second integer
>button, I just set the mode and it all works happy.

And I'll bet cash money that the "integer divide" key and the
"float divide" key are one-in-the-same button. The operation
is determined by the type of the operands (the "mode").

What I don't understand is why polymorphism is all of a sudden
an evil, nasty thing in the Python world -- something that must
be banished at all costs (even if we have to change one of the
basic mathematical operators and break existing programs).

Are the rulers of the Python Kingdom going to ban all
polymorphism? I thought it was one of the _stregnths_ of
Python, and here we are trying to stamp it out!

--
Grant Edwards grante Yow! LBJ, LBJ, how many
at JOKES did you tell today??!
visi.com

Stephen Horne

unread,
Jul 23, 2001, 4:47:47 PM7/23/01
to
On Mon, 23 Jul 2001 18:53:28 GMT, gra...@visi.com (Grant Edwards)
wrote:

>In article <tclolt053o18f8q0n...@4ax.com>, Steve Horne wrote:
>
>>On Mon, 23 Jul 2001 09:46:20 -0500, Skip Montanaro
>><sk...@pobox.com> wrote:
>>
>>>completely foreign to people. After years of bit rot in their
>>>brains due to calculator crutches they may need a minute to
>>>refresh, that should be all.
>>
>>My calculator supports integers - and not with a second integer
>>button, I just set the mode and it all works happy.
>
>And I'll bet cash money that the "integer divide" key and the
>"float divide" key are one-in-the-same button. The operation
>is determined by the type of the operands (the "mode").

Oops - I meant "and not with a second divide button".

Been getting pissed off today, and my typing suffers under those
conditions.

Gareth McCaughan

unread,
Jul 23, 2001, 4:36:21 PM7/23/01
to
Grant Edwards wrote:

> What I don't understand is why polymorphism is all of a sudden
> an evil, nasty thing in the Python world -- something that must
> be banished at all costs (even if we have to change one of the
> basic mathematical operators and break existing programs).
>
> Are the rulers of the Python Kingdom going to ban all

> polymorphism? I thought it was one of the _strengths_ of


> Python, and here we are trying to stamp it out!

The different behaviour of "/" on floats and ints isn't
polymorphism, it's overloading. Two different operations.
Closely related, of course, but different. Generally
"polymorphism" is reserved for when what's being done
is "the same thing" in both cases.

Python doesn't generally object much to overloading either,
of course (def __div__(self, x): ...); and I find the
proposed change scary (what I wish is that Python had
made 1/2 give a rational from day 1, but it's too late
for that to happen unless Guido gets the time machine out
again). So I'm just quibbling.

--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc

Stephen Horne

unread,
Jul 23, 2001, 6:23:31 PM7/23/01
to
On Mon, 23 Jul 2001 21:36:21 +0100, Gareth.M...@pobox.com (Gareth
McCaughan) wrote:

>Grant Edwards wrote:
>
>> What I don't understand is why polymorphism is all of a sudden
>> an evil, nasty thing in the Python world -- something that must
>> be banished at all costs (even if we have to change one of the
>> basic mathematical operators and break existing programs).
>>
>> Are the rulers of the Python Kingdom going to ban all
>> polymorphism? I thought it was one of the _strengths_ of
>> Python, and here we are trying to stamp it out!
>
>The different behaviour of "/" on floats and ints isn't
>polymorphism, it's overloading. Two different operations.
>Closely related, of course, but different. Generally
>"polymorphism" is reserved for when what's being done
>is "the same thing" in both cases.

It *is* the same thing in both cases - float division is nothing more
than a logical extension of integer division. Even mathematicians know
that ;-)

Tim Peters

unread,
Jul 23, 2001, 10:51:03 PM7/23/01
to pytho...@python.org
[Skip Montanaro]
> ...

> I really don't understand the problem with teaching people new to
> Python right from the get-go that when you divide two ints it works
> like grade school long division.

I'm burned out on the repetition here. It's not a question of being hard to
teach. It's largely that it's never sensible for

x = y / z

buried in the middle of some routine to do truncating division if y and z
happen to be ints but best-possible division if they happen not to be ints.
It's this damage to polymorphism that hurts people in real life, and we've
had years of testimony about that on c.l.py (even in this incarnation of the
debate, although it's hard to find unless you read every msg).

This isn't a question of teaching the rules, it's that the specific rule
here is essentially braindead in a language without static type
declarations. If you read nothing else, read Guido's few messages on the
topic. He covers it all succinctly and accurately (and generally declines
to get sucked into endless repetition -- but why a point needs to be made
500 times on Usenet is beyond me).

> ...


> You're pissing off a fairly significant fraction of the language's
> existing constituency in hopes of attracting some non-programmers
> to the language who may not come anyway for various other reasons.

I don't detect any trace of that hypothesized motive in Guido. He wants to
repair what he has come to believe is a serious design error, and is
wrestling with ways to get that done. What a remarkably different world it
would be if people tried to help <wink>.


Chris Gonnerman

unread,
Jul 24, 2001, 12:48:33 AM7/24/01
to Tim Peters, pytho...@python.org
----- Original Message -----
From: "Tim Peters" <tim...@home.com>


> It's largely that it's never sensible for
>
> x = y / z
>
> buried in the middle of some routine to do truncating division if y and z
> happen to be ints but best-possible division if they happen not to be
ints.

I can grant that.

<hack hack hack>

> I don't detect any trace of that hypothesized motive in Guido. He wants
to
> repair what he has come to believe is a serious design error, and is
> wrestling with ways to get that done. What a remarkably different world
it
> would be if people tried to help <wink>.

Some of us have tried. Besides my alternative, I have seen two others which
allow case-by-case preservation of the old semantics where they may have
been
intended.

I have seen very few comments on them though (except from Stephen Horne).

ASSERTIONS:
1. Best-effort handling of division is desirable.
2. An explicit operator for truncating division is desirable
(as in, explicit is better than implicit).
3. Code breakage is bad, and difficult-to-detect code breakage
is worse.
4. Difficulty in writing backwards-compatible code is bad (thus,
code to implement partitioning of a dataset would naturally use
the // operator in 2.2+ but would not be able to in pre-2.2,
so the div() function would have to be religiously used, hurting
readability).

Assertion 1 and 2 conflict with 3 and 4; #4 in particular bothers me. Many
have said that #3 is irrelevant as we have from 2.2 to 2.4 to fix it, but
I have upgraded several systems directly from 1.5.2 to 2.1 without
substantial
problems; going direct to 2.4 from 2.1 would not be so painless.

SOME way is needed to specify, in module scope, which set of mathematics
rules
should be enforced. Whatever method is used should (IMHO) be uniform from
2.2
to 2.4; my method, as given, is the only one where the code reads the same
from
2.2 on:

from __numerics__ import original # or standard, etc...

Just thinking about the implementation gives me headaches, but Guido and Co.
have readily implemented fancy things like the software-time-machine

from __future__ import phasers, warp_drive # or whatever

and so my proposal (or a mutation thereof) should be no biggie.

As I said, you can't honestly say we ALL haven't been trying. It's not that
I
object directly to the change, it's the overall plan/effect/semantics etc.
that
I don't like.

Stephen seems not to want to have to admit to his boss that Python has
changed
the basic rules for division of integers. I can grasp this... a proposal
like
mine, which allows for other numeric types to be dynamically added to the
language, would be an easier sell:

Boss: I heard Python was changing the rules for division of integers.
Are you sure we should be using such a stupid language?
SH: No, boss, you've got it all wrong. We have a new method for adding
numeric types, like rationals, fixedpoint, decimals, etcetera, and
is just happens that the default division mode changed as a
consequence. I can easily add a single line of code to any old
module
and Python will run it under the old rule. No fault, no foul.
Boss: Oh. Well, carry on.

Skip Montanaro

unread,
Jul 24, 2001, 12:45:05 AM7/24/01
to Tim Peters, pytho...@python.org

>> You're pissing off a fairly significant fraction of the language's
>> existing constituency in hopes of attracting some non-programmers to
>> the language who may not come anyway for various other reasons.

Tim> I don't detect any trace of that hypothesized motive in Guido. He
Tim> wants to repair what he has come to believe is a serious design
Tim> error, and is wrestling with ways to get that done. What a
Tim> remarkably different world it would be if people tried to help
Tim> <wink>.

And I did send a summary to Moshe of the objections to the current proposal
as I saw them, just not on the list where they'd get buried in the slew of
messages on the subject.

I think a lot of people feel that unlike most changes considered for Python,
scant attention is being paid to whether or not the proposed change will
break existing code. There's ample anecdotal evidence to suggest that this
will break a lot of code and require a fair amount of effort just to check
code that is probably correct.

Skip


Stephen Horne

unread,
Jul 24, 2001, 3:42:26 AM7/24/01
to
On Mon, 23 Jul 2001 23:48:33 -0500, "Chris Gonnerman"
<chris.g...@newcenturycomputers.net> wrote:

>Stephen seems not to want to have to admit to his boss that Python has
>changed
>the basic rules for division of integers. I can grasp this... a proposal
>like
>mine, which allows for other numeric types to be dynamically added to the
>language, would be an easier sell:
>
> Boss: I heard Python was changing the rules for division of integers.
> Are you sure we should be using such a stupid language?
> SH: No, boss, you've got it all wrong. We have a new method for adding
> numeric types, like rationals, fixedpoint, decimals, etcetera, and
> is just happens that the default division mode changed as a
> consequence. I can easily add a single line of code to any old
>module
> and Python will run it under the old rule. No fault, no foul.
> Boss: Oh. Well, carry on.

And *this* storyline would leave me 98% of the way to seeing the
change as no different to the (IMO) less scary case insensitivity
change - I've already expressed my reservations on the religious
aspects ad nauseum, but in the practical sense this would leave only
one minor problem.

The minor problem is finding the code - the only way I can trace all
these programs written over the last three years which have been
passed from person to person, and which have been modified by others
or which I just plain forgot I wrote etc is by sending out an email to
the whole company. If the change is as simple as above, I can find a
way to do this that saves face - there is no chance of an avalanche of
bugs, only that some people won't want to do the change themselves
giving me an excuse for an occasional half hours wandering about,
getting coffee, doing a no-brainer task and having a chat ;-)

Still not happy with the principle, and I still forsee problems for
people who's code is no longer neatly located in their actual company
, but in the case of my personal pratical issues - well, my blood
pressures down a bit anyway ;-)

Paul Boddie

unread,
Jul 24, 2001, 5:09:37 AM7/24/01
to
"Tim Peters" <tim...@home.com> wrote in message news:<mailman.995943227...@python.org>...

>
> I'm burned out on the repetition here. It's not a question of being hard to
> teach. It's largely that it's never sensible for
>
> x = y / z
>
> buried in the middle of some routine to do truncating division if y and z
> happen to be ints but best-possible division if they happen not to be ints.

Indeed. But given that many people know what / is going to do, and
have managed to reassure themselves that y and z are going to be
integers at the relevant parts of their own code, do you think it's
fair to make their code give an "unexpected" result (for them) just
because one could get an "unexpected" result in the general case?

> It's this damage to polymorphism that hurts people in real life, and we've
> had years of testimony about that on c.l.py (even in this incarnation of the
> debate, although it's hard to find unless you read every msg).

I agree with what you say about the dangers of the / operator, and it
is important to at least try to remove the ambiguity (indeed, why not
start raising exceptions), but I don't see why this has to be done by
breaking untold amounts of code that came before just because a group
of people want to reclaim the / operator as their instrument for the
"one true kind of division".

If someone had suggested using // for the int/int->float operation, I
bet that hardly anyone would have complained, apart from some people
who might consider it "language bloat". But instead, it seems that for
the sake of some aesthetic principle the rug is being pulled out from
under everyone whether they want to lie down or not.

Paul

Christopher A. Craig

unread,
Jul 24, 2001, 8:35:51 AM7/24/01
to pytho...@python.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Tim Peters" <tim...@home.com> writes:

> I'm burned out on the repetition here. It's not a question of being hard to
> teach. It's largely that it's never sensible for
>
> x = y / z
>
> buried in the middle of some routine to do truncating division if y
> and z happen to be ints but best-possible division if they happen

> not to be ints. It's this damage to polymorphism that hurts people


> in real life, and we've had years of testimony about that on c.l.py
> (even in this incarnation of the debate, although it's hard to find
> unless you read every msg).

I haven't spoken out on this yet, but now I'm going to. I don't like
PEP238, but I am not going to repeat what everyone else has said.

What I don't like about it is that in every case I can think of right
now if you apply an operator to two operands of the same type, you get
a result of the same type. <int>/<int> = <float> would change this,
and I don't like it. (yes, you can argue that math.something(<int>)
returns a float, but that's a library module, not a builtin, so I
don't count it.)

Many people have argued that they would like to see the behavior from
the PEP if Python were a new language. I disagree. I would prefer to
see '/' defined as "exact division" and '//' defined as "truncated
division" and have types that don't support either raise a TypeError
if the types don't support the operation in question. I think this
parallels existing operations better.

As examples:

<list>*<list> raises a TypeError
<int>**<negative int> raises a ValueError
<rational>**<rational> would presumably raise a TypeError


- --
Christopher A. Craig <com-n...@ccraig.org>
"Software hoarding is not a victimless crime." Richard Stallman
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt

iEYEARECAAYFAjtda6cACgkQjVztv3T8pztiwACg2bnc0YssqlmsHx0B6zrcE/Bx
RtkAoI0pA4Q3O5ogY3NErL1Y77PtaBMO
=mfMO
-----END PGP SIGNATURE-----

Greg Landrum

unread,
Jul 24, 2001, 9:49:34 AM7/24/01
to

"Tim Peters" <tim...@home.com> wrote in message
news:mailman.995943227...@python.org...
>
> I'm burned out on the repetition here. It's not a question of being hard
to
> teach. It's largely that it's never sensible for
>
> x = y / z
>
> buried in the middle of some routine to do truncating division if y and z
> happen to be ints but best-possible division if they happen not to be
ints.
[snip]

> This isn't a question of teaching the rules, it's that the specific rule
> here is essentially braindead in a language without static type
> declarations.

When I read these arguments and think about them, I'm unsurprised to find
myself agreeing with Tim and Guido here -- I usually end up agreeing with
those guys. It *is* odd to have to do something like:
x = float(y)/z
to get best-possible division in Python. It would be *nice* to never have
to explain integer division behavior again (well, not quite, it'll have to
be explained to programmers who are used to the old way of doing things).

And then I start thinking about all the code I've written for myself, my
former employer and my consulting clients. I *know* I've used '/' to do
integer (truncating) division in that code intentionally. Of course I have,
it's the way things were done. Once PEP 238 is implemented and the change
in place (v2.3?), a lot of that code is going to start producing warnings.
The warnings can be used to track down the problems before code actually
breaks and there will be 2 years in which to do so... that's acceptable.

I do have a question. The PEP says:

If "from __future__ import non_integer_division" is present in the
module, until the IntType nb_divide is changed, the "/" operator
is compiled to FUTURE_DIV.

This is not yet implemented in the Python 2.2 release.

Okay, it's "not yet" implemented for 2.2. It's going to be though, right?
If the change is going to happen, it is going to break some of my code and I
would like to start tracking down these problems and changing my programming
habits ASAP.

[I started this message intending to make a very different argument because
of the code breakage. Then I re-read the PEP and realized that we are being
promised at least 2 years to fix things before code breaks. I'm much more
comfortable with the PEP now.]

-greg

Klaus-G. Meyer

unread,
Jul 24, 2001, 10:20:44 AM7/24/01
to
> those guys. It *is* odd to have to do something like:
> x = float(y)/z
> to get best-possible division in Python.

But what is with the "best possible" multiplication?

99999*99999 -> integer overflow

Why not an long integer result? (or maybe float)

You must explicit type:
99999*99999L or 99999*99999.

Is that not the same thing as type 1./3 ???

Klaus


Marcin 'Qrczak' Kowalczyk

unread,
Jul 24, 2001, 10:32:06 AM7/24/01
to
Tue, 24 Jul 2001 16:20:44 +0200, Klaus-G. Meyer <klaus-ge...@de.bosch.com> pisze:

> But what is with the "best possible" multiplication?
>
> 99999*99999 -> integer overflow

That's why I want int and long unified.

--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK

Steve Horne

unread,
Jul 24, 2001, 11:19:49 AM7/24/01
to
I hate countering arguments from someone who supports my opinion,
but...

On 24 Jul 2001 08:35:51 -0400, com-n...@ccraig.org (Christopher A.
Craig) wrote:

>As examples:
>
><list>*<list> raises a TypeError

Given that other arithmetic operations have been hijacked for other
jobs (concat etc) with lists, there *is* no sensible meaning for this.
In another universe, interpreting lists as vectors might have been
handy I suppose - but not really an everyday case I'd have thought.


><int>**<negative int> raises a ValueError

I believe Guido is already changing this.


><rational>**<rational> would presumably raise a TypeError

Or give a symbolic result ;-)

Just van Rossum

unread,
Jul 24, 2001, 11:55:37 AM7/24/01
to
Marcin 'Qrczak' Kowalczyk wrote:
>
> Tue, 24 Jul 2001 16:20:44 +0200, Klaus-G. Meyer <klaus-ge...@de.bosch.com> pisze:
>
> > But what is with the "best possible" multiplication?
> >
> > 99999*99999 -> integer overflow
>
> That's why I want int and long unified.

And that's in fact being discussed as well.

Just

Bjorn Pettersen

unread,
Jul 24, 2001, 11:44:57 AM7/24/01
to Klaus-G. Meyer, pytho...@python.org
> From: Klaus-G. Meyer [mailto:klaus-ge...@de.bosch.com]

>
> > those guys. It *is* odd to have to do something like:
> > x = float(y)/z
> > to get best-possible division in Python.
>
> But what is with the "best possible" multiplication?
>
> 99999*99999 -> integer overflow
>
> Why not an long integer result? (or maybe float)
>
> You must explicit type:
> 99999*99999L or 99999*99999.
>
> Is that not the same thing as type 1./3 ???

I think perhaps an equally interesting example is something like:

2L**128/2

which currently gives an exact result, but under the proposed new
semantics would give an approximation...

This is only one of the reasons why I think it's a mistake to look at
integer division by itself. If we're going to change basic behaviors it
would be better if we had a consistent semantic model first.

-- bjorn

Marcin 'Qrczak' Kowalczyk

unread,
Jul 24, 2001, 1:50:46 PM7/24/01
to
Tue, 24 Jul 2001 09:44:57 -0600, Bjorn Pettersen <BPett...@NAREX.com> pisze:

> I think perhaps an equally interesting example is something like:
>
> 2L**128/2
>
> which currently gives an exact result, but under the proposed new
> semantics would give an approximation...

That's why I propose rationals.

> If we're going to change basic behaviors it would be better if we
> had a consistent semantic model first.

In my model there are four builtin numeric types: int, rational,
float, and complex. The intent is that floats approximate real numbers.

There are explicit conversions from any to any among int, rational and
float. Conversion of rational and float to int truncates as currently.

+, -, * work for arguments of any two types from these and return
the result in the broader type wrt. the order above.

div, mod, divmod similarly, except that complex arguments are
disallowed.

/ similarly, except that ints are changed to rationals first.

sqrt, sin, cos, exp etc. similarly, except that ints and rationals
are changed to float first.

The behavior of ** depends on the exponent which determines the
narrowest type to which base is converted first. If it's a nonnegative
int, the result has the same type as the base. If it's a negative
int, the base is converted from int to rational. If it's a rational
or float, the base is converted from int or rational to float. If
it's a complex, the base is converted to complex.

Michael Abbott

unread,
Jul 24, 2001, 1:55:14 PM7/24/01
to
Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> wrote in
news:slrn.pl.9lrd...@qrnik.zagroda:

> Tue, 24 Jul 2001 09:44:57 -0600, Bjorn Pettersen <BPett...@NAREX.com>
> pisze:
>
>> I think perhaps an equally interesting example is something like:
>>
>> 2L**128/2
>>
>> which currently gives an exact result, but under the proposed new
>> semantics would give an approximation...
>
> That's why I propose rationals.
>
>> If we're going to change basic behaviors it would be better if we had
>> a consistent semantic model first.
>
> In my model there are four builtin numeric types: int, rational,
> float, and complex. The intent is that floats approximate real numbers.

Unfortunately, this isn't really all that consistent. Consider the
calculation

sqrt(2)**2 == 2

By pretty much the same arguments as have been used elsewhere in this
discussion, I'm sure that you would expect this to evaluate to true.

Hmm. Think about it.

Skip Montanaro

unread,
Jul 24, 2001, 1:08:30 PM7/24/01
to Klaus-G. Meyer, pytho...@python.org

Klaus> But what is with the "best possible" multiplication?

Klaus> 99999*99999 -> integer overflow

Klaus> Why not an long integer result? (or maybe float)

Read (and comment, if you like) on PEP 237, which proposes to unify Python's
ints and longs:

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

I believe this PEP is still in need of a patch to the CVS repository to
support it as well.

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

Terry Reedy

unread,
Jul 24, 2001, 2:01:27 PM7/24/01
to

"Steve Horne" <s...@ttsoftware.co.uk> wrote in message
news:su3rltc8d88jrjdv9...@4ax.com...

> > <list>*<list> raises a TypeError
>
> Given that other arithmetic operations have been hijacked for other
> jobs (concat etc) with lists, there *is* no sensible meaning for
this.

Actually there *is*: cross concatenation, (somewhat similar to set
cross products)

L1*L2 := [i1+i2 for i1 in Li for i2 in L2]

This is very handy for succinctly expressing many list-producing
functions and their corresponding algorithms. Example: combinations,
n things, k at a time
C(n,0) = ()
C(n,k>0) = [(n,)]*C(n-1,k-1) + C(n-1,k)

I have thought of submitting a PEP, after working out more details,
proposing this as a sequence operation that would make Python even
more like executable pseudocode.

Terry J. Reedy

Marcin 'Qrczak' Kowalczyk

unread,
Jul 24, 2001, 2:15:53 PM7/24/01
to
Tue, 24 Jul 2001 17:55:14 GMT, Michael Abbott <michael....@ntlworld.com> pisze:

> sqrt(2)**2 == 2
>
> By pretty much the same arguments as have been used elsewhere in this
> discussion, I'm sure that you would expect this to evaluate to true.

Why?

Skip Montanaro

unread,
Jul 24, 2001, 2:15:05 PM7/24/01
to Marcin 'Qrczak' Kowalczyk, pytho...@python.org

Marcin> The behavior of ** depends on the exponent which determines the
Marcin> narrowest type to which base is converted first.... If it's a
Marcin> rational or float, the base is converted from int or rational to
Marcin> float.

Hmm... PEP 240 proposes that numbers matching the regular expression
'\d*.\d*' be interpreted as rationals. Thus "0.5" would be interpreted as
the rational "5/10" (or perhaps reduced to "1/2"). Using this definition of
rational literal and your coercion semantics, "4**0.5" would yield a float
instead of an integer or rational. Why shouldn't an integer or rational
base be converted to a rational if the exponent is a rational?

Christopher A. Craig

unread,
Jul 24, 2001, 2:35:12 PM7/24/01
to pytho...@python.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Skip Montanaro <sk...@pobox.com> writes:

> Hmm... PEP 240 proposes that numbers matching the regular expression
> '\d*.\d*' be interpreted as rationals. Thus "0.5" would be interpreted as
> the rational "5/10" (or perhaps reduced to "1/2"). Using this definition of
> rational literal and your coercion semantics, "4**0.5" would yield a float
> instead of an integer or rational. Why shouldn't an integer or rational
> base be converted to a rational if the exponent is a rational?

Because 5**0.5 cannot be expressed as a rational.

- --
Christopher A. Craig <com-n...@ccraig.org>

When you say "I wrote a program that crashed Windows", people just stare at
you blankly and say "Hey, I got those with the system, *for free*". - Linus


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt

iEYEARECAAYFAjtdv+AACgkQjVztv3T8pztNbwCgtgNlOwyvT3YUQj1xo/Wxbvtd
PP4An3JzQGhNWRlsk0SWOTKSXRDNdM2w
=2qB9
-----END PGP SIGNATURE-----

Terry Reedy

unread,
Jul 24, 2001, 3:18:06 PM7/24/01
to

> > In my model there are four builtin numeric types: int, rational,
> > float, and complex. The intent is that floats approximate real
numbers.

Note: *approximate*

> Unfortunately, this isn't really all that consistent. Consider the
> calculation
>
> sqrt(2)**2 == 2
>
> By pretty much the same arguments as have been used elsewhere in
this
> discussion, I'm sure that you would expect this to evaluate to true.

No, approximate is not equal. For float 'equality', one should always
test near equality.

abs(sqrt(2)**2 - 2) <= delta

and yes, choosing delta is sometimes an art.


Gareth McCaughan

unread,
Jul 24, 2001, 8:05:34 PM7/24/01
to
Stephen Horne wrote:

[I said:]


>> The different behaviour of "/" on floats and ints isn't
>> polymorphism, it's overloading. Two different operations.
>> Closely related, of course, but different. Generally
>> "polymorphism" is reserved for when what's being done
>> is "the same thing" in both cases.
>
> It *is* the same thing in both cases - float division is nothing more
> than a logical extension of integer division. Even mathematicians know
> that ;-)

I am a mathematician, and I do not know, or even believe,
that "float division is nothing more than a logical extension
of integer division" if "integer division" means what
Python presently does.

To any mathematician on the planet, 1/2 is, well, 1/2.
A rational number quite different from 0.

This isn't necessarily an argument for making division
return rationals when handed integers -- well, it is, but
it's not necessarily a very *strong* argument for that.
(It would involve a non-trivial amount of work, the
results would be amazingly frustrating in practice
unless the numerator and denominator had the sematics
of longs rather than ints, and simple programs could
become mysteriously inefficient. Some people would find
that worse than them just doing the wrong thing.)

If I were re-designing Python from scratch and didn't
care about backwards compatibility, then I'd give it
unified ints and longs, and rationals, and I'd make
division of integers produce rationals. But I'm not,
and since Guido is a better language designer than me
it's probably just as well.

Guido van Rossum

unread,
Jul 25, 2001, 12:18:35 AM7/25/01
to
Gareth.M...@pobox.com (Gareth McCaughan) writes:

> I am a mathematician, and I do not know, or even believe,
> that "float division is nothing more than a logical extension
> of integer division" if "integer division" means what
> Python presently does.

Thanks. I am baffled by the many claims that for mathematicians 1/2
equals zero; I've never met such a mathematicians.

> To any mathematician on the planet, 1/2 is, well, 1/2.
> A rational number quite different from 0.

Right.

> This isn't necessarily an argument for making division
> return rationals when handed integers -- well, it is, but
> it's not necessarily a very *strong* argument for that.
> (It would involve a non-trivial amount of work, the
> results would be amazingly frustrating in practice
> unless the numerator and denominator had the sematics
> of longs rather than ints, and simple programs could
> become mysteriously inefficient. Some people would find
> that worse than them just doing the wrong thing.)

Certainly any suggestion of rationals presumes the use of long ints.
The mysterious inefficiency is also my experience with ABC.

> If I were re-designing Python from scratch and didn't
> care about backwards compatibility, then I'd give it
> unified ints and longs, and rationals, and I'd make
> division of integers produce rationals. But I'm not,
> and since Guido is a better language designer than me
> it's probably just as well.

Right! In fact, the goal of PEP 238 is to make such a redesign of
Python's numeric system possible. This is hinted at by PEP 228
(Reworking Python's Numeric Model). Unfortunately, the motivational
sections in both PEPs are weak -- we never expected so much
opposition.

The interesting thing is that the one thing that has to change in
order to get a unified numeric model, whether we introduce rationals
in the numeric tower or not, is integer division! A numeric tower
with rationals could look like this:

int < long < rational < float < complex

(Note that float stands in for real -- I should have called it that,
in the grand tradition of Algol and Pascal. But this design bug is
not worth fixing, since it doesn't lead to programming errors.)

Without rationals, it would look like this:

int < long < float < complex

Either is acceptable to me; both have their share of problems. A
later transition from a numeric tower without rationals to a tower
with rationals doesn't have to create much backwards compatibility:
the mathematical value of 1/2 is the same of that as 0.5, so an
algorithm that works when 1/2 returns 0.5 will still work (and perhaps
even more accurately!) when 1/2 returns, well, the rational number
1/2.

But PEP 238 can stand on its own. If it is rejected, PEP 228 has no
chance; but PEP 238 can be accepted and PEP 228 rejected and the world
would still be a better place.

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

Guido van Rossum

unread,
Jul 25, 2001, 12:25:49 AM7/25/01
to
"Greg Landrum" <gReGl...@earthlink.net> writes:

> And then I start thinking about all the code I've written for
> myself, my former employer and my consulting clients. I *know* I've
> used '/' to do integer (truncating) division in that code
> intentionally. Of course I have, it's the way things were done.
> Once PEP 238 is implemented and the change in place (v2.3?), a lot
> of that code is going to start producing warnings.

The PEP needs an update. Here's what I am thinking of now.

- In 2.2, the future division statement and the // operator are
available, and there's a command line option to turn on warnings for
int/int and another to make the default for / be a float (i.e. an
implied future division statement everywhere). The standard library
is reworked to make it work with all option values.

- In later versions (timing not yet decided), first the default
changes to enable warnings on int/int, and then (after at least 2
years) to enable float division by default, but the command line
options remain available to reverse the situation.

> The warnings can be used to track down the problems before code actually
> breaks and there will be 2 years in which to do so... that's acceptable.
>
> I do have a question. The PEP says:
>
> If "from __future__ import non_integer_division" is present in the
> module, until the IntType nb_divide is changed, the "/" operator
> is compiled to FUTURE_DIV.
>
> This is not yet implemented in the Python 2.2 release.
>
> Okay, it's "not yet" implemented for 2.2. It's going to be though, right?

Yes; I have a preliminary patch in the SF patch manager (referenced
from the PEP).

> If the change is going to happen, it is going to break some of my
> code and I would like to start tracking down these problems and
> changing my programming habits ASAP.

Yes, you will be able to start changing your habits as soon as 2.2 is
released.

> [I started this message intending to make a very different argument because
> of the code breakage. Then I re-read the PEP and realized that we are being
> promised at least 2 years to fix things before code breaks. I'm much more
> comfortable with the PEP now.]

Thanks!

Courageous

unread,
Jul 25, 2001, 12:05:07 AM7/25/01
to
On 24 Jul 2001 08:35:51 -0400, com-n...@ccraig.org (Christopher A. Craig) wrote:

>any people have argued that they would like to see the behavior from
>the PEP if Python were a new language. I disagree. I would prefer to
>see '/' defined as "exact division" and '//' defined as "truncated
>division" and have types that don't support either raise a TypeError
>if the types don't support the operation in question. I think this
>parallels existing operations better.

I'd go further: '/' should be exact division, and "div" should be
truncated division, analagous to the way divmod works, except
without the mod.

C//

Guido van Rossum

unread,
Jul 25, 2001, 12:31:00 AM7/25/01
to
pa...@boddie.net (Paul Boddie) writes:

> If someone had suggested using // for the int/int->float operation, I
> bet that hardly anyone would have complained, apart from some people
> who might consider it "language bloat". But instead, it seems that for
> the sake of some aesthetic principle the rug is being pulled out from
> under everyone whether they want to lie down or not.

It's not just an aesthetic principle. The currently / behavior is a
design mistake that needs to be eventually eradicated, because it
makes writing reliable cood too hard and it makes writing subtly
broken code too easy. The only way to do that is to bite the bullet
-- otherwise Python will still have this problem in 10 years.

I can live with a temporary language wart that we're committed to
removing. I don't want to live with the wart forever, which the other
solution would do.

(Another argument for PEP 238, which I made in another message, is
that it opens to way to a unified numeric model, hinted at by PEP
228. I will update both PEPs to greatly improve the motivational
sections.)

Guido van Rossum

unread,
Jul 25, 2001, 12:54:45 AM7/25/01
to
"Chris Gonnerman" <chris.g...@newcenturycomputers.net> writes:

> Some of us have tried. Besides my alternative, I have seen two
> others which allow case-by-case preservation of the old semantics
> where they may have been intended.
>
> I have seen very few comments on them though (except from Stephen Horne).

It's not easy to find the light among the heat.

> ASSERTIONS:
> 1. Best-effort handling of division is desirable.
> 2. An explicit operator for truncating division is desirable
> (as in, explicit is better than implicit).
> 3. Code breakage is bad, and difficult-to-detect code breakage
> is worse.
> 4. Difficulty in writing backwards-compatible code is bad
> (thus, code to implement partitioning of a dataset would
> naturally use the // operator in 2.2+ but would not be able
> to in pre-2.2, so the div() function would have to be
> religiously used, hurting readability).
>
> Assertion 1 and 2 conflict with 3 and 4; #4 in particular bothers
> me.

Hm, #4 is relatively new in this discussion (for me, anyway). I will
have to adapt to this new requirement, which I find reasonable
(although I wish it didn't exist -- but I understand the motivation).

> Many have said that #3 is irrelevant as we have from 2.2 to 2.4 to
> fix it, but I have upgraded several systems directly from 1.5.2 to
> 2.1 without substantial problems; going direct to 2.4 from 2.1 would
> not be so painless.

You will have at least from 2.2 to 2.6 though (at least two years),
and in reality more because I propose to add a command line option to
revert to old division semantics for several releases after 2.6.

> SOME way is needed to specify, in module scope, which set of
> mathematics rules should be enforced. Whatever method is used
> should (IMHO) be uniform from 2.2 to 2.4; my method, as given, is
> the only one where the code reads the same from 2.2 on:
>
> from __numerics__ import original # or standard, etc...

Not bad. But I am still uncomfortable with making the old semantics a
*permanent* wart of the language. I'd much rather deal with a future
statement for 5 years than with a __past__ statement forever.

An alternative that would not need this would be to require

from __future__ import division

in order to use the new semantics, and use the proposed command line
option (say, "python -D old") to default to the old behavior as long
as you have to support unconverted code.

> Just thinking about the implementation gives me headaches, but Guido
> and Co. have readily implemented fancy things like the
> software-time-machine
>
> from __future__ import phasers, warp_drive # or whatever
>
> and so my proposal (or a mutation thereof) should be no biggie.

Indeed, this wouldn't be hard -- although maybe a friendlier syntax,
like "directive blah, blah, blah" might make sense *if* we decide to
do this. (Which I still don't think is the best solution, but I do
see your point.)

> As I said, you can't honestly say we ALL haven't been trying. It's
> not that I object directly to the change, it's the overall
> plan/effect/semantics etc. that I don't like.

Would it be more palatable to you if the new semantics didn't become
the default (or the law) until Python 3.0 was introduced?

That's how Perl dealt with a much larger incompatible language change:
Perl4 was left alone (I believe there are still plenty installations
that require it) and Perl5 was the future.

Guido van Rossum

unread,
Jul 25, 2001, 12:56:55 AM7/25/01
to
"Bjorn Pettersen" <BPett...@NAREX.com> writes:

> I think perhaps an equally interesting example is something like:
>
> 2L**128/2
>
> which currently gives an exact result, but under the proposed new
> semantics would give an approximation...

Have you read the PEP? The PEP only returns a float if the int result
would yield a remainder.

Andy Salnikov

unread,
Jul 25, 2001, 2:14:52 AM7/25/01
to

"Guido van Rossum" <gu...@python.org> wrote in message
news:cpitghb...@cj20424-a.reston1.va.home.com...

>
> Thanks. I am baffled by the many claims that for mathematicians 1/2
> equals zero; I've never met such a mathematicians.
>
To many of us, programmers, 1/2 is 0 with 1 as a reminder:) We are like
children, and any child will say _for sure_ that 1 cookie for two children
means one cookie for 1 child and 0 cookies for another:)

> The interesting thing is that the one thing that has to change in
> order to get a unified numeric model, whether we introduce rationals
> in the numeric tower or not, is integer division! A numeric tower
> with rationals could look like this:
>
> int < long < rational < float < complex
>

Just a comment: What bothers me is that floats in computers are not the
same as R continuum im math. This makes me think that rationals are "better"
than floats. Indeed, any float number can be exactly represented by
rational, but not vice virsa. So my tower would be like that:

int < long < float < rational < complex float < complex rational

but, in general, it does not fit good in the linear chain, because floats
are too imprecise and limited. The whole picture would be better without
floats:)

> But PEP 238 can stand on its own. If it is rejected, PEP 228 has no
> chance; but PEP 238 can be accepted and PEP 228 rejected and the world
> would still be a better place.
>

Would not it be better to have rationals first and than change meaning of
int/int->rational, than changing first to int/int->float and then to
int/int->rational?

Cheers,
Andy.


Tim Roberts

unread,
Jul 25, 2001, 2:40:21 AM7/25/01
to
Steve Horne <s...@ttsoftware.co.uk> wrote:
>
>Intellectual decline is not what it used to be ;-) - apparently the
>avarage childs IQ these days (I forget the exact age range) is around
>120. Must it's all the TV and video games ;-)

The average child's IQ these days is 100. That is the very definition of
IQ.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

David Eppstein

unread,
Jul 25, 2001, 2:43:48 AM7/25/01
to
In article <9jlo4v$rhbl$1...@sky.inp.nsk.su>,
"Andy Salnikov" <saln...@inp.nsk.su> wrote:

> > int < long < rational < float < complex
> >
> Just a comment: What bothers me is that floats in computers are not the
> same as R continuum im math. This makes me think that rationals are "better"
> than floats. Indeed, any float number can be exactly represented by
> rational, but not vice virsa. So my tower would be like that:

The ordering is not by what is a "better" representation, or even by
information loss, but by what is the most appropriate direction for one-way
coercions. Although one could convert float->rational without information
loss, it would hardly ever be right to do so, because you are just making
things slower without anything to gain in return: you've already lost your
exactness and pretending you have it again won't make it so. On the other
hand int->long and long->rational are necessary to avoid overflow or
truncation, and any of these ->float are reasonable to speed up
computations where it is ok to be approximate.

So I completely agree with Guido's ordering.
--
David Eppstein UC Irvine Dept. of Information & Computer Science
epps...@ics.uci.edu http://www.ics.uci.edu/~eppstein/

Ben Wolfson

unread,
Jul 25, 2001, 3:07:18 AM7/25/01
to
On Tue, 24 Jul 2001 23:40:21 -0700, Tim Roberts <ti...@probo.com> wrote:

>Steve Horne <s...@ttsoftware.co.uk> wrote:
>>
>>Intellectual decline is not what it used to be ;-) - apparently the
>>avarage childs IQ these days (I forget the exact age range) is around
>>120. Must it's all the TV and video games ;-)
>
>The average child's IQ these days is 100. That is the very definition of
>IQ.

Except in Lake Woebegone, natch.

--
Barnabas T. Rumjuggler
No man can run so fast that he can escape his own past's projectile vomit.

Kirby Urner

unread,
Jul 25, 2001, 3:19:24 AM7/25/01
to
"Andy Salnikov" <saln...@inp.nsk.su> wrote:

> Would not it be better to have rationals first and than change meaning of
>int/int->rational, than changing first to int/int->float and then to
>int/int->rational?
>
>Cheers,
>Andy.
>

This echoes my sentiments over on edu...@python.org:

Were I in charge, I might have preferred that / remain the
way it is, until/unless a more Scheme-like inclusion of
the rational number type (different from float) came along,
which would happen when the "long" type melted away, and
became part of "int" (seamless i.e. no difference from the
user's point of view). This might have happened in 3.xx.
I think it's somewhat premature to fiddle with / in 2.x.

More context: http://mail.python.org/pipermail/edu-sig/2001-July/001543.html
where I admit it: I'm not in charge :-D

Kirby

Stephen Horne

unread,
Jul 25, 2001, 3:27:00 AM7/25/01
to
On Tue, 24 Jul 2001 18:01:27 GMT, "Terry Reedy" <tjr...@home.com>
wrote:

>
>"Steve Horne" <s...@ttsoftware.co.uk> wrote in message
>news:su3rltc8d88jrjdv9...@4ax.com...
>> > <list>*<list> raises a TypeError
>>
>> Given that other arithmetic operations have been hijacked for other
>> jobs (concat etc) with lists, there *is* no sensible meaning for
>this.
>
>Actually there *is*: cross concatenation, (somewhat similar to set
>cross products)
>
>L1*L2 := [i1+i2 for i1 in Li for i2 in L2]

Oops

Should have remembered that.

Toby Dickenson

unread,
Jul 25, 2001, 3:34:56 AM7/25/01
to
Guido van Rossum <gu...@python.org> wrote:

>"Bjorn Pettersen" <BPett...@NAREX.com> writes:
>
>> I think perhaps an equally interesting example is something like:
>>
>> 2L**128/2
>>
>> which currently gives an exact result, but under the proposed new
>> semantics would give an approximation...
>
>Have you read the PEP? The PEP only returns a float if the int result
>would yield a remainder.

That bit of the PEP didnt register on a first reading, and now I am
suprised at that rule.

As I understand it, this means long/long would sometimes give an exact
result and sometimes an approximation, depending on whether the
remainder is zero.

The problem isnt quite as simple as Bjorn was suggesting, but this is
definitely suprising:

>>> ((2L**1000)+0)/2
1071508607186267320948425.... <more digits snipped>

>>> ((2L**1000)+1)/2
1.07150860719e+301

>>> ((2L**2000)+0)/2
1148130695274254524232833.... <more digits snipped>

>>> ((2L**2000)+1)/2
inf

Toby Dickenson
tdick...@geminidataloggers.com

Tim Peters

unread,
Jul 25, 2001, 3:10:27 AM7/25/01
to pytho...@python.org
[Tim Roberts]

> The average child's IQ these days is 100. That is the very definition
> of IQ.

Except in Virginia. Jealous of the rumor that the Tennessee legislature had
defined pi to be 3 on the nose, the VA legislature defined *every* child's
IQ to be 120. The VA school system subsequently saved a lot of money on
now-useless tests, and by most accounts the kids didn't actually get any
dumber. It's also a great source of amusement that the Maryland legislature
sought to get even by mandating that all its childrens' IQs were 80.

suitable-changes-to-python's-numerics-will-follow-ly y'rs - tim


Mikael Olofsson

unread,
Jul 25, 2001, 3:41:02 AM7/25/01
to Andy Salnikov, pytho...@python.org

On 25-Jul-2001 Andy Salnikov wrote:
> To many of us, programmers, 1/2 is 0 with 1 as a reminder:) We are like
> children, and any child will say _for sure_ that 1 cookie for two children
> means one cookie for 1 child and 0 cookies for another:)

Sorry, that throws an exception (i.e. one of the children gets mad). One
cookie for two children means 0 cookies for both children, since mom or
dad did not serve that one cookie at all. After all that is the meaning
of 1/2 being 0 with 1 as a remainder.

Then-again-some-cookies-can-be-cut-in-pieces-ly y'rs

/Mikael

-----------------------------------------------------------------------
E-Mail: Mikael Olofsson <mik...@isy.liu.se>
WWW: http://www.dtr.isy.liu.se/dtr/staff/mikael
Phone: +46 - (0)13 - 28 1343
Telefax: +46 - (0)13 - 28 1339
Date: 25-Jul-2001
Time: 09:35:20

/"\
\ / ASCII Ribbon Campaign
X Against HTML Mail
/ \

This message was sent by XF-Mail.
-----------------------------------------------------------------------

Stephen Horne

unread,
Jul 25, 2001, 4:21:10 AM7/25/01
to
On Tue, 24 Jul 2001 23:40:21 -0700, Tim Roberts <ti...@probo.com>
wrote:

>Steve Horne <s...@ttsoftware.co.uk> wrote:


>>
>>Intellectual decline is not what it used to be ;-) - apparently the
>>avarage childs IQ these days (I forget the exact age range) is around
>>120. Must it's all the TV and video games ;-)
>
>The average child's IQ these days is 100. That is the very definition of
>IQ.

Not in the case where you compare current childrens performace against
past childrens performance on the same test and using the same
assessment criteria - which was the point.

Of course I was misusing a specialist statistic and I doubt I can even
find the source now, but it was just a joke.

Wiktor Sadowski

unread,
Jul 25, 2001, 2:18:52 AM7/25/01
to pytho...@python.org
[Andy Salnikov]

>To many of us, programmers, 1/2 is 0 with 1 as a reminder:) We are like
>children, and any child will say _for sure_ that 1 cookie for two children
>means one cookie for 1 child and 0 cookies for another:)

Your cookies are too old (tough) to slice or one of your children is too
clever (the fat one)

regards
Wiktor Sadowski

Paul Boddie

unread,
Jul 25, 2001, 5:10:22 AM7/25/01
to
Guido van Rossum <gu...@python.org> wrote in message news:<cpd76pb...@cj20424-a.reston1.va.home.com>...

> pa...@boddie.net (Paul Boddie) writes:
>
> > If someone had suggested using // for the int/int->float operation, I
> > bet that hardly anyone would have complained, apart from some people
> > who might consider it "language bloat". But instead, it seems that for
> > the sake of some aesthetic principle the rug is being pulled out from
> > under everyone whether they want to lie down or not.
>
> It's not just an aesthetic principle. The currently / behavior is a
> design mistake that needs to be eventually eradicated, because it
> makes writing reliable cood too hard and it makes writing subtly
> broken code too easy. The only way to do that is to bite the bullet
> -- otherwise Python will still have this problem in 10 years.

I don't disagree with your assertion that it's a bad thing. The
problem is that the / operator has a well-defined meaning in Python
which you're seeking to change. Whether or not it has a desirable
behaviour is almost irrelevant to the strongest argument to leave it
be: that changing its behaviour will potentially break lots of old
code.

I haven't seen any adequate response to the proposal that a different
operator (such as //, although I don't care so much) be used. And in
the PEP, whilst backward compatibility is mentioned, it isn't
addressed in any way which can be considered an acceptable treatment
of the subject.

> I can live with a temporary language wart that we're committed to
> removing. I don't want to live with the wart forever, which the other
> solution would do.

You have designed a language which I and many others really enjoy
using, and are really grateful for. Whilst programming languages tend
to differ from natural languages by resisting change in order to
promote robust, well-defined semantics, what you are doing here is
analogous to issuing a decree that a particular word in
English/Dutch/French (or your preferred natural language), where the
word isn't exactly an infrequently used noun, now means something
else.

What do you propose we do with all the novels ever written in that
language? Instigate a massive rewriting project? Burn them? Did Monty
Python ever do a sketch about the Cultural Revolution? <1/3 wink>

> (Another argument for PEP 238, which I made in another message, is
> that it opens to way to a unified numeric model, hinted at by PEP
> 228. I will update both PEPs to greatly improve the motivational
> sections.)

Your numerical aspirations are noble, but due to practical
considerations won't some of us end up speaking "Dutch" and some of us
speaking "Flemish"? ;-)

Paul

Marcin 'Qrczak' Kowalczyk

unread,
Jul 25, 2001, 8:47:30 AM7/25/01
to
26 Jul 2001 00:03:56 +1200, Paul Foley <see@below> pisze:

>> int < long < rational < float < complex
>

> Well, it could, I suppose, but that would be a good reason to avoid
> Python :-)
>
> What it *should* look like is this:
>
> int < long < rational
> \
> + < [real] < complex
> /
> float

There are no real reals in programming. And Python's complex is as
inexact as float.

I don't understand you. What practical difference do these diagrams
yield? What is wrong in *consequences* of Guido's and mine model
which your model puts differently?

What happens if you int to float in your model? Rational to float?

Frank Cookie Jar Lomax

unread,
Jul 25, 2001, 10:55:57 AM7/25/01
to pytho...@python.org

> To many of us, programmers, 1/2 is 0 with 1 as a reminder:)
> We are like children, and any child will say _for sure_ that 1
> cookie for two children means one cookie for 1 child and 0
> cookies for another:)

No, 1 cookie for 2 children always means no cookies for either child,
lots of crumbs for the dog to lick up, and years of therapy for the
entire family.

proof-that-integer-division-causes-thousands-of-disfunctional-families-
per-year-and-must-be-abolished-ly y'rs, - frank

Terry Reedy

unread,
Jul 25, 2001, 2:08:44 PM7/25/01
to
> Right! In fact, the goal of PEP 238 is to make such a redesign of
> Python's numeric system possible

Saying this explicitly makes explicitly obvious what to me was not,
before:-). Even though I do not currently care about such a redesign,
but you do, I consider the above a point in favor of 238.

(I am assuming that such a redesign would not break 'regular' floating
point code, such as Newton's method, that does not depend on every
last bit being just as it currently is to run correctly.)

I think another, currently less-well-articulated goal/result of 238 is
that it will make it possible for you to pursue your CP4E dream
project without forking Python and also without needing to make
further disruptive changes to the core. If you agree with the last
proviso, then I also consider this a point in 238's favor. I think
more could be said about the connection that would make what's obvious
to you clearer to others.

> The interesting thing is that the one thing that has to change in
> order to get a unified numeric model, whether we introduce rationals
> in the numeric tower or not, is integer division

(IMO -- and attempting to be helpful again) This (and similar
statements) is rhetorically wrong and counter-productive. In PEP238,
you are NOT proposing to delete integer division (and I hope/presume
you never will), you are NOT proposing to switch it to C's version
(ditto), nor are you proposing any other substantive change (ditto).
From a technical viewpoint, you are merely, in Tim's words, proposing
to change it's spelling, so that future i//j == current i/j, down to
the very last bit. (I am ignoring any possible effect of int/long
unification, which is a completely separate issue.) So to ask another
rhetorical question: why frighten people unnecessarily? or futilely
attempt to get them to accept something that you are not proposing
(and I hope/presume you never will)?

The *really* interesting thing is that the one thing that has to
change for you to pursue your further numeric goals is the current
overloading of integer and fractional division onto one symbol, which
is exactly what 238 undoes by adding a second symbol. The main
practical technical issue, to repeat from my essay of two weeks ago,
is code breakage, forwards and back, and the costs and benefits
thereof.

The important thing is that the one thing you need from people in
order to make 238 work without forking Python is their agreement (for
whatever personal reason) to do the respelling and absorb the cost in
return for the expected long-term individual and collective benefits.
You do not need, and will never get, general agreement on the
metaphysical relationships of abstract (count, integer, rational,
real) and concrete (int, long, float) number sets. Ditto for the
abstract virtue or esthetics of various combinations of type-dependent
division rules.

Terry J. Reedy

sburrious

unread,
Jul 25, 2001, 2:29:54 PM7/25/01
to
lo...@pumpichank.com (Frank "Cookie Jar" Lomax) wrote in message news:<mailman.996073073...@python.org>...

Unless you use the old trick of having one child divide the cookie and
the other choose which piece he or she wants.

would-there-were-such-a-solution-to-the-int-division-debate-ly y'rs,
sburrious

William Tanksley

unread,
Jul 25, 2001, 3:12:45 PM7/25/01
to
On Wed, 25 Jul 2001 04:18:35 GMT, Guido van Rossum wrote:
>Thanks. I am baffled by the many claims that for mathematicians 1/2
>equals zero; I've never met such a mathematicians.

Perhaps the best solution would be to make Python's integers actually be
the field of integers mod 4294967291 (not too much of a change -- they're
currently very similar to the integers mod 4294967295). The best of all
worlds -- divisions no longer have remainders, and everything's exact
again.

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

and-writing-the-log-function-becomes-a-lot-more-fun-ly yr's

--
-William "Billy" Tanksley

William Tanksley

unread,
Jul 25, 2001, 3:14:10 PM7/25/01
to
On Wed, 25 Jul 2001 10:55:57 -0400, Frank "Cookie Jar" Lomax wrote:
> > To many of us, programmers, 1/2 is 0 with 1 as a reminder:)
> > We are like children, and any child will say _for sure_ that 1
> > cookie for two children means one cookie for 1 child and 0
> > cookies for another:)

>No, 1 cookie for 2 children always means no cookies for either child,
>lots of crumbs for the dog to lick up, and years of therapy for the
>entire family.

_Exactly_ like floating point! Look at what it did to poor Tim.

--
-William "Billy" Tanksley

David Bolen

unread,
Jul 25, 2001, 3:59:26 PM7/25/01
to
"Terry Reedy" <tjr...@home.com> writes:

> (IMO -- and attempting to be helpful again) This (and similar
> statements) is rhetorically wrong and counter-productive. In PEP238,
> you are NOT proposing to delete integer division (and I hope/presume
> you never will), you are NOT proposing to switch it to C's version
> (ditto), nor are you proposing any other substantive change (ditto).
> From a technical viewpoint, you are merely, in Tim's words, proposing
> to change it's spelling, so that future i//j == current i/j, down to

> the very last bit. (...)

Just for clarification, I don't think that's quite right. // is being
proposed for integer division only. That is, unlike todays /, using
// with two floats, while still yielding a float, would yield the
floor() of what today's / would have yielded, and thus not the same


"down to the very last bit"

--
-- David
--
/-----------------------------------------------------------------------\
\ David Bolen \ E-mail: db...@fitlinxx.com /
| FitLinxx, Inc. \ Phone: (203) 708-5192 |
/ 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \
\-----------------------------------------------------------------------/

David Bolen

unread,
Jul 25, 2001, 4:07:58 PM7/25/01
to
Guido van Rossum <gu...@python.org> writes:

> "Bjorn Pettersen" <BPett...@NAREX.com> writes:
>
> > I think perhaps an equally interesting example is something like:
> >
> > 2L**128/2
> >
> > which currently gives an exact result, but under the proposed new
> > semantics would give an approximation...
>
> Have you read the PEP? The PEP only returns a float if the int result
> would yield a remainder.

Does it? While returning an integral value in the above case,
wouldn't it would in fact be a float data type (barring the addition
of rationals), as per:

(from PEP238)

"The type of a/b will be either a float or a rational, depending on
other PEPs[2, 3]. However, the result will be integral in all case
the division has no remainder."

And given that, what happens if float can't represent the resulting
precision necessary?

Of course, this is only true later when this is the default, right?
Until then, the "future" implementation is an addition of 0.0 to the
divisor, so the result would definitely be float, and not necessarily
integral.

Unless you meant something other than the data type involved by
"returns a float".

Guido van Rossum

unread,
Jul 25, 2001, 4:24:46 PM7/25/01
to
David Bolen <db...@fitlinxx.com> writes:

> Guido van Rossum <gu...@python.org> writes:
>
> > "Bjorn Pettersen" <BPett...@NAREX.com> writes:
> >
> > > I think perhaps an equally interesting example is something like:
> > >
> > > 2L**128/2
> > >
> > > which currently gives an exact result, but under the proposed new
> > > semantics would give an approximation...
> >
> > Have you read the PEP? The PEP only returns a float if the int result
> > would yield a remainder.
>
> Does it? While returning an integral value in the above case,
> wouldn't it would in fact be a float data type (barring the addition
> of rationals), as per:
>
> (from PEP238)
>
> "The type of a/b will be either a float or a rational, depending on
> other PEPs[2, 3]. However, the result will be integral in all case
> the division has no remainder."
>
> And given that, what happens if float can't represent the resulting
> precision necessary?
>
> Of course, this is only true later when this is the default, right?
> Until then, the "future" implementation is an addition of 0.0 to the
> divisor, so the result would definitely be float, and not necessarily
> integral.
>
> Unless you meant something other than the data type involved by
> "returns a float".

The PEP is currently contradictory and incomplete. The "future
division" operator (generated by x/y when in the scope of a future
division statement) will return either a rational or a float --
obviously it can't return a rational until they have been made part of
the language (which may or may not ever happen). Since 2.2 won't have
rationals, it will return a float even for 2L**128/2 -- but only when
you use a future division statement, and in that case you get what you
ask for.

The current patch on SF adds 0.0 but that's not what it will do once
2.2 is released.

David Eppstein

unread,
Jul 25, 2001, 4:45:55 PM7/25/01
to
In article <slrn9lu6hc....@dolphin.openprojects.net>,
wtan...@dolphin.openprojects.net (William Tanksley) wrote:

> Perhaps the best solution would be to make Python's integers actually be
> the field of integers mod 4294967291 (not too much of a change -- they're
> currently very similar to the integers mod 4294967295). The best of all
> worlds -- divisions no longer have remainders, and everything's exact
> again.

If you instead used the ring of integers mod 2^32, you could still divide
by any odd number exactly, without remainders. Division by even numbers
would be harder, but everyone optimizes those by replacing them with
shifts, right?

I think even fewer people would like the results of division in these
systems, though -- e.g. what is 1/3?

> and-writing-the-log-function-becomes-a-lot-more-fun-ly yr's

For mod 2^32, I think what you want is the 2-adic norm...

Lloyd Zusman

unread,
Jul 25, 2001, 8:16:54 PM7/25/01
to
sb...@home.com (sburrious) writes:

Ah ... but there *is* such a solution:

One thread performs an arbitrary integer partitioning, and a second
thread chooses the value within the partition to return to the caller.

For example, to do 5/2, the first thread would arbitrarily pick one of
these 2-element partitions: [0,5], [1,4], [2,3]. It would pass this
partition to the second thread, which would also arbitrarily choose
one of the two numbers to return to the caller, with the other value
returned to the first thread. E.g., if partition [1,4] happens to be
chosen by the first thread, the second thread could return either 1 or
4 to the caller, and the other value back to the first thread.

Not very efficient, not very accurate, not very useful, and not even
very desirable, but given intelligent threads operating under heavy
self-interest (in Python 6.0 maybe?), at least it would be fair. :)


Actually, I'm very much in agreement with Guido's latest decision (to
wait until Python 3.0 before this change in division semantics goes
into full effect, tying it to _future_ in prior versions). It's a
Solomonic solution, and I applaud your wisdom, Guido.


> sburrious

--
Lloyd Zusman
l...@asfast.com

Paul Svensson

unread,
Jul 25, 2001, 9:55:05 PM7/25/01
to
"Terry Reedy" <tjr...@home.com> writes:

>> The interesting thing is that the one thing that has to change in
>> order to get a unified numeric model, whether we introduce rationals
>> in the numeric tower or not, is integer division
>
>(IMO -- and attempting to be helpful again) This (and similar
>statements) is rhetorically wrong and counter-productive. In PEP238,
>you are NOT proposing to delete integer division (and I hope/presume
>you never will), you are NOT proposing to switch it to C's version
>(ditto), nor are you proposing any other substantive change (ditto).
>From a technical viewpoint, you are merely, in Tim's words, proposing
>to change it's spelling, so that future i//j == current i/j, down to
>the very last bit.

This is not what's proposed.
i//j will be for all numeric types like current i/j for ints.
i/j will be for all numeric types like current i/j for floats.

>The *really* interesting thing is that the one thing that has to
>change for you to pursue your further numeric goals is the current
>overloading of integer and fractional division onto one symbol, which
>is exactly what 238 undoes by adding a second symbol. The main
>practical technical issue, to repeat from my essay of two weeks ago,
>is code breakage, forwards and back, and the costs and benefits
>thereof.

The important thing is that i//j will return the same value
regardless if i and j ar ints or floats; ditto for the new i/j.

Numeric unification means that (i == x and j == y) == (i op j == x op y)
for all op, i, j, x, y, regardless of numeric type
(ignoring exceptions and round-off errors).

This is not true for the current semantics of '/'. That's why it must go.

/Paul

Terry Reedy

unread,
Jul 25, 2001, 11:03:20 PM7/25/01
to

"Guido van Rossum" <gu...@python.org> wrote in message
news:cp66chb...@cj20424-a.reston1.va.home.com...
> "Chris Gonnerman" <chris.g...@newcenturycomputers.net> writes:
> > 4. Difficulty in writing backwards-compatible code is bad
> > (thus, code to implement partitioning of a dataset would
> > naturally use the // operator in 2.2+ but would not be
able
> > to in pre-2.2, so the div() function would have to be
> > religiously used, hurting readability).

> Hm, #4 is relatively new in this discussion (for me, anyway). I
will
> have to adapt to this new requirement, which I find reasonable
> (although I wish it didn't exist -- but I understand the
motivation).

My solution for this:

Since int/int and float//float will have new meanings, don't use them.
Write float(int)/int and floor(float/float) instead to get the new
meaning. Only write int//int or float/float. With the tokenizer
module, it will then be easy to change all instances of int//int to
int/int (old meaning). It should even even be possible to have
package installers check sys.version and do this conversion on site as
needed.

This is not the same as having *one* file that is cross-compatible,
but since the generation of the second is automated, it is certainly
close. A version check could be inserted in both versions (and
automatically modified) to make sure that each version of the file
only runs on versions of the interpreter it is compatible with.

For newly written code, the harder problem will be to not use
any of the other neat new features, which mostly *cannot* be
automatically back converted.

Terry J. Reedy

Terry Reedy

unread,
Jul 25, 2001, 11:15:55 PM7/25/01
to

"Guido van Rossum" <gu...@python.org> wrote in message
news:cpd76pb...@cj20424-a.reston1.va.home.com...

Just to let you know that you are making some progress ...

> It's not just an aesthetic principle. The currently / behavior is a
> design mistake that needs to be eventually eradicated,

With the metaphysical mists having mostly dissapated, I now agree with
this for Python. I also believe that the similar behaviour of C is
correct for C.

> because it makes writing reliable cood too hard and it makes
writing subtly
> broken code too easy.

This is because of Python's type system, which is considerably
different from C's.

> The only way to do that is to bite the bullet
> -- otherwise Python will still have this problem in 10 years.

Agreed, better now than later.

Terry J. Reedy


John W. Baxter

unread,
Jul 26, 2001, 1:28:20 AM7/26/01
to
In article <mailman.996045152...@python.org>, Tim Peters
<tim...@home.com> wrote:

> [Tim Roberts]
> > The average child's IQ these days is 100. That is the very definition
> > of IQ.
>
> Except in Virginia. Jealous of the rumor that the Tennessee legislature had
> defined pi to be 3 on the nose, the VA legislature defined *every* child's
> IQ to be 120. The VA school system subsequently saved a lot of money on
> now-useless tests, and by most accounts the kids didn't actually get any
> dumber. It's also a great source of amusement that the Maryland legislature
> sought to get even by mandating that all its childrens' IQs were 80.
>

That's the news from Lake Woebegone, where all the women are
strong...all the men are good looking...and all the children are above
average.

--John

Skip Montanaro

unread,
Jul 26, 2001, 2:50:30 AM7/26/01
to Paul Foley, pytho...@python.org

Paul> The most obvious problem is that it implies that every rational
Paul> can be represented as a float -- this is *severe* brokenness you
Paul> don't need. [I think it also implies that floats with integral
Paul> values (1.0, etc.) should turn into integers.]

You can't do that. Suppose that value you think is 1.0 really got truncated
during a previous calculation because your fp hardware doesn't have enough
bits and lost it? If you convert that to the integer 1 you're screwed
because you are pretending your inexact approximation of the real value is
the real value. You're better off admitting you have an inexact value and
planning accordingly. The only time the VM can convert from inexact to
exact (e.g., float->rational, float->int) is when the programmer says you
can with a cast.

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