On Tue, Nov 2, 2010 at 12:32 AM, Stefan Behnel <[email protected]> wrote: > Robert Bradshaw, 01.11.2010 22:04: >> On Sun, Oct 31, 2010 at 6:56 AM, Stefan Behnel wrote: >>>> On 31 October 2010 10:09, Robert Bradshaw wrote: >>>>> [cdef] class A: >>>>> ... >>>>> >>>>> del A >>> >>> Should Cython prevent this >>> for public/api classes, or would you just get the ImportError at runtime >>> when it tries to read the type from the module dict? >> >> Personally, I would not be opposed to putting everything into the >> __pyx_api object rather than loading anything from the module dict. >> That would be safer for one thing. > > Sounds better, yes. And with an additional fallback to reading classes from > the module dict, it would even be backwards compatible. > > I think that would be part of the public/api unification that we considered > a while ago. > > >> I would say that "del" simply removes things from the Python >> namespace. The c namespace is fixed at compile time, and would remain >> so. This is essentially the case already, though perhaps we disallow >> del for cdef classes as they live in both namespaces (don't know). > > See? That's the kind of "don't know" that I meant. I'm not sure either.
I meant I don't know what happens now. > When I see "del TheClass" in a module, do I have to know what kind of class > this is in order to know if I can continue to refer to it inside the module? Good point. >> We'd probably want to support del on cdef classes for pure Python mode >> anyways. > > It wouldn't work the same way, though. If you "del" a cdef class in pure > mode running under Python, its name will disappear. If you "del" it from > within Cython, it will continue to be accessible under that name and likely > wouldn't support redefinition either. > > >> My main objection is that this decorator is yet another thing that >> doesn't, and cannot, have an exact Python equivalent, and there's a >> reasonable and widespread Python idiom to use in this case. > > I agree. I'm just saying that it is a well defined and useful feature > within Cython. Maybe we could really only allow it within Cython modules, > i.e. use a cdef class modifier instead of a decorator. That would prevent > its ambiguous use from pure mode and we could continue to disallow "del" on > cdef classes as that's also ambiguous in pure more (and also mostly useless > as it doesn't free any resources nor allow redefinition). To clarify, I'm only slightly opposed to this decorator, so if you think it's useful (and you've made a good case) I'm OK. Definitely want final, though unfortunately it seems that final functions and methods would still have to pass through function pointers (perhaps with one level less of indirection) for cross-module calls (unless we did some kind of compile-time linking). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
