[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2019-09-13 - 2019-09-20) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7043 (+12) closed 42945 (+60) total 49988 (+72) Open issues with patches: 2796 Issues opened (53) == #27575: dict viewkeys intersection slow for large dicts https://bugs.python.org/issue27575 reopened by serhiy.storchaka #34820: binascii.c:1578:1: error: the control flow of function âbina https://bugs.python.org/issue34820 reopened by ned.deily #35696: remove unnecessary operation in long_compare() https://bugs.python.org/issue35696 reopened by vstinner #37812: Make implicit returns explicit in longobject.c (in CHECK_SMALL https://bugs.python.org/issue37812 reopened by vstinner #38117: Update to OpenSSL 1.1.1d, 1.1.0l, 1.0.2t https://bugs.python.org/issue38117 reopened by ned.deily #38166: ast identifies incorrect column for compound attribute lookups https://bugs.python.org/issue38166 opened by Justin McCann #38167: O_DIRECT read fails with 4K mmap buffer https://bugs.python.org/issue38167 opened by yoyoyopcp #38169: Increase Code Coverage for SharedMemory and ShareableListe https://bugs.python.org/issue38169 opened by vinay0410 #38172: Python 3.8 Segfult with Bandersnatch pytest Suite https://bugs.python.org/issue38172 opened by cooperlees #38174: Security vulnerability in bundled expat CVE-2019-15903 (fix av https://bugs.python.org/issue38174 opened by Uche Ogbuji #38180: Test pyexpat fails on Fedora 30 https://bugs.python.org/issue38180 opened by umoqnier #38182: test_asyncio: SubprocessMultiLoopWatcherTests.test_stdin_stdou https://bugs.python.org/issue38182 opened by vstinner #38184: [2.7] test_site: test_s_option() failed on AMD64 Fedora Rawhid https://bugs.python.org/issue38184 opened by vstinner #38186: Use FindFirstFile in ntpath.realpath() when access is denied https://bugs.python.org/issue38186 opened by steve.dower #38187: test.test_tools.test_c_analyzer fails in refleak mode https://bugs.python.org/issue38187 opened by pablogsal #38188: Incorrect Argument Order for Calls to _winapi.DuplicateHandle( https://bugs.python.org/issue38188 opened by m3rc1fulcameron #38190: regrtest: test suite completes but Tests Result is not display https://bugs.python.org/issue38190 opened by vstinner #38193: http.client should be "runnable" like http.server https://bugs.python.org/issue38193 opened by Will Boyce #38194: Consistently add exist_ok / missing_ok parameters to directory https://bugs.python.org/issue38194 opened by timhoffm #38195: A bug in the multiprocessing module https://bugs.python.org/issue38195 opened by eshkrig #38197: Meaning of tracebacklimit differs between sys.tracebacklimit a https://bugs.python.org/issue38197 opened by Carl.Friedrich.Bolz #38198: Attributes of pathlib classes are not indexed in Windows help https://bugs.python.org/issue38198 opened by francescor #38199: python3.8-config --ldflags must not generate -L/usr/lib64 https://bugs.python.org/issue38199 opened by vstinner #38200: Adding itertools.pairwise to the standard library? https://bugs.python.org/issue38200 opened by della #38202: A fatal error in test_dictviews https://bugs.python.org/issue38202 opened by ZackerySpytz #38203: regrtest fails to stop test_multiprocessing_spawn worker proce https://bugs.python.org/issue38203 opened by vstinner #38204: Cannot compile on RPi with optimizations https://bugs.python.org/issue38204 opened by DNSGeek #38205: Py_UNREACHABLE() no longer behaves as a function call https://bugs.python.org/issue38205 opened by vstinner #38206: Clarify that tp_dealloc must decref for heap allocated type https://bugs.python.org/issue38206 opened by ammar2 #38207: subprocess: On Windows, Popen.kill() + Popen.communicate() is https://bugs.python.org/issue38207 opened by vstinner #38208: Simplify string.Template by using __init_subclass__() https://bugs.python.org/issue38208 opened by serhiy.storchaka #38209: Simplify dataclasses.InitVar by using __class_getitem__() https://bugs.python.org/issue38209 opened by serhiy.storchaka #38210: Intersection of dict view with iterator returns empty set https://bugs.python.org/issue38210 opened by serhiy.storchaka #38211: clean up type_init() https://bugs.python.org/issue38211 opened by sir-sigurd #38212: test_multiprocessing_spawn: test_queue_feeder_donot_stop_onexc https://bugs.python.org/issue38212 opened by vstinner #38214: __reduce__ API specs for objects with __slots__ https://bugs.python.org/issue38214 opened by crusaderky #38215: Do not import modules in star-import when __all__ is not defin https://bugs.python.org/issue38215 opened by serhiy.storchaka #38216: Fix for issue30458 prevents crafting invalid requests https://bugs.python.org/issue38216 opened by jaraco #38217: argparse should support multiple types when nargs > 1 https:
[Python-Dev] When writing a PEP, please use the template from PEP 12
https://www.python.org/dev/peps/pep-0012/#suggested-sections This applies even to folks who have written a PEP before as that template gets updated on occasion. For instance, there's a new copyright notice and the last couple proposed PEPs didn't catch it because they copy and pasted from old PEPs instead of using the template. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GDXWHQ3CB5VSKR6UEF5LX532VLJOGEHC/
[Python-Dev] static variables in CPython - duplicated _Py_IDENTIFIERs?
I just ran an analysis of static variable definitions in CPython code, using clang, on Ubuntu and Windows. The results should be available here: https://cpython.red-dove.com/ As I understand it, _Py_IDENTIFIER instances are supposed to hold constant strings that are used in Python - e.g. "__class__", "__dict__" and so on. I noticed that there are numerous duplicates of these - e.g. 8 instances of __name__, 11 instances of __dict__, and so on - each instance is defined as static in its source file and so completely distinct from the others. I realise the overall amount of memory used by these structures isn't large, but is there any particular benefit to having these multiple copies? The current situation seems a little untidy, at least. What would be the disadvantage of making them extern in the headers and allocating them once in some consts.c module? After all, they seem for the most part to be well-known constant strings that don't need to be encapsulated in any particular C compilation unit. Regards, Vinay Sajip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GVQOMWXUDYLBXZ2MMIDX5D6X7X42VQV7/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
>From my understanding, _Py_IDENTIFIER was designed for static usage. The overhead is quite low; keeping it as a private (static) module-level internal variable helps to decouple things. This target is very important for keeping public API as small as possible. On Fri, Sep 20, 2019 at 10:32 PM Vinay Sajip via Python-Dev wrote: > > I just ran an analysis of static variable definitions in CPython code, using > clang, on Ubuntu and Windows. The results should be available here: > > https://cpython.red-dove.com/ > > As I understand it, _Py_IDENTIFIER instances are supposed to hold constant > strings that are used in Python - e.g. "__class__", "__dict__" and so on. I > noticed that there are numerous duplicates of these - e.g. 8 instances of > __name__, 11 instances of __dict__, and so on - each instance is defined as > static in its source file and so completely distinct from the others. > > I realise the overall amount of memory used by these structures isn't large, > but is there any particular benefit to having these multiple copies? The > current situation seems a little untidy, at least. What would be the > disadvantage of making them extern in the headers and allocating them once in > some consts.c module? After all, they seem for the most part to be well-known > constant strings that don't need to be encapsulated in any particular C > compilation unit. > > Regards, > > Vinay Sajip > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/GVQOMWXUDYLBXZ2MMIDX5D6X7X42VQV7/ -- Thanks, Andrew Svetlov ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/E24YQUYJMXC4LZXZEU7YELWIDDVWBDF3/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
20.09.19 22:19, Vinay Sajip via Python-Dev пише: I just ran an analysis of static variable definitions in CPython code, using clang, on Ubuntu and Windows. The results should be available here: https://cpython.red-dove.com/ As I understand it, _Py_IDENTIFIER instances are supposed to hold constant strings that are used in Python - e.g. "__class__", "__dict__" and so on. I noticed that there are numerous duplicates of these - e.g. 8 instances of __name__, 11 instances of __dict__, and so on - each instance is defined as static in its source file and so completely distinct from the others. Note that corresponding strings are interned, so all _Py_IDENTIFIER(__name__) share the same Python object. There is also the _PyArg_Parser structure which contains reference to the lazy initialized tuple of strings. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZYQBFVDXPAVVGSA6O4MXZ5ADAZU4Q37T/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
> From my understanding, _Py_IDENTIFIER was designed for static usage. > The overhead is quite low; keeping it as a private (static) > module-level internal variable helps to decouple things. I understand the importance of decoupling in general, but meanings of __name__, __dict__ etc. aren't going to change. What practical difficulties (in terms of coupling) do you foresee if e.g. all C modules know that somewhere there is a constant value representing the constant string "__dict__", and so on? There's no suggestion that some C modules will use a different constant string value to refer to e.g. the "__dict__" attribute than other C modules, is there? I'm not suggesting that all _Py_IDENTIFIERs need to be extern, just the ones whose meanings are public and can't be changed. I'm not coming from a worried-about-the-memory-overhead perspective - it's more about the manageability of ad hoc static variables which can be "considered harmful" in certain scenarios - such as sub-interpreters, for example. _Py_IDENTIFIER seems to account for a fair proportion of all static variable declarations. > This target is very important for keeping public API as small as possible. I'm not suggesting that _Py_IDENTIFIERs become part of the public API. Surely it's not the case that any and every extern identifier becomes part of the public API? (I know people can misuse things and use unsupported internal APIs, but then they're on their own, right?) Regards, Vinay Sajip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ZTLSGAHCKHLQK5BBKYHLEQGJHCU4OAFB/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
On Fri, Sep 20, 2019 at 1:00 PM Andrew Svetlov wrote: > This target is very important for keeping public API as small as possible. Right, I'm pretty sure that right now Python doesn't have any way to share symbols between .c files without also exposing them in the C API. This is fixable using "symbol visibility" features, and it would be nice to have the option to share stuff between our own C files without also sharing it with the world, for lots of reasons. But it might be necessary to implement that first before doing anything to share _Py_IDENTIFIERs. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V4Z6EYNZMNNJFU3KFKHKFE2KCB5L5DSP/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
> > Right, I'm pretty sure that right now Python doesn't have any way to > share symbols between .c files without also exposing them in the C > API. On other C projects I've worked on, the public API is expressed in one set of header files, and internal APIs that need to be exposed across modules are described in a different set of internal header files, and developers who incorrectly use internal APIs by including the internal headers could see breakage when the internals change ... excuse my naïveté, as I haven't done much at Python's C level - does this discipline/approach not apply to CPython? Regards, Vinay Sajip ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XI4Y4M7WBXSMPY2ZDMD6IQWBAOFR6WYE/
[Python-Dev] Re: static variables in CPython - duplicated _Py_IDENTIFIERs?
On Fri, Sep 20, 2019 at 2:58 PM Vinay Sajip via Python-Dev wrote: > > > > Right, I'm pretty sure that right now Python doesn't have any way to > > share symbols between .c files without also exposing them in the C > > API. > > On other C projects I've worked on, the public API is expressed in one set of > header files, and internal APIs that need to be exposed across modules are > described in a different set of internal header files, and developers who > incorrectly use internal APIs by including the internal headers could see > breakage when the internals change ... excuse my naïveté, as I haven't done > much at Python's C level - does this discipline/approach not apply to CPython? Visibility in C is complicated :-). The level I'm talking about is symbol visibility, which is determined by the linker, not by headers. If a symbol is exported, then even if you hide the headers, it's still part of the library ABI, can still collide with user symbols, can still by accessed by determined users, etc. It's still fixable, but it requires some newer tools like -fvisibility=hidden that work differently across different platforms, and so far no-one's done the work to sort out the details. -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GOQDPXFWEBQT7DDQKHHGHWZQMTOG2COI/
