On 4/6/07, Brendan Arnold <[EMAIL PROTECTED]> wrote: > I realise that the Pylons team have done a great job of allowing > Pylons to work with multiple templating engines, database interfaces > etc. but doesn't this kind of go against the One True Way philosophy > of Python? It seems completely backwards to me that Rails is based on > a language that borrows more than a little from Perl and is pretty > free-form, although Pylons is a free-form framework based such a > 'railed' language as Python.
Practicality has to beat purity. Users need a robust out-of-the-box configuration *and* maximum flexibility. All the libraries Pylons depends on are evolving too, and what may seem the best choice this year may not be so next year. (This has already happened re template libraries, SQL ORMs, and probably form and Javascript libraries.) Plus the default libraries may not work for your application or environment: should you therefore be excluded from Pylons? What if that means rewriting your application from scratch? Pylons and TurboGears approach this from opposite directions. TG tried a strict One Way approach and found it unworkable. Pylons is based on Paste, which exists precisely for flexibility, and that's what attracts most Pylons users. Users in both camps are clamoring for access to the same choice of libraries, and that's making the two frameworks more similar. Pylons developers recognize the need for full-stack out-of-the-box support and beginners' docs, but given their philosophy and personal interests they're a bit slower to get it done than other frameworks are.... Rails is getting a lot of beginning users who want the decisions made for them. Pythoneers are too creative and obstinate. They'll advocate One Way if it's obviously superior to the competition (numpy) or can be built on (datetime), but not in e.g., web frameworks where the best design has not yet emerged or there are diverse philosophies. Web programming may be just too big and complicated to reduce to one framework. Other languages do, but they don't have the asynchronous Twisted fans or Zope fans or Pylons fans, who wouldn't touch their stinking language with a ten-foot pole. And hey, Zope sometimes produces some good libraries for the rest of us (ZODB, ZPT, interfaces), and Twisted keeps promising it'll do the same Real Soon Now. :) > Some suggestions: > > o By default, set the paste-script template to be configured for a > database driven application that uses SQLAlchemy and Mako. That's the plan for 0.9.5, though I expect the SQLAlchemy lines will remain commented. If you have to write your tables anyway, it's no more work to also uncomment the lines that say "Uncomment me for SQLAlchemy". > No need to define the imports and initialise the models. Would allow > users to simply define Table classes. No need to define the whats??? How is your proposal different from the situation now? It's widely recognized that out-of-the-box database initialization needs to be improved. Too many users including me have had to spend too much time trying to get the database to work, or to pass options to SQLAlchemy. People are stressing over whether to use bound MetaData or unbound MetaData, whether to keep the Session even if they're not doing ORM, or how to set an option like 'echo_pool' or timeout or auto retry. The holdup is mainly in deciding on the best way to accomplish this. > Other templates could be > accommodated for using different paste-script templates. Perhaps, though it's only 1-3 lines to change in middleware.py. But an app template could come with a sample index template and site template with a $title placeholder. But this would only work if all other factors were equal (no alternate database configurations), because Paste's template selection is one-dimensional. You don't want to get into pylons-genshi-sqlalchemy, pylons-cheetah-durus, pylons-mako-nodatabase, etc. > o Encourage easy internationalisation > > At the moment the i18n folder contains one empty file. Do we create > language plugins (i.e. en.py) with a dict in a utf-8 text file which > could be referenced globally in the app? If so, how? The docs would > tell us the One True Way, would always deal with strings as unicode > and include config parameters for switching - I don't mind writing a > few extra functions, even if I don't intend on deploying elsewhere so > long as it was clear and consistent. I think the infrastructure is there, the docs just haven't caught up. There's definitely a plan for an i18n chapter in the Pylons manual. Feel free to ask questions on this list. > o Config variable available automatically > > No need to import the CONFIG variable, would be automatically > available in a global namespace. You mean putting it in __builtins__? If we did that we should potentially put c, g, h, model, request, session... where does it end? Pylons is already magical enough with its special globals and StackedObjectProxies. The controllers already have all these values courtesy of "from myapp.lib.base import *". I guess we can promote that line as "the easy way to get everything". But the bigger problem is CONFIG not being initialized in many common cases; e.g., importing 'models' to debug it, importing test modules, early in middleware.py or things it calls, etc. You have to do several manual steps to initialize CONFIG in these cases (or use the app_globals dict directly if you have access to it), along with whatever other undocumented steps are necessary to get everything initialized, and that's several steps too many. We're still trying to figure out how to improve this. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
