Raymond Hettinger wrote:
> Are you sure? The former has two builtin lookups (which also entail two
> failed global lookups), a function call, and a test/jump for the result.
> The latter approach has no lookups (just a load constant), a try-block
> setup, an add operation (optimized for integers,
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)
Alex Martelli wrote:
>> As I suggested in a different message: Why are you doing that
>> in the first place?
>
>
> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".
Nit: I think you should not test. Instead, you should starting you mean
to do if the tes
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
[Me]
> Even if there were a performance edge, I suppose that the type
checking
> is the time critical part of most scripts.
That should be: RARELY the time critical part of most scripts.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
> 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
> Because isinstance is faster and handier than testing with try/except
> around (say) "x+0".
Are you sure? The former has two builtin lookups (which also entail two
failed global lookups), a function call, and a test/jump for the result.
The latter approach has no lookups (just a load constant),
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'
On 1/16/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Nothing was said about "different design intent for basestring", as I
> recall (that discussion comes up among the few hits for [basestring
> site:python.org] if you want to check the details).
Please. How many times do I have to say this. *I
On Jan 16, 2006, at 2:01 PM, Martin v. Löwis wrote:
> Alex Martelli wrote:
>> I can't find a PEP describing this restriction of basestring, and I
>> don't see why a coder who needs to implement another kind of
>> character string shouldn't subclass basestring, so that those
>> instances pass an i
On Mon, Jan 16, 2006, Jim Fulton wrote:
>
> In general though, for adults, truthfulness and non-anonymity *do*
> matter. At least they matter to me, a *lot*. I don't think members
> of the PSF should be allowed to hide their identity and certainly, it
> should not be acceptable to contribute to P
[Jim Fulton]
> certainly, it should not be acceptable to contribute to Python
> under a false name.
What do you mean "contribute to Python"? Do you mean become one of
the developers listed on sourceforge? Contribute any patches, even
simple documentation ones? Review, comment and test pat
Jim Fulton wrote:
> In general though, for adults, truthfulness and non-anonymity *do*
> matter. At least they matter to me, a *lot*. I don't think members
> of the PSF should be allowed to hide their identity and certainly,
> it should not be acceptable to contribute to Python under a false name
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, so I tuned out of the rest of the
> discussion. So for t
Alex Martelli wrote:
> I can't find a PEP describing this restriction of basestring, and I
> don't see why a coder who needs to implement another kind of
> character string shouldn't subclass basestring, so that those
> instances pass an isinstance test on basestring which is quite likely
>
Guido van Rossum wrote:
[...]
>
> I think that's unnecessary, and not any more effective than what we
> already do -- ask for a signed contributor form. Someone who signs
> that form "Tim Peters" won't be stopped by a clause asking them to use
> their real name, *really*.
>
Sorry. My previous mes
Alex Martelli wrote:
> > As you already suspected, I think a PEP is needed. The intent of
>
> I'll be happy to write it, if it stands any chance.
>
> > basestring was to *only* be used as the base class for *built-in*
> > string types. Clearly what you're proposing is different (Decimal is
> > not
On Jan 16, 2006, at 7:53 AM, Guido van Rossum wrote:
> On 1/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
>> Now, today, I have _again_ been bit by the lack of basenumber (by a
>> bug of mine, fixed by adding decimal.Decimal to a long tuple of
>> classes to be passed to an isinstance call -- I
Gabriel Becedillas wrote:
> Michael Hudson wrote:
>> Gabriel Becedillas <[EMAIL PROTECTED]> writes:
>>
>>
>>> Hi,
>>> At the company I work for, we've embedded Python in C++ application
>>> we develop. Since our upgrade to Python 2.4.2 from 2.4.1 we started
>>> hitting Py_FatalError("Invalid thre
[vinay]
>> Log:
>> Fixed bug in time-to-midnight calculation.
[Skip]
> Is there some reason not to use datetime to do this?
PEP 291 says logging intends to be compatible with Python 1.5.2, which
leaves datetime out.
Vinay, rather than:
if (currentMinute == 0) and (currentSecond == 0):
On 1/15/06, Alex Martelli <[EMAIL PROTECTED]> wrote:
> Now, today, I have _again_ been bit by the lack of basenumber (by a
> bug of mine, fixed by adding decimal.Decimal to a long tuple of
> classes to be passed to an isinstance call -- I hadn't run that
> particular numeric code of mine since the
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, so I tuned out of the rest of the
discussion. So for the record, I'm fine with that.
--
--Gui
On 1/16/06, Steve Holden <[EMAIL PROTECTED]> wrote:
> Jim Fulton wrote:
> > In general though, for adults, truthfulness and non-anonymity *do*
> > matter. At least they matter to me, a *lot*. I don't think members
> > of the PSF should be allowed to hide their identity and certainly,
> > it shoul
On Mon, Jan 16, 2006 at 01:37:18PM +0900, Seo Sanghyeon wrote:
> But hashlib.new() takes the algorithm name... Does PEP need an update?
The new() function in hashlib's interface doesn't conform to PEP 247;
that's all. I don't think the PEP needs to be updated.
--amk
_
Connelly Barnes wrote:
> Hi,
>
> Perhaps I am the only one bothered by the timeit
> module, but it seems poorly designed to me.
>
> First of all, it should use a geometric series with a
> timeout value to detect how many iterations it should
> perform. Currently, the user is required to manually
Jim Fulton wrote:
> Tim Peters wrote:
>
>>[Georg Brandl -- or so he claimed on January 8]
>>
>>
>>>today, when two Python developers here had approached me about the PSF, I
>>>realized that it is time to correct a mistake which I had made over three
>>>years
>>>ago, when I discovered Linux, free
Martin v. Löwis wrote:
> Christian Tismer wrote:
>> 1. create a file
>> 2. get it's os.path.getmtime()
>> 3. change your time zone
>> 4. get os.path.getmtime again
>>
>> compare - the time stamps are different.
>> Change the time zone back, and they are identical, again.
>
> Just to add an importa
Hi,
Perhaps I am the only one bothered by the timeit
module, but it seems poorly designed to me.
First of all, it should use a geometric series with a
timeout value to detect how many iterations it should
perform. Currently, the user is required to manually
specify the number of iterations (the
> Thomas Heller <[EMAIL PROTECTED]> writes:
> It looks like we need a pronouncement now.
+1
I am a lurker in this list. I maintain ctypes for Debian and I would love to
see it in core python. Debian now includes ctypes for 10 Linux architectures
and kFreeBSD. The only missing significant arc
Tim Peters wrote:
> [Georg Brandl -- or so he claimed on January 8]
>
>>today, when two Python developers here had approached me about the PSF, I
>>realized that it is time to correct a mistake which I had made over three
>>years
>>ago, when I discovered Linux, free software, Usenet etc (I was si
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>> On the other hand it breaks one of the most fundamental Python
>> guidelines: if you get a core dump (segfault etc.) it's a bug in
>> Python or in a 3rd party extension, not in *your* Python code. An
>> exception would have
On Monday 16 January 2006 20:05, Nick Coghlan wrote:
> For example, what's wrong with "hasattr(x, __int__)"? That works
> for all the builtin types, and, IMO, anyone defining a direct
> conversion to an integer for a non-numeric type deserves whatever
> happens to them.
What about something that's
Alex Martelli wrote:
> I'll be happy to draft a PEP if needed (and just as happy to
> eventually provide an implementation patch if the PEP's accepted),
> but wanted to doublecheck on the general issue first!
I haven't really followed the earlier basenumber discussions (aside from the
sidetra
48 matches
Mail list logo
