Optimizing code
Harald Hanche-Olsen
hanche at math.ntnu.no
Fri Feb 25 10:28:47 EST 2000
More information about the Python-list mailing list
Fri Feb 25 10:28:47 EST 2000
- Previous message (by thread): os.path.walk (was: Re: Optimizing code)
- Next message (by thread): Optimizing code
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
+ Gerrit Holl <gerrit.holl at pobox.com>: | > File "du.py", line 21, in du | > return len(disk) | > TypeError: __len__() should return an int | | A long? I don't see any long? Because I didn't show it to you. 8-) | Perhaps you are running a "future" version of Python silently | converting ints to longs? Nah. It's plain vanilla 1.5.2. But this is on a FreeBSD 3.3 machine, where file sizes and offsets are specified using 64 bit integers. Since they don't fit into a (32 bit) python int, python evidently decides to make them all long ints, whether that is needed or not. | And, by the way, why can't len() return a long integer? Presumably because the address space is still 32 bits, and no object in memory can conceivably be longer than 2**32. (In any case I found your use of __len__ to be slightly offensive.) But wait, you sure *could* imagine an object longer than 2**31, and since python ints are signed, then len() would turn out to be negative. so-more-than-2GB-of-swap-could-get-you-into-trouble-ly y'rs, -- * Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/> - "There arises from a bad and unapt formation of words a wonderful obstruction to the mind." - Francis Bacon
- Previous message (by thread): os.path.walk (was: Re: Optimizing code)
- Next message (by thread): Optimizing code
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list