Chris Morton added the comment:
Is this change in behavior considered to be by design or is this issue an
unintended consequence? It seems inconsistent that comprehensions have no
visibility of variable previously defined in the same scoping for this
particular use-case. Is there a way to
Chris Morton added the comment:
Hi Terry, The reason why your code does not reproduce the issue is because you
first execute the code in a global context which then puts the definition of c
in that context. Subsequent calling in the local context then works. If you
remove the first exec
Chris Morton added the comment:
Root cause appears to be indexing c with [] operator. Replacing len(c) with 4
produces the same error.
--
___
Python tracker
<https://bugs.python.org/issue43
Change by Chris Morton :
--
title: Py_AddPendingCall Function Never Called in 3.8, works in 3.6 ->
Py_AddPendingCall Inserted Function Never Called in 3.8, works in 3.6
___
Python tracker
<https://bugs.python.org/issu
Chris Morton added the comment:
I should add that Py_AddPendingCall returns 0 in both cases.
--
title: PyAddPendingCall Function Never Called in 3.8, works in 3.6 ->
Py_AddPendingCall Function Never Called in 3.8, works in 3.6
type: -> be
New submission from Chris Morton :
Building code on Mac OSX or Linux Ubuntu 16.04
#include
#include
#include
#include
// MacOSX build:
// g++ stop.cpp -I /include/pythonX.X -L /lib
-lpythonX.X -o stop
// Linuxe requires addtional linkage:
// -lpthread
void RunPythonScript
New submission from Chris Morton :
Compiling (Window 10, MSVS 16):
#include
int main(int argc, char* argv[])
{
const char* code = "c=[1,2,3,4]\nd={'list': [c[i] for i in
range(len(c))]}\nprint(d)\n";
Py_Initialize();
PyObject* pycode = Py_CompileString(cod
