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
> "Anthony" == Anthony Baxter <[EMAIL PROTECTED]> writes:
Anthony> It sounds like configure needs to grow a test to detect
Anthony> that a "libreadline" it finds is actually the crackful
Anthony> "libedit" and refuse to use it if so.
FYI: Real libreadline is GPL, and rms made a po
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()
I have been experimenting with replacing the big switch in ceval.c by
a computed goto construct [1]. It uses #define's to make it optional.
This work was inspired by Mono's MINT interpreter code,
and Neil Norwitz's attempt to use a function pointer table [2].
Result: about 1% slower on the pysto
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 4:17 PM, Anthony Baxter wrote:
> On Wednesday 18 January 2006 06:19, Barry Warsaw wrote:
>> On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
>>> Building the readline on OS X 10.4 fails, is this known, or am I
>>> doing something wrong?
>>
>> There are definitely seriou
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 Wednesday 18 January 2006 06:19, Barry Warsaw wrote:
> On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
> > Building the readline on OS X 10.4 fails, is this known, or am I
> > doing something wrong?
>
> There are definitely serious issues with readline on OS X 10.4.
> I've hit them too
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 1/17/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Being able to change imaplib to use basenumber instead of (int, float)
> won't make it SIMPLER, but it will surely make it BETTER -- why should
> a long be rejected, or a Decimal,
> for that matter?
Because there's no guarantee that they'll pr
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
Alex Martelli wrote:
> But this doesn't apply to the Python Standard Library, for example see
> line 1348 of imaplib.py: "if isinstance(date_time, (int, float)):".
[...]
> Being able to change imaplib to use basenumber instead of (int, float)
> won't make it SIMPLER, but it will surely make it BETT
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/17/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Alex, I think you're missing a point here: what you are looking
> for is an interface, not a base class - simply because the
I expect numbers to support arithmetic operators, &c -- no need for
basenumber to "spell this out", i.e., "be an itner
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
On 1/17/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
> > Building the readline on OS X 10.4 fails, is this known, or am I doing
> > something wrong?
>
> There are definitely serious issues with readline on OS X 10.4. I've
> hit them too but
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>> On 1/16/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
>>
>>>It looks like we need a pronouncement now.
>>
>>
>> Sorry. It appeared to me that there was general agreement to using a
>> strongly worded warning in the docs,
On Tue, 2006-01-17 at 19:17 +0100, Thomas Heller wrote:
> Building the readline on OS X 10.4 fails, is this known, or am I doing
> something wrong?
There are definitely serious issues with readline on OS X 10.4. I've
hit them too but haven't had time to post about it yet. I'm far from an
expert
On Jan 17, 2006, at 10:17 AM, Thomas Heller wrote:
> Building the readline on OS X 10.4 fails, is this known, or am I doing
> something wrong?
Mac OS X doesn't ship with readline. It ships with BSD libedit
symlinked to readline. Not good enough for Python. You need a third
party copy.
I
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
Georg> Interesting, didn't even know a new page was in the making... Do
Georg> you know who is responsible for the new page?
Tim Parkin is heading things up. Look here:
http://beta.python.org/
Skip
___
Python-Dev mailing list
Python-Dev@
[EMAIL PROTECTED] wrote:
> >> does Python have an official icon?
>
> Ping> i found some images at http://www.pythonology.com/logos...
>
> It appears the yin/yang Python's on that page are being used in the new site
> (beta.python.org). I don't know if that makes it official or not though
Building the readline on OS X 10.4 fails, is this known, or am I doing
something wrong?
Thanks,
Thomas
building 'readline' extension
gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd
-DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I/Users/theller/svn/trunk/./Include -I/U
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'
On 1/17/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/17/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > Guido wrote:
> >
> > > more important to implement __index__() in Python 2.5.
> > > This behaves like __int__() for integral types, but is not
> > > defined for float or Decimal.
> >
> >
[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 1/17/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Guido wrote:
>
> > more important to implement __index__() in Python 2.5.
> > This behaves like __int__() for integral types, but is not
> > defined for float or Decimal.
>
> Why not for Decimal, or even float? I would not be surprised
> if 10.79
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
Guido wrote:
> more important to implement __index__() in Python 2.5.
> This behaves like __int__() for integral types, but is not
> defined for float or Decimal.
Why not for Decimal, or even float? I would not be surprised
if 10.798 failed, but I would expect 1000D to work.
If indexing worked
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
On 1/17/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[snip]
> I don't see a way around creating an integer recognition tool that
> doesn't conflate its terminology with broadly-held, pre-existing math
> knowledge: complex is a superset of reals, reals include rationals and
> irrationals some of
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
Hi Brett, hi all,
On Sat, Jan 14, 2006 at 05:51:25PM -0800, Brett Cannon wrote:
> That would be cool! I definitely would not mind working on PyPy.
> Unfortunately I would not consider changing universities; I really
> like it here.
We are looking at the possibility to do a "Summer of PyPy" in t
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.
Alex, I think you're missing a point here: what you are looking
for is an interface, not a base class - simply because the
assumptions you make when finding a "KnownNumberTypes" instance
are only related to an interface you expect them to provide.
A common case class won't really help all that muc
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
60 matches
Mail list logo
