Comment on PEP-0238

[Terry Reedy]

> I sense some confusion here (or maybe I'm confused). The original point
was  that
> someone could simply search and replace the existing '/' operator with
the 'div'
> operator.

What *I* said (and which Guide acknowledged as a reasonable point) was that
'/' could be programatically replaced with another infix operator thru
search/replace-with-confirmation while replacing it with a function would
require an embedded Python parser to determin the extent of e1 and e2 in
the construct e1/e2 to be written as, for instance, div(e1,e2).

> The existing '/' does not guarantee an integer result (if one of  the
operands
> is a float for example).

Right.  As I thought I understood the 'div' (or div() proposal), update
could not be completely automated, which is why I specified
*with-confirmation* by a human who understands the code.  In some cases,
the intent will be obvious.  In others, searching an entire file, or more,
may be required.

> So providing an idiv operator that always returned  an
> integer result would not suffice for the original desire which was to
have
> an  operator with the same semantics as the existing division operator.
Or do I
> misunderstand?

I thought the desire was/is to have an operator which just preserved int /
int -> int.  But I have never seen it specified whether float div whatever
would be an error or have the current meaning (in which case confirmation
would not be necessary).

In this sense, PEP-0238 is incomplete in not fully specifying a proposed
alternative to current syntax and semantics, which I why I think it
premature to declare it accepted, even though it seems it will be
eventually.

Terry J. Reedy