Wandering Thoughts archives

Created functions and exception stack backtraces

There's a problem with functions that make functions: they obscure information in exception stack backtraces, because all of the created functions have the same name. If you have a lot of auto-created functions, just which one is blowing up and how do you tell them apart?

(I noted a similar effect with lambdas back here.)

A function's name is part of its func_code attribute, specifically func_code.co_name. Unfortunately this attribute is read-only, so you can't have your function creating function rewrite the name of a created function to something more useful for stack backtraces. (While you can change the function's __name__ attribute, it is not used for stack backtraces.)

A similar effect happens with functions that create classes (don't look at me like that; sometimes it can look like the right thing to do). Fortunately, you can rename classes by writing to their __name__ attribute and thus make it so that objects of each different created class have a a distinct repr() and so on, which is quite useful for debugging the resulting potential mess.

(I think changing __name__ is somewhat less work than writing a custom __repr__ function in the generic class framework, and besides you'd have to save the naming information somewhere anyways.)

Microsoft has another problem

As sort of a successor of a previous entry, here is a thesis:

Increasingly, people use Microsoft Windows not because they want to but because they have to.

(There's various reasons they have to: they're forced to by their employer, they need to use programs that only run on Windows, such as IE or Microsoft Office or various computer games, or even because the alternative costs too much.)

This is a problem for Microsoft, because customers that are only using you because they don't have a choice are extremely fickle customers; they are not a good source of long term success. It is much better to offer your customers something they find intrinsically valuable and actively like, instead of just being something they have to tolerate on the way to their real interest.

Now, this is only a thesis; I don't have enough exposure to the Windows world to know if it is actually true. But it is certainly my perception, and definitely my perception that it is not true of the Apple world, that Mac users are using Macs because they want to and like it.

(It is certainly not true of my own Unix usage; I use Unix on my desktops because I actively like the environment. This makes me rather peculiar, all things considered.)

Link: you are what you code

From Robert Brewer comes You are what you code, which has given me something to think about. I'll quote the opening:

Hey, you. Do you realize what you're writing? The long-standing IT joke is that you always end up coding your own job out of existence. But what are you coding yourself into?

(From Planet Python, where his blog is aggregated.)

Update: I apologize to my readers for putting a link here that doesn't work without an extra, annoying step (see the comment).

Update2: the situation has now been fixed.

A simple debugger feature that I would really like

Following up on my earlier thoughts about print based debugging, here's an easy debugger feature that would make my life much better (and make me more inclined to actually use debuggers):

Provide a way to record things that doesn't show them to me until I ask for them.

I'm not actually interested in reading the things that I print out, not right away; I'm just collecting the information so that I can look back in time at the program's state once the bug strikes. The only reason I'm printing things out is that this is the only decent way debuggers give me to dump information for later perusal.

Thus, hiding the stuff that I want to record until I actually ask for it is a big net win, because it avoids drowning me in output that I'm just going to ignore until later anyways. As a bonus the debugger would probably run faster because it doesn't have to display and scroll all that text.

This more or less requires a graphical debugger with some sort of scrollback buffer, but it should be an easy feature to implement. Pretty much everything has a 'print something at a breakpoint' feature, and once you have a scrollback buffer it ought to be relatively trivial to insert content into the scrollback area without actually putting it on the screen.

A debugger would get bonus points for making the record searchable, and more bonus points for being able to directly snapshot the state of variables and the like rather than just saving text output. (This might also make the data take up less memory. You do want to provide for journaling text, since sometimes that's the best way summarizing some bit of state.)