On Dreamhost freaking out because they can’t get Rails deployed reliably.
A long overdue request for maintainers on two potentially important Python projects.
Ian compares Pylons and TurboGears and makes a few interesting general observations along the way.
A prediction piece on the possibility of a Ruby backed coup d'état on the JVM and what that might mean to the pragmatic web developer.
A brief history of the Kid templating language and an endorsement for the next generation of XML-based templating: Genshi.
lesscode.org goes live.
That is to say, they don’t get it. This started out as a simple rant and turned into a decent sized essay on basic shared-nothing architecture and scaling down.
“If you cannot think of 3 good reasons why dynamically typed programming languages have a role to play in this universe, you don’t want the job.”
And why we need more three-legged stools.
How complexity killed the best bug ever created in the whole world.
IronPython vs. JPython: who cares?
Template Inheritence, Match Templates (kind of like XSLT’s), cElementTree support, a refined Python API, documentation…
Wherein we avoid a Python vs. Ruby flamewar by changing the subject to Object vs. RDMS persistence.
I humbly retract my previous negative statements about IBM.
Just keep talking.
The web as currently imagined by the tech. industry is quite different from the web that actually exists.
On using the web to co-ordinate massive grass-roots efforts quickly.
Kid 0.5 announcement with a couple of page fulls of example usage.
What does Ruby on Rails have that we don’t and why?
Python’s attributes are not Java’s getters/setters and why that’s a good thing.
Why I prefer ElementTree to “standard” DOM APIs and why it’s sometimes better than libxml2.
Ross Burton builds the first real-world application using Kid Templates.
On changing from GPL to MIT, going after web-framework support, and simplifying as much as possible.
A comparison of Java’s static methods and Python’s class methods.
I miss Mark Pilgrim.
Trying to figure out a way of providing XSLT-like template matching in Kid.
Why not extend XSLT to be easier instead of building a new template language?
Tim seems to be working miracles over at Sun.
Applying a chain of Python generators to achieve transformation of the XML infoset.
This release is all about documentation.
How I decided to build Kid – the simple, pythonic, XML-based template language.
How to get syndicated in Python-oriented news communities.
A Python based weblog thing or something.
Wherein we predict that whoever decides to take dynamic languages seriously will win the interpreted bytecode market.
Danger’s my middle name.
How they’re different from mine.
There has to be a place for this in the standard library.
Why are they there?
I never would have imagined a language with so much power could be so easy to pick up.
Interesting concept. Layer the routing guts found in modern web frameworks over Linux’s FUSE userland filesystem stuff and you get a nice model for developing custom filesystems.
The small example (~30 LOC) shows how to build a simple GitHub filesystem, which gives you this:
opus:~ broder$ ./githubfs /mnt/githubfs
opus:~ broder$ ls /mnt/githubfs
opus:~ broder$ ls /mnt/githubfs/ebroder
anygit githubfs pyhesiodfs python-simplestar
auto-aklog ibtsocs python-github2 python-zephyr
bluechips libhesiod python-hesiod
debmarshal ponyexpress python-moira
debothena pyafs python-routefs
opus:~ broder$ ls /mnt/githubfs
ebroder
Pretty awesome.
Python version of Docco, the quick-and-dirty, hundred-line-long, literate-programming-style documentation generator:
8888888b.
888 Y88b
888 888
888 d88P .d88b. .d8888b .d8888b .d88b.
8888888P" d88""88b d88P" d88P" d88""88b
888 888 888 888 888 888 888
888 Y88..88P Y88b. Y88b. Y88..88P
888 "Y88P" "Y8888P "Y8888P "Y88P"
All together, we have Docco, Rocco, shocco, and now Pocco. Jeremy observes, “It’s a whole little adorable family of midget programs now…”
Eric Florenzano asks why modern web frameworks insist on a synchronous programming model and gives some answers with possible alternatives. The article is dead on, IMO, but I’m not sold on his conclusion:
We need to look at these alternative implementations like coroutines and lightweight processes, so that we can make asynchronous programming as easy as synchronous programming.
For Ruby, this is all about making Fiber robust and widely available. There was a time when I too thought this would solve all problems by hiding the underlying async model but retaining its benefits. That’s the dream. I don’t believe in it anymore. Having experimented with such an approach on a small team, I’m fairly confident that everybody working on an event-based/async program needs to understand the underlying model or blocking code will inevitably be introduced and destroy everything. And once everyone’s comfy with async, you’ll find that the sync façade is annoying and unhelpful. Embrace it.
Shame:
Our initial goal for Unladen Swallow was a 5x performance improvement over CPython 2.6. We did not hit that, nor to put it bluntly, even come close. Why did the project not hit that goal, and can an LLVM-based JIT ever hit that goal?
Here’s the performance comparison itself. Most gains were under 1.5x and memory usage grew significantly in every benchmark. Startup time also suffered.
As mentioned in the Performance Retrospective, they had to divert a lot of energy from performance work to fixing LLVM bugs and axe grinding on debugging/profiling tools. I have my fingers crossed that they can pull off the 5x gains in the next round. Let’s hope so, I’d demand at least that much to justify this:
In order to use LLVM, Unladen Swallow has introduced C++ into the core CPython tree and build process.
Slipperyest of slopes.
Jacob Kaplan-Moss:
It’s really tempting to use an auto-documentation tool like Javadoc or RDoc for reference material.
Don’t.
Auto-generated documentation is almost worthless. At best it’s a slightly improved version of simply browsing through the source, but most of the time it’s easier just to read the source than to navigate the bullshit that these autodoc tools produce. About the only thing auto-generated documentation is good for is filling printed pages when contracts dictate delivery of a certain number of pages of documentation. I feel a particularly deep form of rage every time I click on a “documentation” link and see auto-generated documentation.
Hate that shit.
You know what I want? Man pages. For everything. Wouldn’t it be cool if you didn’t have to write roff?
Simon Willison on using Redis with the Python REPL to get complex shit done quick. Insightful piece, as always.
Jeremy Zawodny takes a look at the * is Unix thing and throws in some additional goodness: more on fork(2), the benefits of copy-on-write, and atomic file operations.
Jacob Kaplan-Moss does the prefork echo server example from my Unicorn is Unix piece in Python. Awesome. Let’s see some more of these. Where you at, Perl?
Dustin Sallings proofs out an implementation of the recently released Tornado web framework but builds on top of Twisted. The result is -1,297 fewer lines and all the benefits of having the Twisted framework underneath. I’ve been waiting for someone from the Ruby community to announce a port — we’re good at stealing. Using Dustin’s fork as a reference and basing a Ruby implementation on EventMachine might be the way to go.
Ian Bicking’s talk from DjangoCon 2009. Stimulating. I’m sure a nice comment thread will develop here over the next few days as well.
Jacob Kaplan-Moss somehow pulls a bunch of interesting contemporary web development issues into a coherent essay. This bit on what happens when web apps begin to mature is especially well stated:
This is an impossible situation for framework developers: by optimizing for a quick start, by focusing on common needs, we’re essentially guaranteeing future failure. Remember the “Rails doesn’t scale” pseudo-controversy last year? I guarantee it’s only a matter of time until there’s an angry “Django FAIL” moment.
Frameworks ought to gracefully fade away as you replace them, bit by bit, with domain-specific code. (This is what I meant, above, that inter-op is also a scaling issue.) Right now, they don’t.
I wish more people would write about their experiences growing out of the general purpose web framework. It’s a totally natural thing but most people seem hesitant to talk about it because it’s interpreted as an attack on the framework or community.
This seems to be a trend in Python and Ruby web circles. Frameworks present developers with a choice: accept these constraints, give up a little control, and I’ll make you more productive. Longer-lived apps start to evolve out of the framework at some point, though. You need more control over a piece here, or aren’t satisfied with the way something works there, and so you refactor and pull stuff out until the framework begins to slowly fade away. Maturity is a part of the web app development lifecycle we have precious little data on.
This comment nails it:
Maybe it worked out exactly like it should have. Django bootstrapped your app to a certain point. Got you further faster than you would have if you implemented everything from scratch. Then from there, you identified the things you considered inadequate and replaced them. If it all goes away who cares. You have learned something, shared it with us and moved on.
I think that’s just fine. Unexpected maybe, but fine.
Simon Willison is working on python web microframework based on Django. This will get interesting. Fast.
“Almost all non-functional programmers are unaware that tail calls facilitate a programming paradigm that they have never seen. The ability to tail call to functions that are not statically known is the foundation that makes many combinators useful. This is a style of programming where functions are composed in order to create a pipeline for values to flow through. Without tail call elimination, every stage in the pipeline would leak stack space and the whole approach becomes unusably unreliable.”
It’s important to understand how fork(2), pipe(2), and exec(2) work. I don’t want to hear anymore of this “fork is a hack” shit from any of you :)
Geoffrey Grosenbach interviewed me yesterday for the Ruby on Rails podcast. We had a nice chat about Python/WSGI, Rack, Sinatra, Rack::Cache, Heroku, and other random stuff.
Guyon Morée shows how JavaScript 1.7/1.8 have been moving more and more toward Python with a few side-by-side examples. List comprehensions and generators would definitely be extremely cool to have in browser land.
Ian Bicking explains the connection between modern traffic planning and modern programming in dynamic languages.
Nice look at caching idioms in Django and why you need to generate HTTP cache validators up-front and efficiently.
Aristotle Pagaltzis on eating PHP’s lunch: “It will have to be more than just a programming language, because PHP itself is really more than a programming language. It includes a crude web framework (an invocation model reminiscent of CGI, with extensions) plus a crude deployment solution (just make all the libraries part of the language and let the sysadmin worry about it – who in turn often defers to his operating system vendor). This is PHP’s way of taking the worse-is-better philosophy to dazzling new depths …”
I was having this conversation at work the other day and came away with the conclusion that even if something were to reach feature / ease of use parity with PHP today, it would be many years before it actually surpassed the language in real deployments. PHP is everywhere.
All frameworks should approach caching the way Django does. The core app/origin framework does no real caching but provides utility/helper methods for setting standard RFC 2616 cache related headers on the response easily and correctly. A completely separate set of caching goo (“middleware”) sits between your app and performs the actual caching based purely on the headers set by the origin. The benefit to this approach is that caching is totally independent from the app framework and can be swapped out for a true gateway (“reverse proxy”) cache at any time.
Awesome idea. Nice syntax highlighting. (Via Simon Willison)
Good idea. Solve the “concurrency problem” for dynamic/scripting languages and the “language syntax problem” for Erlang, without sacrificing the benefits of either. Someone needs to keep an eye on this.
Sometimes! Or, fork(2) is a very fast operation on legitimate operating systems. I didn’t realize it could be as fast as spawning a thread, though.
Stephen O'Grady with the obligatory Q&A, which is excellent as always.
The Python REPL running on Google’s infrastructure.
Ian Bicking: “Many people are excited about how far up you might be able to scale something based on App Engine, but I’m excited about how far it could be scaled down.”
I’ve since went to sleep and reawakened. I’m typically fairly curmudgeony when I wake up but I’m still having the same reaction.
Christmas in Python land! Run Python/WSGI code on Google’s infrastructure. This is an incredibly H U G E win for the Python web community and further validates WSGI’s architectural awesomeness.
Matt Chisholm evaluates Ruby against Python for an upcoming project and determines that it’s a big pile of doodoo. I can’t agree with the conclusion but he details a lot of Ruby’s warts really quite well.
This was a really great lesscode.org piece by Aristotle. The follow-up discussion in the comments was superb as well. Being in the middle of everything really warped my view of what was going on back then, I think.
David Heinemeier Hansson: “PHP scales down like no other package for the web and it deserves more credit for tackling that scope.”
Agreed!
reddit.com is running Pylons-0.9.6, Paste-1.4.2, Routes-1.7, Beaker-0.7.5 on FreeBSD 6.2-RELEASE (amd64). Wow. Nice environment.
“Between 1988 and 1991 I worked on the research program that led to the Mars Pathfinder rover […] All three of [the prototypes] were programmed not in Lisp, but in little mini-languages whose compilers were written in Lisp.”
Simon Willison’s latest project makes it easy for people developing in Django to hook up and get laid (since they have so much free-time due to developing in Django).
Bob Ippolito wrote up some pros and cons to reverse proxy implementations in different servers a few months back. I don’t think much of it is out of date at this point but nginx isn’t represented.
Ian takes a look at some of the attributes of PHP’s deployment model, why they work so well (for PHP), and why other environments have such a hard time duplicating them.
“The constraints, the instability, and the unpredictability of a shared hosting environment are a big part of the reason why the web hosting business is moving towards virtualization everywhere you look. Big kids need their own sandboxes to play in.”
“Whitespace?”
“After careful considering, much soul-searching, gnashing of teeth and rending of garments, it has been decided to reject this PEP.”
“Talking about a software development schedule more than a year out is like talking about where we go after we die. Everyone has some idea where we’ll end up, but those ideas differ wildly, and there’s a lack of solid evidence to support any of them.”
Thomas Wouters covers a ton of ground (quickly) on lots of Python’s interesting features. This may be the quickest way for newbies (or refugees) to come up to speed with the language.
Aww man, Joe’s real project list looks like my wish-i-was-hacking-on list.
“Web designer” is dead on :)
“The general thrust of this argument is that having a full-fledge rich-windowing experience in the browser is going to put a stop to all that amateurish mucking around with JavaScript and the DOM. … that’s hogwash.”
“In the remaining four templates, the translation from XSLT to Genshi markup is straightforward. And generally, the Genshi markup is both more compact and more powerful.”
Wow. Pretty solid anti dynamic language advocacy piece. It’s been a while since I’ve written anything longish so maybe I’ll try to put together something of response to this.
“also it could be disguised as a cancer research stuff should some disassamble its code. the use-free-computer-time type of thing they do on the net.”
Ranks programmers by who they consider themselves superior to. Comedy.
Wherein the author lists 8 reasons (maybe 3 of which are approaching objective or even valid) and also spells Adrian’s name wrong: “Adrian Zolovaty”. Ruby/Python flame-bait is exactly what we need.
This guy gets around…
I have no idea … but I’m digging the Kid and TG references ;)
But instead of ducking grues and collecting zorkmids, you’re interacting with whatever program code you’re working on, as well as the data and hardware devices that it uses. “It treats the web and APIs as just more objects and places, and is a platform fo
the best shit ever
All roads lead to Lisp…. eventually… we think. :)
Really cool to see TG and Kid getting some press on O'Reilly
Best Lambda Thread. Ever.
Let’s build an open / distributed build network.
Joel Pobar to dive deep into dynamic language support on Microsoft’s CLR..
Joe Gregorio throws together a RESTful web service for generating sparklines.
Nice python-list thread with Paul Rubin challenging my ibm-poop-heads article and Andrew Dalke (and quite a few others) champions it. This discussion is worth more than the original article!
Second part of what looks to be a really kick ass presentation by the BDFL.
Can’t wait to listen to this. Guido talks about how the Python community has grown over the years.
This is mostly true in my experience. It’s too bad we had to pick on some nice Python projects to make the point but true is true.
Damn if I haven’t started writing this post 10 times and stopped because I couldn’t get the point out. Well said, Bill.
We really need this, IMO. I’ve noticed that a lot of Ruby libraries use anonymous blocks for resource management like this and it’s hard to argue that its inferior to the try/except model.
That’s what I’m saying bro..
A Spotlight Plugin that imports and indexes Python source code. w00t!
“Just remember that the next time you use one of the mainstream languages – many of the "features” were designed with the idea in mind that you, the developer, are a moron."
Patrick Logan calls bullshit on a BUILDER.COM article on “scripting languages”… Quick list dynamic language misconceptions: inelegant, fragile, unprofessional, only used by monkeys..
Weird game that uses facets of the web as pieces of riddles. Kind of spooky.
How cool is this?
and under a GPL compatible license.
Everything I ever wanted to say about the current state of software development in ~50 slides. Thanks, Sam.
That’s because they don’t have shithead analyst speculation driving feature development…
Jim Hugunin announces Microsoft’s first official release of IronPython. Let’s be absolutely clear: Microsoft just released a respected free software project.
Best c.l.p thread ever: irritating whitespace-based indentation gone, death of for loop, all strings are regular expressions, and WE FINALLYY GET BRACES! (via Hans Nowak)
Very organized and thorough notes from PyCon.
Here they come…
This one is kind of weird but it shows another kick ass capability dynamic languages have: changing and object instance’s class (behavior) at runtime.
Pretty reusable implementation of the Chain Of Responsibility pattern in Python. Very clean.
Looks like this let’s you use iTMS like normal but the files are stripped of DRM on the way down or something. And it’s written in python.
More dynamic language play on the Java front.
Tim Bray on the dynamic language push at Sun.
Bill de hÓra describes the major flaw in high level languages like Python..
An implementation of John Gruber’s markdown text to XHTML processor in Python.
David Hansson (of Ruby on Rails fame) on why codeless template languages don’t work.
Ahhh, shucks..
Bill de hÓra challenges some of the points I made in Getters/Setters/Fuxors. Specifically, the getter/setter bloat and IDE comparisons. Some good points here.
Well written line-of-though writeup on the decision process leading up to a language selection when the sky is blue and you’re building a new app. Hint: Python :)
excellent list of python Idioms
that’s sick. sick! did you notice he even squeezed a CC license in there?
Elliotte Rusty Harold announces Kid to the masses. thanks!
Udell talk on Python from Summer 2004. He talks about python running on JVM/CLR/Mono towards the end.
Nice intro to Python HTML-based slides. This covers a ton of info in a very small space.
Oh Tim, how I love thee. Let me count the ways..
Nope.
A complete comparison..
Fredrik Lundh with a super simple technique for incremental parsing with ElementTree. There’s a few limitations but this is probably all that is needed in large portion of cases.
Leslie Orchard with some thoughts on Kid. I’ll have to get a post out on exactly what I’m looking to steal from XSLT.
I’ve noticed that too. Concepts aren’t portable between the two languages somehow.
Paul Prescod rebuttal to Paul Graham on the Python/Lisp connection. Good stuff…
Generator expressions, simpler string substitution, built-in set Objects, function decorators, subprocess module, and much more…
This seems to be a bit cleaner and more functional than the standard python unittest module.
I think I’m going to give ZODB a try with my blogging system.
Python based guitar tab editor/viewer.
From late 2000, promises of continuations and other niceties. Will probably never make it into Python core though since there’s JVM and CLR Python implementations to worry about now..
Can be run in-process or client/server. Whole database stays in memory. Could be super useful in some situations.
Some good ideas here. Would have been nice to fold some of the classes into a module..
Hey! I wrote that..
where tf did this come from?
“I prefer (all things being equal) regularity/orthogonality and logical syntax/semantics in a language because there is less to have to remember. (Of course I know all things are NEVER really equal!)”
Beware! Danger lies ahead…
Cookbook area of the Quixote Wiki. Lots o' topic specific howto’s.
Condensed version of everything you need to know about using Quixote. (From PYCON 2004).
Some code and theory on developing RESTish stuff under Quixote.
Python web framework that rocks.
List of built in functions (i.e. non-module) in Python.
A wiki…. About mod_python..
Nice article on how mod_python integrates with apache. Goes into significant detail on non-CGI type stuff you might want to do.
XML.com: Dealing with tagsoup HTML in Python.
Congrats Mark!
An honest and objective comparison of Ruby and Python.
Uche Ogbuji. Compiles schematron schema to python.
“..provides a mountable Linux filesystem which uses your Gmail account as its storage medium.” – Maybe I will be able to put these 7 Gmail invites to good use after all.
This is more documentation than I’ve ever seen on super.
:)
OMFG Python is reaching critical mass.
Ted Leung explores recent developments that seem to suggest that both Sun and Microsoft might be thinking about hijacking Python. If Jython and IronPython grow large followings, the library support has split three ways: Standard Python Libraries, Java Lib
Wish more people would get behind Paul on this one.
Frequently asked questions on the Python programming language. I didn’t see “Why does Python rock so hard?”
80% of what you need to find when coding in Python.
More Python love from Mr. Paul Graham.
Bill points out the inevitability of the Pythonification of the world.
Python script to convert iTunes xml database to rhythmbox xml database.
On entity substitution and whatnot..
Most articles beginning with “occasionally I still discover some obscure feature of Python that displays surprising behavior” are usually worth reading.
Pythonic interface to the del.icio.us REST APIs.
will buy..
Good detail on Python’s new style classes..
ALICE for python
Guido, getopt
Hmm..
A first class path object for Python.