On Sat, 2010-11-06 at 21:07 -0700, Ev Kontsevoy wrote:
> 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.
Can't really say much more except that it's totally optional. That
should be clear from the docs.
> 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
Ben does have plans to create a package that will make this pretty
simple. It's actually even mostly done on the Pylons trunk, although we
decided to not put it into Pyramid (as its API is a based on route's
map.resource, which seemed a little weird).
> 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.
Form generation is not in the scope of Pyramid. OTOH, there are plenty
of excellent form generation packages from which to choose that work
fine with Pyramid. We (loosely, we, meaning really me and Ben, I guess)
do have intent to build higher-level frameworks with Pyramid that will
fill this role.
> 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?!?
It doesn't. Within pyramid.request:
from webob import Request as WebobRequest
class Request(WebobRequest):
....
Within pyramid.response:
from webob import Response
Response = Response # pyflakes
> 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.
@view_config(name='foo.html', renderer='templates/foo.pt')
@view_config(name='foo.json', renderer='json')
@view_config(name='foo.xml', renderer='myxmlrenderer')
def my_view(request):
return {'foo':1, 'bar':2}
> 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.
You can indeed get the request as a threadlocal in Pyramid. But you
don't *import* any threadlocals in pyramid (which is what SOPs allow you
to do).
> 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.
Can you tone it down a bit? I'm afraid your indignance is derogatory
and insulting.
- C
> On Nov 6, 10:25 pm, Eric Ongerth <ericonge...@gmail.com> 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 <eugu...@gmail.com> 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 <b...@groovie.org> 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 pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discuss+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
