Re: tuple to string?

Robert Kern wrote: >Francois De Serres wrote: > > > >>I'll pick ('%c' * len(t)) % t, for it's readability and the fact that >>join() is on the deprec'd list. >> >> > >''.join() is certainly not deprecated. What m

Re: tuple to string?

Francois De Serres wrote: >hiho, > >what's the clean way to translate the tuple (0x73, 0x70, 0x61, 0x6D) to >the string 'spam'? > >TIA, >Francois > > thanks to all! I'll pick ('%c' * len(t)) % t, for it's readability and the

tuple to string?

hiho, what's the clean way to translate the tuple (0x73, 0x70, 0x61, 0x6D) to the string 'spam'? TIA, Francois -- http://mail.python.org/mailman/listinfo/python-list

Exception in callback => GPF?

Hiho, When there's an unhandled exception in my extension-module's-callback-into-Python-function-object, I get a GPF and Python exits. When the exception is being handled within the callback (hence in Python), I get a very significant hiccup (1 to 5 seconds freeze). Question: is there a specif

Re: Documenting extension modules?

Simon Dahlbacka wrote: >Re: assigning a PyStr object to __doc__, take a look at Py_InitModule3, >which does that for you. > > > got it, thx. >Then you have the PyDoc_STRVAR macro in python.h that you might want to >use (see definition below). But as Robert already told you, you'll need >to prov

Re: Documenting extension modules?

Robert Kern wrote: >Francois De Serres wrote: > > >>Hiho, >> >>I can't seem to find a proper way to document my extension module. >>Following the C API doc: >> >>static PyMethodDef ioMethods[] = { >>{"o_count", o_c

Documenting extension modules?

Hiho, I can't seem to find a proper way to document my extension module. Following the C API doc: static PyMethodDef ioMethods[] = { {"o_count", o_count, METH_VARARGS, "Return the count of available MIDI outputs."}, } lacks: a) module level documentation b) function parameters Also,

Re: Building a function call? (update)

Scott David Daniels wrote: >Francois De Serres wrote: > > >>Francois De Serres wrote: >> >> >>>Having a string: "dothat" >>>and a tuple: (x, y) >>>1. What's the best way to build a function call like: dothat(x,y)? >>

Re: Building a function call? (update)

Duncan Booth wrote: >Francois De Serres wrote: > > > >>Sorry, I was unclear about the fact that the args are formals. I'm >>trying to do something like: >> >>func = "dothat" >>args = ('x','y') >>localcontext =

Re: Building a function call?

Steven D'Aprano wrote: >On Wed, 13 Jul 2005 06:16:54 -0700, Robert Kern wrote: > > > >>Duncan Booth wrote: >> >> >>>Francois De Serres wrote: >>> >>> >>> >>>>Having a string: "dothat"

Re: Building a function call? (update)

Francois De Serres wrote: >Hiho, > >Having a string: "dothat" >and a tuple: (x, y) >1. What's the best way to build a function call like: dothat(x,y)? > >Assuming dothat is def'd in the same module, >2. is: eval("dothat(x,y)", None, ((

Re: **kwargs?

Michael Hoffman wrote: >Peter Hansen wrote: > > >>Francois De Serres wrote: >> >> >> > > > >>>*args is documented in the Tutorial. I reckon **kwargs represents a >>>dictionary of arguments. But I don't quite get the semant

Re: Building a function call?

Peter Hansen wrote: >Roland Heiber wrote: > > >>Not the best (not at all) but one way: >> >>def dothat(x,y): >> print "Called with:", x, y >> >>c = (1,2) >> >>locals().get("dothat")(*c) >> >> > >As you say, not the best, but in fact not really advisable under any >circumstances. locals()

Re: Building a function call?

Roland Heiber wrote: >Francois De Serres wrote: > > >>Hiho, >> >>Having a string: "dothat" >>and a tuple: (x, y) >>1. What's the best way to build a function call like: dothat(x,y)? >> >> > >Not the best (not at

**kwargs?

All your **kwargs are belong to us. *args is documented in the Tutorial. I reckon **kwargs represents a dictionary of arguments. But I don't quite get the semantics of **x. Undefined length tuple of undefined length tuples? Are there other practical use cases for ** (common enough please, I wis

Building a function call?

Hiho, Having a string: "dothat" and a tuple: (x, y) 1. What's the best way to build a function call like: dothat(x,y)? Assuming dothat is def'd in the same module, 2. is: eval("dothat(x,y)", None, (('x', 100), ('y', 200))) the right way to have it executed? If dothat is def'd in another module:

The GIL, callbacks, and GPFs

Hello, I'm chasing a GPF in the interpreter when running my extension module. It's not very elaborated, but uses a system (threaded) callback, and therefore the GIL. Help would be mucho appreciated. Here's the rough picture: win32_spam.c /* code here is unit-tested OK */ typedef st

Re: (Win32 API) callback to Python, threading hiccups

Christopher Subich wrote: >Francois De Serres wrote: > > >>- so, on callback, I create a new thread, after checking that the >>previous one has returned already (WaitOnSingleObject(mythread)) so we >>only have one thread involved. >> >> > >

(Win32 API) callback to Python, threading hiccups

ll I figure out what's really happening. Could someone save my precious and already sparse sleeping time, by pointing me to what I'm missing here? WinXP SP1 Python 2.4.1 MinGW GCC 3.4.2 TIA, Francois De Serres -- http://mail.python.org/mailman/listinfo/python-list