On 02/11/2010 22:58, Guido van Rossum wrote:
On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger
<raymond.hettin...@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.
_______________________________________________
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
