Mailman 3 November 2003 - Python-Dev

Re: [Python-Dev] test warnings for "%x"%id(foo) on 2.3 branch
by Anthony Baxter Nov. 5, 2003

Nov. 5, 2003

>>> Anthony Baxter wrote > Hm. "%x" % (id(o) & 2L*sys.maxint+1) > is considerably less obvious that "%x"%id(o) The best I can come up with at this moment using the 'struct' module is ''.join(['%02x'%ord(x) for x in struct.pack('>i', id(o))]), which is also pretty grotesque. Thinking about it further, the better fix might be to replace the test code that looks for an exact match with a regex-based match instead... Anthony -- Anthony Baxter <anthony(a)interlink.… [View More]

2 1

RE: [Python-Dev] Deprecating obsolete builtins
by Batista, Facundo Nov. 5, 2003

Nov. 5, 2003

#- > [Neal Norwitz] #- > > For 2.4 I'd suggest we officially deprecate: apply, #- coerce, intern. #- > +1 . Facundo

1 0

RE: [Python-Dev] PEP 322: Reverse Iteration
by Samuele Pedroni Nov. 5, 2003

Nov. 5, 2003

At 13:50 05.11.2003 +0000, Moore, Paul wrote: >From: Jeremy Fincher [mailto:fincher.8@osu.edu] > > If this proposal could be satisfied by the simple definition: > > > > def reversed(seq): > > for i in xrange(len(seq)-1, -1, -1): > > yield seq[i] > > > > I wouldn't be for it. The reason I'm +1 is because I want > > a standard protocol for iterating in reverse over objects. > >The more I think about it, the less I see the need … [View More]for reversed(). But I'm >having a really difficult time articulating why. > >I don't see enough use cases for something which just reverses sequences, >as above. I tend to loop over concrete sequences less and less these days, >using iterators, generators, enumerate, itertools etc, far more. The simple >reversed() above doesn't help at all there. OK, reversed([x]range) is useful, >but as soon as an iterator-based irange existed, I'd use that for "forward" >loops, and be most upset that reversed(irange) didn't work... > >Whenever I try to play with writing a reversed() which is more general than >the code above, I get stuck because *something* needs reversing, but it's >virtually never a sequence! > >So far, I've needed to reverse: > > itertools.count() > itertools.zip() > enumerate() > >But this is all fairly incestuous - all I'm proving is that *if* you need >reversed() on something other than a sequence, you can't do it without >help from something (the object itself, or something else). But the cases >*I* care about have been pre-existing Python objects, which Raymond is not >proposing to extend in that way! (I can see that having the __reversed__ >protocol may help with user-defined objects, I just don't have such a need >myself). 1) the problem is that reversed want to be simple and sweet, but general reverse iteration is not that simple. 2) itertools.count/ izip and enumerate produce iterators forgetting the original iterable so while nice reversed(count(9)) reversed(enumerate([1,2,3])) would require rather not straightforward mechanisms under the hood. Either one write and introduce revenumerate , revcount revizip OR one could make reversed also a functional allowing not only for reversed(it) # it implements __reversed__ or it's a sequence but also reversed(count,9) reversed(enumerate,[1,2,3]) reversed(izip,[1,2],[1,3]) [ the implementation would use some table to register the impl of all those behaviors], with possible behaviors: def rev_count(n): while True: yield n n -= 1 def rev_izip(*iterables): iterables = map(reversed, iterables) while True: result = [i.next() for i in iterables] yield tuple(result) def rev_enumerate(it): if hasattr(it, '__reversed__'): index = -1 # arbitrary but not totally meaningless :) for elem x.__reversed__(): yield (index,x) index -= -1 if hasattr(x, 'keys'): raise ValueError("mappings do not support reverse iteration") i = len(x) while i > 0: i -= 1 yield (i,x[i]) rev_behavior = { enumerate: rev_enumerate, ... } def reversed(*args): if len(args)>1: func = args[1] args = args[1:] rev_func = rev_behavior.get(func,None) if rev_func: for x in rev_func(args): yield x else: ... error else: ... Whether this is for general consumption is another matter. regards. [View Less]

1 0

RE: [Python-Dev] PEP 322: Reverse Iteration
by Moore, Paul Nov. 5, 2003

Nov. 5, 2003

From: Jeremy Fincher [mailto:fincher.8@osu.edu] > If this proposal could be satisfied by the simple definition: > > def reversed(seq): > for i in xrange(len(seq)-1, -1, -1): > yield seq[i] > > I wouldn't be for it. The reason I'm +1 is because I want > a standard protocol for iterating in reverse over objects. The more I think about it, the less I see the need for reversed(). But I'm having a really difficult time articulating why. I don't see enough use … [View More]cases for something which just reverses sequences, as above. I tend to loop over concrete sequences less and less these days, using iterators, generators, enumerate, itertools etc, far more. The simple reversed() above doesn't help at all there. OK, reversed([x]range) is useful, but as soon as an iterator-based irange existed, I'd use that for "forward" loops, and be most upset that reversed(irange) didn't work... Whenever I try to play with writing a reversed() which is more general than the code above, I get stuck because *something* needs reversing, but it's virtually never a sequence! So far, I've needed to reverse: itertools.count() itertools.zip() enumerate() But this is all fairly incestuous - all I'm proving is that *if* you need reversed() on something other than a sequence, you can't do it without help from something (the object itself, or something else). But the cases *I* care about have been pre-existing Python objects, which Raymond is not proposing to extend in that way! (I can see that having the __reversed__ protocol may help with user-defined objects, I just don't have such a need myself). I'm tending to come down in favour of just having a simple "generate numbers in reverse" function (whether that is irange(..., reverse=True) or irevrange, or something else). Like Guido, I think that covers most real cases. Especially in combination with itertools - reversed(seq) <===> imap(seq.__getitem__, irevrange(len(seq))) Hmm, that reads better with irevrange. Looks like Guido's judgement is right again... Actually, itertools.count() looks very much like it's relevant here. It has a start argument (defaulting to 0) but no stop or step. Maybe we should be extending this, rather than inventing a new itertool. count(start=0, end=<forever>, step=1, reverse=False) This adds a *lot* of generality to count. Or how about itertools.count() as above, and itertools.countdown() as a reversed version? OK. I think I've changed to -0 on PEP 322, and +1 on having irange and irevrange (or an extended count and countdown) in itertools. Paul. [View Less]

1 0

bsddb test case deadlocks fixed
by Gregory P. Smith Nov. 5, 2003

Nov. 5, 2003

I just committed the fixes necessary for test_bsddb.py to complete without deadlocking (yay!). It should remove all possibility of a bsddb deadlock in single threaded applications as well as allow for multiple iterator/generator objects to operate properly on a database at once and make the _DBWithCursor __iter__ implementation more efficient by not asking for the values from the db since it only returns the keys. I believe there are still race conditions that could lead to a deadlock in the … [View More]

5 13

Re: [Python-checkins] python/dist/src/Lib/bsddb __init__.py, 1.11, 1.12
by Skip Montanaro Nov. 4, 2003

Nov. 4, 2003

greg> import UserDict greg> class _iter_mixin(UserDict.DictMixin): greg> def __iter__(self): greg> try: ... Should _iter_mixin inherit from dict, or is there a backward compatibility issue? Skip

2 1

RE: [Python-Dev] Re: PEP 322: Reverse Iteration
by Delaney, Timothy C (Timothy) Nov. 4, 2003

Nov. 4, 2003

> From: Alex Martelli [mailto:aleaxit@yahoo.com] > > I must be missing something. enumerate(x) is an iterator with len(x) > values, each a pair; why would reversing it somehow "transpose" it...? No - you're not. Brain fart on my part :( Tim Delaney

1 0

FW: [Python-Dev] PEP 322: Reverse Iteration
by Raymond Hettinger Nov. 4, 2003

Nov. 4, 2003

> > I believe the assumption is that enumerate (as well as the proposed > irange) > > would grow an __reversed__ method to handle just that usage. Unfortunately, that idea didn't work out. The enumerate object does not hold the original iterable; instead, it only has the result of iter(iterable). Without having the iterable, I don't see a way for it to call iterable.__reversed__. The essential problem that at creation time, the enumerate object does know that it is going to … [View More]

1 0

RE: [Python-Dev] Re: PEP 322: Reverse Iteration
by Delaney, Timothy C (Timothy) Nov. 4, 2003

Nov. 4, 2003

> From: Alex Martelli [mailto:aleaxit@yahoo.com] > > or reversed(enumerate(seq)) if the index IS needed. Hmm - wouldn't this give an iterator that returned two values - an iterable for the seq, and an iterable for the indexes of seq? I would think this would need to be: reversed(*enumerate(seq)) with the presumption being that reversed would reverse each parameter and return them in lockstep. Tim Delaney

2 1

[gmane.comp.sysutils.autotools.announce] Autoconf 2.58 released
by Michael Hudson Nov. 4, 2003

Nov. 4, 2003

We want to be using this asap to get rid of the aclocal hacks, right? I suppose waiting a *few* days for a brown-paper-bag-release situation would be prudent. Cheers, mwh -- This is the fixed point problem again; since all some implementors do is implement the compiler and libraries for compiler writing, the language becomes good at writing compilers and not much else! -- Brian Rogoff, comp.lang.functional

2 1