Mailman 3 June 2006 - Python-announce-list

Leipzig Python User Group - Meeting, June 13, 2006, 8:00pm
by Mike Müller 09 Jun '06

09 Jun '06

========================= Leipzig Python User Group ========================= Next Meeting Tuesday, June 13, 2006 ----------------------------------- We will meet on June 13 at 8:00 pm at the training center of Python Academy in Leipzig, Germany (http://www.python-academy.com/center/find.html). Stefan Schwarzer will give its presentation for the EuropPython 2006 titled "Speed up your Python code". The talk will be in English. Food and soft drinks are provided. Please send a short confirmation mail to info(a)python-academy.de, so we can prepare appropriately. Everybody who uses Python, plans to do so or is interested in learning more about the language is encouraged to participate. While the meeting language will be mainly German, English speakers are very welcome. We will provide English interpretation if needed. Current information about the meetings can always be found at http://www.python-academy.com/user-group/index.html ========================= Leipzig Python User Group ========================= Stammtisch am 13.06.2006 ------------------------- Wir treffen uns am 13.06.2006 um 20:00 Uhr wieder im im Schulungszentrum der Python Academy in Leipzig (http://www.python-academy.de/Schulungszentrum/anfahrt.html). Stefan Schwarzer wird seinen Vortrag für die EuroPython 2006 Anfang Juli in Genf mit dem Titel "Speed up your Python code" vorstellen. Die Vortragsprache wird diesmal Englisch sein. Wir werden aber in deutsch diskutieren und bei Bedarf Wichtiges auf deutsch wiederholen. Für das leibliche Wohl wird gesorgt. Wir bitten um kurze Anmeldung per e-mail an: info(a)python-academy.de An den Treffen der Python Anwendergruppe kann jeder teilnehmen, der Interesse an Python hat, die Sprache bereits nutzt oder nutzen möchte. Die Arbeitssprachen des Treffens ist Deutsch. Englisch sprechende Python-Enthusiasten sind trotzdem herzlich eingeladen. Wir übersetzen gern. Aktuelle Informationen zu den Treffen sind immer unter http://www.python-academy.de/User-Group/index.html zu finden.

1 0

[ANN] Firedrop 0.2.2
by Fuzzyman 07 Jun '06

07 Jun '06

`Firedrop 2 0.2.2 <http://www.voidspace.org.uk/python/firedrop2/>`_ is now available. You can download it from : `Firedrop-0.2.2.zip <http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=firedrop2-0.2…>`_ This is an important release with several new features, and contributions from new developers joining the team. What is Firedrop2 ? ============== **Firedrop2** is a free, cross-platform blogging tool written in `Python <http://www.python.org>`_. It keeps your blog source files on your computer, making it a *clientside* tool. This means you control your blog, and can easily move it from one server to another, with no risk of losing data. It also means you can manage your blog *offline*. It is fully open source, and has all the features you expect from a modern blogging program : * {acro;RSS;Really Simple Syndication} feed generation * Categories * Automatic archive generation * A powerful set of plugins, including spellchecker, emailer, and themes * Entries can be made in text, {acro;HTML}, {acro;ReST}, textile, sextile or markdown markup * HTML templating system and macros for all sorts of tricks * Built-in {acro;FTP} capability for uploading your blog to a server * Integrated blog comments support (Through Haloscan_) * Because it's written in Python, it is easy to extend Firedrop or create new plugins for it What's New ? ========== This release has a lot of bugfixes and changes. Hopefully I've remembered the important ones. {sm;:-)} * Fixed a bug with categories and the unicode wxPython * Added the Themes plugin by Stewart Midwinter [#]_ * RSS feeds can be generated for all the categories, by Davy Mitchell * Firedrop now saves user data in the users home (checking sensibly for directories where it has write permissions) * Now includes support for the `Haloscan <http://www.haloscan.com/>`_ comments system. * Addition of the Firedrop2 banner by Stewart Midwinter. Plus other code improvements and bug fixes. Their is already work being done on the next release. This will include features like : * Faster build time through entry HTML caching * Blog statistics report generation * Tagging * A Podcast plugin * Extension to the plugin protocol for extra plugin capabilities .. [#] The Themes plugin requires version 0.3.32 of `Wax <http://sourceforge.net/projects/waxgui>`_, or more recent.

1 0

Fredericksburg, VA ZPUG June 14: meld3 templating and memcached sessions
by Gary Poster 07 Jun '06

07 Jun '06

Please join us Wed., June 14, 7:30-9:00 PM, for another meeting of the Fredericksburg, VA Zope and Python User Group ("ZPUG"). We will have two full presentations, and some good snacks. If you plan to attend, an email 24 hours in advance would be appreciated (but last minute attendees are welcome). - Chris McDonough will talk about meld3, a Python HTML/XML templating system in the spirit of PyMeld and other 'push-based' templating systems. (http://www.plope.com/software/meld3) - Tres Seaver will present "Using memcached in Python and Zope", including a demo of using his 'mcdutils' product to do shared session management in Zope. Gary ---------------------------------------- General ZPUG information When: second Wednesday of every month, 7:30-9:00. Where: Zope Corporation offices. 513 Prince Edward Street; Fredericksburg, VA 22408 (tinyurl for map is http://tinyurl.com/duoab). Parking: Zope Corporation parking lot; entrance on Prince Edward Street. Topics: As desired (and offered) by participants, within the constraints of having to do with Python or Zope. Mailing list: fredericksburg-zpug(a)zope.org Contact: Gary Poster (gary(a)zope.com)

1 0

itools 0.13.5 released
by "J. David Ibáñez" 07 Jun '06

07 Jun '06

itools is a Python library, it groups a number of packages into a single meta-package for easier development and deployment: itools.catalog itools.i18n itools.uri itools.cms itools.ical itools.web itools.csv itools.resources itools.workflow itools.datatypes itools.rss itools.xhtml itools.gettext itools.schemas itools.xliff itools.handlers itools.stl itools.xml itools.html itools.tmx Changes: Handlers - Lazy load for binary files and images, by Hervé Cauwelier [#98]. - Fixes for archive handlers (ZIP, TAR), by Hervé Cauwelier [#127]. CSV - Fix serialization, escape double quotes. - Now the method "get_rows" always returns a copy of the rows, by Nicolas Deram. CMS Minor features and important fixes: - Fix database sync. - Fix remove when there are virtual handlers. - Improved "browse image" view, by Hervé Cauwelier [#328]. Minor fixes and other changes: - More robust Enumerate class, by Hervé Cauwelier [#304]. - Use CSS classes instead of ids to define the Epoz style, by Hervé Cauwelier [#317]. - Fix edit user's account, password is optional, by Hervé Cauwelier [#321]. - Fix the title of HTML pages when in a subsite, by Hervé Cauwelier [#322]. - Add "del_property" to the handler's API, by Hervé Cauwelier [#327]. - Complete Enumerate's API with "get_value(name)" method, by Hervé Cauwelier [#329]. Resources --------- Download http://download.ikaaro.org/itools/itools-0.13.5.tar.gz Home http://www.ikaaro.org/itools Mailing list http://mail.ikaaro.org/mailman/listinfo/itools Bug Tracker http://bugs.ikaaro.org -- J. David Ibáñez Itaapy <http://www.itaapy.com> Tel +33 (0)1 42 23 67 45 9 rue Darwin, 75018 Paris Fax +33 (0)1 53 28 27 88

1 0

Post-EuroPython sprint (6-9th July)
by hpk＠trillke.net 07 Jun '06

07 Jun '06

Geneva/CERN Post-EuroPython PyPy sprint 6-9th July ==================================================== The next PyPy sprint will be held at CERN/Geneva right after the EuroPython conference. We specifically invite newcomers and people interested to get to know and get into PyPy development. We are going to work on a variety of topics and will give introductions to various aspects of PyPy (on the 6th morning). Some foreseen focus will be on the following topics: * The extension module compiler. Using it for implementing extension modules both for PyPy and CPython from the same source code. (for example if you have a Need for Speed :) * work and experiment with our to-be-relased 0.9 stackless features * work on high level backends: .NET, Javascript etc. * optimization of core Python data types, making full use of PyPy's flexible architecture and python-implemented (and then translated) type system. * You may even dare to dive into ongoing work on the JIT compiler * experimenting with novel security systems for Python, enabled by PyPy * and so on :) Registration ---------------------- If you'd like to come, please subscribe to the `pypy-sprint mailing list`_ and drop a note about your interests and post any questions. More organisational information will be send to that list. We'll keep a list of `people`_ which we'll update (which you can do so yourself if you have codespeak commit rights). Special note to Students! ---------------------------- As you might know, there are three students in Google's Summer of Code program who are working on projects related to PyPy. In addition we are planning our own "Summer of PyPy": we can cover the expenses of attending some of our sprints and provide mentorship. In this vein, if you have an interesting idea for a project relating to PyPy you should send us ("pypy-tb(a)codespeak.net") a proposal. We will consider it get back to you on whether we can fund your travel and accomodation. We expect to able to fund between 4 and 6 students in this way. As we still need to figure out budget/money issues, for now we can only promise for now that we can fund this Post-EP2006 sprint for such students. But don't hesitate to come to our irc channel, ask around and produce proposals! .. _`pypy-sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`people`: people.html

1 0

EP2006 timetable + reduced registration
by Michael Hudson 07 Jun '06

07 Jun '06

Hi Pythonistas! EuroPython 2006 is nearing and there is much good news! We have a very nice program of over 100 interesting talks (sorry that we had to reject some), see here for yourself: http://www.europython.org/timetable Also we have slots for 50 lightning (5 minute) talks so be sure to prepare one and register at the conference. We have also secured Alan Kay (the inventor of OO languages, Smalltalk, opencroquet.org etc.) as a key note speaker and are happy that Guido van Rossum will make it again! But best of all, the voluntary organisers have decided to give you another chance to register for a reduced fee -- but only until this weekend, so hurry and register: http://www.europython.org/sections/registration_issues If you have questions then mail to europython(a)python.org or come to #europython on irc.freenode.net. See you there, or in fact here: http://www.europython.org/venue.jpg Cheers, mwh & holger (on behalf of the EuroPython organizers) -- ZAPHOD: OK, so ten out of ten for style, but minus several million for good thinking, eh? -- The Hitch-Hikers Guide to the Galaxy, Episode 2

1 0

IPython 0.7.2 is out.
by Fernando Perez 07 Jun '06

07 Jun '06

Hi all, The IPython team is happy to release version 0.7.2, with a lot of new enhancements, as well as many bug fixes. We hope you all enjoy it, and please report any problems as usual. WHAT is IPython? ---------------- 1. An interactive shell superior to Python's default. IPython has many features for object introspection, system shell access, and its own special command system for adding functionality when working interactively. 2. An embeddable, ready to use interpreter for your own programs. IPython can be started with a single call from inside another program, providing access to the current namespace. 3. A flexible framework which can be used as the base environment for other systems with Python as the underlying language. 4. A shell for interactive usage of threaded graphical toolkits. IPython has support for interactive, non-blocking control of GTK, Qt and WX applications via special threading flags. The normal Python shell can only do this for Tkinter applications. Where to get it --------------- IPython's homepage is at: http://ipython.scipy.org and downloads are at: http://ipython.scipy.org/dist We've provided: - Source download (.tar.gz) - An RPM (for Python 2.4, built under Ubuntu Dapper 6.06). - A Python Egg (http://peak.telecommunity.com/DevCenter/PythonEggs). - A native win32 installer. The egg is 'light', as it doesn't include documentation and other ancillary data. If you want a full ipython installation, use the source tarball or your distribution's favorite system. We note that IPython is now officially part of most major Linux and BSD distributions, so packages for this version should be coming soon, as the respective maintainers have the time to follow their packaging procedures. Many thanks to Jack Moffit, Norbert Tretkowski, Andrea Riciputi, Dryice Liu and Will Maier for the packaging work, which helps users get IPython more conveniently. Many thanks to Enthought for their continued hosting support for IPython. Release notes ------------- As always, the full ChangeLog is at http://ipython.scipy.org/ChangeLog. The highlights of this release follow. Also see the "What's New" page at http://projects.scipy.org/ipython/ipython/wiki/WhatsNew for more details on some of these features. * Walter Doerwald's ipipe module, which provides a handy way to browse and manipulate tabular data, e.g. groups of files or environment variables (this is currently mostly a *nix feature, due to its need for ncurses). Walter is now a member of the IPython team. * The IPython project is the new home for the UNC readline extension, which allows win32 users to access readline facilities (tab completion, colored prompts, and more). UNC readline has been renamed PyReadline, and has a number of important new features, especially for users of non-US keyboards. See this page for more details: http://projects.scipy.org/ipython/ipython/wiki/PyReadline/Intro * A new extension and configuration API. * Hardened persistence. Persistence of data now uses "pickleshare", a shelve-like module that allows concurrent access to the central ipython database by multiple ipython instances. * Simpler output capture: "files=!ls" will now capture the 'ls' call into the 'files' variable. * New magic functions: %timeit, %upgrade, %quickref, %cpaste, %clip, %clear. Also, a 'raw' mode has been added to %edit, %macro, %history. * Batch files. If the file ends with .ipy, you can launch it by "ipython myfile.ipy". It will be executed as if it had been typed interactively (it can contain magics, aliases, etc.) * New pexpect-based 'irunner' module, to run scripts and produce all the prompts as if they had been typed one by one. This lets you reproduce a complete interactive session from a file, which can be very useful when producing documentation, for example. The module provides default runners for ipython, plain python and SAGE (http://sage.scipy.org). Users can subclass the base runner to produce new ones for any interactive system whose prompts are predictable (such as gnuplot, a system shell, etc.). * New option to log 'raw' input into IPython's logs. The logs will then be valid .ipy batch scripts just as you typed them, instead of containing the converted python source. * Fixes and improvements to (X)Emacs support. PDB auto-tracking is back (it had broken in 0.7.1, and auto-indent now works inside emacs ipython buffers. You will need to update your copy of ipython.el, which you can get from the doc/ directory. A copy is here, for convenience: http://ipython.scipy.org/dist/ipython.el * The ipapi system offers a new to_user_ns() method in the IPython object, to inject variables from a running script directly into the user's namespace. This lets you have internal variables from a script visible interactively for further manipulation after %running it. * Thanks to Will Maier, IPython is now officially part of OpenBSD ports. * A number of threading deadlock fixes. This is of particular interest to matplotlib users. * Compatibility updates with current Gnuplot.py. * We now are (finally! * Various other small fixes and enhancements. See the full ChangeLog for details. Enjoy, and as usual please report any problems. The IPython team.

1 0

python-dev Summary for 2006-04-01 through 2006-04-15
by Steven Bethard 07 Jun '06

07 Jun '06

python-dev Summary for 2006-04-01 through 2006-04-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-04-01_2006-04-15] ============= Announcements ============= --------------------- Python 2.5a1 Released --------------------- Python 2.5 alpha 1 was released on April 5th. Please download it and try it out, particularly if you are an extension writer or you embed Python -- you may want to change things to support 64-bit sequences, and if you have been using mismatched PyMem_* and PyObject_* allocation calls, you will need to fix these as well. Contributing threads: - `TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April. <http://mail.python.org/pipermail/python-dev/2006-April/063324.html>`__ - `outstanding items for 2.5 <http://mail.python.org/pipermail/python-dev/2006-April/063328.html>`__ - `chilling svn for 2.5a1 <http://mail.python.org/pipermail/python-dev/2006-April/063403.html>`__ - `Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April. <http://mail.python.org/pipermail/python-dev/2006-April/063426.html>`__ - `RELEASED Python 2.5 (alpha 1) <http://mail.python.org/pipermail/python-dev/2006-April/063441.html>`__ - `TRUNK is UNFROZEN <http://mail.python.org/pipermail/python-dev/2006-April/063443.html>`__ - `segfault (double free?) when '''-string crosses line <http://mail.python.org/pipermail/python-dev/2006-April/063572.html>`__ - `pdb segfaults in 2.5 trunk? <http://mail.python.org/pipermail/python-dev/2006-April/063591.html>`__ - `IMPORTANT 2.5 API changes for C Extension Modules and Embedders <http://mail.python.org/pipermail/python-dev/2006-April/063637.html>`__ ---------------------- Contributor agreements ---------------------- If you're listed in the `Python acknowledgments`_, and you haven't signed a `contributor agreement`_, please submit one as soon as possible. Note that this includes even the folks that have been around forever -- the PSF would like to be as careful as possible on this one. .. _Python acknowledgments: http://svn.python.org/projects/python/trunk/Misc/ACKS .. _contributor agreement: http://www.python.org/psf/contrib-form-python.html Contributing threads: - `PSF Contributor Agreement for pysqlite <http://mail.python.org/pipermail/python-dev/2006-April/063578.html>`__ --------------------------- Firefox Python bug searches --------------------------- Anthony Baxter has created a `Firefox searchbar`_ for finding Python bugs by their SourceForge IDs. There are also two Firefox sidebar options: `Mark Hammond's`_ and `Daniel Lundin's`_. .. _Firefox searchbar: http://www.python.org/~anthony/searchbar/ .. _Mark Hammond's: http://starship.python.net/~skippy/mozilla/ .. _Daniel Lundin's: http://projects.edgewall.com/python-sidebar/ Contributing thread: - `Firefox searchbar engine for Python bugs <http://mail.python.org/pipermail/python-dev/2006-April/063285.html>`__ ------------------------------------------------- Building Python with the free MS Toolkit compiler ------------------------------------------------- Paul Moore documented how to build Python on Windows with the free MS Toolkit C++ compiler `on the wiki`_. The most up-to-date version of these instructions is in `PCbuild/readme.txt`_. .. _on the wiki: http://wiki.python.org/moin/Building_Python_with_the_free_MS_C_Toolkit .. _PCbuild/readme.txt: http://svn.python.org/projects/python/trunk/PCbuild/readme.txt Contributing thread: - `Building Python with the free MS Toolkit compiler <http://mail.python.org/pipermail/python-dev/2006-April/063719.html>`__ ---------------------------------------------- Please login to the wiki when you make changes ---------------------------------------------- Skip Montanaro has requested that anyone posting to the wiki sign in first, as this makes things easier for those monitoring changes to the wiki. When you're logged in, your changes appear with your name, and so can be immediately recognized as not being wiki-spam. Contributing thread: - `Suggestion: Please login to wiki when you make changes <http://mail.python.org/pipermail/python-dev/2006-April/063447.html>`__ --------------------------- Checking an older blamelist --------------------------- While the buildbot blamelist may scroll off the `main page`_ in a matter of hours, you can still see the blamelist for a particular revision by checking a particular build number, e.g. to see build 800 of the trunk on the G4 OSX, you could check http://www.python.org/dev/buildbot/trunk/g4%20osx.4%20trunk/builds/800. .. _main page: http://www.python.org/dev/buildbot/all/ Contributing threads: - `Preserving the blamelist <http://mail.python.org/pipermail/python-dev/2006-April/063633.html>`__ - `TODO Wiki (was: Preserving the blamelist) <http://mail.python.org/pipermail/python-dev/2006-April/063673.html>`__ ========= Summaries ========= ------------------------- Garbage collection issues ------------------------- One of the problems with garbage-collecting generators (now that they have a __del__ method) was that GC normally assumes that because the *type* has a __del__ method, the *instance* needs finalization. Many generator instances may not need finalization even though their type has a __del__ slot, so generators have been special-cased in the garbage-collection code so that GC can sometimes tell that a generator does not need its finalizer called. As a side note, Tim Peters pointed out that if you're worried about cyclic-gc and __del__ methods, one of the ways to avoid problems is to remove the __del__ method from the object you think might be included in a cycle, and add an attribute to that object that holds a "closing" object with a __del__ method that simply closes all your resources. Since your main object won't have a __del__, it will be easily collected, which should make the closing object collectable too. Contributing threads: - `reference leaks, __del__, and annotations <http://mail.python.org/pipermail/python-dev/2006-March/063213.html>`__ - `reference leaks, __del__, and annotations <http://mail.python.org/pipermail/python-dev/2006-April/063257.html>`__ - `Debugging opportunity :-) <http://mail.python.org/pipermail/python-dev/2006-April/063746.html>`__ ------------------ ElementTree naming ------------------ The elementtree package was included in Python 2.5 as xml.etree. There were some complaints about the naming schemes (which aren't quite `PEP 8`_-compliant) but changing these while elementtree is still distributed as a standalone package seemed like a bad idea. People generally felt that style-motivated renamings should all wait until Python 3000. .. _PEP 8: http://www.python.org/dev/peps/pep-0008/ Contributing thread: - `elementtree in stdlib <http://mail.python.org/pipermail/python-dev/2006-April/063477.html>`__ ----------------------------- Externally maintained modules ----------------------------- Brett Cannon was putting together a PEP for externally maintained code in the stdlib (e.g. ctypes and pysqlite). The PEP will list all modules and packages within the stdlib that are maintained externally, as well as the contact info for their maintainers and the locations where bugs and patches should be reported. At the time of this summary, he had not yet been assigned a PEP number. Contributing threads: - `PEP to list externally maintained modules and where to report bugs? <http://mail.python.org/pipermail/python-dev/2006-April/063279.html>`__ - `need info for externally maintained modules PEP <http://mail.python.org/pipermail/python-dev/2006-April/063549.html>`__ -------------------------------------- String prefix for internationalization -------------------------------------- Martin Blais proposed an ``i`` prefix for internationalized strings to get rid of the ``_()`` required by pygettext. This would allow pygettext to more easily identify internationalized strings, and reduce the number of parentheses necessary in internationalized code. However, it would only have saved two key-strokes, it would have required the introduction of ``iu`` and ``ir`` prefixes, and it would have forced some rewriting of the tools that currently do string extraction using ``_()``, so the idea was rejected. Contributing thread: - `The "i" string-prefix: I18n'ed strings <http://mail.python.org/pipermail/python-dev/2006-April/063488.html>`__ --------------------------- PEP 359: The make statement --------------------------- Steven Bethard introduced a PEP for the make statement which would have made the statement:: make <callable> <name> <tuple>: <block> syntactic sugar for:: class <name> <tuple>: __metaclass__ = <callable> <block> The goal was to allow the creation of non-class objects from a namespace without requiring a misleading ``class`` statement and ``__metaclass__`` hook. With appropriately defined objects, the make statement would have supported syntax like:: make block_property x: '''The x of the frobulation''' def fget(self): ... def fset(self): ... make Schema registration: make String name: max_length = 100 not_empty = True make PostalCode postal_code: not_empty = True make Int age: min = 18 In current Python these would have to be created using class statements which misleadingly created objects that were not classes. Responses were mixed, and the discussion continued on into the next fortnight. .. _PEP 359: http://www.python.org/dev/peps/pep-0359/ Contributing thread: - `PEP 359: The "make" Statement <http://mail.python.org/pipermail/python-dev/2006-April/063694.html>`__ --------------------------------------------- Formatting exceptions with their module names --------------------------------------------- Georg Brandl checked in a patch to make traceback.format_exception_only() prepend the exception's module name in the same way the interpreter does. This caused a number of doctests to fail because the exception module names were not included. After some discussion, it seemed like people agreed that even though some doctests would be broken, it was more important to have the interpreter and traceback.format_exception_only() produce the same output. Contributing thread: - `[Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS <http://mail.python.org/pipermail/python-dev/2006-April/063662.html>`__ ------------------- Benchmarking python ------------------- Benji York and a few others ran Python 2.5a1 through pystone and found it mostly comparable to 2.4.2. However, Raymond Hettinger pointed out that pystone isn't really an appropriate benchmark for comparing across versions -- it's intended more for comparing across architectures and compilers. Contributing threads: - `2.5a1 Performance <http://mail.python.org/pipermail/python-dev/2006-April/063450.html>`__ - `Buildbot slave locks (Was: 2.5a1 Performance) <http://mail.python.org/pipermail/python-dev/2006-April/063481.html>`__ ------------------------------------------------------ PySocketSockObject, socketmodule.c, _ssl.c and Windows ------------------------------------------------------ Tim Peters noticed that on Windows, socketmodule.c and _ssl.c disagreed about the offset of the ``sock_timeout`` member of a ``PySocketSockObject``. Turns out that since _socket was built by a .vcproj but _ssl was built by _ssl.mak (which had forgotten to define WIN32), doubles were aligned to an 8-byte boundary when socketmodule.c was compiled but a 4-byte boundary when _ssl was compiled. Contributing thread: - `Who understands _ssl.c on Windows? <http://mail.python.org/pipermail/python-dev/2006-April/063543.html>`__ ------------------------------ Getting a dictionary of counts ------------------------------ Alex Martelli proposed adding a ``tally()`` function to the collections module which would count the number of each value in an iterable and produce a dictionary. So for example:: tally('abacaab') == {'a': 4, 'c': 1, 'b': 2} People generally thought the function would be useful, but there was some discussion as to whether or not it would be better to provide a collections.bag object instead. The discussion fizzled out without any patches being produced. Contributing thread: - `tally (and other accumulators) <http://mail.python.org/pipermail/python-dev/2006-April/063382.html>`__ ------------------------ Building Python with C++ ------------------------ Anthony Baxter has donated some of his recent time to getting Python to compile with g++. He got Python core to compile correctly, but there were lots of errors in the Modules code that wasn't C++ safe. If you'd like to help Anthony out and fix some bugs, try it yourself using ``CC=g++ ./configure --with-cxx=g++`` Contributing thread: - `building with C++ <http://mail.python.org/pipermail/python-dev/2006-April/063632.html>`__ ---------------------- Adding PEP 302 support ---------------------- Phillip J. Eby has been working on adding `PEP 302`_ import loader support to the necessary modules around Python. In the process, he noticed that both runpy and test.test_importhooks reimplement the base `PEP 302`_ algorithm, and suggested adding functions to pkgutil that would allow such modules to all share the same code for this kind of thing. The code appears to have been checked in, but docs do not appear to be available yet. .. _PEP 302: http://www.python.org/dev/peps/pep-0359/ Contributing threads: - `PEP 302 support for traceback, inspect, site, warnings, doctest, and linecache <http://mail.python.org/pipermail/python-dev/2006-April/063586.html>`__ - `Proposal: expose PEP 302 facilities via 'imp' and 'pkgutil' <http://mail.python.org/pipermail/python-dev/2006-April/063623.html>`__ - `PEP 302 support for pydoc, runpy, etc. <http://mail.python.org/pipermail/python-dev/2006-April/063724.html>`__ ----------------------------------------- Having Python use dlopen() on Darwin/OS X ----------------------------------------- Zachary Pincus asked about using the normal code path for Unix-like systems through dlopen() for Darwin/OS X instead of the officially discouraged NeXT-derived APIs that Python was using at the time. Bob Ippolito approved the patch, and OS X users should hopefully see the change in Python 2.5. Contributing thread: - `Use dlopen() on Darwin/OS X to load extensions? <http://mail.python.org/pipermail/python-dev/2006-April/063336.html>`__ ------------------------------- Saving the hash value of tuples ------------------------------- Noam Raphael suggested `caching the hash value of tuples`_ in a similar way to what is done for strings now. But without any measurements showing that this improved performance, and with the relative rareness of hashing tuples, Guido thought that this was a bad idea. .. _caching the hash value of tuples: http://bugs.python.org/1462796 Contributing thread: - `Saving the hash value of tuples <http://mail.python.org/pipermail/python-dev/2006-April/063275.html>`__ ------------------ sqlite3.dll issues ------------------ If a Windows user tries ``import sqlite3`` and Python finds SQLite's sqlite3.dll before it finds pysqlite's sqlite.py module, Python will end up incorrectly raising an ImportError. Martin v. Löwis suggested that maybe Python should stop treating .dll files as extension modules so conflicts like this could be avoided. It was unclear at the end of the thread if this (or any other) route was being persued. Contributing thread: - `Renaming sqlite3 <http://mail.python.org/pipermail/python-dev/2006-April/063327.html>`__ ---------------- New Python icons ---------------- Andrew Clover made some `new Python icons`_ available based on the logo on the new website. People on python-dev really liked them, and it looked like they'd probably make it into Python 2.5. .. _new Python icons: http://doxdesk.com/img/software/py/icons2.png Contributing threads: - `New-style icons, .desktop file <http://mail.python.org/pipermail/python-dev/2006-March/063235.html>`__ - `New-style icons, .desktop file <http://mail.python.org/pipermail/python-dev/2006-April/063517.html>`__ ---------------------------------------- Py_Initialize/Py_Finalize leaking memory ---------------------------------------- Martin v. Löwis corrected some documentation errors that claimed that Py_Finalize would release all memory (it can't be guaranteed to do so). In the process, Martin and Tim Peters discussed a `recent bug`_ where running Py_Initialize/Py_Finalize in a loop left more and more objects behind each time. The hope was to get the number of added objects after a Py_Initialize/Py_Finalize pair back down to zero if possible, and Martin found at least one leak, but it was unclear at the end of the thread how close they had gotten. .. _recent bug: http://bugs.python.org/1445210 Contributing thread: - `Py_Finalize does not release all memory, not even closely <http://mail.python.org/pipermail/python-dev/2006-April/063618.html>`__ ---------------------- Removing PyObject_REPR ---------------------- Thomas Wouters noticed that the ``PyObject_REPR()`` macro, which was originally introduced as an internal debugging API, leaks a PyString object. It looked like the macro would either be removed entirely, or redefined to call Py_DECREF appropriately and return a newly allocated (and thus freeable) string. Contributing thread: - `PyObject_REPR() <http://mail.python.org/pipermail/python-dev/2006-April/063628.html>`__ ------------------------------------------ uriparse module to replace urlparse module ------------------------------------------ Paul Jimenez offered up his `uriparse module`_ which improves on urlparse. Currently, urlparse doesn't comply with STD66 (a.k.a. RFC3986), as it hard-codes some URI schemes instead of applying the same syntax to all of them. Martin v. Löwis asked for more documentation, and John J Lee suggested deprecating a few functions from urllib and putting RFC-compliant versions in uriparse. The discussion then moved to the tracker, but at the time of this summary, the remaining issues had not yet been resolved. .. _uriparse module: http://bugs.python.org/1462525 Contributing thread: - `New uriparse.py <http://mail.python.org/pipermail/python-dev/2006-April/063294.html>`__ -------------------------------------- Line numbers with the new AST compiler -------------------------------------- Jeremy Hylton noticed that with the new AST-based compiler, the line numbers for things like the implicit ``return None`` at the end of a function were occasionally different from previous versions of Python. The changes looked harmless, so Guido said it was fine to leave the code as it was. Jeremy promised to look into some of the other special cases for alpha 2. Contributing thread: - `line numbers, pass statements, implicit returns <http://mail.python.org/pipermail/python-dev/2006-April/063272.html>`__ ================ Deferred Threads ================ - `PY_FORMAT_SIZE_T warnings on OS X <http://mail.python.org/pipermail/python-dev/2006-April/063280.html>`__ ================== Previous Summaries ================== - `Class decorators <http://mail.python.org/pipermail/python-dev/2006-April/063253.html>`__ - `I'm not getting email from SF when assigned a bug/patch <http://mail.python.org/pipermail/python-dev/2006-April/063255.html>`__ - `improving quality <http://mail.python.org/pipermail/python-dev/2006-April/063269.html>`__ =============== Skipped Threads =============== - `gmane.comp.python.devel.3000 has disappeared <http://mail.python.org/pipermail/python-dev/2006-April/063256.html>`__ - `refleaks in 2.4 <http://mail.python.org/pipermail/python-dev/2006-April/063268.html>`__ - `Name for python package repository <http://mail.python.org/pipermail/python-dev/2006-April/063271.html>`__ - `[Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py <http://mail.python.org/pipermail/python-dev/2006-April/063278.html>`__ - `Bug Day on Friday, 31st of March <http://mail.python.org/pipermail/python-dev/2006-April/063298.html>`__ - `String formating in python 3000 <http://mail.python.org/pipermail/python-dev/2006-April/063305.html>`__ - `SF #1462485 - StopIteration raised in body of 'with' statement suppressed <http://mail.python.org/pipermail/python-dev/2006-April/063312.html>`__ - `SF #1462700 - Errors in PCbuild <http://mail.python.org/pipermail/python-dev/2006-April/063313.html>`__ - `Whole bunch of test failures on OSX <http://mail.python.org/pipermail/python-dev/2006-April/063318.html>`__ - `SF:1463370 add .format() method to str and unicode <http://mail.python.org/pipermail/python-dev/2006-April/063329.html>`__ - `Need Py3k group in trackers <http://mail.python.org/pipermail/python-dev/2006-April/063344.html>`__ - `posixmodule.c patch- revision 43586 <http://mail.python.org/pipermail/python-dev/2006-April/063349.html>`__ - `Twisted and Python 2.5a0r43587 <http://mail.python.org/pipermail/python-dev/2006-April/063370.html>`__ - `r43613 - python/trunk/Doc/lib/libcsv.tex <http://mail.python.org/pipermail/python-dev/2006-April/063386.html>`__ - `current 2.5 status <http://mail.python.org/pipermail/python-dev/2006-April/063411.html>`__ - `Should issubclass() be more like isinstance()? <http://mail.python.org/pipermail/python-dev/2006-April/063422.html>`__ - `The "Need for Speed" Sprint, Reykjavik, Iceland, May 21-28, 2006 <http://mail.python.org/pipermail/python-dev/2006-April/063428.html>`__ - `suggest: nowait option in subprocess.communicate <http://mail.python.org/pipermail/python-dev/2006-April/063445.html>`__ - `strftime/strptime locale funnies... <http://mail.python.org/pipermail/python-dev/2006-April/063448.html>`__ - `PY_SSIZE_T_MIN? <http://mail.python.org/pipermail/python-dev/2006-April/063449.html>`__ - `How to determine if char is signed or unsigned? <http://mail.python.org/pipermail/python-dev/2006-April/063456.html>`__ - `Possible issue with 2.5a1 Win32 binary <http://mail.python.org/pipermail/python-dev/2006-April/063469.html>`__ - `Don Beaudry <http://mail.python.org/pipermail/python-dev/2006-April/063485.html>`__ - `Default Locale, was; Re: strftime/strptime locale funnies... <http://mail.python.org/pipermail/python-dev/2006-April/063487.html>`__ - `dis module and new-style classes <http://mail.python.org/pipermail/python-dev/2006-April/063489.html>`__ - `module aliasing <http://mail.python.org/pipermail/python-dev/2006-April/063491.html>`__ - `str.partition? <http://mail.python.org/pipermail/python-dev/2006-April/063499.html>`__ - `subprocess maintenance - SVN write access <http://mail.python.org/pipermail/python-dev/2006-April/063502.html>`__ - `[IronPython] base64 module <http://mail.python.org/pipermail/python-dev/2006-April/063503.html>`__ - `base64 module <http://mail.python.org/pipermail/python-dev/2006-April/063504.html>`__ - `packaging/bootstrap issue <http://mail.python.org/pipermail/python-dev/2006-April/063511.html>`__ - `Patch or feature? Tix.Grid working for 2.5 <http://mail.python.org/pipermail/python-dev/2006-April/063532.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-April/063542.html>`__ - `Subversion downtime today <http://mail.python.org/pipermail/python-dev/2006-April/063557.html>`__ - `Win64 AMD64 (aka x64) binaries available64 <http://mail.python.org/pipermail/python-dev/2006-April/063558.html>`__ - `int()'s ValueError behaviour <http://mail.python.org/pipermail/python-dev/2006-April/063559.html>`__ - `threadless brownian.py <http://mail.python.org/pipermail/python-dev/2006-April/063563.html>`__ - `Subversion repository back up <http://mail.python.org/pipermail/python-dev/2006-April/063565.html>`__ - `DRAFT: python-dev summary for 2006-02-01 to 2006-02-15 <http://mail.python.org/pipermail/python-dev/2006-April/063588.html>`__ - `Failing "inspect" test: test_getargspec_sublistofone <http://mail.python.org/pipermail/python-dev/2006-April/063589.html>`__ - `updating PyExpat (Was: need info for externally maintained modules PEP) <http://mail.python.org/pipermail/python-dev/2006-April/063600.html>`__ - `DRAFT: python-dev summary for 2006-02-16 to 2006-02-28 <http://mail.python.org/pipermail/python-dev/2006-April/063605.html>`__ - `DRAFT: python-dev summary for 2006-03-01 to 2006-03-15 <http://mail.python.org/pipermail/python-dev/2006-April/063611.html>`__ - `Checking assigned bugs/patches <http://mail.python.org/pipermail/python-dev/2006-April/063640.html>`__ - `String initialization (was: The "i" string-prefix: I18n'ed strings) <http://mail.python.org/pipermail/python-dev/2006-April/063644.html>`__ - `Request for review <http://mail.python.org/pipermail/python-dev/2006-April/063652.html>`__ - `cleanup list <http://mail.python.org/pipermail/python-dev/2006-April/063655.html>`__ - `unicode vs buffer (array) design issue can crash interpreter <http://mail.python.org/pipermail/python-dev/2006-April/063675.html>`__ - `int vs ssize_t in unicode <http://mail.python.org/pipermail/python-dev/2006-April/063676.html>`__ - `Any reason that any()/all() do not take a predicate argument? <http://mail.python.org/pipermail/python-dev/2006-April/063680.html>`__ - `Any reason that any()/all() do not take a predicateargument? <http://mail.python.org/pipermail/python-dev/2006-April/063688.html>`__ - `Exceptions doctest Re: Request for review <http://mail.python.org/pipermail/python-dev/2006-April/063689.html>`__ - `Is test_sundry really expected to succeed on Windows? <http://mail.python.org/pipermail/python-dev/2006-April/063690.html>`__ - `Checkin 45232: Patch #1429775 <http://mail.python.org/pipermail/python-dev/2006-April/063701.html>`__ - `[Python-checkins] r45334 - python/trunk/Lib/test/leakers/test_gen1.py python/trunk/Lib/test/leakers/test_generator_cycle.py python/trunk/Lib/test/leakers/test_tee.py <http://mail.python.org/pipermail/python-dev/2006-April/063702.html>`__ - `ia64 debian buildbot <http://mail.python.org/pipermail/python-dev/2006-April/063704.html>`__ - `[Python-3000] Removing 'self' from method definitions <http://mail.python.org/pipermail/python-dev/2006-April/063709.html>`__ - `Procedure for sandbox branches in SVN? <http://mail.python.org/pipermail/python-dev/2006-April/063725.html>`__ - `Calling Thomas Heller and Richard Jones <http://mail.python.org/pipermail/python-dev/2006-April/063729.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from April 01, 2006 through April 15, 2006. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This python-dev summary is the 2nd written by the python-dev summary master, Steve Bethard (You want 'em faster, you write em! ;-) ). To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- That this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _original text file: http://www.python.org/dev/summary/2006-04-01_2006-04-15.rst .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

python-dev Summary for 2006-03-16 through 2006-03-31
by Steven Bethard 07 Jun '06

07 Jun '06

python-dev Summary for 2006-03-16 through 2006-03-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-03-16_2006-03-31] ============= Announcements ============= ------------------- Python 2.5 schedule ------------------- Python 2.5 is moving forward along its release schedule. A few issues still remain; check `PEP 356`_ for details. .. _PEP 356: http://www.python.org/dev/peps/pep-0356/ Contributing thread: - `Python 2.5 Schedule <http://mail.python.org/pipermail/python-dev/2006-March/062560.html>`__ ----------------------------- Python 3000 gets its own list ----------------------------- Serious work on Python 3000 has started now, with a new `python-3000 mailing list`_ for general discussion, and a `python-3000-checkins mailing list`_ for checkins to the p3yk branch. Right now, Guido wants patches to focus mainly on ripping out old code (e.g. classic classes) and wants the discussion to focus primarily on formalizing the processes for introducing Python 3000. Note that processes is what's important right now .. _python-3000 mailing list: http://mail.python.org/mailman/listinfo/python-3000 .. _python-3000-checkins mailing list: http://mail.python.org/mailman/listinfo/python-3000-checkins Contributing threads: - `Python 3000 Process <http://mail.python.org/pipermail/python-dev/2006-March/062644.html>`__ - `svn checkins are now split <http://mail.python.org/pipermail/python-dev/2006-March/062734.html>`__ - `Discussing the Great Library Reorganization <http://mail.python.org/pipermail/python-dev/2006-March/063052.html>`__ ----------------------------------------------- Buildbot warnings redirected to python-checkins ----------------------------------------------- The buildbot warnings, which for a short time this month appeared on python-dev, have been redirected to the python-checkins list. Contributing thread: - `[Fwd: buildbot warnings in amd64 gentoo trunk] <http://mail.python.org/pipermail/python-dev/2006-March/062754.html>`__ ---------------------------------------------------------- Checkins that change behavior must be accompanied by tests ---------------------------------------------------------- Though it's always been good practice to check in a test with any behavior-changing patch, Neal Norwitz has requested extra care in this area as we approach the release of Python 2.5. From this point on, *any* checkin that could change behavior should be accompanied by a corresponding test. Contributing thread: - `improving quality <http://mail.python.org/pipermail/python-dev/2006-March/062904.html>`__ -------------------------------------- Email 4.0 merged into Python 2.5 trunk -------------------------------------- Barry Warsaw has merged the Email 4.0 package into the Python 2.5 trunk. There's a minor incompatibility in that email.Parser is now a placeholder object instead of a module, but this should not affect the vast majority of users. Contributing thread: - `Merging email 4.0 to Python 2.5 svn trunk <http://mail.python.org/pipermail/python-dev/2006-March/062512.html>`__ --------------------- Python 2.4.3 released --------------------- `Python 2.4.3`_ was released on March 30th. This fixes over 50 bugs in Python 2.4.2, so now's the time to upgrade. .. _Python 2.4.3: http://www.python.org/2.4.3/ Contributing threads: - `release24-maint FREEZE for 2.4.3c1, this Thursday <http://mail.python.org/pipermail/python-dev/2006-March/062655.html>`__ - `RELEASED Python 2.4.3, release candidate 1 <http://mail.python.org/pipermail/python-dev/2006-March/062772.html>`__ - `release24-maint unfrozen, kinda <http://mail.python.org/pipermail/python-dev/2006-March/062774.html>`__ - `BRANCH release24-maint FREEZE from 00:00 UTC on Wednesday 29th <http://mail.python.org/pipermail/python-dev/2006-March/062852.html>`__ - `RELEASED Python 2.4.3, final. <http://mail.python.org/pipermail/python-dev/2006-March/063060.html>`__ ========= Summaries ========= -------------------------------- Including pysqlite in the stdlib -------------------------------- Anthony Baxter asked if folks were still interested in including pysqlite_ in Python 2.5 and got a pretty positive response. Gerhard HÃ¤ring said he could release pysqlite 2.2 and then merge that into Python SVN trunk. In the future, he agreed to synchronize stable changes in the standalone release with the Python core sqlite module. Accompanying these agreements was a long discussion about the pros and cons of including pysqlite, and of course an endless debate about what the new module should be named. In the end, Guido approved the inclusion of pysqlite, and it was given the name sqlite3. .. _pysqlite: http://initd.org/tracker/pysqlite/ Contributing thread: - `pysqlite for 2.5? <http://mail.python.org/pipermail/python-dev/2006-March/062905.html>`__ ----------------------------- Choosing a new tracker system ----------------------------- After Guido noticed that SourceForge had stopped sending him emails when a patch was assigned to him, a number of people took up a discussion about how to replace the SourceForge tracker system. There was already an existing PSF committee in charge of finding such a replacement, and they were considering roundup_, trac_ and jira_, though Bugzilla_ and RT_ had already been vetoed. There was already an instance of roundup running on python.org, and Python-Hosting and Atlassian had existing offers to host Python on Trac and Jira (respectively). There was some discussion about setting up one of these for Python 3000, but Guido thought it was too early for this. Getting the data out of SourceForge seemed to be the current sticking point, and so Fredrik Lundh wrote up `some tools`_ to do this and posted the results to http://effbot.org/tracker-20060403.zip. The discussion was then moved to the `infrastructure list`_. .. _bugzilla: http://www.bugzilla.org/ .. _jira: http://www.atlassian.com/software/jira/ .. _roundup: http://roundup.sourceforge.net/ .. _rt: http://www.bestpractical.com/rt/ .. _trac: http://www.edgewall.com/trac/ .. _python-hosting: http://www.python-hosting.com/freetrac .. _some tools: http://effbot.python-hosting.com/browser/stuff/sandbox/sourceforge/ .. _infrastructure list: http://mail.python.org/mailman/listinfo/infrastructure/ Contributing threads: - `I'm not getting email from SF when assigned a bug/patch <http://mail.python.org/pipermail/python-dev/2006-March/062876.html>`__ ------------------- The C-level set API ------------------- Barry Warsaw wanted to add PySet_Clear(), PySet_Update() and PySet_Next() to the C-level set API. Raymond Hettinger objected, saying that this functionality was already available through PyObject_CallMethod(s, "clear", NULL), PyObject_CallMethod(s, "update", "O", iterable) and PyObject_GetIter(s) respectively (with the last being notably safer too). Barry said that he was hoping to get some static compiler checks and easier debugging that would be lost by using PyObject_CallMethod, and to get some speedups over PyObject_GetIter() in the same way that PyDict_Next() had. Eventually, Raymond agreed to adding PySet_Clear() to the public API and to adding _PySet_Next() and _PySet_Update() to the private API. Contributing threads: - `PySet API <http://mail.python.org/pipermail/python-dev/2006-March/062601.html>`__ - `PySet_Next (Was: PySet API) <http://mail.python.org/pipermail/python-dev/2006-March/062842.html>`__ ---------------- Class decorators ---------------- Greg Ewing suggested a use-case for class decorators that could not be easily addressed with metaclasses: adding a class (but not its subclasses) to a registry. After Phillip J. Eby explained the hack that PyProtocols currently uses to make something like class decorators available, Guido suggested that someone write a PEP to add class decorators to Python 2.6. There was some discussion about moving decorators for classes inside the class for readability reasons, but Guido felt like this was too magical. No PEP had yet been produced at the time of this summary. Contributing thread: - `Class decorators <http://mail.python.org/pipermail/python-dev/2006-March/062836.html>`__ -------------------------------------- Python 3.0: Exception hierarchy issues -------------------------------------- A question from Nick Coghlan about where the new GeneratorExit exception should be placed sparked a new discussion about how the exception hierarchy should look. Barry Warsaw suggested that Exception should be at the top of the hierarchy with KeyboardInterrupt, GeneratorExit, SystemExit, StopIteration, Error and Warning being the next level down. All user defined errors would inherit from Error. People seemed to like this idea, but it would break backwards compatibility as users have been told for a while that their exceptions should derive from Exception, not Error. Guido voted for keeping the `PEP 352`_ semantics (with BaseException at the top of the hierarchy). Barry promised to address the hierarchy issue again on the Python 3000 list. .. _PEP 352: http://www.python.org/dev/peps/pep-0352/ Contributing thread: - `GeneratorExit inheriting from Exception <http://mail.python.org/pipermail/python-dev/2006-March/062568.html>`__ ------------------------------- Python 3.0: Exception statement ------------------------------- Greg Ewing asked if the except clause in Python 3.0 could be changed to:: except <type-or-tuple> as <value>: instead of the current:: except <type-or-tuple>, <value>: which can result in confusing behavior when you accidentally write:: except TypeError, ValueError: and have your TypeError instance bound to the name ValueError. Guido approved the proposal, and then the discussion veered off into the usual syntax debate, this time about whether to use "with" instead, whether to use commas or "or"s between the exception types, and whether or not to require parentheses around multiple types. Guido reiterated his support for the original proposal and shortly afterwards, the thread died. Contributing thread: - `Py3k: Except clause syntax <http://mail.python.org/pipermail/python-dev/2006-March/062446.html>`__ ------------------------------------------------- Adding an N-dimensional array interface to Python ------------------------------------------------- Travis E. Oliphant asked about including Numpy's `N-dimensional array interface`_ in Python core by adding a __array_struct__ member to array.array that looks like:: typedef struct { int version; /* contains the integer 2 as a sanity check */ int nd; /* number of dimensions */ char typekind; /* kind in array --- character code of typestr */ int itemsize; /* size of each element */ int flags; /* flags indicating how the data should be interpreted */ Py_intptr_t *shape; /* A length-nd array of shape information */ Py_intptr_t *strides; /* A length-nd array of stride information */ void *data; /* A pointer to the first element of the array */ } PyArrayInterface; This struct is basically unchanged over Numpy's last 10 years of evolution and Travis was hoping to finally get the interface blessed by official inclusion in Python so that PIL, PyVox, WxPython, PyOpenGL, etc. could all start using the same interface. Guido asked for a PEP, but no one seemed to feel comfortable taking the array interface definition and producing a PEP out of it. .. _N-dimensional array interface: http://numeric.scipy.org/array_interface.html Contributing thread: - `Expose the array interface in Python 2.5? <http://mail.python.org/pipermail/python-dev/2006-March/062501.html>`__ ------------------------------------------------ Inconsistent behavior between += and .__iadd__() ------------------------------------------------ Travis Oliphant noticed that ``a.__iadd__(b)`` and ``a += b`` currently do different things depending on the type of their arguments:: a = range(5) b = numpy.arange(5) a.__iadd__(b) assert a == [0, 1, 2, 3, 4, 0, 1, 2, 3, 4] a = range(5) b = numpy.arange(5) a += b assert a == numpy.array([0, 2, 4, 6, 8]) This apparently occurs because PyNumber_InPlaceAdd coerces ``a`` into a numeric type (a numpy.array object) before trying PySequence_InPlaceConcat. Guido suggested that += (and \*=) should check both the numeric and sequence slots before trying to coerce either arguments. Armin Rigo pointed out that this fix would require that ``listobject.__add__(intobject)`` would have to return NotImplemented instead of immediately raising an exception, but promised to provide the fix when he could. Contributing thread: - `INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c <http://mail.python.org/pipermail/python-dev/2006-March/062885.html>`__ ------------------- Supported platforms ------------------- A couple different threads asked about which of the lesser-known platforms Python is supported on. Andrew MacIntyre verified that OS/2 is still being supported, Donn Cave and Francois Revol maintain the BeOS (a.k.a. Zeta OS) port, and Ralf W. Grosse-Kunstleve promised to make Tru64 machines available for testing Python if people needed them. Contributing threads: - `supported platforms OS2? <http://mail.python.org/pipermail/python-dev/2006-March/062685.html>`__ - `r43214 - peps/trunk/pep-3000.txt <http://mail.python.org/pipermail/python-dev/2006-March/062741.html>`__ - `[Fwd: Re: r43214 - peps/trunk/pep-3000.txt] <http://mail.python.org/pipermail/python-dev/2006-March/062792.html>`__ ---------------------------- Definition of sys.executable ---------------------------- Fredrik Lundh pointed out that when Python is embedded, the documentation for sys.executable seems suggest that it should be pointed to the executable used to start the program, not Python itself. Since this executable is no longer Python, you can no longer run sys.executable to start another Python instance. At least py2exe and PyXPCOM both depend on the current behavior, so the implementation can't be changed. Fredrik suggested adding sys.python_executable so that Python code would always be able to start another Python instance, even when embedded, but the discussion concluded without any final decisions. Contributing thread: - `towards a stricter definition of sys.executable <http://mail.python.org/pipermail/python-dev/2006-March/062453.html>`__ ---------------------------------------------------- Location of modules for multi-architecture platforms ---------------------------------------------------- Neal Becker reported that on x86_64, the Twisted package gets split between an architecture independent directory and an architecture dependent one, and so when Python searches for the package, it finds only the first part of the installation. There was then some discussion about how multi-architecture platforms should be properly supported. The conclusion seemed to be that the package should not be split; instead two versions of the package, one for each architecture, should be installed to two different directories. But Martin v. LÃ¶wis indicated that if anyone thought they knew better how this should work, he would accept patches. Contributing thread: - `Problem with module loading on multi-arch? <http://mail.python.org/pipermail/python-dev/2006-March/062462.html>`__ ----------------- PEP 299: rejected ----------------- Guido rejected `PEP 299`_, which would have encouraged the definition of a module-level __main__() function instead of the current:: if __name__ == '__main__': ... The rejection came after it was clear that writing code to work both before and after the PEP was going to be difficult, that ``import __main__`` would have started raising TypeErrors, and that the proposal didn't particularly gain much over the status quo. .. _PEP 299: http://www.python.org/dev/peps/pep-0299/ Contributing thread: - `What about PEP 299? <http://mail.python.org/pipermail/python-dev/2006-March/062951.html>`__ -------------------------------------- String exceptions in generator.throw() -------------------------------------- In its implementation at the time, `PEP 342`_'s throw method on generators did not support string exceptions. Phillip J. Eby wanted to add support for them, but suggested that string exceptions only be allowed if accompanied by a traceback so that string exceptions could only be passed on, not created. Guido indicated that he'd rather keep things simple and just allow string exceptions regardless of the presence of a traceback. .. _PEP 342: http://www.python.org/dev/peps/pep-0342/ Contributing thread: - `PEP 342 support for string exceptions in throw() <http://mail.python.org/pipermail/python-dev/2006-March/062798.html>`__ ---------------------- Generator memory leaks ---------------------- With `PEP 342`_, generators need a __del__ method to raise the GeneratorExit exception in active generators. However, the __del__ method also means the generator cannot be cleaned up when it's part of a reference cycle. Tim Peters suggested that the best solution was simply to add a special test for generators, and leave any generalizations of this idea until they're actually needed. Contributing threads: - `[Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c <http://mail.python.org/pipermail/python-dev/2006-March/062870.html>`__ - `Fwd: [Python-checkins] r43358 - python/trunk/Modules/itertoolsmodule.c <http://mail.python.org/pipermail/python-dev/2006-March/062972.html>`__ ------------------------------------- PyMem and PyObject freeing mismatches ------------------------------------- When Python's small-object memory allocator was introduced, Python originally supported obtaining an object through PyObject_{New,NEW} and freeing it using any one of PyObject_{Free,FREE}, PyMem_{Del,DEL} or PyMem_{Free,FREE}. The hacks to support the mismatched (PyMem_*) frees were pretty horrible, and since using such mismatched calls has been forbidden for years, Tim Peters started ripping out the support code. Turns out that Python core itself had a number of mismatched calls, but Tim decided to leave the change checked in so that these kinds of issues could get fixed before the 2.5 release. Adam DePrince promised to provide a patch to identify in a debug-build when an object was freed with a mismatched call. Contributing thread: - `Prevalence of low-level memory abuse? <http://mail.python.org/pipermail/python-dev/2006-March/062832.html>`__ ================ Deferred Threads ================ - `reference leaks, __del__, and annotations <http://mail.python.org/pipermail/python-dev/2006-March/063213.html>`__ - `New-style icons, .desktop file <http://mail.python.org/pipermail/python-dev/2006-March/063235.html>`__ ================== Previous Summaries ================== - `Still looking for volunteer to run Windows buildbot <http://mail.python.org/pipermail/python-dev/2006-March/062445.html>`__ - `Making staticmethod objects callable? <http://mail.python.org/pipermail/python-dev/2006-March/062450.html>`__ - `Switch to MS VC++ 2005 ?! <http://mail.python.org/pipermail/python-dev/2006-March/062456.html>`__ - `_bsddb.c ownership <http://mail.python.org/pipermail/python-dev/2006-March/063117.html>`__ =============== Skipped Threads =============== - `[Python-checkins] r43041 - python/trunk/Modules/_ctypes/cfield.c <http://mail.python.org/pipermail/python-dev/2006-March/062444.html>`__ - `open() mode is lax <http://mail.python.org/pipermail/python-dev/2006-March/062447.html>`__ - `bytes thoughts <http://mail.python.org/pipermail/python-dev/2006-March/062455.html>`__ - `Python Library Reference top page too long <http://mail.python.org/pipermail/python-dev/2006-March/062465.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-March/062496.html>`__ - `Bug 1184112 still valid <http://mail.python.org/pipermail/python-dev/2006-March/062510.html>`__ - `Making runpy.run_module *not* thread-safe <http://mail.python.org/pipermail/python-dev/2006-March/062517.html>`__ - `Py3K thought: use external library for client-side HTTP <http://mail.python.org/pipermail/python-dev/2006-March/062543.html>`__ - `dealing with decorators hiding metadata of decorated functions <http://mail.python.org/pipermail/python-dev/2006-March/062545.html>`__ - `All green! <http://mail.python.org/pipermail/python-dev/2006-March/062551.html>`__ - `Py_ssize_t backwards compatibility <http://mail.python.org/pipermail/python-dev/2006-March/062561.html>`__ - `PY_SSIZE_T_CLEAN <http://mail.python.org/pipermail/python-dev/2006-March/062562.html>`__ - `Patch or feature? Tix.Grid working for 2.5 <http://mail.python.org/pipermail/python-dev/2006-March/062577.html>`__ - `__dict__ strangeness <http://mail.python.org/pipermail/python-dev/2006-March/062578.html>`__ - `Two buildbot slaves wedged <http://mail.python.org/pipermail/python-dev/2006-March/062586.html>`__ - `pyexpat namespace problem (Was: libbzip2 version?) <http://mail.python.org/pipermail/python-dev/2006-March/062598.html>`__ - `buildbot failure in sparc solaris10 gcc trunk <http://mail.python.org/pipermail/python-dev/2006-March/062619.html>`__ - `Test <http://mail.python.org/pipermail/python-dev/2006-March/062620.html>`__ - `Py3K timescale and stdlib philosophy (was: Re: Py3K thought: use...) <http://mail.python.org/pipermail/python-dev/2006-March/062625.html>`__ - `Py3K timescale and stdlib philosophy <http://mail.python.org/pipermail/python-dev/2006-March/062630.html>`__ - `Long-time shy failure in test_socket_ssl <http://mail.python.org/pipermail/python-dev/2006-March/062634.html>`__ - `Bug Day? <http://mail.python.org/pipermail/python-dev/2006-March/062646.html>`__ - `Bug Day on Friday, 31st of March <http://mail.python.org/pipermail/python-dev/2006-March/062662.html>`__ - `buildbot failure in x86 W2k trunk <http://mail.python.org/pipermail/python-dev/2006-March/062672.html>`__ - `buildbot failure in x86 XP-2 trunk <http://mail.python.org/pipermail/python-dev/2006-March/062673.html>`__ - `buildbot failure in x86 XP 2.4 <http://mail.python.org/pipermail/python-dev/2006-March/062676.html>`__ - `Documenting the ssize_t Python C API changes <http://mail.python.org/pipermail/python-dev/2006-March/062688.html>`__ - `r43041 - python/trunk/Modules/_ctypes/cfield.c <http://mail.python.org/pipermail/python-dev/2006-March/062689.html>`__ - `buildbot warnings in x86 gentoo trunk <http://mail.python.org/pipermail/python-dev/2006-March/062694.html>`__ - `segfaults on Mac (was Re: Long-time shy failure in test_socket_ssl)) <http://mail.python.org/pipermail/python-dev/2006-March/062701.html>`__ - `buildbot warnings in amd64 gentoo trunk <http://mail.python.org/pipermail/python-dev/2006-March/062714.html>`__ - `[Python-checkins] r43126 - in python/trunk: Doc/lib/libsocket.tex Lib/socket.py Lib/test/test_socket.py Misc/NEWS Modules/socketmodule.c <http://mail.python.org/pipermail/python-dev/2006-March/062723.html>`__ - `buildbot warnings in x86 XP-2 trunk <http://mail.python.org/pipermail/python-dev/2006-March/062727.html>`__ - `buildbot warnings in g4 osx.4 trunk <http://mail.python.org/pipermail/python-dev/2006-March/062730.html>`__ - `buildbot warnings in sparc solaris10 gcc trunk <http://mail.python.org/pipermail/python-dev/2006-March/062749.html>`__ - `Building Python for AMD64 (Windows) <http://mail.python.org/pipermail/python-dev/2006-March/062751.html>`__ - `buildbot warnings in x86 W2k trunk <http://mail.python.org/pipermail/python-dev/2006-March/062777.html>`__ - `buildbot warnings in x86 XP trunk <http://mail.python.org/pipermail/python-dev/2006-March/062778.html>`__ - `Patch to add timestamp() method to datetime objects <http://mail.python.org/pipermail/python-dev/2006-March/062781.html>`__ - `test_quopri, test_wait3, and test_popen2 <http://mail.python.org/pipermail/python-dev/2006-March/062783.html>`__ - `[Python-3000] Iterators for dict keys, values, and items == annoying :) <http://mail.python.org/pipermail/python-dev/2006-March/062787.html>`__ - `howto return malloc()ed memory from C -> Python <http://mail.python.org/pipermail/python-dev/2006-March/062791.html>`__ - `PEP 343: A messy contextmanager corner case <http://mail.python.org/pipermail/python-dev/2006-March/062797.html>`__ - `Another PEP 343 contextmanager glitch <http://mail.python.org/pipermail/python-dev/2006-March/062800.html>`__ - `Pickling problems are hard to debug <http://mail.python.org/pipermail/python-dev/2006-March/062828.html>`__ - `daily releases? <http://mail.python.org/pipermail/python-dev/2006-March/062849.html>`__ - `Changing -Q to warn for 2.5? <http://mail.python.org/pipermail/python-dev/2006-March/062850.html>`__ - `TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th <http://mail.python.org/pipermail/python-dev/2006-March/062853.html>`__ - `refleaks in 2.4 <http://mail.python.org/pipermail/python-dev/2006-March/062856.html>`__ - `Inconsistency in 2.4.3 for __repr__() returning unicode <http://mail.python.org/pipermail/python-dev/2006-March/062857.html>`__ - `Next PyPy Sprint: Tokyo 23/4 - 29/4 <http://mail.python.org/pipermail/python-dev/2006-March/062859.html>`__ - `[Python-checkins] TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th <http://mail.python.org/pipermail/python-dev/2006-March/062867.html>`__ - `Libref sections to put new modules under? <http://mail.python.org/pipermail/python-dev/2006-March/062871.html>`__ - `[Python-checkins] Cancelled! TRUNK FREEZE for 2.5a1: 0000 UTC, Thursday 30th <http://mail.python.org/pipermail/python-dev/2006-March/062880.html>`__ - `Error msgs for new-style division <http://mail.python.org/pipermail/python-dev/2006-March/062924.html>`__ - `Reminder: Bug Day this Friday, 31st of March <http://mail.python.org/pipermail/python-dev/2006-March/062953.html>`__ - `warnings in libffi <http://mail.python.org/pipermail/python-dev/2006-March/063079.html>`__ - `Name for python package repository <http://mail.python.org/pipermail/python-dev/2006-March/063095.html>`__ - `alpha problems -- need input <http://mail.python.org/pipermail/python-dev/2006-March/063116.html>`__ - `unicode vs buffer (array) design issue can crash interpreter <http://mail.python.org/pipermail/python-dev/2006-March/063127.html>`__ - `building sql queries in python <http://mail.python.org/pipermail/python-dev/2006-March/063138.html>`__ - `Win64 AMD64 (aka x64) binaries available64 <http://mail.python.org/pipermail/python-dev/2006-March/063143.html>`__ - `_xmlplus fixup for 2.5 <http://mail.python.org/pipermail/python-dev/2006-March/063159.html>`__ - `(finally) getting around to killing __private names from stdlib <http://mail.python.org/pipermail/python-dev/2006-March/063161.html>`__ - `new article - MapPoint and Python <http://mail.python.org/pipermail/python-dev/2006-March/063172.html>`__ - `xmlrpclib.binary missing? <http://mail.python.org/pipermail/python-dev/2006-March/063195.html>`__ - `Fwd: Python 2.5 update <http://mail.python.org/pipermail/python-dev/2006-March/063199.html>`__ - `2.5 trunk built for Windows available? <http://mail.python.org/pipermail/python-dev/2006-March/063200.html>`__ - `Nasty trunk test failures <http://mail.python.org/pipermail/python-dev/2006-March/063202.html>`__ - `x86 trunk MSI preview <http://mail.python.org/pipermail/python-dev/2006-March/063242.html>`__ - `[Python-checkins] Python Regression Test Failures all (1) <http://mail.python.org/pipermail/python-dev/2006-March/063243.html>`__ - `gmane.comp.python.devel.3000 has disappeared <http://mail.python.org/pipermail/python-dev/2006-March/063251.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from March 16, 2006 through March 31, 2006. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This python-dev summary is the 1st written by the python-dev summary slave, Steve Bethard (Looks like I'm on my own now!). To contact me, please send email: - Steve Bethard (steven.bethard at gmail.com) Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- That this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _original text file: http://www.python.org/dev/summary/2006-03-16_2006-03-31.rst .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Jun 7)
by Cameron Laird 07 Jun '06

07 Jun '06

QOTW: "You can gain substantial speed-ups in very certain cases, but the main point of Pyrex is ease of wrapping, not of speeding-up." - Simon Percivall "The rule of thumb for all your Python Vs C questions is ... 1.) Choose Python by default. . . ." - Ravi Teja Do you remember Python's early (notice the mention of traversal of the World-Wide Web. All of it!) days? Guido invites your reminiscences: http://www.artima.com/forums/flat.jsp?forum=106&thread=161207 Paul Boddie wraps up the "how can I compile Python?" FAQ as authoritatively as possible (at least for the moment): http://groups.google.com/group/comp.lang.python/msg/ccdadf2b24af0f91 Nick Craig-Wood contributes a Process definition to access a Linux process table programmatically: http://groups.google.com/group/comp.lang.python/msg/61ae7c3716fa17db Embedding Python? Initialization is more subtle than first appears. Stefan Schukat explains an example which arises when working with win32: http://groups.google.com/group/comp.lang.python/msg/5cb4424ba6c8fa97 pysqlite has a create_function. Gerhard Haering illustrates its use: http://groups.google.com/group/comp.lang.python/msg/f100756cf7569e13 ======================================================================== Everything Python-related 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 marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. For far, FAR more Python reading than any one mind should absorb, much of it quite interesting, several pages index much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Python411 indexes "podcasts ... to help people learn Python ..." Updates appear more-than-weekly: http://www.awaretek.com/python/index.html Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of 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/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usubject=weekly%20python%20patch Although unmaintained since 2002, the Cetus collection of Python hyperlinks retains a few gems. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://www.python.org/dev/peps/pep-0042/ The online Python Journal is posted at pythonjournal.cognizor.com. editor(a)pythonjournal.com and editor(a)pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python *Py: the Journal of the Python Language* http://www.pyzine.com 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://www.ddj.com/topic/python/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&s… http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lan… There is *not* an RSS for "Python-URL!"--at least not yet. Arguments for and against are occasionally entertained. Suggestions/corrections for next week's posting are always welcome. E-mail to <Python-URL(a)phaseit.net> should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask <claird(a)phaseit.net> 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

Python-announce-list June 2006