pyramids and pylons
Kevin J. Smith
chrism
http://docs.pylonshq.com/#faq for the general FAQ. There should be an
announcement up very soon. It probably won't have much more info than
that has.
For the fear of no-controllers, see:
- http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-gets-its-terminology-wrong-mvc
- http://docs.pylonshq.com/pyramid/dev/narr/handlers.html
"Handlers" == Pylons 1.X controllers.
For the fear of Zope, please see:
- http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-encourages-use-of-zcml
- http://docs.pylonshq.com/pyramid/dev/designdefense.html#pyramid-uses-a-zope-component-architecture-zca-registry
If you spend some time reading the docs you'll see that it using the
framework as an end user really has nothing at all to do with Zope.
William Chambers
I will probably over generalize and water down things, and may be
plain wrong but it should help give you some idea anyways.
pyramid is basically a renamed repoze.bfg, which was a framework made
by the zope folks in an attempt to take useful things from zope and
make them easier to use. I'd say they've done a wonderful job, since
as of about 3 months ago I've converted over all my projects to
repoze.bfg and now pyramid.
Pyramid is basically the future of pylons afaik. But there 'are'
controllers, they're just not named such. The current wording is
"handlers", which are basically the same as controllers.
Hope that helps!
William Chambers
Mike Orr
The Pylons 2 codebase has been going in a BFG-ish direction for
several months (search pylons-discuss and pylons-devel for "marco" and
"bfg"). Pyramid is just a new name for it. It hasn't been announced
yet so your surprise is understandable.
Basically, the Pylons and BFG developers decided to merge their
codebases into one framework. So Pyramid is a fork of BFG with all the
Pylons 2 stuff merged in (and Routes too). The name "Pylons" has grown
from being a single framework to a developer community that maintains
three frameworks: Pylons 1, BFG 1.3, and Pyramid. TurboGears is
considering joining the merger but has not yet committed to it. It
depends on whether they decide to rebase TG on Pyramid or stick with
Pylons 1.
Pyramid supports multiple API styles. Configuration can be imperative
(Pylons-style: instantiating objects and calling methods) or
declarative (BFG-stye: an XML-based configuration file). Routing can
be transversal (a la TurboGears) or URL dispatch (Routes-style). The
Pyramid manual is forked from the BFG book, but it's being geared
toward the Pylons style, so imperative and with URL dispatch.
Pyramid has a different MVC vocabulary. The model is the model, but
the view is the callable that processes the request, so the equivalent
of a Pylons action method. A "view handler" is a class containing view
methods, so the equivalent of a controller. This was just documented
today, so read the chapter on "View Handlers". Some of the chapters
in the manual refer to Pyramid's other modes, so they're irrelevant to
a Pylons-style application. I'm making a howto to explain the relevant
parts.
There are some changes in the syntax. Routes configuration changes to
``config.add_hander()`` or ``config.add_route()``. A view method looks
like this:
class MyViewHandler(object):
def __init__(self, request):
self.request = request
@action(renderer="/index.mako")
def my_view(self):
return {"var1": "value 1"}
This, obviously, is TurboGears-ish, but not exactly the same. You can
mount a Pylons 1 application as a URL overlay, so that you can upgrade
it one page at a time, or add new pages but keep the old pages as-is.
Only a small part of Zope is coming in: the component architecture and
interfaces. Application developers don't need to worry about that,
it's all preconfigured in the Paster application template. The
component architecture is a generic plugin system: it allows you -- if
you want -- to switch out and replace parts of the framework as easily
as switching template engines. It allows the components, routing, and
configuration data to all be specified in the same format in the same
configuration file, if desired. But a normal Pylons-like application
would not do this, it would use a familiar INI file, and a module
that's equivalent to environment/middleware/routing.py
--
Mike Orr <slugg...@gmail.com>
Andrew Kou
- Andrew Kou
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Mike Orr
> Whoa, so Pylons (the framework) is being killed off?
The framework named "Pylons" will remain 1.x, and will be used and
maintained for several years. The part of Pylons that is in the
``pylons`` package is actually pretty small (and has been getting more
simplified and smaller in the past few versions), so there's not much
to maintain. Most of the bugs that get reported are in the dependency
packages.
The version that was going to be Pylons 2 is now called Pyramid.
--
Mike Orr <slugg...@gmail.com>
daniel
understand for which benefits, which could not be handled with the
lovely pylons ..
I feel should consider whether it's time for me to step back to
django .. I always hated zope (useless ?) complexity and I love simple
way of thinking
daniel
On Nov 5, 7:52 am, Mike Orr <sluggos...@gmail.com> wrote:
> > Whoa, so Pylons (the framework) is being killed off?
>
> The framework named "Pylons" will remain 1.x, and will be used and
> maintained for several years. The part of Pylons that is in the
> ``pylons`` package is actually pretty small (and has been getting more
> simplified and smaller in the past few versions), so there's not much
> to maintain. Most of the bugs that get reported are in the dependency
> packages.
>
> The version that was going to be Pylons 2 is now called Pyramid.
>
> --
chrism
> had a quick look at pyramid ... too complex to me and not really
> understand for which benefits, which could not be handled with the
> lovely pylons ..
> I feel should consider whether it's time for me to step back to
> django .. I always hated zope (useless ?) complexity and I love simple
> way of thinking
several packages in the zope namespace, but end users never use or
need to care about those packages. They're a framework implementation
detail.
- C
chrism
> > I feel should consider whether it's time for me to step back to
> > django .. I always hated zope (useless ?) complexity and I love simple
> > way of thinking
>
> I've spent ten years using Zope. Pyramid is not Zope. It does use
> several packages in the zope namespace, but end users never use or
> need to care about those packages. They're a framework implementation
> detail.
about 60,000 (of non-test code). If Django is simpler than Pyramid,
then we better check the laws of physics for loopholes.
daniel
user's benefits of the change. The complexity I talked about as well
the allergy to zope is a personal perception I would wish expressing
here (perhaps I'm the only one feeling that, then just don't care
about it)
I decided to jump from django to pylons beacuse I felt pylons to be
open and simple. I enjoyed using it and I wish thanking immensely all
the contributors
My allergy to the name of zope shall play a role in personal future
decisions, whichever portion of it is going to be used here
Complexity is measured to my way of thinking from a user perspective,
not necessarly from a framework code number of lines developer point
of view
Regards
Daniel
chrism
> No criticism at all, although it would be nice getting the relevant
> user's benefits of the change. The complexity I talked about as well
> the allergy to zope is a personal perception I would wish expressing
> here (perhaps I'm the only one feeling that, then just don't care
> about it)
share of
lumps over the years, and has a reputation for being insular and
mysterious.
But the word "Zope" is meaningless without qualification. What *part*
of Zope
do you hate? "Zope" is a brand, not a technology.
If it's Zope2-the-web-framework, Pyramid is not that. The primary
designers
and developers of Pyramid, if anyone, should know. We wrote Pyramid's
predecessor (repoze.bfg), in part, because *we* knew that Zope 2 had
usability issues and limitations. repoze.bfg (and now Pyramid)
was written to address these issues.
If it's Zope3-the-web-framework, Pyramid is *definitely* not that.
Making
use of lots of Zope 3 technologies is territory already staked out by
the
Grok project. Save for the obvious fact that they're both web
frameworks, Pyramid is very, very different than Grok. Grok exposes
lots of Zope technologies to end users. On the other hand, if you
need to
understand a Zope-only concept while using Pyramid, then we've failed
on some
very basic axis.
If it's just the word Zope: it's, charitably, only guilt by
association. You
need to understand that just because a piece of software internally
uses some
package named ``zope.foo``, it doesn't turn the piece of software that
uses
it into "Zope". There is a lot of *great* software written that has
the word
Zope in its name. Zope is not some sort of monolithic thing, and a
lot of
its software is usable externally.
It's not really my job to defend Zope. But Zope has been
around for over 10 years and has an incredibly large, active
community. If
you don't believe this, http://taichino.appspot.com/pypi_ranking/authors
is
an eye-opening reality check.
> Complexity is measured to my way of thinking from a user perspective,
> not necessarly from a framework code number of lines developer point
> of view
disclosed.
- C
Mike Orr
> had a quick look at pyramid ... too complex to me and not really
> understand for which benefits, which could not be handled with the
> lovely pylons ..
The Pyramid book is a reference manual so it contains all the details.
More Pylons-specific guides will be coming but they're not written
yet. That's why the project is still in alpha. The benefits in short
are more flexibility and unifying some API paradigms that have
sprouted up in different frameworks since WSGI was invented. Ben can
explain it better than I can, just be patient. :) And Pylons 1 is not
going away. I'm still running Pylons 0.9.7 applications which are just
now being converted to Pylons 1.
--
Mike Orr <slugg...@gmail.com>
Graham Higgins
Hash: SHA1
Hi Kevin,
Steady the Buffs, Kevin --- and any other Pylons users who might
currently be going "Whoa?! WTF?".
FACT: Pylons 1.0 is not being killed off in any way, shape or form.
Your apps will continue to work and Pylons 1.0 will continue to be
supported for the foreseeable future, (yea, even in perpetuity should
you be able to lay your hands on a standard deep-space, 6.4 megayear-
rated gravity-powered server like what we have).
The "Pyramid development" is actually /very/ good news for Pylons
users. You may not be aware of it but Pylons 1.0 is currently in a
developmental cul-de-sac which offers no feasible route to a Pylons 2.
When working through the Pylons 1.0 architecture, looking for a way to
allow Pylons to properly support extensibility, Ben recently
discovered an architectural design flaw in Pylons [1]. The problem
orients around the chosen strategy of implementing individual app
extensibility by allowing subclassing of the WSGIController.
Ben says that Bob Brewer (of CherryPy fame) warned him about it at the
start of Pylons but back four years ago Ben was young, carefree and
thought little of it --- I'm paraphrasing, you understand :-)
But now, after four years of development, it ultimately transpires
that Bob was right, one side-effect of this strategy is that it now
profoundly blocks the planned further development of Pylons and the
strategy can't be changed without an accompanying complete re-write of
the Pylons codebase.
Which is not going to happen, for two reasons: 1) it's too much work,
in the wrong direction and ii) all Pylons 1 apps would have to be
comprehensively rewritten to work at all with Pylons 2.
So, with respect to Pylons' roadmap to the future, Pylons is between a
rock and a hard place --- but only with respect to the future. There
may be storm clouds may be looming on the horizon over /there/ but
right here, for Pylons 1 it's sunny and that will continue, so we can
still all go out and play.
Nevertheless, Ben is faced with the very real problem of making a long
running jump and grab to get Pylons into a position where we can all
start moving forward again.
Otherwise, like many corporate products, Pylons 1.0 will have to be
declared "feature-complete" and feature development would cease.
There's nothing wrong with that per se, I'm still using a 10-year old
a Java app that gives me WYSIWYG XML editing, wouldn't give it up for
the world. But I'm sure that a declaration that Pylons 1 was "feature
complete" and "that's your lot" would be received with bitter
disappointment by those Pylons users who were looking forward to
basing future work on Pylons 2.
The thing is, the BFG guys are already where Pylons needs to be, and
they are beckoning welcomingly and have been doing so for a while.
From his omniscient position as Pylons BDFL, Ben is aware that some
power users have already hit the Pylons wall on extensibility and
they've abandoned Pylons in favour of BFG and what's more, they've
found that they love it. There's something of a steady trickle of
advanced technical users from Pylons to BFG and as Ben remarks: "that
says something".
In addition, Ben and Chris McDonough have been exchanging ideas and
doing experimental code sprints for years. Architecturally, BFG is
conceptually very similar to Pylons. Chris looked very carefully at
Pylons when he created BFG and if you read through his blog posts,
you'll find a posting titled "Tips for greenlighting a framework" in
which you'll find: "Requiring that a user subclass a framework-defined
class is almost always the wrong answer" [2].
Oh, the BFG guys might dress differently to us and their cuisine might
taste a bit different to us but basically BFG does pretty much the
same thing as Pylons does - takes some stuff (often in a db) and
whacks it out the door as HTML or whatever.
BFG is WSGI-based, just like Pylons is; it is (broadly) MVC, just like
Pylons (broadly) is and, given a very similar base functionality
(accept request, connect request to code, execute code with in the
context of the req, return template-rendered result), you can see the
attraction of taking BFG's core and using it to replace the flawed
Pylons one.
For their part, the BFG guys are aware that their userbase so far has
been mainly ex-Zope users and a small (but gradually-increasing)
population of ex-Pylons users. It's true that the BFG guys are
originally from the land of Zope but from direct personal experience,
I can say that they are almost completely rehabilitated.
Work it out for yourself: they're already at the place where Pylons
needs to go, so clearly they're nobody's fool. The truly great thing
is that they're willing to share - there's a /very/ clear perception
that the conjunction of Pylons|TG|BFG represents a significant
opportunity to raise the web app development game both in technical
and functional terms.
Specifically, there is a lot of developmental synergy between the
three dev groups. Of late, Ben has been taking nearly all of the
Pylons development load on his own shoulders and the addition of some
more similarly highly-talented, highly-skilled, highly-productive
developers will seriously elevate the Gestalt - a point which is not
lost on BFG, they're very encouraged by this development, too.
Demonstrating a total lack of Zopish dogmatism, Chris has been putting
in a /huge/ amount of effort to partly dismantle BFG, strip out the
stuff that's BFG-oriented into a separate area (so as to not frighten
the Pylons horses) and reform the remainder as a common core suitable
for supporting the minimalist development style that is shared by /
both/ Pylons and BFG. Pylons-oriented code, developed earlier during
exploratory joint code sprints, has already been integrated (by Chris)
and Pyramid is progressing rapidly. Pylons 2 is looking very good
indeed.
There's /explicitly-planned/ space in Pyramid to support the TG
community's "full-stack" style too, should the community fancy jumping
on board.
"Leave no user behind" would be a good description of the current ethos.
Personal tip as an ex-TG user: make the jump, it'll be a huge plus for
TG. You will finally be able to have composite applications (well, all
Pyramid users get that benefit). You can make a package that has your
common controllers, templates, models in it and easily re-use that in
your other sites. And if you need to customise how the package
functions in one of your new sites, you don't even need to fork the
original.
Were you looking enviously at Pinax? Well, with Pyramid, you will have
access to an explicitly-designed extensibility strategy that is
integrated with the framework, instead of one that was bolted on later
as an afterthought.
Is that worth a bit of forbearance? Hope so, it is in my book.
As work proceeded apace on the "common core" it became screamingly
obvious that the /really big/ opportunity facing the dev teams was a
full-on merger of the codebase.
Having a "common core" supporting more than one web app development
framework has always been an elusive, strived-after goal but as soon
as you can stand in the foundations of such a development, the
advantages of a full merger become very clear indeed and, after a
short discussion, a full-on merger was settled upon.
This allows the dev teams to converge on maintenance and development
best practices and provides a significantly more robust and (simply
through having more devs) more capable development team.
The Pyramid codebase is an active building site at the moment, all
dust, sparks and scaffolding, there's a /lot/ of work going on as you
can tell from the commit history, so do wear a hard hat if you visit.
On 5 Nov 2010, at 09:34, daniel wrote:
> had a quick look at pyramid ... too complex to me and not really
> understand for which benefits, which could not be handled with the
> lovely pylons ..
>
> I feel should consider whether it's time for me to step back to
> django .. I always hated zope (useless ?) complexity and I love simple
> way of thinking
I shared your perspective, except that I was considering Clojure and
I'm not as bothered by Zope's software busywork.
A couple of days ago I emailed Ben, saying much the same as you and in
response, Ben kindly disabused me of my many misperceptions and I'm
now totally sold on the move.
I've decided to try and communicate the insights that Ben passed on to
me --- there's a certain flexibility of expression that can be
achieved in personal email but which is just totally unsuitable for
"announcements" and I'm trying to pass on those insights in turn, in a
form that strikes an acceptable balance between formality and
facetiousness.
One of my first self-appointed tasks is to try and communicate (in my
own idiosyncratic style) the benefits to the Pylons userbase. (I've
only just started on this task, so please bear with me while I get
settled in with the new codebase.)
TBH, by far and away the main benefit is that Pylons once again has a
future and one which is hugely brighter than it was just a few weeks
ago.
I guess the benefit accrual process will probably happen over a couple
of stages. The first will be when users start to make use of all the
BFG-provided goodies which will be immediately available through the
merger: things like events, etc.
(I need to go carefully through a whole bunch of saved posts, pulling
out the references to the goodies and making sure that I can express
them fluently in terms that I think Pylons users will readily
understand.)
I'm gonna fire this off now, 'cos I think an early response is
indicated, before things start to get out of hand, if they're heading
that way.
I'm working on a more considered, more detailed exposition --- there's
a long and continuous back story here that stretches back to mid-2008.
I have the first part of an /unfinished/ blog post which I will be
posting later this arvo (in its unfinished state), just to add some
broader context to the upheavals that are currently going on in the
Pylons 2 area. (I'll post the URL here as a reply).
Remember, Pylons 1 is NOT affected by the upheavals, only Pylons 2 is
affected and as Pylons 2 was only ever vapourware, your current
operational context will remain serenely undisturbed.
What you're seeing is a cloud of dust thrown up by the construction
site, don't let it blind you to the superb (pyramid-shaped?) building
that is being constructed. Mike Orr is working to insert a layer of
documentation that is intended to be better attuned to the Pylons
approach with which we've become comfortably familiar and I'll be
looking at taking some of the Shabti templates and migrating them to
Pyramid as well as providing my own warped take on the documentation.
I can personally assure you that Pylons users' concerns are an
explicit subject of intense attention by the Pyramid developers - as
are BFG users' concerns and TurboGears users' concerns. The Pyramid
developers are waaaay too smart to make the elemental mistake of
riding roughshod over users' concerns.
(Who am I to give personal assurances? I am a cognitive scientist with
a Masters in Cognition, Computing and Psychology from Warwick
University in the UK and a career in commercial AI/Expert systems
research in blue-chip Labs (Marconi and HP). My domain specialisms in
cognitive psychology are the cognitive limits of attentional
performance and cognitive issues in causes of human error as applied
to the domain of software engineering and programming language design.
I've been using Pylons for several years and have contributed to the
Pylons' documentation and training material, developed Shabti, a set
of Pylons "power-up" templates and I am currently engaged in
contributing to Pyramid in a similar context.)
Finally, the BFG component of the Pyramid devs anticipated some of
these sort of questions and observations, so they prepared a response:
http://docs.pylonshq.com/denials/pyramid.html
:D
[1] http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks
HTH
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkzUHSAACgkQOsmLt1NhivxyBACgu/EXGJUwOkHsrLTH86x1YGS9
dqYAoLp67Pd3/grjkW8XjqncL2xjvECsiQCVAgUBTNQdIFnrWVZ7aXD1AQKpxwQA
4dK3mZJLVzOQ5lgX2ryAQ2CqfkqZ5ZM9StcQk5+rLz3S0yMO0iEdeQ2RhQ0m7Dfs
WuDUB2CF7cr2ztDhacCQhucRppZJmE3tn+k6kux0xqMHHc2jsV5E6B1bQDRfMXQt
+i4oszySQ6eNuHHsJcLKG1z/76GcZk7dFVhF/sU/Uj8=
=Jvel
-----END PGP SIGNATURE-----
David Gardner
1) use SQLAlchemy to fetch stuff
2) call some backend modules with that data
3) maybe store the results in Beaker
4) then send those results to Mako
I suspect this is probably going to be the case, so I'm cool.
Any incompatibilities are par for the course for a major numbered upgrade.
> There are some changes in the syntax. Routes configuration changes to
> ``config.add_hander()`` or ``config.add_route()``. A view method looks
> like this:
>
> class MyViewHandler(object):
> def __init__(self, request):
> self.request = request
>
> @action(renderer="/index.mako")
> def my_view(self):
> return {"var1": "value 1"}
>
>
>
--
David Gardner
Pipeline Tools Programmer
Jim Henson Creature Shop
dgar...@creatureshop.com
lcrees
As a longtime Pylons classic (1.x) and sometimes Zope 3 user, I'm
intrigued by Pyramids.
A disclaimer: I was not fond of classical Zope 3 development. Since I
worked with a longtime Zope veteran (Jeff Shell), I know why Zope 3
was an architectural improvement over Zope 2. But the application
development experience left a lot to be desired for me personally (the
ZCML requirement was one but not the only reason). However, the
essence of the ZCA was promising and I've followed the grok and repoze
initiatives with great interest as they experimented with ways to free
Zope 3 from Zope 3.
The ZCA exists to free web framework developers from endless
subclassing. Zope 2 had endless subclassing and it began to wear on
people. Zope 3 was a radical break to free the Zope community from the
same problems that Mr. Bangert is facing with Pylons 1.x. The ZCA
unfortunately came about at a time when XML and Javaish enterprisy
terminology was all the rage and it reflects its passage through that
dark time. However, the vast, vast, vast, vast, vast, vast, vast
majority of Pylons web _application_ developers would never have to
face the agony of the raw ZCA, ZCML, or interfaces. That's something
for framework nerds and hardcore Zope veterans. Core ZCA components
like zope.component and zope.interface as well as other Zope
components are over five years old and rock solid. It's merely their
usability that has largely fallen short. Pyramids has the potential to
bring things the Zope community has had for years down from the
mountaintop to a larger community. In truth, the Zope legacy is little
more than an asterisk to future Pylons development.
If Pylons/Pyramids/whatever is successfully packaged and sold, Zope 3
may receive vindication in the end.
Especially if people don't realize they're using Zope 3.
Andrew Kou
I think it is important that it is stressed "pretty heavily" in docs/site etc that Pylons 1 isn't being killed off. I think a lot of people are misunderstanding and getting the impression that this is the case for one reason or another.
Another issue I can see is that people don't understand what the difference of the changes are. Maybe a simple high level diagram would help? (I don't know if that is even possible, just a suggestion)
Best,
- Pyeek
Mike Orr
> So as a user what matters to me is that I can still continue to:
>
> 1) use SQLAlchemy to fetch stuff
> 2) call some backend modules with that data
> 3) maybe store the results in Beaker
> 4) then send those results to Mako
Yes for 1, 3, and 4. I'm not sure what you mean by #2.
Pyramid has a Paster template called "pyramid_sqla" that preconfigures
a SQLAlchemy+Mako application to the same level as Pylons 1. I think
it also includes Beaker but I'm not 100% sure about that. In any case,
the pyramid-beaker plugin is already written. And Pyramid includes an
equivalent to Routes, which is in the process of gaining all of
Route's features.
Pyramid includes a sopisticated auth system that's more integrated
than Repoze.who/what.
It looks like Pyramid does not include a form builder/validator, but
you should be able to use FormEncode/WebHelpers or ToscaWidgets or the
SQLAlchemy-form packages as usual. (I'll be testing a
FormEncode/WebHelpers app soon.) You may have to provide your own code
for @validate or an equivalent, at least at this stage.
You can define your own lib functions and call them from a view or
model. I think that's what you mean by #2?
--
Mike Orr <slugg...@gmail.com>
Kevin J. Smith
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Kevin,
On 4 Nov 2010, at 23:44, Kevin J. Smith wrote:
Someone pointed out pyramids to me (http://docs.pylonshq.com/pyramid/dev/narr/introduction.html) and I am a bit confused with the relationship between pyramids and pylons.
I have been using pylons for over a year now and have never heard of pyramids (and that includes passively following this mailing list.) From the page on pyramids it seems to suggest that pylons post 1.0 will be using pyramids? If so, statements like "no controllers" kind of frighten me ... and quite frankly most things that are Zope related frighten me.
Anybody care to clarify?
Steady the Buffs, Kevin --- and any other Pylons users who might currently be going "Whoa?! WTF?".
FACT: Pylons 1.0 is not being killed off in any way, shape or form. Your apps will continue to work and Pylons 1.0 will continue to be supported for the foreseeable future, (yea, even in perpetuity should you be able to lay your hands on a standard deep-space, 6.4 megayear-rated gravity-powered server like what we have).
The "Pyramid development" is actually /very/ good news for Pylons users. You may not be aware of it but Pylons 1.0 is currently in a developmental cul-de-sac which offers no feasible route to a Pylons 2.
When working through the Pylons 1.0 architecture, looking for a way to allow Pylons to properly support extensibility, Ben recently discovered an architectural design flaw in Pylons [1]. The problem orients around the chosen strategy of implementing individual app extensibility by allowing subclassing of the WSGIController.
Ben says that Bob Brewer (of CherryPy fame) warned him about it at the start of Pylons but back four years ago Ben was young, carefree and thought little of it --- I'm paraphrasing, you understand :-)
But now, after four years of development, it ultimately transpires that Bob was right, one side-effect of this strategy is that it now profoundly blocks the planned further development of Pylons and the strategy can't be changed without an accompanying complete re-write of the Pylons codebase.
Which is not going to happen, for two reasons: 1) it's too much work, in the wrong direction and ii) all Pylons 1 apps would have to be comprehensively rewritten to work at all with Pylons 2.
So, with respect to Pylons' roadmap to the future, Pylons is between a rock and a hard place --- but only with respect to the future. There may be storm clouds may be looming on the horizon over /there/ but right here, for Pylons 1 it's sunny and that will continue, so we can still all go out and play.
Nevertheless, Ben is faced with the very real problem of making a long running jump and grab to get Pylons into a position where we can all start moving forward again.
Otherwise, like many corporate products, Pylons 1.0 will have to be declared "feature-complete" and feature development would cease. There's nothing wrong with that per se, I'm still using a 10-year old a Java app that gives me WYSIWYG XML editing, wouldn't give it up for the world. But I'm sure that a declaration that Pylons 1 was "feature complete" and "that's your lot" would be received with bitter disappointment by those Pylons users who were looking forward to basing future work on Pylons 2.
The thing is, the BFG guys are already where Pylons needs to be, and they are beckoning welcomingly and have been doing so for a while.
From his omniscient position as Pylons BDFL, Ben is aware that some power users have already hit the Pylons wall on extensibility and they've abandoned Pylons in favour of BFG and what's more, they've found that they love it. There's something of a steady trickle of advanced technical users from Pylons to BFG and as Ben remarks: "that says something".
In addition, Ben and Chris McDonough have been exchanging ideas and doing experimental code sprints for years. Architecturally, BFG is conceptually very similar to Pylons. Chris looked very carefully at Pylons when he created BFG and if you read through his blog posts, you'll find a posting titled "Tips for greenlighting a framework" in which you'll find: "Requiring that a user subclass a framework-defined class is almost always the wrong answer" [2].
Oh, the BFG guys might dress differently to us and their cuisine might taste a bit different to us but basically BFG does pretty much the same thing as Pylons does - takes some stuff (often in a db) and whacks it out the door as HTML or whatever.
BFG is WSGI-based, just like Pylons is; it is (broadly) MVC, just like Pylons (broadly) is and, given a very similar base functionality (accept request, connect request to code, execute code with in the context of the req, return template-rendered result), you can see the attraction of taking BFG's core and using it to replace the flawed Pylons one.
For their part, the BFG guys are aware that their userbase so far has been mainly ex-Zope users and a small (but gradually-increasing) population of ex-Pylons users. It's true that the BFG guys are originally from the land of Zope but from direct personal experience, I can say that they are almost completely rehabilitated.
Work it out for yourself: they're already at the place where Pylons needs to go, so clearly they're nobody's fool. The truly great thing is that they're willing to share - there's a /very/ clear perception that the conjunction of Pylons|TG|BFG represents a significant opportunity to raise the web app development game both in technical and functional terms.
Specifically, there is a lot of developmental synergy between the three dev groups. Of late, Ben has been taking nearly all of the Pylons development load on his own shoulders and the addition of some more similarly highly-talented, highly-skilled, highly-productive developers will seriously elevate the Gestalt - a point which is not lost on BFG, they're very encouraged by this development, too.
Demonstrating a total lack of Zopish dogmatism, Chris has been putting in a /huge/ amount of effort to partly dismantle BFG, strip out the stuff that's BFG-oriented into a separate area (so as to not frighten the Pylons horses) and reform the remainder as a common core suitable for supporting the minimalist development style that is shared by /both/ Pylons and BFG. Pylons-oriented code, developed earlier during exploratory joint code sprints, has already been integrated (by Chris) and Pyramid is progressing rapidly. Pylons 2 is looking very good indeed.
Eric Rasmussen
Mike Orr
> This has been a fascinating discussion! I don't have anything to add that
> hasn't already been expressed, but I second Kevin's request to try it out
> and see how it works.
>
> More specifically, to the developers: do you need testers? I'm planning some
> updates to one of my side-projects, and I'd be happy to try rebuilding it in
> Pyramid to see how it goes. It's something I'm doing on the side for fun so
> I can work on it whenever you're ready for testing.
Eric, feel free to play with it. I guess specific questions about
using it should go to pylons-devel at this stage, so that Pylons 1
users won't get confused? My proto howto is here but it was written
before the Pyramid shift, so some parts are out of date. The usage
should be almost the same, just the repository location and package
name is different. I'm thinking of a simple Blog+Comments+Auth
tutorial using SQLAlchemy if you'd like to collaborate on that.
HTML version:
http://bytebucket.org/sluggo/pylons2-userguide/wiki/html/index.html
Sphinx source:
https://bitbucket.org/sluggo/pylons2-userguide
--
Mike Orr <slugg...@gmail.com>
Ben Bangert
> I found it all a bit depressing, mind you, because I have chosen to build our application on a technological dead end framework (Pylons 1.x) But if there is some inherent architectural dead end to Pylons 1.x then I completely understand the necessity to moving to something else.
Yes, some of the beta code I had tried out for Pylons 2.0 would've required a similar amount of porting as this transition will.
> However, I am a bit skeptical of the BFG stuff ... not because I'm worried of its technical capabilities or architecture but I'm worried about its usability and learning curve. Back when I began coding our app I looked at wiring in auth and naturally evaluated repoze who/what and authkit. Even though it appeared, from what I was reading, that repoze who/what was the more capable library it failed my 10 minute test miserably. Whereas, within a short period of time I was able to get something working with authkit.
Luckily, pyramid comes with authentication/authorization (built-in, and optional of course). repoze.what wasn't actually created by the repoze folks, it was a TG2 project for authorization, which many folks have unfortunately had a lot of problems with.
> Of course I realize that there is sometimes tradeoff between ease of use and capability. Which is precisely why I chose Pylons over Django - I wanted to be able to swap out certain modules for others - I wanted a bit more flexibility. But I also remember experiences with Zope in the early days - I found the architecture fascinating and did spend considerable time to learn Zope but at the end of the day I stamped it over-engineered because it was just almost always easier to just cobble something together with mod_python and coding closer to the metal.
I think you'll be able to swap in and replace most anything you'd want to in pyramid as well, this time using better documented hook and plug-in points, rather than attempting to glue together more things.
> It is similar to my Java/Spring framework experience. Fascinating from an academic viewpoint but at the end of the day it is just always easier to code something up with a lightweight language like Python. At the end of the day, the best designs usually turn out to be the simplest.
>
> I shall hold off on my opinions of Pyramids until I have a chance to play with it and I am truly hoping that it doesn't smell anything like Zope.
I'll be sending out an announcement later today, but there's no reason people that want to, can't start kicking the tires now so to speak. Due to the extremely well documented heritage of bfg, there is ample docs. They are quite verbose, for good or bad, so people are working on more new-user friendly guides for the 10k ft view.
Speaking of simplicity, in pyramid, if you have one of those uber-simple little apps that doesn't need a full Pylons-like project setup, you can actually create the entire thing in a single module if that's your fancy:
from pyramid.configuration import Configurator
from pyramid.response import Response
from paste.httpserver import serve
class MySite(object):
def __init__(self, request):
self.request = request
def hello(self):
return Response('Hello world!')
if __name__ == '__main__':
config = Configurator()
config.begin()
config.add_handler('home', '/site/:action', handler=MySite)
config.end()
app = config.make_wsgi_app()
serve(app, host='0.0.0.0')
That's it! While some of the terminology is changing, the overall style (class-type 'controllers') for those coming from Pylons is not. Simple sites can be simple, and larger ones that need extensibility can actually be extensible.
> Which brings up the point, where can we get our hands on Pylons 2.0 work?
There's a pyramid 1.0a1 release on cheeseshop now, the docs are all over at http://docs.pylonshq.com/. This is the home for the combined project right now, and will be further integrated into the main pylonshq site.
Cheers,
Ben
Mike Orr
> Kevin J Smith wrote:
>> From
>> the page on pyramids it seems to suggest that pylons post 1.0 will be using
>> pyramids? If so, statements like "no controllers" kind of frighten me ...
>> and quite frankly most things that are Zope related frighten me.
>>
>> Anybody care to clarify?
>
> Steady the Buffs, Kevin --- and any other Pylons users who might currently
> be going "Whoa?! WTF?".
Chris McDonough wrote:
> The word "Zope" is meaningless without qualification. What *part* of Zope do you hate?
> It's pretty hard to defend Pyramid against charges that won't be
disclosed.
Less confrontation, Chris, please. Pylons users are legitimately
concerned about any sudden changes in the API, abandonment of
previously-supported versions, and over-Zopeification. Also, Pyramid
is being introduced to them in a haphazard way, rather than an
announcement and discussion before the fact as TurboGears had [1] and
presumably BFG had. So people are rightly concerned about where Pylons
is headed, and asking for more details.
[1]: http://groups.google.com/group/turbogears/browse_thread/thread/47779d8587721037?pli=1
The merger/rebanding is very recent -- like a week ago. Graham and I
first heard about it four days ago. That's why not all of the pieces
are in place yet.
The reason for concerns like Kevin's is historical. I (and several
WSGI developers) left Zope in 2000 because it was a huge monolith, and
the documentation was geared toward content creators rather than
Python developers. Zope has since fixed many of these shortcomings:
improving the developer documentation, splitting the code into
multiple packages, and spawning Repoze and BFG and Grok. But ZCML,
component architecture, and interfaces still strike fear into many
hearts. And Zope's greatest accomplishment -- Plone -- is still tied
to Zope 2, and is still more monolithic than many here would like. The
fears about Pylons are legitimate and need to be addressed. We just
need to have a dialog about what exactly is coming from Zope, why it
won't destroy Pylons, and what its benefits are.
The other concern is abandonment of previous versions. Many people
were not happy with the move from TurboGears 1 to TurboGears 2. They
complained that the TG book was published right when its developers
were starting to move away from that paradigm, and that the window
between TG1 and TG2 was unusually short by framework standards. This
forced people to invest in TG1 and then immediately rewrite their apps
for TG2, or stick with TG1 which was now less-supported than they had
been expecting. So people are rightly concerned that Pylons mustn't do
that. Still, the state of the art evolves quickly, so some change is
inevitable.
My message to Pylons users is: the developers share your concerns. We
asked the same questions of Chris when we were first considering BFG
and a component architecture. We hate XML just as much as you do. We
asked, "What would a component architecture gain us? Are there any
alternative non-Zope implementations? Are these pieces separable from
the rest of Zope? How much Zope is enough and how much is too much?"
It turns out that that the Zope developers were smart to see the
benefits of components/interfaces early on, and they were willing to
split that out for the rest of us, just as they had earlier split out
ZODB. There is no alternative Python package for this that has been as
well tested over several years, especially in a web-framework
environment.
When Chris first explained the XML-based configurator, our first
comment was, "That will be unacceptable to Pylons users." So he made a
flexible configuration backend, envisioning multiple configuration
styles (XML, Python, INI, etc). Only the XML and Python styles have
been pursued. (The Paste INI file is not directly related to this. The
upshot for Pylons users is a Python module equivalent to
environment/middleware/routing.py .)
> FACT: Pylons 1.0 is not being killed off in any way, shape or form. Your
> apps will continue to work and Pylons 1.0 will continue to be supported for
> the foreseeable future,
And anyone is free to help with maintenance or take on feature
enhancements -- with Ben's approval. But really, what does Pylons 1
need? We have already rejected larger Form/ORM/Auth dependencies.
"@validate" needs a replacement; that's the only thing I can think of.
> Ben recently discovered an
> architectural design flaw in Pylons [1]. The problem orients around the
> chosen strategy of implementing individual app extensibility by allowing
> subclassing of the WSGIController.
>
> Ben says that Bob Brewer (of CherryPy fame) warned him about it at the start
> of Pylons but back four years ago Ben was young, carefree and thought little
> of it --- I'm paraphrasing, you understand :-)
What is the flaw? The footnote seems to have been omitted.
> Architecturally, BFG is conceptually
> very similar to Pylons. Chris looked very carefully at Pylons when he
> created BFG and if you read through his blog posts, you'll find a posting
> titled "Tips for greenlighting a framework" in which you'll find: "Requiring
> that a user subclass a framework-defined class is almost always the wrong
> answer" [2].
Another missing footnote.
> Demonstrating a total lack of Zopish dogmatism, Chris has been
Well put. :)
> There's /explicitly-planned/ space in Pyramid to support the TG community's
> "full-stack" style too, should the community fancy jumping on board.
There has also been a dialog with the Django developers the past two
years, mostly covering basic WSGI issues and a potential common
request/response object (WebOb). The door is always open if they'd
like greater collaboration, or to port Django to Pyramid the way TG
was ported to Pylons. It hasn't gone very far because Django famously
prefers homegrown code, but we aim to keep the code "Django-ready" by
anticipating what hooks they'd likely need for their features.
And the same goes for any other type of Python web framework. If it
needs new plugin hooks to integrate with Pyramid, we're willing to
consider them. But that work seems to be done because most of the
full-stack frameworks we've seen fall into a few main categories:
CherryPy-like (TG), Pylons-like, Zope-like (only Zope), Twisted-like
(only Twisted), Django-like (only Django), and servlet-like (none
since WebWare nine years ago). Zope and Twisted are too big and unique
to be integrated, and servlet-like has long been abandoned, but we've
tried to accommodate the other major API styles -- to give application
developers the maximum flexibility and mix-and-match ability that was
Pylons' original vision.
--
Mike Orr <slugg...@gmail.com>
Jens Hoffrichter
chrism
> Less confrontation, Chris, please. Pylons users are legitimately
> concerned about any sudden changes in the API, abandonment of
> previously-supported versions, and over-Zopeification. Also, Pyramid
> is being introduced to them in a haphazard way, rather than an
> announcement and discussion before the fact as TurboGears had [1] and
> presumably BFG had. So people are rightly concerned about where Pylons
> is headed, and asking for more details.
- C
Ben Bangert
> Thanks to especially Graham and Mike to point out what the benefit for the "end-user-developer" (a crude term, I know ;) ) will be with the Pylons2/Pyramid move.
>
> When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app.
>
> Some of the things I mean:
>
> - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live)
No worries, these are not dead! The WebHelpers package isn't going anywhere, and its still easy to use throughout your templates.
> - Change in how to address a template (from "package.template" to "package/template.mak")
Ah, sorry if that's confusing. The dotted notation for a full 'resource specification' is optional:
http://docs.pylonshq.com/pyramid/dev/narr/views.html#mak-or-mako-mako-template-renderer
You can and do of course, configure Mako to have a template directory, and relative names like 'foo.mak' are assumed to exist in said template dir.
The ability to use a full resource specification addresses a long-time noted issue with extending or re-using packages of your templates. While Mako lets you plugin multiple template paths, the overlap can get tricky to manage, being able to refer to a template with its package name is specifically to allow you to use templates that might be in another package for extending purposes.
Consider the case where you have a set of templates you use in all your projects, wouldn't it be nice to have a package of those you just call into? And if you needed to tweak just one of those, you could override it with a template of your choice via the override API:
http://docs.pylonshq.com/pyramid/dev/narr/resources.html#the-override-resource-api
This is the start of where many frameworks are telling you to fork code.... ;)
> - The move from implicit routes to explicit routes
Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x with Routes already actually, as the implicit naming and resolving done in Routes generally leads to more problems for users, than helping.
> And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit.
I've tried to provide as smooth an upgrade path as possible between various versions of Pylons. From the upgrade path's I've seen in other web frameworks, its one of the smoother ones... but the fact that so much configuration was in Python files rather than the framework has been very problematic as extensive changes are needed for upgrades as half the 'framework' is more or less assembled in the project itself. pyramid does not have this issue, as rather than having all its configuration innards in your project, you configure pyramid via hook points.
> Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, "Can we solve this in pylons, or do we have to implement it with something different?", but the lack of continuity has been a bit disheartening at times.
>
> Still, I would really be interested in why the subclassing of WSGIController lead Pylons in an architectional dead end, just from a curious point of view :)
http://be.groovie.org/post/1347858988/why-extending-through-subclassing-a-frameworks is my main summary of the problems.
I also have a bit more on this on the faq question here:
http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue-developing-the-pylons-1-0-code-base
> I will take a look at the new packages as soon as I get around to it, but I'm really curious by now.
>
> > But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies.
> > "@validate" needs a replacement; that's the only thing I can think of.
> Maybe not the Pylons package itself (and I personally had no trouble using @validate up to now), but one thing the whole Pylons eco system would hugely benefit from (imo) is a database migration tool. I have looked into those which have been announces (miraku and a couple of others), and all fall short.
I'd love to spend more time on getting an 'official' one hammered out. Part of the reason for combining efforts, and going with pyramid for the base is that we need a strong, stable, extensible system to start building more helpful higher level tools. With a larger team of developers, this becomes much easier. I'm also trying to address ways the Pylons site failed to make it easy enough to get involved and contribute by increasing the amount of documentation on *how* to actually contribute.
http://docs.pylonshq.com/#contributing
So far, there's already a lot more developers working on pyramid, and the set of libraries extending up around it than Pylons managed in the first several years of existence. I really believe that before long, there'll be a set of such compelling libraries for use with pyramid, this issue will be a non-starter, and you'll have a great case to make for clients on why they should port that wasn't nearly as easy to make for moving from Pylons 0.9.6 -> 1.0.
Cheers,
Ben
Mike Orr
<jens.hof...@gmail.com> wrote:
> - The deprecation of rails-style webhelpers. We depend on those quite a bit
> in our first application we wrote (and which is still live)
WebHelpers 0.6.4 is still on PyPI for just this reason. But it was
hard to maintain, the APIs were borrowed from Rails without much
thought, and the implementations did a lot of naive string
concatenation. That was hard to maintain and extend, and if we wanted
to jettison it we had to do it before 1.0.
> - Change in how to address a template (from "package.template" to
> "package/template.mak")
Did Pylons ever have this? I think it was only in TurboGears. Maybe it
came to Pylons via the first version of Buffet and its Cheetah plugin
(horrible).
> - The move from implicit routes to explicit routes
Another example of a bad early decision in Pylons, and thus the need
for a somewhat-painful transition.
We're aware that the transitions to 0.9.7 and 1.0 caused frustrations
like these. We're trying to minimize that in future versions by
keeping Pylons 1 viable for at least a few years after Pyramid is
released. But at some point we'll be discouraging writing new
applications in Pylons 1. Sometime in the future after Pyramid is
released.
--
Mike Orr <slugg...@gmail.com>
Eric Ongerth
in the room now has a bright light shining on it.
As soon as I caught wind of repoze.bfg and now pyramid, I put a couple
of hours into reading through the docs. To me it was apparent even at
first look that the new ontology is more straightforward, and we will
be able to put new apps together even more clearly and simply than
ever. Nothing struck me as more complicated. All I see is more
options and a very significant success in simplifying and clarifying
the tasks that a developer has to go through to get his app or site up
and running.
I'm not surprised the news is shocking to some, but the new direction
makes me very happy. I never really felt at ease with how much Pylons
configuration was tucked away in multiple python files. Any time I
took a break from Pylons for a few months, when I came back I
invariably had to read through Mike's execution analysis to wrap my
head around what was actually going on and why some configuration was
here, some was over here, and some was in yet another place.
Three cheers for Pyramid. Now how long before someone writes a build
template for it and calls it Cheops or Khufu or some other famous
pharaoh's name...
- Eric
On Nov 5, 3:10 pm, Ben Bangert <b...@groovie.org> wrote:
> On Nov 5, 2010, at 1:50 PM, Jens Hoffrichter wrote:
>
> > Thanks to especially Graham and Mike to point out what the benefit for the "end-user-developer" (a crude term, I know ;) ) will be with the Pylons2/Pyramid move.
>
> > When I started to read these posts, I was a bit concerned, too. I (we, my company) have been long time Pylons users, and admittedly, we have seen more changes in Pylons than we liked. I could understand the reasoning behind all those changes, still, for the developer they pose a hazard in long-term-evolution of a written app.
>
> > Some of the things I mean:
>
> > - The deprecation of rails-style webhelpers. We depend on those quite a bit in our first application we wrote (and which is still live)
>
> No worries, these are not dead! The WebHelpers package isn't going anywhere, and its still easy to use throughout your templates.
>
> > - Change in how to address a template (from "package.template" to "package/template.mak")
>
> You can and do of course, configure Mako to have a template directory, and relative names like 'foo.mak' are assumed to exist in said template dir.
>
> The ability to use a full resource specification addresses a long-time noted issue with extending or re-using packages of your templates. While Mako lets you plugin multiple template paths, the overlap can get tricky to manage, being able to refer to a template with its package name is specifically to allow you to use templates that might be in another package for extending purposes.
>
> This is the start of where many frameworks are telling you to fork code.... ;)
>
> > - The move from implicit routes to explicit routes
>
> Yes, all routes do have to be explicit. I was moving that way in Pylons 1.x with Routes already actually, as the implicit naming and resolving done in Routes generally leads to more problems for users, than helping.
>
> > And if I thought a bit more, I would probably come up with a couple of more examples, which have been problematic for us. The problem in there is, that there normally is no smooth upgrade path, and no backwards compatibility, so we are stuck with supporting a 0.9.6.2, a 0.9.7 and a 1.0 pylons app by now, as no one would pay us a money for the complete rework the older apps need, as for the customer, it would mean very little benefit.
>
> I've tried to provide as smooth an upgrade path as possible between various versions of Pylons. From the upgrade path's I've seen in other web frameworks, its one of the smoother ones... but the fact that so much configuration was in Python files rather than the framework has been very problematic as extensive changes are needed for upgrades as half the 'framework' is more or less assembled in the project itself. pyramid does not have this issue, as rather than having all its configuration innards in your project, you configure pyramid via hook points.
>
> > Don't get me wrong, I love pylons, and the first question we ask ourselves when a new project comes in is, "Can we solve this in pylons, or do we have to implement it with something different?", but the lack of continuity has been a bit disheartening at times.
>
> > Still, I would really be interested in why the subclassing of WSGIController lead Pylons in an architectional dead end, just from a curious point of view :)
>
>
> I also have a bit more on this on the faq question here:http://docs.pylonshq.com/faq/pylonsproject.html#why-not-just-continue...
> > I will take a look at the new packages as soon as I get around to it, but I'm really curious by now.
>
> > > But really, what does Pylons 1 need? We have already rejected larger Form/ORM/Auth dependencies.
> > > "@validate" needs a replacement; that's the only thing I can think of.
> > Maybe not the Pylons package itself (and I personally had no trouble using @validate up to now), but one thing the whole Pylons eco system would hugely benefit from (imo) is a database migration tool. I have looked into those which have been announces (miraku and a couple of others), and all fall short.
>
Michael Semcheski
> I'm glad to see (vis a vis this discussion thread) that the elephant
> in the room now has a bright light shining on it.
As a Pylons user, I think one of the most important things that this
discussion shows is that the core developers have direction, energy,
and openness to making this framework better through collaboration.
Its easy to take that for granted, but not every project has this.
Jeff Tchang
How much work is it going to take to get my Pylons 9.7/1.0 project to
Pyramid. Also since I have projects currently being worked on in
Pylons how much of this is going to be dead end work?
I am hoping that there will be specific migration patterns to ease
this pain. A step by step guide for migration so I can at least
understand what work will be required.
What is the recommendation at this point for someone in the middle of
creating a Pylons 9.7/1.0 app? My assumption is to continue but be
aware that a year or two down the road to expect a rewrite.
How about new projects? Should they immediately start using Pyramids
and abandon Pylons?
-Jeff
Eric Ongerth
Pyramid allows you to "mount" an existing Pylons app and serve it
right through without modification. Having done so, you are then free
to convert the app page by page, or handler by handler or however you
wish to proceed ... or leave it unchanged.
Eric
Graham Higgins
Hash: SHA1
On 5 Nov 2010, at 15:05, Graham Higgins wrote:
> (I need to go carefully through a whole bunch of saved posts,
> pulling out the references to the goodies and making sure that I can
> express them fluently in terms that I think Pylons users will
> readily understand.)
Okay, here's one, in the form of some profiling data:
> Pylons: http://svn.repoze.org/whatsitdoing/pylons/results.txt
> 256145 function calls in 0.811 CPU seconds
>
> bfg (~= Pyramid) http://svn.repoze.org/whatsitdoing/bfg/results.txt
> 20013 function calls in 0.084 CPU seconds
Mmm.
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkzWEbMACgkQOsmLt1NhivzoowCfXo4GHcVF8lijXui7YDtsJvIa
1JMAn0x/aM9ByUT1PZZ4fvFDUS2bXlg7iQCVAgUBTNYRs1nrWVZ7aXD1AQKRbgP/
UOHgw//hOLXChjzkDdJJrTsVzqNhI4H4KOtruCc9m5KF/NR6BuFrSzu6ngkgRQ39
oHwf7KnY/ooF2JY6x1HGV9VJoUJhY/U841NqO2jxe/WrmjPeWxCME0z/WCI4n26z
HylyqBUrCWOjoLNK0KqDTvW9wfwudcwsVAbFENSBeAo=
=zy1G
-----END PGP SIGNATURE-----
Roy Smith
Graham Higgins
Hash: SHA1
On 7 Nov 2010, at 02:40, Graham Higgins wrote:
>> Pylons: http://svn.repoze.org/whatsitdoing/pylons/results.txt
>> 256145 function calls in 0.811 CPU seconds
Slight correction...
That was Pylons 0.9.7 Chris informs me. Pylons 1.0 was whittled down
to about 150K.
Also, the standard caveat that those figures usually get drowned if
the app is doing any serious work.
This from Ben: "The bare minimal execution stack during a 'hello
world' request in pyramid is 20 function calls. In pylons, even with
all the middleware stripped, its 256."
I find it a useful datum - it means that I can feel comfortable
serving /favicon.ico and /robots.txt, etc. directly from the app if I
want.
Some early reports of reasonable speedups (*2) after porting apps from
Pylons/GAE to Pyramid/GAE, too early to start grinning yet.
- --
Cheers,
Graham
-----BEGIN PGP SIGNATURE-----
iEYEARECAAYFAkzWG60ACgkQOsmLt1NhivzgmQCg/Y35WGe3xJZl7wDpqY1exVwD
IHMAoKIZI/han2HgKO5KvFGEcDf60BkJiQCVAgUBTNYbrVnrWVZ7aXD1AQIFwwQA
4DhTKdmw+O32giI/Tux7yGZI9JOtRlEcq7iPC2XxijFnlUPDlds3R+9RRALN9MtQ
newZm0sttINIWtfvpdWQqtxg/zm96n6vHbTkD/ymoX0lZ7FLepqJmEYp1jd6GvbA
T8PrEi8PNihgb5xGoaDwCho1HlMPMMkupungJ6bwJpM=
=935+
-----END PGP SIGNATURE-----
cd34
> As a long time user of Pylons the thing that scares me is migration.
> How much work is it going to take to get my Pylons 9.7/1.0 project to
> Pyramid. Also since I have projects currently being worked on in
> Pylons how much of this is going to be dead end work?
I had an undeployed Pylons 1.0 project that we had started working on
about three weeks ago. We used repoze.who/repoze.what (I do not have
Pyramid's auth working with an SQL backend yet) and FormAlchemy along
with a number of webhelpers for pagination and constants. It took
about 16 hours to convert 35 actions in three controllers to Pyramid.
Of that 16 hours, I'd guess that 12 hours was learning Pyramids,
reading the documentation, learning how Pyramid did things - I had
looked at repoze.bfg in the not too distant past, and getting pointers
on IRC to documentation and methodologies behind Pyramid.
With that said. Pylons 1.0 isn't going away for a long time. It
probably won't see many feature upgrades but will receive bugfixes for
stability/security. I don't think I would worry about a project
currently using 0.9.7/1.0 being orphaned and unsupported.
While Pyramid is tagged as an Alpha release, it is a very mature
Alpha. I do believe that we'll be using Pyramid for new development
and as we work out some of the pitfalls we run into, I'll post the
solutions we find.
Mike Orr
> On Nov 6, 1:46 pm, Jeff Tchang <jeff.tch...@gmail.com> wrote:
>> As a long time user of Pylons the thing that scares me is migration.
>> How much work is it going to take to get my Pylons 9.7/1.0 project to
>> Pyramid. Also since I have projects currently being worked on in
>> Pylons how much of this is going to be dead end work?
>
> http://cd34.com/blog/framework/pylons-1-0-to-pyramid-1-0a1/
>
> I had an undeployed Pylons 1.0 project that we had started working on
> about three weeks ago.
Thanks, cd34. I've added links to this in the Pyramid Supplemental Docs.
http://bytebucket.org/sluggo/pyramid-docs/wiki/html/index.html
(This site is a holding place for my documentation until we figure out
what to put in the official docs, and also so that I can keep the
source in its own repository."bytebucket.org" is an automatic redirect
from BitBucket; I guess that's how they serve static content.)
It also contains the Pylons 1.0 Execution Analysis, which I submitted
to the Pylons docs but I don't think it's there yet.
--
Mike Orr <slugg...@gmail.com>