Try a demo in the source distribution's Demo/ directory and report here if it doesn't work.  Many are unmaintained and should be deleted in favor of examples in the documentation.

Why only Python 3.2, why not python 2.7 ?

There's only so much free time developers can spend on Python.  Also, most demos still work in 2.x, even if they are unmaintained, ugly or demonstrate old concepts.  In contrast, most demos weren't tested after porting to 3.x, so many of them don't even run there (and nobody runs them, otherwise we'd have got at least some reports in the tracker).

While I was checking 2.7, /Demo/scripts, some of the codes followed the most naive approach (unoptimized) like /Demo/scripts/fact.py which calculate factors and /Demo/scripts/prime.py which calculates prime. Shall I write the optimized version(if no-one have issues), or the rudimentary working versions are good as of now ?

Well, these demos are not meant to demonstrate the fastest algorithms, but to demonstrate how easy and readable simple algorithms can be written in Python.

That said, if you can write better versions that are also very readable, they'll make a good addition.

I've started going through the demos. So far I've gone through cgi and classes. If this is what you're looking for I'll try and go through the rest in the next week or so.

Python 3.2a0

/cgi
    all work

/classes
    Complex.py - fail

            1 and Complex(0, 10) -> <class 'TypeError'>
        Traceback (most recent call last):
          File "Complex.py", line 314, in <module>
            test()
          File "Complex.py", line 310, in test
            checkop(*(t+item))
          File "Complex.py", line 235, in checkop
            ok = abs(result - value) <= fuzz
          File "Complex.py", line 184, in __rsub__
            return other - self
          File "Complex.py", line 180, in __sub__
            return Complex(self.re - other.re, self.im - other.im)
        TypeError: unsupported operand type(s) for -: 'type' and 'int'

    Dates.py - fail
     
        Traceback (most recent call last):
          File "Dates.py", line 227, in <module>
            test(1850, 2150)
          File "Dates.py", line 185, in test
            if (not a < b) or a == b or a > b or b != b:
        TypeError: unorderable types: Date() < Date()

    Dbm.py - fail 
        {}
        key: "myKey"
        Traceback (most recent call last):
          File "Dbm.py", line 66, in <module>
            test()
          File "Dbm.py", line 49, in test
            if key in d:
          File "Dbm.py", line 25, in __getitem__
            return eval(self.db[repr(key)])
        KeyError: '0'

    Range.py - fail
        Exception: error in implementation:
        correct   = range(5, 100, 3)
        old-style = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47, 50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]
        generator = [5, 8, 11, 14, 17, 20, 23, 26, 29, 32, 35, 38, 41, 44, 47, 50, 53, 56, 59, 62, 65, 68, 71, 74, 77, 80, 83, 86, 89, 92, 95, 98]

    Rev.py - fail
        1 items had failures:
          10 of  17 in Rev
        ***Test Failed*** 10 failures.

        Looks like mostly invalid print syntax
    
    Vec.py - pass

    bitvec.py - fail
        use of __cmp__()
        use of __*slice__()
        didn't check further

Does “tested” in the title of this issue mean “run” or “unit-tested”?

Regarding the 2.7 branch, is this still relevant?

I'm assuming tested means "run", and that a good demo is one that "works" for some nominal input.

I’m making this a meta-bug to record the evaluation of demos and tools, in followup with the thread “Signs of neglect?” started on http://mail.python.org/pipermail/python-dev/2010-June/101092.html.

Some of them have already been adopted or deleted. Please add yourself to Misc/maintainers.rst when you adopt one.

I also propose adding either a section in the README or a new README.removed file to list the deletions; there are probably people out there using these tools (maybe not demos, though), so it’s more polite to tell them “metaclasses is removed, see this doc for modern built-in metaclasses” than to just remove the file.

Regarding testing, please comment on #9153.

I fixed Dates.py.  See issue9151.

I also committed a minimal fix for Complex.py in r82524.

I fixed Rev.py in r82550, but I don't think it is worth keeping in the current form.  Maybe it can be replaced with a pure python reimplementation of builtins.reversed.

Note that slicing does not work for Rev:


>>> r = Rev([1,2,3])
>>> r[:]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "Demo/classes/Rev.py", line 69, in __getitem__
    return self.forw[-(j + 1)]
TypeError: unsupported operand type(s) for +: 'slice' and 'int'

Fixed Range.py in r82551.

I should note here that I fixed Demo/md5test/md5driver.py in r82351 (py3k) and r82352 (release31-maint).

I wonder if it would be possible as a part of Demo and Tools clean-up to move them into packages under Lib.

I would really like to be able to do

$ python -m demo.turtle

instead of (on a Mac)

$ cd /Applications/Python\ 2.6/Extras/Demo/turtle/
$ python turtleDemo.py

and I still cannot find where Apple decided to put Tools.

"instead of (on a Mac)

$ cd /Applications/Python\ 2.6/Extras/Demo/turtle/
$ python turtleDemo.py

and I still cannot find where Apple decided to put Tools."

This has nothing to do with Apple.  "/Applications/Python x.y" is created by the python.org OS X installer, not supplied by Apple.  See Mac/BuildScript/build-installer.py for the details.  AFAIK, the Tools directory is currently not installed by the OS X installer.  Should it be?

On Mon, Jul 26, 2010 at 11:58 PM, Ned Deily <report@bugs.python.org> wrote:
..
> This has nothing to do with Apple.  "/Applications/Python x.y" is created by the python.org OS X
> installer, not supplied by Apple.  See Mac/BuildScript/build-installer.py for the details.

Does this mean that Apple distributes neither Tools nor Demo?   That
would be another reason to move anything anyone cares about to Lib.

>  AFAIK, the Tools directory is currently not installed by the OS X installer.  Should it be?

Probably not all of it.  Moving to "tools" package would give an
opportunity to select which tools are only of interest to those
working with python source and which are of general utility.

>Does this mean that Apple distributes neither Tools nor Demo?   That
>would be another reason to move anything anyone cares about to Lib.

I believe that neither are included in the Apple-supplied Python in OS X, which resides primarily in /System/Library/Frameworks/Python.framework.

In recent OS releases, Apple seems to have taken their cue from the python.org installer framework layouts but tweaked things somewhat.  Ronald may have more insight and/or an opinion on this.  He's also had some contact with the people inside Apple.

What Apple does and doesn't ship is not important for this discussion.

FWIW: Apple doesn't ship any of the GUI wrappers installed in /Applications, although they seem to ship Applet Builder as part of Developer tools (beets my why the bother).

They don't ship any of the examples or tools, and don't ship documentation as well.

Our OSX installer does install most of these, on the assumption that anything that is part of the source distribution might be of interest for users.

On Tue, Jul 27, 2010 at 1:49 AM, Ronald Oussoren <report@bugs.python.org> wrote:
..
> What Apple does and doesn't ship is not important for this discussion.
>
I agree.  I used Apple as an example because I happened to post from
an Apple laptop.  I am sure it is similarly hard to find demo programs
on every other OS and there is no consistency between different
distributions.

However they do ship Lib/test.  This tells me that they don't try to
prune Lib and I think most distributions similarly ship Lib as is.

> Our OSX installer does install most of these, on the assumption that anything that is part of the
> source distribution might be of interest for users.

Installing some of the tools (and I don't think any demos are
installed that way) next to python executable presents a namespace
problem.  Since tools are not consistently prefixed with 'py', they
may conflict with system or user tools that happen to be in the path.
Support for multiple python versions is also somewhat ad hoc.  For
example, on my system I have 2to3, 2to32.6 and 2to3-3.1.   I do agree
that   2to3-3.1 is an improvement over 2to32.6, but how can I guess
that idle2.6 gets upgraded to idle3.1  rather than idle-3.1?  With -m
approach, all I need to know is how to start python of the desired
version: python, python2.6, or even ./python.exe from the root of the
development tree.

It looks like turtle was not the best example for msg111682 because it is already in Lib and python -m turtle runs demo.  I am not sure what the relationship between Demo/turtle and the turtle module is.

Removed Demo and some of the Tools in a series of commits starting with r87579.