Also, isn't there a difference between what's a legal Python identifier vs.
legal cookie name vs. legal form name...?
I suppose as the developer you mostly determine what those things are and
so can avoid that problem.
While this approach is interesting, it's a little too "gunky" to put
directly into WebKit for the reasons you already point out.
But as I pointed out, you can still do this for your own site.
Also, I'd like to see some Python language enhancements before I use what I
call "active attributes". These are possible with __getattr__ and
__setattr__, but use self.__dict__ gets awkward and a few language
provisions would make this programming style much cleaner (and possibly
There's actually a PEP for this, but I didn't care for its specifics very much.
At 03:06 PM 3/15/2001 -0600, Ian Bicking wrote:
>Chuck Esterbrook <echuck@...> wrote:
> > We chose to go with named accessor methods instead of . The explanation
> > for this is at:
> > However, if you still don't like our reasoning or API, you can still "Have
> > it your way.":
>I was unintentionally making my own framework for a while, before I
>realized that was dumb so I've been looking at Webware (though haven't
>had the time to really work with it yet).
>Anyway, the way I handled these I found very convenient, though some
>might consider it rather improper (and I might agree, even).
>Basically, it created both a dictionary and attribute interface. So,
>to access cookies you might do something like:
> or equivalently:
>Now, this does fold a few things together. request.cookie.get is a
>method, not the cookie by the name of "get". There's only a handful
>of these (get, keys, items, values, has_key), and if you want to
>access the cookies dynamically you would use the dictionary interface
>anyway, and would also avoid this problem.
>The class to implement this also looks kind of messy, since
>defining __setattr__ can do odd things (mostly, to initially set
>variables you have to use self.__dict__['attr'] = value).
>I like to think of cookie variables, field variables, and session
>variables as variables (most of the time), so this feels right to me.
>Making an object for each namespace/type of variable means that things
>are kept seperate, and it's easy to restrict or allow setting as
>appropriate (which isn't true when you have the objects returning
>normal dictionaries). It also allows the use of = and del,
>in addition to the dictionary methods, which I would argue is the
>Right Way to do setting, deleting, and interacting with namespaces
>(since it requires learning no new conventions).
>But then again, the biggest flaw is folding together namespaces with
>dictionaries. keys() works, dir() doesn't, has_key() works, hasattr()
>doesn't really (well, actually, I guess it would).
>4869 N. Talman Ave., Chicago, IL 60625