Skip to main content

PyCon: State of Pylons/TurboGears 2/repoze.bfg

State of Pylons/TurboGears 2/repoze.bfg

There are about 2000 people on the Pylons mailing list.

Ben Bangert said that Pylons relies too heavily on subclassing. When people subclass and override stuff in a framework's parent class, it makes it difficult to alter the parent class without breaking people's code.

Side note: The new Pyramid T-shirt is beautifully done, but evil aliens (or anything else for that matter) are a big turn off for me.

Pylons is big, but Ben said that too much of Pylons is dependent on him.

Pylons is merging with repoze.bfg. It's going to be called "The Pylons Project", but it's based on the code in repoze.bfg.

Chris McDonough wrote repoze.bfg. It's a great, but relatively unknown framework. Pylons has better name recognition.

TurboGears 2 is built on Pylons.

The new framework is called Pyramid and is part of "The Pylons Project".

TurboGears 2 and Pylons are going to be maintained together so as not to strand a bunch of legacy projects.

Side note: There were a lot of big beards at this PyCon. Big beards have always been popular among hackers, but it's even more popular right now. I wonder if this has anything to do with the Giants pitching staff and with the Giants winning the World Series.

TurboGears will experiment and innovate on top of Pyramid in the same way it used to experiment and innovate on top of Pylons.

repoze.bfg has a catchphrase: "Plumbing Zope 2 into the WSGI pipeline." It actually doesn't take any code from Zope, but it does borrow some ideas.

There are about 200 people on the repoze.bfg mailing list. It has 100% statement coverage. 100% of the code is documented--if a feature isn't documented, then it doesn't exist. There are 80 committers to the repoze.bfg project!

Pyramid is just repoze.bfg renamed.

There is a Paster template for Pyramid--multiple actually.

These are the features in repoze.bfg: it maps URLs to code; it has an authentication framework; it supports I18N; it supports single file applications as well as larger projects; it makes use of PasteDeploy; it has unit, functional, and integration testing; it uses WSGI; it has great docs; it supports multiple templating engines; it supports Google App Engine; it has plugins; it can serve static files; it has sessions; it has cross site request forgery (CSRF) protection; it supports events; it has good exceptions handling; it supports WSGI middleware; it's extremely fast; it has 100% statement coverage.

One reason that it is so fast is that a lot of work is done at startup so that less work needs to be done at runtime.

It is not a full-stack framework. It has no persistence layer.

It currently has 16 dependencies, but single file applications are still possible.

It is "unopinionated".

Chris (the repoze.bfg guy) said, "I'm a Django fan. I love Django." Obviously, he doesn't think Django is appropriate for all situations.

Pyramid != Zope. It's not Pylons. It's not MVC. Chris hates that term.

Flask may be more appropriate for small projects. Pyramid may be a better fit for larger applications.

Pyramid exposes plug points all over the place.

Pyramid supports row-level security.

There's a Pyramid OpenID library.

They use Lettuce together with a web driver. It can work without Selenium.

WebTest from Ian Bicking looks interesting.

The next version of Pyramid will target Python3.

Paste is in a state of flux, but it's too important to be abandoned.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p