Hi Mike,
Thanks for the response!
So, here's my question: is there any plan or interest in a Pylons
(Paste?) that does *not* use stacked object proxies for things like
request, session, etc?
SOPs have been controversial for a long time. You might find it
interesting searching the pylons-discuss archives.
I think there's an attribute on the controller instance,
``._py_object``, that contains the request/response/session, etc. And
I think you can disable the magic globals by commenting out the
RegistryManager in middleware.py. You can hunt about in the
interactive traceback.
Ah, thank you; I have not yet experimented with the RegistryManager; I
will go down that route to see if it provides a path for achieving what
we want (elaborated below). (And maybe setting them directly on
controllers would provide workaround for certain test cases.)
I think I understand the use-case for this, but have to say that it
really adds a lot of complexity -- particularly in the area of testing
-- and it seems to only enable a very specific (rare?) use case. If
there was only some sort of flag ... or a Pylons fork that just used
thread-local storage for these "globals". I never want to run
multiple applications in the same thread context; does anyone really
*need* to do that?
It's a rare use case. There has been a lot of discussion about
replacing the SOPs with threadlocals. Also, Pylons 2, built on Marco,
will not depend on them, although the compatibility layer will have to
support them for existing apps.
Ah, that's excellent (especially if the compat layer can be disabled).
I haven't been following Pylons 2 plans; I'll start reading up on that.
These stacked object proxies are just a royal pain
to debug. I imagine most developers just throw up a white flag when
they have a run in with one of these quizzical beasts.
The main thing to remember is that ``sop._current_obj()`` returns the
original object. Some builtin functions aren't proxied -- I don't
remember if it's dir(), vars(), or dict() -- so you get back the SOP's
attributes rather than the original object's attributes. In those
cases you have to use ._current_obj().
Yes, I did discover how to pull stuff out of them. I think it takes a
bit more digging than it should, though. I certainly remember wrestling
a bit before figuring out that what I was looking at was actually an SOP
and not an "actual object".
Otherwise, what actual problems are you having with the SOPs? They
work most of the time; that's why there hasn't been a major push to
get rid of them.
Well, my main problem is testing-related; I agree that in the normal
course of events they don't get in the way much, but it feels like they
get in the way all the time when unit testing (but this is important to
us). Here's a very specific case, but seemed to be a general problem we
ran into with SOPs:
We use generic services modules; say we have services/user.py which
contains methods like createUser(), deleteUser(), etc. These services
are exposed via JSON-RPC or AMF gateways (often both), which are just
WSGI apps that we plug in as Pylons controllers. So, (for example) our
services.user module will probably be doing checks against
`pylons.session`. I want to be able to have my UserServiceTest.setUp()
method inject authentication information into `pylons.session` so that
tests in our service layer think we have a valid session (for example).
What we've found is that the `pylons.session` in our test case is not
the same as the `pylons.session` that the services.user service imports.
(Does that make sense? -- I may be misremembering something here.)
Thanks-
Hans
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
