Closed jonorthwash closed 4 years ago
I actually have this implemented on my fork. I'll merge upstream sometime this weekend.
Oh, that's cool! I'd actually started to poke at it too, but I'll wait for your pushes.
@keggsmurph21, this illustrates one reason why "commit early, commit often"¹² is a useful mantra. It's often the first line of communication between collaborators.
Speaking of which, don't you have direct commit access to this repo?
¹ https://sethrobertson.github.io/GitBestPractices/#commit ² https://www.aclweb.org/anthology/J08-3010.pdf
@keggsmurph21, any updates on this?
Sorry, I haven't gotten around to this yet. I'll work on it now.
And yes, I do have direct commit access, but I had started working on rewriting some pieces of this lib, and decided to do that via a fork so that we could continue pushing this branch forward. (I guess I could have also just made a new branch in this repository...)
Done, see 889358b
This looks great. It's worth noting that there are out-of-the-box logging libraries. But this is nice and simple—additional dependencies are already a problem with UltraTrace...
I'm thinking it might be nice to put distributed libraries in a subdirectory somewhere to keep the main directory clean.
I'll open a separate issue
@jonorthwash see #88
Also, regarding python's standard logging
module (and other third party ones), we probably don't even need that level of complexity, since we'll (presumably?) only ever have one logger (i.e. the main app-level one) and one place to log to (i.e. stderr
).
Everything printed to the console should use a proper logger, with "WARNING", "ERROR", "INFO", etc. type messages.