all() is slow?

[Devin Jeanpierre]

Clearly what we need is a modern hygienic macro system to avoid this exec mess!

defmacro defall(name, cond):
    def name(lst):
        for a in lst:
            if not cond:
                return False
        return True

invoke defall(all, cond)

Only slightly tongue in cheek.

We have that stupid exec trick in the Python stdlib. It has to die.

http://hg.python.org/cpython/file/6bf07db23445/Lib/collections/__init__.py#l240

Devin

On Mon, Nov 7, 2011 at 5:06 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Tue, Nov 8, 2011 at 8:46 AM, david vierra <codewarrior0 at gmail.com> wrote:
>> But, you didn't write an all() function.  You wrote a more specialized
>> allBoolean() function. I think this comparison is more fair to the
>> builtin all():
>
> So really, it's not "all() is slow" but "function calls are slow".
> Maybe it'd be worthwhile making an all-factory:
>
> def my_all(code,lst):
>    exec("""def tmp_all(x):
>        for a in x:
>            if not ("""+code+"""): return False
>        return True
> """)
>    return tmp_all(lst)
> timeit.timeit('my_all("a in (True, False)",x)','from __main__ import
> my_all,x',number=10)
>
> Bad code imho, but it _is_ faster than both the original and the builtin.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
>