Re: [pylons-devel] Knob for ACLAuthorizationPolicy?
Id like to hear other people speak up who have needed the same knob. If this is something a few people have needed, I'd ask them if their life would be much better with a knob on aclauthorizationpolicy instead of a custom policy given that they would also need to document it and justify it in the.pyramid docs. On June 11, 2015 11:28:25 AM EDT, Christian Theune christian.the...@googlemail.com wrote: Hi, I am implementing an application that is structured in way where I have a business model and multiple Pyramid applications on top of that, ending up with 4 processes, two of them providing APIs (XML-RPC) and two of them providing UIs. I'm happy using the ACLAuthenticationPolicy but I noticed that my __acl__ methods are getting convoluted as they have to know about the various processes. I wanted to split this up and wondered why the ACLAuthorizationPolicy can't be customized to use different attributes for the lookup. I'm making separate instances of the ACLAuthorizationPolicy in those applications and thus I started out to customize it, but had to copy the whole class. The ACL system itself seems fine for me, but putting the variations of ACLs that I'm dealing with into the same __acl__ is ... well ... convoluted. Chris pointed out that adding knobs isn't that fashionable - but I AFAICT I'm happy with the ACLAuthorizationPolicy except this one bit. I know this isn't necessarily a strong argument but maybe somone can tell me whether I'm doing something wrong or maybe help me to work towards a no knobs needed solution. :) Cheers, Theuni -- 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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.
Re: [pylons-devel] Using lighter workers for waitress
On 08/11/2014 06:56 PM, Ram Rachum wrote: Hi, Does Waitress support using workers lighter than Python threads? No. - C Thanks, Ram. -- 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 mailto:pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com mailto: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. -- 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.
Re: [pylons-devel] Probelms with wairtress in Python 2.7.7
On 06/05/2014 11:49 AM, Bert JW Regeer wrote: https://github.com/Pylons/webob/pull/150 Is an outstanding pull request to fix this in from_file() in WebOb, would this solve the problem? Probably not. More like here: https://github.com/Pylons/pyramid/blob/master/pyramid/response.py#L55 Bert On Jun 5, 2014, at 08:26 , Chris McDonough chr...@plope.com wrote: On 06/05/2014 05:39 AM, Christoph Zwerschke wrote: Am 04.06.2014 12:58, schrieb Tjelvar: Yesterday we encountered a problem with Waitress when using the newly released Python 2.7.7 (on windows). I can confirm this issue on Python 2.7.7. It is obviously caused by the patch for http://bugs.python.org/issue15207 after which some mime types are returned as unicode instead of str under Windows. FWIW, this bug is not in Waitress, but in whatever is setting the content-type, probably WebOb. WSGI specifies that header keys and values must be of the native str type, and Waitress is just enforcing that. It'd be useful if someone could walk through the code that is setting this header and propose a patch that fixes this under 2.7.7. - C -- 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. -- 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.
Re: [pylons-devel] Re: Broken PDF link for 1.5 docs
On 05/17/2014 10:28 PM, JohnWShipman wrote: Still 404. Anybody? Bueller? Please use http://media.readthedocs.org/pdf/pyramid/1.5-branch/pyramid.pdf . ReadTheDocs doesn't much want to do what we tell it to do, so the latest PDF has been moving in and out of existence, AFAICT. - C On Tuesday, May 6, 2014 9:07:09 PM UTC-6, JohnWShipman wrote: On this page: http://docs.pylonsproject.org/en/latest/docs/pyramid.html http://docs.pylonsproject.org/en/latest/docs/pyramid.html there is a link with this text: Pyramid latest documentation http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/ (latest PDF http://media.readthedocs.org/pdf/pyramid/latest/pyramid.pdf) The URL it goes to is 404: http://media.readthedocs.org/pdf/pyramid/latest/pyramid.pdf http://media.readthedocs.org/pdf/pyramid/latest/pyramid.pdf Best regards, John W. Shipman, Web Developer, j...@nmt.edu mailto:j...@nmt.edu National Radio Astronomy Observatories, Socorro, NM, USA -- 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 mailto:pylons-devel+unsubscr...@googlegroups.com. To post to this group, send email to pylons-devel@googlegroups.com mailto: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. -- 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.
Re: choice of documentation license
On Fri, 2013-03-22 at 22:07 +0200, Tshepang Lekhonkhobe wrote: Why choose a non-commercial license[1]? This has the disadvantage of disallowing, for example, Debian to distribute it[2], which would be nice. [1]: http://creativecommons.org/licenses/by-nc-sa/3.0/ [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640780. At this point I'd like to change the docs license to a free license, TBH. I had a delusion at some point that we'd need to protect it from publishing shops that just scrape existing free docs and sell books based on those docs without contributing anything back to the community, which would compete with book sales from folks who do, but I think the point is probably moot. It would be easiest to give the docs the same license as the code, I guess, although I'd be interested in hearing other opinions. -- 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: GSoC 2013
On Sat, 2013-02-16 at 22:12 -0800, Anirudha Bose wrote: Sir/Ma'am, I am interested in participating in the GSoC 2013 for the project some kind of interactive shell for pyramid kinda like http://try.redis-db.com/;. I would like to know how to start working on this. Thanks for the offer. We're not even sure if we're participating this year in GSoC so I'd suggest waiting until it starts to apply. - C -- 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: Why is there a separate pyramid_chameleon repository?
On Sun, 2013-01-20 at 00:32 -0800, Tshepang Lekhonkhobe wrote: When I saw https://github.com/Pylons/pyramid_chameleon, I thought it's a dependency of Pyramid, only to find that it's been integrated into Pyramid itself. Why is it there? It was created at a sprint with the idea that we were going to eventually move Chameleon support out of the core but we never pulled the trigger. Unclear whether we ever will. - C -- 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: Return media files (such as jpg, png) in Response body other than String
On Sun, 2012-12-30 at 18:13 -0800, Shu Lin wrote: Hi, If I have other objects other than String, which is holding a jpg or png file, I like to return it as Response body, how can I do? I tried a piece of code like this: mimetype = image/png body = fs.open(access_path, 'rb') return Response(body, content_type=mimetype) Here body is an buffer object from a kind of filesystem which represents the content in the file. Since, it doesn't support len() like String. I can't passed the Response check for len(). I tried app_iter also like this: return Response(app_iter=[body], content_type=mimetype) But, if I did like this, the wsgiref will complain about the body is not String type. === 2012-12-29 23:33:59,521 INFO [fs.tahoelafs][MainThread] (4363489744) Opening file /family/Ada/IMG_0355.JPG in mode rb Traceback (most recent call last): File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/wsgiref/handlers.py, line 86, in run self.finish_response() File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/wsgiref/handlers.py, line 127, in finish_response self.write(data) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/wsgiref/handlers.py, line 202, in write assert type(data) is StringType,write() argument must be string AssertionError: write() argument must be string == Is there anyway to work around this? Thanks a lot in advance! -Shu http://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/static_assets/files.html#serving-file-content-dynamically Instead of just using an open file as the app_iter, you can use a pyramid.response.FileIter object. This will chunk the file out in fixed-sized blocks: http://docs.pylonsproject.org/projects/pyramid/en/1.4-branch/api/response.html#pyramid.response.FileIter Or you can just shortcut the whole business and return a FileResponse instead of a response: http://docs.pylonsproject.org/projects/pyramid/en/1.4-branch/api/response.html#pyramid.response.FileResponse - C -- 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: Fail to correctly route with view_config decorator and GAE
On 11/07/2012 03:36 PM, tankerdude wrote:
This will work...
def working_view(request):
return{'result': 'ok'}
def make_app():
config.add_route('a', '/a', request_method='GET')
config.add_view(working_view, route_name='a', renderer='json')
That will go to /a with the method but now I try to use @view_config
that I'ved used when not running in GAE
def make_app():
config.add_route('test', '/test', request_method='GET')
config.scan()
@view_config(route_name='test', renderer='json')
def testMe(request):
return{'result': 'hello'}
That, for some reason, will not pick up the /test and 404. The view
callable isn't correctly registered. Maybe I'm doing something slightly
wrong?
I see nothing wrong with it, but you're not really pasting your actual
app, just some pseudocode.
- C
--
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: Fail to correctly route with view_config decorator and GAE
On 11/07/2012 04:27 PM, tankerdude wrote:
It's a pretty trivial application to start.
Here's the __init__.py file that goes with it. It's from the
appengine_pyramid scaffold and that I just added a few lines to. And
yes, I can't see it either. I've done all the way down into router.py's
handle_request method.
Fails to find a view_callable here:
# find a view callable
context_iface = providedBy(context)
view_callable = adapters.lookup(
(IViewClassifier, request.request_iface, context_iface),
IView, name=view_name, default=None)
Code Snippet---
from pyramid.config import Configurator
from resources import Root
import views
import pyramid_jinja2
importos
import logging
from pyramid.view import view_config
__here__ = os.path.dirname(os.path.abspath(__file__))
def working_view(request):
return{'result': 'ok'}
def make_app():
This function returns a Pyramid WSGI application.
config = Configurator(root_factory=Root)
config.add_renderer('.jinja2', pyramid_jinja2.Jinja2Renderer)
config.add_view(views.my_view,
context=Root,
renderer='mytemplate.jinja2')
config.add_route('a', '/a', request_method='GET')
config.add_route('test', '/test', request_method='GET')
config.add_view(working_view, route_name='a', renderer='json')
config.add_static_view(name='static',
path=os.path.join(__here__, 'static'))
config.scan()
return config.make_wsgi_app()
application = make_app()
@view_config(route_name='test', renderer='json')
def testMe(request):
return{'result': 'hello'}
Move testMe function above the application = make_app() line. This is
just garden-variety Python behavior.
- c
On Wednesday, November 7, 2012 12:48:21 PM UTC-8, Chris McDonough wrote:
On 11/07/2012 03:36 PM, tankerdude wrote:
This will work...
def working_view(request):
return{'result': 'ok'}
def make_app():
config.add_route('a', '/a', request_method='GET')
config.add_view(working_view, route_name='a', renderer='json')
That will go to /a with the method but now I try to use @view_config
that I'ved used when not running in GAE
def make_app():
config.add_route('test', '/test', request_method='GET')
config.scan()
@view_config(route_name='test', renderer='json')
def testMe(request):
return{'result': 'hello'}
That, for some reason, will not pick up the /test and 404. The view
callable isn't correctly registered. Maybe I'm doing something
slightly
wrong?
I see nothing wrong with it, but you're not really pasting your actual
app, just some pseudocode.
- C
--
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/-/x-h48vhymSgJ.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Make daemonize() Functionality Available to All Commands
On 10/31/2012 06:50 PM, Dave Mankoff wrote: Let me first say that pyramid has made writing cli scripts a breeze with pyramid.paster.bootstrap(). I love it! I am looking to turn some of my scripts into daemon processes. I went to look at how pserve does this, and I noticed that it is not a trivial piece of code. It seems to me that it would be incredibly useful to add a daemonize function that mimics (and slightly builds upon) the behavior seen in pserve so as to make it easy to developers. I am imagining an interface that looks something like: daemonize(start|stop|restart|reload|status, pid_file_location) or, more cleanly(?) daemon_start(pid_file_location) daemon_stop(pid_file_location) daemon_restart(pid_file_location) daemon_reload(pid_file_location) daemon_status(pid_file_location) Potential additional enhancements would be to specify the signals used for stop, restart, and reload. I think that these can exist as standalone functions, or, alternatively, it would be easy enough to make a callable DaemonCommand base class. Thoughts? Use supervisor instead: http://supervisord.org -- 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/-/HmawT-ZMVK4J. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Suggestion for Request namespace provisioning
On 10/30/2012 04:49 PM, Michael Merickel wrote: On Tue, Oct 30, 2012 at 3:34 PM, Jonathan Vanasco jonat...@findmeon.com wrote: That pattern / functionality is great. I'm just talking about proactively saying this name space is reserved for plugins, this namespace for projects - you can rest assured that as Pyramid grows and new functionality is added, you will not be affected as long as you stay within that container. Right now, request.foo is a bit of a lottery -- from my perspective, chances are you won't add anything to Pyramid over there, but its not an explicit/futureproof property. I think it's cool that Pyramid provides a way to do it, but I don't think layering that opinion on top belongs in the core. Also, FWIW, even if people add some namespacey thing, those namespacey things themselves are subject to conflict. So telling folks to bundle up everything into a namespace isn't a complete solution either. The only true solutions are untenable without ridicule (UUIDs, Java-style com.pyramid.myplugin style namespaces). I'd rather just let the chips fall where they may here and instruct folks to create plugins that don't supply unduly generic request properties. If they supply one, so be it; the system will let the user know there's a conflict, and they can work it out with the authors. Note that this is how Emacs plugins have worked for many years, and Emacs has a *lot* more plugins than does Pyramid. ;-) And they don't even have conflict detection. - C -- 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 10/22/2012 07:58 PM, Iain Duncan wrote: Right, well I'll start collecting them then. Can you send it to idun...@xornot.com mailto:idun...@xornot.com? Chris, what's the easiest way for me to edit a page on the Pylons site to have a preamble and include my email address for people to send their links to? You may want to join irc.freenode.net#pyramid to get further info about this stuff in realtime. - C thanks Iain On Sat, Oct 20, 2012 at 5:27 AM, Thomas G. Willis tom.wil...@gmail.com mailto:tom.wil...@gmail.com wrote: I work for Batterii(http://batterii.com) we have a managed innovation solution written in pyramid and ember.js on top of google appengine. We actually have happy customers using it. I had sent someone our logo about a year ago for inclusion on the pylons site but it's still not up there. Ember.js on the other hand included the logo fairly quickly. On Friday, October 19, 2012 9:30:24 PM UTC-4, Blaise Laflamme wrote: I think this should be added to the new pylons project / pyramid sites refactoring. Noted. If you have anything collected please share. On Friday, 19 October 2012 17:33:15 UTC-4, Iain Duncan wrote: Hi everyone, I started a thread about this ages ago, and expressed interest in making something happen, and then life happened and I had not time. Now I'm in a position where this has become a higher priority again. It seems to me that one thing really lacking in the Pyramid docs is some advocacy and examples of high profile sites using Pyramid. I realize this is a bit non-sensical in that we're not talking about a CMS, but I'm sure I'm far from the only one who has had a client ask about that. Plone and SQLAlchemy have done a great job of it. So questions: - sites using Pyramid? is there a list anywhere? - If I want to help make one, what would be the recommended way of going about this? -- 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/-/sUw3kubem4EJ. To post to this group, send email to pylons-devel@googlegroups.com mailto:pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com mailto:pylons-devel%2bunsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: AuthTktAuthenticationPolicy using MD5
On Sun, 2012-09-23 at 05:54 -0700, Florian Rüchel wrote: How about a script that's part of the framework itself? We have pserve, pcreate... how about pkeygen [-w filename] or pyramid-keygen [-w filename] I like this idea very much. I would like to either get this usage approved or I would just build a simple function inside pyramid. However, such a function belongs more into an installation than into application code. Can you tell me how to build such a script that runs on both Windows and Linux? I would like to see it implemented in this way if Chris approves. Who will use it and when would they use it? On a seperate note: I have started on improving the documentation. As a first step, I have edited the `narr/authentication.rst` to include a note and have documented the API for `pyramid.authentication.AuthTktAuthenticationPolicy` (better documentation for secret, add documentation for hashalg). My question is now how would you handle this in regards to the documentation. I thought about adding this (or a similar) note everywhere this policy is used. This should raise the awareness everywhere the docs are read (e.g. tutorials). Furthermore, since we would clearly recommend to use something like SHA256 if MD5 is not explicitly needed, should we change the code examples to include a better hashalg (instead of just documenting it)? I would vote for a yes, since I don't see any disadvantage: If you build a new application, you should always use another algorithm and as shown above mod_auth_tkt can also easily handle other algorithms if configured correctly. I didn't know we already had a mergeable patch for the hashalg stuff. The last patch I saw seemed maybe a little overwrought. Until we figure that out, I'd hold off on changing docs. I would like to hear some opinions on this matter before I start to make big changes and only end up reverting them because you don't like it. My first version can be found here: https://github.com/Javex/pyramid/commit/549db4b02cbff2c511eb026d3a5856b0b8fb3236 I have also created a small `gensecret` function based on the ideas of Daniel and Domen (but with added Python3 compatibility): https://github.com/Javex/pyramid/commit/d4f2943fa50e34f682f8097dccee2ce3ef1e998e This function is not what I expect in the final version but it shows where I would like to go with this: Provide a function that makes it easier for a user to obtain a strong secret. Either we use it this way or the above mentioned seperate script, that really doesn't matter. Please tell me your thoughts on both topics. - C -- 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: AuthTktAuthenticationPolicy using MD5
On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote: I was getting interested in how Pyramid's authentication works and looked through the commonly used AuthTktAuthenticationPolicy code. I found out it uses MD5 and the only thing keeping the cookie from being forged is the secret. I see two different issues here: First, MD5 is already known to have weaknesses and it would be a good idea to have different algorithms available so they can be set. This shouldn't be very hard to implement (I can write a patch if you desire) and it can improve the security of any site. Second, since everything depends on the single secret, I think it should be documented better (communicated on at least the docstring and the documentation) that the secret has to be strong (long, random, maybe state a minimum length). It would be fine by me if we made it possible to change the hashing algorithm. But it probably needs to continue to support md5, because it's purpose is to be compatible with Apache mod_auth_tkt cookies. I would be happy to accept a patch that allowed folks to plug in a different hashing algorithm, and explain to them that if they do, it will no longer be compatible with those cookies. There are also existing options that can help make it stronger regardless of the hash, such as including the IP in the token, IIRC. - C -- 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: AuthTktAuthenticationPolicy using MD5
On Sun, 2012-09-09 at 17:40 +0200, Domen Kožar wrote: According to https://github.com/gavincarr/mod_auth_tkt/blob/master/conf/02_auth_tkt.conf and http://linux.die.net/man/3/mod_auth_tkt, mod_auth_tkt supports SHA256 and SHA512 since version 2.1 Relevant: https://bitbucket.org/ianb/paste/changeset/7f90a96378ed\ Cool. We should do something similar I guess. On Sun, Sep 9, 2012 at 4:56 PM, Chris McDonough chr...@plope.com wrote: On Sun, 2012-09-09 at 06:55 -0700, Florian Rüchel wrote: I was getting interested in how Pyramid's authentication works and looked through the commonly used AuthTktAuthenticationPolicy code. I found out it uses MD5 and the only thing keeping the cookie from being forged is the secret. I see two different issues here: First, MD5 is already known to have weaknesses and it would be a good idea to have different algorithms available so they can be set. This shouldn't be very hard to implement (I can write a patch if you desire) and it can improve the security of any site. Second, since everything depends on the single secret, I think it should be documented better (communicated on at least the docstring and the documentation) that the secret has to be strong (long, random, maybe state a minimum length). It would be fine by me if we made it possible to change the hashing algorithm. But it probably needs to continue to support md5, because it's purpose is to be compatible with Apache mod_auth_tkt cookies. I would be happy to accept a patch that allowed folks to plug in a different hashing algorithm, and explain to them that if they do, it will no longer be compatible with those cookies. There are also existing options that can help make it stronger regardless of the hash, such as including the IP in the token, IIRC. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- 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: AuthTktAuthenticationPolicy using MD5
On Sun, 2012-09-09 at 12:25 -0700, Florian Rüchel wrote: On Sunday, September 9, 2012 8:23:45 PM UTC+2, Domen Kožar wrote: Florian: do you plan to provide a patch? I am willing to provide a patch but I am new to pyramid and would definitely need someone to double check which places need changing. For example we need a dynamic split depending on the algorithm used as otherwise we cannot determine where the hash ends and the timestamp begins. Furthermore, I don't know which other parts might use the digest parts (so they would need change, too). And last, I haven't looked into tests yet. If they cover this, they should at least be extended to also test a different algorithm. If someone is willing to help me, then yes, I would like to develop this. It might take some time though, so if someone is eager to get this quickly (like by the end of this week, i.e. on Sunday, 16th), then I am probably not the right guy right know. I could probably do it by the end of next week) I don't think there's any hurry. - C -- 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.3 and zope.component question
On 08/28/2012 12:23 AM, Iain Duncan wrote: Hey all (or maybe just Chris? ;), I see in the change log that pyramid 1.3 no longer depends on zope.component. I haven't switched to 1.3, but in my pyramid apps I'm using the zca registry pretty extensively. I'm wondering a few things: - is the pyramid registry still the zope registry, or has there been a re-implementation? Still same. The zope component registry code was moved to zope.interface, so nothing really changed, just where it was imported from. - if it's a re-implementation or some other kind of replacement, is it API compatible to some degree? - is there anything I need to beware of if I'm using the registry, as long as I'm not getting with the the zope global registry libraries? ie, can I just happily continue my merry way as long as my registry access all comes from request.registry and my zca use is all done through method calls on said registry? Nothing has really changed. Just where we import it from. - are there docs about that up anywhere? Nope. thanks! Iain -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Small change proposal to pyramid.config.routes
On 06/27/2012 05:26 AM, abrinner wrote:
Hello,
I propose the following changes to pyramid/config/routes.py:
372c372,375
pattern = self.route_prefix.rstrip('/') + '/' +
pattern.lstrip('/')
---
if pattern:
pattern = self.route_prefix.rstrip('/') + '/' +
pattern.lstrip('/')
else:
pattern = self.route_prefix
Reasoning:
Take the following example:
from pyramid.config import Configurator
# maybe defined in some included application
def routes(config):
config.add_route('example', '')
# maybe the configuration of an including application
if __name__ == '__main__':
config = Configurator()
config.include(routes, route_prefix=/prefix)
This will always generate the following route:
myserver.com/prefix/
Notice the trailing / in the route, although I haven't specified it in
my configuration.
With the change I posted above it would be possible to define, whether
the final route should have a trailing / or not.
It would still have a bias towards having a trailing / as both the
including and the included application can specify one:
# included application:
def routes(config):
config.add_route('example', '/')
# including application:
if __name__ == '__main__':
config = Configurator()
config.include(routes, route_prefix=/prefix/)
This would both result in the following route:
myserver.com/prefix/
but the first example would have this route:
myserver.com/prefix
An existing trailing slash in either of the configurations wouldn't be
removed and if there is none defined, it wouldn't be added. I think,
that this would be the expected behavior.
You'll want to look-at/participate-in
https://github.com/Pylons/pyramid/issues/406
- C
--
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: proposal to decouple colander from translationstring
On 06/27/2012 12:34 PM, Alexey Luchko wrote:
Hi!
I've found colander translates error messages of exceptions :) It is
cool and rather surprising, but is not always required.
I'd like to use colander, but translationstring adds one extra
dependency, that is useless for me. Please, could you remove colander
dependency on translationstring in future releases?
No, sorry. I'd just rather not think about the implications of doing
this for the non-universal benefit of one less dependency.
- C
translationstring import could be rewritten like
try:
import translationstring
except ImportError:
_ = lamba x: x
else:
_ = translationstring.TranslationStringFactory('colander')
,
isn't it?
--
Regards,
Alex.
--
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: Help needed: EuroPython poster session
On 06/15/2012 10:33 AM, Arndt Droullier wrote: So, here is a poster (even two). It's more or less the website in poster format. Any comments or spotted mistakes? http://demo.poolyx.net/website/root/europython_poster/45/file/poster1.jpg http://demo.poolyx.net/website/root/europython_poster/46/file/poster2.jpg These look nice to me! Tres, can you give Arndt any more information about how to submit the poster to the EuroPython people? - C Arndt. 2012/6/14 Arndt Droullier ar...@dvelectric.de mailto:ar...@dvelectric.de I think we need two things: 1. Someone to create the poster. 2. Someone (or a few someones) to man the booth at the poster sessions and answer questions from folks who wander up. If you are willing to do one or the other or both, that'd be great. I think we're just praying someone will have enough gumption to take charge of this and produce something nice-looking as well as hang around the poster session answering questions. Even if it was just a poster that said PYRAMID on it without any other info ;-) I think the poster is little bit more difficult. The guys at Europython take care of the printing and need it these days, right? So 'll start with that. Do you have any details on size, format and so on? And maybe a pyramid flyer? If not I'll browse the website and see what I find. However I should have something by tomorrow and post it here for feedback. OK? Arndt. -- DV Electric / Arndt Droullier / www.dvelectric.de http://www.dvelectric.de -- DV Electric / Arndt Droullier / www.dvelectric.de http://www.dvelectric.de -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Help needed: EuroPython poster session
On 06/14/2012 07:07 AM, Arndt Droullier wrote: Hi, do you still need help? I will attend the EuroPython and could help out with the poster session (by the way there two poster sessions). Or if someone else took over I could offer some support. Though I'm not a designer I can layout and/or create a high resolution print file. I think the Europython is the best oppurtunity in Europe to present Pyramid (and due to the overwhelming django publicity necessary) so I'll do what I can. Just let me know. I think we need two things: 1. Someone to create the poster. 2. Someone (or a few someones) to man the booth at the poster sessions and answer questions from folks who wander up. If you are willing to do one or the other or both, that'd be great. I think we're just praying someone will have enough gumption to take charge of this and produce something nice-looking as well as hang around the poster session answering questions. Even if it was just a poster that said PYRAMID on it without any other info ;-) - C -- 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: wildcard domain for sibling domains
On Tue, 2012-03-27 at 12:18 -0700, Jason wrote: I would like the auth ticket authentication policy to also set the wild card domain for domains one level up from the current domain. For example: An application running on the domain x.y.foo.com would have .y.foo.com set as the domain for one of the cookies. I'm using this to allow app01.mydomain.com and app02.mydomain.com to use the same auth ticket cookie for authentication. Currently I am also using a similarly patched repoze.who so that this works across old Pylons applications and new Pyramid apps, but I couldn't figure out how to send a patch to the repoze.who project that would only apply to repoze.who version 1. I've already created a patch and made a pull request ( https://github.com/Pylons/pyramid/pull/450 ), but is this likely to be an acceptable addition to Pyramid, especially given that it adds a dependency on the publicsuffix package ( http://pypi.python.org/pypi/publicsuffix )? If its unlikely to be accepted, I would like to know so that I can create a new auth ticket authentication policy instead. Yeah I fear a reliance on that package is not in the cards for Pyramid right now. I also fear that the cookie helper is already a little out of control right now with cookie options and I'm loath to add more to it without trying to reconcile all of them. - C -- 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: [Feature Suggest] Consider dropping a python package and paster ini file approach as default.
On Fri, 2012-03-09 at 22:43 -0800, Cosmia Luna wrote: As a freshman in python, it made me very confused once what does a package mean and the weird file such like *.egg-info, entry_points.txt, setup.cfg ... I can't understand very well even today. And the paster like ini file, plain python configuration will surely be more powerful with no cost to learn. I sympathize with this, Python packaging is pretty grotty. However, at some point you're going to need to understand it to make the most of Python. I suggest not use pserve script but a plain python script like below to be default or at least a option to make it easier: #!/path/to/python import sys sys.insert(0, 'path/to/app') from app import wsgi_app, app_config from werkzeug.serving import run_simple run_simple(app_config.HOSTNAME, app_config.PORT, wsgi_app, use_reloader=app_config.DEBUG, use_debugger=app_config.DEBUG) Or something more powerful. Defaults are pretty hard. We get value out of pserve and friends (particularly the --reload flag). Of course what you want is already possible. See the code sample at http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/ - C -- 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: Nested adaptation using Pyramid's registry
On Thu, 2012-03-01 at 20:26 +0700, Jonathan Ballet wrote: Hello, I have some code which looks like this: @adapter(IFolder) @implementer(IImage) def thumbnail_of_folder(folder): return IImage(folder[0]) I want this to adapt and recurse into the subfolders until it founds an IImage (the example assumes there's always something into the folder). If I want to use the registry associated to the request being processed, I can do something like: request.registry.queryAdapterOrSelf(context, IImage) If `context` is not an IImage, it goes into the adapter defined above where I'm stuck, since I don't have access to the request's registry anymore. Is there a way to call nested (recursive, here) adapters using Pyramid's registry, or am I doing something wrong here? If you really want a global registry, you can do: myapp/registry.py -- from pyramid.registry import Registry registry = Registry() myapp/__init__.py -- def main(...): config = Configurator(registry=registry) config.setup_registry() config.hook_zca() ... you'll have to install zope.component for the hook_zca call to work After doing this, you can do from myapp.registry import registry to use the registry in your application. You will also be able to use the global ZCA api e.g. zope.component.getAdapter(); it will use your myapp.registry registry. The downside is that tests become harder to write (you need to clean out the registry after each test). See also http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/zca.html - C -- 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: Nested adaptation using Pyramid's registry
On Thu, 2012-03-01 at 22:36 +0700, Jonathan Ballet wrote: On Thu, Mar 01, 2012 at 10:29:29AM -0500, Chris McDonough wrote: On Thu, 2012-03-01 at 20:26 +0700, Jonathan Ballet wrote: Hello, I have some code which looks like this: @adapter(IFolder) @implementer(IImage) def thumbnail_of_folder(folder): return IImage(folder[0]) I want this to adapt and recurse into the subfolders until it founds an IImage (the example assumes there's always something into the folder). If I want to use the registry associated to the request being processed, I can do something like: request.registry.queryAdapterOrSelf(context, IImage) If `context` is not an IImage, it goes into the adapter defined above where I'm stuck, since I don't have access to the request's registry anymore. Is there a way to call nested (recursive, here) adapters using Pyramid's registry, or am I doing something wrong here? If you really want a global registry, you can do: Yes, I read the document you mentioned, but I actually want to know if there is a way and how to do *without* using the global registry or accessing the thread-local registry. No, there's no declarative way to spell ascend my content tree trying to find an adapter. There's the inverse in the containment= predicate to a view or the pyramid.traversal.find_iterface adapter, where it tries to look towards the root for some object which implements some interface. But it doesn't have anything to do with adaptation. FWIW, I like the idea described in the aforementioned document, although it somehow looks it's not meant to be used this way. Meant to be used is a pretty slippery measure. But personally if I were you I'd just write a function that took the context and the request and which walked up the tree looking for something that was adaptable to IImage. Trying to solve this with adaptation is maybe not useful, especially if you have to create a global to do it. - C -- 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: Nested adaptation using Pyramid's registry
On Thu, 2012-03-01 at 23:03 +0700, Jonathan Ballet wrote: On Thu, Mar 01, 2012 at 10:48:02AM -0500, Chris McDonough wrote: Yes, I read the document you mentioned, but I actually want to know if there is a way and how to do *without* using the global registry or accessing the thread-local registry. No, there's no declarative way to spell ascend my content tree trying to find an adapter. There's the inverse in the containment= predicate to a view or the pyramid.traversal.find_iterface adapter, where it tries to look towards the root for some object which implements some interface. But it doesn't have anything to do with adaptation. Maybe I should have post this to zope-dev instead, since I was just trying to use the ZCA as Pyramid proposes to use it. Probably. FWIW, I like the idea described in the aforementioned document, although it somehow looks it's not meant to be used this way. Meant to be used is a pretty slippery measure. But personally if I were you I'd just write a function that took the context and the request and which walked up the tree looking for something that was adaptable to IImage. Trying to solve this with adaptation is maybe not useful, especially if you have to create a global to do it. Actually, I ended with something like this: while not IImage.providedBy(context): if IFolder.providedBy(context): context = context[0] else: raise Exception() return context but it didn't really look nice to me, and basically renders the usage of the ZCA not really useful. Did you have another idea in mind? The logic you have up will always raise an exception, AFAICT. I'd personally write something that doesnt try to use adapters at all, but still finds an image by walking the tree. Once that works, use it for a while. If it later turns out to be useful to use adaptation after a bit to do image-type specializations, try introducing adaptation then. It's awful easy to get wrapped up in machinery here when the actual problem is much simpler to solve without that machinery. - C -- 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: Can't return JSON using 1.3b1
On Tue, 2012-02-28 at 09:25 -0800, Ben Sizer wrote:
Here's my code (JSON function copied from
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html,
and the rest from the Hello World):
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.view import view_config
@view_config(renderer='json')
def hello_world(request):
return {'content':'Hello!'}
if __name__ == '__main__':
config = Configurator()
config.add_route('create_account', '/create')
config.add_view(hello_world, route_name='create_account')
app = config.make_wsgi_app()
server = make_server('0.0.0.0', 8080, app)
server.serve_forever()
Here's what happens when I visit /create:
Traceback (most recent call last):
File C:\Python27\lib\wsgiref\handlers.py, line 85, in run
self.result = application(self.environ, self.start_response)
File C:\Python27\lib\site-packages\pyramid\router.py, line 187, in
__call__
response = self.handle_request(request)
File C:\Python27\lib\site-packages\pyramid\tweens.py, line 20, in
excview_tween
response = handler(request)
File C:\Python27\lib\site-packages\pyramid\router.py, line 164, in
handle_request
response = view_callable(context, request)
File C:\Python27\lib\site-packages\pyramid\config\views.py, line
371, in viewresult_to_response
raise ValueError(msg % (view_description(view), result))
ValueError: Could not convert return value of the view callable
function __main__.hello_world into a response object. The value
returned was {'content': 'Hello!'}. You may have forgotten to define a
renderer in the view configuration.
But the renderer's right there, copied from the docs...
Any idea what is wrong?
You can't mic view_config with add_view. Instead use view_config with a
scan:
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.view import view_config
@view_config(renderer='json', route_name='create_account')
def hello_world(request):
return {'content':'Hello!'}
if __name__ == '__main__':
config = Configurator()
config.add_route('create_account', '/create')
config.scan()
app = config.make_wsgi_app()
server = make_server('0.0.0.0', 8080, app)
server.serve_forever()
--
Ben Sizer
--
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: Can't return JSON using 1.3b1
On Tue, 2012-02-28 at 10:03 -0800, Ben Sizer wrote:
On Feb 28, 5:41 pm, Chris McDonough chr...@plope.com wrote:
You can't mic view_config with add_view. Instead use view_config with a
scan:
from wsgiref.simple_server import make_server
from pyramid.config import Configurator
from pyramid.view import view_config
@view_config(renderer='json', route_name='create_account')
def hello_world(request):
return {'content':'Hello!'}
if __name__ == '__main__':
config = Configurator()
config.add_route('create_account', '/create')
config.scan()
app = config.make_wsgi_app()
server = make_server('0.0.0.0', 8080, app)
server.serve_forever()
Thanks Chris, that works perfectly.
It just makes me wonder how you'd use the examples at
http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/renderers.html
because none of them have routes defined in the view_config decorator.
Is there a way to add a route to a view_config-decorated view when the
view doesn't have a route name?
Those view configurations use traversal, but it's not really relevant.
However a view resolves to a URL, you can use a renderer to process
return data. You just need to decide how you want to map URLs to views
(routes or traversal).
- C
--
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: Question: How can I response a JSON with render='json',and set the header
On Mon, 2012-02-20 at 06:55 -0800, Zane wrote:
Sample:
@view_config(permission = 'view',route_name='addUser',
renderer='json', custom_predicates=(allowed_methods('POST'),))
def add(request):
post_data = request.json_body
email = post_data['email']
headers = remember(request, email, max_age='86400')
/* How to response this header together*/
return {'succeed':True}
I think this is what you're asking:
request.response.headers['Foo'] = 'bar'
- C
Thanks
Zane
--
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/-/D5fWCOMEDOYJ.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to pylons-devel
+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Question: How can I response a JSON with render='json',and set the header
On Mon, 2012-02-20 at 07:34 -0800, Zane wrote:
Thanks @Chris
Yes.This is what I want, but now I receive a string
{'succeed':True}, and before I add header in response is a object
{'succeed':True} ( I using Ajax)
I guess this cause the view_config(renderer='json')
But How can I add header and return a Obj not a string.
Sorry~ I'm a newer.And Thank you.
Zane
I'm afraid I don't understand, sorry.
- C
--
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/-/IxdaCNua2XYJ.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to pylons-devel
+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Illegal character in URL - possible bug in pyramid 1.3a7
On Sat, 2012-02-11 at 10:32 -0800, Zoltan Benedek wrote: Illegal character in URL - Internal system error, UnicodeDecodeError The error can be reproduced. Might be the bug is in WebOb, but I cannot investigate deeper. May be there is a solution to avoid the system break. When I type the URL: http://localhost:6543/La%C3; - it seems that %C3 is an illegal character and I get: Internal Server Error The server encountered an unexpected internal server error (generated by waitress) and: /home/pyramid/prj1/MyProject$ /py27/bin/pserve development.ini Starting server in PID 2121. serving on http://0.0.0.0:6543 2012-02-11 19:27:28,661 ERROR [waitress][Dummy-4] Exception when serving /La� Traceback (most recent call last): File /py27/lib/python2.7/site-packages/waitress-0.8-py2.7.egg/ waitress/channel.py, line 325, in service task.service() File /py27/lib/python2.7/site-packages/waitress-0.8-py2.7.egg/ waitress/task.py, line 173, in service self.execute() File /py27/lib/python2.7/site-packages/waitress-0.8-py2.7.egg/ waitress/task.py, line 380, in execute appiter = self.channel.server.application(env, start_response) File /py27/lib/python2.7/site-packages/pyramid-1.3a7-py2.7.egg/ pyramid/router.py, line 187, in call response = self.handle_request(request) File /py27/lib/python2.7/site-packages/pyramid_debugtoolbar-0.9.8- py2.7.egg/pyramid_debugtoolbar/toolbar.py, line 103, in toolbar_tween if (request.path.startswith(root_path) or (not remote_addr in hosts)): File /py27/lib/python2.7/site-packages/WebOb-1.2b3-py2.7.egg/webob/ request.py, line 482, in path bpath = bytes(self.path_info, self.url_encoding) File /py27/lib/python2.7/site-packages/WebOb-1.2b3-py2.7.egg/webob/ descriptors.py, line 68, in fget return req.encget(key, encattr=encattr) File /py27/lib/python2.7/site-packages/WebOb-1.2b3-py2.7.egg/webob/ request.py, line 174, in encget return val.decode(encoding) File /py27/lib/python2.7/encodings/utf_8.py, line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode byte 0xc3 in position 3: unexpected end of data I tried to open an issue on github, but appears only for me. I commented on the issue in Github here: https://github.com/Pylons/pyramid/issues/434#issuecomment-3922280 -- 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: file upload
Can't replicate. This app tries to do so but using either /broken or
/works, it returns the same result (a repr of the FieldStorage) on
Pyramid 1.3a7:
from waitress import serve
from pyramid.config import Configurator
from pyramid.response import Response
from pyramid.view import view_config
@view_config(name='works')
def works(request):
form =
html
form action=/works method=POST enctype=multipart/form-data
input type=hidden name=csrf_token value=token/
input type=file name=profile_picture value=/br/
input type=submit value=save picture/
/form
/html
if request.method == 'GET':
return Response(form, content_type='text/html')
else:
picture = repr(request.POST['profile_picture'])
return Response(picture, content_type='text/plain')
@view_config(name='broken')
def broken(request):
form =
html
form action=/broken method=POST enctype=multipart/form-data
input type=file name=profile_picture value=/br/
input type=hidden name=csrf_token value=token/
input type=submit value=save picture/
/form
/html
if request.method == 'GET':
return Response(form, content_type='text/html')
else:
picture = repr(request.POST['profile_picture'])
return Response(picture, content_type='text/plain')
if __name__ == '__main__':
config = Configurator()
config.scan('__main__')
serve(config.make_wsgi_app())
On Wed, 2012-02-08 at 12:15 -0800, Craig Swank wrote:
Forgot to add environment info
pyramid: 1.3a6
python:2.7
os: ubuntu on a vagrant VM on a mac.
On Feb 8, 1:03 pm, Craig Swank craigsw...@gmail.com wrote:
Hello,
I just got wailed on by a file upload for about an hour. Does anyone
know why, when I post this form to my pyramid app:
form action=${save_picture_url} method=POST enctype=multipart/
form-data
input type=file name=profile_picture value=/br/
input type=hidden name=csrf_token value=${csrf_token}/
input type=submit value=save picture/
/form
the request.POST['profile_picture'] is an empty string. When I move
the position of the csrf_token field like this:
form action=${save_picture_url} method=POST enctype=multipart/
form-data
input type=hidden name=csrf_token value=${csrf_token}/
input type=file name=profile_picture value=/br/
input type=submit value=save picture/
/form
Then request.POST['profile_picture'] is a FieldStorage object as
expected.
Craig
--
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: file upload
On Wed, 2012-02-08 at 12:40 -0800, Craig Swank wrote: I made an app with pcreate -t starter and pasted your app's view stuff in and it worked there as well, started it with pserve and both uploads worked there as well. On Feb 8, 1:32 pm, Craig Swank craigsw...@gmail.com wrote: Your app also works in my VM. Both views show a FieldStorage object for POST['profile_picture'] Hmm, confused. One difference I can see between the two is you use waitress to serve it, I'm using pserve. I've not heard of waitress until now. Is there a possibility that pserve could be the reason I'm having problems? pserve is just a wrapper script; the actual server being run depends the [server] section in your configuration file. - C -- 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 can I manage arguments of view_config automatically?
On Thu, 2012-02-02 at 06:03 -0800, Cosmia Luna wrote: Since the 1.3-branch is in alpha status now, I have little confidence using it. I tried simply copying the code from 1.3a6 but it failed to work. It seems that I have to wait before 1.3-branch is stable. It's up to you, but the alpha designator on the 1.3 branch isn't a quality metric. We're likely to release a beta within a couple of weeks, and no major features remain to be implemented. - C Thanks Cosmia -- 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/-/iVDSRdDIBG8J. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: How can I manage arguments of view_config automatically?
On Wed, 2012-02-01 at 20:11 -0800, Cosmia Luna wrote:
I'm a beginner in both python and pyramid, sorry if my question is
silly.
I'm using class-based view-callable in pyramid.
In package.views.someview, I usually write:
# -*- coding: utf-8 -*-
from pyramid.view import view_config
from pyramid.response import Response
from cgi import escape
class SomeView(object):
def __init__(self, req):
self.req=req
# and something other to for things repeatly
def __call__(self):
# Usually not used
return Response(This is the page from __call__ of %s %
escape(repr(self)))
@view_config('add', context='package.views.someview.SomeView')
def add(self):
return Response(This is the page from add of %s %
escape(repr(self)))
@view_config('edit', context='package.views.someview.SomeView')
def edit(self):
return Response(This is the page from edit of %s %
escape(repr(self)))
@view_config('view', context='package.views.someview.SomeView')
def view(self):
return Response(This is the page from view of %s %
escape(repr(self)))
@view_config('delete', context='package.views.someview.SomeView')
def delete(self):
return Response(This is the page from delete of %s %
escape(repr(self)))
This is really boring and makes no sense to specify the name and the
context of the view every time, how can I do that automatically? I
have to specify name because I use traversal approach to map URLs, and
I have to specify the context because of view name conflict.
http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/narr/viewconfig.html#view-defaults-class-decorator
1.3a5 or better required.
- C
--
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 should explicitly require pastescript
On Tue, 2012-01-31 at 09:37 -0800, Jonathan Vanasco wrote: i'm not too familiar with paster create - do you think it would be possible to make an entry point that warned people to use pcreate? Not really, because they also might have PasteScript installed, and the two entry points would compete for the same script name. - C -- 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 should explicitly require pastescript
On Jan 30, 4:38 pm, Jonathan Vanasco jonat...@findmeon.com wrote: and playing around a bit, i see that the newest version of pyramid moved to pcreate from paster create... so perhaps the above is not needed. That's true... http://docs.pylonsproject.org/projects/pyramid/en/1.3-branch/whatsnew-1.3.html#python-3-compatibility -- 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: Feature proposal: includeme feature for classes (not only modules)
On Fri, 2011-12-23 at 21:43 -0800, Ahmed wrote:
Hello all and merry Christmas
The documentation now says that the includeme callable for
config.include is only to be used if you are including modules.
But consider this case:
class MyView(object):
@classmethod
def includeme(cls, config):
config.add_view(cls, route_name='myroute')
I want to do:
config.include('mypackage.views.MyView') .. which would automatically
register the view too.
Is it worth it to add this feature or not?
No. If you want to do this:
def incudeme(config):
cls = MyView
... do whatever you want to do with class ...
Rationale: method names are not importable in Python; the include
dotted name must be importable.
- C
Cheers,
Ahmed
--
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: pyramidtut
On Wed, 2011-11-16 at 05:39 -0800, czam wrote:
Hi list, I got a strange error starting with the wiki tutorial at
http://docs.pylonsproject.org/projects/pyramid/dev/tutorials/wiki2/installation.html
Seems to be a problem in the webob egg...
Just 2 days before I got the tutorial working on another Win7-64bit, I
am using Python 2.5.4 and everything is setup exactly as stated in the
tutorial.
d:\pyramid\pyramidtutScripts\paster.exe create -t
pyramid_routesalchemy tutoria
l
Traceback (most recent call last):
File d:\pyramid\pyramidtut\Scripts\paster-script.py, line 8, in
module
load_entry_point('pastescript==1.7.5', 'console_scripts', 'paster')
()
File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
py2.5.egg\past
e\script\command.py, line 104, in run
invoke(command, command_name, options, args[1:])
File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
py2.5.egg\past
e\script\command.py, line 143, in invoke
exit_code = runner.run(args)
File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
py2.5.egg\past
e\script\command.py, line 238, in run
result = self.command()
File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
py2.5.egg\past
e\script\create_distro.py, line 73, in command
self.extend_templates(templates, tmpl_name)
File d:\pyramid\pyramidtut\lib\site-packages\pastescript-1.7.5-
py2.5.egg\past
e\script\create_distro.py, line 262, in extend_templates
tmpl = entry.load()(entry.name)
File d:\pyramid\pyramidtut\lib\site-packages\setuptools-0.6c11-
py2.5.egg\pkg_
resources.py, line 1954, in load
File d:\pyramid\pyramidtut\lib\site-packages\pyramid-1.2.1-py2.5.egg
\pyramid\
__init__.py, line 1, in module
from pyramid.request import Request
File d:\pyramid\pyramidtut\lib\site-packages\pyramid-1.2.1-py2.5.egg
\pyramid\
request.py, line 6, in module
from webob import BaseRequest
File build\bdist.win32\egg\webob\__init__.py, line 1, in module
File build\bdist.win32\egg\webob\datetime_utils.py, line 18, in
module
File d:\pyramid\pyramidtut\lib\site-packages\webob-1.2b2-py2.5.egg
\webob\comp
at.py, line 89
return b''
^
SyntaxError: invalid syntax
d:\pyramid\pyramidtut
Any ideas?
WebOb 1.2 doesn't work under Python 2.5. I'd try to use Python 2.6 or
better for the tutorial.
- C
--
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 debug toolbar and non-ascii errors
On Tue, 2011-10-25 at 22:31 +0200, Christoph Zwerschke wrote:
My solution was to wrap exceptions and tracebacks in text_() calls, e.g.
in render_summary, render_full and generate_plaintext_traceback.
This avoids the crashes, but utf-8 messages will look odd because
text_() assumes latin-1 encoding by default. My suggestion is to replace
the latin-1 default with utf-8 and fall back to latin-1 only in case the
text is not decodable as utf-8. Like this:
def text_(s, encoding=None, errors='strict'):
if isinstance(s, binary_type):
if not encoding:
try:
return s.decode('utf-8')
except UnicodeDecodeError:
encoding = 'latin-1'
return s.decode(encoding, errors)
return s # pragma: no cover
This has been working nicely for me. Thougts?
If you think that makes sense, I can submit a patch on github.
It's hard to tell if what you described is OK without seeing that code
in context; would you mind submitting a pull request with your suggested
fix?
- C
--
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, 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. - C -- 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: possible regression bug re includeOverrides in pyramid 1.2
On Sep 28, 6:05 pm, Iain Duncan iainduncanli...@gmail.com wrote: Hey folks, I discovered that my zcml using includeOverrides chokes when I upgrade to Pyramid 1.2. I have tested that the issue goes away or reappears from doing nothing except switching my pyramid egg from 1.1 to 1.2 I've released a new version of pyramid_zcml (0.7) which I believe fixes this. Can you try it and see? -- 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: Best deployment method...
On Wed, 2011-10-05 at 05:42 -0700, Sam wrote: I'm trying to decide between deploying using Nginx + paster + supervisord as described here: https://docs.pylonsproject.org/projects/pyramid_cookbook/dev/deployment/nginx.html Or using apache + mod_wsgi as described here: https://docs.pylonsproject.org/projects/pyramid/1.0/tutorials/modwsgi/index.html Is one of the ways significantly faster? more reliable? able to handle more load? Or is it pretty much a wash? It'll be more or less a wash for you if your traffic profile is such that you're willing to rely on input from folks here rather than benchmarking on your own systems. - C -- 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: Best deployment method...
On Wed, 2011-10-05 at 14:52 -0700, Mengu wrote: that is called learning from the experience, chris. yes, his server specifications may vary, his db of choice may vary but in the end this is all the same. I'm just asserting that, if he isn't planning to benchmark anyway, the effective difference between the two options he named (nginx+paster vs. mod_wsgi) probably isn't great enough to matter to him and he'd be better off just setting up one or the other than he would be to worry too much about maximizing value here, if it cost him time and mental energy to do so. - C @sam, proxying nginx to paster is not a good idea. been there, done that. do not do that if you are not going to get max 1K-5K daily unique traffic. in the cookbook it should say, this is how to do it, but don't do it. i'd recommend that only for intranet use for small sized company. if you are going to get good amount of traffic like 5K - 10K reqs/min, go with apache and mod_wsgi. apache is great and can handle that traffic smoothly. you can use 2 web servers if needed. if you are going to get great traffic that you need to handle more than 20K concurrent users, i'd suggest going with nginx + uwsgi. however in such deployments do not use one server. get min. 2 servers, 1 db. server and have a load balancer. in my next wsgi deployment, i will give nginx + gevent a try. and finally, i will recommend you watching this[1] django deployment workshop by jacob kaplan moss of django. it applies to every wsgi app. [1] http://blip.tv/pycon-us-videos-2009-2010-2011/django-deployment-workshop-3651591 On Oct 5, 4:15 pm, Chris McDonough chr...@plope.com wrote: On Wed, 2011-10-05 at 05:42 -0700, Sam wrote: I'm trying to decide between deploying using Nginx + paster + supervisord as described here: https://docs.pylonsproject.org/projects/pyramid_cookbook/dev/deployme... Or using apache + mod_wsgi as described here: https://docs.pylonsproject.org/projects/pyramid/1.0/tutorials/modwsgi... Is one of the ways significantly faster? more reliable? able to handle more load? Or is it pretty much a wash? It'll be more or less a wash for you if your traffic profile is such that you're willing to rely on input from folks here rather than benchmarking on your own systems. - C -- 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: A little sqla help?
On Mon, 2011-09-26 at 20:12 -0400, Chris McDonough wrote: SQLAlchemy people with a heart: I could use some help porting zope.sqlalchemy to Python 3... this is the package that integrates a transaction manager with SQLAlchemy: http://pypi.python.org/pypi/zope.sqlalchemy/0.6.1 I have made most of its tests pass on Python 3, but two fail. To reproduce: http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/py3dev.txt?rev=122965view=markup All of the tests still pass on Python 2 on the same branch. Any help you could provide would be great. I'm already on thin ice with the amount of time I've spent porting other stuff. Mike Merickel solved this... This is because the setuptools (and nose) testrunners do not respect the ``test_suite`` stanza at the bottom of ``tests.py``; these shouldn't be getting run unless the DSN has postgres in it. They are getting run regardless (under sqlite). So not really a failure. - C -- 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.
A little sqla help?
SQLAlchemy people with a heart: I could use some help porting zope.sqlalchemy to Python 3... this is the package that integrates a transaction manager with SQLAlchemy: http://pypi.python.org/pypi/zope.sqlalchemy/0.6.1 I have made most of its tests pass on Python 3, but two fail. To reproduce: http://svn.zope.org/zope.sqlalchemy/branches/chrism-py3/py3dev.txt?rev=122965view=markup All of the tests still pass on Python 2 on the same branch. Any help you could provide would be great. I'm already on thin ice with the amount of time I've spent porting other stuff. - C -- 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 on Python 3.2
Hi folks,
I've been busy doing a stupid amount of work trying to make Pyramid work
on Python 3.2. The good news is that it's getting there. The core of
the current Pyramid master branch at
https://github.com/organizations/Pylons now runs and all of its unit
tests pass under Python 3.2.
Many limitations still exist. This is more of a notice for curious
hackers than it is an announcement that Pyramid is ready for arbitrarily
new users to run on Python 3. We're a ways off from any release.
For example, we don't yet have paster commands working ('paster
create', 'paster pshell', etc), and many scaffolding dependencies have
not been ported yet (such as the toolbar and zope.sqlalchemy). Also,
since Paste has not been ported to Python 3, if you want to run Pyramid
under Python 3.2, you'll have a more limited selection of WSGI servers
to choose from (mod_wsgi, wsgiref, perhaps the CherryPy server).
I've also done very little testing of the framework in integration
scenarios under Python 3, and I haven't adjusted any documentation to
deal with minor backwards incompatibilities. All the unit tests pass,
but the only integration test I've done is making sure hello world
works. I'd encourage the people who use Python 3 to try it out,
however, and help.
More details are available at
https://github.com/Pylons/pyramid/wiki/Python-3-Porting
- C
--
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: Insert jsonp on zcml
The JSONP renderer cannot be used via ZCMLm, sorry.
- C
On Mon, 2011-09-12 at 09:58 -0700, Jamil Atta Junior wrote:
Hi people,
I try to use the zcml with jsonp, and I receiving this error message:
result = renderer(value, system_values)
TypeError: __call__() takes exactly 2 arguments (3 given)
My zcml file:
renderer
name=jsonp
factory=pyramid.renderers.JSONP
/
route
name=site
pattern=/analytics/site/{instance}/{output}
view=analytics.views.site
renderer=jsonp
/
Thanks.
--
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: Insert jsonp on zcml
On Mon, 2011-09-12 at 14:19 -0400, Chris McDonough wrote:
The JSONP renderer cannot be used via ZCMLm, sorry.
I should say that the above is not entirely true, it just requires extra
effort:
# in module named myapp.renderers
from pyramid.renderers import JSONP
jsonp = JSONP('callback')
Then in ZCML:
renderer
name=jsonp
factory=myapp.renderers.jsonp
/
route
name=site
pattern=/analytics/site/{instance}/{output}
view=analytics.views.site
renderer=jsonp
/
- C
- C
On Mon, 2011-09-12 at 09:58 -0700, Jamil Atta Junior wrote:
Hi people,
I try to use the zcml with jsonp, and I receiving this error message:
result = renderer(value, system_values)
TypeError: __call__() takes exactly 2 arguments (3 given)
My zcml file:
renderer
name=jsonp
factory=pyramid.renderers.JSONP
/
route
name=site
pattern=/analytics/site/{instance}/{output}
view=analytics.views.site
renderer=jsonp
/
Thanks.
--
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: Instance level authorization in Pyramid
On Thu, 2011-09-01 at 06:30 -0700, Brian wrote:
I'm in the early stages of designing a my first Pyramid app and I was
hoping for some verification on my approach to instance level
authorization. Most of the stock documentation discusses global ACLs
which apply to an entire class, not individual instances of that
class. Consider a simple CMS which lets users create pages then only
edit the pages they create.
My thought goes something like this:
Configure each route with a factory, to generate a context object:
config.add_route('edit_page', 'edit_page/{page}',
factory='myproject.resources.PageFactory')
In this case the PageFactory would return the {page} instance of the
Page model. Then configure a view for the route with some permission
requirement.
config.add_view('myproject.views.edit_page', route_name='edit_page',
permission='edit')
??? I'm not clear what the difference is between passing a factory to
the add_route vs. passing a context to add_view. I believe the factory
can create a specific instance of a Page and pass it to the view. I
don't know what the context would be if I passed
context=myproject.resources.Page to add_view.
When you use url dispatch, you typically don't really care about
associating the view with a particular context, because the view is
already associated with the route (and by extension, its factory, and by
further extension the context produced by the factory). So saying:
config.add_route('edit_page', 'edit_page/{page}',
factory='myproject.resources.page_factory')
config.add_view('myproject.views.edit_page', route_name='edit_page',
permission='edit', context='project.resources.Page')
Doesn't really buy you anything over:
config.add_route('edit_page', 'edit_page/{page}',
factory='myproject.resources.factory')
config.add_view('myproject.views.edit_page', route_name='edit_page',
permission='edit')
.. because the route_name passed to add_view was enough to associate the
view with the route all alone.
Note that in the above examples I'm assuming that page_factory is
something like this:
def page_factory(request):
... figure out which Page to show from the request variables ...
page = Page(thosevariables)
page.__acl__ = someacl
return page
The magic here would need to happen in ... figure out which Page to
show from the request variables ... and, if you need per-instance
ACLs, what you do in page.__acl__ = someacl. It
really doesn't matter whether page_factory sets the __acl__ on
the Page instance, or whether the Page class' constructor accepts
enough arguments to know which __acl__ to construct and sets it itself.
But the result must be such that page.__acl__ is the ACL you want.
The result of the factory returns the context, and Pyramid's security
machinery compares the ACL of the context against the permission
assigned to the view (in this case, edit).
Then, within the constructor for a Page, created by the PageFactory,
an acl decorator would be set to that instance based on the owner.
Something like...
def __init__(self,...):
self.__acl__ = [
(Allow, Everyone, 'view'),
(Allow, 'user:owners_name_from_db', 'edit'),
]
Then, only a person who is authenticated as owners_name_from_db
would be allowed to view the edit_page view. The value of
owners_name_from_db would be loaded as part of the object when it was
instantiated by the PageFactory.
That works.
I'm really sketchy on how this all fits together. The documentation is
great, if you're making a site where a group of editors can edit
everything, but not so much when you want individuals to be able to
edit specific instances.
I appreciate any advice,
Seems like you have it mostly right, at least as right as you can get
without using something like traversal.
- C
--
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: Instance level authorization in Pyramid
On Mon, 2011-09-05 at 12:44 -0700, Brian wrote: Chris, Thanks for the reply. One more question... Is it acceptable for __acl__ to be a callable associated with an instance? def __acl__(self): return [ (Allow, 'user:%s' % self.owner, 'edit'), ] No, it must be an attribute, but you can use a property to turn it into a callable, e.g.: @property def __acl__(self): return [ (Allow, 'user:%s' % self.owner, 'edit'), ] - C -- 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: problem running helloworld
On Thu, 2011-09-01 at 13:11 -0700, Siddhartha Kasivajhula wrote: Thanks guys, I was able to get it running using those instructions. Though, while working through those I realized that I'd never activated my virtualenv during my initial install attempt -- are the instructions missing that step? link: https://docs.pylonsproject.org/projects/pyramid/1.2/narr/install.html#installing-pyramid-on-a-unix-system $ cd env $ bin/easy_install pyramid (should there be a $ source bin/activate in between those two?) Not required, no. I just tried doing that and it appears to be working now using the original instructions. Don't really understand that, but glad you got it going. - C Thanks! -Sid On Thu, Sep 1, 2011 at 12:57 AM, Steve Piercy steve.piercy@gmail.com wrote: This one may be helpful too: https://docs.pylonsproject.org/projects/pyramid_cookbook/dev/mac_install.html You are welcome to update the instructions for 10.4. --steve On 8/31/11 at 11:21 PM, ja...@misterm.org (James Murty) pronounced: I have come across similar problems compiling Python libraries on OS X, caused by not having the Mac OS X 10.4 Support libraries installed (they're optional in X-Code) and by the Mac's version of GCC being incompatible with some code. This blog post might give you some pointers: http://www.jamesmurty.com/2011/01/29/work-around-osx-lipo-figure-out-architecture-type / FWIW a clean install on OS X 10.7 (Lion) caused no problems. James On Aug 31, 11:41 am, Siddhartha Kasivajhula countvajh...@gmail.com wrote: Hi all, I'm new to Pyramid, and let me say first that it looks really cool and I've been meaning to try it for a while :). I was going through the documentation on installation and the hello world app, and I ran into this error message while trying to run helloworld: siddhartha:apps-110-$python hellopyr.py Traceback (most recent call last): File hellopyr.py, line 2, in module from pyramid.configuration import Configurator File /Library/Python/2.6/site-packages/pyramid-1.0-py2.6.egg/pyramid/configurat ion.py, line 1, in module from pyramid.config import Configurator as BaseConfigurator File /Library/Python/2.6/site-packages/pyramid-1.0-py2.6.egg/pyramid/config.py , line 12, in module from zope.configuration.config import GroupingContextDecorator File /Library/Python/2.6/site-packages/zope.configuration-3.7.4-py2.6.egg/zope/ configuration/config.py, line 23, in module import zope.schema File /Library/Python/2.6/site-packages/zope.schema-3.8.0-py2.6.egg/zope/schema/ __init__.py, line 16, in module from zope.schema._field import Field, Container, Iterable, Orderable File /Library/Python/2.6/site-packages/zope.schema-3.8.0-py2.6.egg/zope/schema/ _field.py, line 24, in module from zope.interface import classImplements, implements, Interface ImportError: No module named interface I installed virtualenv, my python version is: $python --version Python 2.6.1 Looking back at the logs from 'bin/easy_install pyramid', I see this: Running zope.interface-3.7.0/setup.py -q bdist_egg --dist-dir /var/folders/L6/L6RbbV+NGBaO6JGa905AKE +++TI/-Tmp-/easy_install-Zl0QT1/zope. interface-3.7.0/egg-dist-tmp-gOf2zE /usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed Installed assemblers are: /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64 /usr/bin/../libexec/gcc/darwin/i386/as for architecture i386 src/zope/interface/_zope_interface_coptimizations.c:1676: fatal error: error writing to -: Broken pipe compilation terminated. lipo: can't open input file: /var/folders/L6/L6RbbV+NGBaO6JGa905AKE +++TI/-Tmp-//ccJe3vOi.out (No such file or directory)
Re: problem running helloworld
On Wed, 2011-08-31 at 11:41 -0700, Siddhartha Kasivajhula wrote: Hi all, I'm new to Pyramid, and let me say first that it looks really cool and I've been meaning to try it for a while :). I was going through the documentation on installation and the hello world app, and I ran into this error message while trying to run helloworld: siddhartha:apps-110-$python hellopyr.py Traceback (most recent call last): File hellopyr.py, line 2, in module from pyramid.configuration import Configurator File /Library/Python/2.6/site-packages/pyramid-1.0-py2.6.egg/pyramid/configuration.py, line 1, in module from pyramid.config import Configurator as BaseConfigurator File /Library/Python/2.6/site-packages/pyramid-1.0-py2.6.egg/pyramid/config.py, line 12, in module from zope.configuration.config import GroupingContextDecorator File /Library/Python/2.6/site-packages/zope.configuration-3.7.4-py2.6.egg/zope/configuration/config.py, line 23, in module import zope.schema File /Library/Python/2.6/site-packages/zope.schema-3.8.0-py2.6.egg/zope/schema/__init__.py, line 16, in module from zope.schema._field import Field, Container, Iterable, Orderable File /Library/Python/2.6/site-packages/zope.schema-3.8.0-py2.6.egg/zope/schema/_field.py, line 24, in module from zope.interface import classImplements, implements, Interface ImportError: No module named interface I installed virtualenv, my python version is: $python --version Python 2.6.1 Looking back at the logs from 'bin/easy_install pyramid', I see this: Running zope.interface-3.7.0/setup.py -q bdist_egg --dist-dir /var/folders/L6/L6RbbV+NGBaO6JGa905AKE +++TI/-Tmp-/easy_install-Zl0QT1/zope.interface-3.7.0/egg-dist-tmp-gOf2zE /usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed Installed assemblers are: /usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64 /usr/bin/../libexec/gcc/darwin/i386/as for architecture i386 src/zope/interface/_zope_interface_coptimizations.c:1676: fatal error: error writing to -: Broken pipe compilation terminated. lipo: can't open input file: /var/folders/L6/L6RbbV+NGBaO6JGa905AKE +++TI/-Tmp-//ccJe3vOi.out (No such file or directory) WARNING: An optional code optimization (C extension) could not be compiled. Optimizations for this package will not be available! command 'gcc-4.2' failed with exit status 1 ... I also saw a few other messages like this but looks like it ultimately completes the install successfully despite these warnings. Do you know what the problem may be? It's likely that when you created your virtualenv you did not pass the --no-site-packages flag as per the install documentation. The compilation warnings are normal for some definition of normal. You can get rid of them by installing a C compiler on your platform as per the install documentation. - C -- 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: Full and relative URL.
On Sun, 2011-08-07 at 09:49 +0200, Eric Lemoine wrote:
There's no reason for the Host header to *not* be passed
to the backend server, especially if one of the main purposes in life of
the Apache server is to be a frontend for the application being proxied
to. Having it Off is a poor default, IMO.
How about this case:
The backend server has two virtual hosts, one serving app1 and the
other one serving app2. The proxy server makes app1 and app2
available at http://proxy.com/app1 and http://proxy.com/app2,
respectively. In that case you cannot have the proxy pass the Host
header, because the backend server wouldn't be able to determine if
the request should be directed to app1 or app2.
It can, at least for some definition of backend server virtual host.
If the backend server serves up app1 as /app1 and app2 as /app2
(regardless of the Host header), this proxy server configuration works:
VirtualHost *:80
ServerName www.example.com
RewriteEngine On
RewriteRule ^/(.*) http://appserver:6543/$1 [L,P]
ProxyPreserveHost on
/VirtualHost
The above configuration will pass the request off to
http://appserver:6543 with the SCRIPT_NAME+PATH_INFO that came in to
Apache ($1). But the Host header will be the original Host header, so
that when a URL is generated, it will use the host of the proxy instead
of appserver, which is exactly what you want.
On the other hand, if the above configuration disincludes the
ProxyPreserveHost On setting, any fully-qualified generated URL will be
wrong.
This doesn't just include URLs generated by Pyramid APIs like route_url,
static_url, and resource_url. It also includes URLs generated by WebOb
(request.application_url, request.url, etc) and any URLs generated by
middleware that depends on HTTP_HOST.
If you don't allow Apache to pass the Host header in such a system,
you'd need to arrange an alternate scheme to set the Host header in such
a configuration (either in middleware, or via Apache Set-Header). I
can't think of a case where it's advantageous to not use
ProxyPreserveHost to send the Host header, and instead to manage the
Host header yourself.
There are other reasons to munge the environment differently, like if
you're hosting a folder inside a traversal-based application at a root
URL. This is solved by setting request headers as per
http://docs.pylonsproject.org/projects/pyramid/1.1/narr/vhosting.html#virtual-root-support
. But even that preserves the Host header.
This use case doesn't seem so unrealistic to me.
If, as you've suggested, your solution will be to develop an application
with host-and-port-free URLs rather than to proxy the Host header, is it
really worth talking about? If you always generate paths rather than
generating fully qualified URLs, the value of the Host header (or its
presence or absence) is meaningless anyway.
In the meantime, even without a static_path API, I believe you can do
this to get the path of static URLs:
static_url('mypackage:static/foo.css', request, _app_url='')
- C
--
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: Full and relative URL.
On Mon, 2011-08-08 at 06:38 +0200, Eric Lemoine wrote: Right. I'd rather apply this: don't generate fully-qualified URLs in your web apps, or you may have trouble running them behind proxies. You're eventually going to run into situations with middleware that unconditionally generates fully qualified URLs where I believe you're going to need to modify that to always set ProxyPreserveHost On. But until then, you can try to ignore it by generating only paths, although I don't think that makes much sense given that it's so easy to turn on. Got you. Also, FWIW, when relying on ProxyPreserveHost the backend must be aware of the proxy, as it needs a ServerName or ServerAlias referencing the proxy. This might be a management hassle in some situations. I don't think so, unless you're defining backend differently than I am. The point of passing along the Host header is so that things behind the proxy don't need to know or care about the proxy. Assuming every hostname resolves to the IP address of the proxy: the application generates a sensible URL, the user clicks on it, the proxy answers, sends it along to the backend, and passes along the Host header; lather rinse repeat. Sure, apologies if I sound dismissive, I just hate having long discussions about defaults. I understand. Sensible defaults are key. -- Eric Lemoine Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel : 00 33 4 79 44 44 96 Mail : eric.lemo...@camptocamp.com http://www.camptocamp.com -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Full and relative URL.
On Sat, 2011-08-06 at 22:56 +0200, Eric Lemoine wrote: In what configuration would it be sane to have any proxy set the Host header to anything except what the client user agent says the Host header is? Here's what the Apache doc says about the ProxyPreserveHost directive: When enabled, this option will pass the Host: line from the incoming request to the proxied host, instead of the hostname specified in the proxypass line. This option should normally be turned Off. It is mostly useful in special configurations like proxied mass name-based virtual hosting, where the original Host header needs to be evaluated by the backend server. I think the wording of this warning in the Apache docs is a little misleading. There's no reason for the Host header to *not* be passed to the backend server, especially if one of the main purposes in life of the Apache server is to be a frontend for the application being proxied to. Having it Off is a poor default, IMO. - C -- 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: Full and relative URL.
On Thu, 2011-08-04 at 17:40 +0200, Eric Lemoine wrote: Shouldn't Pyramid be able to generate paths, as opposed to URLs, for static resources? Fowarding the Host header doesn't sound like a good solution, as you'll run into issues if you have (Apache) virtual hosts on the backend server. I don't really know what issues you would run into. I'm just talking about a setup where there's one front end web server talking to some number of Pyramid appservers. You can get arbitrarily more complex than that obviously, at your own peril, and maybe passing the Host header along in some other complex setup might be some sort of issue (but I can't imagine one). If you have multiple virtual hosts on the backend server then Apache will determine which virtual host is the target by looking at the Host header. If the Host header is set to the name of the proxy server then Apache won't be able to determine the target virtual host. In what configuration would it be sane to have any proxy set the Host header to anything except what the client user agent says the Host header is? If the next question is why would I ever generate URLs with the scheme and hostname in them, the answer is because sometimes you want to generate URLs to a particular hostname or using a particular scheme (see the app_url arg to route_url). That I understand. What I don't understand is why Pyramid provides route_path but not static_path. I didn't read that in your mail, sorry. Indeed there is no static_path. It'd be reasonably easy to add one (static_url is really just a wrapper around route_url). I'd probably add one, I guess if only not to have to have this conversation again ;-) - C -- 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: Sub-optimal top paragraph on pylonsproject.org
On Wed, 2011-07-20 at 01:52 -0700, Eric Ongerth wrote: Quote from the current http://pylonsproject.org : The Pylons Project was founded by the people behind the Pylons web framework to develop web application framework technology in Python. Rather than focusing on a single web framework, the Pylons Project will develop a collection of related technologies. The first package is the Pyramid web framework. It's factual, but a little clunky and indirect. May I propose a rewrite, maybe something like the following? The Pylons Project develops web application framework technology in Python. Our primary offering is known as Pyramid. Our previous framework was called Pylons. Pyramid is a unification of the Pylons framework with repoze.bfg, providing a superset of the capabilities of both. (or replace that final sentence in any way that seems fitting.) I'm thrilled to take any docs contribution; the best way is via pull request. - C There's just something about the current phrasing of the paragraph, especially given its prominent location on the page, that seems to say we're scrambling to explain this Pylons vs. Pylons vs. Pyramid distinction to you, dear visitor, even though you didn't ask. The point of rewriting -- whether it be my suggestion or someone else's better offering -- would be to provide the simple factual information as smoothly as possible, without a rather than clause, and without a couple of other things that just seem a bit indirect and unnecessary about the current phrasing. No offense intended to he who wrote the paragraph, it's not bad, and I think it made perfect sense in the first quarter of 2011, addressing visitors who most likely were aware of Pylons and arrived to see what the hubbub was about with news of Pyramid making the rounds. But we've quickly moved into a more long term steady state where the average visitor is none too concerned with the history or the aforementioned distinction; by and large I suspect the average visitor simply wants to get straight into the current offering and not worry about those details. I do suppose there is a significant minority of visitors who are newfound maintainers or migrators of Pylons-based projects, who actually are seeking that information; but I don't see a need to cater to them at the top of the page by default. Along those lines I almost went as far as to suggest that we quit even bothering to explain the Pylons vs. Pylons vs. Pyramid distinction on the front page at all. But I suppose it's still necessary, given that Pyramid has top billing and yet the URL and the 'Project itself are still (and will remain) Pylons branded. So I guess that does leave some need for at least a minor explanation. There is also value in noting the strength and extent of current well-known apps/sites/ projects built on the Pylons framework. Thus the grey bar which forms the second main element of the page, below the top orange-gradient Pyramid section, has reason to exist with at least some sort of prominence. Still, I almost think it could be a good idea to remodel it into (mostly/nearly) a full-on Pyramid home page, with a less prominent section at the bottom, or in a sidebar, saying looking for the Pylons framework? and providing links thereto. Maybe right now is not quite that point in time yet, but it's food for thought. I don't mean to take on the sound of a project member or contributor here, as all I've been able to provide is a few typo corrections in docs. Forgive my use of the we voice above. But I do hope these thoughts are worth the community's and the developers' consideration. Thanks. - ejo -- 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.
feature requests before beta.
I'm going to issue the first beta of Pyramid 1.1 soon. Beta really just means no new features. Speak now or forever hold your peace on feature requests for 1.1, as they will have to wait for 1.2 upon the first beta of 1.1. - C -- 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 Fri, 2011-06-03 at 02:51 -0500, Michael Merickel wrote:
+1 to the raise abort(..) or raise redirect(..) options.
I'm torn on the ability to raise arbitrary Response objects.
Also I'm curious about what the deal is with conditional responses...
I'm not very familiar with them but I get curious when I hear that
Pyramid can't handle something!
The issue is with how Pyramid uses (or really more how it doesn't use
parts of) webob.Response.
Currently view callables that don't use a renderer are obligated to
return an object with this interface:
class IResponse(Interface):
status = Attribute('WSGI status code of response')
headerlist = Attribute('List of response headers')
app_iter = Attribute('Iterable representing the response body')
That is, the only restriction that Pyramid puts upon view callable code
is that it must return an object with those three attributes. Pyramid
doesn't care if that object is a webob.Response object. Indeed Pyramid
internally uses IResponse objects that implement this interface that do
not inherit from webob.Response (NotFound and Forbidden currently).
In the meantime, the conditional response code within WebOb is only
executed when a webob.Response object is treated as a WSGI application
(its __call__ is called with an environ and a start_response).
Pyramid never uses a webob response object as a WSGI application,
however; it's __call__ is never called. This means that its
conditional response code is ignored. This is that code:
https://bitbucket.org/ianb/webob/src/411997824d3b/webob/response.py#cl-942 .
This isn't ideal.
- C
--
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, 2011-06-01 at 11:34 -0700, Mike Orr wrote:
On Tue, May 31, 2011 at 11:21 PM, Alexandre Conrad
alexandre.con...@gmail.com 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 chr...@plope.com:
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.
FTR, HTTPExceptions are and always have been raisable, they're just not
currently caught by default. Sorry if making that distinction sounds a
bit pedantic, but important because this is exactly what a developer
needs to do in order to catch and display them currently:
from pyramid.httpexceptions import HTTPException
config.add_view(lambda context, request: context,
context=HTTPException)
In other words, the argument boils down to whether to make people add
the above to their application configuration or whether Pyramid does it
on their behalf by default.
#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.
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.
IMO, all the other stuff (#2 thru 4) depends on this decision, and is
therefore detail-y ancillary stuff.
- C
#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 sluggos...@gmail.com
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Interaction of webob.Response, conditional responses and pyramid.router
On Tue, 2011-05-31 at 17:01 +0900, Ceri Storey wrote: Hi there. I'm just doing some work to add conditional responses to a small web gallery project I'm writing, and I noticed that in pyramid.router, the response's __call__ method itself is not invoked itself, meaning that even if we intend to use WebOb's support for conditional responses, that doesn't happen. Now, naturally, it'd be possible to do my own checking for this case in a response callback, but it does involve a certain amount of re-inventing the wheel, so I think it'd be nice if this magically just worked. So, I guess my question is--is this a deliberate choice, and I've missed the logic behind it? It's a deliberate choice to allow views (or renderings) return something that has three attributes (app_iter, headerlist, status). rather than something that is itself a WSGI app, because I felt it was easier to attach three attributes to an object than it was to write a correct WSGI applications. Truth be told, I might decide differently today if I had it to do all over again, but that ship has already sailed. - C -- 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, 2011-05-31 at 14:47 -0700, Mike Orr wrote:
On Tue, May 31, 2011 at 12:55 PM, Chris McDonough chr...@plope.com 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 only requires that objects used as responses have three
attributes: app_iter, headerlist, status. They do not have to inherit
from Response or any other bas class.
- 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.)
Nope.
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 sluggos...@gmail.com
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: Adding abort and redirect to Pyramid
On Tue, 2011-05-31 at 16:44 -0700, Philip Jenvey wrote: On May 31, 2011, at 12:55 PM, Chris McDonough wrote: On May 16, 2:27 am, Chris McDonough chr...@plope.com 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. Here's what I've decided to do with this issue: - An exception view for the pyramid.interfaces.IExceptionResponse interface will be registed by default. This exception view will simply return the response object it receives as an exception. It will be possible to disuse this default by passing a None value to a constructor parameter. It will be possible to override the default by passing a different view callable to the same constructor parameter. - All objects that inherit from pyramid.response.Response (inlcuding instances of the Response class itself) will provide the IExceptionResponse interface. - 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. We will create a mirror of the http exception hierarchy in pyramid.response. It will be backwards compatible with the current crop of classes that are in webob.exc (aka pyramid.httpexceptions). A backwards compatibility shim for pyramid.httpexceptions will be left in place. I don't see why that's enough of a reason to throw the webob.exc exceptions away, why's the WSGI app compatibility such a problem? webob.exc HTTP* classes use templates that expect to have the request environ available to resolve (non-optional) values. For example, HTTPMethodNotAllowed wants to get request.environ['REQUEST_METHOD'] (to be able to show Request method GET is not allowed as opposed to Request method is not allowed). Currently, people can return to Pyramid a Response object that has no reference to the originating request. If we want to use webob.exc responses (as opposed to creating our own), users will have to return responses with enough info to resolve these sorts of values. In order to do that, we'd have to do one of the following: - Make people pass the request into the response's constructor. - Change the contract of what Pyramid considers a valid response (aka pyramid.interfaces.IResponse to) obligate it to include a method that effectively turns it into a WSGI application. I'm not real keen on the former because it's too much of a pain in the ass. I'm not real keen on the latter because requiring it will be a backwards compatibility foul and not requiring it will require the router to always do a guessy duck-check on every response rendering. But of the two, the latter is less onerous. - 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. Is there a way to make the IExceptionResponse hook without making Response become a subclass of Exception? That's not really the problem. The problem is Python disallowing the raising of new-style classes that don't inherit from BaseException as exception objects. Unless a Response inherits from BaseException, nobody will be able to raise one. - C -- 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
On Tue, 2011-05-24 at 18:22 -0700, Jerry wrote:
Thanks Mike.
Chris, so how about this to offload some work from the template/helper
--
if v is not None:
v = quote_plus(str(v))
result += '%s%s=%s' % (prefix, k, v)
That's probably fine. It will need tests and docs. The right place to
submit it is via a github pull request.
- C
Jerry
On May 25, 12:02 am, Mike Orr sluggos...@gmail.com wrote:
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 chr...@plope.com 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 jerryji1...@gmail.com 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
athttp://groups.google.com/group/pylons-devel?hl=en.
--
Mike Orr sluggos...@gmail.com
--
You received this message because you are subscribed to the Google Groups
pylons-devel group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
Re: route_url _query None value behavior
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 jerryji1...@gmail.com 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.
Re: odd test problem
On Wed, 2011-05-18 at 17:35 +0200, Wichert Akkerman wrote:
I think I finally found the state leakage problem. What appears to be
happening is this:
First test A runs, and creates a Configuration() instance and does some
work on it, including calling config.scan(). This instance is garbage
collected once test A finishes. Next test B runs. This is a functional
test, and calls Configuration() during app setup. At this point any
actions that were created by the Configuration from test A are
re-discovered and called. And now comes the important thing: they are
called with the parameters setup in test A - including an old registry
instance!
The workaround is to always call config.commit() for any Configuration
instances created in a unittest to guarantee that there are no pending
actions.
Is there some way to prevent actions from leaking?
I'm not sure what it means for actions to leak. The actions are kept on
an attribute of the configurator, so if the configurator dies, the
actions die too. I don't understand how they'd survive the death of the
original configurator.
- C
Wichert.
On 5/12/11 15:23 , Wichert Akkerman wrote:
I am running into something weird. I have a unittest that looks like this:
def test_configure_default_authentication_policy(self):
from pyramid.interfaces import IAuthenticationPolicy
from pyramid.authentication import AuthTktAuthenticationPolicy
factory = self.ApplicationFactory()
config = factory.configure(factory.default_settings)
policy = config.registry.queryUtility(IAuthenticationPolicy)
self.assertTrue(isinstance(policy, AuthTktAuthenticationPolicy))
self.assertEqual(policy.cookie.http_only, True)
This is testing part of a factory class that is responsible for creating
the WSGI app. That particular configure method looks like this:
def configure(self, settings):
Build the pyramid application configuration.
:param dict settings: application settings
:rtype: :py:class:`pyramid.config.Configurator`
authentication_policy = AuthTktAuthenticationPolicy(
settings['authentication.secret'],
cookie_name=settings['authentication.cookie'],
include_ip=settings['authentication.include_ip'],
max_age=settings['authentication.lifetime'],
timeout=settings['authentication.lifetime'],
reissue_time=settings['authentication.reissue_time'],
http_only=True,
wild_domain=False)
config = Configurator(
settings=settings,
authentication_policy=authentication_policy)
config.set_renderer_globals_factory(GlobalsFactory)
config.add_route('siteroot', '/')
return config
this test passes. I also have a browser test that tries the not-found
exception view:
class FunctionalTestCase(unittest.TestCase):
def setUp(self):
from voipro.portal.run import main
from infrae.testbrowser.browser import Browser
self.app = main({})
self.browser = Browser(self.app)
class NotFoundFunctionalTests(FunctionalTestCase):
def test_invoked(self):
self.browser.open('http://localhost/not-found')
self.assertEqual(self.browser.status_code, 404)
self.assertTrue('The page you tried to access does not exist'
in self.browser.contents)
this test also passes fine when run in isolation. However when I run all
tests the browser test fails: when the exception view is rendered the
globals factory is not called. It looks like there is some leakage from
test_configure_default_authentication_policy, but I don't see why.
Wichert.
--
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.
Adding abort and redirect to Pyramid
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.
- C
--
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 Mon, 2011-05-16 at 11:42 -0500, Michael Merickel wrote: Is there any support for integrating abort(404) with raise NotFound such that my 404 is rendered properly? Same with abort(403) and Forbidden. No, except in the docs I explain the difference between NotFound and HTTPNotFound and Forbidden and HTTPForbidden. I'm really loath to try to marry them together in some unholy way. - C I'm a little torn but more in favor of the readability of using httpexceptions directly. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: [deform] limit number of entries in a SequenceSchema
On Tue, 2011-05-03 at 17:31 +0100, Chris Withers wrote: Hi All, What's the correct way to limit the number of entries in a SequenceSchema node? The requirements is something like each job must have at least one requirement line, but no more than 5 Not sure if you mean UI or validation, but: - UI wise: use the min_length and/or max_length parameters to SequenceWidget. See http://deformdemo.repoze.org/sequence_of_constrained_len/ Validation-wise, put a validator on the schema node, see the same example. I'm also keen to know if anyone has done a widget which uses a textarea to produce a sequence of strings, rather than the JS add one as a time approach? See http://deformdemo.repoze.org/textareacsv/ - C cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- 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: unit test to check if for a given path a correct context will be returned
On Fri, 2011-04-15 at 15:39 -0700, mdob wrote:
Just like in the title. I have a model and I can test in manually in a
browser. I enter url in a browser and receive a result form one of the
views. Thing is unittest should be doing that. Functional test isn't
exactly what is needed. Because I want to check only if traversal in
my application return a correct context.
I think there should be some way to create a request, send it to the
application and in return receive the context.
from pyramid.traversal import traverse
D = traverse(root, '/some/path')
context = D['context']
root has to come from somewhere though. The most heavy-handed way to
get one is to use the pyramid.scripting.get_root API:
from pyramid.paster import get_app
from pyramid.paster import get_root
app = get_app('/path/to/development.ini', 'myapp')
root = get_root(app)
What'd you be testing here is that the resource tree represented by the
root object you're returning has the right composition. This is a bit
of a strange unit test, because usually a unit test tests your code, and
not the framework code, and it's uncommon to test that a resource tree
is composed of exactly some object at some path (the resource tree often
changes over time).
- C
--
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: Resolving relative asset spec of renderer
On Wed, 2011-04-13 at 06:30 -0700, Dmitry Vakhrushev wrote:
Hi All.
I develop CMS using pyramid. CMS consist of core and some plugins.
Application which use CMS looks like:
from pyramid.config import Configurator
def main(global, **settings):
config = Configurator(settings=settings)
config.include('mycms.core')
config.include('mycms.plugin')
I use Mako as renderer. Global templates (such as layouts) are stored
in application package and local (plugin) templates are stored in
plugin packages. To use global templates (for inheritance) in local
ones I specified in application ini-files the line:
mako.directories = application:templates
Plugin includeme function looks like:
def includeme(config):
config.add_view('.views.someview', context='.resource.Resource',
renderer=':templates/someview.mak')
When I specified renderer name as full asset spec
'mycms.plugin:templates/someview.mak' it works fine. But in relative
form (like in example of code) I got ValueError: Empty module name.
Unlike the Chameleon template renderer, the Mako template renderer does
not respect relative asset specifications (e.g. foo/bar.mak) only
absolute ones (e.g. mypackage:foo/bar.mak).
The built-in Mako renderer is willing to resolve templates from a global
location (using the mako.directories setting). Due to this, it's not
possible for the built-in Mako renderer to distinguish names that should
be looked up from the global loader path from relative asset
specifications, so it requires absolute asset specifications.
The Chameleon renderer, which has no global directories location and
essentially treats every path that isn't absolute as a relative asset
specification.
So, after update __init__ method of pyramid.renderers.RendererHelper
both forms are operational:
class RendererHelper(object):
implements(IRendererInfo)
def __init__(self, name=None, package=None, registry=None):
if name and '.' in name:
rtype = os.path.splitext(name)[1]
else:
rtype = name
# Begin of my additional code ***
if (name.startswith('.') or name.startswith(':')) and package:
if isinstance(package, basestring):
name = package + name
else:
name = package.__name__ + name
# End of my additional code *
if registry is None:
registry = get_current_registry()
self.name = name
self.package = package
self.type = rtype
self.registry = registry
So, is it bug of pyramid.renderers.RendererHelper and what can be
broken after my fix? I'm not sure, that this is appropriate place to
fix it.
It's not a bug, although you might desire the feature. If you want it,
it's possible to create an alternate Mako renderer that always treats
relative paths as relative asset specifications and which does not use a
global lookup path location. See
http://docs.pylonsproject.org/projects/pyramid/1.0/narr/renderers.html#adding-and-changing-renderers
.
- C
--
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 Tue, 2011-04-05 at 23:16 +0200, Juliusz Gonera wrote: Chris McDonough wrote: I think asking a single student to port everything is too much. At this point, I think there's an opportunity to get two students working on the porting effort. I see. I didn't know that. I thought that it was most likely that Pyramid will get only one person. Anyway, I think that when porting the amount of work will depend on the port/replace ratio. To be honest, I'm not sure we can manage paste replacement as a GSOC project, especially from scratch. Paste is relatively large, and encompasses many things. Furthermore, we actually use very little of Paste in Pyramid. Pyramid will happily run without PasteDeploy or PasteScript, so porting either is not a hot issue for Python 3 compatibility in the short term. I see your point now. Pyramid won't run without some things from the Paste package proper (namely its static file application named StaticURLParser, and some auth_tkt components). These will need to be replaced in order to run on Python 3. But it's a *lot* easier just to cut and paste and fix these specific components than it is to port the entirety of Paste, so I'd suggest we just do that. I think we should hold off on passing judgment on replacing Paste until after GSOC, when we know that we can run some form of Pyramid (albeit without PasteDeploy or PasteScript support) successfully. I didn't think about porting everything from Paste. That's why I was rather considering possible replacements for it (Marrow, CherryPy). Anyway, this clears it up a bit for me. Now I understand that having an integrated server and some automatization/config tools is not essential at the moment. As I understand it, those will be eventually necessary for some first official release of Pyramid for Python 3 (which won't be very soon). As for now, other dependencies have to be ported and satisfied in order to be able to start working on next major release of Pyramid. That sounds right. I think all the above stuff is probably too hard to tackle under GSOC. I suspect we should just get the bare minimum ported and see where we are. There is a list of dependencies on the https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm page that indicates the packages that need porting. I'd suggest that creating a proposal to port some of those would be best-received. Should I choose specific ones or just mention that I would be porting part of it? Choosing a subset is a good idea for the application (because it's probably impossible to port all of them), as long as you're willing to trade around as necessary when there's more than one person that wants to work on the same packages. What about porting zope packages? Should we port them or wait for someone who has already begun to finish it? We should port them. - C -- 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 Mon, 2011-04-04 at 10:52 -0700, Alice Bevan–McGregor wrote: Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? There isn't any particular reason not to go with both, INI for backwards compatibility (using similar logic to YAML's parsing of lists, numbers, etc., and YAML for the future. YAML's native rich structures are just too handy, and if you know JSON, you can write YAML. I'll be rolling that into marrow.config. 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? marrow.script was designed to be explicitly argparse/optparse/getopt incompatible. Paste Script's wrapping of optparse made things more complicated, not easier. Unless, of course, someone can come up with an _excellent_ reason why marrow.script should be rewritten to utilize argparse. Marrow.script, OTOH, wraps nothing. It's a direct command line - argspec converter and help text generator. The ease of just throwing a function or class at marrow.script (new or existing!) is highly desirable. 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github (https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. Seems I need to fix that reference. Threading is supported (now that it's supported in marrow.server) using a Futures-based thread pool. The underlying server being async has never been a bad thing in any of the benchmarking I've done, including C10K and 12KR/sec concurrency and speed benchmarks, even with the thread pool enabled. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. Same! :D Just because the packages take a distinctly different approach to some things than Paste/WebOb/Django/pkgname here doesn't make them bad, unusable, or unstable. In fact, for PyPi releases, the packages require 100% unit test coverage, full documentation, and 2.6+/3.1+ polygot compatibility; that already makes them somewhat better than (some of) the alternatives. I think researchy describes some of the marrow stuff pretty well (that doesn't imply bad, unusable or unstable, it just implies opinionatedness that is outside the current mainstream). For example, in this message you've quoted use of a futures-based asynchronous server that says it implements WSGI 2.0, but WSGI 2.0 does not yet exist in any ratified form. I don't see WSGI 2.0 draft compatibility as a goal that we need to explore under GSOC. I think it's great you're pushing the envelope, but we really just need some very simple things that are well behind any of the curves you're at the front of. In the meantime, I don't much care if we get a PasteDeploy replacement that works under Python 3.X for GSOC. Pyramid apps don't strictly require PasteDeploy, they can be run without any declarative configuration. I also don't care much if we don't get a PasteScript replacement for GSOC either. Having a command line wrapper that does a bunch of stuff is handy but not required to make things run. We actually really just need some bits of Paste itself (the FileApp app, StaticURLParser, some of the auth_tkt bits) to work in order to reach a reasonable goal for 3.X compat. After that, we can think about how we'd like to wrap it up nicely for usage. I see the PasteScript/PasteDeploy stuff as a sort of last-resort project for GSOC, because it's pretty gratuituous until we get all the other dependencies ported. I'm already using marrow.tags (and the widgeting it provides), marrow.script, and marrow.blueprint in a number of projects, all with great success. -- 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 Mon, 2011-04-04 at 18:05 +0200, Juliusz Gonera wrote: Hi, I thought that it will be easier if I just post here instead of trying to catch someone on IRC. I have quite a few questions regarding GSoC. First of all, I'm not quite sure if I should propose the specific project or it should be given to me by one of the mentors. I was thinking about porting the necessary packages to Python 3, but I guess it could be too much for a single project (or maybe not?). I think asking a single student to port everything is too much. At this point, I think there's an opportunity to get two students working on the porting effort. Because of that I though about concentrating on Paste issue. I don't know if any decision has been made (whether to update Paste, rewrite create and serve or use something else, e.g. Marrow) and I'm almost sure I'm not the one to make such decisions. However, I have to put something more detailed in the application form. To be honest, I'm not sure we can manage paste replacement as a GSOC project, especially from scratch. Paste is relatively large, and encompasses many things. Furthermore, we actually use very little of Paste in Pyramid. Pyramid will happily run without PasteDeploy or PasteScript, so porting either is not a hot issue for Python 3 compatibility in the short term. Pyramid won't run without some things from the Paste package proper (namely its static file application named StaticURLParser, and some auth_tkt components). These will need to be replaced in order to run on Python 3. But it's a *lot* easier just to cut and paste and fix these specific components than it is to port the entirety of Paste, so I'd suggest we just do that. I think we should hold off on passing judgment on replacing Paste until after GSOC, when we know that we can run some form of Pyramid (albeit without PasteDeploy or PasteScript support) successfully. Regarding Paste and comments on https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: 1. YAML vs INI - is there any decision? 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't it be easy to fix? 3. The same goes for marrow.server.http being asynchronous. As long as it was multithreaded too I don't know how this could be a problem (but maybe I don't know enough). And according to the readme on github (https://github.com/marrow/marrow.server.http), multi-threading is on the todo list: threaded — Enable multi-threading. This is currently unimplemented pending support up-stream in marrow.server and defaults to False. 4. I'm uncomfortable with the direction of these libs personally. They seem to be more researchy than practical in lots of cases. Could somebody elaborate? I'm not trying to question anything, I don't know that much, I would just like to know what is wrong with Marrow. 5. If adapting and improving Marrow is not an option, then what should I do if I want to work on porting Pyramid to Python 3? On IRC Blaise Laflamme suggested CherryPy. What do you think? I thought that this is more development related so I'm posting to devel. Let me know if I was wrong. I think all the above stuff is probably too hard to tackle under GSOC. I suspect we should just get the bare minimum ported and see where we are. There is a list of dependencies on the https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm page that indicates the packages that need porting. I'd suggest that creating a proposal to port some of those would be best-received. - C Regards, -- Juliusz Gonera http://juliuszgonera.com/ -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: requests and transactions
On Thu, 2011-03-31 at 16:49 +0100, Chris Withers wrote: On 31/03/2011 16:09, Chris Withers wrote: What's the preferred way of working with transactions now, be they just SQLAlchemy transactions or, more likely, a bunch of things tied together by a transaction from the 'transaction' package? repoze.tm2 seems to be the old skool BFG way of doing things, but is this still the right way in Pyramid? The templates/scaffolds certainly use repoze.tm2, but the book uses the transaction package as an example for Using Finished Callbacks. What are the differences between these two approaches? Trying to answer this myself: So, repoze.tm2 has the following features missing from the simple example in Using Finished Callbacks: - commit veto: what situations would request.exception be None but the response status start with '4' or '5'? - after_end cleanups: but, I guess these could just be passed to add_finished_callback, right? FWIW, doesn anyone have any real-world examples where they've needed to use after_end cleanups? - isDoomed support: I guess this could be added to the example; can someone explain when isDoomed is True and what happens if that transaction is committed instead of being manually aborted? If I understand the above correctly (hopefully someone will point out if I missed anything!) then a simple Finished Callback should suffice, right? Related: Any chance of a RequestFinished event to subscribe to rather than having to (rather convolutedly) subscribe to NewRequest just so your handler can call add_finished_callback? ...in which case, I'd dearly love that RequestFinished event! Rocky has already created http://docs.pylonsproject.org/projects/pyramid_tm/dev/ which is an alternative to repoze.tm2 that uses a finished callback instead of middleware. I don't know if it solves the problem you're having. - C -- 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 can I iterate dict instance in a chameleon template
On Wed, 2011-03-30 at 21:59 +0900, Ha Nyung Chung wrote: Can I iterate all values in dict object in a chameleon template? I made view callable return dict object named params, which contains all parameter key/value pairs and chose to use chameleon template as a renderer. I wanted to iterate every key and value pairs of params in the template file, but couldn't find how to do that. the following code worked well while just displaying params' keys: li tal:repeat=key settings.keys() tal:content=key/li But this code raised an exception saying 'NoneType' object is not callable: li tal:repeat=key settings.keys() tal:content=settings[key]/li Could you provide a traceback? - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Terminology Change - Template to Skeleton
On Mon, 2011-03-21 at 13:32 -0500, Joe Dallago wrote: Yah the term 'scaffold' is used in a number of rails-like php frameworks as well. I think it would be more easily recognized than skeleton. -1 skeleton. +1 scaffold. Also fine by me. -- 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, 2011-03-21 at 21:53 -0500, Joe Dallago wrote: Haha Daniel, I honestly didn't realize this would become such a big topic of conversation, seeing as it isn't really that important of an issue. http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality I just wanted to make sure that there was some distinction between the two entities in the docs, b/c I remember this being an issue as a beginner. It became even more of a problem, when I went to IRC to ask questions, and confusion arrose over which 'template' I was talking about. I think 'scaffold' is the term that has been collectively accepted by the web development community, so I plan on using that. +1 - C On Mon, Mar 21, 2011 at 9:38 PM, Daniel Holth dho...@gmail.com wrote: Joe, I enjoy posting to mailing lists but as far as I'm concerned you may change the name of things without asking in the future. I have already read the docs and would probably never notice. Daniel -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Terminology Change - Template to Skeleton
Fine by me. - C On Sun, 2011-03-20 at 22:12 -0500, 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. -- 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: webob.acceptparse __radd__
On Wed, 2011-03-16 at 10:18 -0700, Alexandre Conrad wrote: Ok, I figured it out: __radd__ function is only called if the left operand does not support the corresponding operation and the operands are of different types. For instance, to evaluate the expression x - y, where y is an instance of a class that has an __radd__() method, y.__radd__(x) is called if x.__add__(y) returns NotImplemented. Whew. ;-) 2011/3/16 Alexandre Conrad alexandre.con...@gmail.com Hi Chris, I checked-in a bunch of coverage for webob.acceptparse yesterday while I was on flying back to SFO after PyCon, thanks to DVCS. There's still a little more to do, but I can't figure out is how to test an __radd__ special method? Any ideas how I can do that? (without calling it directly). It was nice to meet y'all and hacking together in the Pyramid room. Best, -- Alex | twitter.com/alexconrad -- Alex | twitter.com/alexconrad -- 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 start example (4.1) does not run on my machine
My only guess is that you're not using the virtualenv paster or python when you're trying to start the application. On Wed, 2011-03-09 at 00:16 -0800, armen wrote: Dear community, I am new to pyramid, I followed the installation steps as described in pyramid 1.0 documentation, but when I try to run the example of paragraph 4.1 I get the following error: from pyramid.config import Configurator ImportError: No module named config I think pyramid is properly installed in my system as when I type from pyramid.config import Configurator from within the python shell it works. Additionally, help(modules) command returns a list in which pyramid is included. Thank you in advance for your help -- 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: Questions for Pyramid talk at PyCon
Might be nice to talk about Akhet (nee pylons_sqla) for ex-Pylons folks. It's not released but hopefully shortly. On Wed, 2011-03-09 at 11:03 -0600, Carlos de la Guardia wrote: Hi, I'll be doing a talk about frequently asked questions about Pyramid. I'd like to cover technical questions, because Chris and Ben will surely answer the roadmap/decisions questions on their talk about the state of the Pylons project. I think by far the most often asked question is about traversal vs. routes and there are also many questions about the preferred ways to do sql_alchemy/forms/auth/etc. I have a few ideas, but to make my talk more complete I'd like to have some input from the list. Any favorite questions that I should cover? Thanks. Carlos de la Guardia -- 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 do I combine paster templates?
You can't combine them but you can start out using paster create -t pyramid_routesalchemy myproject then change the result to use Jinja2 using the docs from pyramid_jinja2 at http://docs.pylonsproject.org/projects/pyramid_jinja2/dev/ - C On Sat, 2011-03-05 at 12:34 -0800, Sasker wrote: Hi I am new to Pyramid and currently going through the tutorials. I was wondering how can I combine pyramid_routesalchemy and pyramid_jinja_starter templates so I can get url_dispatch + sqlalchemy + jinja2 I tried searching docs and mailing list but couldn't find how to do this. I am a little confused. Also, I apologize if I am posting to the wrong group, I wasn't quite sure which group I should be posting to. Thanks. -- 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, 2011-03-03 at 23:42 -0800, 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, Can you explain which Z things we'd take out? What Z things are you tripping over? traversal and all complex topics to 'Advance' section seperately. So that, people interested in squeezing full power/flexibility can go through those section while beginners or who come from other framework or technologies can feel better easly and start working on. I'm pretty sure, people would consider/refer advance section once they feel comfortable. So we should reorganize by moving chapters of the documentation around? But Its almost certain that, without un-cluttered, well organized document, its difficult to attract and get more contribution towards Pyramid. No doubt we can do better. - C my 2 cents. On Mar 4, 1:34 pm, Jonathan Vanasco jonat...@findmeon.com wrote: I think the criticisms in the post -- and their defense here -- are really important. I've had the same struggles. While many are not technically valid , they appear to be so because of the documentation and positioning of pyramid. Pyramid is really powerful framework, but its also quite low-level. Most frameworks are high-level. While this can be very powerful, it can also be frustrating. As an example, look at the concept of Auth -- the pyramid auth system is ( unless there are new magical docs out there ) very much positioned at doing some fine-grained authentication ( users, groups, actions) based on each 'view'. Most other frameworks use advanced plugins for this sort of functionality... and have much simpler plugins to handle authentication for each handler / controller / etc as a package. ie: for the majority of web applications, the state of being logged in is the only requirement for access to every method of a class/package, and having to (re)declare auth policies per method becomes daunting. 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. -- 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, 2011-03-03 at 19:09 -0600, Carlos de la Guardia wrote: Guys, I'll be at PyCon and would like to sprint on this. Maybe a tutorial with code. Anyone? I'd be up for that, although I'm also slated to help port WebOb to Py3k. Carlos de la Guardia On Thu, Mar 3, 2011 at 6:08 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 17:57 -0600, Joe Dallago wrote: So the thing we can carry away from this discussion is that we should improve Pyramid's new user experience, with tutorials and perhaps some defaults for basic functionality. We hold these truths to be self evident... - C On Thu, Mar 3, 2011 at 4:27 PM, Mike Orr sluggos...@gmail.com wrote: On Thu, Mar 3, 2011 at 10:22 AM, danjac...@gmail.com danjac...@gmail.com wrote: I'm not sure the OP is trolling, it comes across as frustration. It's absolutely a legitimate point, and it's what I've been concerned about for the past several months. It's why I'm writing the Pyramid Migration Guide and Akhet (the successor to pyramid_sqla) -- both to be released hopefully by PyCon. Stephan comes from a new user's perspective with a Django background. As such, there will be more users like this, and if we can give them specific documentation and examples addressing their concerns, it will help the works-out-of-the-box issue. If we want to attract new users, we must do this. That doesn't mean the Pyramid core developers have to do all the work. It's a great opportunity for add-on products made by others with more time on their hands. The Pyramid manual is essentially a reference guide, so it documents all the alternatives in detail. That's necessary, but it's not the same as a tutorial. And people have such different backgrounds that several focused tutorials would be better than one. I'm writing a migration guide for Pylons users. Stephan's post makes me think a migration guide for Django users would be helpful. I don't know enough about Django to write this myself. Obviously we can't write guides for every single framework, but Pylons covers a variety of WSGI developers who know something about Pylons, and Django covers another large set that's unique enough to require its own guide. Zope/BFG people seem to find the Pyramid manual sufficient, so that's covered. The answers to Stephan's concerns fall into roughly three categories: - Intentional design decisions; i.e., goals for Pyramid. - Tradeoffs we had to make given those decisions. - The historical legacy of BFG, and the desire not to break backward compatibility. Pyramid's design is heavily shaped by things that Pylons/TurboGears didn't have and their developers wanted. BFG did have these so we took them, and along came everything else BFG had. Things that Pylons specifically wanted were: events, a complete reference manual, eliminating the magic globals [1], better unit testing (which views-returning-a-dict provides), interfaces, a larger developer-base, and maybe other things I'm forgetting. Traversal, ZODB, and built-in auth that's simpler than repoze.who/what were minor desires that essentially came for free. [1] Pyramid threadlocals are similar to Pylons magic globals, but the rest of the framework has been designed not to require them (the threadlocals). The BFG developers make a compelling case that traversal and interfaces are useful, especially for certain kinds of applications. That having these available is a good thing, even for those who don't use them, because it provides a migration path to use them later if they become important someday. Traversal is particularly suited to CMS sites where editor-users can attach a page to any URL, arbitrarily nested. Routes doesn't do this; Routes depends on path variables being in fixed URL positions. Interfaces I only understand superficially, but I have a gut feeling they will be more widely used as more people get comfortable with them. Previously interfaces were available only in Zope and BFG. Zope is a very specialized environment, BFG somewhat less so, but Pyramid makes interfaces accessible to the masses (i.e., general Python-web developers). Pyramid and WebHelpers have borrowed some features from Django, but certain aspects of Django are decidedly non-features in Pyramid/Pylons/TurboGears, and have been for five years. The Pylons Project believes in using third-party packages whenever feasable, and in spinning off packages that can be used outside the frameworks. Of course there are disadvantages to this as well as advantages. If a third-party library becomes unmaintained or has version skew (i.e., its latest version has incompatible changes), it adversely affects the framework until we reconcile the two or switch to another library. Likewise, sometimes the framework needs
Re: Some thoughts about Pyramid
For the record, Bottle takes this tact. It's full feature set actually depends on many, many packages (many more than Pyramid does). But it ships as a single file with no dependencies. I'm not a huge fan of this. Maybe it's a successful marketing gimmick but it doesn't actually reduce any complexity. - C On Fri, 2011-03-04 at 08:52 -0800, Thomas G. Willis wrote: that's not a bad idea. I'm using pyramid on app engine, and don't need chameleon, but if I don't push chameleon up to the cloud the app fails to load last time I tried it. of course defining the bare minimum would probably be a challenge. :) -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, 2011-03-04 at 04:43 -0800, Andrey Petrov wrote: Re: Excessive dependencies. Right now when you 'pip install pyramid' on a fresh environment, you get 18 packages installed: Chameleon, Mako, MarkupSafe, Paste, PasteDeploy, PasteScript, WebOb, pyramid, repoze.lru, translationstring, venusian, zope.component, zope.configuration, zope.deprecation, zope.event, zope.i18nmessageid, zope.interface, zope.schema Pyramid depends on 12 distributions directly, the other 7 are transitive dependencies (you missed setuptools above). The dependency graph looks like this: Pyramid | |--- setuptools | |--- Chameleon | |--- Mako | | | -- MarkupSafe | |--- PasteScript || || Paste | |--- PasteDeploy || || Paste | |--- WebOb | |--- repoze.lru | |--- translationstring | |--- venusian | | zope.component | | | | zope.interface | | | -- zope.i18nmessageid | | zope.configuration | | | | zope.interface | | | | zope.schema | | | | zope.i18nmessageid | | | | zope.configuration | | | |--- zope.schema | | | zope.deprecation | | zope.interface 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? - C What about this alternative: Instead of installing all the possible dependencies in advance, we only install the bare minimum* needed to generate a project template and populate the project's setup.py (or requirements.txt) with all the necessary additional dependencies depending on which template was used or what options were chosen. Perhaps we could even auto-pip install -r requirements.txt as soon as the project template is created. This would cut down the base pyramid dependencies to just pyramid and Paste*, and the consequent project dependencies would be a few shorter than the total. Sounds like there is probably a magnitude of reasons why this is a bad idea, but worth bringing up. [*] Or perhaps instead of the absolute bare minimum, it could be a reasonable minimum. - shazow -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
Could you put this in the Pyramid issue tracker? On Fri, 2011-03-04 at 14:28 -0500, Daniel Holth wrote: My wishlist for the manual: 1. searching for request.response_headers should pull up request.response_headerlist 2. glossary for 'Configurator' etc. should link to function signatures -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
On Fri, 2011-03-04 at 12:00 -0800, Mike Orr wrote: On Thu, Mar 3, 2011 at 11:42 PM, Peter Alexis palexis2...@gmail.com 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] There is no ZCML in the Pyramid docs anymore. It was all moved to the pyramid_zcml package docs, and in order to use ZCML, you must install that package. - C -- 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, 2011-03-04 at 16:38 -0500, Reed L O'Brien wrote: On Mar 4, 2011, at 3:42 PM, Blaise Laflamme wrote: That said we definitely need to communicate the right message, provide the right level of documentation for the targeted audience, have a better way to expose tools and contributions, etc... Who is the targeted audience? Currently it seems to be everyone with a complaint. I was very happy with repoze.bfg as it shipped and am very happy with pyramid as it currently ships. It was only a minor nuisance to add pyramid_zcml as a dependency to the projects I had using it. I subsequently stopped using it, so I don't have to manage another dependency; it is just spelling... I used to know the docs in and out pretty well. Now I no longer do, because things keep moving every time someone complains. Mostly I can find what I am looking for by searching, but not if it moves out of the core docs... If the same thing starts happening with pyramid's code/packages and it becomes a game of thimblerig I will be very disappointed. I suspect there is a silent majority out there that feels similarly. That is just a suspicion, however. There currently seem to be to disjoint desires: - make pyramid more opinionated with less ways to do things - make pyramid smaller and remove all dependencies I think that pyramid and bfg before it were clearly not trying to be either the kitchen sink or the micro-est of frameworks. I think it has also been well documented that higher level frameworks should be built on pyramid rather than into it. As for a smaller pyramid, for those embedded webapps... perhaps we should apply the same approach. Keep pyramid shipping with its current features and create a smaller core (say Prism) for it to depend on. Prism might not have any templating, paste or other undesirable and offensive packages, but could be used by people who need to conserve space. I wouldn't likely ever use it as I would want the things that currently ship with pyramid and am not worried about mako taking up 1MB of space unused. WRT the docs, perhaps we don't need to change (or rearrange) perfectly good reference materials every day. If we need introductory docs why not a second Intro to Pyramid doc? If we just want recipes to do basic things without too many options, could we appeal to people (particularly people frustrated with a recent experience) to add how-tos to the cookbook? Isn't that what it is for? The roof on this bike shed should definitely be tin. Cheers, ~ro I'm not averse to changing things in major releases, but we do need to recognize that major refactorings have a cost for both producers and consumers. All major docs work has historically been done by one person (me, or at least someone I've hired). The amount of time it took to write the software was long ago dwarfed by an order of magnitude the time it takes to write and maintain docs. Seemingly insignificant changes (from a developer perspective) to Pyramid can require hours of docs work if a feature is newly exposed or one is removed. I'm not complaining about this, it's just the way things are. On the consumer side, as Reed mentioned, it's very difficult to keep up when things change quickly. So, given that the costs are high, if we do make major functionality changes, I'd like it to be at the boundaries of first-dot major releases. For example, I don't think it makes sense to have a Pyramid 1.1 that does not ship with Mako or Chameleon or Paster, but nothing should be off the table for a 2.X. - C -- 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, 2011-03-03 at 03:54 -0800, Peter Alexis wrote: Just happened to see a blog about Pyramid, http://slacy.com/blog/2011/02/why-im-unhappy-with-the-pyramid-web-framework/ Sounds like (s)he is blowing off a little steam. All of these points are addressed in http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . - C -- 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, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- 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: Fwd: Some thoughts about Pyramid
Pyramid to build [insert awesome site here]. 2. TIMTOWTDI. This is the bigger issue. It's a real roadblock for people starting a project in Pyramid, because they don't know whether to decide between traversal or dispatch, which form library, ZCML or ini, which template engine etc. It's also a potential issue for people taking on legacy Pyramid projects as they don't know what to expect. This is of course a strength as it gives you ultimate flexibility, but is also a source of confusion for newcomers. This situation will hopefully improve with templates built on top of Pyramid, but we're a long way from there yet. On 3 March 2011 17:31, Ben Bangert b...@groovie.org wrote: On Mar 3, 2011, at 9:28 AM, Chris McDonough wrote: Sounds like (s)he is blowing off a little steam. All of these points are addressed in http://docs.pylonsproject.org/projects/pyramid/1.0/designdefense.html . Indeed, my comment is awaiting moderation on the blog, I cited that URL as well. :) Cheers, Ben -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Some thoughts about Pyramid
in an application where the framework itself is limiting your progress. Let's say that you need row-level permissions and the default auth helper doesn't do this. If the entire framework is tied together, then you would have to deal with either having to manipulate some of the source code(which could possibly be changed in future updates) or scrap the whole thing. With Pyramid, a failure in a specific module simply means you ditch that ONE module and sub in another. It is also important to note that if Pyramid itself becomes obsolete in 5-10 years, as Pylons did, then at least you can carry over your knowledge of SQLAlchemy, paster, deform, etc. to the next framework. Essentially what I giving a world world example of the concept of encapsulation, that is something that every programmer should value. On Thu, Mar 3, 2011 at 12:24 PM, Chris McDonough chr...@plope.com wrote: On Thu, 2011-03-03 at 09:39 -0800, Stephen Lacy wrote: Okay, chiming in here. :) Yeah, this is my post. I've been pretty quiet here. Sorry for the somewhat negative tone, as you can imagine, the post was written after spending several hours digging through a very large amount of the Pyramid source code trying to figure out the answer to what seemed to be a very simple question. Yes, I could have asked here, or on #pylons, and maybe I should have. But, at the same time, I think that read and understand the source is an important aspect of a good framework, and that's what I was most frustrated about. We've all been there, no worries. - C -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: url-based authentication methods with pyramid
On Thu, 2011-03-03 at 08:41 -0800, T Ixioides wrote: Hi, I have a project where both humans and bots need to authenticate, but I don't know where to start with this new pyramid framework. In my case, bots will only retrieve URLs starting with /bots/ and other URLs are reserved for humans. I would like humans to authenticate with forms but bots only know basic or digest http auth methods. Since bots and humans will share same login and passwords I think it would make sense to do everything inside a single pyramid application, but I may be wrong on this point. Is this something doable with pyramid and where should I look for first ? Can I do this using url dispatch or traversal or both ? The method of viewfinding is sort of unrelated really, but the steps I'd take to do this would be either to use repoze.who (which already has support for stacked authentication methods) or to write a custom Pyramid authentication policy that can obtain information from either a cookie or basic authentication data. - C Thanks! -- 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, 2011-03-03 at 17:45 -0500, Mark Ramm wrote: A countervailing opinion: pip has problems with namespace packages. For an example, trying to use tox (a testing package which uses pip internally) to run tests against a namespace package (like repoze.anything) consistently fails. I haven't had time (or inclination) to dig into this purely because easy_install *does* work fine for these kinds of packages, but the failure tox may be compelling enough for me to dig into why pip fails under some circumstances related to namespace packages. I think the reason PIP has trouble with namespace packages is the choice to always use single-version-externally-managed. In my experience, if you install EVERYTHING with pip, you're ok, or if you install everything without it, you are OK, but using it along side distribute and easy install. Seems unlikely that this is the same problem, because tox does indeed use pip exclusively internally into a virtualenv it creates itself, so there is no mixing going on. - C -- 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: Question about virginia
On Wed, 2011-03-02 at 02:21 -0800, Georges Dubus wrote: On 1 mar, 23:00, Tres Seaver tsea...@palladion.com wrote: I'm afraid the example doesn't defend against relative '..' at all. That's what I would have thought, but http://localhost:6543/../ redirects to http://localhost:6543/ (sorry, typo in the previous message). I thought this had something to do with virginia, but it seems that the .. is interpreted earlier in the framework. I fact, it looks like it's the expected behaviour for an url ( just try : http://groups.google.com/group/pylons-devel/../../.. ) In a traversal-based application, Pyramid recomputes all '..' segments from the path at ingress, computing a traversal path before the application ever sees it. The pattern of registering views and adapters against interfaces, rather than directly against classes, goes back to our Zope-ish roots. I think some of those interfaces are actually left over from the time when Chris re-wrote 'repoze.kiss' to function as a BFG-based application: in 'repoze.kiss', there were real views registered for all the interfaces. Historical reasons ? That's what I thought. But, as it's used as an example application, wouldn't it be less confusing for newcomers to clean the application from the bits that aren't useful any more, in order to get a minimal working example ? If that's a good, idea, I volonteer. That'd be fine by me, if you can work up a pull request. - C -- 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: authenticated_userid vs unauthenticated_userid
On Mon, 2011-02-28 at 10:06 -0500, Daniel Holth wrote: I think the reasoning is that Interpret the current user id from a cookie / kerberos authentication / some key in the session and see whether the identified user exists in our system should be in different layers. I agree this leaves me scratching my head as to when the distinction is useful. The distinction is useful when folks want to closely control user checking for performance reasons, ala http://docs.pylonsproject.org/projects/pyramid_cookbook/dev/authentication.html . That said, if we had it to do all over again, it would be different. See http://plope.com/pyramid_auth_design_api_postmortem - C My first guess was 'the time between deleting a user from the database and the expiration of an authentication cookie', except I never delete users from my database, I would remove all their group memberships instead. I am used to systems that allow any username to be logged in but don't give any useful permissions unless that user actually has an account. Think of passing REMOTE_USER from a single sign on system, or a system that uses an openid as the userid. The application will only know about a few of these users but they will be logged in whether or not they exist in the application's database. While writing this example, perhaps this distinction could be used to offer a 'create account' form to a user who had just presented a new openid? I'm not entirely sure why that feature wouldn't just be a special group. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel +unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en. -- You received this message because you are subscribed to the Google Groups pylons-devel group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
