Episode: 535
Title: HPR0535: New Features in Python 2.7
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0535/hpr0535.mp3
Transcribed: 2025-10-07 22:40:57

---

MUSIC
This is episode five of a little bit of Python. Brett, being absent today, we have Andrew
Kutling, Jesse Nola, Michael Ford and myself Steve Holden.
I'd like to add, if you want to send us any feedback or hate mail or suggestions for future
topics that you want us to gather, you can email us on all that's bitrifythan.com.
Once again, that address is all at bitofpathon.com.
So what news should we discuss?
Well, let's start off with a pet for 391, which is a dictionary-based configuration for the
logging module inside of the standard library. So I guess I'll start it off. So Vene, the
log module maintainer recently did a pet, and that pet is 391, and it brings a dictionary-based
configuration for the logging module. Now, for those of us and those of you who have used
the logging module in the past, I'm sure we've all run into the problem that the configuration
can be Byzantine at times, and slightly confusing. So what Vene hoped to do was to simplify
the logging module's configuration using this dictionary-based configuration. So you can say,
you can define a dictionary called config, and inside of it, you can define your formatters as
keys, the values being, you know, the various formatting, you can add a handlers inside of the
dictionary. It's a much more sane and rational layout for the configuration of the log module,
that's my opinion. Okay, what about backwards compatibility?
It's, as far as I can tell, it's not backwards compatible. He's going to probably release it up
on a pi pi as far as I'm aware, and it's being put into Python 2.7 and 3.2, but he'll probably
release it as an external module onto pi pi. Are you saying that you think it does break backwards
compatibility in the previous uses? No, no, no, no, it doesn't. It doesn't break. It adds to, I'm sorry.
Right. Okay, that was what I was wondering about. Good. Oh, I apologize.
Is it actually in, do you know if the new scheme is in 2.7 alpha 3, which I think as we
record, Benjamin is currently putting together? I believe it is, yes. Good.
And one of the things I'd like to say about the logging package is that I haven't used it,
and I don't know much about this particular pet, but I do know that I've heard various people
complain about logging in Python, and without having used the package, I can't comment on whether
those complaints have any validity or not. But I do know that Vinay, who is the maintainer of
logging, is a very active developer, and if people do have problems, and they actually bother to
submit bug issues and say what the problems are, he's very responsive at dealing with those
and trying to fix them. So it props to Vinay for looking after this package and for developing it.
Oh, definitely. I mean, he's definitely very, very responsive. I think part of the problem
that many people run into is that configuration has been esoteric in the past, and it's a taste
thing. So a lot of, one of the common criticisms is people take one look at the logging module,
they just say, whoa, where do I even begin to start, and this smells like Java?
That has been my approach to logging. This is, this looks so difficult. I don't think I've
used it once, I believe, because I had to with somebody else's software, but it is,
or was very esoteric in terms of setup and so on.
It is, and I mean, Vinay is very reactive, he's very responsive, but the logging module is definitely
one of those modules that has, it has opinions and very, very strong opinions about how logging,
how handlers, how formatting, you know, chains of various orders, it's very, very opinionated.
And I think that's both a good thing and a bad thing. It's extremely powerful once you kind of
get over the initial learning curve. It's, it's pretty powerful. And I mean, it's got handlers
for everything. It's got syslog, handlers, it's got current, it's got like, it's got a handler
that integrates with the Linux log rotate, Damon. No, it's just, it's extremely powerful. It's just,
it's, it's got a learning curve. Maybe it's just that, maybe there is an article out there that
explains simply how to use logging that I've just never read. I mean, I know that Vinay is very
articulate when you, when you, you converse with him about the, the logging module.
Well, that document and that article should be the documentation. And if the documentation
isn't enough of its tutorial and isn't clear enough, then again, I'd say, just say that in a,
in a Python algorithm, and I'm sure I've been able to deal with this.
Doug Helman did write a Python module of the week article on logging.
And you can probably track that down by googling for Doug Helman logging.
I've seen some better pages of pages. It's nearly covered on standard library now.
It will be very nice if someone were to write a logging module how to, because the library
documentation tries to be more of a reference. And so there isn't really space for an extensive
tutorial that sort of walks you through a set of examples from a very simple log file up to a
very complicated, large application with a big complex tree of logging modules and so on.
I believe Vinay actually started a log for the module. And I, it's, here it is, if you go to
Lumber, PLUM, B-E-R, Jack. So that's one word plumberjack.blogspot.com.
On that blog, I believe Vinay has a very extensive post on Python logging 101.
So he is trying to, you know, document it. That last 101 post was from September 2009. So
I mean, definitely give Vinay feedback. He's extremely responsive. Okay.
If that blog isn't already in Python, I'll make sure I get that. It was best place to go for Python news.
So the reason that this particular pack came up is because Guido had a sudden burst of activity
on the Python dev main list and there's approved about three paps in one go. And I think
PEP 345 and PEP 386 were also, he's just approved. Does anyone know any of the details on, on those Python
enhancement proposals? Well, PEP 345 specifies a new version of the metadata inside a Python
package on the package index. And if you go read the path, there's actually a section which talks
about the difference from version 1.1 of the metadata format. So there are a bunch of added
fields for specifying the maintainer's name and contact email, which, and the maintainer can be
different from the original author. There are also keywords for dependency information.
So the method is just to jump in here under here. Sure. This is for the metadata that you
specify when you basically when you're uploading a package to the Python packaging index.
Right. And for tools that then use that metadata for automatically installing packages from the
final packing packaging index. Correct. And so it also defines a way to specify requirements on
the environment that a package runs in. So you can say that this application requires the win
32 extensions, or it only runs on an i386 platform, or it requires Python version 2.4 or 2.5
and so on. We haven't had proper dependency handling in the Python distutals library for when
you install packages. We haven't had proper dependency handling as part of the core library ever in Python,
have we? I don't believe so. No, it was drafted as part of the metadata, but I don't think anyone
ever actually picked it up and implemented it. So does this pet specify that just utils will use that
to find dependencies or just warn you that you don't have the dependencies?
I don't know and you certainly the pep does not actually say anything about this, but
the obvious assumption is that if if we're adding things to this metadata format,
distutals will gain methods or parameters that let you specify all this information.
Do you know whether the authors of cheesecake are going to adopt their stuff to pep 345 so that
we can actually have something that will complain about it before people upload stuff?
Is cheesecake still being used? Is it still working? I don't know. Do you want to explain what cheesecake
is? Yeah, cheesecake was a Google Summer of Code project, I believe, wasn't it? A couple of years
ago, somebody decided that they were going to take a look and do automated scoring of distributions,
and I think the original idea was to try to improve the quality of the distributed code,
the stuff that got distributed through PyPy. Yeah, it was supposed to be a port of basically the
the CPAN testing service. So pie cheesecake, Donald, is the home page? It says cheesecake,
how tasty is your code? Unfortunately, I'm pretty sure that that has
sort of died down since it took off. I don't know if it's somebody would have to ping rig
to see if it was still kind of up and running. I mean, there are alternatives that have kind of popped
up like PyPants. So if you go to PyPants.org, that was a sprint project from a couple of guys
involved in Django. It's pretty, but I don't know how used it really is or how active it is
right now. From a kind of a personal itch standpoint, I think that there is definitely a space for
a pie cheesecake or pie pants like service layered on top of PyPy in the future. I think testing
like objective quality metrics are going to be kind of critical as the community and it's the
packages and the libraries continue to expand and grow. Yeah, the more automated help we have the
better, I would say, certainly. Yeah. So the other path or the other path that's been approved
at the same time is PEP 386 and that's about changing the version comparison module in
disk utils, which is like just one tiny component of disk utils, the Python distribution utilities.
You wouldn't believe how much sort of debate or you probably would believe and how much
discussion there was to try and get, how can we have a standard algorithm for describing version
numbers that meets everybody's use cases so that you can describe things as alpha and beta and
release candidates and that the version comparisons work for those different release numbers.
So I think they finally hammered something together that just about works for almost everyone.
That's good. I remember that Django this time last year was looking to see whether they had any way
to, to perform version comparisons and I said, well, you know, why did you just use the standard
Python one? And I think they did actually move to the standard Python one, which is good enough
for their purposes, but obviously it wasn't good enough for everyone's.
I've had some exposure to the discussion on disk utils, etc. about the versioning stuff and
consider my, consider my mind blown on just the scope and the emotions involved in
involved in picking version numbers and trying to support all these various versions because
I will tell you this much. There is, I mean, go and take a look at PEP 386 and look at
just the examples and how many, you know, various discussions were involved, et cetera. It's
the list of version numbers from the loose version description is amazing. You've got everything from
1.5.2 B2 to 1.13 plus plus to 2.2 B to 29 is ridiculous.
And then there's people in this slide. There's a version repository,
revision number in the release numbers and this kind of stuff. Yeah, those people should be heard.
Not that I'm opinionated. And this is all part of Tarek's work to improve disk utils so that we
can do things like proper installation of dependencies and then uninstallation of dependencies with
Python packages, hopefully to work with all the platform specific dependency handling stuff as well.
And as you can imagine, these are topics that people do get very passionate and opinionated about.
And he's really been amazing at sort of pushing through and actually making things happen while
still allowing people to work on the details. And I'm sure we've mentioned it in other episodes.
But the other side of that work is the project Distribute which is a community fork of the
old set-up stories projects. We did a lot of this but there were a lot of issues with it.
And it basically wasn't being developed. There was only one person on the development team who
wasn't that involved anymore. So Distribute, it started from the set-up tools code base.
And there's been a lot of bugs fixed. There are a lot of people actually working on it.
So my opinion is that it's usable now because it started from the if you were using set-up tools,
it's only got better from there. It's fantastic for Python to see these issues which are really
quite a big issue issues in the Python community to even get addressed and get addressed and worked on.
And that actually reminds me of another new Python 2.7 feature.
Distribute tells us long had a module called sysconfig which let you look up information about
the system that Python was compiled on, the platform, the compiler switches used, that kind of thing.
And sysconfig has now been promoted out of the distribute package into a library module in 27.
Yeah, there's a bunch of new stuff coming up in 27. One of the things that I actually added
recently to the multi-processing module in the 27 branch was the ability inside of a
multi-processing.pool. You can actually now dictate how many pieces of work a given process inside
of the pool will take and work on before it actually kills itself and is replaced by a new process.
This is actually useful. A lot of things like mod WSGI and Apache use this common
this pool method to basically prevent, you know, memory leaks inside of the code that the processes
are running, just basically just refreshing the processes within the pool for long running things.
Definitely go take a look at the latest 2.7 alpha up on python.org. If you go to docs.python.org
forward slash dev forward slash what's new forward slash 2.7. Andrew, are you still doing these?
Yes, I am. Only the 2.71. But what's new on it is just huge.
So I still have 37 commit messages in my to be written about folder. I hope to get that
completely finished by, I don't know, maybe 2.7 beta 2.
It's still a bit of time before 3.7 comes out. We're earning the out of this.
This alpha 3, the last alpha for 2.7 alpha 4 in a march.
And the language summit may actually end up either adding or somehow modifying the release
scheduled because I know there's going to be a lot of things that we're going to discuss
at the language summit around 2.7 the potential of 2.8 so on and so forth.
Right, if people, if readers want to take a look at the existing schedule, then they can take a
look at pep 373 which actually specifies that which I presume is where you're getting your
information from there. Andrew, correct. And that currently has the final release scheduled for
the 26th of June, although you're indicating that that may actually change somewhat, Jesse.
Yeah, I'm pretty sure things are going to change coming out of python. They always do.
And python coming up is really pushing people to be more active. In addition to 2.7 alpha 3 coming
out, Barry Warsaw announced he was going to issue a 265 bug fix release.
Yeah, we've got the schedule for that as well now, which is great.
So Barry's plan at the moment is to do a release candidate march first and hopefully a 265 final
release March 15th. And so that will hopefully give us all a chance at PyCon to back port bug fixes
or other work we want to. So if there's a bug you that in 2.6 that's been bugging you,
it will be a good idea to work on getting a patch ready.
This has been a little bit of Python episode 5 with Michael Ford, Steve Holden, Andrew Kuschling
and Jesse Nullar. Please send your comments and suggestions to the email address all at bitofpython.com.
Our theme is track 11 from the headroom project album Haifa, available on the Magnetune label.
Thank you for listening to Haifa Public Radio.
HPR sponsored by Carol.net, so head on over to C-A-R-O dot N-E-T for all of us in the