Mailman 3 December 2002 - Python-announce-list

DAXFi 1.0
by alberanid＠libero.it 19 Dec '02

19 Dec '02

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: <alberanid(a)libero.it> Personal home page: http://digilander.iol.it/alberanid/

1 0

ANNOUNCE: Python 2.2.1 Release 1.0 for DOS
by deckerben 18 Dec '02

18 Dec '02

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

1 0

Seeking Expressions of Support
by Steve Holden 18 Dec '02

18 Dec '02

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/ -----------------------------------------------------------------------

1 0

PyCon DC 2003: Extension of submission deadline
by Steve Holden 18 Dec '02

18 Dec '02

[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(a)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/ -----------------------------------------------------------------------

1 0

Flightdeck-UI Multi-Variable Monitor App. V. 0.1.1 released
by fdui＠openlight.com 17 Dec '02

17 Dec '02

*** 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(a)openlight.com).

1 0

Strip-o-Gram 1.3 Released!
by Chris Withers 17 Dec '02

17 Dec '02

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

1 0

Middleware2003: 5 days for deadline - Call for Papers
by Fabio M. Costa 17 Dec '02

17 Dec '02

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(a)cs.wustl.edu) or Markus Endler (endler(a)inf.puc-rio.br). For other questions contact the local arrangements chairs, Alexandre Sztajnberg (alexszt(a)uerj.br) or Renato Cerqueira (rcerq(a)inf.puc-rio.br).

1 0

python-dev Summary for 2002-12-01 through 2002-12-15
by drifty＠bigfoot.com 17 Dec '02

17 Dec '02

+++++++++++++++++++++++++++++++++++++++++++++++++++++ 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(a)python.org or comp.lang.python in the usual way; give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration). All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev! This is the seventh summary written by Brett Cannon (and thus my seventh attempt to get into amk's `Python Quotations <http://www.amk.ca/quotations/python-quotes/>`__). 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 <http://mail.python.org/pipermail/python-dev/2002-December/030638.html>`__ - `Re: New and Improved Import Hooks <http://mail.python.org/pipermail/python-dev/2002-December/030708.html>`__ - `Re[2]: [Python-Dev] New and Improved Import Hooks <http://mail.python.org/pipermail/python-dev/2002-December/030776.html>`__ - `New Import Hook & New Zip Importer <http://mail.python.org/pipermail/python-dev/2002-December/030755.html>`__ - `(no subject) <http://mail.python.org/pipermail/python-dev/2002-December/030812.html>`__ - `Another approach for the import mechanism <http://mail.python.org/pipermail/python-dev/2002-December/030828.html>`__ - `Re: Another approach for the import mechanism <http://mail.python.org/pipermail/python-dev/2002-December/030985.html>`__ - `New Import Hook & New Zip Importer <http://mail.python.org/pipermail/python-dev/2002-December/030755.html>`__ - `Import: where's the PEP? <http://mail.python.org/pipermail/python-dev/2002-December/030868.html>`__ - `zipimport & import hooks <http://mail.python.org/pipermail/python-dev/2002-December/030886.html>`__ - `VFS <http://mail.python.org/pipermail/python-dev/2002-December/030952.html>`__ - `Zip imports, PEP 273, and the .zip extension <http://mail.python.org/pipermail/python-dev/2002-December/030953.html>`__ - `Import compromise <http://mail.python.org/pipermail/python-dev/2002-December/030956.html>`__ - `zipimport, round 3 (or would that be 37?) <http://mail.python.org/pipermail/python-dev/2002-December/030968.html>`__ - `Complexity of import.c <http://mail.python.org/pipermail/python-dev/2002-December/031000.html>`__ - `zipimport, round 4 <http://mail.python.org/pipermail/python-dev/2002-December/031009.html>`__ - `new import hooks & zip import <http://mail.python.org/pipermail/python-dev/2002-December/030755.html>`__ 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/Pytho… .. _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/sandbo… .. _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… ======================================================== `__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/Modul… ============ `PEP 298`__ ============ __ http://mail.python.org/pipermail/python-dev/2002-December/031109.html Splinter threads: - `PEP-298: buffer interface widening too much? <http://mail.python.org/pipermail/python-dev/2002-December/031163.html>`__ - `PEP-298: buffer interface widening too much? <http://mail.python.org/pipermail/python-dev/2002-December/031184.html>`__ 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

1 0

[Module] pyLirc
by Linus McCabe 16 Dec '02

16 Dec '02

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(a)mccabe.nu) http://linus.mccabe.nu -- <a href="http://sourceforge.net/projects/pylirc/">pyLirc</a> -- Module to interact with lirc to get remote control support in python

1 0

[Application] EarltMath 0.1
by Martin Clough 16 Dec '02

16 Dec '02

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(a)mclough.uklinux.net) www.mclough.uklinux.net -- <a href="http://www.mclough.uklinux.net/EarlyMath.html">EarltMath 0.1</a> -- EarlyMath is an arithmetic practice program for 5-7 year olds.

1 0