Christian,
I like the path that exception handling seems to be taking. I'd be
comfortable moving forward with this version as an initial version for
full adoption in the lib.
Per logging, it looks as if python's native logging can suffice. I would
like for the verbosity of logging to be available as a parameter in some
way. For example, have a settings somewhere that specifies the level of
logging, and outputs based on that setting.
To illustrate:
settings.py (or something like that) contains a variable:
loglevel = 0 (where 0 is none, and 1-5 are mapped to DEBUG, INFO,
WARNING, ERROR, CRITICAL)
then, in caps.py
if (loglevel >=1):
log(DEBUG, 'log string')
if (loglevel >=2):
log(INFO, 'log string')
if (loglevel >=3):
log(WARNING, 'log string')
etc, etc
This would allow for silent applications, or verbose ones, depending on
the setting....
Thoughts?
~e
Christian Scholz wrote:
Hi!
I just checked in some use of exceptions in caps.py and some tests
testing them. You can find the exceptions by searching for "exc" and
you can find example of how to catch them (or how they actually look
like) in tests/caps.txt at the bottom.
I also added some deserialization exception at the bottom of caps.py
and separate tests for GET and POST.
Those exceptions now also have a string representation which prints
out more details instead of just "ResourceNotFound".
Included are also the logging changes.
Next step might be to add some more high level caps like for catching
a login failure.
cheers,
Christian
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/pyogp
