>  On Sun, 2008-04-13 at 11:46 +0100, Tane Piper wrote:
>  [...]

> > What I want to
>  > know is there any way I could simplify the method and have it remove
>  > the password field any time a user object is being selected as part of
>  > a related query??

>  Not really, unless you use values(). For any model, if the Python object
>  is being constructed, it pulls back all the values it needs to populate
>  the attributes. The password hash is an attribute of the User model.

>  >  I'm sure there is a need for it when doing
>  > authorisation, but once a session has been confirmed, is it needed
>  > again?

>  Login isn't the only time when the password hash might be needed (for
>  example, it's displayed and editable in the admin screen) and it would
>  be quite hacky to introduce a special case for saying when that field
>  shouldn't be displayed. You're using the User object in public-readable
>  situations, which isn't really part of the design. So change your design
>  a bit so that you're not throwing around this information if you don't
>  want it displayed. Yes, anything can be serialised using json, but that
>  doesn't mean you should indiscriminately do so or that the framework
>  should accommodate that.

>  It might make sense in your situation to just pull back the values()
>  that you need for various objects and serialise that dictionary. Or you
>  could make another pass through the projects list and blank out the
>  attribute(s) you aren't interested in, such as _project_manager_cache.

>  Regards,
>  Malcolm

>  --
>  A clear conscience is usually the sign of a bad memory.
>  http://www.pointy-stick.com/blog/