Eric,
I have spent half of my saturday to read every single page on
http://docs.pylonshq.com/pyramid/dev and I am not seeing anything
pragmatically beneficial there compared to Pylons 1.0
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.
Pyramid does not address this at all. Its just a bunch of class/method
renames without obvious pragmatic benefit.
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!"
- how's that helping? Both Pylons and Pyramid introductory pages say
something "we have looked at Django, Rails and XXX and combined the
best YYYY in ZZZ..." 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? 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.
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. People don't use
truckloads of XML to define those basic CRUD routes and views, not in
2010
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.
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?!?
I can go on and on and on - I have read Pyramid docs. They're already
obsolete, just look at this:
@view_config(renderer='templates/foo.pt')
def my_view(request):
return {'foo':1, 'bar':2}
So now if I need to return XML or JSON I need another view? Again, if
you claim you "borrowed best of rails", I invite you to take a look at
how Rails-3 does it:
def my_view()
respond_with {'foo' => 1, 'bar' => 2}
end
And works great for /my_view.xml, /my_view.json and /my_view.html all
at the same time. I guess you will use that as an excuse to throw away
Pyramid and launch Pyramid-2 based on something entirely different 2
years down the road.
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.
Ughh... This feels like a step backwards. Honestly, using barebone
Paste looks like a best web framework right now. I wonder if Ian had
anything to say about Pylons development vector.
I suspect quite a few Pylons folks will be unhappy. We already saw (!)
Repoze when we were picking our framework. And we didn't like it. We
preferred Pylons. See, we already voted! I don't want XML junk or
built-in authentication even if they're optional. I want a powerful
glue between declaring resources that bind views/models/controllers
together, based on common conventions as opposed to low level
decorators, XML diarrhea or "imeratve" add_view() assmebly. That's
just as low level as basic Paste which is small and nice.
On Nov 6, 10:25 pm, Eric Ongerth <[email protected]> wrote:
> Ev,
>
> Surely you read enough of the docs to see that all declarative
> configuration in Pyramid is optional? The option to configure
> everything nearly the same as Pylons currently does it is right there
> and it is given equal treatment.
>
> Why do you describe the current plans as "killing Pylons" when Pylons
> will continue to be fully functional through Pyramid?
>
> Eric
>
> On Nov 6, 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".
>
> > Not loving Pyramid at all. It's not bad, but it needed to be AMAZING
> > to justify killing Pylons. Sorry to say this, but Pyramid is not it.
>
> > 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.
>
> > Please, please please: stay away from Repoze guys. :-) They're bad
> > influence. Don't pick up the phone when they call. You have a much
> > nicer framework (Pylons). You have users who love you. Don't push us
> > away!!! :)
>
> > Cheers,
> > ev
>
> > On Nov 6, 2:30 pm, Ben Bangert <[email protected]> wrote:
>
> > > Some people have been concerned lately regarding the status of the Pylons
> > > framework in light of new effort being spent around additions to Pyramid.
> > > I
> > > thought it'd be useful to help assuage those fears, and explain a bit more
> > > about the Pylons code-base.
>
> > > Pylons 1.0 was released 6 months ago, in May of 2010. Between 1.0 and
> > > 0.9.7,
> > > which were released over a year earlier in Feb. of 2009, there were
> > > almost no
> > > changes to Pylons besides deprecated bits being removed, and a few
> > > defaults
> > > changing. Most new features instead came from changes to Beaker,
> > > SQLAlchemy,
> > > WebHelpers, and occasionally Routes.
>
> > > Beaker, SQLAlchemy, Mako, and WebHelpers are unaffected by Pyramid: they
> > > continue to work as they have. Pyramid can use most of these packages just
> > > like the Pylons framework can. (A few webhelpers are currently
> > > incompatible
> > > with Pyramid: see pylons-devel). As these packages are also where most of
> > > the
> > > feature improvements for Pylons framework users came from, again, there's
> > > no
> > > change in that!
>
> > > Nothing is changing regarding the Pylons 1.x code-base from how it has
> > > been
> > > for the past year and a half. It is a mature and stable code-base that
> > > meets
> > > many people's needs. There's no reason to feel bummed or sad that it is
> > > somehow 'dead' or 'end-of-life'. It will continue to receive the same bug
> > > fixes and security fixes that it has been getting for the past 18 months,
> > > in
> > > perpetuity.
>
> > > Pyramid really only affects where myself and some other Pylons developers
> > > will
> > > be spending our future development efforts. As a stable and mature
> > > code-base,
> > > the Pylons framework has required a lot less of my attention lately, so my
> > > current development time spent on it has already dropped quite low. The
> > > development time I spend on the Pylons framework is not changing. With
> > > that
> > > freed up time -- and additional developers through this merger -- we can
> > > spend
> > > more effort and resources pushing ahead with Pyramid-related development.
> > > One
> > > thing we're doing is increasing our scope to tackle larger problems that
> > > were
> > > beyond the scope of the Pylons framework.
>
> > > The existing amount of time I've been spending on the Pylons code-base
> > > for the
> > > past 6+ months is not changing. The Pylons 1.x code-base is not changing,
> > > apps
> > > using it will continue to run. But with a larger development effort,
> > > we'll be
> > > able to build some useful additions that should help people whose needs
> > > haven't been completely met by the Pylons framework.
>
> > > Cheers,
> > > Ben
--
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.
