[Distutils] Are chained comparisons allowed in environment markers?

[Nick Coghlan]

On 28 Apr 2013 19:16, "Vinay Sajip" <vinay_sajip at yahoo.co.uk> wrote:
>
>
>
> > 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.

I say no to allowing text based ordered comparisons in environment markers,
due to the inconsistency with the version comparison rules in dependency
specifications. This also rules out chained comparisons in environment
markers.

"Might be useful" is not the relevant criterion at this point. For metadata
2.0, we're aiming more for "essential, given everything we know about
packaging based on our own experience, that of other language communities
and that of Linux distributions".

That said, I can see value in supporting version specifiers (both for
Python and installed distributions) as part of environment markers if a
suitable syntax can be found (perhaps something that looks like a function
call). It is only the use of ordinary Python string comparisons that are
inconsistent with version specifiers that I seriously object to.

Cheers,
Nick.

>
> Regards,
>
> Vinay
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130428/95dec3f2/attachment.html>