I'm pleased to annouce the release both a production and
experimental release of GMPY. GMPY is a wrapper for the
MPIR or GMP multiple-precision arithmetic library. GMPY
is available for download from:
GMPY 1.12 is the new stable release. In addition to fixing
a few bugs, GMPY 1.12 adds support for Python 2.7 and the
current py3k development trunk. Even though my primary
development focus has shifted to GMPY2 (see below), GMPY
1.X will continue to receive bug and compatibility fixes.
To simplify the codebase, allow for changes in the API,
and support simultaneous installation, the development
version has been renamed to GMPY2. The following is list
of changes in GMPY2:
* support for a mutable integer type "xmpz"
* removal of random number functions
* "xmpz" supports slices for setting/clearing bits
* some methods have been renamed (scan1 -> bit_scan1)
* support for Python prior to 2.6 has been removed
* support for all division modes has been added
* ceiling - round to +Infinity
* floor - round to -Infinity
* truncate - round to zero
* 2exp - division by a power of 2
* support is_even() and is_odd()
If you use GMPY regularly, please test GMPY2. There have been
several requests asking for a mutable integer and I am curious
if there are real-world performance improvements.
I am looking for feedback on future enhancements. If you have
specific requests, please let me know. Below are some ideas
* An optional "max_bits" parameter for an "xmpz". If
specified, all results would be calculated modulo
* I've added the ability to set/clear bits of an "xmpz"
using slice notation. Should I allow the source to be
arbitrary set of bits or require that all bits are set
to 0 or 1? Should support for "max_bits" be required?
* Improved floating point support.
Comments on provided binaries
The pre-compiled Windows installers use later versions of
GMP and MPIR so performance some operations should be
The 32-bit Windows installers were compiled with MinGW32 using
GMP 5.0.1 and will automatically recognize the CPU type and use
assembly code optimized for the CPU at runtime. The 64-bit
Windows installers were compiled Microsoft's SDK compilers
using MPIR 2.1.1. Detailed instructions are included if you
want to compile your own binary.
Please report any issues!
PyPy 1.3: Stabilization
We're please to announce release of PyPy 1.3. This release has two major
improvements. First of all, we stabilized the JIT compiler since 1.2 release,
answered user issues, fixed bugs, and generally improved speed.
We're also pleased to announce alpha support for loading CPython extension
modules written in C. While the main purpose of this release is increased
stability, this feature is in alpha stage and it is not yet suited for
Highlights of this release
* We introduced support for CPython extension modules written in C. As of now,
this support is in alpha, and it's very unlikely unaltered C extensions will
work out of the box, due to missing functions or refcounting details. The
support is disable by default, so you have to do::
before trying to import any .so file. Also, libraries are source-compatible
and not binary-compatible. That means you need to recompile binaries, using
python setup.py build
Details may vary, depending on your build system. Make sure you include
the above line at the beginning of setup.py or put it in your PYTHONSTARTUP.
This is alpha feature. It'll likely segfault. You have been warned!
* JIT bugfixes. A lot of bugs reported for the JIT have been fixed, and its
stability greatly improved since 1.2 release.
* Various small improvements have been added to the JIT code, as well as a great
speedup of compiling time.
Maciej Fijalkowski, Armin Rigo, Alex Gaynor, Amaury Forgeot d'Arc and
the PyPy team
We have just released a proof-of-concept implementation of a new
approach to thread management - "newthreading". It is available
for download at
The user's guide is at
This is a pure Python implementation of synchronized objects, along
with a set of restrictions which make programs race-condition free,
even without a Global Interpreter Lock. The basic idea is that
classes derived from SynchronizedObject are automatically locked
at entry and unlocked at exit. They're also unlocked when a thread
blocks within the class. So at no time can two threads be active
in such a class at one time.
In addition, only "frozen" objects can be passed in and out of
synchronized objects. (This is somewhat like the multiprocessing
module, where you can only pass objects that can be "pickled".
But it's not as restrictive; multiple threads can access the
same synchronized object, one at a time.
This pure Python implementation is usable, but does not improve
performance. It's a proof of concept implementation so that
programmers can try out synchronized classes and see what it's
like to work within those restrictions.
The semantics of Python don't change for single-thread programs.
But when the program forks off the first new thread, the rules
change, and some of the dynamic features of Python are disabled.
Some of the ideas are borrowed from Java, and some are from
"safethreading". The point is to come up with a set of liveable
restrictions which would allow getting rid of the GIL. This
is becoming essential as Unladen Swallow starts to work and the
number of processors per machine keeps climbing.
This may in time become a Python Enhancement Proposal. We'd like
to get some experience with it first. Try it out and report back.
The SourceForge forum for the project is the best place to report problems.
'tsearchpath' Version 1.108 is now released and available for download at:
What's New In This Release?
This is the initial public release.
A FreeBSD port has also been submitted.
What Is 'tsearchpath'?
'tsearchpath' is a Python module for searching a list of paths for a
particular file system 'filename'. This can be the name of a
directory, file, or any other entity in the file system. This makes
it easy to add things like include- or configuration file paths to
your own programs.
There is no fee for using 'tsearchpath' so long as the licensing terms
found in 'tsearchpath-license.txt' are observed. Please take a moment
to review this document.
Tim Daneliuk tundra(a)tundraware.com
PGP Key: http://www.tundraware.com/PGP/
RedNotebook 1.0 has been released.
You can get the tarball at
For links to distribution packages head to the RedNotebook homepage
What is RedNotebook?
RedNotebook is a **graphical journal** and diary helping you keep track
of notes and thoughts. It includes a calendar navigation, customizable
templates, export functionality and word clouds. You can also format,
tag and search your entries. RedNotebook is available in the
repositories of most common Linux distributions and a Windows installer
* Describe how to add latex math formulas and custom html tags in help
* Fix crash on windows when data and program live on different
drives in portable mode (LP:581646)
* Fix display of italic text in edit mode
* Fix inserting templates on Windows
* New Translations:
I'm happy to announce that a new release of pyparsing is now
version 1.5.3. It has been almost a year and a half since 1.5.2 was
released, but pyparsing has remained pretty stable.
I believe I have cleaned up the botch-job I made in version 1.5.2 of
trying to support both Python 2.x and Python 3.x. This new release
will handle it by:
- providing version-specific binary installers for Windows users
- use version-adaptive code in the source distribution to use the
correct version of pyparsing.py for the current Python distribution
This release also includes a number of small bug-fixes, plus some
interesting new examples.
Here is the high-level summary of what's new in pyparsing 1.5.3:
- ======= NOTE: API CHANGE!!!!!!! ===============
With this release, and henceforward, the pyparsing module is
imported as "pyparsing" on both Python 2.x and Python 3.x versions.
- Fixed up setup.py to auto-detect Python version and install the
correct version of pyparsing - suggested by Alex Martelli,
thanks, Alex! (and my apologies to all those who struggled with
those spurious installation errors caused by my earlier
- Fixed bug on Python3 when using parseFile, getting bytes instead of
a str from the input file.
- Fixed subtle bug in originalTextFor, if followed by
significant whitespace (like a newline) - discovered by
Francis Vidal, thanks!
- Fixed very sneaky bug in Each, in which Optional elements were
not completely recognized as optional - found by Tal Weiss, thanks
for your patience.
- Fixed off-by-1 bug in line() method when the first line of the
input text was an empty line. Thanks to John Krukoff for submitting
- Fixed bug in transformString if grammar contains Group expressions,
thanks to patch submitted by barnabas79, nice work!
- Fixed bug in originalTextFor in which trailing comments or
ignored text got slurped in with the matched expression. Thanks to
michael_ramirez44 on the pyparsing wiki for reporting this just in
time to get into this release!
- Added better support for summing ParseResults, see the new example,
- Added support for composing a Regex using a compiled RE object;
thanks to my new colleague, Mike Thornton!
- In version 1.5.2, I changed the way exceptions are raised in order
to simplify the stacktraces reported during parsing. An anonymous
user posted a bug report on SF that this behavior makes it difficult
to debug some complex parsers, or parsers nested within parsers. In
this release I've added a class attribute
with a default value of False. If you set this to True, pyparsing
report stacktraces using the pre-1.5.2 behavior.
- Some interesting new examples, including a number of parsers related
to parsing C source code:
. pymicko.py, a MicroC compiler submitted by Zarko Zivanov.
(Note: this example is separately licensed under the GPLv3,
and requires Python 2.6 or higher.) Thank you, Zarko!
. oc.py, a subset C parser, using the BNF from the 1996 Obfuscated C
. select_parser.py, a parser for reading SQLite SELECT statements,
as specified at http://www.sqlite.org/lang_select.html; this goes
into much more detail than the simple SQL parser included in
. stateMachine2.py, a modified version of stateMachine.py submitted
by Matt Anderson, that is compatible with Python versions 2.7 and
above - thanks so much, Matt!
. excelExpr.py, a *simplistic* first-cut at a parser for Excel
expressions, which I originally posted on comp.lang.python in
2010; beware, this parser omits many common Excel cases (addition
numbers represented as strings, references to named ranges)
. cpp_enum_parser.py, a nice little parser posted my Mark Tolonen on
comp.lang.python in August, 2009 (redistributed here with Mark's
permission). Thanks a bunch, Mark!
. partial_gene_match.py, a sample I posted to Stackoverflow.com,
implementing a special variation on Literal that does "close"
up to a given number of allowed mismatches. The application was
find matching gene sequences, with allowance for one or two
. tagCapture.py, a sample showing how to use a Forward placeholder
enforce matching of text parsed in a previous expression.
. matchPreviousDemo.py, simple demo showing how the
helper method is used to match a previously parsed token.
Download pyparsing 1.5.3 at http://sourceforge.net/projects/pyparsing/.
can also access pyparsing's epydoc documentation online at
The pyparsing Wiki is at http://pyparsing.wikispaces.com.
Pyparsing is a pure-Python class library for quickly developing
recursive-descent parsers. Parser grammars are assembled directly in
the calling Python code, using classes such as Literal, Word,
OneOrMore, Optional, etc., combined with operators '+', '|', and '^'
for And, MatchFirst, and Or. No separate code-generation or external
files are required. Pyparsing can be used in many cases in place of
regular expressions, with shorter learning curve and greater
readability and maintainability. Pyparsing comes with a number of
parsing examples, including:
- "Hello, World!" (English, Korean, Greek, and Spanish(new))
- chemical formulas
- configuration file parser
- web page URL extractor
- 5-function arithmetic expression parser
- subset of CORBA IDL
- chess portable game notation
- simple SQL parser
- Mozilla calendar file parser
- EBNF parser/compiler
- Python value string parser (lists, dicts, tuples, with nesting)
(safe alternative to eval)
- HTML tag stripper
- S-expression parser
- macro substitution preprocessor
Zope 3.4.1 Released!
June 22, 2010 - The Zope 3 development team announces the Zope 3.4.1 release.
The 3.4.1 is the long awaited next bugfix version of 3.4.0.
- setuptools update to 0.6c11, so that it supports svn 1.6.
- z3c.layer update to 0.2.4, which is a **SECURITY** fix.
For details see the changelog.
Packages and Eggs
Zope 3 is now fully converted to an egg-based system. While some work still
remains, it integrates very well with the rest of the Python community. The
conversion to egg-based packaging also enables other Python developers to only
have to use small bits and pieces of the complete Zope software system. The
conversion means that Zope 3 developers do not use the classic Zope 3 tar-ball
release anymore. However, for your convenience, Zope 3 developers will provide
the classic Zope 3 tar ball releases for at least the 3.4 series.
So how are Zope 3 applications built using only eggs?
The Known Good Set (KGS)
The known good set -- or in short KGS -- is a configuration of packages and
their versions that are known to work well together. The compatibility is
frequently verified by running over twelve thousand tests on a daily
basis _. The KGS is tested against Python 2.4 and 2.5 on the 32- and 64-bit
platforms. The list of controlled packages and their versions for Zope 3.4 can
be found at the Zope 3 KGS site _.
The KGS can be used in several ways _. The most common way is to "nail" the
versions by downloading the version configuration file _ and insert them as
follows in your buildout configuration::
versions = versions
zope.interface = 3.4.0
``zopeproject`` Project Builder
To start building a project using a common setup, a package called
`zopeproject` can be used to quickly setup the boilerplate for the
project. Ample documentation is provided at the `zopeproject` home page
_. `zopeproject` uses Paste or ZDaemon to create a working server. The
following commands get you started::
$ easy_install zopeproject
$ zopeproject HelloWorld
$ cd HelloWorld
$ bin/helloworld-ctl foreground
At this point, there is no demo package demonstrating a simple Zope 3
application setup. However, the ``z3c.formdemo`` package can be used as a
fairly minimal setup. To get started with it, enter the following::
$ svn co svn://svn.zope.org/repos/main/z3c.formdemo/tags/1.5.3 formdemo
$ cd formdemo
$ python bootstrap.py
$ ./bin/buildout -v
$ ./bin/demo fg
..  http://zope3.pov.lt/buildbot
..  http://download.zope.org/zope3.4/3.4.1/controlled-packages.cfg
..  http://download.zope.org/zope3.4/intro.html
..  http://download.zope.org/zope3.4/3.4.1/versions.cfg
..  http://pypi.python.org/pypi/zopeproject
- Zope 3.4 KGS:
- Zope 3.4 Controlled Packages:
- Zope 3.4 Versions:
- The classic Zope 3 source release will be made only on request.
- The Windows .exe installer will be made only on request.
Installation instructions for both Windows and Un*x/Linux are now available in
the top level `README.txt` file of the distribution. The binary installer is
recommended for Windows.
Zope 3.4 requires Python 2.4 or 2.5 to run. You must also have zlib installed
on your system.
- Zope 3 Development Web Site:
- Zope 3 Developers Mailing List:
- Zope 3 Users Mailing List:
- Bug tracker at launchpad:
- IRC Channel:
#zope3-dev at irc.freenode.net
About Zope 3
Zope 3 is a web application server that continues to build on the heritage of
Zope. It was rewritten from scratch based on the latest software design
patterns and the experiences of Zope 2.
The component architecture is the very core of Zope 3 that allows developers to
create flexible and powerful web applications.
Compatibility with Zope 2
Zope 3 is not upwards compatible with Zope 2. This means you cannot run Zope 2
applications in Zope 3.
We continue to work on the transition from Zope 2 to Zope 3 by making Zope 2
use more and more of the Zope 3 infrastructure. This means that new code
written in Zope 2 can benefit from Zope 3 technology. Also, with care, code
can be written that works in both Zope 3 and Zope 2. This allows a Zope 2
application to slowly evolve towards Zope 3. Unchanged Zope 2 applications
are never expected to work in Zope 3, however.
About the Zope Foundation
The Zope Foundation, based in Fredricksburg, Virginia, is a not-for-profit
organisation that provides support for the Zope community and the Zope
platform and its associated software. Its community includes the open source
community of contributers as well as the community of businesses and
organizations that use Zope.
sorry for choosing this forum for a regional announcement - just hoping to
attract some local users who don't read the local mailing list.
After a while of silence, there will be a meeting of the µPy (Münchner
Python User Group) this thursday (June 24th).
See here for further information:
William Stein, Fernando Perez, and I are founding a non-profit
foundation for mathematical and scientific research computing. Our
purpose is to ensure unrestricted access to the best computational
tools for research and education in mathematics, science, and
engineering. Our aim is to do this primarily by fostering existing
efforts and communities. The foundation will initially focus on
Python, rather than other languages for scientific computing such as R
or Scilab. Despite this initial focus on Python, the foundation's
mission will not be merely to promote the use of Python in science.
Please join us for our first event on June 25th at the Mathematical
Sciences Research Institute (MSRI) in Berkeley, CA. The workshop is
free and lunch is provided. In order to make sure that we have enough
food, we are requiring anyone who wants to attend to RSVP by the end
of the day Wednesday, June 23rd by sending an email to
For more details, please see: