hpr-knowledge-base/hpr_transcripts/hpr0545.txt

Episode: 545
Title: HPR0545: Little Bit of python episode nine
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0545/hpr0545.mp3
Transcribed: 2025-10-07 22:50:41

---

Music
Hello and welcome to another part of Python, episode 9, with Andrew Kutling, Michael Fuzzyman.
What's your second name, Michael?
Ford.
And Steve Holden.
Today we've got a program of varying interest.
We're going to start out talking about what's coming down the pipe in C Python.
Because listeners may be aware that a new 2.7 release is is due out fairly shortly and changes are taking place in the code based daily.
Then we're going to have news from other Python implementations, other Python related news and then the end of the program.
We're going to be talking about a new Python for Newbies section which is coming up.
So first of all, what's coming in C Python?
We've talked about this in a couple of other episodes.
But I think as the Python 2.7 release gets closer and closer, the progress in the, amongst the core, developers gets more and more frantic.
So one of the really new things is that a module called AgPars is going into the standard library.
This is by Stephen Battard.
It's been available as a separate module for quite a while.
And the URL for it is a standalone project.
If you want to use it in earlier versions of Python is code.google.com slash p slash AgPars.
This is a module for creating command line tools and handling command line arguments.
And it really makes the task much easier and provides as well as simple argument handling so much more complex and much more advanced argument handling as well.
So this is actually the third argument parsing library that standard Python will have.
The first one is the get opt module, which is really simple and is modeled on the standard C libraries get opt function.
The second is the opt pars module, which is much more pathonic.
It understands data types, for example, so it can automatically convert option arguments to integer or string or whatever.
It's also very nicely able to build your command line help automatically from the description of your available options, which I think is one of its nicest features and what I tend to use it for.
And the AgPars does a lot of the similar jobs, but because of the way opt pars is written, there's some things it can't do and modern applications need things like the handling subcommands, for example.
Like if you've ever used say subversion and you do subversion, you have subversion commit and then commit has a whole bunch of arguments or you have all the other different sub commands each of which are having their own arguments.
And opt pars isn't able to hand that because of the way it's written, it's not really possible, it wasn't really possible to extend opt pars to do that.
And that's why we've got a third module that's come in.
And there was a lot of discussion about whether opt pars should be deprecated that the final decision was, but because it's so widely used, there's just no need to actually deprecate it.
But for new users, we're going to be pointing them to the AgPars module rather than opt pars.
Seems to make sense. Okay, so command line processing is going to become even more Python and easier.
And then I believe you've got some news, Michael, about changes to the unit test environment and specifically a new unit test module package.
One of the big things that changes in Python 2.7 tripping over myself is a lot of changes to the unit test module which we have covered in a previous episode.
I've now back ported all of those changes to work with Python 2.4 to Python 2.6.
So if you're using earlier versions of Python, you can use all of the fancy, good news stuff that's in unit testing, Python 2.7.
And that package is called unit test 2 and it's on the Python package index.
And what's nice from my point of view is that it's already got users, the new disc utils project, they're using unit test 2.
There's a ticket to take advantage within Django as well.
So it seems to be getting some momentum.
And the on the testing in Python mailing list, Jason Pellerin, who's the maintainer of knows and knows is one of the most popular Python testing tools.
He's sent an email and talked about how there should be because the new stuff in unit test does a lot of what knows was written to do or certainly makes things a lot easier for a lot of what knows does.
He's talking about a new version of knows imaginatively called knows to that will be built on top of unit test 2.
So it's very nice for me to see that momentum here and people starting to use the package.
Excellent.
And then finally, I think we wanted to note that elementary 1.3 is going to be released with 2.7 correct.
Laranshi Kloona committed elementary 1.3 to the Python 2.7 tree.
This requires some discussion because there hasn't been a final release of it yet. It's currently in a beta state.
There isn't really one big large new feature in elementary 1.3.
Instead, there are lots of smaller changes. Some methods have been renamed. Some new methods have been added to let you iterate over, say, all of the inner text contained in a subtree of your XML document.
And the classes for serialization, which convert a tree to a string output, that's been rewritten as well and should be a good deal faster.
So while there isn't one particular big feature from this, it wraps up a bunch of nice improvements.
And it fixes some nasty problems that were with unique kind of problems, I think, as well as one of the...
I saw some tickets being closed related to unicode issues in elementary 1.3.
Yeah, one of the nice parts about the new one is the XML parser, which is replacing XML tree builder.
Now allows you to specify an encoding argument. So you can override your files internally encoding if you want to and say what language you...
What encoding the XML is in. I have to say, until elementary came along, I used to rather dread doing XML work with Python.
And since I started to use elementary, it's become an absolute joy. It is a really easy library to use.
And if you use the C-element tree version, very, very speedy as well, compared with some of the other libraries that are available.
So I would definitely like to record my thanks to Frederick London, the other people who've worked to element tree to make it so successful.
And it's interesting that you mentioned Florence who got this work committed. He's actually a new committed to Python.
And he's been amazingly productive. He actually got involved with Python by start.
He was one of the guys we've had who's recently been working their way through our bug tracker and finding all the outstanding bugs that people haven't commented on and have been doing tree arching and creating patches to fix issues.
He's been working incredibly hard on Python recently, so big thanks to him for that.
He's always nice to see people joining the Python development community. Long may that continue, but we can talk about that another day.
So news from other pythons. There are, of course, a number of other implementations, including PyPy and I and Python, although there's a binomial to the only two.
What have we heard about other pythons recently?
Well, the big news from PyPy is that they've done a 1.2 release.
And for the first time, this release includes their just-in-time compiler.
And it's targeting standard Intel X886 machines, 32 bits for the moment.
It works on Linux, Windows and MacOS.
And they're showing on some substantial, some real world sort of benchmarks.
They're showing that PyPy is running faster, not just faster than C-Python, but in several cases faster than Unladen Swallow II.
So the competition for performance amongst the Python implementations is really hotting up.
Well, I'm very glad to hear it. I think that's one of the more interesting aspects of Python, because there are some people who do need more better Python performance.
And I think that it's good to see developers focusing on that.
Well, one of the things that has come out of Unladen Swallow is Unladen Swallow.
They wanted to be certain that they were really speeding Python up in their work.
And so rather than just using these micro-adventure marks that everyone's been testing the performance of their implementations of Python with, you know, how fast can you add numbers in a loop?
And that kind of thing, which really doesn't tell you anything about how fast your applications are going to run.
So Unladen Swallow started using these more real-world benchmarks, things like the Django Templating Library and other things that they were really interested in speeding up.
And those have now been made into a central repository on Python.org.
And we've got a standard set of benchmarks that all the implementations, once they get to the point where they're capable of running them, they can use these benchmarks.
And we can really compare the performance of the different Python implementations with something other than doing things like the old PyStone or the old Richard benchmarks, which was really not very good benchmarks.
PyStone was never very good.
We did spend several days, a few of us spent several days in the Iceland Need for Speed Sprint, which is what, three, four years ago now, taking a look at benchmarking in Python.
And we realized that it's a very difficult task indeed.
So I think the fact that we've, we've got these real-world pieces of code that people can, can run their implementations against is a terrific thing.
And I think it, it also shows the benefits of having multiple implementations that these implementations are now starting to play off each other.
They're competing with each other, but they're also cooperating and that's a contribution from the Pi Pi guys that's going to be useful for anybody who wants to build an implementation of Python.
Yeah, there's a new rule. You're no longer allowed to claim that your implementation of Python is faster than C Python until you can run these benchmarks.
Oh, good.
It's very easy to make half an implementation of Python that runs very fast.
But to implement, if you, to implement the whole language is a very difficult task as, as many people have discovered.
Yes, we can now add one to an integer faster than any other implementation, but we can't do anything else.
Then there was also, I think, some news from the I and Pi world.
Well, I follow the I and Python news quite closely and that this email caught my eye.
One of the big problems with switching to a completely different implementation of Python is that the C extensions that people rely on may not be there.
And one of the, the C extensions that's very popular that was originally created by Andrew, I believe, is something, something called Pi crypto.
And someone has just done a port to, to I and Python and specifically the bits that were written that are written in C in Pi crypto, they've rewritten in C sharp.
So they should perform very well.
So there's this new project, I and Pi crypto. It's just had its release.
And if you Google for I and Pi crypto, you won't get many results. So I should get you there pretty quickly.
Okay, good one and one interesting question, of course, is, is how does a code base like Pi crypto?
How should it best be engineered so that it can be contributed to multiple Python's?
Back in the day, I actually wrote a PEP describing the API for block encryption modules that Pi crypto supports.
I think it was PEP 247 or thereabouts. And no one else ever really picked up on this PEP because as an application area, there isn't enough activity to attract many different implementations of things.
Yeah, I suppose particularly in the crypto world, probably you've got, I don't know, 10,000 users for every, every programmer and a thousand programmers for every new developer, right?
Or something like that. Not many people actually do hard work in crypto.
And part of the usefulness of writing this Pi crypto adaptation for I and Python is probably that it'll let them run parameco, which implements the SSH protocol.
So you could write iron Python scripts that SSH into servers or securely copy files around or whatever.
And that's often a useful step for the version control systems. I think bizarre, for example, uses parameco to implement bizarre over SSH.
Okay, so this is actually possibly a stepping stone to getting things like bizarre working on iron Python.
Right, right. So lots of progress there. Then do we have anything else to say about the other Python implementations?
Well, just to know that I and Python 2.6 has just made it into Debian said as well. That's some more news from the I and Python world.
There's a guy who he's actually an iron Ruby user in particular. I can't remember his name, I'm afraid, but he's spent a lot of time getting, getting, for example, the I and Python tests to run under the mono version version that Debian packages so that we can have both I and Python.
And I and Ruby are available in Debian said and you'll be able to do up to get I and Python or up get I and Ruby and have them there with their monodependencies.
So it's another implementation of Python that's going to be more easily available to a whole bunch of people.
Okay, would that be Mr Adams Collier that we're talking about?
That's right. Yes, thank you.
Very good. Excellent. Well, thank you to him for making sure that it is available. I know that the whole world isn't absolutely delighted about the prospect of running any monobased packages on Linux distributions.
But I think in terms of making Python more available, it's actually going to be quite useful because it brings a lot of functionality from that people think of as just being dot net functionality to other platforms.
A silly question from someone who doesn't actively use Debian anymore.
Is Debian unstable? That's right. Yes.
I believe so. Yes. Absolutely say so, but I believe so. Yes, I'm not a direct Debian user, although people say they don't use Debian and then they run Ubuntu, which of course is a Debian based distribution.
But has a very different release schedule indeed. Yes, absolutely.
Okay, so other news.
This is slightly old news at this point.
A press has just come out with the definitive guide to Jython.
Yeah, and it's written by most of the primary developers of Jython.
So Frank Wiersbicki and Josh Juneau and Jim Baker and Leo Soto.
Yep. So we can expect it to be a fairly authoritative book then.
I expect so. Excellent.
I think the only other news I can remember we were planning to discuss was the upcoming Pi Week. Is that right?
Coming up in the weeks ahead is the latest iteration of the Pi Week game programming challenge entrance after right computer game using Python and Pi game in one week from scratch.
Okay, and you can participate as an individual or you can form a team.
The way the contest is organized is first the participants vote on a theme.
And the theme is usually something very vague like steam or darkness.
Feathers was the last one I believe. What are the previous ones?
Oh, that explains the chicken game I saw there.
And so once they voted on a theme, then the actual competition starts in a certain day.
So voting for the theme closes on March 21st.
I'm arranging an interview with Richard Jones organizer of the Pi Week game programming challenge.
And I hope to get that interview completed and published before the challenge actually starts.
And that would be nice.
And Richard Jones is he's the primary developer on the piglets toolkit or library, which is games writing library rights.
Yeah, Richard's actually been organizing Pi Week for as long as I can remember their challenge has to be at least what six, seven years old now, Andrew.
The very first Pi Week was in August 2005.
And Richard has been running it since the beginning.
He got the idea from another game programming contest that was you had 48 hours to write a game.
But that's much harder because you basically have to carve out those 48 hours and do nothing else for that time span.
Right. One of the fun things about Pi Week is you're allowed to use existing libraries and toolkits.
So I've seen at least a couple of posts on Planet Python where somebody has said, here's my games programming library.
I'm releasing it so that so that I can use it in the coming Pi Week.
So so long as they've done the public release before the before Pi Week starts, they're then allowed to use all that code that they've already written in their game.
Well, that seems fair because it gives everybody else some chance to benefit from it as well, I suppose.
Yeah, anyone else can use it as well. But it's a nice way of motivating people to release code and release libraries.
Excellent. Other people could follow that example because I do in Pi Week has actually been responsible for several interesting games, including I don't know whether you two guys are galcom players at all.
I don't play.
Yes, I play on my iPhone. It's great for me.
Yeah, well, I was going to say it now has an iPhone implementation as well, but that started out as a Pi Week game, I believe.
And then it was so well received that Phil Hassey, the guy who wrote it, then re-implemented some of it in C.
And it's now become a multiplayer internet-based game as well as other things.
So yeah.
Multiplayer is great fun.
It's all though I must say I'm such a poor player that I've become a little dispirited because I'm forever getting wiped out with complete ease by more experienced players.
It looks like Phil Hassey actually first wrote it as a VGA game in 95.
Oh, right.
It went through several versions and then in 2006, a version of it won the 48-hour game competition.
Okay, right.
And all the modern versions have descended from that 2006 version.
All right.
So I was completely wrong, but it made a good story.
It was a good story.
Thanks, Andrews.
I'll re-edit this into shape.
I should also mention that one of the recent pieces of news we've had from Richard is that they are planning to start a pi-con Australia this year.
So yet another yet another domino in the the plan towards world development to word total world domination.
I think they had to after New Zealand got its own pi-con didn't they?
They were felt that they were letting the site down.
Maybe I think a lot of Australians actually went to New Zealand for pi-con and maybe were encouraged by the response there.
Pi-con New Zealand seemed to me from this the other side of the world to be very well organized and very popular.
And just to throw in that Richard is going to make his way to Euro-Pi-con and he's going to be doing a games programming tutorial at Euro-Pi-con.
So if you're able to make it to to Euro-Pi-con there's yet another reason to come.
Okay, well I am hoping to make it to Euro-Pi-con.
One of the reasons I'm hoping to do that is well there are two other reasons.
One is that I have a potential training customer in Amsterdam.
And the other one is that the Irish Python users have now decided that there's going to be a pi-con Ireland.
And it's a couple of days before that's right yes.
In fact I seem to remember that they're planning to hold theirs on Saturday, July the 17th.
And if I'm correct Euro-Pi-con begins on Monday, July the 19th the same day as Oskon unfortunately.
But I decided I'd rather go to Euro-Pi-con than Oskon because Euro-Pi-con to coincide with other plans.
So it's going to be a busy travel week for me, some of the for me.
I've got three weeks in the far east with a visit to Picon Asia Pacific.
And then in July that's in June and then in July I've got this probably going to be at least a week's trip to Europe.
But lots of interesting things going to be happening on the Python front this summer.
So some other news we've got is about what we're going to be doing in future episodes.
We had a great email from one of our listeners who said why don't you cover some news and some tips that are interesting for people who are new to Python.
So one of the things we're going to be doing in future episodes is have a Python for newbies section and cover things to help people who are just starting out in Python.
And thanks very much for the emails that we've had already.
I would say that was Ganesh Swami Nathana.
I'll probably find I've mangled it but anyway Ganesh, thank you very much for your suggestion.
And we would like listeners to know that we do read your emails and that when they contain suggestions that we think will help the podcast where more than happy to act on them as this indicates.
So I think we agreed didn't we that I would start next week or next next time because of by by talking about newbies on windows, how people could develop Python stuff on the windows platform, which is after all the source of most of our downloads, although of course that's partly because many most Linux implementations now include Python.
So you don't actually need to download it unless you want a more recent version than you get from your Linux distro.
And with that, I think we come to the end of this episode, is that correct?
Yes.
So little remains except to say thank you for listening.
This has been episode nine of a little bit of Python with Andrew Kufling, Michael Ford and myself, Steve Holden.
Until next time, keep using Python.
Please send your comments and suggestions to the email address all at bitofpython.com.
Our theme is track 11 from the headroom projects album HIFA available on the Magnetune label.
Thank you for listening to HIFA public radio.
HBR is sponsored by Carol.net.
So head on over to C-A-R-O dot N-E-T for all of her team.
Thank you very much.
Thank you.