[Python-3000] Changing the import machinery

[Ian Bicking]

Greg Ewing wrote:
> Ian Bicking wrote:
>>try:
>>     from string import Template
>>except ImportError:
>>     from mypackage.backports.string24 import Template
>>
>>Doing this in a more elegent or formalized fashion might be nice. 
> 
> 
> Have you seen my proposal for "or" in import statements?
> Would you consider that elegant enough?

No, I haven't; I assume you mean:

   from string import Template or from mypackage.backports.string24 
import Template

... that (realistic) example doesn't look very pretty :(

>>Versioning the standard library
> 
> 
> My thought on versioning is that it should look something
> like
> 
>    import spam[3:], movies.grail[2:4]
>       # version 3 or later of spam, version 2, 3 or 4 of movies.grail
> 
> I would like this much better than some kind of require()
> function. Integrating the version specification with the
> import would solve some problems, such as the one mentioned
> earlier where a tentative import fails when it would have
> succeeded if some later require() had been done first.

One difference of require() is that it works on distributions (well, 
distribution names), not on Python packages.  So you can have a 
distribution that provides more than one module, or you can have two 
differently-named distributions that provide the same module (which is 
nice for forking).

Also, I already find it difficult to maintain version requirements 
declaratively in my setup.py files.  I have to speculate on whether some 
package will depend or conflict with a version of some other package 
that hasn't even been released yet.  For instance, I might release my 
code A, then realize that there's a bug in another package B that breaks 
A; after B is fixed, I'd like A to require that new fixed version, but 
package A hasn't actually changed in any way... yet I have to give it a 
new version number.

Actually putting the requirements in the import statements in the body 
of my code seems worse.

> The form that the version numbers should take is up to
> debate, but I'd tend to keep it extremely simple, i.e.
> just integers. The baroque possibilities offered by the
> setuptools require() seem like overkill to me.

A more formalized version makes it possible to use the version number 
meaningfully.  E.g., require >=1.5,<1.6 of a library, even though 1.6 
doesn't exist, because there's a policy of not releasing anything but 
bug fixes without at least a minor version increase.

Version parsing *more* sophisticated than setuptools' could make 
branching and forking of projects more feasible.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org