Dag Sverre Seljebotn, 01.11.2010 22:14: > On 10/31/2010 07:09 AM, Stefan Behnel wrote: >> I just wrote a patch for lxml.etree that adds one or both of the decorators >> where they make sense. >> >> It turns out that out of the 117 extension types in lxml.etree, 39 would be >> happy about at least one of the decorators: 30x final and 36x internal. So >> almost every third class is an internal one. Most of them are context >> classes that are passed through C in one way or another and that are used >> by internal callback code. Pure implementation details that no user should >> ever mess around with or even care about. > > Well, a lot of pure Python libraries have "pure implementation details > that no user should ever mess around with or care about". The Python way > is by convention (like a leading underscore telling people to just stay > away), not by enforcement. > > Is the rationale that it is more important to protect possibly > non-segfaulting Cython code than always-safe Python code?
Yes, I think that's a major issue here. In many cases, it's hard to prevent a segfault when users manually instantiate or subclass such a class. Plus, it fills up the user visible module dict with internal stuff because you can't just "del" a cdef class after use. So you get a huge "help(module)" page full of classes out of which one third is useless information. I'm currently considering ways to make lxml ready for environments like Google's App Engine, where it is important to prevent segfaults. Letting users instantiate and override arbitrary classes has proven to be an unlocked barn door for crashes in the past. It's a lot better now because I actually locked down a lot of classes and their methods. But being able to move them out of the way entirely would allow me to really concentrate on what users are meant to work with. (I just checked http://dict.leo.org for a good translation of what this feels like and didn't find one. But looking up a related word made me find "proxy war", which, I think, nicely matches lxml's use of proxy classes ;) > I guess I just don't see the usecase...prepend an underscore to > module-internal class names, and that's it? Most cdef classes in lxml.etree are prefixed with an underscore. That doesn't prevent users from instantiating them and filing crash bug reports. > Regarding final, I see more of a usecase for individual methods than > classes. I'm +0 for final on classes (Python doesn't have such a > feature, why should we?) CPython does. You cannot subclass "bool" and "NoneType". Some classes are simply not meant for subclassing, especially proxy classes that map C level data structures into Python space. > it is locking down individual methods (for > possible speedups) that is important to me (in this case we can argue > why Cython should have something Python does not). You may notice that I've written all existing feature requests regarding "final". Final methods would really make the language easier to use as you could write nicer OO code without sacrificing performance. lxml.etree has a lot of C functions that would look much better as methods. I just didn't want to implement it just now because it's a lot more work than the "final" feature on entire classes (which, BTW, really is a feature that CPython does not support). I think it would make sense to get the Python function refactoring (Python wrapper + C function) done before that. But that will take a bit of time as well. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
