New submission from Marcel Plch :
Currently, there is not way to access per-module state from the methods of
types defined in extension modules.
This PEP provides a fix to this issue.
PEP 573 - https://www.python.org/dev/peps/pep-0573/
Reference implementation -
https://github.com
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +16655
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/17145
___
Python tracker
<https://bugs.python.org/issu
Marcel Plch added the comment:
Is currently anybody actively working on this? Please, report what you have
found out, if so.
I'd like to start digging into this tomorrow and possibly avoid any duplicit
work.
--
___
Python tracker
&
New submission from Marcel Plch :
Steps to reproduce:
$ wget https://www.python.org/ftp/python/3.9.0/Python-3.9.0a4.tar.xz
$ tar xvf Python-3.9.0a4.tar.xz
$ cd Python-3.9.0a4
$ ./configure --with-dtrace
$ make -j12
/usr/bin/ld: libpython3.9.a(ceval.o): in function `_PyEval_EvalFrameDefault
New submission from Marcel Plch :
Problem:
If you want to override CFLAGS by setting EXTRA_CFLAGS, they may have no effect
if there are contrary flags in the CFLAGS_NODIST variable.
How to reproduce:
make CFLAGS_NODIST="-O2" EXTRA_CFLAGS="-Og"
If you look at GCC arg
Marcel Plch added the comment:
I believe you mean this downstream issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1712977
That issue is but only a consequence of a bad flag handling.
The bad flag handling affects not only test_gdb on that specific architecture,
but the entire
Marcel Plch added the comment:
Sorry for not responding for so long, I didn't work on Python through the
summer because of some other matters.
Re-execution of the module is not possible, because there is a check on the C
level, If you call exec_in_module() on an already initialized m
Marcel Plch added the comment:
I have made a patch both for cython and cpython implementing a way to use
Py_mod_create in cython.
Basically module def that specifies a new "Py_mod_cython" slot are excluded
from the rule of no module creation, so these modules can be executed dire
Changes by Marcel Plch :
--
pull_requests: +1744
___
Python tracker
<http://bugs.python.org/issue30177>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Marcel Plch:
Currently the -m switch does not work with extension modules:
$ python3 -m math
/usr/bin/python3: No code object available for math
In order to enable extension modules to behave like Python source modules,
the -m switch should be supported
Changes by Marcel Plch :
--
pull_requests: +1845
___
Python tracker
<http://bugs.python.org/issue30403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Marcel Plch :
--
pull_requests: +1930
___
Python tracker
<http://bugs.python.org/issue19717>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +5888
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue29673>
___
___
Python-
Marcel Plch added the comment:
I have created a PR here - https://github.com/python/cpython/pull/6126
The problem was, indeed, change in the code structure. The macro checked for
presence inside of PyEval_EvalFrame() using address of a neighbouring function.
Also, arguments to
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +6441
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32962>
___
___
Python-
New submission from Marcel Plch :
PEP 489 introduced multiphase initialization of extension and built-in modules.
Now, almost no module in the standard library supports this feature. This
should be improved to prepare Python for better testing of subinterpreters.
Many benefits of PEP 489 don&#
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +4078
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31862>
___
___
Python-
New submission from Marcel Plch :
`Py_FinalizeEx()` only executes callbacks from the subinterpreter from which
Py_FinalizeEx is called.
What is the expected behavior here?
Should the callbacks be specific to individual subinterpreters?
--
components: Extension Modules
messages: 305233
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +4527
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31901>
___
___
Python-
Marcel Plch added the comment:
I created a PR with fix on this issue -
https://github.com/python/cpython/pull/4611
This makes Py_EndInterpreter() call atexit callbacks for the subinterpreter it
is destroying.
It doesn't make Py_Finalize() end all subinterpreters, as the cu
Marcel Plch added the comment:
> At a guess, the problem is because in atexit_callfuncs():
>
>module = PyState_FindModule(&atexitmodule);
>if (module == NULL)
>return;
In #31901, I solved this problem by getiing rid of PyState_FindModule in the
atexit code,
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +4821
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32374>
___
___
Python-
Change by Marcel Plch :
--
pull_requests: +4999
___
Python tracker
<https://bugs.python.org/issue32374>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marcel Plch added the comment:
I have created a PR at https://github.com/python/cpython/pull/5140
It contains documentation, plus, in --with-pydebug mode, it calls m_traverse to
catch easy cases of not handling the m_state==NULL case early
Change by Marcel Plch :
--
pull_requests: +6779
___
Python tracker
<https://bugs.python.org/issue32374>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marcel Plch added the comment:
LTO may break the debug symbols and make GDB unusable.
There is an option, that fixes the issue: to use a -g switch in link flags.
Note that this slows loading of the debug symbols significantly.
I suggest these options as possible approaches:
1) make the
Marcel Plch added the comment:
Yes, but that is not a fix really in this case.
While it makes the test pass because it 'correctly' prints out unknown objects,
it makes no real difference when actually debugging. The -g switch at link time
makes the debug symbols readable and user
Marcel Plch added the comment:
Those -g switches you see there are during compile-time.
For this to work, you need to enable it also during link/time:
./configure --enable-optimizations --with-lto LDFLAGS="-g"
Except for py-bt, you should also try bt. With this link flag enab
Change by Marcel Plch :
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue30345>
___
___
Python-bugs-list mailing list
Unsubscribe:
Marcel Plch added the comment:
The problem is with this function:
static PyObject *
builtin_id(PyModuleDef *self, PyObject *v)
/*[clinic end generated code: output=0aa640785f697f65 input=5a534136419631f4]*/
{
return PyLong_FromVoidPtr(v);
}
It's a one-liner, so the compiler really
Marcel Plch added the comment:
> It's already done, no? But the title issue is "-mcet -fcf-protection
> -O0" and -O0 disables optimizations.
Some of the simple tests are still run even with optimizations.
Disabled optimizations is what we want, because then the function
Marcel Plch added the comment:
I'm going to have a closer look at this and try to add the option.
--
nosy: +Dormouse759
___
Python tracker
<https://bugs.python.org/is
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +7805
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34097>
___
___
Py
Marcel Plch added the comment:
I have created a PR for this: https://github.com/python/cpython/pull/8270
--
___
Python tracker
<https://bugs.python.org/issue34
Marcel Plch added the comment:
It seems reasonable, I'll have a look at it.
--
___
Python tracker
<https://bugs.python.org/issue34097>
___
___
Python-bugs-l
Change by Marcel Plch :
--
keywords: +patch
pull_requests: +8151
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue34325>
___
___
Py
Change by Marcel Plch :
--
pull_requests: +8209
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue34097>
___
___
Python-bugs-lis
New submission from Marcel Plch :
TL;DR: For reproducer, please see attached file and the end of this description
for a runner script.
It seems that when pipe is being read it has a chance of returning EOF and not
setting the return code.
This bug affects all (or at least a broad set of
Marcel Plch added the comment:
original downstream issue - https://bugzilla.redhat.com/show_bug.cgi?id=1623070
--
title: pipe read sometimmes returns EOF but returncode is still None -> pipe
read sometimes returns EOF but returncode is still N
Change by Marcel Plch :
--
type: -> behavior
___
Python tracker
<https://bugs.python.org/issue34566>
___
___
Python-bugs-list mailing list
Unsubscrib
40 matches
Mail list logo
