Enhancement request: move pyDAL to local import #234
Assignees
Comments
|
hm, but wouldn't that cause a fail if someone started slow and didn't use the sql functionality, but then did so? we would be banking on the idea that they know how to deal with an import error in Python. |
|
You can catch the failed import error and print guidance on how to proceed to stdout. |
|
... and I just learned a new one. This day already paid off, thanks! |
raphaelahrens
added a commit
to raphaelahrens/pytm
that referenced
this issue
Mar 13, 2024
In OWASP#234 @colesmj suggested to move the import of pydal into the sqlDumb function. This commit does this and if the import fails raises an UIError with an explanation on how to proceed. The text is just a first draft. To move the import the function get_table was also moved inside the sqlDump function.
raphaelahrens
added a commit
to raphaelahrens/pytm
that referenced
this issue
Mar 13, 2024
In OWASP#234 @colesmj suggested to move the import of pydal into the sqlDumb function. This commit does this and if the import fails raises an UIError with an explanation on how to proceed. The text is just a first draft. To move the import the function get_table was also moved inside the sqlDump function.
|
I think this can be closed now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
pyDAL is used for only 1 purpose within 1 function - pytm.py:1175
SQLDump()For readability and to reduce pre-installation requirements for likely most users, consider making the import of pyDAL currently on pytm.py:24 be local to
SQLDump(). This is allowed by Python and means if no one usesSQLDump()pyDAL is never loaded; otherwise it is a requirement and always loaded even if never used.The text was updated successfully, but these errors were encountered: