Re: Storing settings on module level -- bad idea?

[Chris McDonough]

On Tue, 2012-01-31 at 20:16 -0800, Jonathan Vanasco wrote:
> my .02¢ is this:
> 
> 
> App Developers like features like 'Globals'.  It's something that is
> familiar-from, and present-in many other frameworks.
> 
> 
> Granted, pyramid is a low-level framework - and one that a more
> 'webmonkey' friendly framework might be built upon itself.  But those
> frameworks are likely to end up implementing those features
> themselves... both in bad ways, and in many numerous different ways.
>  If pyramid can find a way to pull it off correctly, it would be
> great.
> 
> 
> Rails didn't succeed because it was a "great framework", its success
> is largely do to it being usable-by and appealing-to really bad
> developers ( i mean really awful ones ).  PHP got to be ubiquitous and
> installed on every platform, by just doing a shoddy job implementing
> everything, so even the worst developers flocked to it.  People I've
> been introduced to by recruiters as "Top Django Pros!" commanding 160k
> salaries, have been robots that barely know python.  
> 
> 
> I loved pylons, I love pyramid.  I only get to code about 20% of my
> time, and love being able to work in them, because they're implemented
> in a way that really resonates with how I like to work.  The problem
> though, is that I'm usually running operations, tech or product at a
> company -- not implementing it.  Having to source people to execute on
> goals is a pain.
> 
> 
> I understand why "technically" some things might not be right or
> ideal, and why they shouldn't be done -- but sometimes the best route
> for adoption and continued health isn't to do the "right" thing.
> 
> 
> sorry for ranting on this.
> /j

It's fine.  Nobody can take away your right to rant!  That said, nothing
is going to change in Pyramid itself with respect to making things that
are currently local into globals while I still walk upright and breathe.

Locals can be turned into globals.  Globals cannot be turned into
locals.  Cope! ;-)

- C



-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Jonathan Vanasco]

my .02¢ is this:

App Developers like features like 'Globals'.  It's something that is 
familiar-from, and present-in many other frameworks.

Granted, pyramid is a low-level framework - and one that a more 'webmonkey' 
friendly framework might be built upon itself.  But those frameworks are 
likely to end up implementing those features themselves... both in bad 
ways, and in many numerous different ways.  If pyramid can find a way to 
pull it off correctly, it would be great.

Rails didn't succeed because it was a "great framework", its success is 
largely do to it being usable-by and appealing-to really bad developers ( i 
mean really awful ones ).  PHP got to be ubiquitous and installed on every 
platform, by just doing a shoddy job implementing everything, so even the 
worst developers flocked to it.  People I've been introduced to by 
recruiters as "Top Django Pros!" commanding 160k salaries, have been robots 
that barely know python.  

I loved pylons, I love pyramid.  I only get to code about 20% of my time, 
and love being able to work in them, because they're implemented in a way 
that really resonates with how I like to work.  The problem though, is that 
I'm usually running operations, tech or product at a company -- not 
implementing it.  Having to source people to execute on goals is a pain.

I understand why "technically" some things might not be right or ideal, and 
why they shouldn't be done -- but sometimes the best route for adoption and 
continued health isn't to do the "right" thing.

sorry for ranting on this.
/j




-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/ddSQnMKjZZ4J.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Chris McDonough]

On Tue, 2012-01-31 at 15:06 -0800, Mike Orr wrote:
> On Tue, Jan 31, 2012 at 9:33 AM, Jonathan Vanasco  
> wrote:
> > I come from Pylons, where we had the g globals object.  I miss it
> > dearly.
> >
> > The Pyramid/Repoze group seems very much into the idea of passing a
> > request around all the time. I don't like that, mostly from the 'mass
> > appeal route' , in that its something that just about every other
> > framework has, and can make Pyramid a bit odd/hard to new people
> > considering it.
> 
> Some frameworks have it and some don't. I've already explained why it
> caused so much trouble in Pylons.
> 
> > Anyways, if you need to do this again:
> >
> > The Akhet scaffold has an event subscriber that creates a 'g' globals
> > object to emulate the pylons environment
> > 
> > https://bitbucket.org/sluggo/akhet/src/6c984e2e24cf/akhet/paster_templates/akhet/%2Bpackage%2B/subscribers.py_tmpl
> >
> > or you could also just have a little convenience method that just
> > wraps get_current_registry()
> >def get_current_settings(field=None):
> >if field:
> >return get_current_registry().settings[field]
> >return get_current_registry().settings
> 
> Akhet doesn't have 'g', but you can inject 'g =
> request.registry.settings' into the template namespace if you want.
> I'm not sure if you misunderstood the file you linked to; the
> 'renderer_globals' variable there is the template namespace, not a 'g'
> variable.
> 
> Chris McDonough wrote:
> > The framework does not require that your application use globals.  This
> makes it possible to run more than one Pyramid application in the same
> Python process, and makes it more likely that Pyramid can be used "like
> a library", which makes creating things like a development environment
> on top of Pyramid more pleasant.
> 
> Pylons bent over backwards to support multiple Pylons applications in
> the same process, and even multiple instances of the same Pylons
> application. That's what really turned the globals into deep voodo,
> and required StackedObjectProxies to ensure the correct global values
> were visible to each request. 

Pyramid also has the same concept of a stack; it's just not implemented
like Pylons' SOPs were.  The problem with SOPs was that they were
*importable*.  When you use the request or registry in Pyramid as a ,
you have to request it via get_current_request() or
get_current_registry(), and if you try to do that at module scope, you
get to keep both pieces when it breaks.  In Pylons, because SOPs were
importable, people had the expectation that they were useful at module
scope, and got wrapped around the axle when they were sometimes not.

> I thought you were trying to discourage
> multiple Pyramid applications in the same process, and that Pyramid
> was intended to run as one extensible application rather than multiple
> applications side by site.

Nah.  There's no logical binary distinction there.  Currently you can do
it either way, or both.  There'd be no reason to not have globals
(except for maybe some idea of cleanliness) if you didn't want to make
it possible to run more than one application per process.  I'm not
suggesting it's a "99%" use case, but for what it's worth, my company
already uses it like this in production to save RAM where we have to
support multiple (small) applications.

- C


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: View Callables as a Class and Dependency Injection

[Chris McDonough]

On Tue, 2012-01-31 at 15:09 -0800, papagr wrote:
> Hello everyone,
> 
> >From the object-oriented point of view, a Pyramid View (instance of a
> callable class) depends on the context and the request. Pyramid,
> correctly injects those dependencies into the view, during a view's
> class instantiation (while processing a Request).
> 
> Assuming that a view depends on other objects to do its job, is there
> a preferred or suggested way of injecting other services
> (dependencies) in a Pyramid view? By "injecting", I do not mean to use
> the Service Locator design pattern, i.e. let the view find its
> dependencies using a registry.

If you mean inject stuff into a *view*, you can cause the request to be
decorated with arbitrary objects on every request using
config.set_request_property (see
).
This requires Pyramid 1.3a6+.

If you mean inject stuff so that it's present in a template, you can use
a BeforeRender event (see

 )

- C


> 
> For the record, I recently configured and used yaak.inject (http://
> pypi.python.org/pypi/yaak.inject) to a Pyramid project. However, I am
> still investigating if there is a better way.
> 
> Cheers,
> 
> Nikolaos Papagrigoriou
> 


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[Karthi]

Lol

-K

On 01-Feb-2012, at 6:04 AM, Chris McDonough  wrote:

> On Tue, 2012-01-31 at 11:22 +0530, chandrakant kumar wrote:
>> 
>> 
>> True, when i started learning pyramid, i tried to search on google and
>> it returned results about 'egyptian pyramids'! 
> 
> I'd hope so!
> 
> - C
> 
> 
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "pylons-discuss" group.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To unsubscribe from this group, send email to pylons-discuss
>> +unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pylons-discuss?hl=en.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[Chris McDonough]

On Tue, 2012-01-31 at 11:22 +0530, chandrakant kumar wrote:
> 
> 
> True, when i started learning pyramid, i tried to search on google and
> it returned results about 'egyptian pyramids'! 

I'd hope so!

- C


> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to pylons-discuss
> +unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-discuss?hl=en.


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[chandrakant kumar]

True, when i started learning pyramid, i tried to search on google and it
returned results about 'egyptian pyramids'!

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

View Callables as a Class and Dependency Injection

[papagr]

Hello everyone,

>From the object-oriented point of view, a Pyramid View (instance of a
callable class) depends on the context and the request. Pyramid,
correctly injects those dependencies into the view, during a view's
class instantiation (while processing a Request).

Assuming that a view depends on other objects to do its job, is there
a preferred or suggested way of injecting other services
(dependencies) in a Pyramid view? By "injecting", I do not mean to use
the Service Locator design pattern, i.e. let the view find its
dependencies using a registry.

For the record, I recently configured and used yaak.inject (http://
pypi.python.org/pypi/yaak.inject) to a Pyramid project. However, I am
still investigating if there is a better way.

Cheers,

Nikolaos Papagrigoriou

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Mike Orr]

On Tue, Jan 31, 2012 at 9:33 AM, Jonathan Vanasco  wrote:
> I come from Pylons, where we had the g globals object.  I miss it
> dearly.
>
> The Pyramid/Repoze group seems very much into the idea of passing a
> request around all the time. I don't like that, mostly from the 'mass
> appeal route' , in that its something that just about every other
> framework has, and can make Pyramid a bit odd/hard to new people
> considering it.

Some frameworks have it and some don't. I've already explained why it
caused so much trouble in Pylons.

> Anyways, if you need to do this again:
>
> The Akhet scaffold has an event subscriber that creates a 'g' globals
> object to emulate the pylons environment
>     
> https://bitbucket.org/sluggo/akhet/src/6c984e2e24cf/akhet/paster_templates/akhet/%2Bpackage%2B/subscribers.py_tmpl
>
> or you could also just have a little convenience method that just
> wraps get_current_registry()
>    def get_current_settings(field=None):
>        if field:
>            return get_current_registry().settings[field]
>        return get_current_registry().settings

Akhet doesn't have 'g', but you can inject 'g =
request.registry.settings' into the template namespace if you want.
I'm not sure if you misunderstood the file you linked to; the
'renderer_globals' variable there is the template namespace, not a 'g'
variable.

Chris McDonough wrote:
> The framework does not require that your application use globals.  This
makes it possible to run more than one Pyramid application in the same
Python process, and makes it more likely that Pyramid can be used "like
a library", which makes creating things like a development environment
on top of Pyramid more pleasant.

Pylons bent over backwards to support multiple Pylons applications in
the same process, and even multiple instances of the same Pylons
application. That's what really turned the globals into deep voodo,
and required StackedObjectProxies to ensure the correct global values
were visible to each request. I thought you were trying to discourage
multiple Pyramid applications in the same process, and that Pyramid
was intended to run as one extensible application rather than multiple
applications side by site.

-- 
Mike Orr 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Caching Response Object

[Simon Yarde]

I wouldn't try to tell from a cookie, I would just put something like this in 
the template::

My Account

then have a script grab a json response containing minimal user info and modify 
the link::

Jane Smith

If js is unavailable then the My Account page remains accessible if slightly 
less friendly.

The semantics of the routes are arguable but this is the basic idea.

This said, Pyramid and MongoDB with Nginx/uWSGI (thanks to guidance from this 
forum) is proving so good that caching is not the concern it might have been.

Best, S

On 31 Jan 2012, at 16:57, jerry wrote:

> Thanks Simon. Varnish is definitely worth exploring.
> 
> I'm also very interested in your second approach, how can you tell if
> the user has JS enabled by looking at her request?
> 
> Jerry
> 
> On Jan 31, 11:45 pm, Simon Yarde  wrote:
>> I wonder if this solves your issue with Varnish, or if it is too coarse:
>> 
>> https://www.varnish-cache.org/docs/trunk/tutorial/cookies.html
>> 
>> It would seem as a minimum you could identify logged-in-users from 
>> non-logged-in-users by a the presence of a specific auth-cookie. This would 
>> certainly accelerate pages for non-logged in users.
>> 
>> I am currently working on pulling basic user info into cached pages via 
>> javascript; this covers most 'cart contents' and 'hello Jane Smith' type 
>> feedback scenarios. The graceful fallback is to send the user to a specific 
>> cart or account page if they don't have js active.
>> 
>> On 31 Jan 2012, at 15:25, jerry wrote:
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>> Thanks Robert.
>> 
>>> However, the cache needs to, at minimum, differentiate login users
>>> from non-login users to serve different content, and only a Pyramid
>>> app aware caching engine can do that.
>> 
>>> Jerry
>> 
>>> On Jan 31, 9:44 pm, Robert Forkel  wrote:
 hi jerry,
 if you run your app via paster/gunicorn/whatever proxied by apache or
 nginx, it is trivial to insert varnish [1] as transparent cache
 between the frontend and the server serving your pyramid app.
 regards
 robert
>> 
 [1]https://www.varnish-cache.org/
>> 
 On Tue, Jan 31, 2012 at 9:16 AM, jerry  wrote:
> Hi,
>> 
> I wonder if anyone has succeeded in caching the template output. The
> main hurdle I'm facing is how to serialize the entire Response object.
> I have made a tween to cache the vanilla 200 response.text, but what
> about redirect, forbidden, etc, I don't have a solution.
>> 
> Any pointer will be much appreciated.
>> 
> Jerry
>> 
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/pylons-discuss?hl=en.
>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "pylons-discuss" group.
>>> To post to this group, send email to pylons-discuss@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> pylons-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit this group 
>>> athttp://groups.google.com/group/pylons-discuss?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Chris McDonough]

On Tue, 2012-01-31 at 09:33 -0800, Jonathan Vanasco wrote:
> I come from Pylons, where we had the g globals object.  I miss it
> dearly.
> 
> The Pyramid/Repoze group seems very much into the idea of passing a
> request around all the time. I don't like that, mostly from the 'mass
> appeal route' , in that its something that just about every other
> framework has, and can make Pyramid a bit odd/hard to new people
> considering it.

The framework does not require that your application use globals.  This
makes it possible to run more than one Pyramid application in the same
Python process, and makes it more likely that Pyramid can be used "like
a library", which makes creating things like a development environment
on top of Pyramid more pleasant.

*You* can use globals if you like, because any nonglobal can be turned
into a global.  The inverse is not true, however.

I'd put some well-tested well-understood turn-nonglobals-into-globals
thing in the cookbook if folks agreed on it (that was the intent of
putting the Django-settings-like recipe in there).  Pyramid, however,
will never require that any framework user depend upon globals.

- C


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Jonathan Vanasco]

I come from Pylons, where we had the g globals object.  I miss it
dearly.

The Pyramid/Repoze group seems very much into the idea of passing a
request around all the time. I don't like that, mostly from the 'mass
appeal route' , in that its something that just about every other
framework has, and can make Pyramid a bit odd/hard to new people
considering it.

mod_perl had an interesting approach to globals.
- it was often recommended that globals were 'read-only' variables, so
you couldn't change them
- the mp architecture was a little weird. the Apache Master server
started up and had the true 'global' vars.  Requests would be handled
by spawned children, up to max-requests, which had their own copy of
globals.  Anything they altered would stay global only within that
child ( not affect the master or the other children ).  because of
tis , applications built on it tended to do a lot of caching and pre-
compiling on startup to build up a true 'global' datastore... but then
basically never think about writing to the globals -- as there was
little efficiency to be had.

Anyways, if you need to do this again:

The Akhet scaffold has an event subscriber that creates a 'g' globals
object to emulate the pylons environment
 
https://bitbucket.org/sluggo/akhet/src/6c984e2e24cf/akhet/paster_templates/akhet/%2Bpackage%2B/subscribers.py_tmpl

or you could also just have a little convenience method that just
wraps get_current_registry()
def get_current_settings(field=None):
if field:
return get_current_registry().settings[field]
return get_current_registry().settings

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Caching Response Object

[jerry]

Thanks Simon. Varnish is definitely worth exploring.

I'm also very interested in your second approach, how can you tell if
the user has JS enabled by looking at her request?

Jerry

On Jan 31, 11:45 pm, Simon Yarde  wrote:
> I wonder if this solves your issue with Varnish, or if it is too coarse:
>
> https://www.varnish-cache.org/docs/trunk/tutorial/cookies.html
>
> It would seem as a minimum you could identify logged-in-users from 
> non-logged-in-users by a the presence of a specific auth-cookie. This would 
> certainly accelerate pages for non-logged in users.
>
> I am currently working on pulling basic user info into cached pages via 
> javascript; this covers most 'cart contents' and 'hello Jane Smith' type 
> feedback scenarios. The graceful fallback is to send the user to a specific 
> cart or account page if they don't have js active.
>
> On 31 Jan 2012, at 15:25, jerry wrote:
>
>
>
>
>
>
>
> > Thanks Robert.
>
> > However, the cache needs to, at minimum, differentiate login users
> > from non-login users to serve different content, and only a Pyramid
> > app aware caching engine can do that.
>
> > Jerry
>
> > On Jan 31, 9:44 pm, Robert Forkel  wrote:
> >> hi jerry,
> >> if you run your app via paster/gunicorn/whatever proxied by apache or
> >> nginx, it is trivial to insert varnish [1] as transparent cache
> >> between the frontend and the server serving your pyramid app.
> >> regards
> >> robert
>
> >> [1]https://www.varnish-cache.org/
>
> >> On Tue, Jan 31, 2012 at 9:16 AM, jerry  wrote:
> >>> Hi,
>
> >>> I wonder if anyone has succeeded in caching the template output. The
> >>> main hurdle I'm facing is how to serialize the entire Response object.
> >>> I have made a tween to cache the vanilla 200 response.text, but what
> >>> about redirect, forbidden, etc, I don't have a solution.
>
> >>> Any pointer will be much appreciated.
>
> >>> Jerry
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups 
> >>> "pylons-discuss" group.
> >>> To post to this group, send email to pylons-discuss@googlegroups.com.
> >>> To unsubscribe from this group, send email to 
> >>> pylons-discuss+unsubscr...@googlegroups.com.
> >>> For more options, visit this group 
> >>> athttp://groups.google.com/group/pylons-discuss?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "pylons-discuss" group.
> > To post to this group, send email to pylons-discuss@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > pylons-discuss+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/pylons-discuss?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[Blaise Laflamme]

Next website will be Pyramid branded and be available by next pycon :)

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/pylons-discuss/-/Q1xkgMbuHt4J.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Caching Response Object

[Simon Yarde]

I wonder if this solves your issue with Varnish, or if it is too coarse:

https://www.varnish-cache.org/docs/trunk/tutorial/cookies.html

It would seem as a minimum you could identify logged-in-users from 
non-logged-in-users by a the presence of a specific auth-cookie. This would 
certainly accelerate pages for non-logged in users.

I am currently working on pulling basic user info into cached pages via 
javascript; this covers most 'cart contents' and 'hello Jane Smith' type 
feedback scenarios. The graceful fallback is to send the user to a specific 
cart or account page if they don't have js active.

On 31 Jan 2012, at 15:25, jerry wrote:

> Thanks Robert.
> 
> However, the cache needs to, at minimum, differentiate login users
> from non-login users to serve different content, and only a Pyramid
> app aware caching engine can do that.
> 
> Jerry
> 
> On Jan 31, 9:44 pm, Robert Forkel  wrote:
>> hi jerry,
>> if you run your app via paster/gunicorn/whatever proxied by apache or
>> nginx, it is trivial to insert varnish [1] as transparent cache
>> between the frontend and the server serving your pyramid app.
>> regards
>> robert
>> 
>> [1]https://www.varnish-cache.org/
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, Jan 31, 2012 at 9:16 AM, jerry  wrote:
>>> Hi,
>> 
>>> I wonder if anyone has succeeded in caching the template output. The
>>> main hurdle I'm facing is how to serialize the entire Response object.
>>> I have made a tween to cache the vanilla 200 response.text, but what
>>> about redirect, forbidden, etc, I don't have a solution.
>> 
>>> Any pointer will be much appreciated.
>> 
>>> Jerry
>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "pylons-discuss" group.
>>> To post to this group, send email to pylons-discuss@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> pylons-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit this group 
>>> athttp://groups.google.com/group/pylons-discuss?hl=en.
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Caching Response Object

[jerry]

Thanks Robert.

However, the cache needs to, at minimum, differentiate login users
from non-login users to serve different content, and only a Pyramid
app aware caching engine can do that.

Jerry

On Jan 31, 9:44 pm, Robert Forkel  wrote:
> hi jerry,
> if you run your app via paster/gunicorn/whatever proxied by apache or
> nginx, it is trivial to insert varnish [1] as transparent cache
> between the frontend and the server serving your pyramid app.
> regards
> robert
>
> [1]https://www.varnish-cache.org/
>
>
>
>
>
>
>
> On Tue, Jan 31, 2012 at 9:16 AM, jerry  wrote:
> > Hi,
>
> > I wonder if anyone has succeeded in caching the template output. The
> > main hurdle I'm facing is how to serialize the entire Response object.
> > I have made a tween to cache the vanilla 200 response.text, but what
> > about redirect, forbidden, etc, I don't have a solution.
>
> > Any pointer will be much appreciated.
>
> > Jerry
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "pylons-discuss" group.
> > To post to this group, send email to pylons-discuss@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > pylons-discuss+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://groups.google.com/group/pylons-discuss?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[John Anderson]

>
>
>
> But maybe now there's a new generation of users who don't have a
> either Pylons or a BFG background, who find all the history and
> non-Pyramid alternatives distracting. If so... again, I don't think we
> want to rip the manual and website apart to address it. But maybe the
> documentation intro or a supplemental doc can start with what Pyramid
> *is*, now, standalone, and then at the end mention how the
> alternatives relate to it.
>
>
I'm of this generation.  I haven't used or really care about anything
pylons/bfg related.  Pyramid is just pyramid to me, I don't really need the
history.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Tom Lazar]

On Jan 31, 2012, at 3:27 PM, Malthe Borch wrote:

> Another option – in terms of "the right thing" – is to derive an
> object that carries just to things you need from the request, e.g.
> "locale" and "logged in user", so that you don't pass around an HTTP
> request everywhere (and hence need to stub it out in tests).

FWIW that's what i ended up with, actually. the view extracts the filesystem 
root setting from the request and then just passes that particular setting to 
the helper methods that require it. in my testing i create a sandbox and pass 
*its* location to the helpers. presto, no request involved, no wsgi app 
instantiated!

> That object might be an "environment" in which code executes.

in my case that's an instance of a 'dropbox' class that receives a root path in 
its init.

i'm actually rather happy with how it turned out :)

tom

> 
> \malthe
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Redirect failure in page templates

[Arndt Droullier]

Am Montag, den 30.01.2012, 10:27 -0800 schrieb Jonathan Vanasco:
> could you share the code that raised the exception , or an
> approximation of it ?
> 

All approximations I tried do not reproduce the exception. Seems to
depend on the context or circumstences. Well, the code connects to
almost everything (sevaral templates, web page, widgets, form, user
databse) and the request makes it's way through several modules.

I think you're right. There is not much use discussing this without
code. And the code is to be released anyway. I will include an example.

Thanks, Arndt.

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Mike Orr]

On Tue, Jan 31, 2012 at 3:30 AM, Tom Lazar  wrote:
> i really would like to have a clean, convenient and supported way to access 
> global settings. i guess, the answer is that pyramid currently doesn't have 
> this on offer.
>
> generically exposing the settings that were used to invoke a pyramid instance 
> on module level would be nice, but i infer from what you've said the the 
> convenience that would add would be outweighed by the stuff that could 
> possibly go wrong. correct?

Pylons had magic globals ('config' -- akin to settings, 'request',
'response', 'session', etc), and they failed in situations like unit
tests or maintenance utilities where you're not in a view called by
the router. Plus they're always a source of potential failure and
hard-to-trace bugs even when they do work most of the time. In short,
it's harder to *guarantee* your application will always be correct
when you're not passing the objects as arguments through to all the
routines that need them. If you pass them all the way through or
attach them to 'self', it leaves a visible trace of how the object got
from one place to another, and who's responsible for modifying it.
With magic globals, this is taken out of your control and you have to
depend on black-box code in the framework, which is harder to test and
guarantee.

A major goal for Pylons 2 was to eliminate the magic globals. Pylons
merged into Pyramid because it fulfilled that goal.

> maybe i could just mock get_current_registry() in my test harness and simply 
> use that in the few places of my code that does not have convenient access to 
> a request.

That's the back door. The 'threadlocals' module gives you the state
objects when you can't access them any other way; e.g., in 'pshell'.
But as the manual says, you should try to use it as little as
possible, because it is essentially a magic global.

-- 
Mike Orr 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Malthe Borch]

On 31 January 2012 13:43, Robert Forkel  wrote:
> fwiw: when I started using pyramid I was also reluctant to pass around
> the request all the time. But it turned out to be the right (and
> transparent) thing to do. In my case this is because I often need
> request-specific information like the locale name basically
> everywhere. Once you get used to this (and to creating DummyRequests
> all the time for tests), you will come to like the registry as the
> place to go for global settings.

Another option – in terms of "the right thing" – is to derive an
object that carries just to things you need from the request, e.g.
"locale" and "logged in user", so that you don't pass around an HTTP
request everywhere (and hence need to stub it out in tests).

That object might be an "environment" in which code executes.

\malthe

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Pylons can be confusing to Pyramid

[Mike Orr]

Switched to bottom-posting to make it easier to discuss this.

> On Jan 27, 6:50 pm, Jemes Hsu  wrote:
>> Pyramid is carrying a lot of old baggage. Reading about Pyramid, you are
>> reading the history about repoze, ZOPE and Pylons and about Pylons
>> projects. One needs to understand Pylons web framework is different from
>> Pylons projects. There is no Pyramid branded delicate website. All these
>> can make learning about Pyramid a bit confusing to beginners. As an
>> example, the discussion group of Pyramid is at pylons-discussion. First "The
>> Pylons Project was founded by the people behind the Pylons web framework to
>> develop web application framework technology in Python." then Pylons web
>> framework is in legacy status. Suggestion is for website to play down on
>> topics with history, even to the extend of hiding Pylon web framework. Just
>> want Pyramid to thrive. I'm new to Pyramid, still learning it, excited by
>> it and will likely use it for next project.

On Mon, Jan 30, 2012 at 9:47 PM, Eric Ongerth  wrote:
> +1 here, even from myself who had some legacy Pylons apps lying
> around.

It's worth re-evaluating the issue. Pyramid has invested a lot in the
joint pylonsproject.org website. I don't think we want to rip it up to
create a separate Pyramid site. But perhaps we can adjust the wording
on the home page and the main documentation page to address this
confusion. I come from a Pylons background so I focus on documentation
for users transitioning from Pylons. Most of our initial users came
from either a Pylons or BFG background -- or they'd heard about Pylons
for years without using it -- and the first thing they want to know is
how Pyramid relates to these frameworks.

But maybe now there's a new generation of users who don't have a
either Pylons or a BFG background, who find all the history and
non-Pyramid alternatives distracting. If so... again, I don't think we
want to rip the manual and website apart to address it. But maybe the
documentation intro or a supplemental doc can start with what Pyramid
*is*, now, standalone, and then at the end mention how the
alternatives relate to it.

-- 
Mike Orr 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Tom Lazar]

On Jan 31, 2012, at 2:59 PM, Chris McDonough wrote:

> If you did what that thing suggested you'd likely write a small wrapper
> to run your app instead of using paster serve, so there'd be no "twice".
> Or at least you can arrange to do that with enough imagination.

true. 
> 
>>> I personally find that global settings makes my test code much more 
>>> brittle, because it means I have to clean up the settings after changing 
>>> them within test code instead of just saying "request.settings = {}". But 
>>> at the end of the day, it's really up to you.
>> 
>> ah, i just give each test a new instance of the settings, so there's no need 
>> to clean up.
>> 
>> i really would like to have a clean, convenient and supported way to access 
>> global settings. i guess, the answer is that pyramid currently doesn't have 
>> this on offer.
> 
> No, it doesn't, or at least it leaves it up to you.  Individuals can
> always make nonglobal things global, but a framework can't make things
> nonglobal once it makes them global.

makes sense.
> 
>> generically exposing the settings that were used to invoke a pyramid 
>> instance on module level would be nice, but i infer from what you've said 
>> the the convenience that would add would be outweighed by the stuff that 
>> could possibly go wrong. correct?
> 
> The Django core devs I've heard always lament using global settings.
> The zope.testing.setUp stuff that clears a module scope registry is
> another antipattern.
> 
>> maybe i could just mock get_current_registry() in my test harness and simply 
>> use that in the few places of my code that does not have convenient access 
>> to a request.
> 
> I dunno.  If you want global stuff it's easy enough to make things
> global if you use a little thought.  Or just pass the request around.

like i mentioned, i've meanwhile realized that my problem was in poor (or no) 
design of what needs to be done where. once i re-arranged the furniture, the 
problem went away.

passing the request around seems the right thing™ to do. at least now i know 
*why* instead of just blindly cargo-culting :)

cheers,

tom

> 
> - C
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Tom Lazar]

On Jan 31, 2012, at 1:43 PM, Robert Forkel wrote:

> fwiw: when I started using pyramid I was also reluctant to pass around
> the request all the time. But it turned out to be the right (and
> transparent) thing to do. In my case this is because I often need
> request-specific information like the locale name basically
> everywhere. Once you get used to this (and to creating DummyRequests
> all the time for tests), you will come to like the registry as the
> place to go for global settings.

thanks robert, that was helpful. since posting the original message to this 
list i've also realized that my real problem is that i'm partially trying to do 
the right things at the wrong places.

for example, by splitting the setting (a filesystem path) into a root part 
(deployment specific) and the remaining relative path (application specific) 
the whole problem vanished.

thanks for the feedback,

tom

> regards
> robert
> 
> On Tue, Jan 31, 2012 at 12:30 PM, Tom Lazar  wrote:
>> On 31.01.2012, at 05:48, Chris McDonough wrote:
>> 
>>> I think it might be significantly better to just create a settings.py
>>> module in your app and put stuff in there instead of in your config file
>> 
>> hm, i don't want to *maintain* the settings in python code, just have easy 
>> access. or else i end up with duplicate entries that i need to keep in sync.
>> 
>>> if you want globals, because this is effectively a monkeypatch, and
>>> makes bootstrap code very timing-dependent.
>> 
>> right.
>> 
>>>  Or you could do something
>>> like what's suggested in
>>> 
>> 
>> wow, that approach seems almost ridiculous :) following it you end up with 
>> having to pass in/configure the location of the ini file *twice*  and parse 
>> the whole thing manually *again*. i don't think i'll go down that road.
>> 
>>> I personally find that global settings makes my test code much more 
>>> brittle, because it means I have to clean up the settings after changing 
>>> them within test code instead of just saying "request.settings = {}". But 
>>> at the end of the day, it's really up to you.
>> 
>> ah, i just give each test a new instance of the settings, so there's no need 
>> to clean up.
>> 
>> i really would like to have a clean, convenient and supported way to access 
>> global settings. i guess, the answer is that pyramid currently doesn't have 
>> this on offer.
>> 
>> generically exposing the settings that were used to invoke a pyramid 
>> instance on module level would be nice, but i infer from what you've said 
>> the the convenience that would add would be outweighed by the stuff that 
>> could possibly go wrong. correct?
>> 
>> maybe i could just mock get_current_registry() in my test harness and simply 
>> use that in the few places of my code that does not have convenient access 
>> to a request.
>> 
>> sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :)
>> 
>> tom
>> 
>>> 
>>> - C
>>> 
>>> 
>>> --
>>> You received this message because you are subscribed to the Google Groups 
>>> "pylons-discuss" group.
>>> To post to this group, send email to pylons-discuss@googlegroups.com.
>>> To unsubscribe from this group, send email to 
>>> pylons-discuss+unsubscr...@googlegroups.com.
>>> For more options, visit this group at 
>>> http://groups.google.com/group/pylons-discuss?hl=en.
>>> 
>> 
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> pylons-discuss+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/pylons-discuss?hl=en.
>> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Chris McDonough]

On Tue, 2012-01-31 at 12:30 +0100, Tom Lazar wrote:
> On 31.01.2012, at 05:48, Chris McDonough wrote:
> 
> > I think it might be significantly better to just create a settings.py
> > module in your app and put stuff in there instead of in your config file
> 
> hm, i don't want to *maintain* the settings in python code, just have easy 
> access. or else i end up with duplicate entries that i need to keep in sync.

You'd just do the work at global scope in a module to read them from an
ini file.  You wouldn't maintain them twice.

> > if you want globals, because this is effectively a monkeypatch, and
> > makes bootstrap code very timing-dependent.
> 
> right.
> 
> >  Or you could do something
> > like what's suggested in
> > 
> 
> wow, that approach seems almost ridiculous :) following it you end up with 
> having to pass in/configure the location of the ini file *twice*  and parse 
> the whole thing manually *again*. i don't think i'll go down that road.

If you did what that thing suggested you'd likely write a small wrapper
to run your app instead of using paster serve, so there'd be no "twice".
Or at least you can arrange to do that with enough imagination.

> > I personally find that global settings makes my test code much more 
> > brittle, because it means I have to clean up the settings after changing 
> > them within test code instead of just saying "request.settings = {}". But 
> > at the end of the day, it's really up to you.
> 
> ah, i just give each test a new instance of the settings, so there's no need 
> to clean up.
> 
> i really would like to have a clean, convenient and supported way to access 
> global settings. i guess, the answer is that pyramid currently doesn't have 
> this on offer.

No, it doesn't, or at least it leaves it up to you.  Individuals can
always make nonglobal things global, but a framework can't make things
nonglobal once it makes them global.

> generically exposing the settings that were used to invoke a pyramid instance 
> on module level would be nice, but i infer from what you've said the the 
> convenience that would add would be outweighed by the stuff that could 
> possibly go wrong. correct?

The Django core devs I've heard always lament using global settings.
The zope.testing.setUp stuff that clears a module scope registry is
another antipattern.

> maybe i could just mock get_current_registry() in my test harness and simply 
> use that in the few places of my code that does not have convenient access to 
> a request.

I dunno.  If you want global stuff it's easy enough to make things
global if you use a little thought.  Or just pass the request around.

- C


-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: [Pyramid] Caching Response Object

[Robert Forkel]

hi jerry,
if you run your app via paster/gunicorn/whatever proxied by apache or
nginx, it is trivial to insert varnish [1] as transparent cache
between the frontend and the server serving your pyramid app.
regards
robert

[1] https://www.varnish-cache.org/

On Tue, Jan 31, 2012 at 9:16 AM, jerry  wrote:
> Hi,
>
> I wonder if anyone has succeeded in caching the template output. The
> main hurdle I'm facing is how to serialize the entire Response object.
> I have made a tween to cache the vanilla 200 response.text, but what
> about redirect, forbidden, etc, I don't have a solution.
>
> Any pointer will be much appreciated.
>
> Jerry
>
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Robert Forkel]

fwiw: when I started using pyramid I was also reluctant to pass around
the request all the time. But it turned out to be the right (and
transparent) thing to do. In my case this is because I often need
request-specific information like the locale name basically
everywhere. Once you get used to this (and to creating DummyRequests
all the time for tests), you will come to like the registry as the
place to go for global settings.
regards
robert

On Tue, Jan 31, 2012 at 12:30 PM, Tom Lazar  wrote:
> On 31.01.2012, at 05:48, Chris McDonough wrote:
>
>> I think it might be significantly better to just create a settings.py
>> module in your app and put stuff in there instead of in your config file
>
> hm, i don't want to *maintain* the settings in python code, just have easy 
> access. or else i end up with duplicate entries that i need to keep in sync.
>
>> if you want globals, because this is effectively a monkeypatch, and
>> makes bootstrap code very timing-dependent.
>
> right.
>
>>  Or you could do something
>> like what's suggested in
>> 
>
> wow, that approach seems almost ridiculous :) following it you end up with 
> having to pass in/configure the location of the ini file *twice*  and parse 
> the whole thing manually *again*. i don't think i'll go down that road.
>
>> I personally find that global settings makes my test code much more brittle, 
>> because it means I have to clean up the settings after changing them within 
>> test code instead of just saying "request.settings = {}". But at the end of 
>> the day, it's really up to you.
>
> ah, i just give each test a new instance of the settings, so there's no need 
> to clean up.
>
> i really would like to have a clean, convenient and supported way to access 
> global settings. i guess, the answer is that pyramid currently doesn't have 
> this on offer.
>
> generically exposing the settings that were used to invoke a pyramid instance 
> on module level would be nice, but i infer from what you've said the the 
> convenience that would add would be outweighed by the stuff that could 
> possibly go wrong. correct?
>
> maybe i could just mock get_current_registry() in my test harness and simply 
> use that in the few places of my code that does not have convenient access to 
> a request.
>
> sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :)
>
> tom
>
>>
>> - C
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To unsubscribe from this group, send email to 
>> pylons-discuss+unsubscr...@googlegroups.com.
>> For more options, visit this group at 
>> http://groups.google.com/group/pylons-discuss?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Re: Storing settings on module level -- bad idea?

[Tom Lazar]

On 31.01.2012, at 05:48, Chris McDonough wrote:

> I think it might be significantly better to just create a settings.py
> module in your app and put stuff in there instead of in your config file

hm, i don't want to *maintain* the settings in python code, just have easy 
access. or else i end up with duplicate entries that i need to keep in sync.

> if you want globals, because this is effectively a monkeypatch, and
> makes bootstrap code very timing-dependent.

right.

>  Or you could do something
> like what's suggested in
> 

wow, that approach seems almost ridiculous :) following it you end up with 
having to pass in/configure the location of the ini file *twice*  and parse the 
whole thing manually *again*. i don't think i'll go down that road.

> I personally find that global settings makes my test code much more brittle, 
> because it means I have to clean up the settings after changing them within 
> test code instead of just saying "request.settings = {}". But at the end of 
> the day, it's really up to you.

ah, i just give each test a new instance of the settings, so there's no need to 
clean up.

i really would like to have a clean, convenient and supported way to access 
global settings. i guess, the answer is that pyramid currently doesn't have 
this on offer.

generically exposing the settings that were used to invoke a pyramid instance 
on module level would be nice, but i infer from what you've said the the 
convenience that would add would be outweighed by the stuff that could possibly 
go wrong. correct?

maybe i could just mock get_current_registry() in my test harness and simply 
use that in the few places of my code that does not have convenient access to a 
request.

sorry for rambling, i guess, i'm (ab-)using the list for rubberducking... :)

tom

> 
> - C
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To unsubscribe from this group, send email to 
> pylons-discuss+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/pylons-discuss?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

[Pyramid] Caching Response Object

[jerry]

Hi,

I wonder if anyone has succeeded in caching the template output. The
main hurdle I'm facing is how to serialize the entire Response object.
I have made a tween to cache the vanilla 200 response.text, but what
about redirect, forbidden, etc, I don't have a solution.

Any pointer will be much appreciated.

Jerry

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.