[issue1509] Documentation lacking for the sqlite3 module.
New submission from Peter Mawhorter: The current documentation for the sqlite3 module on the web fails to make any mention of the fetch* functions posessed by the Cursor class of that module. It in fact gives no indication of how one should extract results from sql queries. The docstrings in the module (viewed using the help() function) are woefully incomplete, and are inconsistent with the function names: | fetchall(...) | Fetches one row from the resultset. | | fetchmany(...) | Fetches all rows from the resultset. | | fetchone(...) | Fetches several rows from the resultset. | Both of these things need to be fixed in order for this module to be useful for someone who doesn't already know how to use it. -- components: Extension Modules messages: 57900 nosy: pmawhorter severity: minor status: open title: Documentation lacking for the sqlite3 module. versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1509> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1509] Documentation lacking for the sqlite3 module.
Peter Mawhorter added the comment: I could try, but I honestly don't know exactly how the fetch* functions work. It would probably take me a good couple of hours of reading before I could write decent documentation, and as much as that would be great, I'm not about to squeeze that into my college schedule. I don't actually have a 2.5 checkout, but I thought that at one point those methods were documented. Is there a way to check the history of the online documentation and revert those pages? -Peter Mawhorter On 11/28/07, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Christian Heimes added the comment: > > Are you able to provide a patch? Please use a snapshot or svn checkout > of 2.5 for the patch. We have a new documentation system. > > -- > nosy: +tiran > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1509> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1509> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1509] Documentation lacking for the sqlite3 module.
Peter Mawhorter added the comment: Yes actually... the fetch documentation there is a sufficient explanation of the functions provided. If it could be added to docs.python.org, that would be great. There still remains the fact that the docstrings in the sqlite3 module don't agree with their function names, but that's a very minor issue, and wouldn't normally impact usability of the module. -Peter Mawhorter On 11/28/07, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote: > > Amaury Forgeot d'Arc added the comment: > > > I thought that at one point those methods were documented > > sqlite3 implements the DB-API: > http://www.python.org/dev/peps/pep-0249/ > is it the documentation you had in mind? > > -- > nosy: +amaury.forgeotdarc > > __ > Tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue1509> > __ > __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1509> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7286] odd exec() behavior or documentation
New submission from Peter Mawhorter : The behavior of the built-in exec() function differs in Python3.1 from the behavior in Python 2.6 when only a single argument is passed. Additionally, the documentation for the function does not suggest the behavior that it has. In Python2.6, an exec statement could both access and change the values of local variables. In Python3.1, it can read values from the local scope, but can't change them. Run the attached script to see examples of this behavior. Note especially that in the first function, the exec'd code changes the value of a variable called 'value'. However, the change isn't visible after the call to exec(), because the value changed was a local variable and presumably, the update is dropped after the exec() finishes. To me, this conflicts with the statement in the documentation that "In all cases, if the optional parts are omitted, the code is executed in the current scope." At the very least, a sentence or two should be added to the documentation explaining that exec() can't affect the value of local variables. In addition, it's strange that, for example, in a function declaring "global value", an exec() statement that modifies 'value' doesn't affect the value of the global variable. In this sense, the code being exec'd doesn't seem to be running in a perfect copy of the function's scope. If it were up to me, I'd allow code being executed by an exec() statement to modify the value of local variables, because that keeps with the paradigm of the exec'd code being simply dynamic code that behaves as if it were written in-line. It also means that programmers who need to change things with an exec statement aren't limited to pushing their changes through global variables, which can lead to conflicts with name sharing (for example, what if my exec() statement is in a recursive function?). Of course, implementing this may be difficult... so it may be better just to add to the documentation to explain this behavior of exec(). -- assignee: georg.brandl components: Documentation, Interpreter Core files: test.py messages: 95036 nosy: georg.brandl, pmawhorter severity: normal status: open title: odd exec() behavior or documentation type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file15289/test.py ___ Python tracker <http://bugs.python.org/issue7286> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
