Files
hpr-knowledge-base/hpr_transcripts/hpr0679.txt
Lee Hanken 7c8efd2228 Initial commit: HPR Knowledge Base MCP Server
- 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>
2025-10-26 10:54:13 +00:00

123 lines
13 KiB
Plaintext

Episode: 679
Title: HPR0679: A Little Bit of Python: Episode 14 2010-06-06
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0679/hpr0679.mp3
Transcribed: 2025-10-08 00:47:05
---
.
Hello, you're listening to a little bit of Python episode 14. You can send us feedback, comments or suggestions on the email address all at bitofpython.com and you can find us on the web at bitofpython.com.
.
You're listening to a little bit of Python with Michael Ford. I'm sitting down in the sprint halls after Python 2010 in Atlanta.
One of the great advantages of coming to Python is you get to meet some of the very famous figures in the Python community and some very clever programmers.
And one of these characters who I've met a few times at various Pycons and Europe pythons now is Christian Tismah.
Now Christian Tismah has been in the Python community a lot longer than I have and has chiefed an enormous amount amongst other things.
He's the creator of Stackless and in recent years has been working on a new version of Psycho, the specializing compiler for speeding up C Python and very lucky to be able to talk to him. Hello, Christian.
Hello Michael. It has been quite a while in the Python community. I think it started in 1997 and at that time I had no idea what to contribute to a contribute website called the Starship.
That's on the Python.org website, isn't it?
It's a Python.net. It's now more a ghost ship. It was a good thing for people to try things out and play around.
But there are so many other sites which fulfill this role that it has lost its purpose.
I'm still maintaining it, but it's much more worth to maintain my first project, which is Stackless Python, which came in 1998.
Influenced by Sam Rushing, who told me something about continuations and complicated things and I thought I wanted to do that.
So the situations are the sort of thing that make ordinary programmers spin around wildly before they fall off, right?
Yeah, and they are actually not the best idea if you want to influence a language like Python.
You should go for a simpler construct and I did that later on and tossed the continuations as basic concept and went to something like Coraldeans.
Right, right. So Stackless is still quite wisely used, isn't it?
Yeah, it's used much more than I'm aware of. One thing I know very well is CCP Games, who have been using it from the beginning and have influenced it very much and they are still using it and build a huge website for the eve online game.
Right, I think I saw in the presentation that they very recently, they nearly got to 60,000 concurrent users.
Yeah, it's incredible. And it's all Python on their servers with Stackless Python.
Yeah, and it's made possible to have so many concurrent users because the technology is based upon Stackless, which can have very many open channels at the same time, which are all run in a single thread.
So Stackless is about doing multi parallelism within the same process without further.
Right, right. As a part of Stackless for quite a while, then over the time the support was taken over by the CCP people and other volunteers.
And I moved on to the Python project, which is about writing Python in itself.
We've heard a lot about Python, so I don't know how you got involved in what you think of the project.
We had the idea. We were three people in 2003 and started that ambitious project and tried to get specialists into it and we got them and we started it and we got funding from the European Union.
And the project went well to 2006. Then we estimated it should be creating revenues, which was not true because good things take a much longer time.
Right. I still believe in the project. I left it not on my own behalf, but I was spoiled by money.
I want me money to continue Armin Rigo's Psyco project.
Right. Now Psyco is a see extension that you can import.
And it adds a specializing compiler, a kind of jits to see Python and accelerates it, right?
Absolutely. So in a sense, I will ask later that Psyco is a mini Python or better to say Psyco is the super-duper large version of Armin's new due toy that replaces Psyco.
So part of Armin's motivation for being involved in Python was because Psyco was so hard to maintain.
And he wanted something that could achieve the same goals, but was a bit easier to maintain.
Yeah.
Because there was a lot of Psyco certainly didn't do and doesn't do. There's still no 64-bit support.
And it didn't support a lot of constructs of newer versions of Python. And that's where you came in, right?
Yeah. I was supposed to solve certain problems like supporting generators.
And we were thinking of 64-bit, which is pretty hard to do because the structure of Psyco is not really suited for that because Psyco is inherently 32-bit.
Right.
And at every place, it knows implicitly that everything is 30-bit and changing that means to rewrite half of the code and to make it aware of word sizes.
So that's a harder problem. Very easy to do probably for Python. People estimate something like the months for doing that.
Right.
And for Psyco, I think it's three months or half a year, I don't know.
When you started this, where you started on Psyco version 2 and you were successfully added support for generators and various other features in Python.
Yes. I made some progress. I worked actually two years on full time on that because there was a company that really wanted to have Psyco accelerating the financial software.
Psyco has ended by the end of last year and I was a bit without orientation. But now suddenly it happened that Cisepen digged in again.
Cisepen wants me to do a prototype of combining Psyco with Psyco.
So that would be the best of both worlds.
They need the stack of behavior and they are tempted by getting a code five times faster because that would be probably to have five times less service.
Right. Right.
And I guess being a game, they have a fair amount of numerical calculations, which is the sort of thing that Psyco is very good at speeding up.
Yes, they have a lot of calculations. Also, there is very much simply written in Python and getting rid of the interpreter overhead pays off very well.
So I hope to make a prototype during this sprint. So they can see it works and then they give me a contract and we work together.
I mean, you did a lot of work on Psyco version two and there's a public repository, but I understand you since then you have done more and there is there is new code available that we haven't seen yet.
Is that right? Can we expect a new push to the public repository of an updated version of Psyco?
Absolutely. My work over the last year is almost not published because that was it wasn't sure what to publish or not and it was for a company that now gave up on Psyco because they changed their strategies.
Yes, primarily they are going away from Python a bit. That's a shame?
Yes, well, there might have been some pressure, I don't know, but that means I can push a huge amount of new code in many new bugs.
So many people, once the new code goes in, you need people to try it out and report the problems.
But I guess you'll have a large code base to try it on at CCP.
Yes, there are a lot of things to test because many bugs don't show up with this standard library, but use in production code it gives some problems.
And I heard you might be looking at perhaps a new direction for the stackless project, a new way of doing stackless, is that right?
Yes, I actually wanted to motivate the CCP people to support that, but they are interested, but not so much because changing something that works is not so interesting.
I have a new concept that would be even more versatile than the current of stackless. I want to go away from patching the source code of Python.
So at the moment to use stackless, you modify the source code and then people have to use a basically a different Python runtime standard one.
Exactly, so it's not hard for somebody to use it, but the average user who wants to try a module doesn't like to exchange the kernel of his interpreter, especially Windows users.
And I always was a bit jealous on the greenlets, which are a spin-off and a tiny project which provide the basing switching capability, not everything of Python, of psycho, Schneiden, not everything of stackless, but kernel technology is there and that is an extension module.
It's a bit easier for many people to get into, even though it doesn't do as much as stackless does.
Yes, exactly. So I would like to do the same in stackless, but without losing any features, which is a little bit harder because psycho has the advantage, it does not need any changes to the kernel.
And that means it runs unmentained since 2002.
Yeah, stackless does a bit more, so it wants to know what kind of things it's switching, so it will be able to do garbage correction and...
Right, it's a bit more in Eastern and a bit more about the CPython internals, it's a bit more closely integrated.
But the internals will not be visible through patching of the source, I'm thinking of patching the executable runtime and inserting special code that treats certain locations in the interpreter differently.
So people wouldn't run a normal Python until they import stackless and then they get all the features of stackless available?
Yes, and they would get even more because when they have their own extension modules, they know how the extension modules are built.
They can build support for those by providing Python class that describes the extension module and how it has to be switched.
And that will be done on an interpretive level without having to code C.
Wow, great. So other C extensions will be able to take advantage of stackless more easily?
Yes, and I wouldn't have to do it by hand.
That sounds like a good reason.
So I guess it all depends on time and what projects you have, but do you have any idea of how long that might take to do or when it might happen?
Well, I call the ProDirect stackless light, although it's a bit of cheating.
I would say it might take three months or a half a year, but probably first comes in a 64-bit port of cycle.
Oh, so Sike might go 64-bit? There are a lot of people who would be very happy if that happens.
Yes, it would happen now. I'm not sure yet if it will become completely open source in the first place or if it should be held back, that's in negotiations.
I expect it will be open source. It is the thing that is most interesting for CZP games to have, so I have to do that first.
Well, it would certainly be a great thing for the Python community.
Whilst we're waiting for unlays and swallow to speed up Python, we can use psycho instead.
Yeah, well, there's one that's under Lanswallow and there's PyPy, both interesting projects where I have to say about unlayswallow.
It seems to be a wisely designed project because it does not make riskful undertakings like cycles and really cold.
It's improving, but it's nothing that you look at and say, wow, we're into great that in our source page.
You don't think cycles ready to be integrated into CPI from then?
No, nothing. Probably never, but it will improve, but it is a rather crazy project and it needs some rather crazy clients to really jump on the boat.
PyPy is still the thing I love the most and I'm supporting it and I want to convince everybody that even if you are using psycho, now you will in a few years, maybe one year, maybe three years, I have no idea which speed they will improve, but the idea behind the PyPy is correct.
It is a thing to do, but people always think it is too far away and they lean back and wait until it happens instead of investing money or something.
Well, the great thing was that this year we got to see some real world benchmarks with PyPy running substantial amounts of code, code sort of from typical applications and in several of those cases running faster than CPI,
even faster than unrelated and so on. So we're finally getting, I think the PyPy community is starting to get excited about it again.
I think quite a few years ago, the PyPy community was very excited and there was this long gap while the work went very slowly, but I think it's got to the point where people are seeing.
It's actually happening, it's actually starting to live up to the promises it's made.
Yeah, that's an interaction, like a gap where PyPy was trying to get things done that it expected to get fast already, but the just in time compiler was very hard to do right, I think they are now at the fifth version.
And that's it, that's shall be it, so I guess they expected it to be three years earlier.
Unlearned Swallow is a good thing, I think, because it's based upon known technology and use LVM to compile the code and it has no very ambitious speed, goal, but they are reachable, so it's something that can go in the standard.
And there's still enough improvement possible to make a difference for PyPy or Cycle.
Thank you very much, Christian, it's been great speaking to you.
It was a pleasure for me.
Thank you very much.
And we'll see you on next Euro Python.
Yes, Euro Python in Birmingham, in July, see you all later.
See you.
Thank you for listening to Hack Republic Radio.
HPR is sponsored by Carol.net, so head on over to C-A-R-O dot N-E-T for all of us in need.
Thank you very much.
Thank you.