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

[Tim Hochberg]

"Ken Seehof" <kens at sightreader.com> wrote :

[SNIP]
> 1. If inexact numbers are excluded from being used as sequence indices,
> won't there be a tendency for programs to have more special case bugs?
> The value of a variable in a calculation might be usually exact, but
inexact
> once in awhile.  So floats can be used as indices until there is a
precision
> error?  Yikes!  And I have a funny feeling in my stomach that this is just
> the tip of the iceberg.  Floats may or may not turn out to be exact
> depending
> on details of a particular run.  This is a Bad Thing.  Integers are always
> exact.  This is a good thing.

You might want to read or reread PEP 228 (not 238). Exactness has nothing to
do with values and everything to with, well, exactness. Note that 228 is a
"pie in the skie" PEP and as such is fairly incomplete, but it may give you
a better idea what Guido was referring to.

Anyway, under the PEP 228 rules, a number would be exact if it was an
integer or rational (internally, there would externally be one number type)
and inexact if it were a float or complex-float. So floats would never be
able to be used as indices since they are inexact, by definition.

> 2. Wouldn't a function in an extension module that takes a number as an
> argument be significantly more difficult to write, since it would have
> figure out the actual runtime type of the number and deal with all the
> different cases?  Right now, I just have to verify the type.  Seems like
> even if you somehow solve the problem of breaking python code, you
> will break extension code badly.  One thing I like about python is that
> it is highly compatible with its extension language.  The further we get
> from the current symmetry between python and C/C++ the harder it
> will be to write extensions.  The same goes for case sensitivity BTW.

I won't comment on case sensitivity, but don't nearly all arguments to
extensions go through PyArg_ParseTuple? Without thinking about it too much,
it seems like it would be a piece of cake to make that backwards compatible.
Did you have something specific in mind?

> 3. Why do you expect it to be wise to hide all the numeric issues under
> a level of abstraction?  The issues will still exist, but will just be
more
> obscure.  Right now, we have a simple and explicit numeric system with
> simple and well understood problems.  Trying to make it simpler for
> beginners by adding complexity to the overall system won't work.

What specifically don't you like?

   * Unification of ints and longs (PEP 237)? This seems almost impossible
to dislike.

    * An addition of a rational type (PEP 239)? You might think this was
useless and argue against it on those grounds, but I can't see that would
inspire the horrified tone of the message above.

   * Addition of a rational literal (PEP 240)? This one you could easily
dislike a lot. But if your really super concerned about the evils of
inexatitude, you'll probably like this more than I do.

Once you have allow PEPs 237 and 239 your 90% of the way to some variation
of PEP 228, you don't even really need 240.

Anyway I'm sure we'd all be much happier if everyone went to
python.sourceforge.net/peps, read all the number PEPs and then, if
necessary, panicked about what was actually in them.

-tim