General discussion about the Cython source code generator for Python extensions

Stefan Behnel | 6 Jan 2010 18:37

[Cython] Make 'inline' methods in cdef-class non-overridable?

Hi,

I think it would be nice to support 'cdef inline' methods in extension 
types and let Cython call them without the normal method indirection, e.g.

cdef class MyType:
     cdef list large_list
     cdef size_t y

     cdef big_method(self):
         for x in self.large_list:
             self.small_method(x)

     cdef inline small_method(self, x):
         self.y += x

would emit a direct call to the ..._small_method(self, x) C function in 
big_method(), instead of passing through self->__pyx_vtab->small_method.

This would require these methods to be non-overridable, which I think makes 
sense for something declared 'inline'.

Thoughts?

Stefan

headers

Dag Sverre Seljebotn | 6 Jan 2010 20:18

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

Stefan Behnel wrote:
> Hi,
> 
> I think it would be nice to support 'cdef inline' methods in extension 
> types and let Cython call them without the normal method indirection, e.g.
> 
> cdef class MyType:
>      cdef list large_list
>      cdef size_t y
> 
>      cdef big_method(self):
>          for x in self.large_list:
>              self.small_method(x)
> 
>      cdef inline small_method(self, x):
>          self.y += x
> 
> would emit a direct call to the ..._small_method(self, x) C function in 
> big_method(), instead of passing through self->__pyx_vtab->small_method.
> 
> This would require these methods to be non-overridable, which I think makes 
> sense for something declared 'inline'.
> 
> Thoughts?

I remember wanting this feature when I first saw Cython (then never got 
around to it). So very much +1 on the feature, not sure about syntax.

Java already has the concept of non-polymorphic dispatches through the 
"final" keyword. So what I was thinking was a new keyword would be used,

(Continue reading)

headers

Stefan Behnel | 7 Jan 2010 09:19

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Dag Sverre Seljebotn, 06.01.2010 20:18:
> there is probably not a use for inline non-final methods as they 
> can't be inlined anyway, and I suppose the times one want a non-inline 
> final method are very scarce

That was my intuition, too. I doubt that this feature is any interesting 
beyond inlining. If the non-overridable function is large enough to 
prohibit inlining, it's likely not worth speeding up the call anyway.

Also, even if the C compiler sees the 'inline' keyword, it's free to ignore 
it if it considers the function too large to have any positive impact.

Stefan

headers

Robert Bradshaw | 7 Jan 2010 09:54

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 6, 2010, at 11:18 AM, Dag Sverre Seljebotn wrote:

> Stefan Behnel wrote:
>> Hi,
>>
>> I think it would be nice to support 'cdef inline' methods in  
>> extension
>> types and let Cython call them without the normal method  
>> indirection, e.g.
>>
>> cdef class MyType:
>>     cdef list large_list
>>     cdef size_t y
>>
>>     cdef big_method(self):
>>         for x in self.large_list:
>>             self.small_method(x)
>>
>>     cdef inline small_method(self, x):
>>         self.y += x
>>
>> would emit a direct call to the ..._small_method(self, x) C  
>> function in
>> big_method(), instead of passing through self->__pyx_vtab- 
>> >small_method.
>>
>> This would require these methods to be non-overridable, which I  
>> think makes
>> sense for something declared 'inline'.
>>

(Continue reading)

headers

Stefan Behnel | 7 Jan 2010 14:08

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Robert Bradshaw, 07.01.2010 09:54:
> On Jan 6, 2010, at 11:18 AM, Dag Sverre Seljebotn wrote:
>> Stefan Behnel wrote:
>>> I think it would be nice to support 'cdef inline' methods in  
>>> extension types and let Cython call them without the normal method
>>> indirection, e.g.
>>>
>>> cdef class MyType:
>>>     cdef list large_list
>>>     cdef size_t y
>>>
>>>     cdef big_method(self):
>>>         for x in self.large_list:
>>>             self.small_method(x)
>>>
>>>     cdef inline small_method(self, x):
>>>         self.y += x
>>>
>>> would emit a direct call to the ..._small_method(self, x) C function
>>> in big_method(), instead of passing through self->__pyx_vtab->small_method.
>>> This would require these methods to be non-overridable, which I  
>>> think makes sense for something declared 'inline'.
>>>
>> I remember wanting this feature when I first saw Cython (then never  
>> got around to it). So very much +1 on the feature, not sure about syntax.
> 
> This has been floating around in the back of my head as well, so +1.

http://trac.cython.org/cython_trac/ticket/474

(Continue reading)

headers

Neil Ludban | 7 Jan 2010 15:05

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

>> Stefan Behnel wrote:
...
> 
>>>    cdef inline small_method(self, x):
>>>        self.y += x
>>> 
>>> would emit a direct call to the ..._small_method(self, x) C  
>>> function in
>>> big_method(), instead of passing through self->__pyx_vtab- 
>>>> small_method.
>>> 
>>> This would require these methods to be non-overridable, which I  
>>> think makes
>>> sense for something declared 'inline'.
>>> 
>>> Thoughts?

This obscures the intent of the code by abusing a C keyword, just
borrow the Java keyword that already has the associated semantics:

cdef final small_method(self, x):
   ...

Add an implicit inline in the C code declaration and emit the direct
calls, and it does exactly what new cython users (like me) expect.

headers

Sturla Molden | 7 Jan 2010 15:45

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


> This obscures the intent of the code by abusing a C keyword, just
> borrow the Java keyword that already has the associated semantics:
>
> cdef final small_method(self, x):

I think a decorator would be better than a keyword:

 <at> cython.nonvirtual
cdef void small_method(self, x):
    pass

In a perfect world, Cython should just look like a Python library.

Also I agree that the C/C++ semantics of inline should be kept. Or
preferably, inline should just be a decorator as well.

 <at> cython.nonvirtual
 <at> cython.inline
cdef void small_method(self, x):
    pass

S.M.

headers

Stefan Behnel | 7 Jan 2010 15:50

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Sturla Molden, 07.01.2010 15:45:
>> This obscures the intent of the code by abusing a C keyword, just
>> borrow the Java keyword that already has the associated semantics:
>>
>> cdef final small_method(self, x):
> 
> I think a decorator would be better than a keyword:
> 
>  <at> cython.nonvirtual
> cdef void small_method(self, x):
>     pass
> 
> In a perfect world, Cython should just look like a Python library.
> 
> Also I agree that the C/C++ semantics of inline should be kept. Or
> preferably, inline should just be a decorator as well.
> 
>  <at> cython.nonvirtual
>  <at> cython.inline
> cdef void small_method(self, x):
>     pass

But wouldn't ' <at> cython.inline' still imply ' <at> cython.nonvirtual' here?

The question is: what use case is there where you would want one without 
the other?

Stefan

(Continue reading)

headers

Sturla Molden | 7 Jan 2010 16:10

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


> The question is: what use case is there where you would want one without
> the other?

In C++ there is actually something called "inline virtual" methods. It
means that it can be inlined if the compiler can infer the type of the
class. This can e.g. happen if the compiler sees an object (global or on
the stack) rather than a pointer.

Sturla

headers

Neil Ludban | 7 Jan 2010 17:37

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 7, 2010, at 9:50 AM, Stefan Behnel wrote:
> 
>>  <at> cython.nonvirtual
>>  <at> cython.inline
>> cdef void small_method(self, x):
>>    pass
> 
> But wouldn't ' <at> cython.inline' still imply ' <at> cython.nonvirtual' here?
> 
> The question is: what use case is there where you would want one without 
> the other?
> 
> Stefan

First use case: a super-optimizing cython would look for methods
that make many calls to inline non-final methods and generate two
code paths depending on whether self is exactly this class.  Of
course, inline would also be automatically detected.

Second use case: other languages use "final" as a software design
technique (not an optimization), but that would be adding a new
feature to Python, probably not the intended goal.

Using "final" still seems much less evil than surprising end users
with unexpected (vs C/C++ and Python) semantics for "inline".

headers

Neil Ludban | 7 Jan 2010 17:40

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

Forgot to ask, what if I wanted to add final/inline/whatever to the
entire class?

On Jan 7, 2010, at 11:37 AM, Neil Ludban wrote:
> On Jan 7, 2010, at 9:50 AM, Stefan Behnel wrote:
>> 
>>>  <at> cython.nonvirtual
>>>  <at> cython.inline
>>> cdef void small_method(self, x):
>>>   pass
>> 
>> But wouldn't ' <at> cython.inline' still imply ' <at> cython.nonvirtual' here?
>> 
>> The question is: what use case is there where you would want one without 
>> the other?
>> 
>> Stefan
> 
> First use case: a super-optimizing cython would look for methods
> that make many calls to inline non-final methods and generate two
> code paths depending on whether self is exactly this class.  Of
> course, inline would also be automatically detected.
> 
> Second use case: other languages use "final" as a software design
> technique (not an optimization), but that would be adding a new
> feature to Python, probably not the intended goal.
> 
> Using "final" still seems much less evil than surprising end users
> with unexpected (vs C/C++ and Python) semantics for "inline".

(Continue reading)

headers

Robert Bradshaw | 7 Jan 2010 21:08

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 7, 2010, at 8:40 AM, Neil Ludban wrote:

> Forgot to ask, what if I wanted to add final/inline/whatever to the
> entire class?

I don't think it's possible to prevent a class from being subclassed  
in Python-land. (Well, not without checking raising some kind of a  
runtime exception on instantiation or something like that...)

- Robert

headers

Neil Ludban | 7 Jan 2010 21:34

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 7, 2010, at 3:08 PM, Robert Bradshaw wrote:
> On Jan 7, 2010, at 8:40 AM, Neil Ludban wrote:
> 
>> Forgot to ask, what if I wanted to add final/inline/whatever to the
>> entire class?
> 
> I don't think it's possible to prevent a class from being subclassed  
> in Python-land. (Well, not without checking raising some kind of a  
> runtime exception on instantiation or something like that...)
> 
> - Robert

Classes defined in extensions must explicitly indicate that they
support subclassing from pure Python.  NoneType and bool are core
types that don't, there may be others.

The intended point was that the semantics of making a class "final"
are understood and would imply the requested optimizations, while
the "inline" keyword wouldn't fit at all in this context.

headers

Robert Bradshaw | 7 Jan 2010 22:06

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 7, 2010, at 12:34 PM, Neil Ludban wrote:

> On Jan 7, 2010, at 3:08 PM, Robert Bradshaw wrote:
>> On Jan 7, 2010, at 8:40 AM, Neil Ludban wrote:
>>
>>> Forgot to ask, what if I wanted to add final/inline/whatever to the
>>> entire class?
>>
>> I don't think it's possible to prevent a class from being subclassed
>> in Python-land. (Well, not without checking raising some kind of a
>> runtime exception on instantiation or something like that...)
>>
>> - Robert
>
> Classes defined in extensions must explicitly indicate that they
> support subclassing from pure Python.  NoneType and bool are core
> types that don't, there may be others.

Ah, I did not know that. That does make a final modifier more  
attractive. This is a larger change to the language than allowing  
inline methods (with an error if one attempts to override them).

> The intended point was that the semantics of making a class "final"
> are understood and would imply the requested optimizations, while
> the "inline" keyword wouldn't fit at all in this context.

I think it depends on the perspective you're coming from. Is the  
intent to have the method inlined, which implies final as a  
consequence, or is the intent to have the method final, with possible  
inlining as an optimization detail?

(Continue reading)

headers

Christopher Barker | 7 Jan 2010 22:52

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

Robert Bradshaw wrote:
> I think it depends on the perspective you're coming from. Is the  
> intent to have the method inlined, which implies final as a  
> consequence,

I think that that's the only good reason -- this is Python (with static 
optimization), after all.

or would "final" provide some optimization?

> A class  could be final

What is the benefit of that? Again, this is Python after all! (though I 
suppose the NoneType and bool examples prove the need)

-Chris

--

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker@...

headers

Stefan Behnel | 11 Jan 2010 10:00

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

Robert Bradshaw, 07.01.2010 22:06:
> On Jan 7, 2010, at 12:34 PM, Neil Ludban wrote:
>> Classes defined in extensions must explicitly indicate that they
>> support subclassing from pure Python.  NoneType and bool are core
>> types that don't, there may be others.
> 
> Ah, I did not know that. That does make a final modifier more  
> attractive. This is a larger change to the language than allowing  
> inline methods (with an error if one attempts to override them).

I'm +0 on 'final' classes. I don't see a major use case, although there may 
be. Some extension types are really just meant as containers for C types, 
and when they are created from module internal code only, there may not be 
much value in subtyping them (although lxml.etree makes a good counter 
example).

Anyway, if it's supported by CPython, it should be ok to support it in 
Cython, I guess, as long as users are aware that this really means that 
they put a serious restriction on the usage of their code, and that this 
should be used with caution.

I certainly have seen enough Java code where 'final' was getting in the way 
at some point (and wasn't easy to remove from externally maintained code), 
or where the keyword was used totally arbitrarily in places where the 
compiler can easily infer the semantics anyway, and where it just adds 
noise to the code. I always expect an important intention when I see this 
keyword in code, and when there isn't one, it tends to confuse me, because 
it doesn't give me the feeling that I have understood the code.

(Continue reading)

headers

Dag Sverre Seljebotn | 11 Jan 2010 12:37

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

Stefan Behnel wrote:
> Robert Bradshaw, 07.01.2010 22:06:
>> The inline keyword is nice because we already use it for functions  
>> (where the final keyword makes no sense). I think it's probably worth  
>> introducing both keywords, where inline would control emission of the  
>> C inline directive. (Of course for non-inline final methods, the C  
>> compiler could decide whether or not to actually inline.) A class  
>> could be final, with the same semantics as java. One question is would  
>> inline imply final, or require it?
> 
> It makes no sense without final, so it should imply it (and certainly not 
> require it).

Actually, in code like this

a = MyClass()
a.foo()

the compiler would be able (in theory) to infer the exact type of "a" 
and treat any method calls on it as final (skip vtable), and then 
whether INLINE is declared or not C-side is an orthogonal issue.

I.e. "cdef inline foo(self)" could mean "allow overriding the method, 
but make it inline in situations where the vtable can be skipped".

Not that I think there's a real use for this...

--

-- 
Dag Sverre

(Continue reading)

headers

Stefan Behnel | 11 Jan 2010 13:48

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Dag Sverre Seljebotn, 11.01.2010 12:37:
> Stefan Behnel wrote:
>> Robert Bradshaw, 07.01.2010 22:06:
>>> The inline keyword is nice because we already use it for functions  
>>> (where the final keyword makes no sense). I think it's probably worth  
>>> introducing both keywords, where inline would control emission of the  
>>> C inline directive. (Of course for non-inline final methods, the C  
>>> compiler could decide whether or not to actually inline.) A class  
>>> could be final, with the same semantics as java. One question is would  
>>> inline imply final, or require it?
>> It makes no sense without final, so it should imply it (and certainly not 
>> require it).
> 
> Actually, in code like this
> 
> a = MyClass()
> a.foo()
> 
> the compiler would be able (in theory) to infer the exact type of "a" 
> and treat any method calls on it as final (skip vtable)

I think that's a worthy optimisation anyway. It's mostly a generalisation 
of ticket #3.

http://trac.cython.org/cython_trac/ticket/3

And this is totally orthogonal to the whole final/inline discussion. It 
only relies on the "missing __new__ support" assumption that we already make.

(Continue reading)

headers

Robert Bradshaw | 11 Jan 2010 19:55

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 11, 2010, at 1:00 AM, Stefan Behnel wrote:

> Robert Bradshaw, 07.01.2010 22:06:
>> On Jan 7, 2010, at 12:34 PM, Neil Ludban wrote:
>>> Classes defined in extensions must explicitly indicate that they
>>> support subclassing from pure Python.  NoneType and bool are core
>>> types that don't, there may be others.
>>
>> Ah, I did not know that. That does make a final modifier more
>> attractive. This is a larger change to the language than allowing
>> inline methods (with an error if one attempts to override them).
>
> I'm +0 on 'final' classes. I don't see a major use case, although  
> there may
> be. Some extension types are really just meant as containers for C  
> types,
> and when they are created from module internal code only, there may  
> not be
> much value in subtyping them (although lxml.etree makes a good counter
> example).
>
> Anyway, if it's supported by CPython, it should be ok to support it in
> Cython, I guess, as long as users are aware that this really means  
> that
> they put a serious restriction on the usage of their code, and that  
> this
> should be used with caution.
>
> I certainly have seen enough Java code where 'final' was getting in  
> the way

(Continue reading)

headers

Sturla Molden | 12 Jan 2010 14:04

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

I'd like to make a different suggestion. What about a keyword to pass  
after cdef in the declaration of the object to indicate the vtab can  
be skipped? I e an assertion that the object will be of the declared  
type. This will maintain better compatibility with Python.

cdef Foo bar = Foo()
cdef inline Foo fastbar = bar

bar.method() # through vtab
fastbar.method() # direct call

SM

Den 11. jan. 2010 kl. 19.55 skrev Robert Bradshaw
<robertwb@... 
 >:

> On Jan 11, 2010, at 1:00 AM, Stefan Behnel wrote:
>
>> Robert Bradshaw, 07.01.2010 22:06:
>>> On Jan 7, 2010, at 12:34 PM, Neil Ludban wrote:
>>>> Classes defined in extensions must explicitly indicate that they
>>>> support subclassing from pure Python.  NoneType and bool are core
>>>> types that don't, there may be others.
>>>
>>> Ah, I did not know that. That does make a final modifier more
>>> attractive. This is a larger change to the language than allowing
>>> inline methods (with an error if one attempts to override them).
>>
>> I'm +0 on 'final' classes. I don't see a major use case, although

(Continue reading)

headers

Stefan Behnel | 12 Jan 2010 15:44

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Sturla Molden, 12.01.2010 14:04:
> I'd like to make a different suggestion. What about a keyword to pass  
> after cdef in the declaration of the object to indicate the vtab can  
> be skipped? I e an assertion that the object will be of the declared  
> type. This will maintain better compatibility with Python.
> 
> cdef Foo bar = Foo()
> cdef inline Foo fastbar = bar
> 
> bar.method() # through vtab
> fastbar.method() # direct call

Why would you want to control this from user code?

Stefan

headers

Neil Ludban | 12 Jan 2010 16:11

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 12, 2010, at 9:44 AM, Stefan Behnel wrote:
> 
> Sturla Molden, 12.01.2010 14:04:
>> I'd like to make a different suggestion. What about a keyword to pass  
>> after cdef in the declaration of the object to indicate the vtab can  
>> be skipped? I e an assertion that the object will be of the declared  
>> type. This will maintain better compatibility with Python.
>> 
>> cdef Foo bar = Foo()
>> cdef inline Foo fastbar = bar
>> 
>> bar.method() # through vtab
>> fastbar.method() # direct call
> 
> Why would you want to control this from user code?
> 
> Stefan

It's explicit and selectively breaks Python's semantics as needed
for optimization.  Much nicer than implicit and global breakage.

headers

Stefan Behnel | 12 Jan 2010 16:17

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Neil Ludban, 12.01.2010 16:11:
> On Jan 12, 2010, at 9:44 AM, Stefan Behnel wrote:
>> Sturla Molden, 12.01.2010 14:04:
>>> I'd like to make a different suggestion. What about a keyword to pass  
>>> after cdef in the declaration of the object to indicate the vtab can  
>>> be skipped? I e an assertion that the object will be of the declared  
>>> type. This will maintain better compatibility with Python.
>>>
>>> cdef Foo bar = Foo()
>>> cdef inline Foo fastbar = bar
>>>
>>> bar.method() # through vtab
>>> fastbar.method() # direct call
>> Why would you want to control this from user code?
> 
> It's explicit and selectively breaks Python's semantics as needed
> for optimization.  Much nicer than implicit and global breakage.

You assume that inlining would break things. It can't, given the current 
type instantiation semantics. That's why I don't see a reason to let users 
ask for inlining when the compiler can do it automatically without any user 
interaction.

Stefan

headers

Stefan Behnel | 12 Jan 2010 16:25

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Stefan Behnel, 12.01.2010 16:17:
> Neil Ludban, 12.01.2010 16:11:
>> On Jan 12, 2010, at 9:44 AM, Stefan Behnel wrote:
>>> Sturla Molden, 12.01.2010 14:04:
>>>> I'd like to make a different suggestion. What about a keyword to pass  
>>>> after cdef in the declaration of the object to indicate the vtab can  
>>>> be skipped? I e an assertion that the object will be of the declared  
>>>> type. This will maintain better compatibility with Python.
>>>>
>>>> cdef Foo bar = Foo()
>>>> cdef inline Foo fastbar = bar
>>>>
>>>> bar.method() # through vtab
>>>> fastbar.method() # direct call
>>> Why would you want to control this from user code?
>> It's explicit and selectively breaks Python's semantics as needed
>> for optimization.  Much nicer than implicit and global breakage.
> 
> You assume that inlining would break things. It can't, given the current 
> type instantiation semantics.

Sorry, ignore what I just said. It can, just not in the above example. The 
case we are talking about here is this:

     cdef MyType x = something_that_returns_some_object()
     cdef inline MyType fast_x = x

in which case 'x' may refer to any subtype of MyType, which can obviously 
override the methods in MyType.

(Continue reading)

headers

Sturla Molden | 13 Jan 2010 11:29

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Den 12. jan. 2010 kl. 15.44 skrev Stefan Behnel <stefan_ml@...>:

>
>> cdef Foo bar = Foo()
>> cdef inline Foo fastbar = bar
>>
>> bar.method() # through vtab
>> fastbar.method() # direct call
>
> Why would you want to control this from user code?
>

Because I feel the common usecase for skipping the vtab indirection is  
calling a method repeatedly from user code.

This will not break Python semantics globally, but be a local  
optimization when the user knows the type of an object. Yes, we can  
already do this by declaring a const function pointer to the method;  
but this approach is less messy, and requires less knowledge of C.

Another way of defining this could be by inheritance. For example:

cdef class FastFoo(Foo, cython.finalobject):
     pass

cdef Foo bar = Foo()
cdef FastFoo fastbar = <FastFoo> bar

Sturla

(Continue reading)

headers

Stefan Behnel | 13 Jan 2010 13:00

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


Sturla Molden, 13.01.2010 11:29:
> Den 12. jan. 2010 kl. 15.44 skrev Stefan Behnel <stefan_ml@...>:
> 
>>> cdef Foo bar = Foo()
>>> cdef inline Foo fastbar = bar
>>>
>>> bar.method() # through vtab
>>> fastbar.method() # direct call
 >>
>> Why would you want to control this from user code?
> 
> Because I feel the common usecase for skipping the vtab indirection is  
> calling a method repeatedly from user code.
> 
> This will not break Python semantics globally, but be a local  
> optimization when the user knows the type of an object.

I'm not so much worried about Python semantics here. Extension types are 
different anyway.

My main concern is with the user knowing "the type of an object". The 
optimisation you enforce here is based on an explicit type that you ask 
Cython to use. It's not based on the actual type of the object. If anywhere 
in the evolution of the code base it happens that the object in question is 
replaced with a subtype, the code above will break without warning and 
potentially in a subtle, non-obvious way.

The only way to make this safe would be to enforce exact type checks on 
assignments to a "cdef inline" variable. That breaks other common code

(Continue reading)

headers

Robert Bradshaw | 12 Jan 2010 21:31

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 12, 2010, at 5:04 AM, Sturla Molden wrote:

> I'd like to make a different suggestion. What about a keyword to pass
> after cdef in the declaration of the object to indicate the vtab can
> be skipped? I e an assertion that the object will be of the declared
> type. This will maintain better compatibility with Python.
>
> cdef Foo bar = Foo()
> cdef inline Foo fastbar = bar

Hmm... The notion of an "inline object" to me evokes allocating on the  
stack, or passing by value, or something like that--not ignoring type  
information when doing method dispatching. This isn't too important-- 
another keyword could be found.

> bar.method() # through vtab
> fastbar.method() # direct call

There is already a more explicit way to get this behavior:

cdef class A:
     cdef identify(self):
         print "I'm an A"

cdef class B(A):
     cdef identify(self):
         print "I'm a B"

cdef A a = A()
cdef B b = B()

(Continue reading)

headers

Sturla Molden | 7 Jan 2010 15:49

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?


> would emit a direct call to the ..._small_method(self, x) C function in
> big_method(), instead of passing through self->__pyx_vtab->small_method.

Or just declare self->__pyx_vtab->small_method a const pointer, so the C
compiler knows it does not change.

SM

headers

Robert Bradshaw | 7 Jan 2010 21:41

Re: [Cython] Make 'inline' methods in cdef-class non-overridable?

On Jan 7, 2010, at 6:49 AM, Sturla Molden wrote:

>
>> would emit a direct call to the ..._small_method(self, x) C  
>> function in
>> big_method(), instead of passing through self->__pyx_vtab- 
>> >small_method.
>
> Or just declare self->__pyx_vtab->small_method a const pointer, so  
> the C
> compiler knows it does not change.

That might help, but I don't think either of these indirections could  
be resolved at compile time, even if the latter could be declared const.

- Robert