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 Systems
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 common,
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, I
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 back
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
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.
The
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
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 about
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
well be considered a
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 other direction.
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 considered a conversion in
[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 issue.
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 'cleanliness'
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(). Unix
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 only opposition to this is that the byte
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 the way they do if
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
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 difference
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 removing
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
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
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 hex
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 function to
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.
Perhaps introduce
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 justify
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
there.
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. I sure don't
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 about removing
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
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() and
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 Nick.
+1 for
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
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
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
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 me. I like it. I
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.convert_to_base(7)
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 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
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
--
exarkun INEFFICIENT
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
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 disappointing
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
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 ints
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 shortcoming
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 if the
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).
Skip
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')
I don't
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 there and
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]
Yep.
gives
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 they
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
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
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 proposed?
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 a python
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 is fully defined,
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 released
in a
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 out that this
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 wait until byte is
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 were
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 the byte type may want to
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 opposition to this is that
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] 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 between hex() and oct() and the proposed binary() is
I'd propose bin() to
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 between hex()
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(5,
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
Jack Diederich [EMAIL PROTECTED] writes:
However... if %b were to represent arbitrary bases, I think that's
backwards. It should be %[pad][.base]b, which would do this:
'%08b %08o %08d %08x' % 12
'1100 0014 0012 000C'
Were I BDFAD (not to be confused
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!-).
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 use --
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
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
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 --
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 mean,
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 are
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 beginner
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
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 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 situation as
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 '101'.
If
[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 very
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
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 suspect
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 trouble using it or
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 is
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]
gives 5?
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)
This seems
86 matches
Mail list logo
