[issue35671] reserved identifier violation
New submission from Markus Elfring : I would like to point out that identifiers like “__DYNAMIC_ANNOTATIONS_H__” and “_Py_memory_order” do not fit to the expected naming convention of the C++ language standard. https://www.securecoding.cert.org/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier Would you like to adjust your selection for unique names? * https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/dynamic_annotations.h#L56 * https://github.com/python/cpython/blob/130893debfd97c70e3a89d9ba49892f53e6b9d79/Include/internal/pycore_atomic.h#L36 -- components: Interpreter Core messages: 333105 nosy: elfring priority: normal severity: normal status: open title: reserved identifier violation type: security versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35671] reserved identifier violation
Markus Elfring added the comment: * How do you think about to reduce the tampering with the reserved name space in mentioned source code (and also in related components)? * Would you like to avoid that this software depends on undefined behaviour? -- ___ Python tracker <https://bugs.python.org/issue35671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
New submission from Markus Elfring: An interface for parameterised SQL statements (working with placeholders) is provided by the execute() method from the Cursor class at the moment. https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.execute I assume that the "SQL Statement Object" from the SQLite C interface is reused there already. http://sqlite.org/c3ref/stmt.html I imagine that it will be more efficient occasionally to offer also a base class like "prepared_statement" so that the parameter specification does not need to be parsed for every passed command. I suggest to improve corresponding preparation and compilation possibilities. -- components: Extension Modules messages: 231759 nosy: elfring priority: normal severity: normal status: open title: Improved support for prepared SQL statements ___ Python tracker <http://bugs.python.org/issue22956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22957] Multi-index Containers Library
New submission from Markus Elfring: I find a data structure like it is provided by the "Boost Multi-index Containers Library" interesting for efficient data processing. http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/index.html How are the chances to integrate a class library with similar functionality into the Python software infrastructure? -- components: Extension Modules messages: 231761 nosy: elfring priority: normal severity: normal status: open title: Multi-index Containers Library type: enhancement ___ Python tracker <http://bugs.python.org/issue22957> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
Changes by Markus Elfring : -- type: -> enhancement ___ Python tracker <http://bugs.python.org/issue22956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
Markus Elfring added the comment: Are you really against benefits from reusing of existing application programming interfaces for the explicit preparation and compilation of SQL statements? It seems that other software contributors like Marc-Andre Lemburg and Tony Locke show more constructive opinions. https://mail.python.org/pipermail/db-sig/2014-December/006133.html https://www.mail-archive.com/db-sig@python.org/msg01829.html http://article.gmane.org/gmane.comp.python.db/3784 -- resolution: rejected -> later ___ Python tracker <http://bugs.python.org/issue22956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
