Updates were recently released by both the IronPython and Boo projects:
IronPython 0.7.5 was released for .NET 2.0.
* Can't Open 2 or more IronPythonConsoles
* File share error when opening the file for reading multiple times
* Generate assembly in the same directory as the Python source
* Can't OR flags together
- note that to use bitwise operations on enums, the [Flags] attribute
must be set on the enum
* sorted() not implemented
* Failed to sort list with mixed types
* Remove nstr and zip2 from __builtins__
* Can't raise a long to an exponent
* dir and __dict__ malfunction
* Old class cannot be instantiated when passing parameters by name
def __init__(self, height=20, width=30):
self.area = height * width
a = A(width = 2)
* Old style class cannot override __getattr__
* Initialization of the map using lambda is incorrect
* Method lookup broken again
- this was a regression in our dynamic method resolution code
reported by Microsoft Research
* PythonEngine Execute method runs only discreet statements
For the full announcement see:
Boo 0.5.4 was released for .NET 1.1 and Mono.
* explicit interface members: def IDisposable.Dispose():
* char literals: char('f')
* unicode literals in strings: \u0032
* a Set class (Boo.Lang.Useful.Collections.Set)
* Singleton design pattern implementation
* the compiler will now call class provided '==' and '!=' operators;
* the compiler will now look for an implicit conversion operator to
boolean when evaluating the conditions for the if/while/unless
* the version of antlr shipped with boo can now generate boo code.
In other words you can now finally write parsers in your favorite
* 'for' and unpack statements now also work with IEnumerator
allowing fine grained control over iteration
* better support for value typed properties
* extended generator expression syntax
* the 'in' and 'not in' operators will now work with any type that
provides a op_Member and op_NotMember implementation respectively
ANNOUNCING twill v0.7.
twill is a simple Web scripting language built on top of Python and
mechanize. It's designed for automated testing of Web sites, but
it may be useful for anybody who needs to deal with Web sites
(with e.g. logins and cookies) in a non-interactive manner.
twill is a reimplementation of Cory Dodt's PBP.
A twill script looks like this:
# go to the /. login page
# fill in the form
fv 1 unickname test
fv 1 upasswd test
# ok, there's no such account ;). show error HTML.
This is the first public release of twill, version 0.7.
(Tagline: "It seems usable to me, but then I'm its author.")
With this release, I'm looking for general feedback on usability, as
well as suggestions on additional use cases.
Download directly here:
Documentation is online at
twill is implemented in Python and uses pyparsing and mechanize. In
addition to the existing simple command language, twill can easily be
extended with Python. twill also provides a fairly simple and
well-documented wrapper around mechanize.
twill scripts can be recorded with maxq, although scripts may require
some hand tweaking at the moment. See the twill documentation for
I'm pleased to announce release 0.38 of Task Coach. New in this release:
- Simplified Chinese user interface added, thanks to limodou.
- Autosave setting to automatically save after every change (1188194).
- Backup setting to create a backup when opening a Task Coach file.
- Added preference dialog to edit preferences not related to the
- Now using gettext for i18n.
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 is
developed using Python and wxPython. You can download Task Coach from:
A binary installer is available for Windows XP, in addition to the
Note that Task Coach is alpha software, meaning that it is wise to back
up your task file regularly, and especially when upgrading to a new release.
The PyPy 0.6 release
*The PyPy Development Team is happy to announce the first
public release of PyPy after two years of spare-time and
half a year of EU funded development. The 0.6 release
is eminently a preview release.*
What it is and where to start
Getting started: http://codespeak.net/pypy/index.cgi?doc/getting_started.html
PyPy Documentation: http://codespeak.net/pypy/index.cgi?doc
PyPy Homepage: http://codespeak.net/pypy/
PyPy is a MIT-licensed reimplementation of Python written in
Python itself. The long term goals are an implementation that
is flexible and easy to experiment with and retarget to
different platforms (also non-C ones) and such that high
performance can be achieved through high-level implementations
of dynamic optimisation techniques.
The interpreter and object model implementations shipped with 0.6 can
be run on top of CPython and implement the core language features of
Python as of CPython 2.3. PyPy passes around 90% of the Python language
regression tests that do not depend deeply on C-extensions. Some of
that functionality is still made available by PyPy piggy-backing on
the host CPython interpreter. Double interpretation and abstractions
in the code-base make it so that PyPy running on CPython is quite slow
(around 2000x slower than CPython ), this is expected.
This release is intended for people that want to look and get a feel
into what we are doing, playing with interpreter and perusing the
codebase. Possibly to join in the fun and efforts.
Interesting bits and highlights
The release is also a snap-shot of our ongoing efforts towards
low-level translation and experimenting with unique features.
* By default, PyPy is a Python version that works completely with
new-style-classes semantics. However, support for old-style classes
is still available. Implementations, mostly as user-level code, of
their metaclass and instance object are included and can be re-made
the default with the ``--oldstyle`` option.
* In PyPy, bytecode interpretation and object manipulations
are well separated between a bytecode interpreter and an
*object space* which implements operations on objects.
PyPy comes with experimental object spaces augmenting the
standard one through delegation:
* an experimental object space that does extensive tracing of
bytecode and object operations;
* the 'thunk' object space that implements lazy values and a 'become'
operation that can exchange object identities.
These spaces already give a glimpse in the flexibility potential of
PyPy. See demo/fibonacci.py and demo/sharedref.py for examples
about the 'thunk' object space.
* The 0.6 release also contains a snapshot of our translation-efforts
to lower level languages. For that we have developed an
annotator which is capable of infering type information
across our code base. The annotator right now is already
capable of successfully type annotating basically *all* of
PyPy code-base, and is included with 0.6.
* From type annotated code, low-level code needs to be generated.
Backends for various targets (C, LLVM,...) are included; they are
all somehow incomplete and have been and are quite in flux. What is
shipped with 0.6 is able to deal with more or less small/medium examples.
Ongoing work and near term goals
Generating low-level code is the main area we are hammering on in the
next months; our plan is to produce a PyPy version in August/September
that does not need to be interpreted by CPython anymore and will
thus run considerably faster than the 0.6 preview release.
PyPy has been a community effort from the start and it would
not have got that far without the coding and feedback support
from numerous people. Please feel free to give feedback and
contact points: http://codespeak.net/pypy/index.cgi?contact
contributor list: http://codespeak.net/pypy/index.cgi?doc/contributor.html
Armin Rigo, Samuele Pedroni,
Holger Krekel, Christian Tismer,
Carl Friedrich Bolz
PyPy development and activities happen as an open source project
and with the support of a consortium funded by a two year EU IST
research grant. Here is a list of partners of the EU project:
Heinrich-Heine University (Germany), AB Strakt (Sweden)
merlinux GmbH (Germany), tismerysoft GmbH(Germany)
Logilab Paris (France), DFKI GmbH (Germany)
This is a small package that facilitates the unit testing process by
aggregating PyUnit tests and making them easier to call from the
command line and from within other unit tests.
Typical PyUnit tests are written in a 1-1 relationship with the module
they test. Module "foo.py" is typically tested with module
"test_foo.py". In packages with multiple modules it can become
cumbersome to run all of the unit tests from the command line.
One could write an aggregator "test_all.py" module and have it call
into each "test_*.py" module to retrieve a TestCase to assemble a
suite. However, that approach requires 2 modifications each time a
unit test is added (one modification for the test itself, and one
modification in test_all.py).
PyTest can run all of the unit tests in a directory via the command
line by locating all modules that begin with "test_". Reflection is
then used to extract the TestCase class, and a suite is constructed
reflecting all test cases.
Additionally, PyTest can be used programmatically in a test_all.py.
Please see my site for more info:
WeatherNet Observations for station: home
Temperature: 48.60F Pressure: 29.82in;
Dew Point: 46.05F (91%) Wind: 312 at 0 mph
Recorded: 00:04:40 05/21/05 (http://wsdl.wxnet.org/home/binding.wsdl)
PyWeather is a collection of weather related modules that are tested
to work. These modules are capable of performing conversion
calculations for many common meteorological units.
See the following URL for more details:
WeatherNet Observations for station: home
Temperature: 49.50F Pressure: 29.82in;
Dew Point: 46.65F (90%) Wind: 312 at 0 mph
Recorded: 23:25:01 05/20/05 (http://wsdl.wxnet.org/home/binding.wsdl)
I am please to announce the first release of pyglfw, a python binding for GLFW
written as an extension module.
GLFW is simple framework acting like a glue between OpenGL and the system.
The aim of pyglfw is simply for me to get my hands on writing an extension for
Python, so this is quite an alpha code I release. Although it works fine, it
might need some fixing in some areas.
Please have a look at it and feel free to let me know what you think about it.
Here is the hope page of pyglfw : http://www.defuze.org/oss/pyglfw/
This message was sent using IMP, the Internet Messaging Program.
I'm pleased to announce the release of ZODB 3.4 beta 1. This corresponds to
the ZODB that will ship in Zope 2.8b2. You can download a source tarball or
Windows installer from:
Note that there are two Windows installers, for Python 2.3 (2.3.5 is
recommended) and Python 2.4 (2.4.1 is recommended).
ZODB 3.4b1 contains many bugfixes and new features, including:
- savepoint/rollback support, a powerful generalization of
subtransactions allowing to revert to any savepoint'ed state
within a transaction
- auto-synchronization with storages after a transaction commit
or abort, and at the explict start (transaction.begin()) of a
- a way to register callbacks invoked just before a transaction
starts to commit -- see the new transaction.beforeCommitHook()
- a new release of ZConfig
See the news file for details:
Note that ZODB 3.4 does not support any version of Zope 2.6 or 2.7. Current
Zope 2.8 and Zope 3 development use ZODB 3.4. The ZODB 3.3 line is
officially retired (3.3.1 final was the last release in the 3.3 line).
'Dllimporter' is a package to facilitate the import of shared libraries
(aka dlls or extension modules) for Python applications
running from a zip archive or an executable (a frozen application).
The standard Python import mechanism cannot import extension modules
being part of a zip archived or frozen package. 'Dllimporter' overcomes
The package provides a class 'dllimporter' the instances of which implement
Pythons 'importer' protocol (see PEP-0302). These instances are
designed to be used as importers on Pythons 'sys.meta_path' (again
see PEP-0302, for details).