"no variable or argument declarations are necessary."

Alex Martelli aleax at mail.comcast.net
Sat Oct 8 09:09:29 CEST 2005

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:

> aleax at mail.comcast.net (Alex Martelli) writes:
> > ap.py:4: No global (test) found
> > ap.py:5: Local variable (ego1d) not used
> > Helen:/tmp alex$ 
> > 
> > If you're so typo-prone and averse to unittests that you consider this
> > kind of issue to be a serious problem, just use pychecker and get
> > informed about any such typo, just as above.
> That's very helpful, but why isn't it built into Python?

Because some users will prefer to use a different approach to checking,
for example, such as pylint (much more thorough in enforcing coding
rules and checking for all sort of things) or nothing (much faster than
pychecker, which in turn is faster than pylint).  Just as for other
programming tools, such as, say, an editor, I think it's wise to avoid
excessive and premature standardization on one specific tool to the
detriment of others.  (IDLE is "bundled with" Python, but not _built
into_ it -- indeed some would claim that the bundling was too much).

Not all tools need evolve at the same speed as the core language, which
currently follows a wise policy of "major" releases (2.3, 2.4, etc)
about 18 to 24 months apart, and NO feature changes for "point" release
(2.4.2 has exactly the same features as 2.4.1 -- it just fixes more
bugs).  Any tool which gets built into python (or, less strictly but
still problematically, is separate but bundled with it) must get on
exactly the same schedule and policy as Python itself, and that is
definitely not something that's necessarily appropriate.

If you're worried about the end-users which can't be bothered to
download tools (and, for that matter, libraries) separately from the
main language, the solution is "sumo releases" -- Enthought Python (from
Enthought) being an extreme example, but Active Python (from
ActiveState) comes with quite a few bundled add-ons, too.  I believe
that Linux has proven the validity of this general model: having the
"core" (mostly the kernel, in Linux's case; the language and standard
library, in Python's) evolve and get released as its own speed, and
having _distributions_ bundling the core with different set of tools and
add-ons get released on THEIR preferred schedules, independently.


More information about the Python-list mailing list