On 02/11/2010 22:58, Guido van Rossum wrote: > On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger > <raymond.hettinger at gmail.com> wrote: >> I'm not sure I follow where we're stuck with the current package. >> AFAICT, the module is still used with "import unittest". >> The file splitting was done badly, so I don't think there any of the >> components are usable directly, i.e. "from unitest.case import SkipTest". >> Also, I don't think the package structure was documented or announced. >> >> This is in contrast to the logging module which does have a >> clean separation of components and where it isn't unusual >> to import just part of the package. >> >> What is it you're seeing as a risk that I'm not seeing? >> Are we permanently locked into the exact ten filenames >> that are currently used: utils, suite, loader, case, result, main, signals, >> etc? >> Is the file structure now frozen? > 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? > Amen. Although not that contrarian, others have spoken up in favour. The split is pretty obvious (in general - I'm sure its not perfect) and divided along major functionality. TestCase - case.py TestResult - result.py TestSuite - suite.py TextTestRunner - runner.py TestLoader - loader.py main function - main.py signal handling - signals.py The utils module is somewhat an odd one out as it is only used by case.py, but this is hardly the most egregious error in the world. If you can't guess where a class lives, __init__.py shows you explicitly (a clear advantage of exporting the public API at the top level ;-) Due to the original design of unittest (and I have many thoughts on that) the modules aren't strictly "reusable" (i.e. isolated from each other) - but many test frameworks (for example) just use the TestCase without using other components. I find it difficult to believe that this package structure is only acceptable if we make people import the TestCase from unittest.case and not expose it at the top level. As mentioned in another email, but this thread has many long and tedious emails, there is no clear consensus that there should be a remerger and I am aware that there are already some consumers of the new package structure. As the maintainer of unittest I'd like to say that in the absence of clear consensus that the merger should happen, or a fiat from the BDFL, the merger won't happen. I believe that this is standard Python development process. All the best, Michael -- http://www.voidspace.org.uk/ READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4