Re: [Python-Dev] future_builtins
Guido van Rossum wrote: > I don't think a -3 warning for oct or hex would do any good. I'm curious as to why. oct and hex have different behavior in 3.0, which is what I thought -3 was for. hex might be overkill, as the only differences are the "L" and the __hex__ behavior. But oct is always different. ___ 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] future_builtins
On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > I don't think a -3 warning for oct or hex would do any good. > > I'm curious as to why. oct and hex have different behavior in 3.0, > which is what I thought -3 was for. hex might be overkill, as the only > differences are the "L" and the __hex__ behavior. But oct is always > different. Well, yeah, but what are you going to do about it? Not use oct()? I expect that *most* programs using oct() or hex() will work just as well under 3.0; typically the output is just printed, not parsed or otherwise further processed. I think -3 should only warn about things where it's easy to modify the code so that it continues to work under 2.6 but will also work under 3.0. Forcing people to use "%o" just to get rid of the warning doesn't make sense to me. -- --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] future_builtins
Guido van Rossum wrote: > On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith > <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >> > I don't think a -3 warning for oct or hex would do any good. >> >> I'm curious as to why. oct and hex have different behavior in 3.0, >> which is what I thought -3 was for. hex might be overkill, as the only >> differences are the "L" and the __hex__ behavior. But oct is always >> different. > > Well, yeah, but what are you going to do about it? Not use oct()? I > expect that *most* programs using oct() or hex() will work just as > well under 3.0; typically the output is just printed, not parsed or > otherwise further processed. > > I think -3 should only warn about things where it's easy to modify the > code so that it continues to work under 2.6 but will also work under > 3.0. Forcing people to use "%o" just to get rid of the warning doesn't > make sense to me. > My thinking wast that using code that run under -3 without warnings would work exactly the same under 3.0, after running through 2to3. So if oct() gave me a warning, I'd switch to the future_builtins version, and do whatever it took to get my program running again under 2.6 (which might involve not caring that the output changed from 2.5 to 2.6). Maybe it's wishful thinking. I'm not too worried about this specific case, either. ___ 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] future_builtins
On Sat, Feb 23, 2008 at 11:34 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > > On Sat, Feb 23, 2008 at 9:01 AM, Eric Smith > > <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: > >> > I don't think a -3 warning for oct or hex would do any good. > >> > >> I'm curious as to why. oct and hex have different behavior in 3.0, > >> which is what I thought -3 was for. hex might be overkill, as the only > >> differences are the "L" and the __hex__ behavior. But oct is always > >> different. > > > > Well, yeah, but what are you going to do about it? Not use oct()? I > > expect that *most* programs using oct() or hex() will work just as > > well under 3.0; typically the output is just printed, not parsed or > > otherwise further processed. > > > > I think -3 should only warn about things where it's easy to modify the > > code so that it continues to work under 2.6 but will also work under > > 3.0. Forcing people to use "%o" just to get rid of the warning doesn't > > make sense to me. > My thinking wast that using code that run under -3 without warnings > would work exactly the same under 3.0, after running through 2to3. That's wishful thinking. :) > So if oct() gave me a warning, I'd switch to the future_builtins version, > and do whatever it took to get my program running again under 2.6 (which > might involve not caring that the output changed from 2.5 to 2.6). > Maybe it's wishful thinking. I'm not too worried about this specific > case, either. I think practicality says we should not warn about this. -- --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] future_builtins (was: Backporting PEP 3127 to trunk)
Georg Brandl 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)? I can certainly do the mechanics of adding the new versions of map and filter to future_builtins, if it's seen as desirable. Maybe we could have 2to3 not put list() around map and filter, if there's been an import of future_builtins. I realize that there are pathological cases where 2to3 doesn't know that a usage of map or filter would really be the generator version from future_builtins, as opposed to the actual list-producing builtins. But would it be good enough to take an import of future_builtins as a hint that the author was aware that 2to3 wasn't going to change map and filter? Still an open issue in my mind is adding a -3 warning to oct and hex, and now conceivably map and filter. Would that be going too far? 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] future_builtins (was: Backporting PEP 3127 to trunk)
I don't think a -3 warning for oct or hex would do any good. I do think map() and filter() should issue a warning under -3 when the first arg is None. (Or does 2to3 detect this now?) On Sat, Feb 23, 2008 at 6:06 AM, Eric Smith <[EMAIL PROTECTED]> wrote: > Georg Brandl 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)? > > I can certainly do the mechanics of adding the new versions of map and > filter to future_builtins, if it's seen as desirable. > > Maybe we could have 2to3 not put list() around map and filter, if > there's been an import of future_builtins. I realize that there are > pathological cases where 2to3 doesn't know that a usage of map or filter > would really be the generator version from future_builtins, as opposed > to the actual list-producing builtins. But would it be good enough to > take an import of future_builtins as a hint that the author was aware > that 2to3 wasn't going to change map and filter? > > Still an open issue in my mind is adding a -3 warning to oct and hex, > and now conceivably map and filter. Would that be going too far? > > 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
Re: [Python-Dev] future_builtins (was: Backporting PEP 3127 to trunk)
On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > I do think map() and filter() should issue a warning under -3 when the > first arg is None. (Or does 2to3 detect this now?) What's wrong with filter(None, seq)? That currently works in 3k: >>> filter(None, range(5)) >>> [x for x in _] [1, 2, 3, 4] (Side note, shouldn't we change the names for filter/map?) n ___ 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] future_builtins (was: Backporting PEP 3127 to trunk)
On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I don't think a -3 warning for oct or hex would do any good. > > I do think map() and filter() should issue a warning under -3 when the > first arg is None. (Or does 2to3 detect this now?) 2to3 does detect that: it will turn map(None, foo) into list(foo). > On Sat, Feb 23, 2008 at 6:06 AM, Eric Smith > <[EMAIL PROTECTED]> wrote: > > Georg Brandl 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)? > > > > I can certainly do the mechanics of adding the new versions of map and > > filter to future_builtins, if it's seen as desirable. > > > > Maybe we could have 2to3 not put list() around map and filter, if > > there's been an import of future_builtins. I realize that there are > > pathological cases where 2to3 doesn't know that a usage of map or filter > > would really be the generator version from future_builtins, as opposed > > to the actual list-producing builtins. But would it be good enough to > > take an import of future_builtins as a hint that the author was aware > > that 2to3 wasn't going to change map and filter? > > > > Still an open issue in my mind is adding a -3 warning to oct and hex, > > and now conceivably map and filter. Would that be going too far? > > > > 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/collinw%40gmail.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] future_builtins (was: Backporting PEP 3127 to trunk)
On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > > I do think map() and filter() should issue a warning under -3 when the > > first arg is None. (Or does 2to3 detect this now?) > > What's wrong with filter(None, seq)? That currently works in 3k: > > >>> filter(None, range(5)) > > >>> [x for x in _] > [1, 2, 3, 4] But that's a bug -- it's been spec'ed that this will stop working. (Can't remember where, perhaps PEP 3100?) > (Side note, shouldn't we change the names for filter/map?) Huh? What? Why? -- --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] future_builtins (was: Backporting PEP 3127 to trunk)
On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > > > > > > I do think map() and filter() should issue a warning under -3 when the > > > first arg is None. (Or does 2to3 detect this now?) > > > > What's wrong with filter(None, seq)? That currently works in 3k: > > > > >>> filter(None, range(5)) > > > > >>> [x for x in _] > > [1, 2, 3, 4] > > But that's a bug -- it's been spec'ed that this will stop working. > (Can't remember where, perhaps PEP 3100?) I looked in 3100 and didn't see it. > > (Side note, shouldn't we change the names for filter/map?) > > Huh? What? Why? The function name returned by repr: itertools.ifilter. n ___ 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] future_builtins (was: Backporting PEP 3127 to trunk)
On Sun, Feb 24, 2008 at 7:02 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > On Sun, Feb 24, 2008 at 6:57 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Sat, Feb 23, 2008 at 5:59 PM, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > > On Sat, Feb 23, 2008 at 8:06 AM, Guido van Rossum <[EMAIL PROTECTED]> > wrote: > > > > > > > > I do think map() and filter() should issue a warning under -3 when > the > > > > first arg is None. (Or does 2to3 detect this now?) > > > > > > What's wrong with filter(None, seq)? That currently works in 3k: > > > > > > >>> filter(None, range(5)) > > > > > > >>> [x for x in _] > > > [1, 2, 3, 4] > > > > But that's a bug -- it's been spec'ed that this will stop working. > > (Can't remember where, perhaps PEP 3100?) > > I looked in 3100 and didn't see it. Hm. Well, it's still the plan. > > > (Side note, shouldn't we change the names for filter/map?) > > > > Huh? What? Why? > > The function name returned by repr: itertools.ifilter. I see. Yes, that's a bug. You could say that the way map and filter are implemented in py3k at the moment is a prototype. I'll file bugs for both of these. -- --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
