>>> 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
> 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
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
5**y rpow: (5,)
x^y%26 (3L, 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'
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?
- _is_ this due to a bug in intobject.c's int_pow()
- _is_ this due to a bug in the implementation of the pow()
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
Luke Kenneth Casson Leighton <lkcl(a)samba-tng.org> writes:
> 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.
Another idea: make UserLong a "new-style class". I'm not sure what
this changes, but it changes "stuff" in this area...
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
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,)
> x^y%26 (3L, 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'
> 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?
> - _is_ this due to a bug in intobject.c's int_pow()
> - _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...
The meaning of "brunch" is as yet undefined.
-- Simon Booth, ucam.chat
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
Well, I wrote a patch for this ages and ages ago:
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
I'd have thought so.
... 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
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
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
--Guido van Rossum (home page: http://www.python.org/~guido/)