New Contributor Experience in Python and other FOSS Communities - A Survey

If you have joined the community of developers contributing to CPython since January 2010, I hope you can find a few spare minutes to participate in a survey being put on by Kevin Carillo. He’s a Ph. D. student at Victoria University of Wellington completing research on new contributors to free and open source projects. Kevin is interested in hearing from everyone from technical to non-technical contributors, whether you had positive or negative experiences.

The survey is available at https://limesurvey.sim.vuw.ac.nz/index.php?sid=65151&lang=en.

Kevin states, “The goal of this research is to understand how a person's experience as a newcomer to a Free/Open Source Software (FOSS) community influences that person's behavior and contributions within that community.” He estimates that the survey will take around 20 minutes to complete.

Throughout the nearly three year period since January 2010, over 40 committers were added and countless others contributed patches, reviews, and bug triage. Since the creation of the Core-Mentors group in March 2011, we’ve seen many first timers come through and have their work committed and released.

We hope that the mentorship group has helped introduce contributors in a positive manner, so we’re looking forward to the results of Kevin’s studies. One of the things Kevin hopes to find is whether or not formal mentorship programs work for introducing contributors. He also looks to find answers to how much community support of newcomers matters, whether formal joining processes involving sponsorship work, and if newcomer specific tasks are the way to go.

If you have the time, please fill out the survey. Python is participating in this survey along with several other groups including Debian, KDE, Gnome, openSUSE, and OpenHatch. Perhaps we can learn a few things and create an even better experience for new contributors!

Python Bug Day this Saturday

This Saturday, you have the opportunity of participating to the Python Bug Day. How would you like to be one of the contributors of Python? If you have ideas for improving parts of the official documentation, the standard library, the language itself, or if you have a patch waiting for a review that you would like to see committed, or if you just want to come and fix an existing bug, it’s your day!

Join us for an effort at closing some Python bugs and feature requests. Get quick feedback on your patches and bugfixes, learn how to submit and examine patches, and have fun chatting with the Python developers and other contributors. You don’t need to know the CPython codebase or process to join, just Python programming knowledge.

If you live in Montreal, come at Caravan to meet fellow hackers and take part in a physical sprint!

Please register to let us know how many people to expect. People from around the world are should join the #python-dev IRC channel to participate in the bug day.

This page contains all the information you need to get set up, see the list of bugs or learn about IRC: http://wiki.python.org/moin/PythonBugDay 

The goal of the bug day is to process bug reports in the Python bug tracker, trying to fix and close issues. 

 What to do:

• Grab a copy of the Python codebase from Mercurial, following instructions in the Developer's Guide, and compile it.
• If you have a problem that isn't in the bug tracker, announce it to the IRC channel, and if it's more than five minutes' work, create a bug report for it. See the bug reporting instructions to learn how to write bug reports.
• When you choose a bug to work on, announce it to the IRC channel (e.g. "I'm working on #123456.") or on the bug report itself. This avoids accidentally duplicating work.
• Consider providing a patch that fixes the problem, or at least a simple test case that demonstrates the bug. Please see the patch submission guidelines in the Developer's Guide before submitting a patch.
• Does the bug appear to be gone in the Python development version (the Mercurial branch "default", that will become 3.4), but not the 3.2, 3.3 or 2.7 maintenance branchs? Report that, too.
• If someone else has supplied a fix, see if this fix works for² you, and add your results to the bug.
• Read the text of proposed patches and assess them for correctness and code quality. This is usually the most time-consuming step in the bug fixing process, so reading patches is very useful.
• If there's a working fix, feel free to add a note asking for the fix to get committed. The bug tracker has a lot of items in it, and it's easy for bugs to be overlooked.
• Feature requests should be classified as type 'feature request' in the bug tracker.

If you need any help beforehand, feel free to ask on core-mentorship mailing-list

Updates to docs.python.org

If you haven't already noticed, several months ago we updated the Sphinx theme for documentation of versions Python 3.2 and beyond on docs.python.org. It's a more modern look, and it also serves as an indicator that you're looking at documentation for a newer version. Thanks go out to Georg Brandl for his work on Sphinx, Python's documentation, and this new theme!

PEP 430

Over the weekend, PEP 430 was approved, which changes the default documentation displayed at http://docs.python.org. See the PEP for full details, but the jist is that we're now promoting the current Python 3 release as the default when you go to the docs home page. However, as the majority use case is still for Python 2 documentation, navigating straight to an unversioned page will present you with the current Python 2 documentation. For example, an unversioned link such as http://docs.python.org/library/zipfile will bring up the 2.7.3 documentation.

Version Dropdown

Supporting that change is a new feature that adds a version dropdown to the top of all documentation pages. Not only does this help when users are brought to a page which they don't expect, but switching between versions is a common operation as more and more projects work to add support for Python 3. Issue 8040 is where you'll find discussion on the change and its patches, with the bulk of the work completed by Yury Selivanov with some help from Georg.

This dropdown is especially handy as you peruse the documentation and come to a page that you want to view in another version. Choosing another version while on any page will load that page's other version, where the latest release of that version is chosen, e.g., 2.7 currently points to 2.7.3. So, as you browse the 2.7.3 built-ins page, choosing 3.3 in the dropdown will bring you to the 3.3.0 built-ins page.

We hope these changes enhance your experience when browsing the Python documentation!

Python 3.3 Beta 2 Released

Release manager Georg Brandl announced on August 12 that the second beta of CPython 3.3 was released, complete with installers for both Mac and Windows. This release represents the final feature set, and the goal is to get it in the hands of users to iron out any last issues.

Following this beta will be two release candidates, coming August 25 and September 8. The final release is slated to happen on September 22.

The "What's New in Python 3.3" document is currently being finalized by curator and long time developer Raymond Hettinger. The document already contains many of the new changes, but keep an eye out for newer versions.

Here are some of the bigger changes:

• PEP 380, syntax for delegating to a subgenerator ("yield from")
• PEP 393, flexible string representation (doing away with the distinction between "wide" and "narrow" Unicode builds)
• A C implementation of the "decimal" module, with up to 80x speedup for decimal-heavy applications
• The import system (__import__) now based on importlib by default
• The new "lzma" module with LZMA/XZ support
• PEP 397, a Python launcher for Windows
• PEP 405, virtual environment support in core
• PEP 420, namespace package support
• PEP 3151, reworking the OS and IO exception hierarchy
• PEP 3155, qualified name for classes and functions
• PEP 409, suppressing exception context
• PEP 414, explicit Unicode literals to help with porting
• PEP 418, extended platform-independent clocks in the "time" module
• PEP 412, a new key-sharing dictionary implementation that significantly saves memory for object-oriented code
• PEP 362, the function-signature object
• The new "faulthandler" module that helps diagnosing crashes
• The new "unittest.mock" module
• The new "ipaddress" module
• The "sys.implementation" attribute
• A policy framework for the email package, with a provisional (see PEP 411) policy that adds much improved unicode support for email header parsing
• A "collections.ChainMap" class for linking mappings to a single unit
• Wrappers for many more POSIX functions in the "os" and "signal" modules, as well as other useful functions such as "sendfile()"
• Hash randomization, introduced in earlier bugfix releases, is now switched on by default

In total, almost 500 API items are new or improved in Python 3.3.

Be sure to check out this release at http://www.python.org/download/releases/3.3.0/ and report any issues to http://bugs.python.org.

Mercurial Mirrors Provided by Atlassian

Long-time friends of the Python community, Atlassian (makers of Bitbucket) recently made available a mirror of http://hg.python.org, synchronized hourly, for your cloning and hacking pleasure.

Using the new mirror should be very intuitive for current users of the Hg repository -- the projects housed in the mirror follow the same naming convention as the repository they're mirroring. So, the CPython source code is mirrored at https://bitbucket.org/python_mirrors/cpython, corresponding to its canonical home at http://hg.python.org/cpython.

Since it's hosted on Bitbucket, the collaborative floodgates are effectively flung open. Not only is it dead easy to clone and submit contributions back to the project, you'll also have the ability to follow the project and receive updates in your dashboard. If RSS is more your style, Bitbucket makes it easy to stay up-to-date with changes via each repository's feed.

If you cloned the cpython repo and want to submit your changes to an issue on http://bugs.python.org, it's as simple as pasting a link to your Bitbucket clone in the "Remote hg repo" box. The default branch is automatically chosen, but appending #branchname to the end of your link will choose that branch.

See how easy it is to get your changes associated with an issue? If you're interested in getting started with CPython development, check out our developer guide.

---

Atlassian has been a user of Python and supporter of the Python community for some time now. They've sponsored PyCons around the world as well as events at those conferences, from the CodeWars competitions during PyCon AU to the recent PyLadies party at PyCon US!

Thanks, Atlassian!

Python 3.3 Alpha 4 Released

Yesterday, May 31, brought the fourth alpha release in the Python 3.3 development schedule. It's an exciting release as it introduces a number of long awaited features that we really hope the community will enjoy.

New Features

PEP 405 - Virtual Environments

Just in time for Alpha 4 comes the addition of PEP 405's support for virtual environments by way of the venv module and pyenv script.

python -m venv /home/yourname/dev/myproject

You may know this functionality through virtualenv, originally created by Ian Bicking. Thanks to Carl Meyer, Vinay Sajip, and anyone else for working on the PEP and implementation, we now have this widely used functionality available in a Python release!

PEP 420 - Namespace Packages

After a long road featuring two preceding PEPS (382 and 402), several sprints (including one sponsored by the PSF), and much discussion on python-dev, import-sig, and at PyCon language summits over the last two years, namespace packages are here. At the summit, Eric Smith stepped up to write a new PEP after the group decided to reject PEPs 382 and 402.

The result is PEP 420. The most obvious feature of a namespace package is the lack of a __init__.py file. However, there's a lot more to it, so check out the PEP!

PEP 3144 - The ipaddress Module

After discussion starting during the Python 3.2 development cycle, the ipaddress module has a new home in the standard library for 3.3. PEP 3144, authored by Peter Moody and taken up by core contributor Nick Coghlan, introduces a collection of classes for working with addresses, networks, and interfaces for both IPv4 and IPv6.

Windows Build Upgraded to Visual Studio 2010

As was recently covered, the Alpha 4 Windows installers now feature binaries produced by Visual Studio 2010, up from the 2008 version. We needed to upgrade to keep up with what most organizations and many of our contributors were using, along with the fact that not changing would mean we'd be at least two versions behind at our next opportunity to do so. With Python 3.4 not coming out until some time in 2014, we didn't want to end up eight years behind the curve and have to make that big of a version jump.

Bug Fixes

As with all of our releases, many contributors submitted patches to fix over 80 issues since last month's Alpha 3. We have fixes across a number of modules, including batches of fixes to IDLE, email, and urllib.

We Need Your Help!

As with all of our releases, backwards compatibility is important to us, so we'd love to hear if any of your projects have issues. Please help us make the best release possible by trying it out!

Python 3.3 is quickly shaping up to be the release everyone's waiting for, so run your tests and report your issues to http://bugs.python.org.

---

Download it now!

Recent Windows Changes in Python 3.3

The Windows build of Python 3.3 has recently seen changes that could use a look from the community throughout our alpha and beta cycle. The first change is the long requested addition of Python to the system Path variable, which was completed in the installer. Secondly, the build was upgraded to Visual Studio 2010.

Python on the Path

A long requested feature, especially from beginners to those involved in education and training, has been the ability for the Python installer to place itself in the system Path environment variable. Having the following message appear when you try to run a simple exercise is not a great first experience:

'python' is not recognized as an internal or external command, operable program or batch file.

Because of that, the first post-install step by many users is to edit the Path environment variable manually to insert the C:Python33 directory. This allows the user to simply type python on the command line and have it open C:\\Python33\\python.exe -- a very desirable feature for a majority of users. In fact, it's such a common post-install step that there are a huge amount of tutorials either about this step by itself or tutorials where their setup introduces this step before moving on.

The easiest part of the whole thing was the code. Path manipulation in the installer consists of adding a new feature to the Feature table, then the Environment table may be updated based on selection of the Path feature. If the feature was selected, the Environment table is modified in a way that the Path is prepended to and will be correctly cleaned up on uninstallation.

The harder part was deciding how to go about the change. If you're going to provide Path manipulation, the major questions are to do it by default or not, and to prepend or append to the Path.

We decided that it wasn't appropriate to make this a default feature. For one, in the dual-version state many users are running in, we run the risk of users running through the installer and putting their system into a state they aren't prepared for. We don't want to change the meaning of python when executed on the command line without the user asking for it. On one hand it's a very beginner focused feature in that it gets a first-timer successfully up and running with ease. However, it's also an advanced feature in that it takes a good understanding of what it's going to do to the users who have 2.6, 2.7, 3.2, and now 3.3 on their machines. We think the best solution for all is to leave it up to them and include an explanation.

The other part we had to think about was whether to prepend or append to the path. While some believe that appending to the path is the more friendly way to work with the system, it would seem to be of limited utility given that the feature is added this late in the game. Instead we went the route of prepending the installation folder, e.g., C:\Python33, in order to make sure this feature is actually useful to our users.

If you have questions or comments, please feel free to raise them on python-dev or see Issue 3561.

Transition to Visual Studio 2010

In time for the last alpha release, we've updated our build tools from Visual Studio 2008 to 2010.
Many potential contributors as well as general Python users have long moved to work environments that use Visual Studio 2010. During a "bug day" some months ago, we had two or three patches come from interested first-timers who found our VS2008 solution not working in VS2010. Over time we received a few more contributions and bug reports on the topic, as well as some chatter in IRC about being behind the curve.

On top of that, my employer at the time moved to VS2010 as well as the employers of at least one other core maintainer, so we were already operating on ports for our companies.

When it came time to think about what to do for Python 3.3, moving to VS2010 became a must have due to our release schedule. Staying with VS2008 for 3.3 would put us into the middle of 2014 as the next time we could release on a new version. That would leave us at least two versions behind, with VS2010 as well as VS11 being available by then.

Another reason is the relative ease of porting between VS2010 and VS11. Once we got ourselves on to 2010, moving on to 11 would not be that hard. VS11 currently reads our VS2010 files without change if you want to use the IDE features of VS11. However, there'd need to be another port in order to use the VS11 compiler suite, but it seems to require minimal effort. Just following the VS11 wizard produced a functioning executable, although it didn't build cleanly.

Where to get Visual Studio 2010?

As usual, Microsoft provides a zero-cost version of Visual Studio 2010 in the name Visual C++ Express, available at http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express. While there are some differences between the Express version and the for-purchase versions, the Express version is used successfully by many contributors.

The fine folks at Microsoft's Open Source Technology Center have provided the core contributors with MSDN licenses free of charge, allowing for access to the full versions of Visual Studio among other products. The full versions of Visual Studio support 64-bit compilation which comes in handy for our amd64 releases, which have been available since 2.5.

Help us out -- try the alphas and betas!

With a change to the installer, a new build system, and the other great changes we have in store, the more feedback we hear from the community during the development cycle, the better we can make this release. If you have a chance to run your projects on Python 3.3, http://bugs.python.org is always open for your reports. You've even got a month to get feature requests in and completed!

The last alpha release is scheduled for this weekend, and the first beta release is scheduled for June 24. You can download our 3.3.0 releases at http://www.python.org/download/releases/3.3.0/.