I very much like the fact that python has *very* little black magic revealed to the user. Strong -1 on optimizing picked builtins in a picked way.
2011/1/4 Steven D'Aprano <st...@pearwood.info>: > Guido van Rossum wrote: >> >> On Tue, Jan 4, 2011 at 2:49 AM, Michael Foord <fuzzy...@voidspace.org.uk> >> wrote: >>> >>> I think someone else pointed this out, but replacing builtins externally >>> to >>> a module is actually common for testing. In particular replacing the open >>> function, but also other builtins, is often done temporarily to replace >>> it >>> with a mock. It seems like this optimisation would break those tests. >> >> Hm, I already suggested to make an exception for open, (and one should >> be added for __import__) but if this is done for other builtins that >> is indeed a problem. Can you point to example code doing this? >> > > I've been known to monkey-patch builtins in the interactive interpreter and > in test code. One example that comes to mind is that I had some > over-complicated recursive while loop (!), and I wanted to work out the Big > Oh behaviour so I knew exactly how horrible it was. Working it out from > first principles was too hard, so I cheated: I knew each iteration called > len() exactly once, so I monkey-patched len() to count how many times it was > called. Problem solved. > > I also have a statistics package that has its own version of sum, and I rely > on calls to sum() from within the package picking up my version rather than > the builtin one. > > > -- > Steven > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lukas.lueg%40gmail.com > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com