From report at bugs.python.org  Sun May  1 00:32:17 2016
From: report at bugs.python.org (Yclept Nemo)
Date: Sun, 01 May 2016 04:32:17 +0000
Subject: [docs] [issue26897] Clarify Popen stdin, stdout, stderr
Message-ID: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>


New submission from Yclept Nemo:

From: https://docs.python.org/dev/library/subprocess.html#popen-constructor

"..., an existing file descriptor (a positive integer), an existing file object, and None."

It should be made clear that the file object must be backed by an operating system file, i.e. must have a valid file descriptor.

As it stands, the documentation suggests implicit concurrency: that any file object can be used, and on read/write from the subprocess/OS arbitrary python code will be executed, i.e. the python interpreter is pre-empted or python spawns a hidden I/O thread.

Anyway, I'm pretty sure subprocess.Popen() just redirects the forked process' stdout/stdin/stderr to the file descriptors from the provided file object.

----------
assignee: docs at python
components: Documentation
messages: 264579
nosy: Yclept.Nemo, docs at python
priority: normal
severity: normal
status: open
title: Clarify Popen stdin, stdout, stderr
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Sun May  1 04:06:18 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 01 May 2016 08:06:18 +0000
Subject: [docs] [issue26898] Error in the
Message-ID: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The math.isclose() documentation reports is_close() as function name, instead of isclose(): 

  >>> import math
  >>> math.isclose.__doc__[:45]
  'is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0)'

----------
assignee: docs at python
components: Documentation
files: isclose.patch
keywords: patch
messages: 264585
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Error in the
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42669/isclose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26898>
_______________________________________

From report at bugs.python.org  Sun May  1 04:12:06 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 May 2016 08:12:06 +0000
Subject: [docs] [issue26898] Error in the
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462090326.69.0.246729700834.issue26898@psf.upfronthosting.co.za>


SilentGhost added the comment:

LGTM

----------
nosy: +SilentGhost
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26898>
_______________________________________

From report at bugs.python.org  Sun May  1 04:27:56 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 01 May 2016 08:27:56 +0000
Subject: [docs] [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462091276.93.0.908216354325.issue26898@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


----------
title: Error in the -> Typo in the documentation of math.isclose()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26898>
_______________________________________

From report at bugs.python.org  Sun May  1 04:28:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 08:28:43 +0000
Subject: [docs] [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <20160501082840.21665.49432.C2902BFB@psf.io>


Roundup Robot added the comment:

New changeset 469bc90e8922 by Berker Peksag in branch '3.5':
Issue #26898: Fix typo in math.isclose() docstring
https://hg.python.org/cpython/rev/469bc90e8922

New changeset 634764b4675c by Berker Peksag in branch 'default':
Issue #26898: Fix typo in math.isclose() docstring
https://hg.python.org/cpython/rev/634764b4675c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26898>
_______________________________________

From report at bugs.python.org  Sun May  1 04:29:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 08:29:55 +0000
Subject: [docs] [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462091395.36.0.181804017555.issue26898@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26898>
_______________________________________

From report at bugs.python.org  Sun May  1 06:09:35 2016
From: report at bugs.python.org (Paul Sokolovsky)
Date: Sun, 01 May 2016 10:09:35 +0000
Subject: [docs] [issue26899] struct.pack_into(),
 struct.unpack_from() don't document support for negative offsets
Message-ID: <1462097375.63.0.546095370218.issue26899@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

See
https://docs.python.org/3/library/struct.html#struct.pack_into
https://docs.python.org/3/library/struct.html#struct.unpack_from

Actual source contains code like:

    if (offset < 0)
        offset += vbuf.len;

to allow specify offsets from the end of a buffer.

----------
assignee: docs at python
components: Documentation
messages: 264590
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: struct.pack_into(), struct.unpack_from() don't document support for negative offsets
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26899>
_______________________________________

From report at bugs.python.org  Sun May  1 13:34:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 17:34:26 +0000
Subject: [docs] [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <20160501173422.10030.40759.61A1DCB7@psf.io>


Roundup Robot added the comment:

New changeset 84ff79cce41e by Serhiy Storchaka in branch '3.5':
Regenerate Argument Clinic code for issue #26874.
https://hg.python.org/cpython/rev/84ff79cce41e

New changeset 98678738b7e9 by Serhiy Storchaka in branch 'default':
Regenerate Argument Clinic code for issue #26874.
https://hg.python.org/cpython/rev/98678738b7e9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Sun May  1 15:33:26 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 01 May 2016 19:33:26 +0000
Subject: [docs] [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1462131206.15.0.317706889775.issue26874@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Forgot that step, thanks Serhiy!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26874>
_______________________________________

From report at bugs.python.org  Mon May  2 05:26:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 09:26:51 +0000
Subject: [docs] [issue18916] Various out-of-date Lock text in 3.2+
In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>
Message-ID: <1462181211.94.0.00871687476381.issue18916@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the path, Christopher.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18916>
_______________________________________

From report at bugs.python.org  Mon May  2 18:57:25 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 02 May 2016 22:57:25 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
Message-ID: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The numbered and bulletted lists are indented from the body text, which looks good in the .rst, but causes the lists themselves to be blockquotes.  This leads to confusing formatting on python.org: https://www.python.org/dev/peps/pep-0420/

BTW: this formatting error is rampant among the PEPs... :(

----------
assignee: docs at python
components: Documentation
files: pep-0420.patch
keywords: patch
messages: 264677
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Fix formatting of lists in PEP 420
Added file: http://bugs.python.org/file42686/pep-0420.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Mon May  2 19:41:07 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 02 May 2016 23:41:07 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462232467.17.0.435750471316.issue26914@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

OK, "rampant" was overly dramatic... :)

These PEPs seem to have the same issue:

pep-0302.html
pep-0327.html
pep-0339.html
pep-0362.html
pep-0364.html
pep-0372.html
pep-0380.html
pep-0382.html
pep-0393.html
pep-0400.html
pep-0403.html
pep-0404.html
pep-0410.html
pep-0416.html
pep-0418.html
pep-0426.html
pep-0432.html
pep-0433.html
pep-0437.html
pep-0446.html
pep-0457.html
pep-0461.html
pep-0472.html
pep-0488.html
pep-0498.html
pep-0628.html
pep-3103.html
pep-3104.html
pep-3108.html
pep-3121.html
pep-3127.html
pep-3131.html
pep-3137.html
pep-3141.html
pep-3147.html
pep-3149.html
pep-3150.html
pep-3156.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 00:26:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 04:26:57 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462249616.99.0.655980031932.issue26914@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For references:

PEP 0302: New Import Hooks
PEP 0327: Decimal Data Type
PEP 0339: Design of the CPython Compiler
PEP 0362: Function Signature Object
PEP 0364: Transitioning to the Py3K Standard Library
PEP 0372: Adding an ordered dictionary to collections
PEP 0380: Syntax for Delegating to a Subgenerator
PEP 0382: Namespace Packages
PEP 0393: Flexible String Representation
PEP 0400: Deprecate codecs.StreamReader and codecs.StreamWriter
PEP 0403: General purpose decorator clause (aka "@in" clause)
PEP 0404: Python 2.8 Un-release Schedule
PEP 0410: Use decimal.Decimal type for timestamps
PEP 0416: Add a frozendict builtin type
PEP 0418: Add monotonic time, performance counter, and process time functions
PEP 0420: Implicit Namespace Packages
PEP 0426: Metadata for Python Software Packages 2.0
PEP 0432: Simplifying the CPython startup sequence
PEP 0433: Easier suppression of file descriptor inheritance
PEP 0437: A DSL for specifying signatures, annotations and argument converters
PEP 0446: Make newly created file descriptors non-inheritable
PEP 0457: Syntax For Positional-Only Parameters
PEP 0461: Adding % formatting to bytes and bytearray
PEP 0472: Support for indexing with keyword arguments
PEP 0488: Elimination of PYO files
PEP 0498: Literal String Interpolation
PEP 0628: Add ``math.tau``
PEP 3103: A Switch/Case Statement
PEP 3104: Access to Names in Outer Scopes
PEP 3108: Standard Library Reorganization
PEP 3121: Extension Module Initialization and Finalization
PEP 3127: Integer Literal Support and Syntax
PEP 3131: Supporting Non-ASCII Identifiers
PEP 3137: Immutable Bytes and Mutable Buffer
PEP 3141: A Type Hierarchy for Numbers
PEP 3147: PYC Repository Directories
PEP 3149: ABI version tagged .so files
PEP 3150: Statement local namespaces (aka "given" clause)
PEP 3156: Asynchronous IO Support Rebooted: the "asyncio" Module

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 00:27:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 04:27:41 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462249661.98.0.729044324077.issue26914@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 00:35:18 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 04:35:18 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462250118.75.0.639534162385.issue26914@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks pretty rampant to me :)

Anyway, +1 for fixing, you can just do it without review if you have the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 03:36:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 07:36:41 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503073637.21667.45381.41DC1C55@psf.io>


Roundup Robot added the comment:

New changeset 03a4c21ca991 by Berker Peksag in branch 'default':
Issue #26914: Fix formatting of lists in PEP 420
https://hg.python.org/peps/rev/03a4c21ca991

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 03:38:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 May 2016 07:38:31 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462261111.33.0.13284587079.issue26914@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, I pushed pep-0420.patch.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 03:52:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 07:52:30 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503075226.8860.42104.6DA06531@psf.io>


Roundup Robot added the comment:

New changeset d420d6fe349f by Georg Brandl in branch 'default':
Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
https://hg.python.org/peps/rev/d420d6fe349f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 04:35:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 08:35:18 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503083514.16687.66468.8809BB14@psf.io>


Roundup Robot added the comment:

New changeset d34c698f63a3 by Georg Brandl in branch 'default':
Fix lists-in-blockquotes in 0xxx PEPs. Ref: #26914
https://hg.python.org/peps/rev/d34c698f63a3

New changeset e7200e32b220 by Georg Brandl in branch 'default':
Fixup some more lists-in-blockquotes. Fixes #26914.
https://hg.python.org/peps/rev/e7200e32b220

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 04:36:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 08:36:47 +0000
Subject: [docs] [issue26916] Word duplications in PEPs
Message-ID: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes typos in PEPs that cause words duplications.

----------
assignee: docs at python
components: Documentation
files: pep_duplicates.patch
keywords: patch
messages: 264695
nosy: docs at python, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Word duplications in PEPs
Added file: http://bugs.python.org/file42689/pep_duplicates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26916>
_______________________________________

From report at bugs.python.org  Tue May  3 04:39:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 08:39:03 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462264743.36.0.307188907611.issue26914@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 04:40:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 May 2016 08:40:47 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462264847.41.0.712811333325.issue26914@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 04:44:50 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 08:44:50 +0000
Subject: [docs] [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <1462265090.44.0.776688447365.issue26916@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26916>
_______________________________________

From report at bugs.python.org  Tue May  3 05:07:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 09:07:10 +0000
Subject: [docs] [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <20160503090705.100786.38829.1B52C6E9@psf.io>


Roundup Robot added the comment:

New changeset d0b969132758 by Serhiy Storchaka in branch 'default':
Issue #26916: Fixed words duplications.
https://hg.python.org/peps/rev/d0b969132758

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26916>
_______________________________________

From report at bugs.python.org  Tue May  3 06:22:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:22:20 +0000
Subject: [docs] [issue26921] Incorrect usage of a/an articles in PEPs
Message-ID: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the usage of a/an articles in PEPs.

----------
assignee: docs at python
components: Documentation
files: pep_articles.patch
keywords: patch
messages: 264710
nosy: docs at python, georg.brandl, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect usage of a/an articles in PEPs
Added file: http://bugs.python.org/file42693/pep_articles.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26921>
_______________________________________

From report at bugs.python.org  Tue May  3 06:42:45 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 03 May 2016 10:42:45 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462272165.7.0.865567591099.issue26914@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Unless I have permissions I've never used, I don't think I can just push fixes to the peps repo. Also, it looks like Georg is working away at it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 06:46:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 10:46:03 +0000
Subject: [docs] [issue26921] Incorrect usage of a/an articles in PEPs
In-Reply-To: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>
Message-ID: <1462272363.33.0.584579591795.issue26921@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Also LGTM.  It's easy to spot PEPs written by French people :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26921>
_______________________________________

From report at bugs.python.org  Tue May  3 06:47:42 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 10:47:42 +0000
Subject: [docs] [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462272461.95.0.598068728657.issue26914@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Yep, they should all be gone. I tried to make sure by running the sources through docutils and finding nested <blockquote><foo_list> nodes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26914>
_______________________________________

From report at bugs.python.org  Tue May  3 06:52:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 10:52:39 +0000
Subject: [docs] [issue26921] Incorrect usage of a/an articles in PEPs
In-Reply-To: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>
Message-ID: <20160503105234.100806.1068.0E7E1C4C@psf.io>


Roundup Robot added the comment:

New changeset d617c7ba4e14 by Serhiy Storchaka in branch 'default':
Issue #26921: Fixed a/an articles.
https://hg.python.org/peps/rev/d617c7ba4e14

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26921>
_______________________________________

From report at bugs.python.org  Tue May  3 06:53:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:53:07 +0000
Subject: [docs] [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <1462272787.28.0.247771910336.issue26916@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26916>
_______________________________________

From report at bugs.python.org  Tue May  3 06:53:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:53:51 +0000
Subject: [docs] [issue26921] Incorrect usage of a/an articles in PEPs
In-Reply-To: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>
Message-ID: <1462272831.78.0.249519892873.issue26921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for reviews Georg.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26921>
_______________________________________

From report at bugs.python.org  Tue May  3 12:59:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 03 May 2016 16:59:32 +0000
Subject: [docs] [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462294772.53.0.211492045273.issue26696@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26696>
_______________________________________

From christianyeganeh at gmail.com  Tue May  3 19:51:04 2016
From: christianyeganeh at gmail.com (Christian Yeganeh)
Date: Tue, 3 May 2016 19:51:04 -0400
Subject: [docs] Bug report
Message-ID: <096F4829-3F30-4113-B189-3FDBC8B120CD@gmail.com>

I have found a bug. Its small and not harmful. But its still there. If you take the string of a tuple, it will not always return the correct string. 
If you have a tuple with only one element and cast it using str() it will put the comma at the end of the string before the ) as if there was a second element. 

sample code:
>>> class testclass:
...     def __repr__(s): return 'a'
... 
>>> (1,2)[1:]
(2,)
>>> tuple([1])
(1,)
>>> tuple(['a'])
('a',)
>>> tuple(tuple([1]))
(1,)
>>> tuple([testclass(),1,'a'])[1:2]
(1,)
>>> (1,2,testclass())[2:]
(a,)
>>> #no matter what way you get it as lon as its a single element it includes the , after the element
... 
>>> #however with multiple elements
... 
>>> tuple([1,2])
(1, 2)
>>> (1,2)
(1, 2)
>>> (1,2,3)[1:]
(2, 3)

Christian Yeganeh

From georg at python.org  Wed May  4 01:21:18 2016
From: georg at python.org (Georg Brandl)
Date: Wed, 4 May 2016 07:21:18 +0200
Subject: [docs] Bug report
In-Reply-To: <096F4829-3F30-4113-B189-3FDBC8B120CD@gmail.com>
References: <096F4829-3F30-4113-B189-3FDBC8B120CD@gmail.com>
Message-ID: <7f843161-c7cc-30c9-2605-7d788da358f3@python.org>

On 05/04/2016 01:51 AM, Christian Yeganeh wrote:
> I have found a bug. Its small and not harmful. But its still there. If you take the string of a tuple, it will not always return the correct string. 
> If you have a tuple with only one element and cast it using str() it will put the comma at the end of the string before the ) as if there was a second element. 
> 
> sample code:
>>>> class testclass:
> ...     def __repr__(s): return 'a'
> ... 
>>>> (1,2)[1:]
> (2,)
>>>> tuple([1])
> (1,)
...

Hi Christian,

this is not a bug, but expected behavior: since 1-tuples are a valid type,
we have to distinguish them from simply parenthesized expressions by the
trailing comma.  You can see that when trying to write a 1-tuple literal:

>>> (1)
1
>>> (1,)
(1,)

And the repr output just mirrors the input syntax.

cheers,
Georg

BTW, trailing commas are also allowed whenever you have a comma-separated
list in Python.  Always using a trailing comma for line-by-line lists
helps in reducing diff churn and not forgetting the comma when adding
elements.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/docs/attachments/20160504/b4a46f80/attachment.sig>

From report at bugs.python.org  Wed May  4 07:08:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 11:08:46 +0000
Subject: [docs] [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462360126.11.0.767145593759.issue26696@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Add collections.abc.ByteString's document.

----------
keywords: +patch
Added file: http://bugs.python.org/file42711/ByteString_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26696>
_______________________________________

From report at bugs.python.org  Wed May  4 08:21:35 2016
From: report at bugs.python.org (mPython)
Date: Wed, 04 May 2016 12:21:35 +0000
Subject: [docs] [issue26947] Documentation improvement needed
Message-ID: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>


New submission from mPython:

On following page: https://docs.python.org/3/glossary.html#term-hashable sentence "All of Python?s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are." is not complete - probably a word "not" is needed on the end.

----------
assignee: docs at python
components: Documentation
messages: 264805
nosy: docs at python, mPython
priority: normal
severity: normal
status: open
title: Documentation improvement needed
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Wed May  4 09:15:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 13:15:53 +0000
Subject: [docs] [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462367753.34.0.203744385669.issue26947@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I think the original is OK. Adding "not" means the opposite.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Wed May  4 09:45:42 2016
From: report at bugs.python.org (Joni Bekenstein)
Date: Wed, 04 May 2016 13:45:42 +0000
Subject: [docs] [issue26950] Typo in unittest.mock > Autospeccing
 documentation
Message-ID: <1462369542.26.0.815413375703.issue26950@psf.upfronthosting.co.za>


New submission from Joni Bekenstein:

In several code examples from unittest.mock > Autospeccing documentation you will find "assret_called_with" instead of "assert_called_with".

----------
assignee: docs at python
components: Documentation
messages: 264815
nosy: Joni Bekenstein, docs at python
priority: normal
severity: normal
status: open
title: Typo in unittest.mock > Autospeccing documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26950>
_______________________________________

From report at bugs.python.org  Wed May  4 09:51:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 13:51:54 +0000
Subject: [docs] [issue26950] Typo in unittest.mock > Autospeccing
 documentation
In-Reply-To: <1462369542.26.0.815413375703.issue26950@psf.upfronthosting.co.za>
Message-ID: <1462369914.73.0.757541518714.issue26950@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but the typos are intentional. Quoting from the documentation:

    [...] if you misspell one of these assert methods then your assertion is gone:

    >>> mock = Mock(name='Thing', return_value=None)
    >>> mock(1, 2, 3)
    >>> mock.assret_called_once_with(4, 5, 6)

    Your tests can pass silently and incorrectly because of the typo.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26950>
_______________________________________

From report at bugs.python.org  Wed May  4 09:55:41 2016
From: report at bugs.python.org (Joni Bekenstein)
Date: Wed, 04 May 2016 13:55:41 +0000
Subject: [docs] [issue26950] Typo in unittest.mock > Autospeccing
 documentation
In-Reply-To: <1462369542.26.0.815413375703.issue26950@psf.upfronthosting.co.za>
Message-ID: <1462370141.84.0.440532600622.issue26950@psf.upfronthosting.co.za>


Joni Bekenstein added the comment:

My bad, didn't see the notice! Makes sense though. Sorry for opening an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26950>
_______________________________________

From report at bugs.python.org  Wed May  4 10:36:13 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 May 2016 14:36:13 +0000
Subject: [docs] [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462372573.27.0.293655183299.issue26947@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Xiang Zhang is correct: the original is technically correct. If you read it like this:

"All of Python?s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are [hashable]."

it should be clear. But if you have a suggestion for wording which is easier to understand (especially for those whose English is not so good) please say so.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Wed May  4 11:14:20 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 May 2016 15:14:20 +0000
Subject: [docs] [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462374860.54.0.117451696041.issue26947@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm a native speaker, and it's not the greatest sentence. How about:

All of Python?s immutable built-in objects (such as numbers, strings and tuples) are hashable. None of its mutable containers (such as lists or dictionaries) are hashable.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Wed May  4 12:08:02 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 May 2016 16:08:02 +0000
Subject: [docs] [issue26954] Add Guido's rejection notice to the "with" FAQ
Message-ID: <1462378082.17.0.472643239372.issue26954@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

The FAQs include a discussion of the rejected Pascal "with" statement (different from the Python `with`). From time to time people propose variants of it, such as using a leading dot to make it unambiguous.

Guido has just firmly rejected the latest such proposal. The FAQ should be updated to make it clear that even with a leading dot the proposal is dead, with a link to Guido's pronouncement.

https://mail.python.org/pipermail/python-ideas/2016-May/040070.html

----------
assignee: docs at python
components: Documentation
messages: 264832
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Add Guido's rejection notice to the "with" FAQ
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26954>
_______________________________________

From report at bugs.python.org  Wed May  4 13:00:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 May 2016 17:00:04 +0000
Subject: [docs] [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462381204.47.0.961860169861.issue26696@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26696>
_______________________________________

From report at bugs.python.org  Wed May  4 14:31:35 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 May 2016 18:31:35 +0000
Subject: [docs] [issue26951] Unintuitive error when using generator
 expression in class property
In-Reply-To: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>
Message-ID: <1462386695.01.0.276122412792.issue26951@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The outer for loop in a generator expression is evaluated immediately; everything after that is evaluated lazily. This was a deliberate design choice: see https://www.python.org/dev/peps/pep-0289/#early-binding-versus-late-binding for some rationale. This explains why you're able to access "B". The inability to access "C" is due to the usual rule for Python scope resolution: class scopes are skipped when examining nested scopes.

The early evaluation of the outermost for is covered in the docs, here: https://docs.python.org/2/reference/expressions.html#generator-expressions

"""
However, the leftmost for clause is immediately evaluated, so that an error produced by it can be seen before any other possible error in the code that handles the generator expression.
"""

So this behaviour is by design, though there may be a doc issue here. Changing components and versions accordingly.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, mark.dickinson
versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26951>
_______________________________________

From report at bugs.python.org  Wed May  4 15:03:30 2016
From: report at bugs.python.org (Alex Chan)
Date: Wed, 04 May 2016 19:03:30 +0000
Subject: [docs] [issue26957] Docs: remove duplicate "the" in description of
 `%z` in datetime docs
Message-ID: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>


New submission from Alex Chan:

The description of the `%z` format code in the datetime docs reads:

> UTC offset in the form +HHMM or -HHMM (empty string if the the object is naive).

This tiny patch removes the second "the".

The current wording goes at least as far back as Python 2.6; see https://docs.python.org/2.6/library/datetime.html?highlight=datetime#strftime-and-strptime-behavior.

----------
assignee: docs at python
components: Documentation
files: oneword.patch
keywords: patch
messages: 264848
nosy: alexwlchan, docs at python
priority: normal
severity: normal
status: open
title: Docs: remove duplicate "the" in description of `%z` in datetime docs
type: enhancement
Added file: http://bugs.python.org/file42719/oneword.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26957>
_______________________________________

From report at bugs.python.org  Wed May  4 16:25:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 20:25:52 +0000
Subject: [docs] [issue26957] Docs: remove duplicate "the" in description of
 `%z` in datetime docs
In-Reply-To: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>
Message-ID: <20160504202549.15727.16652.525839EC@psf.io>


Roundup Robot added the comment:

New changeset 580ddeccd689 by Berker Peksag in branch '3.5':
Issue #26957: Remove duplicate 'the' from datetime documentation
https://hg.python.org/cpython/rev/580ddeccd689

New changeset 3a069e5593ef by Berker Peksag in branch 'default':
Issue #26957: Remove duplicate 'the' from datetime documentation
https://hg.python.org/cpython/rev/3a069e5593ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26957>
_______________________________________

From report at bugs.python.org  Wed May  4 16:26:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 20:26:27 +0000
Subject: [docs] [issue26957] Docs: remove duplicate "the" in description of
 `%z` in datetime docs
In-Reply-To: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>
Message-ID: <1462393587.69.0.891330296544.issue26957@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26957>
_______________________________________

From report at bugs.python.org  Thu May  5 01:31:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 05 May 2016 05:31:52 +0000
Subject: [docs] [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462426312.42.0.130728377821.issue26947@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

As a non-native speaker, actually I prefer the original one. But both versions lead to no confusion for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Thu May  5 03:53:26 2016
From: report at bugs.python.org (Nathan Kerr)
Date: Thu, 05 May 2016 07:53:26 +0000
Subject: [docs] [issue26962] curses documenation- keys for Page Up and Page
 Down are reversed
Message-ID: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>


New submission from Nathan Kerr:

In the documentation for the curses module- 15.11 in Python 2.7 (https://docs.python.org/2.7/library/curses.html), the given key values for Page Up and Page Down are "KEY_NPAGE" and "KEY_PPAGE" respectively. These should be reversed.

This has been fixed in the documentation for 3.5 and 3.6 but not in the previous versions. See this bug report: http://bugs.python.org/issue26679

----------
assignee: docs at python
components: Documentation
messages: 264884
nosy: docs at python, nkerr
priority: normal
severity: normal
status: open
title: curses documenation- keys for Page Up and Page Down are reversed
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26962>
_______________________________________

From report at bugs.python.org  Thu May  5 03:56:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 07:56:14 +0000
Subject: [docs] [issue26962] curses documenation- keys for Page Up and Page
 Down are reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <1462434974.12.0.451048008512.issue26962@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, I forgot to update 2.7 (3.2, 3.3 and 3.4 are in security-fix-only mode so they don't get documentation updates anymore).

----------
nosy: +berker.peksag
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26962>
_______________________________________

From report at bugs.python.org  Thu May  5 04:05:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2016 08:05:41 +0000
Subject: [docs] [issue26962] curses documenation- keys for Page Up and Page
 Down are reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <20160505080532.21003.90248.D74AFC09@psf.io>


Roundup Robot added the comment:

New changeset 4462e193f089 by Berker Peksag in branch '2.7':
Issue #26962: Backport 23d986228c6b to 2.7
https://hg.python.org/cpython/rev/4462e193f089

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26962>
_______________________________________

From report at bugs.python.org  Thu May  5 04:06:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 08:06:10 +0000
Subject: [docs] [issue26962] curses documenation- keys for Page Up and Page
 Down are reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <1462435570.12.0.919244233774.issue26962@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26962>
_______________________________________

From report at bugs.python.org  Thu May  5 06:08:06 2016
From: report at bugs.python.org (mPython)
Date: Thu, 05 May 2016 10:08:06 +0000
Subject: [docs] [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462442886.91.0.753919377535.issue26947@psf.upfronthosting.co.za>


mPython added the comment:

Just to mention that I'm not native speaker, and I'm Django (Python) beginner. I'm very good in C++, Java and in last 12 years read a lot IT documentation. Mentioned sentence was not clear enough for me so I created this ticket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26947>
_______________________________________

From report at bugs.python.org  Thu May  5 13:06:37 2016
From: report at bugs.python.org (Olav Morken)
Date: Thu, 05 May 2016 17:06:37 +0000
Subject: [docs] [issue26964] Incorrect documentation for `-u`-flag
Message-ID: <1462467997.8.0.490878249706.issue26964@psf.upfronthosting.co.za>


New submission from Olav Morken:

The documentation for the `-u`-flag (https://docs.python.org/3/using/cmdline.html#cmdoption-u) contains:

> The text I/O layer will still be line-buffered if writing to the console, or block-buffered if redirected to a non-interactive file.

This does not appear to be the case -- instead it is always line-buffered:

https://hg.python.org/cpython/file/v3.5.1/Python/pylifecycle.c#l1041

Attached is a trivial patch that simply removes everything after "line-buffered".

----------
assignee: docs at python
components: Documentation
files: fix-doc-unbuffered.patch
keywords: patch
messages: 264910
nosy: docs at python, olavmrk
priority: normal
severity: normal
status: open
title: Incorrect documentation for `-u`-flag
Added file: http://bugs.python.org/file42736/fix-doc-unbuffered.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26964>
_______________________________________

From report at bugs.python.org  Thu May  5 17:47:44 2016
From: report at bugs.python.org (Robert Jordens)
Date: Thu, 05 May 2016 21:47:44 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462484864.19.0.115802555056.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

The original bug report is (apart from spelling) correct. This is a bug and it should be closed.

Please reopen.

This patch reverts the erroneous change in:

changeset:   96185:548d5704fcb3
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Thu May 21 11:50:30 2015 -0400
summary:     Issue 24180: Documentation for PEP 492 changes.

----------
keywords: +patch
nosy: +Robert.Jordens
Added file: http://bugs.python.org/file42740/issue26156_power.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Thu May  5 17:51:43 2016
From: report at bugs.python.org (Robert Jordens)
Date: Thu, 05 May 2016 21:51:43 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462485103.43.0.723251234855.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

That should have read "... should _not_ be closed."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Thu May  5 17:59:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2016 21:59:14 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462485554.98.0.227346114413.issue26156@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: not a bug -> 
stage: resolved -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:30:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:30:30 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509030.66.0.59703116191.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The docs looks correct to me. It reflects the fact that the "await" keyword has higher priority than the power operator. "await a ** b" is identical to "(await a) ** b", not "await (a ** b)".

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:32:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 04:32:13 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1462509030.66.0.59703116191.issue26156@psf.upfronthosting.co.za>
Message-ID: <F07DA0DFF279E4B6.9677DFB0-DA4C-45A9-B28A-8DE4FA07C5AD@mail.outlook.com>


Yury Selivanov added the comment:

Fwiw, I'm -1 on changing this. I think that the current names are correct.

----------
nosy: +Yury.Selivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:41:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:41:23 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509683.44.0.312262232847.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But to avoid confusion I propose following patch. This may be more correct, since it is strange to name the expression without "await" "await expression".

----------
Added file: http://bugs.python.org/file42741/issue26156_await_power.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:45:44 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 May 2016 04:45:44 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509944.3.0.95226144861.issue26156@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I agree that what is currently in the docs is technically correct.  The section on the power operator:

   power ::=  await ["**" u_expr]

should be read as:

   power ::=  (["await"] primary) ["**" u_expr]

just as the definition of 'u_expr' below should be read as:

   u_expr ::=  (await ["**" u_expr]) | "-" u_expr | "+" u_expr | "~" u_expr

and 'await' should be read as:

   await ::= ["await"] (atom | attributeref | subscription | slicing | call)

Each definition builds upon previous ones.

However, it is confusing.  Could a name other than "await" be used, since "await" is easily confused with the keyword await?

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:49:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:49:04 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462510143.93.0.0778430480049.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be "w_expr"? ("a_expr" is already used for addition level).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:50:30 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 04:50:30 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462510230.05.0.705361872637.issue26156@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Let's call it "await_expr"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 00:59:55 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 May 2016 04:59:55 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1462510230.05.0.705361872637.issue26156@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MKvSK4upB3d2vcWfVgdOy1cYOak4CEEbfin4=shq8zCw@mail.gmail.com>


Zachary Ware added the comment:

+1 for await_expr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 02:10:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 06:10:41 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462515041.44.0.881249064933.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The confusion is in the definition of await expression with optional "await". Without "await" the expression doesn't suspend the execution of coroutine. And await expression can only be used inside a coroutine function, but the power operator can be used outside.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 03:40:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:40:09 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462520409.09.0.437184323867.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one difference is that kwargs can be NULL in C function if no keyword arguments are supplied.

Here is a patch that adds tests for exact types of args and kwargs arguments in C functions.

I think that we should keep passing NULL as kwargs for performance reasons. But shouldn't we convert dict subclass to exact dict? I think there are good reasons to do this. Some functions can save kwargs for latter use. And this makes the implementation more consistent with PyPy.

If defaultdict behavior is needed for formatting, there is format_map().

----------
keywords: +patch
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file42742/test_args_kwargs_types.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 03:51:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:51:07 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462521067.44.0.709005115434.issue18531@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Removed file: http://bugs.python.org/file42742/test_args_kwargs_types.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 03:51:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:51:20 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462521080.79.0.125417501603.issue18531@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


Added file: http://bugs.python.org/file42743/test_args_kwargs_types.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 04:30:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 08:30:46 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462523446.15.0.323221716366.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch converts var-keyword arguments to exact dict. Since it changes the behavior of str.format() it can be pushed only in 3.6.

----------
Added file: http://bugs.python.org/file42746/ceval_kwargs_exact_dict.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 06:31:22 2016
From: report at bugs.python.org (Robert Jordens)
Date: Fri, 06 May 2016 10:31:22 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462530682.4.0.378788589104.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

Ack to the new patch. It is semantically confusing that the await expression also served as the power base without any await.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 07:50:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 11:50:41 +0000
Subject: [docs] [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1462535441.78.0.699078646026.issue17888@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue17888.patch looks good to me. I'd probably remove the "necessary skills" part.

----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17888>
_______________________________________

From report at bugs.python.org  Fri May  6 08:35:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:35:27 +0000
Subject: [docs] [issue18841] math.isfinite fails with Decimal sNAN
In-Reply-To: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>
Message-ID: <1462538127.14.0.308638172903.issue18841@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18841>
_______________________________________

From report at bugs.python.org  Fri May  6 08:40:01 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 May 2016 12:40:01 +0000
Subject: [docs] [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1462538401.13.0.509963869788.issue17888@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17888>
_______________________________________

From report at bugs.python.org  Fri May  6 09:04:57 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 13:04:57 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462539897.75.0.406419074119.issue26156@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds like it is a bit more than just confusion: given that power can be used outside a coroutine but await can't, Serhiy's formulation would seem to me to be more semantically correct, even if syntactically it is the same as the current.

I think it would regardless be better to replace 'await' with 'await_expr', so +1 on that from me as well.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 11:20:45 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:20:45 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462548045.4.0.778833803664.issue18531@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 11:21:26 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:21:26 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462548086.3.0.93761099268.issue18531@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Eric should chime in on the str.format() implications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 11:41:16 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2016 15:41:16 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462549276.26.0.577648619085.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think it's okay to change this as far as str.format() goes.

Interestingly enough, the motivating case to add str.format_map() in issue 6081 was exactly this kind of code. Although I notice that the example in that issue, which it shows as failing, works in both 2.7 and 3.4 (the only versions I have handy). So I'm not sure what changed after 2009 to cause that code to start working, but I'd be okay with it breaking again. But maybe we should track it down, in case it was deliberately changed and is important to someone.

In any event, since str.format_map() is well-known (to me, at least!), and is the approved way of getting the behavior of passing a specific map in to the format machinery, I'm okay with changing **dict to create an exact new dict, at least as far as str.format() goes. I can't speak to the overall implications (such as other APIs and performance).

I agree it would be a 3.6 only change (and I've change the versions to reflect that).

----------
versions:  -Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 11:46:32 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:46:32 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1462549276.26.0.577648619085.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160506104627.1e7e1ddc@python.org>


Barry A. Warsaw added the comment:

On May 06, 2016, at 03:41 PM, Eric V. Smith wrote:

>I agree it would be a 3.6 only change (and I've change the versions to
>reflect that).

The reason the other versions were included was because this was originally
reported as a documentation bug.  It should probably still be documented in
those older releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 12:45:22 2016
From: report at bugs.python.org (Guido Treutwein)
Date: Fri, 06 May 2016 16:45:22 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1462539897.75.0.406419074119.issue26156@psf.upfronthosting.co.za>
Message-ID: <CADE0f3xgd-K4qU=VO-pMFLwBf1NM2VXNghwjAGP-A8NtEzmBMA@mail.gmail.com>


Guido Treutwein added the comment:

I'm with David here, in that a change would improve ease of comprehension:
I still find it strange, that the grammar symbol has the same name as the
keyword (or in the proposed version keyword+'expr'), which is never done on
more widely used levels. I would have expected something like
'coroutine_suspension', which reflects what it is and not which keyword is
required to state it.

2016-05-06 15:04 GMT+02:00 R. David Murray <report at bugs.python.org>:

>
> R. David Murray added the comment:
>
> Sounds like it is a bit more than just confusion: given that power can be
> used outside a coroutine but await can't, Serhiy's formulation would seem
> to me to be more semantically correct, even if syntactically it is the same
> as the current.
>
> I think it would regardless be better to replace 'await' with
> 'await_expr', so +1 on that from me as well.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26156>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Fri May  6 12:52:37 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2016 16:52:37 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462553557.33.0.190050847831.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Okay. Adding back 3.5 and 2.7, in case someone wants to document the behavior there. I'm not sure if we fix docs in 3.4 still.

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Fri May  6 14:43:09 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 18:43:09 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462560189.4.0.317009490977.issue26889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is my first reading of this doc.  The formatting improvements look good.  A definite enhancement.

Review contains a few comments.  My main difficulty is separating creation of a proxy instance from use of a proxy instance.  Some of the creation parameters govern the use, and hence do not make must sense until one reads the instance description a few paragraphs further on.  
Perhaps the initial sentence "A :class:`ServerProxy` instance is an object that manages communication with aremote XML-RPC server." should be expanded into a paragraph with some of the description given later.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From storchaka at gmail.com  Fri May  6 15:29:47 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 06 May 2016 19:29:47 -0000
Subject: [docs] Improve Doc/library/xmlrpc.client.rst (issue 26889)
Message-ID: <20160506192947.27605.52600@psf.upfronthosting.co.za>


https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst
File Doc/library/xmlrpc.client.rst (right):

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode17
Doc/library/xmlrpc.client.rst:17: XML-RPC is a Remote Procedure Call
method that uses XML passed via HTTP as a
On 2016/05/06 20:36:41, terry.reedy wrote:
> HTTP(S) better?

Done.

Or may be HTTP/HTTPS?

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode49
Doc/library/xmlrpc.client.rst:49: 
On 2016/05/06 20:36:41, terry.reedy wrote:
> New blank line separates instance construction parameters above from
instance
> use parameters.  Good.  I think you could even something like "The
following
> parameters govern the use of the returned proxy instance."

Done.

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode53
Doc/library/xmlrpc.client.rst:53: all clients and servers; see
http://ontosys.com/xml-rpc/extensions.php for a
On 2016/05/06 20:36:41, terry.reedy wrote:
> New link displays page with "Wayback Machine doesn't have that page
archived." 
> Is any more description really needed? Can you just incorporate it?
> 
Rietveld included closing parenthesis in the link. Correct link:

https://web.archive.org/web/20130120074804/http://ontosys.com/xml-rpc/extensions.php

All resources (including Wikipedia) refer to this link. There is no more
"official" document. Apache provided longer list of extension types (see
issue26885), but this project is half-dead too.

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode76
Doc/library/xmlrpc.client.rst:76: 
On 2016/05/06 20:36:41, terry.reedy wrote:
> Not sure that deletion of sentence is an improvement.  See tracker
post.

This sentence just looks tautological or wrong to me. In Python 3 there
is no difference between types and classes (I suppose user-defined
classic classes were meant here). ServerProxy instance methods can't
take or return types. They work with instances of specific types. And if
we left just "Python objects", what other this can be? In Python
everything is an object, and every value is a Python object.

I was unable to reformulate this sentence correctly and preferred to
remove it.

https://bugs.python.org/review/26889/

From report at bugs.python.org  Fri May  6 15:46:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 19:46:53 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462564012.74.0.0678017319739.issue26889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Terry. Updated patch addresses most of your comments. But I'm unable to expand ServerProxy description as you suggest. May you can do this? My purpose was modest. Just fix some incorrect and outdated sentences. Then I fixed some formatting. I was not going and is not able to do anything besides this. I will take all that you offer.

----------
Added file: http://bugs.python.org/file42763/docs_xmlrpc_client_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Fri May  6 18:26:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 22:26:39 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462573599.42.0.414436803477.issue26889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The corrected link works.  I agree with deleting a bad sentence if you cannot fix it.  I think you can go ahead and apply as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Sat May  7 01:45:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 05:45:36 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <20160507054533.22581.4847.2516F85C@psf.io>


Roundup Robot added the comment:

New changeset 04250fc723e6 by Serhiy Storchaka in branch '3.5':
Issue #26889: Tweaked xmlrpc.client documentation.
https://hg.python.org/cpython/rev/04250fc723e6

New changeset 9bdec549bad3 by Serhiy Storchaka in branch 'default':
Issue #26889: Tweaked xmlrpc.client documentation.
https://hg.python.org/cpython/rev/9bdec549bad3

New changeset fb5bd513751f by Serhiy Storchaka in branch '2.7':
Issue #26889: Tweaked xmlrpclib documentation.
https://hg.python.org/cpython/rev/fb5bd513751f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Sat May  7 01:46:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 05:46:29 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462599989.44.0.475062525149.issue26889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Terry.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Sat May  7 03:07:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 07:07:28 +0000
Subject: [docs] [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <20160507070724.15120.42780.9D9D3727@psf.io>


Roundup Robot added the comment:

New changeset 52924d962027 by Serhiy Storchaka in branch '3.5':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/52924d962027

New changeset ea9d69a4d0fe by Serhiy Storchaka in branch 'default':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/ea9d69a4d0fe

New changeset 29a927c524cb by Serhiy Storchaka in branch '2.7':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/29a927c524cb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26889>
_______________________________________

From report at bugs.python.org  Sat May  7 03:19:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 07:19:32 +0000
Subject: [docs] [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462605571.99.0.747513280445.issue26736@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sat May  7 03:50:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 07:50:43 +0000
Subject: [docs] [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <20160507075040.15124.39200.5C34A6C2@psf.io>


Roundup Robot added the comment:

New changeset 211a9f32dfb9 by Serhiy Storchaka in branch '3.5':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/211a9f32dfb9

New changeset 3ceb54a49387 by Serhiy Storchaka in branch 'default':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/3ceb54a49387

New changeset e3af25d70976 by Serhiy Storchaka in branch '2.7':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/e3af25d70976

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sat May  7 04:06:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 08:06:05 +0000
Subject: [docs] [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462608365.59.0.360114844167.issue26736@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The :rfc: and :pep: roles are defined in Sphinx. I don't know if they can be configured to use HTTPS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sat May  7 04:13:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 08:13:57 +0000
Subject: [docs] [issue19444] mmap.mmap() allocates a file descriptor that
 isn't CLOEXEC
In-Reply-To: <1383110349.25.0.857290073089.issue19444@psf.upfronthosting.co.za>
Message-ID: <1462608837.09.0.666868297286.issue19444@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closing because Victor has proposed a patch in Issue 26769.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python 2.7: make private file descriptors non inheritable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19444>
_______________________________________

From report at bugs.python.org  Sat May  7 04:51:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 08:51:45 +0000
Subject: [docs] [issue26897] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1462611105.44.0.128884284231.issue26897@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, in all cases I understand it is just the file descriptor that matters. Perhaps any documentation update could also take Issue 24358 into account, which points out that compressed and buffered file object wrappers also cause inconsistencies in the data at the high-level file object and the OS-level file descriptor.

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26897>
_______________________________________

From report at bugs.python.org  Sat May  7 05:27:18 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 May 2016 09:27:18 +0000
Subject: [docs] [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462613238.02.0.956363092039.issue26736@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Newer Sphinx versions already redefine docutils' RFC and PEP URLs to use https.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sat May  7 10:25:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 14:25:21 +0000
Subject: [docs] [issue11643] Use |version| instead of X.Y in the doc
In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za>
Message-ID: <1462631120.89.0.0216256185406.issue11643@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with ?ric.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11643>
_______________________________________

From report at bugs.python.org  Sat May  7 10:47:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 14:47:01 +0000
Subject: [docs] [issue18730] suffix parameter in NamedTemporaryFile silently
 fails when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462632421.03.0.392339426315.issue18730@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage: needs patch -> patch review
type: behavior -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat May  7 15:02:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 19:02:41 +0000
Subject: [docs] [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1462647761.59.0.692613008726.issue12290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually this wording is not quite correct. __setstate__() is called for any pickled state. It is not called only if the state is not pickled. The state is not pickled if reducing method (__reduce_ex__ or __reduce__) doesn't return state or returns None as a state. Default reducing method for protocol 0 and 1 doesn't return a state if __getstate__() returns false value.

There are many other details of pickle protocol that are not correctly documented in the documentation of the pickle module. PEP 307 documents pickle protocol more correctly.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12290>
_______________________________________

From report at bugs.python.org  Sat May  7 18:44:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 22:44:46 +0000
Subject: [docs] [issue18730] suffix parameter in NamedTemporaryFile silently
 fails when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462661086.29.0.382611825108.issue18730@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Terry may have had the mkstemp() doc string in mind. The NamedTemporaryFile() doc string already points to that function, and it doesn?t make sense to single NamedTemporaryFile() out above other functions.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sat May  7 19:37:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 23:37:16 +0000
Subject: [docs] [issue18730] suffix parameter in NamedTemporaryFile silently
 fails when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462664235.99.0.962404915598.issue18730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Correct.  The doc I quoted was for the unlying mkstemp function.  I should have said so even though this fact was easily discovered. So by docstring, I meant the one for mkstemp also, which is currently 27 lines.  The docstring for the high level functions should not change.

I proposed to shorten the docstring by combining the sentences for prefix and suffix, while adding a bit of info.  I decided to withdraw this suggestion and close this issue.

----------
assignee: docs at python -> terry.reedy
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18730>
_______________________________________

From report at bugs.python.org  Sun May  8 07:59:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 11:59:32 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <20160508115928.5176.5708.FF7D1360@psf.io>


Roundup Robot added the comment:

New changeset 9e29034a41fa by Martin Panter in branch '3.5':
Issue #26512: Clarify Integral; tidy up table of rounding functions
https://hg.python.org/cpython/rev/9e29034a41fa

New changeset a8883951b2ff by Martin Panter in branch 'default':
Issue #26512: Merge rounding doc from 3.5
https://hg.python.org/cpython/rev/a8883951b2ff

New changeset a69805edfadd by Martin Panter in branch '2.7':
Issue #26512: Clarify Integral; tidy up table of rounding functions
https://hg.python.org/cpython/rev/a69805edfadd

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From tjreedy at udel.edu  Fri May  6 14:36:41 2016
From: tjreedy at udel.edu (tjreedy at udel.edu)
Date: Fri, 06 May 2016 18:36:41 -0000
Subject: [docs] Improve Doc/library/xmlrpc.client.rst (issue 26889)
Message-ID: <20160506183641.27605.34651@psf.upfronthosting.co.za>


https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst
File Doc/library/xmlrpc.client.rst (right):

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode17
Doc/library/xmlrpc.client.rst:17: XML-RPC is a Remote Procedure Call
method that uses XML passed via HTTP as a
HTTP(S) better?

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode49
Doc/library/xmlrpc.client.rst:49: 
New blank line separates instance construction parameters above from
instance use parameters.  Good.  I think you could even something like
"The following parameters govern the use of the returned proxy
instance."

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode53
Doc/library/xmlrpc.client.rst:53: all clients and servers; see
http://ontosys.com/xml-rpc/extensions.php for a
New link displays page with "Wayback Machine doesn't have that page
archived."  Is any more description really needed? Can you just
incorporate it?

https://bugs.python.org/review/26889/diff/17111/Doc/library/xmlrpc.client.rst#newcode76
Doc/library/xmlrpc.client.rst:76: 
Not sure that deletion of sentence is an improvement.  See tracker post.

https://bugs.python.org/review/26889/

From report at bugs.python.org  Sun May  8 14:24:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:24:38 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
Message-ID: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a catch when convert static types to dynamic types using PyType_FromSpec(). tp_new is not inherited for static types whose base class is 'object' (see a comment in inherit_special() in Objects/typeobject.c:4569 for explanation). Such types left not callable and not pickleable unless tp_new is explicitly specified. But since PyType_FromSpec() creates heap types, tp_new is inherited from the base 'object' class. Converted types unexpectedly becomes callable and pickleable. Since object.__new__ wouldn't insure the invariants that the extension type's own factory function ensures, instantiated object can be in inconsistent state. Using it can lead to a crash. We already fallen two time in this catch with _tkinter (issue15721) and curses.panel (issue14936) modules (fixed in issue23815).

We should document this catch and a way to avoid it (explicitly set tp_new to NULL for the result of PyType_FromSpec()). Both the C API documentation and PEP 384 should be updated. Would be great if standard examples include a case of non-callable heap type.

As option we can introduce more handy way to set tp_new to NULL by adding {Py_tp_new, NULL} to slots array (currently this doesn't have any effect). But this is new feature.

----------
assignee: docs at python
components: Documentation
messages: 265152
nosy: docs at python, loewis, serhiy.storchaka
priority: high
severity: normal
status: open
title: The danger of PyType_FromSpec()
type: security
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26979>
_______________________________________

From report at bugs.python.org  Sun May  8 14:50:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:50:47 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462733447.36.0.100146659124.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think "await_expr" is good. It is not new that the keyword is a part of the grammar symbol name (yield_expression, comp_for, and_expr, or_test, lambda_expr).

----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 15:00:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 19:00:33 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <20160508190025.42555.10022.6A197E19@psf.io>


Roundup Robot added the comment:

New changeset e876ff4e9e95 by Serhiy Storchaka in branch '3.5':
Issue #26156: Make expressions grammar description more semantically correct.
https://hg.python.org/cpython/rev/e876ff4e9e95

New changeset 61e3160310ae by Serhiy Storchaka in branch 'default':
Issue #26156: Make expressions grammar description more semantically correct.
https://hg.python.org/cpython/rev/61e3160310ae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 15:01:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 19:01:01 +0000
Subject: [docs] [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462734061.07.0.426163081254.issue26156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 15:44:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 19:44:43 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462736683.58.0.818607854714.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

str.format() uses PyDict_GetItem() in 2.7, but PyObject_GetItem() in 3.x. A comment before:

        /* Use PyObject_GetItem instead of PyDict_GetItem because this
           code is no longer just used with kwargs. It might be passed
           a non-dict when called through format_map. */

Thus the behavior of str.format() was changed by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 16:37:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 20:37:07 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160508203704.22565.70437.B34AF344@psf.io>


Roundup Robot added the comment:

New changeset e4835b1ed7b1 by Serhiy Storchaka in branch 'default':
Issue #18531: Single var-keyword argument of dict subtype was passed
https://hg.python.org/cpython/rev/e4835b1ed7b1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 17:06:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 21:06:13 +0000
Subject: [docs] [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462741573.94.0.0995072717948.issue26736@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sun May  8 17:39:08 2016
From: report at bugs.python.org (texttheater)
Date: Sun, 08 May 2016 21:39:08 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
Message-ID: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>


New submission from texttheater:

The documentation does not say what this argument is for.

It says "See the BaseEventLoop.create_connection() method for parameters", but that method does not have a path argument.

The argument seems to be required unless the keyword argument sock is given.

----------
assignee: docs at python
components: Documentation
messages: 265170
nosy: docs at python, texttheater
priority: normal
severity: normal
status: open
title: The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26980>
_______________________________________

From report at bugs.python.org  Sun May  8 18:45:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 22:45:51 +0000
Subject: [docs] [issue26512] Vocabulary: Using "integral" in
 library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1462747551.46.0.906347744573.issue26512@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Sun May  8 18:59:31 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 May 2016 22:59:31 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462748371.54.0.509713333656.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm not sure PyObject_GetItem instead of PyDict_GetItem in 3.x completely explains things, because the code in issue 6081 also works in 2.7.

But I don't think it's terribly important in any event, as long as we understand the 3.x difference. Thanks for researching!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 21:11:51 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:11:51 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
Message-ID: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>


New submission from James Tatum:

In https://github.com/python/typeshed/issues/180, we discussed a slight ambiguity with PEP 484's mention of forward references. It wasn't entirely clear that they don't apply unless using function annotations. This patch attempts to clear up the ambiguity.

----------
assignee: docs at python
components: Documentation
files: forward_references.patch
keywords: patch
messages: 265177
nosy: James.Tatum, docs at python
priority: normal
severity: normal
status: open
title: Clarify forward annotations in PEP 484
Added file: http://bugs.python.org/file42785/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:15:37 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:15:37 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462756537.69.0.204453290124.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Removed file: http://bugs.python.org/file42785/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:15:53 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:15:53 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462756553.3.0.278790192275.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Added file: http://bugs.python.org/file42786/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:26:15 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:26:15 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462757175.51.0.141656682756.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Removed file: http://bugs.python.org/file42786/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:26:23 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:26:23 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462757183.17.0.423818974285.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Added file: http://bugs.python.org/file42787/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 23:53:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 03:53:21 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1462748371.54.0.509713333656.issue18531@psf.upfronthosting.co.za>
Message-ID: <2274620.McyHzD0X0O@raxxla>


Serhiy Storchaka added the comment:

> I'm not sure PyObject_GetItem instead of PyDict_GetItem in 3.x completely
> explains things, because the code in issue 6081 also works in 2.7.

It doesn't work to me in current develop 2.7.11+. What version did you test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 00:07:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 04:07:03 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462766823.45.0.0918771119535.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Now this is just the documentation issue. I think the change of the behavior in 3.6 should be documented too, but I even don't know where.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 00:08:37 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 May 2016 04:08:37 +0000
Subject: [docs] [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462766917.25.0.555491503731.issue26982@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: docs at python -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Mon May  9 08:13:23 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 May 2016 12:13:23 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462796003.77.0.508131021362.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops, sorry. I'm an idiot. I was running in a venv where python was python3. Checking with my installed 2.7.10, I see the expected error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 10:11:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 09 May 2016 14:11:42 +0000
Subject: [docs] [issue26985] Information about CodeType in inspect
 documentation is outdated
Message-ID: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Information about CodeType in inspect documentation is outdated. It lacks attributes: co_kwonlyargcount, co_freevars, co_cellvars. And co_flags lacks many more options. These also apply to the comments of inspect.iscode source code.

----------
assignee: docs at python
components: Documentation
messages: 265197
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Information about CodeType in inspect documentation is outdated
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26985>
_______________________________________

From report at bugs.python.org  Mon May  9 11:49:09 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 09 May 2016 15:49:09 +0000
Subject: [docs] [issue26986] Enhance PyFunction_New documentation
In-Reply-To: <1462808942.73.0.503495552069.issue26986@psf.upfronthosting.co.za>
Message-ID: <1462808949.24.0.192887020258.issue26986@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26986>
_______________________________________

From report at bugs.python.org  Mon May  9 23:09:39 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 03:09:39 +0000
Subject: [docs] [issue26985] Information about CodeType in inspect
 documentation is outdated
In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za>
Message-ID: <1462849779.21.0.0352104427385.issue26985@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Attach patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file42793/inspect_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26985>
_______________________________________

From report at bugs.python.org  Tue May 10 02:44:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 06:44:41 +0000
Subject: [docs] [issue26986] Enhance PyFunction_New documentation
In-Reply-To: <1462808942.73.0.503495552069.issue26986@psf.upfronthosting.co.za>
Message-ID: <20160510064435.89099.82323.6AB40599@psf.io>


Roundup Robot added the comment:

New changeset bfc4c57a0986 by Benjamin Peterson in branch '3.5':
improve PyFunction_New docs (closes #26986)
https://hg.python.org/cpython/rev/bfc4c57a0986

New changeset 71afeb15f617 by Benjamin Peterson in branch 'default':
merge 3.5 (#26986)
https://hg.python.org/cpython/rev/71afeb15f617

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26986>
_______________________________________

From report at bugs.python.org  Tue May 10 04:37:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 08:37:27 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1462869447.85.0.66685802088.issue23921@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From storchaka at gmail.com  Tue May 10 04:37:40 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Tue, 10 May 2016 08:37:40 -0000
Subject: [docs] Standardize documentation whitespace,
 formatting (issue 23921)
Message-ID: <20160510083740.14733.26926@psf.upfronthosting.co.za>


http://bugs.python.org/review/23921/diff/14579/Doc/faq/library.rst
File Doc/faq/library.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/faq/library.rst#newcode747
Doc/faq/library.rst:747: 
On 2016/01/07 02:41:26, vadmium wrote:
> Could probably drop this new blank line

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/faq/programming.rst#newcode668
Doc/faq/programming.rst:668: >>> print(b)
On 2016/03/02 08:04:04, Georg wrote:
> On 2016/01/07 02:41:26, vadmium wrote:
> > Why not add prompts to the lines above as well?
> 
> Yes, link this it's a bit inconsistent.

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/howto/logging-cookbook.rst
File Doc/howto/logging-cookbook.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/howto/logging-cookbook.rst#newcode742
Doc/howto/logging-cookbook.rst:742: root.setLevel(logging.DEBUG)  # send
all messages, for demo; no other level or filter logic applied.
On 2016/03/02 08:04:04, Georg wrote:
> this is probably too long a line (e.g. for PDF output), better move
the comment
> above the code

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/howto/urllib2.rst
File Doc/howto/urllib2.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/howto/urllib2.rst#newcode178
Doc/howto/urllib2.rst:178: values = {'name' : 'Michael Foord',
On 2016/03/02 08:04:04, Georg wrote:
> could also remove the spaces before ':' as well.

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/library/abc.rst
File Doc/library/abc.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/abc.rst#newcode92
Doc/library/abc.rst:92: 
On 2016/01/07 02:41:26, vadmium wrote:
> FWIW I think the existing compact form is fine. The methods don?t have
any
> substance, so separating them doesn?t buy much. But if you want to
make the
> style consistent with MyIterable, you need a blank line above
__getitem__() as
> well.

Done. Removed empty lines.

http://bugs.python.org/review/23921/diff/14579/Doc/library/locale.rst
File Doc/library/locale.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/locale.rst#newcode473
Doc/library/locale.rst:473: >>> locale.strcoll('f\xe4n', 'foo')       #
compare a string containing an umlaut
On 2016/03/02 08:04:04, Georg wrote:
> keep only 2 spaces, the line is already long

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/library/multiprocessing.rst
File Doc/library/multiprocessing.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/multiprocessing.rst#newcode2071
Doc/library/multiprocessing.rst:2071: print(result.get(timeout=1))      
  # prints "100" unless your computer is *very* slow
On 2016/03/02 08:04:04, Georg wrote:
> these lines are also too long.

Will be addressed in separate issue. Changes for this example are
reverted.

http://bugs.python.org/review/23921/diff/14579/Doc/library/optparse.rst
File Doc/library/optparse.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/optparse.rst#newcode1827
Doc/library/optparse.rst:1827: [...]
On 2016/03/02 08:04:04, Georg wrote:
> replace by a single ellipsis, I don't think we're using that style
anywhere else

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/library/tokenize.rst
File Doc/library/tokenize.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/tokenize.rst#newcode216
Doc/library/tokenize.rst:216: if toknum == NUMBER and '.' in tokval:    
    # replace NUMBER tokens
On 2016/03/02 08:04:04, Georg wrote:
> no, keep shorter line

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/library/urllib.request.rst
File Doc/library/urllib.request.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/library/urllib.request.rst#newcode1105
Doc/library/urllib.request.rst:1105: ...                             
data=b'This data is passed to stdin of the CGI')
On 2016/03/02 08:04:04, Georg wrote:
> this is also a case where the longer line may hurt

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst
File Doc/whatsnew/3.2.rst (left):

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#oldcode502
Doc/whatsnew/3.2.rst:502: 
On 2016/01/07 02:41:26, vadmium wrote:
> You could keep the blank line here to mirror the interactive
interpreter better

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst
File Doc/whatsnew/3.2.rst (right):

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1107
Doc/whatsnew/3.2.rst:1107: ...   b'G3805  storeroom  Main chassis    '
On 2016/01/07 02:41:26, vadmium wrote:
> Why not a four-space indent?

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1540
Doc/whatsnew/3.2.rst:1540: >>> os.chdir('mydata')                       
       # change to the source directory
On 2016/03/02 08:04:04, Georg wrote:
> again, too long lines here.

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1555
Doc/whatsnew/3.2.rst:1555: ...     name = 'xz',
On 2016/01/07 02:41:26, vadmium wrote:
> I think you could drop the space around the equal signs and make it
name='xz',
> etc.

Done.

http://bugs.python.org/review/23921/diff/14579/Doc/whatsnew/3.2.rst#newcode1882
Doc/whatsnew/3.2.rst:1882: 
On 2016/01/07 02:41:26, vadmium wrote:
> Add an extra ellipsis to imitate the interpreter better

Done.

http://bugs.python.org/review/23921/

From report at bugs.python.org  Tue May 10 05:02:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 09:02:53 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <20160510090248.15110.38801.0264ABCC@psf.io>


Roundup Robot added the comment:

New changeset 2b492ea961c1 by Serhiy Storchaka in branch '3.5':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/2b492ea961c1

New changeset 909099686e6e by Serhiy Storchaka in branch 'default':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/909099686e6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Tue May 10 06:46:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 10:46:11 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <20160510104607.42351.78213.756095A0@psf.io>


Roundup Robot added the comment:

New changeset be85897e6d58 by Serhiy Storchaka in branch '2.7':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/be85897e6d58

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Tue May 10 06:48:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 10:48:40 +0000
Subject: [docs] [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1462877320.03.0.486377811718.issue23921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed Martin's Georg's and my comments, resolved conflicts, stripped trailing spaces, backported to 2.7.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Wed May 11 06:40:33 2016
From: report at bugs.python.org (Martin Jones)
Date: Wed, 11 May 2016 10:40:33 +0000
Subject: [docs] [issue26997] Docs for pdb should note that __future__ magic
 doesn't work
Message-ID: <1462963233.92.0.988524057924.issue26997@psf.upfronthosting.co.za>


New submission from Martin Jones:

when debugging a program at the pdb prompt, attempting to import from the __future__ module appears successful, but actually doesn't work:

(Pdb) from __future__ import division
(Pdb) 2/3
0

This leads to inconsistencies between statements evaluated on the pdb prompt and those evaluated in the program, which can hamper debugging. It would be good to have a note added to the 2.7 documentation for pdb along the lines of:

Note: importing from the __future__ module does not work under pdb.

----------
assignee: docs at python
components: Documentation
messages: 265300
nosy: Martin Jones, docs at python
priority: normal
severity: normal
status: open
title: Docs for pdb should note that __future__ magic doesn't work
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26997>
_______________________________________

From report at bugs.python.org  Wed May 11 12:45:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 11 May 2016 16:45:55 +0000
Subject: [docs] [issue27000] improve document of filter
Message-ID: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

I think filter's doc can be improved[1]:

1. It doesn't mention ``bool``. ``bool`` is treated the same way as ``None``. It is not called. But this is not mentioned.
2. 'the identity function is assumed' is confusing, at least for me. It looks like when ``None`` is passed, *function* is set to a default func, lambda x: x. Then *function* is called and we identify the return value True or False. But this is not the truth. There is no default value and no function is applied. I think this should be deleted.

[1] https://docs.python.org/3/library/functions.html#filter

----------
assignee: docs at python
components: Documentation
files: filter_doc.patch
keywords: patch
messages: 265325
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: improve document of filter
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42818/filter_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:08:05 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 11 May 2016 17:08:05 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986485.4.0.93386714188.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

Aren't these both implementation details? As in, they only affect efficiency, not effect, right?

----------
nosy: +leewz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:08:31 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 11 May 2016 17:08:31 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986511.07.0.416278707361.issue27000@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

bool is not enough of a special case to call it out without confusing the issue. No, the bool constructor is not actually called. But it will still behave as if it was called for all intents and purpose, it just skips the reference counting shenanigans for the actual True/False singleton objects. Drawing a distinction might make people worry that it wouldn't invoke __len__ or __bool__ as normal.

Similarly, for all intents and purposes, your mental model of the identity function is mostly correct (I suspect the wording meant to use "function" in the mathematical sense, but it works either way). Yes, it never actually calls a function, but that's irrelevant to observed behavior. Your only mistake is in assuming the function actually returns the specific values True or False; no filter function needs to return True or False, they simply evaluate for truth or falsehood (that's why filter's docs use "true" and "false" to describe it, not "True" and "False"). filter(str.strip, list_of_strings) is perfectly legal, and yields those strings that contain non-whitespace characters.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:10:26 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 11 May 2016 17:10:26 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986626.04.0.268877561641.issue27000@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Franklin said it better: The only difference between documentation and behavior is invisible implementation details, which have no business being documented in any event (since they needlessly tie the hands of maintainers of CPython and other Python interpreters, while providing no useful benefit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:33:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 11 May 2016 17:33:10 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462987990.03.0.688601316815.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

First I have to clarify that my mistake is not in understanding but in writing. What I mean by 'identify the return value True or False' is actually what you say, 'evaluate for truth or falsehood'. I also notice the lowercase false and true in the doc. I know they are deliberate. Sorry about this.

For ``bool``, I almost agree with you now. Although I still think it's telling readers incorrect info in the second part. For ``bool``, it is not equivalent to ``(item for item in iterable if function(item))`` but ``(item for item in iterable if item)``. For CPython, you are not telling the truth.

And for identity function, I insist. I don't see any advantage with this sentence other than confusion. I don't think this will affect other implementation either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 15:14:19 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 May 2016 19:14:19 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462994059.82.0.184362502326.issue27000@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> bool is not enough of a special case to call it out without 
> confusing the issue.

I concur.  It would be easy to make the docs less usable by elaborating on this special case.  For the most part, a user should use None if they just want to test the truth value of the input.

The docs for filter() have been through a number of revisions and much discussion.  Let's not undo previous efforts.  For the most part, these docs have been successful in communicating what filter() does.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 15:55:27 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 11 May 2016 19:55:27 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462996527.39.0.0667398545983.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

> Although I still think it's telling readers incorrect info in the second part. For ``bool``, it is not equivalent to ``(item for item in iterable if function(item))`` but ``(item for item in iterable if item)``. For CPython, you are not telling the truth.

What do you mean by, "it is not equivalent"? Are you saying that the first one will give a different result from the second? In general, when interpreting an object in a boolean context, Python will do the "equivalent" of calling ``bool`` on it, where "equivalent" in the docs means "has the same result as". See, for example, the ``itertools`` docs:
https://docs.python.org/3/library/itertools.html#itertools.accumulate

--------

In this case:

If ``filter`` is passed ``None`` or ``bool``, it will call "PyObject_IsTrue" on the object.
    (https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L481)

"PyObject_IsTrue" is defined here:
    https://github.com/python/cpython/blob/6aea3c26a22c5d7e3ffa3d725d8d75dac0e1b83b/Objects/object.c#L1223

On the other hand, ``bool`` is defined here, as "PyBool_Type":
    https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L2686


"PyBool_Type" is defined here, with the ``bool.__new__`` function defined as "bool_new":
    https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L133

"bool_new" is defined here, using "PyObject_IsTrue":
    https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L43

Both "filter_next" and "bool_new" call "PyObject_IsTrue" and take 0 as False, positive as True, and negative as an error. So it's equivalent to calling ``bool``, but the "bool_new" call is sort of inlined.

Does that clear things up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 20:07:12 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 00:07:12 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463011632.32.0.275473578239.issue27000@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for wanting to improve the docs, but the docs are a specification of syntax and behavior, not of implementation.  So, the existing docs are correct, and changing them would over-specify the function.  Since Raymond has also voted for rejection, I'm closing this.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 22:07:54 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 02:07:54 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463018873.92.0.285402152037.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It's OK. Thanks for all your info and do learn. BTW, Franklin, I knew what will happen when ``bool`` is passed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 22:10:52 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Thu, 12 May 2016 02:10:52 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463019052.25.0.651545656144.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

In that case, I'm still wondering what you mean by "not equivalent". Are you saying there is code which will work only if the ``bool`` function is really called?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 22:24:00 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 02:24:00 +0000
Subject: [docs] [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463019840.6.0.959335987152.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Not about code, just the doc. In my opinion, if ``bool`` is not called it is definitely not equivalent to ``(item for item in iterable if function(item))``, which actually calls the function, even there is nothing different in the result. But, this is a rather subjective and not important now. I am OK with all your opinions. And considering other interpreters, leaving it untouched is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Thu May 12 06:14:07 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 10:14:07 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463048047.49.0.297094367952.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

Thanks that's really helpful

Having thought about it some more, I think if possible it'd be really so much better to actually 'fix' the behaviour for the unicode<->str standard codecs (i.e. not base64) rather than just documenting around it. The current behaviour is not only confusing but leads to bugs that are very easy to miss since the methods work correctly when given 7-bit ascii characters. 

I had a poke around in the python source but couldn't quite identify where it's happening - presumably there is somewhere in the str.encode('utf-8') implementation that first "decodes" the string and does so using the ascii codec. If it could be made to use the same encoding that was passed in (e.g. utf8) then this would end up being a no-op and there would be no unpleasant bugs that only appear when the input includes non-ascii characters. 

It would also allow X.encode('utf-8') to be called successfully whether X is already a str or is a unicode object, which would save callers having to explicitly check what kind of string they've been passed. 

Is anyone able to look into the code to see where this would need to be fixed and how difficult it would be to do? I have a feeling that once the line is located it might be quite a straightforward fix

Many thanks

----------
components: +Interpreter Core -Documentation
title: doc for unicode.decode and str.encode is unnecessarily confusing -> unicode.decode and str.encode are unnecessarily confusing for non-ascii

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 06:25:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 10:25:51 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463048750.98.0.485648980524.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that with the -3 option Python 2.7 already warns about incompatibilities. 

>>> 'abc'.encode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use codecs.encode() to handle arbitrary codecs
'YWJj\n'
>>> 'YWJj\n'.decode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use codecs.decode() to handle arbitrary codecs
'abc'
>>> u'abc'.decode('ascii')
__main__:1: DeprecationWarning: decoding Unicode is not supported in 3.x
u'abc'

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 07:02:53 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 11:02:53 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463050973.56.0.441119212211.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

yes the situation is loads better in python 3, this issue is specific to 2.x, but like many people sadly we're not able to move to 3 for the time being. 

Since making this mistake is quite common and there's some sensible behaviour that would make it disappear (resulting in ascii and non-ascii strings being treated the same way by these methods) I'd much prefer if we could actually fix it for python 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 07:20:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 11:20:01 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463052001.0.0.315580653394.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What do you propose? Note that str.encode() doesn't raise an exception. Ascii unicode and 8-bit strings are interchangeable. Ascii unicode strings can be packed in str for less memory consumption (see xmlrpclib or ElementTree), a lot of str constant are used in unicode context (like os.sep or empty string). Breaking str.encode() will break valid existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 07:42:07 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 11:42:07 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463053326.97.0.0990348505488.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

I'm proposing that str.encode() should _not_ throw a 'decode' exception  for non-ascii characters and be effectively a no-op, to match what it already does for ascii characters - which therefore shouldn't break behavior anyone will be depending on. This could be achieved by passing the encoding parameter through to the implicit decode() call (which is where the exception is coming from it appears), rather than (arbitrarily and surprisingly) using "ascii" (which of course sometimes works and sometimes doesn't depending on the input string)

Does that make sense?

If someone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8') is resulting in an implicit call to the equivalent of decode('ascii') (as suggested by the exception message) I think it'll be easier to discuss the details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 08:31:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 12:31:44 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463056303.99.0.690781462111.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If str.encode() raises a decoding exception, this is a programming bug. It would be bad to hide it.

FYI, the default encoding is not hardcoded 'ascii'. Google "Changing default encoding in Python". Maybe this will help in your program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From SlaterJ at sharpsec.com  Thu May 12 15:46:07 2016
From: SlaterJ at sharpsec.com (Slater, John)
Date: Thu, 12 May 2016 19:46:07 +0000
Subject: [docs] How do I install an interpreter?
Message-ID: <B1CA4077D0E0F647AB6BAB2B82E2373EE8F33DB9@NJMBXP03.sharpamericas.com>

Hello,

I'm in a bit of a pickle, so this is both a request and a doc bug report (possibly). Full disclosure: I can't code my way out of a wet paper bag. I've been given a somewhat critical python script to run on my windows box. I found this:

https://docs.python.org/2/faq/windows.html

And I got to the step where it says:

You should then see something like:
Python 2.7.3 (default, Apr 10 2012, 22.71:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

Well, I don't see that. So I'm guessing an interpreter isn't installed. Where do I get one?

Additionally: I would suggest your documentation needs a fork there that says: "Don't see something like this? Click here"

Just a helpful suggestion from a lost n00b.

Also, if you could get me some help on where to get an interpreter, that would be great too.

Thanks!

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160512/cbd2ea66/attachment.html>

From mail at timgolden.me.uk  Thu May 12 16:16:16 2016
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 12 May 2016 21:16:16 +0100
Subject: [docs] How do I install an interpreter?
In-Reply-To: <B1CA4077D0E0F647AB6BAB2B82E2373EE8F33DB9@NJMBXP03.sharpamericas.com>
References: <B1CA4077D0E0F647AB6BAB2B82E2373EE8F33DB9@NJMBXP03.sharpamericas.com>
Message-ID: <5734E490.1010009@timgolden.me.uk>

On 12/05/2016 20:46, Slater, John wrote:
> Hello,
>
> I?m in a bit of a pickle, so this is both a request and a doc bug report
> (possibly). Full disclosure: I can?t code my way out of a wet paper bag.
> I?ve been given a somewhat critical python script to run on my windows
> box. I found this:
>
> https://docs.python.org/2/faq/windows.html
>
> And I got to the step where it says:
>
> You should then see something like:
>
> Python 2.7.3 (default, Apr 10 2012, 22.71:26) [MSC v.1500 32 bit
> (Intel)] on win32
>
> Type "help", "copyright", "credits" or "license" for more information.
>
>>>>
>
> Well, I don?t see that. So I?m guessing an interpreter isn?t installed.
> Where do I get one?
>
> Additionally: I would suggest your documentation needs a fork there that
> says: ?Don?t see something like this? Click here?
>
> Just a helpful suggestion from a lost n00b.
>
> Also, if you could get me some help on where to get an interpreter, that
> would be great too.

John,

You need to go to the Python downloads page:

https://www.python.org/downloads/

Select either 2.7.11 or 3.5.1 depending on whether you need Python 2 or 
Python 3. (They're very similar but there are differences and the 
chances are that any significant script will run with only one of them).

You'll then download get a typical installation package from which you 
can install Python. Having done that you can go back to the docs you 
were working from and you should see the interpreter.

If things don't work, can I suggest you head over to the Python tutor list:

   https://mail.python.org/mailman/listinfo/tutor

and ask there. This particular list (the docs@ address) is more for 
discussion about the documentation itself.

If you don't know which version to use (and if whoever gave you the 
script can't tell you) then post all or part of it here to the Tutor 
list and we can probably tell you which one you want.

TJG

From report at bugs.python.org  Fri May 13 07:42:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 11:42:31 +0000
Subject: [docs] [issue19992] subprocess documentation not explicit about
 fileno()
In-Reply-To: <1387158760.79.0.499761911724.issue19992@psf.upfronthosting.co.za>
Message-ID: <1463139751.91.0.624175242404.issue19992@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19992>
_______________________________________

From report at bugs.python.org  Sat May 14 06:24:37 2016
From: report at bugs.python.org (=?utf-8?q?Salvo_=E2=80=9CLtWorf=E2=80=9D_Tomaselli?=)
Date: Sat, 14 May 2016 10:24:37 +0000
Subject: [docs] [issue27018] Incorrect documentation of select module
Message-ID: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>


New submission from Salvo ?LtWorf? Tomaselli:

import select
help(select.epoll)

It mentions that the default mask is EPOLL_IN | EPOLL_OUT | EPOLL_PRI.

However there are no such constants.

They are called EPOLLIN EPOLLOUT and EPOLLPRI.

Please fix.

----------
assignee: docs at python
components: Documentation
messages: 265513
nosy: Salvo ?LtWorf? Tomaselli, docs at python
priority: normal
severity: normal
status: open
title: Incorrect documentation of select module
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sat May 14 06:55:31 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 May 2016 10:55:31 +0000
Subject: [docs] [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <1463223331.53.0.0694721636347.issue27018@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6
Added file: http://bugs.python.org/file42846/issue27018.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sat May 14 07:14:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:14:55 +0000
Subject: [docs] [issue25841] In FancyURLopener error in example with http
 address.
In-Reply-To: <1449848545.54.0.701964592914.issue25841@psf.upfronthosting.co.za>
Message-ID: <1463224495.66.0.967880580342.issue25841@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25841>
_______________________________________

From report at bugs.python.org  Sat May 14 07:51:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:51:49 +0000
Subject: [docs] [issue1705393] Document select() failure with buffered file
Message-ID: <1463226709.83.0.749244888699.issue1705393@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
title: Select() failure (race condition) -> Document select() failure with buffered file
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705393>
_______________________________________

From report at bugs.python.org  Sat May 14 13:34:06 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 14 May 2016 17:34:06 +0000
Subject: [docs] [issue27021] It is not documented that os.writev() suffer
 from SC_IOV_MAX
Message-ID: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>


New submission from ???? ?????????:

Really, os.writev() suffer from SC_IOV_MAX. This is documented for socket.sendmsg(), but not for os.writev():

The operating system may set a limit (sysconf() value SC_IOV_MAX) on the number of buffers that can be used.

----------
assignee: docs at python
components: Documentation
messages: 265537
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: It is not documented that os.writev() suffer from SC_IOV_MAX
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27021>
_______________________________________

From report at bugs.python.org  Sat May 14 13:39:43 2016
From: report at bugs.python.org (ProgVal)
Date: Sat, 14 May 2016 17:39:43 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
Message-ID: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>


New submission from ProgVal:

Documentation of tempfile.gettempdir() <https://docs.python.org/3/library/tempfile.html#tempfile.gettempdir> does not mention it only supports existing directories.

This led to this question on Stackoverflow: http://stackoverflow.com/q/37229398/539465

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 265539
nosy: Valentin.Lorentz, docs at python
priority: normal
severity: normal
status: open
title: Documentation of tempfile.gettempdir() does not mention it only supports existing directories
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sat May 14 21:05:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 01:05:47 +0000
Subject: [docs] [issue2675] Curses terminal resize problems when Python is
 in interactive mode
In-Reply-To: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>
Message-ID: <1463274347.82.0.497968921144.issue2675@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, this is my interpretation of Pavel?s demo:

If you press a key (other than lowercase ?q?) or resize the terminal, it displays the terminal dimensions in the top-left corner. Without Readline, the dimensions are updated when the terminal resizes.

When Readline is used (interactive mode, or simply ?import readline?), the reported dimensions are static, which I understand is the bug.

Documentating this quirk may be a good start.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, martin.panter
stage: test needed -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2675>
_______________________________________

From report at bugs.python.org  Sat May 14 22:38:54 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 15 May 2016 02:38:54 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463279934.29.0.936557286201.issue27023@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I don't understand. The documentation clearly states:

"Python searches a standard list of directories to find one which the calling user can create files in." How do you expect to be able to write files to a directory that doesn't exist?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 00:29:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 04:29:12 +0000
Subject: [docs] [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <20160515042909.19082.24603.86C70BC6@psf.io>


Roundup Robot added the comment:

New changeset 37c95a4b979a by Senthil Kumaran in branch '3.5':
issue27018 - Fix the documentation of select.epoll.register method.
https://hg.python.org/cpython/rev/37c95a4b979a

New changeset eca161a355d4 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/eca161a355d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sun May 15 00:30:12 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 May 2016 04:30:12 +0000
Subject: [docs] [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <1463286612.39.0.583802190824.issue27018@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report, Salvo.
And thank you for the patch, SilentGhost. This is fixed in the active versions of python.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sun May 15 03:08:12 2016
From: report at bugs.python.org (ProgVal)
Date: Sun, 15 May 2016 07:08:12 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463296092.72.0.805223247355.issue27023@psf.upfronthosting.co.za>


ProgVal added the comment:

The directory could be created

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 04:06:20 2016
From: report at bugs.python.org (Hong Minhee)
Date: Sun, 15 May 2016 08:06:20 +0000
Subject: [docs] [issue27026] async/await keywords are missing from reference
 docs
Message-ID: <1463299580.57.0.0973198258941.issue27026@psf.upfronthosting.co.za>


New submission from Hong Minhee:

The async/await keywords are missing from ?2.3.1. Keywords in reference docs.

The attached patch adds two missing keywords to Doc/reference/lexical_analysis.rst file.

----------
assignee: docs at python
components: Documentation
files: patch.diff
hgrepos: 343
keywords: patch
messages: 265593
nosy: docs at python, hongminhee
priority: normal
severity: normal
status: open
title: async/await keywords are missing from reference docs
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42856/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27026>
_______________________________________

From report at bugs.python.org  Sun May 15 05:12:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 09:12:15 +0000
Subject: [docs] [issue27026] async/await keywords are missing from reference
 docs
In-Reply-To: <1463299580.57.0.0973198258941.issue27026@psf.upfronthosting.co.za>
Message-ID: <1463303535.14.0.868489659894.issue27026@psf.upfronthosting.co.za>


Martin Panter added the comment:

..Related: Issue 26264, about updating the keywords module.

Technically they are only reserved inside ?async def? functions. So it could be misleading adding them with the other always-reserved keywords without an explanation.

----------
nosy: +martin.panter, yselivanov
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27026>
_______________________________________

From report at bugs.python.org  Sun May 15 11:32:51 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 15:32:51 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463326371.4.0.629487784659.issue27023@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, it shouldn't.

The design is that different systems use different locations for the default tempdir, and we look down a list of ones we know about until we find one that exists and can be used.  Likewise, different shells use different environment variables, so we look at a sequence of those as well.

It is arguable whether the fact that an environment variable that points to an invalid directory is ignored is a feature or a bug, but at this point tempfile has behaved that was for so long that we must class it as a feature.

In any case, I would find it objectionable for a program to create a temporary directory for me unasked.  It would be much more likely that I misspelled the directory when I set the environment variable.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 12:27:55 2016
From: report at bugs.python.org (ProgVal)
Date: Sun, 15 May 2016 16:27:55 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463329675.78.0.758918939415.issue27023@psf.upfronthosting.co.za>


ProgVal added the comment:

I know, that's why I did not ask to change the code. Only the doc to make that behavior more explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 12:45:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 16:45:40 +0000
Subject: [docs] [issue27023] Documentation of tempfile.gettempdir() does not
 mention it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463330740.16.0.749850802767.issue27023@psf.upfronthosting.co.za>


R. David Murray added the comment:

As Steve pointed out, the documentation is explicit: "to *find* one the user can craete files in".  You can't find something that doesn't yet exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Mon May 16 03:12:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 07:12:59 +0000
Subject: [docs] [issue18531] Undocumented different between METH_KEYWORDS
 and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160516071243.42363.1238.DA9399B3@psf.io>


Roundup Robot added the comment:

New changeset e3283b4ae61d by Serhiy Storchaka in branch '3.5':
Backported tests for issue #18531.
https://hg.python.org/cpython/rev/e3283b4ae61d

New changeset 621e0a3249c2 by Serhiy Storchaka in branch '2.7':
Backported tests for issue #18531.
https://hg.python.org/cpython/rev/621e0a3249c2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May 16 03:37:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 07:37:55 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463384275.88.0.971368171639.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

XML-RPC link was fixed in issue26889 (using the a web archive).

Left links are http://www.zope.com/, http://www.pythonlabs.com/logos.html, and links to dead projects. What can we do with Zope and PythonLabs links?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon May 16 04:30:07 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 May 2016 08:30:07 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463387407.85.0.924434849052.issue25910@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

zope should be http://www.zope.org/
The pythonlabs link could be removed.
The logos at pythonlabs link does not exist. Reference for pythonlab exists in a humorous form  here: http://www.pythonlabs.com/

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon May 16 04:33:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 08:33:49 +0000
Subject: [docs] [issue27036] Mark up of references in different form
Message-ID: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When there is a reference from the term in different form (e.g. in plural), the modified part can be appended outside of the reference: ":term:`bytes-like object`\ s". But this looks not very nice in rendered document, since only a part of the word is undescored. Proposed patch expands similar references to full words: ":term:`bytes-like objects <bytes-like object>`".

----------
assignee: docs at python
components: Documentation
files: refs_forms.patch
keywords: patch
messages: 265686
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark up of references in different form
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42869/refs_forms.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Mon May 16 05:32:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 09:32:20 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463391140.79.0.938192927262.issue27036@psf.upfronthosting.co.za>


Martin Panter added the comment:

These bug me too. For the changes like the bytes-like objects example, you have my full support.

But for the changes that modify identifier names, I think the both the old and the new versions are pretty bad. Example:

- . . . for some :exc:`SyntaxError`\ s.
+ . . . for some :exc:`SyntaxErrors <SyntaxError>`.

In Firefox, the new version renders as if it is talking about something literally called SyntaxErrors. It is only obvious that the exception is called SyntaxError when you hover the mouse, follow the link, etc.

I wonder if it would be better to find another way to write these kind of cases. E.g.:

* . . . for some syntax errors. [Just drop the link and markup.]
* . . . for some :exc:`SyntaxError` exceptions.

For cases like ?eval()uated?, would it be acceptable changing to ?evaluated with :func:`eval` ??

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From vadmium+py at gmail.com  Mon May 16 05:38:10 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 16 May 2016 09:38:10 -0000
Subject: [docs] Mark up of references in different form (issue 27036)
Message-ID: <20160516093810.18065.55701@psf.upfronthosting.co.za>


https://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst
File Doc/library/asyncore.rst (right):

https://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst#newcode104
Doc/library/asyncore.rst:104: :c:func:`polled <poll>` for read and write
events.
Would it hurt to just drop the markup? As far as I know it normally just
changes the font, and doesn?t make a link.

https://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerregistry.rst
File Doc/library/email.headerregistry.rst (right):

https://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerregistry.rst#newcode214
Doc/library/email.headerregistry.rst:214: ``decoded`` value is set by
:attr:`joining <~str.join>` the :class:`str` value of
I think you would have to drop the tilde (~) to get the link to work.
There are other changes that also have this problem.

But I don?t like this version any better than the original. What about
something like:

.?.?. is set to the concatenation of the :class:`str` value of each
element .?.?., using :meth:`str.join` and a separator of ``',?'``.

https://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst
File Doc/whatsnew/3.4.rst (right):

https://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst#newcode1116
Doc/whatsnew/3.4.rst:1116: mmap objects can now be :mod:`weakrefed
<weakref>`.  (Contributed by Valerie Lambert in
Should probably be spelt ?weakreffed? (refed means re-fed as in fed
again)

Maybe ?weakly referenced with :mod:`weakref` ?, or similar?

https://bugs.python.org/review/27036/

From report at bugs.python.org  Mon May 16 12:08:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:08:24 +0000
Subject: [docs] [issue27037] Universal newline support for
 zipFile.ZipExtFile.read() is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414904.08.0.602688679125.issue27037@psf.upfronthosting.co.za>


R. David Murray added the comment:

The decision was to deprecate 'U' *everywhere* in python3.

Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally.  That issue was deemed too disruptive to the codebase to address effectively, but in fixing things propery for python3 we apparently lost track of the 2.7 bug.

You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper.

The 2.7 documentation should be changed to address this issue and the solution.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:09:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:09:14 +0000
Subject: [docs] [issue27037] Universal newline support for
 zipFile.ZipExtFile.read() is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414954.57.0.499115935538.issue27037@psf.upfronthosting.co.za>


R. David Murray added the comment:

The decision was to deprecate 'U' *everywhere* in python3.

Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally.  That issue was deemed too disruptive to the codebase to address effectively, but in fixing things properly for python3 we apparently lost track of the 2.7 bug.

You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper.

The 2.7 documentation should be changed to address this issue and the solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:09:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:09:22 +0000
Subject: [docs] [issue27037] Universal newline support for
 zipFile.ZipExtFile.read() is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414962.75.0.0863740383451.issue27037@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg265705

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:12:38 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 16 May 2016 16:12:38 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463415158.69.0.303910403835.issue25910@psf.upfronthosting.co.za>


SilentGhost added the comment:

Does it not matter that the link to pythonlabs is a part of the official license text? Besides, it's not an actual html a tag, but rather a verbatim text, surely the only correction here is to make sure that the linkcheck doesn't check links within pre, code and similar tags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon May 16 12:44:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 May 2016 16:44:59 +0000
Subject: [docs] [issue26141] typing module documentation incomplete
In-Reply-To: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za>
Message-ID: <1463417099.86.0.728687978687.issue26141@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26141>
_______________________________________

From report at bugs.python.org  Mon May 16 16:34:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 20:34:36 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463430875.75.0.848577987139.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin! Absolutely agreed with you about references to classes and exceptions. I have removed this from the next version of the patch. I left your idea about ":exc:`SyntaxError` exceptions" for other patch.

?evaluated with :func:`eval` ? looks tautologically to me. In hypertext we can avoid the repetition.

----------
Added file: http://bugs.python.org/file42877/refs_forms2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From storchaka at gmail.com  Mon May 16 16:34:49 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Mon, 16 May 2016 20:34:49 -0000
Subject: [docs] Mark up of references in different form (issue 27036)
Message-ID: <20160516203449.12259.32973@psf.upfronthosting.co.za>

Reviewers: vadmium,


http://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst
File Doc/library/asyncore.rst (right):

http://bugs.python.org/review/27036/diff/17256/Doc/library/asyncore.rst#newcode104
Doc/library/asyncore.rst:104: :c:func:`polled <poll>` for read and write
events.
On 2016/05/16 11:38:10, vadmium wrote:
> Would it hurt to just drop the markup? As far as I know it normally
just changes
> the font, and doesn?t make a link.

Ah, I missed that this is just :c:func:. Maybe use references to
corresponding functions in the select module?

http://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerregistry.rst
File Doc/library/email.headerregistry.rst (right):

http://bugs.python.org/review/27036/diff/17256/Doc/library/email.headerregistry.rst#newcode214
Doc/library/email.headerregistry.rst:214: ``decoded`` value is set by
:attr:`joining <~str.join>` the :class:`str` value of
On 2016/05/16 11:38:10, vadmium wrote:
> I think you would have to drop the tilde (~) to get the link to work.
There are
> other changes that also have this problem.

Good catch!

> But I don?t like this version any better than the original. What about
something
> like:
> 
> .&nbsp;.&nbsp;. is set to the concatenation of the :class:`str` value
of each element
> .&nbsp;.&nbsp;., using :meth:`str.join` and a separator of
``',&nbsp;'``.

I don't know. I left this for David. Maybe this sentence should be
merged with the first sentence in this paragraph.

http://bugs.python.org/review/27036/diff/17256/Doc/library/threading.rst
File Doc/library/threading.rst (right):

http://bugs.python.org/review/27036/diff/17256/Doc/library/threading.rst#newcode272
Doc/library/threading.rst:272: A thread can be :meth:`joined
<~Thread.join>` many times.
Since there are multiple references to Thread.join in surrounding
paragraphs, I think it is better to remove this reference.

http://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst
File Doc/whatsnew/3.4.rst (right):

http://bugs.python.org/review/27036/diff/17256/Doc/whatsnew/3.4.rst#newcode1116
Doc/whatsnew/3.4.rst:1116: mmap objects can now be :mod:`weakrefed
<weakref>`.  (Contributed by Valerie Lambert in
On 2016/05/16 11:38:10, vadmium wrote:
> Should probably be spelt ?weakreffed? (refed means re-fed as in fed
again)
> 
> Maybe ?weakly referenced with :mod:`weakref` ?, or similar?

What about "mmap objects are now :mod:`weakly referenceable <weakref>`"?

Terms "weakly referenceable", "weak referenceable" and "weakly
referenced" are already used in the documentation.

See also yet one change in this file.



Please review this at http://bugs.python.org/review/27036/

Affected files:
  Doc/library/array.rst
  Doc/library/asyncore.rst
  Doc/library/audioop.rst
  Doc/library/base64.rst
  Doc/library/binascii.rst
  Doc/library/doctest.rst
  Doc/library/email.headerregistry.rst
  Doc/library/email.rst
  Doc/library/hashlib.rst
  Doc/library/http.cookies.rst
  Doc/library/logging.config.rst
  Doc/library/logging.rst
  Doc/library/nntplib.rst
  Doc/library/threading.rst
  Doc/library/urllib.request.rst
  Doc/whatsnew/3.4.rst


diff -r 3ceb54a49387 Doc/library/array.rst
--- a/Doc/library/array.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/array.rst	Sat May 07 14:38:30 2016 +0300
@@ -91,7 +91,7 @@ Array objects support the ordinary seque
 concatenation, and multiplication.  When using slice assignment, the assigned
 value must be an array object with the same type code; in all other cases,
 :exc:`TypeError` is raised. Array objects also implement the buffer interface,
-and may be used wherever :term:`bytes-like object`\ s are supported.
+and may be used wherever :term:`bytes-like objects <bytes-like object>` are supported.
 
 The following data items and methods are also supported:
 
diff -r 3ceb54a49387 Doc/library/asyncore.rst
--- a/Doc/library/asyncore.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/asyncore.rst	Sat May 07 14:38:30 2016 +0300
@@ -100,8 +100,8 @@ any that have been added to the map duri
 
    During asynchronous processing, each mapped channel's :meth:`readable` and
    :meth:`writable` methods are used to determine whether the channel's socket
-   should be added to the list of channels :c:func:`select`\ ed or
-   :c:func:`poll`\ ed for read and write events.
+   should be added to the list of channels :c:func:`selected <select>` or
+   :c:func:`polled <poll>` for read and write events.
 
    Thus, the set of channel events is larger than the basic socket events.  The
    full set of methods that can be overridden in your subclass follows:
diff -r 3ceb54a49387 Doc/library/audioop.rst
--- a/Doc/library/audioop.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/audioop.rst	Sat May 07 14:38:30 2016 +0300
@@ -7,7 +7,7 @@
 
 The :mod:`audioop` module contains some useful operations on sound fragments.
 It operates on sound fragments consisting of signed integer samples 8, 16, 24
-or 32 bits wide, stored in :term:`bytes-like object`\ s.  All scalar items are
+or 32 bits wide, stored in :term:`bytes-like objects <bytes-like object>`.  All scalar items are
 integers, unless specified otherwise.
 
 .. versionchanged:: 3.4
diff -r 3ceb54a49387 Doc/library/base64.rst
--- a/Doc/library/base64.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/base64.rst	Sat May 07 14:38:30 2016 +0300
@@ -40,7 +40,7 @@ package instead.
    the modern interface.
 
 .. versionchanged:: 3.4
-   Any :term:`bytes-like object`\ s are now accepted by all
+   Any :term:`bytes-like objects <bytes-like object>` are now accepted by all
    encoding and decoding functions in this module.  Ascii85/Base85 support added.
 
 The modern interface provides:
diff -r 3ceb54a49387 Doc/library/binascii.rst
--- a/Doc/library/binascii.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/binascii.rst	Sat May 07 14:38:30 2016 +0300
@@ -21,7 +21,7 @@ higher-level modules.
 .. note::
 
    ``a2b_*`` functions accept Unicode strings containing only ASCII characters.
-   Other functions only accept :term:`bytes-like object`\ s (such as
+   Other functions only accept :term:`bytes-like objects <bytes-like object>` (such as
    :class:`bytes`, :class:`bytearray` and other objects that support the buffer
    protocol).
 
diff -r 3ceb54a49387 Doc/library/doctest.rst
--- a/Doc/library/doctest.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/doctest.rst	Sat May 07 14:38:30 2016 +0300
@@ -464,12 +464,12 @@ Some details you should read once, but w
   exception name is ignored.
 
 * The interactive shell omits the traceback header line for some
-  :exc:`SyntaxError`\ s.  But doctest uses the traceback header line to
+  :exc:`SyntaxErrors <SyntaxError>`.  But doctest uses the traceback header line to
   distinguish exceptions from non-exceptions.  So in the rare case where you need
   to test a :exc:`SyntaxError` that omits the traceback header, you will need to
   manually add the traceback header line to your test example.
 
-* For some :exc:`SyntaxError`\ s, Python displays the character position of the
+* For some :exc:`SyntaxErrors <SyntaxError>`, Python displays the character position of the
   syntax error, using a ``^`` marker::
 
      >>> 1 1
@@ -1119,7 +1119,7 @@ the interactive examples extracted from 
 * :class:`Example`: A single Python :term:`statement`, paired with its expected
   output.
 
-* :class:`DocTest`: A collection of :class:`Example`\ s, typically extracted
+* :class:`DocTest`: A collection of :class:`Examples <Example>`, typically extracted
   from a single docstring or text file.
 
 Additional processing classes are defined to find, parse, and run, and check
@@ -1277,9 +1277,9 @@ DocTestFinder objects
 
 .. class:: DocTestFinder(verbose=False, parser=DocTestParser(), recurse=True, exclude_empty=True)
 
-   A processing class used to extract the :class:`DocTest`\ s that are relevant to
+   A processing class used to extract the :class:`DocTests <DocTest>` that are relevant to
    a given object, from its docstring and the docstrings of its contained objects.
-   :class:`DocTest`\ s can be extracted from modules, classes, functions,
+   :class:`DocTests <DocTest>` can be extracted from modules, classes, functions,
    methods, staticmethods, classmethods, and properties.
 
    The optional argument *verbose* can be used to display the objects searched by
@@ -1300,11 +1300,11 @@ DocTestFinder objects
 
    .. method:: find(obj[, name][, module][, globs][, extraglobs])
 
-      Return a list of the :class:`DocTest`\ s that are defined by *obj*'s
+      Return a list of the :class:`DocTests <DocTest>` that are defined by *obj*'s
       docstring, or by any of its contained objects' docstrings.
 
       The optional argument *name* specifies the object's name; this name will be
-      used to construct names for the returned :class:`DocTest`\ s.  If *name* is
+      used to construct names for the returned :class:`DocTests <DocTest>`.  If *name* is
       not specified, then ``obj.__name__`` is used.
 
       The optional parameter *module* is the module that contains the given object.
@@ -1370,8 +1370,8 @@ DocTestParser objects
    .. method:: parse(string, name='<string>')
 
       Divide the given string into examples and intervening text, and return them as
-      a list of alternating :class:`Example`\ s and strings. Line numbers for the
-      :class:`Example`\ s are 0-based.  The optional argument *name* is a name
+      a list of alternating :class:`Examples <Example>` and strings. Line numbers for the
+      :class:`Examples <Example>` are 0-based.  The optional argument *name* is a name
       identifying this string, and is only used for error messages.
 
 
diff -r 3ceb54a49387 Doc/library/email.headerregistry.rst
--- a/Doc/library/email.headerregistry.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/email.headerregistry.rst	Sat May 07 14:38:30 2016 +0300
@@ -211,7 +211,7 @@ headers.
 
    The ``decoded`` value of the header will have all encoded words decoded to
    unicode.  :class:`~encodings.idna` encoded domain names are also decoded to unicode.  The
-   ``decoded`` value is set by :attr:`~str.join`\ ing the :class:`str` value of
+   ``decoded`` value is set by :attr:`joining <~str.join>` the :class:`str` value of
    the elements of the ``groups`` attribute with ``', '``.
 
    A list of :class:`.Address` and :class:`.Group` objects in any combination
diff -r 3ceb54a49387 Doc/library/email.rst
--- a/Doc/library/email.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/email.rst	Sat May 07 14:38:30 2016 +0300
@@ -176,13 +176,13 @@ Here are the major differences between :
   Problems found while parsing messages are stored in the message's *defect*
   attribute.
 
-* All aspects of the API which raised :exc:`DeprecationWarning`\ s in version 2
+* All aspects of the API which raised :exc:`DeprecationWarnings <DeprecationWarning>` in version 2
   have been removed.  These include the *_encoder* argument to the
   :class:`~email.mime.text.MIMEText` constructor, the
   :meth:`Message.add_payload` method, the :func:`Utils.dump_address_pair`
   function, and the functions :func:`Utils.decode` and :func:`Utils.encode`.
 
-* New :exc:`DeprecationWarning`\ s have been added to:
+* New :exc:`DeprecationWarnings <DeprecationWarning>` have been added to:
   :meth:`Generator.__call__`, :meth:`Message.get_type`,
   :meth:`Message.get_main_type`, :meth:`Message.get_subtype`, and the *strict*
   argument to the :class:`~email.parser.Parser` class.  These are expected to
diff -r 3ceb54a49387 Doc/library/hashlib.rst
--- a/Doc/library/hashlib.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/hashlib.rst	Sat May 07 14:38:30 2016 +0300
@@ -41,7 +41,7 @@ Hash algorithms
 There is one constructor method named for each type of :dfn:`hash`.  All return
 a hash object with the same simple interface. For example: use :func:`sha1` to
 create a SHA1 hash object. You can now feed this object with :term:`bytes-like
-object`\ s (normally :class:`bytes`) using the :meth:`update` method.
+objects <bytes-like object>` (normally :class:`bytes`) using the :meth:`update` method.
 At any point you can ask it for the :dfn:`digest` of the
 concatenation of the data fed to it so far using the :meth:`digest` or
 :meth:`hexdigest` methods.
diff -r 3ceb54a49387 Doc/library/http.cookies.rst
--- a/Doc/library/http.cookies.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/http.cookies.rst	Sat May 07 14:38:30 2016 +0300
@@ -109,7 +109,7 @@ Cookie Objects
 .. method:: BaseCookie.load(rawdata)
 
    If *rawdata* is a string, parse it as an ``HTTP_COOKIE`` and add the values
-   found there as :class:`Morsel`\ s. If it is a dictionary, it is equivalent to::
+   found there as :class:`Morsels <Morsel>`. If it is a dictionary, it is equivalent to::
 
       for k, v in rawdata.items():
           cookie[k] = v
diff -r 3ceb54a49387 Doc/library/logging.config.rst
--- a/Doc/library/logging.config.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/logging.config.rst	Sat May 07 14:38:30 2016 +0300
@@ -647,7 +647,7 @@ root logger section is given below. ::
 
 The ``level`` entry can be one of ``DEBUG, INFO, WARNING, ERROR, CRITICAL`` or
 ``NOTSET``. For the root logger only, ``NOTSET`` means that all messages will be
-logged. Level values are :func:`eval`\ uated in the context of the ``logging``
+logged. Level values are :func:`evaluated <eval>` in the context of the ``logging``
 package's namespace.
 
 The ``handlers`` entry is a comma-separated list of handler names, which must
@@ -691,7 +691,7 @@ handler. If blank, a default formatter (
 If a name is specified, it must appear in the ``[formatters]`` section and have
 a corresponding section in the configuration file.
 
-The ``args`` entry, when :func:`eval`\ uated in the context of the ``logging``
+The ``args`` entry, when :func:`evaluated <eval>` in the context of the ``logging``
 package's namespace, is the list of arguments to the constructor for the handler
 class. Refer to the constructors for the relevant handlers, or to the examples
 below, to see how typical entries are constructed. ::
diff -r 3ceb54a49387 Doc/library/logging.rst
--- a/Doc/library/logging.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/logging.rst	Sat May 07 14:38:30 2016 +0300
@@ -217,7 +217,7 @@ is the module's name in the Python packa
    many contexts, and interesting conditions which arise are dependent on this
    context (such as remote client IP address and authenticated user name, in the
    above example). In such circumstances, it is likely that specialized
-   :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
+   :class:`Formatters <Formatter>` would be used with particular :class:`Handlers <Handler>`.
 
    .. versionadded:: 3.2
       The *stack_info* parameter was added.
@@ -972,7 +972,7 @@ functions.
    many contexts, and interesting conditions which arise are dependent on this
    context (such as remote client IP address and authenticated user name, in the
    above example). In such circumstances, it is likely that specialized
-   :class:`Formatter`\ s would be used with particular :class:`Handler`\ s.
+   :class:`Formatters <Formatter>` would be used with particular :class:`Handlers <Handler>`.
 
    .. versionadded:: 3.2
       The *stack_info* parameter was added.
diff -r 3ceb54a49387 Doc/library/nntplib.rst
--- a/Doc/library/nntplib.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/nntplib.rst	Sat May 07 14:38:30 2016 +0300
@@ -68,7 +68,7 @@ The module itself defines the following 
    authentication is performed.  Reader mode is sometimes necessary if you are
    connecting to an NNTP server on the local machine and intend to call
    reader-specific commands, such as ``group``.  If you get unexpected
-   :exc:`NNTPPermanentError`\ s, you might need to set *readermode*.
+   :exc:`NNTPPermanentErrors <NNTPPermanentError>`, you might need to set *readermode*.
    The :class:`NNTP` class supports the :keyword:`with` statement to
    unconditionally consume :exc:`OSError` exceptions and to close the NNTP
    connection when done, e.g.:
diff -r 3ceb54a49387 Doc/library/threading.rst
--- a/Doc/library/threading.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/threading.rst	Sat May 07 14:38:30 2016 +0300
@@ -197,7 +197,7 @@ There is the possibility that "dummy thr
 thread objects corresponding to "alien threads", which are threads of control
 started outside the threading module, such as directly from C code.  Dummy
 thread objects have limited functionality; they are always considered alive and
-daemonic, and cannot be :meth:`~Thread.join`\ ed.  They are never deleted,
+daemonic, and cannot be :meth:`joined <~Thread.join>`.  They are never deleted,
 since it is impossible to detect the termination of alien threads.
 
 
@@ -269,7 +269,7 @@ since it is impossible to detect the ter
       When the *timeout* argument is not present or ``None``, the operation will
       block until the thread terminates.
 
-      A thread can be :meth:`~Thread.join`\ ed many times.
+      A thread can be :meth:`joined <~Thread.join>` many times.
 
       :meth:`~Thread.join` raises a :exc:`RuntimeError` if an attempt is made
       to join the current thread as that would cause a deadlock. It is also
diff -r 3ceb54a49387 Doc/library/urllib.request.rst
--- a/Doc/library/urllib.request.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/library/urllib.request.rst	Sat May 07 14:38:30 2016 +0300
@@ -233,7 +233,7 @@ The following classes are provided:
 
 .. class:: OpenerDirector()
 
-   The :class:`OpenerDirector` class opens URLs via :class:`BaseHandler`\ s chained
+   The :class:`OpenerDirector` class opens URLs via :class:`BaseHandlers <BaseHandler>` chained
    together. It manages the chaining of handlers, and recovery from errors.
 
 
diff -r 3ceb54a49387 Doc/whatsnew/3.4.rst
--- a/Doc/whatsnew/3.4.rst	Sat May 07 10:49:58 2016 +0300
+++ b/Doc/whatsnew/3.4.rst	Sat May 07 14:38:30 2016 +0300
@@ -1113,7 +1113,7 @@ with additional speedups by Antoine Pitr
 mmap
 ----
 
-mmap objects can now be :mod:`weakref`\ ed.  (Contributed by Valerie Lambert in
+mmap objects can now be :mod:`weakrefed <weakref>`.  (Contributed by Valerie Lambert in
 :issue:`4885`.)
 
 
@@ -1136,7 +1136,7 @@ the start method.  (Contributed by Richa
 determines how child processes are created.  New function
 :func:`~multiprocessing.get_context` returns a context that uses a specified
 start method.  It has the same API as the :mod:`multiprocessing` module itself,
-so you can use it to create :class:`~multiprocessing.pool.Pool`\ s and other
+so you can use it to create :class:`Pools <~multiprocessing.pool.Pool>` and other
 objects that will operate within that context.  This allows a framework and an
 application or different parts of the same application to use multiprocessing
 without interfering with each other.  (Contributed by Richard Oudkerk in
@@ -1698,7 +1698,7 @@ will ensure that a given block of code e
 :mod:`logging` module.  By default the message can come from any logger and
 have a priority of ``INFO`` or higher, but both the logger name and an
 alternative minimum logging level may be specified.  The object returned by the
-context manager can be queried for the :class:`~logging.LogRecord`\ s and/or
+context manager can be queried for the :class:`LogRecords <~logging.LogRecord>` and/or
 formatted messages that were logged.  (Contributed by Antoine Pitrou in
 :issue:`18937`.)
 
@@ -2366,7 +2366,7 @@ Changes in the Python API
 * :func:`base64.b32decode` now raises a :exc:`binascii.Error` when the
   input string contains non-b32-alphabet characters, instead of a
   :exc:`TypeError`.  This particular :exc:`TypeError` was missed when the other
-  :exc:`TypeError`\ s were converted.  (Contributed by Serhiy Storchaka in
+  :exc:`TypeErrors <TypeError>` were converted.  (Contributed by Serhiy Storchaka in
   :issue:`18011`.)  Note: this change was also inadvertently applied in Python
   3.3.3.
 



From report at bugs.python.org  Mon May 16 16:40:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 20:40:51 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463431251.07.0.158605697058.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> zope should be http://www.zope.org/

Isn't this is a different legal entity?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon May 16 18:12:05 2016
From: report at bugs.python.org (Eric Wieser)
Date: Mon, 16 May 2016 22:12:05 +0000
Subject: [docs] [issue27042] Incorrect grammar for function definitions
Message-ID: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>


New submission from Eric Wieser:

https://docs.python.org/3.2/reference/compound_stmts.html#function-definitions 

and onwards say the following

    decorator      ::=  "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE

This is a regression from the 2.7 docs, which correctly said

    decorator      ::=  "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE

The implication is that the following is supposedly valid in python 3:

    @deco(what : "is this" = "supposed to mean")
    def foo(annotations: "are only for here" = "right?"):
        pass

The interpreter disagrees with the docs, and correctly rejects this syntax as garbage

----------
assignee: docs at python
components: Documentation
messages: 265735
nosy: Eric.Wieser, docs at python
priority: normal
severity: normal
status: open
title: Incorrect grammar for function definitions
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Mon May 16 20:42:37 2016
From: report at bugs.python.org (Ben Finney)
Date: Tue, 17 May 2016 00:42:37 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
Message-ID: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>


New submission from Ben Finney:

The library documentation for ?inspect.cleandoc? describes the transformation that occurs to ?the second line onwards?, but makes no mention of what processing occurs to the synopsis (first) line.

Please update the library documentation for this function, to explicitly describe how it processes each of the different parts of a docstring.

If possible, this should be guided by PEP 257's discussion of how indentation is transformed: https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

----------
assignee: docs at python
components: Documentation
messages: 265741
nosy: bignose, docs at python
priority: normal
severity: normal
status: open
title: Describe what ?inspect.cleandoc? does to synopsis line.
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Mon May 16 21:33:25 2016
From: report at bugs.python.org (Ed Doxtator)
Date: Tue, 17 May 2016 01:33:25 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
Message-ID: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>


New submission from Ed Doxtator:

In the documentation for pyvenv (https://docs.python.org/dev/library/venv.html), there is a table that shows by platform the command required to activate a virtual environment by OS.  For Windows, the values are:

Platform        Shell       Command to activate virtual environment
-------------------------------------------------------------------
Windows         cmd.exe     C:> <venv>/Scripts/activate.bat
  	        PowerShell  PS C:> <venv>/Scripts/Activate.ps1

The commands are incorrect-- they contain forward slashes and should be back slashes.

----------
assignee: docs at python
components: Documentation
messages: 265744
nosy: doc, docs at python
priority: normal
severity: normal
status: open
title: Forward slashes in Windows paths
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Mon May 16 21:38:25 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 01:38:25 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463449105.34.0.461106552867.issue27045@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Forward slashes work fine in Windows, for both the command line and PowerShell. Windows always displays backslahes, but accepts either (as well as any combination of both) in paths.

----------
assignee: docs at python -> 
nosy: +ebarry
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Mon May 16 21:48:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 01:48:34 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463449714.71.0.69953228537.issue27036@psf.upfronthosting.co.za>


Martin Panter added the comment:

It _would_ be nice to sort out the SyntaxErrors problem as well, but don?t let that stop fixing the easier problems. I would be interested in other people?s thoughts.

My problem with things like :func:`evaluated <eval>` is that the meaning is less clear, and it is not obvious what the hyperlink is for. If you print the sentence out, or casually look in a browser, there is not much indication that the function eval() is specified. Ugly as it is, ?eval()uated? is more obvious.

Other options that I would be happier with, if you want to avoid the repeated ?evaluated with eval()?, etc:

Level values are passed through :func:`eval`
list of channels waited with select() or poll()
The ``args`` entry, after passing through :func:`eval`
and :meth:`~Thread.join` cannot be called on them [dummy threads]
Module objects now support :mod:`weakref`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Mon May 16 23:18:37 2016
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 17 May 2016 03:18:37 +0000
Subject: [docs] [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463455117.17.0.43848511858.issue27042@psf.upfronthosting.co.za>


Eric Wieser added the comment:

The offending patch can be found at https://hg.python.org/cpython/rev/71ff2235bb4c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Mon May 16 23:46:01 2016
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 17 May 2016 03:46:01 +0000
Subject: [docs] [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463456761.21.0.223262164163.issue27042@psf.upfronthosting.co.za>


Eric Wieser added the comment:

The parent commit is also bad:

https://hg.python.org/cpython/rev/b65007ef59c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 01:58:03 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2016 05:58:03 +0000
Subject: [docs] [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463464683.86.0.140111480104.issue27042@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 02:20:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 06:20:48 +0000
Subject: [docs] [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <20160517062039.18014.28655.0D7982E7@psf.io>


Roundup Robot added the comment:

New changeset 451dd29ebae3 by Benjamin Peterson in branch '3.5':
Backed out changeset 71ff2235bb4c (closes #27042)
https://hg.python.org/cpython/rev/451dd29ebae3

New changeset d13999a6be8c by Benjamin Peterson in branch '3.5':
class definitions only get argument lists (closes #27042)
https://hg.python.org/cpython/rev/d13999a6be8c

New changeset d384bf58f5f8 by Benjamin Peterson in branch 'default':
merge 3.5 (#27042)
https://hg.python.org/cpython/rev/d384bf58f5f8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 03:13:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 07:13:32 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463469212.25.0.589124541614.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think you make an accent on wrong thing. All these sentences look correct to me if remove any hyperlinks. Hyperlinks are optional. In the phrase "Level values are evaluated" the reference is to the term "evaluating", not to the eval() function. But since this term is not in glossary and is explained only in eval() description, the reference points to the eval() function. The same is for "weakly referencable" and "joining". It would be more correct ton add explicit labels "evaluating", "weak reference" and "join" and use they in references (":ref:`evaluated <evaluating>`"). This would create links without changing the style of the text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Tue May 17 03:36:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 07:36:50 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463470610.76.0.505910898588.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, is it possible to refer to function without changing a style? Something like :ref:`evaluated <func:eval>`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Tue May 17 09:58:20 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2016 13:58:20 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1463431251.07.0.158605697058.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160517135814.GA44955@K2047>


Senthil Kumaran added the comment:

On Mon, May 16, 2016 at 08:40:51PM +0000, Serhiy Storchaka wrote:
> > zope should be http://www.zope.org/
> 
> Isn't this is a different legal entity?

Is it? I don't know. I can find no references to zope.com being
different than zope.org in my google searches and from wikipedia
article.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Tue May 17 11:34:09 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 May 2016 15:34:09 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463499249.61.0.669833099164.issue27036@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Not really, no. You have to add a :ref: target label for the function. If it's only a few instances, that should be manageable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Tue May 17 12:10:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2016 16:10:24 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463501424.07.0.422986543699.issue27045@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since windows users expect them to be backslahes, though, what's the motivation for using forward slashes instead?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From mail at timgolden.me.uk  Tue May 17 12:19:38 2016
From: mail at timgolden.me.uk (Tim Golden)
Date: Tue, 17 May 2016 17:19:38 +0100
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463501424.07.0.422986543699.issue27045@psf.upfronthosting.co.za>
References: <1463501424.07.0.422986543699.issue27045@psf.upfronthosting.co.za>
Message-ID: <573B449A.4010304@timgolden.me.uk>

I haven't tested everywhere but some versions of Windows don't in fact 
accept forward slashes on the cmd.exe command line. Suggest changing to 
backslashes as there's no reason to do otherwise.

From report at bugs.python.org  Tue May 17 12:25:27 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 17 May 2016 16:25:27 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463502327.11.0.994655100695.issue27045@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> docs at python
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:29:18 2016
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 May 2016 16:29:18 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463502558.39.0.441251755831.issue27045@psf.upfronthosting.co.za>


Tim Peters added the comment:

All versions of cmd.exe want backslashes in paths for the commands implemented _by_ cmd.exe - those interpret a forward slash as indicating an option.  For example, here on Win10 Pro:

C:\WINDOWS\system32>dir c:\Windows\System32\xwreg.dll
 Volume in drive C is OS
 Volume Serial Number is 5E8B-CFAC

 Directory of c:\Windows\System32

10/30/2015  02:17 AM           120,320 xwreg.dll
               1 File(s)        120,320 bytes
               0 Dir(s)  2,880,244,813,824 bytes free

`dir` is implemented by cmd.exe, so that example doesn't work with forward slashes:

C:\WINDOWS\system32>dir c:/Windows/System32/xwreg.dll
Parameter format not correct - "Windows".

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:35:07 2016
From: report at bugs.python.org (Tim Golden)
Date: Tue, 17 May 2016 16:35:07 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463502558.39.0.441251755831.issue27045@psf.upfronthosting.co.za>
Message-ID: <573B4832.4040206@timgolden.me.uk>


Tim Golden added the comment:

The key point here is that if I run the example as given on my Win 8.1 
box, it doesn't work. (The venv I'm using is called nw0).

d:\tim\.venvs>dir nw0\Scripts\activate.bat
  Volume in drive D is New Volume
  Volume Serial Number is 2639-22DA

  Directory of d:\tim\.venvs\nw0\Scripts

30/03/2016  07:45               547 activate.bat
                1 File(s)            547 bytes
                0 Dir(s)  458,354,536,448 bytes free

d:\tim\.venvs>
d:\tim\.venvs>nw0/Scripts/activate.bat
'nw0' is not recognized as an internal or external command,
operable program or batch file.

d:\tim\.venvs>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 20:56:45 2016
From: report at bugs.python.org (RoadrunnerWMC)
Date: Wed, 18 May 2016 00:56:45 +0000
Subject: [docs] [issue27049] Typo in "The Python Language Reference" 7.11 --
 "individiual"
Message-ID: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>


New submission from RoadrunnerWMC:

In the Python 3.3 documentation onward, in "The Python Language Reference" section 7.11 (https://docs.python.org/3/reference/simple_stmts.html#import), the following sentence appears:

    "When the statement contains multiple clauses (separated by commas) the two steps are carried out separately for each clause, just as though the clauses had been separated out into individiual import statements."

The word "individual" is misspelled there as "individiual."

----------
assignee: docs at python
components: Documentation
messages: 265795
nosy: RoadrunnerWMC, docs at python
priority: normal
severity: normal
status: open
title: Typo in "The Python Language Reference" 7.11 -- "individiual"
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27049>
_______________________________________

From report at bugs.python.org  Tue May 17 21:46:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 01:46:31 +0000
Subject: [docs] [issue27049] Typo in "The Python Language Reference" 7.11 --
 "individiual"
In-Reply-To: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>
Message-ID: <20160518014628.26077.99900.A82BB10A@psf.io>


Roundup Robot added the comment:

New changeset da67d32c2f74 by Ned Deily in branch '3.5':
Issue #27049: fix doc typo
https://hg.python.org/cpython/rev/da67d32c2f74

New changeset ba71905dd010 by Ned Deily in branch 'default':
Issue #27049: fix doc typo
https://hg.python.org/cpython/rev/ba71905dd010

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27049>
_______________________________________

From report at bugs.python.org  Tue May 17 21:48:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 May 2016 01:48:30 +0000
Subject: [docs] [issue27049] Typo in "The Python Language Reference" 7.11 --
 "individiual"
In-Reply-To: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>
Message-ID: <1463536110.86.0.233039774468.issue27049@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!  Fixed in 3.5 and later; Python 3.3 and 3.4 no longer receive documentation updates.

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: behavior -> 
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27049>
_______________________________________

From report at bugs.python.org  Tue May 17 23:51:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 03:51:24 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <20160518035121.26085.87422.F9949422@psf.io>


Roundup Robot added the comment:

New changeset e6e35ff744fe by Senthil Kumaran in branch '3.5':
issue27045 - Use backslash in windows path to script file.
https://hg.python.org/cpython/rev/e6e35ff744fe

New changeset 2173063cbae8 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/2173063cbae8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 23:53:16 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 18 May 2016 03:53:16 +0000
Subject: [docs] [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463543595.81.0.562102543128.issue27045@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

This is fixed and online docs will reflect it when they get built in their next build cycle. 

Thanks for the report.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Wed May 18 01:29:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 May 2016 05:29:52 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463549392.34.0.631952313047.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Likely revised structure:

* Move the high level convenience API back to the first section under a subheading like "Common operations"

* Give the new run() function its own subheading like "Flexible command invocation"

* Move the exception definitions to the Exceptions subheading

* give the stream constants their own subheading after "Frequently Used Arguments"

* consider whether or not the "Using the subprocess module" heading level is worthwhile, or whether it makes more sense to pull all its subheading up one level

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 03:48:10 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 18 May 2016 07:48:10 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463557690.38.0.216692400809.issue27050@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

FWIW i consider the whole subprocess module doc to be pretty unapproachable and in need of refactoring.  Your suggestions sound like good ones.  We should sit down and make it sane at pycon.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 04:08:41 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 18 May 2016 08:08:41 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463558921.57.0.714348440551.issue27050@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I'm obviously biased, but I find the 'high level convenience API' less convenient than the run() function: there are three different functions for the same basic operation, they're not clearly named (check_output is nothing to do with checking output), and there are things that should be simple but they can only do awkwardly (i.e. capturing both output and the exit code).

Once I can depend on Python >= 3.5, I hope to never use call/check_call/check_output again. Using run() might make code slightly longer, but I think it also makes it clearer. I accept that the trio can probably never be removed, but this is why I demoted them a long way down the docs.

Unfortunately I won't be at PyCon this year to discuss this.

----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 06:55:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 10:55:36 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <20160518105531.22475.90016.A213753F@psf.io>


Roundup Robot added the comment:

New changeset ef6d3a537cf5 by Serhiy Storchaka in branch '3.5':
Issue #27036: Fixed formatting references to "bytes-like object" in plural.
https://hg.python.org/cpython/rev/ef6d3a537cf5

New changeset d6b9a4c3f8ef by Serhiy Storchaka in branch 'default':
Issue #27036: Fixed formatting references to "bytes-like object" in plural.
https://hg.python.org/cpython/rev/d6b9a4c3f8ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Wed May 18 07:14:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 May 2016 11:14:53 +0000
Subject: [docs] [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463570092.87.0.262496210007.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Pushed a part about "bytes-like objects".

Here is a patch that adds explicit labels for referencing without changing the style.

----------
Added file: http://bugs.python.org/file42890/refs_forms3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Wed May 18 10:23:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 May 2016 14:23:40 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463581420.21.0.59859503516.issue27050@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just as a data point, I always found it confusing when viewing the subprocess docs that I had to page past the 'convenience functions' to get to what I consider to be the "real" docs, the docs for Popen.  I rarely use the convenience functions; I find it harder to remember how they work than just using Popen, and in any case I usually end up writing an application-specific 'cmd' function that uses Popen.  I haven't tried using run yet, so I don't really have an opinion on that.

I suppose its like carrying a swiss army knife in your pocket rather than carrying a steak knife, a pair of scissors, and a screwdriver.
If you were carrying a toolbox with *all* the tools, it might be different, but your choices are three tools or the swiss army knife, and to make matters worse those individual tools are really just the swiss army knife in disguise, but it looks different enough to be confusing.

Maybe having table of links at the start of the doc would be the most helpful, regardless of how the docs are re-organized.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 21:36:51 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2016 01:36:51 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463621811.03.0.321573194108.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For reference, http://bugs.python.org/issue13237 covers the original change to emphasise the convenience functions over the full flexibility of Popen. The intent behind that reorganisation was to make it straightforward to get started with the module without needing to first learn what a pipe is (or much of anything about command invocation other than the value of breaking things up into lists to ensure correct quoting). The direct link to the Popen docs in the introductory text was intended to make it easy for advanced users to skip directly to the full Popen docs.

In that context, the three convenience operations are "I don't really care if this works or not", "complain loudly if this doesn't work" and "capture the command output, while complaining loudly if it doesn't work". (Not coincidentally, these are roughly comparable to the operations supported by Perl's system() command and backtick expressions, only with exceptions taking the place of the "$?" magic variable)

Once a user understands what a pipe is well enough to have an opinion on the usefulness of operations other than the 3 basic ones, then I agree run() makes for a nice improvement over using Popen objects directly (thank you Thomas!), but it's still lower level than the convenience APIs (since you need more prior knowledge in order to use it effectively).

I do like David's suggestion of an introductory table providing quick links to the rest of the documentation. Something in the style of the itertools docs would likely be most suitable: https://docs.python.org/3/library/itertools.html

Also +1 on thrashing out the details at the PyCon US sprints, although I'll aim to put an initial draft together before then (so Thomas has a chance to comment on it)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 21:41:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2016 01:41:08 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463622068.63.0.516238787264.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As long as I'm refactoring these docs, I may also take a look at adding some notes about text vs binary handling, since that's still problematic as described in http://bugs.python.org/issue6135

The default behaviour is binary pipes, and setting "universal_newlines=True" switches to UTF-8 encoded text pipes, but anything else involves using binary pipes with separate encoding and decoding steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Thu May 19 02:18:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 06:18:55 +0000
Subject: [docs] [issue27037] Universal newline support for
 zipFile.ZipExtFile.read() is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463638735.62.0.072354229024.issue27037@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The support of the "U" mode will be removed in 3.6 (issue27029).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From storchaka at gmail.com  Thu May 19 02:45:20 2016
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Thu, 19 May 2016 06:45:20 -0000
Subject: [docs] Behavior of ZipFile with file-like object and
 BufferedWriter. (issue 20699)
Message-ID: <20160519064520.16271.35880@psf.upfronthosting.co.za>


http://bugs.python.org/review/20699/diff/16966/Doc/library/io.rst
File Doc/library/io.rst (right):

http://bugs.python.org/review/20699/diff/16966/Doc/library/io.rst#newcode597
Doc/library/io.rst:597: The argument *initial_bytes* is a
:term:`bytes-like object` that
Maybe "The optional argument"?

http://bugs.python.org/review/20699/diff/16966/Lib/_pyio.py
File Lib/_pyio.py (right):

http://bugs.python.org/review/20699/diff/16966/Lib/_pyio.py#newcode678
Lib/_pyio.py:678: """Read bytes into buffer *b*, using at most one
system call
Should this be unified with readinto()?

http://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py
File Lib/test/test_io.py (right):

http://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py#newcode320
Lib/test/test_io.py:320: self.assertEqual(memoryview(data).tobytes(), b"
worl")
Maybe just "bytes(data)"?

http://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py#newcode667
Lib/test/test_io.py:667: def make_file_writer():
Current testing code is 16 lines long, but if expand loop and inline
factories it would 15 lines long (and look more clear to me).

Yet more short and clear writing is:

def check(f):
    with f:
        self.assertEqual(f.write(a), n)
        f.writelines((a,))
check(self.BytesIO())
check(self.FileIO(support.TESTFN, "w"))
...

Only 9 lines!

http://bugs.python.org/review/20699/

From report at bugs.python.org  Thu May 19 02:46:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 06:46:06 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463640366.64.0.831493517524.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added few minor comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From netaoren19 at gmail.com  Thu May 19 04:35:34 2016
From: netaoren19 at gmail.com (Neta Oren)
Date: Thu, 19 May 2016 11:35:34 +0300
Subject: [docs] Regex documentation bug
Message-ID: <CAGJbGGpZwn5OfAOugv_0aONLqAAxeah1mtH1hi6mKLgqKgcvBw@mail.gmail.com>

Hi,
I was reading your documentation page about regex, and noticed you had a
mistake.
The specific page is 'Regular Expression HOWTO -- Python 2.7.11
documentation'.
It is located in the address:
https://docs.python.org/2/howto/regex.html
The mistake is at the 'Performing Matches' section.
The mistake is:
You wrote that the start() and end() methods will retnot end the starting
and ending indices of the match. However in the example you provided the
end index is in fact the length of the match, and not the ending index
(that would be length - 1).
If the index starts at 0 and ends at 11 then that means there are 12
characters, however in your examples it was not as such.
This can create array out of bounds exceptions and other exceptions as well.
This error is repeated in this section several times.
For your attention,
Neta
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160519/6f566b53/attachment-0001.html>

From report at bugs.python.org  Thu May 19 12:23:59 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 19 May 2016 16:23:59 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463675039.37.0.0219371069809.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

btw If anyone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8', error=X) is resulting in an implicit call to the equivalent of decode(defaultencoding, errors=strict) (as suggested by the exception message) I think it'll be easier to discuss the details of fixing.

Thanks for your reply - yes I'm aware that theoretically you _could_ globally change python's default encoding from ascii, but the prevailing view I've heard from python developers seems to be that changing it is not a good idea and may cause lots of library code to break. Also it's probably not a good idea for individual libraries or modules to be changing global state that affects the entire python invocation, and it would be nice to find a less fragile and more out-of-the-box solution to this. You may well be using different encodings (not just utf-8) to be used in different parts of your program - so changing the globally-defined default encoding doesn't seem right, especially for a method like str.encode method that already takes an 'encoding' argument (used currently only for the encoding aspect, not the decoding aspect). 

I do think there's a strong case to be made for changing the str.encode (and also unicode.decode) behaviour so that str.encode('utf-8') behaves the same whether it's given ascii or non-ascii characters, and also similar to unicode.encode('utf-8'). Let me try to persuade you... :)

First, to address the point you made:

> If str.encode() raises a decoding exception, this is a programming bug. It would be bad to hide it.

I totally agree with the general principal of not hiding programming bugs. However if calling str.encode for codecs like utf8 (let's ignore base64 for now, which is a very different beast) was *consistently* treated as a 'programming bug' by python and always resulted in an exception that would be ok (suboptimal usability imho, but still ok), since programmers would quickly spot the problem and fix it. But that's not what happens - it *silently works* (is a no-op) as long as you happen to be using ASCII characters so this so-called 'programming bug' will go unnoticed by most programmers (and authors of third party library code you might be relying on!)... but the moment a non-ascii character get introduced suddenly you'll get an exception, maybe in some library code you rely on but can't fix. For this reason I don't think treating this as a programming bug is helping anyone write more robust python code - quite the reverse. Plus I think the behaviour of being a no-op is almost always 'what you would have wanted it to do' anyway, whereas the behaviour of throwing an exception almost never is. 

I think we'd agree that changing str.encode(utf8) to throw an exception in *all* cases wouldn't be a realistic option since it would certainly break backwards compatability in painful ways for many existing apps and library code. 

So, if we want to make the behaviour of this important built-in type a bit more consistent and less error-prone/fragile for this case then I think the only option is making str.encode be a no-op for non-ascii characters (at least, non-ascii characters that are valid in the specified encoding), just as it is for ascii characters. 

Here's why I think ditching the current behaviour would be a good idea:
- calling str.encode() and getting a DecodeError is confusing ("I asked you to encode this string, what are you decoding for?")
- calling str.encode('utf-8') and getting an exception about "ascii" is confusing as the only encoding I mentioned in the method call was utf-8
- calling encode(..., errors=ignore) and getting an exception is confusing and feels like a bug; I've explicitly specified that I do NOT want exceptions from calling this method, yet (because neither 'errors' nor 'encoding' argument gets passed to the implicit - and undocumented - decode operation), I get unexpected behaviour that is far more likely to break my program than a no-op
- the somewhat surprising behaviour we're talking about is not explicitly documented anywhere
- having str.encode throw on non-ascii but not ascii makes it very likely that code will be written and shipped (including library code you may have no control over) that *appears* to work under normal testing but has *hidden* bugs that surface only once non-ascii characters are used. 
- in every situation I can think of, having str.encode(encoding, errors=ignore) honour the encoding and errors arguments even for the implicit-decode operation is more useful than having it ignore those arguments and throw an exception
- a quick google shows lots of people in the Python community (from newbies to experts) are seeing this exception and being confused by it, therefore a lot of people's lives might be improved if we can somehow make the situation better :)
- even with the best of intentions (and with code written by senior python programmers who understand unicode issues well) it's very difficult in practice to write non-trivial python programs that always consistently use the 'unicode' string type throughout (especially when legacy code or third party libraries are involved), so most 'real' code needs to cope with a mix of str and unicode types in practice. So when you need to write a 'basestring' out to a file, you'd like to be able to simply call the s.encode(myencoding, errors=whatever) method that exists on both str and unicode types and have it 'work' whether it's a str already in that encoding or a unicode object that needs to be converted. This is a common use case and the behaviour I'm suggesting would really help with this case. The alternative is that every python programmer who cares about non-ascii characters has to write an pleasant and un-pythonic if clause to give different behaviour based on __type__, in every place they need a byte str:
	if isinstance(s, unicode): 
		f.write(s.encode('utf-8', errors='ignore'))
	else:
		f.write(s)

nb: Although I've used the example of str.encode above, unicode.decode has the exact same issues (and potential solution), and of course this isn't specific to utf-8 but to all codecs that convert between str and unicode (i.e. most of them except base64). 

I hope you'll consider this proposal - it's probably not a very big change, is very unlikely to break any existing/working code, and has the potential to help reduce fragility and difficult-to-resolve bugs in an area of Python that seems to cause pain and confusion to lots of people.

Thanks for considering!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 13:32:48 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 19 May 2016 17:32:48 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463679168.38.0.24077455536.issue26369@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Ben, I'm sorry to see you have spent such a long time writing up reasons for changing this behaviour. I fear this is a total waste of your time, and ours to read it. Python 2.7 is under feature freeze, and changing the behaviour of str.encode and unicode.decode is a new feature. So it could only happen in 2.8, but there will never be a Python 2.8.

If you want more sensible behaviour, then upgrade to Python 3. If you want to improve the docs, then suggest some documentation improvements. But arguing for a change in behaviour of Python 2.7 str.encode and unicode.decode is, I fear, a waste of everyone's time.

If you still wish to champion this change, feel free to raise the issue on the Python-Dev mailing list where the senior developers, including Guido, hang out. I doubt it will do any good, but there is at least the theoretical possibility that if you convince them that this change will encourage people to migrate to Python 3 then you might get your wish.

Just don't hold your breath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 13:54:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 17:54:55 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463680495.68.0.412131044276.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> btw If anyone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8', error=X) is resulting in an implicit call to the equivalent of decode(defaultencoding, errors=strict) (as suggested by the exception message) I think it'll be easier to discuss the details of fixing.

There is no single place. Search lines "str = PyUnicode_FromObject(str);" in Modules/_codecsmodule.c.

> But that's not what happens - it *silently works* (is a no-op) as long as you happen to be using ASCII characters so this so-called 'programming bug' will go unnoticed by most programmers (and authors of third party library code you might be relying on!)... but the moment a non-ascii character get introduced suddenly you'll get an exception, maybe in some library code you rely on but can't fix.

The problem is that encoding ASCII str to UTF-8 is legal operation in some circumstances and is a programming bug in other. There is no way to distinguish these two cases automatically.

As non-English speaker I am familiar with the problems you described. This is a bug in the design of Python 2, and the only solution is using Python 3.

You can experiment with your idea, but I'm afraid that the patch will be more difficult than you expect and break the tests. I want to warn that even if your experiment is quite successful, there is not much chance to take it in 2.7. This is more like a new feature than a bug fix. Programs that depend on this feature will be incompatible with previous bugfix releases. It is unlikely to help the migration on Python 3, but rather would encourage writing code that is incompatible with Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 14:37:25 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 19 May 2016 18:37:25 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463683045.87.0.664883378198.issue26369@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Agree with Steven; the whole reason Python 3 changed from unicode and str to str and bytes was because having Py2 str be text sometimes, and binary data at other times is confusing. The existing behavior can't change in Py2 in any meaningful way without breaking existing code, introducing special cases for text->text encodings (where Python 3 supports them using the codecs module only), behaving in non-obvious ways in corner cases, etc. Silently treating str.encode("utf-8") to mean "decode as UTF-8 and throw away the result to verify that it's already UTF-8 bytes" is not particularly intuitive either.

It does seem like a doc fix would be useful though; right now, we have only "String methods" documented, with no distinction between str and unicode. It might be helpful to explicitly deprecate str.encode on str objects, and unicode.decode, with a note that while it's meaningful to use these methods in Python 2 for text<->text encoding/decoding, the methods don't exist at all in Python 3.

Otherwise, yes, if you want consistent text/binary types, that's what Python 3 is for. Python 2 has tons of flaws when it comes to handling unicode (e.g. csv module), and fixing any given single problem (creating backward compatibility headaches in the process) is not worth the trouble.

If you're concerned about excessive boilerplate, just write a function (or a type) that allows you to perform the tests/conversions you care about as a single call. For example, the following seems like it achieves your objectives (one line usage, handles str by verifying that it's legal in provided encoding in strict mode, dropping/replacing characters in ignore/replace mode, etc.):

def basestringencode(s, encoding=sys.getdefaultencoding(), errors="strict"):
    if isinstance(s, str):
        # Decode with provided rules, so a str with illegal characters
        # raises exception, replaces, ignores, etc. per arguments
        s = s.decode(encoding, errors)
    return s.encode(encoding, errors)

If you don't want to see UnicodeDecodeError, you either pass 'ignore' for errors, or wrap the s.decode step in a try/except and raise a different exception type.

The biggest change I could see happening code wise would be a textual change to the UnicodeDecodeError error str.encode raises, so str.encode specifically replaces the default error message (but not type, for back compat reasons) with something like "str.encode cannot perform implicit decode with sys.getdefaultencoding(); use .encode only with unicode objects"

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 16:02:32 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:02:32 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
 not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463688152.67.0.827985855276.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. It actually claims to compare not only the counts, but the actual sorted elements themselves. This documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst:

   .. method:: assertItemsEqual(actual, expected, msg=None)

      Test that sequence *expected* contains the same elements as *actual*,
      regardless of their order. When they don't, an error message listing the
      differences between the sequences will be generated.

      Duplicate elements are *not* ignored when comparing *actual* and
      *expected*. It verifies if each element has the same count in both
      sequences. It is the equivalent of ``assertEqual(sorted(expected),
      sorted(actual))`` but it works with sequences of unhashable objects as
      well.

----------
nosy: +vitaly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

From report at bugs.python.org  Thu May 19 16:05:37 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:05:37 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463688337.24.0.369474544918.issue27060@psf.upfronthosting.co.za>


Changes by Vitaly <vitaly.krugl.numenta at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Thu May 19 16:10:34 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:10:34 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
 not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463688634.57.0.47933503053.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

I opened http://bugs.python.org/issue27060 regarding the erroneous documentation of assertItemsEqual in python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

From report at bugs.python.org  Thu May 19 16:17:47 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 May 2016 20:17:47 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463689067.69.0.341306059196.issue27060@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Thu May 19 21:01:51 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Fri, 20 May 2016 01:01:51 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463706110.72.0.467442027324.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Friendly ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Fri May 20 04:01:11 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 May 2016 08:01:11 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463731271.39.0.897765908373.issue26369@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Ben, the methods on stings and Unicode objects in Python 2.x are direct interfaces to the underlying codecs. The codecs can handle any number of input and output types, so there are some which only work on 8-bit strings (bytes) and others which take Unicode as input.

As a result, you sometimes see errors due to the conversion of an 8-bit string to Unicode (in the case, where the codec expects a Unicode input).

As example, take the UTF-8 codec. This expects a Unicode input when decoding, so when you pass in an 8-bit string, Python will convert this to Unicode using the default encoding (which is normally set to 'ascii') and then applies the codec operation.

When the 8-bit string is plain ASCII this works great. If not, chances are high that you'll run into a Unicode error.

Now, in Python 2.x you can change the default encoding to either make this work by assuming that all your 8-bit strings are UTF-8 (set it to 'utf-8' in sitecustomize.py), or you can disable the automatic conversion altogether by setting the default encoding to 'unknown', which is a codec specifically created for this purpose. The latter will also raise an exception when attempting to convert an 8-bit string to Unicode - similar to what Python 3 does, except that the error type is different.

Hope that helps.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Fri May 20 05:34:40 2016
From: report at bugs.python.org (Ben Spiller)
Date: Fri, 20 May 2016 09:34:40 +0000
Subject: [docs] [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463736880.1.0.322259459495.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

Thanks for considering this, anyway. I'll admit I'm disappointed we couldn't fix this on the 2.7 train, as to me fixing a method that takes an errors='ignore' argument and then throws an exception anyway seems a little more like a bug than a feature (and changing it would likely not affect behaviour in any existing non-broken programs), but if that's the decision then fine. Of course I'm aware (as I mentioned earlier on the thread) that the radically different unicode handling in python 3 solves this entirely and only wish it was practical to move our existing (enormous) codebase and customers over to it, but we're stuck with Python 2.7 - I believe lots of people are in the same situation unfortunately. 

As Josh suggested, perhaps we can at least add something to the doc for the str/unicode encode and decode methods so users are aware of the behaviour without trial and error. I'll update the component of this bug to reflect it's now considered a doc issue. 

Based on the inputs from Terry, and what seem to be the key info that would have been helpful to me and those who are hitting the same issues for the first time, I'd propose the following text (feel free to adjust as you see fit):

For encode:
"For most encodings, the return type is a byte str regardless of whether it is called on a str or unicode object. For example, call encode on a unicode object with "utf-8" to return a byte str object, or call encode on a str object with "base64" to return a base64-encoded str object.

It is _not_ recommended to use call this method on "str" objects when using codecs such as utf-8 that convert betweens str and unicode objects, as any characters not supported by python's default encoding (usually 7-bit ascii) will result in a UnicodeDecodeError exception, even if errors='ignore' was specified. For such conversions the str.decode and unicode.encode methods should be used. If you need to produce an encoded version of a string that could be either a str or unicode object, only call the encode() method after checking it is a unicode object not a str object, using isinstance(s, unicode)."

and for decode:
"The return type may be either str or unicode, depending on which encoding is used and whether the method is called on a str or unicode object. For example, call decode on a str object with "utf-8" to return a unicode object, or call decode on a unicode or str object with "base64" to return a base64-decoded str object.

It is _not_ recommended to use call this method on "unicode" objects when using codecs such as utf-8 that convert betweens str and unicode objects, as any characters not supported by python's default encoding (usually 7-bit ascii) will result in a UnicodeEncodeError exception, even if errors='ignore' was specified. For such conversions the str.decode and unicode.encode methods should be used. If you need to produce a decoded version of a string that could be either a str or unicode object, only call the decode() method after checking it is a str object not a unicode object, using isinstance(s, str)."

----------
components: +Documentation -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From petr at kalinin.nnov.ru  Fri May 20 06:04:20 2016
From: petr at kalinin.nnov.ru (=?UTF-8?B?0J/QtdGC0YAg0JrQsNC70LjQvdC40L0=?=)
Date: Fri, 20 May 2016 13:04:20 +0300
Subject: [docs] License on Python documentation textx
Message-ID: <CAL9NuJ-c1j5WjZmrtewY2qoZofGEABi6sTh8u5u9sa2jNmCi5Q@mail.gmail.com>

Hello,

What is the license for Python documentation found at
https://docs.python.org/ ?

I've tried to find any information about it on the site itself, but did not
succeed in it. The footer of the site gives a link to
https://docs.python.org/3/copyright.html , which simply lists several
copyrights and "All rights reserved"s and contains link to
https://docs.python.org/3/license.html#history-and-license . However, the
latter specified licenses for Python only, not for documentation.

The page https://docs.python.org/3/about.html also does not list eny
explicit license.

Is the licenses listed at
https://docs.python.org/3/license.html#history-and-license apply to Python
documentation found at https://docs.python.org/ too? If not, then what is
the exact license for the documentation?

Background: I'm writing a Telegram bot that will be able to provide python
reference (for example, return re.match reference when user sends
"re.match"), for this I parse docs.python.org. I definitely need and want
to know the license of the texts to know whether this is a legitimate use
and how should I properly give attribution.

-- 
Petr Kalinin,
petr at kalinin.nnov.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160520/3e8719a3/attachment.html>

From georg at python.org  Fri May 20 10:01:15 2016
From: georg at python.org (Georg Brandl)
Date: Fri, 20 May 2016 16:01:15 +0200
Subject: [docs] License on Python documentation textx
In-Reply-To: <CAL9NuJ-c1j5WjZmrtewY2qoZofGEABi6sTh8u5u9sa2jNmCi5Q@mail.gmail.com>
References: <CAL9NuJ-c1j5WjZmrtewY2qoZofGEABi6sTh8u5u9sa2jNmCi5Q@mail.gmail.com>
Message-ID: <6c402467-9a13-0c7b-c264-75399a1bc40b@python.org>

Hi Petr,

the Python documentation is distributable under the same license as the code,
given in the "History and License" section.

cheers,
Georg

On 05/20/2016 12:04 PM, ???? ??????? wrote:
> Hello,
> 
> What is the license for Python documentation found at https://docs.python.org/ ?
> 
> I've tried to find any information about it on the site itself, but did not
> succeed in it. The footer of the site gives a link
> to https://docs.python.org/3/copyright.html , which simply lists several
> copyrights and "All rights reserved"s and contains link
> to https://docs.python.org/3/license.html#history-and-license . However, the
> latter specified licenses for Python only, not for documentation.
> 
> The page https://docs.python.org/3/about.html also does not list eny explicit
> license.
> 
> Is the licenses listed
> at https://docs.python.org/3/license.html#history-and-license apply to Python
> documentation found at https://docs.python.org/ too? If not, then what is the
> exact license for the documentation?
> 
> Background: I'm writing a Telegram bot that will be able to provide python
> reference (for example, return re.match reference when user sends "re.match"),
> for this I parse docs.python.org <http://docs.python.org>. I definitely need and
> want to know the license of the texts to know whether this is a legitimate use
> and how should I properly give attribution.
> 
> -- 
> Petr Kalinin,
> petr at kalinin.nnov.ru <mailto:petr at kalinin.nnov.ru>
> 
> 
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/docs/attachments/20160520/49429f2d/attachment.sig>

From georg at python.org  Fri May 20 10:02:50 2016
From: georg at python.org (Georg Brandl)
Date: Fri, 20 May 2016 16:02:50 +0200
Subject: [docs] Regex documentation bug
In-Reply-To: <CAGJbGGpZwn5OfAOugv_0aONLqAAxeah1mtH1hi6mKLgqKgcvBw@mail.gmail.com>
References: <CAGJbGGpZwn5OfAOugv_0aONLqAAxeah1mtH1hi6mKLgqKgcvBw@mail.gmail.com>
Message-ID: <c8bcea54-d891-9e81-2851-b5f4c9ee813c@python.org>

Hi Neta,

the indices returned from regex matches follow the same convention as slice
indices, in that the end index is exclusive: a slice from index 0 to index 11
has 11 items.

cheers,
Georg

On 05/19/2016 10:35 AM, Neta Oren wrote:
> Hi,
> I was reading your documentation page about regex, and noticed you had a mistake.
> The specific page is 'Regular Expression HOWTO -- Python 2.7.11 documentation'.
> It is located in the address: 
> https://docs.python.org/2/howto/regex.html
> The mistake is at the 'Performing Matches' section. 
> The mistake is:
> You wrote that the start() and end() methods will retnot end the starting and
> ending indices of the match. However in the example you provided the end index
> is in fact the length of the match, and not the ending index (that would be
> length - 1). 
> If the index starts at 0 and ends at 11 then that means there are 12 characters,
> however in your examples it was not as such.
> This can create array out of bounds exceptions and other exceptions as well.
> This error is repeated in this section several times.
> For your attention,
> Neta
> 
> 
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/docs/attachments/20160520/fec5f785/attachment.sig>

From report at bugs.python.org  Fri May 20 14:26:03 2016
From: report at bugs.python.org (Mike Taylor)
Date: Fri, 20 May 2016 18:26:03 +0000
Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel
 scroll on Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1463768763.16.0.30032516296.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

OK, so uh, somehow a few months escaped me before I could get to this. >_>

(I've also just signed the Contributor Agreement with the PSF)

----------
keywords: +patch
Added file: http://bugs.python.org/file42917/docs-sidebar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24712>
_______________________________________

From report at bugs.python.org  Fri May 20 14:29:17 2016
From: report at bugs.python.org (Mike Taylor)
Date: Fri, 20 May 2016 18:29:17 +0000
Subject: [docs] [issue24712] Docs page's sidebar vibrates on mouse wheel
 scroll on Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1463768957.32.0.362938391871.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

The bug for Chrome to ship support of position: sticky is here: https://bugs.chromium.org/p/chromium/issues/detail?id=231752 -- it's in active development.

But this patch fixes the jerky sidebar in Firefox as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24712>
_______________________________________

From report at bugs.python.org  Fri May 20 18:30:15 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 22:30:15 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463783414.93.0.0936679975382.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Note: 2.7 doc says that this is renamed assertCountEqual in 3.x.  It was added in 2.7 and 3.2.  The 3.x doc is essentially the same, but with this instead: "Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) ...".

If the method misfunctions, then it should be fixed, not have the bug documented.  But you need to provide specific evidence and example.  The unittest in 3.x has this test with same number, different elements.
        self.assertRaises(self.failureException, self.assertCountEqual,
                          [1, 2] + [3] * 100, [1] * 100 + [2, 3])

I ran following test with same number, different items.
FAIL: test_Count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 4, in test_Count
    self.assertItemsEqual([1,2,3], [1,2,4])
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4
 
This also fails in 3.5 with name change.

----------
components: +Library (Lib) -Documentation
nosy: +terry.reedy
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 18:31:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 22:31:54 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463783514.15.0.0394559618636.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Here is the specific test code so you can replace my lists with examples that you think malfunction.

import unittest as u
class Test(u.TestCase):
    def test_Count(self):
        self.assertItemsEqual([1,2,3], [1,2,4])
u.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:22:17 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:22:17 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463786537.21.0.131559826359.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

According to comment http://bugs.python.org/issue17866#msg188052 in #17866, the maintainers renamed `assertItemsEqual` to `assertCountEqual` somewhere in the 3.x development timeframe. They apparently latched on to the implementation of `assertItemsEqual` in 2.7.x, which compares counts only, rather than its documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:37:59 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:37:59 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463787479.81.0.99120597078.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

Thanks Terry, your assessment is correct. The maintainers appear to have drawn the wrong conclusion in #17866, which mislead me about the existing assertItemsEqual in 2.7, which appears to work correctly after all!

import unittest as u
class Test(u.TestCase):
    def test_equal_count_of_same_elements(self):
        self.assertItemsEqual([1,2,3], [1,2,3])

    def test_equal_count_of_different_elements(self):
        self.assertItemsEqual([1,2,3], [1,2,4])

    def test_different_count(self):
        self.assertItemsEqual([1,2,3], [1,2,3,4])
u.main()


$ python assert_items_equal_test.py --verbose
test_different_count (__main__.Test) ... FAIL
test_equal_count_of_different_elements (__main__.Test) ... FAIL
test_equal_count_of_same_elements (__main__.Test) ... ok

======================================================================
FAIL: test_different_count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 12, in test_different_count
    self.assertItemsEqual([1,2,3], [1,2,3,4])
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

======================================================================
FAIL: test_equal_count_of_different_elements (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements
    self.assertItemsEqual([1,2,3], [1,2,4])
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

----------------------------------------------------------------------
Ran 3 tests in 0.001s

FAILED (failures=2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:46:14 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:46:14 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463787974.38.0.993804191588.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

I think that we can close this as not a bug, as concerning 2.7. However, I think that 3.x made the wrong decision when it renamed assertItemsEqual with assertCountEqual, which now misleads users into thinking that it compares counts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:50:17 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:50:17 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
 not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463788216.96.0.787117618458.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

Folks, assertCountEqual sounds like a really bad name. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much better and more meaningful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

From report at bugs.python.org  Fri May 20 19:55:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 23:55:47 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463788547.56.0.699295913313.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It compares element by element counts, as indicated by "Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) ..." and the failure messages.  Since I understand Counter equality, I ignore the rest.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 20:05:52 2016
From: report at bugs.python.org (Vitaly)
Date: Sat, 21 May 2016 00:05:52 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463789151.96.0.0275112185434.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

Yes, this caused me to examine Counter, which I had not used before, and now I understand it, too. However, the new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 20:06:25 2016
From: report at bugs.python.org (Vitaly)
Date: Sat, 21 May 2016 00:06:25 +0000
Subject: [docs] [issue27060] Documentation of assertItemsEqual in unittest
 is VERY misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463789185.27.0.877501183806.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

... and an unnecessary incompatibility between 2.7 and 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Sat May 21 03:45:05 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 21 May 2016 07:45:05 +0000
Subject: [docs] [issue27074] Confusing text about __all__ in __init__.py in
 tutorial
Message-ID: <1463816705.73.0.630465423608.issue27074@psf.upfronthosting.co.za>


New submission from Antti Haapala:

https://docs.python.org/3/tutorial/modules.html#importing-from-a-package

says that 

"The import statement uses the following convention: if a package?s __init__.py code defines a list named __all__, it is taken to be the list of module names that should be imported when from package import * is encountered."

However, of course this is not true. The behaviour is that `__all__` lists the names that are to be imported from the package with from package import *; only only those names that raise AttributeError at the time of import would be attempted to be imported as submodules.

----------
assignee: docs at python
components: Documentation
messages: 265990
nosy: docs at python, ztane
priority: normal
severity: normal
status: open
title: Confusing text about __all__ in __init__.py in tutorial
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27074>
_______________________________________

From report at bugs.python.org  Sat May 21 04:26:13 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 21 May 2016 08:26:13 +0000
Subject: [docs] [issue27075] Link to StreamReader/Writer from
 codecs.getreader/writer
Message-ID: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Patch attached.

----------
assignee: docs at python
components: Documentation
files: codeclinks.patch
keywords: patch
messages: 265991
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Link to StreamReader/Writer from codecs.getreader/writer
type: enhancement
Added file: http://bugs.python.org/file42923/codeclinks.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27075>
_______________________________________

From report at bugs.python.org  Sat May 21 04:31:23 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 21 May 2016 08:31:23 +0000
Subject: [docs] [issue27076] Doc and comment spelling fixes
Message-ID: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Patch attached.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: docs.patch
keywords: patch
messages: 265992
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Doc and comment spelling fixes
type: enhancement
Added file: http://bugs.python.org/file42924/docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Sat May 21 07:56:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2016 11:56:35 +0000
Subject: [docs] [issue27075] Link to StreamReader/Writer from
 codecs.getreader/writer
In-Reply-To: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>
Message-ID: <20160521115631.29804.24594.4231DF01@psf.io>


Roundup Robot added the comment:

New changeset c1628c1162a4 by Berker Peksag in branch '3.5':
Issue #27075: Link to StreamReader and StreamWriter docs
https://hg.python.org/cpython/rev/c1628c1162a4

New changeset b11b71aaf864 by Berker Peksag in branch 'default':
Issue #27075: Link to StreamReader and StreamWriter docs
https://hg.python.org/cpython/rev/b11b71aaf864

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27075>
_______________________________________

From report at bugs.python.org  Sat May 21 07:57:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 11:57:08 +0000
Subject: [docs] [issue27075] Link to StreamReader/Writer from
 codecs.getreader/writer
In-Reply-To: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>
Message-ID: <1463831828.31.0.797884486755.issue27075@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Ville.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27075>
_______________________________________

From report at bugs.python.org  Sat May 21 08:16:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 May 2016 12:16:08 +0000
Subject: [docs] [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <1463832967.32.0.225935146013.issue27076@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Ville for this. It mostly looks good. I left some comments regarding ?heterogenous?.

I extended the patch with related fixes, mainly outside the Doc/ and Lib/ directories. Whoever commits this should also regenerate importlib, the configure script, and Arg Clinic code (not included in patches).

I?m not too sure about the Lib/msilib/schema.py file because it looks like generated code. But I see that other people have fixed it, so maybe that is okay.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42925/docs.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Sat May 21 09:30:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 13:30:41 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463837441.68.0.495752974815.issue22558@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Yoni. Like Guido said in msg257586, we only want to add links for pure Python modules. Can you update your patch to remove C modules please?

I'd prefer keep curses docs untouched. Lib/curses/* is basically a wrapper to _cursesmodule.c with some utility functions (sqlite3 is another example of this).

Another candidates for removal are distutils.core, wsgiref, ensurepip, formatted (it's deprecated), test (Lib/test is basically the test suite of CPython) modules.

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Sat May 21 18:31:49 2016
From: report at bugs.python.org (Joshua Jay Herman)
Date: Sat, 21 May 2016 22:31:49 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1463869908.44.0.795413473334.issue24459@psf.upfronthosting.co.za>


Joshua Jay Herman added the comment:

Hi, I have alphabetized and added the missing Environment Variables according to Section 1.2 https://docs.python.org/3.6/using/cmdline.html#environment-variables . I also added the missing environment variables from that documentation section.

Should Section 1.2 also be alphabetized? I noticed it wasn't.

This is my first contribution to python (I also just filled out the contributor forms) any comments and criticism is appreciated.

----------
keywords: +patch
nosy: +zitterbewegung
Added file: http://bugs.python.org/file42932/addMissingEnvVarsAndAlphabetize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24459>
_______________________________________

From report at bugs.python.org  Sat May 21 20:34:30 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Sun, 22 May 2016 00:34:30 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463877269.05.0.263160801677.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Thank you for the review, Berker.
I removed source code links from all the modules you specifically mentioned, and all links to C code, including stat.rst which already had such a link before.

But I have to say that I don't quite understand the rationale here and (as a user) would personally prefer easy access to all source code, both C and Python. It is my opinion that a handy link to the source would help promote the conversion of library users to contributors.

----------
Added file: http://bugs.python.org/file42933/mywork2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Sat May 21 22:10:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 02:10:02 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463883000.87.0.857377265128.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

I updated my patch thanks to Serhiy?s comments. Also omitted Arg Clinic generated code in this version to avoid future merge conflicts with the hashes.

----------
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42934/bytes-like-param.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sun May 22 02:35:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 06:35:27 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463898927.34.0.349042148904.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

bytes-like-param.v6.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sun May 22 02:53:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 May 2016 06:53:47 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1463900027.77.0.0689540712263.issue26980@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26980>
_______________________________________

From report at bugs.python.org  Sun May 22 17:53:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 22 May 2016 21:53:34 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1463954014.34.0.577529168849.issue26980@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It's the name of the UNIX domain socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26980>
_______________________________________

From report at bugs.python.org  Sun May 22 19:39:31 2016
From: report at bugs.python.org (Steve Ford)
Date: Sun, 22 May 2016 23:39:31 +0000
Subject: [docs] [issue27088] doc: select: epoll.poll: incorrect timeout
 units, missing maxevents
Message-ID: <1463960371.93.0.0941923922389.issue27088@psf.upfronthosting.co.za>


New submission from Steve Ford:

The short description of epoll.poll is correct (gives timeout unit as seconds [float]; includes maxevents).  However, the long description lists the timeout units as milliseconds ("If timeout is given, it specifies the length of time in milliseconds which the system will wait for events before returning."), and does not include maxevents at all.

See https://docs.python.org/3.5/library/select.html#select.poll.poll

See also https://docs.python.org/2.7/library/select.html#select.poll.poll

----------
assignee: docs at python
components: Documentation
messages: 266118
nosy: docs at python, fordsfords
priority: normal
severity: normal
status: open
title: doc: select: epoll.poll: incorrect timeout units, missing maxevents
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27088>
_______________________________________

From vadmium+py at gmail.com  Sat May 21 07:40:06 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 21 May 2016 11:40:06 -0000
Subject: [docs] Doc and comment spelling fixes (issue 27076)
Message-ID: <20160521114006.26442.70873@psf.upfronthosting.co.za>


https://bugs.python.org/review/27076/diff/17296/Lib/numbers.py
File Lib/numbers.py (left):

https://bugs.python.org/review/27076/diff/17296/Lib/numbers.py#oldcode38
Lib/numbers.py:38: If it is given heterogenous arguments, and doesn't
have special
I understand the original is also a valid spelling, so we should
probably leave this alone.

https://bugs.python.org/review/27076/diff/17296/Lib/unittest/test/test_case.py
File Lib/unittest/test/test_case.py (left):

https://bugs.python.org/review/27076/diff/17296/Lib/unittest/test/test_case.py#oldcode945
Lib/unittest/test/test_case.py:945: # comparing heterogenous
non-hashable sequences
See other comment about ?heterogenous?

https://bugs.python.org/review/27076/

From vadmium+py at gmail.com  Sat May 21 20:20:22 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 22 May 2016 00:20:22 -0000
Subject: [docs] Behavior of ZipFile with file-like object and
 BufferedWriter. (issue 20699)
Message-ID: <20160522002022.31860.65001@psf.upfronthosting.co.za>


https://bugs.python.org/review/20699/diff/16966/Doc/library/io.rst
File Doc/library/io.rst (right):

https://bugs.python.org/review/20699/diff/16966/Doc/library/io.rst#newcode597
Doc/library/io.rst:597: The argument *initial_bytes* is a
:term:`bytes-like object` that
On 2016/05/19 08:45:20, storchaka wrote:
> Maybe "The optional argument"?

Sure

https://bugs.python.org/review/20699/diff/16966/Lib/_pyio.py
File Lib/_pyio.py (right):

https://bugs.python.org/review/20699/diff/16966/Lib/_pyio.py#newcode678
Lib/_pyio.py:678: """Read bytes into buffer *b*, using at most one
system call
On 2016/05/19 08:45:20, storchaka wrote:
> Should this be unified with readinto()?

I don?t want to copy the wording from readinto(), because I want to keep
the first line of the doc string a short summary (while still mentioning
?one system call?).

https://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py
File Lib/test/test_io.py (right):

https://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py#newcode320
Lib/test/test_io.py:320: self.assertEqual(memoryview(data).tobytes(), b"
worl")
On 2016/05/19 08:45:20, storchaka wrote:
> Maybe just "bytes(data)"?

I probably wrote the longer version with Python 2 compatibility in mind.
But I see that neither of my byteslike() functions will work as they are
with Python 2, so I may as well use the simpler version.

https://bugs.python.org/review/20699/diff/16966/Lib/test/test_io.py#newcode667
Lib/test/test_io.py:667: def make_file_writer():
On 2016/05/19 08:45:20, storchaka wrote:
> Yet more short and clear writing is:
> 
> def check(f):
>     with f:
>         self.assertEqual(f.write(a), n)
>         f.writelines((a,))
> check(self.BytesIO())
> check(self.FileIO(support.TESTFN, "w"))
> ...
> 
> Only 9 lines!

Thankyou, I used this version

https://bugs.python.org/review/20699/

From report at bugs.python.org  Mon May 23 09:11:38 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 13:11:38 +0000
Subject: [docs] [issue17866] TestCase.assertItemsEqual exists in 2.7,
 not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1464009098.22.0.845270634342.issue17866@psf.upfronthosting.co.za>


R. David Murray added the comment:

At the time I wanted it to be named assertCountsEqual, which is better (IMO) than either assertItemsEqual or assertCountEqual.  I lost that naming contest, though :(.  On the third hand, I don't think there exists a good two word name for what the function does.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

From report at bugs.python.org  Mon May 23 10:38:29 2016
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 23 May 2016 14:38:29 +0000
Subject: [docs] [issue27021] It is not documented that os.writev() suffer
 from SC_IOV_MAX
In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>
Message-ID: <1464014309.84.0.0564226838535.issue27021@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27021>
_______________________________________

From report at bugs.python.org  Tue May 24 17:36:30 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Tue, 24 May 2016 21:36:30 +0000
Subject: [docs] [issue27113] sqlite3 open parameter "check_same_thread" not
 documented
Message-ID: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>


New submission from Dave Sawyer:

The sqlite3.connect method has 6 parameters. 5 of them are documented.  See below and search for "check_same_thread".  Patch adds documentation for this parameter.

sqlite3.connect(database[, timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements])
Opens a connection to the SQLite database file database. You can use ":memory:" to open a database connection to a database that resides in RAM instead of on disk.

When a database is accessed by multiple connections, and one of the processes modifies the database, the SQLite database is locked until that transaction is committed. The timeout parameter specifies how long the connection should wait for the lock to go away until raising an exception. The default for the timeout parameter is 5.0 (five seconds).

For the isolation_level parameter, please see the Connection.isolation_level property of Connection objects.

SQLite natively supports only the types TEXT, INTEGER, REAL, BLOB and NULL. If you want to use other types you must add support for them yourself. The detect_types parameter and the using custom converters registered with the module-level register_converter() function allow you to easily do that.

detect_types defaults to 0 (i. e. off, no type detection), you can set it to any combination of PARSE_DECLTYPES and PARSE_COLNAMES to turn type detection on.

By default, the sqlite3 module uses its Connection class for the connect call. You can, however, subclass the Connection class and make connect() use your class instead by providing your class for the factory parameter.

Consult the section SQLite and Python types of this manual for details.

The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements.

----------
assignee: docs at python
components: Documentation
files: doc_parm.patch
keywords: patch
messages: 266281
nosy: Dave Sawyer, docs at python
priority: normal
severity: normal
status: open
title: sqlite3 open parameter "check_same_thread" not documented
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42978/doc_parm.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Tue May 24 17:38:24 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Tue, 24 May 2016 21:38:24 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464125904.85.0.418072154099.issue27113@psf.upfronthosting.co.za>


Changes by Dave Sawyer <kingsawyer at gmail.com>:


----------
title: sqlite3 open parameter "check_same_thread" not documented -> sqlite3 connect parameter "check_same_thread" not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Tue May 24 22:24:52 2016
From: report at bugs.python.org (dananntang)
Date: Wed, 25 May 2016 02:24:52 +0000
Subject: [docs] [issue27116] Documentation for regular expression
 alphanumeric matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
Message-ID: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>


New submission from dananntang:

https://docs.python.org/2/library/re.html#regular-expression-syntax
Section 7.2.1. Regular Expression Syntax

Documentation for \w and \W are wrong.
To be specific:
\w is to match any non-alphanumeric character, while \W is to match alphanumeric character

Fix: swap documentation for \w and \W

----------
assignee: docs at python
components: Documentation
messages: 266291
nosy: dananntang, docs at python
priority: normal
severity: normal
status: open
title: Documentation for regular expression alphanumeric matching are swapped. https://docs.python.org/2/library/re.html#regular-expression-syntax
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27116>
_______________________________________

From report at bugs.python.org  Tue May 24 22:36:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 02:36:27 +0000
Subject: [docs] [issue27116] Documentation for regular expression
 alphanumeric matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
In-Reply-To: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>
Message-ID: <1464143787.0.0.765884564204.issue27116@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't think no need to swap. The current doc is right.

>>> re.findall(r'\W+', 'abcd123_#@@@@')
['#@@@@']
>>> re.findall(r'\w+', 'abcd123_#@@@@')
['abcd123_']

It's apparent that \w match alphanumeric and \W vice versa.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27116>
_______________________________________

From report at bugs.python.org  Tue May 24 22:41:23 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 25 May 2016 02:41:23 +0000
Subject: [docs] [issue27116] Documentation for regular expression
 alphanumeric matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
In-Reply-To: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>
Message-ID: <1464144083.25.0.816659323762.issue27116@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27116>
_______________________________________

From report at bugs.python.org  Wed May 25 02:42:48 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 25 May 2016 06:42:48 +0000
Subject: [docs] [issue27119] `compile` doesn't compile into an AST object as
 specified
Message-ID: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>


New submission from Franklin? Lee:

>From `compile`'s doc:
    "Compile the source into a code or AST object."

The docs don't say how to compile into an AST object with `compile`, though. As it says later:
    "If you want to parse Python code into its AST representation, see ast.parse()."

I checked 3.4-3.2, 3.0, 2.7, and 2.6. Versions before 3.4, and version 2.6, are missing the `ast.parse` line, but still have the first line.

----------
assignee: docs at python
components: Documentation
messages: 266311
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: `compile` doesn't compile into an AST object as specified
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________

From report at bugs.python.org  Wed May 25 04:13:01 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 25 May 2016 08:13:01 +0000
Subject: [docs] [issue27119] `compile` doesn't compile into an AST object as
 specified
In-Reply-To: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>
Message-ID: <1464163981.13.0.194675480737.issue27119@psf.upfronthosting.co.za>


Eryk Sun added the comment:

What you're looking for is in the 2nd paragraph of the ast docs:

    An abstract syntax tree can be generated by passing
    ast.PyCF_ONLY_AST as a flag to the compile() built-in
    function, or using the parse() helper provided in this
    module. The result will be a tree of objects whose
    classes all inherit from ast.AST. An abstract syntax
    tree can be compiled into a Python code object using
    the built-in compile() function.

For example:

    >>> mod = compile('42', '', 'exec', ast.PyCF_ONLY_AST)
    >>> mod
    <_ast.Module object at 0x7f0e45b15be0
    >>> ast.dump(mod)
    'Module(body=[Expr(value=Num(n=42))])'

In the discussion of `flags`, I think the compile docs should explicitly list ast.PyCF_ONLY_AST and the CO_FUTURE_* flags in a table.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________

From report at bugs.python.org  Wed May 25 04:46:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 08:46:44 +0000
Subject: [docs] [issue27021] It is not documented that os.writev() suffer
 from SC_IOV_MAX
In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>
Message-ID: <1464166004.94.0.391219302259.issue27021@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27021>
_______________________________________

From report at bugs.python.org  Wed May 25 05:11:46 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 25 May 2016 09:11:46 +0000
Subject: [docs] [issue27119] `compile` doesn't compile into an AST object as
 specified
In-Reply-To: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>
Message-ID: <1464167506.8.0.958720098297.issue27119@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

> What you're looking for is in the 2nd paragraph of the ast docs:

Oh. I considered that, but then compile's docs say:

    The optional arguments flags and dont_inherit
    control which future statements (see PEP 236)
    affect the compilation of source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________

From report at bugs.python.org  Wed May 25 09:39:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:39:15 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464183555.0.0.406197707439.issue27113@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 16509, but I'm going to keep this open since there is a patch attached here.

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Wed May 25 09:41:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:41:01 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1464183661.79.0.592635389513.issue16509@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Issue 27113 has a patch and more detailed description so I'm going to close this one as a 'duplicate'.

Thanks for the report!

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> sqlite3 connect parameter "check_same_thread" not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16509>
_______________________________________

From report at bugs.python.org  Wed May 25 09:41:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:41:51 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464183711.65.0.630173787911.issue27113@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From thomas at kluyver.me.uk  Wed May 25 10:03:49 2016
From: thomas at kluyver.me.uk (thomas at kluyver.me.uk)
Date: Wed, 25 May 2016 14:03:49 -0000
Subject: [docs] sqlite3 open parameter "check_same_thread" not documented
 (issue 27113)
Message-ID: <20160525140349.14157.74557@psf.upfronthosting.co.za>


http://bugs.python.org/review/27113/diff/17342/Doc/library/sqlite3.rst
File Doc/library/sqlite3.rst (right):

http://bugs.python.org/review/27113/diff/17342/Doc/library/sqlite3.rst#newcode194
Doc/library/sqlite3.rst:194: a connection from multiple threads. Be sure
to use SQLite version 3.3.1 or later
This version was released over a decade ago
(https://www.sqlite.org/chronology.html) - is it necessary to mention
the requirement? And if it is, can we include an indication that you
almost certainly have a new enough version, so people don't need to work
out how to find their sqlite version.

http://bugs.python.org/review/27113/diff/17342/Doc/library/sqlite3.rst#newcode195
Doc/library/sqlite3.rst:195: and use locking when writing to the
connection to avoid corruption.
According to the sqlite docs (http://www.sqlite.org/threadsafe.html),
the default mode is 'serialized', which does the necessary locking for
threads to share a connection. Unless Python is overriding this to use
one of the less protected modes, it shouldn't be necessary to use extra
locks around it.

http://bugs.python.org/review/27113/

From report at bugs.python.org  Wed May 25 10:10:18 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 25 May 2016 14:10:18 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464185418.37.0.968442077336.issue27113@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <thomas at kluyver.me.uk>:


----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Wed May 25 11:42:31 2016
From: report at bugs.python.org (Lennart Grahl)
Date: Wed, 25 May 2016 15:42:31 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error,
 not TypeError
Message-ID: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>


New submission from Lennart Grahl:

When using binascii.a2b_hex (or binascii.unhexlify) and the argument is invalid, the doc states that it should raise a TypeError for invalid arguments (e.g. passing an odd-length string).

However, it does raise binascii.Error instead of TypeError:

try:
    binascii.a2b_hex('a')
except Exception as exc:
    print(type(exc))

----------
assignee: docs at python
components: Documentation
messages: 266368
nosy: Lennart Grahl, docs at python
priority: normal
severity: normal
status: open
title: binascii.a2b_hex raises binascii.Error, not TypeError
type: behavior
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 11:55:58 2016
From: report at bugs.python.org (Lennart Grahl)
Date: Wed, 25 May 2016 15:55:58 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464191758.68.0.963867406137.issue27124@psf.upfronthosting.co.za>


Lennart Grahl added the comment:

When using binascii.a2b_hex (or binascii.unhexlify) and the argument is invalid, the doc states that it should raise a TypeError for invalid arguments (e.g. passing an odd-length string).

However, it does raise binascii.Error instead of TypeError:

try:
    binascii.a2b_hex('a')
except Exception as exc:
    print(type(exc))

What surprised me even more was that it raises ValueError (although binascii.Error inherits ValueError) in case a unicode string has been passed as an argument:

try:
    binascii.a2b_hex('?')
except binascii.Error:
    print('binascii.Error')
except ValueError:
    print('ValueError')

----------
title: binascii.a2b_hex raises binascii.Error, not TypeError -> binascii.a2b_hex raises binascii.Error and ValueError, not TypeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 12:23:49 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 25 May 2016 16:23:49 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464193429.56.0.927592994042.issue27124@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

In Python 3.x, 'a' is just as much a Unicode string as '?'. I agree that binascii.a2b_hex should raise ValueError for argument '?', or ';' for that matter, as they are invalid values. There's an inconsistency in why some invalid characters raise ValueError and some raise binascii.Error. But since binascii.Error is a subclass of ValueError, it probably doesn't matter that much, so long as the documentation is clear.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 18:43:05 2016
From: report at bugs.python.org (Phoenix)
Date: Wed, 25 May 2016 22:43:05 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
Message-ID: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>


New submission from Phoenix:

At https://docs.python.org/2/library/multiprocessing.html#authentication-keys there is a typo in the documentation:

"If authentication is requested but do authentication key is specified ..."

s/b (emphasis added)

"If authentication is requested but **no** authentication key is specified..."

----------
assignee: docs at python
components: Documentation
messages: 266393
nosy: docs at python, phx
priority: normal
severity: normal
status: open
title: Typo in Python 2 multiprocessing documentation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 18:44:46 2016
From: report at bugs.python.org (Phoenix)
Date: Wed, 25 May 2016 22:44:46 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464216286.91.0.165278063747.issue27125@psf.upfronthosting.co.za>


Phoenix added the comment:

Later in the same paragraph:

"This value will automatically inherited by"

s/b (emphasis added)

"This value will **be** automatically inherited by"

Or, if you prefer your infinitives unsplit:

"This value will be inherited automatically by"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 21:56:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 01:56:33 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464227792.09.0.509621987737.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

The ?do authentication? error is already fixed in Python 3, but the other error also exists in Python 3. This patch also fixes related errors in Python 3 that I found.

----------
keywords: +patch
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43007/will-be.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 21:57:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 01:57:21 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464227841.91.0.823331535231.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Python 2 patch, including the do ? no fix

----------
Added file: http://bugs.python.org/file43008/will-be.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 23:04:26 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Thu, 26 May 2016 03:04:26 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464231865.98.0.0245399992994.issue27124@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

binascii.Error is used throughout the module for most of the validations, with only a few of them using TypeError/ValueError. I guess it would make more sense to update these to raise binascii.Error (unless they were left on purpose) to make it consistent with the rest of the module, although changing from TypeError to binascii.Error might break existing code.

Anyway, since a2b_hex is currently raising binascii.Error for an odd-length input, the attached patch fixes the documentation to reflect it.

----------
keywords: +patch
nosy: +luiz.poleto
Added file: http://bugs.python.org/file43009/issue27124.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:46 +0000
Subject: [docs] [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.15606.A1E25FF5@psf.io>


Roundup Robot added the comment:

New changeset a3a64b85883f by Martin Panter in branch '3.5':
Issue #27076: Doc, comment and tests spelling fixes
https://hg.python.org/cpython/rev/a3a64b85883f

New changeset 5d254703bd84 by Martin Panter in branch 'default':
Issue #27076: Merge spelling from 3.5
https://hg.python.org/cpython/rev/5d254703bd84

New changeset d3d8faaaaade by Martin Panter in branch 'default':
Issue #27076: More doc and comment spelling fixes for 3.6, by Ville Skytt?
https://hg.python.org/cpython/rev/d3d8faaaaade

New changeset 1e80e53ce20d by Martin Panter in branch '2.7':
Issue #27076: Doc, comment and test function name spelling fixes
https://hg.python.org/cpython/rev/1e80e53ce20d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:47 +0000
Subject: [docs] [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.1520.D1E96788@psf.io>


Roundup Robot added the comment:

New changeset 90b49a29fe0c by Georg Brandl in branch '2.7':
#9911: doc copyedits.
https://hg.python.org/cpython/rev/90b49a29fe0c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9911>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:47 +0000
Subject: [docs] [issue21528] Fix a number of typos in the documentation
In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.60831.F7B72ED9@psf.io>


Roundup Robot added the comment:

New changeset 33f6e360826e by Donald Stufft in branch '2.7':
Fix Issue #21528 - Fix documentation typos
https://hg.python.org/cpython/rev/33f6e360826e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21528>
_______________________________________

From report at bugs.python.org  Thu May 26 04:47:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 08:47:27 +0000
Subject: [docs] [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <1464252447.45.0.215928833439.issue27076@psf.upfronthosting.co.za>


Martin Panter added the comment:

I pushed all the changes, including the MSI files, except for ?heterogeneous?.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Thu May 26 05:03:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 09:03:13 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464253393.15.0.201785871313.issue27124@psf.upfronthosting.co.za>


Martin Panter added the comment:

The TypeError ? binascii.Error changeover was made in revision eb45f85c4c79, to this function, along with various decoding functions in the base64 module. The base64 documenation was only slowly updated in a series of bug fixes, and it looks like unhexlify() is the only one left.

At the top of the binascii documentation, it says that the decoding functions accept ASCII strings. The general check for non-ASCII code points (raising ValueError) would be done before the specific checks for hexadecimal digits and having the right length.

Luiz?s patch looks okay to me.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Thu May 26 12:58:30 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 16:58:30 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464281910.68.0.147653695421.issue27043@psf.upfronthosting.co.za>


Nathan Harold added the comment:

Here's my shot at a revision (corresponding patch attached):

   Clean up indentation from docstrings that are indented to line up with blocks
   of code.  All leading whitespace is removed from the first line.  Any leading
   whitespace that can be uniformly removed from the second line onwards is
   removed.  Empty lines at the beginning and end are subsequently removed.  Also,
   all tabs are expanded to spaces.

This version also makes it explicit that nothing happens to trailing whitespace, should a line happen to have any.  This actually seems to be a difference between this function and the sample implementation in the PEP.

One odd side effect of that difference is that a line consisting only of whitespace may actually not be removed from the beginning or end of the string, if the preceding whitespace removals aren't sufficient to leave the line completely empty.  For instance:

>>> inspect.cleandoc('   A \n  B \n   \n  ')
'A \nB \n '

Two spaces are removed from each of the second, third, and fourth lines.  The fourth line is then empty and is removed; the third line still contains one space and is kept.

On the other hand, as defined in the PEP, the extra space on the third line is removed as trailing whitespace, so that the third line is then removed entirely:

>>> trim('   A \n  B \n   \n  ')
'A\nB'

Most likely this difference rarely affects anything.  In any case, mentioning it here because it influenced exactly how I revised the docs.

----------
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43018/cleandoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Thu May 26 16:58:23 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:58:23 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296302.28.0.912266573515.issue26553@psf.upfronthosting.co.za>


Nathan Harold added the comment:

The 2_fix* patches were unfortunately slightly broken because an unrelated revision to xmlrpc.client.rst changed one of the lines the patch files were using as an anchor (by adding a period to the end).

I've uploaded the 3_fix* series, which addresses this.  The actual changes in these patches are identical to those in their precursors: capitalization of HTTP, HTTPS, FTP, and URL in a few places.

----------
nosy: +nharold
Added file: http://bugs.python.org/file43020/3_fix_3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 16:58:49 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:58:49 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296329.54.0.987033507429.issue26553@psf.upfronthosting.co.za>


Changes by Nathan Harold <penw81-ml at yahoo.com>:


Added file: http://bugs.python.org/file43021/3_fix_3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 16:59:31 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:59:31 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296371.47.0.353232873423.issue26553@psf.upfronthosting.co.za>


Changes by Nathan Harold <penw81-ml at yahoo.com>:


Added file: http://bugs.python.org/file43022/3_fix_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 20:09:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 00:09:31 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464307771.18.0.862617509168.issue27043@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks good to me, thanks Nathan

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Thu May 26 21:11:44 2016
From: report at bugs.python.org (Ben Finney)
Date: Fri, 27 May 2016 01:11:44 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1464281910.68.0.147653695421.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464311501.2653593.620104361.01981811@webmail.messagingengine.com>


Ben Finney added the comment:

On Fri, May 27, 2016, at 02:58, Nathan Harold wrote:
> Here's my shot at a revision (corresponding patch attached):

Thanks for that. The only improvement I'd ask for is to more clearly
separate
the description into two paragraphs: overall description of the effect
of the
function; then, detailed description of the specific transformations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Fri May 27 02:45:13 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 27 May 2016 06:45:13 +0000
Subject: [docs] [issue7951] Should str.format allow negative indexes when
 used for __getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1464331513.62.0.216689365166.issue7951@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The error message is misleading:

>>> s = '{names[-1]} loves {0[1]}'
>>> s.format(('C', 'Python'), names=('Dennis', 'Guido'))
Traceback (most recent call last):
    ...
TypeError: tuple indices must be integers or slices, not str

----------
nosy: +marco.buttu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri May 27 03:22:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 07:22:33 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464333753.0.0.579112944684.issue5784@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 04:45:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 08:45:57 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527084552.13905.13432.4830B7B4@psf.io>


Roundup Robot added the comment:

New changeset 4c88d6d18e85 by Martin Panter in branch '3.5':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/4c88d6d18e85

New changeset 4d4f27fc70d5 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/4d4f27fc70d5

New changeset e5fc74588cea by Martin Panter in branch '2.7':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/e5fc74588cea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 05:12:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 09:12:14 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464340334.5.0.277114963488.issue5784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Failure on Python 2.7:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/3348/steps/test/logs/stdio

======================================================================
ERROR: test_wbits (test.test_zlib.CompressObjectTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/2.7.cea-indiana-x86/build/Lib/test/test_zlib.py", line 534, in test_wbits
    self.assertEqual(zlib.decompress(zlib15, 0), HAMLET_SCENE)
error: Error -2 while preparing to decompress data: inconsistent stream state

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 07:33:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 11:33:31 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527113320.122363.11074.196ED194@psf.io>


Roundup Robot added the comment:

New changeset ca49614989dd by Martin Panter in branch '3.5':
Issue #5784: wbits=0 apparently added in zlib v1.2.3.5
https://hg.python.org/cpython/rev/ca49614989dd

New changeset 1771f0ac9fc2 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/1771f0ac9fc2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From paxguy at yahoo.com  Thu May 26 16:43:54 2016
From: paxguy at yahoo.com (Don Webster)
Date: Thu, 26 May 2016 20:43:54 +0000 (UTC)
Subject: [docs] socket.shutdown: how should be socket.SHUT_*
References: <707503854.10323.1464295434628.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <707503854.10323.1464295434628.JavaMail.yahoo@mail.yahoo.com>

Regarding this page:

https://docs.python.org/2/library/socket.html#socket.create_connection

In the description for socket.shutdown, the values for "how" are incorrectly listed as SHUT_RD, SHUT_WR and SHUT_RDWR

They should be: socket.SHUT_RD, socket.SHUT_WR and socket.SHUT_RDWR

Thanks,
don..

Error when using SHUT_WR instead of socket.SHUT_WR:
Traceback (most recent call last): 
File "p.py", line 21, in <module> 
cli.shutdown(SHUT_WR) 
NameError: name 'SHUT_WR' is not defined 

From liaapass at gmail.com  Thu May 26 23:29:08 2016
From: liaapass at gmail.com (Lisa Passadore)
Date: Thu, 26 May 2016 20:29:08 -0700
Subject: [docs] Print out 2.7.11 Python Reference Library
Message-ID: <CAEzA9BDVWXk=ifnSsU_DYtdvazrZcfSqmtfRrDW13x3JiF3P5Q@mail.gmail.com>

Hi,

I'm new to python and I'm trying to find a paper print out for Python
2.7.11 Reference Library - it's available pdf but I'm such a paper person
and know that I'll want to have an actual booklet of it.  BUT ITS HUGE and
will cost me over a hundred dollars to print out.

Any suggestions??  I've tried searching for a print of it and cant find
anything.

Thank you for your time,

Lisa Bisby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20160526/23b26bf3/attachment.html>

From report at bugs.python.org  Fri May 27 09:47:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 13:47:46 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527134734.13769.29920.6590F6A8@psf.io>


Roundup Robot added the comment:

New changeset 0df93ab07a8f by Martin Panter in branch '2.7':
Issue #5784: Cannot test wbits=0 unless we know we have zlib v1.2.3.5
https://hg.python.org/cpython/rev/0df93ab07a8f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 10:00:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 14:00:48 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464357648.71.0.982575944033.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

Apparently zlib only supports windowBits (wbits) = 0 since v1.2.3.5. I added a version check in the Python 3 tests, which seems to have solved the buildbot problems (OpenIndiana and OS X buildbots). In Python 2 I removed the test, because Python 2 has no zlib.ZLIB_RUNTIME_VERSION to check.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 10:08:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 14:08:35 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464358115.0.0.741769889905.issue5784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> In Python 2 I removed the test, because Python 2 has no zlib.ZLIB_RUNTIME_VERSION to check.

It makes sense. You didn't touch the C code of the module, only doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 12:18:27 2016
From: report at bugs.python.org (Nathan Harold)
Date: Fri, 27 May 2016 16:18:27 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464365907.39.0.530323734626.issue27043@psf.upfronthosting.co.za>


Nathan Harold added the comment:

Split version (cleandoc2.patch):

   Clean up indentation from docstrings that are indented to line up with blocks
   of code.
   
   All leading whitespace is removed from the first line.  Any leading whitespace
   that can be uniformly removed from the second line onwards is removed.  Empty
   lines at the beginning and end are subsequently removed.  Also, all tabs are
   expanded to spaces.

----------
Added file: http://bugs.python.org/file43030/cleandoc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Fri May 27 14:16:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 18:16:46 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464373006.74.0.337536596891.issue5784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would write the test as:

    v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
    supports_wbits_0 = v >= (1, 2, 3, 5)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 15:57:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 19:57:11 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1464373006.74.0.337536596891.issue5784@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaWympBuvy5oHp=ekxh054aNWw+RXjzWoqDPwqr353kYA@mail.gmail.com>


STINNER Victor added the comment:

I agree Serhiy :-) i hesitated to propose exactly the same change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 19:00:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 23:00:55 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464390055.05.0.219285839553.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

> v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
> supports_wbits_0 = v >= (1, 2, 3, 5)

That was basically my first thought. But I didn?t want to presume that every element of the version is an integer. For instance, the current string in the ?develop? branch of zlib has "1.2.8.1-motley".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 20:34:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 May 2016 00:34:36 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1464395675.73.0.13462442272.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

Porting this to Python 2 uncovered a few flaws that I am unsure how to best handle. In this patch I have added workarounds, but perhaps we can find better fixes.

1. The io.BytesIO.write() C implementation does not accept array.array() objects. I suspect it only accepts objects implementing the ?new? memoryview() buffer protocol, and array() only implements the ?old? buffer() protocol.

In Python 2, is array.array() considered a bytes-like object? If so, the proposed update to the write() documentation is not consistent. Perhaps it is a real bug to fix in the BytesIO implementation. Or is test_array_writes() just going too far for Python 2?

I added code to skip the relevant test in test_array_writes(). Maybe it would be simplest to document that in general, BufferedIOBase.write() only has to accept ?new? memoryview()-able objects.

2. The _pyio.BufferedIOBase.readinto() native Python implementation cannot assign into arbitrary bytes-like objects. Python 2 does not have memoryview.cast("B"), buffer() objects seem to be read-only, and I can?t think of any other easy way.

I reverted back to only testing native Python readinto() methods with bytearray(). But perhaps it would be best to document that for Python 2, only memoryview()-able arrays of bytes are acceptable, which should be practical to  handle in native Python code.

3. The _pyio.BytesIO.write() and BufferedWriter.write() native Python implementations did not handle obscure bytes-like objects well. I added buffer() calls to the code. But I am not sure this is a good idea, because it will raise warnings with ?python -3?. An alternative might be to again only require write() to accept memoryview()-able arrays of bytes.

Perhaps the Python 2 definition of ?bytes-like object? should be restricted to the ?new? memoryview() buffer protocol, and to 1-D arrays of bytes. I.e. memoryview(byteslike).ndim == 1 and memoryview(byteslike).format == "B".

----------
Added file: http://bugs.python.org/file43033/bytes-like-param.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Fri May 27 21:35:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 01:35:49 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <20160528013544.10672.51562.8BD38E08@psf.io>


Roundup Robot added the comment:

New changeset bd41151a7429 by Martin Panter in branch '3.5':
Issue #20699: Document that ?io? methods accept bytes-like objects
https://hg.python.org/cpython/rev/bd41151a7429

New changeset c1b40a29dc7a by Martin Panter in branch 'default':
Issue #20699: Merge io bytes-like fixes from 3.5
https://hg.python.org/cpython/rev/c1b40a29dc7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Fri May 27 22:35:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 02:35:38 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <20160528023533.18926.50493.88197C75@psf.io>


Roundup Robot added the comment:

New changeset 4275181c4229 by Martin Panter in branch '3.5':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/4275181c4229

New changeset 8c92ebcca83f by Martin Panter in branch 'default':
Issue #26553: Merge capitalization from 3.5
https://hg.python.org/cpython/rev/8c92ebcca83f

New changeset d914d681b7f3 by Martin Panter in branch '2.7':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/d914d681b7f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Fri May 27 23:12:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 May 2016 03:12:39 +0000
Subject: [docs] [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464405159.91.0.421448358514.issue26553@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou Nathan, and also Anish & Aatish.

For the record, it is normally enough to do a patch against the latest (3.6), and any minor conflicts can be sorted out when applying it to 3.5. In this case the 3.5 and 3.6 patches were basically the same. But the separate patch for 2.7 was very helpful, because there are so many differences between 2 and 3.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Fri May 27 23:53:32 2016
From: report at bugs.python.org (Ben Finney)
Date: Sat, 28 May 2016 03:53:32 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1464365907.39.0.530323734626.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160528035323.GE2150@benfinney.id.au>


Ben Finney added the comment:

On 27-May-2016, Nathan Harold wrote:
> 
> Split version (cleandoc2.patch):
> 
>    Clean up indentation from docstrings that are indented to line up
>    with blocks of code.
>    
>    All leading whitespace is removed from the first line. Any
>    leading whitespace that can be uniformly removed from the second
>    line onwards is removed. Empty lines at the beginning and end are
>    subsequently removed. Also, all tabs are expanded to spaces.

That looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sat May 28 01:12:17 2016
From: report at bugs.python.org (Ketan Bhatt)
Date: Sat, 28 May 2016 05:12:17 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1464412337.81.0.592228485963.issue26149@psf.upfronthosting.co.za>


Ketan Bhatt added the comment:

I would want to work on this, for 2 days. 
This is going to be my first contribution to python, please bear with me if i make some silly mistake.

Looking forward to your support. Thank you

----------
nosy: +Ketan Bhatt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26149>
_______________________________________

From report at bugs.python.org  Sat May 28 02:44:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 06:44:41 +0000
Subject: [docs] [issue20699] Document that binary IO classes work with
 bytes-likes objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1464417881.1.0.468302430782.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Things are more complex in 2.7. Not all objects supporting old buffer protocol support new buffer protocol, and not all functions accepting old buffer protocol work with new buffer protocol.

>>> buffer(array.array('I'))
<read-only buffer for 0xb70fec00, size -1, offset 0 at 0xb70feb60>
>>> memoryview(array.array('I'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface
>>> zlib.compress(buffer('abc'))
"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress(memoryview('abc'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: compress() argument 1 must be string or read-only buffer, not memoryview

The definition of the "bytes-like object" term (changed in 74e1c50498f8) looks not correct in 2.7, because it mentions memoryview (rarely supported in 2.7 besides backported from 3.x features), but not buffer (widely supported in 2.7). It is referred only in one place (in Doc/library/hmac.rst, copied from 3.x in issue21306). I would suggest to avoid using this term, and be more specific about supported protocols in every concrete case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sat May 28 17:14:38 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 May 2016 21:14:38 +0000
Subject: [docs] [issue7951] Should str.format allow negative indexes when
 used for __getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1464470078.38.0.56457724517.issue7951@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Sat May 28 19:58:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 May 2016 23:58:03 +0000
Subject: [docs] [issue25592] distutils docs: data_files always uses
 sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1464479883.29.0.692084262755.issue25592@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Distutils
nosy: +berker.peksag, dstufft, eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Sat May 28 21:10:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 01:10:37 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <20160529011033.122114.86376.663BDDF6@psf.io>


Roundup Robot added the comment:

New changeset ef89ecb6debc by Martin Panter in branch '3.5':
Issue #27124: Fix documentation of exception raised by a2b_hex()
https://hg.python.org/cpython/rev/ef89ecb6debc

New changeset 85e6da63d73f by Martin Panter in branch 'default':
Issue #27124: Merge binascii doc from 3.5
https://hg.python.org/cpython/rev/85e6da63d73f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Sat May 28 23:44:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 03:44:20 +0000
Subject: [docs] [issue27124] binascii.a2b_hex raises binascii.Error and
 ValueError, not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464493460.37.0.406454997113.issue27124@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Sun May 29 03:35:42 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 07:35:42 +0000
Subject: [docs] [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464507342.88.0.738108320068.issue27150@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python
type:  -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 04:10:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 08:10:27 +0000
Subject: [docs] [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464509427.68.0.396436938394.issue27150@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t see any violation or anything needing fixing in the documentation or code. Can you elaborate?

The fcntl() documentation says ?The values used for ?cmd? [F_DUPFD, etc] are operating system dependent, and are available as constants in the ?fcntl? module, using the same names as used in the relevant C header files.? The newest version of Posix specifies both the F_DUPFD and F_DUPFD_CLOEXEC. It would be misleading for Python to use one when the user specified the other.

If you want a best-effort version of F_DUPFD_CLOEXEC for a single-threaded program, why not use os.dup()? I presume this uses F_DUPFD_CLOEXEC where appropriate, and uses some non-atomic fallback if necessary.

----------
nosy: +haypo, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 05:09:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 09:09:16 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <20160529090858.30683.24668.68E2D32A@psf.io>


Roundup Robot added the comment:

New changeset c817d1b5b937 by Martin Panter in branch '2.7':
Issue #27125: Fix various errors like ?will [be] inherited?
https://hg.python.org/cpython/rev/c817d1b5b937

New changeset f7c85accbde9 by Martin Panter in branch '3.5':
Issue #27125: Fix various errors like ?will [be] inherited?
https://hg.python.org/cpython/rev/f7c85accbde9

New changeset 169551a8d5d1 by Martin Panter in branch 'default':
Issue #27125: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/169551a8d5d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 05:11:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 May 2016 09:11:49 +0000
Subject: [docs] [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464509427.68.0.396436938394.issue27150@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZJbB8pT68y0QC+GRb2VN1c5R6jO9CpB=A79TGrZE8DMQ@mail.gmail.com>


STINNER Victor added the comment:

I don't think that it's possible nor worth it to wrap all fcntl() and all
ioctl() calls. I see these functions as very low-level APIs and so I
consider that the caller is responsible of what he/she does.

If you want to change something, explian in fcntl module doc that the PEP
466 is not implemented in this module znd it's a deliberate choice.

I agree with Martin, it's the responsability of the dev to use the right
command depending on the use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 06:43:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 10:43:00 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464518580.03.0.683807792625.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report Phoenix

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 13:41:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 17:41:26 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464543686.73.0.0235130272554.issue27125@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lib/tkinter/tix.py:

-    and a label into one mega widget. It can beused be used to simplify
+    and a label into one mega widget. It can be used be used to simplify

Isn't "be used" duplicated?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 14:26:37 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 18:26:37 +0000
Subject: [docs] [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464546397.76.0.0587186832778.issue27150@psf.upfronthosting.co.za>


???? ????????? added the comment:

OK, it will be consistent, if docs mention that F_DUPFD will not set O_CLOEXEC automatically, mentiont that F_DUPFD_CLOEXEC should be used for that, and also mention PEP446 somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 15:15:29 2016
From: report at bugs.python.org (Ben Kane)
Date: Sun, 29 May 2016 19:15:29 +0000
Subject: [docs] [issue27155] '-' sign typo in example
Message-ID: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>


New submission from Ben Kane:

On page https://docs.python.org/3/library/subprocess.html#replacing-os-system

it looks like the code in the realistic example has a spurious '-' sign.
The line:

        print("Child was terminated by signal", -retcode, file=sys.stderr)

shouldn't have the minus sign negating the retcode:

        print("Child was terminated by signal", retcode, file=sys.stderr)

Full code in the example:

try:
    retcode = call("mycmd" + " myarg", shell=True)
    if retcode < 0:
        print("Child was terminated by signal", -retcode, file=sys.stderr)
    else:
        print("Child returned", retcode, file=sys.stderr)
except OSError as e:
    print("Execution failed:", e, file=sys.stderr)

should be:

try:
    retcode = call("mycmd" + " myarg", shell=True)
    if retcode < 0:
        print("Child was terminated by signal", retcode, file=sys.stderr)
    else:
        print("Child returned", retcode, file=sys.stderr)
except OSError as e:
    print("Execution failed:", e, file=sys.stderr)

Thanks, and apologies if I erred somewhere in this report.

----------
assignee: docs at python
components: Documentation
messages: 266614
nosy: Ben Kane, docs at python
priority: normal
severity: normal
status: open
title: '-' sign typo in example
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Sun May 29 15:23:18 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 19:23:18 +0000
Subject: [docs] [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464549797.99.0.790982908427.issue27155@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

A negative return code generally means an error occurred. Negating retcode here is equivalent to abs(retcode), which shows you want a positive integer to appear in the message - it's not an error.

Could replace '-retcode' with 'abs(retcode)' to be more clear. Possibly also add a comment in the code example body to further clarify this.

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Sun May 29 16:29:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:29:48 +0000
Subject: [docs] [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464553788.41.0.708846829559.issue27155@psf.upfronthosting.co.za>


R. David Murray added the comment:

The negative return code indicates the child was terminated by a signal, exactly as the example error message says.  The signal number is the positive value of the return code.  It makes more sense to negate it than it does to call abs, since we *know* it is negative.

IMO the example is correct as written.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Sun May 29 20:32:11 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 00:32:11 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464568331.07.0.283013492802.issue27043@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 20:58:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 00:58:52 +0000
Subject: [docs] [issue18478] Class bodies: when does a name become local?
In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za>
Message-ID: <1464569932.41.0.511536538573.issue18478@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I can see this has been fixed by explaining the special rules for class definitions at the end of the section.  Do you think there is anything left to do here, Terry?  Perhaps a 2.7 backport of some of the clarifications?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18478>
_______________________________________

From report at bugs.python.org  Sun May 29 21:07:55 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 01:07:55 +0000
Subject: [docs] [issue24647] Document argparse.REMAINDER as being equal to
 "..."
In-Reply-To: <1437079645.1.0.921184801927.issue24647@psf.upfronthosting.co.za>
Message-ID: <1464570475.44.0.231341603054.issue24647@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would say nargs='...' is borderline...it's meaning is *fairly* intuitive, but unlike the other three it does not, as paul.j3 points out, have a regex (or shell) counterpart.

I think we should respect the original author's decision in this case and leave well enough alone.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24647>
_______________________________________

From report at bugs.python.org  Sun May 29 21:24:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 May 2016 01:24:58 +0000
Subject: [docs] [issue18478] Class bodies: when does a name become local?
In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za>
Message-ID: <1464571498.01.0.681143201138.issue18478@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The new language *and* organization introduced sometime during 3.4 is good enough for me. " with an exception that unbound local variables are looked up in the global namespace." covers my example. Thanks for the pointer.

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18478>
_______________________________________

From report at bugs.python.org  Sun May 29 22:22:02 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 02:22:02 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464574922.77.0.157239039824.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you for the patch, Dave.

Following the language style of rest of the docs, check_same_thread, should be explained in a passive voice.

Also, mentioning the version requirement at this place, does not seem suitable to me. When we provide this feature, it assumed that the underlying sqlite linked has the support for it.

Also, (3.3.1 alpha) of sqlite was released in 2006-01-16 
Database connections can now be used by multiple threads, not just the thread in which they were created.

Here is a modified patch which captures the main idea from your patch. Please review this and share your suggestions.

----------
nosy: +orsenthil
Added file: http://bugs.python.org/file43052/issue27113-rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Sun May 29 23:34:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 May 2016 03:34:19 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464579259.37.0.0941599948338.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Indeed it is duplicated! I must have read this in my head many times before pushing it, and never picked it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 23:38:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 03:38:04 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160530033800.103233.68121.7FC75071@psf.io>


Roundup Robot added the comment:

New changeset c1eb32e183fd by Senthil Kumaran in branch '3.5':
issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/c1eb32e183fd

New changeset 4d5a5d4e731d by Senthil Kumaran in branch 'default':
[merge from 3.5] issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/4d5a5d4e731d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:39:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 03:39:02 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160530033900.18944.45025.72DB0B36@psf.io>


Roundup Robot added the comment:

New changeset 8f841baa0e06 by Senthil Kumaran in branch '2.7':
issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/8f841baa0e06

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:39:47 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 03:39:47 +0000
Subject: [docs] =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect?=
 =?utf-8?q?=2Ecleandoc=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464579587.74.0.409523265037.issue27043@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch, Nathan.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:51:10 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 03:51:10 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464580270.8.0.569068980186.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

We should be able to simplify this further based on the comments in the review for the first patch.

Please find my patch issue27113-rev2.patch attached.

----------
Added file: http://bugs.python.org/file43053/issue27113-rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From senthil at uthcode.com  Sun May 29 23:52:35 2016
From: senthil at uthcode.com (senthil at uthcode.com)
Date: Mon, 30 May 2016 03:52:35 -0000
Subject: [docs] sqlite3 open parameter "check_same_thread" not
 documented (issue 27113)
Message-ID: <20160530035235.18285.86624@psf.upfronthosting.co.za>

I agree with both comments made by Thomas. I have attached an updated
patch based upon original patch by Dave Sawyer.


http://bugs.python.org/review/27113/

From report at bugs.python.org  Mon May 30 01:27:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 05:27:38 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <20160530052705.23323.97728.A7C018E9@psf.io>


Roundup Robot added the comment:

New changeset 824d32436198 by Martin Panter in branch '2.7':
Issue #27125: Remove duplicated words from documentation and comments
https://hg.python.org/cpython/rev/824d32436198

New changeset fd0ac7ba091e by Martin Panter in branch '3.5':
Issue #27125: Remove duplicated words from documentation and comments
https://hg.python.org/cpython/rev/fd0ac7ba091e

New changeset e553b5ef7ff3 by Martin Panter in branch 'default':
Issue #27125: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/e553b5ef7ff3

New changeset bd0a12277a8e by Martin Panter in branch 'default':
Issue #27125: Remove duplicated words in exception message
https://hg.python.org/cpython/rev/bd0a12277a8e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Mon May 30 02:10:27 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Mon, 30 May 2016 06:10:27 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464588627.59.0.781836303705.issue27113@psf.upfronthosting.co.za>


Dave Sawyer added the comment:

The revised patch says "connections" plural for true and "connection" singular for false. How about "the connection" since the method returns a connection. I'm wondering though about the lack of explanation or WHY for this parameter. As written it seems like the default value was poorly chosen and everyone should just set it to true. Likewise, if everyone should set it to true, why is it even provided as an option?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Mon May 30 02:48:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 06:48:36 +0000
Subject: [docs] [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464590916.29.0.137662043898.issue27125@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm impressed by the number of duplicates left after all past cleanups.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Mon May 30 11:10:11 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Mon, 30 May 2016 15:10:11 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1464621011.34.0.624036771921.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Ping. Please advise on next step to get this submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Mon May 30 15:09:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 19:09:48 +0000
Subject: [docs] [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1464635388.53.0.507514454664.issue12691@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is there anything left to do here?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12691>
_______________________________________

From report at bugs.python.org  Mon May 30 15:33:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 May 2016 19:33:24 +0000
Subject: [docs] [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1464636804.37.0.833535352826.issue12691@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If there are, I can't remember.  This was one or 7 or 8 untokenize issues with about 5 separate bugs between them.  If there are any current untokenize issues not covered by some other open issue, then a new issue should be opened.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12691>
_______________________________________

From report at bugs.python.org  Mon May 30 21:21:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 May 2016 01:21:30 +0000
Subject: [docs] [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1464657690.05.0.686037362526.issue22558@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Mon May 30 23:06:14 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 May 2016 03:06:14 +0000
Subject: [docs] [issue27113] sqlite3 connect parameter "check_same_thread"
 not documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464663974.78.0.229948632909.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the review. Made it both singular in the updated patch.

* As for why the default value was chosen to be to True, I think, the reason is pysqlite, from sqlite3 module was derived, did not support this option when it was introduced. I still do not find that in pysqlite external library.

That being said, if we want to change the default to looking into multiple threads, we could attempt that change and introduce it. This will be a separate feature request ticket.

----------
Added file: http://bugs.python.org/file43063/issue27113-rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Tue May 31 00:01:56 2016
From: report at bugs.python.org (Ben Kane)
Date: Tue, 31 May 2016 04:01:56 +0000
Subject: [docs] [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464667315.96.0.496402660975.issue27155@psf.upfronthosting.co.za>


Ben Kane added the comment:

https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode

does mention the negativeness about returncode in conjunction with POSIX signals. It would be helpful to mention this Python-specific (I think) behavior in a comment. 
However, returncode can also be set by poll() and wait(), which can also return errors. In the more realistic example, I would appreciate code that handles those errors as well (a check for returncode > 0), or a comment detailing that other errors aren't handled. I copied that code into mine, and didn't consider those cases initially, because "realistic" was in the description.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Tue May 31 04:49:02 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 08:49:02 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464684542.75.0.48222571327.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

Hi,

The thread on python-ideas did not raised a long conversation, I don't think many english speaking people are interested in this subject, and non-english people are not in this list.

BWT, we translated a lot since march: translated 23% of the strings (versus 14% in march), and we'd like to serve a greater number of readers by hitting docs.python.org/fr/, so this messages is a ... bump ?

If I can help in anything, don't hesitate, but I think there's almost nothing left to, I already provided a patch for https://github.com/python/docsbuild-scripts to build the internationalized versions of documentation, tested it as far as I can without knowing your production servers by replicating the same paths on my test machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 05:00:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2016 09:00:57 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464685257.26.0.610775522798.issue26546@psf.upfronthosting.co.za>


STINNER Victor added the comment:

About the URL, we are only talking about 4 languages:

* english
* french
* japanese
* spanish

For docs.python.org.ar, I don't know if it's "spanish" or "spanish of Argentina"?

For a technical documentation, I don't expect to have a flavor of the docuemntation for the USA, UK, Australia, etc. It's the same for french, I only expect one french version. Same for japanese. For spanish, maybe we might support to have other flavors?

We can take a look at PHP documentation since they already support a wide choice of languages. English is "en", french is "fr", japanese is "jp", spanish is "es". Only Brazilian Portuguese uses "pt_BR".

PHP uses the URL http://php.net/manual/<language code>/

I suggest to make english "implicit", the default, and don't break existing URLs since they are now hardcoded in many books, many websites, etc. I don't think that it's worth to add "/en/" and add many redirection pages.

What do you think?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 06:03:02 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 10:03:02 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464688982.26.0.635019104143.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

> About the URL, we are only talking about 4 languages

Yes, and other are clearly not ready to be merged, I still don't know if they want it to happen soon.

> For docs.python.org.ar, I don't know if it's "spanish" or "spanish of Argentina"?

Same conclusion: I don't know either, but let them decide. In all cases, we'll not merge them until they ask for it, so, probably not even this year. Let's do things one by one, showing the way. (Personally I think we may propose them /es/, and if a es_ES version shows up, move `/es/` to `/es-ar/` and give `/es/` to es_ES, but that may just never happen...).

> For a technical documentation, I don't expect to have a flavor of the docuemntation [...] English is "en", french is "fr", japanese is "jp", spanish is "es". Only Brazilian Portuguese uses "pt_BR".

Yes [my proposition](https://mail.python.org/pipermail/python-ideas/2016-March/038879.html) has a whole paragraph about "Dropping the default locale of a language". Around the same subject, it's still undecided if we use a dash (IETF format) or an underscore (gettext format) to separate language and locale, but as we only have "fr" from now, we don't really have to decide today. We'll have to decide when we'll merge "pt-br" which does not even exists (one of some few languages having a "mandatory locale part").

> I suggest to make english "implicit", the default, and don't break existing URLs

+1, we do not need to break anything, let's just don't add `/en/` for "upstream" documentation, that's in fact what my proposed patch does.

> What do you think?

Look like we agree on all points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 12:04:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 16:04:58 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464710698.13.0.247709460926.issue26546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From what I know of regional and country variations in spanish, the main grammatical differences are in usages, such as the informal plural 2nd person, that need not appear in a techical manual.  I don't know about recently acquired technical terms.  From reading pyar for awhile, I also know that it has participants from all over latin america, so I suspect that their translation is not necessarily Argentina-specific.  Conclusion: we (pydev) should not worry until there is an actual conflict from competing translations.

The patch has this table:

+               # version, target, isdev
+               ('3.4', WWWROOT + "/3.4", False),
+               ('3.5', WWWROOT + "/3.5", False),
+               ('3.6', WWWROOT + "/3.6", True),
+               ('2.7', WWWROOT + "/2.7", False)

Why is 3.4 included, given that it now has the same status as 3.3?
Would it not be easier to default to False and only list 3.6?
Is it because you maintain separate branches for different 3.x branches?  Given the presence of Version Changed and Version Added paragraphs, that is almost unnecessary.  (Not having Version Deleted items is the main reason they might be.)

Is/are the main author/maintainer(s) of build_docs.py already nosy on the issue, to review?  I cannot even though at least mildly interested.
(The disconnect between interest and technical expertise is part of the problem with translation issues.)

There is no Rietveld review link for the patch.  I do not know if it is the form of the patch or the target file.  Viktor, do you?  If not, someone on the core-mentorship list would.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 12:20:30 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 May 2016 16:20:30 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464711630.29.0.182215757866.issue26546@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I think you should submit this as a PR against docsbuild-scripts, it will be easier to review there.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 12:35:02 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 16:35:02 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464712501.85.0.519007430633.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

> From what I know of regional and country variations in spanish, [...] we (pydev) should not worry until there is an actual conflict from competing translations.

Totally agree.

> The patch has this table:

> +               # version, target, isdev
> +               ('3.4', WWWROOT + "/3.4", False),
> +               ('3.5', WWWROOT + "/3.5", False),
> +               ('3.6', WWWROOT + "/3.6", True),
> +               ('2.7', WWWROOT + "/2.7", False)

Yes, it sticks to the current style: https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L33

> Why is 3.4 included, given that it now has the same status as 3.3?

What do you mean with "the same status" ? From my translator point of view, they still diverges, like in `Doc/library/zlib.rst:233`:

< "If the optional parameter *max_length* is supplied then the return value "
---
> "If the optional parameter *max_length* is non-zero then the return value "

And I don't think we can rely on certain releases being theorically identical to others, it look like an exception, look like it's not always true. I still prefer having a [clear tree of versions](https://github.com/AFPy/python_doc_fr) but we're (humans) only translating the latest version, we have scripts replicating our work to others.

Yet, if you tell me that there's work ongoing (that I clearly missed) to have every documentations, like by major version, converge to single one, with just some paragraphs added, it may simplify my hierarchy.

> Would it not be easier to default to False and only list 3.6?

Again I stick to the current style of the script, so ease its reading as a whole, but I agree, if we change it, let change it in another commit?

> Is it because you maintain separate branches for different 3.x branches?  Given the presence of Version Changed and Version Added paragraphs, that is almost unnecessary.  (Not having Version Deleted items is the main reason they might be.)

I am not aware of "Version Added" and "Version Changed" paragraphs, I understand that this is a policy to only add new paragraphs and never modify them inside the `3` major version ? This is cool for me, as said in my last paragraph, it may reduce the number of versionned `.po`, but it will not change the human workload (script replicating between po files ...).

> Is/are the main author/maintainer(s) of build_docs.py already nosy on the issue, to review?

Yes, I soon `nosy`ed Benjamin Peterson, look like he's the father of this script, if we trust commits here: https://github.com/python/docsbuild-scripts/commits/master

I even mailed him personally to speak about it (and he even replied once), but he's probably highly busy, and this is something I can understand. So here is my call on the issue to try to move this issue forward (I try to push this project less than once a month, to avoid buzzing everyone ears with this non-critical issue...).

> I cannot even though at least mildly interested. (The disconnect between interest and technical expertise is part of the problem with translation issues.)

Yes I also fully understand that the french translation of the documentation is not a point of interest for most of you upstream ^^ don't worry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 14:26:31 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 18:26:31 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464719191.22.0.492307988366.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

@zach.ware done: https://github.com/python/docsbuild-scripts/pull/1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 14:50:00 2016
From: report at bugs.python.org (Nathan Harold)
Date: Tue, 31 May 2016 18:50:00 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464720600.49.0.6235522954.issue26176@psf.upfronthosting.co.za>


Nathan Harold added the comment:

emailexample.patch fixes the specific issue mentioned in #26426: the Address constructor is now used as documented.  It changes the final output of the two combined examples (as presented in the documentation) accordingly.

In general it seems as though these examples (the two in in 19.1.14.1) were meant to be read, not run.  To run them, the user would have to supply (1) their own roasted-asparagus.jpg, (2) their own local SMTP server, and (3) their own implementation of imaginary.magic_html_parser.  However, the Address constructor usage issue was real, and I was able to generate the relevant output without (2) and (3).

----------
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43070/emailexample.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Tue May 31 16:24:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 20:24:29 +0000
Subject: [docs] [issue26546] Provide translated french translation on
 docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464726269.68.0.557911823397.issue26546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

By 'same status', I meant that 3.4 is on 'security maintenance', just like 3.3 and 3.2.  But do whatever a reviewer wants.

Some people are busy at PyCon this week.  Anyway, I think Zack pointed you in the right direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 17:03:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 21:03:53 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464728633.31.0.796522968953.issue26176@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thank you for the patch.  I blame the mistake on too great a familiarity with the old API :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Tue May 31 17:04:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 21:04:09 +0000
Subject: [docs] [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464728649.92.0.8931223258.issue26176@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Tue May 31 17:14:20 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:14:20 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729260.07.0.544603757097.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

This diff updates the cpython (tip) documentation to document the different behaviour when using splitlines on bytes objects or string objects.

----------
keywords: +patch
nosy: +Alexander Schrijver
Added file: http://bugs.python.org/file43071/cpython3.5_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 17:16:10 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:16:10 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729370.48.0.351675124485.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

This diff synchronizes the cpython 2.7 with that from 3.5 and also describes the difference between bytes objects and unicode objects (from the other diff)

----------
Added file: http://bugs.python.org/file43072/cpython3.5_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 17:20:36 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:20:36 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729636.36.0.802797914432.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

Oops, wrong diff. Sorry, this is the correct one for 2.7.

----------
Added file: http://bugs.python.org/file43075/cpython2.7_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 19:05:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 23:05:51 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464735951.06.0.260772011418.issue22232@psf.upfronthosting.co.za>


Martin Panter added the comment:

For Python 3, the bytes.splitlines() and bytearray.splitlines() documentation has been moved to a separate section out (Issue 21777). I don?t think it is good to add much detail of bytes.splitlines() in the str.splitlines() documentation.

For Python 2, perhaps see Matthew?s patches for 2.7 in Issue 12855. IMO we could reopen that bug if that helps, because only the Python 3 branches were comitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 20:20:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 00:20:45 +0000
Subject: [docs] [issue25570] urllib.request > Request.add_header("abcd",
 "efgh") fails with character ":" in first parameter string
In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za>
Message-ID: <1464740445.35.0.170835624069.issue25570@psf.upfronthosting.co.za>


Berker Peksag added the comment:

add_header.patch looks good to me. Thanks Martin.

----------
nosy: +berker.peksag
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25570>
_______________________________________

From report at bugs.python.org  Tue May 31 22:16:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 02:16:25 +0000
Subject: [docs] [issue20683] Add example to tutorial namespace doc,
 section 9.2
In-Reply-To: <1392798452.78.0.903259935516.issue20683@psf.upfronthosting.co.za>
Message-ID: <1464747381.43.0.57393828763.issue20683@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Karl. Could you give more details about what's missing? The section gives some examples of namespaces:

    [...] the set of built-in names (containing functions such as abs(), and built-in exception names); the global names in a module; and the local names in a function invocation.

I'm not sure if it's worth to convert them to code examples.

----------
nosy: +berker.peksag
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20683>
_______________________________________

From report at bugs.python.org  Tue May 31 23:17:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 03:17:27 +0000
Subject: [docs] [issue20496] function definition tutorial encourages bad
 practice
In-Reply-To: <1391404187.28.0.545168168954.issue20496@psf.upfronthosting.co.za>
Message-ID: <1464751047.67.0.519709443879.issue20496@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Terry. The print example is also useful to show the implicit return value of fib(). Quoting from the same section:

    [...] In fact, even functions without a return statement do return a value, albeit a rather boring one. This value is called None [...]

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20496>
_______________________________________

From report at bugs.python.org  Tue May 31 23:35:09 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 03:35:09 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing in
 tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1464752109.17.0.209410136957.issue17383@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: patch review -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17383>
_______________________________________