On Thu, Feb 21, 2008 at 6:54 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Eric Smith]
>
> > Speaking for myself, these features are generally useful,
>  > and are so even without the new integer literal syntax.
>
>  I'm curious how these are useful to you in Py2.6 where
>  they are not invertible.  In Py3.0, we can count on
>
>   x == int(bin(x), 2)
>   x == eval(bin(x))
>
>  I don't see how these could work in Py2.6 without
>  changing the parser and changing the int() function.

And it needn't work. Nobody actually ever *uses* eval() on repr()
output (well, practically nobody :-).

>  Why would you ever want to create a string like
>  '0o144' when there is no way to convert the string
>  back into a value?
>
>  Having both 0123 and 0o123 in the same version of
>  language will create a confused mess, IMO.

I don't see why. 2.6 already has b'...' as an alias for '...', and
'except E as v' as an alias for 'except E, v'.

>  We should draw the line on Py3.0 backports whenever
>  the two different models would be conflated
>  (i.e. str/unicode vs bytes/text or 0123 vs 0o123).

I draw the line differently. Backports are absolutely not allowed to
break working code that used to work in 2.5. Apart from that, there is
no great harm in 2.6 supporting both the old and the new way. After
all we already have lots of places where Python 2.x supports an old
and a new way (e.g. string exceptions up to 2.5, classic classes, old
and rich comparisons).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to