Re: [Python-Dev] Patches: 1 for the price of 10.
> 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. Recommend apply. Wouldn't this cause subtle errors when the float -> long conversion is no longer precise? Or is this a non issue because it could only happen when seeking on impossibly large files? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Zen of Python
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 hard to believe that this is implying optimization over functionality or clarity. There has to be another reason, yet I can't think of any. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] identity operands (was python-dev Summary for 2005-03-01 through 2005-03-15 [draft])
[Nick Coghlan]
> So, using "".join is roughly three times as fast as abusing sum :)
True in the case where you're concatenating three strings, but what
about 100 strings?
(Full source attached)
Py> timeit.Timer("sum(strings, ai)", setup).repeat()
[33.553668413164239, 32.861660909417253, 33.092705357803851]
Py> timeit.Timer("''.join(strings)", setup).repeat()
[5.4385152302876492, 5.3633637794747671, 5.3587657090496066]
Py> timeit.Timer(" + ".join('"' + s + '"' for s in strings), "").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 randrange
from string import uppercase
setup = """
class additive_identity(object):
def __add__(self, other):
return other
ai = additive_identity()
from random import choice
from random import randrange
from string import uppercase
strings = ["".join(choice(uppercase) for i in range(randrange(10))) for i in
range(100)]"""
strings = ["".join(choice(uppercase) for i in range(randrange(10))) for i in
range(100)]
print "SUM:", timeit.Timer("sum(strings, ai)", setup).repeat()
print "JOIN:", timeit.Timer("''.join(strings)", setup).repeat()
print "ADD:", timeit.Timer(" + ".join('"' + s + '"' for s in strings),
"").repeat()___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] anonymous blocks
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 follows: > >def synchronized(lock): >lock.acquire() >try: >yield None >finally: >lock.release() How is this different from: def synchronized(lock): def synch_fn(block): lock.acquire() try: block() finally: lock.release() return synch_fn @synchronized def foo(): BLOCK True, it's non-obvious that foo is being immediately executed, but regardless I like the way synchronized is defined, and doesn't use yield (which in my opinion is a non-obvious solution) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: Unifying try-except and try-finally
> 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 be to allow finally at the beginning or ending of the try statement. A more flexible approach would be to allow both, or even finally clauses mixed in. To me, that's the ugly portion of this proposal, it's quite arbitrary. And the alternatives I posted have their own brands of ugly. Concisely, this is an arbitrary shortcut for an idiom that already exists. It seems to me that this shortcut would be redundant if PEP 340 or something with similar functionality was accepted. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating builtin id (and moving it to sys())
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 a search. id is handy when debugging, when using the interactive interpreter and temporarily in scripts (print id(something), something for when repr(something) doesn't show the id). In my experience teaching python, id at the interactive interpreter is invaluable, which is why any proposal to move it would get a -1. The fundamental issue is that I want to explain reference semantics well before I talk about packages and the associated import call. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
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-strings into an attribute dictionary, why should > dir() hide that fact? Indeed, there seem to be two camps, those who want dir to reflect __dict__ and those who want dir to reflect attributes of an object. It seems to me that those who want dir to reflect __dict__ should just use __dict__ in the first place. However, in the case of dir handling non-strings, should dir handle non-valid identifiers as well, that is to say that while foo.__dict__[2] = ... is an obvious case what about foo.__dict__["1"] ? Right now the documentation says that it returns "attributes", and I would not consider non-strings to be attributes, so either the documentation or the implementation should rectify this disagreement. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
