Mailman 3 August 2004 - Python-Dev

J2 proposal final
by Robert Brewer 27 Aug '04

27 Aug '04

Hello, Guido, The J2 patch and proposal are finished (http://www.aminus.org/rbre/python/pydec.html) and ready for your consideration. In the interest of time, I'm submitting the arguments to you now. The "call for signatories" is still open, but I think you can get a feel for the level of support based upon the current endorsements, and modify that as more names come in. I'll be in Ensenada (at a friend's bachelor party, if you must know :) until Sunday evening, at which time I will add in any new signatories. If you have any questions until that time, I'm sure Michael Sparks (among others) would be happy to answer or delegate them. Your decision schedule is of course your own. Thanks for your consideration and support throughout this process! For the Python community, Robert Brewer MIS Amor Ministries fumanchu(a)amor.org P.S. For the record, I had selected and am now submitting the J2 syntax based on a community vote on c.l.p., wherein each voter cast 3 votes, for a total of 70 voters with 209 votes. The top contenders as of today (a good time to officially close that vote): 1st 2nd 3rd Total % A1 4 2 3 9 C1 9 9 12 30 0.14 C2 7 7 2 16 J2 33 34 30 97 0.46 The total number of votes for J2 beat the total number of votes for C1 (the next contender) by over three to one. It was unclear to many in that poll whether A1 was a valid vote; it's not recommended to draw any conclusions regarding the preference of voters for A1 from that vote--that may be more correctly drawn from the list of signatories of the proposal.

3 2

PEP 333: Python Web Server Gateway Interface v1.0
by Phillip J. Eby 27 Aug '04

27 Aug '04

(Separately posted to python-list to avoid cross-traffic.) PEP: 333 Title: Python Web Server Gateway Interface v1.0 Version: $Revision: 1.1 $ Last-Modified: $Date: 2004/08/27 17:30:09 $ Author: Phillip J. Eby <pje at telecommunity.com> Discussions-To: Python Web-SIG <web-sig at python.org> Status: Draft Type: Informational Content-Type: text/x-rst Created: 07-Dec-2003 Post-History: 07-Dec-2003, 08-Aug-2004, 20-Aug-2004, 27-Aug-2004 Abstract ======== This document specifies a proposed standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers. Rationale and Goals =================== Python currently boasts a wide variety of web application frameworks, such as Zope, Quixote, Webware, SkunkWeb, PSO, and Twisted Web -- to name just a few [1]_. This wide variety of choices can be a problem for new Python users, because generally speaking, their choice of web framework will limit their choice of usable web servers, and vice versa. By contrast, although Java has just as many web application frameworks available, Java's "servlet" API makes it possible for applications written with any Java web application framework to run in any web server that supports the servlet API. The availability and widespread use of such an API in web servers for Python -- whether those servers are written in Python (e.g. Medusa), embed Python (e.g. mod_python), or invoke Python via a gateway protocol (e.g. CGI, FastCGI, etc.) -- would separate choice of framework from choice of web server, freeing users to choose a pairing that suits them, while freeing framework and server developers to focus on their preferred area of specialization. This PEP, therefore, proposes a simple and universal interface between web servers and web applications or frameworks: the Python Web Server Gateway Interface (WSGI). But the mere existence of a WSGI spec does nothing to address the existing state of servers and frameworks for Python web applications. Server and framework authors and maintainers must actually implement WSGI for there to be any effect. However, since no existing servers or frameworks support WSGI, there is little immediate reward for an author who implements WSGI support. Thus, WSGI *must* be easy to implement, so that an author's initial investment in the interface can be reasonably low. Thus, simplicity of implementation on *both* the server and framework sides of the interface is absolutely critical to the utility of the WSGI interface, and is therefore the principal criterion for any design decisions. Note, however, that simplicity of implementation for a framework author is not the same thing as ease of use for a web application author. WSGI presents an absolutely "no frills" interface to the framework author, because bells and whistles like response objects and cookie handling would just get in the way of existing frameworks' handling of these issues. Again, the goal of WSGI is to facilitate easy interconnection of existing servers and applications or frameworks, not to create a new web framework. Note also that this goal precludes WSGI from requiring anything that is not already available in deployed versions of Python. Therefore, new standard library modules are not proposed or required by this specification, and nothing in WSGI requires a Python version greater than 2.2.2. (It would be a good idea, however, for future versions of Python to include support for this interface in web servers provided by the standard library.) In addition to ease of implementation for existing and future frameworks and servers, it should also be easy to create request preprocessors, response postprocessors, and other WSGI-based "middleware" components that look like an application to their containing server, while acting as a server for their contained applications. If middleware can be both simple and robust, and WSGI is widely available in servers and frameworks, it allows for the possibility of an entirely new kind of Python web application framework: one consisting of loosely-coupled WSGI middleware components. Indeed, existing framework authors may even choose to refactor their frameworks' existing services to be provided in this way, becoming more like libraries used with WSGI, and less like monolithic frameworks. This would then allow application developers to choose "best-of-breed" components for specific functionality, rather than having to commit to all the pros and cons of a single framework. Of course, as of this writing, that day is doubtless quite far off. In the meantime, it is a sufficient short-term goal for WSGI to enable the use of any framework with any server. Finally, it should be mentioned that the current version of WSGI does not prescribe any particular mechanism for "deploying" an application for use with a web server or server gateway. At the present time, this is necessarily implementation-defined by the server or gateway. After a sufficient number of servers and frameworks have implemented WSGI to provide field experience with varying deployment requirements, it may make sense to create another PEP, describing a deployment standard for WSGI servers and application frameworks. [Remainder truncated due to python-dev posting size limit; please see: http://python.org/peps/pep-0333.html for remaining text.]

1 0

PEP-0273 (zip imports) needs to be finished off
by Anthony Baxter 27 Aug '04

27 Aug '04

I just noticed that PEP-0273 is not yet up to date. As the code's been in there since 2.3, it'd be a shame if we had to rip it out of 2.4a3 for lack of a current PEP <wink> And yes, I've not had time to finish PEP-0318. This _will_ be done before 2.4a3. Hopefully _this_ weekend I'll get time to finish it... -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

list += string??
by David Abrahams 27 Aug '04

27 Aug '04

I just discovered the following behavior: C:\Documents and Settings\dave>python Python 2.3 (#46, Aug 25 2003, 18:37:29) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> prefix = ['foo', 'bar', 'baz'] >>> prefix += 'bomb' # meant to write prefix += [ 'bomb' ] >>> prefix ['foo', 'bar', 'baz', 'b', 'o', 'm', 'b'] >>> Is it new and/or intentional? I would have expected an error from the +=. I was very surprised when my error "passed silently". -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

6 7

HTML Side By Side Differencing -- Alpha3
by Dan Gass 27 Aug '04

27 Aug '04

I'm looking for a developer to apply this patch for inclusion in Alpha3. The patch provides methods to generate side by side differences in HTML format (highlights and hyperlinks changed areas). The patch adds functionality to the difflib.py module without changing any of the existing code (low risk of breaking anything). There has been a good deal of participation in improving and reviewing the patch. What I need is someone who has check in privileges and feels comfortable implementing the patch. I've had good support (see patch comments) from a number of people with the exception of some hesitation from Martin v. Löwis which was countered by arguments from Tim Peters and Jim Jewett. In addition to having a wider audience to solicit help from, this is being posted on Python-Dev to provide an opportunity for others to comment on the patch as well since it is being considered for inclusion in Alpha3. For that person who steps forward I can promise that I will provide any needed support in a timely manner. Thanks, Dan Gass

1 1

Re: def fn (args) [dec,dec]:
by Guido van Rossum 27 Aug '04

27 Aug '04

[Anthony] > I'm having trouble finding a single piece from you where you > outline the problems you have with the [decorators] after args, > before :. Could you possibly post a message to python-dev > stating your problems with it? It's the major one I've been > unable to find your objections to. And nobody else has expressed their objections to it either? :-) Just look at it when either the list of decorators or the argument list doesn't fit on one line: class C(object): def longMethodNameForEffect(longArgumentOne=None, longArgumentTwo=42) [ staticmethod, funcattrs(grammar="'@' dotted_name [ '(' [arglist] ')' ]", status="experimental", author="BDFL") ]: """This method blah, blah. It supports the following arguments: - longArgumentOne -- a string giving ... - longArgumentTwo -- a number giving ... blah, blah. """ raise NotYetImplemented That's a total jumble of stuff ending with a smiley. (True story: I left out the colon when typing up this example and only noticed in proofing.) Problems with this form: - it hides crucial information (e.g. that it is a static method) after the signature, where it is easily missed - it's easy to miss the transition between a long argument list and a long decorator list - it's cumbersome to cut and paste a decorator list for reuse, because it starts and ends in the middle of a line Given that the whole point of adding decorator syntax is to move the decorator from the end ("foo = staticmethod(foo)" after a 100-line body) to the front, where it is more in-your-face, it should IMO be moved all the way to the front. (If I could design a language from scratch, I might want to move docstrings to before the 'def' as well; I've come to appreciate this in Java code. Fredrik Lundh's PythonDoc also uses comments prefixing the method definition; he also uses @ so he should be happy with this syntax, as he seemed to be when I mentioned it to him at EuroPython.) --Guido van Rossum (home page: http://www.python.org/~guido/)

14 21

Re: [Python-checkins] python/dist/src/Objects unicodeobject.c, 2.219, 2.220
by M.-A. Lemburg 27 Aug '04

27 Aug '04

tim_one(a)users.sourceforge.net wrote: > Update of /cvsroot/python/python/dist/src/Objects > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv15103/Objects > > Modified Files: > unicodeobject.c > Log Message: > PyUnicode_Join(): Two primary aims: > > 1. u1.join([u2]) is u2 > 2. Be more careful about C-level int overflow. > > Since PySequence_Fast() isn't needed to achieve #1, it's not used -- but > the code could sure be simpler if it were. Hmm, you've now made PyUnicode_Join() to work with iterators whereas PyString_Join() only works for sequences. What are the performance implications of this for PyUnicode_Join() ? Since the string and Unicode implementations have to be in sync, we'd also need to convert PyString_Join() to work on iterators. Which brings up the second question: What are the performance implications of this for PyString_Join() ? The join operation is a widely used method, so both implementations need to be as fast as possible. It may be worthwhile making the PySequence_Fast() approach a special case in both routines and using the iterator approach as fallback if no sequence is found. Note that PyString_Join() with iterator support will also have to be careful about not trying to iterate twice, so it will have to use a similiar logic to the one applied in PyString_Format() where the work already done up to the point where it finds a Unicode string is reused when calling PyUnicode_Format(). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 27 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

2 2

urllib.urlretrieve
by David Abrahams 27 Aug '04

27 Aug '04

Is there a known reliability problem with urllib.urlretrieve? I'm getting silent truncation of downloaded files. http://sourceforge.net/tracker/?func=detail&aid=1016880&group_id=5470&atid=… has the details. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

2 3

Dealing with test__locale failure on OS X before a3
by Brett C. 27 Aug '04

27 Aug '04

test__locale has been failing on OS X for quite a while now (I bet ever since we started compiling against the CoreFoundation framework since that is where the problem exists). I would like to deal with it before a3 goes out in case we need to change something semantically. Bug http://www.python.org./sf/1005113 has most of the details. Basically it looks like Apple locks down the locale so that it can't be change through locale.h . This means that all attempts to change the locale just fails silently. Obviously this sucks. I do have a contact at Apple who said it looks like it the function that caused this issue has been removed from the tree they are working with for Tiger, but that can obviously change and they could also have just moved the functionality to another function. There are a few options on how to deal with this. One is to just turn off test__locale for OS X. We do this for test_locale already so skipping locale tests on OS X already has a precedent. We can raise locale.Error on OS X for all attempts to set the locale. Problem I have with this is I don't know if this problem exists in other versions of OS X beyond 10.3 (test__locale passing for anyone on other OS X versions?). Last option is to try to fix it so that we set the locale through CoreFoundation. I have no clue how doable this is (quick searching turned up http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFLocale… so it might be possible). Problem is I know I can't get it in before a3. Possibly before b1, but no guarantee. And of course this is assuming this works the way we need it to which it might not. Personally I would like to turn off the test on OS X for now and then try to see if there is a proper way to solve this. -Brett

5 10

Decoding incomplete unicode
by Walter Dörwald 26 Aug '04

26 Aug '04

Pythons unicode machinery currently has problems when decoding incomplete input. When codecs.StreamReader.read() encounters a decoding error it reads more bytes from the input stream and retries decoding. This is broken for two reasons: 1) The error might be due to a malformed byte sequence in the input, a problem that can't be fixed by reading more bytes. 2) There may be no more bytes available at this time. Once more data is available decoding can't continue because bytes from the input stream have already been read and thrown away. (sio.DecodingInputFilter has the same problems) I've uploaded a patch that fixes these problems to SF: http://www.python.org/sf/998993 The patch implements a few additional features: - read() has an additional argument chars that can be used to specify the number of characters that should be returned. - readline() is supported on all readers derived from codecs.StreamReader(). - readline() and readlines() have an additional option for dropping the u"\n". The patch is still missing changes to the escape codecs ("unicode_escape" and "raw_unicode_escape") and I haven't touched the CJK codecs, but it has test cases that check the new functionality for all affected codecs (UTF-7, UTF-8, UTF-16, UTF-16-LE, UTF-16-BE). Could someone take a look at the patch? Bye, Walter Dörwald

6 69