Re: [Python-Dev] Backporting PEP 3127 to trunk
On Sat, Feb 23, 2008 at 2:57 AM, Georg Brandl <[EMAIL PROTECTED]> wrote: > Eric Smith schrieb: > > > > Guido van Rossum wrote: > >> I wonder if, in order to change the behavior of various built-in > >> functions, it wouldn't be easier to be able to write > >> > >> from future_builtins import oct, hex # and who knows what else > > > > This makes sense to me, especially if we have a 2to3 fixer which removes > > this line. I'll work on implementing future_builtins. > > Will the future map and filter also belong there (and if they are imported > from future_builtins, 2to3 won't put a list() around them)? Good idea, on both counts! These an just be imported from itertools anyway (except they should be wrapped in something that rejects a None function). And zip() ditto. I suggest that if you don't implement this right away (while the bug day is still on :), you at least add a feature request to the issue tracker, marked easy. -- --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
Re: [Python-Dev] Backporting PEP 3127 to trunk
Eric Smith schrieb: > Guido van Rossum wrote: >> I wonder if, in order to change the behavior of various built-in >> functions, it wouldn't be easier to be able to write >> >> from future_builtins import oct, hex # and who knows what else > > This makes sense to me, especially if we have a 2to3 fixer which removes > this line. I'll work on implementing future_builtins. Will the future map and filter also belong there (and if they are imported from future_builtins, 2to3 won't put a list() around them)? Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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. ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
Greg Ewing <[EMAIL PROTECTED]> writes: > 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 ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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 [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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 ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
Guido van Rossum wrote: > I wonder if, in order to change the behavior of various built-in > functions, it wouldn't be easier to be able to write > > from future_builtins import oct, hex # and who knows what else This makes sense to me, especially if we have a 2to3 fixer which removes this line. I'll work on implementing future_builtins. ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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. ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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 [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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/ ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
On Fri, Feb 22, 2008 at 9:06 AM, Raymond Hettinger <[EMAIL PROTECTED]> 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. 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/) ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
[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 ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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
Re: [Python-Dev] Backporting PEP 3127 to trunk
On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I'm going to work on backporting PEP 3127, specifically the hex, oct(), > and bin() builtins. I have bin() completed, and I'll check it in > shortly. oct() will require a future import. Does anyone have any > pointers for implementing this? I understand (and have completed) > adding the future import, but what I don't understand is how to modify > the behavior of oct() for only the module where the future import is > execute. Any rough ideas or pointers to existing code that does > something similar would be helpful. See co_flags in PyCodeObject in Include/code.h. When you are compiling the code objects, you have access to the future flags. These (can) get baked into the code objects when they are created. You will need to make a new CO_* macro (0x1 is the next available after CO_FUTURE_WITH_STATEMENT). In the past future imports have typically affected the parser or semantics of the VM (e.g., future division). In your case, you need something different. Thomas Wouters had a somewhat similar problem when changing dict methods. In his case though, he output different op codes for the interpreter to execute to call the proper methods (*). You could use a similar trick here. However, if you were doing that, it begs the question of why not do as Guido suggests and just replace the builtins. If you only stored the info in the co_flags of code objects, the only way I know of would be to access the callers frame and get its co_flags. This is yucky. For example, what if oct() was called from C code? I think Guido's suggestion makes the most sense. My description above is just so people know what needs to be done, not a recommendation that it ought to be done. n (*) - e.g. STORE_VIEWATTR in http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/ceval.c http://svn.python.org/projects/python/branches/twouters-dictviews-backport/Python/compile.c ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
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. ___ 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
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 ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
Raymond Hettinger wrote: > [Eric Smith] >> I'm going to work on backporting PEP 3127, specifically >> the hex, oct(), and bin() builtins. > > IMO, these should not be backported. They are strongly > associated with 3.0's new literal syntax. They don't > don't really fit in with 2.6 and don't make 2.6 any more > attractive. I'm just going by what's on the spreadsheet. I assumed that these were all vetted. http://spreadsheets.google.com/pub?key=pCKY4oaXnT81FrGo3ShGHGg&gid=2 Speaking for myself, these features are generally useful, and are so even without the new integer literal syntax. Their existence would make 2.6 more attractive to me. Eric. ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
[Eric Smith] > I'm going to work on backporting PEP 3127, specifically >the hex, oct(), and bin() builtins. IMO, these should not be backported. They are strongly associated with 3.0's new literal syntax. They don't don't really fit in with 2.6 and don't make 2.6 any more attractive. Raymond ___ 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
Re: [Python-Dev] Backporting PEP 3127 to trunk
I wonder if, in order to change the behavior of various built-in functions, it wouldn't be easier to be able to write from future_builtins import oct, hex # and who knows what else Agreed with your approach for bin(). On Thu, Feb 21, 2008 at 2:26 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I'm going to work on backporting PEP 3127, specifically the hex, oct(), > and bin() builtins. I have bin() completed, and I'll check it in > shortly. oct() will require a future import. Does anyone have any > pointers for implementing this? I understand (and have completed) > adding the future import, but what I don't understand is how to modify > the behavior of oct() for only the module where the future import is > execute. Any rough ideas or pointers to existing code that does > something similar would be helpful. I also need a name for the future > import statement. > > Also, I notice in py3k that __hex__ and __oct__ have vanished, and > instead hex() and oct() just uses the __index__ machinery to produce a > number, then converts that to a string. So I'm thinking that maybe we > could use the same future import statement that controls oct()'s > behavior to also switch hex() and oct() to the py3k behavior. Or, maybe > we should use a different future import? Or, I guess, not do this at > all. But I think it's a good idea. > > I guess another issue is changing hex()'s behavior of adding a trailing > L for longs. I don't really see the value in this, and maybe it should > also change with a future import statement. > > For bin(), I just used the py3k behavior, and didn't implement a __bin__ > method. I'm also not adding a trailing L for longs. I think that makes > the most sense. > > Eric. > > ___ > 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/guido%40python.org > -- --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
[Python-Dev] Backporting PEP 3127 to trunk
I'm going to work on backporting PEP 3127, specifically the hex, oct(), and bin() builtins. I have bin() completed, and I'll check it in shortly. oct() will require a future import. Does anyone have any pointers for implementing this? I understand (and have completed) adding the future import, but what I don't understand is how to modify the behavior of oct() for only the module where the future import is execute. Any rough ideas or pointers to existing code that does something similar would be helpful. I also need a name for the future import statement. Also, I notice in py3k that __hex__ and __oct__ have vanished, and instead hex() and oct() just uses the __index__ machinery to produce a number, then converts that to a string. So I'm thinking that maybe we could use the same future import statement that controls oct()'s behavior to also switch hex() and oct() to the py3k behavior. Or, maybe we should use a different future import? Or, I guess, not do this at all. But I think it's a good idea. I guess another issue is changing hex()'s behavior of adding a trailing L for longs. I don't really see the value in this, and maybe it should also change with a future import statement. For bin(), I just used the py3k behavior, and didn't implement a __bin__ method. I'm also not adding a trailing L for longs. I think that makes the most sense. Eric. ___ 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
