RetroSearch Browse

Sat Nov 8 19:00:58 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040131.html

On Saturday 08 November 2003 21:51, Martin v. Löwis wrote:
   ...
> > Lists are mutable, which makes "creating bound methods" (or the
> > equivalent thereof) absolutely unavoidable -- e.g.:

[[ I meant -- but didn't say out loud!-) -- "without changing the current
   bytecode-level logic".  The change I proposed and experimented with
   for strings' is... methods is localized to stringobject.c and requires
   changing nothing except the details of string objects' implementation ]]

> >     xxx = somelist.somemethod
> >     " alter somelist at will "
> >     yyy = xxx( <args if needed> )
> >
> > xxx needs to be able to refer back to somelist at call time, clearly.
>
> It depends on the source code. In your example, I agree it is
> unavoidable. In the much more common case of
>
> yyy = somelist.somemethod(<args if needed>)
>
> one could call the code of somemethod without creating a bound method,
> and, in some cases, without creating the argument tuple. It would be

Yes, if different bytecode was generated, this would of course be possible.

> would not be called anymore. Perhaps that can be changed to
>
>   2           0 LOAD_FAST                0 (a)
>               3 LOAD_METHOD              1 (append)
>               6 LOAD_CONST               1 (1)
>               9 CALL_METHOD              1
>              12 POP_TOP
>              13 LOAD_CONST               0 (None)
>              16 RETURN_VALUE
>
> where LOAD_METHOD has the option of returning an fast_method object
> (which exists only once per type type and method), and CALL_METHOD
> would check for whether there is a fast_method object on stack, and
> then explicitly pop "self" from the stack as well.

Yes, if LOAD_METHOD was also able to return a perfectly generic object
(just in case the attribute named 'append' was not in fact a method), and
CALL_METHOD could fallback to today's CALL_FUNCTION's functionallty.

I'm not sure what's supposed to happen to 'self' if LOAD_METHOD cannot
push a fastmethod object but needs to push something else instead -- would
the something else (anything but a fastmethod) also consume the 'self' then
(whether to ignore it or merge it into a boundmethod)?  It does look like 
this could work, and on a wide range of typical method-call uses.

> > Few situations are as favourable as this one -- immutable object, no
> > arguments, just two possible constant-returning callables needed.
>
> Most cases are as favourable as this one. If you immediately call the

Yes, for the kind of bytecode-level change you're proposing, I do believe
most method-calls do follow this pattern.

> bound method, and then discard the bound-method-object, there is no
> point in creating it first. The exception is the getattr-style
> computation of callables, where getattr cannot know that the result is
> going to be called right away.

...or, no doubt, other special descriptors with getters playing dirty 
tricks.  But I do agree that these are still likely to be a tiny fraction
of use cases.

My proposal was very narrow and safe -- yours is very broad, but
by that very characteristic I think it _may_ make a difference to a
certain pie-throwing-related bet, which my no doubt wouldn't be the
case for mine.  So, Guido may well be more interested in your idea
than in mine, given he's the one directly involved in the pie issues...

Alex

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040131.html below:

[Python-Dev] other "magic strings" issues