From Rimon Barr Mon Dec 2 02:24:38 2002 From: Rimon Barr (Rimon Barr) Date: Sun, 1 Dec 2002 21:24:38 -0500 (EST) Subject: spyce v1.3.2 released Message-ID: Spyce v1.3.2 released on 1 Dec 2002 SPYCE is a server-side engine that supports simple and efficient Python-based dynamic HTML generation. Those who like Python and are familiar with JSP, or PHP, or ASP, should have a look at this engine. It allows one to generate dynamic HTML content just as easily, using Python for the dynamic parts. Its modular design makes it very flexible and extensible. It can also be used as a command-line utility for HTML pre-processing. Get it at: http://spyce.sourceforge.net Grisha released mod_python 3.0.1 today for Apache 2.0.40 and Python 2.2.1 and up. Spyce has been updated to work with this release of mod_python as well. To summarize the known configurations that are known work well (and are often tested by me *): Linux: * Apache 1.3.x with FastCGI - works Apache 2.0.x with FastCGI - unknown, FastCGI still alpha * Apache 1.3.x with CGI - works (slow) Apache 2.0.x with CGI - works (slow) * Apache 1.3.x with mod_python 2.7.x - works Apache 2.0.x with mod_python 3.0.x - works * Apache 1.3.x with proxy - works Apache 2.0.x with proxy - works * command-line - works Xitami via CGI - works (Jim Madsen) Xitami via Xitami LWRP - works (Jim Madsen) Windows: (not tested as often) same as above, except... Apache 2.0.x with mod_python - unknown whether mod_python v3.0.1 works on Windows yet should work on 2000, NT and XP. not sure about 95, 98, ME FastCGI: IIS via CGI - works IIS via FastCGI - works others - unknown CGI and proxy server: should work in any environment MacOS X: reported to work in some configuration by user FreeBSD: reported to work in some configuration by user There were also some small tweaks to Windows installer and config file that should make it more robust across more versions of Apache. Also there was a switch back to the sre regular expression module. This should not affect most users at all. But, watch for stack overruns and please report. (see the changelog below.) Enjoy, Rimon. v1.3.2 mod_python 3.0.1 compatibility - switched to sre module, despite stack limits, because pre module conflicts with pcre shared object that apache uses (actually, just fails on some complicate reg.exps!) This implies that very, very long spyce files might fail, until sre module implements a state-machine-based reg.exp engine. - apacheRequest.connection.child_num mysteriously removed, therefore using os.getpid() in spyceModpyRequest.getServerID() spyceApache.conf tweaked (should be more compatible) installHelper.py converts backslash to forward slash for httpd.conf on Windows switched from pre to sre module in spyceCompile.py - reason: Apache 2.0.x uses different pcre library from Python causing failure under mod_python - pre was used over the default (sre) because sre implementation is stack-based and encountered overruns... Oh, well! Don't write Spyce files that blow the stack until sre is fixed. From hinsen@cnrs-orleans.fr Mon Dec 2 14:46:12 2002 From: hinsen@cnrs-orleans.fr (Konrad Hinsen) Date: Mon, 2 Dec 2002 15:46:12 +0100 Subject: Integrated Development Environment for Python on the Zaurus Message-ID: Integrated Development Environment for Python on the Zaurus =========================================================== A Qt-based Python IDE for the Sharp Zaurus (and other handhelds running Qtopia) is available from http://starship.python.net/~hinsen/Zaurus/ Features: - Specifically designed for a small screen - Automatic indentation support - Python-specific navigation commands - Emacs-style incremental search Requirements: Python and PyQt, both available from http://www.riverbankcomputing.co.uk/ -- ------------------------------------------------------------------------------- Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais ------------------------------------------------------------------------------- From drifty@bigfoot.com Tue Dec 3 05:00:03 2002 From: drifty@bigfoot.com (Brett C.) Date: 2 Dec 2002 21:00:03 -0800 Subject: python-dev Summary for 2002-11-16 through 2002-11-30 Message-ID: ++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary, 2002-11-16 through 2002-11-30 ++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ between November 16, 2002 and November 30, 2002 (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@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 sixth summary written by Brett Cannon (back in my groove). All summaries are now 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, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is. If you want to do that, get an original copy of the text file. .. _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 ====================== Summary Announcements ====================== Nothing to report to speak of. Uh, go to PyCon_ . =) .. _PyCon: http://www.python.org/pycon/ ==================== `bsddb3 imported`__ ==================== __ http://mail.python.org/pipermail/python-dev/2002-November/030247.html Martin v. Loewis merged bsddb3 3.4.0 into CVS under the name ``bsddb``. The old ``bsddb`` module is now no longer compiled by default; if it does get compiled, though, it ends up with the name ``bsddb185``. Barry Warsaw also requested that the extensive testing suite be incorporated and "run it only with a regrtest -u option". Martin wasn't sure how Barry wanted them incorporated, though, since there are multiple files to the test and most testing suites in the stdlib are a single file. Barry suggested that the testing files be put in a directory with the package and that test_bsddb.py just call the tests in that directory, much like how the email package does it. They were integrated and some errors and warnings were found that are being dealt with. It was also agreed upon that development will be moved over to Python so as to keep the module in Python sync'ed up properly and to keep poor Martin from having to import the files into Python's CVS constantly. ======================= `Licensing question`__ ======================= __ http://mail.python.org/pipermail/python-dev/2002-November/030256.html David Abrahams asked about a licensing issue with Boost.Python_ (it is a free library that "enables seamless interoperability between C++" and Python) and it's modified Python.h_ file that it uses. Originally there was no license at the top of that file, but that does not work for some corporations using Boost. So David stuck his own license at the top and asked if this is the right thing to do. Guido asked him to provide the PSF_ license_ at the top of the file and to mention what changes he made. The copyright had been added to the file for Python 2.2.2. .. _Boost.Python: http://www.boost.org/libs/python/doc/ .. _Python.h: .. _PSF: http://www.python.org/psf/ .. _license: http://www.python.org/2.2.2/license.html ========================= `Re: PyNumber_Check()`__ ========================= __ http://mail.python.org/pipermail/python-dev/2002-November/030236.html M.A. Lemburg noticed that PyNumber_Check()'s semantics on what will cause it to return had changed. He asked if it should check whether one of "nb_int, nb_long, nb_float is available (in addition to the tp_as_number slot)". Guido responded that he would like to see it deprecated. We got a history lesson of how PyNumber_Check() was written "when the presence or absence of the as_number "extension" to the type object was thought to be useful". Regardless, Guido said that testing like this does not prove something is a "number" and if you wanted to test this way you could do it yourself. In response, MAL said that perhaps PyNumber_Check() should be changed so that it returned true for something that is "usable as input to float(), int() or long()". Guido said that would be fine "as long as we all agree that that's *exactly* what they check for, and as long as we agree that there may be overlapping areas" for the various Py*_Check() functions. Guido later said testing for nb_int, nb_long, and nb_float was fine. =================================================== `Plea: can modulefinder.py move to the library?`__ =================================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030240.html Just van Rossum wanted to move Freeze's modulefinder.py_ into the stdlib so that it can be distributed with binary releases. In case you don't know what modulefinder.py does, it attempts to find all pure Python module dependencies for a pure Python module. In other words, it checks what the module imports and if it is a Python file, and if it is, records that; it repeats this for all modules it finds, creating a listing of modules needed for the module to run. Guido said that the module needed some work before it could be considered; it had ``print`` statements that were unneeded outside of Freeze and it had no documentation. Just agreed that the documentation needed to be done. As for the ``print`` statements, though, they only come out when ``debug`` is set to true; by default it is false. Guido said that was fine and agreed with the removal of the Windows-specific ``print`` statements. Thomas Heller later said in `another thread`_ that `patch #643711`_ was opened primarily for him and Just to do work in but that everyone was invited to help out. .. _another thread: http://mail.python.org/pipermail/python-dev/2002-November/030445.html .. _modulefinder.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/freeze/modulefinder.py .. _patch #643711: http://www.python.org/sf/643711 ============================ `Dictionary Foolishness?`__ ============================ __ http://mail.python.org/pipermail/python-dev/2002-November/030282.html Raymond Hettinger suggested having "dictionaries support the repetition" to allow one to create a dictionary with enough space as specified by the repetition:: >>> [0] * n # allocate an n-length list >>> {} * n # allocate an n-element dictionary Aahz recalled that dictionaries are resized upon adding to a dictionary and they could theoretically grow smaller. That would seem to possibly limit the usefulness of this idea. Guido then voted -1 (practically a death wish for an idea unless people clamor for it) saying that it relied too much on "arbitrary magic by side effect". He said if people *really* wanted this a method could be proposed. ============================= `dict() enhancement idea?`__ ============================= __ http://mail.python.org/pipermail/python-dev/2002-November/030290.html Just van Rossum suggested overloading the dictionary constructor so that arguments that went to ``**kwargs`` would be used to create the dictionary (this can be seen in the "`Python Cookbook`_" as recipe 1.2 or online at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52313). This is desired because that means cleaner code for creating dicts:: >>> dict(pigs='!fly', birds='fly') Barry commented that he liked it and had something similar in his code for Mailman_ . Thomas Heller voted +1 for it and also said that he used the idiom. Raymond Hettinger and myself also voted +1 for it. .. _Python Cookbook: .. _Mailman: =========================================== `Yet another string formatting proposal`__ =========================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030304.html Oren Tirosh proposed something (read the title to figure out what). He proposed the following syntax:: >>> "\(a) + \(b) = \(a+b)\n" >>> r"\(a) + \(b) = \(a+b)\n".cook() The advantages, according to Oren, are that it would not require introducing the use of a new symbol like ``$``, nor a new string prefix nor a new method. The ``.cook()`` method would be used to evaluate raw strings at a later point; it would draw arguments from the local and global namespace. The biggest drawback was unfamiliarity for programmers. Frederik Lundh pointed out that ``\(`` is "commonly used to escape parentheses in regular expression strings" (Effbot wrote re_ , so he should know). Oren then said that curly braces could (and pretty will) be used instead. Michael Chermside likes this design idea, but thinks the name for ``.cook()`` is not that great. Oren was going for a name that tied into "raw". Michael suggested the name ``.sub()`` to build off of the two PEPs already in existence covering string formatting (`PEP 215`_ and `PEP 292`_ ). .. _re: http://www.python.org/doc/current/lib/module-re.html .. _PEP 215: http://www.python.org/peps/pep-0215.html .. _PEP 292: http://www.python.org/peps/pep-0292.html ===================== `Expect in python`__ ===================== __ http://mail.python.org/pipermail/python-dev/2002-November/030313.html Eric Raymond proposed adding pexpect_ to the stdlib when it reaches version 1 (it is currently at 0.94). His thought was that having functionality like Expect_ would be a boon for Python and use for system administration. Eric said he had been using the module and had no problems with it (Prabhu Ramachandran also said it had worked for him). David Ascher said that he would like to see a more abstract API to allow it work for things other than character streams. He also would like to see something work better on Windows. Eric said that he would not want to hold up this for hopes of getting something better since it already works well for what it does. But it appears that the creator of pexpect is more than willing to help maintain the module if it makes it into the stdlib. Zach Weinberg said that he would be willing to put some work into making the pty_ module more portable since pexpect does its thing using pty. .. _pexpect: http://pexpect.sf.net/ .. _Expect: http://expect.nist.gov/ .. _pty: http://www.python.org/doc/current/lib/module-pty.html =================================== `PEP 288: Generator Attributes`__ =================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030321.html Raymond Hettinger has revised `PEP 288`_ with a new proposal on how to pass things into a generator that has already started. He has asked for comments on the changes, so let him know what you think. .. _PEP 288: http://www.python.org/peps/pep-0288.html =============================================== `PyMem_MALLOC (was [Python-Dev] Snake farm)`__ =============================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030333.html Continuation of http://mail.python.org/pipermail/python-dev/2002-November/029853.html There was a possible issue with ``PyMem_MALLOC()`` that Marc Recht had discovered on FreeBSD. It eventually was tracked down to FreeBSD-CURRENT's implementation of ``malloc()``: ``malloc(0)`` always return 0x800. M.A. Lemburg suggested changing a test in the configure script to try to catch when a platform returned an address for ``malloc(0)`` and treat it just like when it would return ``NULL`` (``NULL`` can't be blindly returned since that would signal a memory error; returning ``NULL`` in a C extension signals an error). Marc came back with news that C99 says that this is legitimate behavior for ``malloc()`` so this could possibly affect other platforms. Marc suggested that ``PyMem_MALLOC()`` just be redefined to ``n ? malloc(n) : NULL``. Problem is that the ``NULL`` issue mentioned above comes into play with this solution. Tim Peters suggested either ``malloc(n || 1)`` or ``malloc(n ? n : 1)`` (the former being a Python idiom that doesn't cut it in C). he does not want to mess with the configure scripts since they have "proven itself too brittle too many times". Tim wanted a way to prevent ever calling the function with 0, but Guido couldn't see any way of doing that without an extra jump. The committed solution is ``malloc((n) ? (n) : 1)``. Easier to just waste one byte then have to deal with the special casing of passing 0. The extra test was not really a worry since no measurable performance reported by Tim. Besides, Tim pointed out "this is ideal for a conditional-move instruction, and more architectures are growing that". ==================================================== `Half-baked proposal: * (and **?) in assignments`__ ==================================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030349.html Gareth McCaughan suggested cutting down one of the separations between parameter passing and assignment by allowing assignment to use arbitrary argument lists:: >>> a,b,*c = 1,2,3,4,5 # c == (3, 4, 5) >>> year, month, day, *dummy = time.localtime() I argued that I didn't like the slightly cluttered look on the left-hand side (LHS) of the assignment. Martin v. Loewis and I basically ended up saying we wanted to keep assignments clear and concise and that this would not help to keep that. Steve Holden basically ended up agreeing. Brian Quinlin, Patrick O'Brien, Nathan Clegg and Timothy Delany liked the idea. The biggest argument in support was that it would allow for a more functional programming style (and that obviously can be good or bad depending on your P.O.V.; I say bad =):: >>> car,*cdr = [head, t1, t2, t3] # car == head, cdr == (t1, t2, t3) In case you don't have functional programming (especially Lisp/Scheme) experience, the basic data structure in Lisp-like language is a list and the most common way to manipulate those lists is with the functions ``car`` and ``cdr``. ``car`` returns the "head", or front, of the list; ``cdr`` returns the "tail", or everything but the head, of the list. This allows for simple recursion since you just pass the ``cdr`` of a list on the recursive call after having dealt with the head of the list. There was also the suggestion of allowing the arbitrary assignment variable to be anywhere in the list of assignment variables:: >>> a,*b,c = 1,2,3,4,5 # a == 1, b == (2, 3, 4), c == 5 To prove that this was not really needed I wrote a function that took in an iterable and the number of variables to assign to and then returned the proper number iterations on the iterator and then the iterator as the last thing returned. Alex Martelli of course improved upon it (and also continued to correct my slightly incorrect statements):: def peel(iterable, arg_cnt=1): """Return ``arg_cnt`` values from iterator of ``iterable`` and then the iterator itself.""" iterator = iter(iterable) for num in xrange(arg_cnt): yield iterator.next() yield iterator The idea of a module for the stdlib containing iterator helper functions was suggested by Alex. One is in progress by Raymond Hettinger. Armin Rigo suggested having iterators become a type. That was quickly shot down, although having the suggested iterator helper module contain a class that could be subclassed by iterators was received with positive comments. The thread ended very quickly after Guido said that he didn't think "that there's a sufficient need to add new syntax". =================================== `from tuples to immutable dicts`__ =================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030358.html Armin Rigo said that he would like to have an immutable type that acted like a dictionary; basically like a struct from C. Martin v. Loewis agreed on the need, but opposed the idea of adding another built-in type or syntax for such a type; that left something for the stdlib. Martin suggested something like:: >>> struct_seq(name, doc, n_in_sequence, (fields)) where ``field`` is a bunch of (name, doc) tuples. What would be returned would be a "thing [that] would be similar to os.stat_result: you [can] call it with the mandatory fields in sequence, and can call it with the optional fields by keyword argument". Armin didn't like it since it went against his initial proposal "which was to have a lightweight and declaration-less way to build structures". He basically ended up suggesting something along the lines of tuples with keyword arguments. Martin didn't like it since he didn't see a great use for it. In the end Armin said to just drop the idea. ============================================ `urllib performance issue on FreeBSD 4.x`__ ============================================ __ http://mail.python.org/pipermail/python-dev/2002-November/030391.html Andrew MacIntyre brought a thread on python-list to python-dev's attention about urllib performance compared to wget (wget is used to download web sites and files). Apparently the used socket is unbuffered instead of using the system default (which was shown to be almost as fast as wget). The question became why this was done. The answer (thanks to Martin v. Loewis) was to prevent deadlock. Apparently under HTTP 1.1 a server can keep a connection open while waiting for the next command. If the connection was buffered it would block until it read enough to fill the buffer which may never come. Frederik Lundh suggested that a subclass or option be available that allowed the choosing of unbuffered or not. Andrew said he would put it on his todo list. ===================================== `test failures on Debian unstable`__ ===================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030384.html Failures on the build of Debian's unstable version of Python led to a discussion about how modules are skipped in the testing suite. `Lib/test/regrtest.py`_ keeps a list of tests that are expected to be skipped on various platforms. Martin v. Loewis doesn't like it because tests such as for the bz2 module are attempted regardless of whether the bz2 library is even installed and yet it is expected to succeed on Linux. Martin summarized that "For many of the tests that are somtimes skipped, knowing the system does not tell you whether the test will should rightfully be skipped, on that system" since tests are skipped often because a module was not there that needed to be imported for the test. Tim Peters, on the other hand, likes it. Since he maintains the Windows distribution from PythonLabs he likes it since it lets him know when new things have been added to Python and might need to be excluded from the Windows distro. Neil (who pointed out the Debian problems) was able to recognize that the tests that failed were meant to pass under Linux. Tim admitted he only cared about keeping the mechanism for Windows; he could care less if it is removed for Linux. Patrick O'Brien chimed in (with Aahz supporting) that the feature is handy since you can easily find out libraries you are missing that you could potentially install. Guido stepped in and suggested setting up a mechanism that would allow an external table in a file to be used when present instead of the default list of tests to skip. Don't think anyone has stepped up to implement this. .. _Lib/test/regrtest.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/test/regrtest.py =================================================================== `Currently baking idea for dict.sequpdate(iterable, value=True)`__ =================================================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030431.html Raymond Hettinger presented "a write-up for a proposed dictionary update method". It basically took an iterable and added keys based on the values returned by the iterator with a value as passed in and used for all new keys. The rationale was to have a fast way to be able to do membership testing using dict's ``__contains__`` or removing duplicates by creating a dict and then outputting the keys using the aptly named ``.keys()``. Previous objecctions to something like this were about the dict constructor and the ``sets`` module. The ones about the constructor are dealt with by making this a method. The latter was argued against by saying that the ``sets`` module is slow. Frederik Lundh brought up that we really don't need multiple ways of doing the same thing. Just van Rossum agreed and said this killed the idea for him. Guido chimed in and said that the ``sets`` module was to help solidify the sets API so that at some point it could be coded in C. To address the speed complaint Guido suggested limiting the ``sets`` module initially to make it faster so that the type won't be held back or unutilized because of its speed. Tim Peters spoke up, though, and said that the spambayes_ project used ``sets`` and he didn't have any complaints. But when major membership testing was needed a dict was used. And Tim pointed out that in order for any C sets code to be fast it would have to directly use dict's C ``__contains__`` code. What this method should return was brought up by Just. Some thought ``None`` since ``.update()`` returns that. Others said ``True``. Guido said ``None`` since ``True`` should only be used when something is explicitly true. Making it a class method was also suggested by Just as an easy way to make it like a constructor. Raymond agreed and changed his proprosal as well as to have the method be named ``.fromseq()``. But then Walter Dorwald said ``.fromkeyseq()`` should be used since there "is another constructor that creates the dict from a sequence of items". Guido voted +1 on that idea. .. _spambayes: http://spambayes.sf.net/ ====================================== `Re: release22-maint branch broken`__ ====================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030330.html Tim Rice discovered that trying to build Python from a directory other then where the source was did not work for the Python 2.2.* CVS. It was all eventually solved and fixed in the CVS branch. I am mentioning it here in case someone reading this had a similar issue. ================================ `Dictionary evaluation order`__ ================================ __ http://mail.python.org/pipermail/python-dev/2002-November/030458.html Gustavo Niemeyer asked about how to handle code like ``{f1():f2(), f3(): f4()}`` and its execution order as pointed out by `bug #448679`_ . As it stood it evaluated in the order of f2, f1, f4, f3. Apparently Guido once upon a time considered this a bug. But Guido mentioned that left-to-right evaluation is not always wanted since ``a = {}; a[f1()] = f2()`` would want f2 to evaluate first. He asked what Jython did. Finn Bock said that Jython went f1, f2, f3, f4. In that case Guido didn't see any reason to fix it. But Tim Peters brought up the point that the bug was more about the lack of specifics on this in the documentation. Gustavo said he would make the code fix along with patches to the docs. .. _bug #448679: http://www.python.org/sf/448679 =========================== `int/long FutureWarning`__ =========================== __ http://mail.python.org/pipermail/python-dev/2002-November/030520.html Mark Hammond asked how the upcoming change in Python 2.4 of hex/oct constants will affect his C extension code and something like ``PyArg_ParseTuple()`` (this function takes arguments passed to something and breaks it up into its individual parts since all arguments are passed as tuples in C code). In case you don't know about the warnings, Python 2.3 warns you that code like ``SOMETHING = 0x80000000`` could have a different meaning in Python 2.4; most likely it will be treated as a positive long. You can currently get rid of the warnings by changing the constant into a long by tacking on a ``L`` to the end of the number. Martin v. Loewis that if Mark appended the ``L`` to his constants that it would not work for an ``i`` argument for ``PyArg_ParseTuple()``. But Guido stepped up and said that there will be no issue since Python will be changed so that Mark's code will accept the constant as a positive long. This caused Guido to wonder if the warning could be changed to some other warning that is not normally printed out. Guido then mentioned that he has "long promised a set of new format codes for PyArg_ParseTuple() to specify taking the lower N bits (for N in 8, 16, 32, 64) and throwing the rest away, without range checks". "If someone else can get to this first, that would be great". So someone be nice to Guido and do this for him. =) Either way no specific resolution has been reached. As of right now you can just live with the warnings, supress the warnings, or change your constants to longs and hope you are not passing into a C extension function that wants an int. ========================================== `assigning to new-style-class.__name__`__ ========================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030475.html Michael Hudson has been working on `patch #635933`_ to allow for assignment to ``__name__`` and ``__bases__`` for new-style classes (this was all so that ``__name__`` would handle nested classes properly to allow for proper pickling; that thread was called `metaclass insanity`_ ). He ran into a slight issue with dealing with assigning to ``__name__``. To get it working, Michael wanted to treat heap and non-heap types differently. For non-heap types Michael wanted to "everything in tp_name up to the first dot is __module__, the rest is __name__". For non-heap types, he wanted to have ``__module__`` as "always __dict__['__module__'], __name__ is always tp_name (or rather ((etype*)type)->name)". And as for the issue of if someone is crazy enough to delete the dict key of ``__module__``, Michael said Python wouldn't crash but you probably would not like the outcome of running code. =) Guido responded saying that Michael's proposal was acceptable. But then there was an issue with ``.mro()`` after the bases had been rearranged. Michael worried about what to do when there was a conflict down the intheritence tree. He thought reverting back to the way things were if there was an issue was best. This would require keeping around copies of the previous states until the changes propogated all the way through. Samuele Pedroni stepped in to try to answer this question (Samuele rewrote the MRO code recently and is directly mentioned in `C3 implementation`_ ). He came up with a possible case where there could be a possible order disagreement if two of the bases of a class had the same bases but one had the order swapped compared to the other (so C has bases of (A, B) and D has bases of (A, B) as well and E had bases (C, D); if C's bases became (B, A), E now has an order disagreement). He suggested that "the mros of the subclasses should be computed lazily when needed (e.g. on the first - after the changes - dispatch), although this may produce inconsistences and errors at odd times". Michael showed that his solution would catch the problem. But he did not like the idea of lazily evaluating; he wanted a more restrictive solution since this is a new thing. Michael stated that what he wanted this for was to "to swap out one class for another -- making instances of the old class instances of the new class, which was possible and making subclasses of the old subclasses of the new, which wasn't". It also turned out neither APL nor Dylan allow this kind of thing so Michael is breaking new ground. Samuele asked about when the classes had solid bases (i.e., only a single superclass such as ``object``). Michael said it would handled with no problem. .. _C3 implementation: http://mail.python.org/pipermail/python-dev/2002-October/029230.html .. _patch #635933: http://www.python.org/sf/635933 .. _metaclass insanity: http://mail.python.org/pipermail/python-dev/2002-November/029872.html ===================== `Classmethod Help`__ ===================== __ http://mail.python.org/pipermail/python-dev/2002-November/030452.html Raymond Hettinger emailed the list because Guido said that the few people in the world who understand descriptors for C code are on the list. The main reason I am mentioning the thread here, though, is because Armin Rigo gave the answer that "There are METH_CLASS and METH_STATIC flags that you can set in the tp_methods table". You also learn, thanks to Guido, that you should only use ``PyErr_BadInternalCall()`` when you know that a "bad argment must have been created by a broken piece of C code". From anandpillai6@yahoo.com Tue Dec 3 16:03:18 2002 From: anandpillai6@yahoo.com (Anand) Date: 3 Dec 2002 08:03:18 -0800 Subject: PyWiew 0.4 released Message-ID: PyWiew, original image viewer/editor written in wxPython/PIL(Python Imaging Library) is released under LGPL. PyWiew Homepage: http://www.angelfire.com/linux/anand Thanks folks! Anand From henrik.ekelund@poboxes.com Tue Dec 3 16:42:56 2002 From: henrik.ekelund@poboxes.com (Henrik Ekelund) Date: 3 Dec 2002 08:42:56 -0800 Subject: ANN: adodbapi - A Python DB API 2.0 interface to Microsoft ADO Message-ID: NAME: adodbapi - A Python DB API 2.0 interface to Microsoft ADO DESCRIPTION: A 100% Python-DB API 2.0 compliant module that makes it easy to use Microsoft ADO for connecting with databases and other data sources. Includes pyunit testcases. PLATFORM: Windows only HOMEPAGE: DOWNLOAD: AUTHOR: Henrik Ekelund LICENSE: Lesser GPL (fine for most commercial vendors) From grashpr@htc.net Tue Dec 3 03:26:09 2002 From: grashpr@htc.net (Kurt Daesch) Date: Mon, 2 Dec 2002 22:26:09 -0500 (EST) Subject: [Application] Securum 1.0 (One of the several latin derivitives for the english word secure) Message-ID: Securum 1.0 (One of the several latin derivitives for the english word secure) ------------------------------------------------------------------------------ An encrypted im/email client server application An encrypted im/email client/server application using custom algorhythms I wrote for secure communcation over network. Very Simple interface. I dare you to crack it! Website coming very soon I also have a *nix version and I will post it here. Will be coming out soon with a p2p chat program employing the same encryption. Download: http://securum.batcave.net/setup.exe Platform: Win32, But Have *nix version as well Requires: wxPython Binaries: yes win32 Gui: wxPython Categories: Applications Kurt Daesch (grashpr@htc.net) under construction coming very soon -- Securum 1.0 (One of the several latin derivitives for the english word secure) -- An encrypted im/email client server application From abpillai@lycos.com Tue Dec 3 15:36:43 2002 From: abpillai@lycos.com (PyWiew) Date: Tue, 3 Dec 2002 10:36:43 -0500 (EST) Subject: [Application] PyWiew/0.4 Message-ID: PyWiew/0.4 ---------- Imageviewer /editor in wxPython using PIL(optional) Image viewer cum editor written in python. Uses wxPython for GUI and PIL for image effects(optional). Features: Open/write any kind of image Multithreaded slideshow URL: http://www.angelfire.com/linux/anand Download: http://www.angelfire.com/linux/anand/PyWiew.pyw License: LGPL Platform: NO Requires: wxPython, PIL(optional) Binaries: NO Gui: wxPython Categories: Graphics, wxPython Widgets PyWiew (abpillai@lycos.com) http://www.angelfire.com/linux/anand/ -- PyWiew/0.4 -- Imageviewer /editor in wxPython using PIL(optional) From gusthy@enternet.hu Wed Dec 4 19:12:01 2002 From: gusthy@enternet.hu (Attila Molnar) Date: Wed, 4 Dec 2002 14:12:01 -0500 (EST) Subject: [Application] PyDBDesigner Message-ID: PyDBDesigner ------------ Relational Database Modeling tool PyDBDesigner is a relational database modeling tool similar to Erwin and PowerDesigner. It is intended to support physical and logical models, reverse engineering, SQL creation etc. URL: pydbdesigner.sourceforge.net License: GPL Gui: wxPython Categories: Database Attila Molnar (gusthy@enternet.hu) -- PyDBDesigner -- Relational Database Modeling tool From sholden@holdenweb.com Wed Dec 4 21:43:58 2002 From: sholden@holdenweb.com (Steve Holden) Date: Wed, 4 Dec 2002 16:43:58 -0500 Subject: PyCon DC 2003: Call For Papers References: <08eb01c29a79$b64fab30$6300000a@holdenweb.com><20021204164724.GD16807@epoch.metaslash.com><15854.12961.85851.596358@slothrop.zope.com><008401c29bcb$c5f37b90$7101a8c0@holdenweb.com> <15854.23287.333274.610359@slothrop.zope.com> Message-ID: PyCon DC 2003, the first Python Community Conference, has now issued a formal call for papers, which you can read at www.python.org/pycon/cfp.html The organizing committee is interested in any and all submissions for presentations. Traditional presentation styles will doubtless be the norm, but if you would like to experiment with a different format you are encouraged to mail suggestions to pycon-interest at python dot org if you are a subscriber to that list, or to the address given at the foot of this message. Time is short, so please make sure any questions are sent in promptly. We will do our best to turn them around quickly. We look forward to seeing you at PyCon DC 2003, for which registration details should be published shortly. Steve Holden PyCon Committee Chair pycondc-2003 at python dot org From Stephen.Kennedy@havok.com Thu Dec 5 12:04:41 2002 From: Stephen.Kennedy@havok.com (Stephen Kennedy) Date: Thu, 5 Dec 2002 12:04:41 -0000 Subject: [Application] Meld 0.6.2 References: Message-ID: Meld 0.6.2 ---------- Diff and merge tool written in python/gnome2. Features: 2/3 way file diff. 2/3 way directory diff URL: http://meld.sf.net Screenshots: http://meld.sourceforge.net/screenshots.html Download: http://sourceforge.net/project/showfiles.php?group_id=53725 License: GPL Requires: gnome2, python-gnome-1.99.13 Gui: python-gnome Categories: Developers, Version Control Stephen

Meld 0.6.2 a gnome2 diff and merge tool. (05-Dec-02) From QHZidtwBLe5m@naply.ut.us Fri Dec 6 00:34:55 2002 From: QHZidtwBLe5m@naply.ut.us (Ben) Date: Fri, 06 Dec 2002 00:34:55 GMT Subject: spammers in moderated groups?! Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Ever wish you could spam the moderated groups? There is every reason to want to. Fewer competing spams, more attentive readership, better propagation. Moderators control the newsgroups no longer. Now you can spam the moderated newsgroups. For more information, post questions to: NEWS.ADMIN.NET-ABUSE.EMAIL -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.2.6 HHjmUKXbiA2E7PRbnFhiCeDf5Rcnnx/RmxwXn+w1ZOpSg7CYEdkEpWbcD43ESmx2 xRCsOBGlsI7e+igwLTZuYPlZg6Ag/RYncxqjIFdfBelxnUTq50iyXhR8+us1ctc8 XCNiTp5plXmyPw86q3scFJAPVkyuhjWLqNdqzIxnyVAiLUga8B9ru3D32D0sfSj0 mjKuf40+G9TiewhcNvSLRTvLqlCXCoXb/ci5Yj== =ORUg -----END PGP SIGNATURE----- He can rigidly play alongside stupid think barns. From vDDEswljB@ZORNYPE.NET.AR Fri Dec 6 00:47:26 2002 From: vDDEswljB@ZORNYPE.NET.AR (Rahavan Jarrah) Date: Fri, 06 Dec 2002 00:47:26 GMT Subject: if you will irritate Shah's hall alongside clouds, it will surprisingly wander the fork Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Ever wish you could spam the moderated groups? There is every reason to want to. Fewer competing spams, more attentive readership, better propagation. Moderators control the newsgroups no longer. Now you can spam the moderated newsgroups. For more information, post questions to: NEWS.ADMIN.NET-ABUSE.EMAIL -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.3.4 D8FnYcSlQMRkdidkBQhqk8sMv/ew7cKXJmXMhUW5k97+JYAgMVNgwshCTxMo9KUu t2YaEjT90RnjeZBdukD3IZ30WqdYrmAN5CyCDcM/xo34rnIz2d1OADaCL6TkChNr FWV9iRf9Q+2dPyi74vQW+i4q1dK0nDhXP7tyh3AnEf61X3pfGxwz6WG0bqB0gduq OO8urvIk9hhsGg0ay/b4PBEfoJEr+bXnNAfPim== =jTg+ -----END PGP SIGNATURE----- The wet desk rarely irrigates Josef, it covers Mustafa instead. From rozen@mcn.org Fri Dec 6 02:10:30 2002 From: rozen@mcn.org (Don Rozenberg) Date: Thu, 05 Dec 2002 18:10:30 -0800 Subject: ANN: PAGE-2.2c - Python Automatic GUI Generator Message-ID: PAGE-2.2c - Python Automatic GUI Generator What is PAGE? ----------- PAGE is an automatic GUI generator which bears a resemblance to Visual Basic. It allows one to easily create GUI window containing a selection of Tk and Tix widgets and bind actions associated with events in those widgets with a straight-forward, visual paradigm. It is a Tcl/Tk/Tix program that generates a Python module that realizes the desired GUI. Further, it supports rework in that one can generate a Python GUI module, debug it in the Python space, and yet be able to return to the Tcl/Tk realm to modify or update the appearance of the GUI or change the bindings on the widgets What's new? ----------- Fixed numerous problems in PAGE-2.2c. Fixed and documented the generation of menus. Fixed and documented the bindings window so now it is highly usable. Removed preferences that were hard to fathom. Added Python colorization to some of the PAGE windows. Rewrote p2t. It is now much more solid than previously and improves rework capabilities. p2t.py converts a Python GUI generated with PAGE into a tcl module that can be opened by PAGE. Included Vrex as an example. This is a very useful visual program for developing and checking regular expressions. It is similar to Visual REGEXP. Included an extension package that enhances python-mode.el in executing a python module with both the interpreter and debugger. It also allows one to run PyChecker from emacs. Improved the documentation. Home *Page* --------- http://*page*.sourceforge.net/ Download ---------- http://sourceforge.net/projects/page License --------- GPL

PAGE 2.2c PAGE - A drag and drop GUI generator for Python (01-Dec-02) -- Don Rozenberg 707-882-3601 rozen@mcn.org From knight@baldmt.com Fri Dec 6 04:18:06 2002 From: knight@baldmt.com (Steven Knight) Date: Thu, 5 Dec 2002 22:18:06 -0600 (CST) Subject: ANNOUNCE: SCons 0.09 is now available Message-ID: 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.09 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. This is a big release that took a long time to produce, mainly due to the addition of the major new Repository feature. WHAT'S NEW IN THIS RELEASE? IMPORTANT: Release 0.09 contains the following interface changes: - The SetCommandHandler() function has been superceded by new SPAWN, SHELL and ESCAPE construction variables. - SCons now exits with an error message if any source or implicit dependency files for a target do not exist and have no Builder. - The 'lib' tool (the Microsoft library archiver) has had its name changed to 'mslib'. This release adds the following features: - A new Repository() method and -Y command-line option support building from source or target files in common repositories. - A new Prepend() Environment method appends values to the beginning of construction variables. - Support for the Intel Fortran Compiler (ifl.exe) has been added. - New messages tell when SCons is "Reading SConscript files ...," "done reading SConscript files," "Building targets," and "done building targets." A new -Q option supresses these. - Shared-object prefixes and suffixes may be specified independently usng new $SHOBJPREFIX and $SHOBJSUFFIX construction variables. - A new ParseConfig() command supports modifying an environment based on parsing output from a *-config command. - New EnsurePythonVersion() and EnsureSConsVersion() functions. - SCons now checks dynamically for the existence of utilities with which to initialize Environments by default. - SCons now supports Microsoft VC++ precompiled header (.pch) files, debugger (.pdb) files, and resource (.rc) files. - The File() and Dir() methods can now take a path-name string as the starting directory. - A new Options() object makes it easier to extend SCons' command- line arguments. - A new SetContentSignatureType() function allows use of file timestamps instead of MD5 signatures. The following fixes have been added: - Construction variable substition on scanner directories (in CPPPATH, F77PATH, LIBPATH, etc.) is now supported. - $$ in a string is now passed through as $. - File names and command lines with spaces and other odd characters are now fully supported. - The "lib" Tool (Microsoft library archiver) now supports long command lines. - Auto-deduced target file names now end up in the same directory as their source files. - Source files specified on the command line are no longer removed. - Using Default() with the -U option now fails gracefully. - SCons no longer unlinks files in certain situations when the -n option is used. - SCons now issues a warning when -c can't remove a target. - File names like '#/../foo' are now interpreted correctly on Win32 systems. - SCons now supplies an error message if there are no command-line or Default() targets specified. - The $ASPPCOM variable has been fixed for the GNU assembler. - The -U option is now properly case-insensitive on Win32 systems. - Using the -j option with multiple targets is now more robust. - SCons now handles a corrupt .sconsign file robustly. - Access and modification times of files in a BuildDir now match the corresponding source file, even without hard links. - Dependencies now propogate succesfully through Alias targets. - Fix unnecessary rebuilds cased by differently-ordered targets on case-insensitive systems. - Dependency scans when $LIBS is overridden now work properly. - Build errors in a list of build commands no longer cause the display of an overly-verbose stack trace. Performance has been improved as follows: - Unnecessary Scanner calls have been eliminated when a file doesn't exist. - The $_CPPINCFLAGS, $_F77INCFLAGS, $_LIBFLAGS and $_LIBDIRFLAGS variables are now generated on-demand, not with every command invocation. - Command execution overhead has been reduced by using the Python os.sytem() function instead of fork() and exec(). The following changes have been made to the SCons packaging: - New scons-local packages make it easy to ship SCons as a stand-alone build tool in other software packages. The documentation has been improved: - Documented the fact that Builder calls return Node objects. - Documented all new features, of course... 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 Thanks to Chad Austin, Matt Balvin, Steve Leblanc, Jeff Petkau and sam th for their contributions to this release. Special thanks to Charles Crain for heavy work on the Repository feature, and Anthony Roach for a tremendous number of bug fixes and other features. On behalf of the SCons team, --SK From wesc@fuzzyorange.com Fri Dec 6 07:31:51 2002 From: wesc@fuzzyorange.com (Wesley Chun) Date: Thu, 5 Dec 2002 23:31:51 -0800 (PST) Subject: ANN: BayPIGgies mtg Wed 12/11 7:30pm Message-ID: BayPIGgies: Silicon Valley-San Francisco Bay Area Python Users Group When: December 11, 2002 @ 7:30pm Where: Stanford University, Palo Alto, CA Agenda: Newbies' Nite Speaker: (everyone!) Due to popular demand, we are having another Newbie Night (e.g. April 2002). This is the chance for all Python programmers to bring their friends and colleagues who should hear about Python. It is also for those who want to or are picking up Python and have questions! We will have a good number of Python experts who will try and help you out. Perl and Java experts are welcome too, as many Python developers also have experience there and can give you an honest comparison. The format is this: Wesley (or Danny) will give just a short half-hour intro presentation on Python to beginners followed by a quick demo, and then we will open it up to everyone for Q&A. Mingling and networking will bring our meeting to a glorious conclusion. :-) # NOTE: the next meeting on January 8, 2003 will be not be at the usual # place... stay tuned for a location update. # Call For Talks: We are actively seeking speakers for BayPIGgies! If you would like to give a talk at one of our 2003 meetings (any Python related topic), contact us to coordinate! more info including directions: http://www.baypiggies.net hope to see some of you next Wednesday! -wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall PTR, =A9 2001 http://starship.python.net/crew/wesc/cpp/ Silicon Valley-San Francisco Bay Area Python Users Group (BayPIGgies) http://deirdre.org/baypiggies wesley.j.chun :: wesc at deirdre.org cyberweb.consulting : henderson, nv : cyberweb at rocketmail.com http://www.roadkill.com/~wesc/cyberweb/ From j-david@noos.fr Fri Dec 6 16:08:32 2002 From: j-david@noos.fr (=?ISO-8859-1?Q?Juan_David_Ib=E1=F1ez_Palomar?=) Date: Fri, 06 Dec 2002 17:08:32 +0100 Subject: XPY 0.1.0 released Message-ID: Download from http://sourceforge.net/projects/lleu/ XPY stands for XPath PYthon, it is a tool to transform XML documents to something else. It is inspired by XSLT, the main difference is that the transformation language is Python. First the XML document is loaded as an extended DOM tree, where each node has new methods that begin with the prefix 'xpy_', these methods define a higher level API used to transform the tree. We will call this extended tree an XPY tree. Once it is loaded it can be transformed with the standard DOM API or with the XPY one. The XPY API lets to use XPath expressions to match nodes in the tree, then Python functions are applied to these nodes. We will call rules to these Python functions, following the terminology from XSLT. Typically there are one or more templates (XML documents) which are transformed by rules (Python functions) using the XPY API. To generate the final tree these rules use data that could be stored in a database, for example. So we have three different elements: the presentation, the logic and the content, achieving a better separation between them than most tools. Each element is implemented using the best posible way: a general purpose programming language for the logic, Python; a description language for the presentation, XHTML for example; and a database for the content (a relational database, the ZODB, etc..). The main advantage of this separation is scalability, it is possible to refactor the code without limits, unlike the most commonly used template languages; and the source looks much more like the final result. Best regards, -- J. David Ibáñez, http://www.j-david.net Software Engineer / Ingénieur Logiciel / Ingeniero de Software From baas@ira.uka.de Sat Dec 7 19:06:40 2002 From: baas@ira.uka.de (Matthias Baas) Date: Sat, 07 Dec 2002 20:06:40 +0100 Subject: ANN: Python Computer Graphics Kit v1.0beta3 Message-ID: The third beta release of the Python Computer Graphics Kit is available at http://cgkit.sourceforge.net What is it? ----------- The kit is a collection of Python modules that contain the basic types and functions required for creating 3D computer graphics images. You'll get new types such as vectors, matrices and quaternions and a complete RenderMan binding that contains all the functions from the current spec (v3.2). Additionally, the kit contains some of the functionality from the Shading Language (noise and other SL functions that can exist without an actual rendering context). The RenderMan binding is as close as possible to the C version, but still provides the flexibility found in Python (like using keyword arguments or using vectors directly as input). The kit should run on any platform where Python (and a C/C++ compiler) is available. Windows users can download a binary version for Python 2.2. What's new? ----------- The entire cgtypes module was rewritten using Pyrex. The vector and matrix operations are something between 2 and 20 times faster now (the matrix inversion was even around 240 times faster in my tests). The new types require Python 2.2 (since Pyrex uses some new features), but the old pure Python types are still available in the pycgtypes module. For more information, visit: http://cgkit.sourceforge.net - Matthias - From pearu@cens.ioc.ee Sun Dec 8 17:20:39 2002 From: pearu@cens.ioc.ee (Pearu Peterson) Date: Sun, 8 Dec 2002 19:20:39 +0200 (EET) Subject: ANN: F2PY - Fortran to Python Interface Generator - 6th Release Message-ID: F2PY - Fortran to Python Interface Generator, Version 2.32.225 --------------------------------------------------------------- I am pleased to announce the sixth public release of F2PY. The purpose of the F2PY project is to provide a connection between Python and Fortran programming languages. For more information, see http://cens.ioc.ee/projects/f2py2e/ Download source: http://cens.ioc.ee/projects/f2py2e/2.x/F2PY-2-latest.tar.gz What's new? ------------ It has been almost a year from the previous release of F2PY. This release comes with a number of improvements, most important ones are listed as follows: - The issue with a Fortran and C multi-dimensional array storage ordering is finally resolved. F2PY generated wrappers automatically carry out all necessary transformations, trying hard to minimize any performance hits. As a result, the end users of F2PY generated wrappers need not to worry about this issue anymore, multi-dimensional arrays in Python and Fortran have now exactly the same signatures. - Improved wrapping C functions with F2PY. - F2PY Users Guide has been throughly revised to describe and illustrate all latest F2PY features such as wrapping Fortran 77 COMMON blocks, Fortran 90 module data, including Fortran 90 module ALLOCATABLE arrays, etc. The F2PY Users Guide is composed using the Python Docutils tool and is available here: http://cens.ioc.ee/projects/f2py2e/usersguide/ - F2PY has new site for unit testing. - F2PY uses scipy_distutils from SciPy (www.scipy.org) project for compiling Fortran sources and building extension modules. Currently, the following Fortran 77/90 compilers are described by scipy_distutils: Absoft Sun SGI Intel Itanium NAG Compaq Digital Gnu VAST - Finally, F2PY has been extensively used/tested for wrapping large Fortran/C libraries, such as, LAPACK, BLAS, ATLAS, FFTW, FFTPACK, etc. (see SciPy project for more information). This experience has been a very important source for ideas how to make binding Fortran/C codes to Python easier and more robust. Enjoy, Pearu Peterson ---------------

F2PY 2.32.225 - The Fortran to Python Interface Generator (08-Dec-02) From thomas@thurman.org.uk Mon Dec 9 09:16:16 2002 From: thomas@thurman.org.uk (Thomas Thurman) Date: Mon, 9 Dec 2002 09:16:16 +0000 Subject: [Application] Yarrow RGTP client 1.2.0 released Message-ID: Yarrow 1.2.0 released --------------------- Yarrow is a web CGI front end to the RGTP message board protocol, as used on the Cambridge GROGGS system, for Linux and compatible systems. It includes an RGTP back end that can be used by other Python-based clients. New in this version: * Distutils-based installation script. * HTTP compression support and basic caching support. * If the user has sufficient permission on the RGTP server, they may change the message of the day and edit the user database. * All reliance on static HTTP content is removed, making installation simpler. All CSS is included within the HTML. * Enhancements for those running text-only browsers. * Tidying and bug fixing. You can download it from: ftp://ftp.thurman.org.uk/pub/thurman/rgtp/yarrow-1.2.0.tar.gz ftp://ftp.thurman.org.uk/pub/thurman/rgtp/yarrow-1.2.0.tar.bz2 CVS web access at: http://source.publication.org.uk/yarrow/Yarrow/ You can experiment with an installed version at: http://rgtp.thurman.org.uk/gossip Screenshots at: http://rgtp.thurman.org.uk/yarrow/screenshots/ Manual at: http://rgtp.thurman.org.uk/yarrow/docs/ Yarrow is implemented in Python, and released under the GNU General Public License. T From chus@lcdx00.wm.lc.ehu.es Mon Dec 9 18:45:18 2002 From: chus@lcdx00.wm.lc.ehu.es (Jesus Fernandez) Date: Mon, 9 Dec 2002 19:45:18 +0100 (MET) Subject: PyClimate 1.2. Analysis of atmospheric and oceanic data Message-ID: Announce: PyClimate 1.2, 09 Dec 2002 We present version 1.2 of our package PyClimate: http://www.pyclimate.org It is dedicated to the analysis of atmospheric and oceanic data sets using Python. It makes heavy use of NumPy and some of our own C extensions to speed up the code. It is distributed according to the GNU General Public License Version 2 (it is free). The updates from version 1.1.1 to 1.2 comprise: a) Some minor bugs corrected. b) Several changes in Principal Component Analysis routines. The old module has been object oriented and a new module allows to process huge data sets. c) Added a netCDF iterator to search tranparently a time record through many of this files. d) Monte Carlo test for the Barnett-Preisendorfer version of the CCA e) Analog search for downscaling purposes f) Array of numerical histograms (NHArray.py) g) Cleaner name spaces h) Statistical tests added to tools.py i) Nearly 100% doc-string documented code and happydoc generated on-line documentation. We would appreciate feedback by users. Enjoy ;-) Jon Saenz, jsaenz@wm.lc.ehu.es Jesus Fernandez, chus@wm.lc.ehu.es Juan Zubillaga, juan@zubi.net

PyClimate 1.2 - Analysis of Atmospheric and Oceanic Data Sets using Python. (09-Dec-02)

From mwh@python.net Tue Dec 10 17:48:04 2002 From: mwh@python.net (Michael Hudson) Date: Tue, 10 Dec 2002 17:48:04 +0000 (GMT) Subject: pyrepl opens up: CVS, mailing list. Message-ID: Pyrepl is my library for building interactive command line interfaces, currently living at: http://starship.python.net/crew/mwh/hacks/pyrepl.html With much credit to Holger Krekel, pyrepl now has its own CVS repository, web site and mailing list. CVS isn't (yet?) accessible anonymously, but you can see a viewcvs instance here: http://cvs.pyrepl.codespeak.net/ although what's in the repo is currently just the last released version (0.7.2). The web site will at some point appear at: http://pyrepl.codespeak.net/ but currently that just redirects you to http://pyrepl.codespeak.net/mailman/listinfo/ where you can sign up for the two (so far) mailing lists: pyrepl-dev(at)codespeak.net pyrepl-checkins(at)codespeak.net (read-only) If you're at all interested in pyrepl, please sign up for these lists! I doubt that they will be noticeably high volume. See you there! Cheers, M. From wesc@fuzzyorange.com Wed Dec 11 02:18:10 2002 From: wesc@fuzzyorange.com (Wesley Chun) Date: Tue, 10 Dec 2002 18:18:10 -0800 (PST) Subject: REM: BayPIGgies mtg Wed 12/11 7:30pm In-Reply-To: Message-ID: hi there, here is a reminder (with the correct date) for tomorrow night's meeting! hope to see some of you there... and bring your friends!! more info and directions at http://www.baypiggies.net and my original message below. -wesley ps. again, UC Santa Cruz is offering 2 Python classes Winter Quarter. i'll be instructing the standard Python Programming course, and there will be new course for complete newbies. just go to http://www.ucsc-extension.edu, hit the red "Course Search" tab and type "Python" into the keyword field to pull up info on both courses. the deadline is Dec 20. call Sherry at 408-861-3765 or e-mail her at smirkarimi at ucsc-extension.edu On Thu, 5 Dec 2002, Wesley Chun wrote: > BayPIGgies: Silicon Valley-San Francisco Bay Area Python Users Group > > When: December 11, 2002 @ 7:30pm > Where: Stanford University, Palo Alto, CA > Agenda: Newbies' Nite > Speaker: (everyone!) > > Due to popular demand, we are having another Newbie Night (e.g. April > 2002). This is the chance for all Python programmers to bring their > friends and colleagues who should hear about Python. It is also for > those who want to or are picking up Python and have questions! We will > have a good number of Python experts who will try and help you out. Perl > and Java experts are welcome too, as many Python developers also have > experience there and can give you an honest comparison. > > The format is this: Wesley (or Danny) will give just a short half-hour > intro presentation on Python to beginners followed by a quick demo, and > then we will open it up to everyone for Q&A. Mingling and networking > will bring our meeting to a glorious conclusion. :-) > > # NOTE: the next meeting on January 8, 2003 will be not be at the usual > # place... stay tuned for a location update. > > # Call For Talks: We are actively seeking speakers for BayPIGgies! If you > would like to give a talk at one of our 2003 meetings (any Python related > topic), contact us to coordinate! > > more info including directions: http://www.baypiggies.net > > hope to see some of you next Wednesday! > > -wesley > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > "Core Python Programming", Prentice Hall PTR, =A9 2001 > http://starship.python.net/crew/wesc/cpp/ > > Silicon Valley-San Francisco Bay Area Python Users Group (BayPIGgies) > http://deirdre.org/baypiggies > > wesley.j.chun :: wesc at deirdre.org > cyberweb.consulting : henderson, nv : cyberweb at rocketmail.com > http://www.roadkill.com/~wesc/cyberweb/ From rjones@ekit-inc.com Wed Dec 11 03:34:45 2002 From: rjones@ekit-inc.com (Richard Jones) Date: Wed, 11 Dec 2002 14:34:45 +1100 Subject: SC-Track Roundup 0.5.3 - an issue tracking system Message-ID: ================================================= SC-Track Roundup 0.5.3 - 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!): - added mention of how to give users multiple Roles - mention needed trailing "/" in TRACKER_WEB - fixed upgrading doc to have CGI changes in the correct order - fixed double-close of anydbm backend (sf bug 639030) - removed use of string/strop from TAL/TALInterpreter - handle KeyboardInterrupt nicely - fixed Date and Interval form value handling - fixed Date.local() - email quoted text stripping is controllable again (sf bug 650742) - extract attachment name from content-disposition if name is missing (sf bug 637278) - removed FILTER_POSITION from bundled configs - reverse message listing in issue display (reversion of recent change) - bad entries for multilink editing in cgi don't traceback now (sf bug 640310) - detect and break email loops (sf bug 640854) - finished of handling of retired flag in filter() (sf bug 635260) - allow StringHTMLProperty in MultilinkHTMLProperty test to work - don't set explicit None Link properties in web create - fixed nasty sorting bug that was lowercasing properties - allow multiple :remove and :add elements per property being edited - added date header to emails (sf bug 651358) 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@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). From kponcin@aerotek.com Wed Dec 11 13:37:37 2002 From: kponcin@aerotek.com (Kristofer Poncin) Date: Wed, 11 Dec 2002 08:37:37 -0500 Subject: Python Positions Message-ID: This is a multi-part message in MIME format. --------------0F91B352CFFA65401C910022 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To whom it may concern: Greetings, my name is Kris Poncin, I am DoD Recruiter with Aerotek Engineering out of Northern Virginia (Metro DC). I currently have 3 openings for Software Test Engineers who can test Python Programs and develop Python Test Scripts. The following is the particular job posting: Title: Software Test Engineer, 3 vacancies. Location: McLean, Virginia Duration: 6 Month Contract Open ended Job Purpose: Work as a member of software test team to develop and test real time, embedded software applications. You will perform tests an evaluate situations based on established criteria and procedures. Qualifications: BS or BA from an accredited university or college, preferably in engineering, math, physics, or computer science or equivalent combination of education and experience. 5+ years or more of development and testing experience. Essential Duties: Analyze product requirements for testability and develop unit tests as required. Develop acceptance test procedures and automated test scripts. Run tests, analyze results, and assist with defect fixes. Develop and test Python Programs to validate IDM software. Required/Desired skills: Real time embedded C, C++, Ada95 or equivalent, Python scripting, Lynx OS, UNIX, Mil.Std. 1553, HW/SW integrations experience. MDPTLS experience a plus, this is the protocol that we are using. My contact info is as follows: Kris Poncin Recruiter DoD Aerotek Engineering 703-818-2034 800-528-0490 x2034 kponcin@aerotek.com --------------0F91B352CFFA65401C910022 Content-Type: text/x-vcard; charset=us-ascii; name="kponcin.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Kristofer Poncin Content-Disposition: attachment; filename="kponcin.vcf" begin:vcard n:Poncin;Kris tel;fax:703-818-2050 tel;work:703-818-2034 x-mozilla-html:FALSE url:www.aerotek.com org:
;Contract Engineering version:2.1 email;internet:kponcin@aerotek.com title:Recruiter adr;quoted-printable:;;12801 Fairlakes Parkway Suite 150=0D=0A;Fairfax;VA;22033; fn:Kris Poncin end:vcard --------------0F91B352CFFA65401C910022-- From Mark Matthews Thu Dec 12 05:02:38 2002 From: Mark Matthews (Dave Cole) Date: 12 Dec 2002 16:02:38 +1100 Subject: Object Craft Python modules announcement Message-ID: Hello all. The purpose of this message is to collect some testimonials from the users of our Open Source software. We have recently joined Open Source Victoria (http://www.osv.org.au), which has the stated objective of being: "a new advocacy group formed to educate Victoria's (Australian) business and government leaders about the benefits of using Open Source software for both server and desktop environments." Your stories will be used to help the advocacy efforts of Open Source Victoria and more importantly, raise the profile of Open Source in general. (Of course it also helps us and our software stand out in the local market). Open Source advocacy obviously lacks the benefit of an enormous marketing budget, and therefore requires efforts at a grass roots level. Business and Government are generally very conservative and need to see that other organisations have successfully deployed Open Source products. Our products are: Albatross - A Toolkit for Highly Stateful Web Applications http://www.object-craft.com.au/projects/albatross/ CSV - A high performance CSV parser for Python http://www.object-craft.com.au/projects/csv/ MSSQL - A MS SQL Server module for Python http://www.object-craft.com.au/projects/mssql/ Paint - A fast, simple Python wrapper of libart, freetype, and libpng. http://www.object-craft.com.au/projects/paint/ sdk32 - A partial Python Wrap of the Win32 Platform SDK http://www.object-craft.com.au/projects/sdk32/ Sybase - A Sybase module for Python http://www.object-craft.com.au/projects/sybase/ It may come as a surprise, but we really have very little idea of who is using our software and what they are using it for. We would love to hear from you. Any contribution will be greatly appreciated. Please send email to: Mark Matthews Object Craft Pty Ltd. -- http://www.object-craft.com.au From max@alcyone.com Fri Dec 13 01:54:40 2002 From: max@alcyone.com (Erik Max Francis) Date: Thu, 12 Dec 2002 17:54:40 -0800 Subject: ANN: fauxident 1.1 -- A simple, faked ident daemon Message-ID: Overview fauxident is a small Python script that will act as an extremely naive ident server, answering all ident requests with a consistent response -- either an ERROR or a USERID response. This can be advantageous on systems where running a true identd is unavailable, where it would be a security risk, or when masquerading firewalls are in use, where multiple machines are involved behind the firewall and running a proper ident system is not an option. Getting the software The current version of fauxident is 1.1. The latest version of the software is available in a tarball here: http://www.alcyone.com/pyos/fauxident/fauxident-latest.tar.gz. The official URL for this Web site is http://www.alcyone.com/pyos/fauxident/. Requirements fauxident requires Python 2.x or greater and a UNIX or Unix-like operating system. License This code is released under the GPL. ..... Release history - 1.1; 2002 Dec 7. Allow multiple user names to be chosen randomly from; include support for suffixed random number of given length; change to -V option for version information; improve documentation. - 1.0.1; 2002 Oct 15. Bugfix to reject large input buffers from the client, preventing a highly unlikely but possible DOS attack. - 1.0; 2002 Aug 14. Initial release. -- Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE / \ There is _never_ no hope left. Remember. \__/ Louis Wu Erik Max Francis' bookmarks / http://www.alcyone.com/max/links/ A highly categorized list of Web links. From Rimon Barr Fri Dec 13 05:06:21 2002 From: Rimon Barr (Rimon Barr) Date: Fri, 13 Dec 2002 00:06:21 -0500 (EST) Subject: spyce v1.3.4 released Message-ID: Spyce v1.3.4 released on 12 Dec 2002 SPYCE is a server-side language that supports simple and efficient Python-based dynamic HTML generation. Those who are familiar with JSP, PHP, or ASP and like Python, should have a look at Spyce. Its modular design makes it very flexible and extensible. It can also be used as a command-line utility for static text pre-processing. Get it at: http://spyce.sourceforge.net Improved explanations of the autosession functionality in the session module based. Changed how request filename is computed under mod_pythod to be slightly more reliable. Fixed Windows installer: it was unable to determine the Python path under certain conditions and bailed. -- Thanks for all the user feedback. Change log v1.3.4 doc updates - session module minor mod_python bug - filename attribute used over environment fix - windows installer unable to find python executable in some cases Enjoy, Rimon. From detlev@die-offenbachs.de Fri Dec 13 08:51:45 2002 From: detlev@die-offenbachs.de (Detlev Offenbach) Date: Fri, 13 Dec 2002 09:51:45 +0100 Subject: ANN: Eric 3.0.0 released Message-ID: Hi, After having received no bug reports for the last two weeks I am proud to announce that Eric 3.0.0 is available for download via http://www.die-offenbachs.de/detlev/eric3.html This is the final release. For details see the history file in the distribution. What is it? ----------- Eric 3.0.0 (or short eric3) is a Python IDE written using PyQt and QScintilla. It has integrated project management capabilities, it gives you an unlimited number of editors, an integrated Python shell, an integrated debugger and more. Please see for yourself by visiting the a.m. page (it contains a picture of Eric our mascot as well). Please report bugs, feature wishes or code contributions to eric-bugs@die-offenbachs.de Help wanted!! ------------- I would need some support in the area of more translations and user documentation. Any volunteers out there? Just let me know. Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From detlev@die-offenbachs.de Fri Dec 13 12:57:32 2002 From: detlev@die-offenbachs.de (Detlev Offenbach) Date: Fri, 13 Dec 2002 13:57:32 +0100 Subject: ANN: Eric 3.0.0 released Message-ID: Hi, after having received no bug reports for the last two weeks I am proud to announce that Eric 3.0.0 is available for download via http://www.die-offenbachs.de/detlev/eric3.html This is the final release. For details see the history file in the distribution. What is it? ----------- Eric 3.0.0 (or short eric3) is a Python IDE written using PyQt and QScintilla. It has integrated project management capabilities, it gives you an unlimited number of editors, an integrated Python shell, an integrated debugger and more. Please see for yourself by visiting the a.m. page (it contains a picture of Eric our mascot as well). Please report bugs, feature wishes or code contributions to eric-bugs@die-offenbachs.de Help wanted!! ------------- I would need some support in the area of more translations and user documentation. Any volunteers out there? Just let me know. Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From fdui@openlight.com Fri Dec 13 23:58:38 2002 From: fdui@openlight.com (fdui@openlight.com) Date: Fri, 13 Dec 2002 18:58:38 -0500 Subject: Flightdeck-UI MVM Application + version 0.1.4 released Message-ID: *** 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. This library release 0.1.4 is combined with the Multi-Variable Monitor (MVM) application release 0.1.0. The MVM is a highly configurable Flightdeck-UI application, which includes a graphical editor and theme support. Little (or even none at all) coding is required to use MVM, although everyone is welcome to code as much as they like. Check out the MVM screenshots at "http://www.openlight.com/fdui/screens.html". Linux/Unix users in particular can quickly assemble a monitoring application that would run in a small window on the desktop. An example is included in the distribution. MVM has been tested under Linux (RedHat 7.2) and a little under Windows 95. Although these are still development releases, the MVM should already be a useful application, and will probably look very nice on some corner of your desktop. The project homepage is at "http://www.openlight.com/fdui/". Both the Flightdeck-UI library and the MVM application are open source/free software. They are written in Python and require Tkinter. Questions can be emailed to originating address of this message. From edream@tds.net Sat Dec 14 14:03:41 2002 From: edream@tds.net (Edward K. Ream) Date: Sat, 14 Dec 2002 14:03:41 GMT Subject: ANN: Leo 3.10 outlining editor Message-ID: leo.py 3.10 is now available at: http://sourceforge.net/projects/leo/ leo.py requires Python 2.1 or above and tcl/tk 8.3 or above. 3.10 corrects bugs, improves Leo's documentation and adds many new features: The highlights of 3.10: ----------------------- - Rewrote the Scripting Chapter in Leo's Users Guide. - Improved the Customization Chapter of the Users Guide. - Adds several customizations contributed by Leo's users. Among these: @read-only nodes. Reading empty .leo files. Redirecting stderr and stdout to Leo's log pane. - New Mark Clones and Go To Next Clone commands. - New Export Headlines command. - Control-dragging a node now clones it. - New "Node Only checkbox in the Find/Change panel. - @root-code trees start in code mode by default. This allows @root trees to work like @file trees. - @root-doc trees start in doc mode by default. - Converted leoConfig.py to use @root-code - New at_root_bodies_start_in_doc_mode option in leoConfig.py. Specifies whether @root trees work like @root-code or @root-doc. - New synonyms: @file-asis = @silentfile @file-nosent = @nosentinelsfile ; @file-noref = @rawfile. - Leo now supports navigation of menus using underlined menus. - Added an easy way to replace any Leo method by a function. The code in customizeLeo.py can now override part of Leo's code! - Added routines to redirect stderr and stdout to Leo's log pane. These routines can be called from customizeLeo.py. - Added "event1" and "event2" hooks for customized event handling. - Improved Leo's window icon, and improved how that icon is loaded. - The usual assortment of bug fixes and minor improvements. Actually, this release fixes more than the usual number of bugs. Quote of the month ------------------ I must say I am very impressed. I have been absolutely seduced by Leo over the past few days. I tell you, I can not put it down. I feel like a kid with a shiny new bike...I'm already bursting with new ways I'd like to use the tool in the future -- Lyn Adams Headley What is Leo? ------------ - A programmer's editor, an outlining editor and a flexible browser. - A literate programming tool, compatible with noweb and CWEB. - A data organizer and project manager. Leo provides multiple views of projects within a single outline. - Fully scriptable using Python. Leo saves its files in XML format. - Portable. leo.py is 100% pure Python. - Open Software, distributed under the Python License. Links: ------ Leo: http://personalpages.tds.net/~edream/front.html Home: http://sourceforge.net/projects/leo/ Download: http://sourceforge.net/project/showfiles.php?group_id=3458 CVS: http://sourceforge.net/cvs/?group_id=3458 Edward -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- From skip@pobox.com Sat Dec 14 18:27:21 2002 From: skip@pobox.com (Skip Montanaro) Date: Sat, 14 Dec 2002 12:27:21 -0600 Subject: New version of Watch - a typing/mouse monitor Message-ID: I'm sick of fiddling with Watch, so I'm announcing a new version. (How's that for arbitrary?) Aside from fixing some annoying bugs and introducing others, the most significant new feature is that it now coordinates activity on multiple systems using a small XML-RPC server to keep track of idle time. Here's a more complete description yanked from the docstring: Watch is a Tk-based program that monitors work and rest times for keyboard and mouse use to help users avoid overuse that can lead to or exacerbate repetitive strain injuries. The user can define the duration of work and rest intervals. In fascist mode, the user can't override the displayed rest window. In friendly mode, a cancel button is available to allow the user to prematurely terminate the rest interval. Watch currently runs on Linux, Windows and MacOSX systems as long as Tkinter is available. It's never been tried on MacOS 9, but there isn't any insurmountable reason why it can't be made to work there either. In case you like the concept, there is still lots to do: * The code's a mess. * The state machine needs to be better separated from Tkinter so that other widget toolkits can be (more easily) substituted for Tkinter. * I believe there's a bug in the transition from the rest phase to the work phase, though I haven't looked closely at that. Until you're happy that it's working reliably, you should enably its friendly mode so you don't get stuck with a cover window that won't disappear. * I don't know how well (or if at all) the XML-RPC server can be spun off from non-Unix platforms. * On non-Linux platforms keyboard activity can either not be tracked or in some situations can only be hinted at (e.g. the jiggle-mouse function for Emacs). * It's completely unpackaged. Originally, it was a single file. It's now three (two applications and a shared module). The only way to get it at the moment is to use CVS. Watch can be found at it's SF home: http://sourceforge.net/projects/watch Feedback is always welcome. -- Skip Montanaro - skip@pobox.com http://www.mojam.com/ http://www.musi-cal.com/ From pinard@iro.umontreal.ca Sat Dec 14 18:50:30 2002 From: pinard@iro.umontreal.ca (=?iso-8859-1?q?Fran=E7ois_Pinard?=) Date: 14 Dec 2002 13:50:30 -0500 Subject: RELEASED: Pymacs 0.21 Message-ID: Hello to everybody, and Emacs users in the Python community. A Pymacs flaw has been discovered by Marco Gidde, by which opaque Python references are returned back to Python from Lisp with extra cruft in the communication protocol. I'm even surprised that this problem never hit me yet. I suggest that current Pymacs users upgrade to this new 0.21 version. -------------------- Pymacs is a powerful tool which, once started from Emacs, allows both-way communication between Emacs Lisp and Python. Pymacs aims Python as an extension language for Emacs rather than the other way around, and this assymetry is reflected in some design choices. Within Emacs Lisp code, one may load and use Python modules. Python functions may themselves use Emacs services, and handle Emacs Lisp objects kept in Emacs Lisp space. `http://www.iro.umontreal.ca/~pinard/pymacs/' contains a copy of the Pymacs documentation in HTML form. The canonical Pymacs distribution is available as `http://www.iro.umontreal.ca/~pinard/pymacs/Pymacs.tar.gz'. Report problems and suggestions to `mailto:pinard@iro.umontreal.ca'. -- François Pinard http://www.iro.umontreal.ca/~pinard From uche.ogbuji@fourthought.com Sun Dec 15 17:15:27 2002 From: uche.ogbuji@fourthought.com (Uche Ogbuji) Date: Sun, 15 Dec 2002 10:15:27 -0700 Subject: Article: "A Python & XML Companion" Message-ID: http://www.xml.com/pub/a/2002/12/11/py-xml.html I offers updates and notes on Python & XML, by Jones and Drake. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Tour of 4Suite - http://www.xml.com/pub/a/2002/10/16/py-xml.html Proper XML Output in Python - http://www.xml.com/pub/a/2002/11/13/py-xml.html RSS for Python - http://www-106.ibm.com/developerworks/webservices/library/ws-p yth11.html Debug XSLT on the fly - http://www-106.ibm.com/developerworks/xml/library/x-deb ugxs.html From gerhard.haering@gmx.de Sun Dec 15 23:55:37 2002 From: gerhard.haering@gmx.de (Gerhard =?iso-8859-1?Q?H=E4ring?=) Date: Mon, 16 Dec 2002 00:55:37 +0100 Subject: pyPgSQL 2.3 released Message-ID: [Yes, I know this announcement is going out a week late] Announce: pyPgSQL - Version 2.3 is released. =========================================================================== pyPgSQL v2.3 has been released. It is available at http://pypgsql.sourceforge.net. pyPgSQL is a package of two (2) modules that provide a Python DB-API 2.0 compliant interface to PostgreSQL databases. The first module, libpq, is written in C and exports the PostgreSQL C API to Python. The second module, PgSQL, provides the DB-API 2.0 compliant interface and support for various PostgreSQL data types, such as INT8, NUMERIC, MONEY, BOOL, ARRAYS, etc. This module is written in Python and works with PostgreSQL 7.0 or later and Python 2.0 or later. It was tested with PostgreSQL 7.0.3, 7.1.3, 7.2.2, 7.3, Python 2.0.1, 2.1.3 and 2.2.2. Note: It is highly recommended that you use PostgreSQL 7.2 or later and Python 2.1 or later. If you want to use PostgreSQL Large Objects under Python 2.2.x, you *must* use Python 2.2.2, because of a bug in earlier 2.2 versions. Project homepages: pyPgSQL: http://pypgsql.sourceforge.net/ PostgreSQL: http://www.postgresql.org/ Python: http://www.python.org/ While there didn't change much under the hood, the build process was completely rewritten, so pyPgSQL should now build out of the box on most popular platforms. For you, this means that a "python setup.py build" will now hopefully just work. And for us, this means we'll have to answer less boring support questions :-) These platforms were tested and will build out of the box (of course, more testing won't hurt): UnixWare 7/OpenUNIX 8, Windows native, Cgwin, FreeBSD 4.7, Redhat Linux 7.3, SuSE Linux 7.3, Debian Linux 3.0. The build process is also designed to work with these platforms, but they could not be tested in real life (please do so, if you can!): Mandrake Linux, NetBSD, OpenBSD, MacOS X. If your platform isn't supported out of the box, you can edit a setup.py file to configure the build process. Patches for supporting additional platforms are more than welcome. Look into setup.py for how to do it. The other big change is that Gerhard finally gave up on getting more feedback on his Unicode patch and merged it into the pyPgSQL 2.x line. Hey, if it did work for Linux 2.4, it can work for us, too <0.7 wink>. Using Unicode works like this: from pyPgSQL import PgSQL con = PgSQL.connect(client_encoding=("utf-8", "ignore"), unicode_results=1) # where client_encoding are the parameters you normally give to the encode # method of a Unicode string. unicode_results=1 means pyPgSQL will return # VARCHAR/CHAR/TEXT fields as Unicode strings instead of byte strings. # As I refuse to do any magic, you'll also have to set the client encoding # for the database manually: cursor = con.cursor() cursor.execute("SET CLIENT_ENCODING TO UNICODE") # There are other ways to set the client encoding, including setting a # special environment variable (see PostgreSQL manual), but I recommend # doing it in code. Support for reference cursors was added. Since PostgreSQL 7.2, you could create cursors in PL/pgSQL and pass a reference to the open cursor back to the client. PgSQL will now cast those referenced cursors into a Cursor object that can be used to fetch the results in the cursor. For example (assuming that mmYearInfo() returns a reference curosr): $ python Python 2.2.2 (#7, Nov 27 2002, 17:10:05) [C] on openunix8 Type "help", "copyright", "credits" or "license" for more information. >>> from pyPgSQL import PgSQL >>> cx = PgSQL.connect(database='esi') >>> cu = cx.cursor() >>> cu.callproc('mmYearInfo') >>> rs = cu.fetchone() >>> rs [] >>> c = rs[0] >>> for i in c.description: ... print i ... ['model_year', varchar, 4, 8, None, None, None, 0] ['mktg_div_name', varchar, 50, 54, None, None, None, 0] ['model_desc', varchar, 50, 54, None, None, None, 0] ['book_types', varchar, 50, 54, None, None, None, 0] ['vehicle_syskey', integer, 4, 4, None, None, None, 0] >>> r = c.fetchone() >>> r ['2003', 'Buick', 'Century', '1;8;9', 2211] >>> --------------------------------------------------------------------------- ChangeLog: =========================================================================== Changes since pyPgSQL Version 2.2 ================================= The following source code files were added to Version 2.3 of pyPgSQL: unicode_tests.py - Test suite for the new Unicode support. Merged from the Unicode patch. Changes to setup.py ------------------- * This file was rewritten entirely so that pyPgSQL now builds out of the box on Windows, Cygwin, Debian Linux, Redhat Linux, SuSE Linux, FreeBSD, UnixWare 7 and OpenUNIX 8. These are the platforms the new build process has been tested on. Untested support is available for Mandrake Linux, NetBSD, OpenBSD and MacOS X. Changes to README ----------------- * Updates for 2.3. * Converted the whole document into reStructuredText, so we can easily built a HTML version using docutils (http://docutils.sf.net/). Changes to README.win32 ----------------------- * Remove out of date warning about PostgreSQL on win32 * Reflected change from windows/ to ports/ Changes to PgSQL.py ------------------- * Fixed various problems with the PgNumeric constructor and formatting routines. * Fixed problems with new __setupTransaction function: | 1. Made it a method of Connection, not Cursor. 2. inTransaction was only set if TransactionLevel was set. * Fixed instances where method name was incorrect: Connection__gcCursor -> _Connection__gcCursor Connection__closeCursor -> _Connection__closeCursor * Cleaned up code where there was unneeded references to conn in Connection class. | * Handle the new '__quote__' method for arrays, too. * Still handle '_quote' methods for backwards compatibility. * Fixed changed PG_TIMESTAMP oid, added PG_TIMESTAMPTZ and PG_REFCURSOR oids. * Reference cursors are now type-casted into cursor objects. * Completed the emulation of a String object for the PgBytea and PgOther classes. This corrects several problems with PgBytea concerning compari- sons, using PgBytea types as keys in dictionaries, etc. * Added the __hash__ function to the PgNumeric class. Cleaned up the code in PgNumeric class and made some small improvments to it. * Added the PgArray class. This is a wrapper around a Python list and is used for all PostgreSQL arrays. This change was made so that lists and tuples no longer have a special meaning in the Cursor.execute() method. * Changed the quoting methods defined in the various classes defining PostgreSQL support types to __quote__. * Merged the Unicode patch. pyPgSQL now has full Unicode support. * Added support for the INTERVAL type. * mxDateTime 1.x is no longer supported. Require mxDateTime 2.x and give useful error message if import fails. * Cosmetic changes: use cmp builtin where appropriate. * Fixed typo where PgTypes.__str__ was spelled incorrectly; compare to None using "is" operator. * Take into account that libpq.PgInt8Type might not be available. * Convert ROWID to PgInt8 instead of PgInt4 (the original behaviour led to overflow errors.) * Always set the displaysize field of cursor.description to -1. PostgreSQL 7.3 doesn't provide this information any more and it's pretty useless nowadays that we've mostly left line printers beyond us. Changes to pyPgSQL/__init__.py ------------------------------ * Register libpq.PgInt8 with copy_reg only if available. Changes to pglargeobject.c -------------------------- * Made the 'closed' attribute of PgLargeObject an int instead of a long. Changes to libpqmodule.c: ------------------------- * Fixed the changed PG_TIMESTAMP oid, added PG_TIMESTAMPTZ and PG_REFCURSOR oids. [Bug #845360] * Fixed the format string of ParseTuple in libPQbool_FromInt. This closes a bug that appeared on Linux/Alpha (#625121). Changes to pgversion.c: ----------------------- * Changed pgversion to recognize release canidate versions of PostgreSQL. Changes to PgSQL test cases: ---------------------------- * Updated test cases to allow for changes in PostgreSQL 7.3. * Don't check for the obsolete displaysize field in cursor.description. Also don't check the backend encoding. Multiple files -------------- The windows/ directory has been moved to a port/ directory. Now we *always* use our own version of various string versions instead of special casing for a dozen different Windows and Unix platforms. In order to get the C version of PgInt8Type, it is now required that the constants LLONG_MAX, LLONG_MIN, ULLONG_MAX and ULLONG_MIN are defined when including limits.h and that including Python.h defines HAVE_LONG_LONG. Otherwise, a Python class is used instead. From chris@psychofx.com Mon Dec 16 11:15:50 2002 From: chris@psychofx.com (Chris Miles) Date: Mon, 16 Dec 2002 11:15:50 +0000 Subject: EDDIE-Tool 0.31 Released Message-ID: EDDIE-Tool 0.31 has just been released. http://eddie-tool.net/ What is it ? The EDDIE-Tool is an intelligent UNIX monitoring tool written entirely in Python. It provides system, network and security monitoring features, with an extensive configuration facility for defining customized monitoring rules. What is new ? Major new features added are directive dependencies, programmable action call periods, and access to previously collected data within directive rules. Also many more smaller updates such as improved Linux memory and swap usage statistics, more file checks, and support for remote SMTP servers. Why is it interesting to Python users ? Besides system and network administrators, Python users may find EDDIE-Tool interesting as it is an example of a threaded, multi-platform software package, providing easy access to system statistics and using Python's power to offer a dynamic and programmable rules engine. Regards, Chris -- Chris Miles chris@psychofx.com http://www.psychofx.com/chris/ From drifty@bigfoot.com Tue Dec 17 07:13:22 2002 From: drifty@bigfoot.com (Brett C.) Date: 16 Dec 2002 23:13:22 -0800 Subject: python-dev Summary for 2002-12-01 through 2002-12-15 Message-ID: +++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2002-12-01 through 2002-12-15 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ between December 1, 2002 and December 15, 2002 (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@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 seventh summary written by Brett Cannon (and thus my seventh attempt to get into amk's `Python Quotations `__). All summaries are now 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, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is. If you want to do that, get an original copy of the text file. .. _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 ====================== Summary Announcements ====================== Aahz suggested that I try writing the summary from a third-person perspective so as to remove ambiguity if anyone ever quotes something from a summary which was written in first-person. I am giving it a go in this summary although there is not much here that is affected. I am also trying to use extended characters for people's names. Hopefully it will show up correctly when I send it out and in the HTML version of this. There was an error in the last summary where I gave Guido's position on something incorrectly (summary of dict evaluation order). It has been fixed. I am going to fix errors like that in old summaries with an errata note in the text version. It won't show up in the HTML version, though. And go to PyCon_. =) .. _PyCon: http://www.python.org/pycon/ =================================== `New universal import mechanism`__ =================================== __ http://mail.python.org/pipermail/python-dev/2002-December/030602.html Splinter threads: - `New and Improved Import Hooks `__ - `Re: New and Improved Import Hooks `__ - `Re[2]: [Python-Dev] New and Improved Import Hooks `__ - `New Import Hook & New Zip Importer `__ - `(no subject) `__ - `Another approach for the import mechanism `__ - `Re: Another approach for the import mechanism `__ - `New Import Hook & New Zip Importer `__ - `Import: where's the PEP? `__ - `zipimport & import hooks `__ - `VFS `__ - `Zip imports, PEP 273, and the .zip extension `__ - `Import compromise `__ - `zipimport, round 3 (or would that be 37?) `__ - `Complexity of import.c `__ - `zipimport, round 4 `__ - `new import hooks & zip import `__ In case you can't figure it out from the title of all of the splnter threads, there was an immense discussion about `PEP 273`_ and getting an import mechanism for zipped modules. To give a little back-story, PEP 273 proposes allowing modules to be put into a zip file for easy distribution. You could then just add the zip file to ```sys.path`_`` , PYTHONPATH_ , etc. and importing from the zip file would be handled properly. It was scheduled to be included in Python 2.3 thanks to Paul Moore keeping James Ahlstrom's patch synced with CVS. All was right with the world, more or less. But Just van Rossum didn't like the added complexity to import.c_. This led to Just to write a new import mechanism. Basically Just was unhappy with how much fiddling the PEP 273 patch was doing to import.c. So, just like any self-respecting programmer would do, he came up with his own solution. =) Most of the discussion revolved around a few central points. One was whether this was even worth the effort. Since the PEP 273 patch worked, why should Just bother reinventing the wheel? The whole reason Just decided to come up with another implementation was a major point. The other was that he felt he could come up with a more general way of allowing custom importers *and* have zip imports a part of the core. There was also a discussion of whether Gordon McMillan's `iu.py`_ wasn't a good solution; it was already well-tested and coded. Just decided to still write his. Just wanted to be able to put arbitrary objects in ``sys.path`` like iu.py. This would allow the object to be called to figure out whether it had the module being requested or not. Taking the zip importer as an example, there would be a zipimporter instance in ``sys.path`` for each zip file in the path (once it was discovered it was a zip file; bootstrapping has been carefully handled). The issue of backward-compatibility was instantly brought up. It has been assumed that everything in ``sys.path`` was a string and starting to include zipimporter objects would break that. The idea of making zipimporters (and any subsequent importers in the stdlib) subclasses of strings was brought up and basically accepted, although Guido viewed it as an ugly hack. But in the end, Just's version acts like iu.py. The basic algorithm for handling zip files is:: def find_module(name, path): if isbuiltin(name): return builtin_filedescr if isfrozen(name): return frozen_filedescr if path is None: path = sys.path for p in sys.path: # I think Just meant to say ``path`` here try: v = zipimporter(p) except ZipImportError: pass else: w = v.find_module(name) if w is not None: return w ...handle builtin file system import... It is easily generalized to work for any registered importers. There is also the idea of adding something called a "meta path" that iu.py has. It would allow one to override any import by catching it before trying ``sys.path``. This is part of what has allowed ``sys.path`` to have only strings even with zip file support. The meta path can be set up for a zip importer that overrides ``sys.path`` for a zip file. One other discussion was over this was going to need a PEP. Just has written up an explanation, but as to whether a PEP is required has not been decided. Just's implementation is now a patch at http://www.python.org/sf/652586 . .. _PEP 273: http://www.python.org/peps/pep-0273.html .. _sys.path: http://www.python.org/doc/current/lib/module-sys.html .. _PYTHONPATH: http://www.python.org/doc/current/tut/node8.html .. _import.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python/compile.c .. _iu.py: http://www.mcmillan-inc.com/iu.html =================== `Mac OSX issues`__ =================== __ http://mail.python.org/pipermail/python-dev/2002-December/030604.html Continuation of http://mail.python.org/pipermail/python-dev/2002-November/030525.html Guido got a hold of a OS X box and ran the test suite on it and found four tests that didn't pass. One was for ``locale`` (which Guido didn't care about), another was the ``test_largefile`` test, another was for ``re``, and the last one was for ``socket``. The ``test_largefile`` suite seeks on a new file to a huge position. On OS X and Windows 2000 this actually adds to the file up to the seek point so as to make it a complete file. Windows 9x, on the other hand, just writes to that offset regardless of whether it is within the bounds of the file. Because it creates such a huge file it takes forever to complete and thus has been made an optional test on OS X. The ``re`` tests were failing for a lack of space on the stack. to allow the tests to pass you need to execute the statement ``ulimit -s 2000`` which ups the stack size to approximately 2 Mb. This has sense been added to the regression testing framework to be done for you if needed. ``socket`` was failing on ``.getsockbyaddr()`` when trying it for the machine's own name. Barry Warsaw discovered that the test passed if you set hostnames by using NetInfo. ============================================================== `RE: how to kill process on Windows started with os.spawn?`__ ============================================================== __ http://mail.python.org/pipermail/python-dev/2002-December/030595.html Skip Montanaro wanted to be able to kill a Windows process externally. He suggested implemented a ``os.kill()`` function that would kill a process in a platform-independent way. Problem is that Windows wants the process hook which is different from what POSIX wants. Another issue is that the Windows docs say that you should not kill processes externally. It seems the idea has been dropped. ========================================================= `extension module .o files wind up in the wrong place`__ ========================================================= __ http://mail.python.org/pipermail/python-dev/2002-December/030644.html Skip Montanaro discovered that if you built Python in a subdirectory of the source directory (e.g., source in ``source/`` and you are building in ``source/build/``) the .o files are put in the wrong place (they use ``source/`` as the root directory to place things instead of ``source/build/``). Someone resolved this issue for themselves by doing a ``make distclean`` and then running ``../configure``. Skip is still trying to figure out of a bug report needs to be filed. ========================================= `Make universal newlines non-optional`__ ========================================= __ http://mail.python.org/pipermail/python-dev/2002-December/030692.html Martin v. Löwis asked if anyone mind not making universal newline support a compile option. He volunteered to remove the ``#ifdef`` statements and such to get this done. Jack Jansen (who wrote the universal newline code) pointed out that if it was required there could be issues on certain platforms. Martin had no issue with this since this would force the platform maintainers to fix the code for it to work. In the end Martin suggested leaving it an option in 2.3 and removing it as an option and requiring it in 2.4. ============================================ `Re: [Patches] Patch for xmlrpc encoding`__ ============================================ __ http://mail.python.org/pipermail/python-dev/2002-December/030984.html A discussion over a patch for ``xmlrpclib`` ended up on python-dev. The relevancy of it was that the statement ``sys.{get,set}defaultencoding`` is only useful for coercion of Unicode to byte strings. It was also stated that ASCII should always be assumed to be the default encoding. Also, never put any non-ASCII text in a string; that is what Unicode objects are for. ========================== `PEP 242 Numeric kinds`__ ========================== __ http://mail.python.org/pipermail/python-dev/2002-December/030859.html Paul DuBois emailed the list mentioning how a group of people were supposed to get together to decide the fate of `PEP 242`_ in June 2002; that didn't happen. So Paul suggested making the suggested "making it a separate deliverable on the Numeric_ site and withdrawing the PEP". Everyone who responded pretty much said to add the proposed module. A final outcome has not been decided as to whether Paul will rescind the PEP or push it forward. If you have an opinion on the matter, let it be known. .. _PEP 242: http://www.python.org/peps/pep-0242.html .. _Numeric: http://www.pfdubois.com/numpy/ ================== `We got leaks!`__ ================== __ http://mail.python.org/pipermail/python-dev/2002-December/030933.html Tim Peters discovered that the new datetime_ type was leaking memory. The C version was slowly leaking about 10 references per loop through the testing suite. But the Python version was leaking 37 reference per loop through. Tim did his reference checking using this chunk of code:: def test_main(): import gc r = unittest.TextTestRunner(stream=sys.stdout, verbosity=2) s = test_suite() while True: r.run(s) gc.collect() print gc.garbage # this is always an empty list print '*' * 10, 'total refs:', sys.gettotalrefcount() This substituted for the ``test_main()`` for the testing suite printed out the reference numbers rather nicely. Well, it didn't take the weekend to solve. Kevin Jacobs stepped up to help. The first thing he found was that it was not occurring in a debug build (which is why when you are testing new code you should **always** run it in a debug build). Then Kevin discovered the issue came up when executing a ``__hash__()`` call on anything. Tim then realized a missing decrement in ``slot_tp_hash()`` was the culprit. Then Kevin found another culprit in ``cPickle_``. That was also patched (and everything has been flagged to be backported to the 2.2 branch). The reason this thread is being mentioned is because it 1) was all solved in 5 hours and 40 minutes which is pretty cool and 2) using the chunk of code that Tim provided to stare at the reference count is a good way to look for memory leaks in your code. .. _datetime: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbox/datetime/ .. _cPickle: http://www.python.org/doc/current/lib/module-cPickle.html ========================= `os.path.commonprefix`__ ========================= __ http://mail.python.org/pipermail/python-dev/2002-December/030947.html Armin Rigo noticed how ``os.path.commonprefix()`` works character-by-character and not by path separators as one might expect (although the documentation does warn about its char-by-char nature). Skip Montanaro suggested ``os.path.commonpathprefix()`` be added. He mentioned that `Tools/scripts/trace.py`_ had such functionality. As of this writing no one has taken the initiative to add the function. .. _Tools/scripts/trace.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Tools/scripts/trace.py ======================================================== `__getstate__() not inherited when __slots__ present`__ ======================================================== __ http://mail.python.org/pipermail/python-dev/2002-December/030980.html Greg Ward noticed that "If a class and its superclass both define __slots__, it appears that __getstate__() is not inherited from the superclass." He wasn't sure if this was a bug or a feature. Well, it's a feature; since there is no guarantee that the superclass's ``__getstate__()`` will know about the subclass's ``__slots__``, it is not automatically inherited. Kevin Jacobs provided the following snippet of code to deal with this "feature":: def __getstate__(self): state = getattr(self, '__dict__', {}).copy() for obj in type(self).mro(): for name in getattr(obj,'__slots__',()): if hasattr(self, name): state[name] = getattr(self, name) return state def __setstate__(self, state): for key,value in state.items(): setattr(self, key, value) ==================== `Tarfile support`__ ==================== __ http://mail.python.org/pipermail/python-dev/2002-December/031086.html Gustavo Niemeyer asked for some help in reviewing the patch ( http://www.python.org/sf/651082 ) that adds Lars Gustabel's tarfile module to the stdlib. The question of the license came up. Lars said he would be willing to change the license over to the `Python Software Foundation`_ . An initial license hand-off agreement is available at http://www.python.org/psf/psf-contributor-agreement.html . .. _Python Software Foundation: http://www.python.org/psf/ ============================== `Tcl, Tkinter, and threads`__ ============================== __ http://mail.python.org/pipermail/python-dev/2002-December/031107.html Martin v. Löwis has now modified ```_tkinter`_`` as so to be able to be used when Tcl has been compiled with thread support. Special thanks goes out to Martin for taking over maintenance of the module. .. __tkinter: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modules/_tkinter.c ============ `PEP 298`__ ============ __ http://mail.python.org/pipermail/python-dev/2002-December/031109.html Splinter threads: - `PEP-298: buffer interface widening too much? `__ - `PEP-298: buffer interface widening too much? `__ Thomas Heller wanted to resolve whether to move forward with an implementation for `PEP 298`_ . This led to a discussion over the specifics of the PEP. Martin v. Löwis wnated some more specific wording from the PEP. Todd Miller then stepped in to say he didn't like how much of an interface was being tacked on. Martin commented that his `PEP 286`_ would help in this whole situation, which Todd ended up agreeing with. .. _PEP 298: http://www.python.org/peps/pep-0298.html .. _PEP 286: http://www.python.org/peps/pep-0286.html From fmc@inf.ufg.br Tue Dec 17 11:49:14 2002 From: fmc@inf.ufg.br (Fabio M. Costa) Date: Tue, 17 Dec 2002 09:49:14 -0200 Subject: Middleware2003: 5 days for deadline - Call for Papers Message-ID: ACM/IFIP/USENIX INTERNATIONAL MIDDLEWARE CONFERENCE http://middleware2003.inf.puc-rio.br http://gsd.ime.usp.br/middleware2003 Rio de Janeiro, Brazil, 16-20 June 2003 CALL FOR PAPERS SUBMISSION DEADLINES ==================== Full Papers: 22 December 2002 Work in Progress Papers, Workshop Papers, and Posters : 20 February 2003 Tutorial Proposals: 01 February 2003 THE CONFERENCE ============== Following the success of past conferences in this series (Lake District/UK, Palisades/NY, and Heidelberg/Germany) and building upon the success of past COOTS conferences, the 4th International Middleware Conference will be the premier event for middleware research and technology in 2003. The scope of the conference is the design, implementation, deployment, and evaluation of distributed system platforms and architectures for future computing and communication environments. Highlights of the conference include a high-quality technical program, tutorials, invited speakers, poster presentations, and workshops, all held in one of Brazil's most outstanding areas of natural beauty. The proceedings of Middleware'2003 will be published as a volume of the Lecture Notes in Computer Science. Conference topics include, but are not limited to: * Distributed real-time and embedded (DRE) middleware platforms * Reliable and fault-tolerant middleware platforms * Support for multimedia in middleware platforms * Novel quality of service (QoS) architectures and evaluation techniques * Event-based, publish/subscribe and asynchronous middleware platforms * Open architectures for reconfigurable middleware * Adaptive and reflective middleware * Middleware protocols and services for information assurance and security * Formal Methods applied to middleware * Management and use of component-based systems in distributed environments * Applications of middleware technologies, including telematics and e-commerce * Novel paradigms, APIs, and languages for distributed systems * Integration of middleware with model-integrated computing architectures, such as OMG MDA * Extensions and refinements to RM-ODP, CORBA, J2EE, .NET, etc. * Impact of emerging Internet technologies and standards on middleware platforms * Integration of middleware platforms with Web services and Java technologies * Distributed systems management and interactive configuration and development tools * Issues of scalability in existing and new distributed systems platforms * Engineering distributed systems in heterogeneous and mobile networks * Middleware for ubiquitous and mobile computing 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) PROGRAM COMMITTEE ================= Gul Agha (UIUC, USA) Jean Bacon (Cambridge U., UK) Gordon Blair (U. of Lancaster, UK) Don Box (Microsoft, USA) Roy Campbell (UIUC, USA) Andrew Campbell (Columbia U., USA) Geoff Coulson (Lancaster U., UK) Naranker Dulay (Imperial College, UK) Svend Frolund (HP Labs, USA) Chris Gill (WUSL, USA) Andy Gokhale (Vanderbilt U., USA) Rashid Guerraoui (EPF L., Switzerland) Arno Jacobsen (U. of Toronto, Canada) Peter Honeyman (CITI U. Michigan, USA) Fabio Kon (U. of Sao Paulo, Brazil) Doug Lea (SUNY Oswego, USA) Guy LeDuc (U. of Liege, Belgium) Orlando Loques (UFF, Brazil) Joe Loyall (BBN Technologies, USA) Raimundo J.A. Macedo (UFBA, Brazil) Edmundo R. Madeira (UNICAMP, Brazil) Jan de Meer (condat AG, Germany) Klara Nahrstedt (UIUC, USA) Priya Narasimhan (Carnegie Mellon U., USA) Carlos Pereira (UFRGS, Brazil) Vijay Raghavan (DARPA, USA) Kerry Raymond (DSTC, Australia) Luis Rodrigues (U. of Lisboa, Portugal) Isabelle Rouvellou (IBM, USA) Bill Sanders (UIUC, USA) Rick Schantz (BBN Technologies, USA) Alexander Schill (Technical U. Dresden, Germany) David Sharp (The Boeing Company, USA) Jacob Slonim (Dalhousie U., Canada) Jean-Bernard Stefani (INRIA, Grenoble, France) Joe Sventek (Agilent Labs, UK) Janos Sztipanovits (Vanderbilt U., USA) Nalini Venkatasubramanian (UC Irvine, USA) Steve Vinoski (IONA Technologies, Ireland) Werner Vogels (Cornell U., USA) Martina Zitterbart (U. of Karlsruhe, Germany) 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@cs.wustl.edu) or Markus Endler (endler@inf.puc-rio.br). For other questions contact the local arrangements chairs, Alexandre Sztajnberg (alexszt@uerj.br) or Renato Cerqueira (rcerq@inf.puc-rio.br). From chrisw@nipltd.com Tue Dec 17 19:59:32 2002 From: chrisw@nipltd.com (Chris Withers) Date: Tue, 17 Dec 2002 19:59:32 +0000 Subject: Strip-o-Gram 1.3 Released! Message-ID: Strip-o-Gram is an HTML Conversion Library that can convert HTML to Plain Text and strip specified tags and Javascript from HTML. See http://www.zope.org/Members/chrisw/StripOGram for more details. This release includes several bug fixes and some new features and will allow the methods to be used from Zope's Script (Python)'s once http://collector.zope.org/Zope/685 has been resolved. cheers, Chris From sholden@holdenweb.com Wed Dec 18 03:04:58 2002 From: sholden@holdenweb.com (Steve Holden) Date: Tue, 17 Dec 2002 22:04:58 -0500 Subject: PyCon DC 2003: Extension of submission deadline Message-ID: [This announcement is being repeated through the mailing lists] [as the newsgroup posting has apparently not fully propagated] The deadline for submissions to PyCon DC 2003 appears to have been too tight for many authors. While some promised submissions have arrived, several have not even though the original deadline of 15 December has passed. Rather than exclude promising papers the organizing committee has decided to extend the deadline for submissions. Accordingly, the new schedule for proposals is as follows: Submission Deadline: January 15, 2003 Notification of Acceptance: January 31, 2003 Final Versions Due: March 10, 2003 Conference Dates: March 26-28, 2003 [unchanged] Authors who have already submitted abstracts are invited to resubmit if they feel that the original deadline had an adverse effect on the quality of their submissions. Please make any appropriate media, mailing lists and newsgroups aware of this announcement. Enquiries should be sent in the first instance to pycondc-2003@python.org. Information about PyCon DC 2003 is available at the following URLs: www.python.org/pycon www.python.org/cgi-bin/moinmoin/PyCon The latter URL, a Wiki page, can also be used to communicate with the conference organizers. This is *your* conference: tell us what *you* want to see in it [note added on repost: -- or the parrot gets it. SH]. regards ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Bring your musical instrument to PyCon! http://www.python.org/pycon/ ----------------------------------------------------------------------- From fdui@openlight.com Tue Dec 17 21:59:52 2002 From: fdui@openlight.com (fdui@openlight.com) Date: Tue, 17 Dec 2002 16:59:52 -0500 Subject: Flightdeck-UI Multi-Variable Monitor App. V. 0.1.1 released Message-ID: *** 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. The Multi-Variable Monitor (MVM) is a highly configurable Flightdeck-UI application, which includes a graphical editor and theme support. Little (or even none at all) coding is required to use MVM, although everyone is welcome to code as much as they like. Check out the MVM screenshots at "http://www.openlight.com/fdui/screens.html". This update to the MVM has an Edit mode that is much easier to use on 800x600 screens. This is done by providing extra controls that trigger the hiding of some elements from view, thus reducing the height of the editor window. Another change is better scaling for the 'About' dialog box. Because users can add their own names, descriptions, etc. to any control file or theme that they write, the dialog box needs to scale in order to fit these variable contents. The project homepage is at "http://www.openlight.com/fdui/". Both the Flightdeck-UI library and the MVM application are open source/free software. They are written in Python and require Tkinter. Questions can be emailed to originating address of this message (fdui@openlight.com). From sholden@holdenweb.com Wed Dec 18 04:06:10 2002 From: sholden@holdenweb.com (Steve Holden) Date: Tue, 17 Dec 2002 23:06:10 -0500 Subject: Seeking Expressions of Support Message-ID: This is my last word on this subject until after Christmas. It's also about as close as I'll ever get to spamming -- apologies to those of you who receive multiple copies of this mail. Please send it on to any individual or list with an interest in Python and related topics. For PyCon DC 2003 to be a success it needs people to get involved. Then Python will finally have low-cost conferences. So take a look at the following link, then don't mail me -- visit the Python Wiki PyCon page and express your support (or not, as the case may be): http://pydish.holdenweb.com/pycon/threat.html Happy holidays ----------------------------------------------------------------------- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Bring your musical instrument to PyCon! http://www.python.org/pycon/ ----------------------------------------------------------------------- From bdeck@lycos.co.uk Wed Dec 18 19:50:15 2002 From: bdeck@lycos.co.uk (deckerben) Date: Wed, 18 Dec 2002 20:50:15 +0100 Subject: ANNOUNCE: Python 2.2.1 Release 1.0 for DOS Message-ID: Greetings, On December 16, 2002 a release-level quality port of Python 2.2.1 to 32-bit DPMI DOS environment was uploaded to http://members.lycos.co.uk/bdeck. This project is called PythonD. Upgraded features from the beta release include: - os.name remains 'posix', as DJGPP is basically a posix-oriented implementation. - os.path is now 'posixpath' - although a few lines from 'dospath' have still been merged with it (like 'splitdrive') to accommodate DJGPP's "posix-dos" style. - Compiled 'pyc' files now read more reliably. - Dynamic linking is now working using either DXE2 or DXE3. - First special PythonD release of distultils library modified for DJGPP (alpha). Dynamic modules now build on PythonD. Requires DJGPP. - 'socketmodule' works more smoothly (requires DOS packet driver). - 'gdbm' module doesn't crash with file I/O anymore. - PyXML now passes all standard tests with 100% success. Its C libraries now link dynamically. - Re-inclusion of modules 'select' and 'termios' (they were removed in the beta). - Optional 'curses' module based on new ncurses 5.3(now linked dynamically). There are still some problems like 'beep'. - 'spawnv', 'spawnve', and 'execv' have been implemented. - sys.path automatically checks for Python Libraries using %DJGPP% and '/dev/env/DJDIR'. %PYTHONPATH% is no longer needed if all files are left in default location under DJGPP. - Source code tree available for first time - WARNING - many additional libraries needed. - Other small fixes. PythonD passes over 140 tests successfuly, with a major failure in popen2 (No forking under DOS). Previous users of the PythonD beta are strongly encouraged to upgrade. Bug reports and user questions are being accepted for this release version only now. Please see website http://members.lycos.co.uk/bdeck for details and download. If you cannot get through, try again later. For information on DJGPP see www.delorie.com/djgpp. Ben From alberanid@libero.it Thu Dec 19 07:26:54 2002 From: alberanid@libero.it (Davide Alberani) Date: Thu, 19 Dec 2002 07:26:54 GMT Subject: DAXFi 1.0 Message-ID: DAXFi 1.0 is available here: http://daxfi.sourceforge.net/ DAXFi is a Python package that helps configure several different kinds of firewalls in a consistent way. The rules can be described with XML files, XML strings, or generated directly by the code. It comes with a Python package, useful to build other applications aimed to manipulate different firewalls in a homogeneous way and includes some useful example programs. DAXFi is release under the GPL license. In this release: User defined chains and chain policies were introduced. The pyXML package is no longer required, and the SAX API is used instead of DOM, with noticeable performance improvement. Now two rules can be merged using the XOR operator. The daxfidump script can write the output to a single file. Many bugs were fixed. -- Davide Alberani email: Personal home page: http://digilander.iol.it/alberanid/ From edream@tds.net Thu Dec 19 14:24:17 2002 From: edream@tds.net (Edward K. Ream) Date: Thu, 19 Dec 2002 14:24:17 GMT Subject: Leo 3.10 outlining editor References: Message-ID: A missing word destroyed the meaning of a sentence: old: - Added an easy way to replace any Leo method by a function. The code in customizeLeo.py can now override part of Leo's code! correct: - Added an easy way to replace any Leo method by a function. The code in customizeLeo.py can now override _any_ part of Leo's code! Edward P.S. Many people will recognize that this "easy way" is a two-line function taken from the always useful Python Cookbook. EKR -------------------------------------------------------------------- Edward K. Ream email: edream@tds.net Leo: Literate Editor with Outlines Leo: http://personalpages.tds.net/~edream/front.html -------------------------------------------------------------------- From thanos@0x01.com Thu Dec 19 19:14:50 2002 From: thanos@0x01.com (thanos vassilakis) Date: 19 Dec 2002 11:14:50 -0800 Subject: Subject: [Web Site] How-To: Easy CGI Session Handling with pso.session Message-ID: How-To: Easy CGI Session Handling with pso.session -------------------------------------------------- How to painlessly adding session handling to a cgi script This document shows you how to use pso.session to add easy session handling to a CGI script. Python Service Objects is a open source internet service development system. The pso system allows you to develop platform and server independent CGI scripts that can later be promoted to NSAPI or modpython request handlers, often without any changes. *** ADDITIONAL NOTES WILL GO HERE, IF ANY *** URL: http://www.scriptfoundry.com/modules/pso/doc/session-cgi.html Categories: Tutorials, Internet thanos vassilakis (thanos@scriptfoundry.com) http://www.scriptfoundry.com/~thanos/ -- How-To: Easy CGI Session Handling with pso.session -- How to painlessly adding session handling to a cgi script From tundra@tundraware.com Thu Dec 19 23:50:09 2002 From: tundra@tundraware.com (Tim Daneliuk) Date: 19 Dec 2002 23:50:09 GMT Subject: ANN: 'twander' 2.29 Released Message-ID: 'twander' 2.29 is released and available at: http://www.tundraware.com/Software/twander/ What Is "twander"? ------------------ "twander" is a Filesystem Browser which runs on both Unix-like systems as well as Win32 systems. It embraces the best ideas of both similar GUI-driven programs (Konqueror, Windows Explorer) as well as text-based interfaces (Midnight Commander, List, Sweep). Why Is "twander" Different? --------------------------- While the "twander" interface is graphical, all the major navigation, selection, and execution commands can be entered from the keyboard, not just the mouse. This means Power Users who are strong typists can minimize dependency on the mouse and materially speed up their interactions with the system. Moreover, unlike the other programs, "twander" does not have a built-in set of commands (which typically cannot be changed). Instead, "twander" supports a rich macro configuration language for virtually limitless user-definition of commands. The configuration language provides a simple mechanism for communicating the list of items currently selected in the GUI to the user-defined commands. Each user is thus free to configure a command set unique and appropriate to their needs. As with the navigation commands, user-defined commands can be invoked with either the keyboard (a single keystroke) or the mouse (a menu selection). Who Might Like "twander"? ------------------------ 1) People who type well and find the mouse a distraction when working. 2) People who want to customize the commands available in their file browser to do things *their* way instead of the way the browser wants to do things. 3) People who wish to provide their less technical colleagues with a tool that has a limited set of "canned" features. For instance, it would be trivial to use "twander" to automate ftp transfers for use by non-technical administrative staff. 4) People interested in the inner workings of a Python/Tkinter program. The entire program is written in Python using the Tkinter GUI modules and is extensively commented throughout. Additional program documentation is provided in Unix 'man' format, PostScript, html, and plain text. 5) Oddly, and as an unintended side-effect of the original design, "twander" will serve the visually-impaired very well. Colors, font type, size, & weight, and window size can all be trivially set on the "twander" command line. So, for instance, it is quite easy to run the program with very large fonts, thus improving readability. Program Requirements -------------------- "twander" runs on Unix-like systems (FreeBSD, Linux) as well as a variety of Win32 systems. It requires the presence of Python 2.2 (or later) and the associated Tkinter support for the target system. These are freely available from: http://www.python.org -- ------------------------------------------------------------------------------ Tim Daneliuk tundra@tundraware.com -- ------------------------------------------------------------------------------ Tim Daneliuk tundra@tundraware.com From just@letterror.com Fri Dec 20 15:14:57 2002 From: just@letterror.com (Just van Rossum) Date: Fri, 20 Dec 2002 16:14:57 +0100 Subject: ANN: PEP 302, New Import Hooks Message-ID: Folks, There's a new PEP (Python Enhancement Proposal) up for review at: http://www.python.org/peps/pep-0302.html It proposes a mechanism for hooking custom import logic into the existing builtin import mechanism. An implementation is available as a patch on sourceforge: http://www.python.org/sf/652586 Since this is proposed as an addition to Python 2.3, there isn't much time left to iron out any wrinkles, so please give this a thorough review. It would be greatly appreciated if any discussion on comp.lang.python would be Cc-ed to me and Paul Moore, since I'm not so sure how much time we can spend monitoring that group. This is not needed for followups to python-dev; both of us do monitor that list rather closely. Just From LogiplexSoftware@earthlink.net Fri Dec 20 17:54:58 2002 From: LogiplexSoftware@earthlink.net (Cliff Wells) Date: 20 Dec 2002 09:54:58 -0800 Subject: Python DSV 1.3.9 Message-ID: DSV 1.3.9 is available for download: http://python-dsv.sf.net This is a bugfix release with no new features (other than correct operation ;) What is it? Python-DSV is a Python module for importing and exporting DSV (delimiter separated values) files. DSV is a generalization of CSV (comma separated values). CSV is a common file format used by many programs to import and export data. Features: - Pure Python - Optional wxPython GUI - Optional heuristics for determining file format - Handles embedded quotes, delimiters and newlines - Customizable error handling - Simple to use - Portable (tested on Linux and Windows) Requirements: - Python 2.0 or greater Optional: - wxPython 2.3 or greater (if you use the GUI) -- Cliff Wells, Software Engineer Logiplex Corporation (www.logiplex.net) (503) 978-6726 x308 (800) 735-0555 x308 From fmc@inf.ufg.br Fri Dec 20 19:11:27 2002 From: fmc@inf.ufg.br (Fabio M. Costa) Date: Fri, 20 Dec 2002 17:11:27 -0200 Subject: Middleware2003: Exteded Deadline: 30th December Message-ID: (Due to a number of requests, the deadline for the submission of Full Pap= ers has been extended. Please note there won=B4t be any further extensions.) ACM/IFIP/USENIX INTERNATIONAL MIDDLEWARE CONFERENCE http://middleware2003.inf.puc-rio.br http://gsd.ime.usp.br/middleware2003 Rio Othon Palace Hotel Rio de Janeiro, Brazil, 16-20 June 2003 CALL FOR PAPERS SUBMISSION DEADLINES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Full Papers (Extended Deadline!): 30 December 2002 Work in Progress Papers, Workshop Papers, and Posters : 20 February 2003 Tutorial Proposals: 01 February 2003 THE CONFERENCE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Following the success of past conferences in this series (Lake District/U= K, Palisades/NY, and Heidelberg/Germany) and building upon the success of pa= st COOTS conferences, the 4th International Middleware Conference will be th= e premier event for middleware research and technology in 2003. The scope o= f the conference is the design, implementation, deployment, and evaluation of distributed system platforms and architectures for future computing an= d communication environments. Highlights of the conference include a high-quality technical program, tutorials, invited speakers, poster presentations, and workshops, all held in one of Brazil's most outstandin= g areas of natural beauty. The proceedings of Middleware'2003 will be published as a volume of the Lecture Notes in Computer Science. Conference topics include, but are not limited to: * Distributed real-time and embedded (DRE) middleware platforms * Reliable and fault-tolerant middleware platforms * Support for multimedia in middleware platforms * Novel quality of service (QoS) architectures and evaluation techniques * Event-based, publish/subscribe and asynchronous middleware platforms * Open architectures for reconfigurable middleware * Adaptive and reflective middleware * Middleware protocols and services for information assurance and securit= y * Formal Methods applied to middleware * Management and use of component-based systems in distributed environmen= ts * Applications of middleware technologies, including telematics and=20 e-commerce * Novel paradigms, APIs, and languages for distributed systems * Integration of middleware with model-integrated computing=20 architectures, such as OMG MDA * Extensions and refinements to RM-ODP, CORBA, J2EE, .NET, etc. * Impact of emerging Internet technologies and standards on middleware=20 platforms * Integration of middleware platforms with Web services and Java=20 technologies * Distributed systems management and interactive configuration and=20 development tools * Issues of scalability in existing and new distributed systems platforms * Engineering distributed systems in heterogeneous and mobile networks * Middleware for ubiquitous and mobile computing ORGANIZATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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) PROGRAM COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Gul Agha (UIUC, USA) Jean Bacon (Cambridge U., UK) Gordon Blair (U. of Lancaster, UK) Don Box (Microsoft, USA) Roy Campbell (UIUC, USA) Andrew Campbell (Columbia U., USA) Geoff Coulson (Lancaster U., UK) Naranker Dulay (Imperial College, UK) Svend Frolund (HP Labs, USA) Chris Gill (WUSL, USA) Andy Gokhale (Vanderbilt U., USA) Rashid Guerraoui (EPF L., Switzerland) Arno Jacobsen (U. of Toronto, Canada) Peter Honeyman (CITI U. Michigan, USA) Fabio Kon (U. of Sao Paulo, Brazil) Doug Lea (SUNY Oswego, USA) Guy LeDuc (U. of Liege, Belgium) Orlando Loques (UFF, Brazil) Joe Loyall (BBN Technologies, USA) Raimundo J.A. Macedo (UFBA, Brazil) Edmundo R. Madeira (UNICAMP, Brazil) Jan de Meer (condat AG, Germany) Klara Nahrstedt (UIUC, USA) Priya Narasimhan (Carnegie Mellon U., USA) Carlos Pereira (UFRGS, Brazil) Vijay Raghavan (DARPA, USA) Kerry Raymond (DSTC, Australia) Luis Rodrigues (U. of Lisboa, Portugal) Isabelle Rouvellou (IBM, USA) Bill Sanders (UIUC, USA) Rick Schantz (BBN Technologies, USA) Alexander Schill (Technical U. Dresden, Germany) David Sharp (The Boeing Company, USA) Jacob Slonim (Dalhousie U., Canada) Jean-Bernard Stefani (INRIA, Grenoble, France) Joe Sventek (Agilent Labs, UK) Janos Sztipanovits (Vanderbilt U., USA) Nalini Venkatasubramanian (UC Irvine, USA) Steve Vinoski (IONA Technologies, USA) Werner Vogels (Cornell U., USA) Martina Zitterbart (U. of Karlsruhe, Germany) FOR MORE INFORMATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For further information, please visit the conference home page: http://middleware2003.inf.puc-rio.br or=20 http://gsd.ime.usp.br/middleware2003. For questions regarding the conference program, contact the PC chairs, Douglas Schmidt (schmidt@cs.wustl.edu) or Markus Endler=20 (endler@inf.puc-rio.br). For other questions contact the local arrangements chairs, Alexandre Sztajnberg (alexszt@uerj.br) or Renato Cerqueira (rcerq@inf.puc-rio.br). From fred@observe.co.za Mon Dec 23 07:44:52 2002 From: fred@observe.co.za (Fred Strauss) Date: Mon, 23 Dec 2002 09:44:52 +0200 Subject: PyBluetooth 0.1.0 Message-ID: PyBluetooth 0.1.0 -=-=-=-=-=-=-=-=- This is to announce the 1st release of a python bluetooth module. It requires The BlueZ Linux Bluetooth stack to work, and is just a wrapper for libbluetooth1. At the moment very few of the functions are wrapped, you can scan for bluetooth devices and get their bdaddresses and from that their names. An example python program is included that does exactly that. The rest of the functions will come soon though. Have a look at http://www.strider.co.za/projects/pybluetooth/ Comments welcome. Testers on different platforms very welcome. Thanks Fred -- Fred Strauss Team Leader Observe (a division of Obsidian Systems) http://www.observe.co.za fred@observe.co.za From thanos@0x01.com Mon Dec 23 13:27:21 2002 From: thanos@0x01.com (thanos vassilakis) Date: 23 Dec 2002 05:27:21 -0800 Subject: ANN: How to building a internet portal in 1 hour using python and pso Message-ID: Just added to the Vaults of Parnassus [http://py.vaults.ca/] A Build your own portal in 1 hour ! ------------------------------------ How to building a internet portal in 1 hour using python and pso We would like to show how one would build a web service using pso. As an example we will build a small portal. It should take less than an hour. The sites requirements will be: Have some pages available to the public and some only for members. * Offer simple member registration system. * Members will be able to upload a jpeg of themselves. * Once logged in members will be able to return within the same day without logging in again. * Members will be able to view listings of information. Although this site does nothing in particular it will illustrate the following: * Template Nesting * Session Handling * Redirection * Handling security and logging in. * Simple Form Handling without confirmation stage * Complex Forms with confirmation stage * File uploading Categories: Tutorials, Internet . Web thanos vassilakis (thanos@scriptfoundry.com) http://www.scriptfoundry.com/~thanos/ -- A Build your own portal in 1 hour ! -- How to building a internet portal in 1 hour using python and pso From bbum@codefab.com Mon Dec 23 16:58:49 2002 From: bbum@codefab.com (Bill Bumgarner) Date: Mon, 23 Dec 2002 11:58:49 -0500 Subject: ANN: PyObjC 0.8 Message-ID: PyObjC version 0.8 is now available for download. See... http://pyobjc.sourceforge.net/ ... for more information. The installer package includes a Project Builder project template for easily creating new Cocoa-Python projects and a slew of examples. Alternatively, the developer can choose to develop applications without using Apple's developer tools. Full support for Interface Builder documents is included. The PyObjC Python module provides a feature complete bridge between the Python programming language and Objective-C. With PyObjC, it is possible to transparently message Objective-C objects from Python and Python objects from Objective-C. Objective-C objects can be subclassed from within Python. Support is also included for using the various functions, enumerated types, and global variables found throughout the Objective-C framework. References to python dictionaries pass into Objective-C act like a well behaved member of the NSDictionary class cluster. Likewise, Python List references behave like a member of the NSArray class cluster. Strings are transparently converted to the native type. NSArray and NSDictionary references passed into Python behave like native Python lists and dictionaries; including the ability to enumerate either using the 'in' operator and to slice NSArray and NSMutableArray instances. PyObjC fully supports creating full featured Cocoa applications written in pure Python. There are aspects of PyObjC that are more powerful than Cocoa in pure Obj-C (the ability to automatically define classes/outlets based on the contents of a NIB file, for example). PyObjC requires OS X 10.2 or greater. 10.1 support is possible and will likely happen soon-- contact me if you need 10.1 support and are willing to do a bit of grunt work to generate the appropriate files (easy to do-- just need a 10.1 development machine). The installer package is designed to work with the built-in Python provided in OS X 10.2. Source is included on the disk image and the pyobjc module works with Python 2.2 or greater as installed directly from the Python Source, with the MacPython packages, and with the Fink build of python. PyObjC also provides an awesome environment for exploring frameworks. The following transcript was copied out of a Terminal window-- it is an example of working directly with the Objective-C runtime from Python within the terminal. >>> from objc import * >>> from Foundation import * >>> b = NSBundle.bundleWithPath_("/System/Library/PrivateFrameworks/ PBXCore.framework") >>> b.principalClass() >>> NSBundle.searchPathsForSupportFilesWithSubpath_("FooBar") ( "/Volumes/Data/Users/bbum/Developer/ProjectBuilder Extras/FooBar", "/Network/Developer/ProjectBuilder Extras/FooBar", "/Developer/ProjectBuilder Extras/FooBar" ) >>> PBXProject = lookUpClass("PBXProject") >>> p = PBXProject.projectWithFile_("/Developer/Examples/AppKit/TextEdit/ TextEdit.pbproj") >>> p.targets() () >>> p.buildStyles() ( , ) The version # of 0.8 indicates that documentation is lacking, unit tests are incomplete and there may be a bug or two lurking within. In practice, the module has proven to be very stable and to allow for the development of extremely complex Cocoa projects in pure Python or a mix of Python and Objective-C. From max@alcyone.com Tue Dec 24 00:25:20 2002 From: max@alcyone.com (Erik Max Francis) Date: Mon, 23 Dec 2002 16:25:20 -0800 Subject: ANN: EmPy mailing lists available Message-ID: EmPy is a templating system for Python. http://www.alcyone.com/pyos/empy/ There are now two mailing lists available for people who wish to keep abreast of EmPy announcements or access other EmPy users: Mailing lists There are two EmPy related mailing lists available. The first is a receive-only, very low volume list for important announcements (including releases). To subscribe, send an email to mailto:empy-announce-list-subscribe@alcyone.com. The second is a general discussion list for topics related to EmPy, and is open for everyone to contribute; announcements related to EmPy will also be made on this list. The author of EmPy (and any future developers) will also be on the list, so it can be used not only to discuss EmPy features with other users, but also to ask questions of the author(s). To subscribe, send an email to mailto:empy-list-subscribe@alcyone.com. -- Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE / \ I used to walk around / Like nothing could happen to me \__/ TLC EmPy / http://www.alcyone.com/pyos/empy/ A templating system for Python. From neal@metaslash.com Tue Dec 24 01:36:30 2002 From: neal@metaslash.com (Neal Norwitz) Date: Mon, 23 Dec 2002 20:36:30 -0500 Subject: ANN: PyChecker v0.8.12 Message-ID: A new version of PyChecker is available just in time for Christmas. There's to be no complaining about the gifts it brings. :-) PyChecker is a tool for finding bugs in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. It is similar to lint. Comments, criticisms, new ideas, and other feedback is welcome. It's been a while since the last release, over 6 months--a record for PyChecker. :-) So there may be problems with the release. You've been warned. This is primarily a bug fix release. While there are a few new features, the biggest change is that PyChecker can be run on Zope by using the __import__ hook. The __import__ hook was added earlier, but had many bugs which made it fairly useless. It should be a little less useless now, YMMV, of course. Changes from 0.8.11 to 0.8.12: * Add --isliteral option to warn when using is/is not against literal (e.g., XXX is 5 YYY is not 'abcdef', etc) * Add --modulo1 option to warn when using (expr % 1), which is constant when expr is an integer or string * Add -4/--noeffect option to disable warnings for 'Statement has no effect' * self is not first argument warning can be disabled with -S/--self '' * Don't print duplicate warnings when importing pychecker * Fix other spurious warnings when importing pychecker * Fix bug for spurious invalid arguments when passing a dict inline * Fix bug for spurious Statement has no effect when print >> x, ... , * Add @option_file command line argument to read options from a file (used on platforms which can't have too many options, ie Windows) * Fix several crashes * Line numbers should be close for Python 2.3 and if run on optimized code PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Mailing List: pychecker-list@lists.sourceforge.net Neal -- pychecker-list@lists.sourceforge.net From lkcl@samba-tng.org Tue Dec 24 23:58:09 2002 From: lkcl@samba-tng.org (Luke Kenneth Casson Leighton) Date: Wed, 25 Dec 2002 00:58:09 +0100 Subject: custom 0.0 release Message-ID: Custom is a Stock / Ordering / Accounts / Sales system for medium-sized businesses. Written fully in python. Running from SQL (with MySQL supported with an example sql script, and MS-SQL via XML supported unofficially) Runs as cgi-scripts from apache, with example apache 2 config and startup scripts provided. It is difficult, with the number of sites out there for e-commerce systems, to justify writing another one, however the following may help explain: - At the time of writing, the author couldn't find any python-based e-commerce systems. - The aim of the site is to help businesses with stock and supplier management, as a tool to help get the best deals from their suppliers and to be able to pass those on to their customers. - The example cgi-scripts do not output or require any java or java script: all content is dynamically generated, with state information stored on a per-customer basis in the SQL database. Download: - http://sourceforge.net/projects/custom Known Bugs: - no documentation yet. - simultaneous user logins from different browsers overwrites the single session cookie, and only the last logged in user with the same username can access the site. From gerson.kurz@t-online.de Wed Dec 25 09:29:41 2002 From: gerson.kurz@t-online.de (Gerson Kurz) Date: Wed, 25 Dec 2002 09:29:41 GMT Subject: ANN: pyrcconv - converts Win32 .rc files to wxPython sourcecode Message-ID: In my current release frenzy I finished pyrcconv. It converts Win32 rc files to usable wxPython source. Great if you want to port dialogs from an existing application. http://p-nand-q.com/e/pyrcconv.html From max@alcyone.com Wed Dec 25 21:38:53 2002 From: max@alcyone.com (Erik Max Francis) Date: Wed, 25 Dec 2002 13:38:53 -0800 Subject: ANN: CSBuddy 1.2.2 -- Counter-Strike server log file monitor and administration tool Message-ID: I normally wouldn't announce a dot release, but the latest version include an fix for the end-of-the-year problem (CS logs don't include the year): Summary A Counter-Strike server log file monitor and administration tool. Overview CSBuddy is a tool designed to help Counter-Strike server owners, particularly those running AdminMod. It does two things: First, it maintains a queryable database of all players that have been seen on the server; and second, it filters the raw logs of a Counter-Strike server and distills them into a single CSBuddy log which shows only high-level activity such as excessive friendly fire incidents, admin activity, and players complaining about misbehavior or saying suspicious things. This tool is built upon an included Counter-Strike log file parser which is provided in a simple derivable class. Getting the software The current version of csbuddy is 1.2.2. The latest version of the software is available in a tarball here: http://www.alcyone.com/pyos/csbuddy/csbuddy-latest.tar.gz. The official URL for this Web site is http://www.alcyone.com/pyos/csbuddy/. Requirements CSBuddy requires Python version 2.0 or greater. License This code is released under the GPL. ... Release history [since 1.2] - 1.2.2; 2002 Dec 19. Fix bug in regular expression for parsing rcon and bad rcon messages. - 1.2.1; 2002 Dec 17. A fix for the end-of-year rollover bug. A mix of logfiles stradding the year boundary will now be handled properly, provided some gap in the months between exists. -- Erik Max Francis / max@alcyone.com / http://www.alcyone.com/max/ __ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE / \ My land's only borders lie / Around my heart \__/ The Russian, _Chess_ Sade Deluxe / http://www.sadedeluxe.com/ The ultimate Sade encyclopedia. From ahaas@airmail.net Sat Dec 21 17:54:19 2002 From: ahaas@airmail.net (Art Haas) Date: Sat, 21 Dec 2002 11:54:19 -0600 Subject: [ANNOUNCE] PythonCAD - A Python-based CAD program Message-ID: I'd like to announce the first release of a new open-source CAD package for Linux - PythonCAD. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program for open-source software users. PythonCAD is being 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 initial release is capable of basic drawing functionality, simple horizontal and vertical dimensioning, and file saving and reloading. There are some simple editing abilities as well. As this is the first release, there are many things that PythonCAD can't do, and things that it doesn't do well. These shortcomings will be addressed in future releases. I've set up a web site for PythonCAD. The site provides much more information about the program, such as software requirements, installation and usage instructions, and other issues pertaining to PythonCAD. There are even a few screen shots show PythonCAD in action. http://www.pythoncad.org Come and join me in developing PythonCAD into a first class drafting program! I'd like to thank the entire Python development team for all their efforts in creating and maintaining Python. My project would not exist without your work! 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 From titus@caltech.edu Fri Dec 27 09:46:45 2002 From: titus@caltech.edu (Titus Brown) Date: Fri, 27 Dec 2002 01:46:45 -0800 Subject: PyWX 1.0b2 release (Python for AOLserver) Message-ID: We are pleased to announce the release of PyWX version 1.0b2. This is our second beta release; it is known to be fairly stable. PyWX can be retrieved from SourceForge, http://download.sourceforge.net/PyWX/PyWX-1.0b2.tar.gz The PyWX homepage is http://pywx.idyll.org What is PyWX? ------------- PyWX is a Python module for AOLserver. AOLserver is a free, open-source, enterprise-class, multi-threaded web server whose performance on dynamic content is reputed to beat Apache. It is used at many large web sites including AOL and ArsDigita. It includes an internal database API that allows persistent database connections. Python is a clean, object-oriented scripting language with excellent support for complicated data structures and great libraries for web programming. PyWX embeds a Python interpreter into AOLserver, allowing threaded execution of Python scripts--even CGI scripts--within the server process. It also allows the Python script to access almost all of AOLserver's internal API via a C extension module. PyWX supports many other features, including + Threaded execution of CGI scripts within emulated CGI environment. + Cross-connection data-persistence. + Access to AOLserver's persistent database mechanism. + Internal Webware and Quixote adaptors. + Pretty good documentation. + Object-oriented Python wrapping of AOLserver's C API functions. Almost all of AOLserver's facilities are available to Python scripts. + Full access to AOLserver's Tcl interpreter from Python, and vice versa. + Optional compiled-script caching. What's new in version 1.0b2? ---------------------------- + configuration script now works properly, documentation updated. + Fixes for gcc 3.x. + Fix for a memory leak (the last detectable one!). + Several fixes for handling POSTed multipart/form-data. + Fix for uncaught exception. + Cleanup of internal HTTP header handling. + Extreme simplification of internals, fix of a crashing bug. + Update for AOLserver 3.5. + Added a handler for the Quixote application server. + Fixed unnecessary proliferation of end-of-connection callbacks. Version 1.0b2 is a bug fix version for 1.0b1 that has been tested over the past year and a half. It is currently used in several stable projects, and there are no known bugs remaining. As a rough measure of its current performance, without optimizing the machine PyWX can deliver a trivial Python script at roughly 230-310 pages per second on a single-processor Pentium 3/500MHz under Linux, and a trivial Oracle database-querying script at about 75-90 pages/s. (The range depends on PyWX configuration.) Please check out our home page at http://pywx.idyll.org and our SourceForge project page at http://sourceforge.net/projects/pywx/ for more information on PyWX, including mailing lists, development archives, and several example pages. You may also be interested in: http://www.aolserver.com -- AOLserver http://www.python.org -- the Python programming language http://webware.sourceforge.net -- Webware toolkit http://www.mems-exchange.org/software/quixote/ -- Quixote toolkit Cheers, Titus Brown for the PyWX team. From ulextida@gisco.mh.us Sat Dec 28 21:44:42 2002 From: ulextida@gisco.mh.us (Byron) Date: Sat, 28 Dec 2002 21:44:42 GMT Subject: Jay, this is my view from NYC Message-ID: <656215C4.E6CAD915@gisco.mh.us> a very skillful attack who profits? -Israeli incursions in two P.A. towns -the largest British fleet organized in eighteen years "coincidentally" has been on route for days nearing the Middle East for "maneuvers" -America asking for coalition of global powers for new "counter-insurgent" war... a planetary Vietnam. Rather then seriously ask why people would kill themselves and so many others, "we" put an answer in their mouths and say, -Prez-"they attack us because we are the bastion of freedom in the world." period.... Some introspection? No. Respect for the enemy? No. Understanding the enemy? No. That is why the forces of reaction do not know what the terms are or what to do. These are the fruits of the politics of denial. We deny the complaints of our victims, even deny they are our victims, and blind ourselves to a planet of enmity. Understanding this, as I have long fruitlessly preached as a "lunatic", one must take one of three possible courses: X) Understand ones position of domination, take every defensive measure, and terrorize the dominated. Y) Deny ones imperial position and be over run by a million cuts Z) Discard past paradigms worn thin since times before pharaoh, make a detente for all humankind and all the rest of nature, including a transformation in our relationships to the Earth and human to human. The standing "American authorities" want solution Y with a big war on the dispossessed, Islam, and the rest. It would be the fourth world war since the sheep in America seem to have missed the third one. Our "leaders" are inept, impotent, and culpable in one of two ways. First: For a second "hijacked" commercial jet to strike the most critical concentration in the global capitalist economy, twenty minutes after the first, and with no military response, is profound negligence. Particularly in the wake of the 1993 WTC attack, the success of this attack is pure negligence...or... complicity. If it is simple puerile negligence, then the governor of NY, and the mayor of NYC, who are so busy congratulating and patting each other on the back for what a great job they have done, should resign in shame and utter humiliation for their total failure. Also former governor Cuomo should beg the forgiveness of his constituents and the greater public. The joint chiefs of staff, as well as all regional military and air commanders should resign or be court-martialed for negligence. The current administration as well as members of senate and house intelligence and military committees should be removed from office and placed under house arrest for extensive questioning. The former administration should be likewise detained. All planning staffs for civil defense and air security should be detained and questioned, if not court marshaled. That is if an enemy attacked us. If there was, however, foreknowledge by any elements of our government, there should be a grand jury, and also a global response. There have been many comparisons today and since the annihilation of the WTC with Pearl Harbor, the attack on Hawaii in 1941. Years of speculation over the absence of our vital air-craft carriers at that attack, as well as myriad evidence, points to a foreknowledge by F.D.R. which is confirmed by a decade of public study of the code breaking facts of Ultra Mega. Many times after Pearl Harbor the British and Americans allowed their own troop ships to go to the bottom rather than reveal to the enemy that all their codes were useless. This was rationalized then and now as expedient both to motivate the American public to eagerness for war and to help finally win it. Today what would be the motive? In a world that should head for peace we have a threatened way of life, the global capitalist military industrial "complex". In need of perceived enemies and great battles, and willing to accept at least a police state "counter-insurgency" planetary domination system, would they sacrifice the WTC? Symbolically it will inspire hundreds of thousands of those disenfranchised with western freedom to fight and seek training and organizations that can help them achieve something so grand. There is our enemy, since realistically China has not invaded its neighbors significantly for a thousand year and is not likely to threaten the U.S.(only Tibet, and maybe one of Siberia.... wait and see-either way the U.S. never even did anything about Tibet) So now around the world we will have tight security which will not stop anything and the police state planet NWO will attempt to take control and will, basically if they are not stopped here. Guilty or innocent the current authorities have to go, for America and the Earth Feel free to distribute my views... What was it an attack against? a view from NYC: 14sep2001 -- They are cleaning with the cafe now, won't attack smogs later. From itamar@itamarst.org Sat Dec 28 23:09:15 2002 From: itamar@itamarst.org (Itamar Shtull-Trauring) Date: Sat, 28 Dec 2002 18:09:15 -0500 Subject: ANN: Cog object database v0.3 Message-ID: Cog is the Checkpointed Object Graph object database, providing semi-transparent persistence for large sets of interrelated Python objects. It handles automatic loading of objects on reference, and saving of modified objects back to disk. Reference counting is used to automatically remove no longer referenced objects from storage, and objects will be automatically be attached to the database if a persistent object references them. Cog does not provide traditional transaction support. Instead, it provides only a way to flag the database as self-consistent, and guarantees that on system restart, the database will be restored to the most recent possible self-consistent state. Cog was originally written by Oliver Jowett (http://www.randomly.org). Download: http://itamarst.org/software/cog/ -- Itamar Shtull-Trauring http://itamarst.org/ Available for Python, Twisted, Zope and Java consulting ***> http://VoteNoWar.org -- vote/donate/volunteer <*** From lkcl@samba-tng.org Sun Dec 29 01:40:00 2002 From: lkcl@samba-tng.org (Luke Kenneth Casson Leighton) Date: Sun, 29 Dec 2002 01:40:00 +0000 Subject: [ANN] custom 0.3 released Message-ID: Note by the author ------------------ the history of this project is that it is a live-running and also continuously developing project to meet a hard-nosed businesses needs. the decision to make it open source has been considered for some time, and recently actioned. the primary motivation for releasing Custom as open source is to make it possible for managers and developers to use Custom, not just myself and the day-to-day staff at the business where Custom is in use. on with the release notes... Custom ------ custom is an e-commerce solution for small to medium-sized businesses that provides: - a web front-end for customers and Point-of-Sale staff to place orders - for warehouse staff to manage stock - for accountants and sales staff to manage and generate invoices - for purchasing managers to keep track of suppliers and competitive pricing. Download -------- http://sf.net/projects/custom Requirements ------------ This package requires or uses the following software, where the MySQL or MS-SQL package need not necessarily be installed on the same server as the rest: - Python 2.1 or greater (http://python.org) - EITHER: - MySQL client libraries (http://mysql.org) - Andy Dustman's MySQLdb package (requires MySQL client) (http://sf.net/projects/mysqldb) OR: - Pysxqmll (a Python / MS-SQL / XML client for MS-SQL 2000) (http://sf.net/projects/pysxqmll) [what a stupid name.] - The mxDateTime and DateTime packages (http://starship.skyport.net/~lemburg/mxDateTime.html) - PyCrypto version 1.9a1 or greater (http://sf.net/pycrypto) In case you were wondering, PostgreSQL is under investigation to be added into the database abstraction system that custom uses. custom uses some features in the SocketServer class that were introduced in Python 2.1. If you wish to stick with Python 2.0, you may wish to copy over the SocketServer.py file from the distribution of Python 2.1 or greater, and use that (making sure that you back up your original SocketServer.py file!) SQL --- You must also install MySQL or MS-SQL 2000 on a server, where you may wish to install the SQL server on a separate system. A high-availability cluster pair is recommended, under which circumstances, if you are considering HA, you should NOT install the custom package on the same box as the SQL database. Yet. Optional requirements --------------------- A barcode scanning device, such as those available from Worth Data (www.pcbarcode.com) that reads EAN and other barcodes and pretends to be a USB keyboard, proves to be very useful. If you are running Linux, install the full HID USB device module and the Input Device and Keyboard support modules: CONFIG_INPUT=m CONFIG_INPUT_KEYBDEV=m CONFIG_USB_HID=m Do not be fooled into installing the partial HID USB keyboard device (CONFIG_USB_KBD) on its own, because it won't work, you MUST install the full HID support. TODO ---- - Create website to describe custom - Create user documentation - Move as much administration into SQL as possible NOTES ----- Please read the INSTALL.txt notes in each directory. The order of installation of the packages is not important, however in order to run the start-up commands specified in the INSTALL.txt notes, you should follow the instructions to the letter, in the following order: - pysqldb/ - cgi/ - Example/ - db/ The purpose of each package is explained below: - pysqldb/ pysqldb contains the package DPyDB which is a collection of SQL abstraction and configuration management classes. - cgi/ cgi contains the HTML dynamic content generation scripts for your site. this is the back-bone of the custom package. however, the formatting and presentation of the HTML is left to some base classes, and you are expected to write your own formatting classes, with the Example/ site presentation classes as... well... examples :) for you to base them on. - Example/ Example/ contains some classes responsible for presentation of your web site, and it also contains the configuration file for the whole package, /etc/custom.conf. If you wish to start creating your own web site immediately, you should copy this entire subdirectory, global/search replace the word "Example" in all files with your own appropriate directory name, and start from there. Typical examples of the functions used are print_html and print_footer, which, funnily enough, output the HTML content at the start and end of every web page, respectively. This is the bit where you may wish to consult with other users of custom, or to hire the author to help with your site design... - db/ db contains all the database management routines used by both the front-end and the back-end of the custom package. db depends on pysqldb, and in turn, the cgi scripts and back-office program monitord.py depend on db/ From mtclough@mclough.uklinux.net Mon Dec 16 13:04:03 2002 From: mtclough@mclough.uklinux.net (Martin Clough) Date: Mon, 16 Dec 2002 08:04:03 -0500 (EST) Subject: [Application] EarltMath 0.1 Message-ID: EarltMath 0.1 ------------- EarlyMath is an arithmetic practice program for 5-7 year olds. EarlyMath is for practicing arithmetic for 5 to 7 year old children - Key Stage 1 in UK education-speak. The program presents random problems at a range of levels. EarlyMath is written in Python using the PyQt toolkit. URL: http://www.mclough.uklinux.net/EarlyMath.html Download: http://www.mclough.uklinux.net/EarlyMath-0.1.tar.gz License: GPL Requires: PyQT, QT Gui: PyQT Categories: Applications Martin Clough (mtclough@mclough.uklinux.net) www.mclough.uklinux.net -- EarltMath 0.1 -- EarlyMath is an arithmetic practice program for 5-7 year olds. From wari@wari.per.sg Thu Dec 19 08:35:25 2002 From: wari@wari.per.sg (Wari Wahab) Date: Thu, 19 Dec 2002 03:35:25 -0500 (EST) Subject: [Application] pyblosxom 0+5i_rev3 Message-ID: pyblosxom 0+5i_rev3 ------------------- PyBlosxom is an implementation of blosxom written in Python Pyblosxom is a weblog engine that uses standard text files located on your filesystem as a database of weblog entries. The concept is simple, managing content is as easy as editing a text file with your favourite text editor. In addition to the features of blosxom, on which it is based, it can be easily extended with preformatters, it also supports bloggerAPI, an XMLRPC interface that most weblog GUI tools supports. URL: http://sourceforge.net/projects/pyblosxom/ License: Python Style Platform: POSIX, Win32(with minor modifications) Categories: Web Wari Wahab (wari@wari.per.sg) http://roughingit.subtlehints.net/ -- pyblosxom 0+5i_rev3 -- PyBlosxom is an implementation of blosxom written in Python From pylirc.linus@mccabe.nu Mon Dec 16 22:31:24 2002 From: pylirc.linus@mccabe.nu (Linus McCabe) Date: Mon, 16 Dec 2002 17:31:24 -0500 (EST) Subject: [Module] pyLirc Message-ID: pyLirc ------ Module to interact with lirc to get remote control support in python Module developed in C to get a python api to the lirc client library. URL: http://sourceforge.net/projects/pylirc/ License: LGPL Platform: linux Requires: lirc client Binaries: linux Categories: User Interfaces, input Linus McCabe (pylirc.linus@mccabe.nu) http://linus.mccabe.nu -- pyLirc -- Module to interact with lirc to get remote control support in python From olivier.ravard@novagrid.com Mon Dec 16 11:57:04 2002 From: olivier.ravard@novagrid.com (Olivier Ravard) Date: Mon, 16 Dec 2002 06:57:04 -0500 (EST) Subject: [Module] NovaGrid 1.0 Message-ID: NovaGrid 1.0 ------------ A light spreadsheet module written in Python/Tkinter and based on Tktable. Can be packed into larger applications. The NovaGrid spreadsheet is a light spreadsheet entirely written in Python / Tkinter and is a free software under GPL. It is a little module of the NovaRPC project. The NovaGrid spreadsheet (and ploting tool) is hosted by sourforge (http://www.sourceforge.net/projects/novagrid). This spreadsheet features are : - to be light, - it can be " packed " or " placed " in a toplevel or in a frame, - you can inserting and deleting data from a python script, - you can plot data from some or all of data in the spreasheet, - to be multi os (Linux and Windows) URL: http://www.novagrid.com/page.php?p=spreadsheet.html Download: http://www.sourceforge.net/projects/novagrid License: GPL Platform: win32, Linux Requires: Tktable BWidget Gui: Tkinter Categories: Tkinter Widgets Olivier Ravard (olivier.ravard@novagrid.com) http://www.novagrid.com -- NovaGrid 1.0 -- A light spreadsheet module written in Python/Tkinter and based on Tktable. Can be packed into larger applications. From iusty@k1024.org Sun Dec 22 03:02:17 2002 From: iusty@k1024.org (Iustin Pop) Date: Sat, 21 Dec 2002 22:02:17 -0500 (EST) Subject: [Application] bakonf-0.5 Message-ID: bakonf-0.5 ---------- A system tool for making backups of configuration files bakonf is a tool for making backups of configuration files on GNU/Linux or Unix-like systems. It uses various methods to reduce the size of the backups it creates, and is designed to be useful for unattended remote servers. URL: http://www.nongnu.org/bakonf Download: http://savannah.nongnu.org/download/bakonf/unstable.pkg/0.5/bakonf-0.5.tar.gz License: GPL Platform: Unix Requires: tarfile optik bz2 Binaries: rpm Categories: Utility Apps Iustin Pop (iusty@k1024.org) -- bakonf-0.5 -- A system tool for making backups of configuration files From thanos@scriptfoundry.com Mon Dec 23 13:20:02 2002 From: thanos@scriptfoundry.com (thanos vassilakis) Date: Mon, 23 Dec 2002 08:20:02 -0500 (EST) Subject: [Web Site] A Build your own portal in 1 hour ! Message-ID: A Build your own portal in 1 hour ! ------------------------------------ How to building a internet portal in 1 hour using python and pso We would like to show how one would build a web service using pso. As an example we will build a small portal. It should take less than an hour. The sites requirements will be: Have some pages available to the public and some only for members. Offer simple member registration system. members will be able to upload a jpeg of themselves. Once logged in members will be able to return within the same day without logging in again. Members will be able to view listings of information. Although this site does nothing in particular it will illustrate the following: Template Nesting Session Handling Redirection handling security and logging in. Simple Form Handling without confirmation stage Complex Forms with confirmation stage File uploading URL: http://www.scriptfoundry.com/modules/pso/doc/pso-example.html Categories: Tutorials, Internet . Web thanos vassilakis (thanos@scriptfoundry.com) http://www.scriptfoundry.com/~thanos/ -- A Build your own portal in 1 hour ! -- How to building a internet portal in 1 hour using python and pso From iusty@k1024.org Thu Dec 26 03:44:13 2002 From: iusty@k1024.org (Iustin Pop) Date: Wed, 25 Dec 2002 22:44:13 -0500 (EST) Subject: [Module] pyxattr-0.1 Message-ID: pyxattr-0.1 ----------- A python module for accessing filesystem Extended Attributes A python module for accessing filesystem Extended Attributes. It allows you to query, set/get and remove extended attributes from files. It is a wrapper over the C libattr library. URL: http://pyxattr.sourceforge.net/ License: GPL Platform: Linux Binaries: Linux Categories: Files Iustin Pop (iusty@k1024.org) -- pyxattr-0.1 -- A python module for accessing filesystem Extended Attributes From iusty@k1024.org Thu Dec 26 03:47:43 2002 From: iusty@k1024.org (Iustin Pop) Date: Wed, 25 Dec 2002 22:47:43 -0500 (EST) Subject: [Module] pylibacl-0.1 Message-ID: pylibacl-0.1 ------------ A python module for manipulating POSIX.1e ACLs This module allows you to manipulate (get, set) the POSIX1.e ACLs on filesystems and OSes which implement them. This is the first public release. The basic functionality is complete, and work is underway to implement all 17 functions in the draft (with a python-like flavor, of course, not bare-bone wrapping). URL: http://pylibacl.sourceforge.net/ License: GPL Platform: POSIX compliant (Linux, FreeBSD, etc) Binaries: Linux FreeBSD Categories: Files Iustin Pop (iusty@k1024.org) -- pylibacl-0.1 -- A python module for manipulating POSIX.1e ACLs From ngps@netmemetic.com (Ng Pheng Siong) Sun Dec 29 16:58:44 2002 From: ngps@netmemetic.com (Ng Pheng Siong) (Ng Pheng Siong) Date: 29 Dec 2002 16:58:44 GMT Subject: [Announce] M2Crypto 0.08 Message-ID: Hi, I present M2Crypto 0.08. Not quite in time for Christmas, but I managed to keep up my tradition of at-least-one-release-per-year for ZServerSSL. What's new: - SWIG 1.3.17. - setup.py does! - ZServerSSL for Zope 2.6.0. Please check it out: http://www.post1.com/home/ngps/m2 Happy New Year! -- Ng Pheng Siong * http://www.netmemetic.com From detlev@die-offenbachs.de Tue Dec 31 10:20:21 2002 From: detlev@die-offenbachs.de (Detlev Offenbach) Date: Tue, 31 Dec 2002 11:20:21 +0100 Subject: ANN: Eric 3.0.1 released Message-ID: Hi, After having received some bug reports and patches during the last two weeks I am proud to announce that Eric 3.0.1 is available for download via http://www.die-offenbachs.de/detlev/eric3.html This is mainly a bugfix release with some functionality enhancements. It includes printing support and support for python sourcecode in foreign character sets (PEP 263). For details see the history file in the distribution. What is it? ----------- Eric 3.0.1 (or short eric3) is a Python IDE written using PyQt and QScintilla. It has integrated project management capabilities, it gives you an unlimited number of editors, an integrated Python shell, an integrated debugger and more. Please see for yourself by visiting the a.m. page (it contains a picture of Eric our mascot as well). Please report bugs, feature wishes or code contributions to eric-bugs@die-offenbachs.de Help wanted!! ------------- I would need some support in the area of more translations and user documentation. Any volunteers out there? Just let me know. Regards, Detlev -- Detlev Offenbach detlev@die-offenbachs.de From jason@tishler.net Tue Dec 31 19:06:59 2002 From: jason@tishler.net (Jason Tishler) Date: Tue, 31 Dec 2002 14:06:59 -0500 Subject: Updated Cygwin Package: python-2.2.2-4 Message-ID: New News: === ==== I have updated the version of Python to 2.2.2-4. The tarballs should be available on a Cygwin mirror near you shortly. The main purpose of this release is to rebuild the _tkinter module against the latest Cygwin tcltk package. Additionally, the _socket module is *no* longer built as a static module to workaround a Cygwin fork() issue due to DLL base address conflicts. Note that this workaround does not works with the current Cygwin release. Instead, if you are experiencing fork() failures, then you must rebase your Cygwin system. See the README for more details. Old News: === ==== Python is an interpreted, interactive, object-oriented programming language. If interested, see the Python web site for more details: http://www.python.org/ Please read the README file: /usr/doc/Cygwin/python-2.2.2.README since it covers requirements, installation, known issues, etc. To update your installation, click on the "Install Cygwin now" link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Note that we have recently stopped downloads from sources.redhat.com (aka cygwin.com) due to bandwidth limitations. This means that you will need to find a mirror which has this update. In the US, ftp://mirrors.rcn.net/mirrors/sources.redhat.com/cygwin/ is a reliable high bandwidth connection. In Germany, ftp://ftp.uni-erlangen.de/pub/pc/gnuwin32/cygwin/mirrors/cygnus/ is usually pretty good. In the UK, http://programming.ccp14.ac.uk/ftp-mirror/programming/cygwin/pub/cygwin/ is usually up-to-date within 48 hours. If one of the above doesn't have the latest version of this package then you can either wait for the site to be updated or find another mirror. The setup.exe program will figure out what needs to be updated on your system and will install newer packages automatically. If you have questions or comments, please send them to the Cygwin mailing list at: cygwin@cygwin.com . I would appreciate if you would use this mailing list rather than emailing me directly. This includes ideas and comments about the setup utility or Cygwin in general. If you want to make a point or ask a question, the Cygwin mailing list is the appropriate place. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 From barry@python.org Tue Dec 31 22:29:54 2002 From: barry@python.org (Barry A. Warsaw) Date: Tue, 31 Dec 2002 17:29:54 -0500 Subject: RELEASED Mailman 2.1 - final Message-ID: After nearly two years of development, we are happy to announce the release of GNU Mailman 2.1. Mailman is free software that enables users to manage email mailing lists and e-newsletters. Its integrated web interface provides easy-to-use access for list members and list administrators. Mailman supports built-in archiving, automatic bounce processing, content filtering, digest delivery, spam filters, and more. Mailman 2.1 is fully internationalized, supporting 17 languages out-of-the-box. A summary of additional new features in Mailman 2.1 is outlined below. The NEWS file in the source distribution contains more details about all the new features. For more information on Mailman, including downloading and installation instructions, please visit one of the following mirror sites: http://www.list.org http://www.gnu.org/software/mailman http://mailman.sf.net The Mailman developers wish to thank Control.com for their sponsorship of several Mailman 2.1 features, Zope Corporation for their support, and the entire Mailman community for their contributions. -Barry Warsaw Pythonlabs, Zope Corporation -------------------- snip snip -------------------- - Multi-lingual support for all web pages and Mailman generated email notices, with languages selectable on a per-site, per-list, and per-user basis. - Through-the-web list creation and removal; (with automatic support depending on the MTA) - "Real name" support for members - Improved simple user-task operation (e.g. no passwords required for subscription and unsubscription). - Support for personalized deliveries and VERP-like message delivery for foolproof bounce detection - Emergency moderation - MIME-based content-filtering, with demime/stripmime-like options - Regular expression based topic-filtering - Better membership management, including searching - Re-organized administrative requests pages - Moderated newsgroup support - A new architecture for the mail delivery subsystem, removing dependence on cron, resulting in improved responsiveness and scalability - New moderation and privacy controls - Invitations - Autoresponse governors - Users can now change some delivery options globally, for all lists at a site, including their password, delivery status, real name, and more. - Improved MIME and I18n support in the archiver - Addition of a separate "list moderator" role - Urgent: header support (bypasses digests to reach all users immediately). From guido@python.org Tue Dec 31 23:35:07 2002 From: guido@python.org (Guido van Rossum) Date: Tue, 31 Dec 2002 18:35:07 -0500 Subject: Python 2.3a1 released Message-ID: I'm happy to announce the successful release of Python 2.3a1 tonight, on Dec 31 (in *some* timezones :-). Go pick it up from its home page: http://www.python.org/2.3/ This is an alpha release: if you have Python code that's important (to you), please test it thoroughly with this release, but don't use the release for production runs. Please report any problems to the SourceForge bug tracker: http://sourceforge.net/bugs/?group_id=5470 What's new? The language isn't changing much this time. Instead, we have lots of new or improved standard library modules: bsddb, bz2, datetime, heapq, logging, optparse, ossaudiodev, random (Mersenne Twister algorithm), sets, socket (added timeouts), textwrap, and zipimport. That's right, you can now import modules from zip files. More elaborate news is on the website: http://www.python.org/2.3/highlights.html (brief) http://www.python.org/doc/2.3a1/whatsnew/ (extensive) http://www.python.org/2.3/NEWS.html (exhausting) --Guido van Rossum (home page: http://www.python.org/~guido/) From fmc@inf.ufg.br Tue Dec 31 18:34:00 2002 From: fmc@inf.ufg.br (Fabio M. Costa) Date: Tue, 31 Dec 2002 16:34:00 -0200 (=?X-UNKNOWN?Q?Hor=2E_de_ver=E3o_leste_da_Am=2E_Sul?=) Subject: Middleware2003: Call for Contributions Message-ID: ACM/IFIP/USENIX INTERNATIONAL MIDDLEWARE CONFERENCE http://middleware2003.inf.puc-rio.br http://gsd.ime.usp.br/middleware2003 Rio de Janeiro, Brazil, 16-20 June 2003 CALL FOR CONTRIBUTIONS 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. SUBMISSION DEADLINES ==================== Tutorial Proposals: 15 January 2003 (!) Work in Progress Papers, Workshop Papers, and Posters : 20 February 2003 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@cs.wustl.edu) or Markus Endler (endler@inf.puc-rio.br). For other questions contact the local arrangements chairs, Alexandre Sztajnberg (alexszt@uerj.br) or Renato Cerqueira (rcerq@inf.puc-rio.br).