Mailman 3 November 2005 - Python-announce-list

New: PPCEncoder 4 PocketPC
by Ivo＠textnews.nntp.hccnet.nl 18 Nov '05

18 Nov '05

I have written a nice Multimedia re-encoder (PPCEncoder) in Python. It re-encodes movies to PocketPC format. You can find it here: http://IvoNet.nl Greetz, Ivo. PS. I'm planning on making it OpenSource, but before I do that I want to clean up the code more. http://IvoNet.nl -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ----------------------------------------------

1 0

ANN: PyDO 2.0rc1
by Jacob Smullyan 17 Nov '05

17 Nov '05

I'm pleased to announce the release of PyDO-2.0rc1. What's New ---------- * If you pass in a module via the new "module" keyword argument of the project() method of PyDO objects and the autoschema function, the dynamically generated classes generated will be associated with that module so it can be pickled and unpickled. * several bugfixes, with corresponding tests. What it is ---------- PyDO is Drew Csillag's ORM (Object-Relational Mapper) database access library for Python that facilitates writing a Python database access layer. PyDO attempts to be simple, flexible, extensible, and unconstraining. PyDO 2 is a rewrite of the 1.x series distributed with SkunkWeb. It has several enhancements: * PyDO can now be used in multi-threaded or twisted-style asynchronous sitations, with or without a customizable connection pool. * PyDO objects are now dict subclasses, but also support attribute access to fields. * Projections -- subsets of the field list of a super-class -- are now supported by the PyDO.project() method. * Table attributes are now declared in a more concise way. * PyDO2 supports runtime table introspection. * Overall, the API has been tightened and the code restructured. PyDO 2 requires Python 2.4 or later. It currently supports PostgreSQL, MySQL, Sqlite, MSSQL, and Oracle. PyDO is dual GPL/BSD licensed. The source tarball is available at SkunkWeb's berlios site: https://developer.berlios.de/projects/skunkweb/ or, more directly: http://download.berlios.de/skunkweb/PyDO-2.0rc1.tar.gz or at the cheeseshop: http://cheeseshop.python/org/pypi/PyDO or install it with easy_install: easy_install PyDO Questions pertaining to PyDO can be addressed to the SkunkWeb mailing list at sourceforge: http://lists.sourceforge.net/lists/listinfo/skunkweb-list Cheers, Jacob Smullyan <smulloni(a)smullyan.org>

1 0

python-dev Summary for 2005-09-01 to 2005-09-15
by Tony Meyer 16 Nov '05

16 Nov '05

[Note: yes, this is *September*! All my (Tony's) bad, Steve has been chugging away at the summaries like he should have. Extra apologies for this one - it was approved by python-dev a while back, and I didn't realise that I hadn't done the python-list post.] python-dev Summary for 2005-09-01 through 2005-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-09-01_2005-09-15.html] ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- In the thread on the print statement, Charles Cazabon provided some nice imagery for Guido's Python 3.0 strategy. Our first QOTF is his comment about the print statement: It's an anomaly. It stands out in the language as a sore thumb waiting for Guido's hammer. We also learned something important about the evolution of Python thanks to Paul Moore. In the thread on the Python 3.0 executable name, Greg Ewing worried that if the Python 3.0 executable is named "py": Python 4.0 is going to just be called "p", and by the time we get to Python 5.0, the name will have vanished altogether! Fortunately, as Paul Moore explains in our second QOTF, these naming conventions are exactly as we should expect them: That's OK, by the time Python 5.0 comes out, it will have taken over the world and be the default language for everything. So omitting the name is exactly right :-) [SJB] Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055995.html>`__ - `Python 3 executable name <http://mail.python.org/pipermail/python- dev/2005-September/056377.html>`__ -------------------------------------------------- The "Swiss Army Knife (...Not)" API design pattern -------------------------------------------------- This fortnight saw a number of different discussions on what Guido's guiding principles are in making design decisions about Python. Guido introduced the "Swiss Army Knife (...Not)" API design pattern, which has been lauded by some as `the long-lost 20th principle from the Zen of Python`_. A direct quote from Guido: [I]nstead of a single "swiss-army-knife" function with various options that choose different behavior variants, it's better to have different dedicated functions for each of the major functionality types. This principle is the basis for pairs like str.split() and str.rsplit () or str.find() and str.rfind(). The goal is to keep cognitive overhead down by associating with each use case a single function with a minimal number of parameters. [SJB] .. _the long-lost 20th principle from the Zen of Python: http:// mail.python.org/pipermail/python-dev/2005-September/056228.html Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/056202.html>`__ - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/056228.html>`__ ------------------------ A Python-to-C++ compiler ------------------------ Mark Dufour announced `Shed Skin`_, an experimental Python-to-C++ compiler, which can convert many Python programs into optimized C++ code, using static type inference techniques. It works best for Python programs written in a relatively static C++-style; much work remains to be done, and Mark would like anyone interested in getting involved to contact him. Shed Skin was one of the recent `Google`_ `Summer of Code`_ projects. .. _Shed Skin: http://shedskin.sourceforge.net .. _Google: http://www.google.com .. _Summer of Code: http://code.google.com/summerofcode.html [TAM] Contributing thread: - `First release of Shed Skin, a Python-to-C++ compiler. <http:// mail.python.org/pipermail/python-dev/2005-September/056356.html>`__ -------------------------------------------------------------- python-checkins followups now stay on the python-checkins list -------------------------------------------------------------- In a follow-up to a `thread in early July`_, the python-checkins mailing list Reply-To header munging has been turned off. Previously, follow-ups to python-checkins would be addressed to python-dev; now, follow-ups will stay on the python-checkins list by default. .. _thread in early July: http://www.python.org/dev/summary/ 2005-07-01_2005-07-15.html#behavior-of-sourceforge-when-replying-to- python-checkins [TAM] Contributing thread: - `python-checkins reply-to <http://mail.python.org/pipermail/python- dev/2005-September/056428.html>`__ ========= Summaries ========= -------------------------------------------- Converting print to a function in Python 3.0 -------------------------------------------- In Python 3.0, Guido wants to change print from a statement to a function. Some of his motivation for this change: * Converting code that uses the print statement to instead use the logging package, a UI package, etc. is complicated because of the syntax. Parentheses, commas and >>s all behave differently in the print statement than they would in a function call. * Having print as a statement makes the language harder to evolve. For example, if it's determined that Python should gain printf behavior of some sort, adding this is harder -- as a statement, it would require the introduction of new syntax, as a function, it would feel like a second-class citizen compared to print. * Since the print statement always inserts spaces, code that doesn't want these spaces will often have to use a completely different style of formatting (e.g. using sys.stdout.write and/or string formatting) * Changing the behavior of statements is hard, while builtin functions can simply be replaced by setting an attribute of __builtin__. Guido's initial proposal suggested three methods to be adopted by all stream (file-like) objects:: stream.write(a1, a2, ...) equivalent to: map(stream.write, map(str, [a1, a2, ...])) stream.writeln(a1, a2, ...) equivalent to: stream.write(a1, a2, ..., "\n") stream.writef(fmt, a1, a2, ...) equivalent to: stream.write(fmt % (a1, a2, ...)) Additionally, three new builtins would appear, write(), writeln() and writef() which called the corresponding methods on sys.stdout. People had a number of problems with this initial proposal: * People make heavy use of the space-insertion behavior of the current print statement. With Guido's initial proposal, inserting spaces would require manually adding space characters, e.g. ``write (foo, " ", bar, " ", baz)``. * People want to keep the stream API simple. With Guido's initial proposal, all file-like objects would probably need to support these three new methods. (But see also `Deriving file-like object methods from read() and write()`_.) * People primarily (about 85% of the time) use the print statement to print complete lines. With Guido's initial proposal, the function to do this, writeln(), has the longer name than the less-frequently needed write(). There were a variety of proposals following Guido's that attempted to address the issues above, most of which were posted to the wiki_. They generally all proposed a function something like:: def print(*args): sys.stdout.write(' '.join(str(arg) for arg in args)) sys.stdout.write('\n') with support for a file= keyword parameter to specify a stream other than sys.stdout, and a sep= keyword parameter to specify a separator other than ' '. There was some discussion about how the final newline could be suppressed, including a nl= keyword parameter and the usage of the Ellipsis object (e.g. so that ``print(foo, bar, ...) `` would not print the final newline). There was also substantial support for a formatting variant like:: def printf(fmt, *args): print(fmt % args) In the end, Guido seemed to be leaning towards supporting three printing variants:: * print(...) would be much like the proposals above, calling str() on each argument and then printing them with spaces in between and a following newline * printraw(...) or printbare(...) would also call str() on each argument and print them, but with no intervening spaces and no final newline (c) printf(fmt, ...) would string-substitute the arguments into the format string and then write the format string Each of these functions would also accept a keyword parameter for specifying a stream other than sys.stdout. Because ``print`` is a keyword, ``from __future__ import printing`` would be required to use the new print() function. At this point, the thread trailed off, and no final decisions were made. [SJB] .. _wiki: http://wiki.python.org/moin/PrintAsFunction Contributing threads: - `Python 3 design principles <http://mail.python.org/pipermail/ python-dev/2005-September/055944.html>`__ - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055968.html>`__ - `New Wiki page - PrintAsFunction <http://mail.python.org/pipermail/ python-dev/2005-September/056081.html>`__ - `Hacking print (was: Replacement for print in Python 3.0) <http:// mail.python.org/pipermail/python-dev/2005-September/056125.html>`__ - `Pascaloid print substitute (Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-September/ 056171.html>`__ ---------------------------------- Making C code easier in Python 3.0 ---------------------------------- Nick Jacobson asked whether reference counting would be replaced in Python 3.0. Guido pointed out that the (CPython) implementation would have to be completely changed, and that isn't planned; many people also pointed out that reference counting is an implementation detail, not part of the language specification, and that there are other options that can be explored (e.g. `PyPy`_, `Jython`_, `IronPython`_). Arising from this question was a suggestion from Greg Ewing to build something akin to `Pyrex`_ (which takes care of reference count/ garbage collection issues automatically) into the standard Python distribution. This suggestion was met with general enthusiasm; some general discussion about which cases were most appropriate for Pyrex use (e.g. extension modules, wrapping C libraries, modules implemented in C for performance reasons) also followed. .. _PyPy: http://codespeak.net/pypy/ .. _Jython: http://www.jython.org/ .. _IronPython: http://www.ironpython.com/ .. _Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ [TAM] Contributing thread: - `reference counting in Py3K <http://mail.python.org/pipermail/ python-dev/2005-September/056215.html>`__ -------------------------- Multiple views of a string -------------------------- Tim Delaney suggested that str.partition could return 'views' of a string, rather than new string objects, as the substrings, to avoid the time needed to create strings that are potentially unused. Raymond Hettinger pointed out that the practical cost is unlikely to be significant, as the strings are likely to be empty, small, or used, and that all the pre-Python 2.5 methods would still be available for those times when they would be more appropriate. However, using string 'views' (objects that reference the 'parent' string, rather than copying the data) caught the imagination of several Python-dev'ers. Discussion ensued about how this object could work (Skip Montanaro threw together a sample implementation); towards the end it was pointed out that buffer() objects, with some additional string methods, could provide this slice-like instance with low memory requirements. Guido also mentioned `NSString`_, the NextStep string type used by `ObjC`_, which is fairly similar. .. _ObjC: http://en.wikipedia.org/wiki/Objc .. _NSString: http://developer.apple.com/documentation/Cocoa/ Reference/Foundation/ObjC_classic/Classes/NSString.html [TAM] Contributing threads: - `Proof of the pudding: str.partition() <http://mail.python.org/ pipermail/python-dev/2005-September/055924.html>`__ - `String views (was: Re: Proof of the pudding: str.partition()) <http://mail.python.org/pipermail/python-dev/2005-September/ 055933.html>`__ - `String views <http://mail.python.org/pipermail/python-dev/2005- September/055947.html>`__ ------------------------------- String-formatting in Python 3.0 ------------------------------- Currently, using ``%`` for string formatting has a number of inconvenient consequences: * precedence issues: ``"a%sa" % "b"*4`` produces ``'abaabaabaaba'``, not ``'abbbba'`` * special-cased tuples: ``"%s" % x`` produces a string representation of x *unless* x is a tuple (in which case it unpacks it, raising a TypeError if ``len(x) != 1``). * keyword formatting issues: a number of people have complained that ``%(myvar)s`` is much more complicated than it needs to be (hence string.Template's ``$myvar``). To address the first two issues, Raymond Hettinger proposed that string formatting become a builtin function, and others proposed that formatting become a method of str/unicode objects. Guido definitely agreed with the move from ``%`` to a callable, but it was unclear as to his preference for function or method. Nick Coghlan tried to address the ``%(myvar)s`` issue by exploring a few extensions to string.Template formatting. He produced a format() function where arguments could be specified either by position (e.g. $1, $2, etc.) or with keywords (e.g. $item, $quantity), and where the usual C-style format specifiers were still supported:: format("$item: $[0.2f]quantity", quantity=0.5, item='Bees') format("$1: $[0.2f]2", 'Bees', 0.5) Nick also briefly explored format specifiers for expanding iterables, but Guido disliked the idea, explaining that adding or removing a print from a program should not drastically change the program's behavior (as it might if a print accidentally consumed an iterable that you weren't done with). There was also some high-level discussion about internationalization concerns, where format strings need to be easy for translators to read and reorganize. Since word orders may change, having either keyword parameters or positional parameters (as in Nick's scheme) is crucial. Unfortunately, this discussion seemed to get lost in the massive `Converting print to a function in Python 3.0`_ discussion, and no decisions were made about either a formatting function or Nick's format specifier extensions. [SJB] Contributing threads: - `Replacement for print in Python 3.0 <http://mail.python.org/ pipermail/python-dev/2005-September/055979.html>`__ - `string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0) <http://mail.python.org/ pipermail/python-dev/2005-September/056163.html>`__ - `string formatting and i18n <http://mail.python.org/pipermail/ python-dev/2005-September/056191.html>`__ - `string.Template format enhancements (Re: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056231.html>`__ --------------------------------------------------------- Deriving file-like object methods from read() and write() --------------------------------------------------------- A variety of methods on the file object, including __iter__(), next (), readline(), readlines() and writelines(), are all derivable from the read() and write() methods. At least twice this fortnight, the issue was raised about making it easier for file-like objects to add the derivable methods if they've defined read() and write(). One suggestion was to provide a FileMixin class (like the DictMixin of UserDict) that other types could inherit from. This has the problem that the creator of the file-like object must determine at the time that the class is defined that it should support the additional methods. It is also more difficult to use mixin classes in C code (because multiple inheritance requires dealing with the type's metaclass). Fredrik Lundh suggested that something along the lines of `PEP 246`_'s object adaptation might be appropriate, but there was still some disagreement on the issue. [SJB] .. _PEP 246: http://www.python.org/peps/pep-0246.html Contributing threads: - `Mixin classes in the standard library <http://mail.python.org/ pipermail/python-dev/2005-September/056135.html>`__ - `Simplify the file-like-object interface (Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056218.html>`__ - `Simplify the file-like-object interface <http://mail.python.org/ pipermail/python-dev/2005-September/056229.html>`__ ------------------------------------ Making new-style classes the default ------------------------------------ Lisandro Dalcin proposed that something like:: from __future__ import new_style_classes be introduced to have newly defined classes implicitly derive from object. It was pointed out that this functionality is already available through the module-level statement:: __metaclass__ = type The argument was made that the __future__ version would be easier for non-experts to understand and to Google for, but Guido declared that the current syntax is fine -- there are much more important issues to be dealt with right now. [SJB] Contributing thread: - `PEP 3000 and new style classes <http://mail.python.org/pipermail/ python-dev/2005-September/056305.html>`__ -------------------------------------------------- Using __future__ to have builtins return iterators -------------------------------------------------- Lisandro Dalcin requested a __future__ import of some sort that would * make range() and zip() return iterators * remove xrange() * make the dict.keys(), dict.values(), dict.items() etc. methods return iterators Guido indicated that an alternate builtins module could be provided so that the first point could be covered with something like:: from future_builtins import zip, range However, there wasn't really a good way to change the dict methods. Simply importing a new dict object from "future_builtins" wouldn't solve the problem because using anyone's module that used the old dict object would mean a mix of the two types in your module. And since __future__ imports are intended to affect only the module which includes them, changing the builtin dict object globally would be inappropriate (as it would let an import in one module break code in another). [SJB] Contributing thread: - `PEP 3000 and iterators <http://mail.python.org/pipermail/python- dev/2005-September/056340.html>`__ ------------------------------------------------------------- Using compiled re methods vs. using module-level re functions ------------------------------------------------------------- After Michael Chermside commented that users should be encouraged to use the methods on compiled re objects instead of the re functions available at the module level (and after Stephen J. Turnbull promised to look into supplying such a documentation patch), there was a brief discussion about how much of a difference using the compiled re objects really makes. As it turns out, in the CPython implementation, the module-level functions cache the first 100 patterns, so in many cases, the only additional cost of using the module-level functions is a dictionary lookup. [SJB] Contributing thread: - `Revising RE docs <http://mail.python.org/pipermail/python-dev/2005- September/055938.html>`__ -------------------------------------- urlparse and urls with too many '../'s -------------------------------------- Fabien Schwob pointed out that urlparse.join() doesn't strip out any extraneous '..' directories (e.g. http://example.com/../index.html). While Guido indicated that he found the current behaviour acceptable, Jeff Epler pointed out that `RFC 2396`_ states that invalid URIs like this may be handled by removing the ".." segments from the resolved path (although this is an implementation detail). Armin Rigo indicated that, even if this is theoretically not a bug, a proposed patch with this motiviation would be welcome. .. _RFC 2396: http://www.faqs.org/rfcs/rfc2396.html [TAM] Contributing thread: - `bug in urlparse <http://mail.python.org/pipermail/python-dev/2005- September/056144.html>`__ ----------------------------------------------- Using an iterator instead of a tuple for \*args ----------------------------------------------- Nick Coghlan suggested that in Python 3.0, the \*args extended function call syntax should produce an iterator instead of a tuple as it currently does. That would mean that code like:: output(*some_long_iterator) would not load the entire iterator into a memory before processing it. I pointed him to a previous discussion Raymond Hettinger and I had about the subject that indicated that for \*args, sequences were preferable to iterators in a number of situations. Guido agreed, indicating that \*args will continue to be sequences in Python 3.0. [SJB] Contributing thread: - `iterators and extended function call syntax (WAS: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/ 2005-September/056109.html>`__ ---------------------------------------- Constructing traceback objects in Python ---------------------------------------- Contributing thread: - `Asynchronous use of Traceback objects <http://mail.python.org/ pipermail/python-dev/2005-September/056091.html>`__ ------------------------------- No dedent() methods for strings ------------------------------- Contributing thread: - `str.dedent <http://mail.python.org/pipermail/python-dev/2005- September/056412.html>`__ ------------------------ Arguments vs. parameters ------------------------ - `Term unification <http://mail.python.org/pipermail/python-dev/2005- September/056409.html>`__ ----------------------------------------------------------------------- Removing sequence support from the return value of stat() in Python 3.0 ----------------------------------------------------------------------- Terry J. Reedy proposed that, in Python 3.0, instead of os.stat() returning a sequence (where the order of the items is only of historical significance), a proper stat object be returned. This was met with general support, and so seems likely to occur. Skip Montanaro also proposed that the st_ prefixes in the attribute names be removed, since there are no namespace issues to be concerned with, which met with some approval, but concern from Guido that the forms with the prefixes would be more familiar to users, and make Googling or grepping simpler. [TAM] Contributing thread: - `stat() return value (was: Re: Proof of the pudding: str.partition ()) <http://mail.python.org/pipermail/python-dev/2005-September/ 055931.html>`__ -------------------------------------------------- Making code in the Tools directory more accessible -------------------------------------------------- Installation of Python typically doesn't include the Tools directory; combined with the lack of mention of these scripts in the documentation, this means that knowledge of these generally useful scripts is fairly limited. Tim Peters noted that historically a Tools directory was only added to the Windows installer if it was specifically requested; as such, the audiopy, bgen, compiler, faqwiz, framer, modulator, msi, unicode, and world Tools directories are not currently included in the Windows installer. Nick Coghlan added that Tools/README.txt isn't included in the Windows installer, so Windows users don't get a synopsis of the tools that are included; he also suggested that adding this readme to the "undocumented modules" section of the standard library would be a simple improvement. Non- windows users typically don't get the Tools directory at all with an install. Remaining questions included how the directory should be documented (e.g. man pages for the scripts, a documentation page for them), where to install them on non-Windows installations (e.g. /usr/share/ python, /usr/lib/pythonX.Y/Tools), and whether the Windows installer should include all of the directories. [TAM] Contributing thread: - `Tools directory (Was RE: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005-September/ 056318.html>`__ ---------------------------------- Responsiveness of IDLE development ---------------------------------- Noam Raphael posted a request for help getting a large patch to IDLE committed to CVS. He was concerned that there hasn't been any IDLE development recently, and that patches are not being considered. He indicated that his group was considering offering a fork of IDLE with the improvements, but that they would much prefer integrating the improvements into the core distribution. It was pointed out that a fork might be the best solution, for various reasons (e.g. the improvements may not be of general interest, the release time would be much quicker), and that this was how the current version of IDLE was developed. However, later on it turned out that Kurt Kaiser had missed the python-dev message, and when it was brought to his attention he moved the discussion to idle- dev, and it seems that everything will end happily and fork-less. [TAM] Contributing thread: - `IDLE development <http://mail.python.org/pipermail/python-dev/2005- September/056357.html>`__ ----------------------------- Speeding up list append calls ----------------------------- A `comp.lang.python message from Tim Peters`_ prompted Neal Norwitz to investigate how the code that Tim posted could be sped up. He hacked the code to replace var.append() with the LIST_APPEND opcode, and achieved a roughly 200% speed increase. Although this doesn't work in general, Neal wondered if it could be used as a peephole optimization when a variable is known to be a list. Martin v. Lˆwis suggested that the code could simply check whether it was a list; Phillip J. Eby and Fredrik Lundh pointed out that this is similar to what various math operators do (e.g. speeding up int + int calls). .. _comp.lang.python message from Tim Peters: http:// groups.google.com/group/comp.lang.python/msg/9075a3bc59c334c9 [TAM] Contributing thread: - `speeding up list append calls <http://mail.python.org/pipermail/ python-dev/2005-September/056396.html>`__ ------------------------------------ Allowing str.strip to remove "words" ------------------------------------ Jonny Reichwald proposed an enhancement to str.strip(). In addition to its current form, where it takes a string of characters to strip, to take any iterable containing either character lists or string lists, so that is is possible to remove entire words from the stripped string. For example:: #A char list gives the same result as the standard strip >>> my_strip("abcdeed", "de") 'abc' #A list of strings instead >>> my_strip("abcdeed", ("ed",)) 'abcde' #The char order in the strings to be stripped are of importance >>> my_strip("abcdeed", ("ad", "eb")) 'abcdeed' Raymond Hettinger queried whether there was actual demand for such a change, and whether such demand was sufficient to justify the added complexity; Josiah Carlson also pointed out that implementing this only requires a four-line function. Judging from the lack of responses, it seems likely that there isn't enough demand. Contributing thread: - `str.strip() enhancement <http://mail.python.org/pipermail/python- dev/2005-September/056119.html>`__ ================ Deferred Threads ================ - `C coding experiment <http://mail.python.org/pipermail/python-dev/ 2005-September/055965.html>`__ - `os.path.diff(path1, path2) <http://mail.python.org/pipermail/ python-dev/2005-September/056391.html>`__ =============== Skipped Threads =============== - `import exceptions <http://mail.python.org/pipermail/python-dev/ 2005-September/055926.html>`__ - `[Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 <http://mail.python.org/pipermail/python-dev/2005-September/ 055927.html>`__ - `setdefault's second argument <http://mail.python.org/pipermail/ python-dev/2005-September/055929.html>`__ - `Alternative imports (Re: Python 3 design principles) <http:// mail.python.org/pipermail/python-dev/2005-September/055945.html>`__ - `python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 <http:// mail.python.org/pipermail/python-dev/2005-September/055963.html>`__ - `Status of PEP 328 <http://mail.python.org/pipermail/python-dev/ 2005-September/055969.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/ python-dev/2005-September/055978.html>`__ - `itertools.chain should take an iterable ? <http://mail.python.org/ pipermail/python-dev/2005-September/055981.html>`__ - `partition() (was: Remove str.find in 3.0?) <http://mail.python.org/ pipermail/python-dev/2005-September/055983.html>`__ - `gdbinit problem <http://mail.python.org/pipermail/python-dev/2005- September/056178.html>`__ - `Exception Reorg PEP checked in <http://mail.python.org/pipermail/ python-dev/2005-September/056296.html>`__ - `international python <http://mail.python.org/pipermail/python-dev/ 2005-September/056326.html>`__ - `SIGPIPE => SIG_IGN? <http://mail.python.org/pipermail/python- dev/2005-September/056341.html>`__ - `[draft] python-dev Summary for 2005-08-16 through 2005-08-31 <http://mail.python.org/pipermail/python-dev/2005-September/ 056348.html>`__ - `[Python-checkins] python/dist/src/Lib urllib.py, 1.169, 1.170 <http://mail.python.org/pipermail/python-dev/2005-September/ 056349.html>`__ - `Wanting to learn <http://mail.python.org/pipermail/python-dev/2005- September/056350.html>`__ - `Python code.interact() and UTF-8 locale <http://mail.python.org/ pipermail/python-dev/2005-September/056361.html>`__ - `pygettext() without newlines (Was: Re: Replacement for print in Python 3.0) <http://mail.python.org/pipermail/python-dev/2005- September/056368.html>`__ - `Python 3 executable name (was: Re: PEP 3000 and iterators) <http:// mail.python.org/pipermail/python-dev/2005-September/056369.html>`__ - `Python 3 executable name <http://mail.python.org/pipermail/python- dev/2005-September/056371.html>`__ - `Skiping searching throw dictionaries of mro() members. <http:// mail.python.org/pipermail/python-dev/2005-September/056403.html>`__ - `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 <http://mail.python.org/pipermail/python-dev/2005- September/056405.html>`__ - `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3 <http://mail.python.org/pipermail/ python-dev/2005-September/056406.html>`__ - `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 <http:// mail.python.org/pipermail/python-dev/2005-September/056419.html>`__ - `Variant of removing GIL. <http://mail.python.org/pipermail/python- dev/2005-September/056423.html>`__ - `Compatibility between Python 2.3.x and Python 2.4.x <http:// mail.python.org/pipermail/python-dev/2005-September/056431.html>`__ - `Example for "property" violates "Python is not a one pass compiler" <http://mail.python.org/pipermail/python-dev/2005-September/ 056190.html>`__ - `python optimization <http://mail.python.org/pipermail/python-dev/ 2005-September/056425.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2005 through September 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). This is the 3rd summary written by the python-dev summary pairing of Steve Bethard and Tony Meyer (Tempus Fugit!). 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-07-16_2005-07-31.html .. _original text file: http://www.python.org/dev/summary/ 2005-09-01_2005-09-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

ANNOUNCE: Ice 3.0 released
by Marc Laukien 16 Nov '05

16 Nov '05

ZeroC, Inc. is pleased to announce the availability of the Internet Communications Engine (Ice), version 3.0.0. For a detailed description of Ice, please have a look at http://www.zeroc.com/ice.html. The most significant change since version 2.1.2 is the addition of IceGrid, a replacement for the IcePack activation service that revolutionizes the way you build and deploy your Ice applications. With support for replication, load balancing, and application distribution, IceGrid provides the tools you need to create scalable grid applications and manage them remotely. For more information on IceGrid, please see http://www.zeroc.com/icegrid/index.html. As you have come to expect, this release also includes a great deal of smaller enhancements and fixes that improve the reliability of your programs and help you get them to market faster. In addition to traditional proprietary licensing models for commercial customers, Ice is also freely available as Open Source under the terms of the GNU General Public License (GPL). You can download the complete Ice source and documentation from http://www.zeroc.com/download.html.

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Nov 16)
by Cameron Laird 15 Nov '05

15 Nov '05

QOTW: "You can tell everything is well in the world of dynamic languages when someone posts a question with nuclear flame war potential like 'python vs. ruby' and after a while people go off singing hymns about the beauty of Scheme..." - vdrab "ctypes completely rocks." - Grant Edwards Michael Lange endows Tkinter with a Tree widget: http://mail.python.org/pipermail/tkinter-discuss/2005-November/000556.html Fuzzyman has written a valuable commentary on urllib2. How do we collectively get a reference to this in the tutorial and/or library reference? http://www.voidspace.org.uk/python/articles/urllib2.shtml What *is* good style for Pythonic symbolic constants? http://groups.google.com/group/comp.lang.python/browse_thread/thread/f09d1d… Diez Roggisch and others describe typical limits to the powers of GUI toolkits, and hint at ways to circumvent those limits: http://groups.google.com/group/comp.lang.python/browse_thread/thread/75ac35… Edgewall Software arranges the tutorial on a tree some readers find convenient: http://projects.edgewall.com/python-sidebar/html/toc-tutorial.html Ben Finney asks serious questions about code re-use: http://groups.google.com/group/comp.lang.python/browse_thread/thread/23dbb1… We're still a long way from knowing how to manage memory well, and certainly it's an opaque issue during software development. Here's what's known: http://groups.google.com/group/comp.lang.python/browse_thread/thread/da4d11… ======================================================================== 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… 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

ANN: Object Shell -- osh 0.6
by Jack Orenstein 15 Nov '05

15 Nov '05

In a Unix shell, you can run a series of commands, connecting the output of one command with the input to the next command using pipes. The information passed from one command to the next is normally organized into lines of text. Tools such as awk and sed are designed to extract and transform information from these lines. It would be much simpler if the data passed between commands was organized into objects. Osh is based on this idea. Because osh is based on Python, it is Python objects that are passed between commands, and Python functions are used to manipulate objects. Osh is licensed under the GPL. For more information and for downloads: http://geophile.com/osh. Jack Orenstein

1 0

ANN: ActivePython 2.4.2 is now available
by TrentM＠ActiveState.com 15 Nov '05

15 Nov '05

I'm happy to announce that ActivePython 2.4.2 is now available for free download from: http://www.ActiveState.com/Products/ActivePython/ This release updates ActivePython to version 2.4.2, that was finalized a few weeks ago. My apologies for the tardiness. If you'll believe it, I've been busy implementing *Ruby* AutoComplete in Komodo. One thing you may not have noticed is that ActivePython has added support for a number of platforms in the past months. Installers are available for the following operating systems and architectures: - Windows/x86 - Mac OS X/powerpc (new) - Linux/x86 - Solaris/SPARC - Solaris/x86 (new) - AIX/powerpc (new) - HP-UX/PA-RISC (new) We would welcome any and all feedback to: ActivePython-feedback(a)ActiveState.com Please file bugs against ActivePython at: http://bugs.ActiveState.com/ActivePython What is ActivePython? --------------------- ActivePython is ActiveState's quality-assured binary distribution of Python. Builds for AIX, HP-UX, Linux, Mac OS X, Solaris, and Windows are made freely available. ActivePython includes the Python core and core extensions (zlib 1.2.3, bzip2 1.0.2, bsddb 4.2.52, Tk 8.4.9, and Tix 8.1.4) and is fully compatible with other Python distributions of the same version. ActivePython also includes a wealth of Python documentation, including: - the core Python docs; - Andrew Kuchling's "What's New in Python" series; - the Non-Programmer's Tutorial for Python; - Mark Pilgrim's excellent "Dive into Python"; and - a snapshot of the Python FAQs, HOWTOs, and PEPs. An online version of the docs can be found here: http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/welcome.html Extra Bits ---------- ActivePython releases also include the following packages: - Windows "debug" package: Debug-built binaries for ActivePython users building debug versions of their binary Python extensions. - ActivePython24.chm: An MS compiled help collection of the full ActivePython documentation set. Linux users of applications such as xCHM might find this useful. This package is installed by default on Windows. These packages are available from: ftp://ftp.activestate.com/ActivePython/etc/ Thanks, and enjoy! Trent, Python Tech Lead -- Trent Mick TrentM(a)ActiveState.com

1 0

PyPy sprint announcement: Gothenburg 7th - 11th December 2005
by Carl Friedrich Bolz 15 Nov '05

15 Nov '05

Gothenburg PyPy Sprint II: 7th - 11th December 2005 ====================================================== (NOTE: internal EU-only sprint starts on the 5th!) The next PyPy sprint is scheduled to be in December 2005 in Gothenborg, Sweden. Its main focus is heading towards phase 2, which means JIT work, alternate threading models and logic programming (but there are also other possible topics). We'll give newcomer-friendly introductions. To learn more about the new PyPy Python-in-Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint ------------------------------ We have released pypy-0.8.0_, which is officially a "research base" for future work. The goal of the Gothenburg sprint is to start exploring new directions and continue in the directions started at the Paris sprint. The currently scheduled main topics are: - The L3 interpreter, a small fast interpreter for "assembler-level" flow graphs. This is heading towards JIT work. - Stackless: write an app-level interface, which might be either Tasklets, as in "Stackless CPython", or the more limited Greenlets. - Porting C modules from CPython. (_socket is not finished) - Optimization/debugging work in general. In particular our thread support is far from stable at the moment and unaccountably slow. - Experimentation: logic programming in Python. A first step might be to try to add logic variables to PyPy. .. _`pypy-0.8.0`: http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html Location & Accomodation ------------------------ The sprint will be held in the apartment of Laura Creighton and Jacob Halen which is in Gotabergsgatan 22. The location is central in Gothenburg. It is between the tram_ stops of Vasaplatsen and Valand, where many lines call. .. _tram: http://www.vasttrafik.se Probably cheapest and not too far away is to book accomodation at `SGS Veckobostader`_. (You can have a 10% discount there; ask in the pypy-sprint mailing list for details. We also have some possibilites of free accomodation.) .. _`SGS Veckobostader`: http://www.sgsveckobostader.com Exact times ----------- The public PyPy sprint is held Wednesday 7th - Sunday 11th December 2005. There is a sprint for people involved with the EU part of the project on the two days before the "official" sprint. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. In the middle of the sprint there usually is a break day and it's usually ok to take half-days off if you feel like it. Network, Food, currency ------------------------ Sweden is not part of the Euro zone. One SEK (krona in singular, kronor in plural) is roughly 1/10th of a Euro (9.15 SEK to 1 Euro). The venue is central in Gothenburg. There is a large selection of places to get food around, from edible-and-cheap to outstanding. You normally need a wireless network card to access the network, but we can provide a wireless/ethernet bridge. Sweden uses the same kind of plugs as Germany. 230V AC. Registration etc.pp. -------------------- Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Gothenburg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/gothenburg-2005/people.txt .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`Gothenburg people`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2005/people.html

1 0

Data Plotting Library DISLIN 9.0
by Helmut Michels 15 Nov '05

15 Nov '05

I am pleased to announce version 9.0 of the data plotting software DISLIN. DISLIN is a high-level and easy to use plotting library for displaying data as curves, bar graphs, pie charts, 3D-colour plots, surfaces, contours and maps. Several output formats are supported such as X11, VGA, PostScript, PDF, CGM, WMF, HPGL, TIFF, GIF, PNG, BMP and SVG. The software is available for several C, Fortran 77 and Fortran 90 compilers. Plotting extensions for the interpreting languages Perl, Python and Java are also supported for the most operating systems. DISLIN distributions and manuals in PDF, PostScript and HTML format are available from the DISLIN home page http://www.dislin.de and via FTP from the server ftp://ftp.gwdg.de/pub/grafik/dislin All DISLIN distributions are free for non-commercial use. ------------------- Helmut Michels Max Planck Institute for Solar System Research Phone: +49 5556 979-334 Max-Planck-Str. 2 Fax : +49 5556 979-240 D-37191 Katlenburg-Lindau Mail : michels(a)mps.mpg.de

1 0

SnakeCard GPL products
by Philippe C. Martin 14 Nov '05

14 Nov '05

Dear all, I have decided to focus my activities on development and support. I have released SnakeCard's produt line source code under the GPL licence www.snakecard.com) It includes: SCF: SnakeCard Framework (software=Python) SCFB: SnaleCard Framework Bundle (software=Python, applets BasicCard T=1, JavaCard T=0) SCALS: (software: Python (core), VB6 (GUI), C++ (GINA DLL), applets BasicCard T=1, JavaCard T=0) SC PCSC Server(software=Python) School and Corporate IDs: Python (core), wxWidget (GUI), applets BasicCard T=1, JavaCard T=0) Regards, Philippe -- ************************************* Philippe C. Martin SnakeCard, LLC www.snakecard.com *************************************

1 0