Mailman 3 January 2019 - docs

[issue35801] venv in 3.7 references python3 executable
by Paul Watson 21 Jan '19

21 Jan '19

New submission from Paul Watson <paul.hermeneutic(a)gmail.com>: The documentation for venv in Python 3.7 references using `python3` to run venv. I do not find a `python3` executable in the kit. https://docs.python.org/3.7/library/venv.html#module-venv ---------- assignee: docs@python components: Documentation messages: 334165 nosy: Paul Watson, docs@python priority: normal severity: normal status: open title: venv in 3.7 references python3 executable type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35801> _______________________________________

1 0

[issue35777] mismatched eval() and ast.literal_eval() behavior with unicode_literals
by jez 21 Jan '19

21 Jan '19

jez <jezhill(a)gmail.com> added the comment: I take the point about breaking backward compatibility. The problem, then, is in the `ast` documentation, and may not be confined to Python 2.7 The `literal_eval` doc <https://docs.python.org/2/library/ast.html#ast-helpers> states no more than that the function evaluates a "string containing a Python literal". The future statement effectively changes the definition of "a Python literal" but of course, as the official `__future__` doc <https://docs.python.org/2/reference/simple_stmts.html#future> explains, this is done for the compilation of each "particular module" in isolation. The question is left open whether the occurrence of this term in `ast` documentation should be read as "a Python literal (as defined by the ast module itself at compile time)", or "a Python literal (as defined by the caller at compile time)". More generally, future statements effectively change the definition of the term "Python syntax", sometimes also simply referred to as "Python". Unfortunately, the `ast` documentation uses these terms loosely throughout, without acknowledging that they are mutable. I propose that the `ast` module documentation flag cases in which the `ast` module's own definitions of "Python" and "Python syntax" may not match those of a caller who has included `__future__` statements, leading to unexpected behavior. I am insufficiently familiar with the full functionality of `ast` to be able to identify where this is and is not an issue, except in `literal_eval`, but I can see it could in principle affect Python 3.x too. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: -Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35777> _______________________________________

1 0

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows
by Christian Ullrich 21 Jan '19

21 Jan '19

New submission from Christian Ullrich <chris(a)chrullrich.net>: Using concurrent.futures.ProcessPoolExecutor on Windows fails immediately with a lot of exceptions of the "access denied", "file not found", and "invalid handle" varieties. Running the script that creates the ProcessPoolExecutor from the main system-wide installation works correctly. Due to Windows' infamous lack of fork(), ProcessPoolExecutor launches its worker processes by setting up an inheritable handle to a pipe and passing the handle on the command line. In a venv situation, it appears that the venv's python.exe internally launches the parent environment's python.exe and passes on its command line, but not its handle table. This sub-subprocess therefore does not have the original handle, and may have a different handle at the same index. Output of the ProcessPoolExecutor example program from the docs when run with the main installation: C:\Daten>py cft.py 112272535095293 is prime: True 112582705942171 is prime: True 112272535095293 is prime: True 115280095190773 is prime: True 115797848077099 is prime: True 1099726899285419 is prime: False Output when run using a venv: C:\Daten>pyv\v37\Scripts\python.exe cft.py Process SpawnProcess-4: Traceback (most recent call last): File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get with self._rlock: File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__ return self._semlock.__enter__() PermissionError: [WinError 5] Access is denied Process SpawnProcess-5: Traceback (most recent call last): File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 297, in _bootstrap self.run() File "C:\Program Files\Python37\lib\multiprocessing\process.py", line 99, in run self._target(*self._args, **self._kwargs) File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 226, in _process_worker call_item = call_queue.get(block=True) File "C:\Program Files\Python37\lib\multiprocessing\queues.py", line 93, in get with self._rlock: File "C:\Program Files\Python37\lib\multiprocessing\synchronize.py", line 95, in __enter__ return self._semlock.__enter__() PermissionError: [WinError 5] Access is denied Traceback (most recent call last): File "cft.py", line 28, in <module> main() File "cft.py", line 24, in main for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)): File "C:\Program Files\Python37\lib\concurrent\futures\process.py", line 476, in _chain_from_iterable_of_lists for element in iterable: File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 586, in result_iterator yield fs.pop().result() File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 432, in result return self.__get_result() File "C:\Program Files\Python37\lib\concurrent\futures\_base.py", line 384, in __get_result raise self._exception concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending. ---------- assignee: docs@python components: Documentation, Library (Lib), Windows messages: 334142 nosy: chrullrich, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: concurrent.futures.ProcessPoolExecutor does not work in venv on Windows type: behavior versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35797> _______________________________________

1 0

[issue35168] shlex punctuation_chars inconsistency
by Roundup Robot 21 Jan '19

21 Jan '19

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- keywords: +patch, patch, patch, patch pull_requests: +11400, 11401, 11402, 11403 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35168> _______________________________________

1 0

[issue35168] shlex punctuation_chars inconsistency
by Roundup Robot 21 Jan '19

21 Jan '19

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- keywords: +patch, patch, patch pull_requests: +11400, 11401, 11402 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35168> _______________________________________

1 0

[issue35168] shlex punctuation_chars inconsistency
by Roundup Robot 21 Jan '19

21 Jan '19

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- keywords: +patch, patch pull_requests: +11400, 11401 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35168> _______________________________________

1 0

[issue35168] shlex punctuation_chars inconsistency
by Roundup Robot 21 Jan '19

21 Jan '19

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- keywords: +patch pull_requests: +11400 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35168> _______________________________________

1 0

[issue35722] disable_existing_loggers does not apply to the root logger
by Cheryl Sabella 20 Jan '19

20 Jan '19

Change by Cheryl Sabella <cheryl.sabella(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation -Library (Lib) nosy: +docs@python _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35722> _______________________________________

1 0

Issue in https://docs.python.org/3/library/importlib.html
by Goldberg, Arthur P 20 Jan '19

20 Jan '19

In “ValueError is also raised a relative name would escape its containing package (e.g. requesting ..bacon from within the spam package).”, s/raised a relative/raised if a relative/ and the example isn’t clear as no package hierarchy is illustrated. Thanks for your great docs overall. Arthur Arthur Goldberg, PhD Associate Professor of Genetics and Genomic Sciences Institute for Data Science and Genomic Technology Mount Sinai School of Medicine 1255 Fifth Ave., Suite C-2 New York, NY 10029 646 526 5020 Karr Lab Arthur.Goldberg(a)mssm.edu<mailto:Arthur.Goldberg@mssm.edu>

1 0

The `errors` parameter for `pickle.load`
by John Yeung 20 Jan '19

20 Jan '19

The docs for `pickle.load` and `pickle.loads` mention that the default value for `errors` is 'strict' but don't say anything about what else it could be. If you're silly enough to try 'loose', you get LookupError: unknown error handler name 'loose' Where can someone find out more about this parameter? If it's too long to explain right there in the docs for `load`, but something is already published, I propose that the docs point to that. If it's a case of "if you really want to use this, you really have to know what you're doing, and you can figure it out for yourself from the source", then the docs should say something to that effect. Another possibility is that using a value other than the default is so rare and specialized that the parameter might as well not be documented (since you have to read the source to learn how to use it anyway, in which case the source *is* your documentation). Finally, as an orthogonal issue, the optional keyword arguments paragraph is identical for both `load` and `loads`. I propose that it follows the less repetitive pattern of `dump` and `dumps`. John Y.

1 0