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 26 Jul '10

26 Jul '10

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, excepting that thou then proceed to four. Tabs are right out.

1 0

What to do with languishing patches?
by Alexander Belopolsky 26 Jul '10

26 Jul '10

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 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.

15 31

Re: [Python-Dev] Python profiler and other tools
by Alexander Belopolsky 25 Jul '10

25 Jul '10

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 affecting profile module as well. I tried to figure out who works on profile to add them to the nosy list and could not find anyone. I seem to remember someone suggesting that python's dynamic nature makes traditional development tools unnecessary. A print statement is the only debugging tool that you need. There may be some truth to it, but in this case, python should not distribute these tools. I am personally in the opposite camp: I love pdb and I am a big believer in profiling and coverage testing. I have entered myself as a maintainer for the trace module which is the simplest of the three, but I would like to learn from developers of pdb and profile on a range of overlapping issues. [1] http://bugs.python.org/issue9315 [2] http://bugs.python.org/issue9317 [3] http://bugs.python.org/issue9323 On Fri, Jul 23, 2010 at 6:26 PM, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote: > Is there any money to pay for the forthcoming 10th birthday party for this > issue? Is the OP still alive? > > Kindest regards. > > Mark Lawrence. > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gm… >

6 8

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

25 Jul '10

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 "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.

4 3

Patch submitted for 7447
by Leonhard Vogt 25 Jul '10

25 Jul '10

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 25 Jul '10

25 Jul '10

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)? -- Terry Jan Reedy

7 19

http://bugs.python.org/issue231540
by Mark Lawrence 25 Jul '10

25 Jul '10

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 25 Jul '10

25 Jul '10

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 certainly experiment with the feature in 3.2, and get an opportunity to iron out any implementation issues before going to the C-and-sugared version later.

1 0

Re: [Python-Dev] Python-Dev Digest, Vol 84, Issue 112
by John Nagle 25 Jul '10

25 Jul '10

> 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: >> > >>> >>Doesn't anybody else think this is lost work for very little gain? My >>> >>/usr/lib/python2.6/site-packages directory consumes 200MB on disk. I >>> >>couldn't care less if my /usr/lib/python2.5/site-packages consumed the >>> >>same amount of disk space... >> > >> > Right, you probably don't care now that your extension modules live in foo.so >> > so it probably won't make much difference if they were named foo-blahblah.so, >> > as long as they import.:) > Most of the time it won't make much difference, right. But I can assure > you, that it will bite some people and there is some code to be adapted. > >> > >> > If you use Debian or Ubuntu though, it'll be a win for you by allow us to make >> > Python support much more robust. > I'd much prefer to have cleanly separated environments by having > separate directories for my python modules. Sharing the source code and > complicating things will not lead to increased robustness. > > - Ralf Debian's policy on Python packaging calls for maximum separation between versions. See "http://www.debian.org/doc/packaging-manuals/python-policy/" This keeps the system updaters from becoming confused, and reduces the risk that an update to one version of Python will break another version. John Nagle

1 0

Re: [Python-Dev] PEP 380 - return value question and prototype implementation (was Thoughts fresh after EuroPython)
by P.J. Eby 24 Jul '10

24 Jul '10

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 need to flag every coroutine with a decorator -- Monocle >makes the decorator really short (@_o) because, as Raymond (not >Monocle's author but its advocate at EuroPython) said, "you'll be >using this hundreds of times". Which I find disturbing in itself. I haven't used Monocle, but in all the libraries I've written myself for this sort of thing (Trellis and peak.events), a decorator is only required for a generator that is a "root" task; everything else is just a normal generator. For example, in Trellis you use @Task.factory to mark a function as spawning an independent task each time it's called, but subgenerator functions called within the task don't need to be marked, and in fact the "yield from" is just a "yield" - the trampoline expects all yields of generators to be subgenerator calls. (PEP 380 can't do this of course, since it also doubles as a sort of 'yield *' - i.e., you may care about the yielded values) Note, though, that even in the sketch I just gave, you don't *really* need to decorate every function, just the ones that need to be called from *non*-decorated functions... i.e. "root" coroutines. Even then, you could *still* skip the decorator and replace: an_iter = decorated_root_function() with: an_iter = From(undecorated_root_function()) and not need to decorate *anything*.

1 0