[issue36725] Reference leak regression with Python3.8a3

STINNER Victor added the comment: New changeset 3cde440f20a9db75fb2c4e65e8e4d04a53216a2d by Victor Stinner in branch 'master': bpo-36725: Refactor regrtest multiprocessing code (GH-12961) https://github.com/python/cpython/commit/3cde440f20a9db75fb2c4e65e8e4d04a53216a2d --

[issue36725] Reference leak regression with Python3.8a3

Change by STINNER Victor : -- pull_requests: +12887 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36725] Reference leak regression with Python3.8a3

STINNER Victor added the comment: New changeset 4d29983185bc12ca685a1eb3873bacb8a7b67416 by Victor Stinner in branch 'master': bpo-36725: regrtest: add TestResult type (GH-12960) https://github.com/python/cpython/commit/4d29983185bc12ca685a1eb3873bacb8a7b67416 --

[issue36725] Reference leak regression with Python3.8a3

Change by STINNER Victor : -- keywords: +patch pull_requests: +12886 stage: -> patch review ___ Python tracker ___ ___

[issue36725] Reference leak regression with Python3.8a3

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36725] Reference leak regression with Python3.8a3

New submission from Kay Hayen : Much like #9366 the same file can be used. This reference leaks according to Nuitka comparative testing: simpleFunction59: FAILED 129511 129512 leaked 1 def simpleFunction59(): a = 3 b = 5 try: a = a * 2 return a finally

[issue36643] Forward reference is not resolved by dataclasses.fields()

Change by Ivan Levkivskyi : -- nosy: +levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue20766] reference leaks in pdb

daniel hahler added the comment: Please see https://bugs.python.org/issue36667 for a followup. It does not look like moving it to `interaction` is relevant for fixing the leak, is it? I think it should be restored in both places. -- nosy: +blueyed

[issue36643] Forward reference is not resolved by dataclasses.fields()

Change by Karthikeyan Singaravelan : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36643] Forward reference is not resolved by dataclasses.fields()

New submission from Misha Drachuk : Forward reference is not resolved by `dataclasses.fields()`, but it works with `typing.get_type_hints()`. E.g. from dataclasses import dataclass, fields from typing import Optional, get_type_hints @dataclass class Nestable: child: Optional['Nestable

[issue19476] Add a dedicated specification for module "reloading" to the language reference

finds a concrete motivator for more detail about module-reloading in the language reference (or decide they want to drive this effort) then they can re-open this issue (or create a new one) at that point. -- resolution: -> rejected stage: needs patch -> resolved status: open -&g

[issue19476] Add a dedicated specification for module "reloading" to the language reference

Cheryl Sabella added the comment: Hi Eric, Is this still a concern since PEP 451 has been implemented for over 5 years now? Thanks! -- nosy: +cheryl.sabella -BreamoreBoy ___ Python tracker

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

STINNER Victor added the comment: New changeset 2368d86ed1249505b10561e005fc57f4884619c1 by Victor Stinner (Miss Islington (bot)) in branch '3.7': bpo-36565: Fix libregrtest for Python without builtin _abc (GH-12733) (GH-12734)

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

Change by miss-islington : -- pull_requests: +12657 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

STINNER Victor added the comment: New changeset 79b5d29041bd85ea3baa050b3fa2481344ea35c9 by Victor Stinner in branch 'master': bpo-36565: Fix libregrtest for Python without builtin _abc (GH-12733) https://github.com/python/cpython/commit/79b5d29041bd85ea3baa050b3fa2481344ea35c9 --

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

Change by STINNER Victor : -- keywords: +patch pull_requests: +12656 stage: -> patch review ___ Python tracker ___ ___

[issue36565] Reference hunting (python3 -m test -R 3:3) doesn't work if the _abc module is missing

ache, cls._abc_negative_cache, cls._abc_negative_cache_version) The first item tuple must be a set of weak references. Currently, it's a weak set of strong references. Attached PR fix the issue. -- components: Library (Lib) messages: 339661 nosy: vstinner priority: normal severity: normal

[issue36436] Potential null pointer de-reference vulnerability

Change by STINNER Victor : -- keywords: +patch pull_requests: +12505 stage: -> patch review ___ Python tracker ___ ___

[issue36436] Potential null pointer de-reference vulnerability

Karthikeyan Singaravelan added the comment: _testcapimodule.c is mostly imported as _testcapi in tests. I am not sure this is a security issue. -- nosy: +serhiy.storchaka, xtreak ___ Python tracker

[issue36436] Potential null pointer de-reference vulnerability

Change by SilentGhost : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36436] Potential null pointer de-reference vulnerability

New submission from wangjiangqiang <767563...@qq.com>: In Modules/_testcapimodule.c line 4186 and 4187. Allocated memory is used without null check. -- messages: 338875 nosy: wjq-security priority: normal severity: normal status: open title: Potential null pointer de-ref

[issue36430] A possible reference leak in itertools.count()

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue36430] A possible reference leak in itertools.count()

Raymond Hettinger added the comment: New changeset c0dce6aa2ce1ff408170bb8de2ebde3bfd8aa6cf by Raymond Hettinger (Miss Islington (bot)) in branch '2.7': bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551) (GH-12554) https://github.com/python/cpython/commit

[issue36430] A possible reference leak in itertools.count()

Change by miss-islington : -- pull_requests: +12501 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36430] A possible reference leak in itertools.count()

miss-islington added the comment: New changeset e0fe25be1ecbdf4abd1b0edd4aabacc4d75dec41 by Miss Islington (bot) in branch '3.7': bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551) https://github.com/python/cpython/commit/e0fe25be1ecbdf4abd1b0edd4aabacc4d75dec41

[issue36430] A possible reference leak in itertools.count()

Change by miss-islington : -- pull_requests: +12499 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36430] A possible reference leak in itertools.count()

Serhiy Storchaka added the comment: New changeset 0523c39e7720b82b38ad793d3f1a5681adcdf873 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551) https://github.com/python/cpython/commit

[issue36430] A possible reference leak in itertools.count()

Change by Zackery Spytz : -- keywords: +patch pull_requests: +12498 stage: -> patch review ___ Python tracker ___ ___

[issue36430] A possible reference leak in itertools.count()

New submission from Zackery Spytz : "long_step" is leaked in itertools_count_impl() if the type->tp_alloc() call fails. -- components: Extension Modules messages: 338853 nosy: ZackerySpytz priority: normal severity: normal status: open title: A possible r

[issue14189] Documentation for some C APIs is missing clear specification of the type of reference they return

Serhiy Storchaka added the comment: This may be fixed recently (see issue18085, issue32077, issue35475 etc). Just check that this is true for all reported functions. -- nosy: +serhiy.storchaka ___ Python tracker

[issue14189] Documentation for some C APIs is missing clear specification of the type of reference they return

Stéphane Wirtel added the comment: I would like to work on this issue. -- nosy: +matrixise versions: +Python 3.8 -Python 2.7 ___ Python tracker ___

[issue14189] Documentation for some C APIs is missing clear specification of the type of reference they return

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5739] Language reference is ambiguous regarding next() method lookup

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36270] DOC: Add link to sys.exc_info for "Reference Manual"

New submission from Cheryl Sabella : In the docs for `sys.exc_info()`, the description of traceback says: traceback gets a traceback object (see the ---> Reference Manual <---) which encapsulates the call stack at the point where the exception originally occurred. It might b

[issue36179] _hashopenssl has reference leaks in OOM case

miss-islington added the comment: New changeset 84b5ac9ba6fd71ba9d0ef98e2a166a35189b263f by Miss Islington (bot) (Christian Heimes) in branch '2.7': [2.7] bpo-36179: Fix ref leaks in _hashopenssl (GH-12158) (GH-12166)

[issue36179] _hashopenssl has reference leaks in OOM case

miss-islington added the comment: New changeset a59d33a1b08bd3dc9dc2584d4360ca81b0f1ad49 by Miss Islington (bot) in branch '3.7': bpo-36179: Fix ref leaks in _hashopenssl (GH-12158) https://github.com/python/cpython/commit/a59d33a1b08bd3dc9dc2584d4360ca81b0f1ad49 --

[issue36179] _hashopenssl has reference leaks in OOM case

Change by Christian Heimes : -- pull_requests: +12164 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36179] _hashopenssl has reference leaks in OOM case

Change by Christian Heimes : -- pull_requests: +12163 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36179] _hashopenssl has reference leaks in OOM case

Change by miss-islington : -- pull_requests: +12162 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36179] _hashopenssl has reference leaks in OOM case

miss-islington added the comment: New changeset b7bc283ab6a23ee98784400ebffe7fe410232a2e by Miss Islington (bot) (Christian Heimes) in branch 'master': bpo-36179: Fix ref leaks in _hashopenssl (GH-12158) https://github.com/python/cpython/commit/b7bc283ab6a23ee98784400ebffe7fe410232a2e

[issue36179] _hashopenssl has reference leaks in OOM case

Change by Karthikeyan Singaravelan : -- nosy: +cstratak ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36179] _hashopenssl has reference leaks in OOM case

Change by Christian Heimes : -- keywords: +patch pull_requests: +12156 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue36179] _hashopenssl has reference leaks in OOM case

New submission from Christian Heimes : Charalampos Stratakis from Red Hat's Python Maintenance Team found two minor reference leaks in _hashopenssl.c. Ref counts of newly allocated are not decreased when allocation of another object fails. -- assignee: christian.heimes components

Re: Lifetime of a local reference

Alan Bawden wrote: The Java compiler has no way to know whether a variable references an object with a finalize() method that has side effects It should be able to tell in some situations, e.g. String a = "hello"; String b = a.replace('e', 'u'); There's no way that b can

Re: Lifetime of a local reference

r...@zedat.fu-berlin.de (Stefan Ram) writes: > Alan Bawden writes: > >The Java compiler has no way to know whether a variable references an > >object with a finalize() method that has side effects > > java.lang.Object#finalize() is deprecated since Java 9. And we are advised to use a

Re: Lifetime of a local reference

On Fri, Mar 1, 2019 at 9:31 AM Marko Rauhamaa wrote: > > Roel Schroeven : > > In the absence of any other mention of bindings being removed, to me > > it seems clear that bindings are not automatically removed. Otherwise > > many things become ambiguous. Example: the documentation for dicts > >

Re: Lifetime of a local reference

Roel Schroeven : > In the absence of any other mention of bindings being removed, to me > it seems clear that bindings are not automatically removed. Otherwise > many things become ambiguous. Example: the documentation for dicts > defines "d[key] = value" as "Set d[key] to value". Does that mean

Re: Lifetime of a local reference

me to (https://docs.python.org/3/reference/datamodel.html#objects-values-and-types): "Objects are never explicitly destroyed; however, when they become unreachable they may be garbage-collected. An implementation is allowed to postpone garbage collection or omit it altogether — it is a m

Re: Lifetime of a local reference

Chris Angelico : > What if an exception gets raised at some point before the function has > returned? The exception object will give full access to the function's > locals. It wouldn't hurt for the Python gods to make an explicit ruling on the matter. Marko --

[issue36126] Reference count leakage in structseq_repr

Change by Serhiy Storchaka : -- resolution: -> fixed stage: -> resolved status: open -> closed type: behavior -> resource usage ___ Python tracker ___

[issue36126] Reference count leakage in structseq_repr

Serhiy Storchaka added the comment: New changeset 69b4a17f342146d6b7a73975a37678db9916aa75 by Serhiy Storchaka (Gao, Xiang) in branch '2.7': bpo-36126: Fix ref count leakage in structseq_repr. (GH-12035) https://github.com/python/cpython/commit/69b4a17f342146d6b7a73975a37678db9916aa75

Re: Lifetime of a local reference

t; goes out of scope. A quick search in the documentation points me to > > (https://docs.python.org/3/reference/datamodel.html#objects-values-and-types): > > > > > > "Objects are never explicitly destroyed; however, when they become > > unreachable they may be

Re: Lifetime of a local reference

On 27/02/2019 21:39, Roel Schroeven wrote: Rhodri James schreef op 27/02/2019 om 15:18: Aren't we overthinking this? I think it's pretty clear that a variable is never deleted before it goes out of scope. A quick search in the documentation points me to (https://docs.python.org/3/reference

Re: Lifetime of a local reference

; >object to be potentially reclaimable sooner. >> >> However, it only makes sense to do that if the compiler can be >> sure that reclaiming the object can't possibly have any side >> effects. That's certainly not true of things like file objects >> that refer

Re: Lifetime of a local reference

ble sooner. > > However, it only makes sense to do that if the compiler can be > sure that reclaiming the object can't possibly have any side > effects. That's certainly not true of things like file objects > that reference resources outside of the program. I'd be pretty > upset if a Java imp

Re: Lifetime of a local reference

Thomas Jollans wrote: If the inspect module's stack frame inspection machinery is supported, then any function call might access any local... (though I don't think a compliant Python implementation necessarily has to support the inspect module fully). You can be devious even without using the

Re: Lifetime of a local reference

have any side effects. That's certainly not true of things like file objects that reference resources outside of the program. I'd be pretty upset if a Java implementation prematurely closed my files on the basis of this clause. Similar considerations apply to Python. Even more so, because its

Re: Lifetime of a local reference

to > (https://docs.python.org/3/reference/datamodel.html#objects-values-and-types): > > > "Objects are never explicitly destroyed; however, when they become > unreachable they may be garbage-collected. An implementation is allowed > to postpone garbage collection or

Re: Lifetime of a local reference

lear that a variable is never deleted before it goes out of scope. A quick search in the documentation points me to (https://docs.python.org/3/reference/datamodel.html#objects-values-and-types): "Objects are never explicitly destroyed; however, when they become unreachable they

Re: Lifetime of a local reference

On 27/02/2019 16.41, Marko Rauhamaa wrote: > Rhodri James : >> The description of the with statement does explicitly say that the >> context manager's __exit__() method won't be called until the suite >> has been executed, so the reference to the open file must exist for

Re: Lifetime of a local reference

uot;) >> flock.flock(f, fcntl.LOCK_EX) >> do_stuff() >> sys.exit(0) > > I would go with: > > def fun(): > with open("lock") as f: > flock.flock(f, fcntl.LOCK_EX) > do_stuff() >

Re: Lifetime of a local reference

ould go with: def fun(): with open("lock") as f: flock.flock(f, fcntl.LOCK_EX) do_stuff() sys.exit(0) The description of the with statement does explicitly say that the context manager's __exit__() method won't be called until the suite has be

Re: Lifetime of a local reference

es > early. But I agree with you that the Python Language Reference does not > appear to address this question anywhere! > That's probably right. However, due to the nature of Python, things like this are possible: >>> v = 'a' >>> def f(): ... a, b, c = 1, 2, 3 ..

Re: Lifetime of a local reference

Just to add on regarding file I/O. It would be more pythonic to use. with open(path): do_stuff() On Wed, Feb 27, 2019, 3:31 AM Marko Rauhamaa wrote: > > Consider this function: > > def fun(): > f = open("lock") > flock.flock(f, fcntl.LOCK_EX) > do_stuff() >

Re: Lifetime of a local reference

ile documentation mentions a special mechanism to prevent premature garbage collection: https://www.gnu.org/software/guile/docs/docs-2.0/guile-ref/Rememb ering-During-Operations.html> > I suspect that given the history of Python, pretty much everybody has > always assumed that a Py

Re: Lifetime of a local reference

spect that given the history of Python, pretty much everybody has always assumed that a Python implementation will not delete local variables early. But I agree with you that the Python Language Reference does not appear to address this question anywhere! -- Alan Bawden -- https://mail.python.org/mailman/listinfo/python-list

Re: Lifetime of a local reference

On 2/26/19 3:54 PM, Marko Rauhamaa wrote: > Consider this function: > > def fun(): > f = open("lock") > flock.flock(f, fcntl.LOCK_EX) > do_stuff() > sys.exit(0) > > Question: can a compliant Python implementation close f (and, > consequently, release the file

Re: Lifetime of a local reference

On Wed, Feb 27, 2019 at 9:00 AM Marko Rauhamaa wrote: > Consider this function: > > def fun(): > f = open("lock") > flock.flock(f, fcntl.LOCK_EX) > do_stuff() > sys.exit(0) > > Question: can a compliant Python implementation close f (and, > consequently,

Lifetime of a local reference

Consider this function: def fun(): f = open("lock") flock.flock(f, fcntl.LOCK_EX) do_stuff() sys.exit(0) Question: can a compliant Python implementation close f (and, consequently, release the file lock) before/while do_stuff() is executed? I couldn't find

[issue36126] Reference count leakage in structseq_repr

New submission from zasdfgbnm : In Python 2.7 structseq is not a tuple, and in `structseq_repr` a tuple is created to help extracting items. However when the check at https://github.com/python/cpython/blob/2.7/Objects/structseq.c#L268 fails, the reference count of this tuple is not decreased

[issue23677] Mention dict and set comps in library reference

Cheryl Sabella added the comment: Assigning to @Mariatta for the CPython mentored sprint. -- assignee: docs@python -> Mariatta nosy: +Mariatta, cheryl.sabella stage: patch review -> needs patch versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6

[issue23677] Mention dict and set comps in library reference

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35577] side_effect mocked method lose reference to instance

Karthikeyan Singaravelan added the comment: Thanks for the report. I think this is design by choice that self is not passed to the side_effect directly set on the mock [0]. Changing this would break existing tests like [1] . You can use the approach by @remi.lapeyre which directly replaces

[issue35930] Raising an exception raised in a "future" instance will create reference cycles

c.DEBUG_SAVEALL) gc.collect() gc.garbage """ You will see (python 3.7) that 23 objects are collected when cleaning the cycle. The problem is the attribute "future._exception". If the exception provided by the "future" is raised somewhere else, we will have re

[issue35577] side_effect mocked method lose reference to instance

Rémi Lapeyre added the comment: Is there a problem with: from unittest import mock class SomeClass: def do_something(self, x): pass def some_function(x): obj = SomeClass() y = obj.do_something(x) return y def do_something_side_effect(self, x): print(self)

[issue35577] side_effect mocked method lose reference to instance

New submission from Adnan Umer : When a method/bounded function is mocked and side_effect is supplied to it, the side_effect function doesn't get the reference to the instance. Suppose we have something like this class SomeClass: def do_something(self, x): pass def

[issue35514] Docs on reference count detail. enhancement.

Change by Cheryl Sabella : -- keywords: +patch pull_requests: +10518 stage: -> patch review ___ Python tracker ___ ___

[issue35514] Docs on reference count detail. enhancement.

Change by Terry J. Reedy : -- nosy: +serhiy.storchaka __ Python tracker __ ___ Python-bugs-list mailing list

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

Ned Deily added the comment: New changeset 75f187478603de33c15f501a947207bfe8ba833f by Ned Deily (Miss Islington (bot)) in branch '3.6': bpo-35475: Add more PyImport* functions in refcounts.dat. (GH-11142) (GH-11199)

[issue35529] A reference counting bug in ctypes

Serhiy Storchaka added the comment: Thank you Zackery. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35529] A reference counting bug in ctypes

miss-islington added the comment: New changeset 3752bc96c0ea1ecf28903cc34cdcd75c658e92ce by Miss Islington (bot) in branch '2.7': bpo-35529: Fix a reference counting bug in PyCFuncPtr_FromDll(). (GH-11229) https://github.com/python/cpython/commit/3752bc96c0ea1ecf28903cc34cdcd75c658e92ce

[issue35529] A reference counting bug in ctypes

miss-islington added the comment: New changeset 4b6caaca41def86d80819f1f93c647918e98393f by Miss Islington (bot) in branch '3.7': bpo-35529: Fix a reference counting bug in PyCFuncPtr_FromDll(). (GH-11229) https://github.com/python/cpython/commit/4b6caaca41def86d80819f1f93c647918e98393f

[issue35529] A reference counting bug in ctypes

Change by miss-islington : -- pull_requests: +10492 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35529] A reference counting bug in ctypes

Serhiy Storchaka added the comment: New changeset d77d97c9a1f593fe161afab97e2a3e2292ab88b9 by Serhiy Storchaka (Zackery Spytz) in branch 'master': bpo-35529: Fix a reference counting bug in PyCFuncPtr_FromDll(). (GH-11229) https://github.com/python/cpython/commit

[issue35529] A reference counting bug in ctypes

Change by miss-islington : -- pull_requests: +10491 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

Serhiy Storchaka added the comment: Sorry, I forget about this issue and remembered it only after creating similar patch from scratch. PR 11247 is what left from it after merging your patch. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions:

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

miss-islington added the comment: New changeset 29d4e309b1b4dfb26d65d83c683002911c066dec by Miss Islington (bot) in branch '3.7': bpo-32077: Update refcounts.dat for Unicode object functions. (GH-11243) https://github.com/python/cpython/commit/29d4e309b1b4dfb26d65d83c683002911c066dec

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

Change by miss-islington : -- pull_requests: +10475 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

Change by miss-islington : -- pull_requests: +10474 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

Serhiy Storchaka added the comment: New changeset b2f642ccd2f65d2f3bf77bbaa103dd2bc2733734 by Serhiy Storchaka (Mat M) in branch 'master': bpo-32077: Update refcounts.dat for Unicode object functions. (GH-11243)

[issue32077] Documentation: Some Unicode object functions don't indicate whether they return a new reference

Change by Mathew M. : -- pull_requests: +10473 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

Change by Serhiy Storchaka : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue35529] A reference counting bug in ctypes

Change by Zackery Spytz : -- keywords: +patch pull_requests: +10464 stage: -> patch review ___ Python tracker ___ ___

[issue35529] A reference counting bug in ctypes

open title: A reference counting bug in ctypes type: behavior versions: Python 2.7, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35529> ___ ___ Python-bugs-l

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

miss-islington added the comment: New changeset 605ef6e534f05925ff826f65518abf163ed3900a by Miss Islington (bot) in branch '3.7': bpo-35475: Add more PyImport* functions in refcounts.dat. (GH-11142) https://github.com/python/cpython/commit/605ef6e534f05925ff826f65518abf163ed3900a

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

Change by miss-islington : -- pull_requests: +10438 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

Change by miss-islington : -- pull_requests: +10437 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35475] Docs do not show PyImport_AddModuleObject() returns a borrowed reference.

Serhiy Storchaka added the comment: New changeset bdabb0737c631835b246c9823852d20331243315 by Serhiy Storchaka in branch 'master': bpo-35475: Add more PyImport* functions in refcounts.dat. (GH-11142) https://github.com/python/cpython/commit/bdabb0737c631835b246c9823852d20331243315

[issue35514] Docs on reference count detail. enhancement.

New submission from bombs : https://docs.python.org/3/c-api/intro.html#reference-count-details When I read that section of the docs first time, I found it hard to grasp what transferring of ownership is, which is an important and repeating concept throughout the docs. Some explanations were

<    6   7   8   9   10   11   12   13   14   15   >