Function call arguments in stack trace?
Hi, In a stack trace, is it possible to somehow get the arguments with which each function was called? So for example, if function `foo` in module `bar` was called with arguments `(1, [2])` when it raised an exception, then instead of: Traceback (most recent call last): File "bar.py", line 123, in foo build_rpms() The stack trace would read: Traceback (most recent call last): File "bar.py", line 123, in foo(1, [2]) build_rpms() This would save a lot of debugging time! Thanks, D. -- http://mail.python.org/mailman/listinfo/python-list
Re: Function call arguments in stack trace?
On Jun 7, 1:23 pm, Neil Cerutti wrote: > Use pdb. Neil, thanks for the tip; `pdb` is indeed a great debugging tool. Still, it doesn't obviate the need for arguments in the stack trace. For example: 1) Arguments in stack trace can expedite a debugging session, and even obviate it completely: "Why did `foo()` fail? Oh, because it got `-1` as its first argument, while I only coded for positive integers!". 2) In some environments, it's very hard to recreate a rare exception and analyze it with `pdb`. For instance, on a web application that emails the stack traces of unhandled exceptions, it's very important for that stack trace to be as informative as possible, since often that's the only debugging feedback you will get. Hope that makes sense, D. -- http://mail.python.org/mailman/listinfo/python-list
Why doesn't this asyncore.dispatcher.handle_read() get called?
Hi,
I'm writing and testing an asyncore-based server. Unfortunately, it
doesn't seem to work. The code below is based on the official docs and
examples, and starts a listening and sending dispatcher, where the
sending dispatcher connects and sends a message to the listener - yet
Handler.handle_read() never gets called, and I'm not sure why. Any
ideas?
Thanks, D.
import asyncore, socket, sys
COMM_PORT = 9345
class Handler(asyncore.dispatcher):
def handle_read(self):
print 'This never prints'
class Listener(asyncore.dispatcher):
def __init__(self, port=COMM_PORT):
asyncore.dispatcher.__init__(self)
self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
self.set_reuse_addr()
self.bind(('', port))
self.listen(5)
def handle_accept(self):
client, addr = self.accept()
print 'This prints.'
return Handler(client)
class Sender(asyncore.dispatcher):
def __init__(self, host):
asyncore.dispatcher.__init__(self)
self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
self.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
self.connect( (host, COMM_PORT) )
self.buffer = 'Msg\r\n'
def handle_connect(self):
pass
def writable(self):
return len(self.buffer) > 0
def handle_write(self):
sent = self.send(self.buffer)
self.buffer = self.buffer[sent:]
def test_communication():
from multiprocessing import Process
def listener():
l = Listener()
asyncore.loop(timeout=10, count=1)
lis = Process(target=listener)
lis.start()
def sender():
s = Sender('localhost')
asyncore.loop(timeout=10, count=1)
sen = Process(target=sender)
sen.start()
lis.join()
test_communication()
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't this asyncore.dispatcher.handle_read() get called?
On Apr 20, 3:01 pm, Jean-Paul Calderone wrote: > You didn't let the program run long enough for the later events to > happen. loop(count=1) basically means one I/O event will be processed > - in the case of your example, that's an accept(). Then asyncore is > done and it never gets to your custom handle_read. Wow, a response from a Twisted founder and core developer =) You were right, of course. Incrementing the count to 2 on the asyncore.loop() calls makes the snippet work as expected. I'd definitely rather use Twisted. It's unclear why transmitting a bytestream message between two servers should require low-level socket incantations such as `self.create_socket(socket.AF_INET, socket.SOCK_STREAM)` or `self.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)`. The stdlib should offer a higher-level asynchronous communication abstraction to support such a straightforward usecase. Twisted does provide that, but my humble needs can't justify the extra dependency cost. Thanks a lot, D. -- http://mail.python.org/mailman/listinfo/python-list
Why do directly imported variables behave differently than those attached to imported module?
Hi! Here's the demonstrating code: # module foo.py var = 0 def set(): global var var = 1 Script using this module: import foo from foo import * print var, foo.var set() print var, foo.var Script output: 0 0 0 1 Apparently, the `var` we imported from `foo` never got set, but `foo.var` on the imported `foo` - did. Why? Thanks, D. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do directly imported variables behave differently than those attached to imported module?
OK, I understand now. `from foo import var` means "create a module-global name `var` inside the current module, and have it point at the object `foo.var` is pointing at (following its evaluation)". Naturally, regardless of whether `foo.var` ever changes, the global `var` of the current module still points at the original object `foo.var` was pointing to at the time of the `var = foo.var` assignment. Thanks, D. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why do directly imported variables behave differently than those attached to imported module?
P.S. now I have to ask: is there a symbolic reference in Python, i.e. a name foo that points to "whatever bar.baz is pointing at"? Thanks, D. -- http://mail.python.org/mailman/listinfo/python-list
Best Git library for Python?
Hi folks, I'm writing a Python program to operate on Git repositories. The program works at the user level of abstraction: i.e. it needs to do everything that an end user can do with Git. I'm talking about the high-level commands like git-clone, git-branch, git-fetch, git-merge, git-rebase, git-push. Having lower-level functionality would be nice, but not essential. What is essential is reliability: the library should work correctly even under reasonable load, and fail noisily and predictably in the extreme situations that simply can't be handled correctly. What's the best library to use? Thanks, D -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Git library for Python?
On Oct 4, 4:04 pm, Lawrence D'Oliveiro wrote: > Why not just call Git itself? That's what I'm doing right now, but since this is a mission-critical process, it would be nice to have a more reliable exception detection and handling mechanism. With my straight calling-out-to-git implementation, the calling Python code doesn't even know about crashes or any kind of out-of-band behavior, much less able to do something about it. Also, I assume a library could provide an additional safety net over a bare "subprocess out to the git CLI client", improving the consistency of its behavior. For instance, it could implement mutex locks to avoid operations running over each other, which is important for our high- load needs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Git library for Python?
On Oct 4, 7:23 pm, Lawrence D'Oliveiro wrote: > You can already check the exit status from the subprocess. What more do you > need? A robust mechanism to deal with said issues... Of course I can write it myself, but it would save much time and effort if I could use something that's already written. D -- http://mail.python.org/mailman/listinfo/python-list
Fastest way to detect a non-ASCII character in a list of strings.
`all_ascii(L)` is a function that accepts a list of strings L, and
returns True if all of those strings contain only ASCII chars, False
otherwise.
What's the fastest way to implement `all_ascii(L)`?
My ideas so far are:
1. Match against a regexp with a character range: `[ -~]`
2. Use s.decode('ascii')
3. `return all(31< ord(c) < 127 for s in L for c in s)`
Any other ideas? Which one do you think will be fastest?
Will reply with final benchmarks and implementations if there's any interest.
Thanks, D
--
http://mail.python.org/mailman/listinfo/python-list
Re: Fastest way to detect a non-ASCII character in a list of strings.
On Mon, Oct 18, 2010 at 1:41 AM, Stefan Behnel wrote: > Or, a bit shorter, using Cython 0.13: > > def only_allowed_characters(list strings): > cdef unicode s > return any((c < 31 or c > 127) > for s in strings for c in s) Very cool, this caused me to look up the 0.13 release notes: http://wiki.cython.org/ReleaseNotes-0.13 So they support generator expressions inside all() et al now... Makes you wonder how long till they support them generally ;-) D -- http://mail.python.org/mailman/listinfo/python-list
Re: Fastest way to detect a non-ASCII character in a list of strings.
On Wed, Oct 20, 2010 at 6:52 AM, Stefan Behnel wrote: > Well, the estimate is about one man-month, so it would be doable in about > three months time if we had the money to work on it. So far, no one has made > a serious offer to support that project, though. I find myself surprised at the relatively little use that Cython is seeing. You would expect a whole lot of organizations and people to fancy a language that's about as high-level as Python, yet almost as fast and down-to-the-metal as C. Add to that the ability to seamlessly integrate with both your existing C/++ codebase and your Python codebase, easily mix very high level abstractions with very low-level machine access... clear winner. I'd expect Cython to have a far larger userbase, with a long line of sponsors queuing up to fund further development. Maybe it will get there some day :-) D -- http://mail.python.org/mailman/listinfo/python-list
