[Python-Dev] Why does httplib import from test_support?

Brett Cannon brett at python.org
Mon Aug 18 20:23:15 CEST 2008


On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <guido at python.org> wrote:
> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <brett at python.org> wrote:
>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <guido at python.org> wrote:
>>> Note that many distros are in the habit of not installing the test
>>> package by default. So dependencies outside that package on *anything*
>>> in it are a problem. Maybe test_support should be lifted out of the
>>> test package?
>>>
>>
>> Well, if distros do tend to do this and we are going to continue to
>> document what is in that module for people's benefit, then yes, it
>> should probably be moved or we try to convince distros to at least
>> include the module and possibly regrtest.
>
> Don't fight the distros! Move it.

And now the great debate; what should it be named? Should we start a
testing package and name the module testing.support, possibly moving
doctest, unittest, and any other testing code there at some point? Or
just make it test_support at the top level? Or should the granularity
be greater, such as separating out stuff that deals with the
interpreter, files, and system state (or something)? The module has
stuff ranging from is_resource_enabled and verbose for regrtest to
catch_warning, TESTFN, and run_with_locale.

>I'm not sure why regrtest needs to
> be moved though?
>

Doesn't have to move. It's just the only other piece of code in the
'test' package that isn't just a test.

-Brett


>> -Brett
>>
>>
>>> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>> skip at pobox.com wrote:
>>>>> The import statement seems to work from an interactive shell (I have a
>>>>> module named test in the same directory as the main prog, hence the
>>>>> problem), but even if it does work should we be importing stuff from the
>>>>> test package in non-test code?
>>>>
>>>> I saw those checkins go by on the checkins list - they have to do with
>>>> silencing -3 warnings for modules that the stdlib still uses in Python
>>>> 2.6 for backwards compatibility reasons (but switching to the relevant
>>>> new approaches in 3.0, thus making the warnings a false alarm).
>>>>
>>>> test.test_support.catch_warning is a convenient way to suppress a
>>>> warning for a small piece of code and then revert the state of the
>>>> warnings module back to the way it was afterwards.
>>>>
>>>> Those imports should probably be guarded with sys.py3kwarn though, with
>>>> a standard import being used if the command line flag isn't set.
>>>>
>>>> Cheers,
>>>> Nick.
>>>>
>>>> --
>>>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>>>> ---------------------------------------------------------------
>>>>            http://www.boredomandlaziness.org
>>>> _______________________________________________
>>>> Python-Dev mailing list
>>>> Python-Dev at python.org
>>>> http://mail.python.org/mailman/listinfo/python-dev
>>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>>>
>>>
>>>
>>>
>>> --
>>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>> _______________________________________________
>>> Python-Dev mailing list
>>> Python-Dev at python.org
>>> http://mail.python.org/mailman/listinfo/python-dev
>>> Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>>
>>
>
>
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>


More information about the Python-Dev mailing list