Mailman 3 March 2004 - Python-announce-list

ANN: Unum 4.0 released
by Pierre Denis March 28, 2004

March 28, 2004

Unum 4.0 is now available on http://home.tiscali.be/be052320/Unum.html. This Python module allows you to work with units like volts, hours, meter-per-second or dollars-per-spam. So you can play with true quantities (called 'unums') instead of simple numbers. Consistency between units is checked at each expression evaluation; an exception is raised when something inconsistent is detected, like adding meters to seconds. Unit conversion and unit output formatting are performed automatically when needed. The main goals are to avoid unit errors in your calculations and to make unit output formatting easy and uniform. Unum is a 'pure' Python module. IMHO, it is stable, lightweight and easy to use. The site contains a comprehensive tutorial page. This new version encompasses all the SI units and allows you to define your own libraries of units, with specific names and symbols. Other improvements make this version more solid and more in-line with latest Python versions: compatibility with NumPy, packages, misc. optimizations, true exceptions, new-style class, static methods, etc. The installation should be easier and more standard through distutils-generated files. The site and tutorial page have been updated to give more accurate information. This version requires Python 2.2 (at least). The license is GPL. Any comments are welcome (E-mail: Pierre.Denis(a)spacebel.be). Thanks for your interest, Pierre Denis <P><A HREF="http://home.tiscali.be/be052320/Unum.html">Unum 4.0</A> - Unum is a Python module that allows to process quantities with units. (28-Mar-04)

1 0

python-dev Summary for 2004-03-01 through 2004-03-15
by Brett C. March 25, 2004

March 25, 2004

python-dev Summary for 2004-03-01 through 2004-03-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from March 01, 2004 through March 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 thirty-seventh summary written by Brett Cannon (waiting for PyCon to start). 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 something mentioned here. 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-02-01_2004-02-29.html .. _original text file: http://www.python.org/dev/summary/2004-03-01_2004-03-15.ht ===================== Summary Announcements ===================== Still looking for a summer job or internship programming. If you know of one, please let me know. Ever since I first had to type Martin v. Loewis' name, I have had issues with Unicode in the summary. When I realized there was a problem I thought it was Vim changing my Unicode in some way since I would notice problems when I reopened the file in TextEdit, OS X's included text editor that I have always used for writing the summaries (and no, I am not about to use Vim to do this nor Emacs; spoiled by real-time spelling and it is just the way I do it). Well, I was wrong. Should have known Vim was not the issue. Turned out that TextEdit was opening the text files later assuming the wrong character encoding. When I forced it to open all files as UTF-8 I no longer had problems. This also explains the weird MIME-quoted issues I had earlier that Aahz pointed out to me since I was just copying from TextEdit into Thunderbird_, my email client, without realizing TextEdit was not reading the text properly. So I thought I finally solved my problem. Ha! Not quite. Turned out to be a slight issue on the generation of the email based on the tool chain for how we maintain the python.org web site. This is in no way the web team's fault since I have unique requirements for the Summaries. But without having to do some recoding of ht2html_ in order to specify the text encoding, I wasn't sure how I should handle this. I thought I had this solved under reST_, but my solution turned out not to work. So the battle continues. So, for the moment, Unicode is not working for the summaries. And here is a question of people who read the Summaries on a regular basis: would you get any benefit in having new summaries announced in the `python.org RSS feed`_? Since this entails one extra, small step in each summary I am asking people to email me to let me know if this would in any way make their lives easier. So please let me know if knowing when a new summary is out by way of the RSS feed would be beneficial to you or if just finding from `comp.lang.python`_ or `comp.lang.python.announce`_ is enough. I actually wrote this entire summary either in the airport or on the flight to DC for PyCon (thank goodness for emergency aisles; my 6'6" frame would be in much more pain than it is otherwise) and thus on Spring Break! I am hoping to use this as a turning point in doing the Summaries on a semi-monthly basis again. We will see if Spring quarter lets me stick to that (expecting a lighter load with less stress next quarter). .. _Thunderbird: http://www.mozilla.org/projects/thunderbird/ .. _ht2html: http://ht2html.sf.net/ .. _directive: http://docutils.sourceforge.net/spec/rst/directives.html .. _python.org RSS feed: http://www.python.org/channews.rdf .. _PyCon: http://www.pycon.org/ .. _comp.lang.python.announce: http://groups.google.com/groups?q=comp.lang.python.announce&ie=UTF-8&oe=UTF… ========= Summaries ========= -------- PEP news -------- PEP 309 ("Partial Function Application") has been rewritten. PEP 318 got a ton of discussion, to the point of warranting its own summary: `PEP 318 and the discussion that will never end`_. PE 327, which is the spec for the Decimal module in the CVS sandbox, got an update. Contributing threads: - `PEP 309 re-written <http://mail.python.org/pipermail/python-dev/2004-March/042865.html>`__ - `Changes to PEP 327: Decimal data type <http://mail.python.org/pipermail/python-dev/2004-March/043155.html>`__ ----------------------------------------------- Playing willy-nilly with stack frames for speed ----------------------------------------------- A patch to clean up the allocation and remove the freelist (stack frames not in use that could be used for something else) was proposed. Of course it would have been applied immediately if there wasn't a catch: recursive functions slowed down by around 20%. A way to get around this was proposed, but it would clutter up the code which was being simplified in the first place. Guido said he would rather have that than have recursive calls take a hit. Then a flurry of posts came about discussing other ways to try to speed up stack allocation. Contributing threads: - `scary frame speed hacks <http://mail.python.org/pipermail/python-dev/2004-March/042871.html>`__ - `reusing frames <http://mail.python.org/pipermail/python-dev/2004-March/042914.html>`__ ---------------------------------------------- PEP 318 and the discussion that will never end ---------------------------------------------- Just looking at the number of contributing threads to this summary should give you an indication of how talked about this PEP became. In case you don't remember the discussion `last time`_, this PEP covers function/method(/class?) decorators: having this:: def foo() [decorate, me]: pass be equivalent to:: def foo(): pass foo = me(decorate(foo)) What most of the discussion came down to was syntax and the order of application. As of this moment it has come down to either the syntax used above or putting the brackets between the function/method name and the parameters. Guido spoke up and said he liked the latter syntax (which is used by Quixote_). People, though, pointed out that while the syntax works for a single argument, adding a long list starts to separate the parameter tuple farther and farther from the function/method name. There was at least one other syntax proposal but it was shot down quickly. Order of application seems to have been settled. Some want the order to be like in the example. Others, though, want the reverse order: ``decorate(me(foo))``. In the end, though, the order in the example code is what people preferred. In the end it was agreed the PEP needed to be thoroughly rewritten which is currently happening. .. _last time: 2004-02-01_2004-02-29.html#function-decoration-and-all-that-jazz .. _Quixote: http://www.mems-exchange.org/software/quixote/ Contributing threads: - `Pep 318 - new syntax for wrappers <http://mail.python.org/pipermail/python-dev/2004-March/042902.html>`__ - `new syntax (esp for wrappers) <http://mail.python.org/pipermail/python-dev/2004-March/042906.html>`__ - `PEP 318 - function/method/class decoration <http://mail.python.org/pipermail/python-dev/2004-March/042917.html>`__ - `(Specific syntax of) PEP 318 - function/method/class <http://mail.python.org/pipermail/python-dev/2004-March/042947.html>`__ - `PEP 318 - generality of list; restrictions on elements <http://mail.python.org/pipermail/python-dev/2004-March/042951.html>`__ - `PEP 318 needs a rewrite <http://mail.python.org/pipermail/python-dev/2004-March/042975.html>`__ - `Python-Dev Digest, Vol 8, Issue 20 <http://mail.python.org/pipermail/python-dev/2004-March/043033.html>`__ - `PEP 318 trial balloon (wrappers) <http://mail.python.org/pipermail/python-dev/2004-March/043076.html>`__ - `funcdef grammar production <http://mail.python.org/pipermail/python-dev/2004-March/043142.html>`__ ---------------------------------------- Compiler optimization flags for the core ---------------------------------------- The topic of compiler flags that are optimal for Python came up when Raymond Hettinger announced his new LIST_APPEND opcode (discussed later in `Optimizing: Raymond Hettinger's personal crack`_). This stemmed from the fact that the bytecode has not been touched in a while. This generated a short discussion on the magic that is caches and how the eval loop always throws a fit when it gets played with. One suggestion was to rework some opcodes to use other opcodes instead in order to remove the original opcodes entirely from the eval loop. But it was pointed out it would be better to just factor out the C code to functions so that they are just brought into the cache less often instead of incurring the overhead of more loops through the eval loop. This then led to AM Kuchling to state that he was planning in giving a lightning talk at PyCon_ about various compiler optimization flags he tried out on Python. Looks like that compiling Python/ceval.c with -Os (optimizes for space) w/ everything else using -O3 gave the best results using gcc 3. This sparked the idea of more architecture-dependent compiler optimizations which would be set when 'configure' was run and detected the hardware of the system. In the end no code was changed in terms of the compiler optimizations. Contributing threads: - `New opcode to simplifiy/speedup list comprehensions <http://mail.python.org/pipermail/python-dev/2004-March/042924.html>`__ - `Who cares about the performance of these opcodes? <http://mail.python.org/pipermail/python-dev/2004-March/042990.html>`__ ------------------------------------------------------ Take using Python as a calculator to a whole new level ------------------------------------------------------ I remember once there was a thread on `comp.lang.python`_ about how to tell when you had an addiction to Python. One of the points was when you start to use Python as your calculator (something I admit to openly; using the 'sum' built-in is wonderful for quick addition when I would have used a Scheme interpreter). Well, Raymond Hettinger had the idea of adding a 'calculator' module that would provide a ""pretty good" implementations of things found on low to mid-range calculators like my personal favorite, the hp32sII student scientific calculator". He then listed a bunch of functionality the HP calculator has that he would like to see as a module. Beyond sparking some waxing about calculators, and the HP 32sII especially (I used a TI-82 back in high school and junior college so I won't even both summarizing the nostalgic daydreaming on HP calculators), the discussion focused mainly on what functionality to provide and the accuracy of the calculations. The former topic focused on what would be reasonable and relatively easy to implement without requiring a mathematician to write in order to be correct or fast. The topic of accuracy, though, was not as clear-cut. First the issue of whether to use the in-development Decimal module would be the smart thing to do. The consensus was to use Decimal since floating-point, even with IEEE 754 in place, is not accurate enough for something that wants to be as accurate as an actual calculator. Then discussions on the precision of accuracy came up. It seemed like it would be important to have a level of precision kept above the expected output precision to make sure any rounding errors and such would be kept to a minimum. Raymond is going to write a PEP outlining the module. Contributing threads: - `calculator module <http://mail.python.org/pipermail/python-dev/2004-March/043003.html>`__ ------------------------ dateutil module proposed ------------------------ Gustavo Niemeyer offered to integrate his dateutil_ module into the stdlib. Discussion of how it should tie into datetime and whether all of it or only some of its functionality should be brought in was transpired. As of right now the discussion is still going on. .. _dateutil: https://moin.conectiva.com.br/DateUtil Contributing threads: - `dateutil <http://mail.python.org/pipermail/python-dev/2004-March/043054.html>`__ ---------------------------------------------- Optimizing: Raymond Hettinger's personal crack ---------------------------------------------- Raymond Hettinger, the speed nut that he is, added a new opcode to Python to speed up list comprehensions by around 35%. But his addiction didn't stop there. Being the dealer of his own drug of choice, Raymond got his next fix by improving on iterations for dictionaries (this is, of course, after all of his work on the list internals). As always, thanks goes to Raymond for putting in the work to make sure the CPython interpreter beats the Parrot_ interpreter by that much more come `OSCON 2004`_ and the Pie-thon contest. And, at Hye-Shik Chang's request, Raymond listed off his list of things to do to feed his addiction so he doesn't go into withdrawls any time in the future. Most of them are nice and involved that would make great personal/research projects. .. _Parrot: http://www.parrotcode.org/ .. _OSCON 2004: http://conferences.oreillynet.com/os2004/ Contributing threads: - `New opcode to simplifiy/speedup list comprehensions <http://mail.python.org/pipermail/python-dev/2004-March/042924.html>`__ - `Joys of Optimization <http://mail.python.org/pipermail/python-dev/2004-March/043097.html>`__

1 0

PROTHON, a classless Python
by Mark Hahn March 25, 2004

March 25, 2004

Ben Collins and I have developed a new interpreted object-oriented language very closely based on Python, that is Prototype-based, like Self (http://research.sun.com/research/self/language.html) instead of class-based like Python. I have named the language Prothon, short for PROtotype pyTHON. You can check it out at http://prothon.org. The prototype scheme makes object oriented computing very simple and complicated things like meta-classes melt away. Once you get used to prototypes, classes seem very ancient and old-fashioned. You can inherit data as well as methods and you can switch prototypes (think "types" or "classes") on the fly. Prothon is pre-alpha, but runs well enough to give it a spin. Basic types, the File object, importing, packages, and the Re module are ready to try. It runs on Linux/Unix and Windows. Obviously Prothon is not Python compatible, so I have taken the liberty of implementing many changes that have been imagined for the almost mythical Python 3.0. Right now I've made decisions unilaterally, but I'm not planning on freezing language decisions until 7/04, so get on the Prothon mailing lists and make your opinions known. Since the Prothon interpreter has been written from the ground up, we've had the opportunity to make it industrial-strength. We feel this is very important for high-end hosting applications, and that this is a current weakness of Python and it's GIL. Prothon has no GIL. Here are some interpreter features: - Uses native OS threads, even multiple interpreters can run at once on the same objects. - Locking is done at the object level with shared read locks and exclusive write locks. - No recursion limits, Prothon is stackless. - Garbage collection is mark-and-sweep in seperate thread. - C coding is simple. Macros simulate coding at Prothon level. (No reference counting!) - Ints are 64-bits, internal architecture is all 64-bit. - Built on Apache Portable Runtime (APR) for stability, ease in porting, and eventual integration with Apache.

1 0

LeoBof cancelled at PyCon
by Edward K. Ream March 23, 2004

March 23, 2004

I shall not be attending PyCon this week due to illness. As a result, Leo's "Bird's of a feather" session has been cancelled. My apologies for this last-minute change of plans. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

1 0

PyPosta
by Uwe Schmitt March 23, 2004

March 23, 2004

Hi, I'd like to announce PyPosta, a console based tool for browsing and cleaning POP boxes without downloading full mails. It uses Console.py from http:///www.effbot.org and thus runs on Windows only. It implments some reusable GUI widgets like ListBox, TextField, .. and uses a state machine for handling user reactions. Internally a separate thread keeps the connection open in order to avoid unintended locking of the mailbox. Source can be found at http://www.rocksport.de/ftp/PyPosta_source.zip An executable for Windows is at http://www.rocksport.de/ftp/PyPosta_winxp.zip It runs on Win XP, ME, 2K. Greetings, Uwe. -- Dr. rer. nat. Uwe Schmitt http://www.procoders.net schmitt(a)procoders.net "A service to open source is a service to mankind."

1 0

ANNOUNCE: PyNSource 1.3 reverse engineering UML tool for Python source code
by abulka＠netspace.net.au March 22, 2004

March 22, 2004

Announcing PyNSource 1.3 A UML reverse engineering and modelling tool for Python source code. http://www.atug.com/andypatterns/pynsource.htm PyNSource is a python code scanner and UML modelling tool that generates UML diagrams that you can layout, arrange and print out. A standalone exe release for windows users is available. PyNSource can also generate UML ASCII / text diagrams, which you can paste into your source code for documentation purposes, in conjunction with an ascii art editor (see references on web site). PyNSource can scan python source code and generate compilable Java or Delphi code, which can be subsequently imported into more sophisticated UML modelling tools. New in this release ------------------- * GUI front end allowing you to import python code directly into a manipulatable UML diagram. * Delphi output (.pas files) * Java output (.java files) now compilable * Standalone .EXE of GUI for windows users. * Print and Print Preview support Features -------- * Resilient: doesn't import the python files, thus will never get "stuck" when syntax is wrong. * Fast * Recognises inheritance and composition relationships * Detects the cardinality of associations e.g. one to one or 1..* etc * Optionally treat modules as classes - creating a pseudo class for each module - module variables and functions are treated as attributes and methods of a class * Has been developed using unit tests (supplied) so that you can trust it just that little bit more ;-) * Free http://www.atug.com/andypatterns/pynsource.htm Andy Bulka http://www.atug.com/andypatterns

1 0

ANN: PyAlbum 0.5.0: a template driven web photo album generator
by Bernd Preusing March 21, 2004

March 21, 2004

A new version of PyAlbum is available: PyAlbum 0.5.0 What's new since 0.4.3 (last announcement here): ================================== - image filters: texts, logos and more... - some templates reworked - better video and audio support - new EXIF module, more info extracted What is PyAlbum: ============= - generates static HTML pages or simple text or XML files from Images - platform independent - written in Python (GPL) - reads info from several sources (text files, image comments, EXIF) - uses flexible templates to generate the output. - existing templates designed for multiple languages - until now, command line only, GUI to come - every feature is configurable - uses PIL and EmPy python modules PyAlbum is hosted on SourceForge.net at http://pyalbum.sourceforge.net/index.html The release can be downloaded from its project page: http://sourceforge.net/projects/pyalbum/ Enjoy, Bernd

1 0

ANN: TLS Lite 0.3.0
by trevp＠trevp.net March 21, 2004

March 21, 2004

I'm pleased to announce a new release of TLS Lite. Several requested features have been added, and I've cleaned things up a lot. New features since 0.2.0 ------------------------- - API docs (courtesy of Epydoc) - integrates with Twisted and asyncore - supports PyCrypto and GMPY for performance - X.509 path validation (requires cryptlib) - supports loading PEM private keys in pure Python - supports OS-specific Random Number Generators - RSA blinding to prevent timing attacks http://trevp.net/tlslite/ TLS Lite is a free python library that implements SSL v3 and TLS v1. TLS Lite supports non-traditional authentication methods such as SRP, shared keys, and cryptoIDs, in addition to X.509 certificates. Trevor

1 0

Europython Call for Participation
by jacob＠cd.chalmers.se March 19, 2004

March 19, 2004

EuroPython 2004 to be held 7-9 June in Göteborg, Sweden. The EuroPython conference will have tracks for Science, Business, Education, Applications, Frameworks, Zope and the Python language itself. Lightning talks, Open Space and BOF sessions are also planned. There will be tutorials as well, both for newcomers to Python and Python users interested in special subjects. In the days before and after the conference, programming sprints will be arranged. In the call for participation prospective speakers are welcomed to give either a formal, refereed paper or a less formal regular presentation. "We see a lot of interest in this years conference even before officially announcing it, with people asking for accomodation information, wanting to give talks and volunteering for other tasks", says Jacob Hallén, head organiser. "We hope that people will stay for a few days after the conference to join spontaneously organised programming sprints", says Laura Creighton, sprint coordinator. "Sprints are fun, and we will have good facilities for them." Important dates * Refereed paper proposals: 19 March - 31 March * Submission of talks: 19 March - 15 April. * Early Bird registration: 31 March - 1 May. For more information and submission forms, please visit http://www.europython.org --

1 0

ANN: python-ldap-2.0.0pre20
by Michael Ströder March 18, 2004

March 18, 2004

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). Changes: Wrapped OpenLDAP's ldap_whoami_s(). Fixed incompability with OpenLDAP 2.2 libs. Code cleaning. ---------------------------------------------------------------- Released 2.0.0pre20 2004-03-xx Changes since 2.0.0pre19: Modules/: * Removed doc strings from functions.c * Removed probably unused wrapper function l_ldap_dn2ufn() since ldap_dn2ufn() is deprecated in OpenLDAP 2.1+ * Removed wrapper function l_ldap_is_ldap_url(). * Removed macro add_int_r() from constants.c since it caused incompability issues with OpenLDAP 2.2 libs (Warning: all result types are Integers now! Use the constants!) * New wrapper function l_ldap_whoami_s() ldap.ldapobject: * New wrapper method LDAPObject.whoami_s() ldap.functions: * Removed is_ldap_url(). The more general function ldapurl.isLDAPUrl() should be used instead. ldap.sasl: * Added class cram_md5 (for SASL mech CRAM-MD5) ldap.async: * Use constants for search result types (see note about add_int_r() above).

1 0