Robert Bradshaw wrote: > On May 15, 2008, at 2:09 PM, Lisandro Dalcin wrote: >> Moreover, I can distribute a single set of generated C sources (I do >> not want users have to install Cython to build my package), and they >> build and the final extension module work just fine. >> > If this is possible (and I think it is), I would *very* much like to > support this. The behavior of the module should depend mostly on the > Cython compilation environment/flags. However, for (unmarked) string > literals I think we should decide based on the C compilation stage. > This makes things like hasattr much more compatible, as well as > accepting/returning string literals objects.
If it will work then I won't argue any more (though Stefan is also resisting it). I'll just mention this: My fear is that with this kind of thinking we get a combinatorial explosion in testing scenarios. I.e., if the exact behaviour of the syntax both depend on the pyx source language level [1] and the C compilation environment, then one could argue that one should test for every combination of these. However, if there is a rule that "behaviour is fixed" after Cython compilation then one only has to write tests that only consider the language levels on each side seperately, so no combinatorial explosion. This is all in principle though and in practical reality, less complete testing might be sufficient. In this case, that practical solution would be to think of the ""-literal as being a third magic string type, that behaves differently depending on the runtime environment. Then one only has to test the behaviour of this magic type, so only the C environment levels has to be tested, and no combinatorial explosion... [1] Pyx source language level == switches for which Python version to emulate, "from __future__ import ..." and so on -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
