[Python-Dev] Making loggerClass an attribute of the logger manager?
Hi, recently I had a use case where I wanted to use logging in two completely separate parts of the same process. One of them needs to create instances a specific Logger subclass, while the other is fine with the default loggers. I got around the problem of the unique root node by using two Managers (and then using Manager.getLogger() instead of getLogger()), but I can only set the loggerClass globally. Making the loggerClass configurable per manager would solve the problem for me, and AFAICS since most applications don't use different managers anyway, there should not be any detrimental effects. What do you think? cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making loggerClass an attribute of the logger manager?
Georg Brandl gmx.net> writes: > Making the loggerClass configurable per manager would solve the > problem for me, and AFAICS since most applications don't use > different managers anyway, there should not be any detrimental > effects. What do you think? Seems reasonable. Apart from the API to set/get, _loggerClass is only used by the manager when instantiating a new logger. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 391 ready for review
Full View PEP 391 is, I believe, ready for review. http://www.python.org/dev/peps/pep-0391/ I've also worked up an implementation, though not yet checked it in: it's available as a module "dictconfig.py" with accompanying unit tests in "test_dictconfig.py", at: http://bitbucket.org/vinay.sajip/dictconfig I believe I have incorporated into the PEP comments from people both here and on python-list. There have been comments in favour of the proposal, no objections to the proposal as a whole, and some questions and objections about specific details. I believe I have addressed these with changes to the PEP. Discussion threads on python-dev: http://mail.python.org/pipermail/python-dev/2009-October/092695.html http://mail.python.org/pipermail/python-dev/2009-October/092782.html http://mail.python.org/pipermail/python-dev/2009-October/093062.html And on python-list: http://mail.python.org/pipermail/python-list/2009-October/1223658.html http://mail.python.org/pipermail/python-list/2009-October/1224228.html There hasn't been a *huge* amount of discussion, but as it's a niche topic I suppose that's fair enough. I'm ready to actually integrate these changes in the core logging package. As I understand it, the next step is to put the PEP forward for review, which is why I'm sending this mail. I've already sent an equivalent mail to the PEP editors: David Goodger suggested I incorporate the above links (done) and Brett Cannon suggested I send this to python-dev - also, now, done. Looking forward to the feedback! Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 ready for review
I would recommend removing the class keyword and replacing it with the () as you have in the custom examples or replacing () with class so it is uniform across all config options handlers: file: class : logging.handlers.RotatingFileHandler formatter: precise filename: logconfig.log maxBytes: 1024 backupCount: 3 custom: (): my.package.MyHandler alternate: cfg://handlers.file This just strikes me as odd to have to remember for built in handlers I need to use the class keyword and for my custom handlers I need to use (). My preference would be the class keyword vs the odd (), as that is what I am defining, the class to be used for this handler. The ext:// I think should be py:// when defining objects to be access via pythons normal import mechanisms and ext:// for resolving external processes or system calls ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 391 ready for review
Vinay Sajip wrote: Full View PEP 391 is, I believe, ready for review. http://www.python.org/dev/peps/pep-0391/ This is my first reading of this. Comments: nit: I believe "both of these serialization formats allow deserialization of Python dictionaries." should be "... to Python dictionaries." "bespoke configuration methods" I had to look up this mostly non-American British word, which I thought meant 'engaged (to be married, as in spoken for)' to guess that you probably mean the much more obscure 'custom configuration methods'. If so, please say so (in plain American ;-) "The logging.config module will have the following additions:" There is currently only one addition. "Nothing will be returned, though exceptions will be raised " Technically incorrect. "Returns None; exceptions ..." or just "Exceptions ...". The doc for print(), for instance, just says what is does and does not mention the default None return. "particular logger has an attached to it a particular handler." delete 'an' " '()' : 'my.package.customFormatterFactory', " This at first appeared to be a typo. You earlier wrote "the user will need to provide a 'factory' - a callable which is called with a configuration dictionary and which returns the instantiated object. This will be signalled by the factory being made available under the special key '()'. " A string is not a callable. So I thought you perhaps meant " '()' : my.package.customFormatterFactory, " without the quotes, or " '()' : <>, ", where <> is understood to be a place filler for an object of the type specified. Then I see "the specified factory callable will be located using normal import mechanisms" If you stick with this, then "This will be signalled by the factory being made available under the special key '()'." would be clearer as "This will be signalled by an absolute import path to the factory being made available under the special key '()'." However, if the code that constructs the dict passed to dictConfig() has the factory in hand, and possibly no absolute import path, why not let it pass the function directly instead of indirectly. (I am here using 'absolute import path' to mean one that logging can resolve, rather than being only resolvable from the dictConfig caller.) Being able to do so is one of the great features of Python. The code for dictConfig could easily wrap the current import. if not hasattr(factory, '__call__'): factory = __import__(factory) "The '()' also serves as a mnemonic that the corresponding value is a callable." More than just that, parentheses preceeded by an expression *are* a call operator, mapped to '__call__', just as the addition operator '+' is mapped to '__add__'. Great choice to me. ... "If serialization is successful, then dictConfig() will be called to process the resulting dictionary" deserialization Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Building a Windows MSI for Python /trunk
Hi all, I got an MSI build working on my WinXP VM just now, and I wanted to touch base with whomever it is that is maintaining this (wonderful!) set of scripts... I ran into three problems, and I managed to figure out two of them; the third wasn't fatal. Note, the diff of my fixed checkout is attached. First, the script that finds & builds the external dependencies has two minor problems. * it puts Tcl in tcl-8.*, and Tk in tk-8.*, but msi.py looks for them in tcl8.* and tk8.* to grab the license text. I changed the glob strings appropriately and that seemed to work. * Tix isn't downloaded/installed/built automatically like everything else, and msi.py looks for its license file, too. I just removed the Tix reference. I can't figure out how to build Tix appropriately; any tips? Second, the buildmsi.bat file refers to python26a3.hhp instead of python27a0.hhp. Third, I could not get _tkinter to build properly, although it wasn't fatal to the endeavor. It couldn't find ..\..\tcltk\lib\tcl85.lib, although tcl85g.lib existed. Oh, and there were a bunch of missing commands that (as a non-Windows xpert) I had to figure out with google -- things like nasm/nasmw, for example. Are these documented somewhere, or would it be helpful to document them? I think I had to install: - Microsoft HTML Help Compiler - cygwin with make and python2.5 to build the docs - nasm (and copy nasm.exe to nasmw.exe) - cabarc Errm, and the 'buildmsi.bat' file has 'build' misspelled as 'buold' ;) I'd love to get this build process working completely automatically and 100% correctly, too. Hat tip to Trent Nelson, who helped me figure out where the scripts are and what other things I needed... cheers, --titus -- C. Titus Brown, [email protected] Index: Tools/msi/msi.py === --- Tools/msi/msi.py (revision 76532) +++ Tools/msi/msi.py (working copy) @@ -875,9 +875,8 @@ for name, pat, file in (("bzip2","bzip2-*", "LICENSE"), ("Berkeley DB", "db-*", "LICENSE"), ("openssl", "openssl-*", "LICENSE"), - ("Tcl", "tcl8*", "license.terms"), - ("Tk", "tk8*", "license.terms"), - ("Tix", "tix-*", "license.terms")): + ("Tcl", "tcl-8*", "license.terms"), + ("Tk", "tk-8*", "license.terms")): out.write("\nThis copy of Python includes a copy of %s, which is licensed under the following terms:\n\n" % name) dirs = glob.glob(srcdir+"/../"+pat) if not dirs: Index: Tools/buildbot/buildmsi.bat === --- Tools/buildbot/buildmsi.bat (revision 76532) +++ Tools/buildbot/buildmsi.bat (working copy) @@ -9,7 +9,7 @@ @rem build the documentation bash.exe -c 'cd Doc;make PYTHON=python2.5 update htmlhelp' -"%ProgramFiles%\HTML Help Workshop\hhc.exe" Doc\build\htmlhelp\python26a3.hhp +"%ProgramFiles%\HTML Help Workshop\hhc.exe" Doc\build\htmlhelp\python27a0.hhp @rem buold the MSI file cd PC ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
