Ev, you're being ideological and presumptive. You're placing stylistic concerns (XML, Zope) above practicality. All of the core Pylons, TurboGears, and BFG developers, and Ian Bicking -- have been working on this project jointly for two years. It was called "Pypefitters/Pipefitters", "Pypes", "Marco", and "Pylons 2" at various stages. The developers all agreed it's a quantum leap ahead in terms of improving Pylons' modularity and abilities, and in unifying the Python-WSGI landscape. And we're keeping all those ugly XMLisms and nasty Zopeisms away from application writers.
No previous framework has provided built-in primitives for all the programming styles that have emerged among the various post-2005 frameworks (traversal vs URL dispatch, "return render" vs decorators, class-based controllers vs a tiny function-based app that can fit in one module, etc). That was the original goal of Pypes. Pyramid's multiple modes allow almost any Python-WSGI framework to be built on top of it, which could provide a new level of unification among frameworks. The component architecture allows applications and the framework to be extensible in ways that weren't previously possible. Can you at least accept the possibility that *maybe* all these developers know something you don't, and that if they feel so strongly about Pyramid, there must be something good about it? I can't explain the advantages as well as Ben or ChrisM so I'm not going to try. But they are trying to explain it, and they'll get better at it over time. Can you attend PyCon next March in Atlanta? Then we can discuss the advantages and disadvantages of Pyramid in person with all the developers together. There will surely be Pyramid open spaces and a sprint, and we can even have some kind of "Is Pyramid good or bad for Pylons?" open space if there's enough interest. Again, your concerns are the same ones the Pylons developers raised with ChrisM two years ago. "Ewww, XML! Zope = bloat." But after thinking about the impacts of a component architecture -- and how they'd otherwise make Pylons enhancements without it -- the developers became convinced that it was a good thing, even if it meant admitting ZCML and Interfaces. A component architecture (ZCA) provides a standard way to extend anything via plugins. Without it, Paste had to use entry points, and Buffet (a templating front-end used in Pylons 0.9.6-0.9.7) had to write its own thing from scratch (and it sucked), and Repoze.who/what had to manage its plugins on its own -- all three doing it a different way and reinventing the wheel. With ZCA, all these can be configured the same way, and parts of the framework (like Routes and Beaker and the thing that calls the controller action) can also be configured that way, and new extensions can be added to Pylons the same way, etc. Zope makes it easier for Ben to write enhancements he'd wanted to do anyway, like to make Pylons applications more nestable inside other Pylons applications -- something that Pylons should do better but the current architecture gets in the way. On Sat, Nov 6, 2010 at 7:00 PM, Ev Kontsevoy <[email protected]> wrote: > Ben, > > Pyramid brings a strong "java odor" in the form of XML-based config. > Why? Put views in views directory, models go to models and handlers to > handlers. Why infect our world with XML? And even if someone needs to > be verbose - use Python for it, its nicer! XML has no place in the > world of dynamic languages, its not "declarative" vs "imperative", > it's "dumb" vs "normal". XML is a tool. It's ugly but it can do some things better than other tools. I'm sure it's possible to create a YAML-based or Python-based alternative to ZCML, because it all has to be converted to Python objects in the end. But somebody would have to take that on as a project. Anyway, Pylons-style Pyramid applications are configured imperatively (in Python modules). If there is any ZCML at all, it's at a low level inside the framework, not anything you'll see. > Look, people had reasons to pick Pylons over Repoze. We don't like > anything Zope, we don't like Repoze and we certainly can't stand XML. > Now you've renamed Repoze to Pyramid and offering us to upgrade or > shut up. Or continue to use Pylons 1. Or fork it if you want to make a different kind of Pylons 2. Pylons is not "dead", it just won't be changing except for bugfixes and maybe backports. And that's good for the subset of users who want long-term stability above anything else. > I am not seeing anything pragmatically beneficial there compared to Pylons 1.0 There are other concerns besides user-visible features. Developer convenience, maintainability, and the ability to give you shiny new features in the future are also factors. One immediate feature is a built-in auth system, which is (reportedly) easier to configure than Repoze.who/what. > The only area where Pylons needed help, where it was ages behind > Rails, was FormFill/Encode. It was by far the biggest blemish on > otherwise neat package for building web applications with Python. The only area where Pylons needed help... FOR YOU. Other people have different needs, such as making Pylons apps more nestable, getting away from the magic globals, making apps more plugin-friendly. switching out parts of the framework for alternative APIs, etc. > Pyramid does not address this at all. Its just a bunch of class/method > renames without obvious pragmatic benefit. There will be application templates configured for several form libraries. They may be in Pyramid or Shabti or in their own packages. Pyramid is just going a little lower level in this area, because not everybody liked the mandatory FormEncode/WebHelpers dependency -- including you it sounds like. > I know that XML is optional. But why? Why is even there? One could > have killed Pylons and said "look, pyramid has a built-in MP3 player!" A component architecture is not like an MP3 player. It's like replacing a 386 chip with a 686. ZCML is just the format that came with the architecture -- sorry, but it has been the format for 12+ years. > Excuse me gentlemen, but have you looked at > Rails-3? Seriously, have you SEEN what can be done with concise > routing syntax and naming configuration? I personally haven't looked at Rails. Could you make a list of Rails-3 features that would benefit Pyramid, and file a bug report? It doesn't help it one bit > that XML is optional. Pylons wasn't about being a kitchen sink of a > framework - it was about being small and lightweight. Pylons is about modularity and choice. Paste is the ultimate modular foundation, and it needed a full-sized framework in the same spirit -- Pylons filled that role. That's what originally attracted me to Pylons: it was written from the ground up based on the then-new Paste and WSGI principles. Modularity => interoperability, the opposite of vendor lock-in that previous frameworks had. The BFG architecture allows Pylons to be a quantum leap more modular than it was before, allowing Pylons to realize its original vision even further. If BFG had existed in 2005 in its current form, there's a good chance that Ben and James (Gardner) would have based Pylons on it from the beginning. Especially if they had foreseen the dead-end features Pylons made in 0.95 and 0.96, which it then had to backtrack from. > Web framework in 2010 is supposed to do this: > > resources("cars") # <--- see there? that one line was supposed to give > me /cars and /car/id for GET, PUT, UPDATE and DELETE requests, > complete with views and default controller actions. Routes already has this: ``map.resource("cars", "car")``. Ben is currently adding all Routes features to Pyramid. He says that this gives the chance to greatly simplify (shrink) the code, and to refactor its internal structure based on the long-planned "Routes 2" branch. So there will probably be some kind of ``config.add_resource_hander`` method for this. Also, Routes recently added a submapper feature, so you can define routes with common attributes in a "with" stanza, or add a group of sub-URLs in one step (e.g., to drop in a generic package like a blog engine). This has promise to simplify route maps, and could have made past usages easier. So there's a strong inclination to reorient Pyramid's routing in this way, and that may lead to a new way to manage resource routes. > Another thing web frameworks are supposed to do in 2010 is to define > an HTML form which DOES NOT need to be parsed on the server and pre- > populated with dictionaries of values to display a validation error. I think this means, "Pylons/Pyramid should have a client-side Javascript validator." This can be implemented with an add-on package or enhanced application template. It would be a good job for TurboGears. But there should not be one blessed Javascript library as a mandatory dependency. We made that mistake in WebHelpers before. The state of the art in Javascript libraries changes every six months, and one library is better for some applications, and another library for other applications. Enhancements like these need to be made in separate packages so that several implementations can be evaluated side by side. Then later, if one is far superior to the others and is useful enough to justify making it a mandatory dependency (meaning those who don't use it would have to carry it around), Pyramid can add it. > Also, a new web framework in 2010 should not be re-inventing Request > and Response objects. What was wrong with Paste?! In 2 years reading > Pylons-Discuss I have never once (!) seen any complaints about WebOb. > Why is Pyramid brings yet another variant of response/request?!? Pyramid has trivial subclasses of webob.Request/Response, just like Pylons does or did. to add a few attributes or for backward compatibility with older request objects. > I guess you will use that [missing Rails-3 features] as an excuse to throw > away > Pyramid and launch Pyramid-2 based on something entirely different 2 > years down the road. The state of the art always changes. Who can predict what will be a best-practice in two years? Or what new paradigms or tools will emerge. Maybe Pyramid can just add a couple features, or maybe it'll need restructuring, or maybe it can be done on top of Pyramid without affecting the base code. > Also, if "stacked proxy globals" were such a big problem, why still > have them? When I saw "configurator.start()" I immediately could smell > something fishy. Just the fact that you have "doer" classes ending > with "or" and having methods like "start" and "stop" tells a lot. This > may not be that bad, but not SPECTACULAR, and spectacular is what you > needed to justify killing of Pylons. Pylons was __amazing__, it just > needed a better form handling package. I don't like them either. It's a deprecated backward-compatibility feature for old BFG apps, as it says clearly in the manual. But it's not worth rejecting the codebase over one minor flaw. ChrisM, can we just delete the threadlocal code now? Pyramid is a new framework; it doesn't have to support all the old misfeatures in BFG's history. Like Python 2 -> 3, and Pylons 0.9.7 -> 1.0. I also was turned off by the threadlocals: it's something we wanted to get away from in Pylons 2. It's not the "start" and "stop" methods that's the problem, but the fact that users don't know how much overhead the threadlocal code is causing in terms of CPU cycles or lines of code (for space-constrained deployments like embedded systems and GAE). Even if it's isolated in an unused module, it feels like the kind of cruft we're trying to leave behind in Pylons 2. On the other hand, some applications need thread locals for their own purposes; e.g., for database connections. So if it can be implemented and/or documented as a general thread local mechanism, rather than as singleton/magic variables, that would deflect these criticisms. By the way, Pylons users also need an upgrade path for 'app_globals'. > I suspect quite a few Pylons folks will be unhappy. There will always be somebody dissatisfied no matter what we do. > We already saw (!) > Repoze when we were picking our framework. And we didn't like it. We > preferred Pylons. See, we already voted! You saw Repoze before choosing Pylons. Repoze didn't exist when I chose Pylons. (Or at least, BFG wasn't mature enough to be even known to most WSGI users and developers.) I agree that we chose Pylons because it didn't have XML or decorators. But now the time has come to revisit that opposition, to see if maybe a small amount of them is acceptable for the sake of a greater good. By the way, you can write view methods without decorators or dict return values: from ??? import render, render_template_to_response c = self.request.tmpl_context # Or something like that c.myvariable = "myvalue" return Response(render("/index.mako")) # - OR - return render_template_to_response("/index.mako") I don't remember the exact syntax of the render functions, but it's similar to that. The Pyramid docs recommend the decorators and dict return values for most users, because we think it's a better way going forward (and that TurboGears was right about that), but you can do it in a more Pylons-like way as above if you want. This will be mentioned in the final manual and howtos. -- Mike Orr <[email protected]> -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
