Jesse Noller

PyCon 2009: Chicago I, along with a whole heck of a lot of other people will be attending PyCon in march. You should know about this by now, unless you’re living under a rock, or in a shoebox (I like shoeboxes).

PyCon 09 is turning out to be one of the ones I am most excited about in some time - barring the fact they let me actually stand up and speak about something, there’s a ton of other excellent and exciting things going on.

I will be doing two talks - “Introduction to Multiprocessing in Python” on Friday, at 3:20 PM, and “Concurrency and Distributed Computing with Python Today” at 3:20 PM Saturday.

The former talk is easy, given it will be focused on introducing the multiprocessing module to the masses, and taking questions about it (be gentle, I just work here). The latter is a much bigger beast. I’ve been blogging about my research in my pycon 2009 category, and I still have a pile of things to keep adding to that. The talk will attempt to differentiate concurrency from distributed systems, and show the various toolkits/frameworks/etc in the ecosystem today, to help you build both types of systems.

Given both talks are 45 minutes in length, I will be publishing my talk notes (my slides are not going to be heavy weight) and other information here.

In addition to me speaking, which may or may not be exciting, there’s one helluva ton of other talks which simply look awesome.

My schedule looks like this:

  • Thursday: Python Language Summit, where I will endeavor to be smart.
  • Friday: How to give a python talk
  • Friday: Using Windmill
  • Friday: Introduction to Python Profiling or How Python is Developed, to harass Brett.
  • Friday: Panel - Python VMs
  • Friday: Building an Automated QA infrastructure using Open Source Tools
  • Friday: Twisted, AMQP and Thrift: Bridging messaging and RPC for building scalable distributed applications
  • Friday: My Talk (I figure I should go to it)
  • Friday: A Whirlwind Excursion through Writing a C Extension or Challenges and Opportunities for Python
  • Thursday: Plugins and monkeypatching: increasing flexibility, dealing with inflexibility
  • Thursday: The (lack of) design patterns in Python or the Pinax talk
  • Thursday: Class Decorators: Radically Simple
  • Thursday: Panel: Object Relational Mappers: Philosophies and Design Decisions.
  • Thursday: Drop ACID and think about data (I wonder if we can take this literally, if he has scary slides though, we all might trip balls)
  • Thursday: My Talk, which is up against Bruce Eckel and Raymond H - I expect no one to show up.
  • Sunday: Panel: Functional Testing Tools in Python
  • Sunday: Designing a web framework: Django’s design decisions

This doesn’t even cover the open space discussions which I might attend - including the “Writing About Python” one Doug Hellmann is putting together as well as the “Teach Me Web Testing” one by Steve Holden.

After the main conference, I’ll be sticking around until Thursday morning for the sprints, at which point I should be sufficiently burned out on python stuff, I will fully convert over to being a full time burger flipper.

Right now there are 620 registered people who made their attendance public I don’t know how many there are in total.

Hope to see you there!

funny-pictures-cat-dog-paper-bag-shrubbery-holy-grail.jpg


"Writing About Python" at PyCon ( 20 February 2009 )
Doug Hellmann
The Python writing community has never been stronger. From blogs to magazines to a slew of recent releases from O'Reilly, Packt, Manning, Apress, and other publishers there a more opportunities than ever before for anyone wanting to write about Python in some form.

PyCon 2009: Chicago

Of course, authoring is only one aspect of producing high quality professional writing. As an editor, it's no surprise that I think all authors can benefit from having someone else read their work. Even an informal review can help identify gaps in an explanation or problems with flow, not to mention typos.

Writers, reviewers, and editors can all benefit from sharing tips, offering advice on tricky problem passages, or just chatting about ongoing projects. That list sounds just like the sorts of things we talk about when discussing programming, doesn't it?

I'd like to bring people together in person for a group discussion and a chance to network. To kick things off, I'm working on organizing a "meetup" as an open space session at PyCon in March. If you are a blogger, published writer, reviewer, or editor -- or aspire to be -- I want you to come and participate. No prior experience is necessary, everyone is welcome.

Let's connect people interested in doing technical reviews with authors and editors. Let's introduce potential writers to the editors and publishers. Let's learn from one another and improve our prose, the same way we improve our code.

We'll have to wait to schedule a precise time until the conference, but right now I'm thinking about late Saturday morning or early afternoon. If you are interested in attending, please post a comment so I can gauge the size of the room we'll need. If you have a preference for the time, make sure to include that information. And if you have ideas for things we should talk about, let's hear them.

Update: Although I was thinking of "print" writing, other forms of publishing like podcasting are welcome, too. We need more good Python podcasts!

Titus Brown

I get really frustrated with posts that claim your unit tests lie toyouor 100% code coverage is fallaciousor there are flaws in coverage measurement.These are sensationalist headlines that encourage bad behavior, byconfusing new or inexperienced or argumentative or lazy developers:"well, we all know test coverage isn't that important..."

There is a fundamental confusion here between necessary andsufficient. In plain English, things that are necessary are,well, necessary for a process; things that are sufficient are,collectively, sufficient.

One does not imply the other. Tires are necessary but notsufficient for a car.

Why do I bring this up? Because near-100% code coverage is basicallynecessary for a complete automated test suite, but not sufficient.

If you do not have near-100% code coverage, then some portion of yourcode is not being executed by your tests. That means that code isuntested. It can't possibly be tested if you aren't executing it!

(As a corollary, no test that adds to code coverage is useless. It may not beas useful as it could be, but it is still running code that is otherwiseuntested. Room for improvement does not equal uselessness!)

OTOH, there are many reasons that 100% code coverage isn't sufficient tomake your test suite good. For one, code coverage isn't branch coverage.For another, code coverage can't tell you if your feature set meets yourclient's needs or is in fact functional -- all it can do is tell you thatyour feature set meets your expectations at the moment.

So, let me suggest this simple pair of statements:

  1. High (statement) code coverage in your tests is important.
  2. High code coverage doesn't guarantee that your tests are complete.

I feel like high code coverage is actually a pretty low bar for aproject. Whether or not you're using TDD, if you don't have high codecoverage numbers, you're not really testing very thoroughly; it'sgenerally pretty easy to amp up your code coverage numbers quickly,although writing the test fixtures can be a problem. I'll talk a bitabout this in my PyCon talk.

Regardless of your tests suite, your project will probably fail in a boring and project-specificway.

--titus

P.S. Many people do get it, which is nice.


simplejson 2.0.9 ( 19 February 2009 )
Bob Ippolito

simplejson (documentation) is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.4+. It is pure Python code with no dependencies, but features an optional C extension for speed-ups.

simplejson 2.0.9 is a major bug-fix update:

  • Adds cyclic GC to the Encoder and Scanner speedups, which could've caused uncollectible cycles in some cases when using custom parser or encoder functions

Simon Willison

The History of Python: Adding Support for User-defined Classes. Guido designed the run-time representation first, and tried to design the syntax to include as few new parsing concepts as possible. The origins of explicit self are also explained.