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

Christopher A. Craig com-nospam at ccraig.org
Tue Jul 24 08:35:51 EDT 2001


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Tim Peters" <tim.one at 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-nospam at 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-----




More information about the Python-list mailing list