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. >> 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. IMHO, "inline" fits exactly the intended optimisation, whereas "final" doesn't imply (and certainly not request) any optimisations at all. > 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). > On another note, I assume inline > methods could be placed in pxd files if desired as well? I guess that would be a suitable extension to this feature, yes. > As for decorators vs. inline (pun intended) function modifiers, we > should certainly support both. Personally, I think adding new keywords is bad. I hope that 'final' would be used rarely enough not to require a new inline keyword here. A decorator would suite the intention perfectly. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
