A use for integer quotients
Tim Daneliuk
tundra at tundraware.com
Mon Jul 23 15:20:01 EDT 2001
Bengt Richter wrote:
>
> On Mon, 23 Jul 2001 11:46:45 GMT, Guido van Rossum <guido at python.org> wrote:> >
> 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
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.
I would only suggest that such a keyword:
- Have "at least" semantics so that later versions would satisfy the 'requires'
as well.
- 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.)
- Be optional, which would mean that anything works.
> 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 ;-)
I worry about all this on two levels:
- As an architectural matter, new behavior should have new operands, IMHO.
- As I said, I'm new to Python, but I've seen a ton of languages come and
go. There seems to be a point at which all languages start getting
burdened with "boutique" features that clutter up the overall paradigm
in favor of rather specialized actions. It seems to be human nature
to never leave well enough alone. Python has an extremely elegant
structure, and I worry that it too will become burdened with nice,
but ugly appendages thereby undermining the cohesion of its initial
design.
It seems to me that the energy to innovate would be better
spent adding more "batteries included" modules to a core lanugage
that is stable and remains so. 'C' for example, largely stayed
the same until ANSI X3J11 (of which I was an Observing Member).
Even there, the initial intent to codify existing practice got
polluted somewhat when various factions tried to get their pet semantics
plugged into the new standard.
Speaking as someone who leads commercial development and architecture
organizations, the adoption of any new technology or language is as much
or more about stability than it is feature set. The Python community
could really distinguish itself here, and thereby garner lots of new
converts, if we resisted the feature-of-the-month-club that has
characterized Java and Perl, for instance.
Just my 2 cents worth...
--
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com
More information about the Python-list
mailing list