> "BAW" == Barry Warsaw <[EMAIL PROTECTED]> writes:
BAW> Unix weenies shouldn't be totally forgotten in P3K.
Great idea! Put all this stuff in a "weenie" module. You can have
weenie.unix and weenie.vms and weenie.unicode, besides the weenie.math
that got all this started.
--
School of
On Fri, 2006-01-20 at 06:56 +1000, Nick Coghlan wrote:
> I'm not aware of anyone that would miss octal literals, but there are plenty
> of hardware weenies like me that would find "int("DEAD", 16)" less convenient
> than "0xDEAD".
Although octal literals is handy for things like os.chmod(). Un
On Jan 19, 2006, at 4:17 PM, Thomas Wouters wrote:
> On Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote:
>
>> I'm not aware of anyone that would miss octal literals,
>
> Except anyone who uses os.chmod. I would be mighty sad if we
> removed octal
> and hexadecimal literals for 'cleanl
On Fri, Jan 20, 2006 at 06:56:23AM +1000, Nick Coghlan wrote:
> I'm not aware of anyone that would miss octal literals,
Except anyone who uses os.chmod. I would be mighty sad if we removed octal
and hexadecimal literals for 'cleanliness' reasons alone.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi!
[Nick Coghlan]
> ...
> I quite like the suggestion of using 'math.base' rather than a builtin, but
> there are still issues to be figured out there:
>- the math module is currently a thin wrapper around C's "math.h". Do we
> really want to change that by adding more methods?
That's not an issu
Nick Coghlan wrote:
> Guido van Rossum wrote:
>
>>On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>>>Guido van Rossum wrote:
>>>
>>>
I think we ought to let this sit for a while and come back to it in a
few week's time. Is 'base' really the right name? It could just as
well be
Guido van Rossum wrote:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> well be considered a conversion in the ot
On Jan 19, 2006, at 11:12 AM, Guido van Rossum wrote:
> On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> I think we ought to let this sit for a while and come back to it
>>> in a
>>> few week's time. Is 'base' really the right name? It could just as
>>> wel
On 1/19/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 19, 2006, Jeremy Hylton wrote:
> >
> > I'm not sure I believe this should be a builtin. I think the
> > threshold for new builtins ought to be nearly as high as the threshold
> > for new keywords. Or the proposer ought to make an argument
Raymond Hettinger wrote:
> That suggests that it would be better to simply add an int method:
> x.convert_to_base(7)
I'd suggest allowing:
x.convert_to_base('0123456')
Where the (str or unicode) argument is the list of digits in order.
This would allow easy converting to base-64 and ot
On Thu, Jan 19, 2006, Jeremy Hylton wrote:
>
> I'm not sure I believe this should be a builtin. I think the
> threshold for new builtins ought to be nearly as high as the threshold
> for new keywords. Or the proposer ought to make an argument about
> what the function should not go in a module.
On 1/19/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > I think we ought to let this sit for a while and come back to it in a
> > few week's time. Is 'base' really the right name? It could just as
> > well be considered a conversion in the other direction.
>
> the same
Guido van Rossum wrote:
> I think we ought to let this sit for a while and come back to it in a
> few week's time. Is 'base' really the right name? It could just as
> well be considered a conversion in the other direction.
the same applies to hex and oct, of course.
as for base itself, I'm more
On Jan 19, 2006, at 10:31, Guido van Rossum wrote:
To keep it simple, the proposal is for the value to be any int or
long.
With an underlying __base__ method call, it wouldn't be hard for
someone
to build it out to support other numeric types if the need arises.
Let's not. What would 3.14
I'm not sure I believe this should be a builtin. I think the
threshold for new builtins ought to be nearly as high as the threshold
for new keywords. Or the proposer ought to make an argument about
what the function should not go in a module.
Jeremy
On 1/19/06, Guido van Rossum <[EMAIL PROTECTE
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Guido, we may be converging on a consensus for my proposal:
>
> base(value, radix=2)
>
> So far no one has shot at it, and it has gathered +1's from Steven,
> Alex, Brett, and Nick.
I think we ought to let this sit for a while and come
On Thursday 2006-01-19 11:15, Thomas Wouters wrote:
> On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
...
> > Introducing a new builtin with a name that's a common, short
> > English word is a bit disagreeable.
>
> While I don't particularly mind the new function in either the bu
On Thu, Jan 19, 2006 at 10:23:30AM +, Gareth McCaughan wrote:
> > +1 on introducing base()
> Introducing a new builtin with a name that's a common, short
> English word is a bit disagreeable.
While I don't particularly mind the new function in either the builtin
module or another, like math,
On Wednesday 2006-01-18 16:55, Steven Bethard wrote:
> [Raymond]
> > Perhaps introduce a single function, base(val, radix=10,
> > prefix=''), as a universal base converter that could replace
> > bin(), hex(), oct(), etc.
>
> +1 on introducing base()
Introducing a new builtin with a name that's a
On Jan 18, 2006, at 11:37 PM, Neal Norwitz wrote:
> On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> Guido, we may be converging on a consensus for my proposal:
>>
>> base(value, radix=2)
>>
>> So far no one has shot at it, and it has gathered +1's from Steven,
>> Alex, Brett, and
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Guido, we may be converging on a consensus for my proposal:
>
> base(value, radix=2)
>
> So far no one has shot at it, and it has gathered +1's from Steven,
> Alex, Brett, and Nick.
+1 for me too, but I'd also like to deprecate hex() a
Guido, we may be converging on a consensus for my proposal:
base(value, radix=2)
So far no one has shot at it, and it has gathered +1's from Steven,
Alex, Brett, and Nick.
To keep it simple, the proposal is for the value to be any int or long.
With an underlying __base__ method call, it woul
On 1/18/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote:
>
> > On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I'd propose bin() to stay in line with the short abbreviated names.
> >>>
> >>> There has been some previous discussion abou
On Jan 18, 2006, at 11:09 AM, Brett Cannon wrote:
> On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
I'd propose bin() to stay in line with the short abbreviated names.
>>>
>>> There has been some previous discussion about removing hex()/oct()
>> from
>>> builtins for Python 3.0, IIRC
Brett Cannon wrote:
> On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
I'd propose bin() to stay in line with the short abbreviated names.
>>> There has been some previous discussion about removing hex()/oct()
>> from
>>> builtins for Python 3.0, IIRC. I sure don't think bin() belongs
Jack wrote:
> The arbitrary base case isn't even academic
> or we would see homework questions about it
> on c.l.py. No one asks about
> hex or octal because they are there.
I have wanted base-36 far more often than I've
wanted base-8. I haven't needed any base
(except 10) often enough to justi
On 1/18/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > > I'd propose bin() to stay in line with the short abbreviated names.
> >
> > There has been some previous discussion about removing hex()/oct()
> from
> > builtins for Python 3.0, IIRC. I sure don't think bin() belongs
> there.
>
> Perh
Jason Orendorff wrote:
> On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
>
>>I think supporting arbitrary bases for floats is way overkill and not
>>worth considering.
>
>
> If you mean actual base-3 floating-point arithmetic, I agree. That's
> outlandish.
>
> But if there were a stdlib
[Raymond]
> Perhaps introduce a single function, base(val, radix=10,
> prefix=''), as a universal base converter that could replace
> bin(), hex(), oct(), etc.
+1 on introducing base()
[Skip]
> Would it (should it) work with floats, decimals, complexes? I presume it
> would work with ints and lo
On 1/18/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> I think supporting arbitrary bases for floats is way overkill and not
> worth considering.
If you mean actual base-3 floating-point arithmetic, I agree. That's
outlandish.
But if there were a stdlib function to format floats losslessly in h
Raymond> Perhaps introduce a single function, base(val, radix=10,
Raymond> prefix=''), as a universal base converter that could replace
Raymond> bin(), hex(), oct(), etc.
Would it (should it) work with floats, decimals, complexes? I presume it
would work with ints and longs.
Skip
__
> > I'd propose bin() to stay in line with the short abbreviated names.
>
> There has been some previous discussion about removing hex()/oct()
from
> builtins for Python 3.0, IIRC. I sure don't think bin() belongs
there.
Perhaps introduce a single function, base(val, radix=10, prefix=''), as
a u
On Tue, Jan 17, 2006, Guido van Rossum wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>>
>> The difference between hex() and oct() and the proposed binary() is
>
> I'd propose bin() to stay in line with the short abbreviated names.
There has been some previous discussion about remo
On Tue, 2006-01-17 at 20:25 -0800, Guido van Rossum wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> > There shouldn't be a %B for the same reason there isn't an %O or %D
> > -- they're all just digits, so there's not a need for an uppercase
[...]
so %b is "binary",
+1
> > The diff
On Tue, 2006-01-17 at 16:38 -0700, Adam Olsen wrote:
> On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> > On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
[...]
> I dream of a day when str(3.25, base=2) == '11.01'. That is the
> number a float really represents. It would be
Steve Holden wrote:
[...]
> Personally I wouldn't even be interested in seeing
> 1.3407807929942597e+154 written in fixed point form *in decimal*, let
> alone in binary where the representation, though unambiguous, would have
> over 500 bits, most of them zeros.
>
Well, shot myself in the foot
Adam Olsen wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>>On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote:
>>
>>
>>>I dream of a day when str(3.25, base=2) == '11.01'. That is the
>>>number a float really represents. It would be so much easier to
>>>understand why floats behave t
Adam Olsen wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
>>On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
>>
>>
>>>On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>>
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>>In-favour-of-%2b-ly y'rs,
>
>My o
Jack Diederich <[EMAIL PROTECTED]> writes:
> > However... if %b were to represent arbitrary bases, I think that's
> > backwards. It should be %[][.]b, which would do this:
> >
> > >>> '%08b %08o %08d %08x' % 12
> > '1100 0014 0012 000C'
> >
>
> Were I BDFAD (not to be
Guido van Rossum wrote:
[...]
>
> I'd propose bin() to stay in line with the short abbreviated names.
>
[...]
>
> The binary type should have a 0b prefix.
It seems odd to me to add both a builtin *and* new syntax for something that's
occasionally handy, but only occasionally. If we're going to
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > The difference between hex() and oct() and the proposed binary() is
>
> I'd propose bin() to stay in line with the short abbreviated names.
Are these features used enough to have 3 builtins?
Would format(number, base) suffice?
format
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> > There shouldn't be a %B for the same reason there isn't an %O or %D
> > -- they're all just digits, so there's not a need for an uppercase
> > variant.
>
> Right.
>
> > The difference b
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> There shouldn't be a %B for the same reason there isn't an %O or %D
> -- they're all just digits, so there's not a need for an uppercase
> variant.
Right.
> The difference between hex() and oct() and the proposed binary() is
I'd propose bin()
On Jan 17, 2006, at 7:12 PM, Jack Diederich wrote:
> On Tue, Jan 17, 2006 at 06:11:36PM -0800, Bob Ippolito wrote:
>>
>> On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote:
>>
>>> On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote:
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrot
On Tue, Jan 17, 2006 at 06:11:36PM -0800, Bob Ippolito wrote:
>
> On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote:
>
> >On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote:
> >>On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> In-favour-of-%2b-ly y'rs,
> >>>
> >>>My only oppo
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
>
> > On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> In-favour-of-%2b-ly y'rs,
> >>>
> >>> My only opposition to this is that
On 1/17/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote:
>
> > I dream of a day when str(3.25, base=2) == '11.01'. That is the
> > number a float really represents. It would be so much easier to
> > understand why floats behave the way they do if it w
On Jan 17, 2006, at 5:01 PM, Jack Diederich wrote:
> On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote:
>> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
In-favour-of-%2b-ly y'rs,
>>>
>>> My only opposition to this is that the byte type may want to use it.
>>> I'd rather wa
On Jan 17, 2006, at 3:38 PM, Adam Olsen wrote:
> On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>> On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
>>
>>> I think a method 5664400.to_base(13) sounds nice.
>> [And others suggested int-methods too]
>>
>> I would like to point
On Tue, Jan 17, 2006 at 04:02:43PM -0800, Guido van Rossum wrote:
> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > In-favour-of-%2b-ly y'rs,
> >
> > My only opposition to this is that the byte type may want to use it.
> > I'd rather wait until byte is fully defined, implemented, and releas
On Jan 17, 2006, at 4:09 PM, Adam Olsen wrote:
> On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
In-favour-of-%2b-ly y'rs,
>>>
>>> My only opposition to this is that the byte type may want to use it.
>>> I'd rather wait until byte
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > In-favour-of-%2b-ly y'rs,
> >
> > My only opposition to this is that the byte type may want to use it.
> > I'd rather wait until byte is fully defined, implemented, and released
> > in
On 1/17/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > In-favour-of-%2b-ly y'rs,
>
> My only opposition to this is that the byte type may want to use it.
> I'd rather wait until byte is fully defined, implemented, and released
> in a python version before that option is taken away.
Has this been pr
On 1/17/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
>
> > I think a method 5664400.to_base(13) sounds nice.
> [And others suggested int-methods too]
>
> I would like to point out that this is almost, but not quite, entirely as
> i
On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
> I think a method 5664400.to_base(13) sounds nice.
[And others suggested int-methods too]
I would like to point out that this is almost, but not quite, entirely as
inapropriate as using str(). Integers don't have a base. String
rep
On 1/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> OK, so, should I just submit a patch?
Hmm, there are quite a few people who strongly dislike the particular
API you're proposing. The problem is, bright newbies might be led to
wanting str(i, base) as an analogy to int(s, base) only because th
On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> > str(5,2) to give '101', just the converse of the way int('101',1)
> [I'm sure you meant int('101', 2) here]
Ye
Hi Alex,
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5?
+1. That's obvious enough for me. Clearly it should only work with int
and long arguments, just like int(x,base) only works if x is a st
On Mon, Jan 16, 2006, Alex Martelli wrote:
>
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's the
On 1/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> class Color:
> msg = {'en':['red', 'green', 'blue'], 'de':['rot','grün','blau']}
> def __str__(self, language='en'):
> return self.msg[language][self.value]
>
> red = Color(0)
>
> so you could say
>
> print str(red, 'de'
[EMAIL PROTECTED] wrote:
>Skip> A shortcoming in int() hardly seems like a good reason to mess
>Skip> with str().
>
>Gareth> How's it a shortcoming in int() that it doesn't do anything
>Gareth> with, say, int(2.345,19)?
>
> My reasoning was that just because int() was written to ig
Alex> Identically the same situation as for int: the base argument is
Alex> only accepted if the first argument is a str (not a float, etc).
Alex> Just the same way, the base argument to str will only be accepted
Alex> if the first argument is an int (not a float, etc).
>>
On Tuesday 2006-01-17 15:19, [EMAIL PROTECTED] wrote:
> Alex> Identically the same situation as for int: the base argument is
> Alex> only accepted if the first argument is a str (not a float, etc).
> Alex> Just the same way, the base argument to str will only be accepted
> Alex> i
Alex> Identically the same situation as for int: the base argument is
Alex> only accepted if the first argument is a str (not a float, etc).
Alex> Just the same way, the base argument to str will only be accepted
Alex> if the first argument is an int (not a float, etc).
A shortcom
Raymond> My reason is that I've rolled-my-own more times than I can
Raymond> count but infrequently enough to where it was easier to
Raymond> re-write than to search for the previous use.
Maybe a bin() builtin would be better. Even better it seems to me would be
to add a method to in
Raymond wrote:
> I presume that only the str() builtin would
> change and that the underlying __str__ slot
> would continue to be hard-wired to the
> (reprfunc) signature.
Are you saying that subclasses of str should
behave differently from the builtin str, and not
in the slots that were added or
On Tue, Jan 17, 2006 at 09:23:29AM -0500, Jason Orendorff wrote:
> It seems dumb to support *parsing* integers in weird bases, but not
> *formatting* them in weird bases. Not a big deal, but if you're going
> to give me a toy, at least give me the whole toy!
>
> The %b idea is a little disappoint
It seems dumb to support *parsing* integers in weird bases, but not
*formatting* them in weird bases. Not a big deal, but if you're going
to give me a toy, at least give me the whole toy!
The %b idea is a little disappointing in two ways. Even with %b,
Python is still dumb by the above criterion
Donovan Baarda <[EMAIL PROTECTED]> writes:
> I personally think %b would be adding enough. The other suggestions are
> just me being silly :-)
Yeah, the whole area is just crying out for the simplicity and
restraint that is common lisp's #'format function :)
Cheers,
mwh
--
INEFFICIENT CAPIT
On Tue, 2006-01-17 at 10:05 +, Nick Craig-Wood wrote:
> On Mon, Jan 16, 2006 at 11:13:27PM -0500, Raymond Hettinger wrote:
[...]
> Another suggestion would be to give hex() and oct() another parameter,
> base, so you'd do hex(123123123, 2). Perhaps a little
> counter-intuitive, but if you were
On Jan 17, 2006, at 2:48 AM, Fredrik Lundh wrote:
> Bob Ippolito wrote:
>
>> I want binary all the time when I'm dealing with bitflags and such.
>> Of course, I'm trained to be able to read bits in hex format, but it
>> would be nicer to see the flags as-is. Even worse when you have to
>> deal w
Bob Ippolito wrote:
> I want binary all the time when I'm dealing with bitflags and such.
> Of course, I'm trained to be able to read bits in hex format, but it
> would be nicer to see the flags as-is. Even worse when you have to
> deal with some kind of file format where fields are N bits long,
On Jan 17, 2006, at 2:36 AM, Ian Bicking wrote:
> Bob Ippolito wrote:
>> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
>>> On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
>>> [...]
>>>
That suggests that it would be better to simply add an int method:
x
Bob Ippolito wrote:
> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
>
>
>>On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
>>[...]
>>
>>>That suggests that it would be better to simply add an int method:
>>>
>>> x.convert_to_base(7)
>>
>>This seems clear and simple to
Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's there and it's awkward to e
On Mon, Jan 16, 2006 at 11:13:27PM -0500, Raymond Hettinger wrote:
> My reason is that I've rolled-my-own more times than I can count but
> infrequently enough to where it was easier to re-write than to search
> for the previous use.
Me too! The assymetry is annoying. Its easy to consume base 2.
On Tue, 2006-01-17 at 01:03 -0500, Barry Warsaw wrote:
> On Mon, 2006-01-16 at 20:49 -0800, Bob Ippolito wrote:
>
> > The only bases I've ever really had a good use for are 2, 8, 10, and
> > 16. There are currently formatting codes for 8 (o), 10 (d, u), and
> > 16 (x, X). Why not just add a
Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
> gives 5? I'm not sure why str has never allowed this obvious use --
> any bright beginner assumes it's there and it's awkward to e
On 1/16/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
>
> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
>
> > On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
> > [...]
> >> That suggests that it would be better to simply add an int method:
> >>
> >> x.convert_to_base(7)
On 1/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> > Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> > str(5,2) to give '101', just the converse of the way int('101',1)
> [I'm sure you meant int('101', 2) here]
> >
On Mon, 2006-01-16 at 20:49 -0800, Bob Ippolito wrote:
> The only bases I've ever really had a good use for are 2, 8, 10, and
> 16. There are currently formatting codes for 8 (o), 10 (d, u), and
> 16 (x, X). Why not just add a string format code for unsigned
> binary? The obvious choice i
On Mon, Jan 16, 2006 at 09:28:10PM -0800, Bob Ippolito wrote:
> On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
[...]
> >> x.convert_to_base(7)
> >
> >This seems clear and simple to me. I like it. I strongly suspect
> >the "bright
> >beginners" Alex is interested in would have no troubl
On Jan 16, 2006, at 9:12 PM, Andrew Bennetts wrote:
> On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
> [...]
>> That suggests that it would be better to simply add an int method:
>>
>> x.convert_to_base(7)
>
> This seems clear and simple to me. I like it. I strongly sus
On Mon, Jan 16, 2006 at 11:54:05PM -0500, Raymond Hettinger wrote:
[...]
> That suggests that it would be better to simply add an int method:
>
> x.convert_to_base(7)
This seems clear and simple to me. I like it. I strongly suspect the "bright
beginners" Alex is interested in would have no
[Jeremy Hylton]
> The concept of base is closely related to ints, and the base argument
> is useful for a large percentage of the types that int accepts. It is
> not related to strings, in general, and applies to only one of the
> types it accepts. In one case "not a float, etc." applies to a ver
On Jan 16, 2006, at 8:18 PM, Barry Warsaw wrote:
> On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
>
>> My reaction having read this far was "huh?". It took some time
>> (several
>> seconds) before it occurred to me what you wanted str(5,2) to
>> mean, and why it
>> should give '10
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>
> On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
> > I think it shouldn't be changed, because the second positional
> > argument only works for a small number of the panoply types that can
> > be passed to str().
>
> Identically the same sit
On Jan 16, 2006, at 8:03 PM, Jeremy Hylton wrote:
> It never occured to me that str() would behave like int() for this
> case. It makes complete sense to me that a factory for numbers would
> ask about the base of the number. What would the base of a string be,
> except in a few limited cases?
On Tue, 2006-01-17 at 15:08 +1100, Andrew Bennetts wrote:
> My reaction having read this far was "huh?". It took some time (several
> seconds) before it occurred to me what you wanted str(5,2) to mean, and why it
> should give '101'.
>
> If you'd proposed, say (5).as_binary() == '101', or "5".en
On Mon, 16 Jan 2006 19:44:44 -0800, Alex Martelli <[EMAIL PROTECTED]> wrote:
>Is it finally time in Python 2.5 to allow the "obvious" use of, say,
>str(5,2) to give '101', just the converse of the way int('101',1)
>gives 5? I'm not sure why str has never allowed this obvious use --
>any bright beg
> I wish you had an argument better than "every bright beginner assumes
> it exists". :-)
>
> But (unlike for some other things that bright beginners might assume)
> I don't think there's a deep reason why this couldn't exist.
>
> The only reasons I can come up with is "because input and output a
On Mon, Jan 16, 2006 at 07:44:44PM -0800, Alex Martelli wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101',
My reaction having read this far was "huh?". It took some time (several
seconds) before it occurred to me what you wanted str(5,2) to m
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
[I'm sure you meant int('101', 2) here]
> gives 5? I'm not sure why str has never allowed this obvious use
It never occured to me that str() would behave like int() for this
case. It makes complete sense to me that a factory for numbers would
ask about the base of the number. What would the base of a string be,
except in a few limited cases? str([1, 2], 4) doesn't make any sense.
You might argue that
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',2)
> gives 5?
+1
The only downside is that like list.reverse(), it will deprive students
of being assigned to write the roll-your-own version.
Raymond
_
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Is it finally time in Python 2.5 to allow the "obvious" use of, say,
> str(5,2) to give '101', just the converse of the way int('101',1)
I think you mean ``int('101' 2)``. =)
> gives 5? I'm not sure why str has never allowed this obvious us
Is it finally time in Python 2.5 to allow the "obvious" use of, say,
str(5,2) to give '101', just the converse of the way int('101',1)
gives 5? I'm not sure why str has never allowed this obvious use --
any bright beginner assumes it's there and it's awkward to explain
why it's not!-). I'
97 matches
Mail list logo