Wednesday, March 23, 2005

Cool PyCon acquaintances

  • Sprints

    • Mike "Bear" Taylor - working on release management (I think) for OSAF. Also kindly providing a windows buildslave for Twisted's buildbot. We've talked a lot on IRC before and exchanged some email.

    • Brian Kirsch - also working for OSAF. Brian's basically in charge of all their email stuff. We've spoken on IRC and on the phone before, and exchanged a lot of code :) Brian has contributed a lot of cool new SMTP code that has improved Twisted's mail support for 2.0.

    • Alex "mesezoic" Levy - another fellow I know from IRC, though we've lived in the same city for a few months now, PyCon was the first chance we had to meet. Alex hacks on nevow and did some sprinting on Twisted WSGI.

    • David Reid - also someone I've known on IRC for a while (noticing a pattern?). David sprinted on adding wildcard subdomain support to twisted.names (a Twisted subproject started deep in the mists of the past which I revived and brought to usability a couple years ago, but haven't developed on much since).

  • Conf day 1

    • Abe Fettig - author of Hep. Also working on another really cool project, but I'm not sure how public it is supposed to be yet so I won't say what it is :)

    • Neal Norwitz - someone whose name I've seen around a lot but who I've never really interacted with. Apparently he is old friends with my housemate. We hung out for a bit around lunch time and chatted about random things.

    • Michelle Levesque - briefly introduced myself in the afternoon after going to her talk. PyWebOff turned out quite excellently despite my underhanded attempts to thwart it ;) It's unfortunate all the talks were limited to half an hour this year; there was certainly a lot more than 30 minutes worth of content in this talk. Given the time constraint, I think this was best presented talk of the day of the ones I saw (except perhaps the keynote, but it's hard to beat a talk with so much dead parrot humor).

    • Jason "jmob" Mobarak - more Twisted folk (at least that's my to him relationship - guess via what medium we most frequently communicate ;). He also kindly hosts an IRC bot for me (it's easy to forget how nice it is to be able to reboot your desktop until you can't).

    • Cory "MFen" Dodt - some crazy fellow from California. Oh yea, he's a Twisted developer. He builds the Windows installers for Twisted as well. Previously only knew him on IRC.

    • Sinistrad - Unfortunately I forget his real name :) We met near the end of the day and chatted about random stuff, mostly work related. He's another guy I know from IRC.

Of course I also got to see a bunch of really people I met at last PyCon (or the PyCon before) too. I was going to list 'em here too but it's getting too late and there are too many and I'd probably forget a bunch of people anyway :)

I attended some presentations too. I already mentioned PyWebOff, but I also saw the py.test talk. Twisted's test framework has some problems and I've wanted to replace it for a few months now. py.test might make a good starting place. It has some really incredibly awesome features, but there are also some deep magic hacks which it includes which I am less certain about. At the very least it bears further investigation though. The py.test talk also included a brief section on py.execnet which mostly just made me sad. Luckily it has nothing to do with py.test, they're just beneath the same package.

The other cool talk of the day was MissionEngine. Their page is pretty good (and with pretty pictures) so I'll leave it at that.

All in all, an excellent start to the conference.


  1. Made you sad? Why?

  2. I wanted to grab some specific examples from the code to respond to this, but seems to have gone down shortly after the py.test talk and still isn't up yet.

    The general gist being that they could have created a lot more functionality and made it accessible much more conveniently with a lot less code with just a little bit of re-use from other projects.

    If codespeak comes back in the next couple days I'll post with some more specifics.

  3. Asynchronous / Synchronous - which is it? Well, it's synchronous, but you couldn't tell that from the number of times asynchronous is used in the documentation and in comments in the code. Holger must mean something different by the word than what most people do when using it (perhaps "multithreaded"?).

    Calls out to "ssh". Ick. Problems with shell escapes and such make it even _more_ insecure than one might otherwise expect it to be (eg, it only escapes ', not \!).

    Ultimately it appears superficially as though py.execnet might be useful for quite a few things but is actually not suitable for anything. Hence sad.

  4. codespeak is back since some time and i am interested in specifics :-)

  5. Thanks for the clarification holger :)

    I must have misread some of the argument quoting code, since it appeared something was trying to do shell quoting. I'll take your word for it that this isn't what's going on.

    As for remote_exec()/receive(), I'm not sure what it buys you to have remote_exec() return immediately if channel.receive() blocks. Is there a way to poll channel.receive() to see if it will return immediately or block? If not, how do you handle multiple concurrent remote_exec()s? Or is that beyond the intended scope of py.execnet?

    It is a shame we didn't talk at PyCon, although I would have rather spent the time picking your brain about py.test :) I may try to do that at some point anyway, but only once I get a good block of time to work on improving Twisteds test harness.

  6. I agree that polling is bad, but it seems to be provided more commonly than saner APIs, so that's what I asked about :)

    > if channel.hasdata():
    > item = channel.receive()

    Am I correct in thinking that the reason you say channel.receive() might block in the above is that another thread might call receive() on that channel after the hasdata() call and before the receive() call?2 In that case I can see why.

    The API _I_ would much prefer, of course, is channel.onReceive(objReceivedCallback), or perhaps remote_exec(...).addCallback(objReceived), but you probably could have guessed that >:)

    (Of course I'm not using execnet for anything, so don't go to any trouble on my account :)

  7. > if channel.hasdata():
    > item = channel.receive()

    >> Am I correct in thinking that the reason you say channel.receive()
    >> might block in the above is that another thread might call receive()
    >> on that channel after the hasdata() call and before the receive()
    >> call?2 In that case I can see why.

    Yes exactly.

    Adding a "callback" (and errback, eh? :-) is easy in principle. But as
    i am assuming multithreaded programs it would need to be defined in what thread(s) that callback will run.