Python-announce-list July 2004

python-announce-list@python.org

52 participants
73 discussions

[ANNOUNCE] gmpy 1.0 alpha released
by Alex Martelli 12 Nov '05

12 Nov '05

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

2 1

ZODB 3.2.2 (final) released
by Tim Peters 07 Sep '04

07 Sep '04

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).

1 3

A Python preprocessor that has automatic flowcharting
by Rick Hilburger 30 Jul '04

30 Jul '04

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.

1 0

Ann: Revival of the BytecodeHacks
by Christian Tismer 29 Jul '04

29 Jul '04

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/

1 0

Docutils 0.3.5 released
by Felix Wiemann 29 Jul '04

29 Jul '04

========================= Docutils 0.3.5 released ========================= Docutils 0.3.5 has just been released. We recommend all users to upgrade to version 0.3.5. Download ======== You can download the release package from: http://prdownloads.sourceforge.net/docutils/docutils-0.3.5.tar.gz?download What's New ========== Major changes since Docutils 0.3.3 include: * improved, extended and reorganized documentation; see <http://docutils.sourceforge.net/docs/index.html>. * new csv-table directive * many minor improvements, additions and bug fixes See the HISTORY at <http://docutils.sourceforge.net/0.3.5/HISTORY.html> for a detailed list of changes. What is Docutils? ================= Docutils is a modular system for processing documentation into useful formats, such as HTML, XML, and LaTeX. For input Docutils supports reStructuredText, an easy-to-read, what-you-see-is-what-you-get plaintext markup syntax. Useful Resources ================ * The Docutils website: http://docutils.sourceforge.net * The reStructuredText homepage: http://docutils.sf.net/rst.html * The Docutils FAQ: http://docutils.sourceforge.net/FAQ.html * Known Bugs: http://docutils.sourceforge.net/BUGS.html#known-bugs Discussion ========== Please direct any discussion to <docutils-users(a)lists.sourceforge.net>. -- Felix Wiemann -- http://www.ososo.de/

1 0

Re: python-dev Summary for 2004-07-01 through 2004-07-15
by brett＠python.org 29 Jul '04

29 Jul '04

> 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

1 0

python-dev Summary for 2004-07-01 through 2004-07-15
by Brett Cannon 28 Jul '04

28 Jul '04

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>`__

1 0

ANN: python-ldap-2.0.1
by Michael Ströder 28 Jul '04

28 Jul '04

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.

1 0

IronPython 0.6
by Bror Johansson 28 Jul '04

28 Jul '04

Available on http://ironpython.com/ /BJ

1 0

Ann: PyGT 0.01 and PyMenu 0.01
by Karl Lindekugel 28 Jul '04

28 Jul '04

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/

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-announce-list July 2004