Parameter checking on an interfase

Bruno Desthuilliers bdesth.quelquechose at free.quelquepart.fr
Wed May 9 16:42:16 EDT 2007


w.m.gardella.sambeth at gmail.com a écrit :
> Hi all,
>         I am more or less new to Python, and currently am making my
> first "serious" program. The application is a Clinical History manager
> (for my wife) which stores its data on a sqlite database. After
> googling on this newsgroup, I have read several threads where is
> stated that the LBYL way of testing parameters is not a pythonic way
> to work, and that is preferable catch the exceptions generated trying
> to use an invalid parameter passed to a function.
>         Although I am generally following this approach, the problem I
> see is that sqlite docs states clearly that the engine does not check
> that the data types passed to the SQL sentences matches the types
> declared for the column, and lets any kind of information to be put in
> any column of the table. When I code the "business objects" of the
> application (don't know if this is the exact term for a layer that
> will isolate the application from the raw database, letting me change
> it in a future if necessary),

business objects and databases are not necessarily related. And business 
objects are much more than a "database abstraction layer" - they are the 
"model" part of the MVC triad, and are the heart of your application's 
logic. As such, they are of course in charge of validating their own 
state wrt/ business rules.

> I realize that if I pass arguments of
> wrong type (say, a numeric ID instead of the patient name), the DB
> engine will accept that gladly, and I will finish with data that could
> not be consistently retrievable if I use the DB from another program
> (no one right now, but I think of, perhaps, statistical trends on
> diseases and treatments).
>         In this case, could be reasonable add type checking LBYL style
> on the methods, so if passed data is of wrong type, it generates a
> adequate exception to be catched by the caller? 

This is more a problem of validation/conversion of values than strictly 
a typing problem IMHO. As someone said : "be liberal about what you 
accept and strict about what you send".


> In this way, the rest
> of the app (mostly GUI) can be coded EAFP style. As programming
> background, as you can guess, I have made some programming in C, VBA
> and JavaScript (quite procedurally).
>         I hope that you can bring me some light about this kind of
> design, so I can improve my coding and get the Python way faster.

I strongly encourage you to have a look at SQLAlchemy (a hi-level 
RDBMS/python interface and an ORM) and Elixir (an ActiveRecord-like 
declarative layer on top of SQLAlchemy), and FormEncode (an in/out 
validation/conversion package).

http://www.sqlalchemy.org/
http://elixir.ematia.de/

FWIW, I'm actually working on using the second to add 
validation/conversion to the first:
http://groups.google.com/group/sqlelixir/browse_thread/thread/af7b2d0b87613482





More information about the Python-list mailing list