Version/requirement marking of code using 2.2+ features? Was Re: A use for integer quotients

[Bengt Richter]

I probably should have started a new thread in the first place, so I'll
prefix the post I should have started with, for context:
__________________________________________________________________

On Mon, 23 Jul 2001 18:51:48 GMT, bokr at accessone.com (Bengt Richter) wrote:

>On Mon, 23 Jul 2001 11:46:45 GMT, Guido van Rossum <guido at python.org> wrote:
>[...]
>>
>>Of course, I'm well aware of the issues around maintaining old code.
>>We will have to carry around "from __future__ import division" for a
>>loooooong time.  Python 2.2 is the first opportunity to introduce it,
>>so let's not be shy.
>>
>What about mandatory version/requirement marking of code depending
>on new features of 2.2 and beyond?
>
>This would introduce *now* the possibility of using 2.1 rules for unmarked
>code, and allowing progress without backwards-compatibility pain[1].
>
>Perhaps a requires statement keyword with syntax like print? E.g.,
>
>    requires {'Python':'2.3', 'math':'2.4','division':('unified','warn') }
>
>or short form could be distinguished by arg type
>
>    requires 2.3
>
>The keyword itself would be rejected by older interpreters, signaling a need
>to upgrade the interpreter (or revise the script code down).
>
>All the good arguments on both sides of the '/' question are making me
>feel wishy-washy, as I sympathize in alternation, but I do find the
>backwards compatibility argument compelling. HTH.
>
>[1] Other than for implementors ;-)
>
__________________________________________________________________

On 23 Jul 2001 19:20:01 GMT, Tim Daneliuk <tundra at tundraware.com> wrote:
>Bengt Richter wrote:
[...see above...]
>
>This is a *really good* idea.  Although I am new to Python, I am not new
>to very large development projects.  This ability to stipulate the minimum
>required runtime environment could go a long way to mitigate upgrade and
>release nightmares.
>
Perhaps I should have started a new thread.[1]] Tim said he was about ready
to ignore any more on this one ;-)

>I would only suggest that such a keyword:
>
>-  Have "at least" semantics so that later versions would satisfy the 'requires'
>   as well.
>
Hm. I think we need both. 'At least' only works if backwards compatibility is
guaranteed ;-)

I think the requires side can be specific. The provider side should declare
its capabilities in a way that allows determining go/nogo, or possibly some
setup action to satisfy the requirement.

>- Be generalized so that any module author could apply the same thing to
>  their module independent of all other modules (I think you were hinting
>  at this above.)
Yes, that's what I was getting at with the 'math':'2.4' entry. But then math
has to be able to show its version/capability info. See below.

>
>- Be optional, which would mean that anything works.
>
Well, for unspecified requirements you have to make some default
assumption. If we assume that 2.1 is the most compatible existing
distribution ( or is there lots that breaks on 1.5.2? ), then
unmarked can mean 2.1.

I left out the other side of requires, which is provides, which
I don't think would need a keyword. But maybe a new __provides__
attribute (perhaps also a dictionary, since that is very flexible)
as a container for encoding what the entity provides.

E.g., dir(math) would get you
 >>> dir(math)
 ['__doc__', '__name__', '__provides__', 'acos', 'sin', ... etc. ]

and math.__provides__ might be
 { 'version':'2.4-', 'angleargs':'+degrees', 'exceptions':('-fpprecloss','-infinity') }

meaning it's backwards('-') compatible with a requires 2.4, and it additionally supports
passing degrees to its functions, but if there's a requires 2.3, the implication is that
some exception functionality was deleted and would have to be hooked in to ensure 2.3
compatibility.

This is OTTOMH, to stimulate better ideas, not a design spec ;-)

[1] Decided to do it ;-)