Namespaces/introspection: collecting sql strings for validation

[Martin Drautzburg]

I would like to validate sql strings, which are spread all over the
code, i.e. I run ("prepare") them against a database to see if it happy
with the statements. Spelling errors in sql have been a major pain for
me.

The statements will not be assembled from smaller pieces, but they will
not neccessarily be defined at module level. I could live with class
level, but method level would be best. And I definitely don't want to
parse the source file, but I am willing to mark the strings so it is
easier to tell sql from non-sql.

So the code will look like this

class Foo:(...):
def aQuery(...):
stmt = """
-- checkSql
select 1 from dual
"""
executeQuery()

at the end of the file I would like to write something like
if (...):
validateSql()

The validateSql() is the problem. It would be imported from elsewhere.
and has to do some serious magic. It would have to lookup its caller's
module, find all the classes (and methods, if we go that far) extract
the constants, check if any of them are an SQL statement and validate
it.

The problem is the first part: how can I lookup the callers module and
the classobjs defined in there? Or finding any constant strings in the
caller's module would also be just fine. Or is there a completely
different way to do such a thing?

[Alex Martelli]

Aahz <aa**@pythoncra ft.comwrote:

But don't put such black magic in production. The completely different
way is: just don't.

Could you expand on that? After all, that's exactly what we do to
implement a super() that works with classic classes -- and it's certainly
production code.

Personally, I'd much rather give up super (not a big loss) and classic
classes (a substantial net gain:-) than have to maintain such "black
magic" in a production environment. Explicit is better than implicit,
&c.
Alex

[Alex Martelli]

Martin Drautzburg <Ma************ ***@web.dewrote :

George Sakkis wrote:

Yes, there is: use an ORM to do the SQL generation for you. Check out
SQLAlchemy, it will buy you much more than what you asked for.

Might look, though in general I don't like OR mappers much. Having SQL
generated feels as strange as having python code generated. Too much
magic, too many layers. I think it is better to simply learn SQL.

Amen, brother; this opinion is definitely an outdated and minority one,
today, but I do tend to share it (and yet I'm programming in Django a
lot these days... ah well, consistency, hobgoblin, little minds, &c:-).
Alex

[Aahz]

In article <1h************ **************@ mac.com>,
Alex Martelli <al***@mac.comw rote:

>Aahz <aa**@pythoncra ft.comwrote:

>>Alex:

>>>
But don't put such black magic in production. The completely different
way is: just don't.

Could you expand on that? After all, that's exactly what we do to
implement a super() that works with classic classes -- and it's certainly
production code.

Personally, I'd much rather give up super (not a big loss) and classic
classes (a substantial net gain:-) than have to maintain such "black
magic" in a production environment. Explicit is better than implicit,
&c.

This application was started with Python 1.4. We still use Python 2.2,
which has some subtle but critical differences with the way new-style
classes are handled in 2.3+. Using super() makes our plugin model work;
otherwise, we'd have to switch to a non-cooperative mechanism for calling
plugin hooks. That would have some advantages, of course, but so much
code would need rewriting, and managing the calling of plugin hooks would
require creating an API registry.

The world is not always a simple place....
--
Aahz (aa**@pythoncra ft.com) <* http://www.pythoncraft.com/

"...string iteration isn't about treating strings as sequences of strings,
it's about treating strings as sequences of characters. The fact that
characters are also strings is the reason we have problems, but characters
are strings for other good reasons." --Aahz