From report at bugs.python.org  Sun Mar  1 06:59:32 2015
From: report at bugs.python.org (Giovanni Cannata)
Date: Sun, 01 Mar 2015 05:59:32 +0000
Subject: [docs] [issue23554] EchoServerClientProtocol class should be
	called	EchoServerProtocol
Message-ID: <1425189572.41.0.939168822868.issue23554@psf.upfronthosting.co.za>


New submission from Giovanni Cannata:

In 18.5.4.3.2. TCP echo server protocol the class in the example code is called EchoServerClientProtocol.  It should be EchoServerProtocol. (The client protocol example is correctly called EchoClientProtocol).

----------
assignee: docs at python
components: Documentation
messages: 236932
nosy: docs at python, gc
priority: normal
severity: normal
status: open
title: EchoServerClientProtocol class should be called EchoServerProtocol
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar  1 13:17:22 2015
From: report at bugs.python.org (Jakub Klama)
Date: Sun, 01 Mar 2015 12:17:22 +0000
Subject: [docs] [issue23557] Misc/SpecialBuilds.txt contains outdated
	information	about PYMALLOC_DEBUG
Message-ID: <1425212242.29.0.401382556458.issue23557@psf.upfronthosting.co.za>


New submission from Jakub Klama:

Section describing block layout under PYMALLOC_DEBUG is wrong - it doesn't contain information about API type byte instead of one of forbidden bytes. That may lead to wrong assumption that one of forbidden bytes is being overwritten until you dig into obmalloc.c code.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 236958
nosy: Jakub Klama, docs at python
priority: normal
severity: normal
status: open
title: Misc/SpecialBuilds.txt contains outdated information about PYMALLOC_DEBUG
versions: Python 2.7

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

From report at bugs.python.org  Sun Mar  1 22:53:05 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 01 Mar 2015 21:53:05 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1425246785.35.0.513458563058.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the signature for acquire looks like:

    threading.Lock.acquire([blocking])


However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c implements multiprocessing.Lock.acquire to support two arguments:  'block' and 'timeout'.


In the docs for 3.4, threading.Lock.acquire now has both 'blocking' and 'timeout' arguments.  Notably, it specifies: "It is forbidden to specify a timeout when blocking is false."  This is indeed enforced by threading.Lock but not at all by multiprocessing.Lock.  In a 3.4.3 shell:

    >>> import multiprocessing
    >>> import threading
    >>> ml = multiprocessing.Lock()
    >>> ml.acquire(False, 20.0)
    True
    >>> ml.release()
    >>> tl = threading.Lock()
    >>> tl.acquire(False, 20.0)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ValueError: can't specify a timeout for a non-blocking call


In 2.7, acquire similarly permits a supplied value for timeout even when set to be non-blocking.

A further difference:  the code in Modules/_multiprocessing/semaphore.c appears to translate a timeout=None into an infinite wait whereas the threading implementation rejects any attempt to supply a None for timeout, demanding a float instead.  (In 3.4, threading uses timeout=-1 to request an infinite wait.)


Given these discrepancies between threading's and multiprocessing's implementations for Lock and given the difficulties in renaming an argument that can be supplied as a non-keyword parameter, the right thing to do at this point is to properly document multiprocessing.Lock's acquire as using 'block' and 'timeout'.

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

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

From report at bugs.python.org  Sun Mar  1 23:20:20 2015
From: report at bugs.python.org (Davin Potts)
Date: Sun, 01 Mar 2015 22:20:20 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1425248420.9.0.0163247389946.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

To be fair, the docs in 2.7 do actually mention the use of 'block' instead of 'blocking' in acquire though it does so inside a "Note" block a bit later in the docs after first claiming that multiprocessing.Lock is a "clone".

In 3.4, that important detail has been inexplicably stripped from this distended "Note" block.


Ultimately, this use of the "Note" block seems to misplace important information that should appear in the description of the multiprocessing.Lock class and its siblings in the synchronization section.

----------

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

From report at bugs.python.org  Mon Mar  2 05:33:53 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 04:33:53 +0000
Subject: [docs] [issue20521] [PATCH] Cleanup for "dis" module documentation
In-Reply-To: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za>
Message-ID: <20150302043350.20295.14909@psf.io>


Roundup Robot added the comment:

New changeset 617feb5d8af2 by Berker Peksag in branch '3.4':
Issue #20521: Change ``TOS`` to TOS in dis documentation.
https://hg.python.org/cpython/rev/617feb5d8af2

New changeset a331d71bdc0a by Berker Peksag in branch 'default':
Issue #20521: Change ``TOS`` to TOS in dis documentation.
https://hg.python.org/cpython/rev/a331d71bdc0a

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

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

From report at bugs.python.org  Mon Mar  2 05:35:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Mar 2015 04:35:10 +0000
Subject: [docs] [issue20521] Cleanup for "dis" module documentation
In-Reply-To: <1391608572.54.0.381225308012.issue20521@psf.upfronthosting.co.za>
Message-ID: <1425270910.01.0.135391339001.issue20521@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Sven. Most of the changes in your patch have already been fixed in issue 22845. Just committed the "``TOS`` -> TOS" part of the patch.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: [PATCH] Cleanup for "dis" module documentation -> Cleanup for "dis" module documentation

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

From report at bugs.python.org  Mon Mar  2 07:37:56 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Mar 2015 06:37:56 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425278276.26.0.761127848263.issue23512@psf.upfronthosting.co.za>


?ric Araujo added the comment:

IIRC the table was added in a 3.x branch and backported to 2.7; the developer doing the backport added the functions missing in 3.x to the end of the table, thinking that re-ordering was not worth the trouble.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Mar  2 07:52:56 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 06:52:56 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425279176.84.0.0415238364851.issue23512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

That was me in #10299 (the issue contains a discussion about the ordering in the last few messages).

Since there are only 4 functions, I think it would be ok removing them from the table and instead add a sentence like "In addition, there are other 4 built-in functions that are no longer considered essential: apply, buffer, coerce, and intern.  They are documented in the Non-essential Built-in Functions section.".

See also #16927 for a proposed grouping that might help solve this issue.

----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Mar  2 08:31:46 2015
From: report at bugs.python.org (Alex Shkop)
Date: Mon, 02 Mar 2015 07:31:46 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1425281506.18.0.615357651444.issue22832@psf.upfronthosting.co.za>


Alex Shkop added the comment:

This patch fixes pointed out bugs in documentation and docstring for ioctl() function.

----------
Added file: http://bugs.python.org/file38295/issue22832_v2.patch

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

From report at bugs.python.org  Mon Mar  2 08:43:48 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:43:48 +0000
Subject: [docs] [issue23455] file iterator "deemed broken";
	can resume after StopIteration
In-Reply-To: <1423766934.46.0.3718920034.issue23455@psf.upfronthosting.co.za>
Message-ID: <1425282228.52.0.32932890235.issue23455@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +pitrou
type:  -> behavior

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

From report at bugs.python.org  Mon Mar  2 08:46:41 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 07:46:41 +0000
Subject: [docs] [issue23460] Decimals do not obey ':g' exponential
	notation	formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425282401.72.0.21774413074.issue23460@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Should we add a note to the format docs, or just close this?

----------
nosy: +ezio.melotti, mark.dickinson

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

From report at bugs.python.org  Mon Mar  2 09:16:32 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:16:32 +0000
Subject: [docs] [issue23312] google thinks the docs are mobile unfriendly
In-Reply-To: <1422121325.13.0.140473067698.issue23312@psf.upfronthosting.co.za>
Message-ID: <1425284192.39.0.990440605534.issue23312@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Mon Mar  2 09:18:40 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:18:40 +0000
Subject: [docs] [issue23320] devguide should mention rules about "paragraph
	reflow"	in the documentation
In-Reply-To: <1422219993.92.0.674256323538.issue23320@psf.upfronthosting.co.za>
Message-ID: <1425284320.8.0.291970178009.issue23320@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Agreed with what Georg said and I think the devguide can be update accordingly.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Mon Mar  2 09:21:16 2015
From: report at bugs.python.org (=?utf-8?q?Rapha=C3=ABl_Bleuse?=)
Date: Mon, 02 Mar 2015 08:21:16 +0000
Subject: [docs] [issue23559] [doc] inconsistent range example output
Message-ID: <1425284476.5.0.408396499523.issue23559@psf.upfronthosting.co.za>


New submission from Rapha?l Bleuse:

Reading the documentation for ranges (see https://docs.python.org/3.5/library/stdtypes.html#ranges), the example using a negative index output is inconsistent with the range effective behaviour.

One can read:
"
>>> r[-1]
18
"

while (in my understanding) it should be:
"
>>> r[-1]
8
"

Note the output should be 8 and not 18.

Rapha?l

----------
assignee: docs at python
components: Documentation
messages: 237029
nosy: bleuse, docs at python
priority: normal
severity: normal
status: open
title: [doc] inconsistent range example output
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  2 09:31:44 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:31:44 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1425285104.69.0.787874194916.issue22933@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Mon Mar  2 09:34:04 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:34:04 +0000
Subject: [docs] [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1425285244.05.0.0230937031238.issue22942@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +Joshua.Landau, neil.g

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

From report at bugs.python.org  Mon Mar  2 09:36:58 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:36:58 +0000
Subject: [docs] [issue22785] range docstring is less useful than in python 2
In-Reply-To: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>
Message-ID: <1425285418.01.0.88135615938.issue22785@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +benjamin.peterson
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 09:40:01 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 08:40:01 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
In-Reply-To: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>
Message-ID: <1425285601.74.0.816411274053.issue22812@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Mon Mar  2 09:42:44 2015
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 02 Mar 2015 08:42:44 +0000
Subject: [docs] [issue23460] Decimals do not obey ':g' exponential
	notation	formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425285764.43.0.506403814234.issue23460@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I don't think we should close: the documentation as written explicitly says that the rules apply to both Decimal and float: "The available presentation types for floating point and decimal values are ...".  But the details listed for 'g' are incorrect.  We could either fix the description for 'g' to explain what happens for `Decimal`, or state up front that the table only applies directly to the `float` type, and that `Decimal` is similar but not identical.

----------

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

From report at bugs.python.org  Mon Mar  2 09:56:30 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 02 Mar 2015 08:56:30 +0000
Subject: [docs] [issue23559] [doc] inconsistent range example output
In-Reply-To: <1425284476.5.0.408396499523.issue23559@psf.upfronthosting.co.za>
Message-ID: <1425286590.22.0.434326720892.issue23559@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The example is correct.  "r" is a range(0, 20, 2), whose last element is 18.

----------
nosy: +georg.brandl
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Mar  2 10:12:24 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:12:24 +0000
Subject: [docs] [issue23460] Decimals do not obey ':g' exponential
	notation	formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425287544.63.0.916911834705.issue23460@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 10:28:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Mar 2015 09:28:10 +0000
Subject: [docs] [issue23560] Group the docs of similar methods in
	stdtypes.rst
Message-ID: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>


New submission from Ezio Melotti:

The Doc/library/stdtypes.rst page describes in detail the built-in types and their methods.  As suggested in #21777 (see the comments on Rietveld), it might be a good idea to group the documentation of some similar methods, such as {r|l|}just, {r|l|}strip, {r|}partition, {r|}index, and {r|}find.

This will remove some duplication, make the page shorter and easier to navigate, and make the methods easier to discover.  Adding tables containing the methods for each types has also been proposed.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 237036
nosy: docs at python, ezio.melotti
priority: normal
severity: normal
stage: needs patch
status: open
title: Group the docs of similar methods in stdtypes.rst
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar  2 11:42:30 2015
From: report at bugs.python.org (Novice Live)
Date: Mon, 02 Mar 2015 10:42:30 +0000
Subject: [docs] [issue23561] a little typo in dis.rst;
	need a non-trivial preceding dot
Message-ID: <1425292950.76.0.483712370522.issue23561@psf.upfronthosting.co.za>


New submission from Novice Live:

it is likely that the author of dis.rst omitted two non-trivial preceding dots.

in the 'Bytecode analysis' section,
both :meth:`dis` and :func:`dis` have no preceding dots before 'dis'.

the dots may be trivial elsewhere, but they are non-trivial here. 
otherwise, the hyperlinks will be unexpectedly targeted to the top of the dis module, rather than the corresponding dis method or function.

ref.
:meth:`.timeit`, where the 'timeit' was preceded by a dot, in timeit.rst.

:)

----------
assignee: docs at python
components: Documentation
files: dis_typo.patch
keywords: patch
messages: 237039
nosy: docs at python, n0vicelive
priority: normal
severity: normal
status: open
title: a little typo in dis.rst; need a non-trivial preceding dot
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38297/dis_typo.patch

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

From report at bugs.python.org  Mon Mar  2 15:37:39 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Mar 2015 14:37:39 +0000
Subject: [docs] [issue23561] a little typo in dis.rst;
	need a non-trivial preceding dot
In-Reply-To: <1425292950.76.0.483712370522.issue23561@psf.upfronthosting.co.za>
Message-ID: <20150302143707.53137.79691@psf.io>


Roundup Robot added the comment:

New changeset 10b563c32f9d by Benjamin Peterson in branch '3.4':
link to the correct dis method or function (closes #23561)
https://hg.python.org/cpython/rev/10b563c32f9d

New changeset 760f222103c7 by Benjamin Peterson in branch 'default':
merge 3.4 (#23561)
https://hg.python.org/cpython/rev/760f222103c7

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

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

From report at bugs.python.org  Mon Mar  2 19:05:10 2015
From: report at bugs.python.org (Andy Maier)
Date: Mon, 02 Mar 2015 18:05:10 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1425319509.72.0.291765427184.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


Added file: http://bugs.python.org/file38303/issue12067-expressions-py3.5_v14.diff

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

From report at bugs.python.org  Mon Mar  2 19:12:09 2015
From: report at bugs.python.org (Andy Maier)
Date: Mon, 02 Mar 2015 18:12:09 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1425319929.16.0.585512140955.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

I have posted v14 of the patch (for the 3.5 'default' branch), based on Martin's v13. v14 addresses all comments Martin made, as described in my responses to them (see patch set 10).

On Issue 4395: That issue should be pursued in addition to this issue; it seems Martin's patch for it is complementary to the patch for this issue here.

On Issue 22000: I agree that that issue is addressed by the patch for this issue here.

All: Please review the v14 patch.

----------

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

From report at bugs.python.org  Mon Mar  2 21:18:17 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 20:18:17 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425327497.55.0.878361746534.issue23512@psf.upfronthosting.co.za>


Carlo Beccarini added the comment:

diff -r 3019effc44f2 Doc/library/functions.rst
--- a/Doc/library/functions.rst	Mon Mar 02 11:17:05 2015 -0500
+++ b/Doc/library/functions.rst	Mon Mar 02 21:13:27 2015 +0100
@@ -22,10 +22,10 @@
 :func:`classmethod`  :func:`getattr`    :func:`map`         |func-repr|_       :func:`xrange`
 :func:`cmp`          :func:`globals`    :func:`max`         :func:`reversed`   :func:`zip`
 :func:`compile`      :func:`hasattr`    |func-memoryview|_  :func:`round`      :func:`__import__`
-:func:`complex`      :func:`hash`       :func:`min`         |func-set|_        :func:`apply`
-:func:`delattr`      :func:`help`       :func:`next`        :func:`setattr`    :func:`buffer`
-|func-dict|_         :func:`hex`        :func:`object`      :func:`slice`      :func:`coerce`
-:func:`dir`          :func:`id`         :func:`oct`         :func:`sorted`     :func:`intern`
+:func:`complex`      :func:`hash`       :func:`min`         |func-set|_        ..
+:func:`delattr`      :func:`help`       :func:`next`        :func:`setattr`    ..
+|func-dict|_         :func:`hex`        :func:`object`      :func:`slice`      ..
+:func:`dir`          :func:`id`         :func:`oct`         :func:`sorted`     ..
 ===================  =================  ==================  =================  ====================
 
 .. using :func:`dict` would create a link to another page, so local targets are
@@ -1699,6 +1699,11 @@
 Python programmers, trainers, students and book writers should feel free to
 bypass these functions without concerns about missing something important.
 
+===================  =================  ==================  =================
+..                     Non-essential    Built-in Functions  ..
+===================  =================  ==================  =================
+:func:`apply`        :func:`buffer`     :func:`coerce`      :func:`intern`
+===================  =================  ==================  =================
 
 .. function:: apply(function, args[, keywords])

----------
Added file: http://bugs.python.org/file38304/functools.rst

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

From report at bugs.python.org  Mon Mar  2 21:23:09 2015
From: report at bugs.python.org (SilentGhost)
Date: Mon, 02 Mar 2015 20:23:09 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425327789.6.0.848562593697.issue23512@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at gmail.com>:


Removed file: http://bugs.python.org/file38304/functools.rst

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

From report at bugs.python.org  Mon Mar  2 21:27:08 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 20:27:08 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425328028.44.0.653801087141.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Added file: http://bugs.python.org/file38305/functions.rst

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

From report at bugs.python.org  Mon Mar  2 22:14:26 2015
From: report at bugs.python.org (Edward D'Souza)
Date: Mon, 02 Mar 2015 21:14:26 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425330866.05.0.368173524955.issue23512@psf.upfronthosting.co.za>


Edward D'Souza added the comment:

I think putting them in a separate table is good, but I think it makes more sense to appear right below the existing table at the top of the page. For better or worse, these "non-essential" functions are still builtins in Python 2.

It would be disconcerting if you went to this page looking for a builtin (eg. coerce) and couldn't find it at the top of the page with the other builtins.

Above all, the list of "builtins" should be accurate as to what builtins actually exist in Python 2.

----------

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

From report at bugs.python.org  Mon Mar  2 22:59:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Mar 2015 21:59:58 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425333598.65.0.142252211486.issue23512@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

> It would be disconcerting if you went to this page looking for a builtin [and had trouble finding it]

I agree with this premise.  Since Idle, and I presume other IDEs, color code apply, coerce, intern, and buffer as builtins indistinguishably from all the others, these 4 should somehow be easy to find in or just below the rest.  I have no particular opinion on the best way to do so.

----------

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

From report at bugs.python.org  Mon Mar  2 23:00:46 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Mon, 02 Mar 2015 22:00:46 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425333646.75.0.446959779914.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Added file: http://bugs.python.org/file38307/functions.rst

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

From report at bugs.python.org  Tue Mar  3 01:10:20 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 00:10:20 +0000
Subject: [docs] [issue17352] Be clear that __prepare__ must be declared as a
	class	method
In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>
Message-ID: <1425341420.2.0.557808953232.issue17352@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Should __prepare__ be special-cased as a classmethod, like __new__ is?  Is there any reason to ever have __prepare__ /not/ be a classmethod?

----------

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

From report at bugs.python.org  Tue Mar  3 03:47:27 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 03 Mar 2015 02:47:27 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425350847.38.0.611901816677.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Removed file: http://bugs.python.org/file38305/functions.rst

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

From report at bugs.python.org  Tue Mar  3 05:31:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 03 Mar 2015 04:31:34 +0000
Subject: [docs] [issue23560] Group the docs of similar methods in
	stdtypes.rst
In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>
Message-ID: <1425357094.25.0.252403641332.issue23560@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Mar  3 13:36:22 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 03 Mar 2015 12:36:22 +0000
Subject: [docs] [issue17352] Be clear that __prepare__ must be declared as a
	class	method
In-Reply-To: <1362409892.83.0.717786566871.issue17352@psf.upfronthosting.co.za>
Message-ID: <1425386182.27.0.841463956219.issue17352@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

__new__ is a little weird - it's actually special cased as a staticmethod.

Your questions is still valid, though.

For existing versions, documenting the requirement is the only option. 

For future versions, we could conceivably implement a "decorate it if it isn't already decorated" fallback, but for backwards compatibility we'd have to avoid double-decorating explicitly decorated implementations.

----------

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

From report at bugs.python.org  Tue Mar  3 14:39:17 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 03 Mar 2015 13:39:17 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425389957.08.0.626644363212.issue23512@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti

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

From report at bugs.python.org  Tue Mar  3 14:56:04 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Tue, 03 Mar 2015 13:56:04 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425390964.14.0.466692458895.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38316/issue23512.diff

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

From report at bugs.python.org  Tue Mar  3 22:43:51 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:43:51 +0000
Subject: [docs] [issue23579] Amazon.com links
Message-ID: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords:easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237160
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:44:50 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:44:50 +0000
Subject: [docs] [issue23580] Amazon.com links
Message-ID: <1425419090.93.0.681413466025.issue23580@psf.upfronthosting.co.za>


New submission from Edrie Ddrie:

Keywords: easy
Priority: normal

----------
assignee: docs at python
components: Documentation
messages: 237161
nosy: Edrie Ddrie, docs at python
priority: normal
severity: normal
status: open
title: Amazon.com links
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Mar  3 22:45:33 2015
From: report at bugs.python.org (Edrie Ddrie)
Date: Tue, 03 Mar 2015 21:45:33 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425419133.84.0.82383418505.issue23579@psf.upfronthosting.co.za>


Edrie Ddrie added the comment:

There a links to Amazon in the official documentation.
(In Python 3.4 in the tkinter.html and othergui.html)

It's not right to advertise for a certain business.
When will the official documentation guide people to eat at MacDonalds ?
I is a sign of a low moral.

A more honest alternative is just to call the book title and author
and let people decide where they buy books.

----------

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

From report at bugs.python.org  Tue Mar  3 22:50:52 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Mar 2015 21:50:52 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425419452.39.0.415819925872.issue23579@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

If the mentioned books have official Web sites we could use a link to them.
Feel free to submit a patch.

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

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

From report at bugs.python.org  Tue Mar  3 23:31:08 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 22:31:08 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425421868.96.0.00683088364652.issue23579@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Tue Mar  3 23:32:00 2015
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 03 Mar 2015 22:32:00 +0000
Subject: [docs] [issue23580] Amazon.com links
In-Reply-To: <1425419090.93.0.681413466025.issue23580@psf.upfronthosting.co.za>
Message-ID: <1425421920.23.0.987669926194.issue23580@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman
resolution:  -> duplicate
status: open -> closed
superseder:  -> Amazon.com links

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

From report at bugs.python.org  Wed Mar  4 03:41:43 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Mar 2015 02:41:43 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1425436903.94.0.717503836765.issue22933@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Mar  4 15:35:07 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 04 Mar 2015 14:35:07 +0000
Subject: [docs] [issue23549] heapq docs should be more precise about how to
	access	the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <1425479707.54.0.0650257266424.issue23549@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Raymond - gentle ping.

Do you see a reason not to check this in?

----------

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

From report at bugs.python.org  Wed Mar  4 20:07:18 2015
From: report at bugs.python.org (Carlo Beccarini)
Date: Wed, 04 Mar 2015 19:07:18 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1425496038.9.0.312240151184.issue23512@psf.upfronthosting.co.za>


Changes by Carlo Beccarini <hackdiablo.cb at gmail.com>:


Removed file: http://bugs.python.org/file38307/functions.rst

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

From report at bugs.python.org  Thu Mar  5 04:02:16 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 05 Mar 2015 03:02:16 +0000
Subject: [docs] [issue19931] namedtuple docstrings are verbose for no added
	benefit
In-Reply-To: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>
Message-ID: <1425524536.09.0.745269505933.issue19931@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> enhancement
versions: +Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Mar  5 09:32:38 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 08:32:38 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
Message-ID: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>


New submission from Yongzhi Pan:

In https://docs.python.org/3/faq/programming.html#what-are-the-rules-for-local-and-global-variables-in-python, two sentences of essentially the same meaning exist. I try to remove this redundancy.

----------
assignee: docs at python
components: Documentation
files: faq_fix.diff
keywords: patch
messages: 237248
nosy: docs at python, fossilet
priority: normal
severity: normal
status: open
title: Redundant sentence in FAQ
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38339/faq_fix.diff

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

From report at bugs.python.org  Thu Mar  5 10:17:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:17:41 +0000
Subject: [docs] [issue19931] namedtuple docstrings are verbose for no added
	benefit
In-Reply-To: <1386521214.76.0.425352875537.issue19931@psf.upfronthosting.co.za>
Message-ID: <1425547061.06.0.146047567046.issue19931@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't think we should strip-out all the docstrings because you're unhappy with automatically (mindlessly) generated documentation.  What you really need is more control over the documentation tool (the ability to save how much detail you want, particularly with subclasses of builtins which have a ton of methods with simplistic docstrings and with abstract base classes).  

The docstring for __repr__ isn't especially useful but it is a key feature of a namedtuple.  

The docstring for __getnewargs__ is informative especially if you're subclassing a named tuple and need to know what it is used for.   

The docstring for the individual property attributes doesn't look helpful when you list them all but does add information for one-at-a-time help, such as help(Key.blockscope), or for tooltips.   FWIW, there is also a proposal to make it easier to custom the default docstrings for the properties (to turn it into more of a data dictionary).

----------
assignee: docs at python -> rhettinger
resolution:  -> rejected
status: open -> closed
versions:  -Python 2.7, Python 3.4

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

From report at bugs.python.org  Thu Mar  5 10:24:12 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 09:24:12 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425547452.61.0.85403806124.issue23589@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
stage:  -> commit review
versions: +Python 2.7 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Mar  5 10:31:29 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 09:31:29 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425547889.12.0.949535744559.issue23579@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low

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

From report at bugs.python.org  Thu Mar  5 11:18:13 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Mar 2015 10:18:13 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425550693.65.0.322782894319.issue23589@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

How about:

In Python, variables that are only referenced inside a function are implicitly
global.  If a variable is assigned a value anywhere within the function's
body, it's assumed to be a local unless explicitly declared as global.

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

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

From report at bugs.python.org  Thu Mar  5 11:40:00 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Thu, 05 Mar 2015 10:40:00 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425552000.11.0.759119439332.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

Updated diff as Raymond's wording.

----------
Added file: http://bugs.python.org/file38340/faq_fix_1.diff

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

From report at bugs.python.org  Thu Mar  5 12:48:53 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 05 Mar 2015 11:48:53 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425556133.46.0.053040714199.issue23589@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think the first sentence could be improved, even though it's correct.
A superficial reading might give the impression that function variables are implicitly global, or that only the variables inside a function are global, especially if the reader is not familiar with the term "referenced".
Swapping the two sentences and talking first about assignment might be enough to make clear that the other sentence is talking about variables that are only read/accessed by the function but not defined/assigned.
The paragraph can also be rephrased to say that Python can freely access variables from outer scopes, but that "global" is required to assign a new value to a global variable, and that variables defined inside a function are local.

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

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

From andreas.r.maier at gmx.de  Mon Mar  2 18:56:14 2015
From: andreas.r.maier at gmx.de (andreas.r.maier at gmx.de)
Date: Mon, 02 Mar 2015 17:56:14 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20150302175614.1895.28855@psf.upfronthosting.co.za>

Responded to Martin's comments.


https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py
File Lib/test/test_compare.py (right):

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode137
Lib/test/test_compare.py:137: class ComparisonTest2(unittest.TestCase):
The new test class I added is really supposed to test everything. The
existing test class also compares results to some extent, but does not
cover everything. I still did not want to remove it, just in case.
I'll change it as follows:
ComparisonTest1 -> ComparisonSimpleTest
ComparisonTest2 -> ComparisonFullTest
to express the expectation for the second test class.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode145
Lib/test/test_compare.py:145: class BaseCompare(object):
Will rename to CompBase, to be consistent with the other renamed classes
(see comment below).

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode162
Lib/test/test_compare.py:162: 
Will rename these classes e.g. from Class_eq to CompEq, so their names
are PEP-8 compliant.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode328
Lib/test/test_compare.py:328: def assert_insts(self, i1, i2, equal,
comp, i1_meth=(), i2_meth=()):
Will change name to assert_comparisons, for now. I will split up the two
_subtest methods into six, for better identification based on subTest()
(I really like that), but if I look at the number of calls to
assert_comparisons(), I don't think I'd like to duplicate them.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode340
Lib/test/test_compare.py:340: None means: Equality comparison not
supported
Agreed. I will remove None from the description and will add an
assertion that it is not passed as None.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode347
Lib/test/test_compare.py:347: None means: Order comparison not supported
I'll change the description of None to mean "Undefined result", plus
I'll add a clarifying note: "Note that the expected results shown above
just indicate which order comparison expression evaluates to True; they
do not make any statement about whether the ordering is a total
ordering."
Let me know if you think that does not cover it.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode375
Lib/test/test_compare.py:375: self.assertEqual(i1 == i2, id(i1) ==
id(i2))
I thought we would have cases where id(i1)-id(i2) needs to be passed for
order comparisons, so I wanted it to be consistent with that. However,
there are no such cases (the one that existed was in error and was
removed), so I think I agree and will change it as you proposed.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode480
Lib/test/test_compare.py:480: self.assert_insts(i1, i2, False,
id(i1)-id(i2))
Seems like that's a remainder from earlier versions of the code where I
still experimented. Because object types don't have a default order
comparison, the assert_insts() method ignores the value anyway and
asserts that TypeError is raised. I'll change the value that is passed,
to None in both of the cases shown here.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode511
Lib/test/test_compare.py:511: self.assert_insts(insts_a[0], insts_b[0],
True, 0,
The create_sorted_insts() method ensures that the returned objects are
in increasing order of their identities. The only interesting case is
where the value is descending between two objects whose identity is
ascending. That allows asserting that the order comparison is based on
values, not on identities.

Now, the flaw in the current code is that it compares always one object
of the first list with one object of the second list, so the identity
order is arbitrary between them. I will fix that by having an additional
loop through the classes with only one list. Also, the existing loop
across the classes can be simplified somewhat.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode550
Lib/test/test_compare.py:550: class Class_str(str):
Will rename to StrSubclass.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode554
Lib/test/test_compare.py:554: def some_func(self):
True. Will be removed.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode569
Lib/test/test_compare.py:569: self.assert_insts(c1, c1, True,   0,
Class_str.meth, Class_str.meth)
On the empty tuple meths: I wanted to have one place that has the
knowledge that there are no meths, instead of repeating that in every
invocation of assert_insts().

But I'm ok either way. Let me know which way you would recommend to go.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode591
Lib/test/test_compare.py:591: i1 = int(10001)
Probably. But then would we also change other objects? As it is now, it
is at least consistent (across the test functions).

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode881
Lib/test/test_compare.py:881: def
test__internal_is_value_comparable(self):
The idea was that "test_" is the common prefix for test functions, and
the extra underscore indicates an internal function. I do realize that
it is redundant with saying "internal" in the function name. However,
while trying to remove the second underscore, I realized something else:
The unittest package executes the test functions in alphabetical order
of their names. I think it makes sense to execute tests of internal
functions first, before they are used in the other real tests. Having
two underscores ensures that it is executed first. I will remove the
"internal_".

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

From amgrima58 at gmail.com  Thu Mar  5 16:39:03 2015
From: amgrima58 at gmail.com (Angela Grima)
Date: Thu, 5 Mar 2015 10:39:03 -0500
Subject: [docs] Question
In-Reply-To: <CAGiusif-wL6D_FwOB-UrAhfxERTpFkTj4L8x+S5Ts8e=3JpO+Q@mail.gmail.com>
References: <CAGiusif-wL6D_FwOB-UrAhfxERTpFkTj4L8x+S5Ts8e=3JpO+Q@mail.gmail.com>
Message-ID: <CAGiusic8QyAeCB1ig8So=zbazX=HRqsPm-xir9Az4OF6xcD63Q@mail.gmail.com>

I have not received a response from you.  However, I think I know what the
problem is.  My laptop is XP (important in terms of programming in
mathematics and science for obvious reasons).  However, my operating system
is Professional only - no XP.  It doesn't seem to make a difference in most
situations, but it is unable to read the decimal point in as a string
variable in Python.  It reads it as a literal and therefore it is unable to
change to a floating number.  In other words, Python does not have the
ability to change the "." into an equivalent decimal point in the system
that I have.  But please note, that the underlying assumption here is that
Python is able to do so in an XP system.

Angela Grima

On Tue, Feb 24, 2015 at 4:24 PM, Angela Grima <amgrima58 at gmail.com> wrote:

> Hello,
> \
> I am a beginner at Python and I am trying to write a program that allows
> me to read in a list of decimal numerals, assign a grade to each one, and
> write each one with the corresponding grade. Unfortunately, it Python
> thinks that each score is a string but does not allow me to convert it to a
> floating point.  I have tried different statements using Python but I am
> still stuck.  Attached are a copy of the program, data being used.  Below
> is the printed output.
>
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
> C:\Users\Ange\Documents\Computer Science\Python Class>docbright.py
> Score Grade
> Traceback (most recent call last):
>   File "C:\Users\Ange\Documents\Computer Science\Python
> Class\docbright.py", lin
> e 18, in <module>
>     x = float(x) + .005
> ValueError: could not convert string to float:ss>
>
> Your help is appreciated.
>
> Angela Grima
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150305/f29f4f99/attachment-0001.html>

From gooogleapps33 at gmail.com  Thu Mar  5 20:01:42 2015
From: gooogleapps33 at gmail.com (Vincent .)
Date: Thu, 5 Mar 2015 20:01:42 +0100
Subject: [docs] =?utf-8?q?Pb_de_d=27essai_du_code_=C3=A0_la_section_7=2E2?=
	=?utf-8?q?=2E1_Methods_Of_File_Objects?=
Message-ID: <CAK9O0gbh=+3OvGQNmsky1AmxHLKdJhAq+g20=3_gOurQZCZ7rg@mail.gmail.com>

Bonjour,

Quand j'ex?cute le code suivant (tir? du manuel section 7.2.1):
f = open('workfile', 'r')
f.read()

Celui-ci fonctionne sous l'interpr?teur, mais pas quand le m?me code est
mis dans un fichier.

Merci de proposer une solution (celle-ci sera employ? par tout lecteur de
la documentation) ? ce probl?me.

Vincent.

--------------------------------------------------------------------------------------------------
Hello,

When I run this code
f = open('workfile', 'r')
f.read()

under python interpreter, it operate.
in a file, it doesn't work

Please, help to fix this bug which be useful for all readers of your docs.

Vincent.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150305/28e4f1b2/attachment-0001.html>

From report at bugs.python.org  Fri Mar  6 11:27:10 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 06 Mar 2015 10:27:10 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425637630.93.0.673383326265.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

What about changing the first sentence to:

In Python, variables that are only referenced but not assigned inside a function are implicitly global.?

----------

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

From report at bugs.python.org  Fri Mar  6 11:46:43 2015
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 06 Mar 2015 10:46:43 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425638803.29.0.978115933227.issue23589@psf.upfronthosting.co.za>


Yongzhi Pan added the comment:

Or:

In Python, variables inside a function that are only referenced but not assigned are implicitly global.?

----------

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

From report at bugs.python.org  Fri Mar  6 17:00:33 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 06 Mar 2015 16:00:33 +0000
Subject: [docs] [issue23589] Redundant sentence in FAQ
In-Reply-To: <1425544358.43.0.799956102379.issue23589@psf.upfronthosting.co.za>
Message-ID: <1425657633.83.0.173442231833.issue23589@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Not to throw a wrench into this, but would it perhaps not be worthwhile to refactor this section in order to include nonlocals as well (obviously not for 2.7)? It seems a little odd to me to have this amount of detail without mentioning nonlocal.

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Sat Mar  7 07:59:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Mar 2015 06:59:55 +0000
Subject: [docs] [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425711595.04.0.496117137516.issue23432@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thank you for your suggestion, Martin. Here is an updated patch.

----------
Added file: http://bugs.python.org/file38365/systemexit_v2.diff

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

From report at bugs.python.org  Sat Mar  7 08:06:15 2015
From: report at bugs.python.org (Sayan Chowdhury)
Date: Sat, 07 Mar 2015 07:06:15 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425711975.75.0.74736372217.issue23579@psf.upfronthosting.co.za>


Sayan Chowdhury added the comment:

Attached a patch by changing the amazon links to official websites.

----------
keywords: +patch
nosy: +sayanchowdhury
Added file: http://bugs.python.org/file38366/issue23579.patch

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

From report at bugs.python.org  Sat Mar  7 08:10:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 07:10:55 +0000
Subject: [docs] [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425712255.01.0.837370801033.issue23432@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch looks fine

----------

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

From report at bugs.python.org  Sat Mar  7 08:12:36 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 Mar 2015 07:12:36 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425712356.1.0.322954845714.issue23579@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

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

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

From ethan at stoneleaf.us  Sat Mar  7 08:37:05 2015
From: ethan at stoneleaf.us (ethan at stoneleaf.us)
Date: Sat, 07 Mar 2015 07:37:05 -0000
Subject: [docs] Amazon.com links (issue 23579)
Message-ID: <20150307073705.20767.85932@psf.upfronthosting.co.za>


http://bugs.python.org/review/23579/diff/14109/Doc/library/othergui.rst
File Doc/library/othergui.rst (right):

http://bugs.python.org/review/23579/diff/14109/Doc/library/othergui.rst#newcode53
Doc/library/othergui.rst:53: <http://www.manning.com/rappin/>`_, by Noel
Rappin and
I think the goal is not to replace one online book store with another. 
Perhaps something along the lines of:

The `wxPython website <hhtp://http://www.wxpython.org/`_ has links to
availabe books.

http://bugs.python.org/review/23579/diff/14109/Doc/library/tkinter.rst
File Doc/library/tkinter.rst (right):

http://bugs.python.org/review/23579/diff/14109/Doc/library/tkinter.rst#newcode40
Doc/library/tkinter.rst:40: `Python and Tkinter Programming
<http://www.manning.com/grayson/>`_
Either list both Manning and Amazon, or neither.  Or an actual home page
for the book not from either online bookstore.

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

From georg at python.org  Sat Mar  7 08:39:05 2015
From: georg at python.org (georg at python.org)
Date: Sat, 07 Mar 2015 07:39:05 -0000
Subject: [docs] Amazon.com links (issue 23579)
Message-ID: <20150307073905.1895.71709@psf.upfronthosting.co.za>


http://bugs.python.org/review/23579/diff/14109/Doc/library/othergui.rst
File Doc/library/othergui.rst (right):

http://bugs.python.org/review/23579/diff/14109/Doc/library/othergui.rst#newcode53
Doc/library/othergui.rst:53: <http://www.manning.com/rappin/>`_, by Noel
Rappin and
On 2015/03/07 08:37:05, stoneleaf wrote:
> I think the goal is not to replace one online book store with another.

That's not "a bookstore", it's the publisher's page.

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

From report at bugs.python.org  Sat Mar  7 10:44:29 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 09:44:29 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <1425721469.91.0.284097996176.issue23579@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sat Mar  7 12:03:28 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 11:03:28 +0000
Subject: [docs] [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1425726208.81.0.52396667628.issue22154@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

The context manager support was added on issue #5511, so the documentation should go to 2.7, 3.4 and default. Also the version added notes should be added.

----------
nosy: +Tuomas Suutari

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

From report at bugs.python.org  Sat Mar  7 12:10:51 2015
From: report at bugs.python.org (Tuomas Suutari)
Date: Sat, 07 Mar 2015 11:10:51 +0000
Subject: [docs] [issue23460] Decimals do not obey ':g' exponential
	notation	formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1425726651.28.0.0462891855827.issue23460@psf.upfronthosting.co.za>


Tuomas Suutari added the comment:

Here's a patch that fixes the description for 'g' to explain what happens for `Decimal` and also documents the Decimal.__format__ in the documentation of the decimal module.

----------
keywords: +patch
nosy: +Tuomas Suutari
Added file: http://bugs.python.org/file38370/issue23460.patch

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

From report at bugs.python.org  Sat Mar  7 12:57:16 2015
From: report at bugs.python.org (Peter Otten)
Date: Sat, 07 Mar 2015 11:57:16 +0000
Subject: [docs] [issue23495] The writer.writerows method should be
	documented as	accepting any iterable (not only a list)
In-Reply-To: <1424465153.78.0.58816335685.issue23495@psf.upfronthosting.co.za>
Message-ID: <1425729436.68.0.559004257076.issue23495@psf.upfronthosting.co.za>


Changes by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

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

From report at bugs.python.org  Sat Mar  7 15:35:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Mar 2015 14:35:20 +0000
Subject: [docs] [issue23579] Amazon.com links
In-Reply-To: <1425419031.81.0.618104402828.issue23579@psf.upfronthosting.co.za>
Message-ID: <20150307143503.1369.17647@psf.io>


Roundup Robot added the comment:

New changeset 5903ab233a1d by Benjamin Peterson in branch '3.4':
replace Amazon links in the documentation (closes #23579)
https://hg.python.org/cpython/rev/5903ab233a1d

New changeset 4ad1ea911fd0 by Benjamin Peterson in branch '2.7':
replace Amazon links in the documentation (closes #23579)
https://hg.python.org/cpython/rev/4ad1ea911fd0

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

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

From report at bugs.python.org  Sat Mar  7 17:41:34 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 16:41:34 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425746494.16.0.47780449049.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here is a patch that fixes the problem.
Even though calling .close() is the correct solution, I preferred to restore the previous behavior and call handle_data as soon as possible.
There is a corner case in which a charref might be cut in half while feeding chunks to the parser -- in that case the parser will wait and it might still be necessary to call .close() if an incomplete charref is at the end of the string.
Adding context manager support to HTMLParser might also help solving the problem, but that's a separate issue.
(Also thanks to Serhiy for the feedback he provided me on IRC.)

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> commit review
versions: +Python 2.7, Python 3.5
Added file: http://bugs.python.org/file38376/issue23144.diff

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

From report at bugs.python.org  Sat Mar  7 18:50:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 17:50:10 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425750610.71.0.874069304846.issue23144@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file38376/issue23144.diff

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

From report at bugs.python.org  Sat Mar  7 18:50:40 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 07 Mar 2015 17:50:40 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425750640.24.0.140708676273.issue23144@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file38380/issue23144.diff

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

From report at bugs.python.org  Sun Mar  8 00:14:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Mar 2015 23:14:09 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425770048.95.0.957950912009.issue23144@psf.upfronthosting.co.za>


Martin Panter added the comment:

I still think it would be worthwhile adding close() calls to the examples in the documentation (Doc/library/html.parser.rst).

BTW I haven?t tested this, and maybe it is not a concern, but even with this patch it looks like the parser will buffer unlimited data and output nothing until close() if each string it is fed ends with an ampersand (and otherwise contains only plain text, no tags etc).

----------

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

From report at bugs.python.org  Sun Mar  8 01:08:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Mar 2015 00:08:10 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425773290.85.0.88764030757.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I still think it would be worthwhile adding close() calls to
> the examples in the documentation (Doc/library/html.parser.rst).

If I add context manager support to HTMLParser I can update the examples to use it, but otherwise I don't think it's worth changing them now.

> BTW I haven?t tested this, and maybe it is not a concern, but even with
> this patch it looks like the parser will buffer unlimited data and
> output nothing until close() if each string it is fed ends with an 
> ampersand (and otherwise contains only plain text, no tags etc).

This is true, but I don't think it's a realistic case.
For this to be a problem you would need:
1) Someone feeding the parser with arbitrary chunks.  Text files are usually fed to the parser whole, or line by line -- arbitrary chunks are uncommon.
2) A file that contains lot of entities.  In most documents charrefs are not very common, and so the chances that a chunk will split one in the middle is low.  Chances that several consecutive charrefs are split in the middle is even lower.
3) A file that is very big.  Even if all the file is buffered until a call to close(), it shouldn't be a concern, since most files have relatively small size.  It is true that this has a quadratic complexity, but I would expect the parsing to complete in a reasonable time for average sizes.

----------

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

From report at bugs.python.org  Sun Mar  8 02:49:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 01:49:34 +0000
Subject: [docs] [issue23556] Scope for raise without argument is different
	in Python	2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1425779374.14.0.88939741617.issue23556@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar  8 03:33:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 02:33:55 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425782035.42.0.87878579694.issue23144@psf.upfronthosting.co.za>


Martin Panter added the comment:

A context manager here would seem a bit strange. Is there any precedent for using context managers with feed parsers? The two others that come to mind are ElementTree.XMLParser and email.parser.FeedParser. These two build an object while parsing, and close() returns that object, so a context manager would be unhelpful.

If an exception is raised inside the context manager, should close() be called (like for file objects), or not?

----------

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

From report at bugs.python.org  Sun Mar  8 12:32:12 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 08 Mar 2015 11:32:12 +0000
Subject: [docs] [issue23144] html.parser.HTMLParser: setting
	'convert_charrefs =	True' leads to dropped text
In-Reply-To: <1420138028.63.0.996553076818.issue23144@psf.upfronthosting.co.za>
Message-ID: <1425814332.48.0.816905940079.issue23144@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> A context manager here would seem a bit strange.

I still haven't thought this through, but I can't see any problem with it right now.  This would be similar to:

  from contextlib import closing
  with closing(MyHTMLParser()) as parser:
      parser.feed(html)

and this already seems to work fine, including with OP's case.

> If an exception is raised inside the context manager,
> should close() be called (like for file objects), or not?

The parser is guaranteed to never raise parsing-related errors during parsing, so this shouldn't be an issue.  I will open a new issue after fixing this so we can keep discussing there.

----------

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

From report at bugs.python.org  Sun Mar  8 18:19:26 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 08 Mar 2015 17:19:26 +0000
Subject: [docs] [issue23081] Document PySequence_List(o) as equivalent to
	list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1425835166.26.0.914150422642.issue23081@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM, can we have a formal review please.

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

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

From report at bugs.python.org  Sun Mar  8 18:56:38 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 17:56:38 +0000
Subject: [docs] [issue23081] Document PySequence_List(o) as equivalent to
	list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1425837398.67.0.803168094988.issue23081@psf.upfronthosting.co.za>


Georg Brandl added the comment:

+1

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

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

From report at bugs.python.org  Sun Mar  8 20:36:00 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:36:00 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
Message-ID: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Since I get hit by this at least once a week, I thought I'd finally report a bug. The Doc/build/html/searchindex.js file is extremely annoying when grepping through the source tree (and especially when grepping in the docs), because it's very likely to match your search *and* it seems made of a huge single line of text, meaning the grep output now fills your terminal with junk.

----------
assignee: docs at python
components: Documentation
messages: 237557
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: searchindex.js is annoying
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar  8 20:50:00 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 19:50:00 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844200.81.0.110401588349.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

And what do you suggest to do about it?

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

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

From report at bugs.python.org  Sun Mar  8 20:50:40 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:50:40 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844240.8.0.932652780193.issue23613@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That's a good question :) Making it a normal multiline file would be good enough.

----------

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

From report at bugs.python.org  Sun Mar  8 20:54:30 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 19:54:30 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844470.49.0.0423243815286.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, that's not useful in a generated file.  I propose you exclude the doc build tree from your search, or use a grepping tool like ag that ignores files ignored by the vcs.

----------

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

From report at bugs.python.org  Sun Mar  8 20:57:29 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Mar 2015 19:57:29 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425844649.77.0.695516065136.issue23613@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Well, that's not useful in a generated file.

Well, here's a case where it's useful... Asking me to change tools is quite obvious and quite pointless at the same time. How about we respond to all Windows-specific issues with "switch to Linux"?

----------

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

From report at bugs.python.org  Sun Mar  8 21:03:52 2015
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 08 Mar 2015 20:03:52 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425845031.95.0.423489475034.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> How about we respond to all Windows-specific issues with "switch to Linux"?

How about we don't respond to strawman arguments?

----------

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

From report at bugs.python.org  Sun Mar  8 21:06:32 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 08 Mar 2015 20:06:32 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425844649.77.0.695516065136.issue23613@psf.upfronthosting.co.za>
Message-ID: <54FCABC4.9020402@egenix.com>


Marc-Andre Lemburg added the comment:

On 08.03.2015 20:57, Antoine Pitrou wrote:
> 
> Antoine Pitrou added the comment:
> 
>> Well, that's not useful in a generated file.
> 
> Well, here's a case where it's useful... Asking me to change tools is quite obvious and quite pointless at the same time. How about we respond to all Windows-specific issues with "switch to Linux"?

Georg suggested excluding the file from your search. That's a very
reasonable answer.

You don't have to change your tools for this,
just configure them to not look in .js files or perhaps not look
in this particular file if it returns false positives for you.

I'd suggest to close this as "wont fix".

----------
nosy: +lemburg

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

From report at bugs.python.org  Sun Mar  8 23:27:32 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 Mar 2015 22:27:32 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425853652.94.0.207731726549.issue23613@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lib/pydoc_data/topics.py was extremely annoying to me for the same reason. I even didn't know about Doc/build/html/searchindex.js because it has different extension. Finally I had written few scripts like:

$ cat ~/bin/findpy
#!/bin/sh
find * -name '*.py' ! -path '*Lib/pydoc_data/topics.py' ! -path '*Lib/plat-*' -exec egrep -n --color "$@" '{}' +

and similar for *.[ch] and *.rst, and forgot about this problem.

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

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

From report at bugs.python.org  Sun Mar  8 23:54:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 Mar 2015 22:54:12 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425855252.11.0.561494486813.issue23613@psf.upfronthosting.co.za>


Martin Panter added the comment:

My own one-liner kicking around in my Bash history that uses GNU Grep options to avoid specific files and directories:

grep -r . --exclude-dir={.git,.hg} --exclude={refcounts.dat,"*.js"} -nIwe PIPE_MAX_SIZE

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar  9 03:28:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 Mar 2015 02:28:52 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1425868131.84.0.712709341864.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch that also removes the masking from the gzip, zipfile, tarfile, and test_zlib modules. I removed the comment about signedness in tarfile; let me know if you saw any others.

----------
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file38398/crc-sign.v2.patch

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

From report at bugs.python.org  Mon Mar  9 07:56:35 2015
From: report at bugs.python.org (Kentrell Johnson)
Date: Mon, 09 Mar 2015 06:56:35 +0000
Subject: [docs] [issue23617] Incorrect plural "includes" on Python Standard
	Library	front page
Message-ID: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>


New submission from Kentrell Johnson:

"The Python installers for the Windows platform usually includes"

should be

"The Python installers for the Windows platform usually include"

----------
assignee: docs at python
components: Documentation
messages: 237598
nosy: docs at python, kentrell.johnson
priority: normal
severity: normal
status: open
title: Incorrect plural "includes" on Python Standard Library front page
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Mar  9 09:56:11 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Mar 2015 08:56:11 +0000
Subject: [docs] [issue23617] Incorrect plural "includes" on Python Standard
	Library	front page
In-Reply-To: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>
Message-ID: <20150309085608.1369.59863@psf.io>


Roundup Robot added the comment:

New changeset 17253605eca4 by Ned Deily in branch '2.7':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/17253605eca4

New changeset e623283e4dd6 by Ned Deily in branch '3.4':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/e623283e4dd6

New changeset 82df13f0ea9b by Ned Deily in branch 'default':
Issue #23617: Correct plurals typo noted by Kentrell Johnson.
https://hg.python.org/cpython/rev/82df13f0ea9b

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

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

From report at bugs.python.org  Mon Mar  9 09:57:23 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 08:57:23 +0000
Subject: [docs] [issue23617] Incorrect plural "includes" on Python Standard
	Library	front page
In-Reply-To: <1425884195.77.0.695422727516.issue23617@psf.upfronthosting.co.za>
Message-ID: <1425891443.04.0.242801660326.issue23617@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> 
versions: +Python 3.5

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

From report at bugs.python.org  Mon Mar  9 12:09:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2015 11:09:32 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425899372.9.0.98559291605.issue23613@psf.upfronthosting.co.za>


R. David Murray added the comment:

Martin's solution is similar to the one I use except that I made an alias for it and I also exclude topics.py.  Which is a tracked file.  It seems that what one wants to ignore is a bit of a personal decision, and so it is probably best left up to the individual to craft a solution (even though I also find it annoying :)

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

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

From report at bugs.python.org  Mon Mar  9 15:14:27 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 14:14:27 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
Message-ID: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>


New submission from Paul Moore:

With Python 3.5 on Windows defaulting (for all users installs) to the read-only "Program Files" directory, and with "Add Python to PATH" having problems adding the per-user "user scripts" directory to PATH, the Python 3.5 documentation needs to explain the recommended practice for running Python 3.5 from the command line on Windows. Issues that should be covered include:

- System installs with need to be run from an elevated prompt, are user installs now the recommended approach? (It's worth noting in that case that user installs re *not* recommended for older versions, as the user Scripts directory wasn't versioned until Python 3.5)
- How to add the correct directories to PATH (including the user scripts directory) - for both CMD and powershell users and in an existing shell as well as a new one (i.e, no "Python command prompt" shortcuts!)
- How to add the correct directories persistently, so they are available to all programs on startup.
- While the "py" launcher solves the problem of running Python, and some modules via -m (such as pip), many packages install console scripts which do not have an equivalent -m invocation, so "use the launcher" is not a complete solution.

The documentation should clarify where (or if) 3rd party documentation needs to comment on Windows path difficulties. For example, the pip documentation has for a long time said that the way to run pip is via the "pip" command, and until Python included the "Add to PATH" option in the installer, we regularly had to deal with user queries because the "pip" command didn't work out of the box - it would be unfortunate if Python 3.5 left 3rd parties back in that situation again.

----------
assignee: docs at python
components: Documentation, Windows
messages: 237650
nosy: docs at python, pmoore, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Python 3.5 docs need to clarify how to set PATH, etc
versions: Python 3.5

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

From report at bugs.python.org  Mon Mar  9 17:41:34 2015
From: report at bugs.python.org (David Linke)
Date: Mon, 09 Mar 2015 16:41:34 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425919294.57.0.960420837351.issue23623@psf.upfronthosting.co.za>


Changes by David Linke <dr.david.linke at gmail.com>:


----------
nosy: +dalito

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

From report at bugs.python.org  Mon Mar  9 17:49:53 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 Mar 2015 16:49:53 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425919793.04.0.500054445524.issue23623@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Mon Mar  9 18:13:48 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 17:13:48 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425921228.8.0.51564466591.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

FYI, the docs in the Python 3.5.0a2 CHM are newer than what's on docs.p.o, specifically the "Using Python on Windows" section. (Apparently I need to do something other than commit changes to get the website updated?)

https://hg.python.org/cpython/file/tip/Doc/using/windows.rst

The section on setting environment variables has been updated since 3.4, but it could be extended further.

----------

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

From report at bugs.python.org  Mon Mar  9 18:24:39 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 09 Mar 2015 17:24:39 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425921879.12.0.669562166538.issue23623@psf.upfronthosting.co.za>


Paul Moore added the comment:

At a minimum, the example should show adding setting the 2 script directories to PATH, and not just sys.prefix.

----------

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

From report at bugs.python.org  Mon Mar  9 19:07:37 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 09 Mar 2015 18:07:37 +0000
Subject: [docs] [issue11726] linecache becomes specific to Python scripts in
	Python 3
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1425924457.73.0.45422142325.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Someone on reddit ran into this, expecting that linecache can be used for an arbitrary text file:
http://www.reddit.com/r/Python/comments/2yetxc/utf8_encoding_problems/

I was quite surprised that the docs say "allows one to get any line from any file." I've always understood that linecache is specifically for Python files, and the use of tokenize.open() means that it will only work for files that are UTF-8 or have the #coding: magic comment in the first two lines.

I think the docs should at least mention this; I'm happy to work on a patch for it at some point if people agree.

----------
nosy: +takluyver

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

From report at bugs.python.org  Mon Mar  9 19:20:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Mar 2015 18:20:09 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1425925209.3.0.605853206467.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, clarifying the docs seems sensible.  "Any file" is slightly different from the reality.

----------
nosy: +r.david.murray
resolution: rejected -> 
stage:  -> needs patch
status: closed -> open
title: linecache becomes specific to Python scripts in Python 3 -> clarify that linecache only works on files that can be decoded successfully
type:  -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Mar  9 20:30:23 2015
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 09 Mar 2015 19:30:23 +0000
Subject: [docs] [issue23613] searchindex.js is annoying
In-Reply-To: <1425843360.7.0.572692234171.issue23613@psf.upfronthosting.co.za>
Message-ID: <1425929423.93.0.741899831975.issue23613@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Most important reason to close this: this is not something to change in Python, but would have to be changed in Sphinx.

----------
resolution:  -> third party
status: open -> closed

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

From report at bugs.python.org  Mon Mar  9 21:45:46 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 20:45:46 +0000
Subject: [docs] [issue21018] [patch] added missing documentation about
	escaping	characters for configparser
In-Reply-To: <1395464420.76.0.68706986346.issue21018@psf.upfronthosting.co.za>
Message-ID: <1425933945.92.0.425554297804.issue21018@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

LGTM so can we have a formal patch review please, thanks.

----------
nosy: +BreamoreBoy
versions: +Python 3.5

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

From report at bugs.python.org  Mon Mar  9 22:20:14 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 21:20:14 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936014.16.0.284062641028.issue23623@psf.upfronthosting.co.za>


Ned Deily added the comment:

Steve, how does https://docs.python.org/dev/using/windows.html look now?  (There may have been an update lag.)

----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Mar  9 22:25:36 2015
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 Mar 2015 21:25:36 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936336.72.0.781580750555.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks good, thanks Ned.

----------

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

From report at bugs.python.org  Mon Mar  9 22:27:12 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 09 Mar 2015 21:27:12 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1425936432.79.0.730239759079.issue23623@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -ned.deily

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

From report at bugs.python.org  Mon Mar  9 22:37:59 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 09 Mar 2015 21:37:59 +0000
Subject: [docs] [issue20751] Misleading examples in the descriptor
	protocol	documentation
In-Reply-To: <1393193636.36.0.125202538555.issue20751@psf.upfronthosting.co.za>
Message-ID: <1425937079.46.0.587483046646.issue20751@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Who is best placed to comment on the suggested docs changes given in msg212035?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From david.haemmerle at univie.ac.at  Fri Mar  6 14:55:29 2015
From: david.haemmerle at univie.ac.at (=?UTF-8?B?RGF2aWQgSMOkbW1lcmxl?=)
Date: Fri, 06 Mar 2015 14:55:29 +0100
Subject: [docs] suggestion for sections about bitwise operators
Message-ID: <54F9B1D1.7030008@univie.ac.at>

Dear sir or madam,

I have a short suggestion how to improve the section 5.8 (Python 2.x) 
and 6.8 (Python 3.x) respectively. These sections only state that the 
arguments of bitwise operators have to be integers. But these operators 
obviously also work with boolean values (True/False). It would be nice 
if the sections explained how the operators behave when one uses only 
boolean values or when one mixes boolean and integer values.

Yours sincerely,
David H?mmerle

From segovia1040 at gmail.com  Fri Mar  6 17:39:44 2015
From: segovia1040 at gmail.com (Juan Nadie)
Date: Fri, 6 Mar 2015 17:39:44 +0100
Subject: [docs] =?utf-8?q?Posible_Error_en_documentaci=C3=B3n=2E?=
Message-ID: <CALTX6nxZ9_bJJmWJA+BvXB9RDVe4=dAsMFqztEzTkjirTP-eGQ@mail.gmail.com>

Hola, buenas tardes. Solo quiero informarles que en el enlace:
https://docs.python.org/3/library/curses.html    que corresponde a la
entrada
16.10. curses <https://docs.python.org/3/library/curses.html#module-curses>
? Terminal handling for character-cell displays el enlace  <next> salta a
la entrada
 16.12. curses.ascii
<https://docs.python.org/3/library/curses.ascii.html#module-curses.ascii> ?
Utilities for ASCII characters

cuando yo creo que el enlace deber?a saltar a la entrada
 16.11. curses.textpad
<https://docs.python.org/3/library/curses.ascii.html#module-curses.ascii>
? Text input widget for curses programs

No es nada importante, pero es una forma de colaborar con Vds. para que la
documentaci?n este lo m?s correcta posible.

Un cordial saludo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150306/2ad5c4e1/attachment-0001.html>

From vadmium+py at gmail.com  Sun Mar  8 00:11:54 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 07 Mar 2015 23:11:54 -0000
Subject: [docs] html.parser.HTMLParser: setting 'convert_charrefs = True'
 leads to dropped text (issue 23144)
Message-ID: <20150307231154.20006.15@psf.upfronthosting.co.za>


https://bugs.python.org/review/23144/diff/14120/Lib/html/parser.py
File Lib/html/parser.py (right):

https://bugs.python.org/review/23144/diff/14120/Lib/html/parser.py#newcode146
Lib/html/parser.py:146: # this is the case before proceding by looking
for an
proceeding [double E]

https://bugs.python.org/review/23144/diff/14120/Lib/html/parser.py#newcode148
Lib/html/parser.py:148: amppos = rawdata.rfind('&', max(i, n-34))
Where does the -34 come from? I guess you are trying to optimize how far
rfind() searches (?looking for an ampersand _near_ the end?), based on
some maximum character reference length, but this at least needs a
comment explaining the magic number.

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

From vadmium+py at gmail.com  Mon Mar  9 02:41:20 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 09 Mar 2015 01:41:20 -0000
Subject: [docs] Python 3 crc32 documentation clarifications (issue 22341)
Message-ID: <20150309014120.27455.44044@psf.upfronthosting.co.za>

Reviewers: storchaka,


https://bugs.python.org/review/22341/diff/13462/Doc/library/binascii.rst
File Doc/library/binascii.rst (right):

https://bugs.python.org/review/22341/diff/13462/Doc/library/binascii.rst#newcode125
Doc/library/binascii.rst:125: the given *crc*.  The default initial
value is zero.  The algorithm
On 2015/02/28 13:02:25, storchaka wrote:
> May be just write the signature as crc32(data, crc=0) and drop the
sentence
> about the default value?

I hesitate to do this because all these functions do not accept keyword
arguments, and writing crc32(.., crc=0) implies (at least to me) that it
may be a keyword argument. The square brackets imply positional-only
parameters in my mind. Is there any style guide or precedence on how to
do this better (e.g. devguide)? I couldn?t find anything obvious.



Please review this at https://bugs.python.org/review/22341/

Affected files:
  Doc/library/binascii.rst
  Doc/library/zlib.rst


# HG changeset patch
# Parent 3de678cd184d943f53e9bc0e74feefaa07cc7f55
Issue #22341: Drop Python 2 workaround and document CRC initial value


diff -r 3de678cd184d -r 8a48ec8372c2 Doc/library/binascii.rst
--- a/Doc/library/binascii.rst	Thu Dec 18 23:47:55 2014 +0100
+++ b/Doc/library/binascii.rst	Fri Dec 19 05:02:33 2014 +0000
@@ -121,24 +121,18 @@
 
 .. function:: crc32(data[, crc])
 
-   Compute CRC-32, the 32-bit checksum of data, starting with an initial crc.  This
+   Compute CRC-32, the 32-bit checksum of *data*, starting with
+   the given *crc*.  The default initial value is zero.  The algorithm
    is consistent with the ZIP file checksum.  Since the algorithm is designed for
    use as a checksum algorithm, it is not suitable for use as a general hash
    algorithm.  Use as follows::
 
       print(binascii.crc32(b"hello world"))
       # Or, in two pieces:
-      crc = binascii.crc32(b"hello")
-      crc = binascii.crc32(b" world", crc) & 0xffffffff
+      crc = binascii.crc32(b"hello", 0)
+      crc = binascii.crc32(b" world", crc)
       print('crc32 = {:#010x}'.format(crc))
 
-.. note::
-   To generate the same numeric value across all Python versions and
-   platforms use crc32(data) & 0xffffffff.  If you are only using
-   the checksum in packed binary format this is not necessary as the
-   return value is the correct 32bit binary representation
-   regardless of sign.
-
 
 .. function:: b2a_hex(data)
               hexlify(data)
diff -r 3de678cd184d -r 8a48ec8372c2 Doc/library/zlib.rst
--- a/Doc/library/zlib.rst	Thu Dec 18 23:47:55 2014 +0100
+++ b/Doc/library/zlib.rst	Fri Dec 19 05:02:33 2014 +0000
@@ -30,10 +30,11 @@
 
 .. function:: adler32(data[, value])
 
-   Computes a Adler-32 checksum of *data*.  (An Adler-32 checksum is almost as
-   reliable as a CRC32 but can be computed much more quickly.)  If *value* is
-   present, it is used as the starting value of the checksum; otherwise, a fixed
-   default value is used.  This allows computing a running checksum over the
+   Computes an Adler-32 checksum of *data*.  (An Adler-32 checksum is
+   almost as reliable as a CRC32 but can be computed much more quickly.)
+   If *value* is present, it is used as the starting value of
+   the checksum; otherwise, a default value of 1 is used.
+   This allows computing a running checksum over the
    concatenation of several inputs.  The algorithm is not cryptographically
    strong, and should not be used for authentication or digital signatures.  Since
    the algorithm is designed for use as a checksum algorithm, it is not suitable
@@ -41,13 +42,6 @@
 
    Always returns an unsigned 32-bit integer.
 
-.. note::
-   To generate the same numeric value across all Python versions and
-   platforms use adler32(data) & 0xffffffff.  If you are only using
-   the checksum in packed binary format this is not necessary as the
-   return value is the correct 32bit binary representation
-   regardless of sign.
-
 
 .. function:: compress(data[, level])
 
@@ -98,8 +92,9 @@
       single: checksum; Cyclic Redundancy Check
 
    Computes a CRC (Cyclic Redundancy Check)  checksum of *data*. If *value* is
-   present, it is used as the starting value of the checksum; otherwise, a fixed
-   default value is used.  This allows computing a running checksum over the
+   present, it is used as the starting value of the checksum; otherwise, a
+   default value of zero is used.
+   This allows computing a running checksum over the
    concatenation of several inputs.  The algorithm is not cryptographically
    strong, and should not be used for authentication or digital signatures.  Since
    the algorithm is designed for use as a checksum algorithm, it is not suitable
@@ -107,14 +102,6 @@
 
    Always returns an unsigned 32-bit integer.
 
-   .. note::
-
-      To generate the same numeric value across all Python versions and
-      platforms, use ``crc32(data) & 0xffffffff``.  If you are only using
-      the checksum in packed binary format this is not necessary as the
-      return value is the correct 32-bit binary representation
-      regardless of sign.
-
 
 .. function:: decompress(data[, wbits[, bufsize]])
 



From susanbruce707 at outlook.com  Mon Mar  9 17:22:30 2015
From: susanbruce707 at outlook.com (Ninja Scroll)
Date: Mon, 9 Mar 2015 16:22:30 +0000
Subject: [docs] 4.4. break and continue Statements, and else Clauses on Loops
Message-ID: <BLU437-SMTP403F3A0FEA749BDDAE1C03F51B0@phx.gbl>



I typed in the example given in python docs tutorial, the output is 
clearly wrong and different from than shown in the example.
Hope this is helpful, kind regards Susan707.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150309/7d60911f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fbdcbahc.png
Type: image/png
Size: 75883 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150309/7d60911f/attachment-0001.png>

From amgrima58 at gmail.com  Mon Mar  9 19:37:20 2015
From: amgrima58 at gmail.com (Angela Grima)
Date: Mon, 9 Mar 2015 14:37:20 -0400
Subject: [docs] Question
In-Reply-To: <CAGiusic8QyAeCB1ig8So=zbazX=HRqsPm-xir9Az4OF6xcD63Q@mail.gmail.com>
References: <CAGiusif-wL6D_FwOB-UrAhfxERTpFkTj4L8x+S5Ts8e=3JpO+Q@mail.gmail.com>
 <CAGiusic8QyAeCB1ig8So=zbazX=HRqsPm-xir9Az4OF6xcD63Q@mail.gmail.com>
Message-ID: <CAGiusifiuXuHk-ccwCBBSEOr=rDzyufYx4sbRy2mfJkNRrPdeg@mail.gmail.com>

I have reviewed my earlier program and made some edits.  It includes edits
to the data (adding a nonsensical inequality sign preceded by a space), and
using the find statement in the revised program.

The program reads two decimal numerals, decides whether the number read is
less than or equal to a certain amount, prints the number and a letter
grade.  I made the number print two digits after the decimal.

By including a  couple of tricks, the situation which requires reading a
decimal numeral, even if Python requires X-Professional computer and XP
system, you can still make it do what you want.  See attached.

On Thu, Mar 5, 2015 at 10:39 AM, Angela Grima <amgrima58 at gmail.com> wrote:

> I have not received a response from you.  However, I think I know what the
> problem is.  My laptop is XP (important in terms of programming in
> mathematics and science for obvious reasons).  However, my operating system
> is Professional only - no XP.  It doesn't seem to make a difference in most
> situations, but it is unable to read the decimal point in as a string
> variable in Python.  It reads it as a literal and therefore it is unable to
> change to a floating number.  In other words, Python does not have the
> ability to change the "." into an equivalent decimal point in the system
> that I have.  But please note, that the underlying assumption here is that
> Python is able to do so in an XP system.
>
> Angela Grima
>
> On Tue, Feb 24, 2015 at 4:24 PM, Angela Grima <amgrima58 at gmail.com> wrote:
>
>> Hello,
>> \
>> I am a beginner at Python and I am trying to write a program that allows
>> me to read in a list of decimal numerals, assign a grade to each one, and
>> write each one with the corresponding grade. Unfortunately, it Python
>> thinks that each score is a string but does not allow me to convert it to a
>> floating point.  I have tried different statements using Python but I am
>> still stuck.  Attached are a copy of the program, data being used.  Below
>> is the printed output.
>>
>>
>> Microsoft Windows [Version 6.1.7601]
>> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>> C:\Users\Ange\Documents\Computer Science\Python Class>docbright.py
>> Score Grade
>> Traceback (most recent call last):
>>   File "C:\Users\Ange\Documents\Computer Science\Python
>> Class\docbright.py", lin
>> e 18, in <module>
>>     x = float(x) + .005
>> ValueError: could not convert string to float:ss>
>>
>> Your help is appreciated.
>>
>> Angela Grima
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150309/06da22e5/attachment-0001.html>
-------------- next part --------------
Y 0.45
Y 0.56
Y 0.69
Y 0.75
Y 0.85
Y 0.95
Y 0.15
Y 0.10
Y 0.25
Y 0.35
-------------- next part --------------

import re
hand = open('datang.txt')

print 'Score Grade'
for line in hand:


  atpos = line.find('.')
#  print  atpos
  spos = line.find(' ',atpos)
#  print spos
  guest = line[atpos+1:spos]
#  print guest
  x = float(guest)
  



  x = x*.01 +.05
#  print x
  
  y =  '.'+guest[0:4]
#  print y

  if x > 1:
    print y,'Error number is greater than 1'
  elif x>=.9:
    print  y,'   A'
  elif x>=.8:
     print  y,'   B'
  elif x>=.7:
     print  y,'   C'
  elif x>=.6:
     print  y,'   D'
  elif x>=0.0:
  	 print  y,'   F'
  else: 
    print y,'Error number is less than 0'
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Output from Revised Program.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 13586 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150309/06da22e5/attachment-0001.docx>

From report at bugs.python.org  Tue Mar 10 11:47:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 Mar 2015 10:47:52 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1425984472.33.0.659798636612.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch that says that the NUL is always appended for both Unicode and Bytes, and explicitly says that internal NULs are allowed.

----------
Added file: http://bugs.python.org/file38420/utf8-null.v2.patch

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

From report at bugs.python.org  Tue Mar 10 12:16:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 11:16:40 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1425986200.75.0.967310631185.issue23088@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are other functions that returns null terminated data: PyByteArray_AsString(), PyBytes_AsStringAndSize(), PyUnicode_AS_UNICODE(), PyUnicode_AsUCS4Copy() PyUnicode_AsUnicode(), PyUnicode_AsUnicodeAndSize(), PyUnicode_AsWideCharString() and may be more. See also examples of notes about embedded null characters.

And for consistency with all other documentation this should be written as "null byte/character", not NUL.

----------

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

From report at bugs.python.org  Tue Mar 10 12:27:57 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Mar 2015 11:27:57 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1425986200.75.0.967310631185.issue23088@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwa9PyepEKH-vUDTd9WUkSQ_aDg27PbnZsLACdO5SNvbAw@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> And for consistency with all other documentation this should be written as "null byte/character", not NUL.

Agreed!

----------

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

From report at bugs.python.org  Tue Mar 10 12:29:31 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 11:29:31 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <CAMpsgwa9PyepEKH-vUDTd9WUkSQ_aDg27PbnZsLACdO5SNvbAw@mail.gmail.com>
Message-ID: <1868065.xC6uC5Mtcv@raxxla>


Serhiy Storchaka added the comment:

Yes, and for agreement with Victor. ;-)

----------

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

From report at bugs.python.org  Tue Mar 10 13:46:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Mar 2015 12:46:51 +0000
Subject: [docs] [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <20150310124647.16649.64982@psf.io>


Roundup Robot added the comment:

New changeset 64c0b4aead0f by Berker Peksag in branch '3.4':
Issue #23432: Remove duplicate content from SystemExit docs.
https://hg.python.org/cpython/rev/64c0b4aead0f

New changeset 5163fb8dc61f by Berker Peksag in branch 'default':
Issue #23432: Remove duplicate content from SystemExit docs.
https://hg.python.org/cpython/rev/5163fb8dc61f

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

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

From report at bugs.python.org  Tue Mar 10 13:47:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 Mar 2015 12:47:58 +0000
Subject: [docs] [issue23432] Duplicate content in SystemExit documentation
In-Reply-To: <1423571355.15.0.388380550498.issue23432@psf.upfronthosting.co.za>
Message-ID: <1425991678.78.0.596547464013.issue23432@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the review, Martin.

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

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

From report at bugs.python.org  Tue Mar 10 18:45:48 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 Mar 2015 17:45:48 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426009548.1.0.83647855899.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

First attempt at describing this attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file38424/linecache-encoding-doc.patch

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

From report at bugs.python.org  Tue Mar 10 21:24:06 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 Mar 2015 20:24:06 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
	of Pool	example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1426019046.0.0.821213429517.issue18620@psf.upfronthosting.co.za>


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


----------
nosy: +jnoller, sbt

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

From report at bugs.python.org  Tue Mar 10 23:55:33 2015
From: report at bugs.python.org (David Linke)
Date: Tue, 10 Mar 2015 22:55:33 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426028133.23.0.68349101026.issue23623@psf.upfronthosting.co.za>


David Linke added the comment:

Besides clarifying documentation, it may be helpful to provide a script that (temporarily) sets the path to pythonX and pythonX/scripts. A batch cmd script that does that and also changes the default Python for the launcher is here: https://gist.github.com/dalito/8356483ac2ffb2b8b468
The Python version is specified just like for the launcher: "pypath -3.4" temporarily sets the path for Python34 and Python34/scripts and "pypath" restores the previous state. The script uses the launcher to get the location of the specified Python version.

I think some of the problem above could be mitigated by including such cmd/powershell script(s).

----------

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

From report at bugs.python.org  Wed Mar 11 00:02:02 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 10 Mar 2015 23:02:02 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426028522.34.0.927580612003.issue23623@psf.upfronthosting.co.za>


Paul Moore added the comment:

Steve has something like that planned, I believe. It's been discussed a couple of times on python-dev

----------

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

From report at bugs.python.org  Wed Mar 11 03:03:19 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 11 Mar 2015 02:03:19 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426039399.6.0.538086282313.issue23623@psf.upfronthosting.co.za>


Steve Dower added the comment:

"Planned" is a bit strong - in need of some simultaneous time and motivation :) Thanks for the upvote.

----------

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

From report at bugs.python.org  Wed Mar 11 12:15:01 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 11:15:01 +0000
Subject: [docs] [issue23639] Not documented special names
Message-ID: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here are lists of special names used in Python core and the stdlib, but absent in documentation index.

Module level names used in pydoc:
    __author__
    __credits__
    __date__
    __version__

Module level name used in doctest:
    __test__

Other module level names:
    __about__               (heapq only)
    __copyright__           (many modules)
    __cvsid__               (tarfile only)
    __docformat__           (doctest only)
    __email__               (test_with and test_keywordonlyarg only)
    __libmpdec_version__    (decimal only)
    __status__              (logging only)


type attributes (mostly used in tests):
    __abstractmethods__     (used in abc, functools)
    __base__
    __basicsize__
    __dictoffset__
    __flags__               (used in inspect, copyreg)
    __itemsize__
    __weakrefoffset__

super() attributes:
    __self_class__
    __thisclass__

Used in sqlite:
    __adapt__
    __conform__

Used in ctypes:
    __ctype_be__
    __ctype_le__
    __ctypes_from_outparam__

Used in unittest:
    __unittest_expecting_failure__
    __unittest_skip__
    __unittest_skip_why__

float methods, for testing:
    __getformat__
    __setformat__

Used in IDLE RPC:
    __attributes__
    __methods__

Others:
    __alloc__               (bytearray method)
    __args__                (used in bdb)
    __build_class__         (builtins function, used in eval loop)
    __builtins__            (module attribute)
    __decimal_context__     (used in decimal)
    __exception__           (used in pdb)
    __getinitargs__         (used in pickle, datetime)
    __initializing__        (used in importlib)
    __isabstractmethod__    (function/method/descriptor attribute, used in abc, functools, types)
    __ltrace__              (used in eval loop, never set)
    __members__             (Enum attribute, used in many modules)
    __mp_main__             (used in multiprocessing)
    __new_member__          (Enum attribute, used in enum internally)
    __newobj__              (copyreg function, used in pickle, object.__reduce_ex__)
    __newobj_ex__           (copyreg function, used in pickle, object.__reduce_ex__)
    __objclass__            (descriptor/enum attribute, used in inspect, pydoc, doctest, multiprocessing)
    __prepare__             (metaclass method, used in builtins.__build_class__, types)
    __pycache__             (cache directory name)
    __return__              (used in pdb)
    __signature__           (used in inspect, never set)
    __sizeof__              (standard method, used in sys.getsizeof)
    __slotnames__           (used in object.__getstate__ for caching)
    __text_signature__      (function/method/descriptor attribute, used in inspect)
    __trunc__               (used in math.trunc, int, etc)
    __warningregistry__     (used in warnings)
    __weakref__             (used in weakref)
    __wrapped__             (used in inspect, functools, contextlib, asyncio)

Needed a patch or a set of patches that will add theses names to the index and document them if they are not documented.

----------
assignee: docs at python
components: Documentation
messages: 237859
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Not documented special names
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 11 13:00:10 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 11 Mar 2015 12:00:10 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426075210.41.0.469970609612.issue23639@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think most of these are either implementation details or "private" names, so there is no need to document them.  The ones that are intended to be used by developers or that are useful to understand the functioning of a public API should be documented.  If these names are already in the documentation but not in the index, then an index entry should be added.

----------
type:  -> enhancement

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

From report at bugs.python.org  Wed Mar 11 13:02:40 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 Mar 2015 12:02:40 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426075360.43.0.611838021807.issue23639@psf.upfronthosting.co.za>


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


----------
dependencies: +__sizeof__ is not documented

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

From report at bugs.python.org  Wed Mar 11 15:59:43 2015
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 Mar 2015 14:59:43 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426085983.55.0.563906521077.issue23625@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Egg files are not a part of the Python stdlib and so I don't understand why you expected them to be supported by imp? Anyway, because egg files are not from Python itself but a third-party project they shouldn't be referenced from the official docs as it would just confuse people who don't know what eggs even are.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +brett.cannon, docs at python
resolution:  -> not a bug
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Wed Mar 11 17:23:06 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 11 Mar 2015 16:23:06 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426090986.77.0.890162457456.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

Dear Bret Cannon,

I don't ask for egg support in the imp module.
I don't want to change the implemenation of imp.find_module()

I just want to update the docs.

Most people run a python version which supports loading zipped eggs.

Please reopened this, since I think you misunderstood me. If not, and you don't care about the docs. Leave it closed :-)

----------
nosy: +guettli

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

From report at bugs.python.org  Wed Mar 11 17:36:13 2015
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 11 Mar 2015 16:36:13 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426091773.72.0.0392124622118.issue23639@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think like Ezio does.  Python covers itself by saying that all names starting and ending with two underscores are reserved, and documents those that are interesting for users.  On the other hand, many third-party frameworks/libs/apps invent their own __names__ (often for metadata, sometimes for custom protocols); I don?t know if a full list of existing names in the doc would have dissuaded them.

----------

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

From report at bugs.python.org  Wed Mar 11 17:45:25 2015
From: report at bugs.python.org (Peter Otten)
Date: Wed, 11 Mar 2015 16:45:25 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426092325.14.0.358947301747.issue23639@psf.upfronthosting.co.za>


Changes by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

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

From report at bugs.python.org  Thu Mar 12 00:38:57 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Mar 2015 23:38:57 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426117137.54.0.089927504897.issue23639@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Thu Mar 12 01:51:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 00:51:09 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1426121469.76.0.747118856014.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

Posting a new patch updating the documentation for some of the extra functions Serhiy mentioned. Also changed references of ?NUL?, ?nul? and ?0? characters to ?null?. I?m not very familiar with Python?s C API, so I am mainly relying on what you guys say without much of my own verification. But if there are other related doc fixes you can think of, I?m happy to include them.

The PyUnicode_AsWideCharString() function already seems to document null termination well enough, so I did not change it. Let me know if you had a specific change in mind.

----------

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

From report at bugs.python.org  Thu Mar 12 01:51:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Mar 2015 00:51:22 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1426121482.23.0.859022490151.issue23088@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file38448/utf8-null.v3.patch

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

From report at bugs.python.org  Thu Mar 12 15:24:50 2015
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 Mar 2015 14:24:50 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426170290.43.0.385761366212.issue23625@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I understood what you asked. My point is that mentioning eggs in the imp doesn't make sense since the imp module nor import supports them natively. Eggs are a setuptools thing, not a Python standard library thing.

----------

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

From report at bugs.python.org  Thu Mar 12 16:24:36 2015
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Thu, 12 Mar 2015 15:24:36 +0000
Subject: [docs] [issue23645] Incorrect doc for __getslice__
Message-ID: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>


New submission from Ga?tan de Menten:

The documentation for __getslice__ at https://docs.python.org/2/reference/datamodel.html#object.__getslice__ states: "Note that missing i or j in the slice expression are replaced by zero or sys.maxint, respectively."

However, in practice, it seems like it is replaced by sys.maxsize instead. This is obviously only a problem for 64bit versions of Python 2 since sys.maxint and sys.maxsize are the same on 32bit Python.

In [1]: class A(object):
   ...:     def __getslice__(self, i, j):
   ...:         print i, j
   ...:

In [2]: a = A()

In [3]: a[:]
0 9223372036854775807

In [4]: import sys

In [5]: sys.maxint
Out[5]: 2147483647

In [6]: sys.maxsize
Out[6]: 9223372036854775807L

In [7]: sys.version
Out[7]: '2.7.9 |Continuum Analytics, Inc.| (default, Dec 18 2014, 16:57:52) [MSC v.1500 64 bit (AMD64)]'

----------
assignee: docs at python
components: Documentation
messages: 237947
nosy: docs at python, gdementen
priority: normal
severity: normal
status: open
title: Incorrect doc for __getslice__
versions: Python 2.7

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

From report at bugs.python.org  Thu Mar 12 19:37:11 2015
From: report at bugs.python.org (Nathan West)
Date: Thu, 12 Mar 2015 18:37:11 +0000
Subject: [docs] [issue23651] Typo in argparse allow_abrev
Message-ID: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>


New submission from Nathan West:

The documentation for the new argparse feature allow_abrev contains a typo:

>>> parser.add_argument('--foobar', action='store_true')
>>> parser.add_argument('--foonley', action='store_false')
>>> parser.parse_args([--foon])
usage: PROG [-h] [--foobar] [--foonley]
PROG: error: unrecognized arguments: --foon

The --foon should be quoted:

>>> parser.parse_args(['--foon'])

----------
assignee: docs at python
components: Documentation
messages: 237971
nosy: Lucretiel, docs at python
priority: normal
severity: normal
status: open
title: Typo in argparse allow_abrev
versions: Python 3.5

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

From report at bugs.python.org  Thu Mar 12 19:46:42 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Mar 2015 18:46:42 +0000
Subject: [docs] [issue23651] Typo in argparse allow_abrev
In-Reply-To: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>
Message-ID: <20150312184636.118005.34922@psf.io>


Roundup Robot added the comment:

New changeset 8411ae359c98 by Berker Peksag in branch 'default':
Issue #23651: Fix typo in allow_abbrev docs.
https://hg.python.org/cpython/rev/8411ae359c98

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

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

From report at bugs.python.org  Thu Mar 12 19:47:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 12 Mar 2015 18:47:09 +0000
Subject: [docs] [issue23651] Typo in argparse allow_abrev
In-Reply-To: <1426185431.21.0.35714831717.issue23651@psf.upfronthosting.co.za>
Message-ID: <1426186029.73.0.329137444215.issue23651@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, Nathan. Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar 13 01:29:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 00:29:14 +0000
Subject: [docs] [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <20150313002911.28819.94104@psf.io>


Roundup Robot added the comment:

New changeset b6fdf8c7a74d by Berker Peksag in branch '3.4':
Issue #22154: Add an example to show context management protocol support of ZipFile.open().
https://hg.python.org/cpython/rev/b6fdf8c7a74d

New changeset 390a2f4dfd4a by Berker Peksag in branch 'default':
Issue #22154: Add an example to show context management protocol support of ZipFile.open().
https://hg.python.org/cpython/rev/390a2f4dfd4a

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

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

From report at bugs.python.org  Fri Mar 13 01:31:52 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 00:31:52 +0000
Subject: [docs] [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1426206712.71.0.881581758924.issue22154@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Mike.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
type: behavior -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Fri Mar 13 01:55:10 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 00:55:10 +0000
Subject: [docs] [issue23081] Document PySequence_List(o) as equivalent to
	list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <20150313005507.32069.62777@psf.io>


Roundup Robot added the comment:

New changeset e31e987207ab by Berker Peksag in branch '3.4':
Issue #23081: Document that PySequence_List also accepts iterables.
https://hg.python.org/cpython/rev/e31e987207ab

New changeset eb4a0048978c by Berker Peksag in branch 'default':
Issue #23081: Document that PySequence_List also accepts iterables.
https://hg.python.org/cpython/rev/eb4a0048978c

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

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

From report at bugs.python.org  Fri Mar 13 01:56:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Mar 2015 00:56:10 +0000
Subject: [docs] [issue23081] Document PySequence_List(o) as equivalent to
	list(o)
In-Reply-To: <1418908520.28.0.480794985208.issue23081@psf.upfronthosting.co.za>
Message-ID: <1426208170.18.0.992445656236.issue23081@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and the patch, Lars.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Fri Mar 13 04:36:44 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 Mar 2015 03:36:44 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426217803.93.0.552062121349.issue23639@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some of these that I believe are at least partially documented, so could be added to the index. But the index for these is not very good anyway, because they are listed in a funny (ASCII-betical?) order in a special section called ?symbols?, rather than alphabetically as you would expect. But that would be a separate issue.

Potential index entries:

builtins.__build_class__() ? https://docs.python.org/dev/library/dis.html#opcode-LOAD_BUILD_CLASS
__builtins__ global variable ? https://docs.python.org/dev/reference/executionmodel.html#naming-and-binding
__conform__() method ? https://docs.python.org/dev/library/sqlite3.html#letting-your-object-adapt-itself
__isabstractmethod__ ? https://docs.python.org/dev/library/abc.html#abc.abstractmethod
Enum.__members__ ? https://docs.python.org/dev/library/enum.html#iteration
__objclass__ ? https://docs.python.org/dev/reference/datamodel.html#implementing-descriptors
type.__prepare__ ? https://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace
__pycache__/ directory ? https://docs.python.org/dev/tutorial/modules.html#compiled-python-files
object.__signature__ ? https://docs.python.org/dev/library/inspect.html#inspect.unwrap
object.__sizeof__() ? https://docs.python.org/dev/library/sys.html#sys.getsizeof
module.__test__ ? https://docs.python.org/dev/library/doctest.html#which-docstrings-are-examined
Real.__trunc__ ? https://docs.python.org/dev/library/math.html#math.trunc
module.__warningregistry__ ? https://docs.python.org/dev/library/warnings.html#warnings.warn_explicit
object.__weakref__ ? https://docs.python.org/dev/c-api/typeobj.html#c.PyTypeObject.tp_weaklistoffset

Others that are referenced by the documentation, but not explained anywhere that I can tell:

* module.__version__, referenced as an attribute in a few modules and also in sample code
* __getformat__(), __setformat__(), __getinitargs__() methods, referenced in ?unittest.mock? documentation

Regarding __base__, I always assumed this was a leftover from Python 2 from some time before multiple inheritance, so maybe __bases__ could be used instead now (unless testing backwards compatibility).

----------

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

From report at bugs.python.org  Fri Mar 13 08:21:51 2015
From: report at bugs.python.org (Ian Lee)
Date: Fri, 13 Mar 2015 07:21:51 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426231311.02.0.350403704846.issue23639@psf.upfronthosting.co.za>


Changes by Ian Lee <ianlee1521 at gmail.com>:


----------
nosy: +IanLee1521

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

From report at bugs.python.org  Fri Mar 13 09:39:45 2015
From: report at bugs.python.org (Alex Shkop)
Date: Fri, 13 Mar 2015 08:39:45 +0000
Subject: [docs] [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426235985.66.0.0285242313603.issue23645@psf.upfronthosting.co.za>


Alex Shkop added the comment:

This is true. In ceval.c default value for end index is PY_SSIZE_T_MAX. Whereas in sysmodule.c defined:

SET_SYS_FROM_STRING("maxsize",
                    PyInt_FromSsize_t(PY_SSIZE_T_MAX));
SET_SYS_FROM_STRING("maxint",
                    PyInt_FromLong(PyInt_GetMax()));

I added a patch that fixes documentation. But please note, that __getslice__ is deprecated since Python 2.0 and is no longer supported in Python 3. Use __getitem__ instead.

----------
keywords: +patch
nosy: +ashkop
Added file: http://bugs.python.org/file38468/issue23645.patch

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

From report at bugs.python.org  Fri Mar 13 10:00:48 2015
From: report at bugs.python.org (=?utf-8?q?Ga=C3=ABtan_de_Menten?=)
Date: Fri, 13 Mar 2015 09:00:48 +0000
Subject: [docs] [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426237248.37.0.725271521406.issue23645@psf.upfronthosting.co.za>


Ga?tan de Menten added the comment:

Thanks for creating the patch! 

PS: I know it is deprecated. But I am stuck on Python2 for that project and my class inherits from numpy ndarray, so I do not have a choice...

----------

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

From report at bugs.python.org  Fri Mar 13 16:31:25 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Fri, 13 Mar 2015 15:31:25 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
Message-ID: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>


New submission from Vladimir Ulupov:

I use PyCharm. This IDE checks the signature functions.
When I used the extra arguments to the function register_dialect - IDE reported error.

This is what has generated IDE for this function.
http://dumpz.org/1347592/

Apparently error here
https://hg.python.org/cpython/file/44c1c0cbdc06/Modules/_csv.c#l1547
https://hg.python.org/cpython/file/c1abcbcfefab/Modules/_csv.c#l1590


https://docs.python.org/2/library/csv.html?highlight=csv#csv.register_dialect
https://docs.python.org/3/library/csv.html?highlight=csv#csv.register_dialect

----------
assignee: docs at python
components: Documentation
messages: 238035
nosy: Vladimir Ulupov, docs at python
priority: normal
severity: normal
status: open
title: csv.register_dialect  doc string
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Mar 13 16:33:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Mar 2015 15:33:12 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426260792.19.0.368120964979.issue23659@psf.upfronthosting.co.za>


R. David Murray added the comment:

Could you clarify what bug in python you are reporting?

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

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

From report at bugs.python.org  Fri Mar 13 16:37:39 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 13 Mar 2015 15:37:39 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426261059.14.0.21064913982.issue23659@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy: +skip.montanaro

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

From report at bugs.python.org  Fri Mar 13 18:59:42 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 17:59:42 +0000
Subject: [docs] [issue23623] Python 3.5 docs need to clarify how to set PATH,
	etc
In-Reply-To: <1425910467.52.0.177540191477.issue23623@psf.upfronthosting.co.za>
Message-ID: <1426269582.53.0.685834153856.issue23623@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Fri Mar 13 19:20:26 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Mar 2015 18:20:26 +0000
Subject: [docs] [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <1426270826.45.0.700615840529.issue23645@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Fri Mar 13 20:33:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Mar 2015 19:33:06 +0000
Subject: [docs] [issue23645] Incorrect doc for __getslice__
In-Reply-To: <1426173876.09.0.220076074076.issue23645@psf.upfronthosting.co.za>
Message-ID: <20150313193236.13203.50941@psf.io>


Roundup Robot added the comment:

New changeset 3b91d834160f by Benjamin Peterson in branch '2.7':
the default is sys.maxsize not sys.maxint (closes #23645)
https://hg.python.org/cpython/rev/3b91d834160f

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

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

From report at bugs.python.org  Sat Mar 14 01:05:19 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 Mar 2015 00:05:19 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1426291519.85.0.443432334258.issue23639@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Idlelib.rpc uses the somewhat arbitrary *strings* '__methods__' and '__attributes__' as private signals in its protocol.  They are not object or attribute names, special or otherwise, in the sense used here.

The use of '__methods__' in idlelib.rpc (line 176) harkens back to pre 2.2 days when __methods__ was officially used in the type introspection api.  That class attribute was "a list of method names supported by the object.".  See PEP 252.  Its complement was __members__, a list of non-method attributes (other than itself, I presume).  rpc uses '__attributes__' instead.

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

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

From report at bugs.python.org  Sat Mar 14 01:13:44 2015
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 14 Mar 2015 00:13:44 +0000
Subject: [docs] [issue23556] Scope for raise without argument is different
	in Python	2 and 3
In-Reply-To: <1425212072.31.0.66074782686.issue23556@psf.upfronthosting.co.za>
Message-ID: <1426292024.17.0.172329671707.issue23556@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Sat Mar 14 13:17:48 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Sat, 14 Mar 2015 12:17:48 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426335468.81.0.76307068345.issue23659@psf.upfronthosting.co.za>


Vladimir Ulupov added the comment:

Incorrect docstring(PyDoc_STRVAR) for function csv.register_dialect

----------

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

From report at bugs.python.org  Sat Mar 14 15:40:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Mar 2015 14:40:12 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426344012.11.0.0873342177023.issue23659@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, you are trying to point out that the docstring doesn't mention fmtparams, or that the dialect object is optional. Sure, that should be fixed.

----------

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

From report at bugs.python.org  Sat Mar 14 16:01:20 2015
From: report at bugs.python.org (Malcolm Smith)
Date: Sat, 14 Mar 2015 15:01:20 +0000
Subject: [docs] [issue23662] Cookie.domain is undocumented
Message-ID: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>


New submission from Malcolm Smith:

This is a fundamental attribute of a cookie, which will be set even if the server doesn't specify it, yet it doesn't appear in the documentation either of 2.x cookielib or 3.x http.cookiejar.

----------
assignee: docs at python
components: Documentation
messages: 238087
nosy: Malcolm Smith, docs at python
priority: normal
severity: normal
status: open
title: Cookie.domain is undocumented
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Mar 14 16:12:56 2015
From: report at bugs.python.org (Vladimir Ulupov)
Date: Sat, 14 Mar 2015 15:12:56 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1426345976.89.0.524545133327.issue23659@psf.upfronthosting.co.za>


Vladimir Ulupov added the comment:

Yes, sorry for my bad English.

----------

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

From report at bugs.python.org  Sat Mar 14 19:28:20 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 18:28:20 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
	module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426357700.63.0.30839397627.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, this looks as a bug in Sphinx configuration. Why module takes priority on class when the role is explicitly specified? I have counted about two hundreds of similar bugs in the documentation.

----------
nosy: +georg.brandl, serhiy.storchaka
type:  -> behavior

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

From report at bugs.python.org  Sat Mar 14 20:46:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 Mar 2015 19:46:00 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
	module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426362359.35.0.0890466939408.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 2.7 that fixes above a hundred of broken class references. But may be even more broken function references. I think it would be better to fix Sphinx rules.

----------
keywords: +patch
priority: normal -> high
Added file: http://bugs.python.org/file38485/docs_class_links-2.7.patch

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

From report at bugs.python.org  Sat Mar 14 21:51:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 14 Mar 2015 20:51:00 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
	module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1426366260.79.0.712125143778.issue21818@psf.upfronthosting.co.za>


R. David Murray added the comment:

This happens because the role is pretty much ignored by Sphinx for linking purposes.  I remember Georg talking about the reason for this, but I forget what it was.  Perhaps it would be possible to, as you suggest, have the roll affect the priority...but it may be the case that the references don't currently retain the needed information.  Regardless, that would be an issue for the Sphinx tracker.

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

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

From report at bugs.python.org  Sat Mar 14 22:59:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 Mar 2015 21:59:10 +0000
Subject: [docs] [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1426370350.93.0.995732398662.issue23662@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Sun Mar 15 04:17:21 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Mar 2015 03:17:21 +0000
Subject: [docs] [issue23549] heapq docs should be more precise about how to
	access	the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <20150315031718.88866.83656@psf.io>


Roundup Robot added the comment:

New changeset 8ddda7d1f8e3 by Eli Bendersky in branch '3.4':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/8ddda7d1f8e3

New changeset 642247a536d5 by Eli Bendersky in branch 'default':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/642247a536d5

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

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

From report at bugs.python.org  Sun Mar 15 04:20:17 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Mar 2015 03:20:17 +0000
Subject: [docs] [issue23549] heapq docs should be more precise about how to
	access	the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <20150315032014.86357.40631@psf.io>


Roundup Robot added the comment:

New changeset b61578bb5014 by Eli Bendersky in branch '2.7':
Issue #23549: Clarify confusion in heapq doc - accessing the mininmal element
https://hg.python.org/cpython/rev/b61578bb5014

----------

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

From report at bugs.python.org  Sun Mar 15 04:20:33 2015
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Mar 2015 03:20:33 +0000
Subject: [docs] [issue23549] heapq docs should be more precise about how to
	access	the smallest element
In-Reply-To: <1425141461.42.0.47354110207.issue23549@psf.upfronthosting.co.za>
Message-ID: <1426389633.39.0.0841360527957.issue23549@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Sun Mar 15 20:40:51 2015
From: report at bugs.python.org (Tapani Kiiskinen)
Date: Sun, 15 Mar 2015 19:40:51 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
Message-ID: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>


New submission from Tapani Kiiskinen:

https://docs.python.org/3/library/functions.html#super

There's no mention in the document which __mro__ is used in the case of a super(Type, obj) call. There's this mention 'The __mro__ attribute of the *type* lists the method resolution search order used by both getattr() and super().' but my understanding is that this only applies in the case of a super(type) call plus it doesn't state that it only applies in that case. (I'm fairly certain I'm not wrong; if only the __mro__ of the type was used then cooperative multiple inheritance (which is referenced three paragraphs down) could not work because the __mro__ of the type never has sibling types.)

Isn't this misleading due to a super(Type, obj) call (or just super() inside a class in 3k) being the more normal way to use the function? Even now I can't find a single resource to confirm which exact mro is used in the case of a super(Type, obj) call, I've only been able to deduce that it probably uses the type(obj).__mro__ then finds the Type and then tries the entries after Type.

Finally 'If the second argument is omitted, the super object returned is unbound. If the second argument is an object, isinstance(obj, type) must be true. If the second argument is a type, issubclass(type2, type) must be true (this is useful for classmethods).'

I'm interpreting this is essentially saying that if the second argument is given that the returned object will be bound, given an object the super call would return a bound instance method and given a type a bound class method? I feel like stating this explicitly would be more clear than implicitly.

----------
assignee: docs at python
components: Documentation
messages: 238157
nosy: Tapani Kiiskinen, docs at python
priority: normal
severity: normal
status: open
title: super() documentation isn't very clear
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/issue23674>
_______________________________________

From report at bugs.python.org  Sun Mar 15 22:06:39 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:06:39 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426453599.19.0.880023151906.issue23674@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

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

From report at bugs.python.org  Sun Mar 15 22:34:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Mar 2015 21:34:03 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426455243.73.0.214295024333.issue23674@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> There's this mention 'The __mro__ attribute of the *type* lists
> the method resolution search order used by both getattr() and super().

I think instead of *type* it should say *object-or-type*.  It is the "second argument" that supplied the MRO.  The "first arguments" determines where we are currently in that MRO so that the search can begin upstream from the current class.

----------

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

From report at bugs.python.org  Sun Mar 15 22:55:48 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Mar 2015 21:55:48 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426456548.08.0.430142046428.issue23674@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree with Tapani; what you just explained should be made explicit ("the type is skipped" isn't the same as "searching starts from the item after the type in the object's MRO").  Also, the docs imply by the phrasing that the getattr docs will explain the method resolution order, but those docs do not in fact address the topic.  Perhaps there should be a link to 'method resolution order' in the glossary?

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

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

From report at bugs.python.org  Mon Mar 16 09:50:55 2015
From: report at bugs.python.org (Frank Millman)
Date: Mon, 16 Mar 2015 08:50:55 +0000
Subject: [docs] [issue23677] Mention dict and set comps in library reference
Message-ID: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>


New submission from Frank Millman:

This is from the documentation at Section 4.6.4. Lists

"""
Lists may be constructed in several ways:

Using a pair of square brackets to denote the empty list: []
Using square brackets, separating items with commas: [a], [a, b, c]
Using a list comprehension: [x for x in iterable]
Using the type constructor: list() or list(iterable)
"""

Comprehensions are mentioned as a constructor.

This is from the documentation at Section 4.10. Mapping Types

"""
Dictionaries can be created by placing a comma-separated list of key: value pairs within braces, for example: {'jack': 4098, 'sjoerd': 4127} or {4098: 'jack', 4127: 'sjoerd'}, or by the dict constructor.

class dict(**kwarg) 
class dict(mapping, **kwarg) 
class dict(iterable, **kwarg) 
Return a new dictionary initialized from an optional positional argument and a possibly empty set of keyword arguments.
"""

There is no mention of dictionary comprehensions.

For consistency, I believe that the documentation for Dicts and Sets should mention comprehensions.

----------
assignee: docs at python
components: Documentation
messages: 238186
nosy: FrankMillman, docs at python
priority: normal
severity: normal
status: open
title: Mention dict and set comps in library reference
versions: Python 3.4

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

From report at bugs.python.org  Mon Mar 16 12:05:30 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Mar 2015 11:05:30 +0000
Subject: [docs] [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426503930.88.0.563545004331.issue23677@psf.upfronthosting.co.za>


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


----------
keywords: +patch
versions: +Python 3.5
Added file: http://bugs.python.org/file38507/issue23677.diff

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

From report at bugs.python.org  Mon Mar 16 13:06:01 2015
From: report at bugs.python.org (Tapani Kiiskinen)
Date: Mon, 16 Mar 2015 12:06:01 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426507561.5.0.662304854479.issue23674@psf.upfronthosting.co.za>


Tapani Kiiskinen added the comment:

A link to the to the glossary would also be good yes. I was figuring out how super() works and as you said the doc gave the impression getattr would explain more but it doesn't. Had to use google to find the glossary entry for MRO which had the link explaining how that is calculated.

----------

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

From report at bugs.python.org  Mon Mar 16 15:00:58 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 14:00:58 +0000
Subject: [docs] [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426514458.91.0.302149933895.issue23677@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds reasonable.  Dict and set comprehensions were added later than list comprehensions, and we probably just didn't notice this needed updating.

Mark's patch, however, is incorrect.  Mark: the dict/set literal notation is a different thing from a comprehension.

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

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

From report at bugs.python.org  Mon Mar 16 18:40:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 17:40:41 +0000
Subject: [docs] [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426527640.99.0.326016832985.issue23679@psf.upfronthosting.co.za>


R. David Murray added the comment:

But the doc explicitly says 2.7.9, so no, they are not correct.  There also should be versionchanged directive, I think.

----------
assignee:  -> docs at python
components: +Documentation
dependencies:  -SSL module should not offer RC4 based cipher suites for clients by default
nosy: +docs at python, r.david.murray
stage:  -> needs patch
status: closed -> open
type: security -> behavior

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

From report at bugs.python.org  Mon Mar 16 18:40:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Mar 2015 17:40:51 +0000
Subject: [docs] [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426527651.29.0.756946412996.issue23679@psf.upfronthosting.co.za>


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


----------
resolution: duplicate -> 

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

From report at bugs.python.org  Mon Mar 16 18:45:38 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Mar 2015 17:45:38 +0000
Subject: [docs] [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <20150316174535.30194.49061@psf.io>


Roundup Robot added the comment:

New changeset e1dfa5f0709f by Benjamin Peterson in branch '2.7':
versionchanged for rc4 removal (closes #23679)
https://hg.python.org/cpython/rev/e1dfa5f0709f

New changeset 2a6a63828a40 by Benjamin Peterson in branch '3.4':
versionchanged for rc4 removal (closes #23679)
https://hg.python.org/cpython/rev/2a6a63828a40

New changeset 87c102d0df39 by Benjamin Peterson in branch 'default':
merge 3.4 (#23679)
https://hg.python.org/cpython/rev/87c102d0df39

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

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

From report at bugs.python.org  Mon Mar 16 22:32:46 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 16 Mar 2015 21:32:46 +0000
Subject: [docs] [issue23682] distutils docs still talk about compatibility
	with	Python 2.2
Message-ID: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

I'm pretty sure the distutils docs for Python 3.4 don't need to describe how to make packages compatible with Python < 2.2.3.

I know that these docs are deprecated in favour of the Python packaging guide, but I still look at them at times, and this is embarrassing.

----------
assignee: docs at python
components: Documentation
files: dont-mention-py22.patch
keywords: patch
messages: 238241
nosy: docs at python, takluyver
priority: normal
severity: normal
status: open
title: distutils docs still talk about compatibility with Python 2.2
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38512/dont-mention-py22.patch

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

From report at bugs.python.org  Mon Mar 16 22:39:39 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 16 Mar 2015 21:39:39 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426541979.67.0.883494378889.issue11726@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Anything else I should be doing here?

----------

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

From report at bugs.python.org  Mon Mar 16 23:09:09 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 22:09:09 +0000
Subject: [docs] [issue23682] distutils docs still talk about compatibility
	with	Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426543749.82.0.717191020054.issue23682@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I also removed it in my patch for issue 19610.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Mon Mar 16 23:14:23 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 Mar 2015 22:14:23 +0000
Subject: [docs] [issue23682] distutils docs still talk about compatibility
	with	Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426544063.12.0.339765092799.issue23682@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
stage:  -> commit review

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

From report at bugs.python.org  Mon Mar 16 23:48:25 2015
From: report at bugs.python.org (Shakeel Mohamed)
Date: Mon, 16 Mar 2015 22:48:25 +0000
Subject: [docs] [issue23542] Update PEP 476 for using urllib2.build_opener()
In-Reply-To: <1425069828.0.0.476725699175.issue23542@psf.upfronthosting.co.za>
Message-ID: <1426546105.68.0.817465200459.issue23542@psf.upfronthosting.co.za>


Shakeel Mohamed added the comment:

Hi, any plans to do this? If not, we can close it.

----------

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

From report at bugs.python.org  Tue Mar 17 02:39:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 01:39:42 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
	default	scheme
Message-ID: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for urlsplit() says:

'''
urlparse(urlstring, scheme='', allow_fragments=True)

. . .

If the scheme argument is specified, it gives the default addressing scheme, to be used only if the URL does not specify one. The default value for this argument is the empty string.
'''

However this contradicts the table of attributes, which gives:

Attribute: scheme, . . . Value if not present: empty string

Similarly for urlsplit(). Of course, the description of the ?scheme? parameter is correct, and the table is only correct when no ?scheme? parameter is given:

>>> urlparse("//example.net").scheme
''
>>> urlparse(b"//example.net").scheme
b''
>>> urlparse("//example.net", "http").scheme
'http'

This issue is split off another where I tried to sneak in a quick fix, but the wording probably needs more thought. Original change: <https://bugs.python.org/review/22852/patch/14176/52720#old-line-92>.

Maybe change it to this?

Value if not present: empty string or default scheme

----------
assignee: docs at python
components: Documentation
messages: 238253
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: urlparse() documentation does not account for default scheme

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

From report at bugs.python.org  Tue Mar 17 05:56:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Mar 2015 04:56:06 +0000
Subject: [docs] [issue23682] distutils docs still talk about compatibility
	with	Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <20150317045603.7239.96127@psf.io>


Roundup Robot added the comment:

New changeset 910a7a540a31 by Berker Peksag in branch '3.4':
Issue #23682: Delete Python 2.2 mention from distutils documentation.
https://hg.python.org/cpython/rev/910a7a540a31

New changeset 7757e98a9f3b by Berker Peksag in branch 'default':
Issue #23682: Delete Python 2.2 mention from distutils documentation.
https://hg.python.org/cpython/rev/7757e98a9f3b

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

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

From report at bugs.python.org  Tue Mar 17 05:56:55 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Mar 2015 04:56:55 +0000
Subject: [docs] [issue23682] distutils docs still talk about compatibility
	with	Python 2.2
In-Reply-To: <1426541566.7.0.328522056183.issue23682@psf.upfronthosting.co.za>
Message-ID: <1426568215.31.0.511612597328.issue23682@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Thomas!

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

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

From report at bugs.python.org  Tue Mar 17 07:40:32 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 06:40:32 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426574432.11.0.40236603628.issue12855@psf.upfronthosting.co.za>


Martin Panter added the comment:

Note to self, or anyone else handling this patch: See <https://bugs.python.org/issue22232#msg225769> for further improvement ideas:

* Might be good to bring back the reference to universal newlines, but say it accepts additional line boundaries
* Terry also suggested a doc string improvement

----------

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

From report at bugs.python.org  Tue Mar 17 07:42:25 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 Mar 2015 06:42:25 +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: <1426574545.27.0.586381238795.issue22232@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Mar 17 10:31:09 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Mar 2015 09:31:09 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426584669.72.0.839928433388.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

In this case I am wearing newbee user glasses.

And with this glasses on my nose, I don't care for implementation.

I am confused that imp module does not work like "import foo".

----------

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

From report at bugs.python.org  Tue Mar 17 10:37:14 2015
From: report at bugs.python.org (mogli)
Date: Tue, 17 Mar 2015 09:37:14 +0000
Subject: [docs] [issue23679] SSL Ciphers RC4
In-Reply-To: <1426505465.73.0.583137037383.issue23679@psf.upfronthosting.co.za>
Message-ID: <1426585034.01.0.24106937629.issue23679@psf.upfronthosting.co.za>


mogli added the comment:

That was fast, great job!

For the record: The SSLv3 issue I also wrote about was a false positive because the test only works with Javascript. Python 2.7.9 has SSLv3 disabled by default as it should.

urllib2.urlopen("https://sslv3.dshield.org")  # fails as it should

----------

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

From report at bugs.python.org  Tue Mar 17 11:05:02 2015
From: report at bugs.python.org (Paul Moore)
Date: Tue, 17 Mar 2015 10:05:02 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426586702.33.0.77423709959.issue23625@psf.upfronthosting.co.za>


Paul Moore added the comment:

Egg files are a format defined by setuptools. If you look in the setuptools documentation it notes that egg files are simply zipfiles with a particular structure and naming convention. So from a core Python perspective, you can use eggs just like any other zipfile. See the zipimport documentation for further details if you need them.

To further confuse the issue, setuptools includes some pretty complex mechanisms for adding eggs to syst.path so that their contents can be imported (there are .pth files and multi-version support, for example). Those mechanisms are part of setuptools, not of core Python. From a core Python perspective, the path handling is something you do manually.

So while I understand your confusion, I think you should understand that it is a confusion over the setuptools implementation, and how it interacts with the mechanisms defined by core Python (which are defined in terms of zipfiles). So if you feel there are any documentation issues, they should probably be addressed by setuptools rather than in the core docs.

On a peripherally related point, your comment "zipped egg files in sys.path are not found" doesn't really explain your problem very well. When reporting to setuptools, I'd suggest that you need to clarify your problem a bit better - what steps did you take, did they match the steps that the setuptools docs tell you to use, and how did the failure show itself? But as I say, that's for a setuptools bug report.

----------
nosy: +paul.moore

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

From report at bugs.python.org  Tue Mar 17 11:37:56 2015
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 17 Mar 2015 10:37:56 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426588675.97.0.201855841171.issue23625@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

The docs should be where new users look.

I don't speak about several hundret words ....

Where do you think new users look for documentation if they want a method which does find a module?

----------

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

From report at bugs.python.org  Tue Mar 17 15:24:08 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 17 Mar 2015 14:24:08 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
	default	scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <1426602248.37.0.277821367764.issue23684@psf.upfronthosting.co.za>


Demian Brecht added the comment:

+1 to the change, but I'd propose maybe "value of *scheme*" given the tables are inline with both urlsplit and urlparse docs?

----------
nosy: +demian.brecht

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

From report at bugs.python.org  Tue Mar 17 15:48:43 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Mar 2015 14:48:43 +0000
Subject: [docs] [issue23625] load_module() docs: zipped eggs are not loaded.
In-Reply-To: <1425986086.94.0.227506635369.issue23625@psf.upfronthosting.co.za>
Message-ID: <1426603723.77.0.065448454049.issue23625@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

https://pythonhosted.org/setuptools/

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

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

From report at bugs.python.org  Tue Mar 17 15:52:02 2015
From: report at bugs.python.org (SMRUTI RANJAN SAHOO)
Date: Tue, 17 Mar 2015 14:52:02 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426603922.49.0.670973941923.issue12855@psf.upfronthosting.co.za>


SMRUTI RANJAN SAHOO added the comment:

i think in this, "line \fone\nline two\n" ,the space after line taking some garbage value or you can say hex value of "\".  so that's why that is showing some hex value. if you write "\n " instead of"\" then you can't find that hex value. i attached my idle image here.

----------
nosy: +SMRUTI RANJAN SAHOO
Added file: http://bugs.python.org/file38523/python.JPG

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

From report at bugs.python.org  Tue Mar 17 22:24:45 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:24:45 +0000
Subject: [docs] [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627485.89.0.579201720133.issue23183@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Tue Mar 17 22:25:27 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:25:27 +0000
Subject: [docs] [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627527.3.0.85040958121.issue23183@psf.upfronthosting.co.za>


Robert Collins added the comment:

Here is a patch with some prose - feedback appreciated!

----------
keywords: +patch
Added file: http://bugs.python.org/file38531/issue-23183-1.patch

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

From report at bugs.python.org  Tue Mar 17 22:25:40 2015
From: report at bugs.python.org (Robert Collins)
Date: Tue, 17 Mar 2015 21:25:40 +0000
Subject: [docs] [issue23183] timeit CLI best of 3: undocumented output format
In-Reply-To: <1420620799.47.0.00516438922368.issue23183@psf.upfronthosting.co.za>
Message-ID: <1426627540.18.0.117738920522.issue23183@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Wed Mar 18 00:42:08 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Mar 2015 23:42:08 +0000
Subject: [docs] [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426635728.38.0.509149075996.issue23677@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

That was embarrassing, hopefully this is rather better.

----------
nosy: +BreamoreBoy
Added file: http://bugs.python.org/file38534/issue23677_v2.diff

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

From report at bugs.python.org  Wed Mar 18 01:18:02 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 00:18:02 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
Message-ID: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>


New submission from Paddy McCarthy:

In the zip section of the documentation, e.g. https://docs.python.org/3/library/functions.html#zip There is mention of an idiom for clustering a data series into n-length groups that I seem to only come across when people are explaining how it works on blog entries such as the three mentioned here: http://www.reddit.com/r/programming/comments/2z4rv4/a_function_for_partitioning_python_arrays/cpfvwun?context=3

It is not a straight-forward bit of code and so I think it should either be explained in more detail in the documentation or removed as an idiom, or I guess it could be encapsulated in a function and added to the stdlib.

----------
assignee: docs at python
components: Documentation
messages: 238365
nosy: Paddy McCarthy, docs at python
priority: normal
severity: normal
status: open
title: idiom for clustering a data series into n-length groups
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 18 02:00:03 2015
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 18 Mar 2015 01:00:03 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426640403.89.0.670598704095.issue23695@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think an example should suffice:

>>> s = [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>> n = 3
>>> zip(*[iter(s)]*n)
[(1, 2, 3), (4, 5, 6), (7, 8, 9)]

----------
nosy: +ethan.furman
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar 18 05:03:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 Mar 2015 04:03:30 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426651410.81.0.849811543719.issue23695@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar 18 06:10:01 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 05:10:01 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426655400.98.0.647621659507.issue23695@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

Hmmm. It seems that the problem isn't to do with the fact that it works, or how to apply it; the problem is with *how* it works. 

Making it an idiom means that too many will use it without knowing why it works which could lead to later maintenance issues. I think a better description of how it works may be needed for the docs.

Unfortunately my description of the how at http://paddy3118.blogspot.co.uk/2012/12/that-grouping-by-zipiter-trick-explained.html was not written with the docs in mind, but you are welcome to any part or the whole, for the Python docs.

----------

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

From report at bugs.python.org  Wed Mar 18 07:33:05 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Wed, 18 Mar 2015 06:33:05 +0000
Subject: [docs] [issue23698] Fix documentation for multiprocessing.Manager
Message-ID: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>


New submission from Anand B Pillai:

multiprocessing.Manager seems to have an inconsistency in behaviour/documentation or both.

The behaviour inconsistency is documented in the attached test script which should run for both Python2 and Python3. 

Briefly, multiprocessing.managers.BaseManager class starts a Python subprocess only after a call to its "start" method. Whereas its subclass, multiprocessing.managers.SyncManager does at the time of object creation. This is undocumented and against the base classe's documented behaviour.

Also, the SyncManager is more commonly advertised via the facade multiprocessing.Manager() which is again at odds with the BaseManager's interface in that,

1. It takes no arguments (Python2) and different arguments (Python 3).
2. You can't call "start" on it but you can call "start" if you initialize it via multiprocessing.managers.SyncManager directly (!)
3. Even if you can't call a start on it, apparently you can shut it down via a call to "shutdown"
4. When you try to start such a manager you get a strange AssertionError complaining the state is not INITIAL. A better error is required here.

Please find the attached file for all the sequence of tests done.

Suggested changes are,

1. Fix the inconsistency in documented behaviour between SyncManager and its base class. Either don't start the child process upon object creation or document it.
2. Fix the inconsistency in SyncManager object creation interface and behaviour via "mulitprocessing.Manager()" and directly via "multiprocessing.managers.SyncManager(...)" . One should be able to start both objects cleanly. And the former should also take the address argument. If not document it properly.
3. The AssertionError when trying to start the SyncManager object obtained via a call to "multiprocessing.Manager()" looks like a bug. It should be fixed - otherwise a bette error should be raised and documentation updated.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: mp_test.py
messages: 238379
nosy: docs at python, pythonhacker
priority: normal
severity: normal
status: open
title: Fix documentation for multiprocessing.Manager
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file38537/mp_test.py

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

From report at bugs.python.org  Wed Mar 18 07:33:43 2015
From: report at bugs.python.org (Frank Millman)
Date: Wed, 18 Mar 2015 06:33:43 +0000
Subject: [docs] [issue23677] Mention dict and set comps in library reference
In-Reply-To: <1426495855.1.0.56894829498.issue23677@psf.upfronthosting.co.za>
Message-ID: <1426660423.06.0.112807205291.issue23677@psf.upfronthosting.co.za>


Frank Millman added the comment:

Lists and tuples are described like this -

class list([iterable]) 
Lists may be constructed in several ways:
[...]

class tuple([iterable]) 
Tuples may be constructed in a number of ways:
[...]

I think a similar approach to Dicts and Sets could make sense -

class dict([**kwarg])
Dicts may be constructed in a number of ways:

- Using a pair of braces to denote the empty dict: {}
- Placing a comma-separated list of key: value pairs within braces: {'jack': 4098, 'sjoerd': 4127} or {4098: 'jack', 4127: 'sjoerd'}
- Using a dict comprehension: {k: v for k, v in iterable}
- Using the dict() built-in: dict() or dict(**kwarg) or dict(mapping, **kwarg) or dict(iterable, **kwarg) 

Add a new example -

f = {k: v for k, v in [('one', 1), ('two', 2), ('three', 3)]}


class set([iterable])
class frozenset([iterable])
Sets may be constructed in a number of ways:

- Non-empty sets (not frozensets) can be created by placing a comma-separated list of elements within braces, for example: {'jack', 'sjoerd'}
- Non-empty sets (not frozensets) can be created by using a set comprehension: {x for x in iterable}
- Using the set() or frozenset() built-in


The 'bullet-point' construction is not really necessary for Sets, but it would make it consistent with the others.


A related point (I can raise a separate Issue if preferred) -

For me, the power of comprehensions lies in their 'filtering' ability. This is not mentioned in any of the above examples, so newcomers may wonder why they should use them.

We don't want to make the examples too complicated. Maybe just add 'if ...' to the example, and provide a cross-reference to Section 6.2.4 in the Language Reference (Displays for lists, sets and dictionaries).

----------

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

From chris.ridley at tesco.net  Mon Mar 16 16:57:24 2015
From: chris.ridley at tesco.net (Chris)
Date: Mon, 16 Mar 2015 15:57:24 -0000
Subject: [docs] Python 3.4.3 epub documentation
Message-ID: <62F6810FCB7844D693D5D30617439B67@ChrissLaptop>

I have tried several times to download the Python 3.4.3 documentation in
epub format but the link
https://docs.python.org/3/archives/python-3.4.3-docs.epub points to a zip
document that does not contain an epub file.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150316/415f225a/attachment-0001.html>

From evgeni at hotmail.ru  Tue Mar 10 09:39:31 2015
From: evgeni at hotmail.ru (Sergeev Evgeni)
Date: Tue, 10 Mar 2015 11:39:31 +0300
Subject: [docs] Omission of namespace parameter to etree.findall(..) etc.
Message-ID: <09daf9ee5d5f49f6455bdfb42d5711b0e1c40b47@mail.qip.ru>

On this page: https://docs.python.org/2/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element.findall

See the discussion here: http://stackoverflow.com/a/14853417/1143274

These extra arguments should really be documented, as they are quite important for painless parsing where namespaces are involved. 

Regards,
Evgeni

P.S. I met this issue because I couldn't find the  tag within . It turned out that I have to delve into XML namespaces, and the most straightforward approach to write readable code turned out to be via the undocumented etree_instance.findall('svg:g', nss) calls, where nss is a dictionary of namespaces like {'svg': 'http://www.w3.org/2000/svg'}. By the way, it would be nice for it to support something like {'': 'http://www.w3.org/2000/svg'} to indicate the default namespace...

P.S.S. I was about to submit a report to the bugtracker, but it turned out that my email address would have been visible to all logged-in users. Obviously, this is accessible to robots who can get a Google OpenID and log in automatically. Therefore, I'm sending this report from my spamfest email account. The point is: this arrangement scares off spam-averse users like me from submitting bug reports.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150310/e36c38e1/attachment.html>

From mail at timgolden.me.uk  Tue Mar 17 18:08:41 2015
From: mail at timgolden.me.uk (Tim Golden)
Date: Tue, 17 Mar 2015 17:08:41 +0000
Subject: [docs] Fwd: Broken Link in 2.7 Docs
In-Reply-To: <CAMcaL3K5J6sXtzGpn5BT1A07t2dbeequJzd=8Xb611T06Dfkuw@mail.gmail.com>
References: <CAMcaL3K5J6sXtzGpn5BT1A07t2dbeequJzd=8Xb611T06Dfkuw@mail.gmail.com>
Message-ID: <55085F99.2030800@timgolden.me.uk>

(via webmaster@)



-------- Original Message --------
Subject: 	Broken Link in 2.7 Docs
Date: 	Tue, 17 Mar 2015 12:09:10 -0400
From: 	Alex Gerdom <agerdom at umail.iu.edu>
To: 	webmaster at python.org



To whom it may concern,

I would like to report a broken link in the 2.7 docs
( https://docs.python.org/2/using/windows.html#pywin32 ).
The link labeled 'PyWin32' links to
http://python.net/crew/mhammond/win32/ which shows the following message:


      Forbidden

    You don't have permission to access /crew/mhammond/win32/ on this
    server.


Thanks for your time,
Alex Gerdom




From susanbruce707 at outlook.com  Fri Mar 13 19:09:38 2015
From: susanbruce707 at outlook.com (Ninja Scroll)
Date: Fri, 13 Mar 2015 18:09:38 +0000
Subject: [docs] Fwd: 4.4. break and continue Statements,
	and else Clauses on Loops
In-Reply-To: <BLU437-SMTP403F3A0FEA749BDDAE1C03F51B0@phx.gbl>
References: <BLU437-SMTP403F3A0FEA749BDDAE1C03F51B0@phx.gbl>
Message-ID: <BLU436-SMTP234AECDA7DE844A41D30F50F5070@phx.gbl>




-------- Forwarded Message --------
Subject: 	4.4. break and continue Statements, and else Clauses on Loops
Date: 	Mon, 9 Mar 2015 16:22:30 +0000
From: 	Ninja Scroll <susanbruce707 at outlook.com>
To: 	docs at python.org





I typed in the example given in python docs tutorial, the output is 
clearly wrong and different from than shown in the example.
I seem to have an error and later discovered the importance of 
associating the correct inset with correct statement
error correction in lower print out.
Hope this is helpful, kind regards Susan707.





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150313/59226d1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 75883 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150313/59226d1d/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prime error corrected.PNG
Type: image/png
Size: 98907 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150313/59226d1d/attachment-0003.png>

From vadmium+py at gmail.com  Fri Mar 13 03:21:38 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 13 Mar 2015 02:21:38 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20150313022138.30397.69463@psf.upfronthosting.co.za>


https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py
File Lib/test/test_compare.py (right):

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode328
Lib/test/test_compare.py:328: def assert_insts(self, i1, i2, equal,
comp, i1_meth=(), i2_meth=()):
On 2015/03/02 18:56:14, andymaier wrote:
> Will change name to assert_comparisons, for now. I will split up the
two
> _subtest methods into six, for better identification based on
subTest() (I
> really like that), but if I look at the number of calls to
assert_comparisons(),
> I don't think I'd like to duplicate them.

Fair enough. Though I think only one of those functions would need to be
called at a time, depending on whether comp was None or not. So
assert_equality_only() would check for TypeError, and
assert_total_order() would try all six comparisons. I don?t think there
would be duplicate calls.

https://bugs.python.org/review/12067/diff/13975/Lib/test/test_compare.py#newcode569
Lib/test/test_compare.py:569: self.assert_insts(c1, c1, True,   0,
Class_str.meth, Class_str.meth)
On 2015/03/02 18:56:15, andymaier wrote:
> On the empty tuple meths: I wanted to have one place that has the
knowledge that
> there are no meths, instead of repeating that in every invocation of
> assert_insts().
> 
> But I'm ok either way. Let me know which way you would recommend to
go.

Since you have now expanded the doc string for assert_comparisons() to
say the meths tuples are only needed for custom classes, I think it
would be consistent to remove them here.

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py
File Lib/test/test_compare.py (right):

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode343
Lib/test/test_compare.py:343: comp:       Integer indicating the
expected order comparison result:
Maybe:

?Integer indicating the expected order comparison result. Requires i1
and i2 to be totally ordered, meaning that at least one comparison is
true.?

Either i1 <= i2 or i1 >= i2 being true essentially means the pair of
objects are totally ordered. E.g. considering i1={"a"} and i2={"b"},
there is no valid comp value (short of something exotic like NaN).

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode366
Lib/test/test_compare.py:366: i1_meth = ()
I think the code was simpler before with the parameter i1_meth=()
default in the function definition

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode609
Lib/test/test_compare.py:609: self.assertTrue(c2 is not c3, "Testcase
error: c2 is c3")
Could use assertIsNot() here, and in other places

https://bugs.python.org/review/12067/diff/14061/Lib/test/test_compare.py#newcode614
Lib/test/test_compare.py:614: self.assertTrue(s2 is s3, "Testcase error:
s2 is not s3")
assertIs()

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

From report at bugs.python.org  Wed Mar 18 10:24:24 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 Mar 2015 09:24:24 +0000
Subject: [docs] [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426670664.1.0.767690674915.issue23698@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +davin, sbt
versions:  -Python 3.2, Python 3.3, Python 3.6

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

From report at bugs.python.org  Wed Mar 18 14:06:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:06:20 +0000
Subject: [docs] [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <20150318130616.7263.8604@psf.io>


Roundup Robot added the comment:

New changeset b44ec269abda by Victor Stinner in branch 'default':
Issue #12155: Fix queue doc example to join threads
https://hg.python.org/cpython/rev/b44ec269abda

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

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

From report at bugs.python.org  Wed Mar 18 14:06:34 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:06:34 +0000
Subject: [docs] [issue12155] queue example doesn't stop worker threads
In-Reply-To: <1306146151.16.0.671326557503.issue12155@psf.upfronthosting.co.za>
Message-ID: <1426683994.69.0.230320164706.issue12155@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.5 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Mar 18 14:15:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:15:07 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150318131504.63576.18156@psf.io>


Roundup Robot added the comment:

New changeset 51341af466e3 by Victor Stinner in branch '3.4':
Issue #11726: clarify linecache doc: linecache is written to cache Python
https://hg.python.org/cpython/rev/51341af466e3

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

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

From report at bugs.python.org  Wed Mar 18 14:19:56 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Mar 2015 13:19:56 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150318131950.11896.22985@psf.io>


Roundup Robot added the comment:

New changeset 01cb2107cbc3 by Victor Stinner in branch '3.4':
Issue #11726: Fix linecache example in the doc
https://hg.python.org/cpython/rev/01cb2107cbc3

----------

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

From report at bugs.python.org  Wed Mar 18 14:21:11 2015
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 Mar 2015 13:21:11 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426684871.6.0.646684831804.issue11726@psf.upfronthosting.co.za>


STINNER Victor added the comment:

4 years to fix this minor documentation issue, I feel ashamed...

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

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

From report at bugs.python.org  Wed Mar 18 14:21:20 2015
From: report at bugs.python.org (Davin Potts)
Date: Wed, 18 Mar 2015 13:21:20 +0000
Subject: [docs] [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426684880.83.0.474957031225.issue23698@psf.upfronthosting.co.za>


Davin Potts added the comment:

This is closely related to issue23510.  The two issues are reacting to the same underlying inconsistency though in this issue the problem is more generally (and clearly) stated whereas issue23510 is more concerned with the consequences to using these as Context Managers.

The solution that gets implemented here should address both issues.

As mentioned in issue23510, I have a working fix though am looking for ways to further minimize the impact to existing code that uses Manager/SyncManager -- simply documenting the current inconsistent state is inadequate.

----------

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

From report at bugs.python.org  Wed Mar 18 16:13:14 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 15:13:14 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1426691594.05.0.415636667402.issue12855@psf.upfronthosting.co.za>


R. David Murray added the comment:

SMRUTI: \f is the python escape code for the ASCII formfeed character.  It is the handling of that ASCII character (among others) that this issue is discussing.

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

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

From report at bugs.python.org  Wed Mar 18 16:33:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Mar 2015 15:33:52 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426692832.72.0.434657822358.issue23695@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it would be both helpful and sufficient to add a gloss, perhaps something like: "this passes zip ``n`` references to the *same* iterator, which means zip calls that single iterator ``n`` times for each tuple it creates; zip thus outputs tuples consisting of ``n`` length chunks from the iterator ``s``".

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

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

From tsftprogramacion at gmail.com  Wed Mar 18 17:30:53 2015
From: tsftprogramacion at gmail.com (Dario A. Columbich)
Date: Wed, 18 Mar 2015 13:30:53 -0300
Subject: [docs] Documenting
Message-ID: <5509A83D.1030307@gmail.com>

Dear Friends:

I am getting into Python by some course and self-study, I am extensive 
writing skills, and I would like to help on documenting, I am not to 
reStructueredText, but I could try, or even in plan text, what I do not 
know is I what to write of.

There is a roadmap to write, or just rewriting ? I can write Spanish and 
English.

It will be nice to m help in the task.

Sincerely yours.



-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150318/c2718697/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsftSoftwareFactoryLittle.jpg
Type: image/jpeg
Size: 13312 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150318/c2718697/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tsftprogramacion.vcf
Type: text/x-vcard
Size: 363 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150318/c2718697/attachment.vcf>

From report at bugs.python.org  Wed Mar 18 20:01:54 2015
From: report at bugs.python.org (Paddy McCarthy)
Date: Wed, 18 Mar 2015 19:01:54 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1426705314.74.0.703763895546.issue23695@psf.upfronthosting.co.za>


Paddy McCarthy added the comment:

I like R. David Murray's suggestion, but I am also aware of how it works and so cannot judge how it would look to the intermediate Python programmer who knows iterators and zip, but is new to this grouper; (who I think should be the target audience).

----------

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

From report at bugs.python.org  Wed Mar 18 20:13:00 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 18 Mar 2015 19:13:00 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1426705980.89.0.0928975984441.issue11468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Raymond, in the meanwhile can the proposed patch be applied?
I don't think it's necessary to show that you need to import a module in order to test its functions.  Using modules also has the disadvantage that people might not know what result to expect if they are not familiar with the functions of that module (e.g. the only functions that return True/False in the math module seem to be isfinite/isnan/isinf), whereas everyone should know basic string methods.

----------

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

From report at bugs.python.org  Wed Mar 18 20:48:34 2015
From: report at bugs.python.org (Paul Sokolovsky)
Date: Wed, 18 Mar 2015 19:48:34 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
	refers to	"unbound methods"
Message-ID: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

Under https://docs.python.org/3/howto/descriptor.html#functions-and-methods , there're several references to unbound methods (including in expected output from the interpreter).

As known, unbound methods are gone in Python3, so seeing those are confusing. (I didn't sharply know that unbound methods are gone from Py3, so was pretty confused by the examples there, comparing them with actual output of Cpython 3.4).

----------
assignee: docs at python
components: Documentation
messages: 238468
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: docs.python.org/3/howto/descriptor.html still refers to "unbound methods"
versions: Python 3.4

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

From report at bugs.python.org  Wed Mar 18 21:28:03 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 18 Mar 2015 20:28:03 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
	refers to	"unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1426710483.31.0.62832468848.issue23702@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> behavior

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

From berker.peksag at gmail.com  Wed Mar 18 21:46:55 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 18 Mar 2015 22:46:55 +0200
Subject: [docs] Documenting
In-Reply-To: <5509A83D.1030307@gmail.com>
References: <5509A83D.1030307@gmail.com>
Message-ID: <CAF4280JTFWUsi_pTLw0oT8FD7C8C66Tg25=nZABNJA0O4U2nqg@mail.gmail.com>

On Wed, Mar 18, 2015 at 6:30 PM, Dario A. Columbich <
tsftprogramacion at gmail.com> wrote:

>  Dear Friends:
>

Hi Dario,

Welcome!


> I am getting into Python by some course and self-study, I am extensive
> writing skills, and I would like to help on documenting, I am not to
> reStructueredText, but I could try, or even in plan text, what I do not
> know is I what to write of.
>

You don't need to worry about reST. You can send plain text patches if you
want. Please take a look at
https://docs.python.org/devguide/documenting.html for quick reST
introduciton and CPython documentation guidelines.


> There is a roadmap to write, or just rewriting ? I can write Spanish and
> English
>

Here is a list of easy documentation issues: http://goo.gl/pgxGTm

--Berker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150318/df53bb02/attachment.html>

From report at bugs.python.org  Wed Mar 18 22:35:47 2015
From: report at bugs.python.org (Maries Ionel Cristian)
Date: Wed, 18 Mar 2015 21:35:47 +0000
Subject: [docs] [issue17799] settrace docs are wrong about "c_call" events
In-Reply-To: <1366428980.14.0.538502026896.issue17799@psf.upfronthosting.co.za>
Message-ID: <1426714547.13.0.284769758339.issue17799@psf.upfronthosting.co.za>


Changes by Maries Ionel Cristian <ionel.mc at gmail.com>:


----------
nosy: +ionel.mc

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

From report at bugs.python.org  Thu Mar 19 07:10:17 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Mar 2015 06:10:17 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1426745417.49.0.154572728303.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Yes, go ahead an apply this patch.

----------
assignee: rhettinger -> ezio.melotti

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

From taihengw at gmail.com  Thu Mar 19 07:06:16 2015
From: taihengw at gmail.com (TaiHeng Wei)
Date: Thu, 19 Mar 2015 14:06:16 +0800
Subject: [docs] A confusing detail in Documentation
Message-ID: <CABD6eKu90TEf6Ji1GhFsae-ykCty4AQ0FnfakrTgUBfFaMbWWA@mail.gmail.com>

  Hi, I am a new beginner learning python by the Documentation now. In the
Python2.7.9.Documentation topic 4.4 break and continue Statements, and else
Clauses o Loops, there have a example program show the else belongs to for
loop. I found in the first circle, the range(2,2) should be a empty list,
so the expression "for x in range(2,n)" should return x is null or empty. I
don't know why the next if condition run well and just return false. I
think there should report a exception. Hope someone can tell me the reason.
 Thanks a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150319/bc23c626/attachment.html>

From techtonik at gmail.com  Thu Mar 19 12:04:07 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 19 Mar 2015 14:04:07 +0300
Subject: [docs] Explanation of deque
Message-ID: <CAPkN8xLRzx8ESVmQEL2Z-xDyvUW_Ez0y8JEU4MYyLcxwsSEq-w@mail.gmail.com>

https://docs.python.org/2/library/collections.html#collections.deque

The documentation is detailed, descriptive, but.. it fails to answer
the main question - what is deque?

"Deques are a generalization of stacks and queues (the name is
pronounced ?deck? and is short for ?double-ended queue?). Deques
support thread-safe, memory efficient appends and pops from either
side of the deque with approximately the same O(1) performance in
either direction."

I must say that I came to the point where I don't get what that means.
Explaining the concept of double-ended queue or circular buffer with
words like "thread-safe" and "memory efficient" is not helpful.
-- 
anatoly t.

From report at bugs.python.org  Thu Mar 19 12:24:38 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Thu, 19 Mar 2015 11:24:38 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1426764277.98.0.587662255726.issue4395@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From consulting at heinrichhartmann.com  Thu Mar 19 12:15:48 2015
From: consulting at heinrichhartmann.com (Heinrich Hartmann)
Date: Thu, 19 Mar 2015 12:15:48 +0100
Subject: [docs] Typo in str.format() definition.
Message-ID: <550AAFE4.8010004@heinrichhartmann.com>

Hi there,

this is a rather pedantic bug report, but still here is it:

The file `https://docs.python.org/2/_sources/library/stdtypes.txt` reads:

```
.. method:: str.format(*args, **kwargs)

   Perform a string formatting operation.  The string on which this
method is
   called can contain literal text or replacement fields delimited by braces
   ``{}``.[...]
```

Should be:

```
[...] contain literal text __and__ replacement fields [...]
```

since the string can certainly contain both.

Best regards,
Heinrich





-- 
Dr. Heinrich Hartmann
Math & IT Consulting

Web:  HeinrichHartmann.com
Work: +49 1525 3638134
Post: Gutenbergstr. 7; D-56073 Koblenz

Please consider using secure Email communication:
* http://heinrichhartmann.com/2014/11/16/Secure-Email-Communication.html
* https://encrypt.to/consulting at heinrichhartmann.com


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

From heinrich at heinrichhartmann.com  Thu Mar 19 12:38:05 2015
From: heinrich at heinrichhartmann.com (Heinrich Hartmann)
Date: Thu, 19 Mar 2015 12:38:05 +0100
Subject: [docs] Quoting in Format Grammar
Message-ID: <550AB51D.4000101@heinrichhartmann.com>

Hi there,

in the str.format grammar you are very careful to get the quoting of
terminal symbols right, e.g. "!", ":" are all quoted.

However, in the format_spec grammar you are less careful with quoting
terminal symbols:

```
.. productionlist:: sf
   format_spec:
[[`fill`]`align`][`sign`][#][0][`width`][,][.`precision`][`type`]
```

IMHO symbols "#", "0", ",", "." should all be quoted.

Or am I missing something here?

Best regards,
Heinrich Hartmann


-- 
Dr. Heinrich Hartmann
Math & IT Consulting

Web:  HeinrichHartmann.com
Work: +49 1525 3638134
Post: Stefan-George Ring 41; D-81929 M?nchen

From report at bugs.python.org  Thu Mar 19 15:03:12 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 19 Mar 2015 14:03:12 +0000
Subject: [docs] [issue23698] Fix documentation for multiprocessing.Manager
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426773792.41.0.0655145281855.issue23698@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Is your patch uploaded anywhere ?

Anyway, before thinking whether this should be a patch or doc fix, one needs multiprocessing module author to possibly comment on the right behaviour expected here.

----------

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

From report at bugs.python.org  Thu Mar 19 15:04:46 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 19 Mar 2015 14:04:46 +0000
Subject: [docs] [issue23698] Fix inconsistencies in behaviour and document
	it	correctly for multiprocessing.Manager facade
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426773886.58.0.101847351934.issue23698@psf.upfronthosting.co.za>


Changes by Anand B Pillai <abpillai at gmail.com>:


----------
title: Fix documentation for multiprocessing.Manager -> Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade

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

From report at bugs.python.org  Thu Mar 19 15:09:54 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 19 Mar 2015 14:09:54 +0000
Subject: [docs] [issue23698] Fix inconsistencies in behaviour and document
	it	correctly for multiprocessing.Manager facade
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426774194.27.0.476552141007.issue23698@psf.upfronthosting.co.za>


Davin Potts added the comment:

No, it's premature to share the start of my patch.

Very much agreed on getting that input/insight -- sbt (multiprocessing module maintainer and original author) was added to the nosy list yesterday too.

----------

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

From report at bugs.python.org  Thu Mar 19 15:41:39 2015
From: report at bugs.python.org (=?utf-8?q?Tomi_Pievil=C3=A4inen?=)
Date: Thu, 19 Mar 2015 14:41:39 +0000
Subject: [docs] [issue23710] C API doc for PyObject_HEAD is outdated
Message-ID: <1426776099.01.0.644113037586.issue23710@psf.upfronthosting.co.za>


New submission from Tomi Pievil?inen:

https://docs.python.org/3/c-api/structures.html#c.PyObject_HEAD says that the macro should be used for creating new types and that it has ob_type. Unfortunately at some point (@61466 perhaps) that definition in object.h was changed. This affects other pages too (at least https://docs.python.org/3/extending/newtypes.html).

I encountered this while checking if a C extension (imposm.parser) could be trivially ported for Python 3. Unfortunately not. I suppose

  self->ob_type

should be replaced with

  Py_TYPE(self)

but that isn't really clear from the docs.

----------
assignee: docs at python
components: Documentation
messages: 238530
nosy: docs at python, tpievila
priority: normal
severity: normal
status: open
title: C API doc for PyObject_HEAD is outdated

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

From broadus.jones at gmail.com  Thu Mar 19 16:32:57 2015
From: broadus.jones at gmail.com (Broadus Jones)
Date: Thu, 19 Mar 2015 10:32:57 -0500
Subject: [docs] Explanation of deque
In-Reply-To: <CAPkN8xLRzx8ESVmQEL2Z-xDyvUW_Ez0y8JEU4MYyLcxwsSEq-w@mail.gmail.com>
References: <CAPkN8xLRzx8ESVmQEL2Z-xDyvUW_Ez0y8JEU4MYyLcxwsSEq-w@mail.gmail.com>
Message-ID: <CAAkhHk=3BHyhH3jaCuvnqyBdw4T_9rFBkGUx-9j1avdNmuX9vg@mail.gmail.com>

Hi. Anatoly,

A deque is a structure that only supports adding to the front of the "line"
or back of the "line".  While a queue is LILO (last in last out, or first
in, first out), a stack is LIFO (last in, first out) a deque allows pulling
from either end, but not the middle.  I have never used one, so i cannot
speak to the use cases.

Examples:A queue could be a line at a bus stop or in front of a bank
teller.  A stack would be a paper inbox on a desk or a gun clip.  A deque
could be a section of water pipe, or a train tunnel through a mountain (the
train could stop and back out).

--
Broadus

On Thu, Mar 19, 2015 at 6:04 AM, anatoly techtonik <techtonik at gmail.com>
wrote:

> https://docs.python.org/2/library/collections.html#collections.deque
>
> The documentation is detailed, descriptive, but.. it fails to answer
> the main question - what is deque?
>
> "Deques are a generalization of stacks and queues (the name is
> pronounced ?deck? and is short for ?double-ended queue?). Deques
> support thread-safe, memory efficient appends and pops from either
> side of the deque with approximately the same O(1) performance in
> either direction."
>
> I must say that I came to the point where I don't get what that means.
> Explaining the concept of double-ended queue or circular buffer with
> words like "thread-safe" and "memory efficient" is not helpful.
> --
> anatoly t.
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150319/e650eb79/attachment.html>

From techtonik at gmail.com  Thu Mar 19 16:58:50 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 19 Mar 2015 18:58:50 +0300
Subject: [docs] Explanation of deque
In-Reply-To: <CAAkhHk=3BHyhH3jaCuvnqyBdw4T_9rFBkGUx-9j1avdNmuX9vg@mail.gmail.com>
References: <CAPkN8xLRzx8ESVmQEL2Z-xDyvUW_Ez0y8JEU4MYyLcxwsSEq-w@mail.gmail.com>
 <CAAkhHk=3BHyhH3jaCuvnqyBdw4T_9rFBkGUx-9j1avdNmuX9vg@mail.gmail.com>
Message-ID: <CAPkN8xJx6D-kgMTa2Qcsyc54vqg155830DBQSb0wfePtshWvzg@mail.gmail.com>

Hi Broadus,

Interesting. I didn't pay attention that it doesn't support random
access. The documentation could be improved by separating the
description of data structure (a picture will be good) and its
implementation details.

On Thu, Mar 19, 2015 at 6:32 PM, Broadus Jones <broadus.jones at gmail.com> wrote:
> Hi. Anatoly,
>
> A deque is a structure that only supports adding to the front of the "line"
> or back of the "line".  While a queue is LILO (last in last out, or first
> in, first out), a stack is LIFO (last in, first out) a deque allows pulling
> from either end, but not the middle.  I have never used one, so i cannot
> speak to the use cases.
>
> Examples:A queue could be a line at a bus stop or in front of a bank teller.
> A stack would be a paper inbox on a desk or a gun clip.  A deque could be a
> section of water pipe, or a train tunnel through a mountain (the train could
> stop and back out).
>
> --
> Broadus
>
> On Thu, Mar 19, 2015 at 6:04 AM, anatoly techtonik <techtonik at gmail.com>
> wrote:
>>
>> https://docs.python.org/2/library/collections.html#collections.deque
>>
>> The documentation is detailed, descriptive, but.. it fails to answer
>> the main question - what is deque?
>>
>> "Deques are a generalization of stacks and queues (the name is
>> pronounced ?deck? and is short for ?double-ended queue?). Deques
>> support thread-safe, memory efficient appends and pops from either
>> side of the deque with approximately the same O(1) performance in
>> either direction."
>>
>> I must say that I came to the point where I don't get what that means.
>> Explaining the concept of double-ended queue or circular buffer with
>> words like "thread-safe" and "memory efficient" is not helpful.
>> --
>> anatoly t.
>> _______________________________________________
>> docs mailing list
>> docs at python.org
>> https://mail.python.org/mailman/listinfo/docs
>
>



-- 
anatoly t.

From report at bugs.python.org  Fri Mar 20 00:10:31 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Mar 2015 23:10:31 +0000
Subject: [docs] [issue16834] ioctl mutate_flag behavior in regard to the
	buffer size	limit
In-Reply-To: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>
Message-ID: <1426806631.88.0.688747278907.issue16834@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looking at the C code, if a writable buffer is passed, mutate_arg is false, and the buffer is longer than 1024 bytes, then a ValueError is raised:

>>> ioctl(0, 0, bytearray(2048), False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: ioctl string arg too long

So it seems the implementation does not match the documentation?s claim that ?the 1024 byte limit . . . is avoided?. IMO this is an implementation bug.

But instead of (or in addition to) fixing it, maybe we could consider removing ?mutate_flag? parameter altogether. It was originally added as a backwards compatibility helper for Issue 555817 in Python 2.3, and changed to True by default in Python 2.5.

----------
components: +Extension Modules
nosy: +vadmium
versions: +Python 3.4

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

From report at bugs.python.org  Fri Mar 20 03:25:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 02:25:05 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426818305.83.0.5527412246.issue22832@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From storchaka at gmail.com  Fri Mar 20 09:02:40 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 20 Mar 2015 08:02:40 -0000
Subject: [docs] Tweak parameter names for fcntl module (issue 22832)
Message-ID: <20150320080240.26159.18167@psf.upfronthosting.co.za>


https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c
File Modules/fcntlmodule.c (right):

https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c#newcode43
Modules/fcntlmodule.c:43: arg: object = NULL
On 2015/03/20 03:24:07, vadmium wrote:
> I?m not familiar with this Clinic stuff, but is there away to make the
default
> appear as arg=0 rather than arg=None?

Yes, it is possible and it would be good.

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

From vadmium+py at gmail.com  Fri Mar 20 03:24:07 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 20 Mar 2015 02:24:07 -0000
Subject: [docs] Tweak parameter names for fcntl module (issue 22832)
Message-ID: <20150320022407.26159.86102@psf.upfronthosting.co.za>


https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c
File Modules/fcntlmodule.c (right):

https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c#newcode43
Modules/fcntlmodule.c:43: arg: object = NULL
I?m not familiar with this Clinic stuff, but is there away to make the
default appear as arg=0 rather than arg=None?

https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c#newcode115
Modules/fcntlmodule.c:115: arg as ob_arg: object = NULL
Would be nice to change this to arg=0 by default too

https://bugs.python.org/review/22832/diff/14056/Modules/fcntlmodule.c#newcode332
Modules/fcntlmodule.c:332: start as startobj: object = NULL
Again the comment about len and start being documented as integers

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

From report at bugs.python.org  Fri Mar 20 12:20:10 2015
From: report at bugs.python.org (Alex Shkop)
Date: Fri, 20 Mar 2015 11:20:10 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426850409.62.0.331338938394.issue22832@psf.upfronthosting.co.za>


Alex Shkop added the comment:

Fixed default values for fcntl(), ioctl() and lockf()

----------
Added file: http://bugs.python.org/file38598/issue22832_v3.patch

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

From report at bugs.python.org  Fri Mar 20 13:26:25 2015
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Mar 2015 12:26:25 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426854385.11.0.557279714906.issue22832@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 20 16:07:23 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Mar 2015 15:07:23 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426864043.08.0.366181726349.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think that that patch that Victor committed is incorrect, and that Thomas's patch is closer to correct.  People *do* use linecache with files other than python source files, and as far as I can see we are not going to stop supporting that.  Given the original docs the intent clearly was that the interface be general, not python-file-specific.

----------
status: closed -> open

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

From report at bugs.python.org  Fri Mar 20 16:20:13 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Mar 2015 15:20:13 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <1426864813.63.0.468124360796.issue11726@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, on further investigation I guess it wasn't intended to be so general :)  But I still think we should make a nod to the reality that it can be used on other text files.  I'll re-close the issue but I may add a sentence to the docs.

----------
status: open -> closed

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

From report at bugs.python.org  Fri Mar 20 16:32:45 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 15:32:45 +0000
Subject: [docs] [issue11726] clarify that linecache only works on files that
	can be	decoded successfully
In-Reply-To: <1301566082.59.0.198488725536.issue11726@psf.upfronthosting.co.za>
Message-ID: <20150320153242.24254.20201@psf.io>


Roundup Robot added the comment:

New changeset ceb14ecc1942 by R David Murray in branch '3.4':
#11726: Make linecache docs reflect that all files are treated the same.
https://hg.python.org/cpython/rev/ceb14ecc1942

New changeset 1a5c72f9ff53 by R David Murray in branch 'default':
Merge: #11726: Make linecache docs reflect that all files are treated the same.
https://hg.python.org/cpython/rev/1a5c72f9ff53

----------

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

From report at bugs.python.org  Fri Mar 20 18:26:20 2015
From: report at bugs.python.org (Demian Brecht)
Date: Fri, 20 Mar 2015 17:26:20 +0000
Subject: [docs] [issue23662] Cookie.domain is undocumented
In-Reply-To: <1426345280.31.0.365548742215.issue23662@psf.upfronthosting.co.za>
Message-ID: <1426872380.73.0.0271445188244.issue23662@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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

From storchaka at gmail.com  Fri Mar 20 18:43:04 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 20 Mar 2015 17:43:04 -0000
Subject: [docs] Tweak parameter names for fcntl module (issue 22832)
Message-ID: <20150320174304.9161.58159@psf.upfronthosting.co.za>


https://bugs.python.org/review/22832/diff/14277/Doc/library/fcntl.rst
File Doc/library/fcntl.rst (right):

https://bugs.python.org/review/22832/diff/14277/Doc/library/fcntl.rst#newcode31
Doc/library/fcntl.rst:31: .. function:: fcntl(fd, cmd[, arg=0])
Brackets are not needed longer.

https://bugs.python.org/review/22832/diff/14277/Doc/library/fcntl.rst#newcode53
Doc/library/fcntl.rst:53: .. function:: ioctl(fd, request[, arg=0[,
mutate_flag=True]])
And here too.

https://bugs.python.org/review/22832/diff/14277/Doc/library/fcntl.rst#newcode108
Doc/library/fcntl.rst:108: .. function:: lockf(fd, cmd, [len=0,
[start=0, [whence=0]]])
And here too.

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

From report at bugs.python.org  Fri Mar 20 18:58:36 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 17:58:36 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426874316.81.0.593557752997.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Except brackets the patch LGTM.

----------

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

From report at bugs.python.org  Fri Mar 20 19:18:36 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Mar 2015 18:18:36 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <20150320181833.30720.5675@psf.io>


Roundup Robot added the comment:

New changeset a3c9c2c92b87 by Serhiy Storchaka in branch 'default':
Issue #22832: Tweaked parameter names for fcntl module to better match
https://hg.python.org/cpython/rev/a3c9c2c92b87

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

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

From report at bugs.python.org  Fri Mar 20 19:19:56 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 18:19:56 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426875595.98.0.697658299746.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks you for your patch Alex.

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

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

From storchaka at gmail.com  Fri Mar 20 20:26:49 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 20 Mar 2015 19:26:49 -0000
Subject: [docs] Python 3 crc32 documentation clarifications (issue 22341)
Message-ID: <20150320192649.9161.43429@psf.upfronthosting.co.za>


http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst
File Doc/library/binascii.rst (right):

http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst#newcode129
Doc/library/binascii.rst:129: crc = binascii.crc32(b"hello", 0)
Why 0 was added? I think it is better to left only one argument, for
demonstrating that the second argument is optional.

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

From report at bugs.python.org  Fri Mar 20 20:35:11 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 19:35:11 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426880111.04.0.811723600985.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

These notes was added by Gregory in r68535. Ask him if they still are needed.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Fri Mar 20 20:36:55 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Mar 2015 19:36:55 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426880215.12.0.986679006157.issue22341@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue4903.

----------

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

From report at bugs.python.org  Fri Mar 20 22:07:32 2015
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 20 Mar 2015 21:07:32 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426885652.75.0.483005832185.issue22341@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I do not object to the removal of the & 0xfffffff from the stdlib library code if these functions have actually been fixed to always return unsigned now.  (double check the behavior, and if good, just do it!)

But I think the docs should still mention that the & 0xffffffff is a good practice if code needs to be compatible with Python versions prior to X.Y (list the last release before the behavior was corrected).  Possibly within a .. versionchanged: section.

People often use the latest docs when writing code in any version of Python as we continually improve docs and are pretty good about noting old behaviors and when behaviors changed.

----------

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

From report at bugs.python.org  Fri Mar 20 22:44:00 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 Mar 2015 21:44:00 +0000
Subject: [docs] [issue23725] [PATCH] update tempfile docs to say that
	TemporaryFile	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426887840.37.0.17878263366.issue23725@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> patch review

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

From vadmium+py at gmail.com  Fri Mar 20 22:56:39 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 20 Mar 2015 21:56:39 -0000
Subject: [docs] Python 3 crc32 documentation clarifications (issue 22341)
Message-ID: <20150320215639.9161.93143@psf.upfronthosting.co.za>


http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst
File Doc/library/binascii.rst (right):

http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst#newcode129
Doc/library/binascii.rst:129: crc = binascii.crc32(b"hello", 0)
On 2015/03/20 20:26:49, storchaka wrote:
> Why 0 was added? I think it is better to left only one argument, for
> demonstrating that the second argument is optional.

The first print() in the example already illustrates that the initial
CRC argument is optional.

Looking at this with fresh eyes, I think I would actually like to make
the second part look like the following, which is more like how you do
iterative CRC calculation in the real world:

crc = 0
crc = binascii.crc32(b"hello", crc)
crc = binascii.crc32(b" world", crc)

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

From storchaka at gmail.com  Fri Mar 20 23:30:33 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 20 Mar 2015 22:30:33 -0000
Subject: [docs] Python 3 crc32 documentation clarifications (issue 22341)
Message-ID: <20150320223033.27858.95046@psf.upfronthosting.co.za>


http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst
File Doc/library/binascii.rst (right):

http://bugs.python.org/review/22341/diff/14133/Doc/library/binascii.rst#newcode129
Doc/library/binascii.rst:129: crc = binascii.crc32(b"hello", 0)
On 2015/03/20 22:56:39, vadmium wrote:
> On 2015/03/20 20:26:49, storchaka wrote:
> > Why 0 was added? I think it is better to left only one argument, for
> > demonstrating that the second argument is optional.
> 
> The first print() in the example already illustrates that the initial
CRC
> argument is optional.
> 
> Looking at this with fresh eyes, I think I would actually like to make
the
> second part look like the following, which is more like how you do
iterative CRC
> calculation in the real world:
> 
> crc = 0
> crc = binascii.crc32(b"hello", crc)
> crc = binascii.crc32(b" world", crc)

I think it only complicates the example. It creates an impression, that
you can omit the argument when calculate all checksum at a time, but
should specify it when calculate it incrementally.

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

From report at bugs.python.org  Fri Mar 20 23:52:10 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 22:52:10 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1426891930.16.0.787380379608.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Gregory, I think the three functions have been fixed since Python 3.0. It looks like you changed them in revisions 6a7fa8421902 (zlib module) and 132cf3a79126 (crc32 functions). Looking at the 3.0 branch, all three functions use PyLong_FromUnsignedLong(), but in the 2.7 branch, they use PyInt_FromLong(). This is tested in test_zlib.ChecksumTestCase.test_crc32_adler32_unsigned(). See also my changes to test_penguins() in the patch here for further testing. There is no explicit testing of binascii.crc32() unsignedness, but it is implicitly tested by test_same_as_binascii_crc32(), because the expected CRC is beyond the positive 32 bit signed limit.

I am happy to put back the suggestion of masking for backwards compatibility if you really think it is necessary. But since it only involves Python < 3.0 compatibility, I thought it would be okay to remove it; see my original post. The documentation is often pretty good about noting when Python 3 behaviours changed, but you usually have to look elsewhere to see the differences from Python 2.

----------

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

From report at bugs.python.org  Sat Mar 21 00:30:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 Mar 2015 23:30:39 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426894239.4.0.40636070893.issue22832@psf.upfronthosting.co.za>


Martin Panter added the comment:

I object to dropping the brackets from the function signatures. Now it gives the impression that the functions accept keyword arguments:

ioctl(fd, request, arg=0, mutate_flag=True)

but:

>>> ioctl(0, 0, bytearray(), mutate_flag=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: ioctl() takes no keyword arguments

There is already a little bit of precedent for this, e.g. the built-in eval() function, but I would prefer using square brackets, or some other non-Python syntax indicator.

----------

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

From report at bugs.python.org  Sat Mar 21 01:36:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 Mar 2015 00:36:48 +0000
Subject: [docs] [issue23698] Multiprocessing.Manager: fix behavior and
	doc	inconsistencies
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1426898208.56.0.589046126248.issue23698@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Fix inconsistencies in behaviour and document it correctly for multiprocessing.Manager facade -> Multiprocessing.Manager: fix behavior and doc inconsistencies

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

From report at bugs.python.org  Sat Mar 21 02:59:13 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 01:59:13 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426903153.35.0.668129262124.issue22832@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> I object to dropping the brackets from the function signatures. Now it gives the impression that the functions accept keyword arguments:

See issue 21488 for a similar confusion.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sat Mar 21 03:34:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 Mar 2015 02:34:03 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426905243.0.0.886283825287.issue23725@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Zbyszek. For future reference, please send patches from the Mercurial repository. It will make the patch review process easier. See also devguide.

+:func:`TemporaryDirectory`, :func:`SpooledTemporaryFile`, which can be

Both TemporaryDirectory and SpooledTemporaryFile are actually a class. See https://hg.python.org/cpython/file/3.4/Lib/tempfile.py#l510

+   :ref:`context-managers`).  On completion of the context or

:ref:`context-managers` link is unnecessary in my opinion. It would be better to link https://docs.python.org/3/library/tempfile.html#examples

(Please update tempfile.TemporaryDirectory docs too.)

----------
nosy: +berker.peksag
title: [PATCH] update tempfile docs to say that TemporaryFile is secure -> update tempfile docs to say that TemporaryFile is secure
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Sat Mar 21 03:50:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Mar 2015 02:50:50 +0000
Subject: [docs] [issue23674] super() documentation isn't very clear
In-Reply-To: <1426448451.56.0.492486239807.issue23674@psf.upfronthosting.co.za>
Message-ID: <1426906250.99.0.90910815288.issue23674@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Sat Mar 21 05:19:28 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Mar 2015 04:19:28 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1426911568.27.0.23561627944.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

It would also be helpful to have a patch with minimum changes (that is, do not reflow the lines).

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

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

From report at bugs.python.org  Sat Mar 21 05:44:38 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 04:44:38 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1426913078.69.0.929774675979.issue22832@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is worth a discussion on Python-Dev.
http://comments.gmane.org/gmane.comp.python.devel/152025

----------

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

From dawncold at me.com  Sat Mar 21 05:46:43 2015
From: dawncold at me.com (tianzhen)
Date: Sat, 21 Mar 2015 12:46:43 +0800
Subject: [docs] an old bug on python2.7 docs page sidebar
Message-ID: <550CF7B3.7080100@me.com>

https://bugs.python.org/issue3154

The input box is too wide now.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-03-21 12:41:39.png
Type: image/png
Size: 158168 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150321/85900c91/attachment-0001.png>

From storchaka at gmail.com  Sat Mar 21 09:12:16 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sat, 21 Mar 2015 08:12:16 -0000
Subject: [docs] Document that PyUnicode_AsUTF8() returns a null-terminated
 string (issue 23088)
Message-ID: <20150321081216.9161.95269@psf.upfronthosting.co.za>

I can't make a decision about the patch for this issue, you should ask
other developer for the review. I can only make formal notes and ask
questions.


https://bugs.python.org/review/23088/diff/14165/Doc/c-api/bytes.rst
File Doc/c-api/bytes.rst (right):

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/bytes.rst#newcode158
Doc/c-api/bytes.rst:158: If *length* is *NULL*, the string may not
contain embedded null characters;
I think it is better to avoid words "string" (except may be a
combination "byte string") and "character" when say about the content of
a bytes object.

This documentation is mainly a copy of the documentation of Python 2
strings, and contains outdated and incorrect wording. It would be good
to fix this, but may be in other issue.

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/unicode.rst#newcode230
Doc/c-api/unicode.rst:230: The returned buffer is always terminated with
an extra null character,
May be the wording used in PyUnicode_AsUnicode,
PyUnicode_AsUnicodeAndSize, and PyUnicode_AsWideCharString looks
cleaner?

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/unicode.rst#newcode233
Doc/c-api/unicode.rst:233: The *o* argument has to be a Unicode object
(not checked).
argument or parameter? What is correct?

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

From report at bugs.python.org  Sat Mar 21 10:11:29 2015
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 21 Mar 2015 09:11:29 +0000
Subject: [docs] [issue23730] Document return value for ZipFile.extract()
Message-ID: <1426929089.45.0.62065226759.issue23730@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The documentation for zipfile.ZipFile.extract() doesn't mention at all that it returns the local path created, either for the directory that the member represents, or the new file created from the zipped data.

*Returns the full local path created (a directory or new file)* or similar.

----------
assignee: docs at python
components: Documentation
messages: 238778
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Document return value for ZipFile.extract()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Mar 21 10:37:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 09:37:04 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
	arguments	disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1426930624.82.0.77255289404.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current behavior is more complicated.

>>> OSError(1, 2, 3, 4).args
(1, 2)
>>> OSError(1, 2, 3, 4, 5).args
(1, 2)
>>> OSError(1, 2, 3, 4, 5, 6).args
(1, 2, 3, 4, 5, 6)

If I remember correctly:

1 -- errno
2 -- strerror
3 -- filename
4 -- winerror (?)
5 -- filename2

Isn't it documented anywhere?

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

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

From report at bugs.python.org  Sat Mar 21 14:58:04 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 13:58:04 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1426946284.34.0.111611054016.issue23360@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar 21 16:53:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 15:53:45 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1426953225.8.0.253757472352.issue23360@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation looks contradictory. "The *data* argument must be", but "The *data* argument may also be". "must be a bytes object", but "If *data* is a buffer".

Why not write just "The data argument must be a bytes-like object, an iterable of bytes-like objects, or None"? It doesn't depend if url is a string or a Request object.

AFAIK the data argument of Request can be an iterable of bytes-like objects in additional to a bytes-like object or None.

The note about the application/x-www-form-urlencoded format is applied not only to a bytes object, but to an iterable of bytes-like objects too. I.e. to any acceptable value except None.

----------

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

From report at bugs.python.org  Sat Mar 21 18:10:00 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Mar 2015 17:10:00 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1426957800.19.0.0547602974297.issue17232@psf.upfronthosting.co.za>


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


----------
stage: patch review -> needs patch
versions: +Python 3.5 -Python 3.3

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

From storchaka at gmail.com  Sat Mar 21 19:22:00 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sat, 21 Mar 2015 18:22:00 -0000
Subject: [docs] Typo in class io.BufferedIOBase docs (issue 22671)
Message-ID: <20150321182200.9161.10150@psf.upfronthosting.co.za>


https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py
File Lib/test/test_io.py (right):

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode608
Lib/test/test_io.py:608: # Exercise the default RawIOBase.read() and
readall() implementations
May be create separate test for readall?

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode636
Lib/test/test_io.py:636: dict(method="readinto", avail=10, request=5,
result=5),
This is too verbose. Tuples would look cleaner. And testing code with
test["..."] looks untidy.

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode644
Lib/test/test_io.py:644: )
Does it make sense to add tests for request=0 or -1?

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode654
Lib/test/test_io.py:654: self.assertSequenceEqual(buffer[:size],
range(size))
Fill buffer before reading and test that buffer[size:] is not changed.

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

From vadmium+py at gmail.com  Sun Mar 22 00:09:01 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sat, 21 Mar 2015 23:09:01 -0000
Subject: [docs] Typo in class io.BufferedIOBase docs (issue 22671)
Message-ID: <20150321230901.27858.45932@psf.upfronthosting.co.za>


https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py
File Lib/test/test_io.py (right):

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode608
Lib/test/test_io.py:608: # Exercise the default RawIOBase.read() and
readall() implementations
On 2015/03/21 19:22:00, storchaka wrote:
> May be create separate test for readall?

Okay

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode636
Lib/test/test_io.py:636: dict(method="readinto", avail=10, request=5,
result=5),
On 2015/03/21 19:22:00, storchaka wrote:
> This is too verbose. Tuples would look cleaner. And testing code with
> test["..."] looks untidy.

Perhaps a matrix of tuples with a comment at the top saying what the
columns are would work.

https://bugs.python.org/review/22671/diff/13484/Lib/test/test_io.py#newcode644
Lib/test/test_io.py:644: )
On 2015/03/21 19:22:00, storchaka wrote:
> Does it make sense to add tests for request=0 or -1?

request=0: yes; request=-1: no, because you can?t have a bytearray -1
bytes long :)

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

From report at bugs.python.org  Sun Mar 22 02:54:08 2015
From: report at bugs.python.org (Mike Short)
Date: Sun, 22 Mar 2015 01:54:08 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1426989248.62.0.349455343329.issue22933@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38627/shutil_2.7.patch

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

From report at bugs.python.org  Sun Mar 22 02:54:26 2015
From: report at bugs.python.org (Mike Short)
Date: Sun, 22 Mar 2015 01:54:26 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <1426989266.97.0.211943844215.issue22933@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


Added file: http://bugs.python.org/file38628/shutil_latest.patch

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

From vadmium+py at gmail.com  Sun Mar 22 05:50:13 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 22 Mar 2015 04:50:13 -0000
Subject: [docs] Document that PyUnicode_AsUTF8() returns a
 null-terminated string (issue 23088)
Message-ID: <20150322045013.9161.42736@psf.upfronthosting.co.za>

Reviewers: storchaka,


https://bugs.python.org/review/23088/diff/14165/Doc/c-api/bytes.rst
File Doc/c-api/bytes.rst (right):

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/bytes.rst#newcode158
Doc/c-api/bytes.rst:158: If *length* is *NULL*, the string may not
contain embedded null characters;
On 2015/03/21 09:12:16, storchaka wrote:
> I think it is better to avoid words "string" (except may be a
combination "byte
> string") and "character" when say about the content of a bytes object.

Agreed.

> This documentation is mainly a copy of the documentation of Python 2
strings,
> and contains outdated and incorrect wording. It would be good to fix
this, but
> may be in other issue.

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

https://bugs.python.org/review/23088/diff/14165/Doc/c-api/unicode.rst#newcode233
Doc/c-api/unicode.rst:233: The *o* argument has to be a Unicode object
(not checked).
On 2015/03/21 09:12:16, storchaka wrote:
> argument or parameter? What is correct?

I _think_ ?argument? is slightly more correct, unless this is
inconsistent with the surrounding documentation. It is subtle but I
would tend to think of ?the o parameter? as meaning the variable name or
a generic placeholder that holds the argument.



Please review this at https://bugs.python.org/review/23088/

Affected files:
  Doc/c-api/bytearray.rst
  Doc/c-api/bytes.rst
  Doc/c-api/unicode.rst


# HG changeset patch
# Parent 3de678cd184d943f53e9bc0e74feefaa07cc7f55
Document that the UTF-8 representation is null-terminated

diff -r 3de678cd184d Doc/c-api/bytearray.rst
--- a/Doc/c-api/bytearray.rst	Thu Dec 18 23:47:55 2014 +0100
+++ b/Doc/c-api/bytearray.rst	Thu Mar 12 00:39:46 2015 +0000
@@ -64,7 +64,8 @@
 .. c:function:: char* PyByteArray_AsString(PyObject *bytearray)
 
    Return the contents of *bytearray* as a char array after checking for a
-   *NULL* pointer.
+   *NULL* pointer.  The returned array always has an extra
+   null byte appended, even when the array already contains null bytes.
 
 
 .. c:function:: int PyByteArray_Resize(PyObject *bytearray, Py_ssize_t len)
diff -r 3de678cd184d Doc/c-api/bytes.rst
--- a/Doc/c-api/bytes.rst	Thu Dec 18 23:47:55 2014 +0100
+++ b/Doc/c-api/bytes.rst	Thu Mar 12 00:39:46 2015 +0000
@@ -136,8 +136,9 @@
 
 .. c:function:: char* PyBytes_AsString(PyObject *o)
 
-   Return a NUL-terminated representation of the contents of *o*.  The pointer
-   refers to the internal buffer of *o*, not a copy.  The data must not be
+   Return the contents of *o*.  The pointer refers to the internal
+   buffer of *o*, which is always terminated with an extra null byte,
+   even when the string already contains null bytes.  The data must not be
    modified in any way, unless the string was just created using
    ``PyBytes_FromStringAndSize(NULL, size)``. It must not be deallocated.  If
    *o* is not a string object at all, :c:func:`PyBytes_AsString` returns *NULL*
@@ -151,10 +152,10 @@
 
 .. c:function:: int PyBytes_AsStringAndSize(PyObject *obj, char **buffer, Py_ssize_t *length)
 
-   Return a NUL-terminated representation of the contents of the object *obj*
+   Return a null-terminated representation of the contents of the object *obj*
    through the output variables *buffer* and *length*.
 
-   If *length* is *NULL*, the resulting buffer may not contain NUL characters;
+   If *length* is *NULL*, the string may not contain embedded null characters;
    if it does, the function returns ``-1`` and a :exc:`TypeError` is raised.
 
    The buffer refers to an internal string buffer of *obj*, not a copy. The data
diff -r 3de678cd184d Doc/c-api/unicode.rst
--- a/Doc/c-api/unicode.rst	Thu Dec 18 23:47:55 2014 +0100
+++ b/Doc/c-api/unicode.rst	Thu Mar 12 00:39:46 2015 +0000
@@ -226,9 +226,11 @@
 .. c:function:: Py_UNICODE* PyUnicode_AS_UNICODE(PyObject *o)
                 const char* PyUnicode_AS_DATA(PyObject *o)
 
-   Return a pointer to a :c:type:`Py_UNICODE` representation of the object.  The
-   ``AS_DATA`` form casts the pointer to :c:type:`const char *`.  *o* has to be
-   a Unicode object (not checked).
+   Return a pointer to a :c:type:`Py_UNICODE` representation of the object.
+   The returned buffer is always terminated with an extra null character,
+   even when the string already contains null characters.
+   The ``AS_DATA`` form casts the pointer to :c:type:`const char *`.
+   The *o* argument has to be a Unicode object (not checked).
 
    .. versionchanged:: 3.3
       This macro is now inefficient -- because in many cases the
@@ -650,7 +652,9 @@
 
    Copy the string *u* into a new UCS4 buffer that is allocated using
    :c:func:`PyMem_Malloc`.  If this fails, *NULL* is returned with a
-   :exc:`MemoryError` set.
+   :exc:`MemoryError` set.  The returned buffer always has an extra
+   null character appended, even if the string already contains
+   null characters.
 
    .. versionadded:: 3.3
 
@@ -689,7 +693,8 @@
    Return a read-only pointer to the Unicode object's internal
    :c:type:`Py_UNICODE` buffer, or *NULL* on error. This will create the
    :c:type:`Py_UNICODE*` representation of the object if it is not yet
-   available. Note that the resulting :c:type:`Py_UNICODE` string may contain
+   available. The buffer is always terminated with an extra null character.
+   Note that the resulting :c:type:`Py_UNICODE` string may also contain
    embedded null characters, which would cause the string to be truncated when
    used in most C functions.
 
@@ -708,7 +713,8 @@
 .. c:function:: Py_UNICODE* PyUnicode_AsUnicodeAndSize(PyObject *unicode, Py_ssize_t *size)
 
    Like :c:func:`PyUnicode_AsUnicode`, but also saves the :c:func:`Py_UNICODE`
-   array length in *size*. Note that the resulting :c:type:`Py_UNICODE*` string
+   array length (excluding the extra null terminator) in *size*.
+   Note that the resulting :c:type:`Py_UNICODE*` string
    may contain embedded null characters, which would cause the string to be
    truncated when used in most C functions.
 
@@ -717,7 +723,7 @@
 
 .. c:function:: Py_UNICODE* PyUnicode_AsUnicodeCopy(PyObject *unicode)
 
-   Create a copy of a Unicode string ending with a nul character. Return *NULL*
+   Create a copy of a Unicode string ending with a null character. Return *NULL*
    and raise a :exc:`MemoryError` exception on memory allocation failure,
    otherwise return a new allocated buffer (use :c:func:`PyMem_Free` to free
    the buffer). Note that the resulting :c:type:`Py_UNICODE*` string may
@@ -902,10 +908,10 @@
 
    Copy the Unicode object contents into the :c:type:`wchar_t` buffer *w*.  At most
    *size* :c:type:`wchar_t` characters are copied (excluding a possibly trailing
-   0-termination character).  Return the number of :c:type:`wchar_t` characters
+   null termination character).  Return the number of :c:type:`wchar_t` characters
    copied or -1 in case of an error.  Note that the resulting :c:type:`wchar_t*`
-   string may or may not be 0-terminated.  It is the responsibility of the caller
-   to make sure that the :c:type:`wchar_t*` string is 0-terminated in case this is
+   string may or may not be null-terminated.  It is the responsibility of the caller
+   to make sure that the :c:type:`wchar_t*` string is null-terminated in case this is
    required by the application. Also, note that the :c:type:`wchar_t*` string
    might contain null characters, which would cause the string to be truncated
    when used with most C functions.
@@ -914,9 +920,9 @@
 .. c:function:: wchar_t* PyUnicode_AsWideCharString(PyObject *unicode, Py_ssize_t *size)
 
    Convert the Unicode object to a wide character string. The output string
-   always ends with a nul character. If *size* is not *NULL*, write the number
-   of wide characters (excluding the trailing 0-termination character) into
-   *\*size*.
+   always ends with a null character. If *size* is not *NULL*, write the number
+   of wide characters (excluding the trailing null termination character)
+   into *\*size*.
 
    Returns a buffer allocated by :c:func:`PyMem_Alloc` (use
    :c:func:`PyMem_Free` to free it) on success. On error, returns *NULL*,
@@ -1045,9 +1051,11 @@
 
 .. c:function:: char* PyUnicode_AsUTF8AndSize(PyObject *unicode, Py_ssize_t *size)
 
-   Return a pointer to the default encoding (UTF-8) of the Unicode object, and
-   store the size of the encoded representation (in bytes) in *size*.  *size*
-   can be *NULL*, in this case no size will be stored.
+   Return a pointer to the UTF-8 encoding of the Unicode object, and
+   store the size of the encoded representation (in bytes) in *size*.  The
+   *size* argument can be *NULL*; in this case no size will be stored.  The
+   returned buffer always has an extra null byte appended (not included in
+   *size*), even if the string already contains null characters.
 
    In the case of an error, *NULL* is returned with an exception set and no
    *size* is stored.



From report at bugs.python.org  Sun Mar 22 11:31:02 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:31:02 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
Message-ID: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>


New submission from Martin Panter:

This patch adds the PEP 457 positional-only slash ?/? indicator to some function signatures in the documentation. I only looked at the the os, builtin, binascii, zlib and fcntl modules, and their functions where the documentation incorrectly suggests that they accept keyword arguments. For example, I changed

eval(expression, globals=None, locals=None)

to

eval(expression, globals=None, locals=None, /)

References:

* Issue 22832: ?fcntl? module changed to look like accepting keyword arguments
* Ongoing discussion: <https://mail.python.org/pipermail/python-dev/2015-March/138847.html>

There are many more instances where square brackets are used, or the arguments are mandatory. See the PEP for examples, but I do not think it is so important to ?fix? them.

I also fixed parameter name mismatches that I discovered for a quite a few functions that do take keyword arguments.

One more thing I noticed, that I do not know how to fix, is the Argument Clinic signatures list invalid default values for zlib.compressobj(zdict=None) and os.utime(ns=None):

>>> zlib.compressobj(zdict=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'NoneType' does not support the buffer interface
>>> os.utime("dummy", ns=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: utime: 'ns' must be a tuple of two ints

----------
assignee: docs at python
components: Documentation
files: pos-defaults.patch
keywords: patch
messages: 238890
nosy: docs at python, serhiy.storchaka, vadmium
priority: normal
severity: normal
status: open
title: Clarify documentation of positional-only default values
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file38632/pos-defaults.patch

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

From report at bugs.python.org  Sun Mar 22 11:33:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:33:19 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
In-Reply-To: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>
Message-ID: <1427020399.06.0.460021505801.issue22832@psf.upfronthosting.co.za>


Martin Panter added the comment:

I opened Issue 23738 about my problem with the new signature, so it does not get forgotten.

----------

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

From report at bugs.python.org  Sun Mar 22 11:53:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 10:53:19 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427021599.41.0.593872683033.issue23738@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hmm it seems my change for os.utimes() in Modules/posixmodule.c does not automatically get reflected in the doc string. Is there some script I can run to regenerate it, or do I have to do it manually?

----------

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

From report at bugs.python.org  Sun Mar 22 12:22:47 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Mar 2015 11:22:47 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427023367.16.0.324338810748.issue23738@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

./python Tools/clinic/clinic.py --make

or just

    make clinic

----------

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

From report at bugs.python.org  Sun Mar 22 12:25:09 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Mar 2015 11:25:09 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427023509.36.0.0373706796784.issue23738@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sun Mar 22 15:15:19 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Mar 2015 14:15:19 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
In-Reply-To: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>
Message-ID: <20150322141516.30033.28779@psf.io>


Roundup Robot added the comment:

New changeset e5de4ee6aa4a by Benjamin Peterson in branch '3.4':
clarify behavior of shutil.move when destination exists (closes #22933)
https://hg.python.org/cpython/rev/e5de4ee6aa4a

New changeset 4502e598fe26 by Benjamin Peterson in branch '2.7':
clarify behavior of shutil.move when destination exists (closes #22933)
https://hg.python.org/cpython/rev/4502e598fe26

New changeset a9f36ec5d944 by Benjamin Peterson in branch 'default':
merge 3.4 (#22933)
https://hg.python.org/cpython/rev/a9f36ec5d944

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

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

From report at bugs.python.org  Sun Mar 22 15:42:05 2015
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 22 Mar 2015 14:42:05 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427035325.89.0.648809862423.issue23738@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Mar 22 17:00:10 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Sun, 22 Mar 2015 16:00:10 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427040010.4.0.766661430231.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

v2:
- remove reflows
- update TemporaryDirectory description too
- do not call things which are not functions "functions"
- with O_TMPFILE the file is not unlinked, also update TemporaryFile description for that
- link to Examples

----------
Added file: http://bugs.python.org/file38634/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

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

From report at bugs.python.org  Sun Mar 22 18:18:33 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 22 Mar 2015 17:18:33 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427044713.16.0.140315944043.issue23738@psf.upfronthosting.co.za>


R. David Murray added the comment:

Personally I would rather stick to the [] syntax in the docs, with the default values mentioned in the text.

----------
nosy: +georg.brandl, r.david.murray

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

From report at bugs.python.org  Mon Mar 23 00:57:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Mar 2015 23:57:49 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427068669.08.0.403531625492.issue23725@psf.upfronthosting.co.za>


Martin Panter added the comment:

[Padding]

Please start sentences with capital letters, specifically ?mkstemp() and mkdtemp() are lower-level functions . . .?.

The new sentence at the top about context managers seems out-of-place. Perhaps something like ?They can also be used as context managers, which triggers the cleanup on exit.?

The new paragraph about cleanup of TemporaryFile is good, but I think it now makes the last sentence of that entry redundant: ?. . . can be used in a ?with? statement . . .?

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar 23 01:16:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 00:16:14 +0000
Subject: [docs] [issue22163] max_wbits set incorrectly to -zlib.MAX_WBITS in
	tarfile, shouldn't be negative
In-Reply-To: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>
Message-ID: <1427069773.96.0.926141486024.issue22163@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the patch is wrong and the zlib documentation needs fixing instead. See <https://docs.python.org/dev/library/zlib.html#zlib.decompress> for a possible explanation of the negative sign, although it would make more sense for compress() which would actually create a ?gzip? header.

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

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

From report at bugs.python.org  Mon Mar 23 02:55:45 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Mar 2015 01:55:45 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427075745.81.0.62504669648.issue23725@psf.upfronthosting.co.za>


R. David Murray added the comment:

If the first word is a function name that does not start with a capital, the sentence can't start with a capital.  Sometimes it is worthwhile to reword the sentence so you can start it with a capitalizable word, but sometimes it isn't.  (I haven't reviewed the patch, just putting in my two cents on this particular topic ;)

----------

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

From report at bugs.python.org  Mon Mar 23 03:16:14 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Mon, 23 Mar 2015 02:16:14 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427076973.99.0.268609280426.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

> Please start sentences with capital letters, specifically ?mkstemp() and mkdtemp() are lower-level functions . . .?.

This would make the sentence more convoluted... I think that with markup it is pretty clear that this is a function name and the lowercase letter it not misleading.

> The new sentence at the top about context managers seems out-of-place. Perhaps something like ?They can also be used as context managers, which triggers the cleanup on exit.?

The two sentences are merged now.

> The new paragraph about cleanup of TemporaryFile is good, but I think it now makes the last sentence of that entry redundant: ?. . . can be used in a ?with? statement . . .?

Yes, removed.

v3:
- remove sentence ?. . . can be used in a ?with? statement . . .?
- merge two senteces in first paragraph

----------
Added file: http://bugs.python.org/file38640/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

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

From report at bugs.python.org  Mon Mar 23 03:52:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 02:52:45 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427079165.52.0.141060671086.issue23725@psf.upfronthosting.co.za>


Martin Panter added the comment:

The current proposed text would be rendered something like this:

'''
TemporaryFile, NamedTemporaryFile, TemporaryDirectory, SpooledTemporaryFile are high-level interfaces which provide automatic cleanup and can be used as context managers. mkstemp() and mkdtemp() are lower-level functions which require manual cleanup.
'''

My opinion is it is very often worthwhile rewording the sentence. It is awkward to read at the moment, especially if you are trying to skim over it without reading the whole paragraph. Unlike in Python, in English there?s always more than one way to do it. Perhaps you could consider this version instead:

'''
The TemporaryFile, NamedTemporaryFile, TemporaryDirectory, [and] SpooledTemporaryFile classes are high-level interfaces which provide automatic cleanup and can be used as context managers. The mkstemp() and mkdtemp() functions are lower-level, and require manual cleanup.
'''

Only about three more words, and not particularly convoluted. But if you disagree, I can live with it, since there are plenty more examples of this in the Python documentation and elsewhere :)

Other than that, I think the patch is good.

----------

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

From report at bugs.python.org  Mon Mar 23 04:46:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 03:46:45 +0000
Subject: [docs] [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1427082405.21.0.84420392813.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to <http://zlib.net/manual.html#Advanced>, the deflateInit2(windowBits) parameter can be:

* +8 to +15 to include a ?zlib? header and trailer
* ?8 to ?15 to write a raw Deflate stream with no header nor trailer
* 16 + (8 to 15) to include a basic ?gzip? header and trailer

The inflateInit2(windowBits) parameter can also be set to the above values to specify what header and trailer to expect, and it can also be set to 0 to read the window size from the ?zlib? header itself.

Assuming that the Python module passes ?wbits? straight through to the actual ?zlib? module, I think these points could be clarified in the Python documentation.

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar 23 04:53:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 Mar 2015 03:53:50 +0000
Subject: [docs] [issue22163] max_wbits set incorrectly to -zlib.MAX_WBITS in
	tarfile, shouldn't be negative
In-Reply-To: <1407409352.24.0.421737248606.issue22163@psf.upfronthosting.co.za>
Message-ID: <1427082830.23.0.0499532663777.issue22163@psf.upfronthosting.co.za>


Martin Panter added the comment:

Eduardo?s patch causes many tests to fail. Abbreviated test output:

$ ./python -bWall -m test -v test_tarfile
======================================================================
ERROR: test_compare_members (test.test_tarfile.GzipStreamReadTest)
ERROR: test_empty_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_fileobj_regular_file (test.test_tarfile.GzipStreamReadTest)
ERROR: test_ignore_zeros (test.test_tarfile.GzipStreamReadTest)
ERROR: test_non_existent_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_null_tarfile (test.test_tarfile.GzipStreamReadTest)
ERROR: test_provoke_stream_error (test.test_tarfile.GzipStreamReadTest)
ERROR: test_read_through (test.test_tarfile.GzipStreamReadTest)
----------------------------------------------------------------------
tarfile.ReadError: invalid compressed data

======================================================================
ERROR: test_stream_padding (test.test_tarfile.GzipStreamWriteTest)
----------------------------------------------------------------------
zlib.error: Error -3 while decompressing data: invalid stored block lengths

======================================================================
FAIL: test_detect_file (test.test_tarfile.GzipDetectReadTest)
FAIL: test_detect_fileobj (test.test_tarfile.GzipDetectReadTest)
AssertionError

----------------------------------------------------------------------
Ran 387 tests in 14.216s

FAILED (failures=2, errors=9, skipped=8)

There is already Issue 5784 open about clarifying the ?wbits? parameter, so I think we can close this as a duplicate.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> raw deflate format and zlib module

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

From report at bugs.python.org  Mon Mar 23 06:03:31 2015
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Mon, 23 Mar 2015 05:03:31 +0000
Subject: [docs] [issue23725] update tempfile docs to say that TemporaryFile
	is secure
In-Reply-To: <1426878892.3.0.689958999466.issue23725@psf.upfronthosting.co.za>
Message-ID: <1427087011.23.0.969326229601.issue23725@psf.upfronthosting.co.za>


Zbyszek J?drzejewski-Szmek added the comment:

Actually they are not classes, so the proposed wording cannot be used. But indeed it sounds better with the "and".

v4:
- one more "and"

----------
Added file: http://bugs.python.org/file38643/0001-docs-update-description-of-TemporaryFile-and-tempfil.patch

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

From report at bugs.python.org  Mon Mar 23 10:33:45 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:33:45 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427103225.25.0.99046412753.issue23747@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why is this function even exposed on Linux?

It is a deliberate design choice of the platform module. mac_ver(), win32_ver() and linux_distribution() are available on all platforms.

mac_ver() says "entries which cannot be determined are set to ''. All tuple entries are strings."

Maybe it should be better explained in the doc.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, haypo
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 23 10:36:00 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Mon, 23 Mar 2015 09:36:00 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427103360.89.0.175964494725.issue23747@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

Similarly for mac_ver, java_ver etc.

>>> platform.mac_ver()
('', ('', '', ''), '')
>>> platform.java_ver()
('', '', ('', '', ''), ('', '', ''))

Maybe it is okay if these functions are present, but can't they raise an exception or return None instead of returning these funny tuples when empty strings ?

I am surprised at Python's inconsistency in such things. For example,

>>> import winsound
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named 'winsound'

Works as expected on Linux. In the same vein, these functions shouldn't be present as well IMHO - I agree this is debatable of course.

----------

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

From report at bugs.python.org  Mon Mar 23 10:50:54 2015
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 Mar 2015 09:50:54 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103360.89.0.175964494725.issue23747@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ6PMwDMvRuGaNEPEdeT6xuYK+sPbD-AYZ72NNebc9WSA@mail.gmail.com>


STINNER Victor added the comment:

> Maybe it is okay if these functions are present, but can't they raise an exception or return None instead of returning these funny tuples when empty strings ?

It would break the backward compatibility. Again, it's a delibarate choice.

----------

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

From report at bugs.python.org  Mon Mar 23 15:08:37 2015
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 23 Mar 2015 14:08:37 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427119717.77.0.540042045684.issue23738@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I say switch to what Argument Clinic uses, else there's a disconnect syntactically between help() and the docs.

----------

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

From report at bugs.python.org  Mon Mar 23 15:28:11 2015
From: report at bugs.python.org (Andreas Sommer)
Date: Mon, 23 Mar 2015 14:28:11 +0000
Subject: [docs] [issue23750] Clarify difference between
	os.system/subprocess.call in	section "Replacing os.system()"
Message-ID: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>


New submission from Andreas Sommer:

Reading over the section "Replacing os.system()" (https://docs.python.org/2/library/subprocess.html#replacing-os-system), one might assume that the return value of os.system and subprocess.call are equivalent.

    status = os.system("mycmd" + " myarg")
    # becomes
    status = subprocess.call("mycmd" + " myarg", shell=True)

However, they are not. Example:

    import sys
    import os
    import subprocess

    print subprocess.call("false")
    print os.system("false")

gives 1 and 256, respectively. Maybe this could be rephrased for clarity, or a hint added.

----------
assignee: docs at python
components: Documentation
messages: 239028
nosy: Andreas Sommer, docs at python
priority: normal
severity: normal
status: open
title: Clarify difference between os.system/subprocess.call in section "Replacing os.system()"
type: enhancement

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

From report at bugs.python.org  Tue Mar 24 01:33:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 00:33:35 +0000
Subject: [docs] [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1427157215.25.0.644726430231.issue22942@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 9232, about adding support for trailing commas in all cases of function calls and definitions.

----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Mar 24 02:52:35 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 01:52:35 +0000
Subject: [docs] [issue23750] Clarify difference between
	os.system/subprocess.call in	section "Replacing os.system()"
In-Reply-To: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>
Message-ID: <1427161955.09.0.563696841636.issue23750@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another difference is that (at least POSIX) system() blocks SIGINT and SIGQUIT while the child is running. Compare:

$ python3 -c 'print("Waiting"); import os; print("Returned", os.system("sleep 3 && exit 3"))'
Sleeping
Returned 768
$ python3 -c 'print("Sleeping"); import os; print("Returned", os.system("sleep 3 && exit 3"))'
Waiting
^CReturned 2  # Hit Ctrl+C during sleep command
$ python3 -c 'print("Sleeping"); import subprocess; print("Returned", subprocess.call("sleep 3 && exit 3", shell=True))'
Sleeping
Returned 3
$ python3 -c 'print("Sleeping"); import subprocess; print("Returned", subprocess.call("sleep 3 && exit 3", shell=True))'
Sleeping
^CTraceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.4/subprocess.py", line 539, in call
    return p.wait(timeout=timeout)
  File "/usr/lib/python3.4/subprocess.py", line 1566, in wait
    (pid, sts) = self._try_wait(0)
  File "/usr/lib/python3.4/subprocess.py", line 1514, in _try_wait
    (pid, sts) = _eintr_retry_call(os.waitpid, self.pid, wait_flags)
  File "/usr/lib/python3.4/subprocess.py", line 491, in _eintr_retry_call
    return func(*args)
KeyboardInterrupt
[Exit 1]

----------
nosy: +vadmium

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

From vaishali.m.ahire at gmail.com  Mon Mar 23 10:24:55 2015
From: vaishali.m.ahire at gmail.com (Vaishali Ahire)
Date: Mon, 23 Mar 2015 14:54:55 +0530
Subject: [docs] updatation is needed
Message-ID: <CAOQv-R3baED+6erz4=9xTurrsaF1NFqgEp_AwtsgE68a4fey=Q@mail.gmail.com>

in documentation page of python 3.0 and current documentation  of
python tutorial there is missing break statement in  break and
continue statements example.
for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print(n, 'equals', x, '*', n//x)
...             break
...     else:
...         # loop fell through without finding a factor
...         print(n, 'is a prime number')

here extra break statement is required at the end of else loop.

From report at bugs.python.org  Tue Mar 24 09:25:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 08:25:17 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
Message-ID: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>


New submission from Martin Panter:

There are moves at documenting and implementing support for ?bytes-like? objects in more APIs, such as the ?io? module (Issue 20699), http.client (Issue 23740). The glossary definition is currently ?An object that supports the Buffer Protocol, like bytes, bytearray or memoryview.? This was originally added for Issue 16518. However after reading Issue 23688, I realized that it should probably not mean absolutely _any_ object supporting the buffer protocol. For instance:

>>> reverse_view = memoryview(b"123")[::-1]
>>> stdout.buffer.write(reverse_view)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BufferError: memoryview: underlying buffer is not C-contiguous

I think the definition should at least be tightened to only objects with a contiguous buffer, and ?contiguous? should be defined (probably in the linked C API page or the memoryview.contiguous flag definition, not the glossary). So far, my understanding is these are contiguous:

* A zero-dimensional object, such as a ctypes object
* An multi-dimensional array with items stored contiguously in order of increasing indexes. I.e. a_2,2 is stored somewhere after both a_1,2 and a_2,1, and all the strides are positive.

and these are not contiguous:

* memoryview(contiguous)[::2], because there are memory gaps between the items
* memoryview(contiguous)[::-1], despite there being no gaps nor overlapping items
* Views that set the ?suboffsets? field (i.e. include pointers to further memory)
* Views where different array items overlap each other (e.g. 0 in view.strides)

Perhaps the bytes-like definition should tightened further, to match the above error message, to only ?C-contiguous? buffers. I understand that C-contiguous means the strides tuple has to be in non-strict decreasing order, e.g. for 2 ? 1 ? 3 arrays, strides == (3, 3, 1) is C-contiguous, but strides == (1, 3, 3) is not. This also needs documenting.

I?m not so sure about these, but the definition could be tightened even further:

* Require memoryview(x).cast("B") to be supported. Otherwise, native Python code would have to use workarounds like struct.pack_into() to write to the ?bytes-like? object. See Issue 15944.
* Require len(view) == view.nbytes. This would help in some cases avoid the bug that I have seen of code naively calling len(data), but the downside is ctypes objects would no longer be considered bytes-like objects.

----------
assignee: docs at python
components: Documentation
messages: 239097
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Tighten definition of bytes-like objects

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

From tgmiller5 at hotmail.com  Tue Mar 24 09:29:53 2015
From: tgmiller5 at hotmail.com (Tammy Miller)
Date: Tue, 24 Mar 2015 04:29:53 -0400
Subject: [docs] Docs Python mailing list
Message-ID: <COL125-W36F57A9124AB9780D522D9FA0A0@phx.gbl>

I subscribe to the mailing list a couple of days ago and I have not receive any daily digest from docs python. 

Thank you, 
Tammy 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150324/701d8c9a/attachment-0001.html>

From report at bugs.python.org  Tue Mar 24 09:53:56 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 08:53:56 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427187236.71.0.332453262588.issue23756@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Tue Mar 24 10:10:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Mar 2015 09:10:41 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1427188241.59.0.835014367081.issue19023@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review

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

From report at bugs.python.org  Tue Mar 24 10:20:16 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Mar 2015 09:20:16 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427188816.9.0.00381696535261.issue23756@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Totally agree. Current definition is too wide. Actually in different places the term "bytes-like object" can imply different requirements.

* Supports buffer protocol. list isn't.

* Contiguous. memoryview()[::2] isn't.

* len() returns bytes size. array('I') isn't.

* Supported indexing (and slicing) of bytes. array('I') isn't.

* Indexing returns integers in the range 0-255. array('b') isn't.

* Supports concatenation. memoryview isn't.

* Supports common bytes and bytearray methods, such as find() or lower().

* A subclass of (bytes, bytearray).

* A subclass of bytes.

* A bytes itself.

----------
nosy: +r.david.murray, serhiy.storchaka
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar 24 10:44:55 2015
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Tue, 24 Mar 2015 09:44:55 +0000
Subject: [docs] [issue23758] Improve documenation about num_params in
	sqlite3	create_function and create_aggregate
Message-ID: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>


New submission from C?dric Krier:

num_params must have the value -1 for any number of arguments see https://www.sqlite.org/c3ref/create_function.html

----------
assignee: docs at python
components: Documentation
files: sqlite3_doc.patch
keywords: patch
messages: 239104
nosy: ced, docs at python
priority: normal
severity: normal
status: open
title: Improve documenation about num_params in sqlite3 create_function and create_aggregate
type: enhancement
Added file: http://bugs.python.org/file38664/sqlite3_doc.patch

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

From report at bugs.python.org  Tue Mar 24 11:52:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 10:52:52 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <20150324105248.63570.70295@psf.io>


Roundup Robot added the comment:

New changeset 4a2a5fddbab3 by Ezio Melotti in branch '2.7':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/4a2a5fddbab3

New changeset 010e33b37feb by Ezio Melotti in branch '3.4':
#11468: improve unittest basic example.  Initial patch by Florian Preinstorfer.
https://hg.python.org/cpython/rev/010e33b37feb

New changeset d6791e4026f1 by Ezio Melotti in branch 'default':
#11468: merge with 3.4.
https://hg.python.org/cpython/rev/d6791e4026f1

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

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

From report at bugs.python.org  Tue Mar 24 11:55:55 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 10:55:55 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1427194555.4.0.672720674377.issue11468@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tweaked the wording a bit, added a link to the section about setUp/tearDown, and applied it on all the 3 branches.
Thanks for the patch Florian!

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

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

From report at bugs.python.org  Tue Mar 24 12:45:31 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Mar 2015 11:45:31 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <20150324114528.7247.33192@psf.io>


Roundup Robot added the comment:

New changeset 971d299d2cf3 by Ezio Melotti in branch '2.7':
#23512: list non-essential built-in functions after the table.  Patch by Carlo Beccarini.
https://hg.python.org/cpython/rev/971d299d2cf3

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

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

From report at bugs.python.org  Tue Mar 24 12:47:23 2015
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 24 Mar 2015 11:47:23 +0000
Subject: [docs] [issue23512] The list of built-in functions is not
	alphabetical on	https://docs.python.org/2/library/functions.html
In-Reply-To: <1424791511.8.0.507561074794.issue23512@psf.upfronthosting.co.za>
Message-ID: <1427197643.73.0.647003668383.issue23512@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Tue Mar 24 15:18:06 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:18:06 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427206686.43.0.709973842478.issue23747@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is a deliberate choice because (I'm guessing) the designer thought it would make it easier to write cross platform scripts.  In any case, as Haypo said, it is what it is (and it *is* consistent with itself).

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

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

From report at bugs.python.org  Tue Mar 24 15:26:24 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:26:24 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427207184.34.0.771170865569.issue23747@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is a deliberate choice because the functions accept default values to be returned if the actual values cannot be determined, and because it is easier therefore to write cross-platform scripts if the functions do *not* raise an error when called on the "wrong" platform.  There are other functions in the platform module to use to determine which platform you are on.

Agreed that the fact that they work is currently documented only by implication for those familiar with our doc style (that is, there are no "avaiability" tags, implying they are available on all platforms).  This should be corrected, probably in an introductory paragraph (which will be overlooked by most people reading the docs :)

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

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

From report at bugs.python.org  Tue Mar 24 15:26:34 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:26:34 +0000
Subject: [docs] [issue23747] platform module exposes win32_ver function on
	posix	systems
In-Reply-To: <1427103016.81.0.503768282249.issue23747@psf.upfronthosting.co.za>
Message-ID: <1427207194.33.0.065891116364.issue23747@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg239124

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

From report at bugs.python.org  Tue Mar 24 15:28:05 2015
From: report at bugs.python.org (=?utf-8?q?Jo=C3=ABl_Schaerer?=)
Date: Tue, 24 Mar 2015 14:28:05 +0000
Subject: [docs] [issue23762] python.org page on new-style classes should be
	updated
Message-ID: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>


New submission from Jo?l Schaerer:

This page (found it via a search engine):

https://www.python.org/doc/newstyle/

is supposed to give the status of "New-style classes". However this information is no longer relevant for Python 3, and my needlessly scare newcomers. I believe it should be either deleted or updated to mention that python3 users don't need to care about this anymore.

----------
assignee: docs at python
components: Documentation
messages: 239127
nosy: docs at python, joelthelion
priority: normal
severity: normal
status: open
title: python.org page on new-style classes should be updated
type: enhancement

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

From report at bugs.python.org  Tue Mar 24 15:35:29 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 14:35:29 +0000
Subject: [docs] [issue23738] Clarify documentation of positional-only
	default values
In-Reply-To: <1427020261.31.0.215855760889.issue23738@psf.upfronthosting.co.za>
Message-ID: <1427207729.17.0.330686167741.issue23738@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's a good point.

----------

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

From report at bugs.python.org  Tue Mar 24 16:00:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Mar 2015 15:00:54 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1427209254.92.0.310026079165.issue23756@psf.upfronthosting.co.za>


R. David Murray added the comment:

This not dissimilar to the problem we have with "file like object" or "file object".  The requirements on them are not consistent.  I'm not sure what the solution is in either case, but for file like objects we have decided to ignore the issue, I think.  (ie: what exactly a file like object needs to support in order to work with a give API depends on that API, and we just live with that).

----------

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

From report at bugs.python.org  Wed Mar 25 14:49:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 13:49:51 +0000
Subject: [docs] [issue23743] Python crashes upon exit if importing g++
	compiled mod	after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427291391.12.0.186112548341.issue23743@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, clearly you are the interested party that solved it :)  Thanks.

Unfortunately I don't know that we have a place where this could be documented, since currently mingw isn't a fully supported platform.  Perhaps in the distutils docs somewhere?

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

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

From report at bugs.python.org  Wed Mar 25 16:22:15 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 15:22:15 +0000
Subject: [docs] [issue23778] Add a visual distinction to multiline
	versionchanged	blocks
Message-ID: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>


New submission from Demian Brecht:

This came up during #2211, where a multiline versionchanged entry was suggested. Currently, there is no visual distinction between any but the first line of the description and the rest of the body of the docs. The attached patch adds a consistent level of indentation (30px) to all but the first child. This change makes it much more obvious where the versionchanged block ends and the rest of the docs continue.

----------
assignee: docs at python
components: Documentation
files: versionchanged_indent.patch
keywords: patch
messages: 239261
nosy: demian.brecht, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Add a visual distinction to multiline versionchanged blocks
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file38689/versionchanged_indent.patch

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

From report at bugs.python.org  Wed Mar 25 16:34:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 15:34:27 +0000
Subject: [docs] [issue23778] Add a visual distinction to multiline
	versionchanged	blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427297667.48.0.164338217819.issue23778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh, you clearly know more about docutils/css than I do.

I don't think we want multiple blank delimited paragraphs under a versionchanged directive, though, from a style point of view.  A compact unordered list would be best.

----------
nosy: +georg.brandl, r.david.murray

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

From report at bugs.python.org  Wed Mar 25 16:53:07 2015
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 Mar 2015 15:53:07 +0000
Subject: [docs] [issue23743] Python crashes upon exit if importing g++
	compiled mod	after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427298786.99.0.241317905648.issue23743@psf.upfronthosting.co.za>


Steve Dower added the comment:

I think these days as soon as a repro includes "import distutils" or "import setuptools" the docs go straight to http://pypa.io :)

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Wed Mar 25 17:27:33 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 16:27:33 +0000
Subject: [docs] [issue23778] Add a visual distinction to multiline
	versionchanged	blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427300853.78.0.308229059806.issue23778@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I noted in #2211 that nested lists are supported by Sphinx, so that solves that specific issue. Perhaps it /may/ still be useful to have this though in order to support multiple paragraphs for more detailed change descriptions when needed? That said, I'm not sure that's something that's necessarily even wanted as such messages are intended to be terse.

----------

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

From report at bugs.python.org  Wed Mar 25 17:30:12 2015
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Mar 2015 16:30:12 +0000
Subject: [docs] [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427301012.13.0.360161668441.issue23487@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar 25 17:42:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 Mar 2015 16:42:01 +0000
Subject: [docs] [issue23778] Add a visual distinction to multiline
	versionchanged	blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427301721.4.0.108650111597.issue23778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, exactly, they are supposed to be terse.  So I think we should reject this.

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

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

From report at bugs.python.org  Wed Mar 25 17:48:06 2015
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 25 Mar 2015 16:48:06 +0000
Subject: [docs] [issue23778] Add a visual distinction to multiline
	versionchanged	blocks
In-Reply-To: <1427296935.3.0.719629949286.issue23778@psf.upfronthosting.co.za>
Message-ID: <1427302086.25.0.322771668829.issue23778@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Sounds good to me.

----------

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

From report at bugs.python.org  Wed Mar 25 17:53:44 2015
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Mar 2015 16:53:44 +0000
Subject: [docs] [issue23487] argparse: add_subparsers 'action' broken
In-Reply-To: <1424417043.22.0.71313795028.issue23487@psf.upfronthosting.co.za>
Message-ID: <1427302424.38.0.707435715743.issue23487@psf.upfronthosting.co.za>


paul j3 added the comment:

As to the nature of the error when 'add_subparsers' is given an 'action' parameter:

'add_subparsers' does several things to 'kwargs' before it passes them to the relevant Action class.

     def add_subparsers(self, **kwargs):
        # adds 'parser_class'
        # removes 'title', 'description' (used in an argument group)
        # add 'prog'
        parsers_class = self._pop_action_class(kwargs, 'parsers')
        action = parsers_class(option_strings=[], **kwargs)

What I wrote earlier about using the registry is partly wrong.  The Action class is determined by either the 'action' parameter or the registry entry.

     In [17]: p._pop_action_class({}, 'parsers')
     Out[17]: argparse._SubParsersAction

     In [18]: p._pop_action_class({'action':'test'}, 'parsers')
     Out[18]: 'test'

So the 'action' parameter works - if you specify a compatible Action class.

    sp=p.add_subparsers(dest='cmd',action=argparse._SubParsersAction)

Such a class must have the same __init__ signature, otherwise you'll get errors such the OP's.

It might be worth rewriting the documentation line so this is clearer.  Otherwise I recommend closing this issue.






     action = parsers_class(option_strings=[], **kwargs)

----------

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

From report at bugs.python.org  Thu Mar 26 02:05:34 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 01:05:34 +0000
Subject: [docs] [issue23764] Reference inspect.Signature.bind from
	functools.wraps	documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427331934.56.0.414849367769.issue23764@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, unfortunately, on closer inspection, even partial itself ends up suffering from the same problem as the current inspect.wraps - validation ultimately happens at the point of calling the original wrapper function, so if you don't actually call it, you won't get any argument validation.

You can use https://docs.python.org/3/library/inspect.html#inspect.Signature.bind to force early validation without actually calling the underlying callable, but that's always going to be substantially slower than "just try it and see if it works". functools is also further down in the stdlib dependency hierarchy than the inspect module so it isn't possible to offer that behaviour without creating a circular dependency.

What would be possible is to point out explicitly that "wraps" only updates introspection metadata, and if you're after eager argument validation (e.g. before queuing a command for delayed execution), then you likely want inspect.Signature.bind.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
title: Accept a separate "call_target" parameter to functools.partial -> Reference inspect.Signature.bind from functools.wraps documentation
versions: +Python 3.4

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

From report at bugs.python.org  Thu Mar 26 02:13:02 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Thu, 26 Mar 2015 01:13:02 +0000
Subject: [docs] [issue23764] Reference inspect.Signature.bind from
	functools.wraps	documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427332382.1.0.661900163292.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

Sounds good! I think the docs on functools.wraps already list precisely which data is updated, but maybe mentioning explicitly that it can not affect the argspec could indeed make it clearer.
Either way, thank you for your help!

----------
components: +Library (Lib) -Documentation
versions:  -Python 3.4

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

From report at bugs.python.org  Thu Mar 26 03:06:26 2015
From: report at bugs.python.org (productivememberofsociety666)
Date: Thu, 26 Mar 2015 02:06:26 +0000
Subject: [docs] [issue23764] Reference inspect.Signature.bind from
	functools.wraps	documentation
In-Reply-To: <1427220873.41.0.520106438504.issue23764@psf.upfronthosting.co.za>
Message-ID: <1427335586.57.0.70625901922.issue23764@psf.upfronthosting.co.za>


productivememberofsociety666 added the comment:

Sorry, did not mean to change the Components and Versions thingies...

----------
components: +Documentation -Library (Lib)
versions: +Python 3.4

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

From report at bugs.python.org  Thu Mar 26 03:19:18 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Mar 2015 02:19:18 +0000
Subject: [docs] [issue23743] Python crashes upon exit if importing g++
	compiled mod	after importing gcc compiled mod
In-Reply-To: <1427087434.95.0.234111642557.issue23743@psf.upfronthosting.co.za>
Message-ID: <1427336358.47.0.890858742797.issue23743@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

pypa.io hosts the internal dev docs for PyPA, I believe you meant packaging.python.org, and that would indeed be the right home.

However, this kind of C/C++ linker related problem is way too advanced for the current state of the binary extension docs which basically say "C/C++ is hard relative to Python, let someone else deal with creating your extension modules for you": https://packaging.python.org/en/latest/extensions.html

For the scientific stack in particular we go even further and say to get someone else to build and link the extension modules for you: https://packaging.python.org/en/latest/science.html

Folks encountering the kind of problem described in this issue is thus mostly useful as a data point in *why* we give those instructions: because DIY cross-platform C/C++ development is a teeming morass of "fun" interoperability bugs like this one just waiting to be discovered :)

----------

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

From report at bugs.python.org  Thu Mar 26 16:32:40 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:32:40 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427383960.43.0.100922646469.issue23484@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attaching patches for 3.5/default, 3.4, and 2.7 which update the documentation on multiprocessing.Lock, RLock, Semaphore, and BoundedSemaphore to describe their actual implemented behavior, replacing the existing, misleading claim that they are clones of threading.Lock, etc., respectively.

Specific changes:
* Lock and RLock now have their acquire and release methods drawn out so as to best explain the significant behavioral differences (versus threading) in return values, potential exceptions being raised, and passing arguments.
* Semaphore and BoundedSemaphore are not as drawn out because their behaviors are indeed the same in every regard except for the difference in block-vs-blocking (and in the case of 2.7, timeout is novel in multiprocessing and doesn't appear until 3.2 in threading).
* In 3.4 and 3.5, the inaccurate note block at the end of the synchronization section no longer misrepresents the treatment of the timeout argument in threading analogs.

It is worth noting that in 3.x, the behavior around the timeout argument in multiprocessing.{Lock,RLock,Semaphore,BoundedSemaphore} already matches that of threading.Semaphore and BoundedSemaphore.  The threading module appears inconsistent in its use of the timeout argument when comparing Semaphore/BoundedSemaphore with Lock/RLock.  It would be interesting to investigate whether in 3.x this inconsistency within threading could be brought in line with the rest of multiprocessing.

In issue21342 the notion of unifying the implementations of these synchronization primitives across threading and multiprocessing is suggested.  If that is pursued, it would reasonably be attempted on default/3.5 and not backported to 2.7 (nor probably 3.4).  Thus this patch to update the documentation is still highly valuable for 2.7 and 3.4 and 3.5 (at least until such time as a unification effort might be undertaken in the case of 3.5).

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file38702/issue_23484_doc_locks_py35_and_py34.patch

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

From report at bugs.python.org  Thu Mar 26 16:33:31 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:33:31 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427384011.19.0.0377930218502.issue23484@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


Added file: http://bugs.python.org/file38703/issue_23484_doc_locks_py27.patch

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

From report at bugs.python.org  Thu Mar 26 16:37:48 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:37:48 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427384268.38.0.122505807019.issue23484@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


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

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

From report at bugs.python.org  Thu Mar 26 16:44:18 2015
From: report at bugs.python.org (Davin Potts)
Date: Thu, 26 Mar 2015 15:44:18 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
	of Pool	example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1427384658.69.0.437763492846.issue18620@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


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

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

From report at bugs.python.org  Fri Mar 27 02:10:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 Mar 2015 01:10:36 +0000
Subject: [docs] [issue13322] buffered read() and write() does not
	raise	BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1427418636.24.0.0703339568531.issue13322@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 1191964, discussing inconsistencies and how to differentiate the four non-blocking special results in a new API:

* read signals permanent EOF
* read signals no data temporarily available
* write signals a permanently broken pipe or connection
* write signals no buffer space temporarily available

----------

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

From report at bugs.python.org  Fri Mar 27 12:24:07 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Fri, 27 Mar 2015 11:24:07 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
Message-ID: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>


New submission from Valentine Sinitsyn:

sum() function doctstring describes expected arguments as follows (Python 2.7.6):

sum(...)
    sum(sequence[, start]) -> value
...

This implies sum() should accept str, unicode, list, tuple, bytearray, buffer, and xrange. However, you clearly can't use this function to sum strings (which is also mentioned in the docstring):

>>> sum('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I'd suggest to describe first argument as iterable, which is actually what sum() expects there.

----------
assignee: docs at python
components: Documentation
messages: 239388
nosy: docs at python, vsinitsyn
priority: normal
severity: normal
status: open
title: sum() function docstring lists arguments incorrectly
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar 27 15:53:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 27 Mar 2015 14:53:25 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427468005.39.0.347624565078.issue23787@psf.upfronthosting.co.za>


R. David Murray added the comment:

In python3 the docstring does say iterable.  It wouldn't be a bad thing to change it in 2.7, but it is not much of a priority.  iterable vs sequence makes no difference to the str question: a string is an iterable.  The docstring explicitly says strings are excepted, as you mentioned, so there's nothing to do about that.

I note that python3 also does not support iterables of byte-like objects.  I'm not sure if this would actually be helpful to add to the docstring, though, since sum(b'abc') works and a docstring is probably not an appropriate place to go into detail as to why.

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

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

From report at bugs.python.org  Fri Mar 27 17:02:47 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Fri, 27 Mar 2015 16:02:47 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427472167.1.0.13664600274.issue23787@psf.upfronthosting.co.za>


Valentine Sinitsyn added the comment:

Yes, strings aren't an issue. I only used them as an example.

I came across this issue during code review, discussing if it is okay to pass generator expression to sum() (like sum(x*2 for x in xrange(5)) or is it better to convert it to the list first (sum([x*2 for x in xrange(5)])). Both variants work so docstring is sort of specification here.

Surely, it's not a high priority task anyways.

----------

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

From report at bugs.python.org  Fri Mar 27 20:36:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Mar 2015 19:36:03 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427484963.96.0.933076009844.issue23787@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file38716/sum_doc.diff

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

From report at bugs.python.org  Fri Mar 27 22:28:39 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:28:39 +0000
Subject: [docs] [issue23762] python.org page on new-style classes should be
	updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427491719.16.0.629687113983.issue23762@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"Unfortunately, new-style classes have not yet been integrated into Python's standard documention" is not even true for 2.7.  I think the page should be deleted.  Any of the reverences that are both useful and not in the docs could be added to the docs.

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

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

From report at bugs.python.org  Fri Mar 27 22:30:28 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Mar 2015 21:30:28 +0000
Subject: [docs] [issue23762] python.org page on new-style classes should be
	updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427491828.62.0.227154075295.issue23762@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This tracker can only handle changes to the docs.  Deleting a web page would be an issue for the python.org tracker on github.  But we should not make a request there until the docs have been checked and we are sure it should go.

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

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

From report at bugs.python.org  Fri Mar 27 23:33:17 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 27 Mar 2015 22:33:17 +0000
Subject: [docs] [issue23762] python.org page on new-style classes should be
	updated
In-Reply-To: <1427207285.84.0.436806674049.issue23762@psf.upfronthosting.co.za>
Message-ID: <1427495597.09.0.29130286319.issue23762@psf.upfronthosting.co.za>


Berker Peksag added the comment:

IMHO, it can stay as a historical document. We just need to add a note to point out the correct documentation. So I think this can be handled on GitHub. I can't update the content since I don't have edit rights, so please open a new issue at https://github.com/python/pythondotorg/issues

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sat Mar 28 23:58:28 2015
From: report at bugs.python.org (Wolfgang Maier)
Date: Sat, 28 Mar 2015 22:58:28 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427583508.68.0.191032939185.issue23787@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

>This implies sum() should accept str, unicode, list, tuple, bytearray, buffer, and xrange.

and in fact it *does* accept all these as input. It just refuses to add the elements of the sequence if these elements are of certain types. Of course, the elements of a string are strings themselves so this does not work:

>>> sum('abc', '')
Traceback (most recent call last):
  File "<pyshell#88>", line 1, in <module>
    sum('abc', '')
TypeError: sum() can't sum strings [use ''.join(seq) instead]


compare with a bytes sequence in Python3, where the elements are ints:

>>> sum(b'abc', 0)
294


but strings are also perfectly accepatble as input if you do not try to add their str elements, but something else:

>>> class X (int):
    def __add__(self, other):
        return X(ord(other) + self)

>>> sum('abc', X(0))
294

=> the docs are right and there is no issue here.

----------
nosy: +wolma

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

From report at bugs.python.org  Sun Mar 29 08:01:41 2015
From: report at bugs.python.org (Daniel Shahaf)
Date: Sun, 29 Mar 2015 06:01:41 +0000
Subject: [docs] [issue23802] patch: __deepcopy__ memo dict argument usage
Message-ID: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>


New submission from Daniel Shahaf:

In the 'copy' module documentation, it wasn't fully clear to me how __deepcopy__ implementations should treat the memo dict argument.  The attached patch clarifies that __deepcopy__ implementations should treat the memo dict argument as an opaque type.

----------
assignee: docs at python
components: Documentation
files: opaque.diff
keywords: patch
messages: 239473
nosy: danielsh, docs at python
priority: normal
severity: normal
status: open
title: patch: __deepcopy__ memo dict argument usage
type: enhancement
Added file: http://bugs.python.org/file38723/opaque.diff

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

From report at bugs.python.org  Sun Mar 29 15:12:16 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 29 Mar 2015 13:12:16 +0000
Subject: [docs] [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427634736.09.0.125953992387.issue23746@psf.upfronthosting.co.za>


Changes by Anand B Pillai <anandpillai at letterboxes.org>:


----------
nosy: +docs at python

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

From report at bugs.python.org  Sun Mar 29 15:12:28 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Sun, 29 Mar 2015 13:12:28 +0000
Subject: [docs] [issue23746] sysconfg.is_python_build() is buggy
In-Reply-To: <1427101982.73.0.589713060591.issue23746@psf.upfronthosting.co.za>
Message-ID: <1427634748.42.0.373364287839.issue23746@psf.upfronthosting.co.za>


Changes by Anand B Pillai <anandpillai at letterboxes.org>:


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

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

From report at bugs.python.org  Sun Mar 29 16:11:59 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:11:59 +0000
Subject: [docs] [issue23802] patch: __deepcopy__ memo dict argument usage
In-Reply-To: <1427608901.41.0.0640545279461.issue23802@psf.upfronthosting.co.za>
Message-ID: <1427638319.16.0.0396928271637.issue23802@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would rather say simply "The memo dictionary should be treated as an opaque object".  On the other hand, I doubt we will ever change the structure of the memo dict, because I'm sure that somewhere out there there is code that is *not* treating it as opaque :)

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

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

From report at bugs.python.org  Sun Mar 29 16:56:26 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 Mar 2015 14:56:26 +0000
Subject: [docs] [issue23806] documentation for no_proxy is missing from the
	python3	urllib documentation
Message-ID: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>


New submission from R. David Murray:

no_proxy (and what notation it supports) is mentioned in the python2 urllib docs, but not in the python3 docs.

----------
assignee: docs at python
components: Documentation
messages: 239493
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: documentation for no_proxy is missing from the python3 urllib documentation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Mar 29 21:07:21 2015
From: report at bugs.python.org (Valentine Sinitsyn)
Date: Sun, 29 Mar 2015 19:07:21 +0000
Subject: [docs] [issue23787] sum() function docstring lists arguments
	incorrectly
In-Reply-To: <1427455446.97.0.658394608092.issue23787@psf.upfronthosting.co.za>
Message-ID: <1427656041.75.0.988039989874.issue23787@psf.upfronthosting.co.za>


Valentine Sinitsyn added the comment:

Seems like mentioning string was really a bad idea. They were only used as (poor) example, forget them if they are confusing in any way.

In my understanding, any sequence in Python is iterable, bit not all iterables are sequences (correct me if I'm wrong). Then, the purpose of my suggestion is to explicitly say that sum() accepts iterables. In its current form, it seems like it doesn't, that's why I considered the docstring [subtly] wrong.

----------

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

From report at bugs.python.org  Sun Mar 29 23:46:12 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Mar 2015 21:46:12 +0000
Subject: [docs] [issue23806] documentation for no_proxy is missing from the
	python3	urllib documentation
In-Reply-To: <1427640986.55.0.996928918568.issue23806@psf.upfronthosting.co.za>
Message-ID: <1427665572.87.0.704447374363.issue23806@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Mar 30 02:34:50 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 00:34:50 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1427675690.14.0.685924665135.issue19023@psf.upfronthosting.co.za>


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


----------
components:  -Tests
nosy: +berker.peksag
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 30 02:36:46 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Mar 2015 00:36:46 +0000
Subject: [docs] [issue23758] Improve documenation about num_params in
	sqlite3	create_function and create_aggregate
In-Reply-To: <1427190295.06.0.0583773654336.issue23758@psf.upfronthosting.co.za>
Message-ID: <1427675806.85.0.484689055888.issue23758@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag, ghaering
stage:  -> patch review
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Mar 30 14:19:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 12:19:39 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1427717978.96.0.337179229961.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v3:

* Reverted to original crc32(b"hello") example call with the implicit initial CRC
* Added ?Changed in version 3.0? notices, restoring a brief version of the suggestion to use the bit mask, along with an explanation.

Python 2 compatibility information is generally unprecedented in the Python 3 documentation though, but hopefully this version should make more sense to people not already familiar with the Python 2 odd behaviour.

----------
Added file: http://bugs.python.org/file38737/crc-sign.v3.patch

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

From report at bugs.python.org  Mon Mar 30 14:40:55 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 Mar 2015 12:40:55 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
In-Reply-To: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>
Message-ID: <1427719255.26.0.913794545085.issue22341@psf.upfronthosting.co.za>


Martin Panter added the comment:

V4 fixes a merge conflict with recent gzip changes.

----------
Added file: http://bugs.python.org/file38739/crc-sign.v4.patch

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

From report at bugs.python.org  Mon Mar 30 20:40:47 2015
From: report at bugs.python.org (Karl O. Pinc)
Date: Mon, 30 Mar 2015 18:40:47 +0000
Subject: [docs] [issue23814] argparse: Parser level defaults do not always
	override	argument level defaults
Message-ID: <1427740847.33.0.866518706982.issue23814@psf.upfronthosting.co.za>


New submission from Karl O. Pinc:

In the argparse library parser library, contrary to the documentation,
parser-level defaults do not always override argument-level defaults.

https://docs.python.org/3.5/library/argparse.html#argparse.ArgumentParser.set_defaults

says "Note that parser-level defaults always override argument-level defaults:"

(And so does the python 3.3 docs.)

The docs then provide this example:

  >>> parser = argparse.ArgumentParser()
  >>> parser.add_argument('--foo', default='bar')
  >>> parser.set_defaults(foo='spam')
  >>> parser.parse_args([])
  Namespace(foo='spam')

But it is only true that parser-level defaults override argument-level
defaults when they are established after the argument is added.

The output below shows an argument level default overrideing
a parser level default.

$ python3
Python 3.3.2 (default, Jun  4 2014, 11:36:37) 
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.set_defaults(foo='spam')
>>> parser.add_argument('--foo', default='bar')
_StoreAction(option_strings=['--foo'], dest='foo', nargs=None, const=None, default='bar', type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args([])
Namespace(foo='bar')

It seems that whichever default is set last is the one which is used.
Or perhaps there are not argument level defaults and parser level
defaults, there are just defaults, period.  (It might, possibly,
be nice if there _were_ both argument and parser level defaults
and parser level defaults had priority.  Then this would not be
a documentation bug.)

----------
assignee: docs at python
components: Documentation
messages: 239632
nosy: docs at python, kop
priority: normal
severity: normal
status: open
title: argparse: Parser level defaults do not always override argument level defaults
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 31 03:44:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 01:44:24 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1427766264.09.0.118856032465.issue12855@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v4 adds back the reference to ?universal newlines?. I did not alter the doc string, because I don?t think doc strings need to be as detailed as the main documentation.

----------
Added file: http://bugs.python.org/file38748/linebreakdoc.v4.py3.5.patch

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

From report at bugs.python.org  Tue Mar 31 04:40:03 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 Mar 2015 02:40:03 +0000
Subject: [docs] [issue23484] SemLock acquire() keyword arg 'blocking' is
	invalid
In-Reply-To: <1424345474.95.0.767809945273.issue23484@psf.upfronthosting.co.za>
Message-ID: <1427769603.76.0.608342233643.issue23484@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Mar 31 06:11:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 04:11:11 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1427775071.14.0.342083075259.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

utf8-null.v4.patch:

* Clarified some mentions of ?string? and ?character? as bytes or code points
* Copied the warning about embedded nulls to PyUnicode_AS_UNICODE()

----------
Added file: http://bugs.python.org/file38750/utf8-null.v4.patch

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

From report at bugs.python.org  Tue Mar 31 07:49:03 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 Mar 2015 05:49:03 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1427780943.06.0.0634194767531.issue23088@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch LGTM, but someone other should look on it. David, could you please make a look?

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

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

From report at bugs.python.org  Tue Mar 31 13:50:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 Mar 2015 11:50:39 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1427802639.04.0.473499416414.issue23360@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think we should avoid mentioning bytes-like objects until Issue 23740 (http.client support), Issue 23756 (clarify definition), and/or SSLSocket.sendall() support are sorted out.

Changes in non-urlencoded.3.patch:
* Removed iterable object as direct urlopen() argument, since that would require a custom Content-Length and therefore a custom Request object
* Removed Content-Type discussion from urlopen() for similar reasons
* Added iterable object to Request constructor (already tested)
* Clarified default Content-Type whenever data is not None
* Added a test for default Content-Type with iterable object

----------
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file38758/non-urlencoded.3.patch

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

From report at bugs.python.org  Tue Mar 31 15:56:02 2015
From: report at bugs.python.org (rschwieb)
Date: Tue, 31 Mar 2015 13:56:02 +0000
Subject: [docs] [issue23823] "Generalization" misused in deque docs
Message-ID: <1427810162.43.0.413466648837.issue23823@psf.upfronthosting.co.za>


New submission from rschwieb:

This sentence in the deque docs (https://docs.python.org/2/library/collections.html#collections.deque) is not accurate: 

"Deques are a generalization of stacks and queues ..."

Deques are a _specialization_ of stacks and queues. Every deque is-a stack and is-a queue, but saying that "deques generalize stacks and queues" reverses this relationship.

On the surface it might seem minor, but I think it's worth correcting in this case since the "is-a" relationship is so fundamental in computer science. Besides, I'd like to think Python's awesome documentation is above using words to mean the opposite of what they mean :)

----------
assignee: docs at python
components: Documentation
messages: 239710
nosy: docs at python, rschwieb
priority: normal
severity: normal
status: open
title: "Generalization" misused in deque docs
type: enhancement
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/issue23823>
_______________________________________

From report at bugs.python.org  Tue Mar 31 16:52:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Mar 2015 14:52:41 +0000
Subject: [docs] [issue23823] "Generalization" misused in deque docs
In-Reply-To: <1427810162.43.0.413466648837.issue23823@psf.upfronthosting.co.za>
Message-ID: <1427813561.91.0.218997739344.issue23823@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry, I disagree.

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Tue Mar 31 18:47:28 2015
From: report at bugs.python.org (Demian Brecht)
Date: Tue, 31 Mar 2015 16:47:28 +0000
Subject: [docs] [issue23360] Content-Type when sending data with urlopen()
In-Reply-To: <1422794612.5.0.505084736818.issue23360@psf.upfronthosting.co.za>
Message-ID: <1427820448.14.0.447591700872.issue23360@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +demian.brecht

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