Disqus - Friends of aaronoliver

Re: defaultdict.fromkeys does not play nice.

Matt Wilson — Tue, 03 Jun 2008 13:33:59 -0000

Hey Gary, thanks for the comment.

Setting the default_factory after I make an instance doesn't go back and rerun the keys through the default factory. So, in that sense, fromkeys is kinda useless to me. That's why I'd prefer that it just raised that NotImplementedError.

>>> b = defaultdict.fromkeys(['x', 'y'], list)
>>> b
defaultdict(None, {'y': <type 'list'="">, 'x': <type 'list'="">})
>>> b.default_factory = list
>>> b['z']
[]
>>> b['x']
<type 'list'="">

Re: defaultdict.fromkeys does not play nice.

Matt Wilson — Wed, 04 Jun 2008 10:32:46 -0000

Hey Georg,

Yeah, I agree that the defaultdict.fromkeys behavior is not a bug, but it does seem a little surprising. Anyhow, I posted to comp.lang.python here about this topic and got some pretty good explanation.

Re: Wacky idea for python coroutines

Matt Wilson — Sun, 15 Jun 2008 13:56:18 -0000

Florian -- I don't think I follow you. What do you mean by yielding across call stacks? How is that different than regular yield and send?

Re: Wacky idea for python coroutines

Matt Wilson — Sun, 15 Jun 2008 16:37:24 -0000

Florian, thanks for the extra detail. I think I need to study co-routines in stackless, pypy, and greenlets before I will really understand your point.

Re: My netflix problem

Matt Wilson — Wed, 18 Jun 2008 12:42:05 -0000

Sounds like a good idea. "No Country" in particular seemed really slow and grisly. Lindsey read the book Atonement, and she liked that, so that's how that one landed on the list.

Re: Wacky idea for python coroutines

Matt Wilson — Sat, 21 Jun 2008 09:48:42 -0000

Hi Calvin -- thanks for the comment! After the callback fires, how can I go back into the code that originally raised the exception? As far as I understand, that frame is inacessible.

Re: Don’t spend your termite poison money on insurance against Martian invasions.

Matt Wilson — Fri, 04 Jul 2008 01:13:03 -0000

Hi DomesticMouse,

Yeah, I agree, the lenders could lend to anyone that could scratch an X on the application, and they knew they could hand off the risk to somebody else down the chain.

I think Fannie Mae and Freddie Mac grew like tumors on lab rats during the go-go 90s. Now they're so highly leveraged that even moderate tremors causes the whole house of cards to crash down.

Re: Help improve my PyOhio talk

Matt Wilson — Tue, 08 Jul 2008 08:48:31 -0000

I think you did plug Bruce! Anyway, I'm not stuck with S5 at all. I really like reST, so I don't want to give that up. The fact that I can verify all my code snippets with doctest.testfile is immensely helpful.

Re: Help improve my PyOhio talk

Matt Wilson — Tue, 08 Jul 2008 08:50:04 -0000

Yep, you described the problems that kept happening last night. Gonna check out Bruce now.

Re: Help improve my PyOhio talk

Matt Wilson — Tue, 08 Jul 2008 17:49:32 -0000

So, Bruce could really benefit from a hello-world example on the web page. You gotta do a little to entice people!

Re: Help improve my PyOhio talk

Matt Wilson — Wed, 09 Jul 2008 18:11:53 -0000

Hi David, That is an approach I considered, but I really like the simplicity of a single presentation format. Less can go wrong.

I could do the whole presentation just from a single really-long text file, I suppose....

Re: Help improve my PyOhio talk

Matt Wilson — Wed, 09 Jul 2008 18:13:27 -0000

Hi Kumar,

Yeah, I used rst2s5.py also. Problems surfaced when the projector had a resolution of 1024x768, which is smaller than my laptop's 1440x900 resolution.

I'm going to study that starscream slideshow app also.

Re: Help improve my PyOhio talk

Matt Wilson — Sun, 13 Jul 2008 14:49:56 -0000

Thanks David, I think I'll take that path.

Re: I heart Python doctests

Matt Wilson — Mon, 14 Jul 2008 17:53:18 -0000

moved this comment to the reply it was meant to be.

Re: I heart Python doctests

Matt Wilson — Mon, 14 Jul 2008 17:58:21 -0000

Hi Michael, Thanks for the comment!

I'm not sure I understand your point about tests in several places. The tests are in two places at most; the docstring, and then whatever external tests I write. It isn't difficult to trace them all down quickly because everything is in predictable locations.

I think that the *right kind of tests* are useful as documentation. It's sometimes easier to show rather than tell. Sure, a 200-line docstring is goofy. But I don't find myself writing those kinds of doctests.

Re: I heart Python doctests

Matt Wilson — Mon, 14 Jul 2008 20:36:47 -0000

Hi Olivstor, I don't think you can invoke the Zen since Tim Peters is the guy that wrote both the Zen AND came up with the idea for doctests :)

But in terms of practicality, I think it would be straightforward to come up with some rules for when to use which test framework; e.g., if you need a big long list of fixtures, please use something besides a doctest.

So, the "obvious" way to do it would be to look at the testing needs and then let dictate which tool to use.

The "one obvious way to do it" doesn't mean (by my interpretation, anyway), to use the same tool for everything.

Python has for-loops, iterators, generator expressions, and map. They're all appropriate in different contexts.

Anyhow, thanks for the comment!

Re: I heart Python doctests

Matt Wilson — Mon, 14 Jul 2008 21:58:29 -0000

Hi Terry, Yeah, I do use the doctests plugin for nose. So when I run my doctests, I do $ nosetests --with-doctest blah.py

Well, actually, with-doctest=1 is in my $HOME/.noserc, so I don't need the --with-doctest option.

Re: I heart Python doctests

Matt Wilson — Tue, 15 Jul 2008 08:52:44 -0000

Masklinn -- thanks for the regexp help! I hoped there was a way to do it. Code updated.

Re: I heart Python doctests

Matt Wilson — Tue, 15 Jul 2008 08:55:41 -0000

Yeah, doctests are so simple to write that *anybody* can start writing tests, and I believe that any automated testing, even if it only covers 10% of the code, is still a huge help.

Re: Google Releases Mox for Python Mocking, I Giggle and Clap My Hands Like a Kid on Christmas

Matt Wilson — Thu, 17 Jul 2008 10:04:03 -0000

Maybe you should write a python mock shootout article. Every mock object package seems to fall down somewhere. And it would be nice to know the holes before I spend a few hours plowing through the cryptic docs and getting my hopes up.

If that article takes too long to execute, maybe write a much shorter article to stand in for the real thing. rimshot!

Re: I need to write faster tests

Matt Wilson — Fri, 18 Jul 2008 14:25:47 -0000

...

Re: I need to write faster tests

Matt Wilson — Fri, 18 Jul 2008 14:26:13 -0000

Hi Kumar, thanks for the comment! I saw your fixture project earlier today on planetpython. Right now, my setup code doesn't go through the app to setup. It makes a database connection directly and monkeys around.

All my tests use the same setup and teardown, so each test starts at the same state. That still might not let me run tests in parallel, however, since they're all working on the same user objects. If I could run all these in parallel, that would likely cut time way down. Maybe I could change my setup code so that each test gets objects created with names just for them.

I'll be the first one to admit that I have a lot more to learn in terms of testing. Right now, I feel a lot of frustration waiting for these things to finish execution.

I'll check out fixture over the weekend. Thanks for the tips.

Re: I need to write faster tests

Matt Wilson — Fri, 18 Jul 2008 20:25:22 -0000

Yeah, I think maybe there's nothing wrong with these narrative-based tests, but I would like to separate them from my other split-second tests.

Re: I need to write faster tests

Matt Wilson — Fri, 18 Jul 2008 20:27:28 -0000

The other thing that unit tests won't catch is when one unit alters its interface but the second unit doesn't find out about it.

Incidentally, I don't agree with the idea that interfaces shouldn't change. If I come up with a better way of doing something, I'm going to do it.

Re: Supply-side economics explained

Matt Wilson — Mon, 21 Jul 2008 09:03:56 -0000

...