[Python-Dev] FAT Python (lack of) performance

[Sjoerd Job Postmus]

On Mon, Jan 25, 2016 at 11:58:12PM +0100, Victor Stinner wrote:
> ...
> Oh, they are a lot of things to do! ...

Just wondering, do you also need a set of (abusive) test-cases which
check 100% conformity to the CPython semantics? I'm sure many of us
would be able to whip up some ideas of things that are possible with
Python and are of the kind "but you should not do that! That's bad
programming!" which may or may not break the optimizations (especially
specialized functions).

I'm thinking of things like

    def override_length_function_test():
        global len
        value = len("abc")
	len = lambda obj: ord(obj[0]))
	value += len("abc")
	assert value == 3 + 97, "Outdated `len` used."

And also cases where `len` was changed not in the function itself, but
in another function that was called indirectly (maybe 4 functions down,
one of which was monkey-patched in after the compilation step):

    module_a.py
    def test_func(callback):
        value = len("abc")
	callback()
	value += len("abc")
	assert value == 3 + 97, "Outdated `len` used."

    module_b.py
    import module_a
    def override_length_function_test():
        def callback():
	    module_a.len = lambda obj: ord(obj[0])
	assert module_a.test_func(callback) == 3 + 97, "Outdated `len` used."

(I'm sure some of the other readers of this list can be even more
creative in trying to show that making optimizations like this can break
semantics.)

Other fun tricks I'd like to try is overriding the `len` method from a
signal handler, what happens when you monkey-patch a dependent method,
having `__getitem__` and `__getattr__` on some value override `len`.

Basically: trying things that I normally should not try during my
working hours, on account of wanting to still have a job the next day.

Kind regards,
Sjoerd Job