On Nov 2, 2010, at 3:58 PM, Guido van Rossum wrote: > To spout a somewhat contrarian opinion, I just browsed the new > unittest package, and the structure seems reasonable to me, even if > its submodules are not particularly reusable. I've used this kind of > style for development myself. What is so offensive about it?
I don't find anything offensive about it. The issues have to do with being able to find and analyze code. For example, to find-out what assert.ItemsEqual does, I have to figure-out that it was put in the case.py file. In Py2.6, you code use IDLE's Open Module tool to immediately bring up all the source for unittest. Then you could fire-up the class browser to quickly see and navigate the structure, but that also no longer works in Py2.7. Also, it used to be the just knowing the module name was sufficient to find the code with http://svn.python.org/view/python/branches/release26-maint/Lib/unittest.py?view=markup All you needed to study the code was a web browser and its find function. Now you need to open ten tabs to be able to browse this code. IOW, the packaging broke a read-the-source-luke style of research that I've been teaching people to use for years. I probably didn't articulate the above very well, but I think Martin said it more succinctly in this same thread. The other issue that Brett pointed out is that the file names now become part of the API, "from unittest.utils import safe_repr". In the logging module, packaging was done well. The files fell along natural lines in the API, some of the components we usable separately and testable separately. Likewise with the xml packages. In contrast, the unittest module is full of cross-imports and tightly coupled pieces (like suite and case) have been separated. Raymond
_______________________________________________ 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
