asyncio — Asynchronous I/O, event loop, and concurrency tools — PyMOTW 3

The asyncio module provides tools for building concurrent applications using coroutines. While the threading module implements concurrency through application threads and multiprocessing implements concurrency using system processes, asyncio uses a single-threaded, single-process approach in which parts of an application cooperate to switch tasks explicitly at optimal times. Most often this context switching occurs when the program would otherwise block waiting to read or write data, but asyncio also includes support for scheduling code to run at a specific future time, to enable one coroutine to wait for another to complete, for handling system signals, and for recognizing other events that may be reasons for an application to change what it is working on.

Read more…

This post is part of the Python Module of the Week series for Python 3. See PyMOTW.com for more articles from the series.

argparse — Command-Line Option and Argument Parsing — PyMOTW 3

The argparse module includes tools for building command line argument and option processors. It was added to Python 2.7 as a replacement for optparse . The implementation of argparse supports features that would not have been easy to add to optparse , and that would have required backwards-incompatible API changes, so a new module was brought into the library instead. optparse is now deprecated.

Read more…

This post is part of the Python Module of the Week series for Python 3. See PyMOTW.com for more articles from the series.

queue — Thread-safe FIFO Implementation — PyMOTW 3

The queue module provides a first-in, first-out (FIFO) data structure suitable for multi-threaded programming. It can be used to pass messages or other data between producer and consumer threads safely. Locking is handled for the caller, so many threads can work with the same Queue instance safely and easily. The size of a Queue (the number of elements it contains) may be restricted to throttle memory usage or processing.

Read more…

This post is part of the Python Module of the Week series for Python 3. See PyMOTW.com for more articles from the series.

Python Module of the Week for Python 3

Over the last several years since my book, The Python Standard Library by Example, was published many folks I’ve talked with at conferences or by email have asked when I would be updating the content for Python 3. I’ve been putting off that work, mostly because of other projects. I’m happy to announce that I’ve finally started updating the content and intend to publish updates weekly.

The new versions of the articles, updated and rewritten for Python 3.5, are all available under https://pymotw.com/3/. The same RSS feeds and email notices are still set up, so if you were subscribed to the old feed you’ll receive the updates as they go online. There is also a new twitter account @pymotw in case you want to follow it for updates, without following my personal account. For more details, see the about page.

All of the old content for Python 2.7 is still available at https://pymotw.com/2/, for continued reference.

virtualenvwrapper needs a new maintainer

virtualenvwrapper is probably the most popular tool I maintain. A surprising number of people use the current version of the shell scripts that grew out of a hacky little set of bash aliases I wrote 7+ years ago. There are even several competitors now. I created a market segment! ;)

Perhaps ironically, I’ve found my own needs have changed enough that I don’t use it much myself any more. Most of my work these days involves OpenStack, and we have enough tooling consistency built into our repos that I don’t need a ton of virtualenvs. I’m actually back mostly to using a couple of hacky shell aliases again because they, combined with tox, are lighter weight. All of which leads to reduced motivation to keep up with maintenance.

virtualenvwrapper is still useful, but it isn’t seeing the TLC it needs and deserves. There are a handful of open pull requests that have been lingering for a while, and several bugs in the same state. That’s not to mention the need to make it work with Python 3’s pyenv. 

So, I’m looking for someone to help take on the maintenance duties for virtualenvwrapper.

As I’ve explained here and in the docs, although the wrappers are a python tool, they are mostly written as shell scripts compatible with bash, zsh, and ksh. If you like shell scripting and you’re interested in getting involved, get in touch (doug@doughellmann.com) and I’ll try to work with you to get you set up for development and to answer any questions about the current implementation.

Update 4 Jan 9:30 AM EST: I’ve had several folks contact me interested in helping out. Let’s use the Google group https://groups.google.com/forum/#!forum/virtualenvwrapper to figure out how to proceed.

sphinxcontrib-paverutils 1.10.0

sphinxcontrib-paverutils provides an alternative integration of Sphinx and Paver. It supports calling Sphinx from within Paver using multiple configurations, and does not assume you only want to build HTML output.

What’s new in 1.10.0?

  • add warnerror flag to tell Sphinx to treat build warnings as errors