Python-Dev May 2002

python-dev@python.org

104 participants
148 discussions

by Tim Peters

>>> FreeBSD 4.4 (2.1.1 w/o pymalloc) >>> justpush 89.72 >>> justzip 110.41 >>> >>> FreeBSD 4.4 (recent CVS with pymalloc) >>> justpush 19.21 >>> justzip 46.32 >>> [Tim] > ... > That I didn't know (only the compiler was mentioned above). So you've > got your own mystery. What are you going to do about it <wink>? The good news: This isn't a mystery after all. Between 2.1 and 2.2, I changed list.append() to do mildly exponential overallocation instead of fixed-increment overallocation. "In theory" that makes the worst cases amortized linear time instead of quadratic time. Looks like FreeBSD's realloc is more sensitive to this change than most. the-bad-news-is-i-barely-remember-changing-it-ly y'rs - tim

18 years, 5 months

testing... (ignore this)

by Aahz

Is python-dev dead or quiet? Does exim need a boot? -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "I used to have a .sig but I found it impossible to please everyone..." --SFJ

18 years, 5 months

[bug?] UserLong.py - pow(5, UserLong(3), 26) fails

by Luke Kenneth Casson Leighton

hiya people, been a while, i'm back onto python exploration for a serious monster exciting parallelisation project. as part of the evaluation, i have created UserLong.py, and am working my way through the list of all operations. i may have some mistakes and/or missing operators, and am trying to work this one out. at the bottom of the file are some inline debug tests. one of these - pow(int(5), UserLong(3), 26) - is failing: Script started on Wed May 1 19:06:30 2002 highfield:/usr/local/lib/python2.2# python UserLong.py int 3 long 3 5**int(y) 125 5**y rpow: (5,) 3 x^y%26 (3L, 26) 21L 5^y%26 Traceback (most recent call last): File "UserLong.py", line 153, in ? print "5^y%26", pow(5, y, 26) TypeError: unsupported operand type(s) for pow(): 'int', 'instance', 'int' highfield:/usr/local/lib/python2.2# Script done on Wed May 1 19:06:37 2002 now, if i read this correctly, what is happening is that in the [optimised] code, Objects/intobject.c, support for types other than int, float and long - via the macro CONVERT_TO_LONG - are simply not supported. this i believe can be demonstrated to be so because if you do pow(5, [], 26) you get the same error except replace 'instance' above with 'list'. now, could someone with a little more knowledge than i kindly evaluate, if they have the time, whether: - _is_ this happening because i have missed out a function in UserLong.py that i do not know the name of? or: - _is_ this due to a bug in intobject.c's int_pow() or: - _is_ this due to a bug in the implementation of the pow() "spam" function? - other? many thanks, luke -- ---------------------------------------------------------- this message is private, confidential, and is intented for the specified recipients only. if you received in error, altered, deleted, modified, destroyed or interfered with the contents of this message, in whole or in part, please inform the sender (that's me), immediately. if you, the recipient, reply to this message, and do not then receive a response, please consider your reply to have been lost or deliberately destroyed: i *always* acknowledge personal email received. please therefore take appropriate action and use appropriate protocols to ensure effective communication. thank you.

18 years, 5 months

Re: [Python-Dev] Re: [bug?] UserLong.py - pow(5, UserLong(3), 26) fails

by Michael Hudson

Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> writes: > michael, > > the point of doing a UserLong.py is that it is an easy way > to add in profiling and debug info and to evaluate alternative > implementations of Long numbers. > > the ultimate aim is to find out if it is worth adding in > support for Aspex Technology's massively parallel signal > processor chip as a python co-processor. I see. Another idea: make UserLong a "new-style class". I'm not sure what this changes, but it changes "stuff" in this area... Cheers, M. -- C is not clean -- the language has _many_ gotchas and traps, and although its semantics are _simple_ in some sense, it is not any cleaner than the assembly-language design it is based on. -- Erik Naggum, comp.lang.lisp

18 years, 5 months

Re: [Python-Dev] [bug?] UserLong.py - pow(5, UserLong(3), 26) fails

by Michael Hudson

Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> writes: > one of these - pow(int(5), UserLong(3), 26) - is failing: What's the point of UserLong now we have 2.2? > Script started on Wed May 1 19:06:30 2002 > highfield:/usr/local/lib/python2.2# python UserLong.py > int 3 > long 3 > 5**int(y) 125 > 5**y rpow: (5,) > 3 > x^y%26 (3L, 26) > 21L > 5^y%26 > Traceback (most recent call last): > File "UserLong.py", line 153, in ? > print "5^y%26", pow(5, y, 26) > TypeError: unsupported operand type(s) for pow(): 'int', 'instance', 'int' > highfield:/usr/local/lib/python2.2# > Script done on Wed May 1 19:06:37 2002 > > now, if i read this correctly, what is happening is that in > the [optimised] code, Objects/intobject.c, support for types > other than int, float and long - via the macro CONVERT_TO_LONG - > are simply not supported. > > this i believe can be demonstrated to be so because if you > do pow(5, [], 26) you get the same error except replace > 'instance' above with 'list'. > > now, could someone with a little more knowledge than i kindly > evaluate, if they have the time, whether: > > - _is_ this happening because i have missed out a function in > UserLong.py that i do not know the name of? > > or: > > - _is_ this due to a bug in intobject.c's int_pow() > > or: > > - _is_ this due to a bug in the implementation of the pow() > "spam" function? > > - other? Are you aware of this text in section 3.3.6 of the lang ref: Note that ternary pow() will not try calling __rpow__() (the coercion rules would become too complicated). so I'd say this is, if anything, a "documented limitation", though that might something of a stretch... Cheers, M. -- The meaning of "brunch" is as yet undefined. -- Simon Booth, ucam.chat

18 years, 5 months

Re: [Python-Dev] Built in objects supporting slices

by Michael Hudson

Paul Moore <gustav(a)morpheus.demon.co.uk> writes: > At the moment, built in objects such as lists don't support the slice > notaton l[a:b:c]. Would there be support for including this in Python > 2.3? If so, what would be the necessary procedure? Would this require a > PEP? Well, I wrote a patch for this ages and ages ago: http://www.python.org/sf/400998 It got rejected, mostly for lack of interest. > Alex Martelli has offered to do the code, if someone will champion the > work. I'm happy to do this, but I don't have commit privileges, so it > would require someone else to actually commit any changes. I presume > that the correct approach would be to submit the changes as a patch to > SourceForge? I'd have thought so. Cheers, M. -- ... with these conditions cam the realisation that ... nothing turned a perfectly normal healthy individual into a great political or military leader better than irreversible brain damage. -- The Hitch-Hikers Guide to the Galaxy, Episode 11

18 years, 5 months

millions of tuples

by Ian Kjos

Two things spoken by Guido: > But millions of tuples are not uncommon. They're probably the only > thing to worry about here. > Unfortunately, the visit API doesn't make it easy to watch this[*]; a > tuple calls visit() on its items but learns nothing except whether it > failed. (I've never seen a visit() implementation that could fail, so > I'm not sure even why the return code exists.) * "this" is the number of tracked objects visited during a GC scan, as described by MvL If visit() does something sensible (like traversing a directed, potentially cyclic graph), then the only way it could fail is to not return. No doubt there is a clear record of who calls this function. Why not we change the semantics of visit() in this case to provide the required information? Make visit() return a non-negative integer for "number of tracked objects seen". If someone can find a good reason for error codes, then there is the negative half of the integer number line. (/me is going out on a limb and hypothesizing that visit() is in C for all relevant cases.)

18 years, 5 months

Making None a keyword

by Guido van Rossum

I'd like to make None a keyword. This prevents dumb users from assigning to it and screwing themselves, and can cause a slight speedup because using None avoids two dict lookups. - Any objections? - Can somebody help me implement this? I've got the parser changes ready, but not the compiler changes. Believe it or not, Zope3 contains code that will break with this change: there are functions with a default argument of the form None=None as a speedup hack. I think this is an argument *for* the change. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

18 years, 5 months

Jump to page:

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev May 2002