chop() and empty() functions
I've been using the following lambda/function for a number of months now (I got the idea from someone in #python, though I don't remember who): def chop(s, n): """Chops a sequence, s, into n smaller tuples.""" return zip(*[iter(s)] * n) ...or... chop = lambda s, n: zip(*[iter(s)] * n) I was wondering if something like this already exists in Python proper somewhere, perhaps in an optimized way? (I checked itertools, but I didn't see anything right away). Furthermore, what do people think about the idea of adding a truly empty, no-op global lambda somewhere in Python? I use them a lot (usually defining a: empty = lambda *a, **k: None somewhere at the topmost module space), but if enough people did too, it might be worth adding an empty() builtin to much later versions of Python. Anyways, if these are stupid ideas I'm not surprised. Just some things I've been thinking about and figured I'd toss out there on my lunch break. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: chop() and empty() functions
On Sat, 2006-05-27 at 06:22 +1000, John Machin wrote: > On 27/05/2006 2:54 AM, Jeremy L. Moles wrote: > > ["chop" snipped] > > > > > Furthermore, what do people think about the idea of adding a truly > > empty, no-op global lambda somewhere in Python? I use them a lot > > What is the use case? Why write something like """empty(foo, 42, > cmd="xyzzy")""" when you could merely write "pass" or nothing at all? Well, in a lot of the libraries I use, there is often a need for a callback of some sort. Sure, I--and most other people--often define an empty, no-op function of some sort when you want to at least have "something" there, but I thought it might be kinda' neat to be able to have a builtin called empty() or noop() that returned a (possibly optimized?) function that just did nothing. :) It probably is a dumb idea, hehe... the chop() was the big one I thought people might comment on. For example, I often do stuff like this for handling "input events" in soya: evhandlers = [emptyfunc for i in range(MAX_NUM_EVENTS)] evhandlers[EVENT_NUMBER] = self.my_handler_function ...and then in the actual input loop I'll come along and say... evhandlers[ev](*args) In this way I don't have to test the value of any event and behave accordingly--I just send it on it's way. It's just an iterative way to say, "Okay, give me some default behavior for everything, and I'll come back around later and set the explicit handlers later." This same design is probably used in other areas too... that's why I brought up the "truly empty noop" thing; it would give me fuzzy feeling to know that in those cases where empty() is defined, nothing is happening (although, this could currently be the case in Python, I'm not sure--I don't know a lot about Python internals). Again, it's not a big deal. Just wondered what people thought. :) > > (usually defining a: empty = lambda *a, **k: None somewhere at the > > topmost module space), but if enough people did too, it might be worth > > adding an empty() builtin to much later versions of Python. > > -- http://mail.python.org/mailman/listinfo/python-list
Having to "print" before method invocation?
I have an object (written as part C extension, part pure Python) called foo that I've been using without much fuss for a few months now. However, in my latest project (a rather large one involving multi-threading, pygtk, etc.), I'm seeing some really strange behavior with a particular instance of my foo object. About midway through my program, any attempt to use the instance fails; however, if I add print statements before trying to invoke methods on it, the foo object instance works fine. I thought it might have something to do w/ reference counting, but calling sys.getrefcount() shows sane values both before and after the method call. I know it's almost pointless to ask this question w/out showing any code, but does anyone have any general ideas about what might make something "invalid" unless you print it to stdout before using it? -- http://mail.python.org/mailman/listinfo/python-list
Re: Having to "print" before method invocation?
Hey Fredrik, thanks for responding. :) Your posts are always helpful and informative! On Wed, 2006-03-08 at 15:41 +0100, Fredrik Lundh wrote: > Jeremy L. Moles wrote: > > >I have an object (written as part C extension, part pure Python) called > > foo that I've been using without much fuss for a few months now. > > However, in my latest project (a rather large one involving > > multi-threading, pygtk, etc.), I'm seeing some really strange behavior > > with a particular instance of my foo object. > > > > About midway through my program, any attempt to use the instance fails; > > however, if I add print statements before trying to invoke methods on > > it, the foo object instance works fine. > > fails in what way? Unfortunately, very silently. There aren't any exceptions thrown or anything. The be more specific, the C part of the object is a wrapper around some socket Send/Recv functions (that interface w/ wpa_supplicant). The problem I'm getting is that unless I add that print statement, wpaobject.Recv() returns "", whereas with the print statement it returns what it should (a large string representing the response from wpa_supplicant). More strange is that this is the first time I've had to do this. Up until this point, every unittest and app has succeeded without such trickery. > if you get a spurious exception, it's very likely that your C extension sets > the > exception state (either directly or because some API function it uses fails), > but > forgets to report this back to Python. > > e.g. if you have a C function that does something like > > PyErr_SetString(PyExc_AttributeError, "blah blah"): > > Py_INCREF(Py_None); > return Py_None; > > instead of > > PyErr_SetString(PyExc_AttributeError, "blah blah"): > > return NULL; > > the interpreter won't raise the exception immediately (since it expected you > to > return NULL if something went wrong), but the exception may still be raised at > a later time, if you run interpreter code that does something like > > do something > if (PyErr_Occurred()) > ... /* this will catch your error even if "something" succeeds */ ... > > *or* it may be masked, by code that does > > PyErr_Clear(); > do something > > the actual exception might give you additional clues (e.g. if you get a > KeyError, > look for unchecked dictionary accesses in your code, etc). > > hope this helps! > > > > -- http://mail.python.org/mailman/listinfo/python-list
