Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TurboGears joins the Pylons Project

compoundthinking.com

Post reply on HN
Print view View original

11–20 of 42 posts

Re: TurboGears joins the Pylons Project

#11

Post by sankyo »

cookiecaper wrote: post #5

A bit unsettling for me. I use Pylons on several projects, though I haven't kept up with Pylons news. I really like Pylons because it was to me the best representation of the ideal framework out there; it was flexible and easy to plug in your own stuff, it was not haughty or insistent that you do things a certain way, it did not rewrite Python's whole standard library as many other frameworks practically rewrite the…

I have been digging into the pyramid docs and writing some toy apps with it trying to learn it, and I think that you will not be disappointed. I am confident that turbogears / tosca widgets will be integrated in such a way that it is loosely coupled and will not get in your way if you do not want to use it.

Spend some time reading the pyramid docs - it it totally agnostic for template engines, authentication/authorization, http session implementation, etc. very pluggable.

I will say though, that at this point 1.0alpha8, a noob will probably get frustrated, but someone who has worked with pylons / repoze / sqlalchemy can connect the dots.

Also, with every alpha release, you can also see the changes to the documentation, which is looking more like django docs (i.e. good)

Django fills a certain niche and if it matches your problem, it is a no brainer. If you need a more flexible web framework, look at pyramid.

Re: TurboGears joins the Pylons Project

#12

Post by stdbrouw »

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything.

I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to get excited about. Even the documentation for Pyramid, which at first seems beautifully comprehensive and one of the system's strong points, turns out to be an interlinking mess lacking clear explanations of even the very basics of the system.

True enough, like Pylons before it, Pyramid is anything but opinionated, which probably makes it a good base platform for the TurboGears devs, but how much will it matter when people will just shrug their shoulders after looking at the landing page, and proceed to download Django or Flask/Werkzeug or, heck, Ruby on Rails?

Anyway, regardless of my scepticism, building new stuff and starting new projects is always fun, so hopefully the Pylons project devs enjoy the process.

Re: TurboGears joins the Pylons Project

#14

Post by stdbrouw »

simonw wrote: post #13

Can anyone expand upon the benefits of repoze.bfg?

repoze.bfg used to cater mainly to people from the Zope/Plone-world — less cruft than Zope 2, easier to understand than Zope 3, but the same underlying ideas and mechanisms: object traversal for URL mapping, ZCML for configuration, an aspect-oriented vibe etc.

Ian Bicking made some interesting remarks about BFG back in 2008: http://blog.ianbicking.org/2008/11/06/where-next-for-plone-d...

Re: TurboGears joins the Pylons Project

#15

Post by clark »

stdbrouw wrote: post #12

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to g…

Nice trolling.

Re: TurboGears joins the Pylons Project

#16

Post by stdbrouw »

clark wrote: post #15
stdbrouw wrote: post #12

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to g…

Nice trolling.

I kind of expected this response, and the style of writing may be a little provoking, but I think it's a pretty factual assessment of where these projects are headed. Feel free to disagree, though.

Re: TurboGears joins the Pylons Project

#17

Post by chrism »

stdbrouw wrote: post #12

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to g…

As the author, I'm interested in improving the Pyramid docs. Can you elaborate on your issues with them? Did you notice the tutorials at http://docs.pylonshq.com/pyramid/dev/index.html#tutorials (lots of people seem to miss them).

Re: TurboGears joins the Pylons Project

#18

Post by forgotAgain »

Sorry to hear about TurboGears. When I first found it I was very excited to use it. I think they lost a lot of momentum and community trust with the changes made going from version 1 to version 2. I know after that I felt I could not use them because I had no way of knowing if version 3 would be something completely done over again.

Re: TurboGears joins the Pylons Project

#20

Post by storborg »

stdbrouw wrote: post #12

The simple fact is that the larger Python community never really cared for repoze.bfg and TurboGears. The Pylons, BFG and TurboGears teams joining forces feels more like a last, somewhat desparate move to garner some attention for projects that never reached critical mass. I don't think it'll change much of anything. I used to do development in Pylons and I've tried my hand at Pyramid, and there's simply nothing to g…

I've been steeped in Pylons for several years now. I agree that Pylons has nothing to get excited about. However, (and this is the important part) it provided really straightforward glue to integrate a few other things that are definitely worth getting excited about: SQLAlchemy, Mako/Jinja, Routes, Beaker, and Paste.

Pylons' past philosophy always seemed to be "we'll take the best-in-breed of python web software and put it together in an elegant way." Sadly, they seem to have abandoned that philosophy for the sake of protecting the precious nest eggs of massive full-stack framework developers.

While the new changes to Pylons certainly don't prevent you from using the aforementioned exceptional-quality components, the smushing-together of projects while trying to retain legacy compatibility seems to have created an enormous system where there isn't a cohesive or consistent way of doing things.

No thanks--I think I'll go for WebOb and its lightweight performance.

Post reply on HN