PEP 238 (revised)

Guido van Rossum guido at
Fri Jul 27 10:09:43 EDT 2001

Peter Hansen <peter at> writes:

> Guido van Rossum wrote:
> > 
> > Here's a completely revised version of PEP 238.  
> [...]
> > 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)
> >     when applied to ints or longs.  The "new" value changes the
> >     default globally so that the / operator is always interpreted as
> >     true division.  
> The choice of command line options is inconsistent with the terminology
> used elsewhere in the updated PEP.  
> To further reduce the potential for confusion, I suggest changing
> "old" and "new" to "classic" and "true".  

I considered this, but I disagree.  I don't think there will be much
confusion since the words "classic" and "true" don't occur in the
source (except when overloading __truediv__).  The old/new distinction
makes the arrow of time more obvious.

> If that suggestion is accepted, "warn" might be better spelled 
> more like "classic-warn".
> --
> The updated PEP also makes no mention of a utility for scanning 
> existing code to check for potential problems.  Is this considered
> an intractable problem?  Is there any commitment to doing this,
> eventually, as part of the implementation of this PEP?  Or is the
> presence of the "warn" option considered sufficient (to allow for
> testing, rather than scanning)?

The PEP can't address everything.  I have no idea how to write such a
scanner, and I think it would require type inference of unrivaled
sophistication, so I'm not keen on promising it in the PEP.  I assume
there will be some kind of conversion tool, but it's outside the scope
of the PEP.

--Guido van Rossum (home page:

More information about the Python-list mailing list