[Distutils] [RFC] PEP 345 and PEP 386 updates

M.-A. Lemburg mal at egenix.com
Wed Oct 21 11:53:43 CEST 2009

Tarek Ziadé wrote:
> On Wed, Oct 21, 2009 at 10:42 AM, M.-A. Lemburg <mal at egenix.com> wrote:
>> Tarek Ziadé wrote:
>>> On Tue, Oct 20, 2009 at 5:20 PM, M.-A. Lemburg <mal at egenix.com> wrote:
>>>>>> The micro-language should provide a limited number of
>>>>>> variables to use on the conditions:
>>>>>> python_version = sys.version
>>>>>> sys_platform = sys.platform
>>>>> If we adopt such a micro-language (I'm reserving judgment until I've
>>>>> had more time to read the relevant PEPs carefully), I'd rather see the
>>>>> names match what's in the Python runtime more closely, probably only
>>>>> avoiding the call syntax.
>>>> We could do that as well, yes.
>>> +1 on close names + no call syntax
>>> but, notice that "python_version" here is:   "%s.%s" %
>>> sys.version_info[0], sys.version_info[1]
>>> thats why we came up with that name, to disinguish it from sys.version
>>> (that contains more stuff)
>> I think we do need the full version here, so perhaps using
>> sys.version.split()[0] would be better or simply the full
>> version string and then have conditions use >=, <=, <, >
>> only (ie. not =, since that would likely never match).
> Notice that for the comparisons >, < to work, that requires more than string
> comparisons in case we provide the ability to work with rc versions, because:
>>>> '2.6.3rc4' < '2.6.3'
> False
> We said earlier that we could use sys.hexversion to handle this, but otherwise,
> at least for the Python version, we can use the StrictVersion() class
> from Distutils,
> *But* we ended up thinking that it would be better for the first version to keep
> just "==", "!=", "in" and "not in" operators and a MAJOR.MINOR string.
> These are enough just to compare strings, on a limited number of
> versions for Python.


> What use case you have in mind for a three numbers version ?

This may occur when you for example rely on PyXML, elementtree
or simplejson which are also available as external packages
(with a different release cycle).

E.g. say there's a bug in the JSON package included in Python
versions 2.6.0, 2.6.1, 2.6.2 which is fixed in 2.6.3 and has
also been fixed in the PyPI version of the package.

Now say that a system ships with 2.6.1 as Python version.

For Python versions with the bug, you'd add a requirement for
the external package in order to work around the bug in the
system installation of Python. For Python versions >= 2.6.3,
you'd continue to use the package from the system provided
Python installation.

It's a rather rare use case, so just something to think
about for a future revision of the proposal.

>> Note that packages do sometimes need to know that a certain
>> Python patch level release is installed (e.g. Zope often has
>> had this need) and a proper dependency checker would have to
>> detect a possible mismatch.
> I see. I would rather have this patch info in another variable, and restrict
> the micro language capabilities as much as possible.
> Any hint were Zope does this ?

Early Zope versions simply warned about the problem in the
release documentation. IIRC, later versions actually tested
the installed Python version and warned about issues during
the installation process.

I'm not sure how Zope 2.12 with all the tiny little packages
handles this case.

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Oct 21 2009)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611

More information about the Distutils-SIG mailing list