Python logging module

[RCL-Carl]

Is anyone working on a python logging module ? I'd like to use the same interface that can target the web console but also for targeting other types of end points (like web sockets). I'd be interested in working on developing something like this. Would this be accepted as a module if I put something together ?

[JdeH]

No one is currently working on a logging module, so it would be very useful if you picked that up. From what I've seen from your re work, I expect that if you write a logging module, it will have a high chance of being accepted for the distribution.

The criteria for acceptance of a module as part of the distribution are:

1. Fits the design goals of Transcrypt

Clarity, speed, compactness and robustness are favored over 100% completeness. This means a module reliably covering the most common usecases without being bloated is a good candidate for inclusion.

2. Has an autotest coming with it

The reason for this is that the core of Transcrypt still is in flux, and with every modification we must make sure nothing has fallen over, i.e. that the core modifications didn't break any module that is part of the distribution. The only way to make this feasible with limited resources is automated back to back testing with CPython.

I've seen you already know this, but for other contributers who happen to read this: You'll find examples of autotests in https://github.com/QQuick/Transcrypt/tree/master/transcrypt/development/automated_tests. You can just add a logging folder there, as @AXGKI did for the time module that he contributed.

The simplest way to make the logging module suitable for autotesting would probably be to add a handler to it that would pass logger output to autoTester.check. That could e.g. be achieved by passing the autoTester instance to the handler and then have the handler call the check method for each message.

3. Has some documentation coming with it, as far as it deviates from the CPython version of that module.

Location of modules

1. Any 'standard' module that becomes part of the distribution will be in https://github.com/QQuick/Transcrypt/tree/master/transcrypt/modules. This prevents name conflicts with CPython. So if your module is called 'logging', this is where it should go since there's also a CPython module by that name.

2. In the rare case a module should be part of the distribution but there's a name conflict with other modules in the distribution, use Transcrypt's URL based module system, as is e.g. done with module: https://github.com/QQuick/Transcrypt/tree/master/transcrypt/modules/com/fabricjs which can be imported with:

from com.fabricjs import fabric

This requires that the contributer has a URL at his disposition. In general the import format would be:

from <myTopLevelDomain>.<myDomain>.<anyThing> import <myModule>

3. An alternative is creating a pip-installable module on PyPi . It should have a unique name, e.g. loggingscrypt, and preferably have 'transcrypt' it its keyword set, to be findable. Even in the case of a separately distributed module it is advisable to add an autotest, allowing quick regression testing at new releases of Trancrypt.

[axgkl]

@RCL-Carl : That would rock totally, to have on the server a log receiver for browser logs.

Maybe that would be a lightweight process to receive the logs(?): http://websocketd.com/

[RCL-Carl]

That would rock totally, to have on the server a log receiver for browser logs.

Yes, that is exactly what I'm thinking as an end goal.

I'm considering a first pass at the logging module consisting of:

• Most of the base classes for the logging module "Logger, Handler, etc"
• I would only implement the StreamHandler in the first pass
• No File-IO centric operations - ie, No FileHandler, etc. If someone wants to add them later for nodejs support or to the HTML5 storage concepts they can but I don't see a clear use case yet.
• I'm planning on having a "dictConfig" method from logging.config but nothing else

This would get us to a tested version that can log to the console with no dependencies. I think a websocket based implementation may have some javascript library dependencies. I think something like socket.io or sockjs, which ever is the preferred implementation these days. This keeps a lot of the browser dependent shimming out of the main project.

Thoughts?

[axgkl]

All cool if you ask me, can't wait. For me the way they do the server and client here would totally be fine for starters. In the short/midterm I think we need anyway a server sided companion for transcrypt - including some conventions regarding e.g. session, user, jwt keys, storage... Then the logger should be able to be configured matching on values of those (i.e only log for that userid or include the roles of the user within the log messages). And that should best be server sided dynamically reconfigurable, i.e. the formatter and config would be cool to be updateable without a reload of the app, via the websocket server I guess. Just 2 cents of mine, can't wait as said ;-)

[JdeH]

@RCL-Carl Took the liberty to assign this to you.

[RCL-Carl]

Ignore this message, I'm just trying to figure out how I can get an image hosted on github.