Re: Policy for "Specifying Supported Versions" for Python3
"Paul Wise" <pabs@debian.org> wrote:
>On Tue, Jun 22, 2010 at 6:30 AM, Scott Kitterman <debian@kitterman.com> wrote:
>
>> If we maintain a standard that if in Python you import foo, then the Python
>> package name is python-foo and the Python3 package is names python3-foo, I
>> would think this is manageable. I think that adding this metapackage would
>> impose a lot of complexity on packagers and/or python helper maintainers,
>> bloat the Packages.gz file signficantly, and probably provide confusing search
>> results.
>
>What is the point of separate python-foo/python2-foo and python3-foo
>packages? Will they be separate source packages or just binary
>packages? Will we rename the python3-foo packages to python-foo once
>python 2 is gone? After python 2 is gone will we add new packages
>named python-foo and have old python3-bar packages in the archive at
>the same time?
>
>From a design perspective we think it's better to maintain run time separation between the Python and Python 3 stacks. Although they share a common ancestry there is effectively no Python code that runs unmodified in Python 3.
Right now the Python 3 code base is much narrower than Python's (my unscientific and not very educated guess is it's about 10%). My guess is we are more than one release cycle away from the point where they are at all comparable. I would be surprised if significant amounts of Python go away in this decade.
I don't know what will happen when Python is gone, but I think that's far enough in the future we shouldn't let it color our current design.
In the mean time, there is benefit to run time seprartion. It's cleaner and makes it easier to determine if Something will work in Python 3 or not. If we don't have binary separation, one would have to examine binary depends to evaluate Python 3 support. Putting Python and Python 3 code in the same binary isn't conceptually a lot different than putting Python and Perl bindings in the same package.
Scott K
Reply to: