On Mar 18, 5:32 pm, Christopher Lee <l...@chem.ucla.edu> wrote:
> I guess that would mean we'd need a test suite for logger's
> functionality, since it's now being incorporated as part of Pygr?
It has a doctest based testsuite that executes when you run the logger
module on its own.
This could be incorporated in the main test runner. On the other hand
all test modules heavily use the logger thus we are already testing
it. If the logger would break the testutil module breaks as well, so I
think this may not need another explicit test.
> Release Management Question: is this a functionality change (and
> therefore delays the alpha release), or is this "debugging" that can
> occur after the alpha?
I think the logger should be added into the pygr package as soon as
possible and new
code should make use of it. Switching all prints to logging calls is
sort of an 'scratch an itch' like task, one evening when the time is
right someone can just swap out the prints to logger calls in 10
minutes. The important thing is to have the logger module present so
that we can actually do it.
> an interpreted language like Python there is a performance hit for
> every debug statement
> Do you know of any good way around this in Python?
Probably there isn't any proper methodology for that.
Technically the assert statement gets removed when python is invoked
with the optimization flag, and one could probably make calls to
logging messages as part of the assertion (ugh), but that is misusing
asserts ... and impractical anyhow
best,
Istvan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pygr-dev" group.
To post to this group, send email to pygr-dev@googlegroups.com
To unsubscribe from this group, send email to
pygr-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pygr-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
