Will's blog

Carl put up a Pledgie campaign for raising $4,600 to cover the costs for videoing PyGotham 2011.

For $4,600, we're getting a lot of bang for our buck. Amongst other things:

• video that will last long after the conference done by a seasoned video crew that does video for PyCon, DjangoCon, and other conferences
• transcriptions of select talks

PyGotham 2011 is only a couple of weeks away. They have a pretty great speaker line-up. My manager is going to talk about Moving Fast with Django covering deployment pipelines!

Your help funding video for this conference makes a big difference! Please donate!

I use a four space indent which causes problems when indenting if statements that span multiple lines. For example:

if (a
    and b
    and c):
    if_block_here

The problem is caused because if is two characters and therefor if ( is four characters--which matches the four space indent. I end up with code where I can't easily distinguish if statement from the if block.

After talking about it with Paul and Chris and working out what the specifics of the problem are, I decided to use double parens. The above with double-parens looks like this:

if ((a
     and b
     and c)):
    if_block_here

That satisfies PEP-8, doesn't change the semantics, and fixes my problem. It is a little goofy to use double parens, but it's a good enough fix until I get around to fiddling with the code that does automatic indentation in python-mode.

I'd be interested in other ideas that don't involve using \ at the end of lines if they're out there.

I was reviewing something and learned that Python saves the original sys.stdin, sys.stdout, and sys.stderr as sys.__stdin__, sys.__stdout__, and sys.__stderr__ respectively. That's pretty handy to know. Works in at least Python 2.5 and up--I didn't test earlier versions.

The sordid story

I, too, was contacted by Packt Press to review Expert Python Programming by Tarek Ziadé. I finished reading the book months ago, but didn't get around to writing the review.

Then I saw the review from some person I don't know and the reply from Tarek. Tarek then went on to work through all the "bugs" and put out a new revision of the book. I still didn't get around to writing a review.

Then I saw Orestis' review. This review is pretty comprehensive. I think it covers a lot of the things I was going to say, so I'll just fill in the gaps.

The short review

The book is pretty good. It's really aggressive in that it's trying to cover a lot of ground and as such some of the chapters don't get very deep. Even so, I think the book does achieve it's mission:

1. it tells Python developers who are unaware of tools that would help them do development in Python what they're missing,
2. it tells them what tools and other things in the Python world fill those gaps,
3. it walks through how to use those things (generally speaking)

There are two things I wish had been different. The first is that every chapter should have ended with a "further reading" section that listed books, magazine articles, urls and other resources that further cover the topic. That would have really helped people the book is targeting.

The other thing I wish had been different is that many of the urls used throughout the book are "fragile": they're really long, have a lot of funky bits in them, and if the owner of that site moves anything around, the url becomes a dead link. I'm not really sure how to fix this, but maybe books should have bit.ly-like links in them that redirect through the book's web-site to the url in question. When the resource at that url goes away, then the book author can change the web-site to summarize what was there or provide a different link.

If you're interested in the book

If you think that's interesting, check out the Tarek's blog entry about the book and sample chapter.

If you still like it, then it's probably worth buying or waiting for Packt Press to send you an email to review it. ;)

If you're writing code like this:

try:
   foo = somevar.getBlah()["xyz"].split(".")[-1].decode("ascii", "replace")
except:
   pass

Please stop! You're killing the rain forest!

In Miro, we've got long strings that are displayed in the user interface. I think the code that defines these strings is messy and hard to parse. For example:

def some_func():
    description = _("""\
This is a really long description that has multiple sentences and a few \
things that need to %(getfilledin)s and it goes on and on and on and on \
and I'm not really sure what's the best way to format it so that it's happy \
in editors and easier to parse.""") % {"getfilledin": blahblah}

PEP-8 doesn't address this, which is fine. I was curious to see what other projects do.

I'm working on improving the PyBlosxom testing situation and in the process of doing that ran into a problem with nose (version 0.10.0) and coverage (version 2.77). Both installed with easy_install.

When running:

nosetests --verbose --with-coverage --cover-package=Pyblosxom --include unit
nosetests --verbose --with-coverage --cover-package=Pyblosxom --include functional

I bumped into the problem described here (nose.python-hosting.com) and here (code.google.com). The solution is to either:

1. remove coverage.py from /usr/bin, or
2. change the filename from /usr/bin/coverage.py to /usr/bin/coverage

I work for Participatory Culture Foundation as a developer on the Miro internet video player.

Today we released Miro 1.0. For most of the projects I've worked on, the 1.0 mark is exciting to reach, but also somewhat of a downer because it really requires you to hone the list of all possible things you could do down to a small finite list. Inevitably, there are things people will want to do that 1.0 doesn't do. Still, it's a huge milestone for the project. We're already working on post-1.0 development and making changes to decisions that didn't turn out as well as we had hoped.

A good portion of the work we do is in Python with lots of interaction between Python and libraries written in C and C++. For example, we use a lot of Pyrex to speed up critical sections.

Miro is a great product to continue to push open standards for video distribution and consumption on the Internet. I regularly watch GoogleEDU videos through Miro and I'm hoping other Python-related channels will be available as well. At some point, I'd like to create my own Python-videos channel and aggregate good Python-related video content. There's a lot of screencasts and tutorials out there....

I'm really late to the PyPi party. Both of the projects I've worked on over the years are in PyPi, but neither are up to date and neither support easy_install.

Figured I'd update them now. Three things I bumped into while working on Lyntin:

1. the PyPi tutorial is pretty good and walks you through what you need to know,
2. the list of classifiers is here, and
3. the Cheesecake folks have scores for all the PyPi modules here

That last one is kind of interesting. You can see the scores and the Cheesecake log output.

A few days ago, I saw on Grig's blog that Titus created a mailing list covering Testing in Python. I joined the list and it's been very educational. So far the posts have been in the "Hi--my name is _____________ (name) and I use ______________ (framework) and ___________ (framework) and ____________ (explanation for which framework gets used for which specific purposes)." Then this spawns a conversation with thoughts and insights and lots of applause. There have also been questions regarding how to use some of the frameworks and which framework would suit some need the best.

While I'm following the mailing list, I'm taking notes so that I can finish up this round of adding testing to PyBlosxom so that I can do a release this week. We're using nose and I'm using a similar structure that Cheesecake uses since I have some familiarity with their project.

It's a neat list so far. I'm glad Titus put it together--it's definitely solving my immediate needs.