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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
