Re: [Python-Dev] Backporting PEP 3127 to trunk
[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. 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. 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). Raymond
Raymond Hettinger 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.
Why would you ever want to create a string like '0o144' when there is no way to convert the string back into a value?
Because I need to output the values, for debugging and other purposes. I have no need to eval something I've bin'd, so I don't need them to be invertible. Same with hex. I realize I could just write these functions myself in Python, and not use the builtins. But I don't see the drawback of them being in 2.6. Eric.
On Thu, Feb 21, 2008 at 6:54 PM, Raymond Hettinger
[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/)
[GvR]
. 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).
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced. Also, I thought that the only reason you allowed b'' to be an alias for '' in 2.6 was that it was the only way 2-to-3 converter would work. That same rationale doesn't seem to apply here. I don't really see why the necessity of b'' should be seen as opening the flood gates to backport everything without regard to whether it makes Py2.6 better. Raymond
On Fri, Feb 22, 2008 at 9:06 AM, Raymond Hettinger
[GvR]
. 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).
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head.
Raymond, I am getting really sick and tired of your strong language like this. It feels like a personal attack to me, over and over. You seem to be the only one advocating 2.6 stay lean and mean (except of course when *you* want something new). I don't want to go over this discussion again. I've drawn the line at breaking code that works under 2.5; you need to be satisfied with that.
Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced.
Also, I thought that the only reason you allowed b'' to be an alias for '' in 2.6 was that it was the only way 2-to-3 converter would work. That same rationale doesn't seem to apply here. I don't really see why the necessity of b'' should be seen as opening the flood gates to backport everything without regard to whether it makes Py2.6 better.
Again with the colorful language. Nobody is opening floodgates. Enough said or I start using colorful language myself. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Raymond Hettinger wrote:
[GvR]
. 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).
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced.
Also, I thought that the only reason you allowed b'' to be an alias for '' in 2.6 was that it was the only way 2-to-3 converter would work. That same rationale doesn't seem to apply here. I don't really see why the necessity of b'' should be seen as opening the flood gates to backport everything without regard to whether it makes Py2.6 better.
It certainly doesn't seem to have the same urgency for cases where 2to3 can unambiguously do the right thing. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/
Raymond Hettinger wrote:
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced.
Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions. Robert Brewer fumanchu@aminus.org
Robert Brewer wrote:
Raymond Hettinger wrote:
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced.
Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions.
Unless you're trying to write code to work with both 2.6 and 3.0.
Eric Smith wrote:
Robert Brewer wrote:
Raymond Hettinger wrote:
I thought the whole point of 3.0 was a recognition that all that doubling-up was a bad thing and to be rid of it. Why make the situation worse? ISTM that we need two versions of oct() like we need a hole in the head. Heck, there's potentially a case to be made that we don't need oct() at all. IIRC, unix permissions like 0666 were the only use case that surfaced.
Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions.
Unless you're trying to write code to work with both 2.6 and 3.0.
Who would try that when PEP 3000 says (in bold type no less): There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset. ? And why should python-dev support such people? Robert Brewer fumanchu@aminus.org
Robert Brewer wrote:
Eric Smith wrote:
Robert Brewer wrote:
Postgres bytea coercion is a frequent use case for oct() in my world. But I agree we don't need two versions. Unless you're trying to write code to work with both 2.6 and 3.0.
Who would try that when PEP 3000 says (in bold type no less):
There is no requirement that Python 2.6 code will run unmodified on Python 3.0. Not even a subset.
?
Yes, but it also describes the "recommended development model for a project that needs to support Python 2.6 and 3.0 simultaneously". That is to run 2to3 on 2.6 code (which is -3 clean), and not edit the resulting code. I'm trying to enable that for code which wants to use some (small) 3.0 features. I don't see the harm in that. I think this means that the existing oct and hex builtins should raise a -3 warning. The future_builtins version would not raise a warning. Eric.
Raymond Hettinger wrote:
ISTM that we need two versions of oct() like we need a hole in the head.
I don't know about oct(), but I found hex() to be quite useful the other day when I was using the interactive interpreter to to some hex calculations. It would have been quite tedious having to say "%x".format(_) or some such all the time to see the results in hex. An alternative might be to have some variable that can be set to control the format of numbers printed by the interactive shell. -- Greg
Greg Ewing
I don't know about oct(), but I found hex() to be quite useful the other day when I was using the interactive interpreter to to some hex calculations. It would have been quite tedious having to say "%x".format(_) or some such all the time to see the results in hex.
An alternative might be to have some variable that can be set to control the format of numbers printed by the interactive shell.
Something like this?
import sys import __builtin__ def myhook(o): ... if isinstance(o, int): ... print hex(o) ... else: ... print repr(o) ... __builtin__._ = o ... sys.displayhook = myhook 123 0x7b
Bernhard
participants (7)
-
Bernhard Herzog -
Eric Smith -
Greg Ewing -
Guido van Rossum -
Raymond Hettinger -
Robert Brewer -
Steve Holden