Parameter checking on an interfase
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;)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Parameter checking on an interfase
On 9 mayo, 17:42, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] 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/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 -- http://mail.python.org/mailman/listinfo/python-list
Patch to pydoc (partial) to handle encodings other than ascii
Hello Pythonists:
I am using SPE as python IDE on Windows, with Python 2.5.1 installed
(official distro). As my mother tongue is Spanish, I had documented
some modules in it (I now, I should have documented all in English,
except if I were 110% sure than nobody else would read my docs, but
they are only for in-house use). When I tried to use the pydoc tab
that SPE attaches to every source file, I only found a message saying
that my accented text coud not be decoded.
Browsing the SPE's sources, I found that pydoc's HTMLDoc class could
not handle the non-ascii characters. Then patched the Doc's class (the
parent of HTMLDoc) code to look for the encoding declared in the
source of the module to document, and (in HTMLDoc) decode the source
with it. As the HTML file writer function used the same class and
choked when writing the file, reencoded the text with the same
encoding on writing.
As I could not find the mail of pydoc's maintainer (the source code
states that the autor is Ka-Ping Yee, but the original date is from
2001, and I could not find if he is still maintaining it), I want to
make this patch available so can be possible to use pydoc on non-ascii
sources (at least to generate programmatically HTML documentation). If
the solution is useful (please don't hesitate in criticize it), may be
can be incorporated on a future pydoc version.
I don't know how to make a patch file (I usually don't do co-op
programming, but use to code as a hobby), but of course I don't even
think of sending 90 k of code to the newsgroup, so I am sending the
modified code here, with the indication of where do the modifications:
After line 323, replace
if inspect.ismodule(object): return self.docmodule(*args)
with:
if inspect.ismodule(object):
remarks = inspect.getcomments(object)
start = remarks.find(' -*- coding: ') + 13
if start == 12:
start = remarks.find('# vim:fileencoding=') + 19
if start == 18:
if inspect.getsource(object)[:3] == '\xef\xbb\xbf':
self.encoding = 'utf_8'
else:
self.encoding = sys.getdefaultencoding()
else:
end = remarks.find(' ', start)
self.encoding = remarks[start:end]
else:
end = remarks.find('-*-', start)
self.encoding = remarks[start:end].strip()
return self.docmodule(*args)
After the line 421 (moved to 437 with the previous insert), insert
title = title.decode(self.encoding)
contents = contents.decode(self.encoding)
And finally replace line 1491 (now 1509):
file.write(page)
with:
file.write(page.encode(html.encoding))
The code don't solves the encoding issue on consoles (just try to
document utf-8 sources and see what funny things appears!), but if the
approach can help, may be something can be worked to use it in a
general way (I just don't know hoy to get the console encoding, and I
don't use consoles most of the time).
Hope that this can help to some other non-ascii user like me.
Cheers (and sorry for the english).
Walter Gardella
--
http://mail.python.org/mailman/listinfo/python-list
