PEP0238 lament

Steve Horne sh at ttsoftware.co.uk
Tue Jul 24 11:01:10 EDT 2001


On 24 Jul 2001 13:57:36 GMT, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:

>Tue, 24 Jul 2001 14:33:47 +0100, Steve Horne <sh at ttsoftware.co.uk> pisze:
>
>>>> Language design mistake.
>>>
>>>It allows to write code which increments a number of unknown type
>>>by one. How would you write it in your universe?
>
>> Literals can be used for any type where the representation matches,
>> so incrementing is not a problem.
>
>Ok, this applies to Ada and Haskell. But how to fix the "design
>mistake" in Python?

IMO it's not a mistake - just a choice - and I was just passing on an
example of something you seemed incredulous of, plus rambling a bit.

>So we must continue to design the meaning of operators under the
>assumption that mixed-type arithmetic promotes arguments to some
>common type.

I still find the idea of 'promoting' integer measures into real
measures disturbing.

I can probably come to accept that integer values can be used for real
measures, either as a coarse approximation or as an exact value that
just happens to be a member of integers. But something in my mindset
says that integer measures should *never* be allowed to change into
real measures unless specifically requested - probably even in the
cases where they already do.

This kind of suggests two integer types - an integer_within_real and a
discrete_integer. Real-style (float or rational) division would then
simply be banned for discrete_integer. Likewise, operators mixing
integer measures and real measures (even if both were represented by
integers) would be an error - a coercion should be done if that is the
real intention.

As a way of working, I think it would handle both week typing of
representations and strong typing of fundamentally different measures
very well. But having two integer types seems hard to explain.

I guess I'm rambling again.

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk



More information about the Python-list mailing list