Hello, I'm a relative newbie to cython/pyrex, so I won't be offended if this suggestion gets thrown out quickly as long as I learn something in the process. From my googling, it seems that decorators aren't really supported by cython/pyrex yet (http://wiki.cython.org/enhancements/decorators) but are on cython's to-do list. It strikes me that decorators would be a natural way of handling this, i.e. having a @notNone decorator for functions that has the affect of adding "not None" to every argument. If part of the reason for switching the default is that writing "not None" for every argument is awkward, this would be a reasonable middle ground.
-- Hoyt On Fri, Aug 22, 2008 at 11:36 AM, Robert Bradshaw <[EMAIL PROTECTED]> wrote: > On Aug 22, 2008, at 12:47 AM, Kirill Smelkov wrote: > >> В сообщении от Четверг 21 августа 2008 >> Greg Ewing написал(a): >>> Lisandro Dalcin wrote: >>> >>>> I know, I can (and I do) use 'Type arg is not >>>> None' in argument lists, but I never liked it. >>> >>> Speaking of that, I've been thinking for a while now >>> about making "not None" the default, and requiring >>> "or None" to specify that None is an acceptable >>> parameter value. >>> >>> Having seen a number of pieces of Pyrex code that >>> were susceptible to being crashed because "not None" >>> wasn't used where it should have been, I think >>> this would be a safer default. The change may >>> break some existing code, though. >>> >>> What do people think? >> >> I'm +1 for having "not None" the default. >> >> I was always wondering why was it the vice versa when I was >> stydying Pyrex -- >> for internal functions this was creating additional overhead and >> additional >> inconvenience, and I'd better put "or None" explicitely where it >> makes sence >> -- for high-level functions who interface with Python level. >> >> >> Bearing backward compatibility in mind, maybe let's create a >> compile option to >> switch this behaviour? And we'll remove old behaviour step-by-step: >> >> o first declare there is new "not None" by default with explicit >> switch, saying >> it will be the default in the next release. >> o then make default "not None" default and allow users to switch >> back with >> cython/pyrex option, but say this old behaviour will be removed >> in the next >> release >> o remove old behaviour in the next release. >> >> Sounds reasonable? > > I am still -1 to the idea, but keep trying to convince me :). > Certainly I would like things to be more friendly then they are right > now, but having two kinds of extension class types that are declared > exactly the same way, one of which can take a None and the other > can't, seems odd. Certainly enabling a switch to check for this is > something I want to have, and not limited to python function > arguments either. > > - Robert > > > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev > -- +++++++++++++++++++++++++++++++++++ Hoyt Koepke UBC Department of Computer Science http://www.cs.ubc.ca/~hoytak/ [EMAIL PROTECTED] +++++++++++++++++++++++++++++++++++ _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
