[Python-Dev] no remaining issues blocking 2.5 release

M.-A. Lemburg mal at egenix.com
Wed Aug 16 00:55:45 CEST 2006


Martin v. Löwis wrote:
> M.-A. Lemburg schrieb:
>>> It's either an official feature, with somebody maintaining it,
>>> or people should expect to break it anytime.
>> I'll let you know when things break - is that good enough ?
> 
> That can't be an official policy; you seem to define "breaks"
> as "breaks in my (your) personal usage of distutils". While
> this is fine as an end-user point of view, it isn't useful
> as a maintenance guideline.

It's all I can offer.

We do use quite a few distutils
features and also extend it in various ways, so I suppose
that our build system covers quite a bit of what distutils
has to offer. Think of it as a test-bot that runs a real-life
test on the distutils code.

> In case you don't see what I mean: I said that something
> is already broken (bdist_msi), where "broken" means
> "doesn't work", and you said "it's only a small part".
> So if it's fine that only small parts break, I wonder
> where this gets us over time.

distutils is composed of many components. bdist_msi is
one of them. Because it's new it can hardly "break"
distutils in any way because it's a feature that didn't
exist in the distutils version shipped with
Python prior to 2.5.

As a result, that distribution format cannot be used with
older Python versions, but the rest of distutils continues
to work as usual.

I wouldn't call that breakage of distutils. It's just a
feature that has external requirements, much like you
can't run bdist_rpm without having the RPM tool installed.

In general, if you have to rely on new features in Python
such as extension modules which are not available in older
Python versions, then that's fine - but again, if not
really necessary, I'd rather see an approach being used
that also works with older Python versions.

What I do consider breakage, is if you use Python 2.5
features just to beef up some part of distutils core
code.

> For another example, you found that 2.1 compatibility is
> now broken (due to usage of True and False). When distutils
> was still listed in PEP 291, 2.1 compatibility was mentioned
> as a goal. Now, it doesn't seem to bother you very much
> that 2.1 compatibility is gone.

Actually, it does bother me, but I understand that not
many people use Python 2.1 anymore, so don't insist keeping
that version requirement.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Aug 16 2006)
>>> 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::


More information about the Python-Dev mailing list