From: D'Arcy J.M. Cain on
On Sat, 26 Jun 2010 12:04:38 +0100
Nobody <nobody(a)> wrote:
> Ask anyone with a surname like O'Neil, O'Connor, O'Leary, etc; they've
> probably broken a lot of web apps *without even trying*.

At least it isn't a problem with the first name field. Oh, wait...

D'Arcy J.M. Cain <darcy(a)> | Democracy is three wolves | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
From: Lawrence D'Oliveiro on
In message <mailman.2123.1277522976.32709.python-list(a)>, Tim Chase

> On 06/25/2010 07:49 PM, Lawrence D'Oliveiro wrote:
> ...

I see that you published my unobfuscated e-mail address on USENET for all to
see. I obfuscated it for a reason, to keep the spammers away. I'm assuming
this was a momentary lapse of judgement, for which I expect an apology.
Otherwise, it becomes grounds for an abuse complaint to your ISP.

From: Lawrence D'Oliveiro on
In message <mailman.2126.1277534032.32709.python-list(a)>, Ian Kelly

> Your example from the first post of the thread rewritten using sqlalchemy:
> conn.execute(
> items.update()
> .where(items.c.inventory_nr == modify_id)
> .values(
> dict(
> (field[0], Params.getvalue("%s[%s]" % (field[1],
> urllib.quote(modify_id))))
> for field in [
> (items.c.class_name, "modify_class"),
> (items.c.make, "modify_make"),
> (items.c.model, "modify_model"),
> (items.c.details, "modify_details"),
> (items.c.serial_nr, "modify_serial"),
> (items.c.inventory_nr, "modify_invent"),
> (items.c.when_purchased, "modify_when_purchased"),
> ... you get the idea ...
> (items.c.location_name, "modify_location"),
> (items.c.comment, "modify_comment"),
> ]
> )
> )
> .values(last_modified = time.time())
> )
> Doesn't seem any less flexible to me, plus you don't have to worry
> about calling your SQLString function at all.

Except I only needed two calls to SQLString, while you need two dozen
instances of that repetitive items.c boilerplate.

As a human, being repetitive is not my job. That's what the computer is for.
From: Lawrence D'Oliveiro on
In message <2010062522560231540-angrybaldguy(a)gmailcom>, Owen Jacobson wrote:

> It's not hard. It's just begging for a visit from the fuckup fairy.

That's the same fallacious argument I pointed out earlier.
From: Lawrence D'Oliveiro on
In message <pan.2010.>, Nobody wrote:

> On Sat, 26 Jun 2010 12:40:41 +1200, Lawrence D'Oliveiro wrote:
>>>> I construct ad-hoc queries all the time. It really isn't that hard to
>>>> do safely.
>>> Wrong.
>>> Even if you get the quoting absolutely correct (which is a very big
>>> "if"), you have to remember to perform it every time, without exception.
>>> More generally, as a program gets more complex, "this will work so long
>>> as we do X every time without fail" approaches "this won't work".
>> That's a content-free claim. Why? Because it applies equally to
>> everything. Replace “quoting” with something like “arithmetic”, and
>> you'll see what I mean:
> If you omit the arithmetic, the program is likely to fail in very
> obvious ways. Escaping is "almost" an identity function, which makes it
> far more likely that omission or repetition will go unnoticed.

Maybe you need to go back and reread my original posting. The SQLString
routine doesn't just escape special characters, it generates a full MySQL
string literal, complete with quotation marks. That makes it rather more
likely for a syntax error to occur if I forget to use it, don't you think?

>>> And you need to perform it exactly once. As the program gets more
>>> complex, ensuring that it's done in the correct place, and only there,
>>> gets harder.
>> Nonsense. It only needs to be done at the boundary to the appropriate
>> component (MySQL, HTML, JavaScript, whatever).
> That assumes that you have a well-defined "boundary", which isn't
> necessarily the case.

It's ALWAYS the case.

> In any case, you're still trying to make arguments about whether it's easy
> or hard to get it right, which completely misses the point. Eliminating
> the escaping entirely makes it impossible to get it wrong.

Except nobody has yet shown an alternative which is easier to get right.