[issue26540] Python Macros
New submission from Devyn Johnson: Would it be a good idea to add macros to Python? This would allow developers to test a condition (such as, "is this code running on Linux?" or "is this Python version 3.6?"). Then, the compiled bytecode will already contain the needed code, as opposed to testing the conditions during each execution. -- components: Interpreter Core messages: 261582 nosy: Devyn Johnson priority: normal severity: normal status: open title: Python Macros type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26411] Suggestion concerning compile-time warnings
New submission from Devyn Johnson: I understand that compile-time warnings can typically be ignored. However, from my experience with programming (C STD-2011, for instance), "weird bugs", non-easily-replicable bugs, and odd behaviors disappear when warnings like this are fixed. I also understand that it will be time-consuming to fix each and every minor warning. I have also noticed (in my own coding-projects) that fixing all warnings generated by -Wextra (and the many other warning flags) allows the compiler to more easily apply various optimizations. -- components: Interpreter Core messages: 260686 nosy: Devyn Johnson priority: normal severity: normal status: open title: Suggestion concerning compile-time warnings type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26411> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26410] "incompatible pointer type" while compiling Python3.5.1
New submission from Devyn Johnson: When compiling Python3.5.1 on Ubuntu 15.10 (64-bit), I see three "incompatible pointer type" warnings (copy-pasted below). I understand that they can be ignored. However, from my experience with programming (in C STD-2011), "weird bugs" and other odd behavior disappears when warnings like this are fixed. Environment flags (such as CFLAGS) and the configure settings do not appear to influence that warning (i.e. my settings are irrelevant to this bug report). I hope that this bug report is found to be helpful. Also, thank you Python-developers for making and maintaining Python as open-source software. Python/ceval_gil.h: In function drop_gil: Python/ceval_gil.h:181:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] _Py_atomic_store_relaxed(_last_holder, tstate); ^ Python/ceval_gil.h: In function take_gil: Python/ceval_gil.h:243:9: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] _Py_atomic_store_relaxed(_last_holder, tstate); ^ Python/pystate.c: In function PyThreadState_Swap: Python/pystate.c:509:5: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] _Py_atomic_store_relaxed(&_PyThreadState_Current, newts); -- components: Build messages: 260685 nosy: Devyn Johnson priority: normal severity: normal status: open title: "incompatible pointer type" while compiling Python3.5.1 type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26178] Python C-API: __all__ Creator
New submission from Devyn Johnson:
When creating Python modules via th C-API, it would be wonderful if there were
an easier and more efficient way of creating an "__all__" for the module. In my
opinion, an API function should be made; i.e., something like PyALL("FUNC1",
"FUNC2", ...)
Currently, I use something like the below code.
"""
PyObject *create_all(void);
PyObject *create_all(void) { // Create __all__
#define _ALLSTRING "[ss"
#define _ENDSTRING "]"
return Py_BuildValue(
_ALLSTRING
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
"sss"
#ifdef __BMI2__
""
#endif
#endif
_ENDSTRING,
// STRING CONVERSIONS
"lowercasestr",
"uppercasestr",
// FIND AND REPLACE/REMOVE
"strreplace",
"strreplace_once",
"rmgravequote",
// ASSEMBLY-RELATED COMMANDS
#if defined(ENV64BIT) && (defined(__x86_64__) || defined(__x86_64))
"rdtsc",
"get_vendor_id",
"get_cpu_stepping",
#ifdef __BMI2__
"is_fpu_aval",
"is_avx_aval",
"is_fma_aval",
"is_aes_aval",
#endif
#endif
"nop"
);
}
// Some code excluded
MODINIT { // Initialize module
PyObject *m;
m = PyModule_Create();
PyModule_AddObject(m, "__all__", create_all());
PyModule_AddStringConstant(m, "__author__", __author__);
PyModule_AddStringConstant(m, "__version__", __version__);
if (m == NULL)
return NULL;
return m;
}
"""
--
components: Interpreter Core
messages: 258804
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API: __all__ Creator
type: enhancement
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26178>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26178] Python C-API: __all__ Creator
Devyn Johnson added the comment: Thanks, @skrah and @haypo . I never thought of it that way. I made "__all__" in my extensions because "__all__" was used in many Python scripts. Thanks for the alternative perspective. -- status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26179] Python C-API "unused-parameter" warnings
New submission from Devyn Johnson:
When compiling Python C-API extensions with "-Wextra", warnings like
warning: unused parameter ‘self’ [-Wunused-parameter]
appear for code (like below). It seems like a minor issue for a warning to
appear when "PyObject *self, PyObject *args" is required. Is there an
underlying issue in the API?
static PyObject *mathfunc_ismersenneprime(PyObject *self, PyObject *args) {
sllint num;
ASSERT_LONGLONG_ARG(num);
if (num < (sllint)0) ERR_POSITIVE_INT;
returnbool(islonglongmersenneprime(num));
}
--
components: Interpreter Core
messages: 258809
nosy: Devyn Johnson
priority: normal
severity: normal
status: open
title: Python C-API "unused-parameter" warnings
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26179>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25903] SUGGESTION: Optimize code in PYO
New submission from Devyn Johnson: I have a suggestion. When Python code is byte-compiled to *.pyo files, what if byte-compiler were to be made to enhance some of the code. For instance, "if type(OBJECT) == int:" would be changed to "if isinstance(OBJECT, int):". Python is used in numerous software, so why not add a feature like this that could increase performance? -- messages: 256676 nosy: Devyn Johnson priority: normal severity: normal status: open title: SUGGESTION: Optimize code in PYO type: enhancement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25904] SUGGESTION: New Datatypes
New submission from Devyn Johnson: As we all know, Python is sometimes used to computer large numbers and precise numbers (i.e. doubles) with the help of third-party modules. In my opinion, it seems that Python may benefit from gaining new data-types such as "longint" (a "long long" in C) and "quad" (a "long double" in C). Thus, Python could natively be used for processing larger numbers than Python3.6. -- components: Interpreter Core messages: 256678 nosy: Devyn Johnson priority: normal severity: normal status: open title: SUGGESTION: New Datatypes type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25904> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
