Clement Rouault added the comment:
Hello,
As this issue may never be fixed for python3.6. I wanted to post a solution to
bypass the bug. It may be useful for the next person stumbling on this as I
have.
The __class__ closure is only created if a function use the word super(). This
closure
Clement Rouault added the comment:
Hello,
I have a Python2 project that relies heavily on ctypes and I cannot migrate
this project to Python3 due to this bug. (I target 3.6)
I have some experience with CPython and submitting patchs and I would like to
know what I can do to help moving this
New submission from Clement Rouault :
While playing with '_multiprocessing.PipeConnection' I found out that
instancing an object with a subtype of '_multiprocessing.PipeConnection' will
crash the interpreter when the object is deleted.
My guess is that some connection me
Clement Rouault added the comment:
Stated as you did, it makes sens. Should the change of return type be
acknowledged somewhere in the documentation ?
--
___
Python tracker
<http://bugs.python.org/issue23
Clement Rouault added the comment:
My comment was about the behavior of `winreg.QueryValueEx`. The current
behavior is:
>>> import winreg
>>> tstkey = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "TestKey")
>>> winreg.QueryValueEx(tstkey, "
Clement Rouault added the comment:
I would like to discuss the fact that this patch is a new feature.
In the current state, CPython handles the `REG_QWORD` type as an unkown type
and returns the raw registry value: a string of size 8.
In my opinion this behavior does not match the Windows
Clement Rouault added the comment:
Because `QWORD` is not defined in any file included by CPython. The main file
for basic sized type definition in Windows is:
basetsd.h: Type definitions for the basic sized types.
which contains the definition of `DWORD64`: `typedef unsigned __int64
Clement Rouault added the comment:
I also stumbled on this issue when playing with the winreg module.
I will try to make the discussion go forward by submitting a new patch.
I added a test and tried everything (test included on 3.5) on my own computer
(windows 8.1 64b)
There are two points that
Changes by Clement Rouault :
--
nosy: +hakril
___
Python tracker
<http://bugs.python.org/issue23026>
___
___
Python-bugs-list mailing list
Unsubscribe:
Clement Rouault added the comment:
After a few months, I am back to you on this issue.
What should be the next step of the process ?
--
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
Clement Rouault added the comment:
> > The call to PySequence_GetItem() may be expensive, and we have to drop
> > the result if an OverflowError is raised after the call.
> You do realize that this error will be very rare and therefore
> inconsequential.
The real question
Clement Rouault added the comment:
> Also, PY_SSIZE_T_MAX is a valid value to pass to PySequence_GetItem(), so it
> shouldn't be blocked unless necessary.
I agree with you, that's why my first path was checking at the next call if
it->it_index had overflowed. But then it
Clement Rouault added the comment:
Thanks for the comments.
I corrected the patch and updated the test. I also added a test that check the
behavior of setstate with negative indice.
Just one question:
> __setstate__ must implement the same check.
Why should __setstate__ check
Clement Rouault added the comment:
Here is a first try for a patch.
There are two points I am not sure about:
1) The message for the OverflowError: is that explicit enough ?
2) The behaviour of the iterator after the raise of OverflowError.
With this patch every call to `next(it)` where `it
New submission from Clement Rouault:
I found an interger overflow in the standard iterator object
(Objects/iterobject.c)
The `it_index` attribute used by the iterator is a `Py_ssize_t` but overflow is
never checked. So after the index `PY_SSIZE_T_MAX`, the iterator object will
ask for the
Clement Rouault added the comment:
Updated some docstrings in the new patch after the review comments.
Thanks kushou for the code review.
--
Added file: http://bugs.python.org/file35954/dis_generator3.patch
___
Python tracker
<http://bugs.python.
16 matches
Mail list logo