At 09:50 PM 4/10/2007 -0700, Guido van Rossum wrote: >I'm kind of worried about the performance though -- won't you have to >pay at least for the lookup of __and1__ or __or1__ in the MRO of the >first argument?
Not if they're tp_* slots. And we could introduce the feature only for new-style classes, thereby preventing any performance hit for existing classic classes. (Classic classes' tp_and1 et al would simply invoke normal boolean testing.) What I find interesting about this proposal is that it comes very close to allowing abstract interpretation of arbitrary Python expressions. If there were a couple of other operator pairs like 'if1/if2', you'd be able to take a generator expression and transform it to SQL without parsing or bytecode decompiling (the two techniques currently used by today's Python ORM's like DejaVu). Unfortunately, to get full abstract interpretation (ala PyPy, but without looking at any bytecode), there would need to be a way to handle try/except/finally and while loops, and I don't have any ideas about how one would implement those. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
