Mailman 3 August 2001 - Python-announce-list

python-dev summary, July 16-31
by Andrew Kuchling 07 Aug '01

07 Aug '01

This is a summary of traffic on the python-dev mailing list between July 16 and July 31 2001. It is intended to inform the wider Python community of ongoing developments. To comment, 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 a PEP if you have an opinion. Summaries are archived at: <http://starship.python.net/crew/mwh/summaries/> <http://www.amk.ca/python/dev/> And following close behind the grossly delayed July 4-15 one, here's the python-dev summary for July 16-31. Two Python releases came out during this period. As usually happens in the interval surrounding a release, there were two kinds of discussions on python-dev: a few lengthy ones thrashing around an issue, and lots of little short ones to resolve a single bug or issue. --amk Python 2.1.1 released ===================== Python 2.1.1, a bugfix release, was issued on July 20th as announced by GvR. Thomas Wouters was the release manager, and did a fine job of backporting patches from the 2.2 CVS tree. http://www.python.org/2.1.1/ 2.1.1 makes a slight modification to Python's license for the sake of GPL compatibility, so there should no longer be any impediment (if there ever was) to 2.1 finding its way into Linux distributions. Roswell, the new Red Hat beta, already includes Python 2.1.1, and it should also make its way into Debian testing before too long. The first alpha release of Python 2.2 was also issued during this period, on July 18. http://www.python.org/2.2/ 2.2a1 includes new support for iterators and generators, plus the usual pile of bugfixes, of course. The source distribution for 2.2a1 was taken from 'descr-branch', the experimental branch in CVS containing significant changes to the implementation of Python's object model (PEP 252 and 253). Guido is working on a tutorial for these changes: http://www.python.org/2.2/descrintro.html As usual I'm writing up an explanation of the changes in 2.2: http://www.amk.ca/python/2.2/ Neil Schemenauer posted some patches to make ExtensionClass compile with 2.2a1, and ran the MEMS Exchange's basic unit tests successfully; this amounts to 3569 test case over roughly 18,000 lines of code, so this is a good sign. http://mail.python.org/pipermail/python-dev/2001-July/016494.html No one else reported any problems with the descr-branch changes, so on July 31 Tim Peters announced that the descr-branch would be merged back into the trunk and the branch brought to a close. That was done a day or so later. Division ======== I came back from vacation to find comp.lang.python filled with an endless and at times vitriolic flame war over PEP 238, "Non-integer Division". It seems to have been triggered to some degree by GvR posting a proposed patch, which gave the impression that the issue was decided and the solution set in stone: http://mail.python.org/pipermail/python-dev/2001-July/016174.html The resulting firestorm didn't touch python-dev much, so I don't need to summarize them. They did lead to a revised version of PEP 238, discussing many of the suggestions and ideas that were raised: http://python.sourceforge.net/peps/pep-0238.html Parrot ====== Another lengthy thread started when Eric S. Raymond reported on some discussions from the Open Source Conference: "The Perl people are receptive -- indeed, some of them are actively pushing -- the idea that their new bytecode should not be Perl-specific. Dan Sugalski, the current lead for the bytecode interpreter project, has named it Parrot. At the Perl 6 talk I attended, Chip Salzenberg speculated in public about possibly supporting a common runtime for Perl, Python, Ruby, and Intercal(!)." http://mail.python.org/pipermail/python-dev/2001-July/016406.html Guido didn't immediately rule the idea out: "Obviously, just as the new design is aiming at Perl 6, it would be aiming at Python 3. Nothing's impossible these days, so I am keeping an open mind. I expect that in addition to the bytecode, the entire runtime architecture would have to be shared though for this to make sense, and I'm not sure how easy that would be, even if Perl is willing to be flexible. Most of Python's run-time semantics are very carefully defined and shouldn't be changed in order to fit in the common runtime." http://mail.python.org/pipermail/python-dev/2001-July/016413.html The resulting discussions ranged over a number of topics: regex implementations, Python's current virtual machine, the proposed Perl6 virtual machine, how to support both Python and Perl semantics at the same time, and the mechanics of standards committees. The only concrete outcome of all this chatter was that Raymond will write an architectural comparison of the existing Python and Perl bytecodes. It's far too early to say if anything will come of this, so a common VM should be viewed as an interesting, but not particularly likely, possibility for now; when more details of the Parrot VM's design become clear, the idea will no doubt resurface. cgitb.py ======== ?!ng resurfaced after a lengthy absence, and proposed the cgitb module for addition. Demoed at IPC9, cgitb.py sets an exception-handling hook using sys.excepthook that produces a nicely formatted traceback instead of just letting the script cause an HTTP 500 'Internal Server Error'. For your debugging convenience, the traceback also includes the local variables at each level of the stack. The module itself isn't controversial, but ?!ng's suggestion of adding an 'if' to site.py to automatically enable it was. Writing errors to standard output instead of standard error, and in particular sending them out to a potentially hostile Web user, made most people nervous. The consensus was to add the module, but authors of CGI scripts would have to choose to enable the formatted tracebacks, instead of having them automatically enabled. Frank Willison ============== On July 31st, we heard that Frank Willison, the editor-in-chief at O'Reilly, had died suddenly the day before. Paul Prescod posted the news, adding an eloquent tribute: http://mail.python.org/pipermail/python-dev/2001-July/016479.html Tim O'Reilly wrote a memorial on the O'Reilly Web site, and there's also a page of comments from Willison's friends and acquaintances. http://www.oreilly.com/news/frank_0701.html Random bits =========== Panu A Kalliokoski wrote 'Selecting', a module containing an abstraction for writing asynchronous servers, much like asyncore but claimed to be easier to use. http://mail.python.org/pipermail/python-dev/2001-July/016000.html Paul Prescod reported on the existence of a Python port to the Sony Playstation 2. It exists, but unfortunately isn't publicly available. http://mail.python.org/pipermail/python-dev/2001-July/016365.html Moshe Zadka asked if anyone has copies of old versions of Python hanging around. He's found 1.2, but would really like versions preceding 1.0. Discussion of the file encoding directive (covered in the previous python-dev summary) continued, but there was no convergence toward a solution. It looks like this issue will be dropped for a while. IPv6 support for the socket module was committed, and various minor problems came up. All were quickly fixed. http://mail.python.org/pipermail/python-dev/2001-July/016216.html Unanswered questions ==================== Some questions were posted that deserved answers, but didn't get any (in public, at least). I'll misuse my editorial power in an effort to nudge someone into action. Martin Sjögren wondered why the Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS macros don't take an argument specifying a variable to save the thread state to. He said he needed this, but didn't explain why. http://mail.python.org/pipermail/python-dev/2001-July/016190.html Andrew MacIntyre, who's working on an up-to-date OS/2 port of Python, noticed that the parser doesn't use Python's memory allocation hooks to allocate parser nodes. When he tried modifying the parser code to use the allocation hooks, the resulting interpreter worked but took a massive performance hit. http://mail.python.org/pipermail/python-dev/2001-July/016129.html Related Links ============= Python-dev archives: http://www.python.org/pipermail/python-dev/ http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/python-dev Python project page on SourceForge: http://sourceforge.net/projects/python Python Enhancement Proposals (PEPs): http://python.sourceforge.net/peps/

1 0

ANN: PyChecker v0.8
by Neal Norwitz 07 Aug '01

07 Aug '01

A new version of PyChecker is available for your hacking pleasure. PyChecker is a tool for finding common bugs in python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. Comments, criticisms, new ideas, and other feedback is welcome. Change Log from 0.7.5 to 0.8: * Add check for accessing list as list[1,2], should be slice 1:2 * Add -J/maxargs to warn when using too many arguments * Add -K/maxlocals to warn when using too many local variables * Add -D/intdivide to warn when using integer division * Add -O/objattrs to warn when using object.attribute that doesn't exist * Add -M/reimportself to warn when a module imports itself * Add -E/unusednames to provide a list of unused names to ignore (default is: [ '_', 'empty', 'unused' ]) * Major refactoring of warn.py -> utils, msgs, Warning, CodeChecks * Fix spurious warnings for No class attribute for dynamic classes * Fix spurious warnings when using objects from blacklisted modules (Instantiating object with arguments, but no constructor, etc) * Fix spurious warnings when using lambdas * Fix spurious warning (No global Y) when using: from X import Y (problem in python 1.5/1.6 only) In case you missed 0.7.5, here's the change Log from 0.7 to 0.7.5: * Suppress warnings on a per module/function/class/method basis with new suppressions = {} in .pycheckrc * Suppress warnings by setting __pychecker__ in source code * Change long argument behaviour --arg sets arg to true, --no-arg sets arg to false (also works for warning suppression) * Add -U/--reuseattr check if function/class/method names are reused * Add -T/--argsused check for unused method/function arguments * Add -G/--selfused ignore if self is unused in a method (requires --argsused) * Add -q/--stdlib to disable warnings from the standard library * Add -o/--override warning when a method has different signature than one being overridden in a base class * Add -F/--rcfile to generate a .pycheckrc file * Fix checking files in standard library before local file * Fix spurious warning when using from X import Y and imports in methods (Module (m) re-imported) * Fix spurious warning when doing: from X import Y, Z * Fix spurious warning when deriving from Exception() and instantiating object with multiple arguments * Fix method argument checks when calling base class methods * Fix error msg to base constructors (msg count was wrong) * Fix access to builtin module attributes (e.g., sys.exc_value) generating 'No attribute warnings' * Fix tests (forgot to add : after line number in expected results) PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Neal -- pychecker(a)metaslash.com

1 0

[ANNOUNCE] PyUnit 1.4 released
by Steve Purcell 06 Aug '01

06 Aug '01

Version 1.4 of the PyUnit testing framework has just been released. The primary intention of this release is to provide a standalone package of the same PyUnit code contained in the Python 2.1 standard library. This is primarily for the benefit of those who use older (or Java-flavoured) versions of Python. The release may also be of interest to Python 2.1 users who would like to run their tests using the Tkinter-based GUI test runner tool which is part of the PyUnit package but is not contained in the Python standard library. Summary of changes since version 1.3.1: - Updated documentation - main() runs all tests in the module __main__ by default - New code allows all test cases in a given module to be located and instantiated - Simplified command line syntax - Made TextTestRunner configurable with verbose and quiet options, and consequently removed obsoleted JUnitTextTestRunner - Test instantiation code now localised in a replaceable TestLoader class - Distutils 'setup.py' contributed by Bill Bumgarner - TestResult.addSuccess() method added (thanks to Frederic Corne) - Stop overridden test methods being run twice (thanks to Brian Zimmer and Maas-Marten Zeeman) - Don't expand GUI's progress bar vertically when resizing (Fred Drake) The release is available from the PyUnit homepage at http://pyunit.sourceforge.net/ or directly from http://prdownloads.sourceforge.net/pyunit/pyunit-1.4.0.tar.gz Very best wishes to all, -Steve -- Steve Purcell, Pythangelist Get testing at http://pyunit.sourceforge.net/ Test your web apps with http://webunit.sourceforge.net/

1 0

ANN: port of Python 2.1.1 to OS/2+EMX
by Andrew MacIntyre 05 Aug '01

05 Aug '01

I have uploaded a port of Python 2.1.1 to the incoming directories of the Hobbes (http://hobbes.nmsu.edu) and LEO (http://archiv.leo.org/) OS/2 software archives. This port, besides updating to the Python 2.1.1 source level, includes the mpz (GNU MP) and crypt (GNU UFC) modules. I hope crypto export laws don't get in the road here. The distributed archives are: python-2.1.1-os2emx-bin-010805.zip (binary installation package, 3.0MB) python-2.1.1-os2emx-src-010805.zip (source patches and makefiles, 106kB) In addition, the following Python extensions are available in binary packages: Numeric (aka NumPy) v20.1.0 (numericpython-20.1.0-os2emx.zip, 490k) Konrad Hinsen's Scientific v2.2 (scientificpython-2.2-os2emx.zip, 330k) More info available at http://www.andymac.org/software.html; the above archives are also available there if you can't find them at Hobbes or LEO. OS/2 users enjoy! -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 andymac(a)pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

1 0

www.python.org is back!
by Guido van Rossum 03 Aug '01

03 Aug '01

The Python sites http://www.python.org and ftp://ftp.python.org are back up, thanks to the energetic help of Thomas Wouters and XS4ALL (the dutch ISP that's his employer). We're still fetching some missing files from a mirror, so please be patient if your favorite download isn't there yet. We're also still working on restoring the FAQ wizard and the 2.0 MoinMoin and restarting the Ultraseek engine (search.python.org) -- I hope this will be completed later today. Thanks again to XS4ALL (http://www.xs4all.nl/) and Thomas! --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Roundup issue tracker version 0.2.5
by Richard Jones 03 Aug '01

03 Aug '01

Roundup 0.2.5 - an issue tracking system *** This release fixes the setup.py module for python 2.0 users *** Users should also note that the bsddb3 module currently has a bug that renders it non-functinal. The anydbm or bsddb back-ends should be used instead. See the release notes on the website or the CHANGES.txt distributed with the source for more information. Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)users.sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.0+ 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 and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/

1 0

python-dev summary, July 5-15
by Andrew Kuchling 03 Aug '01

03 Aug '01

This is a summary of traffic on the python-dev mailing list between July 5 and July 15 (inclusive) 2001. It is intended to inform the wider Python community of ongoing developments. To comment, 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 a PEP if you have an opinion. Summaries are archived at: <http://starship.python.net/crew/mwh/summaries/> <http://www.amk.ca/python/dev/> Michael Hudson is taking a break from writing the python-dev summaries, so I'll be writing them for the summer. This summary for July 4-15 is quite late, having been delayed first by my week-long vacation in Quebec and then by the file getting accidentally deleted from my laptop -- remember, kids, don't leave important text files sitting in /tmp/. Anyway, after unpacking my luggage and running 'strings' on my root partition, here it is. --am"crawling from the wreckage"k XML-RPC added to standard library ================================= Eric S. Raymond forwarded a suggestion from Dave Winer to add XML-RPC support to Python's standard library. Dave suggests that the open-source community can turn up the heat on Microsoft by visibly supporting and promoting open RPC standards that compete with .NET, such as XML-RPC and SOAP 1.1. He thinks that the implementors of scripting languages like Perl and Python are in a particularly good position to make this happen, by making XML-RPC and/or SOAP 1.1 fully documented parts of their standard libraries. XML-RPC is a simple protocol for making remote procedure calls; function parameters are converted into an XML format and sent using HTTP. Implementations exist for many different languages, and there are two Python implementations, /F's xmlrpclib.py and Eric Kidd's C library. Kidd posted to suggest using /F's code: My library, although nice, is intended for C programmers, and needlessly duplicates a lot of Python functionality. It has its own data model (based on Python's), UTF-8 processing (based on Python's), structure builder (based on Python's), and so on. You get the picture. One objections raised was that XML-RPC is ostensibly ASCII-only, though almost everyone seems to ignore this and supports Unicode anyway, as Eric Kidd pointed out: Fredrik's library supports Unicode. My library supports Unicode. The Java libraries all support Unicode. And furthermore, we all appear to have interop. I was +0, as while XML-RPC works pretty well, what it does isn't very much: My misgiving is that XML-RPC is pretty limited, the lack of support for None being particularly painful to a Python programmer. Perhaps, if we can only have one, SOAP would be better, but I haven't used SOAP seriously for anything yet. /F was +1 on adding xmlrpclib.py, -0 on SOAP support: -0 on soap support in 2.2 (it's still a moving target; a new spec draft was released this weekend). if we want something now, it should be cayce ullman's SOAP.py, not my soaplib.py. but I don't think we need SOAP in the standard library for another year or two. (fwiw, my current thinking is that SOAP is a flawed idea, and that the need for SOAP will go away when people get better XML/Schema tools, but that's another story. and don't get me started on SOAP BDG...) So he checked in the code, and ESR contributed documentation for the module. There's no sign that SOAP is going into 2.2, as everyone seemed rather lukewarm about it. GvR also wondered if Python 2.2 should support DAV ("That's another open protocol that Python could easily support out of the box.") and /F agreed, but Greg Stein, the DAV expert and champion on python-dev, remained silent. site-packages on Windows ======================== On Windows, third-party Python packages get installed into the root of the Python installation, C:\PYTHON2.1. Pete Shinners complained about this: for the love of all things good, can we please make a recommendation in our PEP that the windows installation location be something other than "C:\PYTHON21"? something like "C:\PYTHON21\SITE-PACKAGES" would be a big improvement. i thought i heard that macpython recently made this "fix", why is the windows version lagging on this? PEP 250, by Paul Moore, discusses fixing this. http://python.sourceforge.net/peps/pep-0250.html Encodings for Unicode literals ============================== Another lengthy thread centred around PEP 263, "Defining Unicode Literal Encodings", by M.-A. Lemburg, which suggests using the directive statement proposed by PEP 244 to define a default encoding for Unicode literals. Right now a Unicode literal always uses the 'unicode-escape' encoding, so a literal such as u"\u1234\u4720" is turned into a 2-character Unicode string consisting of U+1234, U+4720. PEP 263 suggests that you could define the encoding to be something else, so you could put, say, Cyrillic characters into a Unicode literal and have them be automatically converted. Most of the problems people have aren't with the idea of indicating the encoding, but rather with how it should be done. PEP 263 suggests something like this: directive unicodeencoding = "UTF-8" But that syntax isn't actually allowed by PEP 244. There's also a circular problem with module docstrings; many tools expect the module docstring to be the very first thing in the file, preceded only by comments and blank lines, so putting a directive first will break such tools. But the encoding should apply to the docstring if it's a Unicode literal, so the directive has to come first. Discussion was inconclusive. Some people liked the idea; others think a comment would be better and easier for non-Python tools such as editors to deal with; yet others don't approve of having a 'directive' statement at all. There seems agreement that the issue of source file encoding is worth clearing up, but no obvious solution is at hand. Related Links ============= Python-dev archives: http://www.python.org/pipermail/python-dev/ http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/python-dev Python project page on SourceForge: http://sourceforge.net/projects/python Python Enhancement Proposals (PEPs): http://python.sourceforge.net/peps/

1 0

Sybase module 0.31 released
by Dave Cole 03 Aug '01

03 Aug '01

What is it: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. Commercial support is available for this module. Please refer to our website for details: http://www.object-craft.com.au/support.html For those people who do not have LaTeX installed there is a PDF document. These is also a PostScript document which prints out a handy A5 booklet on an A4 duplex printer. The module and documentation are all available on here: http://www.object-craft.com.au/projects/sybase/ Thanks ------ Timothy Docker reported and fixed two bugs one of which was quite nasty. Derek Harland supplied a patch to allow mxDateTime.DateTime objects to be supplied as parameters to cursor.execute(). Changes for this release ------------------------ 1) The Connection.execute() method was incorrectly returning DATETIME column values. This was due to a bug in the internal DataBuf implementation which always returned the DATETIME value at index 0 in the buffer regardless of the fact that the buffer contained 16 column values. Note that the Cursor.execute() method was not affected since it only allocates buffers for one row. Thanks to Timothy Docker for fixing this. 2) The internal Sybase.py context initialisation was being performed before the DB-API exceptions were defined. If the initialisation failed the module tried to raise an exception which had not been defined. Ooops. Thanks to Timothy Docker for fixing this. 3) The internal DateTime object no longer allows you to modify the cracked datetime attributes. Previously you may have been fooled into thinking that modifying these attributes would change the internal value... Thanks to Derek Harland for pointing this out. 4) You can now pass an mxDateTime.DateTime object as a parameter to Cursor.execute(). Thanks to Derek Harland for implementing this feature. - Dave -- http://www.object-craft.com.au

1 0

Roundup issue tracker version 0.2.4
by Richard Jones 03 Aug '01

03 Aug '01

Roundup 0.2.4 - an issue tracking system Changes: See the release notes on the website or the CHANGES.txt distributed with the source. This is another bug-fix and feature-add release. Existing users are encouraged to upgrade as some usability bugs are fixed. The major bugs fixed are the removal of a python 2.1-specific call and cleaner importing of instances (you may now call instances "roundup" and it won't get confused). Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)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.0+ 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 and three database back-ends. Back-ends for relational databases are being developed. Source is available at the website: http://sourceforge.net/projects/roundup/

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Jul 30)
by Cameron Laird 02 Aug '01

02 Aug '01

Quotes of the week: Paul Prescod: Perl users seem remarkably accepting of change considering the installed base of the language. Paul Prescod: Moore's law is slowly making type declarations irrelevant. Stephen: The web just doesn't lend itself to building look-ahead auto-complete fields for names, emails etc. Uwe Zessin releases Python 2.1.1 for OpenVMS http://www.decus.de/~zessin/python2/ Harry George offers example use of setup.py http://groups.google.com/groups?th=18626bc240f7e9e3 June Kim and Dave Brueck present the argument in favor of dynamic typing http://groups.google.com/groups?th=2d17178851b0f98e Thomas Weholt's relatively innocent question about distributed computing technologies leads to deep (if largely Python-free) and even important analyses by Tim Daneliuk, Graham Dumpleton, Galen Swint, and others. Also in the same thread, Ng Pheng Siong provides nice performance boosts for SOAP. http://groups.google.com/groups?th=559ffaccf0ac9907 You can submit a paper for the tenth Python Conference http://www.python10.org/p10-callpapers.html Duncan Grisby provides a fine quick-start tutorial to CORBA use, as well as directions to a public fortune-cookie service http://groups.google.com/groups?th=2244bf713d379f2e Guido launches a lively and important newsgroup thread on the reality of type-class unification (and discloses his own temporal intuition is accurate only to a decimal order-and-a-half of magnitude) http://groups.google.com/groups?th=a8dc15aab8832a6b Front Range Pythoneers energetically dispute the validation theology involved in PyUnit (look for "Doctest" as a subject) http://community.tummy.com/pipermail/frpythoneers/2001-July/thread.html David Mertz teaches that Pippy is a port of Python to PalmOS http://www-106.ibm.com/developerworks/linux/library/l-pippy?open&l=252,t=gr… Now it's called, "Zope Corporation" http://www.zope.com/News/PressReleases/DC2ZC ======================================================================== Everything you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the daily python url http://www.pythonware.com/daily comp.lang.python.announce announces new Python software. Be sure to scan this newly-revitalized newsgroup at least weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Michael Hudson continues Andrew Kuchling's marvelous tradition of summarizing action on the python-dev mailing list once every other week. http://starship.python.net/crew/mwh/summaries/ http://www.amk.ca/python/dev The Vaults of Parnassus ambitiously collect Python resources http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Software Foundation has replaced the Python Consortium as an independent nexus of activity http://www.python.org/psf/ Cetus does much of the same http://www.cetus-links.de/oo_python.html Python FAQTS http://python.faqts.com/ Python To-Do List anticipates some of Python's future direction http://www.python.org/cgi-bin/todo.py Python Journal is at work on its second issue http://www.pythonjournal.com Links2Go is a new semi-automated link collection; it's impressive what AI can generate http://www.links2go.com/search?search=python Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.pyth… Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://purl.org/thecliff/python/url.html or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lan… Suggestions/corrections for next week's posting are always welcome. [http://www.egroups.com/list/python-url-leads/ is hibernating. Just e-mail us ideas directly.] To receive a new issue of this posting in e-mail each Monday morning, ask <claird(a)neosoft.com> to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project.

1 0