A use for integer quotients

Tim Daneliuk tundra at tundraware.com
Mon Jul 23 21:20:01 CEST 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