[Python-Dev] Python equivalents in stdlib Was: Include datetime.py in stdlib or not?
Alexander Belopolsky
alexander.belopolsky at gmail.com
Wed Jul 7 22:16:03 CEST 2010
On Wed, Jul 7, 2010 at 3:45 PM, Brett Cannon <brett at python.org> wrote:
> On Wed, Jul 7, 2010 at 08:29, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
..
>> For datetime.py this approach presents several problems:
>>
>> 1. replacing datetime with self.module.datetime everywhere can get
>> messy quickly.
>> 2. There are test classes defined at the test_datetime module level
>> that subclass from datetime classes. The self.module is not available
>> at the module level. These should probably be moved to setUp()
>> methods and attached to test case self.
>> 3. If #2 is resolved by moving definitions inside functions, the
>> classes will become unpickleable and pickle tests will break. Some
>> hackery involving injecting these classes into __main__ or module
>> globals may be required.
>
> So I have been thinking about this about how to possibly make this
> standard test scaffolding a little cleaner. I think a class decorator
> might do the trick. If you had all test methods take a module argument
> you could pass in the module that should be used to test. Then you
> simply rename test_* to _test_*, create test_*_(c|py), and then have
> those methods call their _test_* equivalents with the proper module to
> test. You could even make this generic by having the keyword arguments
> to the decorator by what the test suffix is named.
>
Hmm, I've been playing with the idea of using a metaclass to do
essentially the same, but a class decorator may be a simpler solution.
I still don't see how this address #1, though. In the ideal world,
I would like not to touch the body of test_* methods. These methods,
however are written assuming from datetime import date, time,
datetime, tzinfo, etc at the top of test_datetime.py. Even if the
decorator will call _test_* with six additional arguments named date,
time, datetime, tzinfo, etc, it will not work because by the time
decorator (or even metaclass machinery) gets to operate, these names
are already resolved as globals.
> The benefit of this is you don't have to define one base class and
> then two subclasses; you define a single test class and simply add a
> decorator.
I like this.
> This addresses #1.
Except it does not. :-(
> As for #3, that I can't answer and might
> simply require restructuring those specific pickle tests.
What about #2?
More information about the Python-Dev
mailing list