On Jan 22, 2010, at 4:43 AM, Stefan Behnel wrote: >>>> 3. C++ support >>> I can't say I'm anywhere near up-to-date with the status of that, >>> but if >>> you think it's at a somewhat stable point, so that existing features >>> won't >>> have to get rolled back and replaced, I'm fine with adding it (or >>> parts of >>> it) in 0.13. It's always good to enable users to exercise new >>> features >>> early, and especially the signature overloading support should be >>> very >>> useful to Cython's optimiser by itself. >> >> Yes, I tried to make sure everything exposed is stable and compatible >> moving forward. There are some design decisions that would be good to >> confirm before we release (e.g. I added operators >> cython.preincrement, >> cython.dereference, etc. which might be suited for shorter names > > I'm fine with "preincrement", assuming that it's only really > required in a > couple of cases. The "dereference" could be shortened to "deref", I > expect > that to be used much more often. We also shouldn't forget that users > can > always do the abbreviation themselves during the import.
Right now we have: - preincrement - postincrement - predecrement - postdecrement - dereference - address # was added for pure mode I'm assuming any user will alias them to shorter names, but maybe we should too. For example, "inc" is nice and short, but ambiguous. > BTW, should we use a separate namespace module? E.g. "cythoncpp"? I > think > that would make it clearer what the usage scope is, and the imports > would > still be as broadly simplifiable as before. And Cython could warn if > you > import the C++ module while generating plain C code. :) Those operators all make sense in C as well, no need to limit them. If we're going with a separate namespace, I'd prefer cython.operators. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
