setup.py and file extensions like ".c++"
Is there any way to get setup.py to recognize file extensions like .c++ in lieu of .cpp? I'd love to not have to rename the source files for the library I'm trying to wrap in a python C extension. I get: error: unknown file type '.c++' (from 'parser.c++') when I type 'python setup.py build' thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list
accepting cStringIO in an extension
I want to accept a cStringIO object in a function in a python extension module. How do I do this? e.g., static PyObject *myfunc(PyObject *self, PyObject *args) { PyObject *cstringio; if (!PyArg_ParseTuple(args, "O:cStringIO", &cstringio)) { PyErr_SetString(PyExc_ValueError, "value must be a cstringio"); return NULL; } /* how to get at the data buffer or call read() on cstringio? */ } I understand that I probably want PyEval_CallObject(), but I don't know how to get at the read() method of cstringio. Thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list
customizing a logging logger
Suppose I have some sort of context variable that I want to appear in log messages. E.g.: logger = logging.getLogger("somelogger") class SomeOp: def __init__(self, ctx): self.ctx = ctx def method1(self): logger.info("%s: here's a message", self.ctx) What's the idiomatic way to abstract away the inclusion of self.ctx from the calls in logger.info() et al? Is there some way I can declare a @property def info(self): return logger.info but have it insert the '"%s: " % self.ctx' bit for me in one place instead of the dozens of places I currently do it in the class? Thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list
Re: customizing a logging logger
I think the following question is clearer. I want to make it so that method1 below can be transformed: logger = logging.getLogger("somelogger") class SomeOp: def __init__(self, ctx): self.ctx = ctx def method1(self): logger.info("%s: here's a message", self.ctx) logger.debug("%s: msg #2", self.ctx) v = 'yessir' logger.debug("%s: msg #3 %s", self.ctx, v) into something like: def method1(self): logger.info("here's a message") logger.debug("msg #2") v = 'yessir' logger.debug("msg #3 %s", v) What is the best way to do this, so that I don't have to manually put the self.ctx in the log string in hundreds of different places? Thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list
Re: customizing a logging logger
On Sep 12, 10:46 am, Vinay Sajip <[EMAIL PROTECTED]> wrote: > On 11 Sep, 17:14, [EMAIL PROTECTED] wrote: > > > What is the best way to do this, so that I don't have to manually put > > the self.ctx in the log string in hundreds of different places? > > Another way is to generate your log messages via a factory method > which prepends the context: you can do this via a mixin, too. > > def log_message(self, msg): > return "%s: %s" % (self.ctx, msg) > > Note also that in recent versions, an optional "extra" parameter can > be used, to pass info into the LogRecord. > > Seehttp://mail.python.org/pipermail/patches/2007-January/021535.html > which may be of some help - it's a similar use case. > > Best regards, > > Vinay Sajip The email thread you pointed to was very informative, especially since I was about to go down the road of creating one logger per context (eek!). Whichever method I choose, I am particularly concerned with the following aspect: I like to use the "logger.debug("msg %s %s", s1, s2)" format, as I understand that when the logging for this log level is turned off, we don't have to do the potentially expensive string building that a '%' operator would imply. It seems like using something other than a literal string in the message is the way to go, since I assume that its __repr__() won't get called unless the logger is actually going to log a message for it. Is that right? Are any of the other methods likely to provide as-good or better performance? thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list
Accessing overridden __builtin__s?
I'm having a scoping problem. I have a module called SpecialFile, which defines: def open(fname, mode): return SpecialFile(fname, mode) class SpecialFile: def __init__(self, fname, mode): self.f = open(fname, mode) ... The problem, if it isn't obvioius, is that the open() call in __init__ no longer refers to the builtin open(), but to the module open(). So, if I do: f = SpecialFile.open(name, mode) I get infinite recursion. How do I tell my class that I want to refer to the __builtin__ open(), and not the one defined in the module? Thanks, Gary -- http://mail.python.org/mailman/listinfo/python-list