From: PJ Eby <pje@telecommunity.com>
So, can we keep inequalities (and therefore chained comparisons) out of the spec then? ;-)
But it seems a reasonable expectation to have "python_version > '2.5'" in the spec, which needs no version parsing to work, and likewise it seems not unreasonable to also allow "'2.4' <= python_version < '2.6'". What's the actual difficulty in allowing this? It seems a reasonable use case.
It makes a single-source version of the code tougher, because strings don't have a decode() method in Python 3.
I must be missing something - why not something like def ensure_unicode(s): if not isinstance(s, text_type): s = s.decode('unicode_escape') return s assuming you only ever pass bytestrings or Unicode in s, and text_type is unicode on 2.x and str on 3.x?
I definitely want to move to a single source strategy ASAP, but that's precisely why I'd prefer not to decode something that's already a string of version-appropriate type. ;-)
Sadly, some type checking is unavoidable if you can't control what people pass in to your code, but it seems easy enough to deal with from a pragmatic point of view.
Mainly, I just want to keep the code size small, without opening too many interop problems or backward compatibility issues. If we outlaw absolutely everything in the first version of the spec (and enforce it), we don't end up with implementation-defined behavior, but can still loosen restrictions later if an actual use case appears.
I'm OK with restricting to ASCII (though, from having done numerous single-source ports, the cross-platform handling of Unicode/bytes seems to be a solved problem), but I don't think inequalities need to be removed. (It's easy to disable in distlib's implementation, so that's not the issue - it's whether it's a useful thing to have in the spec.) Let's see what others say. Regards, Vinay