Mailman 3 May 2004 - Python-announce-list

[ANN] tconfpy 1.185 Release And Available
by Tim Daneliuk May 15, 2004

May 15, 2004

'tconfpy' Version 1.185 is now released and available for download at: http://www.tundraware.com/Software/tconfpy The last public release was 1.184 (4-27-2004) This release fixes a bug that incorrectly reported syntax errors within literal blocks found inside False conditionals. The bug was benign but noisy, so a new release was dropped to fix it. Complete details can be found in the WHATSNEW.txt file included in the distribution. Users are strongly encouraged to join the tconfpy-users mailing list as described in the documentation. What Is 'tconfpy'? ------------------ 'tconfpy' is an advanced configuration file parser and validator for Python programs. By using 'tconfpy', Python programmers can provide their users with an external configuration file for setting program options, defining defaults, and so on. 'tconfpy' offloads the responsibility for parsing and validating a configuration file from the main application. The Python programmer need only deal with the results and any errors or warnings generated during the parsing process. 'tconfpy' recognizes a rich configuration language and provides a number of sophisticated programming features including: - The ability to breakup large configurations into smaller pieces via the '.include' directive. - Support for string substitution and concatenation throughout the configuration file via string variables. Variables may be locally declared, a reference to a symbol already in the symbol table, or a reference to an environment variable. - A complete set of conditional directives for selective processing of configuration options. Both existential ("If variable exists ...") and comparison ("if string equals/does not equal string ...") forms are provided, as is an '.else' directive. - The ability to instantiate program options prior to reading a configuration file and make them mandatory by declaring those options as Read-Only. - Optional type validation to ensure that a user enters a value appropriate for boolean, integer, floating point, string, or complex data. - Optional value validation to ensure that a configuration option is either within a specified range or one of an enumerated set of possible values. For configuration options which are string types, 'tconfpy', can optionally specify min/max string lengths and enumerate a set of legitimate regular expressions that the string must match. - The ability to define an arbitrary number of lexical namespaces. - The ability to use the various features of 'tconfpy' as a pre- processor for any other text (including source code for other programming languages and Python itself) via the '.literal' directive. - The ability to "template" classes of variables, thereby predefining the type and value restrictions for such variables. This makes 'tconfpy' useful as a building block for data validation tools. - An optional debug capability which returns detailed information about each line parsed. - Includes a test driver program for learning how to program with 'tconfpy' and for debugging and testing your own configuration files. - Comes with approximately 40 pages of documentation including a Programmer's API Reference and a User's Guide to the 'tconfpy' configuration language. Documentation is provided in several formats including Unix 'man', Plain Text, html, pdf, and Postscript. 'tconfpy' is a Pure Python module and is platform-independent. It should work identically on any platform on which Python runs. ------------------------------------------------------------------------------ Tim Daneliuk tundra(a)tundraware.com

1 0

python-dev Summary for 2004-04-01 through 2004-04-30
by Brett C. May 15, 2004

May 15, 2004

python-dev Summary for 2004-04-01 through 2004-04-30 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from April 01, 2004 through April 30, 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-ninth and fortieth summary written by Brett Cannon (Should be doing homework instead). 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-04-01_2004-04-30.html .. _original text file: http://www.python.org/dev/summary/2004-04-01_2004-04-30.ht ===================== Summary Announcements ===================== Well, as you may have noticed, I wasn't able to keep up the pace of releasing the summaries twice in a month. Joys of school. Hopefully over the summer I will be able to semi-monthly releases since I will only be working and not have homework hanging over my head 24/7. To give everyone a a heads-up, a release candidate for Python 2.3.4 is going to be released May 13/14 (depending where you are on the globe). If you have time, please download it and run the regression test suite (instructions can be found in the module documentation for the 'test' package) and report any issues you have. ========= Summaries ========= -------------------------------------------------------- Method decorators and the discussion that will never end -------------------------------------------------------- Method decorators and `PEP 318`_ were discussed ad nausea this past month. The PEP should be updated in the near future. .. _PEP 318: http://www.python.org/peps/pep-0318.html Contributing threads: - `PEP 318 -- a couple use cases <http://mail.python.org/pipermail/python-dev/2004-April/043902.html>`__ - `PEP 318: Decorators last before colon/bakeoff <http://mail.python.org/pipermail/python-dev/2004-April/043911.html>`__ - `PEP 318 bake-off? <http://mail.python.org/pipermail/python-dev/2004-April/043952.html>`__ - `PEP 318: Is decorators the right term for these things? <http://mail.python.org/pipermail/python-dev/2004-April/043973.html>`__ - `Re: PEP 318: Let's propose some useful built-in decorators <http://mail.python.org/pipermail/python-dev/2004-April/043975.html>`__ - `Help with PEP 318 <http://mail.python.org/pipermail/python-dev/2004-April/044011.html>`__ - `PEP 318: Properties <http://mail.python.org/pipermail/python-dev/2004-April/044012.html>`__ - `PEP 318: More examples of decorator use <http://mail.python.org/pipermail/python-dev/2004-April/044132.html>`__ - `PEP 318: How I would implement decorators <http://mail.python.org/pipermail/python-dev/2004-April/044133.html>`__ - `PEP 318 - check for consensus <http://mail.python.org/pipermail/python-dev/2004-April/044251.html>`__ ------------------------------------------------------------ Relative imports: the *other* discussion that will never end ------------------------------------------------------------ `PEP 328`_, which covers relative imports, has been updated to cover its lengthy discussion. It seems the PEP is pretty much finalized. .. _PEP 328: http://www.python.org/peps/pep-0328.html Contributing threads: - `Re: PEP 328 -- relative and multi-line import <http://mail.python.org/pipermail/python-dev/2004-April/043978.html>`__ - `Some comments on PEP 328 (absolute/relative imports) <http://mail.python.org/pipermail/python-dev/2004-April/043998.html>`__ - `PEP 328: __path__ <http://mail.python.org/pipermail/python-dev/2004-April/044017.html>`__ - `from ...sys import path <http://mail.python.org/pipermail/python-dev/2004-April/044024.html>`__ -------------------- stdlib: Python or C? -------------------- The question of whether stdlib modules should be coded in Python or C came up again. Armin Rigo posted some numbers comparing performance of heapq using the Python version both in a stock Python interpreter and in Psyco_ and then the C version. Armin's quick timings showed that the Python version of heapq was actually faster than the C version when used in Psyco. If it is possible to get the Python version to go faster, should it and future modules be coded in Python? The usual arguments over maintenance and readability were brought up. In the end the Python version of heapq was put back into the library with the C version renamed to _heapq. .. _Psyco: http://psyco.sf.net/ Contributing threads: - `Python is faster than C <http://mail.python.org/pipermail/python-dev/2004-April/044054.html>`__ ----------------------------------- Getting an Interest Group on Artima ----------------------------------- Bill Venners of Artima_ asked if there was anyone who wanted to act as a moderator for an interest group for Python on the site. If you are interested, read the email for details. .. _Artima: http://www.artima.com/ Contributing threads: - `Python Interest Group <http://mail.python.org/pipermail/python-dev/2004-April/044131.html>`__ ------------------------------- Informative reprs for iterators ------------------------------- Raymond Hettinger suggested having the repr of iterators for built-in types list the first three objects returned by the iterator. That way you would actually know what was in the iterator. It was suggested only for iterators where the length of the iterator was known and extracting the first three objects from the iterator to display them would be cheap. In the end, though, it was not added for built-in types. Some itertools iterators, though, did get more informative reprs. Contributing threads: - `More imformative iterator representations <http://mail.python.org/pipermail/python-dev/2004-April/044136.html>`__ - `Proposed iterator representations <http://mail.python.org/pipermail/python-dev/2004-April/044166.html>`__ ------------------------------ Turning globals into constants ------------------------------ Raymond Hettinger came up with some code that could take a code object and make all globals constants, thus speeding up access and removing code that did this explicitly (``_len = len``, etc.). It was proposed for the stdlib in `PEP 329`_, but was rejected in the end for being too "hackish" in terms of fiddling with bytecode directly. It did bring up the idea of trying to come up with a way to flag built-ins that might be masked. If the compiler knew what built-ins were not going to be masked a direct lookup in the built-in namespace would be all that was needed to access a built-in. As it stands now, though, since an external module could inject a shadowing function into the global namespace of a module (such as having module bar having the code ``import foo; foo.len = lambda x: 42`` to shadow 'len' in the module foo), Python has to check the global namespace first, and then the built-in namespace for all non-local name accesses. That is costly and it could possibly be avoided since the common case is to not shadow a built-in. Guido suggested having programmers have to specify when a built-in could be shadowed. This could be compared to the 'volatile' keyword in C; the programmer has to specify when the compiler should not try to optimize access. This seemed like the best way to go since forcing the programmer to flag when a built-in will *not* be shadowed would be more work for the common case. Obviously this would all break backwards-compatibility and thus would either require a __future__ statement initially or would be like true division and always be a __future__ import until Python 3.0 . But it was all just being thrown around with no concrete ideas on implementation and such. .. _PEP 329: http://www.python.org/peps/pep-0329.html Contributing threads: - `Candidate Function Decorator <http://mail.python.org/pipermail/python-dev/2004-April/044204.html>`__ - `PEP 329: Treating Builtins as Constants... <http://mail.python.org/pipermail/python-dev/2004-April/044396.html>`__ - `peps 329, 266, 267 <http://mail.python.org/pipermail/python-dev/2004-April/044492.html>`__ ----------------------------- Decimal "stuff" was discussed ----------------------------- Two big topics came up about the Decimal package. The first one was over whether there should be an exponent limit. The discussion went back and forth, but in the end it was decided that having a limit is good since it will prevent undetected overflow and underflow. The second topic was about adding extra methods. This was shot down since the point of the Decimal module is to follow the standard as put forth at http://www2.hursley.ibm.com/decimal/decarith.html . After the module has been in the library and seen some wide usage then possible additions beyond the standard could be made. exponent limit repr (passable to eval if possible) sticking to spec initially Contributing threads: - `Decimal data type issues <http://mail.python.org/pipermail/python-dev/2004-April/044208.html>`__ - `Decimal conversion to string <http://mail.python.org/pipermail/python-dev/2004-April/044269.html>`__ - `Decimal - context manipulation <http://mail.python.org/pipermail/python-dev/2004-April/044485.html>`__ ------------------------------------------------- Magic hashing numbers segues into JIT compilation ------------------------------------------------- Raymond Hettinger suggested using a different number for hashing since it could be expressed in terms of shifts and additions. But Tim Peters said it was a bad idea to futz with the number since the current one had proven its usefulness for so long and had been studying in a Python-specific way years ago. Since part of the justification for changing to another number was the number of cycles it would take to do the calculations, the discussion shifted to JIT compilation. Clarification for JIT compared to specialized compilation (former does single compiled version of a function while the latter does multiple versions based on the argument types) came up along with wondering how some of the optimizations used in the Self_ language could be applied to Python. .. _Self: http://research.sun.com/self/language.html Contributing threads: - `String hash function multiplier <http://mail.python.org/pipermail/python-dev/2004-April/044235.html>`__ - `Optimization targets - refcount <http://mail.python.org/pipermail/python-dev/2004-April/044304.html>`__ ---------------------------------- Modules that need some documentin' ---------------------------------- Yours truly compiled a list of modules that need documentation that can be found both in the email starting this thread (although I made one mistake on that list of including the imp module) or at http://www.python.org/cgi-bin/moinmoin/ModulesThatNeedDocs where Michael Chermside was nice enough to put it on up on the wiki. Writing docs for modules is not that hard and is a great way to help out. See http://www.python.org/dev/doc/devel/doc/doc.html on how to do documentation using LaTeX. And if that scares you, even just writing the docs in reST_ is helpful since someone else can volunteer to convert it to LaTeX. Contributing threads: - `Possible modules that could use docs <http://mail.python.org/pipermail/python-dev/2004-April/044392.html>`__ -------------------------------------- A change in the name of the CVS server -------------------------------------- SourceForge_ started forcing people to use cvs.sf.net:/cvsroot/python as the location of the CVS server as compared to the previously supported (but not "official") path of cvs.python.sf.net:/cvsroot/python that shows up as SSH reporting a possible man-in-the-middle attack. Barry Warsaw posted a Python script by Greg Ward that would traverse a CVS checkout and change the name of the CVS server. That script can be found at http://mail.python.org/pipermail/python-dev/2004-April/044593.html . Contributing threads: - `SSH problems getting into SourceForge's CVS? <http://mail.python.org/pipermail/python-dev/2004-April/044592.html>`__ --------------------------- A ConfigParser replacement? --------------------------- Dan Gass presented his `config.py`_ to python-dev to see if there was any interest in adding it. While he was given the standard response that no new modules will be accepted for inclusion in the stdlib until it has seen widespread acceptance and use by the community, Barry Warsaw suggested a possible ConfigParser replacement shootout ala the `getopt-sig`_ and how it was decided that optparse (aka Optik_) should be the suggested command-line parser used. This won't happen for 2.4, but if people are interested enough this could be done for 2.5 if someone decides to spear-head this. People also immediately pointed out ZConfig_ (by our very own Fred Drake) as another possibility. .. _config.py: http://config-py.sf.net/ .. _getopt-sig: http://mail.python.org/mailman/listinfo/getopt-sig .. _Optik: http://optik.sourceforge.net/ .. _ZConfig: http://www.zope.org/Members/fdrake/zconfig/ Contributing threads: - `Proposal: A more powerful alternative to ConfigParser <http://mail.python.org/pipermail/python-dev/2004-April/044520.html>`__ - `Proposal: A more powerful alternativeto... <http://mail.python.org/pipermail/python-dev/2004-April/044529.html>`__ ----------------------------------------- Moving forward with generator expressions ----------------------------------------- Guido said he wanted to get generator expressions into CVS. While this is good and all, it still doesn't address the whole argument over whether early or late binding for variables in the genexps should be used (in case you have not been following, early binding would have a genexp save the state of the variables used in the genexp at creation time while late binding will use the state of the variables at the time of each execution of the genexp). Since Guido prefers the late binding for simplicity, he suggested using it for 2.4a1 and a2. If it was found that late binding was bad then for 2.4b1 early binding could be used. No one had issues with that idea. What people did have issue with was the whole thing about late bindings period. Basically the issue boils down to whether late binding is too much of a surprise for the cases where they can have issues. But Greg Ewing pointed out that the use case that genexps were being created for were for arguments to functions; a use case where the genexp is used immediately and whose possible abuse of variables would not be an issue. It was realized that genexps are not exactly the same as listcomps and thus not a direct replacement. Genexps are meant for places where memory is going to be an issue; if a listcomp would do just a good of a job, then just go ahead and use a listcomp. Contributing threads: - `PEP 289 - Generator Expressions - Let's Move Forward <http://mail.python.org/pipermail/python-dev/2004-April/044555.html>`__ --------------------------------------------------- How should gettext return strings from an .mo file? --------------------------------------------------- Gustavo Niemeyer noticed that if you called 'gettext.gettext' it would return the exact bytes stored in the .mo file. Apparently `GNU gettext`_ translates the bytes according to the current locale instead of just passing them through untouched. Gustavo wanted to make Python match the GNU implementation. Barry Warsaw and Martin v. Loewis disagreed, though. Since Python's way of doing it has been that way for so long, they didn't want to break backwards-compatibility. It was also stated that code should use 'gettext.ugettext' anyway. In the end it was agreed upon that if Gustavo wanted this functionality he should add another function to 'gettext' (such as 'lgettext') that did what he wanted. .. _GNU gettext: http://www.gnu.org/software/gettext/gettext.html Contributing threads: - `Small issues in gettext support <http://mail.python.org/pipermail/python-dev/2004-April/044569.html>`__ ----------------------------------------------- And how long have you been hacking on the core? ----------------------------------------------- Anthony Baxter, fearless release manager, decided to run the Misc/ACKS file through ``cvs annotate`` which prints out who edited every line and when it was edited and then he sorted it. This was to see when people were added to the ACKS file and thus find our roughly how long people have been hacking on the Python core. The file wasn't started until January 26, 1994 so a lot of the "old-timers" don't have exact dates (of which Anthony is one of them). Yours truly was added on July 19, 2002. Contributing threads: - `today's pointless, yet slightly terrifying, factoid(s) <http://mail.python.org/pipermail/python-dev/2004-April/044574.html>`__

1 0

[ANN] PyLint 0.4.1
by Sylvain Thénault May 14, 2004

May 14, 2004

Hello all I'm pleased to announce the 0.4.1 version of pylint. This is a quick bug fix release to correct some annoyous bug of the previous version What's new ? ------------ * fix the setup.py script to allow bdist_winst (well, the generated installer has not been tested...) with the necessary logilab/__init__.py file * fix file naming convention as suggested by Andreas Amoroso * fix stupid crash bug with bad method names What is pylint ? ---------------- Pylint is a python tool that checks if a module satisfy a coding standard. Pylint can be seen as another pychecker since nearly all tests you can do with pychecker can also be done with Pylint. But Pylint offers some more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented, and much more (see http://www.logilab.org/pylint/ for the complete check list). The big advantage with Pylint is that it is highly configurable, customizable, and you can easily write a small plugin to add a personal feature. The usage it quite simple : $ pylint mypackage.mymodule This command will output all the errors and warnings related to the tested code (here : mypackage.mymodule), will dump a little summary at the end, and will give a mark to the tested code. Pylint is free software distributed under the GNU Public Licence. Home page --------- http://www.logilab.org/projects/pylint/ Download -------- ftp://ftp.logilab.org/pub/pylint/ Mailing list ------------ mailto://python-projects@lists.logilab.org -- Sylvain Thénault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org

1 0

ANNOUNCE: Rx4RDF and Rhizome 0.3.0
by Adam Souzis May 14, 2004

May 14, 2004

Rx4RDF is application stack for building RDF-based applications and web sites. Rhizome is a Wiki-like content management and delivery system built on Rx4RDF that generalizes the wiki concept in several ways. What's new? This release is focused on making Rhizome usable for running small-scale web sites: * Much improved documentation, including manuals for Rhizome, Raccoon and ZML. * Many features added to Rhizome -- it now has (nearly) all the functionality you'd expect in a full-featured Wiki. It also much easier to browse and edit the underlying RDF model (and the default template is less ugly). * Raccoon's security has been enhanced by disabling potentially dangerous settings by default and by the creation of an audit log of changes to the database. Rhizome now supports fine-grained authorization of the changes to the RDF model and provides a secure default authorization schema. In addition, there have several other enhancements, see http://rx4rdf.liminalzone.org/changelog.txt for more details. More Info: * Rx4RDF is a set of technologies designed to make RDF more accessible and easier to use. It includes: ** RxPath provides a deterministic mapping between the RDF abstract syntax to the XPath data model, allowing you to query, transform and update a RDF model with languages syntactically indentical to XPath, XSLT and XUpdate (dubbed RxPath, RxSLT, and RxUpdate respectively). ** ZML is a Wiki-like text formatting language that lets you write arbitrary XML or HTML (using Python-esque indentation rules), enabling you to author XML documents with (nearly) the same ease as a Wiki entry. ** RxML is an alternative XML serialization for RDF that is designed for easy authoring in ZML, allowing novices to author and edit RDF metadata. * Raccoon is a simple application server that uses an RDF model for its data store, roughly analogous to RDF as Apache Cocoon is to XML. Raccoon uses RxPath to translate arbitrary requests (currently HTTP, XML-RPC and command line arguments) to RDF resources, each of which can be associated with RxSLT and RxUpdate stylesheets. * Rhizome is a Wiki-like content management and delivery system built on Raccoon that takes the concept of the Wiki to the next level: everything is editable, not just content but its meta-data and behavior, even the structure of the site itself. Furthermore, wiki entries are abstract globally unique RDF resources that can have any kind of content and whose presentation is contextual. Homepage: http://rx4rdf.liminalzone.org/ Download: http://sourceforge.net/project/showfiles.php?group_id=85676 -- adam (asouzis @ user.sf.net)

1 0

ANNOUNCE: Pymqi 0.5b MQ Interface released
by Les Smithson May 14, 2004

May 14, 2004

Pymqi 0.5b is now available at http://www.hare.demon.co.uk/pymqi. This version adds support for MQ 5.3 connection handle sharing between threads. Pymqi is a Python extension for IBM's Messaging & Queueing middleware, MQSeries (aka WebSphere MQ family). This allows Python scripts to make calls directly to MQI to connect queues and get/put messages on them etc. Pymqi combines the power of Python with the benefits of the messaging model. It can be used to develop test harnesses for MQ based systems, for rapid prototyping of MQ applications, for development of administrative GUI's (when combined with e.g., TkInter), and even for mainstream MQ application development! Pymqi does not replace MQI, but is layered on top of it, so you must have MQ (either client or server) installed before you can use it.

1 0

RELEASED email 2.5.5
by Barry Warsaw May 13, 2004

May 13, 2004

I've tagged and uploaded email package version 2.5.5 which fixes a number of bugs since version 2.5.4. This version matches what will be in Python 2.3.4 final, and is therefore only useful for use with older versions of Python. It is compatible with Python 2.1.3 and newer. Please see the email-sig for more information: http://www.python.org/sigs/email-sig/ Enjoy, -Barry

1 0

RELEASED Python 2.3.4, release candidate 1
by Anthony Baxter May 13, 2004

May 13, 2004

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.3.4 (release candidate 1). Python 2.3.4 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Assuming no major problems crop up, a final release of Python 2.3.4 will follow late next week. For more information on Python 2.3.4, including download links for various platforms, release notes, and known issues, please see: ~ http://www.python.org/2.3.4 Highlights of this new release include: ~ - Bug fixes. According to the release notes, more than 20 bugs ~ have been fixed, including a couple of bugs that could cause ~ Python to crash. These were discovered by Zope3. Highlights of the previous major Python release (2.3) are available from the Python 2.3 page, at ~ http://www.python.org/2.3/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFAo3yTDt3F8mpFyBYRAicdAJwOngKitELJ25u3oCW+iQcc581wbQCgh1Ah f/Ci2omZVG7p63xY9cfZiSw= =e3Rv -----END PGP SIGNATURE-----

1 0

ANN: pygenx 0.5.2
by Michael Twomey May 13, 2004

May 13, 2004

pygenx 0.5.2 is now available: http://software.translucentcode.org/pygenx/pygenx-0.5.2.tar.gz http://software.translucentcode.org/pygenx/ What is it? ----------- pygenx is a wrapper for the genx[1] canonical[2] XML generation library. If you need a simple, fast, way of generating correct XML without worrying about escaping characters or character entities then pygenx is ideal. Example ------- #!/usr/bin/env python import genx writer = genx.Writer() fp = file("greeting.xml", "w") writer.startDocFile(fp) writer.startElementLiteral("greeting") writer.addText("Hello world!") writer.endElement() writer.endDocument() greeting.xml: <greeting>Hello world!</greeting> Why the high version number? ---------------------------- In case you are wondering why you never saw a 0.1 - 0.4 release that is because I am tracking genx's beta releases (currently beta 5), and also because this is the first version of pygenx to build and pass the test suite on all platforms I've tested it on (previously an optimisation bug in genx was causing it to fail after being built by distutils). [1] genx - http://www.tbray.org/ongoing/When/200x/2004/02/20/GenxStatus [2] canonical XML - http://www.w3.org/TR/xml-c14n mick

1 0

Config-py 1.1 Released
by dmgass＠hotmail.com May 13, 2004

May 13, 2004

config-py version 1.1 has been released and is available at SourceForge. Highlights of the changes are: 1) License changed from GPL to MIT (less restrictive) 2) Settings available as attributes of configuration instances 3) Allow user exact control of when environment keys are utilized 4) Exception class was added 5) Other (backwards compatible) interface and documentation improvements Module Description ------------------ This python module provides a simple, but extremely flexible and powerful method of controlling python script execution by use of configuration settings stored in user configuration files. This module is a more powerful alternative to the ConfigParser module already available in the standard Python distribution. The standard ConfigParser module parses text based user configuration files and provides access to that information. This module reads python based configuration files and provides access to the python objects contained within. In addition, this module supports hierarchical organization of the settings within the configuration files so that settings may be accessed using keys specified by the user from the command line or by other means. By use of python based configuration files, this module provides a simple solution to most configuration problems but also has the flexibility to solve the most complex configuration issues. Other Important Information --------------------------- License: MIT Project Home Page: http://config-py.sourceforge.net/ Download URL: https://sourceforge.net/projects/config-py/ Author/Maintainer: Dan Gass (dmgass(a)hotmail.com) <P><A HREF="http://config-py.sourceforge.net/">config-py 1.1</A> - Python based user configuration file accessor module. (13-May-04)

1 0

ANN: Vancouver Python Workshop
by Brian Quinlan May 12, 2004

May 12, 2004

Vancouver Python Workshop ========================= The Vancouver Python and Zope User Group is pleased to announce the Vancouver Python Workshop. The conference will begin on July 31st with keynote addresses by Guido van Rossum (the creator of Python) and Paul Everitt (co-founder of Zope Corp). Further talks (and tutorials for beginners) will take place on August 1st and 2nd. The conference will be roughly divided into three tracks: o Python language and applications o Content management with Python (esp. Zope and Plone) o Python for beginners More information see: http://www.vanpyz.org/conference/ or contact Brian Quinlan at: brian(a)sweetapp.com Vancouver ========= In addition to the opportunity to learn and socialize with fellow Pythonistas, the Vancouver Python Workshop also gives visitors the opportunity to visit one of the most extraordinary cities in the world (1). For more information about traveling to Vancouver, see: http://www.vanpyz.org/conference/travel.html http://www.tourismvancouver.com Important dates =============== Paper proposals accepted: May 17th to June 15th Attendee registration: June 1st to June 30th Late registration: from July 1st Keynotes, preconference sprints & tutorials: July 31st Conference and tutorial dates: August 1st and 2nd (1) http://news.bbc.co.uk/2/hi/business/2299119.stm http://www.mercerhr.com/pressrelease/details.jhtml?idContent=1128760 Cheers, Brian

1 0