Mailman 3 April 2006 - Python-Dev

base64 module
by Sanghyeon Seo 18 May '06

18 May '06

Hello, base64 module documentation for b64decode function says, "TypeError is raised if s were incorrectly padded or if there are non-alphabet characters present in the string." But this doesn't seem to be the case. Testcase: import base64 base64.b64decode('%') Since % is a non-alphabet character, this should raise TypeError (btw, shouldn't this be ValueError instead?), but Python 2.4.3 silently ignores. I found this while experimenting with IronPython. IronPython 1.0 Beta 5 gives: Traceback (most recent call last): File base64, line unknown, in b64decode SystemError: cannot decode byte: '%' It's not TypeError, but it doesn't silently ignore either. Seo Sanghyeon

13 33

2.5 open issues
by Neal Norwitz 10 May '06

10 May '06

If you are addressed on this message, it means you have open issues that need to be resolved for 2.5. Some of these issues are documentation, others are code issues. This information comes from PEP 356. The best way to get me to stop bugging you is to close out these tasks. :-) Who is the owner for getting new icons installed with the new logo? Code issues: +++++++++++ Fred, Fredrik, Martin: xmlplus/xmlcore situation re: ElementTree Jeremy: AST compiler issues We should really try to get these resolved soon, especially the XML issue since that could result in some sort of API change. The AST issues should just be bug fixes AFAIK. Documentation missing: +++++++++++++++++++ Fredrik: ElementTree Gerhard: pysqlite Martin: msilib Thomas: ctypes Thomas, I know you checked in some ctypes docs. Is that everything or is there more coming? It seemed pretty short given the size of ctypes. If you don't expect to have time to finish these tasks, then it's your job to find someone else who will. n

11 19

Raising objections (was: setuptools in the stdlib)
by Neal Norwitz 09 May '06

09 May '06

On 4/18/06, M.-A. Lemburg <mal(a)egenix.com> wrote: > Phillip J. Eby wrote: > > As for discussion, Guido originally brought up the question here a few > > months ago, and it's been listed in PEP 356 for a while. I've also > > posted things related to the inclusion both here and in distutils-sig. > > I know, but the discussions haven't really helped much in > getting the setuptools design compatible with standard > distutils. I'm glad to see the discussions taking place; better late than never. However, I think we need to do a better job raising objections earlier. I'm not sure how to do this, but one way is to use PEPs. There is an outstanding issues section in the 2.5 release PEP 356. In this case, perhaps it would have been good to add a bullet item there. I've been trying to ensure the issues aren't lost. There's only one item in the list that still needs addressing (Fred, you listening? You had an idea for solving the problem). I plan to start a 2.6 release schedule PEP soon (before 2.5 is released). It will mostly be a place holder/boilerplate until it can be filled out when a major feature is implemented, a PEP accepted, or outstanding issue raised. The PEP should be updated by a committer when any of those occur. If anyone has better ideas how to ensure the issues aren't lost and are addressed, I'd like to know. n

17 69

PEP 3102: Keyword-only arguments
by Talin 08 May '06

08 May '06

PEP: 3102 Title: Keyword-Only Arguments Version: $Revision$ Last-Modified: $Date$ Author: Talin <talin at acm.org> Status: Draft Type: Standards Content-Type: text/plain Created: 22-Apr-2006 Python-Version: 3.0 Post-History: Abstract This PEP proposes a change to the way that function arguments are assigned to named parameter slots. In particular, it enables the declaration of "keyword-only" arguments: arguments that can only be supplied by keyword and which will never be automatically filled in by a positional argument. Rationale The current Python function-calling paradigm allows arguments to be specified either by position or by keyword. An argument can be filled in either explicitly by name, or implicitly by position. There are often cases where it is desirable for a function to take a variable number of arguments. The Python language supports this using the 'varargs' syntax ('*name'), which specifies that any 'left over' arguments be passed into the varargs parameter as a tuple. One limitation on this is that currently, all of the regular argument slots must be filled before the vararg slot can be. This is not always desirable. One can easily envision a function which takes a variable number of arguments, but also takes one or more 'options' in the form of keyword arguments. Currently, the only way to do this is to define both a varargs argument, and a 'keywords' argument (**kwargs), and then manually extract the desired keywords from the dictionary. Specification Syntactically, the proposed changes are fairly simple. The first change is to allow regular arguments to appear after a varargs argument: def sortwords(*wordlist, case_sensitive=False): ... This function accepts any number of positional arguments, and it also accepts a keyword option called 'case_sensitive'. This option will never be filled in by a positional argument, but must be explicitly specified by name. Keyword-only arguments are not required to have a default value. Since Python requires that all arguments be bound to a value, and since the only way to bind a value to a keyword-only argument is via keyword, such arguments are therefore 'required keyword' arguments. Such arguments must be supplied by the caller, and they must be supplied via keyword. The second syntactical change is to allow the argument name to be omitted for a varargs argument: def compare(a, b, *, key=None): ... The reasoning behind this change is as follows. Imagine for a moment a function which takes several positional arguments, as well as a keyword argument: def compare(a, b, key=None): ... Now, suppose you wanted to have 'key' be a keyword-only argument. Under the above syntax, you could accomplish this by adding a varargs argument immediately before the keyword argument: def compare(a, b, *ignore, key=None): ... Unfortunately, the 'ignore' argument will also suck up any erroneous positional arguments that may have been supplied by the caller. Given that we'd prefer any unwanted arguments to raise an error, we could do this: def compare(a, b, *ignore, key=None): if ignore: # If ignore is not empty raise TypeError As a convenient shortcut, we can simply omit the 'ignore' name, meaning 'don't allow any positional arguments beyond this point'. Function Calling Behavior The previous section describes the difference between the old behavior and the new. However, it is also useful to have a description of the new behavior that stands by itself, without reference to the previous model. So this next section will attempt to provide such a description. When a function is called, the input arguments are assigned to formal parameters as follows: - For each formal parameter, there is a slot which will be used to contain the value of the argument assigned to that parameter. - Slots which have had values assigned to them are marked as 'filled'. Slots which have no value assigned to them yet are considered 'empty'. - Initially, all slots are marked as empty. - Positional arguments are assigned first, followed by keyword arguments. - For each positional argument: o Attempt to bind the argument to the first unfilled parameter slot. If the slot is not a vararg slot, then mark the slot as 'filled'. o If the next unfilled slot is a vararg slot, and it does not have a name, then it is an error. o Otherwise, if the next unfilled slot is a vararg slot then all remaining non-keyword arguments are placed into the vararg slot. - For each keyword argument: o If there is a parameter with the same name as the keyword, then the argument value is assigned to that parameter slot. However, if the parameter slot is already filled, then that is an error. o Otherwise, if there is a 'keyword dictionary' argument, the argument is added to the dictionary using the keyword name as the dictionary key, unless there is already an entry with that key, in which case it is an error. o Otherwise, if there is no keyword dictionary, and no matching named parameter, then it is an error. - Finally: o If the vararg slot is not yet filled, assign an empty tuple as its value. o For each remaining empty slot: if there is a default value for that slot, then fill the slot with the default value. If there is no default value, then it is an error. In accordance with the current Python implementation, any errors encountered will be signaled by raising TypeError. (If you want something different, that's a subject for a different PEP.) Backwards Compatibility The function calling behavior specified in this PEP is a superset of the existing behavior - that is, it is expected that any existing programs will continue to work. Copyright This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

23 65

Visual studio 2005 express now free
by Guido van Rossum 08 May '06

08 May '06

Microsoft just announced that Visual Studio 2005 express will be free forever, including the IDE and the optimizing C++ compiler. (Not included in the "forever" clause are VS 2007 or later versions.) Does this make a difference for Python development for Windows? http://msdn.microsoft.com/vstudio/express/ -- --Guido van Rossum (home page: http://www.python.org/~guido/)

11 20

Any reason that any()/all() do not take a predicate argument?
by Mikhail Glushenkov 02 May '06

02 May '06

Hi, sorry if this came up before, but I tried searching the archives and found nothing. It would be really nice if new builtin truth functions in 2.5 took a predicate argument(defaults to bool), so one could write, for example: seq = [1,2,3,4,5] if any(seq, lambda x: x==5): ... which is clearly more readable than reduce(seq, lambda x,y: x or y==5, False) IIRC, something like that is called junctions in Perl 6.

7 9

Adding functools.decorator
by Nick Coghlan 02 May '06

02 May '06

Collin Winters has done the work necessary to rename PEP 309's functional module to functools and posted the details to SF [1]. I'd like to take that patch, tweak it so the C module is built as _functools rather than functools, and then add a functools.py consisting of: from _functools import * # Pick up functools.partial def _update_wrapper(decorated, func, deco_func): # Support naive introspection decorated.__module__ = func.__module__ decorated.__name__ = func.__name__ decorated.__doc__ = func.__doc__ decorated.__dict__.update(func.__dict__) # Provide access to decorator and original function decorated.__decorator__ = deco_func decorated.__decorates__ = func def decorator(deco_func): """Wrap a function as an introspection friendly decorator function""" def wrapper(func): decorated = deco_func(func) if decorated is func: return func _update_wrapper(decorated, func, deco_func) return decorated # Manually make this decorator introspection friendly _update_wrapper(wrapper, deco_func, decorator) return wrapper After typing those four lines of boilerplate to support naive introspection out in full several times for contextlib related decorators, I can testify that doing it by hand gets old really fast :) Some details that are up for discussion: - which of a function's special attributes should be copied/updated? - should the __decorates__ and __decorator__ attributes be added? If people are happy with this idea, I can make sure it happens before alpha 3. Cheers, Nick. [1] http://www.python.org/sf/1478788 -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

5 7

More on contextlib - adding back a contextmanager decorator
by Nick Coghlan 02 May '06

02 May '06

A few things from the pre-alpha2 context management terminology review have had a chance to run around in the back of my head for a while now, and I'd like to return to a topic Paul Moore brought up during that discussion. Paul had a feeling there should be two generator decorators in contextlib - one for __context__ methods and one for standalone generator functions. However, contextfactory seemed to meet both needs, so we didn't follow the question up for alpha 2. The second link in this chain is the subsequent discussion with Guido about making the context manager and managed context protocols orthogonal. With this clearer separation of the two terms to happen in alpha 3, it becomes more reasonable to have two different generator decorators, one for defining managed contexts and one for defining context managers. The final link is a use case for such a context manager decorator, in the form of a couple of HTML tag example contexts in the contextlib documentation. (contextlib.nested is also a good use case, where caching can be used to ensure certain resources are always acquired in the same order, but the issue is easier to demonstrate using the HTML tag examples) Firstly, the class-based HTML tag context manager example: -------------------- class TagClass: def __init__(self, name): self.name = name @contextfactory def __context__(self): print "<%s>" % self.name yield self print "</%s>" % self.name >>> h1_cls = TagClass('h1') >>> with h1_cls: ... print "Header A" ... <h1> Header A </h1> >>> with h1_cls: ... print "Header B" ... <h1> Header B </h1> -------------------- Each with statement creates a new context object, so caching the tag object itself works just as you would expect. Unfortunately, the same cannot be said for the generator based version: -------------------- @contextfactory def tag_gen(name): print "<%s>" % name yield print "</%s>" % name >>> h1_gen = tag_gen('h1') >>> with h1_gen: ... print "Header A" ... <h1> Header A </h1> >>> with h1_gen: ... print "Header B" ... Traceback (most recent call last): ... RuntimeError: generator didn't yield -------------------- The managed contexts produced by the context factory aren't reusable, so caching them doesn't work properly - they need to be created afresh for each with statement. Adding another decorator to define context managers, as Paul suggested, solves this problem neatly. Here's a possible implementation: def managerfactory(gen_func): # Create a context manager factory from a generator function context_factory = contextfactory(gen_func) def wrapper(*args, **kwds): class ContextManager(object): def __context__(self): return context_factory(*args, **kwds) mgr = ContextManager() mgr.__context__() # Throwaway context to check arguments return mgr # Having @functools.decorator would eliminate the next 4 lines wrapper.__name__ = context_factory.__name__ wrapper.__module__ = context_factory.__module__ wrapper.__doc__ = context_factory.__doc__ wrapper.__dict__.update(context_factory.__dict__) return wrapper @managerfactory def tag_gen2(name): print "<%s>" % name yield print "</%s>" % name >>> h1_gen2 = tag_gen2('h1') >>> with h1_gen2: ... print "Header A" ... <h1> Header A </h1> >>> with h1_gen2: ... print "Header B" ... <h1> Header B </h1> -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

8 18

Crazy idea for str.join
by Josiah Carlson 01 May '06

01 May '06

I understand the underlying implementation of str.join can be a bit convoluted (with the auto-promotion to unicode and all), but I don't suppose there is any chance to get str.join to support objects which implement the buffer interface as one of the items in the sequence? Something like: y = 'hello world' buf1 = buffer(y, 0, 5) buf2 = buffer(y, 6) print ''.join([buf1, buf2]) should print "helloworld" It would take a PyBuffer_Check() just after the PyUnicode_Check() block. And one may be able to replace the other PyString_* calls with PyObject_AsCharBuffer() calls. I'm not going to push for this, but someone other than me may find such functionality useful. - Josiah P.S. One interesting thing to note is that quite a few underlying objects take buffer objects in lieu of strings, even when they aren't documented as doing so; file.write(), array.fromstring(), mmap[i:j] = buffer, etc.

7 25

introducing the experimental pyref wiki
by Fredrik Lundh 01 May '06

01 May '06

the pytut wiki (http://pytut.infogami.com/) has now been up and running for one month, and has seen well over 250 edits from over a dozen contributors. to celebrate this, and to exercise the toolchain that I've deve- loped for pytut and pyfaq (http://pyfaq.infogami.com/), I spent a few hours putting together a hyperlinked mashup of the language reference and portions of the library reference: http://pyref.infogami.com/ a couple of notes: - all important "concepts" have unique URLs: this includes key- words, types, special methods and attributes, statements, builtin functions, and exceptions. - the conversion and structure is a bit rough; especially the syntax/data model/execution model parts needs some serious refactoring. the "concept pages" are in a lot better shape. - registered users can add comments to all pages (editing is currently "by invitation only"; mail me your infogami account if you want to help!) - the documentation style used at the pyref site is tuned for authoring; an "end-user rendering" for python.org can look a lot different. (all three sites can be made available in glorious XHTML for inclusion in arbitrary toolchains). enjoy! </F>

6 8