[Moved to python-dev from xml-sig] Guido van Rossum wrote: > > > Perhaps a good start would be using lib/python-2.0.0 as installation > > target rather than just lib/python2. I'm sure this was discussed > > before, but given the problems we had with this during the 1.5 > > cycle (with 1.5.2 providing not only patches, but also new > > features), I think a more fine-grained approach should be > > considered for future versions. > > We're using lib/python2.0, and we plan not to make major releases with > a 3rd level version number increment! SO I think that's not necessary. Ah, that's good news :-) > > About package versioning: how would the version be specified > > in imports ? > > > > from mx.DateTime(1.4.0) import now > > from mx(1.0.0).DateTime import now > > from mx(1.0.0).DateTime(1.4.0) import now > > > > The directory layout would then look something like this: > > > > mx/ > > 1.0.0/ > > DateTime/ > > 1.4.0/ > > > > Package __path__ hooks could be used to implement the > > lookup... or of course some new importer. > > > > But what happens if there is no (old) version mx-1.0.0 installed ? > > Should Python then default to mx-1.3.0 which is installed or > > raise an ImportError ? > > > > This sounds like trouble... ;-) > > You've got it. Please move this to python-dev. It's good PEP > material! Done. > > > > We will have a similar problem with Unicode and the stdlib > > > > during the Python 2.0 cycle: people will want to use Unicode > > > > together with the stdlib, yet many modules in the stdlib > > > > don't support Unicode. To remedy this, users will have to > > > > patch the stdlib modules and put them somewhere so that they > > > > can override the original 2.0 ones. > > > > > > They can use $PYTHONPATH. > > > > True, but why not help them a little by letting site > > installations override the stdlib ? After all, distutils > > standard target is site-packages. > > Overrides of the stdlib are dangerous in general and should not be > encouraged. > > > > > BTW, with distutils coming on strong I don't really see a > > > > need for any hacks: instead distutils should be given some > > > > smart logic to do the right thing, ie. it should support > > > > installing subpackages of a package. If that's not desired, > > > > then I'd opt for overriding the whole package (without any > > > > hacks to import the overridden one). > > > > > > That's another possibility. But then distutils will have to become > > > aware of package versions again. > > > > This shouldn't be hard to add to the distutils processing: > > before starting an installation of a package, the package > > pre-install hook could check which versions are installed > > and then decide whether to raise an exception or continue. > > Here's another half-baked idea about versions: perhaps packages could > have a __version__.py file? Hmm, I usually put a __version__ attribute right into the __init__.py file of the package -- why another file ? I think we should come up with a convention on these meta-attributes. They are useful for normal modules as well, e.g. __version__, __copyright__, __author__, etc. Looks like its PEP-time again ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4