Parameter checking on an interfase

[w.m.gardella.sambeth]

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), 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? 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.
Cheers!
Walter Gardella
PS: Excuse me if my english is not good enough, but is not my mother
tongue (I'm argentinian), and if my computerish is flawed (I'm only
human)

 

[Alex Martelli]

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? In this way, the rest

As maybe one of the first popular authors to use LBYL and EAFP in this
sense, I think I should comment here. First, I don't agree with
SQLite's design decision to be typeless -- I believe types are important
in RDB's in a very different way to their limited importance in programs
(where Python's "duck typing almost everywhere" suits me just fine,
though some intermediate approach like Boo's might be even better).
Nevertheless, SQLite is a good job and I use it happily... when I
_don't_ particularly care for type issues.

When I _do_ care -- I go back to PostgreSQL. It may not be quite as
handy as SQLite, if you want a self-contained program to deploy as a
unit... but in just about all other respects, it's got huge advantages.
Do consider it -- it will do a better job protecting your data's
integrity (among which type-checking of specific fields is just a
beginning). For _valuable_ data, where integrity really matters, that's
really a big point. ((Oracle, IBM DB2, SAP/DB, Firefly, and no doubt
others, might be just as good as PostgreSQL... but I have a sweet spot
for the latter; for MySQL, even though I do have to use it sometimes for
work purposes, my sympathy on the other hand is pretty low indeed)).

If you decide PostgreSQL is not worth the bother, then I think that's a
good sign that you should avoid type-checking in your code anyway, as it
indicatres that SQLite's "typeless data" approach may be OK for you.


Alex

 

[Bruno Desthuilliers]

(e-mail address removed) 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

 

[w.m.gardella.sambeth]

(e-mail address removed) a écrit :




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.


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".


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/af7b2d0...

Hi all:
First of all I give Bruno many thanks for the definition of
business objects, because plugs a big hole on my concepts. And after
reading your messages, I reach to the conclussion that the best I can
do with my program is to unittest more (against my own dumbness) the
classes that will call the interfase, and take out all the type
checking code from the callees. And in the event that the program
could grow/evolve in something more serious, change the RDBMS to
another more fit to the task.
Thank you very much and May Entropy be benevolent with you.

Walter