Using Future Statements to Prepare for the Future

Note: This article was first published the June 2008 issue of Python Magazine

Mark Mruss

With the release of Python 3.0 only a few months away many Python programmers have visions of compatibility problems dancing in their heads. This article will introduce the concept of future statements including two future statements that you can use to help prepare your code for version 3.0.

Introduction

Python 3.0 (or Python 3000 as many people know it) is something that many Python programmers have started thinking about. Besides being the next major version of our beloved programming language, version 3.0 of Python will break backwards compatibility with the current 2.0 branch of Python. This means that a some of the code that you are writing right now in Python 2.X won’t immediately work in Python 3.0. Since Python 3.0 has a scheduled release date of September 2008 [1] now may be a good time to start thinking about future migration.

Of course there’s no reason to be alarmed yet. Guido, himself, has said that there is no rush to switch over to Python 3.0. [2] According to his PyCon 2008 essay “Python 3000 and You” you should switch when the following are true: “1. You’re ready 2. All your dependencies have been ported.” [3]

In the same essay Guido also says that Python programmers should be prepared and that they should “start writing future-proof” code for 2.5″ [4] In this sprit, this article will introduce “future statements” and two ways that you can use them now in order to make the migration process from the Python 2.0 branch to the Python 3.0 branch as smooth as possible.

The rest of this article, and the examples within, will assume that you are working with Python 2.5.
Continue reading Using Future Statements to Prepare for the Future

Python Version Poll Results

The results are in for the first annual LearningPython.com Python version quiz:

Which version of Python do you use?

  • 2.6 (65%, 700 Votes)
  • 3.1 (17%, 187 Votes)
  • 2.5 (17%, 182 Votes)
  • 2.7 (4%, 48 Votes)
  • 2.4 (3%, 32 Votes)
  • 3.0 (2%, 20 Votes)
  • 2.3 (0%, 5 Votes)
  • 2.1 (0%, 3 Votes)
  • 1.5 (0%, 2 Votes)
  • 2.2 (0%, 1 Votes)
  • 2.0 (0%, 1 Votes)
  • 1.6 (0%, 1 Votes)

Total Voters: 1,084

Loading ... Loading ...

By a landslide version 2.6 is the winner, with 3.1 and 2.5 following far behind. A grand total of 1084 people voted and 700 of those still use Python 2.6, 187 use 3.1 and 182 use 2.5. While not the largest sampling of users the wide margin of victory probably means that most Python programmers are still targeting 2.6, or at the very least the newest version of the 2.x branch. Now what is installed on our end user’s system…that’s another matter all together.

Thanks again to everyone that voted. I’m happy that I was able to attract 1000+ people to vote in this poll. My next idea for a poll is an IDE poll, partially because I’m curious as to what people are using, and partially because there is a good chance that I may have overlooked other programs on my way to selecting Geany.

Note: Python 2.7 was released (July 3rd, 2010) after the poll was created (Mach 4, 2010) this means that the value for 2.7 is probably larger now and 2.6 is probably slightly smaller.

Introducing Descriptors and Properties

Note: This article was first published the May 2008 issue of Python Magazine

Introducing Descriptors and Properties

Mark Mruss

New-style classes were introduced to Python with the release of Python 2.2. And with these new-style classes came descriptors and properties. This article will introduce the descriptor protocol, descriptors, and properties.

Introduction

New-style classes were introduced to Python with the release of Python 2.2. A new-style class is any class that is derived from the object base class. New-style classes give Python programmers many new (and initially confusing) features. One such feature is the descriptor protocol, and more specifically descriptors themselves.

Descriptors give Python programmers the ability to easily and efficiently create “managed attributes”. Managed attributes can be thought of as attributes that are not accessed directly. Instead their access is “managed” by something else, generally a class or a function.

If you haven’t come across this before you are probably wondering why one would want to manage attribute access? One reason might be that you don’t want people to be able to delete the attribute. Another reason may be that you need to ensure that your attribute data is always valid. Or perhaps attribute x is based on attribute y, so every time the value of y changes you want to update the value of x. From these few examples you can see the many possible cases where you might want to control access to certain attributes.

For those of you familiar with other programming languages, this type of access is often referred to as “getters and setters”. In many language, implementing “getters and setters” means using private variables and public functions that get and set the variable’s value. Since Python doesn’t (really) have private variables, the descriptor protocol is basically a built-in and Python-ic way to way to achieve something similar.

This article will introduce you to the descriptor protocol, descriptors, and properties. It will focus on demonstrating how to use them to create managed attributes. Since the descriptor protocol requires new-style classes, all of the examples in this article require Python 2.2 or newer.

Continue reading Introducing Descriptors and Properties

Forums Forums Forums

I just wanted to re-point out the fact that there are some forums associated with this blog. There’s not much happening there, and recently they have become a haven for spammers, but I’m trying to clean them up and if other Python programmers read this blog maybe the forums could actually become useful!

Either way for those that didn’t know, there are learning python forums available.

Poll: Python Version

Edit: Due to popular demand (well a couple of comments) I’ve decided to allow multiple answers to the poll. This should make everyone that uses two versions happy.

With two major versions of Python available to us Python programmers (2.X and 3.X) I thought it would be interesting to see which version the readers of this blog are using and targeting.

Personally I’m still using 2.5 on my Debian box because it’s the default, and 2.6 on my Windows PC. While I have used 3.X and have it installed, I’ve remained on the 2.X branch largely because many of the modules that I play around with are still focused on the 2.X branch so that’s where my focus has remained.

I voted 2.5 since I do that majority of my programing on my Debian box. So now what about you:

Which version of Python do you use?

  • 2.6 (65%, 700 Votes)
  • 3.1 (17%, 187 Votes)
  • 2.5 (17%, 182 Votes)
  • 2.7 (4%, 48 Votes)
  • 2.4 (3%, 32 Votes)
  • 3.0 (2%, 20 Votes)
  • 2.3 (0%, 5 Votes)
  • 2.1 (0%, 3 Votes)
  • 1.5 (0%, 2 Votes)
  • 2.2 (0%, 1 Votes)
  • 2.0 (0%, 1 Votes)
  • 1.6 (0%, 1 Votes)

Total Voters: 1,084

Loading ... Loading ...

If you want to explain your choice leave a comment below.

An Introduction to Google Calendars

Note: This article was first published the March 2008 issue of Python Magazine

Mark Mruss

Over the past few years Google has expanded it’s services beyond those of a normal search engine. One of those new services is the Google Calendar. This article will provide an introduction to working with the Google Calendar using Python.

Introduction

As many of you know, Google has branched out and started offering more services besides their ubiquitous search engine. You have email, calendars, documents, spreadsheets, photos, maps, videos, source code hosting, and the list goes on. Fortunately for us Python programmers, Google released the Google data Python Client Library on March 26th, 2007, giving Python programmers easy access to some of these services.

Continue reading An Introduction to Google Calendars

Introducing Docstrings

By: Mark Mruss

Note: This article was first published the February 2008 issue of Python Magazine

Of all the tasks assigned to programmers, commenting code and writing documentation are among the most disliked. This article introduces you to Python’s documentation strings. While they won’t make commenting your code any more enjoyable, they will provide a systematic approach to doing it, as well as access to additional tools for documentation generation and testing.

[ad]

Continue reading Introducing Docstrings

Iterators, Iterables, and Generators! Oh, my!

By: Mark Mruss

Note: This article was first published the January 2008 issue of Python Magazine

Iterators, iterables, and generators are features handled so wall by Python that people programming in other languages cannot help but drool over. Fortunately for us, creating iterators, iterables and generators is a relatively simple task. This article introduces the concepts of iterators, iterables, and generators and illustrates how easy it is to add them to your code.

  1. Introduction
  2. Iteration in Python
  3. An Initial Example
  4. Creating An Iterator
  5. Looking More Closely At The Iterator
  6. The Upside And Downside Of Iterators
  7. Generators
  8. Looking Closely At The Generator
  9. But What About Iterables?
  10. Creating An Iterable Object
  11. Conclusion

Continue reading Iterators, Iterables, and Generators! Oh, my!

DodgerEditor 0.1a

So just to prove that I’m a masochist and that the Dodger Editor is not dead (even though I don’t think that anyone has been using it) I thought I’d post a quick update. No the editor is not dead and no neither am I.

I’m still writing for Python Magazine and working on the editor in some of the free time that I get. I just added a selection cursor mode to the editor which makes it easier for me to use. You can see it in the second row of the pallet in the following screen shot.

Now with a Select Mode!
Now with a Select Mode!

If you want access to the newest code you can grab it from the mercurial repository: http://freehg.org/u/selsine/dodger/

If anyone is at all interested in this project, whether it’s using or helping to develop, or just some suggestions please let me know. I’m always open to opinions. If I get the time I’d like to work on a short post showing you how you can use the Dodger Editor to create the level files for a game, when that will be I don’t know but hopefully soon.