Mailman 3 July 2005 - Python-announce-list

ANN: pyc 0.7
by Stelios Xanthakis July 12, 2005

July 12, 2005

Pleased to announce pyc 0.7 pyc is a sourcecode-to-bytecode compiler written entirely in python and derrived from the standard library compiler module. It features many interesting optimizations which both compress the size of the generated bytecode, and make it faster to execute. The most important fix in this release is that it attempts to correct the stacksize calculation routines. With that fixed, the code produced by pyc should be a bit faster than the standard bytecode produced by the internal CPython compiler. Download: http://students.ceid.upatras.gr/~sxanth/pyc/pyc-0.7.tar.bz2 Changelog: http://students.ceid.upatras.gr/~sxanth/pyc/CHANGES.txt Cheers, Stelios

1 0

[ANN] Fail2Ban 0.5.0
by Cyril Jaquier July 12, 2005

July 12, 2005

Hi, The version 0.5.0 of Fail2Ban is available. This is a development version and contains a lot of new features (mail notification, CIDR support, firewall rules configuration, etc). Please test it and report any bugs in order to make it stable as soon as possible. "Fail2Ban is written in Python. It scans log files like /var/log/pwdfail or /var/log/apache/error_log and bans IP that makes too many password failures. It updates firewall rules to reject the IP address." Homepage: http://fail2ban.sourceforge.net Best Regards, Cyril Jaquier

1 0

ChiPy Users Group Meeting, Thu July 14
by Ian Bicking July 12, 2005

July 12, 2005

icago Python User Group, ChiPy, will have its next meeting on Thursday, July 14, starting at 7pm. For more information on ChiPy see http://chipy.org We'll be having three presentations this month: * Adrian Holovaty will be giving a preview of his new web framework Django. * John Hunter will talk about using Python with C and C++ projects. * Ian Bicking will discuss some functional programming techniques available in Python. We'll also be planning the book club <http://chipy.org/bookclub.html> There will be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. Location -------- This month we will be meeting Monadnock building in Downtown Chicago. We need to give building security a list of names, so if there's any chance you'll attend email tobis(a)mailbag.com with the subject "ChiPy July Meeting" so Michael can add you to the list. Please bring an ID. The Monadnock building is at 53 W Jackson, and the meeting is on the 8th floor. It is convenient to all El lines. Parking is available nearby, but expect to pay about $9. About ChiPy ----------- ChiPy meets once a month, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy

1 0

BayPIGgies: July 14, 7:30pm (Google)
by Aahz July 11, 2005

July 11, 2005

The next meeting of BayPIGgies will be Thurs, July 14 at 7:30pm at Google, building 40, room Temp Tech Talk. Alex Martelli will be doing his "Black Magic" talk on descriptors, decorators, and metaclasses. Prepare to have your head exploded! BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we may meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. This week, there has been discussion of a potluck -- if you want a potluck, speak up NOW on the mailing list. Advance notice: The August 11 meeting agenda has not been set. Please send e-mail to baypiggies(a)baypiggies.net if you want to suggest an agenda (or volunteer to give a presentation). -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng.

1 0

ANN: GDL python module
by m_schellens＠users.sf.net July 10, 2005

July 10, 2005

GDL - GNU Data Language, a free IDL (Interactive Data Language - see http://www.rsinc.com) clone. (IDL 6.0 compatible incremental compiler capable of running programs written in IDL) Version: 0.8.10 Note: If you never heard of IDL or GDL you probably don't need to read further. GDL can now be build as a python module, allowing IDL/GDL routines to be called from python (for python standards the installation is quite unusual but simple, see INSTALL and PYTHON.txt for details). This is in early beta stage right now. Depending on the interest, the interface might be extended in the future. For passing arrays to and from python, GDL uses numarray. HOMEPAGE: http://gnudatalanguage.sourceforge.net DOWNLOAD: http://sourceforge.net/projects/gnudatalanguage/ Gaurav Khanna provides binaries for Mac OS X on his HPC page: http://hpc.sourceforge.net GDL FEATURES: *FULL* syntax compatibility with IDL 6.0 *ALL* IDL language elements are supported, including: _EXRA, _REF_EXTRA and _STRICT_EXTRA keywords, Objects, Pointers, Structs, Common blocks, Assoc variables, Arrays, System variables, All operators, All data types... Compiles on Linux and Mac OS X (10.2, 10.3, and 10.4) The file input output system is fully implemented (Exception: For formatted I/O the C() sub-codes are not supported yet) Most image file formats (jpeg, tiff, ...) are supported. netCDF files are fully supported. HDF file support. Basic HDF5 file support. READFITS and WRITEFITS from the IDL-Astrolib are working. Graphical output is partially implemented. The PLOT, OPLOT, PLOTS, XYOUTS, SURFACE and TV commands (along with WINDOW, WDELETE, SET_PLOT, WSET, TVLCT) work (important keywords, some !P system variable tags and multi-plots are supported) for X windows, z-buffer and postscript output. A GUI (widgets) is not implemeted yet. Check it out! marc

1 0

ANN: numarray-1.3.3
by Todd Miller July 9, 2005

July 9, 2005

Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. ========================================================================= Release Notes for numarray-1.3.3 I. ENHANCEMENTS None. 1.3.3 fixes a fatal problem with embedding numarray and loading it more than once. It also fixes some numarray memory leaks associated with restarting the Python interpreter. II. BUGS FIXED / CLOSED 1233431 Add 'type' to fromfunction() 1230490 Numarray: integer overflow in sum() is not detected 1216688 ufunc's ignoring complex operand 1213675 Problems embedding after 1.1.1 1209946 Mac OS-X --use_lapack 1212975 numarray.fromfunction(...) misbehavior 1209929 config.h and Python-2.2 1235278 Add -lm to numarray link lists See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.2 I. ENHANCEMENTS None. 1.3.2 fixes the problem with gcc4 on Mac OS-X 10.4 Tiger II. BUGS FIXED / CLOSED 1193125 Build failure on Mac OS 10.4 (Tiger) 1195370 numarray1.3.1 setup.py broken See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.1 I. ENHANCEMENTS None. 1.3.1 fixes the problem with gcc-3.4.3 II. BUGS FIXED / CLOSED 1152323 /usr/include/fenv.h:96: error: conflicting types for 'fegete 1185024 numarray-1.2.3 fails to compile with gcc-3.4.3 1187162 Numarray 1.3.0 installation failure See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. ========================================================================= Release Notes for numarray-1.3.0 Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, arrays of heterogeneous records, string arrays, and in-place operation on memory mapped files. I. ENHANCEMENTS 1. Migration of NumArray.__del__ to C (tp_dealloc). Overall performance. 2. Removal of dictionary update from array view creation improves performance of view/slice/subarray creation. This should e.g. improve the performance of wxPython sequence protocol access to Nx2 arrays. Subclasses now need to do a.flags |= numarray.generic._UPDATEDICT to ensure that dictionary based attributes are inherited by views. NumArrays no longer do this by default. 2. Modifications to support scipy.special. 3. Removal of an unnecessary getattr() from ufunc calling sequence. Ufunc performance. II. BUGS FIXED / CLOSED 1179355 average() broken in numarray 1.2.3 1167184 Floating point exception in numarray's dot() 1151892 Bug in matrixmultiply with zero size arrays 1160184 RecArray reversal 1156172 Incorect error message for shape incompatability 1155538 Incorrect error message when multiplying arrays See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. III. CAUTIONS This release should be backward binary compatible with numarray-1.1.1 and 1.2.3. WHERE ----------- Numarray-1.3.0 windows executable installers, source code, and manual is here: http://sourceforge.net/project/showfiles.php?group_id=1369 Numarray is hosted by Source Forge in the same project which hosts Numeric: http://sourceforge.net/projects/numpy/ The web page for Numarray information is at: http://stsdas.stsci.edu/numarray/index.html Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at the Source Forge project for NumPy at: http://sourceforge.net/tracker/?group_id=1369 REQUIREMENTS ------------------------------ numarray-1.3.0 requires Python 2.2.2 or greater. AUTHORS, LICENSE ------------------------------ Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science Institute. We'd like to acknowledge the assitance of Francesc Alted, Paul Dubois, Sebastian Haase, Chuck Harris, Tim Hochberg, Nadav Horesh, Edward C. Jones, Eric Jones, Jochen Kuepper, Travis Oliphant, Pearu Peterson, Peter Verveer, Colin Williams, Rory Yorke, and everyone else who has contributed with comments and feedback. Numarray is made available under a BSD-style License. See LICENSE.txt in the source distribution for details. -- Todd Miller jmiller(a)stsci.edu

1 0

ANN: eric3 3.7.1 available
by Detlev Offenbach July 9, 2005

July 9, 2005

Hi, I am proud to announce the availability of eric3 3.7.1. This is a bug fix release which fixes a severe bug next to some normal ones. NOTE: Everybody using 3.7.0 or 3.6.x should upgrade. It is available via http://www.die-offenbachs.de/detlev/eric3.html. What is it? ----------- Eric3 is a Python and Ruby IDE with all batteries included. Please see a.m. website for more details. Regards, Detlev -- Detlev Offenbach detlev(a)die-offenbachs.de

1 0

python-dev Summary for 2005-06-16 through 2005-06-30
by Steven Bethard July 9, 2005

July 9, 2005

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-06-16_2005-06-30.html] ===================== Summary Announcements ===================== ------------------ OSCON Registration ------------------ Though if you haven't yet registered, you've already missed the early registration period (which ended June 20), you should still consider taking a look at the O'Reilly Open Source Convention (OSCON). Guido assures us that "the Python program is really good!" Contributing Thread: - `Please spread the word about OSCON early reg deadline <http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__ ========= Summaries ========= ------------ PEP Clean Up ------------ Raymond Hettinger decided to go through the `list of PEPs`_ and do some spring cleaning (late for the Northern Hemisphere, but early down south). * Rejection of `PEP 303`_ ("Extend divmod() for Multiple Divisors") was proposed on the grounds that it has been open for two and half years and hasn't generated discussion or support, is unpersuasive, and unnecessary. No-one spoke up for it (and some against), so it is now rejected. * Rejection of `PEP 254`_ ("Making Classes Look More Like Types") was proposed on the grounds that it is only an empty stub and is unlikely to ever get filled-out. No-one spoke up either way, and it is now rejected. * Rejection of `PEP 265`_ ("Sorting Dictionaries by Value") was proposed on the grounds that as of Python 2.4 its use case is easily solved with a one-line sorted() solution. Several people agreed, and no-one disagreed, so the PEP is now rejcted. * Rejection of `PEP 276`_ ("Simple iterator for ints") was proposed on the grounds that the principal use case was largely met by enumerate() and that the proposed syntax was problematic. Guido agreed, so the PEP was rejected. * Rejection of `PEP 281`_ ("Loop Counter Iteration with range and xrange") was proposed on the grounds that it too was solved by the enumerate() built-in. Guido agreed again, and this PEP too was rejected. * Rejection of `PEP 294`_ ("Type Names in the types Module") was proposed on the grounds that a centralized repository of type names was a mistake and that neither the "types" nor "new" modules should be carried forward to Python 3.0. No-one disagreed, and the PEP was rejected. * Rejection of `PEP 313`_ ("Adding Roman Numeral Literals to Python" - yes, this is a real PEP!) was proposed, and the PEP was rejected. * Rejection of `PEP 336`_ ("Make None Callable") was proposed on the grounds that no support has grown beyond the original poster, and that it fails the tests of obviousness, necessity, clarity, and explicitness. Many people, including Guido, agreed, and the PEP was rejected. * Raymond suggested updating `PEP 284`_ ("Integer for-loops"), but several people spoke up against it, including Guido, so the PEP was rejected. * Raymond asked whether `PEP 330`_ ("Python Bytecode Verification") had any known uses. Guido said that he believes that a verification tool has some value, but if someone wants to add it to Tools/scripts, no PEP is required, so the PEP was rejected. * A.M. Kuchling volunteered to take over `PEP 206`_ ("Python Advanced Library", or the "Batteries Included" PEP) and rewrite it to describe a set of third-party packages to complement the standard library. This was approved, and so he's now the maintainer. * Raymond suggested accepting `PEP 312`_ ("Simple Implicit Lambda"), which resulted in the most discussion of any of the PEP recommendations. However, Guido hates the unary colon syntax, and it was decided that the PEP needs to go back to the drawing board and find a more Pythonic syntax (perhaps an alternative unary operator). The PEP is now deferred. * Raymond asked whether `PEP 237`_ ("Unifying Long Integers and Integers") was now complete and could be marked as final. Guido noted that it was complete for 2.x, but that phase C will be implemented in Python 3.0, as the PEP states. He indicated that he would be fine with marking `PEP 237`_ as final and moving this phase to `PEP 3000`_; at the time of writing, this hadn't been done yet. .. _list of PEPs: http://wwww.python.org/peps .. _PEP 303: http://www.python.org/peps/pep-0303.html .. _PEP 265: http://www.python.org/peps/pep-0265.html .. _PEP 254: http://www.python.org/peps/pep-0254.html .. _PEP 276: http://www.python.org/peps/pep-0276.html .. _PEP 281: http://www.python.org/peps/pep-0281.html .. _PEP 294: http://www.python.org/peps/pep-0294.html .. _PEP 313: http://www.python.org/peps/pep-0313.html .. _PEP 336: http://www.python.org/peps/pep-0336.html .. _PEP 284: http://www.python.org/peps/pep-0284.html .. _PEP 330: http://www.python.org/peps/pep-0330.html .. _PEP 206: http://www.python.org/peps/pep-0206.html .. _PEP 312: http://www.python.org/peps/pep-0312.html .. _PEP 237: http://www.python.org/peps/pep-0237.html .. _PEP 3000: http://www.python.org/peps/pep-3000.html Contributing Threads: - `Propose rejection of PEP 303 -- Extend divmod() for Multiple Divisors <http://mail.python.org/pipermail/python-dev/2005-June/054283.html>`__ - `Propose to close PEP 254 -- Making Classes Look More Like Types <http://mail.python.org/pipermail/python-dev/2005-June/054357.html>`__ - `Propose to reject PEP 265 -- Sorting Dictionaries by Value <http://mail.python.org/pipermail/python-dev/2005-June/054262.html>`__ - `Propose to reject PEP 276 -- Simple iterator for ints <http://mail.python.org/pipermail/python-dev/2005-June/054276.html>`__ - `Propose to reject PEP 281 -- Loop Counter Iteration with range and xrange <http://mail.python.org/pipermail/python-dev/2005-June/054263.html>`__ - `Propose to reject PEP 294 -- Type Names in the types Module <http://mail.python.org/pipermail/python-dev/2005-June/054353.html>`__ - `Propose to reject PEP 313 -- Adding Roman Numeral Literals to Python <http://mail.python.org/pipermail/python-dev/2005-June/054278.html>`__ - `Propose to reject PEP 336 -- Make None Callable <http://mail.python.org/pipermail/python-dev/2005-June/054280.html>`__ - `Propose updating PEP 284 -- Integer for-loops <http://mail.python.org/pipermail/python-dev/2005-June/054316.html>`__ - `Question about PEP 330 -- Python Bytecode Verification <http://mail.python.org/pipermail/python-dev/2005-June/054354.html>`__ - `Request to rewrite PEP 206 <http://mail.python.org/pipermail/python-dev/2005-June/054287.html>`__ - `Recommend accepting PEP 312 -- Simple Implicit Lambda <http://mail.python.org/pipermail/python-dev/2005-June/054303.html>`__ - `Is PEP 237 final -- Unifying Long Integers and Integers <http://mail.python.org/pipermail/python-dev/2005-June/054305.html>`__ [TAM] ------------------------------------------- PEP 342: Coroutines via Enhanced Generators ------------------------------------------- Raymond Hettinger withdrew `PEP 288`_, since the exception-handling part is now covered in `PEP 343`_ and the generator-attributes part was never very popular. Though he seemed to think `PEP 342`_ could replace the generator-attributes part, he was concerned that `PEP 342`_ was proposing too extensive a set of changes, as it modified the basic for-loop and continue statement semantics, and created a split between new- and old-style iterators. As a result of those comments, Phillip J. Eby took over `PEP 342`_, eliminated the continue expression and modification of the for-loop, added some motivating examples, and provided a `prototype patch`_ implementing the proposal. `PEP 342`_ now retains normal Python for-loop and continue statements, and does not introduce a new iterator protocol. Instead, it modifies the generator-iterator type by adding the methods: - send(value) which acts like the previously proposed single-argument form of next(). (Introducing a new method instead of overloading next() minimizes overhead for simple next() calls.) Calling send(value) before the generator has advanced to the first yield-expression raises a TypeError. - throw() which injects exceptions at the point of the generator's last yield-expression. - close() which injects a GeneratorExit exception into the generator to make sure that it terminates. PEP 342 also attempts to ensure that this close() method will be called when a generator-iterator is garbage-collected. Additionally, Phillip's patch addressed some garbage collection issues, having generators set their gi_frame to None when they finish, and modifying gcmodule.c to check for tp_del methods on instance objects (instead of just on heap types) so that the close() methods of generators would be properly invoked. The revised PEP was accepted by Guido at EuroPython. .. _PEP 288: http://www.python.org/peps/pep-0288.html .. _PEP 342: http://www.python.org/peps/pep-0342.html .. _PEP 343: http://www.python.org/peps/pep-0343.html .. _prototype patch: http://python.org/sf/1223381 Contributing Threads: - `Withdrawn PEP 288 and thoughts on PEP 342 <http://mail.python.org/pipermail/python-dev/2005-June/054261.html>`__ - `Implementing PEP 342 (was Re: Withdrawn PEP 288 and thoughts on PEP 342) <http://mail.python.org/pipermail/python-dev/2005-June/054309.html>`__ - `gcmodule issue w/adding __del__ to generator objects <http://mail.python.org/pipermail/python-dev/2005-June/054334.html>`__ - `Generator enhancements patch available <http://mail.python.org/pipermail/python-dev/2005-June/054337.html>`__ [SJB] -------------------------------------------------- Adding Jason Ordenorff's path module to the stdlib -------------------------------------------------- Reinhold Birkenfeld suggested that Jason Ordenorff's `path module`_ should be in the standard library as it has a large user base, frequently c.l.py praises, is a superior interface to OS paths than the existing os.path module, and could more easily be made to properly support unicode paths. Phillip J. Eby reviewed the module and made a list of suggested changes, primarily changing so that there is only one way to do things and clearing up naming confusion between the module and the existing os.path module, but was generally in favour of inclusion. The suggestion was to call the object either "path" or "Path" and put it either in the os module or os.path module, although Guido vetoed os.path.path and Tony Meyer begged for more differentiation between the path class and path module than a single character's case. Early enthusiasm suggested that a PEP wasn't needed to include the module, as there was general agreement about the inclusion and all but minor details. Guido disagreed, however, asking whether there was a need for a completely different mechanism for doing the same things that os.path already does, and inevitable disgreements about details (e.g. time in seconds, or a datetime object?) reinforced the need for a PEP. Discussion was still continuing at the end of the summary period; a PEP seems the likely outcome. .. _path module: http://www.jorendorff.com/articles/python/path/ Contributing Thread: - `Adding the 'path' module (was Re: Some RFE for review) <http://mail.python.org/pipermail/python-dev/2005-June/054439.html>`__ [TAM] ------------------------------- PEP 304 searches for a champion ------------------------------- Skip Montanaro wrote `PEP 304`_ ("Controlling Generation of Bytecode Files") a couple of years ago, and has mostly sat idle other than minor updates. Skip has no personal use for the PEP, and can't offer championing for it than continuing to respond to people's inputs. He asked whether anyone would be willing to take up championship of the PEP, or if it could be rejected. There were a couple of people interested in the idea, but no-one has yet volunteered to take the PEP from Skip. .. _PEP 304: http://www.python.org/peps/pep-0304.html Contributing Threads: - `PEP 304 - is anyone really interested? <http://mail.python.org/pipermail/python-dev/2005-June/054419.html>`__ - `PEP 304 "Controlling Generation of Bytecode Files" - patch updated <http://mail.python.org/pipermail/python-dev/2005-June/054264.html>`__ [TAM] ------------------------- Merging float and Decimal ------------------------- Fredrik Johansson suggested that Python floats and decimal.Decimal objects should be merged together much in the way that Python ints and longs have been. The idea would be that a binary or decimal represenation could be selected at runtime using a context object like decimal.Context. This would allow code like:: >>> from __future__ import new_float_behaviour >>> 1.1 1.1 >>> import sys >>> sys.float_context.binary = True >>> 1.1 1.1000000000000001 One issue would be the extent to which various context settings could be respected for both binary and decimal floating-point numbers. Since binary floating-point numbers would be represented using C floats, they would not have direct access to the traps and flags that decimal.Decimal floats do because these signals are not available in C. This issue could possibly be addressed by maintaining platform-dependent code for accessing traps and flags. People seemed generally to agree with the proposal, with Raymond Hettinger suggesting a roadmap: first move decimal.Decimal objects to C code, next introduce decimal literals such as 123.45d, and then perhaps use decimal floating-point numbers as the default in Python 3.0. Contributing Thread: - `Decimal floats as default (was: discussion about PEP239 and 240) <http://mail.python.org/pipermail/python-dev/2005-June/054409.html>`__ [SJB] ------------------------------------------------ API differences between builtin set and sets.Set ------------------------------------------------ Barry Warsaw noted that builtin set objects (unlike sets.Set objects) do not have .union_update() methods as aliases for their .update() methods. He also pointed out that the documentation for builtin set objects does not cover the .update() method, and wrongly indicates that the set methods only accept sequences, not iterables. Raymond Hettinger pointed-out that dropping union_update() from the API was an intentional design decision that was be discussed prior to release. At Barry's suggestion, Raymond expanded the docs to include a detailed list of differences between the set builtins and the sets module. The list is thankfully short. Contributing Thread: - `Inconsistent API for sets.Set and build-in set <http://mail.python.org/pipermail/python-dev/2005-June/054518.html>`__ [SJB] ---------------------------------- Using the alternate form of iter() ---------------------------------- In the dowhile threads, Jp Calderone pointed out a useful case for the alternate form of iter() which takes a no-argument function to call repeatedly, and a sentinel value to look for:: for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): f2.write(chunk) This started a brief discussion on how this very useful idiom could be made easier to read. I suggested that it would be nice if iter() had a signature like unittest.TestCase.assertRaises which accepts ``*args`` and ``**kwargs`` to be passed to the function when it is called. This would have to be a Python 3.0 change because it's backwards incompatible, but would look something like:: for chunk in iter('', f1.read, CHUNK_SIZE): f2.write(chunk) Benji York, Michael Hudson and James Y Knight suggested that functional.partial (which will be available in Python 2.5) is a more general solution because it does not require argument reordering and it can also be used in the occasional cases that require multiple callables:: for chunk in iter(partial(f1.read, CHUNK_SIZE), ''): f2.write(chunk) Raymond Hettinger suggested a Python 3.0 roadmap: the file API should evolve an iterblocks(size) method, and iteration patterns terminating with '' should all be replaced with modern iterators that terminate by raising StopIteration. Contributing Thread: - `iter alternate form and *args and **kwargs <http://mail.python.org/pipermail/python-dev/2005-June/054256.html>`__ [SJB] -------------------------------------- Adding lightweight cooperative threads -------------------------------------- Adam Olsen outlined various problems with the current state of Python threading (they are expensive, unpredictable, uninterupptible, fail silently, and have finely grained atomicity), and proposed adding lightweight cooperative threads to Python (including a new operator for threaded calls, and new statement for creating threads). The proposal received no support, however, with Adam pointed towards `Stackless Python`_ and greenlets from `the Py lib`_ as similar solutions that do not require modification of the language. `PEP 342`_ was also touted as a solution - the PEP includes a short (<50 lines) cooperative threading example. .. _Stackless Python: http://www.stackless.com/ .. _the Py lib: http://codespeak.net/py .. _PEP 342: http://www.python.org/peps/pep-0342.html Contributing Thread: - `Adding Python-Native Threads <http://mail.python.org/pipermail/python-dev/2005-June/054430.html>`__ [TAM] ------------------------------ Syntax for ignoring exceptions ------------------------------ Dmitry Dvoinikov proposed a shorthand for ignoring exceptions:: ignore TypeError: do stuff [else: do other stuff] which would replace:: try: do stuff except TypeError: pass [else: do other stuff] Most people seemed to think that generally the except and/or else clauses would be non-trivial, so the savings of two lines were not really worth the complications to the language. Contributing Thread: - `Explicitly declaring expected exceptions for a block <http://mail.python.org/pipermail/python-dev/2005-June/054387.html>`__ [SJB] ---------------------------------- Proposed new serialization format. ---------------------------------- Simon Wittber proposed a pre-PEP for `RFE 46738`_, to provide a safe, documented class for serialization of simple python types; however, many people commented that they felt that there were already sufficient serialization formats. Simon felt that they were all slow, bloated or unsafe, but wasn't able to convince anyone that there was a need for a new format. .. _RFE 46738: http://python.org/sf/467384 Contributing Thread: - `PEP for RFE 46738 (first draft) <http://mail.python.org/pipermail/python-dev/2005-June/054313.html>`__ [TAM] --------------------------------------- Behavior of subprocess.call(stdin=PIPE) --------------------------------------- In a followup to a `sourceforge patch`_, Stuart Bishop asked that subprocess.call() close the input stream if it receives the keyword argument stdin=PIPE. Since subprocess.call() creates a process and waits for it to complete before returning, the stdin pipe is never available to the caller and thus can never be written to while the process is running. Stuart suggested that if subprocess.call() closed the input stream when stdin=PIPE, subprocesses that incorrectly read from stdin would break out with an error immediately instead of hanging. While people seemed to agree that the current behavior of subprocess.call(stdin=PIPE) was mildly undesirable, there was disagreement as to the solution. Michael Chermside suggested that subprocess.call(stdin=PIPE) should raise an exception, while Peter Åstrand felt that keeping the subprocess.call() wrapper around subprocess.Popen() as simple as possible spoke against complicating it with error checking code. .. _sourceforge patch: http://www.python.org/sf/1220113 Contributing Thread: - `subprocess.call() and stdin <http://mail.python.org/pipermail/python-dev/2005-June/054405.html>`__ [SJB] =============== Skipped Threads =============== - `getch() in msvcrt does not accept extended characters. <http://mail.python.org/pipermail/python-dev/2005-June/054506.html>`__ - `Terminology for PEP 343 <http://mail.python.org/pipermail/python-dev/2005-June/054525.html>`__ - `List copy and clear (was Re: Inconsistent API for sets.Set and build-in set) <http://mail.python.org/pipermail/python-dev/2005-June/054522.html>`__ - `Multiple expression eval in compound if statement? <http://mail.python.org/pipermail/python-dev/2005-June/054164.html>`__ - `refcounting vs PyModule_AddObject <http://mail.python.org/pipermail/python-dev/2005-June/054232.html>`__ - `Some RFE for review <http://mail.python.org/pipermail/python-dev/2005-June/054438.html>`__ - `Please spread the word about OSCON early reg deadline <http://mail.python.org/pipermail/python-dev/2005-June/054259.html>`__ - `New python developer <http://mail.python.org/pipermail/python-dev/2005-June/054509.html>`__ - `Possible C API problem? <http://mail.python.org/pipermail/python-dev/2005-June/054471.html>`__ - `PyPI: no space left on device <http://mail.python.org/pipermail/python-dev/2005-June/054331.html>`__ - `PySWT -- Python binding of SWT using GCJ + SIP <http://mail.python.org/pipermail/python-dev/2005-June/054502.html>`__ - `Subclassing in 'C' <http://mail.python.org/pipermail/python-dev/2005-June/054434.html>`__ - `is type a usable feature? <http://mail.python.org/pipermail/python-dev/2005-June/054422.html>`__ - `misplaced PEP <http://mail.python.org/pipermail/python-dev/2005-June/054377.html>`__ - `using pyhon from the MSYS shell <http://mail.python.org/pipermail/python-dev/2005-June/054505.html>`__ - `[Python-checkins] python/dist/src/Lib Cookie.py, 1.17, 1.18 <http://mail.python.org/pipermail/python-dev/2005-June/054447.html>`__ - `[Python-checkins] python/dist/src/Tools/bgen/bgen bgenGenerator.py, 1.17, 1.18 bgenObjectDefinition.py, 1.29, 1.30 bgenType.py, 1.15, 1.16 bgenVariable.py, 1.6, 1.7 scantools.py, 1.37, 1.38 <http://mail.python.org/pipermail/python-dev/2005-June/054444.html>`__ - `floatobject.c 2.136 <http://mail.python.org/pipermail/python-dev/2005-June/054513.html>`__ ======== Epilogue ======== ------------ Introduction ------------ This is a summary of traffic on the `python-dev mailing list`_ from June 16, 2005 through June 30, 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). This is the sixth summary written by the python-dev summary cabal of Steve Bethard, Tim Lesher, and Tony Meyer. To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tim Lesher (tlesher 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 at 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. I 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 me 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/ .. _original text file: http://www.python.org/dev/summary/2005-06-16_2005-06-30.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

ZODB 3.2.9 final released
by Tim Peters July 8, 2005

July 8, 2005

I'm pleased to announce the release of ZODB 3.2.9 (final). This corresponds to the ZODB (and ZEO) that will ship with Zope 2.7.7 (final) this coming weekend. In addition to minor bugfixes, there is one critical bugfix in 3.2.9, concerning data consistency after a subtransaction commit. This was discovered by code inspection, and a test case showing the problem was constructed from that analysis. It's a subtle problem, and it remains unclear how frequently or severely the bug may have manifested in applications (apart from that it had no effect on applications that don't use subtransactions). See the NEWS file for details: http://zope.org/Products/ZODB3.2/NEWS You can download a source tarball or Windows installer from: http://zope.org/Products/ZODB3.2 Note that there are two Windows installers, one each for use with the Python 2.3 line (2.3.5 is recommended) and the Python 2.4 line (2.4.1 is recommended). Python 2.4 has not yet been certified for use with Zope, but Python 2.4.1 is supported for standalone ZODB/ZEO use. ZODB 3.2.9 can be used with Zopes in the 2.7 line, at or after Zope 2.7.3. Note that ZODB 3.2.9 does not support development on Zope 2.8 or Zope 3 (they moved on to the ZODB 3.4 and 3.5 lines, respectively).

1 0

Second Fredericksburg, VA ZPUG Meeting July 13
by Gary Poster July 8, 2005

July 8, 2005

Please join us July 13, 7:30-9:00 PM, for the second meeting of the Fredericksburg, VA Zope and Python User Group ("ZPUG"). Zac Bir, Zope Corporation Senior Software Engineer, will present on PyObjC. Further meetings are planned for the second Wednesday of every month. Location will be at the Zope Corporation offices. More information http://www.zope.org/Members/poster/ fxbgzpug_announce_2 and below. Hope to see you there! 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. Contact: Gary Poster (gary(a)zope.com) Second meeting information -------------------------------------- When: July 13, 7:30. Speaker: Zac Bir, Zope Corporation Senior Software Engineer. Topic: Python applications on Mac OS X with PyObjC (http:// pyobjc.sourceforge.net/) Lightning talk: Benji York, Zope Corporation Senior Software Engineer will present a lightning talk on reading parallel ports in Python, using a Super Nintendo game controller as an example.

1 0