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

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@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig