Pythonic Quote of the Week - sliding away...

[Emile van Sebille]

I understand the intents both of Guido's and Tim's quotes below.  Granted
that Python-Labs is reluctant to add to their obligation to support
additional standard modules for ever more, I think a future PEP should lay
out a PEP like process (call it SPAM - Specialized Python Add-in Module ;-)
that formalizes *which* modules will be considered as acceptable for
inclusion in the core.  Then it becomes clear if a particular module is or
will be Python-Labs supported, or if the community builds and supports it.
I feel that the PEP you are proposing will help keep the level of third
party contributions to the core consistent and maintainable.  I also feel
that additional modules accepted to the core by Python-Labs will be few and
far between.  I would like to know, in a formal manner, that xyz_lib.py will
or will not make it into the core.

The community needs a CPAN like mechanism.  Perhaps ActiveState's
"Repository of our Dreams" will be such a thing.  AMK, in his work on PEPs
229 (DistUtils) and 241 (Package Metadata), takes us in that direction.
Zadka in PEP 206 (Batteries Included) promotes creation of a "fat"
distribution that includes common third party software the core modules and
language conditionally use, and encourages installation using distutils.  I
think it is important to delineate what needs to be distributed this way.  I
also think a mechanism to support this *should* be sanctioned and/or
possibly built by Python-Labs.  This, together with a in/out pronouncement
on suggested/contributed modules will go a long way to encourage the
community to contribute and build upon contributed modules.

Python-Labs wants and needs to build and support a standard Python that runs
on all supported platforms.  Limiting the range of modules in the core
package works towards this goal.  Providing a sanctioned mechanism for
optional third party module/package support/installation works towards
reducing the demand on Python-Labs to include those same modules in the
core, thereby contributing towards this goal.  Finally, to paraphrase Guido
when he said in reference to his personal desire to make an IDE for Python,
the competition reduces the need.   Commercial solutions should be
available.  Multiple options should (as they are now) be available.  In
general, I feel that the durability of third party modules pales in
comparison to the support the core language and modules receive from the
Python-Labs team.  Multiple options smooth out the ups and downs of third
party module reliability.


Emile van Sebille
emile at fenx.com

---------

--

Emile van Sebille
emile at fenx.com

---------
"Carlos Ribeiro" <cribeiro at mail.inet.com.br> wrote in message
news:mailman.994210026.25214.python-list at python.org...
At 17:34 03/07/01 -0500, Emile van Sebille wrote:
>Pythonic Quote of the Week...
>     Quite granted that nobody is forced to use a feature.  But when
>     a language becomes too featureful, people start programming in
>     the subdialect they like best, later creating difficulties to
>     other wanting to read their programs, who might like other parts
>     better.
>
>     One of the reason behind Python legibility success, is that
>     there is almost only one way to do one thing (to contrast with
>     Perl, say).  We are progressively sliding away of this virtue.
>     The danger is real.
>                                   François Pinard
>
>http://groups.google.com/groups?ic=1&q=msgid:mailman.993966362.10675.python
-list at python.org

We've got a very good discussion in the past three days about the current
status of the library. I feel that at least part of the problem pointed out
by François Pinard may be attributed at the lack of some highly needed
modules on the standard library. As people keep reinventing the wheel, we
get two problems:

- Less productivity

- More fragmentation

The solution as proposed by the main python-dev guys - Guido himself and
Tim Peters - is that the community should take the responsibility to keep
the library, as we can see here:

[Guido van Rossum, 2001-06-30 05:53:49 PST]
So let's all do what we do best: the core developers (e.g. PythonLabs)
improve the language, and the community improves the library.

[Tim Peters, Date: 2001-06-30 21:01:05 PST]
A problem is that nobody at PythonLabs has any spare cycles. People can
suggest any number of things we should do for them, but we're already
overloaded -- it simply won't happen.


As it's impossible to clone an army of timbots to solve this problem, we
must try to find another solution. I don't believe that we can sort this
issue without some involvement of PythonLabs and the core Python-dev guys.
The problem is not lack of good modules, but lack of *standard* modules. To
make a module standard, some level of Python-dev commitment is a *must*.

One of things that plugged me on this "Python thing" was the "batteries
included" motto. In fact, the strength of any programming environment can
be measured by the extension and usability of its standard library. That's
where Java is shining today. The investment on the standard library is one
of the surest ways of making Python popular while keeping with the "there's
one way to do it" motto.


Carlos Ribeiro