open defaults

Maybe you have a Requirements Document that patiently explains your input fill shall only contain lowercase "a" .. "z" characters and newlines. I don't care. Eventually some maintenance engineer will trip over this, hard. Don't do it. Use bind variables, as the DB vendor intended. Do not attempt to merge this feature branch to main in its current state.

open() defaults

Maybe you have a Requirements Document that patiently explains your input file shall only contain lowercase "a" .. "z" characters and newlines. I don't care. Eventually some maintenance engineer will trip over this, hard. Don't do it. Use bind variables, as the DB vendor intended. Do not attempt to merge this feature branch to main in its current state.

So instead of evaluating set() just once, "at compile time" when the class is being parsed into bytecode, for N calls we evaluate set() N times, "at run time". And yes, I know, the Optional aspect is annoying and ugly, sorry about it, that's life.

nit: That's a curiously long way to write print(query, file=file).

What you definitely want to avoid is an ETL that does COMMIT after each INSERT. That will slow things down without offering any app-level benefits.

So instead of evaluating set() just once, "at compile time" when the class is being parsed into bytecode, for N calls we will evaluate set() N times, "at run time". And yes, I know, the Optional aspect is annoying and ugly, sorry about it, that's life.

nit: That's a curiously long way to write print(query, file=file). And when you feel the need to .format(), usually it's better to write an f-string: `f"{query}\n"

What you definitely want to avoid is an ETL that does COMMIT after each INSERT. That will slow things down without offering any app-level benefits. An auto-commit setting of True will sometimes arrange for more COMMITs than a code author intended.

nit: The 'r' mode is default and might be elided. If you're keen to tack on open options, you might consider , encoding='utf8'. Personally I wouldn't, but some folks assert it should always be specified for fear of the system default being Latin1 or some crazy thing. The systems I work on have a sensible unicode system default, so the concern seldom arises.

1. Write injection-free code, always.
2. Avoid mutable default parameters.
3. Think carefully about whether a class or method is truly so well-named, so self-explanatory, that it needs no docstring. (Sometimes we don't need one, but less often than you think.)
4. Gather mandatory parameter values up front.
5. Embrace Path.
6. Only write {get,set}ters for _private attributes.
7. Raise specific errors rather than generic Exception.

nit: The 'r' mode is default and might be elided. If you're keen to tack on open() options, you might consider , encoding='utf8'. Personally I wouldn't, but some folks assert it should always be specified for fear of the system default being Latin1 or some crazy thing. The systems I work on have a sensible unicode system default, so the concern seldom arises.

1. Write injection-free code, always.
2. Avoid mutable default parameters.
3. Think carefully about whether a class or method is truly so well-named, so self-explanatory, that it needs no docstring. (Sometimes we don't need one, but less often than you think.)
4. Gather mandatory parameter values up front.
5. Embrace Path.
6. Choose snake_case identifiers.
7. Only write {get,set}ters for _private attributes.
8. Raise specific errors rather than generic Exception.