Given that we're about to release beta3, I propose to name it test_support at the top level and leave it at that for now. Introducing a testing package should be relegated to 3.1 IMO.
On Mon, Aug 18, 2008 at 11:23 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: >>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <[EMAIL PROTECTED]> >>> 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 <[EMAIL PROTECTED]> wrote: >>>>> [EMAIL PROTECTED] 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 | [EMAIL PROTECTED] | Brisbane, Australia >>>>> --------------------------------------------------------------- >>>>> http://www.boredomandlaziness.org >>>>> _______________________________________________ >>>>> 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/guido%40python.org >>>>> >>>> >>>> >>>> >>>> -- >>>> --Guido van Rossum (home page: http://www.python.org/~guido/) >>>> _______________________________________________ >>>> 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/brett%40python.org >>>> >>> >> >> >> >> -- >> --Guido van Rossum (home page: http://www.python.org/~guido/) >> > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ 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
