[Python-Dev] Proposing PEP 345 : Metadata for Python Software Packages 1.2

david.lyon at preisshare.net david.lyon at preisshare.net
Mon Dec 28 08:44:22 CET 2009

> david.lyon at preisshare.net writes:
>  > With respect, it's not a very common use case for a developer to
>  > say that package needs a python interpretor 'older' than 2.5.
> Of course it is.  I don't claim it is the majority of cases out there,
> but stable versions of many of the packages I use will specify an
> older python (Mailman and Zope both specify a range of Pythons, rarely
> including the most recent release, and Bazaar, although it tries to
> keep up with Python releases, tends to recommend being conservative,
> sticking to release (n-1) for the first few months into release n.)
> And in fact this case is often more the important one.  Packages that
> depend on having a *recent* version of python will often crash
> quickly, before doing permanent damage, when an undefined syntax,
> function, or method is invoked, while packages that depend on a quirk
> in behavior of an older version will typically silently corrupt data.
>  > imho, all that they would know, is that they're using python
>  > (for example) 2.4 or 2.5 (pick a python version) and they
>  > know it works pretty well.
> If they want to specify a Python version that works, they may as well
> bundle it, and many do.  But even in that case the user may want to
> know about the dependency.
> BTW, *all* of the Python applications I really care about make a point
> of specifying a range of versions they work with (or bundle a
> particular version).  So in fact many developers do know what versions
> work or fail, and often why (and they sometimes even provide
> workarounds/patches for adventurers who want to use a Python outside
> of the recommended range).
>  > It's then up to the user if they want to use it on any other
>  > version.
> This is often an undesirable posture.  From the user's point of view,
> the system version of Python may have passed various local tests and
> therefore be strongly preferred (for example, requiring far less time
> for approval from the security team).  This is especially true for
> mail or web applications and other applications that must run in a
> very hostile environment.  Many developers do want to provide this
> kind of information to such users.
> I think you should rethink your position on how valid your personal
> intuitions are for generalization.  You are certainly representative
> of a certain important segment of developers, but I don't think you
> have a good sense of the very broad class of requirements that other
> developers are bringing to the table.

More information about the Python-Dev mailing list