/\/\ ___ (_)_ __ /\/\ ___ (_)_ __
/ \ / _ \| | '_ \ / \ / _ \| | '_ \ __
/ /\/\ \ (_) | | | | / /\/\ \ (_) | | | | | /| _)
\/ \/\___/|_|_| |_\/ \/\___/|_|_| |_| |.__)
MoinMoin 1.3.2 advanced wiki engine released
MoinMoin is an easy to use, full-featured and extensible wiki software
package written in Python. It can fulfill a wide range of roles, such as
a personal notes organizer deployed on a laptop or home web server,
a company knowledge base deployed on an intranet, or an Internet server
open to individuals sharing the same interests, goals or projects.
A wiki is a collaborative hypertext environment with an emphasis
on easy manipulation of information.
MoinMoin 1.3.2 is a maintenance release that fixes several bugs and
introduces some new features. See below. Upgrading is recommended
for all users. - http://moinmoin.wikiwikiweb.de/MoinMoinDownload
Major bugs that were fixed
* Changing a group page is not respected by the wiki while
checking the permissions (bug in wikidicts).
* Slow (compared to 1.2) when running with persistent servers.
* Does not support configurations with no underlay directory.
* Failure in the BadContent code could lead to a uneditable wiki,
when moinmaster site was down.
* Problems on Python 2.2.x (x >= 2).
* Using gdchart for charts might lead to an instability.
* Fixed non-ASCII page names for Apache 2 on Windows.
* Better ReStructuredText support is built-in now. See HelpOnParsers.
* Create new pages easily using configurable interface and page templates
with the new NewPage macro.
For a more detailed list of changes, see the CHANGES file in the
distribution or http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.3/CHANGES
Major new features in 1.3
* MoinMoin speaks your language! Complete Unicode support,
translated system and help pages in more than ten languages, and
support for languages written from right to left are the base features
of our internationalisation support.
* Fresh look and feel. New default user interface design, improved
existing themes and enhanced theme plug-in framework that make it
easier to modify the design or create completely new user interface.
* Find anything on your wiki, instantly. New search engine and
streamlined Google-like search interface, using multiple search
terms, regular expressions, search term modifiers and boolean search.
* Antispam - keep spammers out of you wiki. Protect your wiki with
automatically updated spam patterns maintained on the MoinMaster
wiki, and shared by all MoinMoin wikis worlwide.
* Underlay directory - easy upgrade and maintenance. New streamlined
directory layout protects all system and help pages in a separate
* Run with your favorite server. Use either a standalone server that
requires only Python, the high performance Twisted server, Apache with
Fast CGI, mod_python or plain CGI.
* Multiconfig - easier, more powerful configuration. New class-based
configuration allow you to easily configure single or multiple
wikis sharing a common setup.
MoinMoin has been around since year 2000. Most of the codebase was
written by Jürgen Hermann; it is currently being developed by a growing
team. Being originally based on PikiPiki, it has evolved heavily since then
(PikiPiki and MoinMoin 0.1 consisted of just one file!). Many large
enterprises have been using MoinMoin as a key tool of their intranet, some
even use it for their public web page. A large number of Open Source
projects use MoinMoin for communication and documentation. Of course there
is also a large number of private installations.
* Project site: http://moinmoin.wikiwikiweb.de/
* Feature list: http://moinmoin.wikiwikiweb.de/MoinMoinFeatures
* Download: http://moinmoin.wikiwikiweb.de/MoinMoinDownload
* This software is available under the GNU General Public License v2.
* Changes: http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.3/CHANGES
* Upgrade: http://moinmoin.wikiwikiweb.de/HelpOnUpdating
* Known bugs:
sent by Alexander Schremmer for the MoinMoin team
Dear Python Colleague:
The PyCon Program Committee is happy to announce that
the opening keynote speech, at 9:30 am on Wednesday
March 23 will be:
Python on the .NET Platform, by
Jim Hugunin, Microsoft Corporation
Jim Hugunin is well-known in the Python world for his
pioneering work on JPython (now Jython), and more
recently for the IronPython .NET implementation of
Jim joined Microsoft's Common Language Runtime team
in August last year to continue his work on Iron Python
and further improve the CLR's support for dynamic
languages like Python.
I look forward to hearing what Jim has to say, and
hope that you will join me and the rest of the Python
community at PyCon DC 2005, at George Washington
University from March 23-25, with a four-day sprint
starting on Saturday March 19.
Early bird registration rates are still available for
a few more days. Go to
for the current schedule, and register at
Chairman, PyCON DC 2005
PyCon DC 2005: The third Python Community Conference
The scoop on Python implementations and applications
This is a summary of traffic on the `python-dev mailing list`_ from December
01, 2004 through December 15, 2004. It is intended to inform the wider Python
community of on-going developments on the list. To comment on anything
mentioned here, just post to `comp.lang.python`_ (or email
python-list(a)python.org which is a gateway to the newsgroup) with a subject line
mentioning what you are discussing. All python-dev members are interested in
seeing ideas discussed by the community, so don't hesitate to take a stance on
something. And if all of this really interests you then get involved and join
This is the fifty-fourth summary written by Brett Cannon (amazed no one has
complained about the lateness of these summaries!).
To contact me, please send email to brett at python.org ; I do not have the
time to keep up on comp.lang.python and thus do not always catch follow-ups
All summaries are archived at http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText_ which can be
found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is
probably markup for reST_ (otherwise it is probably regular expression syntax
or a typo =); you can safely ignore it, although I suggest learning reST; it's
simple and is accepted for `PEP markup`_ and gives some perks for the HTML
output. Also, because of the wonders of programs that like to reformat text, I
cannot guarantee you will be able to run the text version of this summary
through Docutils_ as-is unless it is from the `original text file`_.
.. _PEP Markup: http://www.python.org/peps/pep-0012.html
The in-development version of the documentation for Python can be found at
http://www.python.org/dev/doc/devel/ and should be used when looking up any
documentation on new code; otherwise use the current documentation as found at
http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at
http://www.python.org/peps/ . To view files in the Python CVS online, go to
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and
suggested patches can be found at the SourceForge_ project page.
The `Python Software Foundation`_ is the non-profit organization that holds the
intellectual property for Python. It also tries to forward the development and
use of Python. But the PSF_ cannot do this without donations. You can make a
donation at http://python.org/psf/donations.html . Every penny helps so even a
small donation (you can donate through PayPal or by check) helps.
.. _python-dev: http://www.python.org/dev/
.. _SourceForge: http://sourceforge.net/tracker/?group_id=5470
.. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev
.. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python
.. _Docutils: http://docutils.sf.net/
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _Python Software Foundation: http://python.org/psf/
.. _last summary: http://www.python.org/dev/summary/2004-11-16_2004-11-30.html
.. _original text file: http://www.python.org/dev/summary/2004-12-01_2004-12-15.ht
PyCon_ 2005 planning is well underway. The schedule has been posted at
http://www.python.org/pycon/2005/schedule.html and looks great with a quite the
varied topics. And there is still time for the early-bird registration price
of $175 ($125 students) before it expires on January 28th.
Some day I will be all caught up with the Summaries...
.. _PyCon: http://www.pycon.org
PEPS: those existing and gestating
[for emails on PEP updates, subscribe to python-checkins_ and choose the 'PEP'
A proto-PEP covering the __source__ proposal from the `last summary`_ has been
posted to python-dev.
`PEP 338`_ proposes how to modify the '-m' modifier so as to be able to execute
modules contained within packages.
.. _python-checkins: http://mail.python.org/mailman/listinfo/python-checkins
.. _PEP 338: http://www.python.org/peps/pep-0338.html
- `PEP: __source__ proposal
- `PEP 338: Executing modules inside packages with '-m'
The xmllib module was deprecated but not listed in `PEP 4`_. What does one do?
Well, this led to a long discussion on how to handle module deprecation.
With the 'warning' module now in existence, PEP 4 seemed to be less important.
It was generally agreed that listing modules in PEP 4 was no longer needed.
It was also agreed that deleting deprecated modules was not needed; it breaks
code and disk space is cheap.
It seems that no longer listing documentation and adding a deprecation warning
is what is needed to properly deprecate a module. By no longer listing
documentation new programmers will not use the code since they won't know about
it. And adding the warning will let old users know that they should be using
.. _PEP 4: http://www.python.org/peps/pep-0004.html
- `Deprecated xmllib module
- `Rewriting PEP4
PR to fight the idea that Python is "slow"
An article_ in ACM TechNews that covered 2.4 had several mentions that Python
was "slow" while justifying the slowness (whether it be flexibility or being
fast enough). Guido (rightfully) didn't love all of the "slow" mentions which
I am sure we have all heard at some point or another.
The suggestions started to pour in on how to combat this. The initial one was
to have a native compiler. The thinking was that if we compiled to a native
executable that people psychologically would stop the association of Python
being interpreted which is supposed to be slow. Some people didn't love this
idea since a native compiler is not an easy thing. Others suggested including
Pyrex with CPython, but didn't catch on (maintenance issue plus one might say
Pyrex is not the most Pythonic solution). This didn't get anywhere in the end
beyond the idea of a SIG about the various bundling tools (py2app, py2exe, etc.).
The other idea was to just stop worrying about speed and move on stomping out
bugs and making Python functionally more useful. With modules in the stdlib
being rewritten in C for performance reasons it was suggested we are putting
out the perception that performance is important to us. Several other people
also suggested that we just not mention speed as a big deal in release notes
This also tied into the idea that managers don't worry too much about speed as
much as being able to hire a bunch of Python programmers. This led to the
suggestion of also emphasizing that Python is very easy to learn and thus is a
moot point. There are a good number of Python programmers, though; Stephan
Deibel had some rough calculations that put the number at about 750K Python
developers worldwide (give or take; rough middle point of two different
.. _article: http://gcn.com/vol1_no1/daily-updates/28026-1.html
- `2.4 news reaches interesting places
- MS VC compiler versions
- Any reason why CPPFLAGS not used in compiling?
Extension modules now compile with directories specified in the LDFLAGS
and CPPFLAGS env vars
- adding key argument to min and max
min and max now have a 'key' argument like list.sort
- Unicode in doctests
- SRE bug and notifications
- PyInt_FromLong returning NULL
- PyOS_InputHook enhancement proposal
- The other Py2.4 issue
- MinGW And The other Py2.4 issue
- Supporting Third Party Modules
- Python in education
effbot.org proudly presents release 0.9.8 of the cElementTree library,
a fast and very efficient implementation of the ElementTree API, for
Python 2.1 and later. On typical documents, it's 15-20 times faster
than the Python version of ElementTree, and uses 2-5 times less
This release includes a new "iterparse" mechanism, which can be
used to process the tree as it is being built. While not quite as
fast as a full parse, it's over 4 times faster than Python's standard
SAX interface, and even a bit faster than sgmlop.
The library is available as C source code, and as Windows installers
for all recent Python versions. Get your copy here:
The cElementTree module uses some support functions from the standard
ElementTree library, and will not work properly without it. If you
haven't installed it already, you can get it from:
this is to let you know about a new release of eric3, the Python IDE. It
has a bunch of new functions. The most prominent ones are listed below.
- added some dialog wrappers that make eric3 use KDE dialogs, if KDE and
PyKDE are installed
- added a previewer for UI files
- added a previewer for translation files
- added a "Continue to cursor" command to the debugger
- added view profiles and a correspondig configuration dialog
- added capability to show the coverage annotations in the editor
- added capability to select the protocol of the VCS server at login time
- added support for alternative keyboard shortcuts
- changed variables viewer to keep the state of the tree while debugging
- added multiple selection capabilities to the browsers
- added capability to enter variables filter patterns to the variables
- added an icon previewer to the configuration dialog icons page
and some more little things.
It is available via http://www.die-offenbachs.de/detlev/eric3.html
I hope you enjoy it.
What is eric3
eric3 is Python IDE written using the PyQt wrappers. If the PyKDE
wrappers are installed as well, it will work as a KDE application and
use KDE dialogs. It has a built in debugger, profiler, help viewer,
unlimited number of editors with syntax highlighting, autocompletion and
many more. Eric3 interfaces to CVS and subversion and has a built in
documentation generation facility. For all the other details and
snapshots please see the above URL.
I am pleased to announce release 0.19 of Task Coach. New in this release:
- A list view of effort spent on tasks.
- Effort spent on tasks can now also (besides by using the start and
stop buttons) be entered and edited manually. This is convenient if you
want to enter (or change) time spent after the fact.
If you are able to run Task Coach on other platforms than Windows XP
(home or pro) I'd appreciate a note. If you run into problems, please
mail me as well. In the latter case, please include all platform
details, Python version and wxPython version, and of course a detailed
description of the problem.
What is Task coach?
Task Coach is a simple task manager that allows for hierarchical
tasks, i.e. tasks in tasks. Task Coach is open source (GPL) and uses
wxPython. You can download Task Coach from:
A binary installer is available for Windows XP, in addition to the
source distribution. If you use the source distribution you need Python
version 2.3 or higher and wxPython version 126.96.36.199 or higher.
Changes in this release:
* Removed some cruft code, apparently leading to a huge speedup
in bindery and pushbind
* binderytools.pushdom now returns elements rather than subtree
* Added ns:* form of match to patterns support
* Added many docstrings
* More demos and tests
* Bug fixes
The code sample from the last announcement is now simplified. The
complete Amara 0.9.3 code for iterating through address labels in an XML
document, generally not using more memory to process 10,000 labels than
from amara import binderytools
for label in binderytools.pushbind('/labels/label',
print label.name, 'of', label.address.city
Amara XML Toolkit is a collection of Python tools for XML processing--
not just tools that happen to be written in Python, but tools built from
the ground up to use Python idioms and take advantage of the many
advantages of Python.
Amara builds on 4Suite [http://4Suite.org], but whereas 4Suite focuses
more on literal implementation of XML standards in Python, Amara
focuses on Pythonic idiom. It provides tools you can trust to conform
with XML standards without losing the familiar Python feel.
The components of Amara are:
* Bindery: data binding tool (fancy way of saying: a very Pythonic XML
* Scimitar: implementation of the ISO Schematron schema language for
converts Schematron files to Python scripts
* domtools: set of tools to augment Python DOMs
* saxtools: set of tools to make SAX easier to use in Python
* Flextyper: user-defined datatypes in Python for XML processing
There's a lot in Amara, but here are highlights:
Amara Bindery: XML as easy as py
Based on the retired project Anobind, but updated to use SAX rather than
to create bindings. Bindery reads an XML document and returns a data
structure of Python objects corresponding to the vocabulary used in the
XML document, for maximum clarity.
Bindery turns the document
<python spam="eggs">What do you mean "bleh"</python>
<python ministry="abuse">But I was looking for argument</python>
Into a set of objects such that you can write
In order to get the value "eggs" or
In order to get the value "But I was looking for argument".
There are other such tools for Python, and what makes Anobind unique is
that it's driven by a very declarative rules-based system for binding
XML to the Python data. You can register rules that are triggered by
XPattern expressions specialized binding behavior. It includes XPath
support and supports mutation. Bindery is very efficient, using SAX
to generate bindings.
Scimitar: exceptional schema language for an exceptional programming
Merged in from a separate project, Scimitar is an implementation of ISO
Schematron that compiles a Schematron schema into a Python validator
You typically use scimitar in two phases. Say you have a schematron
schema schema1.stron and you want to validate multiple XML files
against it, instance1.xml, instance2.xml, instance3.xml.
First you run schema1.stron through the scimitar compiler script,
A file, schema1.py is generated and can be used to validate XML
python schema1.py instance1.xml
Which emits a validation report.
Amara DOM Tools: giving DOM a more Pythonic face
DOM came from the Java world, hardly the most Pythonic API possible.
Some DOM-like implementations such as 4Suite's Domlettes mix in some
Pythonic idiom. Amara DOM Tools goes even further.
Amara DOM Tools feature pushdom, similar to xml.dom.pulldom, but
easier to use. It also includes Python generator-based tools for
DOM processing, and a function to return an XPath location for
any DOM node.
Amara SAX Tools: SAX without the brain explosion
Tenorsax (amara.saxtools.tenorsax) is a framework for "linerarizing" SAX
so that it flows more naturally, and needs a lot less state machine
Amara is open source, provided under the 4Suite variant of the Apache
license. See the file COPYING for details.
Amara requires Python 2.3 or more recent and 4Suite 1.0a4 or more
recent. Make sure these are installed, unpack Amara to a convenient
location and run
python setup.py install
Uche Ogbuji Fourthought, Inc.
Use CSS to display XML - http://www.ibm.com/developerworks/edu/x-dw-x-xmlcss-i.html
Introducing the Amara XML Toolkit - http://www.xml.com/pub/a/2005/01/19/amara.html
Be humble, not imperial (in design) - http://www.adtmag.com/article.asp?id=10286
UBL 1.0 - http://www-106.ibm.com/developerworks/xml/library/x-think28.html
Manage XML collections with XAPI - http://www-106.ibm.com/developerworks/xml/library/x-xapi.html
Default and error handling in XSLT lookup tables - http://www.ibm.com/developerworks/xml/library/x-tiplook.html
The wxBrowser (and wxwML) can be used to create web based applications
using wxWidgets GUI objects and wxPython instead of a browser and
The wxBrowser reads wxwML from a web server and translates it into
(wx)python code during run time. All GUI Events are bound to URLs
instead of functions defined in the application. In case an event is
triggered the wxBrowser requests a new document using the URL and,
expecting wxwML back, translates and executes it within a try/except
block, ignoring errors.
The wxBrowser is very work in progress, there's still lots of things to
be done but this version is complete enough to convey the idea.
You can download the python source from SourceForge
and there's a sample application at http://www.pulp.se/wx/contacts that
you can use to test it.
For more info, see: http://sourceforge.net/projects/serf and
PyComicsViewer-0.9.0 has been released.
What is PyComicsViewer?
Is a comics viewer written in python, PyGTK and PIL. I made it as I
didn't fully like any of the existing viewers and I wanted something
that works the same (nice) way on both Linux and Windows.
Because of the way it was implemented, you can also use it like a kind
of image browser/viewer, but this is not its primary destination.
Browsing images from uncompressed directories is provided because
resulted naturally from the implementation and because I've seen some
people that distribute their scaned comics uncompressed.
Changes in 0.9.0 (2005/01/21)
* treat the argument from the command line as a comics it has
to open on initial start-up
* make the PyComicsViewer.py search its glade template in the
same folder it is stored
* save and restore the usage of PIL at app's stop and restart
* added some custom icons for the menu and toolbar
Changes in 0.8.0 (2005/01/17)
* corrected some keyboard bugs
* use only one glade template for all dialogs and windows
* use only one open dialog that can open both files and folders
* added a refresh button to reload the current archive
* code clean-ups
PyComicsViewer is released under the GPL.
Where can I get it?
You can download it from: