On Apr 14, 2010, at 9:21 AM, Christopher Barker wrote: > Stefan Behnel wrote: >> I've written up a CEP for now: >> >> http://wiki.cython.org/enhancements/argumentnonechecks > > great, thanks!
Yes, thanks! > > A couple comments: > > > """ > Typed argument values that must reject None are more common than those > than can safely allow them (without being optional arguments). So the > current syntax requires more overhead on the user side than the > proposed > syntax. > """ > > This seems to be very much style dependent. If I followed the > conversation right, Lisandro (and I) would use a lot of "not None", > whereas Dag would use a lot of "or None". So I think the more > compelling > argument is that leaving out a "not None" could result in a segfault, > whereas leaving out an "or None" would result in an exception, and be > more likely to be caught in tests. > > > About "or None": None is a very common and useful case for an extra > type > one might want, but it's not the only one -- is there a way to tell > Cython that you want to accept one of two (or a few) types? > > > > """Changing the behavior of cdef MyExtType x is not an option as the > variable requires an initial value and users must be able to set it > to a > neutral value to destroy the reference they contain. > """ > > This is probably a result of my limited understanding, but I'm still a > bit confused about this -- there has got to be a less dangerous way to > do that -- after all, people write a lot of code in C without > needing it. This is what happens when people dereference NULL or uninitialized pointers. (Under the hood, all Python objects are just PyObject*, in C+ + terms they're all heap allocated.) > - Can't you destroy the reference with a "del"? Not for local variables (yet). What would you put in its place? i.e. cdef MyType x = ... del x print x The Python interpreter sets it to NULL and checks, on every access, if it's NULL (raising an UnboundLocal exception if it is). With control flow, we'll be able to do this too without (much, in most cases) cost. > - It doesn't seem onerous to me that an initial value needs to be of > the type specified -- that's the cost of static typing. It's easy to come up with default values for ints, doubles, pointers, etc. (though they may be just garbage). Less so with MyRandomExpensiveToCreateClassThatRequiresLotOfArguments. In C++ one either has default constructors, or the language forces you to call one--in other words you can't declare a stack-allocated C++ object without assigning it. (Not only are Python classes all heap allocated, there are several reasons why this is not very Pythonic or feasible for Cython, among them the much simpler scoping rules.) > Dag Sverre Seljebotn wrote: >> But it can still be compared to Cython-with-control-flow-analysis, at >> which point I don't have to bother about "or None" or "not None" at >> all, >> meaning one less thing to think about (and learn!) with respect to >> pure >> Python. > > Yes, that will be wonderful -- but are we talking months or years > before > it's a reality? I'd think less than a year. For example, personally, I'll have a lot more time to work on Cython once I graduate. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
