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 oc
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
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 (i
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
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
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 sa
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
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 poten
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
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
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
[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.
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 inver
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 fo
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
[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
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 mak
[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
_
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
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 impo
20 matches
Mail list logo
