On 19 March 2014 11:09, Steven D'Aprano <st...@pearwood.info> wrote: > Although I have tentatively said I think this is okay, it is a change in > actual semantics of Python code: what you write is no longer what gets > run. That makes this *very* different from changing the implementation > of sort -- by analogy, its more like changing the semantics of > > a = f(x) + f(x) > > to only call f(x) once. I don't think you would call that an > implementation detail, would you? Even if justified -- f(x) is a pure, > deterministic function with no side-effects -- it would still be a > change to the high-level behaviour of the code.
Ah, I think this is a good alternative example. Given the stated assumptions (true builtin dict, not modified between operations), would we be OK with PyPI optimising the following to only do a single dict lookup: a = d[x] + d[x] It's essentially the same optimisation as the one being discussed - in the code *as written*, there are two lookups visible, but for any sensible __hash__ and __eq__ implementation, they should always give the same answer for a true builtin dict that isn't modified between the two lookups. (and yes, PyPy has the infrastructure to enforce those constraints safely and fall back to normal execution if they aren't met - that ability to take opportunistic advantage of known behaviours of particular types is one of the key things that makes it such a powerful tool for implicit optimisations, as compared to things like Cython and Numba, which change semantics more markedly, but also have to be explicitly applied to specific sections of your code rather than being applied automatically). I think it's certainly borderline (it's the kind of surprising behavioural change that irritates people about C/C++ optimisers), but I also think it's a defensible optimisation if the gain is significant enough. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com