Mailman 3 November 2019 - Python-Dev

Dangerous default value for reuse_address in asyncio loop.create_datagram_endpoint()
by vaizki＠vaizki.fi 21 Nov '19

21 Nov '19

When creating UDP servers with asyncio's create_datagram_endpoint(), the default value for reuse_address = True, resulting in a dangerous (and currently incorrectly documented) situation. I have proposed changing the default value but understandably such a change for a core library function parameter is not to be taken lightly. Thus I put this up for discussion on the list. As background, when creating TCP servers on UNIX-like systems, it is almost boilerplate to set SO_REUSEADDR for all server sockets to make sure that a restarting server can immediately bind the socket again. Without the SO_REUSEADDR sockopt, the kernel will hold the addr:port in a TIME_WAIT state for a while, preventing reuse. Thus, when creating TCP servers with loop.create_server(), the parameter reuse_address has a very reasonable default value of True. However things are very different in UDP-land. The kernel does not hold UDP server ports in a waiting state so the SO_REUSEADDR sockopt was repurposed in Linux (and *BSD afaik) to allow multiple processes to bind the SAME addr:port for a UDP server. The kernel will then feed incoming UDP packets to all such processes in a semi-fair-roundrobin manner. This is very useful in some scenarios, for example I've used it myself in C++ projects to allow UDP servers to be scaled easily and rolling upgrades to be implemented without separate load-balancing. But for this to be the default behaviour is quite dangerous. I discovered this default behaviour accidentally by having 2 separate Python programs (both doing SIP over UDP) accidentally configured to use the same UDP port. The result was that my 2 processes were indeed "sharing the load" - neither of them threw an exception at startup about the port being already in use and both started getting ~half of the incoming packets. So off to the docs I went and discovered that the documentation for create_datagram_endpoint() does not mention this behaviour at all, instead it mistakenly refers to the TCP protocol use of SO_REUSEADDR: "reuse_address tells the kernel to reuse a local socket in TIME_WAIT state, without waiting for its natural timeout to expire. If not specified will automatically be set to True on Unix." https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.creat… What makes this default especially dangerous is, - Most people are not aware of this special mode that Linux allows for UDP sockets - Even if it was documented to be the default, many people would miss it unless a big warning was slapped on the docs - The problems are unlikely to appear in test scenarios and much more likely to pop up in production months or years after rolling out the code - If you have never used it on purpose, it is very confusing to debug, causing you to doubt your own and the kernel's sanity - The behaviour changes again if you happen to use a multicast address... Thus, my proposal is to change the default value for UDP to False or deprecate the function and introduce a new one as suggested by Yuri in my original bug report at: https://bugs.python.org/issue37228

3 2

Exposing Tools/parser/unparse.py in the stdlib?
by Pablo Galindo Salgado 21 Nov '19

21 Nov '19

Hi, What do people feel about exposing Tools/parser/unparse.py in the standard library? Here is my initial rationale: * The tool already needs to be maintained and updated as is tested as part of the test suite. * I have used the tool almost all the time I needed to deal with AST transformations. * The public interface will have a very low surface API, keeping maintaining it (the public interface) a very small burden IMHO. We could add the public interface to the ast.py module or a new one if people feel strongly about it. Does anyone feel strongly against this or have any objection that I am not contemplating? Regards from rainy London, Pablo Galindo Salgado

9 13

[RELEASE] Python 3.9.0a1 available for testing
by Łukasz Langa 21 Nov '19

21 Nov '19

Go get it here: https://www.python.org/downloads/release/python-390a1/ <https://www.python.org/downloads/release/python-390a1/> This is an early developer preview of Python 3.9 Python 3.9 is still in development. This releasee, 3.9.0a1 is the first of six planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2020-05-18) and, if necessary, may be modified or deleted up until the release candidate phase (2020-08-10). Please keep in mind that this is a preview release and its use is not recommended for production environments. Major new features of the 3.9 series, compared to 3.8 Many new features for Python 3.9 are still being planned and written. Among the new major new features and changes so far: PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. (Hey, fellow core developer, if a feature you find important is missing from this list, let Łukasz know <mailto:lukasz@python.org>.) The next pre-release of Python 3.9 will be 3.9.0a2, currently scheduled for 2019-12-16. - Ł

2 2

thes mapping data type and thescfg cfg file module - review and suggestion request
by Dave Cinege 19 Nov '19

19 Nov '19

If you are not aware: - Thesaurus is a mapping data type with recursive keypath map and attribute aliasing. It is a subclass of dict() and is mostly compatible as a general use dictionary replacement. - ThesaurusExtended is a subclass of Thesaurus providing additional usability methods such as recursive key and value searching. - ThesaurusCfg is a subclass of ThesaurusExtended providing a nested key configuration file parser and per key data coercion methods. The README.rsl will give a better idea: https://git.cinege.com/thesaurus/ After 7 years I might have reached the point of 'interesting' with my Thesaurus and ThesaurusCfg modules. To anyone that is overly bored, I'd appreciate your terse review and comments on how mundane and worthless they still actually are. :-) I'm primarily interested in suggestions to what I've done conceptually here. While I'm not completely ashamed of the state of the Thesaurus code, ThesaurusCfg is not far beyond the original few hours I slapped it together one day in frustration. After considering suggestions I intend to make changes towards a formal release. Thanks in advance, Dave

4 7

Pass the Python thread state to internal C functions
by Victor Stinner 19 Nov '19

19 Nov '19

Hi, Are you ok to modify internal C functions to pass explicitly tstate? -- I started to modify internal C functions to pass explicitly "tstate" when calling C functions: the Python thread state (PyThreadState). Example of C code (after my changes): if (_Py_EnterRecursiveCall(tstate, " while calling a Python object")) { return NULL; } PyObject *result = (*call)(callable, args, kwargs); _Py_LeaveRecursiveCall(tstate); return _Py_CheckFunctionResult(tstate, callable, result, NULL); In Python 3.8, the tstate is implicit: if (Py_EnterRecursiveCall(" while calling a Python object")) { return NULL; } PyObject *result = (*call)(callable, args, kwargs); Py_LeaveRecursiveCall(); return _Py_CheckFunctionResult(callable, result, NULL); There are different reasons to pass explicitly tstate, but my main motivation is to rework Python code base to move away from implicit global states to states passed explicitly, to implement the PEP 554 "Multiple Interpreters in the Stdlib". In short, the final goal is to run multiple isolated Python interpreters in the same process: run pure Python code on multiple CPUs in parallel with a single process (whereas multiprocessing runs multiple processes). Currently, subinterpreters are a hack: they still share a lot of things, the code base is not ready to implement isolated interpreters with one "GIL" (interpreter lock) per interpreter, and to run multiple interpreters in parallel. Many _PyRuntimeState fields (the global _PyRuntime variable) should be moved to PyInterpreterState (or maybe PyThreadState): per interpreter. Another simpler but more annoying example are Py_None and Py_True singletons which are globals. We cannot share these singletons between interpreters because updating their reference counter would be a performance bottleneck. If we put a "superglobal-GIL" to ensure that Py_None reference counter remains consistent, it would basically "serialize" all threads, rather than running them in parallel. The idea of passing tstate to internal C functions is to prepare code to get the per-interpreter None from tstate. tstate is basically the "root" to access all states which are per interpreter. For example, PyInterpreterState can be read from tstate->interp. Right now, tstate is only passed to a few functions, but you should expect to see it passed to way more functions later, once more structures will be moved to PyInterpreterState. -- On my latest merged PR 17052 ("Add _PyObject_VectorcallTstate()"), Mark Shannon wrote: "I don't see how this could ever be faster, nor do I see how it is more correct." https://github.com/python/cpython/pull/17052#issuecomment-552538438 Currently, tstate is get using these internal APIs: #define _PyRuntimeState_GetThreadState(runtime) \ ((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current)) #define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime) or using public APIs: PyAPI_FUNC(PyThreadState *) PyThreadState_Get(void); #define PyThreadState_GET() PyThreadState_Get() I dislike _PyThreadState_GET() for 2 reasons: * it relies on the _PyRuntime global variable: I would prefer to avoid global variables * it uses an atomic operation which can become a perofrmance issue when more and more code will require tstate -- An alternative would be to use PyGILState_GetThisThreadState() which uses a thread local state (TLS) variable to get the Python thread state ("tstate"), rather that _PyRuntime atomic variable. Except that the PyGILState API doesn't support subinterpreters yet :-( https://bugs.python.org/issue15751 "Support subinterpreters in the GIL state API" is open since 2012. Note: While the GIL is released, _PyThreadState_GET() is NULL, whereas PyGILState_GetThisThreadState() is non-NULL. -- Links: * https://pythoncapi.readthedocs.io/runtime.html : my notes on moving globals to per interpreter states * https://bugs.python.org/issue36710 * https://bugs.python.org/issue38644 Victor -- Night gathers, and now my watch begins. It shall not end until my death.

13 24

Dangerous default value for reuse_address in asyncio loop.create_datagram_endpoint()
by Jukka Vaisanen 19 Nov '19

19 Nov '19

When creating UDP servers with asyncio's create_datagram_endpoint(), the default value for reuse_address = True, resulting in a dangerous (and currently incorrectly documented) situation. I have proposed changing the default value but understandably such a change for a core library function parameter is not to be taken lightly. Thus I put this up for discussion on the list. As background, when creating TCP servers on UNIX-like systems, it is almost boilerplate to set SO_REUSEADDR for all server sockets to make sure that a restarting server can immediately bind the socket again. Without the SO_REUSEADDR sockopt, the kernel will hold the addr:port in a TIME_WAIT state for a while, preventing reuse. Thus, when creating TCP servers with loop.create_server(), the parameter reuse_address has a very reasonable default value of True. However things are very different in UDP-land. The kernel does not hold UDP server ports in a waiting state so the SO_REUSEADDR sockopt was repurposed in Linux (and *BSD afaik) to allow multiple processes to bind the SAME addr:port for a UDP server. The kernel will then feed incoming UDP packets to all such processes in a semi-fair-roundrobin manner. This is very useful in some scenarios, for example I've used it myself in C++ projects to allow UDP servers to be scaled easily and rolling upgrades to be implemented without separate load-balancing. But for this to be the default behaviour is quite dangerous. I discovered this default behaviour accidentally by having 2 separate Python programs (both doing SIP over UDP) accidentally configured to use the same UDP port. The result was that my 2 processes were indeed "sharing the load" - neither of them threw an exception at startup about the port being already in use and both started getting ~half of the incoming packets. So off to the docs I went and discovered that the documentation for create_datagram_endpoint() does not mention this behaviour at all, instead it mistakenly refers to the TCP protocol use of SO_REUSEADDR: "reuse_address tells the kernel to reuse a local socket in TIME_WAIT state, without waiting for its natural timeout to expire. If not specified will automatically be set to True on Unix." https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.creat… What makes this default especially dangerous is, - Most people are not aware of this special mode that Linux allows for UDP sockets - Even if it was documented to be the default, many people would miss it unless a big warning was slapped on the docs - The problems are unlikely to appear in test scenarios and much more likely to pop up in production months or years after rolling out the code - If you have never used it on purpose, it is very confusing to debug, causing you to doubt your own and the kernel's sanity - The behaviour changes again if you happen to use a multicast address... Thus, my proposal is to change the default value for UDP to False or deprecate the function and introduce a new one as suggested by Yuri in my original bug report at: https://bugs.python.org/issue37228

1 0

Implementation of PEP-0604
by Philippe Prados 18 Nov '19

18 Nov '19

To implement a full version of PEP604 <https://www.python.org/dev/peps/pep-0604/>, I analyze the typing module, started with _GenericAlias. 1) I must rewrite : - def _type_check(arg, msg, is_argument=True) - def _type_repr(obj) - def _collect_type_vars(types) - def _subs_tvars(tp, tvars, subs) - def _check_generic(cls, parameters) - def _remove_dups_flatten(parameters) - def _tp_cache(func) - class _Final - class _Immutable - class _SpecialForm(_Final, _Immutable, _root=True) - class ForwardRef(_Final, _root=True) - class TypeVar(_Final, _Immutable, _root=True) - def _is_dunder(attr) - class _GenericAlias(_Final, _root=True) - class Generic - class _TypingEmpty - class _TypingEllipsis - def _get_protocol_attrs(cls) - def _is_callable_members_only(cls) - def _allow_reckless_class_cheks() - class _ProtocolMeta(ABCMeta) - class Protocol(Generic, metaclass=_ProtocolMeta) 2) The function _tp_cache use functools.lru_cache() def _tp_cache(func): cached = functools.lru_cache()(func) it's not reasonable to move the lru_cache() in the core 3) The method TypeVar.__init__() use: def_mod = sys._getframe(1).f_globals['__name__'] # for pickling 4) The method def _allow_reckless_class_cheks() use: return sys._getframe(3).f_globals['__name__'] in ['abc', 'functools'] 5) The method Protocol.__init_subclass___proto_hook() use: if (isinstance(annotations, collections.abc.Mapping) it's not reasonable to move the Mapping type in the core It's not enough to move the typing classes, I must move functools.lru_cache() and dependencies, collections.abs.Mapping and dependencies, and track the frame level. *It's too big for me.* May be, the approach with only PEP 563 is enough. from __future__ import annotations a:int|str=3 This new syntax is only usable in annotations. Without runtime evaluation and without modifying issubclass() and isinstance() may be acceptable. Only the mypy (and others tools like this) must be updated. Philippe

6 9

Summary of Python tracker Issues
by Python tracker 16 Nov '19

16 Nov '19

ACTIVITY SUMMARY (2019-11-08 - 2019-11-15) 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: open 7148 ( +8) closed 43418 (+59) total 50566 (+67) Open issues with patches: 2820 Issues opened (39) ================== #38750: Solve IPv4 categorisation issues with the ipaddress module https://bugs.python.org/issue38750 opened by Wicken #38753: AsyncMock not cited as new in 3.8 https://bugs.python.org/issue38753 opened by John Belmonte #38755: Long unicode string causes SyntaxError: Non-UTF-8 code startin https://bugs.python.org/issue38755 opened by Andrew Ushakov #38760: Document for urllib.error.HTTPError.headers Should Specify Wha https://bugs.python.org/issue38760 opened by Han You #38762: Logging displays wrong "processName" if "sys.modules" is clear https://bugs.python.org/issue38762 opened by Delgan #38765: `ast.AST._attributes` is used by `ast.dump()` but not document https://bugs.python.org/issue38765 opened by pekka.klarck #38768: Support lldb enhancement in MacOS https://bugs.python.org/issue38768 opened by Manjusaka #38770: Pickle handle self references in classes https://bugs.python.org/issue38770 opened by Saim Raza #38776: rlock_count<0 https://bugs.python.org/issue38776 opened by toywei #38778: Document that os.fork is not allowed in subinterpreters https://bugs.python.org/issue38778 opened by pconnell #38780: SysLogHandler crash atexit https://bugs.python.org/issue38780 opened by jaraco #38782: Convert importlib.abc to use typing.Protocol https://bugs.python.org/issue38782 opened by brett.cannon #38783: the window size is bigger than the specific size when create a https://bugs.python.org/issue38783 opened by johnliao #38784: ip_network does not clear/update the broadcast_address cache w https://bugs.python.org/issue38784 opened by 992jo #38787: PEP 573: Module State Access from C Extension Methods https://bugs.python.org/issue38787 opened by Dormouse759 #38788: Inconsistent documentation of tell/seek on textiobase/textiowr https://bugs.python.org/issue38788 opened by qha #38789: difflib lacks a way to check if results are empty https://bugs.python.org/issue38789 opened by simon_ #38790: test_fcntl failing on macOS CI https://bugs.python.org/issue38790 opened by steve.dower #38792: IDLE calltips may not properly close on KeyboardInterrupt https://bugs.python.org/issue38792 opened by ZackerySpytz #38793: pathlib.Path.resolve(strict=False) strips final path component https://bugs.python.org/issue38793 opened by lutecki #38794: Setup: support linking openssl statically https://bugs.python.org/issue38794 opened by Lukas.Vacek #38795: test_asyncio.test_subprocess.test_terminate() timed out on AMD https://bugs.python.org/issue38795 opened by vstinner #38796: test_multiprocessing_forkserver: test_mymanager_context() fail https://bugs.python.org/issue38796 opened by vstinner #38797: x86-64 High Sierra 3.x buildbot worker fails to build Python: https://bugs.python.org/issue38797 opened by vstinner #38798: test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data https://bugs.python.org/issue38798 opened by vstinner #38799: race condition in multiprocessing.Pool with maxtasksperchild=1 https://bugs.python.org/issue38799 opened by steve.lorimer(a)gmail.com #38802: Clearer wording of os.WNOHANG documentation to avoid misinterp https://bugs.python.org/issue38802 opened by bbmmy #38803: test_wait3 and test_wait4 leaked references on x86 Gentoo Refl https://bugs.python.org/issue38803 opened by vstinner #38804: Regular Expression Denial of Service in http.cookiejar https://bugs.python.org/issue38804 opened by bc #38805: locale.getlocale() returns a non RFC1766 language code https://bugs.python.org/issue38805 opened by markgrandi #38806: "pdb.Pdb(skip=…).set_trace()" should always stop on calling https://bugs.python.org/issue38806 opened by blueyed #38807: Better exception message in os.path.join https://bugs.python.org/issue38807 opened by tomasfarias #38809: On Windows, build scripts should prefer using python.exe from https://bugs.python.org/issue38809 opened by taleinat #38810: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)" https://bugs.python.org/issue38810 opened by andymaier #38811: Pathlib crashes when os module is missing 'link' method https://bugs.python.org/issue38811 opened by tohojo #38812: Comparing datetime.time objects incorrect for TZ aware and una https://bugs.python.org/issue38812 opened by epicadv #38813: math.modf() change integer returned part as integer instead of https://bugs.python.org/issue38813 opened by aikimark1955 #38814: Python3.7.5 crashes on OSX with my django project https://bugs.python.org/issue38814 opened by karolyi #38815: test_ssl: test_min_max_version() fails on AMD64 FreeBSD Shared https://bugs.python.org/issue38815 opened by vstinner Most recent 15 issues with no replies (15) ========================================== #38814: Python3.7.5 crashes on OSX with my django project https://bugs.python.org/issue38814 #38812: Comparing datetime.time objects incorrect for TZ aware and una https://bugs.python.org/issue38812 #38809: On Windows, build scripts should prefer using python.exe from https://bugs.python.org/issue38809 #38807: Better exception message in os.path.join https://bugs.python.org/issue38807 #38806: "pdb.Pdb(skip=…).set_trace()" should always stop on calling https://bugs.python.org/issue38806 #38805: locale.getlocale() returns a non RFC1766 language code https://bugs.python.org/issue38805 #38804: Regular Expression Denial of Service in http.cookiejar https://bugs.python.org/issue38804 #38799: race condition in multiprocessing.Pool with maxtasksperchild=1 https://bugs.python.org/issue38799 #38798: test_asyncio.test_sendfile.test_sendfile_ssl_pre_and_post_data https://bugs.python.org/issue38798 #38795: test_asyncio.test_subprocess.test_terminate() timed out on AMD https://bugs.python.org/issue38795 #38790: test_fcntl failing on macOS CI https://bugs.python.org/issue38790 #38788: Inconsistent documentation of tell/seek on textiobase/textiowr https://bugs.python.org/issue38788 #38787: PEP 573: Module State Access from C Extension Methods https://bugs.python.org/issue38787 #38783: the window size is bigger than the specific size when create a https://bugs.python.org/issue38783 #38782: Convert importlib.abc to use typing.Protocol https://bugs.python.org/issue38782 Most recent 15 issues waiting for review (15) ============================================= #38811: Pathlib crashes when os module is missing 'link' method https://bugs.python.org/issue38811 #38809: On Windows, build scripts should prefer using python.exe from https://bugs.python.org/issue38809 #38807: Better exception message in os.path.join https://bugs.python.org/issue38807 #38806: "pdb.Pdb(skip=…).set_trace()" should always stop on calling https://bugs.python.org/issue38806 #38804: Regular Expression Denial of Service in http.cookiejar https://bugs.python.org/issue38804 #38794: Setup: support linking openssl statically https://bugs.python.org/issue38794 #38792: IDLE calltips may not properly close on KeyboardInterrupt https://bugs.python.org/issue38792 #38787: PEP 573: Module State Access from C Extension Methods https://bugs.python.org/issue38787 #38778: Document that os.fork is not allowed in subinterpreters https://bugs.python.org/issue38778 #38753: AsyncMock not cited as new in 3.8 https://bugs.python.org/issue38753 #38743: configure: on macOS (darwin) add CoreFoundation to flags befor https://bugs.python.org/issue38743 #38741: Definition of multiple ']' in header configparser https://bugs.python.org/issue38741 #38731: bad input crashes py_compile library https://bugs.python.org/issue38731 #38724: Implement subprocess.Popen.__repr__ https://bugs.python.org/issue38724 #38712: add signal.pidfd_send_signal https://bugs.python.org/issue38712 Top 10 most discussed issues (10) ================================= #22367: Add open_file_descriptor parameter to fcntl.lockf() (use the n https://bugs.python.org/issue22367 9 msgs #38780: SysLogHandler crash atexit https://bugs.python.org/issue38780 8 msgs #38591: Deprecate Process Child Watchers https://bugs.python.org/issue38591 7 msgs #38794: Setup: support linking openssl statically https://bugs.python.org/issue38794 7 msgs #4630: IDLE: add cursor noblink option https://bugs.python.org/issue4630 5 msgs #38724: Implement subprocess.Popen.__repr__ https://bugs.python.org/issue38724 5 msgs #36128: ResourceReader for FileLoader inconsistently handles path sepa https://bugs.python.org/issue36128 4 msgs #36852: Python3.7.2 fails to cross-compile (yocto / openembedded) when https://bugs.python.org/issue36852 4 msgs #38500: Provide a way to get/set PyInterpreterState.frame_eval without https://bugs.python.org/issue38500 4 msgs #38673: REPL shows continuation prompt (...) when comment or space ent https://bugs.python.org/issue38673 4 msgs Issues closed (59) ================== #9399: Provide a 'print' action for argparse https://bugs.python.org/issue9399 closed by rhettinger #11354: argparse: nargs could accept range of options count https://bugs.python.org/issue11354 closed by rhettinger #26353: IDLE: Saving Shell should not add \n https://bugs.python.org/issue26353 closed by terry.reedy #27805: io.open('/dev/stdout', 'a') raises OSError with errno=ESPIPE https://bugs.python.org/issue27805 closed by benjamin.peterson #35192: pathlib mkdir throws FileExistsError when not supposed to https://bugs.python.org/issue35192 closed by xtreak #35666: Update design FAQ about assignment expression https://bugs.python.org/issue35666 closed by xtreak #35856: bundled pip syntaxwarning https://bugs.python.org/issue35856 closed by inada.naoki #36092: unittest.mock's patch.object and patch.dict are not supported https://bugs.python.org/issue36092 closed by xtreak #36130: Pdb(skip=[...]) + module without __name__ => TypeError https://bugs.python.org/issue36130 closed by benjamin.peterson #37436: os.path.isfile() with big number cause OverflowError: fd is gr https://bugs.python.org/issue37436 closed by serhiy.storchaka #37564: ArgumentParser should support bool type according to truth val https://bugs.python.org/issue37564 closed by rhettinger #37759: Polish whatsnew for 3.8 https://bugs.python.org/issue37759 closed by rhettinger #37855: Compiling Python 3.7.4 with Intel compilers 2019 https://bugs.python.org/issue37855 closed by vstinner #38351: Modernize email example from %-formatting to f-string https://bugs.python.org/issue38351 closed by taleinat #38385: statistics: incorrect documentation https://bugs.python.org/issue38385 closed by rhettinger #38421: email.utils.parsetime_tz does not return "None" as the tz offs https://bugs.python.org/issue38421 closed by petr.viktorin #38438: argparse "usage" overly-complex with nargs="*" https://bugs.python.org/issue38438 closed by rhettinger #38517: functools.cached_property should support partial functions and https://bugs.python.org/issue38517 closed by taleinat #38565: Expose the value passed of typed passed to functools.lru_cache https://bugs.python.org/issue38565 closed by rhettinger #38609: Trashcan mechanism segfault during interpreter finalization in https://bugs.python.org/issue38609 closed by ronaldoussoren #38635: Simplify decoding the ZIP64 extra field and make it tolerant t https://bugs.python.org/issue38635 closed by serhiy.storchaka #38677: Arraymodule initialization error handling improvements https://bugs.python.org/issue38677 closed by serhiy.storchaka #38679: Scipy and Scikit learn library installation issues https://bugs.python.org/issue38679 closed by terry.reedy #38692: add a pidfd child process watcher https://bugs.python.org/issue38692 closed by benjamin.peterson #38723: Pdb._runscript should use io.open_code() instead of open() https://bugs.python.org/issue38723 closed by steve.dower #38734: Python 3.7 and 3.8 in Windows Store do not start under git bas https://bugs.python.org/issue38734 closed by steve.dower #38736: argparse: wrong type from get_default when type is set https://bugs.python.org/issue38736 closed by paul.j3 #38738: Fix formatting of True and False https://bugs.python.org/issue38738 closed by serhiy.storchaka #38740: Line count mismatch between open() vs sys.stdin api calls https://bugs.python.org/issue38740 closed by thammegowda #38742: ElementTree won't parse comments before root element https://bugs.python.org/issue38742 closed by scoder #38747: Slowly introduce a subset of Jupyter console (IPython) feature https://bugs.python.org/issue38747 closed by terry.reedy #38749: sqlite3 driver fails on four byte unicode strings coming from https://bugs.python.org/issue38749 closed by serhiy.storchaka #38751: Document maximum JSON depth or remove it. https://bugs.python.org/issue38751 closed by rhettinger #38752: __init__ taking out of context variables https://bugs.python.org/issue38752 closed by eric.smith #38754: Python3.7 site-packages https://bugs.python.org/issue38754 closed by ned.deily #38756: Add generic versions of weakref types to typing module https://bugs.python.org/issue38756 closed by levkivskyi #38757: mocking an exception, arguments do not seem to be passed to th https://bugs.python.org/issue38757 closed by cjw296 #38758: @dataclass defaults https://bugs.python.org/issue38758 closed by gvanrossum #38759: Python 2.7.9 x64 for Windows version is 2.7.13 https://bugs.python.org/issue38759 closed by steve.dower #38761: weakref.WeakSet not instanceof collections.abc.Set https://bugs.python.org/issue38761 closed by rhettinger #38763: mock with side effect : assert_called_once returns None while https://bugs.python.org/issue38763 closed by cjw296 #38764: Deterministic globbing. https://bugs.python.org/issue38764 closed by gvanrossum #38766: AttributeError: 'xml.etree.ElementTree.ParseError' has no attr https://bugs.python.org/issue38766 closed by mlj #38767: Replace Mersenne Twister RNG with a PCG family algorithm https://bugs.python.org/issue38767 closed by rhettinger #38769: generators are currently hashable https://bugs.python.org/issue38769 closed by steven.daprano #38771: Bug in example of collections.ChainMap https://bugs.python.org/issue38771 closed by rhettinger #38772: shutil.copytree fail to copy some bytes https://bugs.python.org/issue38772 closed by benjamin.peterson #38773: Fatal Python error: Aborted https://bugs.python.org/issue38773 closed by brett.cannon #38774: Statements in try block still executes after raised error https://bugs.python.org/issue38774 closed by Torbjørn Wikestad #38775: Cloudpickle.py file is crashing due to data type incompatibili https://bugs.python.org/issue38775 closed by xtreak #38777: plist handling of real data type https://bugs.python.org/issue38777 closed by David Nicolson #38779: Simple typo in strings module documentation https://bugs.python.org/issue38779 closed by zach.ware #38781: Clear buffer in MemoryHandler flush https://bugs.python.org/issue38781 closed by penlect #38785: Segmentation fault in asyncio https://bugs.python.org/issue38785 closed by asvetlov #38786: Add parsing of https links to pydoc https://bugs.python.org/issue38786 closed by taleinat #38791: readline history file is hard-coded https://bugs.python.org/issue38791 closed by jconder #38800: Resume position for UTF-8 codec error handler not working https://bugs.python.org/issue38800 closed by serhiy.storchaka #38801: Scientific notation doesn't work with itertools.islice https://bugs.python.org/issue38801 closed by rhettinger #38808: weird bug while using a for loop and array https://bugs.python.org/issue38808 closed by mark.dickinson

1 0

Nominations for the 2019 Steering Council Election are open until Friday.
by Thomas Wouters 14 Nov '19

14 Nov '19

Perhaps this should've been announced a little more widely: we have upcoming Steering Council elections, and nominations close soon -- end of day *this Friday*. Five seats need to be filled. (We have four nominations so far, but I have no idea how many people are gearing up to nominate in the next couple of days.) Nominees *do not need to be core developers*, although a core developer has to do the nominating. Brett Cannon and Carol Willing have posted about what the work entails: https://snarky.ca/what-its-like-to-be-on-the-python-steering-council/ https://www.willingconsulting.com/post/2019-11-02-python-steering-retro/ If you think you might be interested but you're not a core developer, or you're just not comfortable self-nominating, please feel free to talk to me (or other core developers you might know). If you're not sure if you'd have a useful contribution -- well, we can talk about that, too :) ---------- Forwarded message --------- From: Ewa Jodlowska <ewa(a)python.org> Date: Fri, Nov 1, 2019 at 1:40 PM Subject: [python-committers] Nominations for the 2019 Steering Council Election are now open. To: <python-committers(a)python.org> Hello! Per PEP 13, members of the Committers group can post to the "Steering Council Nominations" category on Discourse to nominate a person ( https://discuss.python.org/t/2019-steering-council-nominations-are-now-open…). All users are able to reply. Nominations should be posted as a Topic with the name "Steering Council nomination: " and tagged with the election tag. All Posts and Replies in this category will be moderated, so there may be some delay before they appear. Thank you, Ernest & Ewa ----------------------- *As a non-profit organization, the PSF depends on sponsorships and donations to support the Python community. Check out our Annual Impact Report for more details: https://www.python.org/psf/annual-report/2019/ <https://www.python.org/psf/annual-report/2019/>* *Please contribute to PSF; we can't continue our work without your support! https://www.python.org/psf/donations/ <https://www.python.org/psf/donations/>* _______________________________________________ python-committers mailing list -- python-committers(a)python.org To unsubscribe send an email to python-committers-leave(a)python.org https://mail.python.org/mailman3/lists/python-committers.python.org/ Message archived at https://mail.python.org/archives/list/python-committers@python.org/message/… Code of Conduct: https://www.python.org/psf/codeofconduct/ -- Thomas Wouters <thomas(a)python.org> Hi! I'm an email virus! Think twice before sending your email to help me spread!

2 1

Belatedly accepting PEP 579 (design discussion leading to vectorcall)
by Petr Viktorin 12 Nov '19

12 Nov '19

I approve [PEP 579], with the understanding that acceptance of an Informational PEP doesn't really mean that much. PEP 579 charts the design issues addressed in PEP 575, PEP 580, PEP 590 (and hopefully more upcoming proposals). As noted in PEP 1: Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementers are free to ignore Informational PEPs or follow their advice. While there is no consensus on whether the issues or the solutions in PEP 579 are valid, the list is still useful to guide further design. I plan to note that in the PEP itself to inform drive-by readers: https://github.com/python/peps/pull/1233/files I should have done this ages ago, but it fell off my TODO list. Thanks to Brett for reminding me! [PEP 579]: https://www.python.org/dev/peps/pep-0579/

1 0