lee/hpr-knowledge-base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit: HPR Knowledge Base MCP Server

Browse Source 
- MCP server with stdio transport for local use
- Search episodes, transcripts, hosts, and series
- 4,511 episodes with metadata and transcripts
- Data loader with in-memory JSON storage

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Lee Hanken
2025-10-26 10:54:13 +00:00
commit 7c8efd2228
4494 changed files with 1705541 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

207
hpr_transcripts/hpr0510.txt Normal file
View File

@@ -0,0 +1,207 @@
Episode: 510
Title: HPR0510: Python Language Moratorium Python 2.7 End of the Line?
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0510/hpr0510.mp3
Transcribed: 2025-10-07 22:04:08
---
Stay tuned!
Welcome to a little bit of Python Episode 1 with Andrew Kufling, Jesse Nourler, Brett
Cannon, Michael Ford and myself, Steve Holden.
I'm Steve Holden. I'm the chairman of the Python Software Foundation, which gives me
a huge amount of leeway to ignore my own financial best interests in running my own business,
Holden Web LLC, which does Python and other systems design and implementation consulting
and training, and I've been a Python user now for almost 15 years.
I'm Michael Ford. I've been developing with Python since about 2002.
I maintain the unit test, standard library testing framework in Python, and I'm currently
just switched to freelancing. I'm currently working with the firm in Germany, developing
with Django and also with Iron Python in Silverlice, and also the author of Iron Python in action.
Brett? My name is Brett Cannon. I'm currently a PhD candidate at the University of British Columbia.
I started using Python in the fall of 2000, became a core developer in April 2003, and I'm
also currently the executive vice president of the Python Software Foundation.
Jesse? I'm Jesse Nourler. I'm the maintainer of the multi-processing module for Python, full-time
Python developer coming out of Boston. And is Andrew still with us Andrew?
I'm Andrew Cushlin. I'm a web developer in Fairfax, Virginia, and I'm also a former Python core
developer. I still have commit access, but these days most of what I do is writing.
And so we decided that today's topics should be the 2.7, version 2.7 end of life considerations,
the moratorium on the further development of the Python language.
The first of the topics is going to be the moratorium. And for those of you who don't read
PEPs, the relevant Python enhancement proposal is PEP-3003, which came from an ideas suggestion
by Guido Van Rossum, Python's founder and inventor, who feels that perhaps it would be a good idea to let
other implementations catch up with C Python before we start to throw too many more changes
into the language. Would you all say that's the first summary of the thrust of the PEP?
I'd say the interesting thing about the moratorium is that although it applies to the language,
so the language syntax can't change for the next couple of years and it also applies to the built-in objects.
One of the things it gives us a chance to do is to improve the quality of the standard library.
It doesn't say it's not a moratorium on changes in the standard library.
Well, no, quite. In fact, the title of the PEP is Python language moratorium, isn't it?
So not only can there is the suggestion that we, well, all right, the suggestion is that we don't,
that no more new buildings are added, that the language syntax effectively becomes immutable
other than fixing any ambiguities that may be discovered in it.
The language will continue to operate as it is pretty much.
And there will be no new future imports during the period of the moratorium.
And I think Guido was suggesting was it an 18-month moratorium, 18 to 24-month moratorium?
More or less. The idea is for the moratorium to actually last for the entire length of development of Python 3.3.
And with Python 3.2, do, I'm not sure, is it, do you think, end of 2010?
Probably.
Well, the release candidate is going to remain in June with 3.2 final June at the end of June is the current schedule living.
That's interesting. The PEP actually says the moratorium would include Python 3.2 to be released 18 to 24 months after 3.1.
Well, so the schedule that we're looking at right now, too, is was sent out by Benjamin, I'd say a couple of weeks ago.
And actually after that schedule was posted, the moratorium was approved.
And then there's a current discussion about the exact links between the releases.
Guido has been kind of staunchly in the camp of, I think, 18 months, 18 months between releases.
But Benjamin's schedule didn't exactly match that. So that's still kind of up in the air as far as I'm aware.
Well, I think it's probably a good thing to have a good long time because there was very little time between the 3.0 and the 3.1 releases because it was mostly 3.1 was mostly an efficiency release in the I.O. area, wasn't it?
Yes.
The decision is that the 3.0 should definitely follow at least 18 months after 3.1, whatever that was.
What we're really saying then is that there's going to be an unusual period of stability in the language after this brief hiccup where the developers allowed themselves to break compatibility with the Python 2 range.
Basically, the best way to view the schedule is to view it as the language stands in Python 3.1 will be the way it is for Python 3.2 and 3.3.
And no new additions will come about until Python 3.4, if at all.
Terrific.
In addition to the basic ideas of allowing the other interpreters and other implementations to catch up, what people have to keep in mind is Python over the last five years has added eight months.
Five years has added a ton of syntax, a ton of built-ins, a ton of future imports.
Then we turn around and after adding all of that syntax and all those changes into the 2X release, we also turn around and release Python 3, which is a major overhaul with major syntax changes.
The fact is that most of the stuff hasn't been able to see production use, widespread production use.
We don't know if everything we put in over the last five years actually will stand the test of time.
Well, and I think there was some feeling among certain portions of the Python user base.
The language was, if you like, going too far. I mean, some people said, well, why don't we just keep it at 2.5 and not change the language at all?
I mean, some people would have been quite happy not introducing the Python 3 series, although I think that might long term have been a mistake.
But yeah, I think you have to bear in mind that people use Python to actually get jobs done.
They're not infinitely fascinated by the various new bits and pieces that can be put in.
If those bits and pieces don't happen to be useful for the majority of people's production jobs, then probably the developers wouldn't have been doing their user base a favor by putting them in.
So it is going to be interesting to see what gets included and what gets used and what doesn't.
I remember this topic came up a couple of years ago on the Python dev mailing list and there was one developer there.
Well, nothing fundamentally new has been added to Python. So 1.5.2.
But I think that, I mean, there is a lot of new stuff that's coming.
I'm looking at some of the things that David Beesley, for example, his presentation on some of the really cool stuff you can do with the really new generation of stuff.
We're sending values back into it. I mean, I haven't had a chance to really digest that and really see what that makes possible.
I think that's going to, in the long run, it's going to change our Python code.
It's going to take time to digest that. I think it's a good thing that we pause and digest what we've already done.
Yes, I agree.
Something I've been watching, I have this unhealthy obsession with blogs and stuff online, et cetera.
And one of the things I've been seeing that's really actually been bothering me is this assertion that we're freezing and we're putting this moratorium in place because all of us think that Python is done.
The syntax is complete. The buildings are complete.
I think people need to understand that's categorically false.
No one thinks that it's done. No one thinks that we're not going to change anything.
We're actually putting this in place so that it slows things down just a little bit so that other people can catch up.
So that developers can catch up so that OS vendors can catch up.
And I think the way this reflects the fact that some of the really exciting things that are happening with Python at the moment are in the long term,
some implementations. There is a Python unlearned life and I'm Python and I'm Python.
I mean, there's an enormous amount going on in the Python world.
Well, right. When you look at the other development, so I mean, it's entirely possible that C Python in a year's time isn't going to be the fastest Python implementation.
There are already signs in in Ion Python that there are certain programs who will run much faster in Ion Python on the sea, rather than they will in C Python.
And so unless the Unladen's follow guys actually merge their stuff back into C Python, either Ion Python or PyPy might well be a faster implementation in a year or 18 months time.
I hope so. I hope so.
Well, another thing we should also underline for people who maybe don't know too much about the different developments of Python.
I mean, okay, first of all, Ion Python is an implementation that runs in the .NET environment on top of the common language runtime.
There's Jison, which takes Python and compiles it into bytecode for the Java machine.
And then there's PyPy, PyPy, which is an implementation of the Python system using the Python language as its base implementation.
And they're experimenting with all kinds of just in time tricks and so on to get better execution speed.
But all of the major implementations are apparently committed to implementing the language as it's currently implemented in Python 3, 3.1 and 3.0 being essentially the same grammar.
So if this moratorium works, that means that by the end of an 18 month or two year period, we'll have all of the major implementations using the same language.
And that's got to be a good thing, I would say.
I think Python 3 support for the various runtimes is actually probably more than a year off.
Frankly, I think most of them are going to catch up to Python 2.6.
And then they're going to say, okay, this is our checkpoint.
And then they're going to move over to Python 3.
And I don't see, hey, Michael, is the iron Python 2.6 now?
It's a release counter to this, as we've just been doing.
Yeah, the iron Python 2.6 is finally released.
Yeah.
So I mean, most of them are going to be targeting 2X for a while.
And I mean, Python 3, like I said, it's a very large monkey wrench for implementers and users.
So it's going to take the better part of the moratorium to get all of those, like,
they're going to have their 2.X syntax release.
Then they're going to have a new release.
They're Python 3 release.
And so we're looking at least a year and a half.
Oh, sure.
For them to bring the next topic, which is 2.7 end of life.
And what happens?
And certainly for I and Python for the dotnet framework.
And I also imagine for the Java guys, Python 3 is a lot better fit for those platforms.
Because those platforms are one of the big changes in Python 3 is that the strings are all unicode.
And those platforms, dotnet and Java, they're already using unicode strings underneath.
So they're going to actually be a lot easier for them to implement.
So it's kind of my last thoughts on the moratorium is that people need to realize this isn't the end of Python.
The fact is that I don't think any of us, Guido included, think that there's nothing else we want to add.
I mean, you always see clamoring for, you know, tilde recursion and this, that, the next thing.
And the fact is that we have to, we have to take into consideration everything we've already added.
Plus the things that are coming down the pike, the i.e. Python 3.
Before we can go and do these changes, we have to really ask ourselves, you know, does this change actually change what Python is versus just adding a future?
Yeah.
So it isn't a bad thing.
It's a breather.
It's technically, it's basically just Python dev taking a breather and reflecting on what we have done up to this point, especially with all the changes in the Python 3.
That have not widely been distributed to the community and just looking at and going, was this worth it?
Was this not?
And while we're taking a breather, allowing everyone to catch up behind, see Python's implementation and just meet us up the burning line.
While we're taking a breather, so we can all move forward as a entire community and do the language forward.
Because as Jesse said, this is definitely not a stop on Python.
It's just a breather.
We're going to keep going after we catch our breath and ready to move forward again.
In the PEP 2003 document, it says that 2.7 is expected to be the effective end of life of the Python 2 series code with 3.x releases being the future.
So what are the implications of this?
Well, I want to read one.
Yeah, what Jesse's implying is the way Python has currently developed is we are at the moment using subversion and we use SVN merge to merge changes between all the releases.
Now, what people need to keep in mind is since Python 3 came into existence, we essentially have four branches under development.
We have a stable branch for Python 2, which is currently 2.6.
We have trunk, which is 2.7.
We have what we call the Pi3K branch, which is Python 3.2 at the moment.
And then also stable in Python 3, which is Python 3.1, which means anytime there's a bug that actually is found that it affects all four versions that needs to be fixed in all four, which can include actually decimated tweaking if there's a, if it strutles a change between Python 2 and Python 3.
Which basically means bug fixes at the moment, at least for the developers can be rather time consuming and very annoying.
So no having to do that anymore will definitely be a good thing.
From a core developer's point of view, at least for my personal view, having the Python 2 series end at 2.7 meaning 2.7 becomes a maintenance release.
And we no longer have a trunk release author, they will cut us down to three branches and just make it that much more easier to do development.
So just to say that this isn't a done deal yet, the suggestion is that Python 2.7 is the last release of Python 2.
And the Python 2 then goes into maintenance and Python 3 becomes the main branch in all the future, all new features and further development happens on Python 3.
Well, I mean, frankly, I'd be surprised if it wasn't because for as long as I've had the commit bit, I think that's been like two years, two and a half years.
Ever since I got the bit cliff, I have been under the direct impression that 2.7 was going to be the end of life.
Yeah, unofficially, it's been 2.7 at the language summit at Python in 2009 this past year.
It was generally agreed upon by everyone in attendance that 2.7 is most likely or basically would be the end of life.
There has actually been, there was brief talk about having 2.6 actually be the end, although that looks like it's been kind of died.
I think all of the time it was.
You've gone through the pain of merging that code onto the 2.7 product.
Yeah, no, no, it's losing all that.
I mean, 2.7 is going to have a life of its own if nothing more is a bigger ramp into Python 3.
I mean, remember, there's a ton of hooks inside of Python 2.6 to get people so that they can be semi-compatible with Python 3.
2.7 is just going to ease that ramp even more, ease that transition.
So it's worth releasing it just for that fact.
That might have a bunch of multi-processing fixes that would be great to get in.
Python, on Python dev where there was some developers saying, why should I call my code to Python 3?
Because as far as I can sell, not very many people are using it and the libraries that I need, I haven't been fortunate yet.
Isn't that going to be a problem for all the people out there who are relying on it?
Well, of course, just because someone's relying on Python 2 doesn't mean that they have to move to 3.
I mean, as long as they don't want the new features of 3, then they can stay with Python 2 pretty much as long as they want.
I've never heard any suggestion that people will develop as well stop releasing bug fixes for Python 2 for at least another 2 years after it's released, I would have thought.
Part of this, though, is the concept that if you build it, they will come.
So if I were, and I actually have this quite frequently, if I'm approached by somebody and they say, hey listen, what should I use?
Python 2 or Python 3? I say, listen, install them both for your green field code, the stuff that doesn't have any external dependencies, try out Python 3.
For anything that actually depends on external modules, use Python 2.
Until those external modules pour over and we give them the assistance that they need and they start seeing that, hey, there's a lot more features in Python 3 than Python 2 that makes our lives easier as library maintainers.
I don't think we're going to get the critical mass that we need to push people into Python 3 or guide them rather.
Well, I think we do as a language, we do actually probably need to start doing some positive supportive people porting their code to 3 because I think we've got to get at some stage, we've got to get all the major libraries available in 3.
Yeah, and if Python 2 continues development forever, people will just keep going, oh, I don't really need to switch to 3, there's an X version of 2 I'll use.
So it's kind of a sticking carrot, right? We're going to release 2.7 more 95% I bet 2.7 is going to be the end of life for Python 2.
Yeah, we will have security fixes for at least five years. I suspect we will at least do point releases for year 2, probably at least.
But the point is is if we kept releasing, everyone will just keep seeing on 2. But if we end of life 2 and basically, okay, after this point, we're going to start working on the hope is people will go, oh, well, now I'll concert looking at 3 since 2 is no longer going forward.
They'll see the new features and actually realize how much benefit there is to actually switching and I'll hopefully get momentum going to get the library switch so that people actually start using in Python.
Not only that, of course, but literature and that kind of thing is going to become increasingly Python 3 oriented.
I'm writing a set of courses for a Riley at the moment and that's being done in Python 3 because these courses are supposed to have quite a long lifetime.
And if they have a long lifetime clearly, we want to be aiming at the right language.
And so this all kind of like you said before, this all dumb tails with the moratorium, I was actually joking, David Beasley was joking with me.
He's like, you know, if you want to see, you know, what effect all these changes that you're doing into the language and the interpreter, et cetera, are how they actually affect us as writers and developers.
He's like, you know, try writing a book against Python right now or writing a course is in your case, Steve.
Well, indeed, yeah, I mean, we took the decision when we had to decide what version of the language we're going to use and we decided to use 3 simply because it didn't make sense to do anything else. 3 clearly is the future.
I think that there's a huge overlap between version 2 and version 3, which should be helpful to people who have libraries of their own to port or who have code that they want to port.
But I think there's no doubt that in 18 months time, I'm going to be wanting to be using Python 3 and not primarily Python 2, even though Python 2.7 is going to remain a viable platform for long after that period.
Yeah, if any of the reason various Linux distributions have long life releases such as Ubuntu and Red Hat and applies enterprise Linux, those themselves will obviously lead to 2.7 or the Python 2 series lasting for quite a while.
So no one should think that the core developers are not least aware that people have real life code out there are going to have to support systems that continue to use too, but we do have to try to get the community moving forward so that we can start using 3.
And as Steve said, it's definitely is the future from a personal standpoint, coding in Python 3 is just so much nicer than Python 2 that I honestly much prefer using 3 over 2 and using whenever I can.
And I'm always happy for it.
Okay, see you soon. Thanks everybody.
This has been episode one of the little bit of Python podcast featuring Steve Holden, Brett Cannon, Michael Ford, Jesse Naller, and myself Andrew Kushling.
Our theme is Track 11 from the Headroom Project's album A.E.Fa, released on the Magnetune label.
Thank you for listening to Haftler Public Radio.
Thanks for your responses by Carol.net, so head on over to C-A-R-O dot A.E.C. for all of us here.
Thank you very much.