>
> On Mar 17, 2005, at 12:19 PM, Mike Orr wrote:
>>
>> Grr, gratuitous accessor functions get my goat.  This is Python, not
>> Java.  We have properties in case an attribute setting needs
>> validation.  (Another reason to make all classes new-style...)
>> There's already quixote.get_user() if you reeeeally want to use a
>> function.  I thought .set_user() was a method because of the
>> significance it had for the application.
>>
>
> Wait a minute.  It is reasonable to thing that code accessing sessions,
> say to list them all, might want to access the user (in a way that could
> be specialized if necessary, by a subclass).  quixote.get_user() doesn't
> do that.
>
> And while properties are helpful in cases where you have no alternative,
> they seem to me to be gratuitous alternative syntax for method calls.
>
>> +0.5 for making Session dictionary-like though.  No reason to
>> arbitrarily limit its usability.
>
> So you want accessor, setter, and support for persistence, for
> information not
> needed by quixote and maybe not by an application.  I thought you
> didn't like
> gratuitous code. ;)

Not really.  I'm not advocating making Session dictionary-like.  I prob'ly
wouldn't use that feature anyway.  I'm just saying that if is support for
the change, it's a reasonable one.  (Where "reasonable" to me means
"useful in a wide variety of situations".)

What I am saying is, things that are attribute-like in nature I like to be
attributes.  There is wide agreement that a session.user attribute is
adequate for most known cases (username string, user object).  A scenario
where it wouldn't be, where the value *must* be calculated dynamically for
every access, doesn't even sound plausable.  Users don't arbitrarily
"morph" between accesses; they remain stable until they log out.  In the
*rare* event a user can't be adequately represented by an attribute, a
property in a Session subclass is a reasonable workaround.  The
alternative, requiring .get_user() and .set_user() for every access,
forces everybody to do an indirect workaround to cater to a paranoid doom
scenario that may never happen.

If we're talking about stripping Quixote to the bare essentials, why is
there a user object at all?  Quixote doesn't need it; it's just a
convenience for the application.

Regarding persistence, are you talking about one of my earlier e-mails?  I
would like to see Quixote come with "batteries included", yes.  How is
having persistence out of the box different from having a user object out
of the box?  It's something that no serious application can do without.
But since there's no "one size fits all" solution to persistence, why not
have several optional strategies to choose from or expand?  They could be
in a separate package, quixote.tools.persistence or
quixote.tools.session_managers, so they don't clutter the directory of
"essential" modules.  AMK wrote an excellent article (which I can't find
right now) on why the Python standard library should be expanded so people
have the "best of breed" implementations readily available and don't all
have to reinvent the wheel; I'd argue the same thing applies to Quixote.
Or they could be in a separate QuixoteExtras tarball.  Anything would be
better than having to hunt them down one by one or cut/paste them off the
wiki page.