Re: New project . Pylons or Pyramid
+1. If I chose Pylons over Django and TurboGears (not to mention Rails) for its flexibility, light weight, and pluggability, Pyramid offers more of those qualities than Pylons and with better docs, plus built-in authorization/authentication support rather than the Pylons situation with that. On Mar 9, 8:56 pm, Iain Duncan iainduncanli...@gmail.com wrote: Another vote to start with Pyramid. I've been using 'it' since repoze.bfg 1.1 and am constantly being pleasantly surprised. Now that there is a bigger development community, even more docs, and more beginner friendly additions, I can't think of any reason not to use it right away. iain On Fri, Mar 4, 2011 at 4:42 PM, Mengu whalb...@gmail.com wrote: sure you can start with pyramid. pyramid 1.0 is already production ready with its awesome docs. On Mar 4, 5:10 am, Ravi ravi.gidw...@gmail.com wrote: Hi Group: I have started a new web based project and it is in its early stage. So with pylons merging with pyramids, I have two questions: 1) do you all suggest starting with Pyramids ? Or shall I wait for some more months ? 2) Are there any DO/DON'T that I should follow for make sure I have easy migration from pylons 1.0 to pyramid. -- About my web application: 1) Web based application. 2) Currently using Jinja2 template engine. 3) Will use session, cache. 4) Most of the data will be fetched using a REST based APIs which are not part of this application. 5) Will need to support a user base of atleast 100,000 users. 6) Will have usual registration/profile kind of forms and validations and may be few more forms. -- I have already seen the pylons FAQ ( http://docs.pylonsproject.org/faq/pyramid.html#should-i-port-my-pylon...), but will like hear from you all. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
What's the best way to optimize database connections in Pyramid?
I was advised a while back by someone to throw my MongoDB connection call into a pyramid.events.NewRequest subscriber. However, this has proven to be a bad idea because the NewRequest subscriber gets called even if the request is a static_route request, and since the event.request object in the NewRequest subscriber doesn't have a matched_route attribute, there's no bullet-proof way to filter those out. How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? Thanks, Seth -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Pyramid 2 ideas
In discussing with chrism and Ian Bicking porting Pyramid to Python 3, it became clear that we might want to do some other changes at the same time, enough to warrant a new major version, aka Pyramid 2. I've outlined the ideas on the following wiki page: https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm These are just some ideas for discussion; we're not committing to any of them at this point. If you have other ideas let's get them on the list. Part of the reason for doing this is to determine which projects we might want to offer to Google Summer of Code students. Here's a summary of the ideas on the wiki page: - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below. - Replace Paste, PasteDeploy, and PasteScript with something. - paster create can be extracted to a new utility, either a top-level script or a subcommand. The code could do with some modernization. - paster create can likewise be extracted to a new utility. - Rename application templates to application skeletons to avoid confusion with file templates. - Possible new names for Paster and its components: glue (Glue is the new Paste!), Create, Serve, karnak. - Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine code and give better names. - Replace the INI file with an YAML file? - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in Pyramid. Some of these are more properly dependencies of the specific applications which are using them. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: What's the best way to optimize database connections in Pyramid?
Hi On Sun, Mar 13, 2011 at 5:54 AM, Seth seedifferen...@gmail.com wrote: [snip] How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? I usually try to stick to a connection that is always on environ. You'd have a wsgi middleware that always try to get the connection from the threadinglocal and expose that under some environ key, say, 'conn.mongo'. If the middleware fails to get that from the thread, you'd create another connection and then re-expose it under the same key. Regards, Fernando -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: What's the best way to optimize database connections in Pyramid?
I've been a fan of tacking the connection onto the request object using @reify, thus if your request never calls request.db it doesn't have any db overhead. Thanks to reify, it reuses the same connection throughout that request. If you want to ensure that the connection is closed at the end of the request, you can also add a finished_callback to handle that. class MyRequest(Request): @reify def db(self): # do stuff to get connection either from middleware in previous email # or actually create a connection conn = # optional: add callback to cleanup after request is complete def _cleanup(request): conn.close() self.add_finished_callback(_cleanup) return conn The cleanup and things is handled by repoze.tm2 if using something like SQLAlchemy with the ZopeTransactionExtension, but otherwise you'll probably want to handle it yourself. Michael On Sun, Mar 13, 2011 at 8:54 AM, Fernando Correa Neto fcd...@gmail.comwrote: Hi On Sun, Mar 13, 2011 at 5:54 AM, Seth seedifferen...@gmail.com wrote: [snip] How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? I usually try to stick to a connection that is always on environ. You'd have a wsgi middleware that always try to get the connection from the threadinglocal and expose that under some environ key, say, 'conn.mongo'. If the middleware fails to get that from the thread, you'd create another connection and then re-expose it under the same key. Regards, Fernando -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: What's the best way to optimize database connections in Pyramid?
When failing to get it from the thread is that always because the connection is closed or could it also be because some other thread had locked the previously opened connection? On Sun, Mar 13, 2011 at 9:54 PM, Fernando Correa Neto fcd...@gmail.com wrote: Hi On Sun, Mar 13, 2011 at 5:54 AM, Seth seedifferen...@gmail.com wrote: [snip] How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? I usually try to stick to a connection that is always on environ. You'd have a wsgi middleware that always try to get the connection from the threadinglocal and expose that under some environ key, say, 'conn.mongo'. If the middleware fails to get that from the thread, you'd create another connection and then re-expose it under the same key. Regards, Fernando -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- med venlig hilsen / with kind regards Jørgen G. Jørgensen. --- -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 2 ideas
i like ini files so much better than yaml. i realize it is brainstorming at this point, but is there any killer feature of yaml or something? -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: What's the best way to optimize database connections in Pyramid?
Perhaps I am missing something here but why would you serve static files from your Pyramid app? Why don't you serve the static files by the webserver directly? As for MongoDB, how about a wrapper around the pymongo classes/objects and use lazy connectors, ie. do the actual connection only if one does not exist in the thread, whenever a pymongo method is called? Vlad On 03/13/2011 09:54 AM, Seth wrote: I was advised a while back by someone to throw my MongoDB connection call into a pyramid.events.NewRequest subscriber. However, this has proven to be a bad idea because the NewRequest subscriber gets called even if the request is a static_route request, and since the event.request object in the NewRequest subscriber doesn't have a matched_route attribute, there's no bullet-proof way to filter those out. How are other people connecting to a db with high-traffic sites using Pyramid and avoiding the static_route re-connection nonsense? Perhaps we could request to get a matched_route object on the NewRequest event object? Thanks, Seth -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 2 ideas
On Sun, Mar 13, 2011 at 11:25 AM, Thomas G. Willis tom.wil...@gmail.com wrote: thanks for the info. i guess I'm thinking if you need something to support such a complex configuration that an ini file can't handle it, aren't you programming at that point and if so, why not use a real programming language? in java they does this stuff all the time. I know that the line is pretty blurry between code and configuration, but my guide has always been if it's versioned in your vc repo, it's code. just thinking out loud, but I like the simplicity of an INI other than that, python makes a nice dsl for that kind of stuff too, one of the few things I like about django is the settings.py(hate the import magic though) There's nothing fatal about INI but it has three limitations: - Can't express types other than strings. Can't express dicts/lists. External routines have to parse these (asbool, sqlalchemy.engine_from_config). - Rigid two-level structure, can't express hierarchies. - It's not really a multi-language standard as it claims to be: there is no formal definition of which characters are allowed. I was surprised when Paste started using keys containing ':'. - Sucky ConfigParser (although it's improved in Python 2.7/3.2) Its main advantages are: - Less verbose than a Python module of scalar assignments, where you have to quote the strings and can't have sections (unless you use classes for them, but then you have the class keyword). - Easier for sysadmins who don't know Python to maintain the file; they don't have to learn Python quoting rules. There's a feeling among some developers and many (but not all) users that INI's disadvantages may be outweighing its advantages. YAML can express all the things ppl wish the config file had. It can also express a full ZCA configuration, which would allow the same file to do app configuration, logging, and component configuration without using ZCML. That's what Marco was, a YAML-based version of PasteDeploy. Its development was halted but parts of it could be revived for a new tool. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Pyramid 2 ideas
On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor al...@gothcandy.com wrote: Howdy! - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below. This is not just a good idea, it's the slaw; with the ratification of PEP there finally exists a standard protocol for Python 3 support. - Replace Paste, PasteDeploy, and PasteScript with something. - paster create can be extracted to a new utility, either a top-level script or a subcommand. The code could do with some modernization. - Rename application templates to application skeletons to avoid confusion with file templates. - Possible new names for Paster and its components: glue (Glue is the new Paste!), Create, Serve, karnak. - Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine code and give better names. - Replace the INI file with an YAML file? Marrow is my namespaced meta-framework rewrite of Paste, WebOb, and other utilities. I'll add it to the list. Although I'm hoping to move away from namespace packages, as Paste as done. They have already caused practical problems in that you can't install part of a namespace package as OS packages and part as virtualenv packages. We can't get away from Zope's namespace package but I think we can avoid it where it's unnecessary. Nevertheless I'll add Marrow to the list in case it turns out to be the best meta-framework otherwise. * marrow.wsgi.objects (WebOb) request/response/exceptions These are fully WebOb compatible? WebOb has become essentially the only multi-framework Request/Response, so I dont' want to interfere with it becoming a standard. It's easier to program in WebOb than raw WSGI. - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in Pyramid. Some of these are more properly dependencies of the specific applications which are using them. There exists a package called alacarte which offers a back-end agnostic templating interface. It already supports Mako, Jinja2, and a handful of others, including serialization formats like JSON, Bencode, and YAML. It was built to replace the ancient (and crufty) TurboGears 1 buffet API. Does it require an entry point for each templage engine as Buffet does? That's what we ultimately removed from Pylons because it was a level of indirection and complexity that wasn't really necessary. -- Mike Orr sluggos...@gmail.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
