[issue32325] C API should use 'const char *' instead of 'char *'
New submission from Stephen Kelly :
When using C++ to extend python, one may use PyGetSetDef for example:
static PyGetSetDef Noddy_getseters[] = {
{"first",
(getter)Noddy_getfirst, (setter)Noddy_setfirst,
"first name",
NULL},
{"last",
(getter)Noddy_getlast, (setter)Noddy_setlast,
"last name",
NULL},
{NULL} /* Sentinel */
};
However, in C++ implicit conversion from const char* to char* is deprecated
since C++98, and is a removed conversion in C++11.
https://godbolt.org/g/sswUKM
GCC/Clang warn about this, and MSVC in conformance mode (/permissive-) errors
on it.
PyGetSetDef and similar APIs should use const char* instead of char* for
members such as `name`.
--
components: Library (Lib)
messages: 308316
nosy: steveire
priority: normal
severity: normal
status: open
title: C API should use 'const char *' instead of 'char *'
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue32325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30060] Crash on Py_Finalize if Py_NoSiteFlag is used
New submission from Stephen Kelly:
When attempting to use PyImport_ImportModule("os") (or to import many other
libraries), there is a crash on Py_Finalize if Py_NoSiteFlag is set. The issue
appears to be the use of frozenset() as a result of importing the module.
I reproduced this on Windows after building 2.7.13 with VS 2015 by applying the
following patch:
Python changes.
--- Include\\fileobject.h
+++ Include\\fileobject.h
@@ -70,7 +70,7 @@
*/
int _PyFile_SanitizeMode(char *mode);
-#if defined _MSC_VER && _MSC_VER >= 1400
+#if defined _MSC_VER && _MSC_VER >= 1400 && _MSC_VER < 1900
/* A routine to check if a file descriptor is valid on Windows. Returns 0
* and sets errno to EBADF if it isn't. This is to avoid Assertions
* from various functions in the Windows CRT beginning with
--- Modules\\posixmodule.c
+++ Modules\\posixmodule.c
@@ -529,7 +529,7 @@
#endif
-#if defined _MSC_VER && _MSC_VER >= 1400
+#if defined _MSC_VER && _MSC_VER >= 1400 && _MSC_VER < 1900
/* Microsoft CRT in VS2005 and higher will verify that a filehandle is
* valid and raise an assertion if it isn't.
* Normally, an invalid fd is likely to be a C program error and therefore
--- Modules\\timemodule.c
+++ Modules\\timemodule.c
@@ -68,6 +70,9 @@
#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
/* Win32 has better clock replacement; we have our own version below. */
#undef HAVE_CLOCK
+#define timezone _timezone
+#define tzname _tzname
+#define daylight _daylight
#endif /* MS_WINDOWS && !defined(__BORLANDC__) */
#if defined(PYOS_OS2)
Backtrace:
KernelBase.dll!7ff963466142() Unknown
> python27_d.dll!Py_FatalError(const char * msg) Line 1700C
python27_d.dll!PyThreadState_Get() Line 332 C
python27_d.dll!set_dealloc(_setobject * so) Line 553C
python27_d.dll!_Py_Dealloc(_object * op) Line 2263 C
python27_d.dll!PySet_Fini() Line 1084 C
python27_d.dll!Py_Finalize() Line 526 C
mn.exe!main(int argc, char * * argv) Line 40C
[External Code]
Reproducing code:
#include
int main(int argc, char** argv)
{
// http://www.awasu.com/weblog/embedding-python/threads
// Comment this to avoid crash
Py_NoSiteFlag = 1;
Py_Initialize();
PyEval_InitThreads(); // nb: creates and locks the GIL
// NOTE: We save the current thread state, and restore
it when we unload,
// so that we can clean up properly.
PyThreadState* pMainThreadState = PyEval_SaveThread(); // nb: this also
releases the GIL
PyEval_AcquireLock(); // nb: get the GIL
PyThreadState* pThreadState = Py_NewInterpreter();
assert(pThreadState != NULL);
PyEval_ReleaseThread(pThreadState); // nb: this also releases the GIL
PyEval_AcquireThread(pThreadState);
// Can reproduce by importing the os module, but the issue actually appears
// because of the use of frozenset, so simplify to that.
#if 0
PyObject* osModule = PyImport_ImportModule("os");
Py_DECREF(osModule);
#endif
// As in abc.py ABCMeta class
PyRun_SimpleString("abstractmethods = frozenset(set())");
PyEval_ReleaseThread(pThreadState);
// release the interpreter
PyEval_AcquireThread(pThreadState); // nb: this also locks the GIL
Py_EndInterpreter(pThreadState);
PyEval_ReleaseLock(); // nb: release the GIL
// clean up
PyEval_RestoreThread(pMainThreadState); // nb: this also locks the GIL
Py_Finalize();
}
--
components: Interpreter Core
messages: 291568
nosy: steveire
priority: normal
severity: normal
status: open
title: Crash on Py_Finalize if Py_NoSiteFlag is used
type: crash
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue30060>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30060] Crash on Py_Finalize if Py_NoSiteFlag is used
Stephen Kelly added the comment:
I found that if I build and run this code with Python 3, then I get a very
different backtrace.
KernelBase.dll!7ff963466142() Unknown
python36_d.dll!Py_FatalError(const char * msg) Line 1457C
python36_d.dll!PyEval_AcquireLock() Line 253C
mn.exe!main(int argc, char * * argv) Line 22C
[External Code]
The failure is
Py_FatalError("PyEval_AcquireLock: current thread state is NULL");
So, it is not clear to me what is incorrect about this code, but presumably I
have done something incorrect here?
--
___
Python tracker
<http://bugs.python.org/issue30060>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30060] Crash on Py_Finalize if Py_NoSiteFlag is used
Stephen Kelly added the comment: The issue http://bugs.python.org/issue17978 has a quite similar backtrace and there is discussion in http://bugs.python.org/issue17703#msg241412 about changing the TRASHCAN macro to access the _PyThreadState_Current directly instead of calling PyThreadState_Get (which is fatal for a nullptr). The very next thing the TRASHCAN macro does is check if the thread state is nullptr in a non-fatal way. Is there a reason not to apply that patch? -- ___ Python tracker <http://bugs.python.org/issue30060> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30251] Windows Visual Studio solution does not have an install target
New submission from Stephen Kelly: The Windows Visual Studio solution does not have an install target. As far as I understand, the configure system used on Unix does have an install target. That means that on Windows, binaries resulting from the build to not end up in the same layout as result from using the official installer. Third party modules expect the same layout. For example, Sip/PyQt requires it https://www.riverbankcomputing.com/pipermail/pyqt/2017-April/039109.html . There are probably other modules similarly affected. I don't know what else an install target should do, but I note its absence. -- components: Build messages: 292872 nosy: steveire priority: normal severity: normal status: open title: Windows Visual Studio solution does not have an install target versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30252] Configuration system does not work for Windows/Visual Studio
New submission from Stephen Kelly: As far as I know, there is a configuration system for python based on the configure script. Python can be configured with --without-threads to disable threading support. There is no equivalent system for Windows/Visual Studio. This makes it harder to build python with configurations. -- components: Build messages: 292874 nosy: steveire priority: normal severity: normal status: open title: Configuration system does not work for Windows/Visual Studio versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30252> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30253] Python does not build without WITH_THREADS defined on Windows/Visual Studio
New submission from Stephen Kelly: As there is no configuration system for python on Windows (issue30252) I tried to change pyconfig.h to comment out some lines: // #define NT_THREADS // #define WITH_THREAD After building, I had to additionally patch * threadmodule.c and thread.c to exclude all content (I don't know if there is a way to exclude the file entirely with the Python build system - there should be something like that as part of a configure system). * Wrap uses of PyThread_get_thread_ident() in ifdefs in timemodule.c. This is surprising because I would expect it to not compile on any platform without the ifdefs. -- components: Build messages: 292879 nosy: steveire priority: normal severity: normal status: open title: Python does not build without WITH_THREADS defined on Windows/Visual Studio versions: Python 3.6 ___ Python tracker <http://bugs.python.org/issue30253> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
New submission from Stephen Kelly : There are several bugs on http://docs.python.org/library/datetime.html Section 8.1.6 references the method rzinfo.dst(), which does not exist. Presumably this should be tzinfo.dst(). Section 8.1.4 contains an implementation of a GMT2 timezone. There seems to be a bug in the utcoffset() and dst() implementations. The timedelta(hours=2) is in the dst() implementation, but it should be in the uctoffset() implementation. The docs for tzinfo.utcoffset() start with 'Return offset of local time from UTC, in minutes east of UTC'. Other methods (eg dst()) also document that the unit to return should be 'minutes'. However, all code samples instead return a timedelta. The documentation I quoted should instead read 'Return offset of local time from UTC as a timedelta, or None'. -- assignee: docs@python components: Documentation messages: 150272 nosy: docs@python, steveire priority: normal severity: normal status: open title: datetime documentation typos versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue13666> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly added the comment: Patch looks good to me. -- ___ Python tracker <http://bugs.python.org/issue13666> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13666] datetime documentation typos
Stephen Kelly added the comment: There are actually other bugs in the same code example: ... def __init__(self): # DST starts last Sunday in March ... d = datetime(dt.year, 4, 1) # ends last Sunday in October ... self.dston = d - timedelta(days=d.weekday() + 1) ... d = datetime(dt.year, 11, 1) ... self.dstoff = d - timedelta(days=d.weekday() + 1) where does dt come from? this fragment should be in the implementation of dst (in both the GMT1 and GMT2 classes. -- ___ Python tracker <http://bugs.python.org/issue13666> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30905] Embedding should have public API for interactive mode
New submission from Stephen Kelly:
Consider the following three snippets:
1)
const char* sourceCode =
"a = 9\n"
"a";
// This is OK! Python runs both lines.
// BUT: The value of 'a' is not printed
PyRun_StringFlags(sourceCode, Py_file_input, localDictionary, localDictionary,
0);
2)
// This is OK! We run one statement at a time:
PyRun_StringFlags("a = 9", Py_single_input, localDictionary, localDictionary,
0);
// Python prints the value of 'a' because we use Py_single_input!
PyRun_StringFlags("a", Py_single_input, localDictionary, localDictionary, 0);
3)
const char* sourceCode =
"a = 9\n"
"a";
// This is NOT OK! Python throws a SyntaxError because we used Py_single_input.
PyRun_StringFlags(sourceCode, Py_single_input, localDictionary,
localDictionary, 0);
The intention is to be able to run script code in an interpreter built into an
application, and to maintain two user features:
1) The behavior is the same as the standard python interpreter with regard to
printing values automatically without requiring the print() statement.
2) It is allowed to copy/paste possibly multiple lines/statements and execute
them
These two requirements are in conflict, because while Py_single_input enables
the first, it forbids the second.
I have worked around this by using internal API in Python-ast.h and setting
`mod->kind = Interactive_kind;` before calling `PyAST_CompileEx`, but that
should not be needed.
--
components: Interpreter Core
messages: 298162
nosy: steveire
priority: normal
severity: normal
status: open
title: Embedding should have public API for interactive mode
versions: Python 3.6
___
Python tracker
<http://bugs.python.org/issue30905>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30251] Windows Visual Studio solution does not have an install target
Stephen Kelly added the comment: This is resolved as not a bug. Is there a way to convert it to a feature request? -- ___ Python tracker <http://bugs.python.org/issue30251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34442] zlib module not built on windows
New submission from Stephen Kelly : I tried to build python 3.7.0 from source. I ran the PCBuild/build.bat script. That downloaded zlib to the external/ directory. However, it does not seem to be built. When running I get: python\3.7.0\lib\zipfile.py", line 646, in _check_compression "Compression requires the (missing) zlib module") RuntimeError: Compression requires the (missing) zlib module I examined PCBuild/pcbuild.proj. It makes no mention of zlib, though it mentions other externals. I notice that Python 3.6.1 contained zlib in Modules/zlib instead of coming from external/. Presumably that source was moved, but the Windows-related scripts were not updated. -- components: Extension Modules messages: 323791 nosy: steveire priority: normal severity: normal status: open title: zlib module not built on windows type: compile error versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34442> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
