Ticket #1075 (reopened enhancement)

Opened 1 year ago

Last modified 2 months ago

Ditch Dabo's logger objects; use Python's logging

Reported by: paul Assigned to: dj
Priority: minor Milestone: 0.8.3
Component: ui Version:
Keywords: Cc:

Description

Let's harness the power of Python's logging objects instead of continuing implementing our own. We encourage anyone with the time and inclination to jump in and get this done. Any questions just ask on dabo-dev or as a comment to this tracker item.

Change History

06/21/07 20:34:02 changed by dj

  • owner changed from somebody to dj.

I modified the log Object, though it is not subclassing Pythons Logger it behaves much more like it.

06/21/07 20:35:47 changed by dj

  • status changed from new to closed.
  • resolution set to fixed.

I modified the log Object to behave more like Pythons Logger, though It is not a subclass of the Python Logger. [Revision 3194]

06/22/07 08:48:30 changed by paul

  • status changed from closed to reopened.
  • resolution deleted.

Ok, let's try this again. :)

Revision [3194] caused Dabo apps to stop running. This caused the following:

  • Dabo API Docs were not auto-generated last night
  • The nightly tarball posted on Dabo-dev today will not work if anyone downloads it

There were at least a few obvious syntax errors (obvious if the changes had been tested before committing). These are:

  • bitwise ~= causes a syntax error in Python.
  • missing comma in a property definition
  • 'self' doesn't exist in the context of a method signature

Even after I fixed the above problems, something else somewhere keeps my Dabo app from starting:

  class SelectTextBox(SelectControlMixin, dabo.ui.dTextBox): pass
TypeError: Error when calling the metaclass bases
    metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclass of all its bases

I have no idea why changing the logger would affect something in the ui layer, and I don't have any inclination to continue hunting down these errors at this time.

Now that I'm looking at this, why bitwise anyway (why not a Python list)? And why not use Python's logger instead of continuing to roll our own?

If you want to do this again, please make a branch by issuing:

svn copy http://svn.dabodev.com/dabo/trunk http://svn.dabodev.com/dabo/branches/dj

then make your changes to the branch, test, and when confident that the changes will result in a functional drop-in for the existing logger, merge it back into the trunk.

Thanks.

06/22/07 13:34:17 changed by dj

Ok, I'll add the branch when I commit again.

I did bitwise mainly because I was reusing much of the code from the logger I wrote for an app I am working on and thats how I did it there.

And why not use Python's logger instead of continuing to roll our own? I guess cause I again was reusing code I already had, I'll rewrite it to subclass Pythons

06/22/07 13:49:28 changed by dj

Ahh, now that I go review Pythons logger I remember why I didnt use it in the first place and used a bitwise method for determining the level.

I used bitwise so I could turn on or off specific logging levels (This is achievable with the python list, I just didnt think about it when I wrote it)

I did not use the python logger because of the same reasons. If I wanted to turn on my debugging statements it would also turn on all levels above it. So say I add a Custom level DB, where do I put it, above or below INFO. If I want DB statements, but not INFO statements I put it above, but then if I want INFO statements and not DB's I need to put it bellow. Either that or I have to have separate instances of the logger for each level, which would be exactly how you have it now. and Ed seemed to want a single instance that mapped directly to dabo instead of dabo.loggerinstance.write

06/22/07 15:36:32 changed by dj

Ok, reworked the logger so it actually works, and created my own branch so you can test it out without breaking your working copies.