Re: Specifying Supported Python Versions - Round 2
"Barry Warsaw" <barry@python.org> wrote:
>On Jun 30, 2010, at 04:58 PM, Scott Kitterman wrote:
>
>>On Wednesday, June 30, 2010 04:51:38 pm Piotr Ożarowski wrote:
>>> [Scott Kitterman, 2010-06-30]
>>>
>>> > For Python3:
>>> >
>>> > 1. A new field called X-Python3-Version: It does not support lists of
>>> > versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g
>>> > 3.1), greater than or equal to a version (e.g. >= 3.1), or strictly less
>>> > than a version (e.g. << 3.2). Versions 2 or less will raise an error.
>>> >
>>> > 2. There is no #2. If your build system uses py3versions -r, then you
>>> > need X-P3-V, if it's not there, an error will be raised. If it doesn't
>>> > use py3versions -r, then it's between the maintainer and their build
>>> > system. The field is not mandatory.
>>>
>>> why? If py3versions is invoked in debian/rules, then there definitely is
>>> at least one python3-* binary package. Why do you want to make this
>>> field required? I'd make it optional and assume all 3.X versions if
>>> X-P3-V is not set.
>>
>>I'm trying to minimize the amount of implicit magic we do.
>>
>>There was strong consensus for Python 2 that "all" wasn't a great idea for XS-
>>P-V and so we point people away from it. No implicit all seem the logical
>>next step for Python 3 were we have more freedom to make things work the way
>>we want.
>>
>>If there's some consensus for an implicit "all" in Python 3, I won't object.
>
>The question that comes to mind is why Python 2 and Python 3 would have
>different rules? If there's a good reason (e.g. it cleans up a backward
>compatibility wart), then cool. If not, then consistency between the two
>might make a reasonable default.
>
I don't want to break a lot of packages. Both implicit and explicit all are widely used in Python packages. I think we have more freedom to do the "right" thing for Python 3.
Scott K
Reply to: