Good Things Come in Threes: Python Cookbook, Third Edition
It became official earlier today that David Beazley and myself will be co-editing/co-curating the next edition (the Third Edition) of the Python Cookbook. That’s really exciting. Here’s why:
It’s Python 3, Cover to Cover
Go big or go home. The third edition will be a Python 3 Cookbook. This by itself makes this a rather large undertaking, since it means modules used in earlier editions that don’t work in Python 3 can’t be used, and so those old recipes will need to be scrapped or rewritten.
You heard it right: if a module used in the last edition of Python Cookbook doesn’t work in Python 3, it won’t be in this edition. This includes some modules for which several recipes already exist, like dateutil and wxPython, and other modules I would’ve liked to use for illustrative purposes, like Tornado and psycopg2. I guess there’s still some time for smaller modules to port to Python 3 and be left alone in this edition, but I don’t know how realistic that is for something like wxPython.
It’s going to be ok.
I can’t find any modules (yet) in the second edition for which Python 3-compatible substitutes don’t exist, and in some cases I found myself wondering why a separate module was used at all when what needs doing isn’t a whole lot of work in pure Python anyway. I guess if the module is there and stable, why not use it, eh? Fair enough.
Three Authors?
Actually, yes. David, myself, and YOU, where YOU is anyone who posts good Python 3 recipes to the ActiveState ‘Python Cookbook’ site. This is actually not new. If you look at the last edition, you’ll see separate credits for each recipe. The Python Cookbook has always been a community effort, featuring recipes by some very familiar names in the Python community.
Anyway, just in case that wasn’t direct enough:
Go to the ActiveState Python Cookbook site and post a Python 3 recipe, and if it’s solid, your name and recipe may well be in the book.
Basically, ActiveState gives us free reign over their Python Cookbook content, so it’s a convenient way to let the community contribute to the work. If it’s in there, and it’s good, we can use it. They’re cool like that.
Three Questions
Answer these in the comments, or send email to Dave and I at PythonCookbook at oreilly.
- What are your three favorite recipes from either the 1st or 2nd edition?
- What are your three least favorite recipes from either the 1st or 2nd edition?
- What are three things (techniques, modules, basic tasks) you’d like to see covered that weren’t covered in earlier editions?
Three Cool Things About the Third Edition
- Tests. When the book comes out, we’ll make the unit tests for the recipes available in some form that is yet to be determined (but they’ll be available).
- Porting help. We’re not going to leave module authors out in the cold. We’re going to provide some help/advice. We’ve both written code in Python 3, and dealt with the issues that arise. I’m still porting one of my projects and have another in line after that, so I’ll be dealing with it even more.
- Dave and I are both overwhelmed with excitement about this book, about Python 3, and about working with you on it. Come help us out by posting Python 3 recipes (tests are also nice, but not required) on ActiveState, and shoot us an email at PythonCookbook at oreilly dotcom.
There will be other cool things, too. We’ll let you know, so stay tuned to this blog, Dave’s blog, and you should definitely follow @bkjones and @dabeaz on Twitter, since we’ll be asking for opinions/resources/thoughts on things as we go.
Share this:
This entry was posted on Thursday, December 16th, 2010 at 10:15 am and is filed under Python, Scripting, Sysadmin, Technology, Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Things which I’d like to see:
– Using automating the virtualenv utility
– describing and searching all the directories, PATHs which python looks for modules.
– SVG will be displayed in IE 9 so I’d like to see python generation of SVG.
– creating, reading & updating of spreadsheets.
Favourite recipes: ones which help search, cleanup, backup the hard drive, running diff, calling simple o/s functions (file move, delete, get system info), parsing html / xml, doing basic email.
Of course put a few fun ones in such as solving puzzles or playing games.
Things I’d like to see:
* more focus on usage of packages from the Cheeseshop to make life easier (and require less coding) for the user/programmer
* more on using Python for common system admininistration tasks
* notes on modern packaging best-practice (distutils2, pip, virtualenv)
* re. the GUI toolkit chapter: focus only on tkinter (since it comes standard with Python). There’s no room to cover PyQT, Wx, PyGTK, etc. in any useful level of detail.
* Special “get involved!” blockquote sections scattered throughout the text noting modules that are simply not yet available for Python 3 at the moment. Useful for helping developers who want to get involved but who don’t really know what’s missing and/or needing-to-be-ported from 2to3. Also useful for new users to signal to them that an omission in the cookbook is not necessarily because of an oversight.
Thanks for the feedback.
@John — I’m a little surprised about the GUI toolkit sentiment. I actually agree with you, but figured a lot of people would really want that material.
What about the rest of you? There are three ways to go:
— GUI section, tkinter only
— no GUI section
— GUI section covering multiple frameworks (suggest away, but it must be Python 3. No exceptions)
wxPython (the framework garnering the bulk of the recipes in the last edition) is out because it’s not ported to Python 3 yet, but PyQT is, and it’s more robust than tkinter. That said, it’s also kind of a bear to install if you’re not running Linux.
I agree that TkInter is old and the main reason it is still used is that it comes built-in. It is also rather poorly documented – I found that “Python and Tkinter Programming” by John E. Grayson (Manning) is a required accessory when writing a Tkinter GUI. So I think a chapter of TkInter recipes would be a good thing.
I don’t understand John’s comment that on one hand supports CheeseShop and add-ons while also rejecting add-on GUIs. I support covering add-ons. Python is an entire ecosystem today and one cannot say they ‘program python’ without knowing at least something about the ‘other stuff’ that is available. I looked at an ISP’s list of supported Python apps the other day, and out the twenty listed there were a couple I had never heard of, and about half I have only the vaguest idea about.
So let’s have a web chapter that not only includes urllib and webbrowser but touches on Django, Pylons, Mako etc. However make it clear which recipes are done with standard batteries and which need a plug (I had to read too much to figure this out in the previous edition).
I know ActiveState is a supported of this project, and their Python interops with Windows nicely, but I’m a Linux user most of the time and like to keep things portable. I can do without recipes for attaching to Access, calling COM, etc.
> I don’t understand John’s comment that on one hand supports CheeseShop and add-ons while also rejecting add-on GUIs.
The point of a cookbook is to be a go-to guide for when you quickly need to accomplish a given task that can be covered in a page or two, or three, ex.: programmatically sending an email, parsing a log file, sorting a list of data structures, etc.
Sometimes a reader will need a simple GUI for some fairly small task, and tkinter still serves that purpose fairly well.
I’d assumed that other larger toolkits were too much to cover given constraints in the length of the book. Here’s a made-up (but, I think, reasonable) litmus test on whether the Cookbook should cover tkinter or else some other larger GUI toolkit: your busy friend needs to create a simple GUI dialog-style app that, I dunno, say, opens a text file, parses it into lines, displays those lines in a GUI, and lets the user select one and click a “Go” button to do something regarding the data on that line.
If you can write a cookbook recipe clearly describing how to do that with PyQt/PyGTK/whatever, and it’s not substantially longer or more complicated than a corresponding tkinter recipe, then there’s not much reason to use tkinter (the major plus of tkinter being simplicity). The whole point of the recipe is to make life easier for the reader who just wants you to succinctly tell them an easy, good, and modern way to do it so they can code it up and move on (well, and also be able to maintain and/or update their solution later on).
> So let’s have a web chapter that not only includes urllib and webbrowser but touches on Django, Pylons, Mako etc.
Alas, I doubt the authors have room to include any substantial coverage of Django, Pylons, Mako, etc., and those projects have good documentation on their own anyway. And if a reader wants to know what their options are for given type of task, the Python wiki serves that purpose pretty well.
One last thing: if you include recipes for PyQt, you may also want to include at least some for using Python with GTK, the future of which (re. Python 3) is summarized at www.mail-archive.com/pygtk@daa.com.au/msg19868.html , which is:
”
> Some News about PyGTK porting to Python 3.x ?
I do not plan to do so. PyGTK will be maintained to work with gtk +-2.22/24 and Python 2.X indefinitely.
PyGObject + gobject-introspection is the recommended way to develop Python applications against gtk+-3.X and Python 3.x.”
More about this on the PyGTK mailing list, as well as at www.j5live.com/ .
Any chance of Peter Norvig’s Spelling Corrector and Guido’s Sorting Million Integers to appear in the cookbook? They are very beautiful pieces of “code”. Thanks.
Ps. I don’t know what I do like or dislike more in the book. I just like the book too much
FYI: Tornado runs on Python 3.2 now.
www.tornadoweb.org/