route_url and query params
request.route_url() doesn't convert extra args to query params. Is
this intentional? If so, it's another difference from pylons.url().
$ paster pshell development.ini Zzz
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39)
[GCC 4.4.5] on linux2
Type "help" for more information. "root" is the Pyramid app root object.
>>> req = pyramid.threadlocal.get_current_request()
>>> req.route_url("main", action="pony")
'http://localhost/pony'
>>> req.route_url("main", action="pony", horn=1)
'http://localhost/pony'
>>> req.route_url("main", action="pony", horn="1")
'http://localhost/pony'
--
Mike Orr
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@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: Pylons , Pyramid which is better
On Tue, Dec 28, 2010 at 10:33 AM, AbdAllah Ahmed wrote: > Hi, I Asked this qeustion before in StackOverFlow but i'm still > missed : > > Now there is Pylons 1.0 and Pyramid alpha release and TurboGear will > be apart of Pylons > > Will Pylons Continue after the final release of pyramid 1 or not ? , Pyramid is the new name for Pylons 2. Pylons 1 will have bugfixes and security fixes and some feature backports from Pyramid, but whether it will add features depends on if somebody wants to do the work. The Pylons, BFG, and TurboGears projects have merged under the name "the Pylons project". The codebase comes from BFG with Pylons and TG features added on. > whcih is better ? , what are the differences ? That's a long answer. Pyramid has a more flexible architecture, but it's still in alpha and it's definitely a transition for Pylons users. There is not yet a point-by-point comparison between the two. Look over the pylons-devel and pylons-discuss archive and the main differences will emerge. (Keep in mind that messages in early November were from when Pyramid was brand new, so some of the things said about it are either out of date or inaccurate.) -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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 1.0a8 released
On Tue, Dec 28, 2010 at 2:48 PM, Seth wrote: > Chris, > My apologies, the 2nd issue was because I took > out config.begin()/config.end() from my unittest setUp/tearDown methods > because I thought they were no longer required. Adding them back causes the > tests to pass. I thought they were obsolete too, but the application templates still have them in the tests. So are they obsolete or not? -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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 1.0a8 released
On Wed, Dec 29, 2010 at 1:28 PM, Marius Gedminas wrote: > On Wed, Dec 29, 2010 at 10:56:29AM -0800, Seth wrote: > The docs say that messages don't have to be strings, so you can do > exactly that, if you push dicts like this: > > request.session.flash(dict(message='Hello!', queue='welcome')). > > Or you could push tuples. Or a custom subclass of unicode with a > 'css_class' attribute -- just make sure it's pickleable. Hi there. I wrote the flash code for WebHelpers, then somebody (I can't remember who) asked for categories and we expanded it, then I adapted it forPyramid's central session object, and Chris modified it to the current version. It has multiple queues because the WebHelpers concept of multiple Flash objects is non-viable with the flash integrated into he session. I initially kept categories, but then Chris and I decided to drop them because queues cover almost the same purpose. The only thing you can't do without categories is to mix them (i.e., display an INFO then DEBUG then ERROR then INFO, in whatever order the messages were pushed). It seemed unlikely people would want to do that anyway for web display; rather they'd want to show all the errors first, then the infos, then the debugs, which you can do with multiple queues. The messages are intended to be strings, but this is not enforced. I couldn't think of any specific use case for non-string messages, but users always come up with unanticipated uses so I didn't want to prevent those. (Queue names have to be strings because they're concatenated to a constant string to create a session key.) If there's a need for additional features, we can consider adding them. I'm not sure what Seth is asking. "a method which returns *any* flash message from any queue". So you want the messages returned in creation order tagged with their queue name? This would be the same as "categories" which I described above, which is not implemented because it seemed like too much complexity for too little value. It sounds like Marius' suggestion is a suitable workaround, using one queue and pushing an object that contains both a message and a category. I think you can build a higher-level API to make that convenient. If you need some kind of helper method or something in the core, let us know and we'll consider it. PS. Chris added the '.peek_flashes' method. I didn't see the use for it, but again it's there for unanticipated use cases. I usually do "if peek_flashes; for msg in pop_flashes" as "<% messages = request.session.pop_flashes() %> %if messages:" . -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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 1.0a8 released
On Thu, Dec 30, 2010 at 9:17 AM, Seth wrote: > Thanks for all the input and I suppose Marius' answer is the most > straightforward solution. Perhaps I was expecting something a little more > like Mike's "category" style implementation, b Credit to Eli Collins for the implementation. > but I can see how that could > become "too much complexity for too little value." > With regards to the peek_flash method: If one is using a templating system > that allows python code in the template logic, this would likely be > unnecessary; but for templates that only give you basic stuff like loops, > tests, and prints, the peek method is needed for truth testing and multiple > "non-loop" prints (i.e. printing different key/value pairs as in Marius' > example). My first reaction is it's inefficient, but that's just because of the WebHelpers situation. In Pyramid it's a just a session.get(KEY, []). In WebHelpers it creates a list of Message instances. (The messages are stored as a tuple in the session, because Eli said object unpickling may be unreliable in edge cases.) -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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: Serving static index.html from /
On Wed, Jan 5, 2011 at 10:23 AM, Dominik wrote:
> Hi Chris,
>
>> We have a "cookbook" in the works that describes how to do something
>> like this. Here's a sneak peek:
>>
>> http://plope.com/static/pyramid_cookbook/static.html#root-relative-cu...
>
> Yes, thanks - I found something similar in the "Serving Static Assets"
> documentation [1]. However, if I understood correctly, this still
> wouldn't help for the standard case of responding to request to "/"
> with the static "index.html", like apache does for example for
> index.htm(l)/php/cgi etc. Any ideas?
>
> The whole static stuff seems very hacky for me, examples:
> 1) from the same page: [1] "The special name *subpath above is used by
> the pyramid.view.static view callable to signify the path of the file
> relative to the directory you’re serving."
> 2) The special purpose of the "name" attribute of the static view.
> 3) The double meaning of add_static_view depending on the first
> parameter (i.e. in the external host case)
>
> I wish this would be cleaned up some day, more consistent and more
> intuitive to understand.
I'm testing an application template that serves static files from "/"
and has a SQLAlchemy configuration (coming soon). This is working for
me:
from pyramid.view import static
# Set up routes and views
config.add_handler('home', '/', '{{package}}.handlers:MainHandler',
action='index')
config.add_handler('main', '/{action}', '{{package}}.handlers:MainHandler',
path_info=r'/(?!favicon\.ico|robots\.txt|w3c)')
config.add_route('static', '/*subpath', static('{{package}}:static'))
The first line is a regular home route for "/".
The second line handles "/{action}", but it has to exclude top-level
static files which would be mistaken for actions. (The path_info regex
doesn't match /favicon.ico, /robots.txt, or /w3c.)
The third line is a catchall route for all other URLs, which goes to
the static directory. The static() function creates a static view. But
Chris has said this will disable traversal, so I need to make a route
predicate function so that the route matches only if the file exists.
But if you don't need traversal, you can use this as-is.
--
Mike Orr
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@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.
Testing an application template
Chris, How do you test an application template in Pyramid? You said you had unit tests for them, which I didn't think was feasable. But I don't see any test module that does it, not test_paster or test_testing or test_scripting which seemed closest. But I do see several premade applications in the tests directory, which don't seem to have their own tests. Are these apps for other tests to use? -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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_sqla initial release
The ``pyramid_sqla`` package version 0.1 has been released. It contains a library for SQLAlchemy access and an application template closer to Pylons 1 than those that come with Pyramid. This is an alpha release for community testing and feedback; the API is not guaranteed to be stable yet. My goal is a 1.0 release before Pyramid 1.0. The ``pyramid_sqla`` package (installed in site-packages) replaces the 'meta.py' module in Pylons 1 applications, allowing 'models' to be a package without circular imports. A basic script to create tables is included. The application template serves static files from "/" like Pylons does, using special route options to make this an ordinary route without masking your dynamic URLs or traversal. This allows you to deal with /favicon.ico and /robots.txt the same way as your other static files. The application template also includes a helpers.py module tied to the ``h`` template variable, serves *.html templates via Mako (configurable), has a full logging configuration in development.ini including a logger for the application package, and listens on 127.0.0.1:5000 by default. It also includes a basic script to create database tables, akin to 'websetup.py' in Pylons 1 applications. My goal is a 1.0 release before Pyramid 1.0. Pyramid's application templates will be consolidated down to one without SQLAlchemy, and this will be the add-on template for SQLAlchemy/Pylons-like applications. I discussed with Ben how to migrate from Pylons 1's meta.py, and we came up with this approach of a library holding the scoped session, a collection of engines, and a declarative base, all accessed by accessor functions. This avoids circular dependencies in package-format models, and allows the maximum part of the model to be defined at model level (always importable) rather than in ``init_model()``. A few scenarios --namely reflection -- will still require ``init_model()``, unless you can guarantee that the library is initialized before the the model is imported -- but there's no way around that. In ordinary use that shouldn't matter because myapp/__init__.py configures the engines before the model is imported, but Nosetests imports modules willy-nilly looking for tests. I think this configuration is robust enough for Nosetests, but that needs more testing. So please send feedback. Version:0.1, released 2011-01-12 Docs: https://bitbucket.org/sluggo/pyramid_sqla/wiki/html/index.html Download: http://pypi.python.org/packages/source/p/pyramid_sqla/pyramid_sqla-0.1.tar.gz PyPI: http://pypi.python.org/pypi/pyramid_sqla Source: http://bitbucket.org/sluggo/pyramid_sqla (Mercurial) -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-de...@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 for Pylons users guide
Hi all, I'm starting an article on Pyramid for Pylons 1 users, focusing on the differences between the frameworks and how to do familiar things in Pyramid. It'll also cover add-on stuff like forms and auth, or at least list the alternatives available. I'm wondering if there are any particular questions people would like included. If so, please email them to me. -- Mike Orr -- 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 for Pylons users guide
On Fri, Jan 14, 2011 at 9:09 PM, Alice Bevan–McGregor wrote: > On 2011-01-14 19:53:58 -0800, Mike Orr said: > >> Hi all, I'm starting an article on Pyramid for Pylons 1 users, >> focusing on the differences between the frameworks and how to do >> familiar things in Pyramid. It'll also cover add-on stuff like forms >> and auth, or at least list the alternatives available. >> >> I'm wondering if there are any particular questions people would like >> included. If so, please email them to me. >> >> -- >> Mike Orr > > Here's a good question for inclusion: > > Other than the additional step of resolving the 'view' associated with a > 'resource', which seems like a great idea, how does dictionary-based > resource resolution differ from object dispatch? > > From what I've seen in blog posts—overriding the dictionary lookup method—it > seems a little too close to object dispatch where you have straight-up > attribute lookup—allowing override using __getattr__ and usually some > combination of __default__ (effectively __getattr__ with extra arguments) > and __lookup__ (redirecting the dispatch by returning a new object to > inspect). I don't understand traversal enough to answer that. I'll try to figure it out from the new traversal chapter in the Pyramid manual. Maybe somebody who knows traversal can send me a couple paragraphs for inclusion. Regarding John's helpers question, the pyramid_sqla application template I released a couple days ago has a helpers.py module tied to an 'h' template variable. -- Mike Orr -- 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.
Form handling in Pyramid
nt page (GET). So different URLs for form and submission require two views. Most people have kept the two-view approach with @validate even for non-REST forms. I think it would be best to support both approaches, two-view and one-view. One thing I was concerned about in pyramid_simpleform (http://packages.python.org/pyramid_simpleform/) is that the view handler has the form view and submission view that look almost the same. It's like one could go to either URL? What's the purpose of this, and how does it handle the case of failed validation? Anyway, if you have any ideas on what should be in the Pyramid-Pylons form howto (which will probably be the Pyramid form howto too, since there isn't one of those I could find), now's the time to speak up. -- Mike Orr -- 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 1.0a10 released
On Tue, Jan 18, 2011 at 12:33 PM, Chris McDonough wrote: > Pyramid 1.0a10 has been released. > > - The "add_handler" method of the Configurator has been > "externalized". When you upgrade to Pyramid 1.0a10, > the "add_handler" method will stop working. To make it > work again, add a dependency named "pyramid_handlers" > to your Pyramid application's "setup.py" "install_requires" > list, or install "pyramid_handlers" by hand. Then follow > the instructions described at > http://docs.pylonsproject.org/projects/pyramid_handlers/dev/#setup > > Once this step is accomplished, config.add_handler will > work again. Released pyramid_sqla 0.2 to reflect this. Applications made with pyramid_sqla 0.1 will not work with 1.0a10 until you apply this change. -- Mike Orr -- 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 1.0a10 released
On Thu, Jan 20, 2011 at 2:43 AM, Eric Lemoine wrote: > On Thu, Jan 20, 2011 at 11:02 AM, Wichert Akkerman wrote: >> Does pyramid_sqla have any documentation? I couldn't find anything on pypi >> or pylonsproject.org. > > It's linked on <http://pypi.python.org/pypi/pyramid_sqla/0.1>. > > <https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/index.html> Bitbucket doesn't have a good place for documentation so I put it in the project wiki. Static files in the wiki have this different URL (bytebucket.org). I may set up a site on docs.python.org at some point. -- Mike Orr -- 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 1.0a10 released
On Thu, Jan 20, 2011 at 2:49 PM, Wichert Akkerman wrote: > On 2011-1-20 19:49, Mike Orr wrote: >> >> On Thu, Jan 20, 2011 at 2:43 AM, Eric Lemoine >> wrote: >>> >>> On Thu, Jan 20, 2011 at 11:02 AM, Wichert Akkerman >>> wrote: >>>> >>>> Does pyramid_sqla have any documentation? I couldn't find anything on >>>> pypi >>>> or pylonsproject.org. >>> >>> It's linked on<http://pypi.python.org/pypi/pyramid_sqla/0.1>. >>> >>> <https://bytebucket.org/sluggo/pyramid_sqla/wiki/html/index.html> >> >> Bitbucket doesn't have a good place for documentation so I put it in >> the project wiki. Static files in the wiki have this different URL >> (bytebucket.org). I may set up a site on docs.python.org at some >> point. > > Could you turn it into sphinx docs so it can be added to pylonsproject.org > along with the other docs? That would make the package and its documentation > more accessible. It is Sphinx docs. I just haven't gotten the hang of Git yet. -- Mike Orr -- 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: Form handling in Pyramid
How does Pyramid handle HTTP method tunneling? Where the formal method is POST and the actual method is in a '_method' param? it's not really a form library issue because you'd want it uniform across all libraries. How does Pylons do it? Is it in WebOb? Is it something we need to add? -- Mike Orr -- 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: Form handling in Pyramid
It's a tradition in Pylons to use the Atom REST protocol for model objects with add/modify/delete forms. I've been half questioning that myself because there's little advantage if all the clients are interactive web browsers. But regardless of whether it's been oversold, it's the way most Pylons users do their forms, so it needs a straightforward migration path. WebHelpers form() helper automatically converts the method if it's not POST or GET, and a lot of people will be using that and expecting it to be converted back for their routes. On Fri, Jan 21, 2011 at 12:05 PM, Chris McDonough wrote: > It doesn't handle it. I need to see credible examples use cases for it, > I think. > > Various folks have wanted to add e.g. name="_method" value="PUT"/> to a Pyramid form post in my tenure in > #pylons, but it's beyond me why someone would try to be emulating a > "REST client" when using a browser, as the access patterns and expected > responses for REST APIs are dramatically different than those of a user > using a browser (authentication is usually different, usually REST > methods don't return HTML, etc). > > - C > > On Fri, 2011-01-21 at 11:55 -0800, Mike Orr wrote: >> How does Pyramid handle HTTP method tunneling? Where the formal method >> is POST and the actual method is in a '_method' param? it's not really >> a form library issue because you'd want it uniform across all >> libraries. How does Pylons do it? Is it in WebOb? Is it something we >> need to add? >> >> -- >> Mike Orr >> > > > -- > 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. > > -- Mike Orr -- 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: Form handling in Pyramid
On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough wrote: > On Fri, 2011-01-21 at 12:13 -0800, Daniel Holth wrote: >> I always setup two view functions, one for GET and one for POST. >> >> I don't do PUT, but if you want Pyramid lets you condition a view on >> both the request method and parameters. The second function should >> only be called for a PUT, or a POST with _method=PUT in the >> parameters: >> >> def some_method(request): >> # handle everything else >> >> def some_method_PUT(request): >> # handle the PUT >> >> ... >> >> config.add_view(some_method) >> config.add_view(some_method_PUT, request_method='PUT') >> config.add_view(some_method_PUT, request_method='POST', >> request_param="_method=PUT") > > True, I guess we handle it already by default, so unless there's some > usage pattern I don't understand (likely), we don't really need to argue > about supporting it or not. We at least need to document it as a FAQ, and mention it in the routing section and view section. This syntax does make the routes less straightforward (they show the low-level details rather than the high-level intention). If the application is expecting both tunneled PUT and direct PUT, it will have to accomodate both possibilities. And views will also have to handle tunneled PUT themselves because it won't be converted. (Although that could be done in the view handler .__init__, but that's kind of a band-aid approach because it covers only the views and not the routes.) -- Mike Orr -- 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: Form handling in Pyramid
On Fri, Jan 21, 2011 at 11:55 AM, Mike Orr wrote: > How does Pyramid handle HTTP method tunneling? Where the formal method > is POST and the actual method is in a '_method' param? it's not really > a form library issue because you'd want it uniform across all > libraries. How does Pylons do it? Pylons does it in the Routes middleware (routes.middleware.RoutesMiddleware). There's a constructor arg 'use_method_override', default true. -- Mike Orr -- 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: Form handling in Pyramid
On Fri, Jan 21, 2011 at 12:38 PM, Chris McDonough wrote: > On Fri, 2011-01-21 at 12:30 -0800, Mike Orr wrote: >> On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough wrote: >> >> config.add_view(some_method) >> >> config.add_view(some_method_PUT, request_method='PUT') >> >> config.add_view(some_method_PUT, request_method='POST', >> >> request_param="_method=PUT") >> > >> > True, I guess we handle it already by default, so unless there's some >> > usage pattern I don't understand (likely), we don't really need to argue >> > about supporting it or not. >> >> We at least need to document it as a FAQ, and mention it in the >> routing section and view section. > > It could and probably should be a cookbook entry. > >> This syntax does make the routes less straightforward (they show the >> low-level details rather than the high-level intention). If the >> application is expecting both tunneled PUT and direct PUT, it will >> have to accomodate both possibilities. And views will also have to >> handle tunneled PUT themselves because it won't be converted. >> (Although that could be done in the view handler .__init__, but that's >> kind of a band-aid approach because it covers only the views and not >> the routes.) > > What is the distinction you're trying to make between "PUT" and > "tunneled PUT"? Are you saying that a view should return something > different to a browser client than to a non-browser client based on > whether the _method param exists? I'm saying that a PUT-capable client will send a real PUT, while a browser will send a tunneled PUT. The difference may come down to whether Javascript is enabled in the browser thus allowing an Ajax request, with a fallback using an HTML form for non-Javascript browsers. If the view and routing are expecting only one kind of PUT, they may mishandle the other kind. It's easier to just convert the request than to explain the problem to application developers. -- Mike Orr -- 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: Form handling in Pyramid
On Fri, Jan 21, 2011 at 1:13 PM, Daniel Holth wrote:
> I think it is very relaxing that my view handles unedited requests. I'm
> confused about the problem you are having. Since the framework keeps GET
> requests out, why does the PUT-handler have to check request.method at all?
There are two issues. Going back to Chris's routing example, although
I'll change add_view to add_route because I'm mainly thining of URL
Dispatch.
> config.add_route(NAME, PATTERN, VIEW, request_method='PUT')
> config.add_route(NAME, PATTERN, VIEW, request_method='POST',
> request_param="_method=PUT")
If the appdev omits one of these, either because they don't know about
tunneled PUT or because they underestimate the variety of clients and
uses, the URL won't match at all and either the user will get a 404 or
a later (wrong) route will match.
In the view, if it's a single-purpose view that handles only record
modification (i.e., a submission from a form or the non-form
equivalent), it won't care what the method is. As a corollary, it will
have to call another view (or return 400 status) if the data fails
validation, because it doesn't have the form-display code.
If it's a multi-purpose view, the user better check for both kinds of
PUTs or DELETEs, because if he naively does ``if self.request.method
== 'POST'`:` or ``if self.request.method == 'PUT':``, the result will
be wrong if the other PUT style was used. So maybe they should do ``if
self.request.method != 'GET':`` instead, although that raises the
possibility that the method may be entirely unexpected ('DELETE'
instead of 'PUT'), in which case again the result is wrong. (It
*should* return 405 status if the method is inappropriate for the
view., and not just act like it were a different method.)
--
Mike Orr
--
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: How to mock models while testing views?
On Tue, Jan 25, 2011 at 10:38 AM, Ryan wrote: > I use PyMox for mocking in unit testing of models. While testing views, I'd > like to mock model methods as well. Any examples of how to do this? > Or, is this the wrong approach? Should the view tests be considered full > integration tests, and therefore not be mocked? View tests are a higher level of unit test, because you can test the return dict rather than the rendered HTML. The extreme approach to testing is to "mock everything possible, providing only the minimum dummy features necessary to exercise the test". But most programmers would just test the real models in views, using a test database with sample data. Because if you already have other tests testing the model in isolation, they should have caught any problems in the model. And if you have high-level model-access methods (usually class methods on the model) which the view calls, you'd test those in isolation too. Then you can just let the views test the real models, and if the view result contains model instance(s), you can examine those too and make sure they have the correct values. -- Mike Orr -- 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 1.0b3 released...
On Fri, Jan 28, 2011 at 8:13 AM, Chris McDonough wrote: > - Paster templates and tutorials now use tabs instead of spaces in their > HTML templates. Tabs??? Hasn't everybody switched to spaces instead of hard tabs in Python programming? Most people's editors are set to four-space tabs. -- Mike Orr -- 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 1.0b3 released...
On Fri, Jan 28, 2011 at 10:52 AM, Christoph Zwerschke wrote:
> Am 28.01.2011 17:51 schrieb Mike Orr:
>>
>> On Fri, Jan 28, 2011 at 8:13 AM, Chris McDonough wrote:
>>>
>>> - Paster templates and tutorials now use tabs instead of spaces in their
>>> HTML templates.
>>
>> Tabs??? Hasn't everybody switched to spaces instead of hard tabs in
>> Python programming? Most people's editors are set to four-space tabs.
>
> He was talking about HTML templates, not Python code. For HTML, tabs make
> some sense, as the page size gets a bit smaller.
Well, eliminating all non-functional whitespace would make the page
size even smaller. I'm just concerned that it'll make the pages
inconvenient to edit. ("Must use tabs here to avoid inconsistency, but
not in other files.")
I did notice an extreme vacuuming of whitespace in pylons.css. And it
defines styles for all sorts of obscure tags that seem to be already
the default and don't make much difference. And also, it was
referencing Google fonts for some reason, which which was causing a
slight rendering delay on my system. It didn't seem to use the Google
fonts but it was causing a slight rendering delay, so I took the font
line out for pyramid_sqla but left the rest of the file. I'm not sure
that stylesheet is a useful basis for a user application ("I want my
h3 font size exactly 1.25em, and I must have these specific fonts"),
but if it supports the default page and I don't have anything
particular that would be better, I figured might as well leave it in.
--
Mike Orr
--
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: URLDispatch vs Traversal question
On Sun, Jan 30, 2011 at 8:25 AM, Wade Leftwich wrote:
> Actually a bit more in keeping with the spirit of Traversal, and again
> keeping your calls to Mongo to a mininum, would be something like
> this:
>
> /blog/month/2011/01/29/my-post-about-pyramid would do this:
>
> archive = Blog['archive']
> year = archive['2011'] = archive.__getitem__('2011') = Year(y=2011)
> month = year['01'] = year.__getitem__('01') = Month(y=2011, m=1)
> day = month['29'] = month.__getitem__('01') = Day(y=2011, m=1, d=29)
> post = day['my-post-about-pyramid'] = day.__getitem__('my-post-about-
> pyramid') = Post(y=2011, m=1, d=29, slug='my-post-about-pyramid')
> ... and the default view for Post would be to query Mongo
>
> This would handle shorter paths in a natural way -- e.g. '/blog/month/
> 2011/01' would map to the default view for Month(y=2011, m=1), which
> would call Post.list_posts_for_month() .
Are you traversing each level of the date here, or using a subpath from archive?
It seems like extra overhead to create a temporary Year class and
Month class just to traverse through them. What are you gaining?
I'm thinking of making a CMS site with articles embedding nested
comments. Chris suggested making the article a repoze.folder.Folder
subclass. I said it seems funny to think of an artlcle as a folder. He
said he makes almost everything folders nowadays, as it makes it
easier to both use the object and traverse through it. Could
ArchiveYear and ArchiveMonth be made into Folder subclasses to factor
away some of the code?
--
Mike Orr
--
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 1.0 released.
I'm still working on a Pylons-Pyramid migration guide. I should have a draft out by next weekend. -- Mike Orr -- 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 Migration Guide, first draft
Here's the first draft of my Pyramid Migration Guide. It's an introduction to Pyramid for Pylons 1 users, comparing the two frameworks feature by feature. This is a first draft so it may have inaccuracies people will report in the next few days. And a few sections at the end aren't written yet. But for what it is, it can serve as an introduction to the Pyramid manual if you're finding the vocabulary confusing or the details overwhelmingly many. It focuses on the pyramid_sqla application template in the pyramid_sqla package, which is the most Pylons-like template. I'll be out of town next week (Mon-Fri) and I may leave my computer at home, so if I don't reply for a few days that's why. Finished sections: vocabulary, Paster, INI file, models, view handlers, routing (and a minimal overview of traversal), request object, templates, static files, session (flash messages and secure forms), webhelpers, shell, deployment. Not yet written: testing, forms, authorization, other Pyramid features (overview of events, hooks, extending/ZCA, ZCML). There's an internationalization section but I don't know enough about the topic to write it myself. Online version: https://bytebucket.org/sluggo/pyramid-docs/wiki/html/migration.html Sphinx source: https://bitbucket.org/sluggo/pyramid-docs/src This is part of my Pyramid Supplemental Docs project. It will eventually be on github and in the Pyramid docs, but first I wanted to get it written. Replies to pylons-devel if it's a minor bug report or comment or Pyramid usage issue, or to pylons-discuss if you think it's important to all Pylons users. -- Mike Orr -- 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.
Global variables
On Wed, Feb 9, 2011 at 2:46 PM, Tres Seaver wrote: > One bit I noticed: In > https://bytebucket.org/sluggo/pyramid-docs/wiki/html/migration.html#app-globals-and-cache, > you state:: > > You can also use ordinary module globals or class attributes, > provided you don’t run multiple instances of Pyramid applications in > the same process. (Pyramid does not encourage multiple applications > per process anyway. Instead Pyramid recommends its extensibility > features such as its Zope Component Architecture, which allow you to > write pieces of code to interfaces and plug them into a single > application.) > > Pyramid actually goes out of its way to make running multiple apps in > the same process work: in fact, it uses the ZCA in a way which means > that registrations made in one app's configurator won't interfere with > those made in another app's configurator. Perhaps the docs need to show > an example of such a setup, but it is quite supported. > > Some of us *do* write apps that expect to be extended / reconfigured via > the ZCA registry, but Pyramid itself doesn't mandate that (or even > document it all that well). If such an app uses the "global" ZCA APIs, > it won't benefit from Pyramid's segregated registries, but that is no > different from use of any other global (module- or class-scope > variables, etc.) I just got back from my trip. So what's the official recommendation for arbitrary global variables? I just wrote what I thought would be safe. But people have their database connections and other things they'll have to put somewhere. Should I say to put them all in the registry? Under Settings? As module globals? If they do want to put something into the registry, what's the syntax? Can you just assign an attribute in 'registry'? -- Mike Orr -- 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: paginator/batcher for use with Pyramid
Paginate works with Pyramid, with the caveat that if you use the Page.pager() method, you have to pass a custom URL generator to the constructor as described on the webhelpers.paginate page. I'm working on a variation that won't have this restriction. On Thu, Feb 24, 2011 at 7:03 AM, Renato Pereira wrote: > Hi Chris, > > I don't know if is recommended, but I use webhelpers[1]. It's pretty > easy to use. =] > > > [1] http://webhelpers.groovie.org/ > > On 02/24/2011 08:38 AM, Chris Withers wrote: >> Hi All, >> >> What's the recommended paginator/batcher for use with Pyramid? >> >> cheers, >> >> Chris >> > > -- > > -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- > > Renato de Pontes Pereira > - Membro opensuse - http://en.opensuse.org/User:Renatopp > - http://renatopp.wordpress.com > - @renatopp - twitter > - renatopp - irc > > -- > 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. > > -- Mike Orr -- 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: paginator/batcher for use with Pyramid
On Thu, Feb 24, 2011 at 10:57 AM, Ben Bangert wrote: > On Feb 24, 2011, at 9:43 AM, Gael Pasgrimaud wrote: > >> On Thu, Feb 24, 2011 at 6:37 PM, Mike Orr wrote: >>> Paginate works with Pyramid, with the caveat that if you use the >>> Page.pager() method, you have to pass a custom URL generator to the >>> constructor as described on the webhelpers.paginate page. >>> >> >> Can't we have a default pyramid generator (and well, webob based >> frameworks) in WebHelpers who use the request.path to generate the url >> ? >> >> So you can use Page.pager(request=request) > > Yep, that was the thought for the next iteration. That's something I hadn't seen, passing a (WebOb-compatible) request to the pager method rather than to the constructor. That might be a solution. > Also, to require the object being paginated to support the Python sequence > API, so that the hacky code that tries to deal with various SQLA things isn't > needed. Ie, there'd be some sequence wrappers for SQLA query objects vs. a > bunch of if/else code toggling it inside the paginator. I still need to see a more concrete version of what you're thinking of. The paginator already treats the collection as a sequence as much as possible. Also, you were talking about a way to fetch one more record than required, and using the extra primary key as the starting point for the next page to avoid the OFFSET clause which is inefficient (because it has to cycle through all the records before this page). I tried to do this but I don't see how it would work. 1) We can't figure out which record number we're on without cycling through the previous records, because it changes depending on the WHERE clauses. 2) The user would have to pass in the name of the primary key field. 3) You'd have to transmit the last primary key to the next request as a query param. 2 and 3 are doable, but I don't see how to do 1 without passing a bunch of state variables to the next page, and the pager may go out of kilter if these aren't calculated correctly for the receiving page. -- Mike Orr -- 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: paginator/batcher for use with Pyramid
On Thu, Feb 24, 2011 at 11:10 AM, Mike Orr wrote: >>> Can't we have a default pyramid generator (and well, webob based >>> frameworks) in WebHelpers who use the request.path to generate the url >>> ? >>> >>> So you can use Page.pager(request=request) >> >> Yep, that was the thought for the next iteration. > > That's something I hadn't seen, passing a (WebOb-compatible) request > to the pager method rather than to the constructor. That might be a > solution. Or rather, it would solve the "/index?page=2" problem. It wouldn't solve the "/index/page/2" problem, which requires knowledge of a specific router. webhelpers.paginate already has two framework-specific mechanisms hardwired into it, which is against the spirit of a generic helper. I was going to put a derivative in pyramid_sqla (or rather its descendant Akhet, which I'll release in a week or so), which could be Pyramid-specific and could also remove the other hardwired mechanisms. -- Mike Orr -- 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: paginator/batcher for use with Pyramid
On Thu, Feb 24, 2011 at 2:20 PM, Chris Withers wrote: > On 24/02/2011 19:10, Mike Orr wrote: >>>> >>>> On Thu, Feb 24, 2011 at 6:37 PM, Mike Orr wrote: >>>>> >>>>> Paginate works with Pyramid, with the caveat that if you use the >>>>> Page.pager() method, you have to pass a custom URL generator to the >>>>> constructor as described on the webhelpers.paginate page. > > Okay, I take it the examples that are out there for this still hold true? The Pyramid example I mentioned in an earlier thread (about a month ago) should work. I don't have the syntax in front of me. You have to create a function that returns the correct URL when called like this: func(page=4) => /url/for/myarticle?page=4 >>>> So you can use Page.pager(request=request) >>> >>> Yep, that was the thought for the next iteration. >> >> That's something I hadn't seen, passing a (WebOb-compatible) request >> to the pager method rather than to the constructor. That might be a >> solution. > > Does that work now or is it something for the future? Future. The 'request' arg isn't recognized at present. > What if the primary key is not numeric? That doesn't matter. >> to avoid the OFFSET clause which is inefficient (because >> it has to cycle through all the records before this page). > > This I don't follow, lack of relational knowledge. > I presume you mean the OFFSET is slow on the server? That's what Ben says. But it's what everybody has been doing, and it's not slow in my applications. (MySQL, with a high-grade CPU and plenty of memory) >> 1) We can't figure out which record number we're on without cycling >> through the previous records, because it changes depending on the >> WHERE clauses. > > I don't follow this, can you give a simple example? Say you have a hundred records numbered 1 to 100, and you're paging ten at a time. Page 3 is records 20-39, and the number of skipped records (the OFFSET) is 20 (#1-19). But if you add arbitrary conditions, like show only records that were modified on a Thursday and have an address (a relation to another table), then the offset size will probably be less than 20. But how much less we don't know unless we run the complete query. So if you click on a page link /article?page=4&last=39 That 'last' doesn't really tell you anything because you still have to run the whole query to figure out which relative record number you're at. (Otherwise ``page.first_item`` and ``page.last_item`` would be unknown, and you wouldn't be able to say "Showing records 29-39 of 100".) The only way around that is to pass several more pieces of state data in the query string, and that's where I worry about miscalculating or the pages getting out of kilter. >> 2) The user would have to pass in the name of the primary key field. > > To where? To the Page constructor. It has to know which field to look at to determine what the last primary key value was. > Now, anyway, back to the problem at hand for me. > As it happens, I am looking to paginate the results fairly simple SA query: > > session.query(MyModel) > > What's the most efficient way I can do that with currently available > software? > > What version of webhelpers should I use? Are there any changes to the query > I should make to make it more efficient? Just follow the WebHelpers instructions, and define a URL generator callback to pass. WebHelpers 1.2 is the current version and has been stable since last August. The current code uses OFFSET, but there's no way around that at the moment. And we're not sure if a more efficient algorithm is feasable anyway. At least for SQL databases. CouchDB may have its own special features. -- Mike Orr -- 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: paginator/batcher for use with Pyramid
On Thu, Feb 24, 2011 at 4:20 PM, Mike Orr wrote: >>> 2) The user would have to pass in the name of the primary key field. >> >> To where? > > To the Page constructor. It has to know which field to look at to > determine what the last primary key value was. Er, it would have to do that if the proposed algorithm is implemented. Currently there is no primary key arg. -- Mike Orr -- 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_tm 0.1 released
On Sun, Feb 27, 2011 at 10:28 PM, Chris Withers wrote: > On 26/02/2011 10:18, Wichert Akkerman wrote: >> >> We had a mini-discussion on this topic on irc this week. The only >> difference between the two is that repoze.tm2 uses middleware, while >> pyramid_tm uses pyramid events. >> >> Personally I am a bit worried about a trend to move away from reusable >> WSGI middleware to pyramid-specific approaches, especially when there >> appears to be no functional benefit. > > Indeed. Thanks for the clarification, I'll definitely stick with repoze.tm2 > then. I haven't looked at pyramid_tm closely enough to tell whether it'll work for pyramid_sqla, but the fact remains that WSGI is a clunky protocol for services, and a non-middleware solution would be welcome. The protocol is good for web servers and non-data services like error handlers, but it forces a distortion in libraries that share data with the application because you can't just call things directly, you have to shoehorn the data into one dict or the HTTP headers, and any interaction in views has to be via callback objects in the dict. It's ironic that Jim Fulton used to complain that using middleware for data services was an abuse of the protocol and framework/application developers ignored him, but now after five years of use framework developers are coming to the same conclusion for a different reason: the WSGI protocol is just too artificial and rigid to use for data services. You see that especially in repoze.who/what, which are overly complex partly because of their middleware nature, and to an extent Routes too. Generic reusable code is a good thing but it doesn't have to be middleware. The various form libraries are reusable but they aren't middleware. -- Mike Orr -- 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.
pylons-discuss and pylons-devel
On Thu, Mar 3, 2011 at 11:44 AM, Mike Orr wrote: > On Thu, Mar 3, 2011 at 1:03 AM, drebbin wrote: >> Hi all, >> I am joining this community because of an interest in Pyramid -- about which >> I had posted an issue in the pylons-devel list. Now I notice that that list >> is only scarcely visited, contrary to this list, and am a bit confused. >> Where shall I post "n00b questions of a seasoned programmer" ;) ? > > Now that Pyramid 1.0 is released, this is the place for Pyramid > questions. In alpha development we were using pylons-devel to avoid > confusing those who were new to Pylons 1 and couldn't tell the > difference between Pylons questions and Pyramid questions. Now that > Pyramid is properly documented and supported, that issue has gone > away. Here's generally what pylons-discuss and pylons-devel are for. pylons-discuss: - Questions from users at all levels, from newbie to advanced, on both Pyramid and Pylons 1. Including usage questions about their dependencies and libraries commonly used with them, and general web development questions encountered when using Pyramid or Pylons. - Changes in the frameworks that affect the application API or performance, especially those that raise backward-compatibility issues. - (In Pyramid's case, the changes were so large and it was unstable for so many months, that an overview was posted to pylons-discuss, but not every detail while it was unstable.) pylons-devel: - Discussions that only framework developers care about. This list mainly exists so that those who don't care about internal framework issues (i.e., regular application developers) can avoid subscribing to it. - Topics include implementation details, minor bug reports, trivial information, wild-eyed proposals that may not be approved (or that you want to refine and bake before announcing to the userbase), etc. -- Mike Orr -- 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: Some thoughts about Pyramid
ompletelyDifferentName.") But that's a tradeoff we had to accept. One thing I remember fondly about Quixote is that I could read the entire printed source in half an hour and understand it. But eventually I realized that Quixote just didn't have certain features I needed, and I switched to Pylons. Re auth, there is some ambiguity because some people are recommending the built-in auth while others are using repoze.who/what. Generally, the built-in auth is simpler, and not being middleware makes it more straightforward. But repoze.who has more authentication mechanisms out of the box. Eventually there will be patterns for combining the two, or a simpler successor to repoze.who that's aware of the built-in auth will emerge. The Pyramid manual and the migration guide are necessarily geared toward the majority users who come from a BFG or Pylons background. Those users are comfortable with Paste and have been using it for five years, so that's what the standard application templates recommend. There have been calls over the years to replace Paster, but no clear idea on what to replace it with, or assurance that anything else would be sufficiently better. Paste's creator, Ian Bicking, has been spinning off packages out of Paste (WebOb, WebError), and expects that eventually all of Paste will be spun off or left to die. But there has been little effort to replace PasteDeploy or PasteScript because they basically work. -- Mike Orr -- 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: Tutorials
On Thu, Mar 3, 2011 at 12:43 AM, drebbin wrote: > Side note: as somebody in some mailing list mentioned, distribute and pip is > the new hotness. I used them successfully in the tutorials, maybe you can > update the narrative. That's still evolving. Distutils2 is the new future hotness but it's still in alpha. It's written with dependencies and pip in mind, and will be in Python 3 someday (with a package available for Python 2). In the meantime, I use Ubuntu 10.10 and install the "python-setuptools" package, which is actually Distribute. That works fine for me, along with the 10.10 versions of python-pip, python-virtualenv, and virtualenvwrapper. I do think that setuptools and easy_install need to be eradicated from the docs. (The only advantage easy_install has is for installing precompiled Windows binary eggs, for packages that contain C extensions.) But Distribute is also stagnating somewhat as development focuses on Distutils2. -- Mike Orr -- 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: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 12:11 AM, Chris McDonough wrote: > So we should reorganize by moving chapters of the documentation around? Maybe if we just rename the Pyramid manual to the Pyramid Reference Manual it will set readers' expectations appropriately. I'm not sure if there's anything that needs to change in the manual. -- Mike Orr -- 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: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 9:39 AM, Chris McDonough wrote: > Of these, the only ones to very easily *not* install would be Mako, > Chameleon, PasteScript, Paste, and PasteDeploy. The others are core > dependencies that really can't very easily be externalized. > > Doing that would take us down to 13 dependencies. We could indeed make > "pyramid_chameleon" and "pyramid_mako" and "pyramid_paste" packages to > restore the functionality for users of those dependencies. > > Would that actually service any particular goal? Would having fewer > "rails" in the core actually make anybody happier? I was -1 on splitting them but as I thought about it more I'm +0. There's a benefit in distinguishing more between what Pyramid itself needs and what the application templates need. If somebody is never going to use Chameleon or Mako, or they detest PasteDeploy, why install them? Especially if it causes problems in space-constrained deployments. The user can't nullify a dependency without changing other packages' setup.py files, and excluding packages manually that then get re-added whenever somebody runs "python setup.py install" because they think it will just bring the app up to date seems wrong. If we do split them off, we should probably add a paragraph to the templates' documentation saying "this template uses X which provides X", or "all templates distributed with Pyramid depend on X which provides X". That will keep people fully informed about what decisions the templates are making for them, and what leeway they have to choose alternatives. -- Mike Orr -- 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: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 12:11 AM, mjmein wrote: > One also just needs to define what the ultimate goal is: > > Is it to compete with Django/Rails? In that case I agree that alot of > work needs > to be done on simplifying and removing options. The power of Django/ > Rails are that > they provide one way of doing things that works in the most cases. The > problem is > that it is very difficult if you want to go outside the constraints > imposed by them. Pyramid has several simultaneous goals. It definitely has the niche in traversal-style and component-style apps, and as the only one in that area besides Zope. It has also pulled in Pylons and TurboGears users who highly value mix-and-match interoperability and leveraging third-party tools. In that sense it's a medium-level framework (Pylons-like) with the potential to host high-level frameworks (TurboGears-like). There is also some interest in providing an alternative to Django, and in gaining market share among Python-web frameworks and all web frameworks. But it's not an overriding interest; it's just something that would be nice to have. Pylons never did marketing well for two reasons. One, the core developers aren't talented marketers. Two, we were busy finishing Pylons 1, and then we immediately finished Pyramid 1 back-to-back. That didn't leave much extra time for marketing or for focusing on the website. Now that Pyramid 1 is finished, we can take a step back and look at some areas we've neglected; e.g., marketing and tutorials. I say "we", although in reality Ben is busy with his clients' sites, I'm plowing through three Pyramid add-ons, and for all I know Chris is working on his own clients' sites, and who knows what others are doing. Still, it's worth discussing how the Pylons Project as a whole can improve on marketing, documentation, and handholding (new users through the process of building their first site). I have a friend who is a marketer and supports the Pylons Project, but he's kind of gotten burned out on Python as a whole for various reasons so he can't quite be a full marketing advisor. Is there anyone else with marketing-type experience who would like to stand up? -- Mike Orr -- 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: Some thoughts about Pyramid
On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis wrote: >>I mentioned "unless there are new magical docs", because I think 99% >> of the problems with pyramid right now are the docs. They're hard to >> sift through (rather dense) and easy to miss things in. Meanwhile, >> docs for projects like Django and Rails are really light and breezy... >> and link to the more-in-depth specialized docs and api docs. > > I feel more or less same, 'coz I was finding much difficulty in > understanding the framwork from the document. Escpecially, the > registration, configuration, the Z* things etc... > The framework is so powerful, but lack of clean medium to get into it > causing people to take U turn. It would be much better if we can re- > arrange/modify the documents in a way to take out Z* things, traversal > and all complex topics to 'Advance' section seperately. This is where Pyramid's multiple goals come into play. The BFG-ish users say that Traversal was immediately understandable to them and they could apply it right away, while they find URL Dispatch cumbersome. ZCML configuration was moved to the back of the manual for exactly the reason you describe, because it was a stumbling block for the large number of Pylons users who were about to come, and the BFG users knew where to find it in the back of the manual. I'd support moving Traversal to the back except I think there'd be more resistance to doing that than there was for ZCML. Traversal is central to an application if you're using it, whereas ZCML is "just zis configuration format, y'know". [voice of Zaphod Beeblebrox's psychiatrist] -- Mike Orr -- 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: Some thoughts about Pyramid
I'll be at the Pyramid sprint but I don't know what I'll be doing. I would like to learn Git and Pyramid-at-Github if somebody would like to do a mini crash course. On Fri, Mar 4, 2011 at 11:38 AM, Blaise Laflamme wrote: > I'm up too > > On Mar 3, 8:09 pm, Carlos de la Guardia > wrote: >> Guys, >> >> I'll be at PyCon and would like to sprint on this. Maybe a tutorial >> with code. Anyone? -- Mike Orr -- 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: Some thoughts about Pyramid
On Fri, Mar 4, 2011 at 12:03 PM, Blake Hyde wrote: > On Fri, Mar 4, 2011 at 2:50 PM, Mike Orr wrote: >> I have a friend who is a marketer and supports the Pylons Project, but >> he's kind of gotten burned out on Python as a whole for various >> reasons so he can't quite be a full marketing advisor. Is there anyone >> else with marketing-type experience who would like to stand up? >> > > I'm generally a lurker, and am currently overwhelmed with other > projects, but I do have some suggestions in this area and would be > glad to help contribute to marketing efforts as time allows. Will you be at PyCon? There will undoubtedly be Pyramid/WSGI related Open Spaces every day at the conference; or at least there have been the past two years. So for those who can't attend the sprints, please stop by an open space and say hi. -- Mike Orr -- 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: CSRF protection and session factories
On Wed, Mar 9, 2011 at 11:24 AM, Stephen Lacy wrote: > In my form handling view, I'm using code that looks like this: > > if not request.session.csrf_valid(request.POST['csrft']): > return HTTPInternalServerError() This is popular but I'd use HTTPBadRequest (400). It's a client error if the token is incorrect, not a server error. Otherwise it gives the impression that a bug made the server crash, and the server logs will say that too so you can't count how many hack attempts vs genuine errors you got. -- Mike Orr -- 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
--
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 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 -- 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
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
--
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
Added Marrow to the list. I looked over the components home pages and had two concerns: - marrow.server.http is asynchronous. I don't think we want to make such a large leap from multithreaded to asynchronous in the default server. People have just gotten used to making their apps thread-safe; I don't think we want to force them to make them asynchronous-safe too in order to upgrade to Python 3. - marrow.script disavows argparse and optparse in favor of its own GNU-like syntax. Do we need another command-line parser? I was just starting to use argparse. (PasteScript does not use either, but argparse would be an advantage.) - Is the distinction between PasteScript and PasteDeploy really worth keeping? Marrow seems to keep the distinction but I was going to meld them together. It seems like you rarely use them apart, and for our purposes of "create" and "serve" both are necessary. People are always having to look in both PasteDeploy and PasteScript to see where something is defined. -- Mike Orr -- 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 1:40 PM, Andrey Popp <8may...@gmail.com> wrote: > Hello, > > On Mar 13, 2011, at 3:29 PM, Mike Orr wrote: >> - Replace the INI file with an YAML file? > > YAML is not as good as it can be for config file format: > > * It has slow parsers. > > * There's risk of bloating YAML file with Python type annotations (tags), > e.g. !!bool, !!python/tuple when dealing with YAML programmatically. > > I better suggest looking for something that has syntax similar to Configgy > for Scala. > > I propose another idea for GSoC -- generic (persistent agnostic, > pluggable, extensible) admin interface based on Pyramid. It seems Tres > Seaver started doing something like this on github[1], but what about > putting it on GSoC rails? I think this will be the killer feature for > Pyramid itself. > > [1]: https://github.com/Pylons/bottlecap Added to the list, but can you specify what exactly you want this admin interface to do? What does "persistent" and "agnostic" mean in an admin interface? I assume "pluggable" and "extensible" means extensible with ZCA. -- Mike Orr -- 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 Mon, Mar 14, 2011 at 12:37 PM, danjac...@gmail.com wrote: > Migration to Python 3 aside (which has to happen, sooner or later) my > concern here is that moving to Pyramid 2 so quickly is a bit premature > given the paint is barely dry on Pyramid 1. We aren't moving quickly but just capturing people's ideas onto a list so that we can see if an architectural pattern emerges, so that we don't forget anything, and to disclose our potential long-term direction to both users and framework-makers (TurboGearsSuccessor, Khufu). We will have to choose GSOC tasks in a month or so, and we want to make sure they're consistent with our general direction so they don't turn into dead ends. A GSOC task will not be all of this, it would be one small part. It would also depend on what the student is interested in. The takeaway seems to be that PasteDeploy and PasteScript are not part of the permanent core but are "blessed" add-ons (formal dependencies), as Mako is. You can already configure a Pyramid app imperatively -- IN PYTHON -- by instantiating the app passing in the desired settings. This is hopefully emphasized in the Pyramid manual to a greater extent than is for Pylons; or at least that was the intention. The Paster templates with INI files are just a convenience to get you started. Paste* need a maintainer as Ian moves on to other things. That de facto falls to use because we use them most. The consensus seems to be that PasteDeploy and PasteScript could be cleaned up with their current active features rather easily, but Paste itself is more difficult, so it may be better to take what we need and leave the rest to die. So there are three different issues: moving Paste out of the Pyramid core, rewriting PasteDeploy/PasteScript with their current features (possibly merging them), and adding/moving to YAML This comes back to porting to Python 3 in that, how much effort do we want to put into porting the existing Paste* code to Python 3, if we're not sure we want to keep it long-term. > Should we not wait until there are some actual projects built with > Pyramid, and we get feedback from real world usage ? The danger is > that this ends up like TG2 - a continually moving target moving from > one dependency to the next, depending on what's flavour of the month, > with a small core of developers continually making changes but leaving > behind those who need a stable framework to work on. Reluctance noted. We do need more Pyramid applications and experience, and we don't want to be flightly like TurboGears has seemed. Perhaps we can just think about it for six months, and if there's anything somebody think is especially cool they can make an add-on for it. -- Mike Orr -- 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: RESTful Pyramid
On Sun, Mar 13, 2011 at 10:33 PM, ZHUO Qiang wrote: > Hi All, > > I'm right now developing a new RESTful web service project using Pyramid. > The problem is that there seems little info about how to do RESTful route in > Pyramid (on the contrary there is pretty good support about how to build > RESTful style web in both framework and document In Pylons). > > Actaully it's not hard to figure out how to do it the Pyramid way after some > study. And I have summarized my solution here: > http://zhuoqiang.me/a/restful-pyramid > > I see others are looking for the solution as well (see > https://groups.google.com/d/msg/pylons-devel/0Qypgj7Lk1M/CaNwkqaC38UJ) I > hope it will be a help to all. > > Any feedbacks, correctings, suggestions are welcome. I'm not sure if the > solution has any potential side effects. > > It's better that some build-in support for RESTful be added into Pyramid, at > least there should be some *offical* docuement for how to do it. There was going to be a pyramid_routehelper package with an equivalent to Routes map.resource() but it's not written yet. So for now you have to do REST on your own. Yes, there needs to be an official way to do it. You can also use the request_param route predicate to check the _method param directly. -- Mike Orr -- 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
There has been an ongoing discussion between the WSGI developers and Twisted about how to be more compatible. The upshot is that asynchronous servers need some kind of token in the output stream that means "I'm not ready; come back later." Other middlewares would have to pass this token through unchanged. And of course, the application would have to use non-blocking libraries such as non-blocking database executors. I'm not sure if ordinary file access is "blocking" enough to require that too. The upshot has been that Twisted runs WSGI applications in a thread anyway because it can't be sure they won't block. And there hasn't been enough interest from WSGI developers to actually pursue using it with asynchronous servers. I think Python has a future object now which standardizes Twisted's Deferred and the equivalent in other asynchronous servers. So that's a start. On Tue, Mar 15, 2011 at 2:05 PM, Vlad K. wrote: > > Speaking of asynchronous... what is the future of WSGI regarding > asynchronous serving? With websockets (or whatever the standard will emerge > out of it) coming fully supported in the next generation of browsers (what, > within a year? two?), is this even a possibility for WSGI and with that > Pyramid? Returning iterators as response objects? Gevent integration? > > > .oO V Oo. > > > -- > 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. > > -- Mike Orr -- 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: GSOC status
I started a list of potential GSOC projects. https://github.com/Pylons/pyramid/wiki/Gsoc2011 I'm not sure how many ppl have write access to the wiki, but I'll add anything I see mentioned on the list or that somebody emails me. On Wed, Mar 16, 2011 at 12:51 PM, Chris McDonough wrote: > Hi folks, > > I've been talking to folks for the last couple of weeks and it seems > like we have at least four people (not including myself) who are willing > to act in some measure as a GSOC mentor for the Pylons Project. > > We still need to set concrete goals of our students. I'll try to work > up some of that next week. > > If any potential students see this who are interested, in general, in > participating in a Pylons/Pyramid-themed GSOC process, could you respond > on the list and provide us with an idea of what you're interested in and > your general skill level with Python and Pylons/Pyramid? -- Mike Orr -- 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: GSOC status
No objections, although it's too early to commit to specific GSOC project yet. I was going to say that somebody just announced a project to revamp PasteScript/PasteDeploy, but it looks like that somebody is you. So maybe some of that could come under GSOC. BTW, I'm going to post a wishlist of features for paster create and application templates. First Chris has to register Pylons as a subproject of Python's GSOC, I'm not sure if that's been done yet. Then here's the timeline: http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2011/timeline So prospective students discuss projects with "mentoring organizations" until March 27, then students apply March 28-April 8, and then mentoring organizations review the proposals until April 22. On Thu, Mar 17, 2011 at 10:50 AM, Joe Dallago wrote: > I too would like to participate in GSOC. I have spoken to Whit > Morris, and he has has agreed to sponsor me. I was thinking that > re-factoring Paste(serve and create) could be my project. Any > objections? -- Mike Orr -- 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.
WebHelpers conflict #63 and #59
I got this bug report in WebHelpers 1.3b1:
On Sat, Mar 19, 2011 at 9:36 PM, Bitbucket wrote:
> New issue 63: Regression: paginate loads whole table when given SqlAlchemy
> object
> https://bitbucket.org/bbangert/webhelpers/issue/63/regression-paginate-loads-whole-table-when
>
> nh2 on Sun, 20 Mar 2011 05:36:05 +0100:
>
> Description:
> The changeset <> replaces
> {{{
> list(obj[slice])
> }}}
> by
> {{{
> list(obj)[slice]
> }}}
>
> which results in **all** rows being loaded on e.g.
> Page(Session.query(MyModel),filter(...)).
>
> Therefore, webhelpers 1.3b1 completely kills performance.
>
> Responsible:
> bbangert
This was done in order to solve this big report:
> #59, by dennysonique:
> While using TurboGears 2 which relies on Webhelpers (sprox forms) I
> found this bug:
> Line 434 has an error causing:
> Module webhelpers.paginate:434 in init view
> self.items = list(self.collection[self.first_item-1:self.last_item])
> TypeError: unhashable type
> The solution to fix this is to change:
> -- self.items = list(self.collection[self.first_item-1:self.last_item])
> ++ self.items = list(self.collection)[self.first_item-1:self.last_item]
In other words, different users have contradictory desires. Should I
revert #59 and change it to WONTFIX, or is there a way to reconcile
these two? Or is this a reason to overhaul how paginate handles lists
vs queries overall? If so, what would be a better algorithm?
--
Mike Orr
--
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: WebHelpers conflict #63 and #59
On Sun, Mar 20, 2011 at 6:38 AM, Wichert Akkerman wrote: >>> New issue 63: Regression: paginate loads whole table when given >>> SqlAlchemy object >>> > Yaiks - that change will effectively kill any site which does pagination > over a large SQL table, so reverting it would be a good start. I don't see > why the original line would raise that TypeError though. Did the bug > submitter contribute a test to demonstrate that? It looks like he is > strangely behaving collection type. I reverted the patch in 556b55e75dd6, and implemented Marcin Kuzminski's slice test posted to the bug report. Can somebody try checking out WebHelpers dev and make sure it works in your application, especially if you have some large tables to try it against? I'll release 1.3b2 in a day or two after people have had time to test it. (https://bitbucket.org/bbangert/webhelpers/issue/59/webhelperspaginate-error-line-434) Sprox objects appear to be unsliceable and therefore incompatible with paginate. I also discovered that SQLAlchemy queries and selects also don't have .__getslice__, but that's OK because their wrapper class emulates it. So i had to move the slice check below the SQLAlchemy check. I wrote some unittests for various collection types, and discovered there seems to be a bug with SQLAlchemy select objects. https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails The wrapper's .__len__ returns the query's rowcount directly, which is -1, which makes Python choke because len() isn't supposed to return a negative number. The test is commented out but is tests/test_paginate.py#TestSQLAlchemyCollectionTypes.test_sqlalchemy_select . Christoph, can you try the test and see if the wrapper is buggy or the test is wrong? I don't know how long it's been this way; maybe nobody uses paginate with select. https://bitbucket.org/bbangert/webhelpers/issue/64/paginate-sqlalchemy-select-test-fails In the long term I think paginate should be refactored to eliminate the pseudo-list layer. It makes it hard to tell what the backend is doing, and how Python's special methods are interacting with it, and how the collection's special methods may be complicating it further. I'd like to replace the list-like wrappers with straightforward helper classes that do their business directly and return a Page or the data to construct a Page. The Page could remain a list subclass but it would be fully static, not collection-aware. Furthermore I'd like users to be able to provide their own helper classes for third-party collection types. There have been patches to add PyMongo, CouchDB, and now Sprox to paginate, but we can't add everything. Better to go with autonomous helper classes. But this is a longer-term project, it's not something I can do right now. Christoph, what do you think? https://bitbucket.org/bbangert/webhelpers/issue/65/refactor-paginates-pseudo-lists -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Sun, Mar 20, 2011 at 8:12 PM, Joe Dallago wrote: > This issue has been previously discussed, I just wanted to make sure > that everyone agrees. At the moment the docs refer to "paster > templates" and renderered templates(mako, chameleon, jinja) using the > same name. I propose that we change the official nomenclature used to > describe "paster templates" to "skeleton," and leave the word > "template" to describe rendered templates. Any objections? I will > start going through the docs as soon as I get the ok from everyone. Yes. I already did that in the Akhet manual but I had to introduce it with "template" and use "template" in the PyPI description for ppl who might not recognize it. The sooner we can get away from "template" completely, the better. -- Mike Orr -- 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: WebHelpers conflict #63 and #59
On Mon, Mar 21, 2011 at 9:05 AM, Marius Gedminas wrote: > I'll just add a note that defining __getslice__ is not necessary to support > slicing (in fact it's been deprecated since Python 2.0). The modern way > is to have your __getitem__ check if the argument passed to it is an > instance of the builtin `slice` type. > > (You probably knew that already, but your wording above is a bit ambiguous.) No, I didn't know that. I've never dealt with slices, just individual items. Actually, I don't know if I can check for that. I can check for the presence of a method, but not its semantics. Unless I call the method and see what it does with a slice, but that would be silly and potentially disruptive. > Incidentally, what's that '__slice__' thing you're checking for in > https://bitbucket.org/bbangert/webhelpers/changeset/556b55e75dd6#chg_webhelpers/paginate.py_newline215 > ? docs.python.org has no knowledge of it. Oh, that should be .__getslice__ . Maybe that's causing some of the SQLAlchemy complications (but not all of them). -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Mon, Mar 21, 2011 at 12:09 PM, Stephen Lacy wrote: > Why not just cut to the chase and call them "examples". > They can then be fully fledged working applications, and users can be > advised to copy them to their own directory structures before continuing. > That's probably what everybody does anyway, right? No, because the project name and package name is built into the structure, so reusing an existing app would mean making a lot of fundamental changes to it. -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Mon, Mar 21, 2011 at 11:08 AM, Alice Bevan–McGregor wrote: > On 2011-03-20 23:23:02 -0700, Mike Orr said: > >> On Sun, Mar 20, 2011 at 8:12 PM, Joe Dallago wrote: >>> >>> This issue has been previously discussed, I just wanted to make sure >>> that everyone agrees. At the moment the docs refer to "paster >>> templates" and renderered templates(mako, chameleon, jinja) using the >>> same name. I propose that we change the official nomenclature used to >>> describe "paster templates" to "skeleton," and leave the word >>> "template" to describe rendered templates. Any objections? I will >>> start going through the docs as soon as I get the ok from everyone. >> >> Yes. I already did that in the Akhet manual but I had to introduce it >> with "template" and use "template" in the PyPI description for ppl who >> might not recognize it. The sooner we can get away from "template" >> completely, the better. >> >> -- >> Mike Orr > > ±0 — skeleton describes what it is less than, say, blueprint. A Linux > /etc/skel is static, for one. Blueprints often reference other blueprints, > too. I like the word blueprint better than skeleton, actually. I would have suggested it but you had already taken the name. I don't think we can use your implementation classes directly, because they make a several fundamental changes compared to PasteDeploy/PasteScript that I don't think Pyramid is ready to commit to at this point. Such as using alacarte, being another namespaced package, adding several dependencies, etc. I've heard your packages are also Python 3-only? I think what we'll probably do is make a new implementation of Paste* but keep the features and API mostly the same, at least that's what a few developers are working on. Would you mind if we use the term "blueprint" in this "paster create" replacement? -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Mon, Mar 21, 2011 at 12:44 PM, Ben Bangert wrote: > I've been doing Pylons for a long time, and we generally do say 'paster > templates' and no one thus far has ever gotten confused afaik. "Template" has been a problem for years. Even if people can figure it out, it's cumbersome to write in documentation and tutorials where you have to explain that a template (skeleton) is not a template (file) although some of its files are templates. And the phrase "application template" is long and cumbersome when you have to repeat it many times. -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Mon, Mar 21, 2011 at 2:05 PM, Ben Bangert wrote: > On Mar 21, 2011, at 1:48 PM, Mike Orr wrote: > >> "Template" has been a problem for years. Even if people can figure it >> out, it's cumbersome to write in documentation and tutorials where you >> have to explain that a template (skeleton) is not a template (file) >> although some of its files are templates. And the phrase "application >> template" is long and cumbersome when you have to repeat it many >> times. > > Ah, good point. I guess I'm too used to explaining things in person. ;) > > So any reason it *shouldnt* be called 'scaffolding' given its already a well > known name that people already associate with this exact thing? I mean, I can > see how 'blueprint' can technically be a more accurate term, but existing > re-use of the name and lack of anyone already associating it with this seems > like a point against it. 'Skeleton' is a long-established term in Unix where it refers to the files initially copied to a newly-created home directory. That's an exact analogue of what we're doing. "Scaffold" or "Scaffolding" would be OK too, although I'd prefer the shorter "Scaffold". "Scaffolding" connotes the ad-hoc process of constructing it individually for each building, while "Scaffold" sounds like a product that remains the same over many uses, which is how an app template works. There's also that word "Fixture" that some people call a class that acts as a framework for unittests. -- Mike Orr -- 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.
Fwd: [GitHub] Added Pylons migration guide and dev docs links. [Pylons/pylonshq GH-15]
Oh dear, this is now out of date. (And I don't have my Github login with me.) If you're referring to the Pyramid Migration Guide, it has been merged into the Akhet documentation, which is newer. The PMG was written for pyramid_sqla, which is now deprecated. Also, i couldn't find the link on the website. -- Forwarded message -- From: cguardia Date: Mon, Mar 21, 2011 at 2:29 PM Subject: [GitHub] Added Pylons migration guide and dev docs links. [Pylons/pylonshq GH-15] To: sluggos...@gmail.com -- Reply to this email directly or view it on GitHub: https://github.com/Pylons/pylonshq/pull/15 -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Tue, Mar 22, 2011 at 10:07 AM, Eric Lemoine wrote: > $ paster create --list-templates > Available templates: > basic_package: A basic setuptools-enabled package > paste_deploy: A web application deployed through paste.deploy > pylons: Pylons application template > pylons_minimal: Pylons minimal application template > pyramid_alchemy: pyramid SQLAlchemy project using traversal > pyramid_routesalchemy: pyramid SQLAlchemy project using url > dispatch (no traversal) > pyramid_starter: pyramid starter project > pyramid_zodb: pyramid ZODB starter project > > So, so long that Pyramid is based on Paste for templates, introducing > a new term might be confusing to people. We can use [other word] throughout, we just have to remember to mention that "paster create" calls it a template, both when first introducing the word and when directly referring to the command and its output. The sooner we can replace "paster create" with something that doesn't use the word "template", the better. I think it's pretty clear that it's not worth making significant changes to PasteScript because it's a namespace package under Paste, and Paste is the package that's least useful. > I honestly didn't realize this would become such a big topic of conversation It may require a historical view to understand this. From the late 90s till 2005, every Python framework was unique and non-interpoerable with any other. This was widely seen as intolerable so WSGI was created. Paste was the concrete manifestation of WSGI (meaning, it provided tools to choose a WSGI app and server and connect them, and building blocks for WSGI frameworks. Paste was the only concrete unifying factor among all these frameworks that gradually moved together; even those that didn't merge or didn't use Paste directly. Paste itself provides only mini-frameworks. Pylons was the first Paste framework to include a real template engine. Thus the ambiguity started between "application templates" and template files. But because Paste was the only unifying factor between these frameworks that were trying to become un-fragmented, there was little interest in changing anything about Paste that might harm the fragile unity. What's different now is that, seven years later, framework consolidation is well established, most of the useful parts of Paste have been spun off into separate packages with non-Paste identities, the remaining parts of Paste are stagnating and people have not rushed to take over its maintenance, and the frameworks have become more assertive, "Let's make some changes." So therefore, a move to rename "application template" is viable now in a way that it wasn't before. Just this week I decided to rename "application template" in my Akhet manual because the term was just too cumbersome, but I never thought the Pyramid docs would be amenable to doing that. And then a few days later you say you do want to change the Pyramid docs. So it's an idea that's gaining momentum, and that's why the big discussion broke out. -- Mike Orr -- 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: Terminology Change - Template to Skeleton
On Tue, Mar 22, 2011 at 6:46 PM, Ben Bangert wrote: > On Mar 22, 2011, at 6:30 PM, Michael Merickel wrote: > >> I'd imagine we can update Paste to support an alias for templates? >> >> paster create --list-scaffolding >> paster create --scaffold pyramid_starter >> paster create -s pyramid_routesalchemy >> >> Maybe the actual "templates" commands could even be hidden from the help and >> simply supported if ran with a deprecation warning. >> >> Just throwing it out there, as I'm sure it's more complicated than that. A >> lot of the templating code for Paste is kind of scary. > > We sure can! In fact, several of us have the commit rights needed. :) > > Deprecating the old one is definitely an option. That's a good idea. Just updating the output would avoid the confusion. I wouldn't deprecate -t though (even if you deprecate the long form --template), because many people are used to typing it and it would be annoying to get deprecation warnings all the time. -- Mike Orr -- 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: WebHelpers conflict #63 and #59
I changed the .__slice__ to .__getitem__. This passes the tests in the SQLAlchemy and sliceable cases. I think it will let some non-sliceable cases through which would cause the original Sprox error, but i don't think there's anything we can do about that because we can't check whether .__getitem__ accepts a slice without calling it and guessing what the exception means, and calling it may cause side effects (like a db query). So if y'all can make sure you're satisfied with it, I'll release beta 2 in a day or two. -- Mike Orr -- 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: WebHelpers conflict #63 and #59
Update: I found a way to check for the exact exception reported, which
was common to the Sprox failure and other unsliceable failures
("TypeError: unhashable type"). So I can at least raise the
incompatible message so users will know what's going on.
On Tue, Mar 22, 2011 at 10:21 PM, Mike Orr wrote:
> I changed the .__slice__ to .__getitem__. This passes the tests in the
> SQLAlchemy and sliceable cases. I think it will let some non-sliceable
> cases through which would cause the original Sprox error, but i don't
> think there's anything we can do about that because we can't check
> whether .__getitem__ accepts a slice without calling it and guessing
> what the exception means, and calling it may cause side effects (like
> a db query).
>
> So if y'all can make sure you're satisfied with it, I'll release beta
> 2 in a day or two.
>
> --
> Mike Orr
>
--
Mike Orr
--
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: Terminology Change - Template to Skeleton
On Wed, Mar 23, 2011 at 3:31 PM, Philip Jenvey wrote: > > On Mar 22, 2011, at 7:14 PM, Mike Orr wrote: > >> On Tue, Mar 22, 2011 at 6:46 PM, Ben Bangert wrote: >>> >>> >>> We sure can! In fact, several of us have the commit rights needed. :) >>> >>> Deprecating the old one is definitely an option. >> >> That's a good idea. Just updating the output would avoid the >> confusion. I wouldn't deprecate -t though (even if you deprecate the >> long form --template), because many people are used to typing it and >> it would be annoying to get deprecation warnings all the time. > > FYI you'd only get the warnings in <= Python 2.6. As of 2.7/3.2, > DeprecationWarnings are hidden by default. > > I'd actually want an annoying warning shown the user at some point, but just > not immediately. I'd make it a PendingDeprecationWarning (hidden everywhere > by default) for a while. "-t" doesn't have to mean anything, it's just an option letter. "paster create -t" rolls off the fingers after you've typed it often enough. It can be kept as an alias for "paster create -s". (Or -b.) -- Mike Orr -- 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: Form handling in Pyramid
On Tue, Mar 29, 2011 at 4:06 AM, karantan wrote: > Hi, > > So is there any news if pyramid will have anything like "from > pylons.decorators import validate"? i tried to use formencode but it's > not so easy to implement in pyramid. i will try formish next and i > hope i'll have more success with it... Have you tried pyramid_simpeform? It's a different interface than @validate but it seems to be becoming the most common on on Pyramid. -- Mike Orr -- 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: ATTN: Please keep general discussion on pylons-discuss
On Thu, Mar 31, 2011 at 7:14 AM, Chris Withers wrote: > On 15/03/2011 20:01, Ben Bangert wrote: >> >> Here's a quick way to know which one to post to: >> pylons-devel >> - Discussion about development of pylons project libraries such as >> pylons/pyramid/etc. >> >> pylons-discuss >> - General discussion about best practices of development, asking for help, >> etc. > > How about just merging the lists? > > Is there really so much volume as to justify two lists? > Having a -devel and -discuss list always feels like elitism to me, in that > the people who can actually help hang out on -devel, and the people who need > it on -discuss :-S That sounds more like a prejudice than anything that's happening on the lists. It happens on lists that have hundreds of messages a day like Debian, but those groups also have more developers so some of them remain on the user list. The two lists are meant to be a convenience for users, so that those who don't care about minor/theoretical development discussions and trivial "This page on the website doesn't work" or "You forgot to change the version number in this place" can skip it. All the developers are on the -discuss list and answer questions there. But sometimes when I have too much mail, I don't read messages based on their subject lines. That would happen with either one list or two. We did take usage questions on -devel in the alpha days of Pyramid, to prevent Pyramid questions from confusing Pylons users. That's where all the confusion between the lists came from. That's over now. -- Mike Orr -- 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: GSoC, Python 3 dependencies, Paste
On Thu, Apr 7, 2011 at 7:58 AM, Juliusz Gonera wrote: > OK, it took me some time but I finally wrote the application: > http://blog.juliuszgonera.com/wp-content/uploads/2011/04/gsoc-pyramid.pdf > > I'm not sure if I should put something more in milestones. PSF wiki > (http://wiki.python.org/moin/SummerOfCode/Application) suggests listing > week-by-week work plan, but I'm not sure it's suitable for this project. I > guess many things can change, but if a week-by-week work plan is recommended > I can prepare a draft. On the other hand side, their own application > template lists only those 3 milestones (start, midterm, final). Week by week is probably not realistic because you don't know how long each part will take, and the tasks probably won't fall on week boundaries. Still, if you can identify a sequence of steps that must be taken for each milestone, you can estimate the number of days for each step. E.g., write tests for this subpackage, that subpackage, etc. Leave at least the last week of each milestone free for contingencies. > Also, I'd like you to comment on the packages chosen by me to be ported (too > little / too much work?) My main concern about all the applications is that I'm not sure we can accurately predict that this far in advance how long each package will take and their relative importance. (I'm only talking about applications related to porting to Python 3/unit testing; I'm not sure if there are any applications outside that.) That partly depends on what all the GSOC students and other developers do over the summer. What I'm saying is that while we can make tentative student-to-package assignments up front, I think we'll need the flexibility to re-evaluate this midterm-ish. Just to discuss between the students/mentors/group leader whether the second-half assignments still make sense or whether a student may want to change packages. Because the ultimate goal is to run Pyramid on Python 3, and we need to avoid giving one package too much attention and another package too little. For instance, most of the applications are focused heavily on Ian's packages (Paste, WebOb, WebError, etc.) This may be appropriate for not; I'm not sure; ChrisM would have a better handle on that. But we can't have two students working on the same package, or rigidly focus on a few packages that turn out to be too easy or too marginal (e.g., 10% of the problem). That's where I think flexibility comes in. It would reassure me if applications indicate whether students are willing to consider working on other packages if it seems appropriate at the time, and perhaps list alternate packages that they'd be most (or least) interested in working on. The other thing I'd like to see in all the applications is a more specific indication of the person's Python programming experience. E.g., what kinds of packages or programs you've worked on, the kinds of Python complexity involved in that, etc. Writing unit tests probably requires just basic Python experience, but porting may involve more depending on the package. For instance, I have a solid background with (Mako-style) templating, database models, URL dispatch and tag builders, but not much with the Zope-style interfaces or traversal. So I'm fine with anything database-y but if it involves ZCA or garbage collection or packet tracing, I'd probably want to call in the experts. Anyway, it helps to know up front what kinds of tasks a student can jump right into and what kinds would be more difficult. -- Mike Orr -- 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: Session differences in Pylons and Pyramid
On Mon, May 23, 2011 at 3:44 AM, Wichert Akkerman wrote: > On 5/23/11 12:23 , neurino wrote: >> >> > Creating tables and adding initial content is better done with paster >> setup-app or another separate command. >> >> But setup-app is not present in pyramid. > > setup-app is a PasteDeploy thing. You can use it with pyramid apps if you > want to, but I would recommend using a paster command approach instead: much > simpler and does not suffer from the many problems setup-app has. Akhet has a stub script for initializing the database (myapp.scripts.create_db). This replaces "paster setup-app". You can either use this, make a Paster command, or use setup-app. I wouldn't recommend setup-app though because it has a lot of old questionable code, and the main features it provides are for writing files, not initializing databases. So a lot of your work will be working around features you don't need. -- Mike Orr -- 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: route_url _query None value behavior
webhelpers.util.update_params deletes any parameter with a value of
None. Mako templates converts None values to ''. Having None convert
to "None" is almost never useful in query parameters, while having
integers and other types converted to strings is useful. So that all
argues for trapping None and either converting it to '' or deleting
the parameter.
On Sat, May 21, 2011 at 7:39 PM, Chris McDonough wrote:
> Don't think this is really right if you consider the desire to be able
> to pass integers (like 0), which others have requested before.
>
> What precedent is there to passing the value None being converted to
> empty string?
>
> - C
>
> On Sat, 2011-05-21 at 18:35 -0700, Jerry wrote:
>> Google group messes with the formatting, which should have been --
>>
>> else:
>> if v.__class__ is unicode:
>> v = v.encode('utf-8')
>> if v:
>> v = quote_plus(str(v))
>> result += '%s%s=%s' % (prefix, k, v)
>> else:
>> result += '%s%s=' % (prefix, k)
>>
>> Jerry
>>
>> On May 22, 9:32 am, Jerry wrote:
>> > Hi,
>> >
>> > Pyramid's route_url/route_path behavior with None _query terms doesn't
>> > seem very canonical to me --
>> >
>> > (Pdb) request.route_path('home', _query=[('q', None)])
>> > '/home?q=None'
>> >
>> > Omitting value is more like it --
>> >
>> > (Pdb) request.route_path('home', _query=[('q', '')])
>> > '/home?q='
>> >
>> > so is omitting both --
>> >
>> > (Pdb) request.route_path('home', _query=[('q', [])])
>> > '/home?'
>> >
>> > Chris and other Pyramid maintainers: would you consider adding this
>> > simple check to urlencode() in pyramid/encode.py ? --
>> >
>> > 89 for (k, v) in query:
>> > 90 if k.__class__ is unicode:
>> > 91 k = k.encode('utf-8')
>> > 92 k = quote_plus(str(k))
>> > 93 if hasattr(v, '__iter__'):
>> > 94 for x in v:
>> > 95 if x.__class__ is unicode:
>> > 96 x = x.encode('utf-8')
>> > 97 x = quote_plus(str(x))
>> > 98 result += '%s%s=%s' % (prefix, k, x)
>> > 99 prefix = '&'
>> > 100 else:
>> > 101 if v.__class__ is unicode:
>> > 102 v = v.encode('utf-8')
>> > if v:
>> > 103 v = quote_plus(str(v))
>> > 104 result += '%s%s=%s' % (prefix, k, v)
>> > else:
>> > result += '%s%s=' % (prefix, k)
>> > 105 prefix = '&'
>> >
>> > Thanks.
>> >
>> > Jerry
>>
>
>
> --
> 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.
>
>
--
Mike Orr
--
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 Brainstorm & Marrow
*. But we (Pyramid) need to stop and think awhile about what we want to replace it with. > On marrow.server.http: > >> The underlying communication stack (marrow.io/server) is fundamentally >> async. That particular fact has zero (and I mean it, zero) impact on writing >> WSGI applications that run under the HTTP/1.1 implementation. The underlying >> stack also has full support for a worker thread pool (using Futures) and >> multi-processing. Both of these details are handled for you by the web >> server; if you enable a thread pool, communication is still handled using >> async, but the WSGI application is executed in a thread. This allows you to >> tune a deployment for your requirements. Development or io-bound? Run a base >> server. CPU-bound? Run a threaded server. Need to scale? Add >> multi-processing to either of those. > > I'll mention it again, since this point is very important: the underlying > server being async has ZERO impact on your own applications. It's not like I > magically monkeypatched async support in everywhere; no, instead, only the > core reactor for I/O (which makes sense) is async. The HTTP protocol > implementation plugged into marrow.server either runs the WSGI application > inline (which blocks other requests if not fast enough) or in a thread pool, > your choice. (Choice is good! I have an RPC service running in pure async > mode that can handle ~6KRsec; threading slows it down!) If you can put this in a Pyramid/Marrow HOWTO, it would make users more comfortable about trying it. Most Pyramid/Pylons users come from a multithreaded background. They either know or have learned how to make their views thread-safe. Many have not used async servers and don't know how to make their views async-safe. Normally it involves using special database libraries, socket wrappers (if the view itself is invoking web services or doing RPC etc), and also thinking about what else might be an intolerable blockage (e.g., parsing or producing a multigigabyte file). You say that Marrow users don't have to worry about any of these. In that case, please explain in the HOWTO how to configure Pyramid/Marrow for the various modes, the actual effect of typical blocking constructs (SQLAlchemy, web services, etc) on the various modes, and how Marrow's thread pool compares to PasteHTTPServer's thread pool. Explaining it in the terminology that Pyramid and Pylons users are familiar with will go a long way in making users more willing to try Marrow, and the Pyramid developers more willing to consider Marrow. >> Proper releases of marrow packages require 100% unit test coverage, >> documentation, and multiple working examples. In that case, suitable documentation may already be written. You'd just need to paste some paragraphs into a HOWTO and reword it a bit so that users can see how THIS [what I'm familar with in Pyramid] corresponds to THAT [something new in Marrow]. The correspondence may seem obvious to you, but not necessarily to users. And users may not be willing to spend time figuring out what the correspondence is; they'll just move on to another library. > One of the easiest ways to examine these libraries are via the example code > [2][3], and through the code for the libraries themselves. Additionally, > you'll have to dig into a fork [4] to see demonstrations of WSGI1 > compatibility in marrow.server.http. The adapter [5] is simple, and likely > incomplete, but functional. I'm probably sounding redundant here, but only those who are especially motivated to use Marrow will follow all those references and figure out the correspondence between those examples and Pyramid. Others will move on unless there's a Pyramid-specific HOWTO. Of course, it may not be worth your while to write such a thing, depending on how important Pyramid is to you. But if you seriously want to spread Marrow adoption and/or Pyramid is important to you, it would be worth your while. -- Mike Orr -- 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: Adding "abort" and "redirect" to Pyramid
On Sun, May 15, 2011 at 11:27 PM, Chris McDonough wrote:
> I've created a branch named "httpexception-utils" on GitHub which
> contains an implementation of "redirect" and "abort" for Pyramid that
> act like their Pylons brethren.
>
> In short, the abort feature is used like this:
>
> from pryamid.httpexceptions import abort
>
> def aview(request):
> abort(401)
>
> This will perform the same job as what used to be necessary as:
>
> def aview(request):
> return HTTPUnauthorized()
>
> The redirect feature is used like this:
>
> from pryamid.httpexceptions import redirect
>
> def aview(request):
> redirect('http://example.com')
>
> This will perform the same job as what used to be necessary as:
>
> def aview(request):
> return HTTPFound(location='http://example.com')
>
> In addition, any "HTTP exception" (an exception imported from
> pyramid.httpexceptions) can now be raised rather than returned. The
> object raised will be used as a response.
>
> Here's the branch:
>
> https://github.com/Pylons/pyramid/tree/httpexception-utils
>
> Here's the commit which added the feature:
>
> https://github.com/Pylons/pyramid/commit/1ffb8e3cc21603b29ccd78152f82cca7f61a09b1
>
> It'd be nice to get some feedback from existing Pylons users to see if
> the implementations of these features are "good enough"; it'd also be
> nice to hear dissenting opinions with reasons for dissent if folks
> believe this feature should not be added to Pyramid.
Raising HTTP exceptions should definitely be added to Pyramid. It's
silly for an application to have to add an exception view that just
returns the exception: it feels kludgy, it's not what views are for,
and it adds to the overhead. Why can't the code that invokes the view
just have an 'except HTTPException:'? If the user really wants to
register an exception view in order to display a fancy-dancy page,
that's another thing. It seems like Pyramid should be able to
accommodate both.
HTTP errors *are* exceptions. If you call a support method and it
discovers that a required query parameter is missing, what's it
supposed to do? The request can't continue, so it might as well kill
it right there. That's directly akin to a ZeroDivisionError. 'raise'
has two advantages. One, it shortcuts the call stack so you don't have
to return some dummy value, or define another exception just to catch
it later. Two, 'raise' is a Python keyword so it's syntax-highlighted
and users should be expecting it.
abort() and redirect() are not necessarily the most intuitive but I
can't think of any better API for them. I did use them a lot in Pylons
and I miss them a bit in Pyramid. They do have the disadvantage that
they look like normal returning function calls instead of having that
'raise' keyword. 'redirect' is particularly useful because it's not
intuitive that 'HTTPFound' means "I'm doing a redirect". If you see it
often you get used to it, but otherwise it's like, "Oh, nice, it found
something. That doesn't tell me what it's going to do with it." I
think that's a shortcoming of the HTTP status: it should have been
called 'Redirect' rather than 'Found'.
BTW, I mentioned a few days ago that my application is displaying a
blank page when I return HTTPNotFound or HTTPBadRequest, so something
is missing somewhere. The HTTP status is right but the body is empty,
no "Not Found" or anything.
--
Mike Orr
--
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: Adding "abort" and "redirect" to Pyramid
On Thu, May 26, 2011 at 6:15 AM, Daniel Holth wrote: > 'return' makes sense because views return a response. Whether the response > has an error code of 200, 301 or 5xx is a separate concern. Of course > exceptions make sense too. This only became an issue because HTTPException happens to be a WSGi application so it looks like a view return value. It would have been better if it were just an Exception subclass so there would be no question they should be raised and caught. In fact, I'm not even sure the body and headers of the HTTPException should be honored; it's really the job of the framework to decide how to display HTTP errors (possibly using a plugin such as an error-view to customize it). in Pylons, if the StatusCodeRedirect middleware is active, it makes a subrequest. If it's not active, something in Pylons or Paste generates a plain error message including the title, description, and (in debug mode) the exception's 'message' argument. It's certainly not the responsibility of the code that discovers an inconsistency necessitating a 4xx or 5xx error to style it: the error is rarely the main purpose of the function; it's just something the function wants to get rid of as quickly as possible. If the view really wants to RETURN a 4xx or 5xx condition, it can set 'request.response_status_int' the normal way rather than invoking HTTPException. Or it can instantiate the exception and pass it to an application-making function that would turn it into a WSGI application (something like the HTTPException constructor), and return that. -- Mike Orr -- 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 Brainstorm & Marrow
On Thu, May 26, 2011 at 3:39 PM, Alice Bevan–McGregor wrote: >> Argparse does what it does reasonably well; I have not yet gotten sick >> enough of it to jettison it. > > For sure there is no point taking an existing working solution and throwing > it to the wind to re-engineer it under a different parser. Marrow.script is > primarily targeted at people who either have an existing callable > (class/method) they want to expose as a command-line script, or for those > who want to write really, really fast one-off scripts. That *is* the issue. Marrow is ideal if you have a function like: myfunc(a, b, c=1, d=None): "a is a string; b is a list of strings; c is an int; d is an optional string" And you want to publish it without replicating your argument structure in Argparse. On the other hand, those who are already using Argparse may find Marrow unnecessary, too magic, and something else to learn. But Pyramid is a different situation than either of these. The main function in a pyramid application is: main(global_conf=None, **local_conf): "global_conf is an optional dict; local_conf is keyword args, potentially parsed from a file" settings = local_conf init_component_1(settings) init_component_2(settings) 'main' does not know what all the required arguments are. Instead, each components finds the arguments it needs in the settings dict. Theoretically there could be a validator at the beginning of the function that checks all the settings. But none of this is specific enough for @argument-like decorators on the function. What Paste mainly does is to convert an INI file like this: [app:myapp] use = entrypoint#main arg1 = value1 arg2 = value2 into a function call. "entrypoint#main" is an entry point that maps to some callable. The other keys become arguments to that call. This is something beyond what Marrow's arg parsing does. So anything that replaces PasteDeploy would have to do this or the equivalent. >> I'm probably sounding redundant here, but only those who are especially >> motivated to use Marrow will follow all those references and figure out the >> correspondence between those examples and Pyramid. Others will move on >> unless there's a Pyramid-specific HOWTO. > > I'm posting on the Pyramid/Pylons *developer* list, not the user list, so > I'd expect the "open-mindedness"/curiosity level to be somewhat higher, as I > would also expect the tolerance to non-Pyramid-specific content to be > higher. Unfortunately, the majority of the Marrow projects that could > benefit Pyramid would require core changes, thus a fork and a number of > branches to explore the options, not just add-on packages or adaptive > HOWTOs. I can see your point. It's just that it's not a case of Pyramid choosing between alternatives it knows it needs. It's a case of you promoting an alternative that Pyramid isn't sure it needs, so it wants to make sure it does need it before putting a lot of time into it. -- Mike Orr -- 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 Brainstorm & Marrow
On Thu, May 26, 2011 at 3:39 PM, Alice Bevan–McGregor wrote: > Unfortunately, the majority of the Marrow projects that could > benefit Pyramid would require core changes, thus a fork and a number of > branches to explore the options, not just add-on packages or adaptive > HOWTOs. In that case, what might be better than a HOWTO is an outline of how the packages could be integrated. I.e., which specific parts of Pyramid would interface with which parts of the Marrow suite. If you need help analyzing the Pyramid side, i may be able to help with that ; i.e., looking under the surface in Pyramid and what design requirements it has at that particular point. -- Mike Orr -- 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: Adding "abort" and "redirect" to Pyramid
On Tue, May 31, 2011 at 12:55 PM, Chris McDonough wrote:
> - We will disuse the classes from webob.exc because, although they
> advertise themselves as Response objects, they really very badly
> want to be used as WSGI applications rather than "plain response"
> objects.
Aren't all Response objects WSGI applications? I thought that was part
of the API, that they could serialize themselves.
> - "pyramid.response.Response" will now be a *subclass* of
> webob.response.Response (rather than an alias) which will
> both inherit from Exception (so it can be raised) and will provide
> the pyramid.interfaces.IExceptionResponse interface.
Can't anything be raised regardless of whether it inherits from
Exception? (And for new-style classes, if the Python version is recent
enough.) I think Pylons' abort() raises HTTPException subclasses,
doesn't it?
So I don't see how these new exception classes will be different from
the old ones except for a new parent and interface, which doesn't
really affect the user.
> After the above steps are taken, "raise
> pyramid.response.HTTPUnauthorized(...)" from within view code (or
> event handler code) will generate a 401 response code with a default
> body out-of-the-box. It will mean (probably more controversially)
> "raise Response('OK')" will generate a 200 response code with the body
> "OK".
It may be an unorthodox way to return but it's probably better to just
allow it than to take steps to prevent it. I could see how it could be
a "feature" in a few cases. And again, Python doesn't seem to be
overly concerned with what you raise. The move against string
exceptions was to make sure you provided the actual class in the
'except' clause rather than comparing by equality.
--
Mike Orr
--
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: Adding "abort" and "redirect" to Pyramid
On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
wrote:
> Hi,
>
> This post totally went over my head and there's a lot to read which I
> don't feel like doing right now, so I'll just give my 2 cent straight
> away (and if it was already addressed, reply "already addressed", and
> I will dig into the thread's archives):
>
> 2011/5/15 Chris McDonough :
>> def aview(request):
>> abort(401)
>>
>> def aview(request):
>> redirect('http://example.com')
>
> What I *really* didn't like with Pylons abort() and redirect() was the
> fact that that these functions were stopping the code flow without a
> return statement.
We could just make abort() and redirect() helper functions that return
an exception, which the user would then raise. The priority for me is:
1. Make HTTPExceptions raisable by default.
2. Add a helper to construct a redirect:
redirect(location, **kw) => HTTPFound(location=location, **kw)
3. Add a helper to construct an abort:
abort(N, message=None, **kw) =>
httpexception_by_number(status=N, message=message, **kw)
4. Make abort() and redirect() raise their result rather than returning it.
#1 is important so that you can cut through multiple function calls if
you discover an error condition.
Use case 1: a support method/function for several handlers
discovers a required query parameter is missing. The application's
forms and links would never produce such a request, so we presume the
request is illegitimate and abort 400.
Use case 2: a support method/function discovers that a required
support file is missing, an authentication server is unreachable, etc.
This is a webmaster/sysadmin error so we abort 500.
#2 is important because HTTPFound is not very self-documenting, and we
shouldn't have to specify the location by keyword argument since it's
the entire purpose of the call.
#3 is useful but perhaps not necessary. It's convenient but not
necessary self-documenting because you have to memorize all the
numbers. It's also helpful to have a message as a positional argument.
This would be added to the error message. This has been proven useful
in Pylons. A further enhancement would be to have both a secure and an
insecure message. The secure message would appear in the default error
screen, while the insecure message would be included in the sysadmin's
error report.
#4 is minimally useful. They do have the significant downside of
looking like returning function calls when they actually change the
program flow. It would be fine if they simply return the error and the
user raise it explicitly.
raise redirect(location)
raise abort(N, message=None)
Or they could be capitalized to appear more like class constructors:
raise Redirect(location)
raise Abort(N, message=None)
--
Mike Orr
--
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: Adding "abort" and "redirect" to Pyramid
On Wed, Jun 1, 2011 at 11:39 PM, Chris McDonough wrote:
>> #1 is important so that you can cut through multiple function calls
> if
>> you discover an error condition.
>> Use case 1: a support method/function for several handlers
>> discovers a required query parameter is missing. The application's
>> forms and links would never produce such a request, so we presume the
>> request is illegitimate and abort 400.
>
> The folks I've talked to on the "don't turn HTTPExceptions into
> responses by default" side of the debate argue that both use cases above
> are poor coding practices because only "view code" (code that is
> contacted only because a view was matched, as opposed to random things
> that that view may call into) has enough information to be able to
> return a sensible response. They further argue that since it's so easy
> to "turn on" the feature, allowing folks that don't share their opinion
> to do it, Pyramid shouldn't do it by default. Just FYI, that's the
> other side of the argument.
OK, but there's such a thing as view support methods, code that's
common to several views so it doesn't have to be repeated in all of
them. That's the only place where I'd use this. For instance:
class MyHandler(object):
def my_view(self):
params = self.request.params
self._process_id(params.get("id"))
# Private methods
def _process_id(self, id_str):
if id_str is None or not id_str.isdigit():
abort(400, "query param 'id' missing")
id = str(id)
self.record = model.Something.get(id)
if self.record is None:
abort(404, "that Something does not exist")
--
Mike Orr
--
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: Adding "abort" and "redirect" to Pyramid
On Thu, Jun 2, 2011 at 12:03 PM, Wichert Akkerman wrote:
> On 2011-6-2 19:20, Mike Orr wrote:
>>
>> OK, but there's such a thing as view support methods, code that's
>> common to several views so it doesn't have to be repeated in all of
>> them. That's the only place where I'd use this. For instance:
>>
>> class MyHandler(object):
>> def my_view(self):
>> params = self.request.params
>> self._process_id(params.get("id"))
>>
>> # Private methods
>> def _process_id(self, id_str):
>> if id_str is None or not id_str.isdigit():
>> abort(400, "query param 'id' missing")
>> id = str(id)
>> self.record = model.Something.get(id)
>> if self.record is None:
>> abort(404, "that Something does not exist")
>
> Personally I find that this coding style makes it hard to read code: you are
> basically rewriting a standard language feature (raising an exception) in a
> way that makes it look like a normal function call.
That's only in the difference between "abort()" and "raise abort()".
As I've said, I'm not opposed to requiring the latter, and I think it
might actually be a good thing.
--
Mike Orr
--
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: When the Pyramid Migration Guide will be completed?
Migrating from Pylons? That would be the Akhet manual. https://docs.pylonsproject.org/projects/akhet/dev/ On Sat, Aug 13, 2011 at 1:42 AM, Max Avanov wrote: > Subj. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/pylons-devel/-/st7DLdZbkRgJ. > 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. > -- Mike Orr -- 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: Logging configuration
On Fri, Oct 21, 2011 at 5:51 AM, Chris McDonough wrote: > On Fri, 2011-10-21 at 02:50 -0700, Mattias wrote: >> I am setting up a little test application using pylons and pyramids, I >> am currently using mod_wsgi under apache2 as the server. So far >> everything works perfectly except my logging. I have tried to change >> the >> >> On the page >> http://docs.pylonsproject.org/projects/pyramid/1.2/narr/logging.html >> is says "This chapter assumes you’ve used a scaffold to create a >> project which contains development.ini and production.ini files which >> help configure logging. All of the scaffolds which ship along with >> Pyramid do this." >> >> Later on it says "The paster serve command calls the >> logging.fileConfig function using the specified ini file if it >> contains a [loggers] section (all of the scaffold-generated .ini files >> do). logging.fileConfig reads the logging configuration from the ini >> file upon which paster serve was invoked." >> >> I use paster in my wsgi file, http://pastie.org/2734261, but I know >> you can also use paster as the server. >> >> Will the automatic logging configuration only work if I am using >> paster as the server? > > In short, yes. But technically, paster is not the server. "paster > serve" *runs* a server, but it is not a server. Automatic logging > configuration takes place when you use "paster serve". If you don't use > "paster serve", it doesnt happen. "paster serve" does the equivalent of: import logging.config logging.config.fileConfig(INI_FILE) You can put that in your startup code somewhere. Python 2.7 also has a new 'dictConfig' function that takes a nested dict structure instead of a filename, if you find that more convenient. -- Mike Orr -- 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: suggestion for scaffolds
On Fri, Feb 3, 2012 at 9:28 AM, Jonathan Vanasco wrote: > 2. migrate all the /static/ items to /static/pyramid/ > > it's too cluttered and slightly intimidating , and when you're playing > around... i want to clean out those files but I don't want to lose > them (yet). +1 I usually delete them immediately, but when I started I was reluctant to because I didn't know which ones I might want to use or refer to. -- Mike Orr -- 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.
Cleaning up the Pylons GitHub project
I noticed that the pyramid-collective GitHub project has been created for unofficial add-on packages. https://github.com/pyramid-collective With that, we need to decide which repositories in should remain in Pylons and which ones should move to the collective. There are over 50 repositories, some best-of-breed, some up-and-coming, and some past their prime. With that many packages of varying quality, it's hard to tell the gems from the chaff. I'm moving SQLAHelper now, but what about pyramid_handlers and pyramid_routehelper? https://github.com/Pylons/pyramid_handlers https://github.com/Pylons/pyramid_routehelper Both of them have recent commits. pyramid_handlers is an old design pattern that did not turn out to be as useful as expected, although it works. pyramid_routehelper I thought was unfinished and not ready for use, but somebody added tests to it 11 months ago. Does it work? (It provides Routes-style resource routes, which Pyramid doesn't do natively.) I'd suggest moving pyramid_handlers to the collective as a has-been design pattern. pyramid_routehelper provides a unique feature, so it might stay in Pylons if it's reliable. It depends on whether we think resource routes is important enough to be in the main project. There are a lot of other packages in Pylons that I know nothing about, so I don't know how current/best-of-breed they are. pyramid_rpc pyramid_mailer pyramid_exclog pyramid_jqm pyramid_xmlrpc jslibs pyramid_who (*) pyramid_ldap (*) pyramid_zodbconn pyramid_zodbsessions peppercorn shootout pyramid_viewgroup cluegun translationstring pyramid_formish repozitory jove jove_catalog pyramid_skins pyramid_registration zodburi pyramid_errmail pyramid_traversalwrapper stateof limone limone_zodb breckenridge pyramid_metatag groundhog guillotine miniconference hybridauth It would be good to put every repository's status in its description or README. But how do you set the description? I've never found an edit box for it, yet somehow some of my repositories have descriptions. The README is automatically displayed when you go to the repository, but that doesn't help when you're going down the list of repositories and don't want to open all of them. -- Mike Orr -- 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: How important is the file structure (templates and static folder) in the package of a Pyramid Project
On Sun, Sep 23, 2012 at 9:43 AM, Raj Nathani wrote: > Hey I'm kind of new to Pyramid and web frameworks in general. One of the > things I've learnt so far is that every Pyramid project created with a > starter > scaffold has a package in which there are two folders - templates and > static. > > Is it necessary to keep the structure this way? Would the whole thing work > fine if the folders were renamed/in-existent (with template and static files > out one level higher in the projects root folder instead)? I'm pretty sure > it isn't. The main issue is specifying the paths. "myapp:templates/...", or "templates/...", depends on the directory being inside a Python package. MyApp/myapp is an importable Python package. MyApp isn't. You'd have to create a relative path using __file__, or specify an absolute path, and I'm not sure if these are compatible with add_static_view() or renderer= anyway. > But that > brings me to my next question, which is about the 'static' folder, I've > seen calls from python scripts within the project which declare in some of > way that 'static' content is served from 'static' folder. How does this > help? > Does Pyramid have a different and faster way of serving files which it > knows are static? No, it's a convenience for the developer. The scaffolds predefine a view for URL "/static" pointing to "myapp:static". That provides a place for all static files to go, without the developer having to define a view and a directory. You can of course have multiple static directories for different purposes. The fastest way to serve static files in production, is to arrange for the main webserver (Apache) to serve the static directory directly rather than passing those requests to the application. -- Mike Orr -- 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: Sites using Pyramid & Pyramid Advocacy
On Fri, Oct 26, 2012 at 1:35 PM, Iain Duncan wrote: > >> >> What is the objective? To promote Pyramid or to promote third parties >> using Pyramid? If the former then having a well-curated list of showcase >> examples seems best. If the later then there may be an argument for opening >> it up to make it easy for people to submit their own sites. It's possible >> to do both but probably not in the same place. >> > > For me personally, the objective is to be able to show people and clients > that Pyramid is used extensively in real world applications. In that sense, > I agree some curation is probably necessary, as on the SQLAlchemy page. But > I think it also helps just to have a really big list, much like Plone does. Well. different people are looking for different things. Some people want to see big names and high-traffic sites. Others want to see really extensive sites doing a lot of things. Others want to see a large number of sites. Others want to see a wide variety of innovative features in the sites. The latter includes those who aren't using Pyramid yet and want to see what it can do, and also those who are using Pyramid and looking for ideas for their own sites. -- Mike Orr -- 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: Is there a need to mention non-final release version in 'versionadded' directives?
On Sun, Jan 27, 2013 at 9:42 AM, Tshepang Lekhonkhobe wrote: > Could we simply remove this? Does a user need to know which exact alpha (or > beta) release an API was added? I think such detail is a bit of overkill for > 'versionadded' Sphinx directives; it's better left in VCS history. > > ok: added in 1.4b2 > better: added in 1.4 It can go either way depending on context. The first couple versions of Pyramid needed it because major API changes were being made between development versions, so it was necessary to tie to the version with the right API in order to develop your application. Some other projects have long beta periods and there's not as much distinction between betas and final, so the betas get used in applications. I guess this mostly happens with small libraries like WebHelpers and Routes, where most changes are adding a little incremental feature. With Pyramid not undergoing major structural changes now, it would be fine to say "added in 1.4", and people can look at the Changelog if they want to know the specific beta. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: question about design decision on pyramid's core
I don't know officially, but Chameleon was added a lot earlier and the code may be inherited from BFG. Mako was added for the Pylons integration because Chameleon would have been too big a change for them. At the time it was thought that these would be the built-in template engines and others would be third-party. Since then mcdonc has talked about spinning those off too, as pyramid_chameleon and pyramid_mako, but that hasn't happened yet. On Wed, Mar 27, 2013 at 10:44 AM, Jonathan Vanasco wrote: > looking at the source, I see: > > * pyramid/chamelon_text.py > * pyramid/chamelon_zpt.py > * pyramid/mako_templating.py > > was there any reason for these being on the top-level, and not under a > consolidated namespace like pyramid/templating , or did this just > happen randomly ? > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to pylons-devel+unsubscr...@googlegroups.com. > To post to this group, send email to pylons-devel@googlegroups.com. > Visit this group at http://groups.google.com/group/pylons-devel?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Wanted: HTML tag generator for WebHelpers2
I'm thinking about rewriting the low-level HTML tag generator in
WebHelpers2, and wondering if there's an existing library that would be
worth using in this HTML 5/Python 2.6+ world. Something to reimplement the
low-level make_tag function:
make_tag("a", "Click here", href="foo.html") =>
"Click here."
The stdlib seems to only have ElementTree, which is overkill and not that
suited to making individual tags in isolation. The libraries on PyPI seem
to be very old, older than the WebHelpers implementation. So I'm looking
for something that's:
- In the stdlib, or small and with no esoteric dependencies.
- Fast.
- Without ancient HTML 4/3 clutter.
- Compatible with MarkupSafe and the ''.__html__()`` protocol.
Other desirable features:
- Knows about HTML 5's empty tags, boolean attributes, data attributes, etc.
- Can set characteristics at the class level, and is subclassable.
- Has a Tag class or equivalent for lazy stringification. This would allow
you to build up the attributes piecemeal, pass the tag to a template, and
it would stringify itself when str() or .__html__() is called. Possibly
caching the string.
Is there a library that does this or should I write it myself?
I'd also like feedback on another idea. I'm thinking about adding arguments
to build up the class attribute and style attribute piecemeal:
make_tag(..., classes=["foo", "bar"]) => ' ... class="foo bar"'
make_tag(..., styles=["margin:0", "padding: 1ex"]) => '...
style="margin:0; padding: 1ex")
Would this be useful to others? Would the names collide with any other
potential attributes? (I don't think so since HTML doesn't define "styles"
and "classes", and is unlikely to because of user confusion.) Is there a
better API? Are there any other attributes where this would be useful on?
Are there any other syntactic sugar patterns that would be helpful in a
Javascript-rich or HTML 5 application?
--
Mike Orr
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
Version b3 converts arguments like "data_a_b" to "data-a-b". It's not in
PyPI (I must have forgotten that step) but it's in the source. Version b4
will probably be out this weekend, with at least 'classes' and 'styles',
because I need that for a project.
There was some discussion about whether there is ever any use case to *not*
convert underscores; i.e., whether it needs to be switchable outside the
specific case of "data_" -> "data-". I don't think so because the HTML spec
seems to say that only hyphens are valid in attribute names.
On Fri, Jun 28, 2013 at 2:31 PM, Jonathan Vanasco wrote:
>
>
> On Friday, June 28, 2013 5:04:08 PM UTC-4, Mike Orr wrote:
>>
>>
>> Are there any other syntactic sugar patterns that would be helpful in a
>> Javascript-rich or HTML 5 application?
>>
>
> you should support html5 custom data attributes , the *data-** syntax.
>
> ie:
> http://example.com"; data-a="1" data-b-a="2">Link to
> Example.com
>
> you can have one (or more) dashes in them, so I'm not sure how you could
> pass them in , other than as a dict
>
> make_tag(... attrs={ 'data-a' :1 , 'data-b-a':2 }... )
> make_tag(... data_attrs={ 'data-a' :1 , 'data-b-a':2 }... )
> make_tag(... data_attrs={ 'a' :1 , 'b-a':2 }... )
>
> personally i would prefer one of the first two options; i'm only bringing
> up the last one to note my disapproval of it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/pylons-devel.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Mike Orr
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
On Sat, Jun 29, 2013 at 3:11 PM, Marius Gedminas wrote: > On Fri, Jun 28, 2013 at 02:04:08PM -0700, Mike Orr wrote: >> I'd also like feedback on another idea. I'm thinking about adding arguments >> to build up the class attribute and style attribute piecemeal: >> >> make_tag(..., classes=["foo", "bar"]) => ' ... class="foo bar"' >> >> make_tag(..., styles=["margin:0", "padding: 1ex"]) => '... >> style="margin:0; padding: 1ex") >> >> Would this be useful to others? > > Yes! > >> Would the names collide with any other >> potential attributes? (I don't think so since HTML doesn't define "styles" >> and "classes", and is unlikely to because of user confusion.) Is there a >> better API? > > What about > > make_tag(..., style=["margin: 0", "padding: 1ex"]) > > and > > make_tag(..., class_=["foo", "bar"]) > > i.e. overload the type of the attribute instead of the name? That might work. And it would avoid the need to check for both keywords. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
I implemented the 'class', 'class_',' and 'style' list arguments. Version b3 looks like it was never frozen for release, so that will be the next version. My next steps, not necessarily in this order, are: reimplementing the HTML builder, converting the tests to py.test, the Python 3 port, and some small reorganizations. The online docs don't yet mention the list arguments or the underscore to hyphen conversion (for data-foo). On Sat, Jun 29, 2013 at 9:08 PM, Mike Orr wrote: > On Sat, Jun 29, 2013 at 3:11 PM, Marius Gedminas wrote: >> On Fri, Jun 28, 2013 at 02:04:08PM -0700, Mike Orr wrote: >>> I'd also like feedback on another idea. I'm thinking about adding arguments >>> to build up the class attribute and style attribute piecemeal: >>> >>> make_tag(..., classes=["foo", "bar"]) => ' ... class="foo bar"' >>> >>> make_tag(..., styles=["margin:0", "padding: 1ex"]) => '... >>> style="margin:0; padding: 1ex") >>> >>> Would this be useful to others? >> >> Yes! >> >>> Would the names collide with any other >>> potential attributes? (I don't think so since HTML doesn't define "styles" >>> and "classes", and is unlikely to because of user confusion.) Is there a >>> better API? >> >> What about >> >> make_tag(..., style=["margin: 0", "padding: 1ex"]) >> >> and >> >> make_tag(..., class_=["foo", "bar"]) >> >> i.e. overload the type of the attribute instead of the name? > > That might work. And it would avoid the need to check for both keywords. -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
On Mon, Jul 1, 2013 at 11:48 PM, Wichert Akkerman wrote: > > On Jun 28, 2013, at 23:04 , Mike Orr wrote: > > I'm thinking about rewriting the low-level HTML tag generator in > WebHelpers2, and wondering if there's an existing library that would be > worth using in this HTML 5/Python 2.6+ world. > > > In rare situations where I can't use a template library I use lxml's > E-factory to build HTML: http://lxml.de/tutorial.html#the-e-factory (or > http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory ). I thought about lxml but I think it's too big a dependency, especially with its C dependencies. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
On Tue, Jul 2, 2013 at 12:46 AM, Mike Orr wrote: > On Mon, Jul 1, 2013 at 11:48 PM, Wichert Akkerman wrote: >> >> On Jun 28, 2013, at 23:04 , Mike Orr wrote: >> >> I'm thinking about rewriting the low-level HTML tag generator in >> WebHelpers2, and wondering if there's an existing library that would be >> worth using in this HTML 5/Python 2.6+ world. >> >> >> In rare situations where I can't use a template library I use lxml's >> E-factory to build HTML: http://lxml.de/tutorial.html#the-e-factory (or >> http://lxml.de/lxmlhtml.html#creating-html-with-the-e-factory ). > > I thought about lxml but I think it's too big a dependency, especially > with its C dependencies. Maybe I should just ask the list: is lxml suitable as a tag generator for webhelpers2.html? Or is it too big for a general-purpose library, not everyone of which will be generating HTML. -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
On Wed, Jul 3, 2013 at 11:09 AM, Jason McKellar wrote: > On Tue, Jul 2, 2013 at 12:46 PM, Mike Orr wrote: >> Maybe I should just ask the list: is lxml suitable as a tag generator >> for webhelpers2.html? Or is it too big for a general-purpose library, >> not everyone of which will be generating HTML. > > I may be in the minority about dependencies, but I really don't mind have > extra dependencies if they are the right tool. It doesn't hurt that I use > lxml in most of my Pyramid applications anyway. The thing is, WebHelpers has always tried to avoid dependencies so that it can be used in the widest variety of use cases. It now depends on MarkupSafe because that's a small best-of-breed security enhancement. And I found some hidden dependencies on Pylons and Routes that I've now eradicated. Lxml to me seems large, whether that's accurate or not. And WebHelpers' need is just for a small thing, and it would use only 5% of lxml's features. I may make an HTML class with a basic Python back end, and a subclass that uses lxml if available. Did I really put this on pylons-devel? I meant to put it on pylons-discuss, but I just typed "pylons" and let it autocomplete, forgetting that pylons-devel existed. -- Mike Orr -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Wanted: HTML tag generator for WebHelpers2
On Wed, Jul 3, 2013 at 10:21 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 07/03/2013 11:12 PM, Mike Orr wrote: > >> The thing is, WebHelpers has always tried to avoid dependencies so >> that it can be used in the widest variety of use cases. It now >> depends on MarkupSafe because that's a small best-of-breed security >> enhancement. And I found some hidden dependencies on Pylons and >> Routes that I've now eradicated. > > FWIW, MarkupSafe is deliberately incompatible with Python 3.2: the > maintainer is stonewalling a trivial pull request restoring compatibility > to leverage its users to drop 3.2 and adopt 3.3: > > https://github.com/mitsuhiko/markupsafe/pull/13 > > For my money, that zeroes out any "best of breed" stamp it might > otherwise have. YMMV, of course. Mike, how are you handling smart escaping without MarkupSafe in Mako on 3.2? Are you falling back to the pre-MarkupSafe code? -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: Pyramid Design Question
On Mon, Sep 2, 2013 at 8:42 PM, Michael Zhang wrote: > Hi guys, > > My name is Michael Zhang, and I am very new to Pyramid. I have a quick > question in designing a large web application backend, and hope the > community can help me out. I really appreciate your help. It helps me to > learn and get my job done. > > My question is simple: what are some good strategies in organizing common > methods or classes for operations that we might constantly use in our > applications? For example, if we have a method to collect all the comments > belonging to a blog post, where we should put this method/class in our > application in a clear and organized fashion? To us, there are potentially > two choices: > > Choice A. We can define our model Blog, and inside Blog, we can define a > method like getAllComments. > > Choice B. We can separately define BlogCRUD class, that has methods to get > all comments. > Choice B sounds too pedantic and Javaesque. There's no reason you *can't* put methods like this in your models. However, you may choose to keep them separate for convenience. I'm actually deciding that right now as I port a Pylons application that has all queries in high-level model methods. I got tired of mixing these kinds of queries with model instance methods (e.g., to format a field or group of fields). Then I realized I could put those high-level methods in the resource tree, and that would separate them from both the model modules and the view modules. That partly depends on whether you want to have a resource tree, whether you want to use traversal, and whether you'll have access control lists. To me it seems to come down to application size: the resource tree is nice in large application, but overkill in small ones. The main separation I make in my applications is between the model and everything else; i.e., the model can't depend on or import other parts of the application, so that it can be used standalone or with another framework/user interface. So I have an 'init_models(engine)' function that sets the engine, and if I needed to pass any INI settings I would pass them as individual arguments to that function. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [pylons-devel] Should pyramid.request.Request.route_path() work for external routes?
On Sat, Oct 5, 2013 at 12:00 AM, Harvey Smith wrote: > Currently in Pyramid v1.5a2 one cannot easily loop over a list of routes to > generate the URLs (for example to generate a nav menu) if some of the routes > are external and one wished to use URL paths instead of qualified URLs > (easier to server through proxies.) This is because Request.route_path() > will raise an exception when called with an external route. > > Since external routes must contain the qualified URL by definition, it would > be more convenient if Request.route_path() just returned the qualified URL > instead of an exception in these cases. In other words Request.route_path() > should prefer to return URL paths when possible, but not bail out when it's > not. > > Or will this cause some evil side effects I am missing? That could go either way. I normally use route_path() but if I were generating an external URL I'd probably call route_url() to make it clear. On the other hand, I don't see anything wrong with route_path() returning a fully-qualified external URL because an unqualified URL is meaningless in that case. I'm not sure if we should support looping through routes though; that sounds fragile. You'd have to know something about the routes to know if each one was suitable for the menu, and if the routes require parameters you wouldn't be able to generate them without the parameters. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/groups/opt_out.
Re: [pylons-devel] Announcing Montague: replace INI with YAML, JSON, etc
On Tue, Jun 23, 2015 at 12:55 PM, Jon Rosebaugh wrote: > Around last December, I got annoyed with the way PasteDeploy combines the > INI file parsing with the WSGI object loading. INI files are awfully clumsy > and there are many alternatives that offer features such as lists and nested > dicts, but as long as WSGI object loading was done through PasteDeploy, > Pyramid could not easily take advantage of these config formats. Hey, I was just thinking that last week, that maybe it would be worth switching to YAML or JSON config files. I thought I would have to write the glue code myself. I have a validator that I call from my main function that validates the settings and converts their types. I want any invalid settings to raise an exception at startup, not when they're used in some obscure request. I've also got a fair amount of list parsing and nested data structures and extra INI sections. It takes a significant amount of code and deciding how to express these in a setting or a section and write unit tests for them. I've found a section works for something dict-like, and dotted key names can be used for nested dicts or objects, but it's more cumbersome than expressing them directly in YAML or JSON. I also have to create a ConfigParser myself to read the section, and set the 'here' or '__file__' key if I need them. Thanks for publishing Montague; I'll try it out. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com. Visit this group at http://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.
