[Distutils] Are chained comparisons allowed in environment markers?

[Vinay Sajip]

> From: PJ Eby <pje at 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