RetroSearch Browse

Sat Nov 29 19:56:58 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040522.html

> > (2) PEP 237 promises that repr() of a long should no longer show a
> >     trailing 'L'.  This is not yet implemented (i.e., repr() of a long
> >     still has a trailing 'L').  First, past experience suggests that
> >     quite a bit of end user code will break, and it may easily break
> >     silently: there used to be code that did str(x)[:-1] (knowing x
> >     was a long) to strip the 'L', which broke when str() of a long no
> >     longer returned a trailing 'L'.  Apparently some of this code was
> >     "fixed" by changing str() into repr(), and this code will now
> >     break again.  Second, I *like* seeing a trailing L on longs,
> >     especially when there's no reason for it to be a long: if some
> >     expression returns 1L, I know something fishy may have gone on.
> 
> -0, The reasons are good but this one has been promised for several
> years.  It's time for an L free python -- one less thing to have to
> learn.

Yes, but people using type() or isinstance() or __class__ will still
have to remember that there are two types of integers: int and long.
And both built-ins will be with us for years, and they aren't quite
aliases for each other (long('12') returns a long, but int('12') an
int).

> If there is transition difficultly, let it be a prompt to consider
> applying the forthcoming Decimal module.

This I don't understand.

> If necessary, we could add a debug mode switch for L's to be on or off.
> By putting it the debug build, we keep people from using it in
> production code.  The purpose is to allow code to be run twice to see if
> different results are obtained.

But making a debug build is far from trivial (especially on Windows).
Perhaps it should be a switch on the regular build but also produce a
warning, to annoy. :-)

> Also, we can put migration advice in PEP 290 and whatsnew24.tex to grep
> for indicators like [:-1] on the same line as long() or repr().

Can you take care of that?

> > Should I update PEP 237 to reflect this?
> 
> Yes, that's better than surprising people later.

I'll do that (in due time).

--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040522.html below:

[Python-Dev] Int FutureWarnings and other 2.4 TODOs