On 2005 Feb 21, at 04:42, Guido van Rossum wrote:
Oh, bah. That's not what basestring was for. I can't blame you or
your
client, but my *intention* was that basestring would *only* be the
base of the two *real* built-in string types (str and unicode).
I think all this just reinforces the notion th
> >>Eliminating the blockstack would be nice (esp. if it's enough to get
> >>frames small enough that they get allocated by PyMalloc) but this
> >>seemed to be tricky too (or at least Armin, Samuele and I spent a
> >>cuple of hours yakking about it on IRC and didn't come up with a clear
> >>approac
> >> Oh, bah. That's not what basestring was for. I can't blame you or your
> >> client, but my *intention* was that basestring would *only* be the
> >> base of the two *real* built-in string types (str and unicode).
>
> I think all this just reinforces the notion that LBYL is
> a bad idea!
In th
At 04:32 PM 2/21/05 +1300, Greg Ewing wrote:
Alex Martelli wrote:
The need to check "is this thingy here string-like" is sort of frequent,
because strings are sequences which, when iterated on, yield sequences
(strings of length 1) which, when iterated on, yield sequences ad infinitum.
Yes, this
At 04:32 PM 2/21/05 +1300, Greg Ewing wrote:
Phillip J. Eby wrote:
Hm, actually I think I see the answer; in the case of module-level code
there can be no "anonymous local variables" the way there can in functions.
Why not? There's still a frame object associated with the call
of the anonymous fun
Alex Martelli wrote:
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
Oh, bah. That's not what basestring was for. I can't blame you or your
client, but my *intention* was that basestring would *only* be the
base of the two *real* built-in string types (str and unicode).
I think all this just rein
Phillip J. Eby wrote:
Hm, actually I think I see the answer; in the case of module-level code
there can be no "anonymous local variables" the way there can in
functions.
Why not? There's still a frame object associated with the call
of the anonymous function holding the module's top-level code.
T
Phillip J. Eby wrote:
At 03:56 PM 2/20/05 -0500, Phillip J. Eby wrote:
At 07:00 PM 2/20/05 +, Michael Hudson wrote:
Eliminating the blockstack would be nice (esp. if it's enough to get
frames small enough that they get allocated by PyMalloc)
Someone might like to take a look at the way Pyrex
ge
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 07:00 PM 2/20/05 +, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>> >>Where are the attempts to speed up function/method calls? That's an
>> >>area where we coul
At 03:56 PM 2/20/05 -0500, Phillip J. Eby wrote:
At 07:00 PM 2/20/05 +, Michael Hudson wrote:
Eliminating the blockstack would be nice (esp. if it's enough to get
frames small enough that they get allocated by PyMalloc) but this
seemed to be tricky too (or at least Armin, Samuele and I spent a
At 07:00 PM 2/20/05 +, Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>>Where are the attempts to speed up function/method calls? That's an
>>area where we could *really* use a breakthrough...
>
> Amen!
>
> So what happene
At 06:38 PM 2/20/05 +, Michael Hudson wrote:
>> It folds the two steps into a new opcode. In the case of
>> store_name/load_name, it saves one three byte instruction, a trip around
>> the eval-loop, two stack mutations, a incref/decref pair, a dictionary
>> lookup, and an error check (for the
Michael Hudson wrote:
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
[SNIP]
And whatever happened to CALL_METHOD?
It didn't work as an optimization, as far as I remember. I think the
patch is on SF somewhere. Or is a branch in CVS? Oh, it's patch
#709744.
Do we need a tp_callmethod that takes an
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
>>Where are the attempts to speed up function/method calls? That's an
>>area where we could *really* use a breakthrough...
>
> Amen!
>
> So what happened to Armin's pre-allocated frame patch? Did tha
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> Any objections to new peephole transformation that merges a store/load
>> pair into a single step?
>>
>> There is a tested patch at: www.python.org/sf/1144842
>>
>> It folds the two steps into a new opcode. In the case of
>> store_name/load_name,
Guido van Rossum wrote:
I'm concerned that there's too much hacking of the VM going on with
too little benefit.
I completely agree. It would be so much more useful if people tried
to fix the bugs that have been reported.
Regards,
Martin
___
Python-Dev mai
At 09:15 AM 2/20/05 +0100, Alex Martelli wrote:
This is because types.ClassType turns somersaults to enable this: in this
latter construct, Python's mechanisms determine ClassType as the metaclass
(it's the metaclass of the first base class), but then ClassType in turn
sniffs around for another
At 08:17 AM 2/20/05 -0800, Guido van Rossum wrote:
Where are the attempts to speed up function/method calls? That's an
area where we could *really* use a breakthrough...
Amen!
So what happened to Armin's pre-allocated frame patch? Did that get into 2.4?
Also, does anybody know where all the time g
On 2005 Feb 20, at 17:06, Guido van Rossum wrote:
[Alex]
I did have some issues w/UserString at a client's, but that was
connected to some code doing type-checking (and was fixed by injecting
basestring as a base of the client's subclass of UserString and
ensuring the type-checking always used isin
> Any objections to new peephole transformation that merges a store/load
> pair into a single step?
>
> There is a tested patch at: www.python.org/sf/1144842
>
> It folds the two steps into a new opcode. In the case of
> store_name/load_name, it saves one three byte instruction, a trip around
>
[Alex]
> I did have some issues w/UserString at a client's, but that was
> connected to some code doing type-checking (and was fixed by injecting
> basestring as a base of the client's subclass of UserString and
> ensuring the type-checking always used isinstance and basestring).
Oh, bah. That's n
Any objections to new peephole transformation that merges a store/load
pair into a single step?
There is a tested patch at: www.python.org/sf/1144842
It folds the two steps into a new opcode. In the case of
store_name/load_name, it saves one three byte instruction, a trip around
the eval-loop,
Martin v. Löwis wrote:
>> I'd say that this explains why it would still make sense to let the code
>> generator change
>> "x in (a, b, c)" to "x == a or x == b or x == c", as long as a, b, and c are
>> all integers.
>
> How often does that happen in real code?
don't know, but it happens:
[EMAI
Alex Martelli <[EMAIL PROTECTED]> writes:
> On 2005 Feb 20, at 04:35, Jack Diederich wrote:
>
>> I didn't dig into the C but does having 'type'
>> as metaclass guarantee the same behavior as inheriting 'object' or
>> does object
>> provide something type doesn't? *wince*
>
> I believe the forme
On 2005 Feb 20, at 05:20, Raymond Hettinger wrote:
...
This sort of thing is easy to test for and easy to fix. The question
is
whether we care about updating this module anymore or is it a relic.
Also, is the use case one that we care about. AFAICT, this has never
come up before.
I did have s
On 2005 Feb 20, at 04:35, Jack Diederich wrote:
I always use new style classes so I only have to remember one set of
behaviors.
I agree: that's reason #1 I recommend always using new-style whenever I
teach / tutor / mentor in Python nowadays.
"__metaclass__ = type" is warty, it has the "action a
26 matches
Mail list logo
