In article <[email protected]>,
Victor Hooi <[email protected]> wrote:
> cur.executemany("INSERT INTO foobar_foobar_files VALUES (?)",
> [[os.path.relpath(filename, foobar_input_folder)] for
> filename in filenames])
I don't often write raw SQL embedded in Python. I'm much more likely to
use some sort of ORM layer. But, if I were doing this, I would break it
up something like:
There's a few different strategies I employed there. My first thought
was a logical break of computing the list of pathnames vs. inserting
them into the database. That got me here:
paths = [[os.path.relpath(filename, foobar_input_folder)] \
for filename in filenames]
cur.executemany("INSERT INTO foobar_foobar_files VALUES (?)",
paths)
I wouldn't have actually broken the first line with the backslash, but
I'm doing that to appease my news posting software.
My next step would be some simple textual changes; I'd get rid of the
overly-line variable names. In general, I don't like very short
variable names, but I'm OK with them as long as the scope is very small,
as it is here:
paths = [[os.path.relpath(fn, folder)] for fn in filenames]
cur.executemany("INSERT INTO foobar_foobar_files VALUES (?)",
paths)
I'd probably factor out the double lookup of os.path.relpath. I think
this is easier to read:
relpath = os.path.relpath
paths = [[relpath(fn, folder)] for fn in filenames]
cur.executemany("INSERT INTO foobar_foobar_files VALUES (?)",
paths)
If filenames was a very long list, it would also be a little bit faster
to execute, but that's such a small factor as to probably be
unmeasurable.
And, finally, I'd probably move one set of square brackets down into the
SQL statement. It really makes more sense there anyway; the bundling up
of the arguments into a sequence is more a part of the database API than
it is inherent to the data.
relpath = os.path.relpath
paths = [relpath(fn, foobar_input_folder) for fn in filenames]
cur.executemany("INSERT INTO foobar_foobar_files VALUES (?)",
[paths])
--
https://mail.python.org/mailman/listinfo/python-list
