> I think there is a place for backwards-incompatibility. For example, > the __new__() being renamed to __cinit__() (as __new__() a very > different meaning in Python). However, if there is ever backwards- > compatibility issues, it should be for a *very* good reason. Also, we > might want to add syntax candy, so I'm not sure about the "previously > unavailable features" clause.
I'll agree to the last sentence, but not what is before (see below). <snip> > I don't think supporting multiple versions of the language, and > having a specific Pyrex flag, is a good idea. If one wants a specific > version of Cython, one can download and use that one. If one wants > *exatly* Pyrex syntax, use Pyrex itself. Any difference should be > clearly documented, and be for good reason, but having different > "modes" that we continue supporting seems cumbersome. The sum of this is, I think, exactly why some people are sceptical to Pyrex and Cython as software projects. The thing is, if you are responsible for a big project and wondering if Cython is for you, there's *two* needs: - Is it stable in the sense that I don't have to keep up with new developments in the languages? (Doesn't matter how trivial the change is as long as you cannot compile previously working code -- that's essentially wasted time, no matter how nice-looking the new syntax is.) - Bugfixes! You can't simply say download an old revision and use that one, because when you stumble upon bugs in Cython (which there are!), you have to consistently work around them because you cannot upgrade for the bugfixes without also upgrading your syntax. Look to Python and how they promise to keep 2.6 alive for a long time even if 3.0 arrives... I think there's basically two models: - The big project way: Fork off new development branches but keep backporting bugfixes to older releases. - Keep supporting multiple language revisions in the same branch. (This is not too hard in many cases; one can probably often simply stick a backwards-compatability transform for the syntax in the pipeline if the right conditions are met. Though there's the danger of a growingly complex parser.). I don't think the current model (keep adding bugfixes to newest release, which also reserves the right to change the language without being backwards-compatible) is a good idea. > Maybe... I really don't like the idea of mixing the two modes, e.g. > > cdef cdef x = cdef(3) The idea is really only that Cython should be able to compile *all* Python code, and that includes Python code with the cdef used as variable names. If Cython cannot compile Python code containing "cdef" as a variable it could really, as you've said put it sometimes, be considered a bug since it's possible to write Python code that's not Cython-compilable. But a mode flag probably fixes that in a good way without allowing stuff like above. -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
