See http://gmpy.sourceforge.net/ for details.
What is it: a wrapper for the GMP library, to provide multi-precision
arithmetic for Python. Multi-precision floats, and unbounded-precision
rationals, are not present in stock Python; multi-precision integers
('long') are, but gmpy's version of multi-precision integers is faster
for some operations (NOT all -- used to be, but Python 2.3 did serious
enhancements to some operations on longs) and provides lots of nifty
pre-packaged additional functions.
Minor changes and bug-fixes since the latest 0.9 pre-alpha; support for
Python 2.3. The Windows binary release is now for Python 2.3 _only_ (if
you're stuck with Python 2.2 on Windows, you can keep using gmpy 0.9
pre-alpha and not really suffer from that). Known bug on Windows: the
scan0 and scan1 functions appear broken (perhaps related to the lack of
a GMP 4.0 library for Windows -- haven't found one around yet).
Alex
I'm pleased to announce the release of ZODB 3.2.2 (final). This is the
version of ZODB that will ship with Zope 2.7.1 (final). Upgrading to ZODB
3.2.2 is strongly recommended for all users, and is critical for sites
running ZRS.
You can download a source tarball or Windows installer from:
http://zope.org/Products/ZODB3.2
As promised with the ZODB 3.2.2b1 release last week, the tests for the
unsupported Berkeley-based storages are now disabled in 3.2.2. In addition,
a small but critical bug in FileStorage.restore() was identified and
repaired. This bug didn't affect the Zope core, but is critical for sites
running ZRS. See the news file for more detail:
http://zope.org/Products/ZODB3.3/NEWS
Note that ZODB 3.2.2 does not support Zope X3 (Zope 3 requires ZODB 3.3 --
as will Zope 2.8).
My new non-profit web site is www.getcet.org
It's about automatic flow chart generation. I have a program that
automatically draws a flow chart next to Python code so that you can see and
understand the flow among the lines of Python code. I use a slightly
different syntax for flow control than Python does, but the rest is regular
Python. I have numerous images to illustrate this. I think it would be a
new way to have code that is somewhat self-documenting. It could also help
Python be somewhat self-teaching, at least with respect to structured
control constructs and how they work.
Dear community,
I could not resist to do this announcement, although
this project belongs to Michael Hudson.
Mike, please forgive me. I owe you a beer.
In a single day-and-night session, I hacked against bytecodehacks,
to upgrade it from Python 1.5.2 to Python 2.3 .
This was quite some work, although not so very much, due to
the excellent basic layout which Michael created.
What are the Bytecodehacks?
---------------------------
The bytecodehacks allow you to do certain modifications to
compiled Python code objects. There are lots of applications
included, like macro expansions and function inlining,
things which Python does not provide and also is not supposed
to provide. This kind of madness exists for people who ask
for it, without worring those who don't care.
Again, this great package was written by Michael Hudson in early
2000, and to my knowledge, it was never ported to the more
recent Python versions. Michael told me that this is a package
he is no longer too fond of, since it was written in his early days.
He also told me that he is not keen on supporting it so much,
because he would be tempted to give it a whole rewrite.
Now, I'm thinking differently. I got the package to work, after
about 12 hours of hacking, and it simply works. Since I didn't
write the initial version, I have a different relationship to it.
In other words: It is easier to maintain a foreign package than
your own, since you are not married with it.
Why do I dig into foreign areas?
--------------------------------
Well, I have enough work with my Stackless package.
Stackless is almost ready. (Almost, like your toy
railway gets really ready; it really never will.)
I just built a minimum Psyco support into it, because
I'm basically always after as much speed as I can get.
But there are limits with the regular Python interpreter.
So my idea is to use these crazy other projects to get more
performance, and to support them directly.
My first idea to accelerate Psyco using Stackless was
to provide Stackless with extra hardware stacks, which can
be switched at light-speed. I still have this idea in mind,
but the implementation is not so trivial.
Comparatively, replacing generators (yield calls) with
a couple of save/restores of tuples *is* almost trivial,
as I'm probably going to show tomorrow.
In Python, these "fake-generators" would be reasonably
slower.
But, by the fact that these are then Psyco-enabled, makes
them really, really fast, and also completely inlineable.
I think to name the module "renegate". :-)
Why do I want to revive this package
------------------------------------
Well, I am a pragmatic guy, and I have a really good reason why I
need the bytecodehacks. I am writing a sophisticated package
which involves parsing of PDF files, and I want to do it all in
Python. In order to get this PDF processor to almost C speed,
I used Armin Rigo's wonderful Psyco package.
Unfortunately, Psyco has a few limitations, which act as a
show-stopper:
- generators are not supported. That means, whenever I use
a generator, Psyco will not accelerate it, but will act as a
small slow-down.
- Psyco is great at optimizing simple structures like lists, tuples,
numbers and strings. It is less able to enhance things like
object properties. Using self frequently disables almost all
of Psyco's capabilities.
- Psyco has difficulties with inlining. Simple functions *are*
inlined, but when they contain a conditional branch or they
exceed some limit, inlining is disabled. This *could* be changed,
but with a lot of effort by changing C code. This is not going to
happen, because all of this stuff will be enhanced and
re-implemented during the PyPy project.
Now, by combining the re-animated bytecodehacks project with
Psyco, I am almost sure that I can remove certain restrictions
from Psyco, by turning problematic Python structures into simple
ones, which the current Psyco can handle natively.
Poor man's PyPy
---------------
Although I am a member of the PyPy project, and I do belong to the
people who initiated the PyPy project, I am impatient, and I want
to get a few of the expected PyPy results right now. Psyco is
phantastic but not perfect, and it needs some help to gather maximum
performance.
By adding Bytecodehacks in the right manner, I think I can fill
this gap. With BCH, I can replace generators by ordinary methods
of a class (plus a few bytecode instructions which have no real
Python equivalent, like goto). By inspecting the data flow of a
self.attribute, I can prove that it is invisible outside and
replace it by a simple local variable in many cases. By using
Bytecodehacks for proper inlining of functions, I can deliver
Psyco from this difficult task.
The expected result
-------------------
By consequently applying the methods I sketched above,
I expect that I can make almost every existing application
reasonably faster. I will provide this as a service for
customers and charge them for relevant acceleration.
The software will stay open-sourced. This is just a few
add-ons to Psyco and Bytecodehacks, and I'm not the author
of these. I just found out how nicely they can fit together.
My guess is an overall acceleration of at least a factor of
five for almost any native Python application. There is no proof
yet, this is all Vodoo from my stomach. But this stomach tends
to be quite reliable
Mike, please forgive me this announcement. You should have
written it, but I was so very inspired.
Getting the bytecodehacks for Python 2.3
----------------------------------------
The current source code is available at
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bytecodehacks login
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/bytecodehacks
co bytecodehacks
cheers -- chris
--
Christian Tismer :^) <mailto:tismer@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
> Summary Announcements
> =====================
> I don't think my informal editors on python-dev often enough for their
> help.
That should read "I don't *thank* my informal editors", not "think".
I added that bit just before I sent out the final version and thus it
was never checked by anyone. I am not kidding when I say I don't
proof-read anything. =)
-Brett
python-dev Summary for 2004-07-01 through 2004-07-15
++++++++++++++++++++++++++++++++++++++++++++++++++++
This is a summary of traffic on the `python-dev mailing list`_ from July
01, 2004 through July 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 `python-dev`_!
This is the forty-forth summary written by Brett Cannon (wished he could
be at
OSCON to see Guido throw a pie).
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 posted there.
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/
.. _reST:
.. _reStructuredText: http://docutils.sf.net/rst.html
.. _PSF:
.. _Python Software Foundation: http://python.org/psf/
.. contents::
.. _last summary:
http://www.python.org/dev/summary/2004-07-01_2004-07-15.html
.. _original text file:
http://www.python.org/dev/summary/2004-07-01_2004-07-15.ht
Summary Announcements
=====================
I don't think my informal editors on python-dev often enough for their
help. In case you didn't know, I send a rough draft (read: first draft
since I **hate** proof-reading) to python-dev before a summary out for
general consumption to make sure I didn't totally get something wrong.
Luckily I tend not to screw stuff up that badly and it ends up being
little grammatical errors here and there. But if it wasn't for them the
summaries would not be the level of quality that they are (read:
wouldn't seem like they are written by some grad student with impeccable
grammar but instead as if they are written by some grad student with
decent grammar =). Anyway, I just felt like I should give a public
thanks to everyone who has ever sent me a fix.
In case you didn't know, Python 2.4a1 was released in early July. If
you have not already please `download <http://www.python.org/2.4/>`__ it
and run the `regression test suite
<http://www.python.org/dev/doc/devel/lib/regrtest.html>`__.
And it looks like Unicode will finally work in the Summaries! Thanks
for that goes to David Goodger for making that happen.
Summaries
=========
------------------
2.4a1 out the door
------------------
Thanks to Anthony Baxter, `Python 2.4a1`_ went out the door in early
July. If you have not downloaded it and run the regression test suite,
please do (see the stdlib docs on the 'test' pacakge on how to run the
tests and please check if you can that any failures you got were not
already posted and possibly fixed in CVS).
.. _Python 2.4a1: http://www.python.org/2.4/
Contributing threads:
- `2.4a1
<http://mail.python.org/pipermail/python-dev/2004-July/045944.html>`__
- `RELEASED Python 2.4, alpha 1
<http://mail.python.org/pipermail/python-dev/2004-July/046013.html>`__
--------------------------------
MSI installer on Windows for 2.4
--------------------------------
Some discussion on Martin v. Löwis' MSI installer code took place on the
list. It seemed like Martin's installer was good and just needed some docs.
Contributing threads:
- `VC 7.1 maintenance?
<http://mail.python.org/pipermail/python-dev/2004-July/045815.html>`__
- `Windows installer for 2.4?
<http://mail.python.org/pipermail/python-dev/2004-July/045954.html>`__
---------------------------------------------------------------------------------
Decimal is in the stdlib with defaults for people who don't have a "bot"
nickname
---------------------------------------------------------------------------------
Since the Decimal package went in at the beginning of July, most of the
discussions about Decimal revolved around making it easy to use out of
the box for normal folk; "practicality beats purity".
First discussion was over invalid constructor arguments. Originally if
you tried something like ``Decimal("Raymond")``, it would return NaN.
Obviously that ain't cool. Turned out to be a misinterpretation of the
IBM spec that Decimal is based on. In the doc an exception being
"signaled" is the same as it being raised in Python. So that got
clarified and now raises an exception.
From there a discussion of what signals should be on by default ensued.
Michael Chermside sparked it with his list of what he thought would
work. Some other people posted theirs and all of them coagulated into a
final list. Those defaults have been added to CVS and will be available
in 2.4a2 .
Contributing threads:
- `decimal API
<http://mail.python.org/pipermail/python-dev/2004-July/045859.html>`__
- `decimal.py signals & traps
<http://mail.python.org/pipermail/python-dev/2004-July/045963.html>`__
---------------------------------------------------------
The second Python Bug Day stomped out some of the buggers
---------------------------------------------------------
AM Kuchling organized another Python Bug Day on July 10. A couple of
people, including yours truly, showed up on #python-dev and managed to
close a bunch of patches and bugs; 18 and 15 of them to be exact.
Thanks to all that helped out, it was fun.
The next one is tentatively scheduled for August 7th.
Contributing threads:
- `Python Bug day this Saturday
<http://mail.python.org/pipermail/python-dev/2004-July/045901.html>`__
- `Bug day outcome
<http://mail.python.org/pipermail/python-dev/2004-July/046065.html>`__
----------------------------------
file()? open()? Paper? Plastic?
----------------------------------
Guido had noticed someone had committed a patch that changed open() to
file(). While some of us thought that using the file type's factory
constructor was the proper way to open files, Guido set us straight.
Turns out he wants open() to be used for opening files. Part of the
reason is that open() might at some point develop the abilities to open
other things such as URLs (think ``open`` on OS X).
Contributing threads:
- `file() or open()?
<http://mail.python.org/pipermail/python-dev/2004-July/045921.html>`__
---------------------------------------------------------------------------------------------
What happens when you try to enter a new key in a dict that has another
key considered equal?
---------------------------------------------------------------------------------------------
Michael Chermside wondered the same thing. Tim Peters answered. Turns
out to be undefined, but currently implemented as to keep the original
key and not the new key.
Contributing threads:
- `Equal but different keys in dicts
<http://mail.python.org/pipermail/python-dev/2004-July/046040.html>`__
-------------------------------------------------------------------------------------
New macro that decrefs and sets to NULL a value, all while spinning
plates on sticks!
-------------------------------------------------------------------------------------
Jim Fulton added a new macro named Py_CLEAR() that takes in a variable,
Py_DECREFs it, and then sets it to NULL. The common use case is a field
in a struct that can hold a PyObject but not always which is set to NULL
when it doesn't. It is in no way meant to signify the PyObject should
be garbage collected immediately, just that the current variable no
longer holds a reference to anything.
Contributing threads:
- `Proposal: C API Macro to decref and set to NULL
<http://mail.python.org/pipermail/python-dev/2004-July/046086.html>`__
--------------------------------------
Trying out tagged integers in the core
--------------------------------------
Result: can be faster, but people don't want the added complexity (and
Guido had a bad experience while developing the ABC language).
For those of you who don't know what tagged integers are, imagine all
PyObjects being either an object or integer based on whether certain
bits were flipped. This has the perk of saving space and not having to
do a memory fetch to get to the int value in an int object. Problem is
you now have to check constantly whether a PyObject is really a pointer
or a tagged integer.
Contributing threads:
- `Tagged integers
<http://mail.python.org/pipermail/python-dev/2004-July/046139.html>`__
------------------------------------------------------
You are not getting proper tail recursion optimization
------------------------------------------------------
If you know what proper tail recursion is, skip this paragraph. Still
there? OK, on with the lesson. Proper tail recursion is when a
recursive call is made in which the callee does not need to return to
the caller. Think of a 'return' statement that makes a recursive
function call only; you don't *have* to return through the call chain
since you just want that return statement to get to the first point
where you are going to perform calculations on it. So if you have a
recursive 'return' statement you can skip creating a bunch of frames
that stick around by just having each subsequent tail recursive call
just return to the beginning of the recursion. Confused yet? Use
Scheme and you will know what I am talking about (this stuff is actually
*required* by the Scheme specification). I could explain it using
continuations, but chances are more people know about tail recursion
than continuations so I am not even go to bother melting your brains
with continuations. =)
A patch to add proper tail recursion optimization was proposed, but
Guido shot it down very strongly. Guido has spoken and is not about to
change his mind. If you want to read the **long** thread on why then go
ahead. Basically, though, Guido said that if you are writing recursive
code that is hitting the recursion limit you should probably change your
algorithm. There was also issues with how to handle tracebacks but that
wasn't as entertaining. =)
Contributing threads:
- `Proper tail recursion
<http://mail.python.org/pipermail/python-dev/2004-July/046150.html>`__
Find a new pre-release of python-ldap:
http://python-ldap.sourceforge.net/
python-ldap provides an object-oriented API to access LDAP directory
servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for
that purpose. Additionally it contains modules for other LDAP-related
stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema).
----------------------------------------------------------------
Released 2.0.2 2004-07-29
Changes since 2.0.1:
Modules:
* Fixed detecting appropriate OpenLDAP libs version for
determining whether ldap_whoami_s() is available or not.
This fixes build problems with OpenLDAP libs 2.1.0 up
to 2.1.12.
Initial (Alpha) releases of two new modules:
PyGT - Python Grid Toolkit
A framework for developing, deploying, and managing grid systems using
python modules. Curently very alpha, releasing to gauge public
interest in project. GPL
PyMenu - Python Menu Toolkit
An easy-to-use API for making quick curses menus in python. Alpha, LGPL
Both of these projects can be found at
http://www.karllindekugel.com/
