[Python-ideas] start, test, init

[Ron Adam]

On 12/01/2013 03:13 PM, Nick Coghlan wrote:
>  > As for the testing case... I'd like for python to have a -t option that
> only sets a global name __test__ to True.  Then that covers most of your
> use cases without adding a whole lot.  Sometimes less is more.
>  >
>  >    if __test__:
>  >        test()
>  >    elif __name__ == '__main__':
>  >        main()
>  >
>  > That's just one possible combination of using __test__ and __name__.
>
> Oh, interesting. Such an option could also alter -O and -OO to keep assert
> statements.

You could use the __test__ flag as the key to remove asserts rather than 
-O, -OO, and __debug__.  Is that what you are thinking?

If so, I think it would be equivalent to this.

      assert (invariant_condition) if __test__ else 1, fail_message



> I'd love to see that idea elaborated further, as there are a variety of
> questions around how it might work in practice (Compile time constant like
> __debug__?

Isn't __debug__ set at Python's compile time, not module compile time?

I think that makes __debug__ good for testing C extensions and python's own 
C code, but it's too static to be very useful in python modules.


Always False builtin shadowed in the main module?

That would limit the __test__ check to the __main__ module.  I'd like to be 
able to have that check available anywhere.

For example if I wanted to insert some print functions and use the __test__ 
flag to turn them on when I need to see them...

        if __test__:
            print(this)
            print(that)

The idea could go one step further and allow a value to be passed with the 
-t flag.  Then you could select tests based on that value.



> If it works
> like __debug__ and/or affects -O and -OO, does it need a new naming
> convention in the pycache directory?)

I don't think it should effect -O or -OO in any significant way.  And -O or 
-OO shouldn't effect __test__ either.


I think the easiest way to implement it is to just to have __test__ set in 
the modules attributes at load/import time. If it's always to be available, 
then why not?  I consider testing an imortant part of any program, so 
having __test__ in a module doesn't seem out of place to me.  If 
anything... maybe if it's there... it's more likely to be used.  ;-)


I also like how easy it is to access.  For many small scripts, including an 
argument parser is more work than I want to do, but including a few small 
tests to call if "__test__ == True" is perfect for those cases.

     if __test__:
         import doctest
         doctest.testmod()

     elif __name__ == '__main__':
         main()


And I think it makes using __name__ here seem more natIt may also work as a 
name in the sys module.  sys.__test__, but I prefer the simpler spelling of 
just __test__ because it looks nicer and allows for setting __test__ at the 
top of a module.ural.

Ok, maybe that one is just me.   It just seems, to me, some of the oddness 
comes from always seeing it spelled *exactly the same everywhere*. So the 
"if __name__ == '__main__':"  line just begs for being reduced to something 
more minimal.

Of course that does not mean it should be changes just that we will 
consider doing that to anything that stands out as being duplicated a lot. 
  It's just what good programmers do. ;-)

Cheers,
    Ron