Announcing Design By Contract for Python 1.0 beta 1
Design by Contract is familiar to anyone who has spent time with the
Eiffel programming language. This implementation is a cross between
full Eiffel-style contracts and the doctest module.
Contracts are high-level assertions that are part of the program's
documentation. Modules and classes have invariants, expressions that
must be true at the start and end of every public function or method
call. Methods and functions have pre-conditions, expressions that must
be true on entry; and post-conditions, expressions that must be true
This version supports the full contract feature set:
* pre: expressions in function and method docstrings;
* post: expressions in function and method docstrings;
* inv: expressions in class and module docstrings;
* post: expressions can access __old__ values and the __return__
* pre: expressions are weakened by derived methods; and
* post: and inv: expressions are tightened by derived classes.
<P><A HREF="http://www.wayforward.net/pycontract/">Contract 1.0
Design By Contract for Python. (21-May-03)
SCons is a software construction tool (build tool, or make tool) written
in Python. It is based on the design which won the Software Carpentry
build tool competition in August 2000.
Version 0.14 of SCons has been released and is available for download
from the SCons web site:
Or through the download link at the SCons project page at SourceForge:
RPM and Debian packages and a Win32 installer are all available, in
addition to the traditional .tar.gz and .zip files.
This release most notably adds support for Java builds (javac, javah,
rmic and jar), and adds Autoconf-like functionality for finding #include
files and libraries. It also adds significant performance improvements
over previous versions.
WHAT'S NEW IN THIS RELEASE?
IMPORTANT: Release 0.14 contains the following interface changes:
- Tool specifications no longer take a "platform" argument.
- Emitter functions in Builders are now passed Node objects, not
strings, for all targets and sources.
- New TargetSignatures() and SourceSignatures() functions
have been added to replace SetBuildSignatureType() and
- The Export() function and the exported variables argument of
SConscript() now search for variables using the same rules as
Python: local first, then global.
- The SetJobs() and GetJobs() functions have been deprecated in favor
of using SetOption('num_jobs', num) and GetOption('num_jobs').
- Callable expansions of construction variables in a command line
now take a fourth "for_signature" argument that is set when the
expansion is being called to generate a build signature.
- Construction variables for building a target are now frozen
when the Builder is called; later changes to the Environment
do not necessarily affect how the target is build.
See the release notes for more information about these changes.
This release adds the following features:
- Support for the Java tools javac, javah, rmic and jar has
- A Configure() function has been added that supports a lot
of functionality similar to Autoconf.
- A new PLATFORM construction variable stores a string representing
the platform on which SCons is being run.
- Dependencies may now be specified on in-core Python values.
- Help text can now be sorted arbitrarily.
- New $TARGET and $SOURCE attributes: ".posix" expands to a path name
with forward slashes as separators, even on Win32 systems;
".srcpath" expands to a path to the source of a file in a BuildDir;
".srcdir" expands to a path to the BuildDir itself.
- A new clear() method resets a Node's state for re-use by continuous
integration build interfaces.
- Support for using Ghostscript to convert Postscript to PDF files
has been added.
- A stand-alone "Alias" function has been added.
- Import('*') will now import everything that's been Export()ed.
- New SetOption() and GetOption() functions support setting and
fetching various command-line options within an SConscript file.
- The Tool() function now adds tool names to a $TOOLS variable,
which may be used to examine what tools are available.
- The C preprocessor "#import" statement is now supported.
- Newly-built .dll files can now be registered with the Windows
registry using regsvr32.
- An IDL scanner has been added.
- A builder for Windows type library (.tlb) files from IDL files.
The following fixes have been added:
- Cygwin fixes: Use the .dll extension for shared libraries; don'
use -fPIC when compiling shared libraries; use 'rm' to remove files;
use MSVC '@' syntax for linking long command-lines.
- The SYSTEMROOT environment variable on Win32 systems is now
automatically propagated to the execution ENV environment.
- Remote CVS file names are now checked out using Posix-style path names.
- Trying to expand an out-of-range subscript for a construction
variable like $TARGETS or $SOURCES now interpolates the null string.
- SCons now correctly links or duplicates files in subsidiary
- SCons now reports "Cleaning targets ..." when the -c option is used.
- The "Entering directory" message now quotes the directory name
exactly like Make does.
- Export() now works correctly for local Python variables, and can
accept a dictionary as an argument.
- PDB files now get put in a BuildDir() correctly.
Performance has been improved as follows:
- Unnecessary redundant signature calculations for command lines and
Nodes have been eliminated. Development tests suggest this may
speed up builds up to 30% or more.
Distinctive features of SCons include:
- a global view of all dependencies; no multiple passes to get
everything built properly
- configuration files are Python scripts, allowing the full use of a
real scripting language to solve difficult build problems
- a modular architecture allows the SCons Build Engine to be
embedded in other Python software
- the ability to scan files for implicit dependencies (#include files);
- improved parallel build (-j) support that provides consistent
build speedup regardless of source tree layout
- use of MD5 signatures to decide if a file has really changed; no
need to "touch" files to fool make that something is up-to-date
- easily extensible through user-defined Builder and Scanner objects
- build actions can be Python code, as well as external commands
An scons-users mailing list is available for those interested in getting
started using SCons. You can subscribe at:
Alternatively, we invite you to subscribe to the low-volume
scons-announce mailing list to receive notification when new versions of
SCons become available:
Thanks to Chad Austin, Allen Bierbaum, Steve Christensen, Charles
Crain, Damyan Pepper, Stefan Reichor, Anthony Roach, Greg Spencer, and
Christoph Wiedemann for their contributions to this release. Special
thanks to David Snopek for donating base code for the new Config
functionality that had been originally written under a different
On behalf of the SCons team,
TriZPUG May Meeting: ReportLab - PDF made easy
The Triangle Zope/Python User Group (TriZPUG) will hold its next meeting on
Wednesday, May 28, at 6:30 p.m. in Raleigh, NC. We will be meeting in the
DELTA conference room(s) at Venture III, who has kindly permitted us to use
their meeting room, on NCSU's Centennial Campus. Directions to Venture III
are below. Ian Sparks will be giving a talk on the ReportLab library.
Hope to see you there!
Title: ReportLab - PDF made easy
Reportlab is a python library for the creation of Adobe Portable Document
Format (PDF) documents. This talk introduces the foundation of the library:
the canvas object. We'll start with canvas primitives : drawing, writing
text, importing graphics etc and go on to examine how the canvas exposes
some of PDFs special capabilities. Finally we'll take a look at PLATYPUS
(Page Layout and Typography Using Scripts), a high-level library built on
the canvas which makes creating complex documents a breeze.
Directions to the TriZPUG Meeting:
If you need directions to NCSU's Centennial Campus, try the following link
If you need directions to the Venture III building, follow this link
http://lts.ncsu.edu/about/venture3.html, but skip step #3 since the meeting
is after hours.
For more about TriZPUG:
PIDER is an experimental webcrawler written in python
using urllib2. It uses python's HTMLParser for parsing
PIDER is released under a GNU kind of license. You are
free to download the source, use it and extend it, as
long as you maintain the original copyright.
The program has been tested on Windows NT/Window 2000
on python 2.2.
If you like the program or just plain want to criticise
it, drop a mail. I am always looking forward to improving
my python skills :-)
The 'Python Guy',
EuroPython 2003 is on the way! We have a tremendous selection of over
seventy (!) talks available for you in the three days at EuroPython:
This includes a wide selection of Zope talks across all three days as
well -- so if you are interested in Zope, don't miss the largest Zope
Here is more information about the schedule:
To make sure you are part of this exciting event, register today! The
early bird rate of 200 Euros is available until May 31st -- less than
two weeks from today.
You can review the rates and register here:
Announcing version 5b5 of Installer:
Changes in 5b5:
* Works with Python 2.3
* A --onefile always uses a temporary directory (no conflicts between
* A --onefile cleans up under any but the most extreme circumstances
* reload works properly
* Can UPX your executables (and DLLs on Windows), if installed.
* Improved COM Server support from Mark Hammond.
Unix (relying on volunteers)
Python 1.5 to 2.3
What is it:
The Installer package is any easy way to deploy
Python apps to systems without Python installed
(or with incompatible Pythons installed).
Installer support single-file and single-directory
deployments. On Windows, Installer supports
COM, including in-process COM servers.
Release 5b5/A>Easy Python app deployment. (19-May-
"Write your HDL test benches in Python!"
I am happy to announce the release of MyHDL 0.2, a Python package for
using Python as a hardware description & verification language.
You can find it at http://jandecaluwe.com/Tools/MyHDL/Overview.html.
MyHDL is a Python package for using Python as a hardware description
language. Popular hardware description languages, like Verilog and
VHDL, are compiled languages. Python with MyHDL can be viewed as a
"scripting language" counterpart of such languages. However, Python is
more accurately described as a very high level language (VHLL). MyHDL
users have access to the amazing power and elegance of Python for
their modeling work.
The key idea behind MyHDL is to use Python generators to model the
concurrency required in hardware descriptions. As generators are a
recent Python feature, MyHDL requires Python 2.2.2 or higher.
MyHDL can be used to experiment with high level modeling, and with
verification techniques such as unit testing. The most important
practical application however, is to use it as a hardware verification
language by co-simulation with Verilog and VHDL.
The present release, MyHDL 0.2, enables MyHDL for co-simulation. The
MyHDL side is designed to work with any simulator that has a PLI. For
each simulator, an appropriate PLI module in C needs to be
provided. The release contains such a module for the Icarus Verilog
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium