Re: [Python-Dev] Mutable sequence .sort() signature
[Kurt] > Looking at the various py3k docs and mail lists, etc. I just can't > find the specification and discussion of the signature change > eliminating the comparison function (so far)! There is a note Misc/NEWS and I believe the 2-to-3 folks are looking at a conversion. The Py3.0 docs have the new signature (same as the old one but it no longer accepts a cmp function and to prevent accidents keyword arguments are required). I'm not sure where else to document it. > Does it come up in -3 warnings? It doesn't, but it wouldn't be hard to add one. Raymond Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mutable sequence .sort() signature
On Feb 12, 2008 8:10 PM, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote: > "Guido van Rossum" <[EMAIL PROTECTED]> writes: > > > Also, pretty prominent, in the what's new in 3.0 doc. > > By 'prominent', are you suggesting putting it near the bottom of the > "Common Stumbling Blocks" section, as opposed to the "Other Language > Changes" section? > > I can work up a short patch. I think that's a good start. Andrew Kuchling can always move it later if that section becomes too crowded or uneven. I suggest you just check this in, and also the PEP 3100 patch. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mutable sequence .sort() signature
"Guido van Rossum" <[EMAIL PROTECTED]> writes: > Also, pretty prominent, in the what's new in 3.0 doc. By 'prominent', are you suggesting putting it near the bottom of the "Common Stumbling Blocks" section, as opposed to the "Other Language Changes" section? I can work up a short patch. -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mutable sequence .sort() signature
Also, pretty prominent, in the what's new in 3.0 doc. On Feb 12, 2008 6:39 PM, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote: > Raymond Hettinger <[EMAIL PROTECTED]> writes: > > > [Kurt] > >> Looking at the various py3k docs and mail lists, etc. I just can't > >> find the specification and discussion of the signature change > >> eliminating the comparison function (so far)! > > > > There is a note Misc/NEWS and I believe the 2-to-3 folks are looking > > at a conversion. The Py3.0 docs have the new signature (same as > > the old one but it no longer accepts a cmp function and to prevent > > accidents keyword arguments are required). > > Yes, I see you changed those docs. But I think we need to give better > notice that this is one of the py3k incompatibilities. > > > I'm not sure where else to document it. > > I'd say in PEP3100. Here's a patch: > > http://bugs.python.org/issue2092 > > -- > KBK > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Odom
def mrange(minvec, maxvec=None):
if maxvec is None:
maxvec = minvec
minvec = [0] * len(maxvec)
vec = list(minvec)
unitpos = len(vec) - 1
maxunit = maxvec[unitpos]
_tuple = tuple
while 1:
if vec[unitpos] == maxunit:
i = unitpos
while vec[i] == maxvec[i]:
vec[i] = minvec[i]
i -= 1
if i == -1:
return
vec[i] += 1
yield _tuple(vec)
vec[unitpos] += 1
''' Clicker wheel objects:
- init with a sqn
- return init value
- when called, repopulates vec, calls another clicker when rolling over
- last one terminates
'''
from itertools import cycle
def odom(*args):
''' Cartesian product of input interables. Equivalent to nested for-loops.
For example, product(A, B) returns the same as ((x,y) for x in A for y in B).
The leftmost iterators are in the outermost for-loop, so the output tuples
cycle in a manner similar to an odometer (with the rightmost element changing
on every iteration).
product('ab', range(3)) --> ('a',0) ('a',1) ('a',2) ('b',0) ('b',1) ('b',2)
product((0,1), (0,1), (0,1)) --> (0,0,0) (0,0,1) (0,1,0) (0,1,1) (1,0,0) ...
'''
#itertools.cycle version with next() calls'
_tuple = tuple
cycles = [cycle(p).next for p in args]
vec = [c() for c in cycles]
minvec = vec[:]
i = right = len(vec) - 1
while 1:
yield _tuple(vec)
vec[i] = cycles[i]()
while vec[i] == minvec[i]:
i -= 1
if i == -1:
return
vec[i] = cycles[i]()
else:
i = right
def odom(*args):
#Index version for easy conversion to C'
''' Cartesian product of input interables. Equivalent to nested for-loops.
For example, product(A, B) returns the same as ((x,y) for x in A for y in B).
The leftmost iterators are in the outermost for-loop, so the output tuples
cycle in a manner similar to an odometer (with the rightmost element changing
on every iteration).
product('ab', range(3)) --> ('a',0) ('a',1) ('a',2) ('b',0) ('b',1) ('b',2)
product((0,1), (0,1), (0,1)) --> (0,0,0) (0,0,1) (0,1,0) (0,1,1) (1,0,0) ...
'''
_tuple = tuple
pools = map(list, args)
maxvec = map(len, pools)
indices = [0] * len(pools)
vec = [p[0] for p in pools]
i = right = len(pools) - 1
slots = list(reversed(range(len(pools
while 1:
yield _tuple(vec)
for i in slots:
indices[i] += 1
if indices[i] != maxvec[i]:
vec[i] = pools[i][indices[i]]
break
indices[i] = 0
vec[i] = pools[i][indices[i]]
else:
return
if __name__ == '__main__':
for t in odom(range(2), range(3), 'abcd'):
print t
print list(odom('ab', range(3)))
print list(odom(*[range(2)]*3))
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Mutable sequence .sort() signature
Raymond Hettinger <[EMAIL PROTECTED]> writes: > [Kurt] >> Looking at the various py3k docs and mail lists, etc. I just can't >> find the specification and discussion of the signature change >> eliminating the comparison function (so far)! > > There is a note Misc/NEWS and I believe the 2-to-3 folks are looking > at a conversion. The Py3.0 docs have the new signature (same as > the old one but it no longer accepts a cmp function and to prevent > accidents keyword arguments are required). Yes, I see you changed those docs. But I think we need to give better notice that this is one of the py3k incompatibilities. > I'm not sure where else to document it. I'd say in PEP3100. Here's a patch: http://bugs.python.org/issue2092 -- KBK ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon: deadline for hotel reservations and early-bird registration coming soon!
If you haven't registered for PyCon yet, now is the time! The early-bird registration deadline is February 20, one week away. After that, the price for registration will be going up. http://us.pycon.org/2008/registration/ The deadline for hotel reservations at the conference rate is also February 20. Act now, because the regular rate is considerably higher! http://us.pycon.org/2008/registration/hotel/ A reminder to tutorial and talk speakers: you are responsible for your own registration and hotel reservations. So don't delay! PyCon 2008: March 14-16, 2008 (& tutorials March 13, & sprints March 17-20) David Goodger PyCon 2008 Chair signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Preventing merges into Py3k
On Feb 12, 2008 9:44 AM, thomas.heller <[EMAIL PROTECTED]> wrote: > Author: thomas.heller > Date: Tue Feb 12 18:44:23 2008 > New Revision: 60746 > > Modified: >python/branches/py3k/Modules/_ctypes/_ctypes.c > Log: > Revert the last svnmerge (r60681) from trunk to _ctypes.c, it should > not have been merged as was noticed in the commit message. There is a way to prevent merging a particular revision by instructing svnmerge properly. I believe the syntax is svnmerge block (svnmerge help block will explain you more). Christian has been using this -- Christian, care to post a detailed example? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [Fwd: Re: int/float freelists vs pymalloc]
[fwd as reply was intended for python-dev] Christian Heimes wrote: > Andrew MacIntyre wrote: >> I tried a LIFO stack implementation (though I won't claim to have done it >> well), and found it slightly slower than no freelist at all. The >> advantage of such an approach is that the known size of the stack makes >> deallocating excess objects easy (and thus no need for >> sys.compact_free_list() ). > > I've tried a single linked free list myself. I used the ob_type field to > daisy chain the int and float objects. Although the code was fairly > short it was slightly slower than an attempt without a free list at all. > pymalloc is fast. It's very hard to beat it though. I'm speculating that CPU cache effects can make these differences. The performance of the current trunk float freelist is depressing, given that the same strategy works so well for ints. I seem to recall Tim Peters paying a lot of attention to cache effects when he went over the PyMalloc code before the 2.3 release, which would contribute to its performance. > A fixed size LIFO array like PyFloatObject > *free_list[PyFloat_MAXFREELIST] increased the speed slightly. IMHO a > value of about 80-200 floats and ints is realistic for most apps. More > objects in the free lists could keep too many pymalloced areas occupied. I tested the updated patch you added to issue 2039. With the int freelist set to 500 and the float freelist set to 100, its about the same as the no-freelist version for my tests, but PyBench shows the simple float arithmetic to be about 10% better. I'm inclined to set the int LIFO a bit larger than you suggest, simply as ints are so commonly used - hence the value of 500 I used. Floats are much less common by comparison. Even an int LIFO of 500 is only going to tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant enough that I can't see a need for a compaction routine. A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on 64bit). I'd like to think that these changes could be considered fixes for performance bugs so that they could be applied for 2.5.2, but I doubt that will fly. Cheers, Andrew. -- - Andrew I MacIntyre "These thoughts are mine alone..." E-mail: [EMAIL PROTECTED] (pref) | Snail: PO Box 370 [EMAIL PROTECTED] (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] svn repo out of disk?
Aahz wrote: > On Mon, Feb 11, 2008, Steve Holden wrote: >> Douglas Napoleone wrote: >>> Not sure if this is effecting the core svn repository or not, but the >>> conference software (also hosted at svn.python.org) is reporting that >>> the disk is full: >>> >>> [...] >> Doug: >> >> You may not be aware that this issue occurred a couple of days ago, [...] > > Steve: > > You may not be aware that Doug sent his message a couple of days ago; it > was simply delayed in transit. > > (Not that I wasn't confused myself until I looked at the Date: header.) [smacks head] -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] int/float freelists vs pymalloc
Andrew MacIntyre wrote: > I seem to recall Tim Peters paying a lot of attention to cache effects > when he went over the PyMalloc code before the 2.3 release, which would > contribute to its performance. Well, I guess we have to ask Uncle Tim on this matter and ask for his opinion. I've no experience with optimization on the level of CPU cache lines. But it sounds interesting. Does somebody have an advice for some articles or a good book? > I tested the updated patch you added to issue 2039. With the int > freelist set to 500 and the float freelist set to 100, its about the same > as the no-freelist version for my tests, but PyBench shows the simple > float arithmetic to be about 10% better. > > I'm inclined to set the int LIFO a bit larger than you suggest, simply as > ints are so commonly used - hence the value of 500 I used. Floats are > much less common by comparison. Even an int LIFO of 500 is only going to > tie up ~8kB on a 32bit box (~16kB on 64bit), which is insignificant > enough that I can't see a need for a compaction routine. > > A 200 entry float LIFO would only account for ~4kB on 32bit (~8kB on > 64bit). I added some profiling code to lists and dicts. Increasing the free list size didn't make a difference for lists and dicts. I used 200 instead of 80 for the free list size and the ratio of reuse / allocation increased minimal. Every entry in the free list costs 4 bytes for the pointer and 16 bytes for the int or float object on 32bit including padding on 8byte address boundaries. For 500 objects that's about 9kb which isn't a big deal nowadays. But - andere there is always a but - every object may keep a 4kb arena alive. Unless a program is creating and destroying lots of ints at once a larger number doesn't make a performance difference. I'd stick to 80, maybe 120 for ints for now. > I'd like to think that these changes could be considered fixes for > performance bugs so that they could be applied for 2.5.2, but I doubt > that will fly. Not a chance ;) Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
