[Python-ideas] Move Demo scripts under Lib

[M.-A. Lemburg]

Alexander Belopolsky wrote:
> I originally proposed this under the Demo and Tools cleanup issue [1].
>   The idea was to create a new package "demo" in the standard library
> which will host selected demo programs or modules that currently
> reside in the Demo/ directory of the source distribution.  There are
> several advantages to this approach:
> 
> 1. Discoverability.  Currently, various distributions place demo
> scripts in different places or not include them at all.   There is no
> easy way for an end user to discover them.  With a demo package, there
> will be a natural place in the python manual to document demo scripts
> and users will be able to run them using -m option.  IDEs will be able
> to present demo source code and documentation consistently.
> 
> 2. Test coverage.  One of the points raised in [1] was that Demo
> scripts are not routinely tested.  While it is not strictly necessary
> to move them under Lib to enable testing, doing so will put these
> scripts on the same footing as the rest of the standard library
> modules eliminating an unnecessary barrier to writing tests.
> 
> 3. Quality/relevance.  Many scripts in Demo are very old and do not
> reflect modern best practices.  By picking and choosing what goes to
> Lib/demo, we can improve the demo collection without removing older
> scripts that some may find useful.
> 
> One objection raised to this idea was that Demo scripts do not have
> the same stability of the API and backward compatibility requirements
> as the rest of the standard library.   I don't think this is a serious
> issue.  As long as we don't start importing demo modules from other
> stdlib modules, there is no impact on the stdlib itself from changing
> demo APIs.  Users may be warned that their production programs should
> not depend on the demo modules.  I think the word "demo" itself
> suggests that.
> 
> What do you think?

Calling a stdlib package "demo" or "example" is not a good idea,
since those are rather common package names in existing
applications.

I also don't really see the point in moving *scripts* to the stdlib.
The lib modules are usually not executable or meant for execution
and you'd normally expect scripts to be under .../bin rather than
.../lib.

Why don't you turn the ones you find useful into PyPI packages
to install separately ?

> [1] http://bugs.python.org/issue7962#msg111677

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Oct 26 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/