Guido van Rossum wrote:
>> Would a possible special method name __methodcall__ be accepted, where
>> if it exists on a callable, you can expect to use it as __call__ but
>> with the understanding that it accepts as self when called in
>> an optimizable form? This would reduce the method call to tw
On 8/15/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
> On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Right. I'm against anything that changes the current semantics. I'm
> > all for a compiler optimization that turns " . (
> > )" into a single opcode that somehow manages to avoid c
On 8/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Talin wrote:
> > > the compiler would note the combination of the attribute access and the
> > > call, and combine them into an opcode that skips the whole method
> > > creation step.
> >
On 8/13/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Talin wrote:
> > the compiler would note the combination of the attribute access and the
> > call, and combine them into an opcode that skips the whole method
> > creation step.
>
> Something like that could probably be made to work. You'd
> want
Talin wrote:
> the compiler would note the combination of the attribute access and the
> call, and combine them into an opcode that skips the whole method
> creation step.
Something like that could probably be made to work. You'd
want to be careful to do the optimisation only when the
attribute
Talin wrote:
> Anyway, I just wanted to throw that out there. Feel free to -1 away... :)
Based on the later discussion, I see two interesting possibilities:
1. A special CALL_METHOD opcode that the compiler emits when it spots the
".NAME(ARGS)" pattern. This could simply be an optimisation perfo
[Josiah]
> I'm -1 for instantiating all methods (for the infinite cost reasons),
> and -1 for int, long, list, tuple, dict, float (method access is
> generally limited for these objects). I'm +0 for offering a suitable
> metaclass and/or decorator, but believe it would be better suited for
> the P
> However, I also realize that requiring every access to a class variable
> to instantiate a new method object is expensive, to say the least.
Why does every access to a class variable have to instantiate a new method
object?
___
Python-3000 mailing li
On 8/13/06, Talin <[EMAIL PROTECTED]> wrote:
HI wonder if it could be me made to work in abackwards-compatible way. In other words, suppose the existing logic ofcreating a method object were left in place, however the'obj.instancemethod()' pattern would bypass all of that. In other words,
t
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>> One of the items in PEP 3100 is getting rid of unbound methods. I want
>> to explore a heretical notion, which is getting rid of bound methods as
>> well.
>>
>> Now, to be honest, I rather like bound methods. I like being able to
>> cap
Talin <[EMAIL PROTECTED]> wrote:
>
> One of the items in PEP 3100 is getting rid of unbound methods. I want
> to explore a heretical notion, which is getting rid of bound methods as
> well.
>
> Now, to be honest, I rather like bound methods. I like being able to
> capture a method call, store
On 8/13/06, Talin <[EMAIL PROTECTED]> wrote:
> One of the items in PEP 3100 is getting rid of unbound methods. I want
> to explore a heretical notion, which is getting rid of bound methods as
> well.
I believe you're suggesting that the code that I just wrote moments
ago would stop working::
One of the items in PEP 3100 is getting rid of unbound methods. I want
to explore a heretical notion, which is getting rid of bound methods as
well.
Now, to be honest, I rather like bound methods. I like being able to
capture a method call, store it in a variable, and call it later.
However, I
13 matches
Mail list logo
