Mailman 3 March 2009 - Python-Dev

Grammar for plus and minus unary ops
by Jared Grubb March 27, 2009

March 27, 2009

I was recently reviewing some Python code for a friend who is a C++ programmer, and he had code something like this: def foo(): try = 0 while try<MAX: ret = bar() if ret: break ++try I was a bit surprised that this was syntactically valid, and because the timeout condition only occurred in exceptional cases, the error has not yet caused any problems. It appears that the grammar treats the above example as the unary + op applied twice: u_expr ::= … [View More]

3 2

"setuptools has divided the Python community"
by Olemis Lang March 27, 2009

March 27, 2009

On Fri, Mar 27, 2009 at 2:27 PM, Eric Smith <eric(a)trueblade.com> wrote: > Olemis Lang wrote: >>> >>> I also think the feature should go. If you want functionality that's so >>> difficult to provide when you install as a zip file, the answer is not to >>> make things more complex, but to not install as zip files. >>> >> >> What about environments like Google App Engine ? I mean, AFAIK using >> ZIP files is the *official* … [View More]

1 0

GPython?
by Terry Reedy March 27, 2009

March 27, 2009

An ars technica articla just linked to in a python-list post http://arstechnica.com/open-source/news/2009/03/google-launches-project-to-… calls the following project "Google launched" http://code.google.com/p/unladen-swallow/wiki/ProjectPlan (Though the project page does not really claim that.) I am sure some people here might find this interesting. I'd love to have a faster CPython, but this note: "Will probably kill Python Windows support (for now)." would kill merger back into mainline (… [View More]

9 12

Summary of Python tracker Issues
by Python tracker March 27, 2009

March 27, 2009

ACTIVITY SUMMARY (03/20/09 - 03/27/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2395 open (+33) / 15008 closed (+21) / 17403 total (+54) Open issues with patches: 845 Average duration of open issues: 661 days. Median duration of open issues: 400 days. Open Issues Breakdown open 2357 (+33) pending 38 ( +0) Issues Created Or Reopened (55) … [View More]

1 0

"yield" in list comprehensions
by Antoine Pitrou March 27, 2009

March 27, 2009

Hello, Just for the record, I thought I'd point out this slightly exotic and funny incompatibility between 2.x and py3k. This is due to the fact that list comprehensions now live in their own frame, so a "yield" expression inside a list comprehension turns the comprehension itself into a generator (rather than the enclosing function). http://bugs.python.org/issue5577 Regards Antoine.

1 0

Re: [Python-Dev] suggestion for try/except program flow
by Hrvoje Niksic March 27, 2009

March 27, 2009

Mark Donald wrote: > Thanks for the idea, but I believe it has a different outcome. You'd > have to copy the generic handler into an except clause to get exactly > the behaviour I'm looking for, which is worse than nesting the try > blocks Then simply change Exception to BaseException. Since all exceptions should derive from BaseException, there should be no difference between that and a bare "except:" clause.

1 0

"setuptools has divided the Python community"
by Olemis Lang March 27, 2009

March 27, 2009

On Fri, Mar 27, 2009 at 5:22 AM, Paul Moore <p.f.moore(a)gmail.com> wrote: > 2009/3/27 Guido van Rossum <guido(a)python.org>: >> - keep distutils, but start deprecating certain higher-level >> functionality in it (e.g. bdist_rpm) >> - don't try to provide higher-level functionality in the stdlib, but >> instead let third party tools built on top of these core APIs compete > > Please don't move bdist_wininst out of the core, though! > > I'd … [View More]

2 1

Re: [Python-Dev] suggestion for try/except program flow
by Hrvoje Niksic March 27, 2009

March 27, 2009

Mark Donald wrote: > I frequently have this situation: > > try: > try: > raise Thing > except Thing, e: > # handle Thing exceptions > raise > except: > # handle all exceptions, including Thing How about: try: ... code that can raise Thing or another exception ... except Exception, e: if isinstance(e, Thing): # handle thing # generic exception handling

2 1

return from a generator [was:PEP 380 (yield from a subgenerator) comments]
by Jim Jewett March 27, 2009

March 27, 2009

On Thu, Mar 26, 2009 at 4:19 PM, P.J. Eby wrote: >> What I don't like is the confusion of adding "return values" to generators, >> at least using the 'return' statement. At Fri Mar 27 04:39:48 CET 2009, Guido van Rossum replied: > I'm +1 on "yield from" and +0 on return values in generators. > def g(): > yield 42 > return 43 > for x in g(): > print x # probably expected to print 42 and then 43 I still don't see why it needs to be a … [View More]

4 3

Re: [Python-Dev] PEP 380 (yield from a subgenerator) comments
by P.J. Eby March 27, 2009

March 27, 2009

At 09:24 PM 3/25/2009 -0700, Guido van Rossum wrote: >ISTR that the motivation for adding new syntax is that the best you >can do using a trampoline library is still pretty cumbersome to use >when you have to write a lot of tasks and subtasks, and when using >tasks is just a tool for getting things done rather than an end goal >in itself. I agree that the motivation and the comparison should be >added to the PEP (perhaps moving the trampoline sample >*implementation* to a … [View More]reference or an appendix, since it is only the >appearance of the trampoline-*using* code that matters). In particular, it should explain why these choices are so costly as to justify new syntax and a complex implementation: * decorator clearly identifying intent to create a task vs. no indication of task-ness * "yield Return(value)" vs. "return value" * "result = yield subgenerator()" vs. "result = yield from subgenerator()" Especially since the first two differences arguably make the non-"yield from" code clearer, and the third makes it more compact. >with judicious use of decorators and helper classes you can get a >reasonable approximation, and I think Twisted uses something like >this, so it's not just theory. I think the best you can do without new >syntax though is still pretty cumbersome and brittle, which is why I >have encouraged your PEP. On the "cumbersome" side, there are only three differences, as I've shown above... and one of them uses less syntax than the PEP. I'm not sure what you mean by brittle. Twisted and PEAK have both had generator-based tasks for ages, and have been used in production for years, even before generators had send()/throw() -- the addition of yield expressions made it possible to get rid of the one previous brittleness, where you needed to do things like: yield subgenerator(); result = resume() in order to pass values or exceptions in. Since send()/throw() was added, the need to call a function after each yield was eliminated, at least from PEAK and my newer Trellis library; haven't looked at Twisted's tasks in a while. I believe there are other generator-based task libraries available on PyPI, but can't comment on their robustness. (The existence of throw(), by the way, makes it possible to produce tracebacks that look *exactly* as if you had called a series of functions, rather than iterating over a bunch of generators. The sample code I gave should do this correctly, as it was created by yanking out working, tested code from my Trellis library, and cutting out all the Trellis-specific bits.) If someone can find any semantic differences between the code I posted and the yield-from proposal (apart from the absence of the "for x in y: yield x" part of the functionality), I'd like to know about it... and it should go in the PEP. [View Less]

4 4