Mailman 3 April 2006 - Python-Dev

Bug day?
by John J Lee 29 Apr '06

29 Apr '06

Is another bug day planned in the next week or two? John

1 0

Re: [Python-Dev] Adding wsgiref to stdlib
by Phillip J. Eby 29 Apr '06

29 Apr '06

At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote: >(I'm asking Phillip to post the URL for the current >source; searching for it produces multiple repositories.) Source browsing: http://svn.eby-sarna.com/wsgiref/ Anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref

1 0

Internal documentation for egg formats now available
by Phillip J. Eby 29 Apr '06

29 Apr '06

Please see http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt for source, or http://peak.telecommunity.com/DevCenter/EggFormats for an HTML-formatted version. Included are summary descriptions of the formats of all of the standard metadata produced by setuptools, along with pointers to the existing manuals that describe the syntax used for representing requirements, entry points, etc. as text. The .egg, .egg-info, and .egg-link formats and layouts are also specified, along with the filename syntax used to embed project/version/Python version/platform metadata. Last, but not least, there are detailed explanations of how resources (such as C extensions) are extracted on-the-fly and cached, how C extensions get imported from zipfiles, and how EasyInstall works around the limitations of Python's default sys.path initialization. If there's anything else you'd like in there, please let me know.

3 10

Summer of Code mailing list
by Neal Norwitz 29 Apr '06

29 Apr '06

There's a new SoC mailing list. soc2006(a)python.org You can sign up here: http://mail.python.org/mailman/listinfo/soc2006 This list is for any SoC discussion: mentors, students, idea, etc. Student can submit applications starting May 1, so now is the time to get students interested in your ideas! Please pass this information along. Cheers, n

1 0

Re: [Python-Dev] 2.5 open issues
by Phillip J. Eby 29 Apr '06

29 Apr '06

At 07:38 AM 4/28/2006 -0700, Guido van Rossum wrote: >On 4/28/06, A.M. Kuchling <amk(a)amk.ca> wrote: > > - wsgiref to the standard library > > (Owner: Phillip Eby) > >I still hope this can go in; it will help web framework authors do the >right thing long term. I doubt I'll have time to write documentation for it before alpha 3. If it's okay for the docs to wait for one of the beta releases -- or better yet, if someone could volunteer to create rough draft documentation that I could just then edit -- then it shouldn't be a problem getting it in and integrated. However, just to avoid the sort of thing that happened with setuptools, I would suggest, Guido, that you make a last call for objections on the Web-SIG, which has previously voiced more criticism of wsgiref than the Distutils-SIG ever had about setuptools. Granted, most of the Web-SIG comments were essentially feature requests, but some complained about the presence of the handler framework. Anyway, after the setuptools flap I'm a little shy of checking in a new library without a little more visible process. :)

2 2

Is this a bad idea: picky floats?
by skip＠pobox.com 28 Apr '06

28 Apr '06

>From a numerical standpoint, floats shouldn't generally be compared using equality. I came across a bug at work yesterday where I had written: if not delta: return 0.0 where delta was a floating point number. After a series of calculations piling up round-off error delta took on a value on the order of 1e-8. Not zero, but it should have been. The fix was easy enough: if abs(delta) < EPSILON: return 0.0 for a suitable value of EPSILON. That got me to thinking... I'm sure I have plenty of other similar mistakes in my code. (Never was much of a numerical analysis guy...) What if there was a picky-float setting that generated warnings if you compared two floats using "==" (or implicitly using "not")? Does that make sense to try for testing purposes? The implementation seemed straightforward enough: http://python.org/sf/1478364 I'm sure at the very least the idea needs more thought than I've given it. It's just a half-baked idea at this point. Skip

1 0

Python Grammar Ambiguity
by Michael Foord 28 Apr '06

28 Apr '06

Hello all, I'm working on a parser for part of the Python language (expressions but not statements basically). I'm using PLY to generate the parser and it's mostly done. I've hit on what looks like a fundamental ambiguity in the Python grammar which is difficult to get round with PLY; and I'm wondering *why* the grammar is defined in this way. It's possible there is a reason that I've missed, which means I need to rethink my workaround. List displays (list comprehensions) are defined as (from http://docs.python.org/ref/lists.html ) : test ::= and_test ( "or" and_test )* | lambda_form testlist ::= test ( "," test )* [ "," ] list_display ::= "[" [listmaker] "]" listmaker ::= expression ( list_for | ( "," expression )* [","] ) list_iter ::= list_for | list_if list_for ::= "for" expression_list "in" testlist [list_iter] list_if ::= "if" test [list_iter] The problem is that list_for is defined as : "for" expression_list "in" testlist This allows arbitrary expressions in the 'assignment' part of a list comprehension. As a result, the following is valid syntax according to the grammar : [x for x + 1 in y] Obviously it isn't valid ! This parses to an ast, but the syntax error is thrown when you compile the resulting ast. The problem is that for the basic case of a list comprehension ( ``[x for x in y]``), ``x in y`` is a valid expression. That makes it extremely hard to disambiguate the grammar so that the ``in`` is treated correctly, and not part of an expression. My question is, why are arbitrary expressions allowed here in the grammar ? As far as I can tell, only identifiers (nested in parentheses or brackets) are valid here. I've got round the problem by creating a new node 'identifier_list' and just having that return the expected syntax tree (actually an expression list). This gets round the ambiguity [#]_. It worries me that there might be a valid expression allowed here that I haven't thought of. My current rules allow anything that looks like ``(a, [b, c, (d, e)], f)`` - any nested identifier list. Would anything else be allowed ? If not, why not modify the grammar so that the compiler has less possible invalid syntax trees to work with ? (Also the grammar definition of string conversion is wrong as it states that a trailing comma is valid, which isn't the case. As far as I can tell that is necessary to allow nesting string conversions.) Fuzzyman http://www.voidspace.org.uk/python/index.shtml .. [#] If I could make precedence work in PLY I could also solve it I guess. However I can't. :-)

5 7

Re: [Python-Dev] [Python-checkins] Python Regression Test Failures refleak (1)
by Tim Peters 28 Apr '06

28 Apr '06

[19 Apr 2006, Neal Norwitz] > test_cmd_line leaked [0, 17, -17] references > test_filecmp leaked [0, 13, 0] references > test_threading_local leaked [-93, 0, 0] references > test_urllib2 leaked [-121, 88, 99] references Thanks to Thomas digging into test_threading_local, I checked in what appeared to be a total leak fix for it last week. On my Windows box, it's steady as a rock now: """ $ python_d -E -tt ../lib/test/regrtest.py -R:50: test_threading_local test_threading_local beginning 55 repetitions 1234567890123456789012345678901234567890123456789012345 ....................................................... 1 test OK. [27145 refs] """ Is it still flaky on other platforms? If not, maybe the reported test_threading_local leaked [-93, 0, 0] references is due to stuff from a _previous_ test getting cleaned up (later than expected/hoped)?

2 2

Type-Def-ing Python
by Brian C. Lum 28 Apr '06

28 Apr '06

Dear Python Community, I have been trying to research how to type-def python. I want to type-def python so that I can use it as a static analyzer to check for bugs. I have been going over research on this field and I came upon Brett Cannon's thesis in which he tweaks the compiler and shows that type-defing python would not help the compiler achieve a 5% performace increase. Brett Cannon, "Localized Type Inference of Atomic Types in Python": http://www.ocf.berkeley.edu/~bac/thesis.pdf I was wondering if anyone could help me contact him so that I could might ask him for his source code and try to use type-defing as a bug-finder. With thanks, Brian

3 2

Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
by Phillip J. Eby 28 Apr '06

28 Apr '06

At 08:09 PM 4/25/2006 -0700, Guido van Rossum wrote: >On 4/25/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote: > > >I would augment #1 to clarify that if you have __enter__ and __exit__ > > >you may not have __context__ at all; if you have all three, > > >__context__ must return self. > > > > Well, requiring the __context__ allows us to ditch the otherwise complex > > problem of why @contextfactory functions' return value is usable by "with", > > without having to explain it separately. > >Really? I thought that that was due to the magic in the decorator (and >in the class it uses). Actually, I got that explanation backwards above. What I meant is that the hard thing to explain is why you can use @contextfactory to define a __context__ method. All other examples of @contextfactory are perfectly fine, it's only the fact that you can use it to define a __context__ method. See, if @contextfactory functions return a thing *with* a __context__ method, how is that usable with "with"? It isn't, unless the thing also happens to have __enter__/__exit__ methods. This was the hole in the documentation that caused Nick to seek to revisit the decorator name in the first place. >But that *still* doesn't explain why we are recommending that >everything providing __enter__/__exit__ must also provide __context__! Because it means that users never have to worry about which kind of object they have. Either you pass a 1-method object to "with", or a 3-method object to "with". If you have a 2-method object, you can never pass it to "with". Here's the thing: you're going to have 1-method objects and you're going to have 3-method objects, we know that. But the only time a 2-method object is useful is if it's a tag-along to a 1-method object. It's easier from a documentation perspective to just say "you can have one method or three", and not get into this whole "well, you can also have two, but only if you use it with a one". And if you rule out the existence of the two-method variant, you don't have to veer into any complex questions of when you should use three methods instead of two, because the answer is simply "always use three". This isn't a technical problem, in other words. I had exactly the same POV as you on this until I read enough of Nick's rants on the subject to finally see it from the education perspective; it's easier to explain two things, one of which is a subtype of the other, versus explaining two orthogonal things that sometimes go together and sometimes don't, and the reasons that you might or might not want to put them together are tricky to explain. Of course, this approach opens a new hole, which is how to deal with people asking "why does it have to have a __context__ method if it's never called". So far, Nick's answer is "because we said so" (aka "deliberate design decision"), which isn't great, but at least it's honest. :)

4 5