You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
StefanBehnel edited this page Apr 11, 2008
·
2 revisions
There are 3 separate issues here
input
output
codebase
The holy grail would be to have a single Cython codebase run in Python 2.3 - 3.x., accept valid 2.3 - 3.x code, and the code produced should be able to compile and link against Python 2.3 - 3.x (irregardless of what platform Cython was run on).
This may be unrealistic. We know there will be slight dependancies on the runtime platform due to the growing/changing content of the builtins module. Where there are ambiguities in the code (e.g. code that is valid 2.x and 3.x, but has different meaning) we should perhaps give a warning, and default to the code it is being run on. I would like to attempt for some level of implementing 3.x-only features manually for use in a 2.x environment, but certainly this will not be possible for everything. (One instance where we have done this is keyword-only arguments.)
StefanBehnel: the biggest semantic problem I currently see is bytes/unicode literals. Should Cython source code default to 'bytes' literals, which are compatible with plain C strings? Or should it follow Python 3 in breaking source code compatibility? This would mean that most(!) code would break, as converting a string literal to a C string would no longer work.