From: Lawrence D'Oliveiro on 28 Jun 2010 20:30
> Seriously, almost every other kind of library uses a binary API. What
> makes databases so special that they need a string-command based API?
HTML is also effectively a string-based API. And what about regular
expressions? And all the functionality available through the subprocess
module and its predecessors?
The reality is, embedding one language within another is a fact of life. I
think it's important for programmers to be able to deal correctly with it.
From: Peter H. Coffin on 28 Jun 2010 23:25
On Mon, 28 Jun 2010 03:07:29 -0700, Dennis Lee Bieber wrote:
> Coding for something like a DBTG network database did not allow for
> easy changes in queries... What would be a simple join in SQL was
> traversing a circular linked list in the DBTG database my college
> taught. EG: loop get next "master" record; loop get next sub-record
> [etc. until all needed data retrieved] until back to master; until back
> to top of database.
We'll also note that most of these you'd have to map out where each
field in a record was by hand, any time you wanted to open the file.
Often several times, because there would be multiple record layouts per
67. No matter how many shorts we have in the system, my guards will be
instructed to treat every surveillance camera malfunction as a
--Peter Anspach's list of things to do as an Evil Overlord
From: Nobody on 29 Jun 2010 05:35
On Tue, 29 Jun 2010 12:30:36 +1200, Lawrence D'Oliveiro wrote:
>> Seriously, almost every other kind of library uses a binary API. What
>> makes databases so special that they need a string-command based API?
> HTML is also effectively a string-based API.
HTML is a data format. The sane way to construct or manipulate HTML is via
the DOM, not string operations.
> And what about regular expressions?
What about them? As the saying goes:
Some people, when confronted with a problem, think
"I know, I'll use regular expressions."
Now they have two problems.
They have some uses, e.g. defining tokens. Using them to match more
complex constructs is error-prone and should generally be avoided unless
you're going to manually verify the result. Oh, and you should never
generate regexps dynamically; that way madness lies.
 Assuming that the language's tokens can be described by a regular
grammar. This isn't always the case, e.g. you can't tokenise PostScript
using regexps, as string literals can contain nested parentheses.
> And all the functionality available through the subprocess
> module and its predecessors?
The main reason why everyone recommends subprocess over its predecessors
is that it allows you to bypass the shell, which is one of the most
common sources of the type of error being discussed in this thread.
IOW, rather than having to construct a shell command which (hopefully)
will pass the desired arguments to the child, you just pass the desired
arguments to the child directly, without involving the shell.
> The reality is, embedding one language within another is a fact of life. I
> think it's important for programmers to be able to deal correctly with it.
That depends upon what you mean by "embedding". The correct way to use
code written in one language from code written in another is to make the
first accept parameters and make the second pass them, not to have the
second (try to) generate the former dynamically.
Sometimes dynamic code generation is inevitable (e.g. if you're writing a
compiler, you probably need to generate assembler or C code), but it's not
to be done lightly, and it's unwise to take shortcuts (e.g. ad-hoc string
From: Roy Smith on 29 Jun 2010 08:41
Nobody <nobody(a)nowhere.com> wrote:
> > And what about regular expressions?
> What about them? As the saying goes:
> Some people, when confronted with a problem, think
> "I know, I'll use regular expressions."
> Now they have two problems.
That's silly. RE is a good tool. Like all good tools, it is the right
tool for some jobs and the wrong tool for others.
I've noticed over the years a significant anti-RE sentiment in the
Python community. One reason, I suppose, is because Python gives you
some good string manipulation tools, i.e. split(), startswith(),
endswith(), and the 'in' operator, which cover many of the common RE use
cases. But there are still plenty of times when a RE is the best tool
and it's worth investing the effort to learn how to use them effectively.
One tool that Python gives you which makes RE a pleasure is raw strings.
Getting rid of all those extra backslashes really helps improve
Another great feature is VERBOSE. I've written some truly complicated
REs using that, and still been able to figure out what they meant the
next day :-)
From: Stephen Hansen on 29 Jun 2010 10:11
On 6/29/10 5:41 AM, Roy Smith wrote:
> Nobody<nobody(a)nowhere.com> wrote:
>>> And what about regular expressions?
>> What about them? As the saying goes:
>> Some people, when confronted with a problem, think
>> "I know, I'll use regular expressions."
>> Now they have two problems.
> That's silly. RE is a good tool. Like all good tools, it is the right
> tool for some jobs and the wrong tool for others.
There's nothing silly about it.
It is an exaggeration though: but it does represent a good thing to keep
Yes, re is a tool -- and a useful one at that. But its also a tool which
/seems/ like an omnitool capable of tackling everything.
Regular expressions are a complicated mini-language well suited towards
extensive use in a unix type environment where you want to embed certain
logic of 'what to operate on' into many different commands that aren't
languages at all -- and perl embraced it to make it perl's answer to
text problems. Which is fine.
In Python, certainly it has its uses: many of them in fact, and in many
it really is the best solution.
Its not just that its the right tool for some jobs and the wrong tool
for others, or that -- as you said also -- that Python provides a rather
rich string type which can do many common tasks natively and better, but
that regular expressions live in the front of the mind for so many
people coming to the language that its the first thing they even think
of, and what should be simple becomes difficult.
So people quote that proverb. Its a good proverb. As all proverbs, its
not perfectly applicable to all situations. But it does has an important
lesson to it: you should generally not consider re to be the solution
you're looking for until you are quite sure there's nothing else to
solve the same task.
It obviously applies less to the guru's who know all about regular
expressions and their subtleties including potential pathological behavior.
... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/