I’ve been hacking on other people’s python3 code for a while doing porting and bugfixes but so far my own code has been tied to python2 because of dependencies. Yesterday I ported my first personal script from python2 to python3. This was just a simple, one file script that hacks together a way to track how long my kids are using the computer and log them off after they’ve hit a quota. The kind of thing that many a home sysadmin has probably hacked together to automate just a little bit of their routine. For that use, it seemed very straightforward to make the switch. There were only three changes in the language that I encountered when making the transition:
- octal values. I use octal for setting file permissions. The syntax for octal values has changed from
- exception catching. No longer can you do:
except Exception, exc. The new syntax is:
except Exception as exc.
- print function. In python2,
print is a keyword so you do this:
print 'hello world'. In python3, it’s a function so you write it this way:
- The strict separation of bytes and string types. Required me to specify that one subprocess function should return string instead of bytes to me
When I’ve worked on porting libraries that needed to maintain some form of compat between python2 (older versions… no nice shiny python-2.7 for you!) and python3 these concerns were harder to address as there needed to be two versions of the code (usually, maintained via automatic build-time invocation of 2to3). With this application/script, throwing out python2 compatibility was possible so switching over was just a matter of getting an error when the code executed and switching the syntax over.
This script also didn’t use any modules that had either not ported, been dropped, or been restructured in the switch from python2 to python3. Unlike my day job where urllib’s restructuring would affect many of the things that we’ve written and lack of ported third-party libraries would prevent even more things from being ported, this script (and many other of my simple-home-use scripts) didn’t require any changes due to library changes.
Verdict? Within these constraints, porting to python3 was as painless as porting between some python2.x releases has been. I don’t see any reason I won’t use python3 for new programming tasks like this. I’ll probably port other existing scripts as I need to enhance them.
Congratulations and many thanks to everyone who was involved in the effort to unbundle zlib from rsync! Looks like this long standing bug that’s been a sore spot for many distributions is finally being addressed. It almost makes me want to create a Fedora 18 Feature page for it :-)
If you were at the first day of PyCon Santa Clara this year, you might have seen the picketing employees outside the main hotel/conference center. Looks like the reason for that protest has made it to the attention of a group that’s going to send a petition to the Hyatt management.
This is something I’ve been noticing for a while and am finally getting around to blogging.
In the first days of FESCo, Thorsten Leemhuis was the chairman. One of the quirks of his time was that we’d encounter a topic where we voted on a solution and found that a majority agreed with one sentiment but it wasn’t unanimous. When that happened, Thorsten would be sure to ask if there was anything we could do to make the solution more acceptable to the dissenters even if they still wouldn’t vote for the proposal.
This sometimes lead to discussions of a proposal that had been approved with margins like 7 to 2 and after the discussion and changes, the vote was still 7 to 2. So from an external standpoint, this might be seen as unproductive. Why don’t we just get a decision made and move on?
But over the years I’ve watched a lot of other split decisions be made on several committees from both the inside and the outside and it’s struck me that, perhaps, we don’t do nearly enough of this sort of examination. Making changes after it was clear that a majority agreed with the basic proposal had several beneficial effects:
- It made the proposals more palatable to more people by getting rid of at least some issues that had made their way in to the final drafts.
- It forced dissenters to figure out what specific things they wanted to be changed in the proposal rather than simply being able to say “I hate this whole thing”.
- It made more people a part of the decision– whether or not they voted for it, if some of their ideas were in it, they felt some ownership for having help craft it.
- And perhaps most importantly, it let everyone know that the door of communication still worked. People found that their ideas were still valued by the other members even if they didn’t agree with each other on the overall picture.
So what can we do with this? Maybe it’s too much to ask that we look over every little decision we make where there’s disagreement and attempt to find every last bit of common ground that we can (There were certainly times when it seemed to take forever to make a decision) but what about decisions that are close votes? What about decisions that have days-long threads as part of their backstory? In these cases, consider the proposal that the majority agrees on to be a strawman. A starting point from which to start chipping away to see what changes can be made that are still acceptable to the majority while addressing many of the issues that the minority has. Remember that the goal is to craft a compromise that addresses as many concerns as possible.
We’ve just deployed a new Fedora Account System to production. This release just pulls a few new features that didn’t quite make the 0.8.10 release:
- Ian Cole (icole) Added a feature to allow for email address to be used instead of login name for logging in. Because of the way we do authentication, this means that email addresses can also be used on the other applications on admin.fedoraproject.org as well.
- Pierre-Yves Chibon (pingou) Implemented an audio captcha for people signing up for a new account. It generates a wav file that gets downloaded to your computer that you can listen to and then type in the proper answer to the captcha.
- Adam M. Dutko (addutko) Standardized some of the errors that can be returned from our JSON API.
- Our translation team pointed out a few areas where we weren’t loading translations correctly and I fixed them. Look forward to more complete translations in the future.
That’s it for this minor update.
/me goes to play with the audio captcha some more.
Are you on IRC? Are you at FUDCon? Do you have a project that you want to happen in Fedora?
The Fedora Board is working on choosing goals that each individual member wants to champion and bring to fruition this year in Fedora. So if you have some idea that you think a Board member’s help will make work better, grab your nearest Board member[*] and ask them to bring it up on their Sunday meeting. One of them may take it up as something they think they can work on and help accomplish in the coming year.
[*] Board members you may see wandering around at FUDCon:
- Jared Smith
- Toshio Kuratomi
- David Nalley
- Peter Robinson
- Jon Stanley
- Christoph Wickert
As mentioned last week a new kitchen release went out today. Since last week some small changes were made to the documentation and a few changes to make building kitchen easier were implemented but nothing has changed in the code. Here’s the text of the release announcement:
== Kitchen 1.1.0 has been released ==
Kitchen is a python library that brings together small snippets of code that you might otherwise find yourself reimplementing via cut and paste. Each little bit is useful and important but they usually feel too small and too trivial to create a whole module just for that one little function. However, experience has shown that any code implemented by copying will inevitably be shown to have bugs. And when you fix those bugs, you’ll wish you had created the module so you could fix the bug in one place rather than two (or five.. or ten…). Kitchen aims to be that one place.
Kitchen currently has code for easily setting up gettext so it won’t throw UnicodeErrors in corner cases, compatibility modules for different python2 stdlib versions (2.4, 2.5, 2.7), a little bit of iterators, and a whole lot of code for unicode-byte string conversion. In addition to the code, kitchen contains documentation that explains some of the common problems that arise when dealing with unicode in python2 and how to fix them through changes in coding practices and/or making use of functions from kitchen.
The 1.1.0 release enhances the gettext portion of kitchen. The major enhancements are:
- get_translation_object can now be used as a drop in replacement for the stdlib’s gettext.translations() function.
- If get_translation_object finds multiple message catalogs for the domain, it will setup the additional catalogs as fallbacks in case the message isn’t found in the first one.
- The gettext and lgettext functions were reworked so that they guarantee that the string they return is both a byte str (this was present in previous kitchen releases) and is a valid sequence of bytes in the selected output_charset. This should prevent tracebacks if your code decodes and reencodes a value returned from the gettext and lgettext family of functions.
- Several fixes to the way fallback message catalogs interacted with input and output charsets.
For the complete set of changes, see the NEWS file.