Mailman 3 January 2003 - Python-announce-list

python-dev Summary for 2003-01-01 through 2003-01-15
by drifty＠bigfoot.com 17 Jan '03

17 Jan '03

+++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2003-01-01 through 2002-01-15 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ between January 1, 2003 and January 15, 2003 (inclusive). It is intended to inform the wider Python community of on-going developments on the list that might interest the wider Python community. To comment on anything mentioned here, just post to python-list(a)python.org or comp.lang.python in the usual way; give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration). 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 ninth summary written by Brett Cannon (and fashionably late, no less!). 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_; you can safely ignore it (although I suggest learning reST; its simple and is accepted for PEP markup). 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 itself. .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. contents:: ====================== Summary Announcements ====================== This summary has been written in the first-person. Aahz had suggested I write in third-person, but I just can't stand it. =) A new project named `Minimal Python`_ whose goal is to write a Python interpreter using a minimal amount of C and maximizing the amount of code written in Python. As of now it is just a mailing list but some interesting points have already been made and it has some major Python programmers involved with it so it will more than likely succeed. Leaving out `Broken strptime in Python 2.3a1 & CVS`_ for two reasons. One, the only lesson in that thread is that when C does not give you a good standard, rewrite the code in Python and come up with one. Two, since the whole thing revolves around my code I would be more biased than I normally am. =) Also, some of the threads have notes with them mentioning how I could not find them in the Mailman archive. And go to PyCon_ (especially since I am going to be giving a tutorial on reST_)! .. _Minimal Python: http://codespeak.net/mailman/listinfo/pypy-dev .. _Broken strptime in Python 2.3a1 & CVS: http://mail.python.org/pipermail/python-dev/2003-January/031983.html .. _PyCon: http://www.python.org/pycon/ =================================================== `PEP 303: Extend divmod() for Multiple Divisors`__ =================================================== __ http://mail.python.org/pipermail/python-dev/2002-December/031511.html Splinter threads: - map, filter, reduce, lambda (can't find thread in Mailman archive) As mentioned in the `last summary`_, this thread sparked a huge response to the built-ins in Python (if you don't remember what all the built-ins are, just execute ``dir(__builtins__)`` in the interpreter). It started with Christian Tismer calling for the deprecation of ``divmod()`` since he "found that divmod compared to / and % is at least 50 percent *slower* to compute", primarily because ``divmod()`` is a function and the overhead that comes from being that. Guido responded and agree that, in hindsight, "Maybe it wasn't such a good idea". But since it isn't broken he is not for replacing it since "At this point, any change causes waste". Besides, Tim Peters came up with the great compromise of removing " divmod() when [Tim's] dead. Before then, it stays." Guido would rather have the energy spent on adding the ability for the language to recognize that it "is a built-in so it can generate more efficient code". This led to Christian suggesting changing Python so that built-ins like ``divmod()`` that can easily be written in Python be done so and thus remove the C version without any backwards-compatibility issues. Guido's response was to "first make some steps towards the better compiler [Guido] alluded to. Then we can start cutting." Tim in an email said that "If we have to drop a builtin, I never liked reduce <wink>". This then led to Barry Warsaw saying he could stand to lose ``apply()``. Then Raymond Hettinger nominated ``buffer()`` and ``intern()`` as things that could stand to go away. Michael Hudson suggested ``map()`` and ``filter()``. Guido said ``apply()`` could stand getting a PendingDeprecationWarning since the new calling conventions (``fxn(*args, **kwargs)``) replace ``apply()``'s use. He almost mentioned how he wanted something like ``foo(1, 2, 3, *args, 5, 6, 7, **kw)`` since the ``5, 6, 7`` is currently not supported. But the call for the removal of ``lambda`` is what really set things off. People in support of the removal said that nested scoping removed a huge reason for having ``lambda``. But functional programmers said that they wouldn't let ``lambda`` be taken away. It was agreed it had its uses, but the name was not relevant to its use and its syntax is non-standard and should be changed in Python 3000. Someone suggested renaming it ``def``, but Guido said no since "Python's parser is intentionally simple-minded and doesn't like having to look ahead more than one token" and using ``def`` for ``lambda`` would break that design. Barry suggested ``anon`` which garnered some support. It was also suggested to have ``lambda`` use parentheses to hold its argument list like a good little function. And then all of this led to a discussion over features in Python that are not necessarily easy to read but are powerful. Some said that features such as list comprehensions, the ``*/**`` calling syntax, etc., were not good since they are not syntactically obvious. This was argued against by saying they are quite useful and are not needed for basic programming. .. _last summary: http://www.python.org/dev/summary/2002-12-16_2002-12-31.html ================== `Holes in time`__ ================== __ http://mail.python.org/pipermail/python-dev/2003-January/031836.html Tim Peters brought up an inherent problem with the new datetime_ type and dealing with timezones and daylight savings. Imagine when DST starts; the clock jumps from 1:59 to 3:00. Now what happens if someone enters a time that does not use DST? The implementation has to handle the possibility of something inputting 2:00 and instantly pushing forward an hour. But what is worse is when DST ends. You go from 1:59 back to 1:00! That means you pass over everything from 1:00 to 1:59 twice during that day. Since it is flat-out impossible to tell, what should be done in this case? Originally ``datetime`` raised a ValueError. It has now been changed to "go through 1:00am to 1:59am twice" according to Aahz. If you want to read a paper on the history of time go to http://www.naggum.no/lugm-time.html as recommended by Neil Schemenauer. .. _datetime: http://www.python.org/dev/doc/devel/lib/module-datetime.html =========================================== `no expected test output for test_sort?`__ =========================================== __ http://mail.python.org/pipermail/python-dev/2003-January/031889.html This thread was originally started by Skip Montanaro to try to figure out why ``test_sort`` was failing to catch an error when run through ``regrtest.py``. But Skip quickly realized ``regrtest.py`` was using the wrong directories. What makes this thread worth mentioning is a question I posed about whether it was worth converting tests over to PyUnit. Guido said not for the sake of converting, but if you were going to be improving upon the tests, then moving a testing suite over to PyUnit was a good idea. It was also said that all new testing suites should use PyUnit (although doctest is still acceptable, just not preferred). Walter Dörwald started `patch #662807`_ to use for converting tests to PyUnit. So give a hand if you care to. .. _patch #662807: http://www.python.org/sf/662807 ============ binutils ============ (Can't find in Mailman archive) Andrew Koenig told python-dev of a problem with binutils_ 2.13 way back in the `2002-089-16 through 2002-09-01 summary`_. Well, it appears that 2.13.2 fixes the issues. .. _2002-089-16 through 2002-09-01 summary: http://www.python.org/dev/summary/2002-08-16-2002-09-01.html =========================== The meaning of __all__ =========================== (Can't find in Mailman archive) Jack Jansen asked what the proper use of ``__all__``; a discussion on the PyObjC_ mailing list sparked this question. The answer is that ``__all__`` is used for the public API of a module. .. _PyObjC: http://pyobjc.sourceforge.net/ ====================================== PEP 301 implementation checked in ====================================== (Can't find in Mailman archive; http://mail.python.org/pipermail/python-list/2003-January/137270.html goes to python-list discussion) AM Kuchling announced that the `PEP 301`_ implementation by Richard Jones. The web server handling everything is at `amk.ca`_ off of a DSL line so don't hit it too hard. An example of how to change a Distutils ``setup.py`` file is given in the e-mail. .. _PEP 301: http://www.python.org/peps/pep-0301.html .. _amk.ca: http://www.amk.ca/cgi-bin/pypi.cgi ======================================= bz2 problem deriving subclass in C ======================================= (Can't find in Mailman archive) This thread was originally about a patch by Neal Norwitz and how to properly deal with deallocating in C code. Apparently this has nipped several people in the bum and has changed since the introduction of new-style classes. It appears that if you are deallocating a base type, you call its ``tp_dealloc()`` function; if it is a new-style class, you call ``self->ob_type->tp_free()``. ==================== `Cross compiling`__ ==================== __ http://mail.python.org/pipermail/python-dev/2003-January/031848.html (Link only part of thread; rest missing) Splinter threads: - `Bastion too <http://mail.python.org/pipermail/python-dev/2003-January/031851.html>`__ - `What attempts at security should/can Python implement? <http://mail.python.org/pipermail/python-dev/2003-January/031871.html>`__ - `Whither rexec? <http://mail.python.org/pipermail/python-dev/2003-January/031842.html>`__ - `tainting <http://mail.python.org/pipermail/python-dev/2003-January/031960.html>`__ Originally a thread about cross-compilation on OS X to Windows by Timothy Wood, this ended up changing into a thread about security in Python. As has come up multiple times before, rexec_'s lack of actual security for new-style classes came up. This then led to a question of whether Bastion_ was secure as well. The answer was no and have now been subsequently sabotaged on purpose by Guido; they now require you to manually edit the code to allow them to work. A discussion on how to make Python secure came up. Various points were made such as how to deal with introspection and how people might try to get around being locked out of features. Tainting was also mentioned for strings. If you need some security in your app, take a look at mxProxy_. Its design is similar to how Zope3_ handles security. .. _rexec: http://www.python.org/doc/current/lib/module-rexec.html .. _Bastion: http://www.python.org/doc/current/lib/module-Bastion.html .. _mxProxy: http://www.egenix.com/files/python/mxProxy.html .. _Zope3: http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/FrontPage =========================== `tutor(function|module)`__ =========================== __ http://mail.python.org/pipermail/python-dev/2003-January/031893.html (Only part of thread; rest missing from archive) Christopher Blunk proposed the idea of having a built-in ``examples()`` function or something similar that would spit out example code on how to use something. There was a discussion as to whether it was reasonable for Python to try to keep up a group of examples in the distribution. It was agreed, though, that more code examples would be good to have *somewhere*. One place is in the Demo_ directory of the source distribution. Problem with that is it is only available in the source distribution and it is not vigorously maintained. Both of these are solvable, but it didn't look like anyone was taking the reigns to cause this to happen. Another was to push people to give to an online repository (such as the `Python Cookbook`_) to keep it centralized and accessible by anyone. Problem with that is it creates a dependency on something outside of PythonLab's control. The last option was adding it to the module documentation. This is the safest since it means it becomes permanent and everyone will have access to it. But it has the same drawback as all of these other suggestions; you can't access it in the interpreter as easily as you can ``help()``. The thread ended with no conclusion beyond cleaning up the ``Demos`` directory and adding more examples to the official documentation would be nice. .. _Demo: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Demo/ .. _Python Cookbook: http://aspn.activestate.com/ASPN/Python/Cookbook/ ========================================= `PEP 297: Support for System Upgrades`__ ========================================= __ http://mail.python.org/pipermail/python-dev/2003-January/031838.html MA Lemburg asked if Guido would be willing to let an implementation of `PEP 297`_ into Python 2.3. He said yes and would also be willing to add it to 2.2.3 and even 2.1.4 if that version ever comes about. A discussion of how to handle the implementation began. The agreed upon directory name became ``site-package-<Python-version>`` with ``<Python version>`` being the full version: major.minor.micro. ``site.py`` will be modified so that if the current version of Python is different from the version of the directory that it won't add it to ``sys.path``. There was the brief idea of deleting the directory as soon as the version did not match, but that was thought of being harsh and unneeded. .. _PEP 297: http://www.python.org/peps/pep-0297.html ================================ `PyBuffer* vs. array.array()`__ ================================ __ http://mail.python.org/pipermail/python-dev/2003-January/031841.html (Only part of thread; rest missing from archive) Splinter threads: - `Slow String Repeat <http://mail.python.org/pipermail/python-dev/2003-January/031895.html>`__ Bill Bumgarner asked whether ``PyBuffer*`` or ``array.array()`` was the proper thing to use because one is like a huge string and the other is unsigned ints. Guido basically said to just use strings like everyone else for byte storage. Bill said he would just live with the dichotomy. This thread also brought up a question of performance for the code ``array.array('B').fromlist([0 for x in range(0, width*height*3)])``. Was cool to watch various people take stabs as speeding it up. Written in Python, the fast way was to change it to ``array.array('B', [0])*width*height*3``; doing several decent-sized calls minimized ``memcpy()`` calls in the underlying C code. Raymond Hettinger came up with a fast way to do it in C. ========================== `new features for 2.3?`__ ========================== __ http://mail.python.org/pipermail/python-dev/2003-January/031837.html Neal Norwitz wanted to get the tarfile_ module into Python 2.3. This led to Guido saying he wanted to get Docutils_ and better pickling for new-style classes in as well. The Docutils idea was shot down because it was stated it currently is not ready for inclusion. 2.4 is probably the version being shot for. The pickle idea raised security ideas (this is becoming a trend for some reason on the list lately). In case you didn't know, you shouldn't run pickled code you don't trust. .. _tarfile: http://python.org/sf/651082 ================ `sys.path[0]`__ ================ __ http://mail.python.org/pipermail/python-dev/2003-January/031896.html Thomas Heller had a question about the documented handling of ``sys.path[0]``. This quickly led to the point that the value, when specified and not the empty string, is a relative path; not necessarily the desired result. And so `patch #664376`_ was opened to make it be absolute. .. _patch #664376: http://www.python.org/sf/664376 =================== `Misc. warnings`__ =================== __ http://mail.python.org/pipermail/python-dev/2003-January/031884.html MA Lemburg noticed that ``test_ossaudiodev`` and ``test_bsddb3`` were not expected skips on his Linux box. He wondered why they were not exepected to be skipped on his platform. This led to a discussion over the expected skip set and how it is decided what is going to be skipped (experts on the various OSs make the call). ============================== `Raising string exceptions`__ ============================== __ http://mail.python.org/pipermail/python-dev/2003-January/031907.html It looks like string exceptions are going to raise PendingDeprecationWarning; you have been warned. ====================== `PEP 290 revisited`__ ====================== __ http://mail.python.org/pipermail/python-dev/2003-January/032003.html Kevin Altis was cleaning up wxPython_ and all the references to the ``string`` module and pointed out that the stdlib probably could stand to have a similar cleaning as well. Guido said, though, that it is better to choose a module you are familiar with and do a complete style clean-up instead of doing a library-wide clean-up of a single thing. .. _wxPython: http://www.wxpython.org/ ============================ `Assignment to __class__`__ ============================ __ http://mail.python.org/pipermail/python-dev/2003-January/032016.html Kevin Jacobs got bitten by the change to non-heap objects that prevents the assigning to ``__class__`` (it was recently backported to the 2.2 branch). He asked if there was any way to bring it back; Guido said no because of various layout issues in the C struct and such. ================================= `Parallel pyc construction`__ ================================= __ http://mail.python.org/pipermail/python-dev/2003-January/032060.html Paul Dubois ran into an problem on a 384 processor system with .pyc file corruption. He wanted a way to just skip the creation of .pyc files entirely since his programs run for so long that initial start-up times are inconsequential and that is the point of .pyc files. Neal Norwitz is working on `patch #602345`_ to implement a command-line option. .. _patch #602345: http://www.python.org/sf/602345 ============================================== `Extension modules, Threading, and the GIL`__ ============================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032017.html This thread was briefly mentioned in the `last summary`_. But it had changed into a discussion of Python external thread API. Mark Hammond commented how he had bumped up against its limitations in multiple contexts. Mark thought it would be useful to define an API where one wanted the ability to say "I'm calling out to/in from an external API". This would be a large project, though, and so Mark was not up to doing it on his own. David Abrahams, though, stepped up and said he was willing to help. So did Anthony Baxter. Tim Peters had his own twist by wanting to be able to call from a thread into a Python thread without knowing a single thing about that state of Python at that point, e.g. don't even know that that interpreter is done initializing. Mark saw the way to go about solving all of this by writing a PEP, write a new C API to solve this issue that is optional and used by extension modules wanting to use the new features, and then define a new TLS (Thread Local Storage; thank you acronymfinder.com). Mark thought the TLS would only be needed for thread-state. Someone suggested ACE_ as a TSS (Thread State Storage) implementation which can cover all the platforms that Python needs covered. But Mark suggested coming up with a "pluggable TLS" design. .. _ACE: http://doc.ece.uci.edu/Doxygen/Beta/html/ace/classACE__TSS.html ============================================ `Interop between datetime and mxDateTime`__ ============================================ __ http://mail.python.org/pipermail/python-dev/2003-January/032100.html MA Lemburg expressed interest in trying to get mxDateTime_ to play nice with datetime_. The idea of having a base type like the new basestring in Python 2.3 was suggested. But there was pickling issues with datetime, MA wanting to keep mxDateTime compatible with Python 1.5.2, and getting everyone to work in a consistent way through the base type. Another instance where interfaces would be handy. .. _mxDateTime: http://www.lemburg.com/files/python/mxDateTime.html =========================== `properties on modules?`__ =========================== __ http://mail.python.org/pipermail/python-dev/2003-January/032106.html Neil Schemenauer wanted to be able to make module variables be properties. Samuele Pedroni stepped up and said the issue for this to work was "about instance-level property apart the module thing details". He also pointed out that it would mean you could directly import a property which would cause unexpected results, thus killing the idea. Guido was disappointed he didn't get to wield his BDFL pronouncement stick and smack the idea down <wink>. ====================================== `Fwd: Re: PEP 267 improvement idea`__ ====================================== __ http://mail.python.org/pipermail/python-dev/2003-January/032165.html Oren Tirosh forwarded an e-mail from python-list(a)python.org to python-dev about `PEP 267`_ and various strategies. One was using negative keys for signaling guaranteed key lookup failure. Oren also played with inlining. He also said that since interned strings are now out of Python as of 2.3 (thanks to Oren) that the namespace could "have only interned strings as entry keys and avoid the need for a second search pass on first failed lookup". He even considered creating a special dict type for namespaces. .. _PEP 267: http://www.python.org/peps/pep-0267.html

1 0

ANNOUNCE: SCons 0.10 is now available
by Steven Knight 16 Jan '03

16 Jan '03

SCons is a software construction tool (build tool, or make tool) written in Python. It is based on the design which won the Software Carpentry build tool competition in August 2000. Version 0.10 of SCons has been released and is available for download from the SCons web site: http://www.scons.org/ Or through the download link at the SCons project page at SourceForge: http://sourceforge.net/projects/scons/ RPM and Debian packages and a Win32 installer are all available, in addition to the traditional .tar.gz and .zip files. WHAT'S NEW IN THIS RELEASE? IMPORTANT: Release 0.10 contains the following interface changes: - The meaning of the third argument passed to user-defined Scanner functions has changed. It was formerly the target node being built, and is now a list of directories (a path) which may be searched for files found during the scan. - The .sconsign files are no longer ASCII text, they are now a pickled (binary) Python data structure. This release adds the following features: - SCons now prints a description of Python functions being executed as actions to update a target. - Scanners now support a "recursive" attribute that specifies the Scanner will be re-applied to files found during the scan. - A new Clean() method supports removing user-specified files when using the -c option. - New SetJobs() and GetJobs() method support setting or fetching the default number of jobs. - The MinGW tool chain is now supported. - A new --debug=includes option has been added. The following fixes have been added: - SCons now symlinks or copies files from Repositories on different file systems, when hard links won't work. - The Install() method prints something when the -n option is used. - When the -n option is used, SCons no longer creates duplicate source files in a BuildDir(). - The Program() Builder (and other multiple-step Builders) now work properly when only the source file is specified. - A bug when building a file whose basename matched the directory in which it lived has been fixed. - The -c options will now properly remove symlinks. - The Environment.get() now returns None by default. - Error messages now all start with "scons: ***". - Warning messages now all start with "scons: warning:". Performance has been improved as follows: - Scanners are now called once and only once per file. - Internal checks for whether a file has a Builder have been significantly sped up. - Unnecessary internal imports have been removed. The following changes have been made to the SCons packaging: - The scons-local packages no longer contain Python bytecode (*.pyc) files. The documentation has been improved: - The initial explanation of SConscript files has been improved. - A misformatted table in the StaticObject description has been fixed. - New features have been documented. ABOUT SCONS Distinctive features of SCons include: - a global view of all dependencies; no multiple passes to get everything built properly - configuration files are Python scripts, allowing the full use of a real scripting language to solve difficult build problems - a modular architecture allows the SCons Build Engine to be embedded in other Python software - the ability to scan files for implicit dependencies (#include files); - improved parallel build (-j) support that provides consistent build speedup regardless of source tree layout - use of MD5 signatures to decide if a file has really changed; no need to "touch" files to fool make that something is up-to-date - easily extensible through user-defined Builder and Scanner objects - build actions can be Python code, as well as external commands An scons-users mailing list is available for those interested in getting started using SCons. You can subscribe at: http://lists.sourceforge.net/lists/listinfo/scons-users Alternatively, we invite you to subscribe to the low-volume scons-announce mailing list to receive notification when new versions of SCons become available: http://lists.sourceforge.net/lists/listinfo/scons-announce ACKNOWLEDGEMENTS Special thanks to Derrick 'dman' Hudson, Steve Leblanc, Lachlan O'Dea, and Anthony Roach for their contributions to this release. On behalf of the SCons team, --SK

1 0

ANN: NCBI EUtils client
by Andrew Dalke 16 Jan '03

16 Jan '03

We have developed a client-side interface to NCBI's "EUtils" server, which is a web service for querying their Entrez databases, including GenBank and PubMed. It is available from http://www.dalkescientific.com/EUtils/ and distributed under the Biopython license, http://www.biopython.org/License.shtml Example: Get all protein sequences related to protein GI:4579714 >>> import EUtils >>> from EUtils import HistoryClient >>> client = HistoryClient.HistoryClient() >>> result = client.post(EUtils.DBIds("protein", "4579714")) >>> related = result.neighbor_links("protein") >>> related_dbids = related.linksetdbs["protein_protein"].dbids >>> proteins = client.post(related_dbids) >>> len(proteins) 223 >>> infile = proteins.efetch(retmode = "text", rettype = "fasta") >>> >>> fasta = infile.read() >>> print fasta[:788] >gi|27450749|gb|AAO14677.1|AF508258_1 rhodopsin [Pyrocystis lunula] MAPIPDGFTYGQWSLVYNSLSFGIAGMGCATIFFWLQLPNVSKSYRTALTITGLVTAIATYHYVRIFNSW VDAFKVVNVNGGDYTVTLLGAPFNDAYRYVDWLLTVPLLLIELILVMKLPKAETVKLSWNLGVASAVMVA LGYPGEIQDDLLVRWFWWAMAMIPFYYVVVTLVNGLSDATAKQPDSVKSLVVTARYLTVISWLTYPGVYI IKSMGLAGNIATTYEQVGYSVADVVAKAVFGVLIWAIAAGKSDEEEKNGLLG >gi|6319528|ref|NP_009610.1| Homolog to HSP30 heat shock protein Yro1p; Yro2p [Saccharomyces cerevisiae] MSDYVELLKRGGNEAIKINPPTGADFHITSRGSDWLFTVFCVNLLFGVILVPLMFRKPVKDRFVYYTAIA PNLFMSIAYFTMASNLGWIPVRAKYNHVQTSTQKEHPGYRQIFYARYVGWFLAFPWPIIQMSLLGGTPLW QIAFNVGMTEIFTVCWLIAACVHSTYKWGYYTIGIGAAIVVCISLMTTTFNLVKARGKDVSNVFITFMSV IMFLWLIAYPTCFGITDGGNVLQPDSATIFYGIIDLLILSILPVLFMPLANYLGIERLGLIFDEEPAEHV GPVAEKKMPSPASFKSSDSDSSIKEKLKLKKKHKKDKKKAKKAKKAKKAKKAQEEEEDVATDSE >>> Andrew Dalke dalke(a)dalkescientific.com -- Need usable, robust software for bioinformatics or chemical informatics? Want to integrate your different tools so you can do more science in less time? Contact us! http://www.dalkescientific.com/

1 0

Flightdeck-UI MVM 0.1.2 + Library 0.1.5 released
by fdui＠openlight.com 16 Jan '03

16 Jan '03

*** The Flightdeck-UI project is looking for testers and user feedback *** on all platforms. If you come up with your own themes and control *** files, they may be included in the distribution. In addition, *** links to good screenshots can be added to the Flightdeck-UI site. *** The MVM application can also show your name, organization, URL and *** a brief description for any control file or theme that you create. The goal of the Flightdeck-UI project is to apply ideas from aircraft instrumentation design to general purpose user interfaces. New features added to MVM allow any numerical value published on almost any website to be monitored by the application. Example control files (supplied with the distribution) illustrate the monitoring of current outdoor temperatures in the U.S. and Europe. MVM can be quickly configured to track data from several sources (for example your favorite stock, the local weather, the number of visits to your website, etc.). It will then sit in some corner of your desktop, allowing you to read this information with an occasional glance. MVM includes a graphical editor and theme support. Go see the screenshots at "http://www.openlight.com/fdui/screens.html". MVM is built on top of the Flightdeck-UI library, which provides widgets based on the basic instruments of flight. See the project homepage ("http://www.openlight.com/fdui/") to download the software, read more information on the current as well as future Flightdeck-UI widgets, learn the rationale behind the MVM monitoring approach, etc. The README files for both the application and the library, as well as two whitepapers are available from the project homepage. MVM and the Flightdeck-UI library are both open source/free software. They have been tested under Linux (RedHat 7.2) and a little under Windows 95. Questions can be emailed to originator of this message. Your ideas and participation will be appreciated!

1 0

How-To install and use PSO services under Windows NT/2000/XP
by thanos＠0x01.com 15 Jan '03

15 Jan '03

A new document by Vadim Shaykevich showing how to install and use PSO services under Windows NT/2000/XP http://sourceforge.net/docman/display_doc.php?docid=14746&group_id=49265

1 0

Python Success Stories
by Stephan R.A. Deibel 15 Jan '03

15 Jan '03

Hi, Archaeopteryx sponsors a Python Advocacy website and we've just released the first batch of Python Success Stories that we've collected as part of this effort: http://pythonology.org/success Many of these will also appear in printed form in a booklet from O'Reilly Associates. The stories can be reused on other websites. If you are interest in doing so please see: http://pythonology.com/success&help=1 Or, if you want to contribute your own story, see: http://pythonology.com/successguide Thanks, - Stephan ------------------------------------------------------------------------ Wing IDE for Python Archaeopteryx Software, Inc www.wingide.com Take Flight!

1 0

The Year In Scripting Languages Lua/Perl/Python/Ruby/Tcl 2002
by Mitchell N Charity et al 14 Jan '03

14 Jan '03

This is a joint review of 2002 for the programming languages Lua, Perl, Python, Ruby, and Tcl. It was a cooperative effort by people from the five communities. An HTML version is available at http://www.vendian.org/language_year/ . - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Lua in 2002 2002 was a very busy year for Lua [1]. A major new version (5.0) was discussed, planned, implemented, and released in alpha and beta versions. We also saw a marked increase of the size and participation of the Lua community. Details on this and other events that happened to Lua in 2002 follow. * Work on a new version The plans for a new version (4.1) and their discussion in the mailing list [2], which had officially started with the release of an alpha version in July 2001 and several work versions since then, finally converged to a comprehensive mature proposal for Lua 5.0 in April. An alpha version was released in August and a beta version was released on December; the final version of Lua 5.0 expected to be released by February 2003. Lua 5.0 is an important step in the evolution of Lua (hence the leap from 4.0 directly to 5.0). Lua 5.0 includes several new features, such as lexical scoping, Lua coroutines and support for external multithreading and coroutines, metatables and metamethods, fine control of global name resolution, tail calls, fast register-based virtual machine, safe garbage-collector metamethods, new error handling protocol, and more. All this is of course done respecting our design goals: simplicity, efficiency, portability, and low embedding cost. * Choosing a new license Starting with Lua 5.0, Lua will be released under the MIT license [3]. Up to now we had our own license [4], very similar to but not identical to the zlib license [5] and others. The community pointed to us that the license was sometimes a source of confusion and misunderstanding. So we decided that having a standard license would clear the issue and allow more people, specially in the industry, to choose Lua without being concerned with legal matters. * Community participation The active participation of the Lua community -- both in the mailing list and in the lua-users wiki [6] -- was an important ingredient in making all this happen. The community is also organizing itself. Since May, it maintains a web interface to the mailing list archive [7] that can be searched and also referred to in lua-l: postings now have a permanent link and this helps to answer recurring questions. This web interface is much faster than the one at Yahoo Groups that exists since March 1999 (and also has no annoying ads). A newsgroup interface to the mailing list [8] was created at gname.org in July by their own initiative. The mailing list remains the premier forum for discussing Lua. It has now over 700 subscribers (435 direct subscribers plus 284 registered at Yahoo Groups). Novice and experts participate actively in the discussions, which are instructive and friendly. The wiki at lua-users also experienced a marked growth in 2002 and is becoming a major source of detailed technical information about Lua, some of it distilled and condensed from lua-l postings. Many people contributed new pages, corrected and expanded existing ones, and helped to maintain several pages moved from www.lua.org. The wiki also now contains the details and implementations of feature proposals. As intended when it was launched, the wiki has become the ideal companion for the mailing list. A small part of the community got together in person in February, at a Lua Library Design Workshop [9] held at Harvard University. The move in Lua 5.0 to namespaces in libraries was one consequence of this meeting. The workshop also provided an opportunity to meet Roberto Ierusalimschy [10], Lua's chief architect. * Lua in 2003 2003 will bring the official release of Lua 5.0 and also probably Lua 5.1, at least in work stage. Our main focus in Lua 5.1 is the implementation of incremental garbage collection to replace the current atomic mark-and-sweep. The need for this was identified by the community, specially those using Lua for games. We shall probably also see a new draft of the long-waited Lua book by Roberto, updated for Lua 5. * References 1. http://www.lua.org/ 2. http://www.lua.org/lua-l.html 3. http://www.lua.org/license.html 4. http://www.lua.org/copyright.html 5. http://www.opensource.org/licenses/zlib-license.html 6. http://lua-users.org/wiki/ 7. http://lua-users.org/lists/lua-l/ 8. http://news.gmane.org/thread.php?group=gmane.comp.lang.lua.general 9. http://lua-users.org/wiki/LuaLibraryWorkshop 10. http://www.lua.org/authors.html - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Perl While 2002 was a year during which the Perl 6 design development process grown up, Perl 5 was not left behind. A new major version, Perl 5.8.0, was released, introducing major features. * Perl 5.8.0 released Perl 5.8.0 was released after more than two years of work. Among its new features [1], the most important ones are a full support for Unicode, a new implementation of threads, a completely reworked I/O subsystem, and support for 64-bit architectures. This release was also a personal win from the point of view of the Perl developers, because it was extensively tested, due to a much improved test suite, and to volunteers to run it on a daily basis on a wide range of OSes and configurations. There's also more in Perl than Perl itself. Numerous projects based on Perl have also started or have significantly evolved. Among them, I have to mention at least the popular mod_perl Apache module [2] which allows to embed Perl into a web server. * The Community The Perl community is so dynamic and well-organized that I can't choose where to begin. Well, the spinal nerve of this community is probably the Comprehensive Perl Archive Network (or CPAN [3]), central repository for a whole universe of Perl modules. But the community is organized among several axes : on Internet, you'll find an extensive set of mailing lists [4], newsgroups in the comp.lang.perl.* hierarchy, news and weblogs [5], help and idea sharing for beginners and for gurus at perlmonks [6], and I'm sure I'm forgetting a load of resources. There are also two noticeable high-quality publications : the Perl Review [7] and the Perl Journal [8]. In the real world, numerous Perl users groups (known as the Perl mongers [9]) have succeeded in cementing this community as well as promoting the language. Among the factual successes are the organization of the Yet Another Perl Conferences [9], that will continue in 2003, and the funding of the Perl 6 core team through the Perl Foundation [10] (Perl 6 being the next major step in Perl, redesigned and reimplemented from the ground up). * Perl 5 in 2003 The development version of Perl (5.9.0) is being actively worked on, and development releases are to be expected, as well as a new maintenance release, Perl 5.8.1, aimed at fixing the most outstanding bugs discovered in Perl 5.8.0. Currently, it appears that those bugs pertain (quite logically) to the newest features : threads and Unicode. The to-do lists are not small, and, with the start of the Perl 6 project, Perl needs contributors more than ever : as a popular saying reminds us, patches are welcome. If you want to follow what's happening in the world of Perl development, you can read the weekly summaries of the developers' mailing lists, published on perl.com [11] for Perl 6 and Parrot (Parrot being the future Perl 6 virtual machine) and on use.perl [5] for Perl 5. In the process we hope to bring Perl to higher levels to maturity, and to have fun. At least that's how the future looks from there. * References 1. http://dev.perl.org/perl5/news/2002/07/18/580ann/ 2. http://perl.apache.org/ 3. http://cpan.org/ 4. http://lists.perl.org/ 5. http://use.perl.org/ 6. http://www.perlmonks.org/ 7. http://www.theperlreview.com/ 9. http://www.tpj.com/ 9. http://www.yapc.org/ 10. http://www.perl-foundation.org/ 11. http://www.perl.com/ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Python: Year in Review The Python community spent a good part of 2002 learning how to use new-style classes, introduced with Python 2.2, and polishing their implementation with a couple of maintenance releases. We also released an alpha version of Python 2.3 on the last day of the year. * Python 2.2 released The major new feature of Python 2.2, which was actually released just before Christmas 2001, is new-style classes. This feature eliminates many of the differences between Python's builtin types (list, dict, &c.) and user-defined types implemented with class statements. It allows programmers to subclass builtin types in Python and makes it easier to define new classes in C. New-style classes introduced many subtle differences in class semantics and many new features for classes, including a super function, class and static methods, and properties. Backwards compatibility was addressed in a fairly clean way: Both new-style classes and so-called "classic" classes are available in the interpreter via different metaclasses. The classic metaclass is used unless the class inherits from the new builtin type "object" or explicitly declares its metaclass. See Guido van Rossum's essay "Unifying types and classes in Python 2.2" for a more thorough discussion of new-style classes. http://www.python.org/2.2.2/descrintro.html There were four maintenance releases during the calendar year. The currently recommended versions of Python are 2.2.2 and 2.1.3. The 2.2.2 release seems to be quite stable, with more than 100 bugs fixed since the original 2.2 release. The 2.1.x releases this year fixed a few critical bugs. * Python in 2003 The goals for Python 2.3 are modest compared to new-style classes. The alpha release on Dec. 31 introduced only minor language changes, like a new boolean type. Most of the improvements are to the standard library, including a new BerkeleyDB interface, a logging module styled after log4j, a family of new datetime types, a pair of set types, and a new random number generator (Mersenne Twister). The module import mechanism was also improved, with a new set of hooks and support for zip archives. The custom object allocator, which has been an optional, compile-time feature for a couple of releases, has been enabled by default for 2.3. It is a fast, special-purpose allocator for small blocks that sits on top of the platform malloc. It saw a major overhaul to improve stability and performance between 2.2 and 2.3 See Andrew Kuchling's "What's New in Python 2.3" document for more information about the release. http://www.python.org/doc/2.3a1/whatsnew/ One reason (among many) for the more modest goals of Python 2.3 is a sense in the community that the language is changing too quickly. The perception of a large or vocal part of the community is that stability, performance, and libraries will provide more benefit than new core language features. When Guido proposed the addition of a boolean type on comp.lang.python, the thread ran on for a couple of weeks and 375 messages with a vigorous opposition. It seems fair to observe, however, that many people believe that Python changes too quickly and that the new features they need are important enough to add anyway. * Notable developments The year saw a lot of development activity in the larger Python community. I've tried to include some highlights from important or interesting projects, but I'm sure there are omissions. - Boost.Python version 2, a C++ library that enables seamless interoperability between C++ and Python http://www.boost.org/libs/python/doc/ - Chandler, Mitch Kapor's foundation announced plans to develop a personal information manager written in Python http://www.osafoundation.org/ - Leo, an outlining editor that doubles as a programmer's editor and a literate programming tool http://sourceforge.net/projects/leo/ - Mailman 2.1, a mailing list manager http://www.list.org/ - omniORBpy 2.0, a robust high performance CORBA ORB for Python http://omniorb.sourceforge.net/ - Pyrex, a specialized language for writing C extension modules that extends Python with C datatype declarations http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ - Psyco 0.4.1, a specializing compiler for Python http://psyco.sourceforge.net/ - reStructuredText, the long-awaited markup language for Python docstrings and almost any other kind of text http://docutils.sourceforge.net/rst.html - Twisted 1.0, an event-driven networking framework http://twistedmatrix.com/ - Wing IDE 1.1 and up, a development environment for Python http://wingide.com/ - wxPython, a cross platform GUI toolkit based on wxWindows http://wxpython.org/ - Zope 2.5, 2.6, and an alpha release of Zope 3 an application server specializing in content management http://www.zope.org/ Four Python conferences were held in 2002, including a couple of European conferences. Many new books were published including the well-regarded Python Cookbook and the first two books on Jython, the Java implementation of Python. * Keeping up with Python news Some valuable summarizes in increasing order of frequency: Bi-weekly summaries of python-dev mailing list http://www.python.org/dev/summary/ Dr. Dobb's (weekly) Python URL http://www.ddj.com/topics/pythonurl/ Daily Python URL http://www.pythonware.com/daily/index.htm - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ruby.year(2002): A report from the Ruby community Ruby [1] continued to delight its practitioners and, perhaps, tempt those who work in other languages, throughout 2002. Increased traffic on the ruby-talk mailing list suggests that more and more people from around the world are discovering Ruby and the joys it brings to programming, and visions of Ruby's future have enthused Rubyists everywhere. * Web Application Development with Ruby Web application development with Ruby is beginning to come into its own, and many web development tools achieved milestone stability releases. Web developers now have several options, including eRuby [2] (for embedding Ruby code directly into HTML documents), Amrita [3] (an alternative that uses templates to cleanly separate logic and presentation) and complete site-development frameworks like CGIKit [4] and ILE [5]. The mod_ruby [2] module for Apache is also fast and stable. * Virtual Machines The quest for improved performance also sparked a number of new Ruby projects. There are now several virtual machine (VM) development efforts, including Cardinal [6] (a Ruby front-end to Parrot), JRuby [7] (a Java implementation of the Ruby interpreter) and an as-yet-unnamed VM that Matz, the creator of Ruby, and his co-conspirators are keeping a closely guarded secret. * Improved Support for Windows and Mac OS X A lot of focus has been placed on enhancing Ruby's usability with non-Unix operating systems. The Ruby distribution for Windows [8] includes many popular Ruby extensions, as well as an HTML Help version of Thomas and Hunt's Programming Ruby, providing a very easy way for users to get up and running with either the stable or development release of Ruby. Also, beginning with the 10.2 (Jaguar) release, Ruby is now a standard part of the Mac OS X operating system. * New Versions The year ended with the release of Ruby 1.6.8, which is promised to be the last release in the 1.6.x series. The end of 2002 also saw a "preview" release of Ruby 1.8. In addition to enhancements in the Ruby language itself, the upcoming 1.8 release will incorporate several new modules into Ruby's standard library. Test::Unit [9], a rock-solid, object oriented automated unit testing framework will be included in the standard distribution. Another planned addition is REXML [10], a clean and intuitive XML processing library. * Ruby in Print There were many signs of the rising popularity of Ruby in 2002. A number of new English language books, such as Ruby in a Nutshell (Yukihiro Matsumoto), Teach Yourself Ruby in 21 Days (Mark Slagell), The Ruby Way (Hal Fulton) and Ruby Developer's Guide (Michael Neumann, Robert Feldt and Lyle Johnson), were published this year. In Japan, an additional 11 Ruby books were published (bringing the total in Japanese to 27). * Ruby Conference A notable event was the second annual Ruby Conference, held in November 2002 in Seattle, WA, USA. There were about fifteen presentations, as well as a keynote speech by Matz. Slides of those talks are available online at http://www.zenspider.com/Languages/Ruby/RubyConf2002/ . * Ruby in 2003 The upcoming year promises a number of exciting new developments. In addition to the previously mentioned Ruby 1.8, one of the most eagerly anticipated projects is FreeRIDE [11], a powerful cross-platform IDE for Ruby. This software is being designed and built by a large group of volunteers and is itself a great testimony to the strong spirit of the Ruby community. * Challenges In addition to the many successes, we as a community face a number of challenges. One is the need for better documentation and documentation tools. A related problem that a good deal of the documentation for Ruby libraries is only available in Japanese, and as a result there is substantial interest in having English translations of those texts. Another challenge for the Ruby community is the need for more well defined methods of packaging and distribution for Ruby libraries and extension modules. * More about Ruby Ruby's home page is the official source for downloads as well as information about CVS and mailing list access. The newly redesigned Ruby Application Archive [12] is an online catalog of Ruby libraries and extension modules. The Ruby Weekly News [13] is posted every week to the ruby-talk mailing list and provides a nice summary of what people are talking about. For a more comprehensive account, archives of the mailing list [14] are available as well. Finally, an important resource for Ruby developers is the Ruby Garden [15]. The Ruby Garden is a portal site that provides message boards, online polls and links to other popular Ruby web sites including the Ruby Garden Wiki [16]. * References 1. http://www.ruby-lang.org/ 2. http://www.modruby.net/ 3. http://www.brain-tokyo.jp/research/amrita/ 4. http://www.spice-of-life.net/download/cgikit/index_en.html 5. http://virtualschool.edu/ile/ 6. http://www.rubygarden.org/ruby?CardinalProject 7. http://jruby.sourceforge.net/ 8. http://rubyinstaller.sourceforge.net/ 9. http://testunit.talbott.ws/ 10. http://www.germane-software.com/software/rexml/ 11. http://www.rubyide.org/ 12. http://www.ruby-lang.org/raa/ 13. http://www.rubygarden.org/rurl/html/index.html 14. http://blade.nagaokaut.ac.jp/ruby/ruby-talk/index.shtml 15. http://www.rubygarden.org/ 16. http://www.rubygarden.org/ruby?HomePage - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tcl 2002 was a significant year for the Tcl community - culminating in the release of Tcl/Tk 8.4 after a long gestation period. * Tcl 8.4 released The 8.4 release includes a number of significant features, including * a new Virtual File System (VFS) layer that allows (in principle) filesystem activity to be diverted away from the native operating system to something else; drivers exist for a number of underlying "access methods", including FTP, HTTP, Metakit, WebDAV, etc. * 64 bit support - both files and arithmetic, also on 32-bit systems * major performance improvements - 8.4 is the fastest Tcl version yet * enhanced thread support, stability, and performance * Unicode and I18N improvements * three new Tk widget types, most other widgets have been enhanced * native MacOS X Aqua support Details of these and other changes can be found at [1]. Or start your Tcl explorations from this new URL (redirect): http://www.tcl.tk/ The other significant development in the Tcl world was in the area of portability and deployment. The introduction of VFS to the core enables Starkits [2], which provide easy single-file deployment of applications and packages (like Java jar files, but with more power). They can be interpreted using either Tclkit, a single file Tcl/Tk interpreter available on numerous platforms, or ActiveTcl, the ActiveState Tcl distribution. An archive of Starkits is available at [3]. * The Community The Tcl community continues to be an active and vibrant group of very diverse characters, supported by a number of forums: * Tclers' Wiki - over 3500 pages of useful information (mostly, but not exclusively) related to Tcl/Tk and associated technology [4] * Tclers' Chat, typically with a number of Tcl "experts" online at most times - available by browser [5] or a tkchat application [6] * comp.lang.tcl newsgroup and mailing lists, see selection at [7] * Tcl-URL! - a summary of highlights posted weekly on comp.lang.tcl The Tcl community holds on to its tradition of welcoming both newbies and interaction with people from other language communities. A good starting point is the comp.lang.tcl newsgroup. * Notable developments The last year saw the continued use of Tcl/Tk in a very wide variety of applications (both Open Source and commercial), including: * ActiveTcl / TclDevKit / Komodo - Tcl/Tk core and tools development at ActiveState [8] * the Tcl/Tk Plugin - revival of web browser plugin based on Tcl/Tk 8.4 and taking advantage of new features [9] and supporting both Internet Explorer and Mozilla (on a wide variety of platforms) * Tclkit - standalone single-file runtime with Tcl, Tk, Incrtcl, Metakit, TclVFS, zlib [11] * AOLServer - high-performance web/content server used by AOL [10] * Critcl - embedding C/C++ in Tcl, on-the-fly compiled or precompiled for easy deployment [12] * gnocl - is a GTK+ and Gnome extension that provides easy to use commands to quickly build GTK+ and Gnome compliant user interfaces, it interoperates with Tk [19] * InstallBase - a multi-platform GUI installer in Tcl/Tk and designed to work on Windows, Mac, and almost any flavor of UNIX / Linux [18] * MOODS - graphical monitoring application for Linux [13] * Privaria - a Secure, Firewall-Friendly Platform for Peer-to-Peer Networking [14] * SnackAmp - a multi-platform audio music (mp3, ogg ,wav ...) player and organizer for large music collections [15] * TCLBridge - a powerful component designed to allow seamless integration of Tcl/Tk and any ActiveX capable language, such as Visual Basic 6 and any of the Microsoft .NET languages [16] * Toucan - a Desktop IDE for developing Palm OS applications [17] * Wikit - a wiki implementation used to power the Tclers' Wiki, but also can be used to embed a wiki in applications for documentation/help [20] There are more applications and extensions than space to mention them. See news:comp.lang.tcl.announce for an overview. * Tcl in 2003 2003 is likely to be a year of consolidation - Tcl/Tk 8.4.1 is out, solid, and becoming the standard Tcl version; plans for 8.5 and/or 9 are under consideration. The coming year is also likely to see more work in the area of repositories/archives, more interfaces to other languages for Tcl/Tk, and yet more platforms supported. * References 1. http://www.tcl.tk/software/tcltk/8.4.html 2. http://www.equi4.com/starkit 3. http://mini.net/sdarchive/ 4. http://wiki.tcl.tk/ 5. http://mini.net/cgi-bin/chat.cgi 6. http://wiki.tcl.tk/tkchat 7. http://aspn.activestate.com/ASPN/Tcl/Mail 8. http://www.activestate.com/Tcl 9. http://tclplugin.sf.net/ 10. http://www.aolserver.com/ 11. http://www.equi4.com/tclkit 12. http://www.equi4.com/critcl 13. http://jfontain.free.fr/moodss/ 14. http://eepatents.com/privaria/ 15. http://snackamp.sourceforge.net/ 16. http://www.tclbridge.com/ 17. http://toucan.sourceforge.net/ 18. http://installbase.sourceforge.net/ 19. http://www.dr-baum.net/gnocl/ 20. http://wiki.tcl.tk/wikit - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Thanks to the authors Luiz Henrique de Figueiredo (Lua) Rafael Garcia-Suarez (Perl) Jeremy Hylton (Python) The Ruby Community (Ruby) Jeff Hobbs, Steve Landers, and Jean-Claude Wippler (Tcl) Additional thanks to Piers Cawley, Jarkko Hietaniemi, Jeremy Hylton, Lyle Johnson, Dan Sugalski, Greg Sullivan, and Jean-Claude Wippler. A copy of this email is available at http://www.vendian.org/language_year/ There are many useful and interesting languages not included here. If you write a similar summary, I would be glad to include it on the webpage. You might also consider similar collaborations within other super-communities. Please feel free to forward this email appropriately, but I suggest you wait a day or so to avoid duplication. Mitchell Charity

1 0

Middleware2003: Call for Contributions: Tutorials deadline: 15/Jan
by Fabio M. Costa 14 Jan '03

14 Jan '03

ACM/IFIP/USENIX INTERNATIONAL MIDDLEWARE CONFERENCE http://middleware2003.inf.puc-rio.br Rio de Janeiro, Brazil, 16-20 June 2003 CALL FOR CONTRIBUTIONS SUBMISSION DEADLINES ==================== Tutorial Proposals: 15 January 2003 (!) Work in Progress Papers, Workshop Papers, and Posters: 20 February 2003 Following the success of past editions of the conference, Middleware2003 will host a number of high quality workshops and tutorials, as well as work-in-progress and posters sessions. We are currently seeking quality submissions for these events. Please see details below. TUTORIALS ========= Traditionally, Middleware hosts a one day tutorial program. Proposals for high-quality tutorials in all middleware-related areas, from academic research to industrial applications, are solicited. Tutorial levels may be introductory, intermediate, or advanced. Topics of broad interest are preferred. Further information: http://middleware2003.inf.puc-rio.br/tutorials.htm WORKSHOPS ========= 1) Middleware for Pervasive and Ad-Hoc Computing http://www.smartlab.cis.strath.ac.uk/MPAC/ 2) Reflective and Adaptive Middleware Systems http://tao.doc.wustl.edu/~corsaro/RM2003/ 3) Middleware for Grid Computing http://virtual01.lncc.br/mgc2003 4) Model-driven Approaches to Middleware Applications Development (MAMAD) http://www.dstc.edu.au/mamad-2003/ 5) QoS-enabled Component-Oriented Programming - Supporting Composable QoS http://www.cs.wustl.edu/~nanbor/QOSCOP/ WORK-IN-PROGRESS ================ Work-in-Progress (or WiP) papers should describe on-going work and interim results. Submissions should be no longer than 2500 words. All submissions will be peer reviewed. Accepted papers will have a short presentation slot in the conference program and will be published in IEEE Distributed Systems Online. Further information: http://middleware2003.inf.puc-rio.br/wip.htm POSTERS ======= Posters are meant for publicizing current research initiatives as well as interesting new systems implemented using middleware technology. Reports of preliminary experience from middleware use cases are solicited. A 500-word summary of the poster's contents should be submitted by February 20th, 2003. Along with the notification of acceptance, authors will receive formatting instructions for the posters to be presented at the conference. Further information: http://middleware2003.inf.puc-rio.br/posters.htm ORGANIZATION ============ General Chair: Carlos J.P. Lucena (PUC-Rio, Brazil) Program co-Chairs: Douglas Schmidt (UC Irvine, USA) Markus Endler (PUC-Rio, Brazil) Local Arrangements co-Chairs: Alexandre Sztajnberg (UERJ, Brazil) Renato Cerqueira (PUC-Rio, Brazil) WiP and Posters Chair: Guruduth S. Banavar (IBM T.J. Watson, USA) Advanced Workshops Chair: Gordon Blair (Lancaster University, UK) Tutorials Chair: Frank Buschmann (Siemens AG, Germany) Publicity co-Chairs: Fabio Costa (UFG, Brazil) Fabio Kon (IME-USP, Brazil) FOR MORE INFORMATION ==================== For further information, please visit the conference home page: http://middleware2003.inf.puc-rio.br or http://gsd.ime.usp.br/middleware2003. For questions regarding the conference program, contact the PC chairs, Douglas Schmidt (schmidt(a)cs.wustl.edu) or Markus Endler (endler(a)inf.puc-rio.br). For other questions contact the local arrangements chairs, Alexandre Sztajnberg (alexszt(a)uerj.br) or Renato Cerqueira (rcerq(a)inf.puc-rio.br). --- Middleware2003 is sponsored by Sony Corporation ---

1 0

[ANN] Py 1.3 Ships
by Bryan Richard 14 Jan '03

14 Jan '03

Py 1.3 -------- Py Parlour Press[1], in conjunction with It's About Time Productions, announces availability of the third (1.3) issue of Py. The new issue contains 100% more oozing Pythonikal goodness, including: A Python Game Postmortem: Freedom Force http://store.pyzine.com/article.phtml?a=7 Extending Python with C, Part III (Alex Martelli) http://store.pyzine.com/article.phtml?a=1 Generating Web Menus with menugen (Mike Soulier) http://store.pyzine.com/article.phtml?a=3 POOPy: Creating New Objects with Inheritance (Greg Lindstrom) http://store.pyzine.com/article.phtml?a=6 Programming and Oxford Physics: Python, Pascal, or C (Michael Williams) http://store.pyzine.com/article.phtml?a=5 Python Gaming with Pygame (Pete Shinners) http://store.pyzine.com/article.phtml?a=2 What's It For? On the Use of Python Idioms (Raymond Hettinger) http://store.pyzine.com/article.phtml?a=4 Py Weblogs ---------- We're also pleased to announce two new Py weblogs, where Publisher Bryan Richard and new Managing Editor Kendall Clark spew great quantities of hot air, daily, about Python, Py, and the world at large: Publisher's weblog[2] http://pyzine.com/#weblog Editor's weblog[3] http://pyzine.com/log/ Fire up your browsers and RSS newsreaders and keep track of all the happenings in the Py world. The Next Issue -------------- Py's new Managing Editor, Kendall Clark, is busy begging, borrowing, and stealing content for future issues. Want to maximize your Python whuffie?[4] One way is to write a piece (or even a column) for Py. Contact Kendall Clark (kendall(a)monkeyfist.com) and he'll pester you endlessly with ideas, suggestions, and edits. Upcoming Py issues will focus on Python web development & infrastructure, weblogging & RSS, and burgeoning world of friendly Python forks. Py Store -------- For subscriptions, article abstracts, previous issues, and bootlegged copies of Py3K, visit the Pyzine.com store: http://store.pyzine.com/ Subscriptions include 4 issues of Py in the newly expanded format: 32 pages of fresh, steaming Python content by some of the most respected writers of the community. U.S. subscriptions are $40; Canadian subs are $60; all others $75. All prices subject to the whims of the publisher. About Py -------- Py is a print technical journal for Python developers. A lack of competition does not keep Py from being the best -- quite the opposite, in fact. About Py Parlour Press ---------------------- >From the fringes of the publishing industry comes Py Parlour Press. Concerned only with producing the finest publications money can buy, this is outlaw tech publication at its finest. NOTES ----- [1] http://pyzine.com/ [2] RSS version: http://pyzine.com/index.xml [3] RSS version: http://pyzine.com/log/index.xml [4] http://www.thestandard.com/article/display/0,1151,19498,00.html

1 0

Writing an Open Source Implementation of FoxPro
by p-nowak＠eelink.net 14 Jan '03

14 Jan '03

Hello, I have been doing some thinking about writing an open source implementation of FoxPro. I write mostly in Python and I been thinking Python has too many similarities and strengths not to take a close look at basing the FoxPro project on Python. Some of the benefits of a Python approach include: - The Python interpreter is similar to the FoxPro interpreter in basic parse and execute function; - Python works on multiple platforms; - Python core code is easy to read and well-designed; - Python has a large community and so does FoxPro -- getting some cross over will probably be good for both camps. - The FoxPro community would welcome this project I think. Just wondering what the group comments on this idea are. Paul

1 0

ASV 0.5 - a library for manipulating simple database formats such as CSV
by Laurence Tratt 13 Jan '03

13 Jan '03

I am pleased to be able to announce the third public version (0.5) of my ASV module, a mature pure Python module for inputting, manipulating and outputting simple database formats. Included is a command line interface for the quick conversion of file formats e.g. TSV -> CSV. As standard, ASV can read and write CSV (Comma Separated Values), TSV (Tab Separated Values) and colon separated value formats although it is simple to write your own input/output classes to cope with the bizarre variations that people seem to find themselves faced with from time to time. As the 'main' format, the CSV handler has been designed to cope gracefully with a wide variety of input formats. The design of ASV specifically allows conversion between different formats (eg TSV -> CSV). This new version of ASV is a small bug fix release and should be entirely backwards compatible with the previous release. I reccomend that all ASV users upgrade to this version. The download URL for ASV is: http://tratt.net/laurie/python/asv/ Please feel free to mail me with any comments you may have at laurie(a)tratt.net Laurie <P><A HREF="http://tratt.net/~laurie/python/asv/">ASV 0.5</A> - a library for manipulating simple database formats such as CSV (03-Dec-02)

1 0

CherryPy-0.8 released
by Remi Delon 13 Jan '03

13 Jan '03

We're pleased to announce the release of CherryPy-0.8. This release adds a brand new HTTP server that supports SSL, XML-RPC, threading, forking and process pool. The documentation has also been improved: the tutorial now has a section about deploying a CherryPy server for production and several HowTos have been added. ------------------------------------------ About CherryPy: CherryPy is a Python-based tool for developing dynamic websites. It uses many powerful concepts together, which makes it unique in its approach to website development. CherryPy sits between an application server and a compiler. You write source files, compile them with CherryPy and CherryPy generates an executable containing everything to run the website (including an HTTP server). It is released under the GPL license. CherryPy has been used in production for more than a year and it has proven fast and robust. Key properties/features of CherryPy are: - Based exclusively on Python (runs everywhere Python runs) - Delivers fast, robust, and scalable websites - Developers can use OOP as well as AOP (Aspect Oriented Programming) concepts to develop web sites - True separation of content and presentation - Simple but powerful templating language - "HTML editor safe" templating language (templates can go back and forth between designers and developers) - Powerful standard libraries to make your life easy Other properties/features are: - Can be linked to many databases (Oracle, Sybase, MySql, PostgreSql, ...) - Can run behind another webserver (Apache, ...) - Easy clustering and load-balancing set up for high-traffic websites - Built-in caching capability - SSL support (based on PyOpenSSL) - XML/XSL support (based on 4Suite) - Built-in XML-RPC support Remi. http://www.cherrypy.org

1 0

ANN: imgSeek 0.5 released
by nieder＠mail.ru 13 Jan '03

13 Jan '03

Hello, After speed improvements, major feature additions and bug fixes, I am proud to announce that imgSeek 0.5 is available for download at http://prdownloads.sourceforge.net/imgseek/imgSeek-0.5.tar.gz?download What is it? ----------- imgSeek is a photo collection manager and viewer with content-based search and many other features. The query is expressed either as a rough sketch painted by the user or as another image you supply (or an image in your collection). The searching algorithm makes use of multiresolution wavelet decompositions of the query and database images. Requires PyQT 3.5. Generously hosted by SourceForge at http://imgseek.sourceforge.net/ Please report bugs, rants, feature wishes or code contributions to the email bellow. Regards, -- Ricardo Niederberger Cabral <nieder(a)mail.ru>

1 0

[ANNOUNCE] Second release of PythonCAD now available
by Art Haas 12 Jan '03

12 Jan '03

I'd like to announce the second release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The second release fixes a few of the shortcomings in the initial release. Setting linetype properties, color choice, and drawing entity style are now done from the "Draw" menu. This release also adds some missing functionality, such as the ability to change the linetype, color, and style of the drawing entities, and the ability to move entities from one layer to another. The Python code has had numerous doc strings added, and various bug fixes have been applied. Visit the PythonCAD web site for more information about what PythonCAD does, and aims to be. http://www.pythoncad.org Come and join me in developing PythonCAD into a world class drafting program! Art Haas -- They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, Historical Review of Pennsylvania, 1759

1 0

pyrad 0.4 - native python RADIUS implementation
by Wichert Akkerman 12 Jan '03

12 Jan '03

pyrad is an implementation of a RADIUS client and server as described in RFC2865, 2866, and others. It takes care of all the details like building RADIUS packets, sending and receiving them, and en-/decoding responses. (RADIUS is a common protocol used for authentication, authorisation and accounting for remote access (and similar) services). This release adds new features and introduces an API change: a RADIUS server implementation was added, as well as the basis of a proxy server. Changes since previous release ------------------------------ * Fix last case of bogus exception usage * Move RADIUS code constants to packet module * Add support for decoding passwords and * generating reply packets to Packet class * Add basic RADIUS server and proxy implementation Example ------- Here is an example of a client doing authentication request: import pyrad.packet from pyrad.client import Client from pyrad.dictionary import Dictionary srv=Client(server="radius.my.domain", secret="s3cr3t", dict=Dictionary("dicts/dictionary", "dictionary.acc")) req=srv.CreatePacket(code=pyrad.packet.AccessRequest, User_Name="wichert", NAS_Identifier="localhost") req["User-Password"]=req.PwCrypt("password") reply=srv.SendPacket(req) if reply.code==pyrad.packet.AccessAccept: print "access accepted" else: print "access denied" print "Attributes returned by server:" for i in reply.keys(): print "%s: %s" % (i, reply[i]) And an example for a trivial RADIUS server: from pyrad import dictionary, packet, server class FakeServer(server.Server): def _HandleAuthPacket(self, fd, pkt): server.Server._HandleAuthPacket(self, fd, pkt) reply=self.CreateReplyPacket(pkt) reply.code=packet.AccessAccept self.SendReplyPacket(fd, reply) srv=FakeServer(dict=dictionary.Dictionary("dictionary")) srv.hosts["127.0.0.1"]=server.RemoteHost("127.0.0.1", "s3cr3t", "localhost") srv.BindToAddress("") srv.Run() Requirements ------------ pyrad requires Python 2.0 or later. Author, copyright, availability ------------------------------- pyrad was written by Wichert Akkerman <wichert(a)deephackmode.org> The current version and documentation can be found at its homepage: http://www.wiggy.net/code/pyrad.xhtml Copyright 2002,2003 Wichert Akkerman. All rights reserved. pyrad is distributed under the BSD license. Please see the source archive for the full license text. -- Wichert Akkerman <wichert(a)wiggy.net> http://www.wiggy.net/ A random hacker

1 0

ANN: wxPython 2.4.0.1
by Robin Dunn 11 Jan '03

11 Jan '03

I'm pleased to annouce that the 2.4.0.1 release of wxPython is ready for download from http://wxpython.org/. wxPython is the Python binding to the wxWindows C++ cross platform GUI library, which supports creating GUI applications on WIndows, Linux and Mac OS X with a native look and feel. This release is primarily a bugfix release and a transition from the 2.3.x series to the "stable" 2.4.x series of releases. However there have been a few releases made since I last widely announced it so I will summarize the new features in the recent releases below Updated XRCed and wxTimeCtrl contribs. Show a couple new wxGrid features in the demo. Added wxHtmlFilter. wxASSERT and related C++ runtime diagnostics are now converted to Python exceptions. When an assert happens a wxPyAssertionError (which derives from AssertionError) exception is created and when control returns back to the Python code that invoked the C++ API it will be raised. The same exception restrictions are in place as before, namely that exceptions can't cross from one Python layer through C++ to another Python layer. That simply means that if you want to catch wxPyAssertionError or any other exception that you need to do it before control returns to C++ at the end of your event handler or callback code. There is some test code in demo/wxButton.py you can use to play with this new feature. Added some methods to wxApp (SetAssertMode and GetAssertMode) that let you control how C++ assertions are processed. Valid modes are: wxPYAPP_ASSERT_SUPPRESS, wxPYAPP_ASSERT_EXCEPTION, and wxPYAPP_ASSERT_DIALOG. Using _SUPPRESS will give you behavior like the old "final" builds and the assert will be ignored, _EXCEPTION is the new default described above, and _DIALOG is like the default in 2.3.3.1 and prior "hybrid" builds. You can also combine _EXCEPTION and _DIALOG if you wish, although I don't know why you would. You can now overload OnInitGui, OnExit and OnAssert in your classes derived from wxApp. Added GetSelectedCells, GetSelectionBlockTopLeft, GetSelectionBlockBottomRight, GetSelectedRows, GetSelectedCols nethods to wxGrid. Added Python == and != operators for some basic classes. Fixed the Python wrappers for wxInputStream so they no longer block when reading from a wxProcess on wxGTK. They now work more or less as they did before 2.3.3.1 but the dual meaning of eof() has been removed. There is now a CanRead() method that lets you know if there is data waiting to be read from the pipe. Fixed method name clash in wxIEHtmlWin, renamed Refresh to RefreshPage. Added Throbber from Cliff Wells to the library and the demo. Windows installer prompts to uninstall old version first. Added wxPython.lib.evtmgr by Robb Shecter, which is an easier, more "Pythonic" and more OO method of registering handlers for wxWindows events using the Publish/Subscribe pattern. Added wxPython.lib.popupctl by Gerrit van Dyk which is a combobox-like gizmo for poping up arbitrary controls. It is currently using wxDialog because of some issues with wxPopupWindow... Added wxPython.lib.gridmovers by Gerrit van Dyk which facilitates the dragging of columns and/or rows in a wxGrid. Added wxPython.lib.multisash by Gerrit van Dyk which is a nice implementation of allowing the user to split a window any number of times either horizontally or vertically, and to close the split off windows when desired. Added helpviewer tool that displays HTML books similarly to how MS HTMLHelp viewer does. Changed how the wxPythonDocs tarball is built and added a script to launch the doc viewer. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!

1 0

[ANN] Soya 3D 0.2.1
by Jiba 11 Jan '03

11 Jan '03

Soya 3D 0.2.1 is out! WHERE? http://oomadness.tuxfamily.org/en/soya LICENSE? GPL WHAT IT IS? Soya 3D is a 3D engine for Python, written in C and Python. It rests on OpenGL for 3D and SLD for initialization. Several advanced features are proposed like landscapes, raypicking,... and a set of tutorials is also included. Jiba

1 0

ReseekFile and MultiDict
by Andrew Dalke 11 Jan '03

11 Jan '03

I've developed two new modules people may find interesting. They can be found at http://www.dalkescientific.com/Python/ . Both modules have been placed in the public domain. The first is ReseekFile. This wraps a file handle to allow seeks back to the beginning. It is very useful in Internet work when you need to check that the the input stream is in the proper format before passing it to to the parser. Example: >>> # Check first if the file starts with 'ERROR:' >>> # and if so, raise an exception >>> import urllib2, ReseekFile >>> infile = urllib2.urlopen("http://somewhere/") >>> infile = ReseekFile(infile) >>> s = infile.readline() >>> if s.startswith("ERROR:"): >>> raise Exception(s[:-1]) >>> infile.seek(0) >>> infile.nobuffer() >>> ... proces the input file as normal .. The second is MultiDict This implements two types of dictionary-like objects where there can be more than one entry with the same key. One is OrderedMultiDict, which preserves the order of all entries across all keys. The other is UnorderedMultidict, which only preserves the order of entries for the same key. Example: >>> import MultiDict >>> od = MultiDict.OrderedMultiDict() >>> od["Name"] = "Andrew"; od["Color"] = "Green" >>> od["Name"] = "Karen"; od["Color"] = "Brown" >>> od["Name"] 'Karen' >>> od.getall("Name") ['Andrew', 'Karen'] >>> for k, v in od.allitems(): ... print "%r == %r", (k, v) ... 'Name' == 'Andrew' 'Color' == 'Green' 'Name' == 'Karen' 'Color' == 'Brown' >>> ud = MultDict.UnorderedMultiDict(od) >>> for k, v in ud.allitems(): ... print "%r == %r", (k, v) ... 'Name' == 'Andrew' 'Name' == 'Karen' 'Color' == 'Green' 'Color' == 'Brown' >>> Andrew dalke(a)dalkescientific.com -- Need usable, robust software for bioinformatics or chemical informatics? Want to integrate your different tools so you can do more science in less time? Contact us! http://www.dalkescientific.com/

2 1

Minimal Python project
by holger krekel 10 Jan '03

10 Jan '03

Minimal Python Discussion, Coding and Sprint -------------------------------------------- We announce a mailinglist dedicated to developing a "Minimal Python" version. Minimal means that we want to have a very small C-core and as much as possible (re)implemented in python itself. This includes (parts of) the VM-Code. Building on the expected gains in flexibility we also hope to use distribution techniques such as PEP302 to ship only a minimal set of modules and load needed modules on demand. As Armin Rigo of PSYCO fame takes part in the effort, we are confident that MinimalPython will eventually run faster than today's CPython. And because Christian Tismer takes part, we are confident that we will find a radical enough approach which also fits Stackless :-) We are very interested in learning about and integrating prior art. And in hearing any doubtful or reinforcing opinions. Expertise is welcomed in all areas. So if you have an interest or even code regarding 'minimal python' please join the list: http://codespeak.net/mailman/listinfo/pypy-dev discussions previously took place on python-de and in private mails. We will repost some core ideas (in english) for further discussion. In a few months we'd like to do a one-week Sprint in Germany focusing on releasing first bits of Minimal Python. best wishes, Armin Rigo, Christian Tismer, Holger Krekel

1 0

SC-Track Roundup 0.5.4 - an issue tracking system
by Richard Jones 09 Jan '03

09 Jan '03

================================================= SC-Track Roundup 0.5.4 - an issue tracking system ================================================= This is a bugfix release for version 0.5.x - if you're upgrading from before 0.5, you *must* read doc/upgrading.txt! Unfortunately, the Zope frontend for Roundup is currently broken, with no fix in the forseeable future. Roundup requires python 2.1.3 or later for correct operation. Users of the sqlite backend are encouraged to upgrade sqlite to version 2.7.3. We've had a good crack at bugs (thanks to all who contributed!): - key the templates cache off full path, not filename - implemented whole-database locking - hyperlinking of special text (url, email, item designator) in messages - fixed time default in date.py - fixed error in cgi/templates.py (sf bug 652089) - fixed handling of missing password (sf bug 655632) - applied patches for handling Outlook quirks (thanks Andrey Lebedev) (multipart/alternative, "fw" and content-type "name") - fire auditors and reactors in rdbms retire (thanks Sheila King) - better match for mailgw help "command" text - handle :add: better in cgi form parsing (sf bug 663235) - handle all-whitespace multilink values in forms (sf bug 663855) - fixed searching on date / interval fields (sf bug 658157) - fixed form elements names in search form to allow grouping and sorting on "creation" field - display of saved queries is now performed correctly Source and documentation is available at the website: http://roundup.sourceforge.net/ Release Info (via download page): http://sourceforge.net/projects/roundup Mailing lists - the place to ask questions: http://sourceforge.net/mail/?group_id=31577 About Roundup ============= Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)users.sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.1+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates (a classic bug/feature tracker and a minimal skeleton) and six database back-ends (anydbm, bsddb, bsddb3, sqlite, metakit and gadfly).

1 0

PyCon call for papers -- deadline looming!
by Guido van Rossum 09 Jan '03

09 Jan '03

There's still time to submit abstracts to the Python Conference in DC (March 26-28). The submission deadline for proposals is January 15. http://www.python.org/pycon/cfp.html Don't miss presenting at this unique event! --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

[ANN] Third Austin Python Users Group Meeting
by Travis N. Vaught 09 Jan '03

09 Jan '03

Greetings, Apologies for the short notice, but we've finalized the time for the January Austin Python User's Group meeting. Alan Runyan is the speaker this month. He'll be primarily discussing Plone (http://plone.org <http://plone.org/> - Plone is cool). Where: Enthought, Inc. 515 Congress Ste. 1614 When: Monday, January 13, 2003 6:30 PM Enthought is located downtown at 6th and Congress in the Bank of America building. We're located on the 16th floor in Suite 1614. If you're coming from IH 35, you can just exit 6th Street and head West 5-6 blocks. Free parking is somewhat scarce downtown, but the dedicated can find it. For everyone else, the Littlefield parking garage is next to our building. Its entrance is between 5th and 6th streets on Brazos. Our building officially closes to the public at 6:00, but tell security that you're going to a meeting at Enthought, and they will let you in. Email travis(a)enthought.com to RSVP or with any questions. Also, you may subscribe to apug(a)scipy.org, our mailing list, at http://scipy.net/mailman/listinfo/apug . If you don't RSVP, come anyway. Bring a friend.

1 0

Betty, try our bullet-proof, complaint-resistant web hosting. Guaranteed.
by Usha MacDougan-MacDuncan 09 Jan '03

09 Jan '03

1 0

Article: Python generators + DOM
by Uche Ogbuji 09 Jan '03

09 Jan '03

http://www.xml.com/pub/a/2003/01/08/py-xml.html Techniques and routines taking advantage of Python generators for DOM processing. Builds on my earlier article: http://www-106.ibm.com/developerworks/library/x-tipgenr.html -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com A Python & XML Companion - http://www.xml.com/pub/a/2002/12/11/py-xml.html XML class warfare - http://www.adtmag.com/article.asp?id=6965 MusicBrainz metadata - http://www-106.ibm.com/developerworks/xml/library/x-think14.html

1 0

ANN: Oak DNS Server (again)
by Ed Stoner 08 Jan '03

08 Jan '03

We are pleased to announce (again) the release of the Oak DNS Server. The first announcement didn't make it through the newgroups, probably because we put an incorrect url in the announcement (we know a lot more about DNS than we do about Zope inheritance :-) The software is new but it is being run in a production environment at multiple locations already. The software can be downloaded from: http://www.digitallumber.com/oak What is it? Oak is a DNS Server written in pure python. Features: - Pure Python - Runs on Windows and various unixes - configuration through python - recursion - zone transfers - slave servers - dynamic updates - various secuirty enhancements Except for the DNSSEC, we think that Oak is a functional replacement for bind (we are using it as such). Please give it a try. It's nice to be able to manage your DNS config with python. License: LGPL ------------ Ed Stoner Digital Lumber, Inc. (www.digitallumber.com) ed(a)digitallumber.com

1 0