John Keeping <john@xxxxxxxxxxxxx> writes: >>> + - Where required libraries do not restrict us to Python 2, we try to >>> + also be compatible with Python 3. In this case we use >>> + `from __future__ import unicode_literals` if we need to differentiate >>> + Unicode string literals, rather than prefixing Unicode strings with >>> + 'u' since the latter is not supported in Python versions 3.0 - 3.2. >> >> "In this case"? In what case? This document will stay effective >> long after you settle one particular backward incompatibility Python >> 3 introduced, namely, the unicode literal issues. It is just one >> "example". > > I meant "in the case where you are supporting Python 3" but I suspect it > would be better to move the unicode_literals sentence to a new bullet. > Or maybe we should just remove it - I haven't seen a case in the current > Git source where we need Unicode literals. Yeah, "we support 2.x" and "we suport 3.x" may want to be combined, but listing individual specifics as separate points to watch out for would make it much more readable. > As more people have started trying to support Python 3 in the wild, it > has become clear that it is often easier to have a single codebase that > works with both Python 2 and Python 3, and not use 2to3. > > It is for this reason that the Unicode literal prefix was reintroduced. Yes, and from that perspective, placing floor on earlier 3.x makes tons of sense, no? These early versions may not be unstable in the "this does not behave as specified in the language specification for 3.x" sense, but for the purpose of running scripts meant to be executable by both 2.x and 3.x series, the early 3.x versions are not as good as later versions where Python folks started making deliberate effort to support them. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html