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>
_______________________________________
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.Arrayhttps://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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________
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>
_______________________________________