PEP 238 (revised)

[David Bolen]

Guido van Rossum <guido at python.org> writes:

> Alternatives
> 
>     In order to reduce the amount of old code that needs to be
>     converted, several alternative proposals have been put forth.
>     Here is a brief discussion of each proposal (or category of
>     proposals).  If you know of an alternative that was discussed on
>     c.l.py that isn't mentioned here, please mail the second author.
> 
>     - Let / keep its classic semantics; introduce // for true
>       division.  This doesn't solve the problem that the classic /
>       operator makes it hard to write polymorphic numeric functions
>       accept int and float arguments, and still requires the use of
>       x*1.0/y whenever true divisions is required.

Is the polymorphic argument really true here?  I buy the difficult case
currently (as described in the motivation) is a polymorphic way to get
a "true" result using the existing classic / operator.  But once you
have // as true division you'd just use it in such a case.  So what is
the remaining hard polymorphic case for / once you have // for "true"?
Getting an integer result in all cases?  If so, wouldn't an actual
floor(x/y) or even int(x/y) suffice?  It wouldn't work with complex,
but then neither would the definition of the floor behavior in the PEP
either (see below), so you'd want to stick with true division if you
might receive complex numbers and wanted to work polymorphically.

Or if this isn't the polymorphic case being described, perhaps another
sentence or two could clarify that?

I'd probably also mention in this alternative that if true division is
the correct default behavior, then / seems logically the correct
symbol for default division behavior.  It may not be a technical
argument, and is mitigated somewhat by the compatibility issue, but
it's a point in favor of the change nonetheless.

>     - Use a directive (or some other way) to specify the Python
>       version for which a specific piece of code was developed.  This
>       requires future Python interpreters to be able to emulate
>       *exactly* every previous version of Python, and moreover to do
>       so for multiple versions in the same interpreter.  This is way
>       too much work.  A much simpler solution is to keep multiple
>       interpreters installed.

While some number of version implementations may need to be supported
for some changes, this suggestion doesn't require them all in
perpetuity, so that's slightly misleading.  One could easily consider
some range of versions being supported (and retired over time), and an
advantage of this approach would be accurate (and reportable) breakage
if using code expecting version behavior no longer supported.

I agree that in general this would be a significant amount of work though.

> Command Line Option
> 
>     The -D command line option takes a string argument that can take
>     three values: "old", "warn", or "new".  The default is "old" in
>     Python 2.2 but will change to "warn" in later 2.x versions.  The
>     "old" value means the classic division operator acts as described.
>     The "warn" value means the classic division operator issues a
>     warning (a DeprecatinWarning using the standard warning framework)
                 ^Deprecation

> Semantics of Floor Division
> 
>     Floor division will be implemented in all the Python numeric
>     types, and will have the semantics of
> 
>         a // b == floor(a/b)
> 
>     except that the type of a//b will be the type a and b will be
>     coerced into.  Specifically, if a and b are of the same type, a//b
>     will be of that type too.

How will this work with complex numbers?  Is it actually a floor()
operation on the division result or something else?

Perhaps this section could more clearly lay out how this impacts each
of the current types and/or the coercions planned?  I noticed the
current sample patch has a comment to the effect of only doing the
right thing with ints and longs.

> Semantics of True Division
> 
>     True division for ints and longs will convert the arguments to
>     float and then apply a float division.  That is, even 2/1 will
>     return a float (2.0), not an int.

Since this is a statement of overall semantics for true division, it
might be useful to at least comment that complex numbers remain
unchanged in behavior (presumably?).

>     Q. How do I write code that works under the classic rules as well
>        as under the new rules without using // or a future division
>        statement?
> 
>     A. Use x*1.0/y for true division, divmod(x, y)[0] for int
>        division.  Especially the latter is best hidden inside a
>        function.  You may also write floor(x)/y for true division if
                                       ^float

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/