> 1067760 -- float-->long conversion on fileobj.seek calls, rather than
>float-->int. Permits larger floats (2.0**62) to match large
>int (2**62) arguments. rhettinger marked as "won't fix" in
>the original bug report; this seems like a clean solution,
>tho. Recom
On Thu, 20 Jan 2005 09:03:30 +1000, Stephen Thorne
<[EMAIL PROTECTED]> wrote:
> "Flat is better than nested" has one foot in concise powerful
> programming, the other foot in optimisation.
>
> foo.bar.baz.arr involves 4 hashtable lookups. arr is just one hashtable
> lookup.
I find it amazingly h
repeat()
[17.726616371633828, 17.785511845779279, 18.179861127601413]
So at 100 strings, the difference is over 5x, and I assume you'll see
the relative distance increase as you increase the number of strings.
Timothy Fitz
import timeit
from random import choice
from random import randrang
On 4/21/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>for dummy in synchronized(the_lock):
>BODY
>
> or perhaps even (making "for VAR" optional in the for-loop syntax)
> with
>
>in synchronized(the_lock):
>BODY
>
> Then synchronized() could be written cleanly as follo
> No, as except clauses can only occur before the finally clause, and execution
> should not go backwards.
This restriction feels a bit arbitrary. I can guarantee someone is
going to flatten this:
try:
try:
A
finally:
B
except IOError:
C
A more flexible approach would
On 8/17/05, Christian Robottom Reis <[EMAIL PROTECTED]> wrote:
> I've done some searching through my code and id() isn't the most-used
> builtin, so from my perspective the impact would be limited, but of
> course others might think otherwise.
All of my primary uses of id would not show up in such
On 8/16/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> -0 The behavior of dir() already a bit magical. Python is much simpler
> to comprehend if we have direct relationships like dir() and vars()
> corresponding as closely as possible to the object's dictionary. If
> someone injects non-stri
