Method signatures in example code

2 views
Skip to first unread message

Lloyd Kvam

unread,
Jan 31, 2006, 2:58:59 PM1/31/06
to cherry...@googlegroups.com
Perhaps it is just me, but I hate the way the example code fails to
reflect the way CherryPy actually calls methods.

def index(self, **responseMap):

is the "normal" index signature. If there are no parameters, then
responsemap will be an empty dict. I think it is a mistake to present
code that is brittle and will fail when the actual request differs from
the expected request.

Similarly the default signature is really

def default(self, *urlpath, **responseMap):

I realize the current examples may look less threatening by only
presenting the expected arguments, but I think it does a disservice to
gloss over issues that should not be ignored.

I am willing to work through the documentation and make corrections so
that the examples are more robust, but do not want to waste my time if
that is not wanted.


This is example #7 from my 2.0 installation.

def default(self, user):
# Here we react depending on the virtualPath -- the part of the
# path that could not be mapped to an object method. In a real
# application, we would probably do some database lookups here
# instead of the silly if/elif/else construct.
if user == 'remi':
out = "Remi Delon, CherryPy lead developer"
elif user == 'hendrik':
out = "Hendrik Mans, CherryPy co-developer & crazy German"
<snipped>

I'd rather see:

def default(self, user, *discard, **ignore):

and explain why discard and ignore should be included. It might even be
worth pointing out that no default value is needed for user because if
there were no path value for user, the index method will be called
rather than default.


Is the example code really the preferred way to write a CherryPy
application?

Robert Brewer

unread,
Feb 8, 2006, 3:30:49 AM2/8/06
to cherry...@googlegroups.com
Lloyd Kvam wrote:
> def index(self, **responseMap):
> is the "normal" index signature. If there are no
> parameters, then responsemap will be an empty dict.
> I think it is a mistake to present code that is
> brittle and will fail when the actual request
> differs from the expected request.

IMO that is exactly what you want to have happen--failure. Errors should not pass silently.

> Similarly the default signature is really
> def default(self, *urlpath, **responseMap):
>

> Is the example code really the preferred way to write
> a CherryPy application?

IMO, yes. In almost all of the cases where I've experienced errors due to extraneous arguments, it's been during my own development and testing. I can honestly say that I haven't had a single occurrence of extraneous-arg errors in production unless it pointed out a bug that needed fixing in my own app code. YMMV--maybe you're writing mashup apps that demand fuzzier interfaces.

Any other anecdotal opinions out there?


Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org

winmail.dat
Reply all
Reply to author
Forward
0 new messages