Christopher Barker, 14.04.2010 18:21: > """ > 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".
I still have some doubts that the example that Dag presented comes close enough to a majority. Python has optional arguments, so it's extremely rare that I need to pass None into a function explicitly. In many, many cases where I accept None, there will be a None default value, which the change would handle properly (and, BTW, that can already be implemented now, so I will do it). In most Python code I have seen so far, required arguments that received a None value eventually resulted in an exception at some point. I doubt that this is substantially different in Cython code. > 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. I agree, and that argument is already in the CEP. > 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? That has been discussed back in the early days but never got us anywhere AFAIR. I would expect that such a discussion would be redirected to this page nowadays: http://wiki.cython.org/enhancements/methodtemplates > """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. > - Can't you destroy the reference with a "del"? Not in current Cython. However, this could be faked even without flow control analysis by setting the variable to NULL on deletion and adding NULL checks (and an appropriate exception) to each access of the variable. Since this would only apply to names that are actually del-ed within a function, the performance hit wouldn't even be /that/ high. It's not that trivial to implement, though, because you'd also have to take nogil blocks into account etc. Getting proper flow control analysis working is certainly a better thing to spend your time on. > - 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. Python objects are different, though, and None is a *very* handy value that you really want to be able to assign to a typed name, believe me. In some cases, e.g. when the extension type guards certain resources, you won't even be able to use an instance of the extension type itself as None-like value, because you can't easily instantiate it. > 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? Since no-one has started working on this yet, and there are no known plans to do so in the near future, I'd expect 'years' not to be too far away from the truth, although 'months' could be possible with the right combination of developer time and interest. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
