Thanks to the Python Software Foundation, a PandaBoard arrived on Trent Nelson’s desk just in time for the holidays! Santa dropped off the present for python-dev this morning, and there’s a Raspberry Pi not far behind it.
On Raymond Hettinger’s recent thread about the memory layout of dictionaries, Barry Warsaw and Christian Heimes shared concerns about how things might look on ARM devices. Christian mentioned the Snakebite environment, run by Trent Nelson, but without any ARM machines in the environment, Trent offered to host the boxes if someone donates them.
Based on the thread’s suggestions and the low cost of the devices, the PSF authorized purchase of a PandaBoard ES, featuring a 1.2 GHz ARM Cortex A9, along with several accessories to get it running. The PSF already had a few Raspberry Pi devices on hand, which come with a 700 MHz ARMv6, so one was dispatched to Trent.
Thanks to the PSF for making the purchase, and thanks to Trent for offering to set up the machines and add them to the environment!
Thursday, December 20, 2012
Monday, November 19, 2012
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!
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!
Tuesday, October 30, 2012
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.
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.
Monday, October 29, 2012
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!
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.
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!
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!
Tuesday, August 14, 2012
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.
Thursday, June 7, 2012
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!
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!
Friday, June 1, 2012
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.
Subscribe to:
Posts (Atom)