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