[DB-SIG] In praise of pyformat

Mike Meyer mwm-keyword-dbsig.588a7d at mired.org
Tue Aug 14 16:18:17 CEST 2007


On Mon, 13 Aug 2007 19:11:15 -0500 Carl Karsten <carl at personnelware.com> wrote:
> Mike Meyer wrote:
> > While I think your order is a little exaggerated, I'll merely point
> > out that it's a common thing to see when you're writing code that
> > writes code. SQL pretty much sucks for this, but Python isn't to bad -
> > and it's one of the most powerful programming technics available - I
> > seem to use it in every other application. So I'd expect it to become
> > more common, not less.
> about a million to one seems realistic to me.

In my experience, its more like every other application that needs
this.

> How often does an identifier come from an untrusted source?

Um, how about in every web-based app that has a real search facility?
One that lets the user specify which column(s) they want to check, or
that can search multiple tables? I seem to be involved in working on
one of those every few years: an SGML document search engine, a user
database search engine, a webmail client, a workflow management
system, and a software change tracking system are what I can recall
now.

> hmm... still seems million to one.  could be because I 
> have never heard of such a thing, and even have trouble imagining it, so to me 
> it is more like 100 to 0.

Um, SQL has no facility to do this kind of thing, and the python apis
in general have no support for it, so this sort of reminds me of a C
programmer saying that objects don't have any use.

Of course, technically you're both right. Anything I can do with
objects, I can do without them. And when I start looking at how to
make the identifies not come from an untrusted source, I can see ways
to do it. However, they all involve me doing lots of copy-n-paste
"development", or adding tables to deal with indirection to my queries
and presumably slowing them down - or both.

       <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.


More information about the DB-SIG mailing list