> > In many cases, this is true, but there are other scenarios (certain > > forms of exception handling, for example) where there is no syntax > > that's valid in both versions. That's syntax, not just libraries and > > functions. There's no way to even get a file to parse in both Python 2 > > and Python 3 in these situations. > > Martin's approach was single codebase where the 3.x version for execution is > generated by 2to3, not single source for execution across 2.x and 3.x. Thus > I'm wondering if this difference is accounted for by 2to3?
Most certainly - that's the whole *point* of 2to3. Converting the cases where the syntax differs are actually the easy parts - it is very easy to find out, by static analysis, that Python 3 would reject a piece of code, and to propose a reformulation that is equivalent. That's where 2to3 shines, and thus where anybody adding 3.x support to a 2.x code base doesn't need to worry at all. When the syntax is correct in both versions, but library names differs, 2to3 still works fairly well if it guesses correctly that the name indeed refer to the renamed libraries (which has some degree of uncertainty in Python). The really difficult cases for 2to3 is where a piece of code works unmodified in both 2.x and 3.x, but does something significantly different. For example, string literals mean something different, and the result of reading from a file may be different (unicode vs. bytes in both cases). Fortunately, Django already attempts to differentiate bytes and unicode fairly well, so it was easy to fix the remaining spots which would break under 3.x. Regards, Martin
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
