On 04/28/2016 08:26 AM, Stefan Krah wrote:
Random832 writes:
A more relevant point would be that _decimal does *not* use the API in a
way *which would be broken by the proposed change*, regardless of
whether the way in which it uses it is subjectively correct or can cause
leaks.
And the ulti
Stefan, could you explain which module you are talking about and why it
would cost you a week? What is your responsibility here?
--Guido (mobile)
On Apr 28, 2016 8:28 AM, "Stefan Krah" wrote:
> Random832 fastmail.com> writes:
> > A more relevant point would be that _decimal does *not* use the A
Random832 fastmail.com> writes:
> A more relevant point would be that _decimal does *not* use the API in a
> way *which would be broken by the proposed change*, regardless of
> whether the way in which it uses it is subjectively correct or can cause
> leaks.
And the ultimate point is that I don't
Serhiy Storchaka gmail.com> writes:
> 2. Most code that use PyModule_AddObject() doesn't work as intended.
> Since the bahavior of PyModule_AddObject() contradicts the documentation
> and is contrintuitive, we can't blame authors in this.
>
> I don't say this is a high-impacting bug, I even agr
On Thu, Apr 28, 2016, at 10:11, Stefan Krah wrote:
> For actual users of Valgrind this is patently obvious and was
> pretty much the point of my post.
A more relevant point would be that _decimal does *not* use the API in a
way *which would be broken by the proposed change*, regardless of
whether
Random832 fastmail.com> writes:
> On Thu, Apr 28, 2016, at 05:05, Stefan Krah wrote:
> > $ valgrind --suppressions=Misc/valgrind-python.supp ./python -c "import
> > decimal"
> >
> > [...]
> > ==16945== LEAK SUMMARY:
> > ==16945==definitely lost: 0 bytes in 0 blocks
> > ^^
On 28.04.16 11:38, Stefan Krah wrote:
Serhiy Storchaka gmail.com> writes:
No impact except emitting a deprecation warning at build time. But we
can remove a deprecation warning and add it in future release if this is
annoying.
But are you sure, that your code uses PyModule_AddObject() correctl
On Thu, Apr 28, 2016, at 05:05, Stefan Krah wrote:
> $ valgrind --suppressions=Misc/valgrind-python.supp ./python -c "import
> decimal"
>
> [...]
> ==16945== LEAK SUMMARY:
> ==16945==definitely lost: 0 bytes in 0 blocks
>
Well, the obvious fla
Serhiy Storchaka gmail.com> writes:
> But are you sure, that your code uses PyModule_AddObject() correctly?
> Only two modules in the stdlib (_json and _tkinter) used it correctly.
> Other modules have bugs even in tries to use PyModule_AddObject()
> correctly for some operations.
For the list
Serhiy Storchaka gmail.com> writes:
> No impact except emitting a deprecation warning at build time. But we
> can remove a deprecation warning and add it in future release if this is
> annoying.
>
> But are you sure, that your code uses PyModule_AddObject() correctly?
> Only two modules in the
On 28.04.16 01:24, Case Van Horsen wrote:
On Wed, Apr 27, 2016 at 11:06 AM, Serhiy Storchaka wrote:
I think it is better to have relation with PyModule_AddIntConstant() etc
than with PyObject_SetAttrString.
My patch doesn't introduce new public function, but changes the behavior of
the old fun
On Wed, Apr 27, 2016 at 11:06 AM, Serhiy Storchaka wrote:
> I think it is better to have relation with PyModule_AddIntConstant() etc
> than with PyObject_SetAttrString.
>
> My patch doesn't introduce new public function, but changes the behavior of
> the old function. This needs minimal changes to
Hrvoje Niksic avl.com> writes:
> This inconsistency has caused bugs (or, more fairly, potential leaks)
> before, see http://bugs.python.org/issue1782
>
> Unfortunately, the suggested Python 3 change to PyModule_AddObject was
> not accepted.
First, these "leaks" only potentially show up when yo
On 27.04.16 16:08, Nick Coghlan wrote:
On 27 April 2016 at 17:14, Serhiy Storchaka wrote:
I think that we can resolve this issue by following steps:
1. Add a new function PyModule_AddObject2(), that steals a reference even on
failure.
I'd suggest a variant on this that more closely matches t
On 27.04.16 15:31, Hrvoje Niksic wrote:
On 04/27/2016 09:14 AM, Serhiy Storchaka wrote:
There are three functions (or at least three documented functions) in C
API that "steals" references: PyList_SetItem(), PyTuple_SetItem() and
PyModule_AddObject(). The first two "steals" references even on fa
On 27.04.16 10:14, Serhiy Storchaka wrote:
There are three functions (or at least three documented functions) in C
API that "steals" references: PyList_SetItem(), PyTuple_SetItem() and
PyModule_AddObject(). The first two "steals" references even on failure,
and this is well known behaviour. But P
On 27 April 2016 at 23:08, Nick Coghlan wrote:
> On 27 April 2016 at 17:14, Serhiy Storchaka wrote:
>> I think that we can resolve this issue by following steps:
>>
>> 1. Add a new function PyModule_AddObject2(), that steals a reference even on
>> failure.
>
> I'd suggest a variant on this that m
On 27 April 2016 at 17:14, Serhiy Storchaka wrote:
> I think that we can resolve this issue by following steps:
>
> 1. Add a new function PyModule_AddObject2(), that steals a reference even on
> failure.
I'd suggest a variant on this that more closely matches the
PyList_SetItem and PyTuple_SetIte
On 04/27/2016 09:14 AM, Serhiy Storchaka wrote:
There are three functions (or at least three documented functions) in C
API that "steals" references: PyList_SetItem(), PyTuple_SetItem() and
PyModule_AddObject(). The first two "steals" references even on failure,
and this is well known behaviour.
On Wed, Apr 27, 2016 at 10:14 AM, Serhiy Storchaka wrote:
> I think that we can resolve this issue by following steps:
>
> 1. Add a new function PyModule_AddObject2(), that steals a reference even on
> failure.
+1
It would be good to document PyModule_AddObject's current behavior in
3.5+ (alread
There are three functions (or at least three documented functions) in C
API that "steals" references: PyList_SetItem(), PyTuple_SetItem() and
PyModule_AddObject(). The first two "steals" references even on failure,
and this is well known behaviour. But PyModule_AddObject() "steals" a
reference
21 matches
Mail list logo