Mailman 3 August 2005 - Python-announce-list

[ANNOUNCE] gmpy 1.0 alpha released
by Alex Martelli 12 Nov '05

12 Nov '05

See http://gmpy.sourceforge.net/ for details. What is it: a wrapper for the GMP library, to provide multi-precision arithmetic for Python. Multi-precision floats, and unbounded-precision rationals, are not present in stock Python; multi-precision integers ('long') are, but gmpy's version of multi-precision integers is faster for some operations (NOT all -- used to be, but Python 2.3 did serious enhancements to some operations on longs) and provides lots of nifty pre-packaged additional functions. Minor changes and bug-fixes since the latest 0.9 pre-alpha; support for Python 2.3. The Windows binary release is now for Python 2.3 _only_ (if you're stuck with Python 2.2 on Windows, you can keep using gmpy 0.9 pre-alpha and not really suffer from that). Known bug on Windows: the scan0 and scan1 functions appear broken (perhaps related to the lack of a GMP 4.0 library for Windows -- haven't found one around yet). Alex

2 1

ANN: PyDev 0.9.4 released
by Fabio Zadrozny 06 Sep '05

06 Sep '05

Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.4 has just been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Release Highlights: - New PYTHONPATH configuration (for the whole ambient), used for running your files, PyLint, code completion... - Integrated Scott Schleiser patches for the debugger (you won't see any 'implement me' anymore!). - Integrated Heikki Toivonen patch for PyLint using the project pythonpath. - Integrated Heikki Toivonen patch for indentation after '(', '[' and '{' (if the line ends with a comma). - Some StackOverflow errors were removed from code completion. - Keybindings added for Refactoring (powered by bycicle repair man) - check the FAQ. - Some bug-fixes as usual... Regards, -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com

1 6

ANN: FarPy GUIE v0.0.1 - Python GUI Editor
by dberlin＠gmail.com 31 Aug '05

31 Aug '05

I named this tool - FarPy GUIE, and is available at: http://farpy.holev.com/ This is a quote from the site: "GUIE (GUI Editor) provides a simple WYSIWYG GUI editor for wxPython. The program was made in C# and saves the GUI that was created to a XML format I called GUIML. This GUIML is a pretty standrad representation of the GUI created with the program. Next, GUIE takes these GUIML files and translates it to wxPython Python code. You may ask yourself why I took the extra step? Why didn't I go straight from C# controls to wxPython code? Why is GUIML neccessary? Well, it isn't. It is there simply for people (or maybe I) to take the GUIML and convert it to other languages. This, by affect can convert this tool from a Python GUI editor, to "any programming language with a GUI module" GUI editor. The GUI Editor was built to be as point & click as possible, trying to avoid wxPython's sizers completly. This means that controls can go anywhere, and you have the freedom to play with the GUI however you want. However, this also means that until some more advanced aligning features are added, this method might be a little awkward at first." I must add that the tool is in it's early stages of development, and basically I need the public's help to make it better. Thanks,

1 0

[ANN] FreeImagePy 1.0.0
by Michele Petrazzo 31 Aug '05

31 Aug '05

What is? It' a python wrapper for FreeImage, Open Source library for developers who would like to support popular graphics image formats. How work? It use a binary freeimage library present on the system and ctypes. It 's released with the two public license GPL/FIPL: GPL: GNU GENERAL PUBLIC LICENSE - freeimagepy.sf.net/license-gpl.txt FIPL: FreeImage Public License - freeimagepy.sf.net/license-fi.tx More informations can be found here: http://freeimagepy.sf.net/ Michele Petrazzo

1 0

ANN: M2Crypto 0.15
by Heikki Toivonen 31 Aug '05

31 Aug '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M2crypto release 0.15 In this M2Crypto release: * Support for OpenSSL up to 0.9.8 * Support for SWIG 1.3.24 * Support for Python 2.4.1 * Twisted integration * Safer defaults for SSL context and post connection check for clients * Eliminated C pointers from interfaces (some may still remain in callbacks) * Many cases where Python interpreter crashed have been fixed * Improved thread safety of many callbacks * Memory leak fixes * And of course more of the OpenSSL API is covered, new docstrings and tests have been written To get the source: svn co http://svn.osafoundation.org/m2crypto/tags/0.15 m2crypto-0.15 Enjoy! - -- Heikki Toivonen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFTtOb8x8KoP+JuwRAsziAJ9+ihoqleq1nWJS6Ssuvdkj6Lnh5wCfR8fP laxXwvW7OUruYDN2pqlPT3g= =7dc6 -----END PGP SIGNATURE-----

1 0

PySyck-0.55.1: Initial Release
by Kirill Simonov 30 Aug '05

30 Aug '05

PySyck: Python bindings for the Syck YAML parser and emitter ============================================================ YAML_ is a data serialization format designed for human readability and interaction with scripting languages. Syck_ is an extension for reading and writing YAML in scripting languages. Syck provides bindings to the Python programming language, but they are somewhat limited and leak memory. PySyck_ is aimed to update the current Python bindings for Syck. PySyck_ may be used for various tasks, in particular, as a replacement of the module pickle_. Please be aware that PySyck_ is a beta-quality software and is not ready yet for production use. You may download PySyck_ source and Windows binary packages from http://xitology.org/pysyck/. It is the initial release of PySyck_. .. _YAML: http://yaml.org/ .. _Syck: http://whytheluckystiff.net/syck/ .. _PySyck: http://xitology.org/pysyck/ .. _pickle: http://docs.python.org/lib/module-pickle.html -- xi

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Aug 30)
by Diez B.Roggisch 30 Aug '05

30 Aug '05

QOTW: "If I wanted to write five lines instead of one everywhere in a Python program, I'd use Java." -- Paul Rubin http://groups.google.com/group/comp.lang.python/msg/6fac4f3022acd1fa?hl=de& "i think less buggy code is not the main concern for all." -- km http://groups.google.com/group/comp.lang.python/msg/db5acbd68447ae33?hl=de& Bryan Olson discovers inconsistencies in the slice implementation that lead to a new slicing PEP and a lively discussion about string index semantics: http://groups.google.com/group/comp.lang.python/browse_frm/thread/402d770b6… Mark Dickinson finds strange runtime differences depending on the existence of dummy variables - the riddle is solved by Stelios Xanthakis who points out that min() can behave non-deterministically when the compared entities have no well-defined comparision sematics: http://groups.google.com/group/comp.lang.python/browse_frm/thread/2ff00f124… Russell E. Owen tries to get unique ids for bound methods - and discovers that id() can return the same value for two different bound methods. The solution is to keep a reference to the bound method, thus the id() won't be reused - which tkinters _register does: http://groups.google.com/group/comp.lang.python/browse_frm/thread/143a9000b… Ramza Brown wants a small footprint python distro - and gets answers which shed light on the subject from varying perspectives: http://groups.google.com/group/comp.lang.python/browse_frm/thread/18e8f91c8… Diego Andrs Sanabria wonders about the apparent lack of a binary tree data type in python: http://groups.google.com/group/comp.lang.python/browse_frm/thread/fb307dbdf… sysfault wants enlightenment about decorators and metaclasses - and hopefully now has it: http://groups.google.com/group/comp.lang.python/browse_frm/thread/6bcb4d9ae… Roland Hedberg wants to speed up his client/server implementation - and gets deep insight into the TCP/IP protocol stacks: http://groups.google.com/group/comp.lang.python/browse_frm/thread/507a711c6… As often before, Jp Calderone eloquently illustrates the expressiveness Twisted affords those writing multitasking network servers: http://groups.google.com/group/comp.lang.python/browse_thread/thread/dce337… max(01)* needs help on piping commands in python: http://groups.google.com/group/comp.lang.python/browse_frm/thread/5cbe31266… Pythoneers are nearly unanimous: when you need dynamic names for your variables ... you're probably doing something wrong. Python is plenty dynamic, though, so of course it's *possible*: http://groups.google.com/group/comp.lang.python/browse_thread/thread/d9a99f… Damien Elmes needs advice dealing with locales: http://groups.google.com/group/comp.lang.python/browse_frm/thread/8f44319ae… KM compares apples with oranges - and gets told so: http://groups.google.com/group/comp.lang.python/browse_frm/thread/d1c6888ea… 42 thinks he has new ideas about restricting python's execution - it turns out to be old news again, though: http://groups.google.com/group/comp.lang.python/browse_frm/thread/89e733d60… ======================================================================== 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 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 Cetus collects Python hyperlinks. 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://python.sourceforge.net/peps/pep-0042.html 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/topics/pythonurl/ (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… 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

IMDbPY 2.1 released
by alberanid＠libero.it 30 Aug '05

30 Aug '05

IMDbPY 2.1 is available (tgz, deb, rpm, exe) from: http://imdbpy.sourceforge.net/ IMDbPY is a Python package useful to retrieve and manage the data of the IMDb movie database about both movies and people. With this release you can transfer the whole content of the plain text data files (distributed by IMDb) into a SQL database. A lot of bugs where fixed, and the 'http' data access system retrieves some new information. Platform-independent and written in pure Python (and few C lines), it can retrieve data from both the IMDb's web server and a local copy of the whole database. IMDbPY package can be very easily used by programmers and developers to provide access to the IMDb's data to their programs. Some simple example scripts are included in the package; other IMDbPY-based programs are available from the home page. -- Davide Alberani <alberanid(a)libero.it> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/

1 0

python-dev Summary for 2005-08-01 through 2005-08-15
by Tony Meyer 29 Aug '05

29 Aug '05

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-08-01_2005-08-15.html] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Some wise words from Donovan Baarda in the PEP 347 discussions: It is true that some well designed/developed software becomes reliable very quickly. However, it still takes heavy use over time to prove that. Contributing thread: - `PEP: Migrating the Python CVS to Subversion <http://mail.python.org/pipermail/python-dev/2005-August/055105.html>`__ [SJB] ------------ Process PEPs ------------ The PEP editors have introduced a new PEP category: "Process", for PEPs that don't fit into the "Standards Track" and "Informational" categories. More detail can be found in `PEP 1`_, which is itself a Process PEP. .. _PEP 1: http://www.python.org/peps/pep-0001.html Contributing thread: - `new PEP type: Process <http://mail.python.org/pipermail/python-dev/2005-August/055361.html>`__ [TAM] ----------------------------------------------- Tentative Schedule for 2.4.2 and 2.5a1 Releases ----------------------------------------------- Python 2.4.2 is tentatively scheduled for a mid-to-late September release and a first alpha of Python 2.5 for March 2006 (with a final release around May/June). This means that a PEP for the 2.5 release, detailing what will be included, will likely be created soon; at present there are various accepted PEPs that have not yet been implemented. Contributing thread: - `plans for 2.4.2 and 2.5a1 <http://mail.python.org/pipermail/python-dev/2005-August/055342.html>`__ [TAM] ========= Summaries ========= ------------------------------- Moving Python CVS to Subversion ------------------------------- The `PEP 347`_ discussion from last fortnight continued this week, with a revision of the PEP, and a lot more discussion about possible version control software (RCS) for the Python repository, and where the repository should be hosted. Note that this is not a discussion about bug trackers, which will remain with Sourceforge (unless a separate PEP is developed for moving that). Many revision control systems were extensively discussed, including `Subversion`_ (SVN), `Perforce`_, `Mercurial`_, and `Monotone`_. Whichever system is moved to, it should be able to be hosted somewhere (if *.python.org, then it needs to be easily installable), needs to have software available to convert a repository from CVS, and ideally would be open-source; similarity to CVS is also an advantage in that it requires a smaller learning curve for existing developers. While Martin isn't willing to discuss every system there is, he will investigate those that make him curious, and will add other people's submissions to the PEP, where appropriate. The thread included a short discussion about the authentication mechanism that svn.python.org will use; svn+ssh seems to be a clear winner, and a test repository will be setup by Martin next fortnight. The possibility of moving to a distributed revision control system (particularly `Bazaar-NG`_) was also brought up. Many people liked the idea of using a distributed revision control system, but it seems unlikely that Bazaar-NG is mature enough to be used for the main Python repository at the current time (a move to it at a later time is possible, but outside the scope of the PEP). Distributed RCS are meant to reduce the barrier to participation (anyone can create their own branches, for example); Bazaar-NG is also implemented in Python, which is of some benefit. James Y Knight pointed out `svk`_, which lets developers create their own branches within SVN. In general, the python-dev crowd is in favour of moving to SVN. Initial concern about the demands on the volunteer admins should the repository be hosted at svn.python.org were addressed by Barry Warsaw, who believes that the load will be easily managed with the existing volunteers. Various alternative hosts were discussed, and if detailed reports about any of them are created, these can be added to the PEP. While the fate of all PEPS lie with the BDFL (Guido), it is likely that the preferences of those that frequently check in changes, the pydotorg admins, and the release managers (who have all given favourable reports so far), will have a significant effect on the pronouncement of this PEP. .. _PEP 347: http://www.python.org/peps/pep-0347.html .. _svk: http://svk.elixus.org/ .. _Perforce: http://www.perforce.com/ .. _Subversion: http://subversion.tigris.org/ .. _Monotone: http://venge.net/monotone/ .. _Bazaar-NG: http://www.bazaar-ng.org/ .. _Mercurial: http://www.selenic.com/mercurial/ Contributing threads: - `PEP: Migrating the Python CVS to Subversion <http://mail.python.org/pipermail/python-dev/2005-August/055064.html>`__ - `PEP 347: Migration to Subversion <http://mail.python.org/pipermail/python-dev/2005-August/055211.html>`__ - `Hosting svn.python.org <http://mail.python.org/pipermail/python-dev/2005-August/055360.html>`__ - `Fwd: Distributed RCS <http://mail.python.org/pipermail/python-dev/2005-August/055372.html>`__ - `cvs to bzr? <http://mail.python.org/pipermail/python-dev/2005-August/055373.html>`__ - `Distributed RCS <http://mail.python.org/pipermail/python-dev/2005-August/055377.html>`__ - `Fwd: PEP: Migrating the Python CVS to Subversion <http://mail.python.org/pipermail/python-dev/2005-August/055388.html>`__ - `On distributed vs centralised SCM for Python <http://mail.python.org/pipermail/python-dev/2005-August/055432.html>`__ [TAM] ------------------------------------------ PEP 348: Exception Hierarchy in Python 3.0 ------------------------------------------ This fortnight mostly concluded the previous discussion about `PEP 348`_, which sets out a roadmap for changes to the exception hierarchy in Python 3.0. The proposal was heavily scaled back to retain most of the current exception hierarchy unchanged. A new exception, BaseException, will be introduced above Exception in the current hierarchy, and KeyboardInterrupt and SystemExit will become siblings of Exception. The goal here is that:: except Exception: will now do the right thing for most cases, that is, it will catch all the exceptions that you can generally recover from. The PEP would also move NotImplementedError out from under RuntimeError, and alter the semantics of the bare except so that:: except: is the equivalent of:: except Exception: Only BaseException will appear in Python 2.5. The remaining modifications will not occur until Python 3.0. .. _PEP 348: http://www.python.org/peps/pep-0348.html Contributing threads: - `Pre-PEP: Exception Reorganization for Python 3.0 <http://mail.python.org/pipermail/python-dev/2005-August/055063.html>`__ - `PEP, take 2: Exception Reorganization for Python 3.0 <http://mail.python.org/pipermail/python-dev/2005-August/055103.html>`__ - `Exception Reorg PEP checked in <http://mail.python.org/pipermail/python-dev/2005-August/055138.html>`__ - `PEP 348: Exception Reorganization for Python 3.0 <http://mail.python.org/pipermail/python-dev/2005-August/055162.html>`__ - `Major revision of PEP 348 committed <http://mail.python.org/pipermail/python-dev/2005-August/055199.html>`__ - `Exception Reorg PEP revised yet again <http://mail.python.org/pipermail/python-dev/2005-August/055292.html>`__ - `PEP 348 and ControlFlow <http://mail.python.org/pipermail/python-dev/2005-August/055310.html>`__ - `PEP 348 (exception reorg) revised again <http://mail.python.org/pipermail/python-dev/2005-August/055412.html>`__ [SJB] ---------------------- Moving towards Unicode ---------------------- Neil Schemenauer presented `PEP 349`_, which tries to ease the transition to Python 3.0, in which there will be a bytes() type for byte data and a str() type for text data. Currently to convert an object to text, you have one of three options: * Call str(). This breaks with a UnicodeEncodeError if the object is of type unicode (or a subtype) or can only represent itself in unicode and therefore returns unicode from __str__. * Call unicode(). This can break external code that is not yet Unicode-safe and that passed a str object to your code but got a unicode object back. * Use the "%s" format specifier. This breaks with a UnicodeEncodeError if the object can only represent itself in unicode and therefore returns unicode from __str__. `PEP 349`_ attempts to address this problem by introducing a text() builtin which returns str or unicode instances unmodified, and returns the result of calling __str__() on the object otherwise. Guido preferred to instead relax the restrictions on str() to allow it to return unicode objects. Neil implemented such a patch, and found that it broke only two test cases. The discussion stopped shortly after Neil's report however, so it was unclear if any permanent changes had been agreed upon. Guido made a few other Python 3.0 suggestions in this thread: * The bytes() type should be mutable with a corresponding frozenbytes() immutable type * Opening a file in binary or text mode would cause it to return bytes() or str() objects, respectively * The file type should grow a getpos()/setpos() pair that are identical to tell()/seek() when a file is open in binary mode, and which work like tell()/seek() but on characters instead of bytes when a file is opened in text mode. However, none of these seemed to be solid commitments. .. _PEP 349: http://www.python.org/peps/pep-0349.html Contributing threads: - `PEP: Generalised String Coercion <http://mail.python.org/pipermail/python-dev/2005-August/055186.html>`__ - `Generalised String Coercion <http://mail.python.org/pipermail/python-dev/2005-August/055194.html>`__ [SJB] ---------------------------- PEP 344 and reference cycles ---------------------------- Armin Rigo brought up an issue with `PEP 344`_ which proposes, among other things, adding a __traceback__ attribute to exceptions to avoid the hassle of extracting it from sys.exc_info(). Armin pointed out that if exceptions grow a __traceback__ attribute, every statement:: except Exception, e: will create a cycle:: e.__traceback__.tb_frame.f_locals['e'] Despite the fact that Python has cyclic garbage collection, there are still some situations where cycles like this can cause problems. Armin showed an example of such a case:: class X: def __del__(self): try: typo except Exception, e: e_type, e_value, e_tb = sys.exc_info() Even in current Python, instances of the X class are uncollectible. When garbage collection runs and tries to collect an X object, it calls the __del__() method. This creates the cycle:: e_tb.tb_frame.f_locals['e_tb'] The X object itself is available through this cycle (in ``f_locals['self']``), so the X object's refcount does not drop to 0 when __del__() returns, so it cannot be collected. The next time garbage collection runs, it finds that the X object has not been collected, calls its __del__() method again and repeats the process. Tim Peters suggested this problem could be solved by declaring that __del__() methods are called exactly once. This allows the above X object to be collected because on the second run of the garbage collection, __del__() is not called again. Thus, the refcount of the X object is not incremented, and so it is collected by garbage collection. However, guaranteeing that __del__() is called only once means keeping track somehow of which objects' __del__() methods were called, which seemed somewhat unattractive. There was also brief talk about removing __del__ in favor of weakrefs, but those waters seemed about as murky as the garbage collection ones. .. _PEP 344: http://www.python.org/peps/pep-0344.html Contributing thread: - `__traceback__ and reference cycles <http://mail.python.org/pipermail/python-dev/2005-August/055251.html>`__ [SJB] ---------------------------- Style for raising exceptions ---------------------------- Guido explained that these days exceptions should always be raised as:: raise SomeException("some argument") instead of:: raise SomeException, "some argument" The second will go away in Python 3.0, and is only present now for backwards compatibility. (It was necessary when strings could be exceptions, in order to pass both the exception "type" and message.) PEPs 8_ and 3000_ were accordingly updated. .. _8: http://www.python.org/peps/pep-0008.html .. _3000: http://www.python.org/peps/pep-3000.html Contributing threads: - `PEP 8: exception style <http://mail.python.org/pipermail/python-dev/2005-August/055187.html>`__ - `FW: PEP 8: exception style <http://mail.python.org/pipermail/python-dev/2005-August/055191.html>`__ [SJB] ----------------------------------- Skipping list comprehensions in pdb ----------------------------------- When using pdb, the only way to skip to the end of a loop is to set a breakpoint on the line after the loop. Ilya Sandler suggested adding an optimal numeric argument to pdb's "next" comment to indicate how many lines of code should be skipped. Martin v. Löwis pointed out that this differs from gdb's "next <n>" command, which does "next" n times. Ilya suggested implementing gdb's "until" command instead, which gained Martin's approval. It was also pointed out that pdb is one of the less Pythonic modules, particularly in terms of the ability to subclass/extend, and would be a good candidate for rewriting, if anyone had the inclination and time. Contributing threads: - `pdb: should next command be extended? <http://mail.python.org/pipermail/python-dev/2005-August/055218.html>`__ - `an alternative suggestion, Re: pdb: should next command be extended? <http://mail.python.org/pipermail/python-dev/2005-August/055286.html>`__ [TAM] ------------------ Sets in Python 2.5 ------------------ Raymond Hettinger has been checking-in the new implementation for sets in Python 2.5. The implementation is based heavily on dictobject.c, the code for Python dict() objects, and generally deviates only when there is an obvious gain in doing so. Raymond posted a proposed C API sets; no comments were forthcoming and it was implemented for Py2.5 without changes. Contributing threads: - `[Python-checkins] python/dist/src/Objects setobject.c, 1.45, 1.46 <http://mail.python.org/pipermail/python-dev/2005-August/055337.html>`__ - `Discussion draft: Proposed Py2.5 C API for set and frozenset objects <http://mail.python.org/pipermail/python-dev/2005-August/055365.html>`__ [SJB] ================================ Deferred Threads (for next time) ================================ - `SWIG and rlcompleter <http://mail.python.org/pipermail/python-dev/2005-August/055413.html>`__ =============== Skipped Threads =============== - `Extension of struct to handle non byte aligned values? <http://mail.python.org/pipermail/python-dev/2005-August/055062.html>`__ - `Syscall Proxying in Python <http://mail.python.org/pipermail/python-dev/2005-August/055069.html>`__ - `__autoinit__ (Was: Proposal: reducing self.x=x; self.y=y; self.z=z boilerplate code) <http://mail.python.org/pipermail/python-dev/2005-August/055093.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2005-August/055110.html>`__ - `PEP 342 Implementation <http://mail.python.org/pipermail/python-dev/2005-August/055151.html>`__ - `String exceptions in Python source <http://mail.python.org/pipermail/python-dev/2005-August/055155.html>`__ - `[ python-Patches-790710 ] breakpoint command lists in pdb <http://mail.python.org/pipermail/python-dev/2005-August/055157.html>`__ - `[C++-sig] GCC version compatibility <http://mail.python.org/pipermail/python-dev/2005-August/055219.html>`__ - `PyTuple_Pack added references undocumented <http://mail.python.org/pipermail/python-dev/2005-August/055232.html>`__ - `PEP-- Context Managment variant <http://mail.python.org/pipermail/python-dev/2005-August/055271.html>`__ - `Sourceforge CVS down? <http://mail.python.org/pipermail/python-dev/2005-August/055307.html>`__ - `PSF grant / contacts <http://mail.python.org/pipermail/python-dev/2005-August/055311.html>`__ - `Python + Ping <http://mail.python.org/pipermail/python-dev/2005-August/055319.html>`__ - `Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-August/055347.html>`__ - `dev listinfo page (was: Re: Python + Ping) <http://mail.python.org/pipermail/python-dev/2005-August/055348.html>`__ - `set.remove feature/bug <http://mail.python.org/pipermail/python-dev/2005-August/055352.html>`__ - `Extension to dl module to allow passing strings from native function <http://mail.python.org/pipermail/python-dev/2005-August/055363.html>`__ - `build problems on macosx (CVS HEAD) <http://mail.python.org/pipermail/python-dev/2005-August/055385.html>`__ - `request for code review - hashlib - patch #1121611 <http://mail.python.org/pipermail/python-dev/2005-August/055410.html>`__ - `python-dev Summary for 2005-07-16 through 2005-07-31 [draft] <http://mail.python.org/pipermail/python-dev/2005-August/055411.html>`__ - `string_join overrides TypeError exception thrown in generator <http://mail.python.org/pipermail/python-dev/2005-August/055414.html>`__ - `implementation of copy standard lib <http://mail.python.org/pipermail/python-dev/2005-August/055450.html>`__ - `xml.parsers.expat no userdata in callback functions <http://mail.python.org/pipermail/python-dev/2005-August/055362.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from August 01, 2005 through August 15, 2005. 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). Tim Lesher has had to bow out from the summaries for now; many thanks to him for the contributions he made over the last few months. This is the 1st summary written by the python-dev summary confederacy of Steve Bethard and Tony Meyer (Thanks Tim!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. 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 penny helps 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 ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note 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/ .. _last summary: http://www.python.org/dev/summary/2005-04-16_2005-04-30.html .. _original text file: http://www.python.org/dev/summary/2005-08-01_2005-08-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

ANN: retest 0.3
by Christof 28 Aug '05

28 Aug '05

what is it ---------- A simple server which enables Python regular expression tests in a webbrowser. Uses SimpleHTTPServer and AJAX. You need: Python, a modern webbrowser like Firefox, IE (from 5.5), Safari) which handles XMLHttpRequests. Currently works best with Firefox, any feedback is welcome. license ------- This work is licensed under a Creative Commons License. download -------- retest-0.3.zip - 050828 http://cthedot.de/retest/retest-0.3.zip Tested with Python 2.4.1 on Windows XP and Firefox 1.05 only. any comment will be appreciated, thanks christof hoeke <P><A HREF="http://cthedot.de/retest/">retest 0.3</A> - test Python regular expressions in a webbrowser (28-Aug-05)

1 0