From: Rimon B. <rim...@co...> - 2005-02-24 22:57:36
|
Ah, yes: On the meaning of None. Regarding Jonathan's point (two emails below), as to the output of None within [[= ]], I tend to agree that emitting an empty string is more convenient (option #3). This is equivalent to the way interactive Python interpretter handles output that is None, choosing to elide it. I think that we should make this change. It's a reasonable cosmetic output change, and I don't think anyone will be adversely affected. If anything, it's more convenient. Regarding Conan's point (below), I think we should leave the behaviour as is for the get(), get1(), post(), post1(), etc... methods, for a number of reasons: 1. I think that request.getpost1('var') == request.getpost1('var', None) which means return a default value of None, if 'var' does not exist. In other words, I view 'None' as a value, not as "no default". If not, how would you easily specify a default value of None. (It's often a pretty good value for a default.) 2. Exceptions are not a "Good Thing", in my opinion, when dealing with values from web. People are lazy. And, you don't want to rely on the value being ok, until much later when you don't know that it was user-provided. I think the checking should be in line. Moreover, we should add modules to easily (even automatically) check for invalid user input that could lead to cross-site scripting attacks, etc. 3. The documentation never claims dictionary-like behaviour. A single key can have multiple values, for example. If you really wish to generate an exception for a missing value, write the following: request.getpost1()['var'] 4. Finally, I think that it could break a lot of existing Spyce code by generating exceptions in new places. That said, Conan raises a valid point regarding the request.__getitem__, method ie. the request['var'] syntax. One could argue that it should have dictionary semantics, because it looks like a dictionary. That fact that it does not is well documented: http://spyce.sourceforge.net/doc-mod_request.html. But, we could change it if people feel strongly. I feel that exception semantics are too strong, for reasons explained in #2 above. And, we should consider the impact on existing users, ala #4 above. All the best, Rimon. On Thu, 24 Feb 2005, Conan Albrecht wrote: > Jonathan -- an interesting note. I've used request.getpost1('var', '') so > much I haven't thought much about it. An important note to me is that we're > already different than Python dicts. If we were the same then request['var'] > should throw a KeyError if not there. > > On Feb 24, 2005, at 2:34 PM, Jonathan Ellis wrote: > >> 1) Allow customization of the default value in request.get|post* in >> spyce.conf. Drawback: programatically the distinction between None and '' >> is often an important one. Also, excessive customizability is not a Good >> Thing. > Agree. Too much customization is bad. This is not important enough to be a > custom feature IMO. > >> 2) Allow specification of global transform filters in spyce.conf. Drawback: >> again, we don't want to overcomplicate things. > Agreed. > > >> 3) Change FilterUnify.writeExpr to special-case None. Drawback: python >> programmers know str(None) == 'None' and might be surprised. Still, this >> is easily documented, and manual response.write will still behave >> "normally." This makes the most sense to me ATM. > This is the best approach if we want to do something about it. It keeps the > special case to the printing code. This means that regular code can still > expect request['var'] to be None, not ''. > > I'm not bothered enough by this to make a special case anywhere for it. > However, if you and/or others feel strongly I'd be OK either way. > > |