Barry Warsaw <barry <at> python.org> writes: > > Putting Python version numbers in the packages would be a > maintenance nightmare, since all the packages - *and their > dependencies* - would have to be updated every time a new Python > release was added or removed from the distribution. Because of the > sheer number of packages available, this amount of work is infeasible.
How is this "infeasible" exactly? Wouldn't it be an easy target for scripting? > As an example of the problem, a common (though fragile) Python idiom > for locating data files is to do something like this:: I don't think this is fragile. It is the most robust I can think of, but perhaps I'm missing another solution :) (well, apart from pkg_resources, that is) > The implementation of this PEP would have to ensure that the same > directory level is returned from `__file__` as it does without the > `pyr` directory, so that the common idiom above continues to work:: > > >>> import foo > >>> foo.__file__ > 'foo.pyr' Would things like exec() work on the given directory? > An earlier version of this PEP described "fat" Python byte code files. > These files would contain the equivalent of multiple `pyc` files in a > single `pyf` file, with a lookup table keyed off the appropriate magic > number. This was an extensible file format so that the first 5 > parallel Python implementations could be supported fairly efficiently, > but with extension lookup tables available to scale `pyf` byte code > objects as large as necessary. As Martin said, this creates concurrent access problems, when several interpreters modify the file simultaneously. > * What about `py` source files that are compatible with most but not > all installed Python versions. We might need a way to say "this py > file should be hidden from Python versions X.Y or earlier". -1. This is the distributor's job, not Python's. If you want you can create dummy pyc's in your pyr that will raise an ImportError or a NotImplementedError with some versions of Python. But I don't think Python should have a stake in this. > * Would a moratorium on byte code changes, similar to the language > moratorium described in PEP 3003 [16]_ be a better approach to > pursue, and would that solve the problem for vendors? At the time > of this writing, PEP 3003 is silent on the issue. -1. Bytecode is an internal detail; besides, it is vital to be able to evolve it. Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
