Comment on PEP-0238

[Terry Reedy]

"Paul Prescod" <paulp at ActiveState.com> wrote in message
news:mailman.994115046.6243.python-list at python.org...
> I strongly feel that in the modern world, people will see an unadorned
> 82/4 as 20.5.

So?...  My point was that numbers in real, consequential computations *are*
adorned with a unit, even if just implicitly, and that people should
*think* about what that adornment/tagging is.

> Go ask someone on the street: "What's 11 divided by 2."  If
> they are good enough at mathematics to even figure out an answer, they
> will usually respond 5.5.

Yes, given an underspecified abstract question of no consequence,
especially verbally, people will often fill in the blank with something
that lets them answer.  So?  (see above).

> Very few would bother to ask you whether you  mean "count division."

The question under debate is whether we should keep the existing method of
*telling* a Python interpreter what me mean, which I strongly favor, or
break scads of code to change it to something else, as some have proposed.

...

> I do not think it is very good idea to use two syntaxes that are
> semantically equivalent in "real math" to indicate divisibility.

Since I am advocating no change, I am unclear as to what you mean here.

>. And maybe one day we could say
> that 5.00 represents not double-precision math but *triple* precsion.
> Adding zeros to the end could get you more and more precision.

I believe something like this is part of the IBM decimal arithmetic
proposal/project.

1.0/3 = .3, 1.00/3 = .33, etc (in which case, 1/3 = 0 by the same rule)

...
> In a dynamically typed language with no type declarations it makes more
> sense to define the nature of the operation *at the point of the
> operation* and not at the point where the value is initialized.

As noted in another thread, Python is deeply polymorphic.  The meanings of
3*2 and '3'*2, or 3+2 versus '3'+'2', for instance are more different that
8/3 versus 8.0/3.  This nature of the operation *is* defined by the
initializations of the values.  Do you suggest that we unbundle such other
usages also?

>If you
> write a function like this:
>
> def teachersPerClassRoom(teachers, classroom):
>     return teachers/classroom
>
> you absolutely do NOT want the users of this function to accidently
> subvert it and get meaningless answers by passing it "3.0" instead of
> "3".
> Therefore to make this safe, you need to do this:
>
> def teachersPerClassRoom(teachers, classroom):
>     return int(teachers)/int(classroom)

The same is true whenever you want to block some of the polymorphic
possibilities of a Python expression.  Consider

def muladd(a,b,c): return a*b+c

and a user passing in 2, 'hello', 'goodbye'.  Any expresion with names
(variables) instead of all literals opens the door to polymophic
possibilities depending on the type of the compile-time unspecified values.
But the question under debate is whether the compiler should silently
coerce pairs of integers, including unambiguous pairs of literals, to a
pair of floats when they happen to be connected with '/' instead of one of
the many other operators.  To me, this would be a major wart.

> > Requiring  that people think about divisibility in choosing a number
representation is
> > no more burdensome (and I think less so) than requiring them to think
about
> > mutability in choosing a tuple versus list sequence representation.
>
> Many Python hot-shots admit to occasionally being bitten by the
> int/float problem whereas we never have trouble with tuple/list.

Very funny.  According to my memory, the case is more the opposite.  Hardly
a month go by that some newbie does not ask "What is a tuple?", "What is
the difference between tuples and lists?", "Why do we have both?",  "How
can I decide which to use?", "Couldn't we simplify Python by merging them
together?", and repeatedly, some version of "I changed a list and now its
changed when I access it by a different name [or anonymous reference]!!!
Why???".

Terry J. Reedy