On Jan 20, 2007, at 3:04 PM, Jamie wrote: > Mike Orr's post in which he mentioned Pylons as being the "hackers' > framework" is one of the most insightful posts I've read in my short > time here. Would you consider this the driving philosophy behind > Pylons?
Well, its sort of like that right now due to it being a smaller and generally rather advanced community. This isn't too say that there aren't advanced users of TurboGears and Django, there definitely are, they just don't constitute as high of a percentage of the user base. > The reason I rambled on about my background is because I wanted to > know > whether Pylons is right for someone like myself. Who is the target > audience? Are you interested in courting away PHP developers who may > not (yet) even know a lick of Python? Or, maybe even reaching as far > back beginning web developers? At the other end of the spectrum are > the > Python veterans who've used PSP and a templating system for a while > and > just want a framework to tie everything nealty together. I think Pylons can be used by everyone, from a beginner to an advanced user. As you mentioned, the docs aren't there for that right now but with the 'ideal' set of docs, I see no reason someone new to Python and web dev couldn't use Pylons rather easily. > The later group seems to be primarly focus of Pylons which is fine, of > course. However, I think that pool people is rapidly shrinking because > they're all jumping on their favorite framework bandwagon and are > likely to stick with it for a while. As for the focus, I think at the moment its focused on the advanced user because they're the ones most likely to choose a component based framework designed around flexibility and the WSGI spec. Pylons isn't designed to focus on woo'ing a specific set of developers, its built to provide a good starting point for designing web applications (based on WSGI) with the tools you (the developer) like most. Thus, things that other frameworks make hard (change default template langauge, ORM's, etc), Pylons purposely tries to make as easy as possible. This absolutely puts it at a disadvantage for documentation. I believe in the convention over configuration, so Pylons does try and provide some defaults and streamline some common tasks. I don't think it'd really work to do the, "If using SQLObject do this..." in the docs, because people are using Pylons in a lot of different ways with tools I don't know about. Finally, there's a few things we're still refactoring in Pylons before 1.0. It's quite likely a decent amount of documentation will need changing, which makes it even less of a payoff from a developer standpoint to write. Should we write docs or fix things and add features? It's a tough trade-off, and so far we've been focused mostly on fixing things and trying to get everything polished for an extremely solid core for 1.0. Since SQLAlchemy, Mako, Myghty, and many of the parts behind Pylons do have extensive documentation the docs we've put in Pylons try to focus on not repeating them. If you want a framework that can grow with your needs without burying you in complexity (WSGI keeps a lot of things simple), I think you'd be hard pressed to beat Pylons in the Python web world. 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 -~----------~----~----~----~------~----~------~--~---
