hmmm there's a design decision with a python library we're writing at work that i Don't Like but it would break other people's code if i fixed it and it's an extremely minor issue, but it's pretty much the only thing i actually know about the library because i just started here so it does bug me

@monorail hmm what's the decision? :blobcatthinking:​ maybe you could keep the current api working and expose a new fixed api as well? idk

Follow

@00dani there's a simple logging library that defined two classes: __NullLogger and __PrintLogger. they both implemented a few methods that would take a message you might want logged and do something with it. NullLogger ignores it, and PrintLogger prints it to stdout. so you'd pass in a NullLogger if you don't care, and a PrintLogger if you want to see what it does

but in the library itself, there are lines that say NullLogger = __NullLogger() and PrintLogger = __PrintLogger(). to use the library, you wouldn't instantiate your own logger object, you'd do from log import PrintLogger or whatever. i don't like that but. i guess it's fine

i was asked to implement a new logger object that would print to stdout and write to a file. while i was in there i cleaned things up a bit, had them all inherit from a new __BaseLogger class, whatever. but the problem is that at the time the library is imported, i don't yet know the filename they want me to be writing to, so i can't provide a global FileLogger object. you have to instantiate one yourself with the filename passed into the constructor

so not only are we doing this thing i think is gross, we're only doing it in 2 out of 3 cases

Sign in to participate in the conversation
glaceon.social

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!