> From: PJ Eby <[email protected]>
> 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
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
