decompyle -- A Python byte-code decompiler
version 2.2 beta 1
'decompyle' converts Python byte-code back into equivalent Python
source. It accepts byte-code from any Python version starting with 1.5
up to 2.2.
The generated source is very readable: docstrings, lists, tuples and
hashes get pretty-printed.
'decompyle' may also verify the equivalence of the generated source by
by compiling it and comparing both byte-codes.
Since Release 0.6.0:
* Now decompyles byte-code from Python versions 1.5 up to 2.2
* Now requires Python 2.2 but is able to decompyle older byte-coe,
too. Prior version of decompyle had to be run with the Python
version which generated the byte-code.
* pretty-prints docstrings, hashes, lists and tuples
* decompyle is now a script and a package
* Now adds an emacs mode-hint and tab-width to the output files
* enhanced test suite: more test patterns, .pyc/.pyo included
* avoids unnecessary 'global' statements
* many internal changes and code overhouls
Please refere to the file 'CHANGES' for a list of changes in this
Where to get it?
The source archives and instructions for isntalling the package can be
Simple Help Needed!
Please help testing 'decompyle'!
The EXTENDED_ARG token is untested (this is a new token for Python 2.0
which is used only if many items exist within a code object). If you
have byte-code which does or may include this token, please try to
decompyle your application.
It's easy: the script 'test_pythonlib' which is included in the source
distribution does the job for you. Just read the simple
'decompyle' requires Python 2.2 or later.
* The EXTENDED_ARG token is untested (this is a new token for Python
2.0 which is used only if many items exist within a code object).
* Byte-code generated by Python 2.2 differs byte-code generated by a
prior version even for the same source. This is due the intruduction
of iterators. Currently 'Decompyle' fails verifying the source if
the byte-code was generated by an older version of Python.
* Verifying decompyled source with optizimzed byte code (.pyo) when
running without optimizations (option '-O' not given) fails in most
cases. Same is true for vis-a-versa. This is due to the fact that
Python generated different bytecode depending on option '-O'.
| hartmut Goebel | hartmut(a)goebel.noris.de // |
| Software Manufactur | \X/ |
Announcing the creation of a mailing list for Vancouver Python Zope User
Group (VanPyZ) with thanks to Chris Abraham.
Mailing list: http://lists.zpug.org/mailman/listinfo/vanpyz
Web site (temporary): http://vanpyz.agmweb.ca
Further discussion about when, where and what will be on the list.
Thanks to everyone who attended, it was good to see so many local Python and
Version 0.05 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 files.
WHAT'S NEW IN THIS RELEASE?
Version 0.05 of SCons adds the following features:
- A library can be specified as a $SOURCES file, not just in the LIBS
- Scanners can now return a list of strings.
- .sconsign files are first written to a temporary file and renamed.
- The list of variables exported to an SConscript file may now be
a UserList, too.
- Preliminary support for Unicode strings has been added.
- The -q option has been added.
- The -u option has been added.
- SCons now scans files with .cc and .hh suffixes for #include lines.
- A Builder's Action may now be a Python code object that *returns* a
command line to be executed.
The following fixes have been added:
- PROGSUFFIX is now set to .exe under Cygwin.
- Work around for a bug in os.path.normpath() returning '' for './'
on WIN32 systems.
- White space in a PREFIX or SUFFIX creates separate command-line
arguments as appropriate.
- Fetching MicroSoft DevStudio information from the Windows
registry has been fixed and made more robust.
- sys.stdout is now flushed after print so it intermixes correctly
with sys.stderr output.
- Scanned dependencies are now relative to the directory of the file
- All of the directories for a list of targets are created before
trying to build any of the targets.
- Ignore() now ignores both indirect (scanned) and direct dependencies
- The -c option no longer stops if a target doesn't exist to be removed.
- The --debug=pdb option now works on WIN32 systems.
- The scons script now returns an error code on build failures.
Performance has been improved as follows:
- #include lines from a file are now cached once.
- Dependencies are now scanned only once per file when walking the
The documentation has been improved:
- Writing your own Scanners is now documented.
- The LIBPATH construction variable is now documented.
- The man page is now included in the Debian distribution.
- HTML documents are cleaned up by running them through tidy.
WHAT IS SCONS?
SCons is a software construction tool (build tool, make tool) written
in Python. Its design is based on the design which won the Software
Carpentry build tool competition in August 2000 (in turn derived from
the Perl-based Cons build tool).
Distinctive features of SCons include:
- configuration files are Python scripts, allowing the full use of a
real scripting language to solve build problems
- a modular architecture allows the SCons Build Engine to be
embedded in other Python software
- a global view of all dependencies; no multiple passes to get
- the ability to scan files for implicit dependencies (#include files);
- improved parallel build (-j) support
- use of MD5 signatures to decide if a file has changed
- easily extensible through user-defined Builder and Scanner objects
An scons-users mailing list has been created 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:
Special thanks to Chad Austin, Charles Crain, Steve Leblanc, and Anthony
Roach for their contributions to this release.
On behalf of the SCons team,
Article submission deadline for the 2nd issue of Py is April 30, 2002.
Issue 01.02 should ship the first week of June 2002 provided all goes
well. All submissions are welcome and encouraged. View the full
guidelines at http://www.pyzine.com/write.phtml.
Reminder: Submission deadline for articles to receive consideration
for inclusion in the 1st issue is February 28, 2002. Articles
received prior to the deadline but do not make the cut (due in large
part to space considerations) will be considered for future issues.
Py 01.01 ships the first week of April 2002.
Thanks to everyone for their suggestions and submissions thus far.
For the uninitiated: Py is a print zine for Python developers. You
can learn more at www.pyzine.com.
Questions? Contact cook(a)pyzine.com
Py: the Journal of the Python Language Bryan "cook" Richard
We've just released Wing IDE Standard (aka Wing IDE) version 1.1.2.
This is a bug fix release that solves problems seen by some users.
It also adds support for Zope 2.5.0.
A detailed list of changes made to Wing IDE is here:
Download the update: http://wingide.com/support/downloads
Get a demo license: http://wingide.com/wingide/demo
The Zope 2.5.0 patch, Zope 2.5.0 + Wing IDE 1.1.2 for Linux, and
the Zope 2.5.0 Debug Server for Wing IDE are all available now
from the Zope Support section of the above downloads link.
We are working on support for the unpatched Zope distribution, so
that Wing IDE users can upgrade to new versions of Zope immediately
as they appear. So with some luck, this is our last upgrade to
Zope-specific support that depends directly on the Zope version.
Wing IDE for Python Archaeopteryx Software, Inc
www.wingide.com Take Flight!
I'm pleased to announce the first release of Wing IDE Lite!
Wing IDE Lite offers a generous subset of the features of Wing IDE at a
price accessible to non-commercial users such as hobbyists, students,
educators, and non-profit organizations.
* The source code browser, some of the debugger tools, and several
other features are omitted from this product. Detailed feature
lists are at http://wingide.com/wingide/features.
* Projects are limited to 100 files in size.
* Cost is $35 US on all platforms
Try the demo: http://wingide.com/wingide/demo
Or purchase: http://wingide.com/order
A discounted version of Wing IDE Standard Edition is still available
for students and educators that require the full Wing IDE feature
set for their work.
Please send questions and comments to info(a)wingide.com.
Wing IDE for Python Archaeopteryx Software, Inc
www.wingide.com Take Flight!
Grouch is a system for describing and enforcing a Python object schema.
That is, it provides you with a language for describing the intended
type signatures of your objects (collectively, the "object schema"), and
tools to walk an object graph, checking that every value found matches
your object schema.
In a nutshell, Grouch is an after-the-fact type checker for Python
CHANGES IN THIS RELEASE
* Fix for Python 2.2: define our own set of names for the standard
Python types, so that an object schema that worked with Python 2.1
will continue to work with Python 2.2 (and vice-versa).
* Radically simplified how Grouch objects are pickled and unpickled;
the excessively complicated design in Grouch 0.1 was broken by
design and only worked in Python 2.1 because of pure blind luck.
(The change in dictionary order in Python 2.2 revealed its
* Fix for Python 2.2: use vars() instead of dir() to get an object's
* Fixed a subtle problem in union types that masked certain type
errors: eg. if a variable x is declared to be of type "Foo|Bar"
(instance of Foo or instance of Bar), and x is set to a Foo instance
with a type problem of its own (say, missing attribute a), Grouch
turned the "x is a Foo instance with attribute a missing" into "x is
not a valid Foo instance", which meant that "x is neither a Foo nor
a Bar". Unfortunately, the new logic means that unions like
"[int] | [string]" won't work, until I have a better understanding
of what's going on here. Type systems are tricky.
Grouch requires Python 2.0 or greater, with Jeremy Hylton's "compiler"
package installed. At least in Python 2.0 .. 2.1.2, this package is
included in Python's source distribution, but not installed as part of
the standard library.
AUTHOR, COPYRIGHT, LICENSE, AVAILABILITY
Grouch was written by Greg Ward <gward(a)mems-exchange.org>. Includes
code (lib/spark.py) written by John Aycock, which is licensed
Copyright (c) 2001 Corporation for National Research Initiatives.
All Rights Reserved.
See LICENSE.txt for license information.
For the latest version, visit
Greg Ward - software developer gward(a)mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
seems that others too want to use the serial port from python...
here's my module (python license). The current version is 1.12.
from the readme/homepage:
This module capsulates the access for the serial port. It provides
backends for stadard Python running on Windows, Linux, BSD (possibly
any POSIX compilant system) and Jython. The module named "serial"
automaticaly selects the appropriate backed.
(C) 2001-2002 Chris Liechti <cliechti(a)gmx.net>
- same class based interface on all supported platforms
- port numbering starts at zero, no need to know the port name in the
- port string can be specified if access through numbering is
- support for diffrent bytesizes, stopbits, parity and flow control
with RTS/CTS and/or xon/xoff
- working with or without receive timeout
- file like API with "read" and "write"
- The files in this package are 100% pure Python.
They depend on non standard but common packages on Windows
(win32all) and Jython (JavaComm). POSIX (Linux, BSD) uses only
modules from the standard python distribution)
- The port is set up for binary transmission. No NULL byte stripping,
CR-LF translation etc. (which are many times enabled for POSIX.)
This makes this module universally useful.
more details on the Homepage: http://pyserial.sourceforge.net/