Mailman 3 July 2010 - Python-Dev

Re: [Python-Dev] Readability of hex strings (Was: Use of coding cookie in 3.x stdlib)
by Georg Brandl July 26, 2010

July 26, 2010

Am 26.07.2010 20:42, schrieb Alexandre Vassalotti: > [+Python-ideas -Python-Dev] > > import binascii > def h(s): > return binascii.unhexlify("".join(s.split())) > > h("DE AD BE EF CA FE BA BE") In Py3k: h = bytes.fromhex Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, … [View More]

1 0

What to do with languishing patches?
by Alexander Belopolsky July 26, 2010

July 26, 2010

On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote: > On 17/07/2010 22:57, Terry Reedy wrote: .. >> I am certainly reluctant to recruit others to help, as I did for #9222, >> if there will be no action indefinitely. >> > > This is standard Python behavour. The worst case I've come across is a > patch that dated back to 2001 that had not been dealt with. But I'm > staggered as to how a third party supplies a patch … [View More]for (say) 2.3, it doesn't > get applied, then the issue tracker simply keeps updating the version > targeted until we're now at 3.2. That of course doesn't mean that anything > will get done, better wait until py4.7? > If this is the reputation that Python gets as a project, I think it is alarming. I was going to dismiss Mark's comment as over dramatizing the situation, but unfortunately it is not. Let me focus on a specific example not because it is important, but because it illustrates many different problems in an easy to understand case. The issue is http://bugs.python.org/issue1699259, which is a very simple patch submitted back in 2007. I came across that patch a year an a half later and posted a review. OP responded the next day and posted an updated patch. I gave the resulting patch a positive review, but the timing was unfortunate because it was during RC phase for 3.0. At the time, I made a prediction that 'deferring [the patch] to 2.7 and 3.1 [was] virtually equivalent to closing with "won't fix"'. That was quite right: the next comment came a year later with "Moving the 3.1 target to 3.2, since 3.1 is out" only to be forgotten for another year to be rediscovered in Mark's recent crusade. As I said, the issue is not an important one, but I noticed that OP did not submit any other patch or commented on any other issue since then. It is impossible to tell if he was turned off by the lack of attention to his patch, but I think it is likely that Python is loosing contributors when they submit a patch, respond to reviews and see their patch languish for no specified reason. I think there is at least one improvement that we can make. We can set up a mechanism that will assure that acceptable patches that don't get applied because they come at the wrong time in development cycle, get applied early in the development of the next release. We already have "posponed" and "remind" resolutions, but these are exclusive of "accepted". I think there should be a clear way to mark the issue "accepted and would be applied if X.Y was out already." Chances are one of the resolution labels already has such meaning, but in this case it should be more prominently documented as such. [View Less]

15 31

Re: [Python-Dev] Python profiler and other tools
by Alexander Belopolsky July 26, 2010

July 26, 2010

I am changing the subject from "http://bugs.python.org/issue231540," because if there was a prize for a non-descriptive subject, OP would win it. There must be a good reason why traditional software development tools such as debugger, profiler and coverage are mostly neglected in python. Terry and I have recently discovered that the trace (coverage) module does not have any unit tests [1] and pretty much does not work in 3.x. [2] One of the recently fixed trace module problems [3] is likely … [View More]

6 8

Re: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
by P.J. Eby July 25, 2010

July 25, 2010

At 07:08 AM 7/24/2010 -0700, Guido van Rossum wrote: >- After seeing Raymond's talk about monocle (search for it on PyPI) I >am getting excited again about PEP 380 (yield from, return values from >generators). Having read the PEP on the plane back home I didn't see >anything wrong with it, so it could just be accepted in its current >form. I would like to reiterate (no pun intended) the suggestion of a special syntactic form for the return, such as "yield return x", or "… [View More]return with x" or something similar, to distinguish it from a normal generator return. I think that when people are getting used to the idea of generators, it's important for them to get the idea that the function's "return value" isn't really a value, it's an iterator object. Allowing a return value, but then having that value silently disappear, seems like it would delay that learning, so, a special form might help to make it clear that the generator in question is intended for use with a corresponding "yield from", and help avoid confusion on this. (I could of course be wrong, and would defer to anyone who sees a better way to explain/teach around this issue. In any event, I'm +1 on the PEP otherwise.) By the way, the PEP's "optimized" implementation could probably be done just by making generator functions containing yield-from statements return an object of a different type than the standard geniter. Here's a Python implementation sketch, using a helper class and a decorator -- translation to a C version is likely straightforward, as it'll basically be this plus a light sprinkling of syntactic sugar. So, in the pure-Python prototype (without syntax sugaring), usage would look like this: @From.container def some_generator(...): ... yield From(other_generator(...)) # equivalent to 'yield from' ... def other_generator(...): ... raise StopIteration(value) # equivalent to 'return value' We mark some_generator() with @From.container to indicate that it uses 'yield from' internally (which would happen automatically in the C/syntax sugar version). We don't mark other_generator(), though, because it doesn't contain a 'yield from'. Now, the implementation code (a slightly altered/watered-down version of a trampoline I've used before in 2.x, hopefully altered correctly for Python 3.x syntax/semantics): class From: @classmethod def container(cls, func): def decorated(*args, **kw): return cls(func(*args, **kw)) # wrap generator in a From() instance return decorated def __new__(cls, geniter): if isinstance(geniter, cls): # It's already a 'From' instance, just return it return geniter self = object.__new__(cls, geniter) self.stack = [geniter] return self def __iter__(self): return self def __next__(self): return self._step() def send(self, value): return self._step(value) def throw(self, *exc_info): return self._step(None, exc_info) def _step(self, value=None, exc_info=()): if not self.stack: raise RuntimeError("Can't resume completed generator") try: while self.stack: try: it = self.stack[-1] if exc_info: try: rv = it.throw(*exc_info) finally: exc_info = () elif value is not None: rv = it.send(value) else: rv = it.next() except: value = None exc_info = sys.exc_info() if exc_info[0] is StopIteration: # pass return value up the stack value, = exc_info[1].args or (None,) exc_info = () # but not the error self.stack.pop() else: if isinstance(rv, From): stack.extend(rv.stack) # Call subgenerator value, exc_info, rv = None, (), None else: return rv # it's a value to yield/return else: # Stack's empty, so exit w/current return value or error if exc_info: raise exc_info[1] else: return value finally: exc_info = () # don't let this create garbage def close(self): if self.stack: try: # There's probably a cleaner way to do this in Py 3, I just # don't know what it is off the top of my head... raise GeneratorExit except GeneratorExit as e: try: self.throw(*sys.exc_info()) except (StopIteration, GeneratorExit): pass else: raise RuntimeError("Generator(s) failed to close()") # XXX probably needs some more code here to clean up stack def __del__(self): try: self.close() except: pass As you can (hopefully) see, the main code path simply ends up delegating next/send/close etc. directly to the iterator on the top of the stack, so there isn't any multi-layer passthru going on, as in the "non-optimized" version of the spec in the PEP. [View Less]

4 3

Patch submitted for 7447
by Leonhard Vogt July 25, 2010

July 25, 2010

Hi I have made a documentation patch for issue 7447. I cannot change the stage to patch-review - is this intentional? Would be great if someone could comment on the patch. Leonhard

2 1

Does trace modules have a unit test?
by Terry Reedy July 25, 2010

July 25, 2010

In reviewing http://bugs.python.org/issue9282 the issue came up, where is the unit test for trace.py? test/test_trace.py is actually a test of the line trace facility of sys.settrace (and should have been called test_linetrace or test_settrace). The only trace import Eli could find in Lib/test is the one in regrtest.py for the -T option. Have we missed something? If you say 'make one', what should be its name? Can the existing file be renamed (I gather this can be a bit of a problem)? -- … [View More]

7 19

http://bugs.python.org/issue231540
by Mark Lawrence July 25, 2010

July 25, 2010

Is there any money to pay for the forthcoming 10th birthday party for this issue? Is the OP still alive? Kindest regards. Mark Lawrence.

9 11

Re: [Python-Dev] Thoughts fresh after EuroPython
by P.J. Eby July 25, 2010

July 25, 2010

At 04:29 PM 7/25/2010 +1000, Nick Coghlan wrote: >So, while I can understand Guido's temptation (PEP 380 *is* pretty >cool), I'm among those that hope he resists that temptation. Letting >these various ideas bake a little longer without syntactic support >likely won't hurt either. Well, if somebody wants to clean up my syntax-sugar-free version a little (maybe adding a "From.return_(value)" staticmethod that raises StopIteration(value)) and throw it in the stdlib, then people can … [View More]

1 0

Re: [Python-Dev] Python-Dev Digest, Vol 84, Issue 112
by John Nagle July 25, 2010

July 25, 2010

> Date: Sat, 24 Jul 2010 23:59:14 +0200 > From:schmir@gmail.com > To: Barry Warsaw<barry(a)python.org> > Cc: Ronald Oussoren<ronaldoussoren(a)mac.com>,python-dev(a)python.org > Subject: Re: [Python-Dev] versioned .so files for Python 3.2 > Message-ID:<87aapgbky5.fsf(a)brainbot.com> > Content-Type: text/plain; charset=us-ascii > > Barry Warsaw<barry(a)python.org> writes: > >> > On Jul 23, 2010, at 01:46 PM,schmir(a)gmail.com wrote:… [View More]

1 0

Re: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
by P.J. Eby July 25, 2010

July 25, 2010

At 08:21 PM 7/24/2010 -0700, Guido van Rossum wrote: >FWIW, the thing that was harder to debug when I tried to write some >code involving generators and a trampoline recently, was thinking of a >function as a generator without actually putting a yield in it >(because a particular version of a coroutine pattern didn't need to >block at all). Monocle uses a decorator to flag all coroutines which >fixes this up in the right way, which I think is clever, but I'm torn >about the … [View More]

1 0