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
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
> 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 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
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 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
> 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
