docs November 2017

docs@python.org

17 participants
533 discussions

[issue31996] `setuptools.setup` parameter `py_modules` is undocumented
by Luther Thompson 11 Nov '17

11 Nov '17

New submission from Luther Thompson <lutheroto(a)gmail.com>: I wrote my own distribution package with only one module, but the module file was not being installed along with the dist info file. I found by looking up the code for the `six` module that `setup` has a `py_modules` parameter which apparently must be used to make the installation work. This module is not mentioned anywhere in https://packaging.python.org/tutorials/distributing-packages/. ---------- assignee: docs@python components: Documentation messages: 305997 nosy: Luther Thompson, docs@python priority: normal severity: normal status: open title: `setuptools.setup` parameter `py_modules` is undocumented type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31996> _______________________________________

2 2

[issue32006] multiprocessing.Array 'c' code is not documented
by Steven D'Aprano 10 Nov '17

10 Nov '17

New submission from Steven D'Aprano <steve+python(a)pearwood.info>: multiprocessing.Array is documented as taking the same character codes as array.array, but it also takes 'c' which is not documented. https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array https://docs.python.org/3/library/array.html#module-array ---------- assignee: docs@python components: Documentation messages: 306069 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: multiprocessing.Array 'c' code is not documented type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32006> _______________________________________

1 0

[issue31995] Set operations documentation error
by Alexander Mentis 10 Nov '17

10 Nov '17

New submission from Alexander Mentis <asmentis(a)gmail.com>: Documentation for set/frozenset says |=, &=, -=, ^= operators do not apply to immutable instances of frozenset. This is incorrect. These operators can be used on frozenset; however, they behave differently on frozenset than on set. When used with set, they modify the target set in place. When used with frozenset, they return a new frozenset that replaces the target frozenset. ---------- assignee: docs@python components: Documentation messages: 305981 nosy: Alexander Mentis, docs@python priority: normal severity: normal status: open title: Set operations documentation error versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31995> _______________________________________

3 6

[issue31824] Missing default argument detail in documentation of StreamReaderWriter
by Peter Lovett 10 Nov '17

10 Nov '17

New submission from Peter Lovett <pacqa100(a)yahoo.com.au>: Documentation of StreamReaderWriter at https://docs.python.org/3/library/codecs.html#codecs.StreamReaderWriter section 7.2.1.4.3 is missing the default value on the errors argument. Should change from: class codecs.StreamReaderWriter(stream, Reader, Writer, errors) to be: class codecs.StreamReaderWriter(stream, Reader, Writer, errors='strict') ---------- assignee: docs@python components: Documentation messages: 304646 nosy: PeterLovett, docs@python priority: normal severity: normal status: open title: Missing default argument detail in documentation of StreamReaderWriter type: behavior versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31824> _______________________________________

4 8

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 10 Nov '17

10 Nov '17

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: Steven's patch is outdated since 71a0b43854164b6ada0026d90f241c987b54d019. But that commit missed that spaces are not ignored within tokens. PR 4366 fixes this by using the wording from Ezio's comments. ---------- nosy: +zach.ware _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Serhiy Storchaka 10 Nov '17

10 Nov '17

Change by Serhiy Storchaka <storchaka+cpython(a)gmail.com>: ---------- pull_requests: +4319 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue15606] re.VERBOSE whitespace behavior not completely documented
by Kevin Shweh 10 Nov '17

10 Nov '17

Kevin Shweh <kevin.shweh(a)gmail.com> added the comment: It looks to me like there are more situations than the patch lists where whitespace still separates tokens. For example, *? is a reluctant quantifier and * ? is a syntax error, even in verbose mode. ---------- nosy: +Kevin Shweh _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue15606> _______________________________________

1 0

[issue31778] ast.literal_eval supports non-literals in Python 3
by Neil Schemenauer 09 Nov '17

09 Nov '17

Neil Schemenauer <nas-python(a)arctrix.com> added the comment: Just a comment on what I guess is the intended use of literal_eval(), i.e. taking a potentially untrusted string and turning it into a Python object. Exposing the whole of the Python parser to potential attackers would make me very worried. Parsing code for all of Python syntax is just going to be very complicated and there can easily be bugs there. Generating an AST and then walking over it to see if it is safe is also scary. The "attack surface" is too large. This is similar to the Shellshock bug. If you can trust the supplier of the string then okay but I would guess that literal_eval() is going to get used for untrusted inputs. It would be really nice to have something like ast.literal_eval() that could be used for untrusted strings. I would implement it by writing a retricted parser. Keep it extremely simple. Validate it by heavy code reviews and extensive testing (e.g. fuzzing). ---------- nosy: +nascheme _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31778> _______________________________________

1 0

[issue14124] _pickle.c comment/documentation improvement
by Merlijn van Deen 09 Nov '17

09 Nov '17

New submission from Merlijn van Deen <valhallasw(a)gmail.com>: As suggested by loewis in msg154233, I created some documentation to help people get started with _pickle.c. ---------- assignee: docs@python components: Documentation, Extension Modules files: _pickle_c_doc.diff keywords: patch messages: 154284 nosy: docs@python, valhallasw priority: normal severity: normal status: open title: _pickle.c comment/documentation improvement type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24641/_pickle_c_doc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14124> _______________________________________

3 4

[issue31778] ast.literal_eval supports non-literals in Python 3
by Serhiy Storchaka 09 Nov '17

09 Nov '17

Serhiy Storchaka <storchaka+cpython(a)gmail.com> added the comment: Ping. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31778> _______________________________________

1 0

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs November 2017