On Mon, Apr 20, 2015 at 01:33:37PM -0400, Barry Warsaw wrote: > Personally, I think the use of dict.iteritems is way overused. The > performance hit is theoretical unless you've actually measured it, and even > then I think it probably doesn't help much unless you've got huge dicts.
I tend not to take other people's personal preferences as useful data points when choosing my coding style, so I tend to get easily irritated by comments like yours, just as I was irritated by people on that lwn thread saying that all the incompatibilities introduced by python 3.5 where "obscure". I generally pick my coding style according to the official documentation. If iteritems is documented to iterate a dictionary with an O(1) of memory usage, and items() is documented as creating a copy of the dictionary into a list and therefore having an O(n) memory complexity, I will use iteritems() unless I need to have a list as a result. If iteritems() turns out to be less performing, I consider it a problem in the way things are documented, and I won't be held accountable for not making measurements. It is my habit to carefully follow the documentation trying to pick the tool that has built precisely with the intention of addressing what I am doing. I would rather hear people saying "I'm sorry that things took a different direction than expected", rather than hear people moaning about the use of obscure features, or the neglect of doing measurements. > >Also, if I implement new features I am not necessarily going to test > >them on python3 unless it somehow happens automatically. > > One word: tox :) Nice word. It is a tool that I have never used, and that is not available on debian stable where the services are currently deployed. > >Running the test suite twice is not much of an option, though, because it > >already takes a lot of time to run, and doubling the time it takes just means > >that code is going to get tested less. Unless of course someone reviews my > >test code and finds a way to make it run super fast: I'd certainly welcome > >that! > > The nice thing is you can run `tox -e py27` for your normal cases, and then > `tox` before you push updates to just be sure it works for all supported > versions. The unfortunate thing is that I would have to budget several hours of my time to learn a new tool and integrate it in my workflow, and I have more urgent things on top of my todo list than "redo what currently works fine using a new tool". I would be fine if someone sent me patches to make the code *also* work with tox, but I would not personally use it myself until I have allocated time that I currently don't have to master it, because I refuse to be the primary maintainer of code that uses tools that I do not know well[1]. Knowledge transfer and migrations may be fun for some, but for others *they are a cost*, as shown by the mere existence of this thread. Enrico [1] also, given the volatility of a lot of new tools in the python ecosystem, I have adopted the safety practice of making sure that a tool has been /widely/ adopted for at least a year or two before even bothering to look at it. I like that practice: I saved myself the burden of rewriting setup.py files countless times because of that. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: Digital signature