On Mon, May 31, 2010 at 1:38 AM, Evgeny <[email protected]> wrote:
> OK.
> I've just thought what if I'm unable to get global request/config out
> of every piece of my code.
>
> Today I have a helper function that utilizes config, environ, and I
> call it from templates
> just like ${h.help_me('arg')}.
> So do I supposed to call it in 1.1 like
> ${h.help_me('arg', self.request, self.config,
> self.whatever_request_context_I_need_there)}?
> instead of importing globals in lib/help_me.py?
Your function probably doesn't need all of config, but one or two
specific variables. So you'd pass those. And in a template, 'request'
and 'config' are already in the template namespace (that's what the
render function does) so you don't need 'self'.
${paginate.Page(c.records, items_per_page=config["items_per_page"])}
Well, that's a bit contrived because you'd normally pass
items_per_page as a 'c' variable. But that's how you'd pass a config
var to a library routine.
> I believe the beauty of Pylons and Python, is that it allows a minor
> magic in favor of nice readability.
> As a framework user, I don't need a pure OOP design of it. I just need
> a tool to do the things.
That's the counter-argument, and why the SOPs exist.
> So globals are good in many situations, and request/response/config is
> really of nothing magic in them.
The last part is untrue. They're magic because they don't follow the
normal rules of Python, that when you set an attribute, it keeps that
value until you reassign it. The SOPs depend on Pylons pushing and
popping values onto the attributes to match the current request. An
accessor function (such as get_request()) would be non-magical because
it would be obvious to the user that some sort of calculation is being
performed. Instance properties are not equivalent because again, it's
documented that any instance attribute might be a property. But
people do not expect that for module attributes. Indeed, that's why
people are dumbfounded when they get a "no object has been registered
in this thread" error, because it's not a standard part of Python.
The problems with SOPs are precisely what people have described in
this thread: the fact that they don't always work in some edge cases,
and so you sometimes have to get the config another way in certain
situations.
> Python is not Java, not "everything is object".
> This is why I love Python, and switched to it. It has nice compromises
> in its design that helps a lot in daily life.
But Python also believes that simple is better than complex, explicit
is better than implicit, and intuitive is better than magical.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
