Robert Bradshaw, 22.01.2010 10:08: > On Jan 22, 2010, at 12:40 AM, Stefan Behnel wrote: >> and #467. The latter one can be bad in rare cases but shouldn't do >> much harm normally (and isn't >> exactly trivial to get right). > > Not quite a blocker, but it'd be really good to get that fixed.
Why did I expect that answer? ;) >>> I'm imagining a big release >>> where we pull in a bunch of stuff that's been "almost ready" for a >>> while: >>> >>> 1. Safe type inference (on by default) >>> >>> This seems to be basically ready, but is too big of a change for an >>> x.y.z release. >> Ok with me, but that's in cython-devel already. Would you want to >> roll back >> the implementation or just disable the feature by default? The latter >> should basically revert to the original behaviour already, AFAICT. > > I see at > http://hg.cython.org/cython-devel/file/fce98451e2dd/Cython/Compiler/Options.py#l51 > > that it's False. None is the "safe" value, right? Right, so we'd just leave it as False for 0.12.x then. >>> 2. Closures >> Sure, let's get that one out and then take a look at where that gets >> us. >> There hasn't been such a major new feature in Cython for a while, >> and this >> will enable tons of new use cases and forms the basis for quite a >> lot of >> other Python features (e.g. lambda and generators). > > lambda is pretty much there. (IIRC, you did the parse tree transform > for that, right?) :) I remembered that I had started working on that, but I didn't remember that I had actually finished it up. But I just checked and there's a working test case, so I'm happy to agree that that's done. I guess generators are next, then. >>> 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. 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. :) >, and > we would be fixing on "operator+" rather than "__add__" declaration > notation.) Yes, I still think that makes sense. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
