From report at bugs.python.org  Sat Nov  1 00:00:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Oct 2014 23:00:11 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414796411.74.0.291234573162.issue22725@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The first argument of enumerate is 'iterable' in the 2.7 docstring also.

"enumerate(iterable[, start]) -> iterator for index, value of iterable

Return an enumerate object.  iterable must be another object that supportsniteration.  The enumerate object yields pairs containing a count (from\nstart, which defaults to zero) and a value yielded by the iterable argument.  enumerate is useful for obtaining an indexed list:   (0, seq[0]), (1, seq[1]), (2, seq[2]), ..."

We should update at least that part of the doc entry.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 3.6

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

From report at bugs.python.org  Sat Nov  1 00:47:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 31 Oct 2014 23:47:49 +0000
Subject: [docs] [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414799269.66.0.880149902051.issue22738@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On Win7, current Firefox, '-c' looks the same (definitely lowercase) for 2.7,8, 3.4.2, and 3.5.0a0,

I agree both that the sys.argv entry should be left as is and that 'interpret' is better than 'feed' or the current verbiage.  I think 'cmd' should be left as is because it is more descriptive than the generic 'str' and because the latter implies to me that cmd must always (as opposed to often) be quoted, which is not true.  The result would be
  -c cmd : interpret cmd as a program (terminates option list)

For 3.5, the current line is repository\Modules\main.c: 55.  If we agree on the above, I am willing to make the patch and push it.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.4

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

From report at bugs.python.org  Sat Nov  1 02:04:22 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 01:04:22 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414803862.16.0.552820399567.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The "sequence" parameter name is an unfortunate hold-over from olden times were many things that accepted iterables were marked as taking sequences.

This was fixed in Python 3, but it can't be changed in Py2.7 because the parameter name is exposed as a keyword argument:

    >>> list(enumerate(sequence='abc', start=2))
    [(2, 'a'), (3, 'b'), (4, 'c')]

The rest docs for Python 2.7 read just fine, "Return an enumerate object. sequence must be a sequence, an iterator, or some other object which supports iteration."   I think that is sufficient to clarify any confusion caused by the unfortunate choice of keyword argument name.

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

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

From report at bugs.python.org  Sat Nov  1 02:42:29 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 01:42:29 +0000
Subject: [docs] [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414806149.17.0.411293917606.issue22738@psf.upfronthosting.co.za>


R. David Murray added the comment:

I am hard pressed to come up with anything useful you can do with the argument to -c without quoting it.

----------

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

From report at bugs.python.org  Sat Nov  1 02:58:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 01:58:05 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414807085.64.0.782853064601.issue22725@psf.upfronthosting.co.za>


R. David Murray added the comment:

We have a suggestion for a wording improvement (that does not change the sentence to which you refer) that has been accepted as better than the existing wording by a couple of committers.  This improvement is actually independent of what the variable is named.  The 2.7 docstring should also be fixed to show the actual argument name, IMO.

----------
resolution: rejected -> 
status: closed -> open
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov  1 03:17:36 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 01 Nov 2014 02:17:36 +0000
Subject: [docs] [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414808256.63.0.793124281436.issue22738@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Semi-useful: print a numeric expression without spaces
C:\Users\Terry>python -c print(2**50)
1125899906842624

Less useful: print a string expression without spaces or double quotes
C:\Users\Terry>python -c print('*'*50)
**************************************************

----------

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

From report at bugs.python.org  Sat Nov  1 03:35:33 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 01 Nov 2014 02:35:33 +0000
Subject: [docs] [issue22738] improve  'python -h' documentation for '-c'
In-Reply-To: <1414384786.34.0.941168460328.issue22738@psf.upfronthosting.co.za>
Message-ID: <1414809333.0.0.042596981548.issue22738@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  Those don't work in my shell, since the '*' gets interpreted as a globbing character.  I didn't know it worked on Windows.

----------

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

From report at bugs.python.org  Sat Nov  1 04:28:40 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 03:28:40 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414812520.56.0.445006650142.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Can you attach a proposed patch and I will make a decision.  

FWIW, I'm very happy with the current documentation at https://docs.python.org/2.7/library/functions.html#enumerate  Between the text, example, and pure python equivalent, it does a great job communicating what enumerate is supposed to do.

Proposed improvements to the docstring should match the main documentation as much as possible.

----------

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

From report at bugs.python.org  Sat Nov  1 08:08:58 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Nov 2014 07:08:58 +0000
Subject: [docs] [issue22755] contextlib.closing documentation should use a
	new example
In-Reply-To: <1414536052.52.0.0865505363528.issue22755@psf.upfronthosting.co.za>
Message-ID: <1414825737.94.0.227075206231.issue22755@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Can a different example be chosen?

The traditional examples (urllib, socket, StringIO) grow context manager support as soon as the need becomes apparent.  So, that leaves only user-defined classes, third-party classes, generators, and cases where we already have a competing context manager that does something other than close.

A reasonable candidate is an sqlite connection.  It is a legitimate use case for contextlib.closing() since connections need to be closed after use, and because they already are context managers that do something different than closing (the commit or rollback transactions).

A generator example would work, but closing generators is a rare and esoteric need (not many people even realize than you *can* close a generator), so this would make a bad example.

A user defined class can add its own __enter__ and __exit__ to close if needed, so it isn't common to use contextlib.closing() on your own classes.   The primary use case is for third-party classes where you don't control the source code and a closing context manager isn't present; however, those make for bad examples because they aren't in the standard library (i.e. aren't familiar) and because the better maintained modules are also adding context manager support.

Out of all of these, only the sqlite connection example seems to be durable (won't go away) and familiar (in the standard library and not an exotic feature).

That said, I think it would be best to stick with the simplest and most familiar possible examples even if they are no longer needed.   The purpose of the example is to show how closing() works.  We can use the surrounding text to indicate that the example is no longer necessary and that the most common remain uses are to add closing() behavior to third-party code you don't control (if you do control the code, then adding CM support directly to the class would be preferable).

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

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

From report at bugs.python.org  Sat Nov  1 18:54:14 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 01 Nov 2014 17:54:14 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414864454.09.0.145831056293.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Attached patch should fix the deprecated-removed directive. I've tested it with the following examples:

   .. deprecated-removed:: 3.4 4.0

      The ``'U'`` mode.


   .. deprecated-removed:: 3.4 4.0
      The ``'U'`` mode.


   .. deprecated-removed:: 3.4 4.0

----------
keywords: +patch
Added file: http://bugs.python.org/file37102/issue22695.diff

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

From report at bugs.python.org  Sat Nov  1 20:38:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 01 Nov 2014 19:38:35 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414870715.68.0.90163790467.issue22695@psf.upfronthosting.co.za>


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


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

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

From storchaka at gmail.com  Sat Nov  1 20:54:30 2014
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sat, 01 Nov 2014 19:54:30 -0000
Subject: [docs] open() declared deprecated in python 3 docs (issue 22695)
Message-ID: <20141101195430.21625.20763@psf.upfronthosting.co.za>


http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py
File Doc/tools/extensions/pyspecific.py (right):

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py#newcode182
Doc/tools/extensions/pyspecific.py:182: node[0].insert(0,
nodes.inline('', '%s: ' % text,
Should not this line be unindented?

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

From berker.peksag at gmail.com  Sat Nov  1 21:25:26 2014
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Sat, 01 Nov 2014 20:25:26 -0000
Subject: [docs] open() declared deprecated in python 3 docs (issue 22695)
Message-ID: <20141101202526.21625.81762@psf.upfronthosting.co.za>


http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py
File Doc/tools/extensions/pyspecific.py (right):

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py#newcode182
Doc/tools/extensions/pyspecific.py:182: node[0].insert(0,
nodes.inline('', '%s: ' % text,
On 2014/11/01 20:54:30, storchaka wrote:
> Should not this line be unindented?

Good catch! Will update the patch. Thanks.

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

From report at bugs.python.org  Sun Nov  2 13:10:15 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 12:10:15 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414930215.62.0.872097983178.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is a new patch. Thanks for the review, Serhiy.

----------
Added file: http://bugs.python.org/file37105/issue22695_v2.diff

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

From berker.peksag at gmail.com  Sun Nov  2 13:10:52 2014
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Sun, 02 Nov 2014 12:10:52 -0000
Subject: [docs] open() declared deprecated in python 3 docs (issue 22695)
Message-ID: <20141102121052.9313.72238@psf.upfronthosting.co.za>


http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py
File Doc/tools/extensions/pyspecific.py (right):

http://bugs.python.org/review/22695/diff/13186/Doc/tools/extensions/pyspecific.py#newcode182
Doc/tools/extensions/pyspecific.py:182: node[0].insert(0,
nodes.inline('', '%s: ' % text,
On 2014/11/01 20:54:30, storchaka wrote:
> Should not this line be unindented?

Done.

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

From report at bugs.python.org  Sun Nov  2 15:33:43 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 14:33:43 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414938823.02.0.205145130938.issue22317@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +bethard
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Sun Nov  2 16:05:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 15:05:39 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1414940739.02.0.769914087626.issue22695@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On my superficial view the patch looks good. But I am not well known with Sphinx code.

----------

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

From report at bugs.python.org  Sun Nov  2 16:22:15 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:22:15 +0000
Subject: [docs] [issue22344] Reorganize unittest.mock docs into linear manner
In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>
Message-ID: <1414941735.5.0.912733878586.issue22344@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Sun Nov  2 16:35:23 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:35:23 +0000
Subject: [docs] [issue22357] inspect module documentation makes no reference
	to	__qualname__ attribute
In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>
Message-ID: <1414942523.99.0.311073920504.issue22357@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou, yselivanov
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Sun Nov  2 16:37:59 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:37:59 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414942679.9.0.765332846232.issue22388@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Sun Nov  2 16:47:05 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:47:05 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1414943225.92.0.0963698073583.issue22525@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/issue22525>
_______________________________________

From report at bugs.python.org  Sun Nov  2 16:56:00 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 15:56:00 +0000
Subject: [docs] [issue22558] Missing hint to source code - complete
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1414943760.32.0.484063317171.issue22558@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The source links have been added where the code proved to be readable, easy to understand, and self documenting, and have been omitted when the code is complicated and not self documenting.  This has been done under the assumption that reading the code might help understanding the documentation, but there are other situations where users might want to see the code regardless of how readable it is, so I wouldn't object if you decide to add links to all the modules.

----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  2 17:01:57 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 02 Nov 2014 16:01:57 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414944117.43.0.761176178303.issue22317@psf.upfronthosting.co.za>


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


----------
nosy: +paul.j3
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  2 17:03:31 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Nov 2014 16:03:31 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1414944211.94.0.339111204718.issue22671@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Nov  2 18:29:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 02 Nov 2014 17:29:34 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <20141102172926.120736.72886@psf.io>


Roundup Robot added the comment:

New changeset e3825486da53 by Serhiy Storchaka in branch '3.4':
Issue #22388: Unified the style of "Contributed by" sentences in What's New.
https://hg.python.org/cpython/rev/e3825486da53

New changeset 5f10a4a1e4df by Serhiy Storchaka in branch 'default':
Issue #22388: Unified the style of "Contributed by" sentences in What's New.
https://hg.python.org/cpython/rev/5f10a4a1e4df

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

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

From report at bugs.python.org  Sun Nov  2 18:31:29 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 17:31:29 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414949489.28.0.427883087325.issue22388@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Ezio for your review.

----------

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

From report at bugs.python.org  Sun Nov  2 18:32:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Nov 2014 17:32:16 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1414949536.57.0.0424993816338.issue22388@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Nov  2 19:04:51 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Nov 2014 18:04:51 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414951491.09.0.262020637102.issue22725@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file37111/enumerate-doc.2.7.patch

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

From report at bugs.python.org  Sun Nov  2 19:05:17 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 02 Nov 2014 18:05:17 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1414951517.25.0.929224558095.issue22725@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file37112/enumerate_doc-3.4.patch

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

From report at bugs.python.org  Sun Nov  2 19:09:45 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 02 Nov 2014 18:09:45 +0000
Subject: [docs] [issue22344] Reorganize unittest.mock docs into linear manner
In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>
Message-ID: <1414951785.22.0.443793794246.issue22344@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rbcollins

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

From report at bugs.python.org  Sun Nov  2 22:07:03 2014
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 02 Nov 2014 21:07:03 +0000
Subject: [docs] [issue22785] range docstring is less useful than in python 2
Message-ID: <1414962423.59.0.0293441090984.issue22785@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The Python 3.4 docstring for range is:
{{{
 |  range(stop) -> range object
 |  range(start, stop[, step]) -> range object
 |
 |  Return a virtual sequence of numbers from start to stop by step.
}}}

In Python 2.7, it said:
{{{
    range(stop) -> list of integers
    range(start, stop[, step]) -> list of integers

    Return a list containing an arithmetic progression of integers.
    range(i, j) returns [i, i+1, i+2, ..., j-1]; start (!) defaults to 0.
    When step is given, it specifies the increment (or decrement).
    For example, range(4) returns [0, 1, 2, 3].  The end point is omitted!
    These are exactly the valid indices for a list of 4 elements.
}}}

Note that Python 3 seems to imply that the end-point is included, while Python 2 made clear that it was not.  "Arithmetic progression" is a bit involved, but it would be good to mention that the end-point is omitted in the Python 3 docstring.

----------
assignee: docs at python
components: Documentation
messages: 230525
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: range docstring is less useful than in python 2
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov  3 00:29:37 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Sun, 02 Nov 2014 23:29:37 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1414970977.25.0.580308129824.issue20351@psf.upfronthosting.co.za>


Charles-Axel Dein added the comment:

Sounds good. Do you know when this will get merged?

----------

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

From report at bugs.python.org  Mon Nov  3 02:40:09 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:40:09 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <1414978809.64.0.226834705951.issue21759@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

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

From report at bugs.python.org  Mon Nov  3 02:41:02 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:41:02 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414978862.11.0.325710816527.issue22317@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


----------
nosy: +Mike.Short

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

From report at bugs.python.org  Mon Nov  3 02:49:10 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:49:10 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414979349.98.0.246056359363.issue22317@psf.upfronthosting.co.za>


Mike Short added the comment:

I am uploading patches for both 2.7 as well as latest (3.x).  I only added the action verbiage itself in, but would it be beneficial to also add in links to more detailed descriptions similar to what is done in ArgumentParser.add_argument earlier in the argparse page?

----------
keywords: +patch
Added file: http://bugs.python.org/file37115/argparse.patch

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

From report at bugs.python.org  Mon Nov  3 02:49:28 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 03 Nov 2014 01:49:28 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
In-Reply-To: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>
Message-ID: <1414979368.38.0.858872438887.issue22317@psf.upfronthosting.co.za>


Changes by Mike Short <bmshort at gmail.com>:


Added file: http://bugs.python.org/file37116/argparse27.patch

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

From ezio.melotti at gmail.com  Mon Nov  3 07:44:03 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 03 Nov 2014 06:44:03 -0000
Subject: [docs] improve documentation for enumerate() (built-in function)
	(issue 22725)
Message-ID: <20141103064403.10674.39021@psf.upfronthosting.co.za>


http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst#newcode361
Doc/library/functions.rst:361: Return an enumerate object which when
:term`iterated <iterable>` yields a
"which when iterated" sounds a bit weird to me.  Would it be better if
commas were added before and after "when iterated"?
The link to "iterable" could also be moved to "enumerate object", even
though it might be somewhat misleading if one expects it to link to the
documentation of the actual enumerate object.

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

From report at bugs.python.org  Mon Nov  3 11:32:15 2014
From: report at bugs.python.org (Yongzhi Pan)
Date: Mon, 03 Nov 2014 10:32:15 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1415010735.49.0.356133435968.issue8350@psf.upfronthosting.co.za>


Changes by Yongzhi Pan <panyongzhi at gmail.com>:


----------
nosy: +fossilet

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

From rdmurray at bitdance.com  Mon Nov  3 14:58:34 2014
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Mon, 03 Nov 2014 13:58:34 -0000
Subject: [docs] improve documentation for enumerate() (built-in
	function) (issue 22725)
Message-ID: <20141103135834.10673.42888@psf.upfronthosting.co.za>


http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/22725/diff/13194/Doc/library/functions.rst#newcode361
Doc/library/functions.rst:361: Return an enumerate object which when
:term`iterated <iterable>` yields a
On 2014/11/03 07:44:04, ezio.melotti wrote:
> "which when iterated" sounds a bit weird to me.  Would it be better if
commas
> were added before and after "when iterated"?

It sounds weird to me with the commas, but I think this is a grey area
in English and I have no objection to changing it.  (In my mind the
'when iterated' is an essential part of the clause and not a separate
clause, but I'm not sure that's meaningful.)

> The link to "iterable" could also be moved to "enumerate object", even
though it
> might be somewhat misleading if one expects it to link to the
documentation of
> the actual enumerate object.

I don't see that that would be clearer.

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

From report at bugs.python.org  Tue Nov  4 05:56:17 2014
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 04 Nov 2014 04:56:17 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415076977.35.0.913395315014.issue22725@psf.upfronthosting.co.za>


Tshepang Lekhonkhobe added the comment:

@raymond

Why do you say that 'sequence' is a keyword?

>>> enumerate()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Required argument 'sequence' (pos 1) not found

That means that 'sequence' can be changed to 'iterable' without worrying about backwards compatibility.

----------
nosy: +tshepang

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

From report at bugs.python.org  Tue Nov  4 06:22:06 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Nov 2014 05:22:06 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415078526.14.0.264691745755.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

static PyObject *
> Why do you say that 'sequence' is a keyword?

It is a keyword argument to enumerate().  Here's the relevant section of code:

enum_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
{
    enumobject *en;
    PyObject *seq = NULL;
    PyObject *start = NULL;
    static char *kwlist[] = {"sequence", "start", 0};

    if (!PyArg_ParseTupleAndKeywords(args, kwds, "O|O:enumerate", kwlist,
                                     &seq, &start))
        return NULL

----------

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

From report at bugs.python.org  Tue Nov  4 08:50:21 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 07:50:21 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415087421.14.0.606475432531.issue22695@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

----------

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

From report at bugs.python.org  Tue Nov  4 09:10:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 08:10:38 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415088637.95.0.00433196200754.issue22725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Specifically, this works (in 2.7):

  >>> enumerate(sequence=myvar)

Changing sequence to iterable would break any code that was written like the above.

----------

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

From report at bugs.python.org  Tue Nov  4 11:22:00 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 10:22:00 +0000
Subject: [docs] [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415096520.34.0.246513872074.issue22792@psf.upfronthosting.co.za>


eryksun added the comment:

Follow the "String Methods" link at the top of the string module documentation. Or use this link:

https://docs.python.org/3.4/library/stdtypes.html#str.replace

See also help(str.replace) and help(str) in the interactive shell.

----------
assignee:  -> docs at python
components: +Documentation -Distutils
nosy: +docs at python, eryksun

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

From report at bugs.python.org  Tue Nov  4 11:23:28 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:23:28 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096608.07.0.809056927704.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

However, it may not be possible to change this for backward compatibility reasons.  People shouldn't be using dir() for determining attributes and the like, but they do, as documented by the multiprocessing module in the stdlib.

This should at least be noted more explicitly in the docs for dir().

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

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

From report at bugs.python.org  Tue Nov  4 11:24:49 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:24:49 +0000
Subject: [docs] [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415096689.56.0.894118972188.issue22792@psf.upfronthosting.co.za>


Georg Brandl added the comment:

There is already a "see also: string methods" at the top of the page.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Tue Nov  4 11:28:33 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:28:33 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096913.3.0.296131794976.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I definitely think this should be changed. I just don't know how to do it :-)

----------
stage:  -> needs patch
versions: +Python 3.5

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

From report at bugs.python.org  Tue Nov  4 11:28:39 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:28:39 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415096918.99.0.935343911051.issue22790@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Nov  4 11:36:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:36:27 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097386.96.0.853733146062.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Attaching prototype patch without test suite adjustments.

----------
keywords: +patch
Added file: http://bugs.python.org/file37126/type_dir_patch.diff

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

From report at bugs.python.org  Tue Nov  4 11:40:59 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 10:40:59 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097659.27.0.045280672297.issue22790@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/issue22790>
_______________________________________

From report at bugs.python.org  Tue Nov  4 11:44:13 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:44:13 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415097853.65.0.896036543073.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I have a question: why would do it for classes and not for regular objects?

----------
assignee: docs at python -> 

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

From report at bugs.python.org  Tue Nov  4 11:48:22 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 04 Nov 2014 10:48:22 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098102.5.0.787830896001.issue22790@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Ah, I misunderstood the patch, sorry. Nevermind.

----------

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

From report at bugs.python.org  Tue Nov  4 11:48:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 10:48:27 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098107.38.0.787833315701.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Basically beacuse with the current patch, this is because object_dir also does merge_class_dict, to get class attributes.  This means that attributes like __qualname__ would show up in dir(instance), but are not actually available on the instance.

Fixing this requires a more substantial rewrite, but is certainly the right way if this is accepted at all.

----------

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

From report at bugs.python.org  Tue Nov  4 12:02:45 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 11:02:45 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415098965.33.0.249023103703.issue22790@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg230614

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

From report at bugs.python.org  Tue Nov  4 12:49:18 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 11:49:18 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415101758.85.0.506970648635.issue22725@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/issue22725>
_______________________________________

From report at bugs.python.org  Tue Nov  4 13:30:04 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 04 Nov 2014 12:30:04 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415104204.05.0.191006124233.issue22790@psf.upfronthosting.co.za>


eryksun added the comment:

__doc__ and __module__ are also getsets (to support built-in types), but it's nothing to worry about since the attributes can't be deleted.

I think the most value added here is for listing __mro__ and the others that Georg mentioned. Should the following attributes be blacklisted from dir() as CPython implementation details?

    __base__
    __flags__
    __basicsize__
    __itemsize__
    __dictoffset__
    __weakrefoffset__

It's not as if people will miss what they never had.

----------

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

From report at bugs.python.org  Tue Nov  4 16:57:37 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 15:57:37 +0000
Subject: [docs] [issue22792] string replace() not documented
In-Reply-To: <1415094641.17.0.34490093881.issue22792@psf.upfronthosting.co.za>
Message-ID: <1415116657.88.0.820858911135.issue22792@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify for the OP: in python3 the 'string' module does not contain a replace function, whereas in 2.7 it did.  'replace' is only a method on str in python3, whereas in 2.7 it is both an str method and a function in the string module.

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

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

From report at bugs.python.org  Tue Nov  4 17:52:33 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 04 Nov 2014 16:52:33 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415119953.15.0.482886325231.issue22790@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

__base__ exists also in Jython and PyPy (#22456).

I think that all attributes could be listed.

----------

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

From report at bugs.python.org  Tue Nov  4 18:04:57 2014
From: report at bugs.python.org (Joshua Chin)
Date: Tue, 04 Nov 2014 17:04:57 +0000
Subject: [docs] [issue22797] urllib.request.urlopen documentation falsely
	guarantees	that a URLError will be raised on errors
Message-ID: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>


New submission from Joshua Chin:

The documentation for urlopen states that it "Raises URLError on errors." However, urlopen can raise a ValueError. In fact, test_urllib. urlopen_FileTests.test_relativelocalfile  specifically checks if urlopen raises a ValueError. I suggest removing the guarantee from the documentation.

----------
assignee: docs at python
components: Documentation
files: urlopen_doc.patch
keywords: patch
messages: 230640
nosy: Joshua.Chin, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request.urlopen documentation falsely guarantees that a URLError will be raised on errors
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file37129/urlopen_doc.patch

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

From report at bugs.python.org  Tue Nov  4 18:12:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 17:12:38 +0000
Subject: [docs] [issue22797] urllib.request.urlopen documentation falsely
	guarantees	that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415121157.96.0.178195524813.issue22797@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a general principle in Python.  A module may raise specific errors, but there are always other errors that may be raised.  The wording could be clarified, but it should not be removed.

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

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

From report at bugs.python.org  Tue Nov  4 18:43:41 2014
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 04 Nov 2014 17:43:41 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123020.94.0.140197876832.issue22790@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

So, dir(C) contains '__mro__', but not 'mro'?

I'm -1 on the change.
>From https://docs.python.org/3.4/library/functions.html#dir :
"""
Note Because dir() is supplied primarily as a convenience for use at an interactive prompt, it tries to supply an interesting set of names more than it tries to supply a rigorously or consistently defined set of names, and its detailed behavior may change across releases. For example, metaclass attributes are not in the result list when the argument is a class.
"""

dir(sys) does not list its __str__ method, even if sys.__str__() works, because returning only the explicit content of the module is more interesting to the user.

Likewise, the implementation of dir(__class__) returns the methods and attributes of *instances* because [someone decided that] it's the most relevant info for the user.

----------

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

From report at bugs.python.org  Tue Nov  4 18:46:55 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 17:46:55 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123215.37.0.430428166168.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> So, dir(C) contains '__mro__', but not 'mro'?

That can be discussed.

But I would argue that at least __name__, __bases__ and __qualname__ are interesting attributes for the user.  Same for methods like __subclasses__().

Otherwise, it's quite ironic to prevent attributes that allow introspection in the first place from being displayed in one of the main features used for introspection.

----------

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

From report at bugs.python.org  Tue Nov  4 18:53:05 2014
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 04 Nov 2014 17:53:05 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415123585.72.0.0576402782979.issue22790@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Why are __flags__, __basicsize__, __itemsize__, __dictoffset__, and __weakrefoffset__ interesting?

I agree with Georg about the others.

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

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

From report at bugs.python.org  Tue Nov  4 19:00:13 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 04 Nov 2014 18:00:13 +0000
Subject: [docs] [issue22790] some class attributes missing from dir(Class)
In-Reply-To: <1415090644.24.0.620494684539.issue22790@psf.upfronthosting.co.za>
Message-ID: <1415124013.02.0.0204169369427.issue22790@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> Why are __flags__, __basicsize__, __itemsize__, __dictoffset__, and __weakrefoffset__ interesting?

I haven't said they are, but on the other hand I don't see why consistency is a bad thing.

----------

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

From report at bugs.python.org  Tue Nov  4 21:43:36 2014
From: report at bugs.python.org (Joshua Chin)
Date: Tue, 04 Nov 2014 20:43:36 +0000
Subject: [docs] [issue22797] urllib.request.urlopen documentation falsely
	guarantees	that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415133816.66.0.448482831403.issue22797@psf.upfronthosting.co.za>


Changes by Joshua Chin <joshuarchin at gmail.com>:


Added file: http://bugs.python.org/file37131/urlopen_doc.patch

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

From report at bugs.python.org  Tue Nov  4 22:10:08 2014
From: report at bugs.python.org (Devin Jeanpierre)
Date: Tue, 04 Nov 2014 21:10:08 +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: <1415135408.93.0.418992783536.issue22785@psf.upfronthosting.co.za>


Changes by Devin Jeanpierre <jeanpierreda at gmail.com>:


----------
nosy: +Devin Jeanpierre

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

From report at bugs.python.org  Tue Nov  4 23:25:18 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 04 Nov 2014 22:25:18 +0000
Subject: [docs] [issue22797] urllib.request.urlopen documentation falsely
	guarantees	that a URLError will be raised on errors
In-Reply-To: <1415120697.65.0.296811511924.issue22797@psf.upfronthosting.co.za>
Message-ID: <1415139918.54.0.247143358769.issue22797@psf.upfronthosting.co.za>


R. David Murray added the comment:

(Looking at your new patch...thanks for giving it a try even though I wasn't clear).

There are lots of other errors it can raise, too.  I was thinking more along the lines of "raises URLError on http protocol errors".  The problem is that's not completely accurate, either, but I don't remember exactly when it is that HTTPError can leak through.

Just for reference, in my code that calls urlopen and needs to keep running it if can't access the URL no matter what the (network-derived) reason, I catch ConnectionError, HTTPError, URLError, and IncompleteRead.  

We do not document all possible exceptions.  We document those that are specific to the module in question (which is URLError in this case) or that are part of the documented API (such as mentioning TimeoutError as what happens if the timeout specified by a timeout keyword is exceeded).

ValueErrors are a general class of errors that, when encountered, usually mean you need to fix your code (or, in the case of the SSL one you mention, check for SSL support at startup, assuming I understood correctly), rather than something you would catch around the urlopen call in a typical program.  There are, of course, occasions when you *do* catch ValueErrors in specific bits of code, but there is no practical way we can document all of the reasons ValueError might get raised, so we don't try.

All of that said, it would be lovely to have a reference somewhere (maybe a tutorial?) that went over all the possible exceptions one might get while using various network libraries, and why they might arise.  It is an issue that comes from the fact that the libraries are built on top of each other and the general python technique is that lower level errors are allowed to bubble up.  It would be a beast to keep up to date, though, which is probably one reason we don't have one.  But even that kind of guide wouldn't include ValueErrors.

----------

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

From report at bugs.python.org  Wed Nov  5 01:15:11 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 05 Nov 2014 00:15:11 +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: <1415146511.13.0.293694640165.issue22785@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> needs patch
versions: +Python 3.5

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

From report at bugs.python.org  Wed Nov  5 07:22:48 2014
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Wed, 05 Nov 2014 06:22:48 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1415088637.95.0.00433196200754.issue22725@psf.upfronthosting.co.za>
Message-ID: <CAA77j2D3+TnYBP89MipLO6vaSJYM27nHxQRStb5ew0_+2kzDQA@mail.gmail.com>


Tshepang Lekhonkhobe added the comment:

Oh, I see now. The documentation doesn't make it clear.

Anyways, what were the advantages of making it a keyword, instead of
just a positional argument?

----------

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

From report at bugs.python.org  Wed Nov  5 08:13:18 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 07:13:18 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415171598.74.0.735743720312.issue22725@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Missing keyword argument support is not the norm, it's the exception that is only due to implementation details in C code. Eventually, we'd like every C function to support keyword arguments.

Converting everything is tedious work, though, and still makes things slower (that may become less of an issue eventually with Clinic), so only select functions are converted.

Functions are good candidates for keyword argument support when they have parameters that are best passed as keywords, such as

    enumerate(x, start=5)

which makes it immediately clear what the second parameter does.

----------

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

From report at bugs.python.org  Wed Nov  5 09:29:23 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:29:23 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1415176163.76.0.217060991593.issue22725@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm sorry but I do not like the proposed patch at all.  The wording is awkward "which when iterated" and has weird terminology "the sequence number".

The OP's concern about the *sequence* versus *iterable* parameter name has been addressed (it is part of the 2.7 API and is unchangeable).

I see no need for revising the text which already discusses "sequence or some other object that supports iterable", that has clear examples, and that has pure python equivalent code.   The existing wording has worked well for most people for the better part of a decade.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Nov  5 09:33:11 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:33:11 +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: <1415176391.59.0.130417289002.issue22785@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Note that Python 3 seems to imply that the end-point is included

The Python 2 wording is better in this regard.

Also, it would be nice clarify what is meant by "virtual sequence".  I know what that means only because I already know what range() does.  For someone who doesn't already know what it means, that phrase probably doesn't add any value.

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

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

From report at bugs.python.org  Wed Nov  5 09:49:54 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 05 Nov 2014 08:49:54 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1415177394.8.0.596437007166.issue22525@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Georg's proposed wording reads well and is clearer than the current wording.  The patch is ready to apply.

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

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

From report at bugs.python.org  Wed Nov  5 20:21:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 19:21:44 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <20141105192059.85194.49862@psf.io>


Roundup Robot added the comment:

New changeset 5c5909740026 by Georg Brandl in branch '3.4':
Closes #22525: clarify documentation for ast.literal_eval().
https://hg.python.org/cpython/rev/5c5909740026

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

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

From report at bugs.python.org  Wed Nov  5 20:24:25 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 05 Nov 2014 19:24:25 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1415215465.21.0.253201714108.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, Raymond.

----------

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

From report at bugs.python.org  Wed Nov  5 20:27:22 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 05 Nov 2014 19:27:22 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <20141105192409.723.63761@psf.io>


Roundup Robot added the comment:

New changeset 3e8d3c4bc17e by Georg Brandl in branch '2.7':
Closes #22525: clarify documentation for ast.literal_eval().
https://hg.python.org/cpython/rev/3e8d3c4bc17e

----------

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

From report at bugs.python.org  Wed Nov  5 21:13:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Nov 2014 20:13:33 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415218413.28.0.620358658666.issue22695@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  6 05:35:13 2014
From: report at bugs.python.org (Christopher Foo)
Date: Thu, 06 Nov 2014 04:35:13 +0000
Subject: [docs] [issue22803] textwrap.indent version added not documented
Message-ID: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>


New submission from Christopher Foo:

I was running my program under CI and it failed under 3.2:

    text = textwrap.indent(text, '* ', predicate=lambda line: True)

    AttributeError: 'module' object has no attribute 'indent'

textwrap.indent appears to be a new feature in 3.3 but Doc/library/textwrap.rst is not documented with ".. versionadded:: 3.3"

----------
assignee: docs at python
components: Documentation
messages: 230725
nosy: chfoo, docs at python
priority: normal
severity: normal
status: open
title: textwrap.indent version added not documented
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Nov  6 06:28:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 06 Nov 2014 05:28:34 +0000
Subject: [docs] [issue22803] textwrap.indent version added not documented
In-Reply-To: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>
Message-ID: <20141106052826.85216.52649@psf.io>


Roundup Robot added the comment:

New changeset 501edbbb74ff by Raymond Hettinger in branch '3.4':
Issue 22803:  Add missing versionadded directive.
https://hg.python.org/cpython/rev/501edbbb74ff

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

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

From report at bugs.python.org  Thu Nov  6 06:28:59 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Nov 2014 05:28:59 +0000
Subject: [docs] [issue22803] textwrap.indent version added not documented
In-Reply-To: <1415248513.64.0.157096168022.issue22803@psf.upfronthosting.co.za>
Message-ID: <1415251738.96.0.457239889501.issue22803@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the bug report.

----------
nosy: +rhettinger
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Thu Nov  6 22:07:10 2014
From: report at bugs.python.org (Mark Grandi)
Date: Thu, 06 Nov 2014 21:07:10 +0000
Subject: [docs] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
Message-ID: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>


New submission from Mark Grandi:

In the asyncio documentation, specifically asyncio-eventloop.rst, in the description for BaseEventLoop.call_at(), it has:

   Arrange for the *callback* to be called at the given absolute timestamp *when* (an int or float), using the same time reference as :meth:`time`.

This links to the time module's time.time() method, which is incorrect as well as confusing, as the event loop's clock is NOT the same as time.time(), and it even says so on the top of the 'delayed calls' section

According the python documentation guide, it should have a period before it to make it refer to a method that is within the same module. I however decided to change it to `BaseEventLoop.time()`, because when i  see the text 'time()', even if it links to the right method, still makes me think of time.time(), which is again confusing and generally incorrect. 

Attached is a patch file, its a trivial change, but i did regenerate the docs and confirmed that it works, and clicking the link takes you to the right method in the page.

----------
assignee: docs at python
components: Documentation
files: markgrandi_asyncio-eventloop.rst.patch
keywords: patch
messages: 230764
nosy: docs at python, markgrandi
priority: normal
severity: normal
status: open
title: Typo in asyncio-eventloop.rst, time() link is wrong
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file37141/markgrandi_asyncio-eventloop.rst.patch

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

From report at bugs.python.org  Fri Nov  7 00:46:21 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 06 Nov 2014 23:46:21 +0000
Subject: [docs] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415317581.61.0.248394074157.issue22808@psf.upfronthosting.co.za>


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


----------
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov
stage:  -> patch review
versions: +Python 3.5

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

From report at bugs.python.org  Fri Nov  7 00:48:44 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Nov 2014 23:48:44 +0000
Subject: [docs] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415317724.34.0.232888074163.issue22808@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LG, can someone commit this? Should be backported to the 3.4 docs as well.

----------

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

From report at bugs.python.org  Fri Nov  7 11:00:09 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 10:00:09 +0000
Subject: [docs] [issue22812] Documentation of unittest -p usage wrong on
	windows.
Message-ID: <1415354409.44.0.0207378794997.issue22812@psf.upfronthosting.co.za>


New submission from Robert Collins:

>From https://code.google.com/p/unittest-ext/issues/detail?id=13

The following is incorrect on Windows:

    python -m unittest discover -p '*.py'

It should be without the single quotes around the .py:

    python -m unittest discover -p *.py

This needs to be documented.

----------
assignee: docs at python
components: Documentation
messages: 230777
nosy: docs at python, rbcollins
priority: normal
severity: normal
status: open
title: Documentation of unittest -p usage wrong on windows.
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov  7 16:16:27 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 07 Nov 2014 15:16:27 +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: <1415373387.76.0.823036220206.issue22812@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why doesn't it work with the quotes?  Wouldn't it be better to make it work?  Or is it as simple as changing the example to use double quotes?

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

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

From report at bugs.python.org  Fri Nov  7 16:22:44 2014
From: report at bugs.python.org (Robert Collins)
Date: Fri, 07 Nov 2014 15:22:44 +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: <1415373764.75.0.201133413002.issue22812@psf.upfronthosting.co.za>


Robert Collins added the comment:

I agree. IIRC the windows shell passes the argument as "'*.py'" rather than as "*.py", so when we glob it we get no files, as no python files end with an apostrophe.

----------

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

From report at bugs.python.org  Fri Nov  7 17:29:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 16:29:46 +0000
Subject: [docs] [issue22242] Doc fix in the Import section in language
	reference.
In-Reply-To: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>
Message-ID: <20141107162942.85196.28486@psf.io>


Roundup Robot added the comment:

New changeset f473063318c3 by Brett Cannon in branch 'default':
Issue #22242: Try to make some import-related loader details clearer.
https://hg.python.org/cpython/rev/f473063318c3

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

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

From report at bugs.python.org  Fri Nov  7 17:31:41 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 07 Nov 2014 16:31:41 +0000
Subject: [docs] [issue22242] Doc fix in the Import section in language
	reference.
In-Reply-To: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>
Message-ID: <1415377901.07.0.727644278115.issue22242@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So the second point isn't contradictory, just more thorough (and had a mad mix of singular/plural wording). Loaders could add more than one module if they chose to. The key point is that when a load fails, only the modules that failed and that the loader itself was directly involved with loading should be removed from sys.modules.

I tried to fix the plurality of the words in the second part to help clear things up.

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

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

From report at bugs.python.org  Fri Nov  7 18:51:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 07 Nov 2014 17:51:44 +0000
Subject: [docs] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <20141107175130.108387.30076@psf.io>


Roundup Robot added the comment:

New changeset 8b1d8fcb494b by Berker Peksag in branch '3.4':
Issue #22808: Link to the correct time method in BaseEventLoop.call_at().
https://hg.python.org/cpython/rev/8b1d8fcb494b

New changeset 98f4bc1332c9 by Berker Peksag in branch 'default':
Issue #22808: Link to the correct time method in BaseEventLoop.call_at().
https://hg.python.org/cpython/rev/98f4bc1332c9

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

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

From report at bugs.python.org  Fri Nov  7 18:52:32 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 07 Nov 2014 17:52:32 +0000
Subject: [docs] [issue22808] Typo in asyncio-eventloop.rst,
	time() link is wrong
In-Reply-To: <1415308030.44.0.289698928336.issue22808@psf.upfronthosting.co.za>
Message-ID: <1415382752.57.0.826451177619.issue22808@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Committed. Thanks for the patch, Mark.

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

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

From report at bugs.python.org  Sat Nov  8 13:50:38 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 08 Nov 2014 12:50:38 +0000
Subject: [docs] [issue22820] RESTART line with no output
In-Reply-To: <1415445819.89.0.337025555913.issue22820@psf.upfronthosting.co.za>
Message-ID: <1415451038.27.0.675262706273.issue22820@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your code doesn't produce any output (ie: there are no print calls).  I don't use Idle myself, but I'm guessing that is why you don't see anything after the restart line.  If that is the case, do you see a place in whatever help or documentation you have read that it would be appropriate to mention this?  (The distinction is that the REPL window automatically prints the return value of whatever you type in, whereas in a program you get output only if you do the print yourself).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray, terry.reedy
type: crash -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Nov  8 18:43:49 2014
From: report at bugs.python.org (Chris PeBenito)
Date: Sat, 08 Nov 2014 17:43:49 +0000
Subject: [docs] [issue22822] IPv6Network constructor docs incorrect about
	valid input
Message-ID: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>


New submission from Chris PeBenito:

Here:

https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv6Network

In the constructor documentation, item 1 says:

"""
A string consisting of an IP address and an optional mask, separated by a slash (/). The IP address is the network address, and the mask can be either a single number, which means it?s a prefix, or a string representation of an IPv6 address. If it?s the latter, the mask is interpreted as a net mask. If no mask is provided, it?s considered to be /128.

For example, the following address specifications are equivalent: 2001:db00::0/24 and 2001:db00::0/ffff:ff00::.
"""

However in issue22800 it has been identified that using the expanded netmask (e.g. ff00::/ff00::) is not supported.

----------
assignee: docs at python
components: Documentation
messages: 230871
nosy: docs at python, pebenito
priority: normal
severity: normal
status: open
title: IPv6Network constructor docs incorrect about valid input
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Nov  8 21:40:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 08 Nov 2014 20:40:51 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <20141108204048.108373.52185@psf.io>


Roundup Robot added the comment:

New changeset 9001298e3094 by Berker Peksag in branch '3.4':
Issue #22695: Fix rendering of the deprecated-removed role in HTML.
https://hg.python.org/cpython/rev/9001298e3094

New changeset ec81edc30221 by Berker Peksag in branch 'default':
Issue #22695: Fix rendering of the deprecated-removed role in HTML.
https://hg.python.org/cpython/rev/ec81edc30221

----------

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

From report at bugs.python.org  Sat Nov  8 21:42:59 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Nov 2014 20:42:59 +0000
Subject: [docs] [issue22695] open() declared deprecated in python 3 docs
In-Reply-To: <1413964221.11.0.813943721284.issue22695@psf.upfronthosting.co.za>
Message-ID: <1415479378.79.0.320735756352.issue22695@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the reviews.

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

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

From report at bugs.python.org  Sun Nov  9 19:18:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 18:18:28 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
Message-ID: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/3.4/library/functools.html#functools.cmp_to_key says " A key function is a callable that accepts one argument and returns another value indicating the position in the desired collation sequence."  A python list poster (Veek M) 'value indicating the position' as meaning 0, 1, 2, ... and I would read it that way if I did not know better.

Entries for min() and max() say "The key argument specifies a one-argument ordering function like that used for list.sort()."  This would be reused here.  We also, now, have a Glossary entry for 'key function'.  This could be referred to instead.

----------
assignee: docs at python
components: Documentation
messages: 230895
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.cmp_to_key: misleading key function description
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Nov  9 19:52:31 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Nov 2014 18:52:31 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415559151.16.0.427193770445.issue22830@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll add a link to the glossary entry for key function and to the sorting howto.  Also, I'll change "value indicating the position" to "value to be used as the sort key".

The form sentence being discussed should probably remain close to how it is currently written.  It is part of a two sentence paragraph that contrasts cmp functions versus key functions, so the parallel sentence structure is part of what it is trying to communicate.

FWIW, interpreting "value indicating position" as 0, 1, 2, etc isn't incorrect.  That is a possible key function.

In general, I prefer doc changes to be very minor when they have a history of many people reading them correctly; otherwise, we risk moving away from something that was already working pretty well.

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

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

From report at bugs.python.org  Sun Nov  9 22:02:47 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 09 Nov 2014 21:02:47 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415566967.1.0.482204679648.issue22830@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree with your comments and proposed changes and will leave this to you.

----------

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

From report at bugs.python.org  Mon Nov 10 02:10:32 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 01:10:32 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <20141110011027.113478.19574@psf.io>


Roundup Robot added the comment:

New changeset dbe1744ec62e by Raymond Hettinger in branch '2.7':
Issue 22830:  Clarify docs for functools.cmp_to_key().
https://hg.python.org/cpython/rev/dbe1744ec62e

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

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

From report at bugs.python.org  Mon Nov 10 02:21:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 01:21:46 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <20141110012128.719.65720@psf.io>


Roundup Robot added the comment:

New changeset 63274cf1b40d by Raymond Hettinger in branch '3.4':
Issue 22830:  Clarify docs for functools.cmp_to_key().
https://hg.python.org/cpython/rev/63274cf1b40d

----------

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

From report at bugs.python.org  Mon Nov 10 02:27:48 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 10 Nov 2014 01:27:48 +0000
Subject: [docs] [issue22830] functools.cmp_to_key: misleading key function
	description
In-Reply-To: <1415557108.23.0.961507341186.issue22830@psf.upfronthosting.co.za>
Message-ID: <1415582868.81.0.935284026646.issue22830@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov 10 02:32:31 2014
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Nov 2014 01:32:31 +0000
Subject: [docs] [issue22832] Tweak parameter names for fcntl module
Message-ID: <1415583151.45.0.487298070274.issue22832@psf.upfronthosting.co.za>


New submission from Brett Cannon:

http://bugs.python.org/review/20152/ is filled with various suggestions from Serhiy on how to update the function parameters in the fcntl module to more closely match what is in the man pages. This should be fully backwards-compatible as the parameters are positional-only. It should be easy as the code doesn't need to change thanks to Argument Clinic. Trick will be updating both the code and the docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 230931
nosy: brett.cannon, docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak parameter names for fcntl module
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Mon Nov 10 18:30:42 2014
From: report at bugs.python.org (Jonathan Sharpe)
Date: Mon, 10 Nov 2014 17:30:42 +0000
Subject: [docs] [issue22839] Incorrect link to statistics in tracemalloc
	documentation
Message-ID: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>


New submission from Jonathan Sharpe:

The link to "statistics" in the documentation for tracemalloc.Snapshot.compare_to (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.compare_to) should be to the statistics method (https://docs.python.org/3/library/tracemalloc.html#tracemalloc.Snapshot.statistics), per the description, not to the statistics module (https://docs.python.org/3/library/statistics.html#module-statistics), where it currently points.

----------
assignee: docs at python
components: Documentation
messages: 230968
nosy: docs at python, jonrsharpe
priority: normal
severity: normal
status: open
title: Incorrect link to statistics in tracemalloc documentation
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Nov 10 21:50:35 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 10 Nov 2014 20:50:35 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1415652633.99.0.446291074214.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch which fixes remnants. It also corrects descriptions of parsing arguments format units.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37169/bytes_like.patch

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

From report at bugs.python.org  Mon Nov 10 22:15:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 10 Nov 2014 21:15:43 +0000
Subject: [docs] [issue22839] Incorrect link to statistics in tracemalloc
	documentation
In-Reply-To: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>
Message-ID: <20141110211537.29008.29181@psf.io>


Roundup Robot added the comment:

New changeset 387bbada31e8 by Berker Peksag in branch '3.4':
Issue #22839: Fix Snapshot.statistics() link.
https://hg.python.org/cpython/rev/387bbada31e8

New changeset 524a004e93dd by Berker Peksag in branch 'default':
Issue #22839: Fix Snapshot.statistics() link.
https://hg.python.org/cpython/rev/524a004e93dd

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

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

From report at bugs.python.org  Mon Nov 10 22:16:53 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 10 Nov 2014 21:16:53 +0000
Subject: [docs] [issue22839] Incorrect link to statistics in tracemalloc
	documentation
In-Reply-To: <1415640642.7.0.721406876046.issue22839@psf.upfronthosting.co.za>
Message-ID: <1415654212.88.0.358126713241.issue22839@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the report, Jonathan.

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

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

From ezio.melotti at gmail.com  Mon Nov 10 23:12:06 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 10 Nov 2014 22:12:06 -0000
Subject: [docs] There is no standard TestCase.runTest implementation
	(issue 22153)
Message-ID: <20141110221206.6978.73589@psf.upfronthosting.co.za>

On 2014/11/10 22:24:13, vadmium wrote:
>
http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst
> File Doc/library/unittest.rst (right):
> 
>
http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#newcode1561
> Doc/library/unittest.rst:1561: If no methods with the usual name
prefix are
> found, but the ``runTest()`` method is implemented, there will be a
single test
> case using that method.
> I think this was my original wording. What about something like
> 
> A test case instance is created for each method named by
getTestCaseNames(). By
> default these are the method names beginning with ?test?. If
getTestCaseNames()
> returns no methods, but the runTest() method is implemented, a single
test case
> is created for that method instead.
> 

This sounds quite clear to me?

> Personally, I use runTest() for test case classes designed with a
single test
> method in mind. But I?m not sure the documentation should suggest
that.



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

From report at bugs.python.org  Tue Nov 11 02:26:04 2014
From: report at bugs.python.org (Clayton Kirkwood)
Date: Tue, 11 Nov 2014 01:26:04 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
Message-ID: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>


New submission from Clayton Kirkwood:

Documentation says:
> Match objects always have a boolean value of True. Since match() and
> search() return None when there is no match, you can test whether 
> there was a match with a simple if statement:
>
> match = re.search(pattern, string)
> if match:
>     process(match)

What happens:
blah = <_sre.SRE_Match object; span=(0, 28), match='<BR>Nov. 10, 08:16:09 PM EST'>
     if blah == True:
           print("True")
     if blah:
            print('blah True')

blah True
///

Blah is not True

One suggestion: instead, the passage above should say ?evaluates true in a boolean context?.

----------
assignee: docs at python
components: Documentation
messages: 230994
nosy: crkirkwood, docs at python
priority: normal
severity: normal
status: open
title: doc error: 6.2.4. Match Objects
type: resource usage
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 11 02:42:14 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 11 Nov 2014 01:42:14 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415670134.2.0.344236359804.issue22843@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's what "have a boolean value of True" means.  (ie: bool(<matchobject>) is True).  I'm neutral on whether or not it is worth changing the wording.

----------
nosy: +r.david.murray
type: resource usage -> behavior

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

From report at bugs.python.org  Tue Nov 11 08:42:47 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 07:42:47 +0000
Subject: [docs] [issue22845] Minor tweaks dis documentation
Message-ID: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch changes dis documentation:

* formats the *file* parameter with stars, not ``backticks``.
* adds missed links to opcodes.
* fixes POP_STACK to POP_TOP.

I hesitate about TOS and TOS1 words. Should they be highlighted in any manner?

----------
assignee: docs at python
components: Documentation
files: doc_dis.patch
keywords: patch
messages: 231003
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Minor tweaks dis documentation
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file37173/doc_dis.patch

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

From report at bugs.python.org  Tue Nov 11 08:51:23 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Nov 2014 07:51:23 +0000
Subject: [docs] [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <1415692283.3.0.454716070109.issue22845@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM. While at it, could you add a period after these:

+      Added *file* parameter

----------

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

From report at bugs.python.org  Tue Nov 11 09:06:06 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Nov 2014 08:06:06 +0000
Subject: [docs] [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <20141111080602.9603.73263@psf.io>


Roundup Robot added the comment:

New changeset d676f2725699 by Serhiy Storchaka in branch '3.4':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/d676f2725699

New changeset ac0334665459 by Serhiy Storchaka in branch 'default':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/ac0334665459

New changeset 0a32764004ab by Serhiy Storchaka in branch '2.7':
Issue #22845: Improved formatting of dis documentation.
https://hg.python.org/cpython/rev/0a32764004ab

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

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

From report at bugs.python.org  Tue Nov 11 09:16:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Nov 2014 08:16:20 +0000
Subject: [docs] [issue22845] Minor tweaks dis documentation
In-Reply-To: <1415691767.11.0.329151218594.issue22845@psf.upfronthosting.co.za>
Message-ID: <1415693779.94.0.80978850775.issue22845@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done. Thank you Georg for your review.

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

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

From report at bugs.python.org  Tue Nov 11 10:12:11 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 11 Nov 2014 09:12:11 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415697131.29.0.935222371599.issue22843@psf.upfronthosting.co.za>


Georg Brandl added the comment:

"evaluates true" should not be used in any case, the objects do not equal to True in any case.

The phrase "is considered true in a boolean context" is already in the docs and could be used here too.

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

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

From report at bugs.python.org  Tue Nov 11 17:56:41 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 11 Nov 2014 16:56:41 +0000
Subject: [docs] [issue22558] Missing hint to source code - complete
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1415725001.74.0.231294592897.issue22558@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

+1 "to add links to all the [Python] modules"

If the code is not readable, hard to understand or not self-documenting that's the reason to improve the code not to make it harder to find and see.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Nov 12 00:51:08 2014
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 11 Nov 2014 23:51:08 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1415749868.44.0.418498101854.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Ping! It's been about 3 months since this was given the green light...

----------

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

From report at bugs.python.org  Wed Nov 12 02:17:26 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 01:17:26 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1415755045.72.0.557355778479.issue21514@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/issue21514>
_______________________________________

From report at bugs.python.org  Wed Nov 12 07:33:44 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 12 Nov 2014 06:33:44 +0000
Subject: [docs] [issue19796] urllib2.HTTPError.reason is not documented as
	"Added in	2.7"
In-Reply-To: <1385459958.78.0.648544615764.issue19796@psf.upfronthosting.co.za>
Message-ID: <1415774024.52.0.429754158087.issue19796@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue 13211 was about a bug in exception hierarchy of the urllib2 module(not an addition to the public API - see msg147318 for detailed explanation). I don't think we need to update documentation.

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

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

From Laura-M.Niesemann at web.de  Sat Nov  1 12:04:54 2014
From: Laura-M.Niesemann at web.de (Laura M Niesemann)
Date: Sat, 1 Nov 2014 12:04:54 +0100
Subject: [docs] Win7 py2exe Bug
Message-ID: <trinity-c3019fe7-7691-4157-960d-ec9e0cfd44f2-1414839894875@3capp-webde-bs05>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141101/ec0fdfb2/attachment-0001.html>

From robertc at robertcollins.net  Mon Nov  3 11:01:47 2014
From: robertc at robertcollins.net (robertc at robertcollins.net)
Date: Mon, 03 Nov 2014 10:01:47 -0000
Subject: [docs] There is no standard TestCase.runTest implementation
	(issue 22153)
Message-ID: <20141103100147.10674.33382@psf.upfronthosting.co.za>


http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst
File Doc/library/unittest.rst (right):

http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#newcode657
Doc/library/unittest.rst:657: In most uses of :class:`TestCase`, you
will neither change
On 2014/10/31 18:00:26, ezio.melotti wrote:
> This line is indented wrong.

I can fix this up at commit time.

http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#newcode1561
Doc/library/unittest.rst:1561: If no methods with the usual name prefix
are found, but the ``runTest()`` method is implemented, there will be a
single test case using that method.
On 2014/10/31 18:00:26, ezio.melotti wrote:
> This line is too long, and also not too clear to me.
> What is the usual name prefix? "test_"?
> Does "a single test case" refers to *testCaseClass*?  What are test
cases should
> use runTest? What does "using" mean here?

TestClass('runTest') rather than TestClass('test_something'). It seems
clear enough to me, but I am probably too close to the implementation.
Do you have some suggested improvement to the prose?

The name prefix is indeed test_, but thats covered elsewhere I think.

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

From vadmium+py at gmail.com  Mon Nov 10 22:24:13 2014
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 10 Nov 2014 21:24:13 -0000
Subject: [docs] There is no standard TestCase.runTest implementation
	(issue 22153)
Message-ID: <20141110212413.6978.87865@psf.upfronthosting.co.za>

Reviewers: rbcollins, ezio.melotti,


http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst
File Doc/library/unittest.rst (right):

http://bugs.python.org/review/22153/diff/12734/Doc/library/unittest.rst#newcode1561
Doc/library/unittest.rst:1561: If no methods with the usual name prefix
are found, but the ``runTest()`` method is implemented, there will be a
single test case using that method.
I think this was my original wording. What about something like

A test case instance is created for each method named by
getTestCaseNames(). By default these are the method names beginning with
?test?. If getTestCaseNames() returns no methods, but the runTest()
method is implemented, a single test case is created for that method
instead.

Personally, I use runTest() for test case classes designed with a single
test method in mind. But I?m not sure the documentation should suggest
that.



Please review this at http://bugs.python.org/review/22153/

Affected files:
  Doc/library/unittest.rst


diff -r 3d45155b7b9b Doc/library/unittest.rst
--- a/Doc/library/unittest.rst	Sat Aug 16 22:54:24 2014 +0530
+++ b/Doc/library/unittest.rst	Sun Aug 17 01:58:13 2014 -0700
@@ -653,10 +653,8 @@
    kinds of failure.
 
    Each instance of :class:`TestCase` will run a single base method: the method
-   named *methodName*.  However, the standard implementation of the default
-   *methodName*, ``runTest()``, will run every method starting with ``test``
-   as an individual test, and count successes and failures accordingly.
-   Therefore, in most uses of :class:`TestCase`, you will neither change
+   named *methodName*.
+  In most uses of :class:`TestCase`, you will neither change
    the *methodName* nor reimplement the default ``runTest()`` method.
 
    .. versionchanged:: 3.2
@@ -1560,6 +1558,8 @@
       Return a suite of all tests cases contained in the :class:`TestCase`\ -derived
       :class:`testCaseClass`.
 
+      If no methods with the usual name prefix are found, but the ``runTest()`` method is implemented, there will be a single test case using that method.
+
 
    .. method:: loadTestsFromModule(module)
 



From Michael.Grazebrook at CliffordChance.com  Mon Nov 10 22:24:21 2014
From: Michael.Grazebrook at CliffordChance.com (Michael.Grazebrook at CliffordChance.com)
Date: Mon, 10 Nov 2014 21:24:21 +0000
Subject: [docs] datetime timezone handling
Message-ID: <EB9022E4800B9B47BFFD43EFC23AA5A611F1E2@lon-mb-07.internal.cliffordchance.net>

Hi

Concerning this documentation:
https://docs.python.org/3.5/library/datetime.html

Please could you provide some information about what timezones are supported by default with the %Z option. At the very least some warning that expecting %Z to match BST or EST is unlikely to work would have saved me many hours today. It might be useful to add a reference to PEP 431 in Note 6

Michael Grazebrook

[CC]Office1[/CC]



This message and any attachment are confidential and may be privileged or otherwise protected from disclosure.  If you are not the intended recipient, please notify the sender immediately and delete this message and any attachment from your system.  Do not copy them or disclose the contents to any other person.

Clifford Chance LLP is a limited liability partnership registered in England & Wales under number OC323571. CC Worldwide Limited is a company registered in England & Wales under number 5663642. The registered office and principal place of business of both is at 10 Upper Bank Street, London, E14 5JJ.  Both are authorised and regulated by the Solicitors Regulation Authority whose rules can be accessed at http://www.sra.org.uk/solicitors/handbook/code/content.page <http://www.sra.org.uk/solicitors/handbook/code/content.page>. For details of our complaints procedure, and of our policy on payment of interest on any money we hold for you in a client account, see http://www.cliffordchance.com/Legal_statements.html <http://www.cliffordchance.com/Legal_statements.html>  For further details of Clifford Chance, see our website at www.cliffordchance.com <http://www.cliffordchance.com>.
Email communications may be monitored by Clifford Chance, as permitted by applicable law and regulations.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141110/36fa06d9/attachment-0001.html>

From nhorspool at hotmail.com  Wed Nov 12 16:57:26 2014
From: nhorspool at hotmail.com (Nigel Horspool)
Date: Wed, 12 Nov 2014 15:57:26 +0000
Subject: [docs] =?utf-8?q?Minor_typo_in_Python3_documentation?=
Message-ID: <BAY405-EAS426438B4A4770C1D4E6C641BB8E0@phx.gbl>

Section 4.6.3 has, in the list of operations on mutable lists/sequences, the following entry:

   s.pop([i])   retrieves the item at i and also removes it from s


That should of course read:

   s.pop(i)      retrieves the item at i and also removes it from s




--


NH




Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141112/17984fe8/attachment-0001.html>

From report at bugs.python.org  Wed Nov 12 18:37:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:37:39 +0000
Subject: [docs] [issue22855] csv writer with blank lineterminator breaks
	quoting
In-Reply-To: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>
Message-ID: <1415813859.24.0.623525412645.issue22855@psf.upfronthosting.co.za>


R. David Murray added the comment:

Also, it is hard to see how to make this clearer:

csv.QUOTE_MINIMAL
Instructs writer objects to only quote those fields which contain special characters such as delimiter, quotechar or any of the characters in lineterminator.

Hmm.  Perhaps it would be a bit clearer if it said "... which contain the special characters delimiter, quotechar, ..."

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

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

From report at bugs.python.org  Wed Nov 12 18:37:50 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 12 Nov 2014 17:37:50 +0000
Subject: [docs] [issue22855] csv writer with blank lineterminator breaks
	quoting
In-Reply-To: <1415811903.81.0.569163118403.issue22855@psf.upfronthosting.co.za>
Message-ID: <1415813870.64.0.5750335748.issue22855@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 12 18:45:55 2014
From: report at bugs.python.org (Ben Finney)
Date: Wed, 12 Nov 2014 17:45:55 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415814355.25.0.0850788834647.issue22843@psf.upfronthosting.co.za>


Ben Finney added the comment:

The current wording of the passage ?Match objects always have a boolean value of True? implies that the value compares equal to the ?True? constant. That implication is incorrect.

I disagree with R. David Murray; if we want to say that a value is considered true *in a boolean context*, that's very different from saying it has the ?True? value.

Georg, ?evaluates true in a boolean context? has the meaning you're seeking; it is chosen precisely because it does *not* imply equality to the True constant.

----------
nosy: +bignose

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

From report at bugs.python.org  Thu Nov 13 15:28:38 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 13 Nov 2014 14:28:38 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
Message-ID: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The documentation shown for Python 2.7.8 currently includes 2.7.9 parts, e.g. for the ssl modules (https://docs.python.org/2.7/library/ssl.html).

Since there were so many changes to the ssl module for 2.7.9 which are not available in 2.7.8, I think it would be good to be able to not only select "2.7.8" from the doc version drop-down, but to also really get that particular version of the documentation, and provide a separate "2.7.9" snapshop as well.

I tried https://docs.python.org/2.7.8/library/ssl.html, but that doesn't seem to exist.

PS: I'm not sure whether this is the right tracker to report this. Feel free to move it elsewhere.

----------
assignee: docs at python
components: Documentation
messages: 231113
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: https://docs.python.org/ should make a true 2.7.8 version available
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov 13 15:36:00 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Nov 2014 14:36:00 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1415889360.91.0.638324297642.issue22863@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

There's https://docs.python.org/release/2.7.8/

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu Nov 13 19:01:26 2014
From: report at bugs.python.org (Geoff Shannon)
Date: Thu, 13 Nov 2014 18:01:26 +0000
Subject: [docs] [issue22865] Allow pty.spawn to ignore data to copy
Message-ID: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>


New submission from Geoff Shannon:

While using the pty.py module I had cause to want to be able to silently eat characters from the input stream.  I discovered that because of the check for end of file being "if not data" that there was no way to do this.

Since the default function used by spawn and _copy is a thin wrapper on os.read, I figured that it would be useful to interpret None as a sentinel value meaning "this is not EOF, but there's nothing I actually want to copy over."

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: pty.patch
keywords: patch
messages: 231126
nosy: RadicalZephyr, docs at python
priority: normal
severity: normal
status: open
title: Allow pty.spawn to ignore data to copy
type: enhancement
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/file37189/pty.patch

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

From report at bugs.python.org  Thu Nov 13 21:52:37 2014
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 13 Nov 2014 20:52:37 +0000
Subject: [docs] [issue22867] document behavior of calling atexit.register()
	while	atexit._run_exitfuncs is running
Message-ID: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

A discussion on comp.lang.python about prettying up the "if __name__ == 'main__'" idiom led to a suggestion that a decorator could simple register the main function using atexit.register. That looks like it will work, but leaves open the possibility that while main() is running via atexit._run_exitfuncs, other exit functions might be registered.

As currently defined (at least in the Python version with 2.7), I think everything will work fine. Still, the behavior of adding new exit functions during exit is not defined. Would be kind of nice if this behavior was blessed, and then mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 231135
nosy: docs at python, skip.montanaro
priority: low
severity: normal
status: open
title: document behavior of calling atexit.register() while atexit._run_exitfuncs is running

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

From report at bugs.python.org  Thu Nov 13 21:57:55 2014
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 13 Nov 2014 20:57:55 +0000
Subject: [docs] [issue22867] document behavior of calling atexit.register()
	while	atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1415912275.53.0.906035061157.issue22867@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/issue22867>
_______________________________________

From report at bugs.python.org  Fri Nov 14 07:34:23 2014
From: report at bugs.python.org (Yi Bai)
Date: Fri, 14 Nov 2014 06:34:23 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
Message-ID: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>


New submission from Yi Bai:

Hi, I suppose there is a minor error in the example of the filter() function in 5.1.3 part of the document.

------------------------------------------------------------------
filter(function, sequence) returns a sequence consisting of those items from the sequence for which function(item) is true. If sequence is a string or tuple, the result will be of the same type; otherwise, it is always a list. For example, to compute a sequence of numbers not divisible by 2 or 3:

>>>
>>> def f(x): return x % 2 != 0 and x % 3 != 0
...
>>> filter(f, range(2, 25))
[5, 7, 11, 13, 17, 19, 23]
------------------------------------------------------------------

I think what the example does is "to compute a sequence of numbers not divisible by 2 and 3", not "2 or 3".

----------
assignee: docs at python
components: Documentation
messages: 231149
nosy: docs at python, enchyisle
priority: normal
severity: normal
status: open
title: Minor error in the example of filter()
type: resource usage

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

From report at bugs.python.org  Fri Nov 14 08:38:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 07:38:27 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415950707.12.0.760010790338.issue22868@psf.upfronthosting.co.za>


Georg Brandl added the comment:

For me the text is correct.  However, it depends on parsing the English sentence in the right way, which can be confusing.  The prose means "not (divisible by 2 or 3)" which is equivalent to "not divisible by 2 and not divisible by 3", therefore the Python code has an "and" operator.

It would probably be best to remove the negation, which also removes the ambiguity: "compute a sequence of numbers divisible by 2 or 3" or such.

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

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

From report at bugs.python.org  Fri Nov 14 11:07:20 2014
From: report at bugs.python.org (Yi Bai)
Date: Fri, 14 Nov 2014 10:07:20 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415959640.9.0.523884474876.issue22868@psf.upfronthosting.co.za>


Yi Bai added the comment:

Ah yes. You are right, Georg.
And as you suggested, it might be better to remove this ambiguity, for people with poor parsing skills like me. :)

----------

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

From report at bugs.python.org  Fri Nov 14 11:13:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 14 Nov 2014 10:13:50 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <20141114101306.57224.59104@psf.io>


Roundup Robot added the comment:

New changeset 5dd835edde1e by Georg Brandl in branch '2.7':
Closes #22868: make example less ambiguous.
https://hg.python.org/cpython/rev/5dd835edde1e

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

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

From report at bugs.python.org  Fri Nov 14 11:14:35 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 10:14:35 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415960075.92.0.0561579170411.issue22868@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Done. Thanks for the report!

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

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

From report at bugs.python.org  Fri Nov 14 11:20:18 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 14 Nov 2014 10:20:18 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1415960418.39.0.149955158583.issue22868@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 14 16:56:01 2014
From: report at bugs.python.org (=?utf-8?q?Santiago_Palacio_G=C3=B3mez?=)
Date: Fri, 14 Nov 2014 15:56:01 +0000
Subject: [docs] [issue22871] datetime documentation incomplete
Message-ID: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>


New submission from Santiago Palacio G?mez:

In the datetime documentation page https://docs.python.org/2/library/datetime.html
In the directive sections, there are a few things that are not documented there. I really don't know all the possible directives, but the few examples I'm aware of, and how they seem to work for me:
%D seems to behave as the default %x (None locale)
%h seems to behave as %b

----------
assignee: docs at python
components: Documentation
messages: 231162
nosy: docs at python, spalac24
priority: normal
severity: normal
status: open
title: datetime documentation incomplete
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov 14 18:24:12 2014
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 14 Nov 2014 17:24:12 +0000
Subject: [docs] [issue22871] datetime documentation incomplete
In-Reply-To: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>
Message-ID: <1415985852.33.0.240669524382.issue22871@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky, ethan.furman, lemburg

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

From report at bugs.python.org  Fri Nov 14 20:14:38 2014
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 14 Nov 2014 19:14:38 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1415992478.63.0.925885519925.issue16802@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

To me, there's also a valid use case on Unix; A parent process forks and execs, wanting to share a socket to the executed child process. The best way for the child to create a socket object is to use the fileno parameter of socket.socket().

----------
nosy: +petri.lehtinen

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

From report at bugs.python.org  Fri Nov 14 20:15:17 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 19:15:17 +0000
Subject: [docs] [issue22822] IPv6Network constructor docs incorrect about
	valid input
In-Reply-To: <1415468629.6.0.255055357939.issue22822@psf.upfronthosting.co.za>
Message-ID: <1415992517.68.0.62882869558.issue22822@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +ncoghlan, pmoody

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

From report at bugs.python.org  Fri Nov 14 20:31:29 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 14 Nov 2014 19:31:29 +0000
Subject: [docs] [issue22871] datetime documentation incomplete
In-Reply-To: <1415980561.47.0.0764312378681.issue22871@psf.upfronthosting.co.za>
Message-ID: <1415993489.3.0.679175900293.issue22871@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

If you read the paragraph preceding the table of directives [1], you will see that "The full set of format codes supported varies across platforms, because Python calls the platform C library?s strftime() function, and platform variations are common. To see the full set of format codes supported on your platform, consult the strftime(3) documentation."


[1] https://docs.python.org/2/library/datetime.html#strftime-and-strptime-behavior

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

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

From report at bugs.python.org  Fri Nov 14 21:01:44 2014
From: report at bugs.python.org (Corbin Simpson)
Date: Fri, 14 Nov 2014 20:01:44 +0000
Subject: [docs] [issue22875] asyncio: call_soon() documentation unclear on
	timing
Message-ID: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>


New submission from Corbin Simpson:

Hi there!

While assisting somebody on #python (where manners go to die), I was consulting asyncio's documentation. Given my unfamiliarity with asyncio, I was surprised to read BaseEventLoop.call_soon()'s documented behavior: "Arrange for a callback to be called as soon as possible." [1]

The question in mind is whether call_soon() waits for control to return to the event loop before calling the first callback in the queue. After all, given the documented behavior, it would not be unreasonable for call_soon() to always call callbacks immediately if no other callbacks were enqueued. I can imagine scenarios where a previous queued callback from e.g. call_soon_threadsafe() creates a callback that causes queueing behavior, but otherwise I would expect "as soon as possible" to mean "immediately".

It's true that in other event loops, this kind of callback registration waits for control to return to the event loop before running callbacks. However, many event loops that I've worked with indicate that call_later() is the correct API for adding callbacks that respect the event loop. In fact, call_later(0, callback, args) looks quite a bit like the familiar Twisted callLater(0, callback, args) pattern!

Additionally, there is no indication as to whether call_later() and call_soon() use the same queue.

I'd like clarification on these points in the Python 3 documentation, please. I'd like to know whether call_soon() can be immediate, and whether call_soon() preempts or interleaves with call_later().

(Yes, I know that Twisted's documentation is missing this too [2] [3]. I'll get to that soon enough.)

Thanks!
~ C.

[1]: https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_soon
[2]: http://twistedmatrix.com/documents/current/core/howto/time.html
[3]: http://twistedmatrix.com/documents/current/api/twisted.internet.interfaces.IReactorTime.html#callLater

----------
assignee: docs at python
components: Documentation, asyncio
messages: 231180
nosy: Corbin.Simpson, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: call_soon() documentation unclear on timing

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

From report at bugs.python.org  Fri Nov 14 21:03:51 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Nov 2014 20:03:51 +0000
Subject: [docs] [issue22875] asyncio: call_soon() documentation unclear on
	timing
In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>
Message-ID: <1415995431.2.0.11220239099.issue22875@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

"As soon as possible" is constrained by "all callbacks are called from the event loop".

Feel free to suggest a doc patch (asyncio docs are in dire need of more help!)

----------

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

From report at bugs.python.org  Fri Nov 14 21:08:50 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 14 Nov 2014 20:08:50 +0000
Subject: [docs] [issue22875] asyncio: call_soon() documentation unclear on
	timing
In-Reply-To: <1415995304.37.0.00737491261157.issue22875@psf.upfronthosting.co.za>
Message-ID: <1415995730.0.0.763523318164.issue22875@psf.upfronthosting.co.za>


R. David Murray added the comment:

Personally, when I read that I thought "arrange for" made it pretty clear it was when control returned to the event loop, but I agree that if it can be made clearer it should be.

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

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

From report at bugs.python.org  Fri Nov 14 22:03:34 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:03:34 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415669163.97.0.11938367664.issue22843@psf.upfronthosting.co.za>
Message-ID: <1415999014.71.0.778448837562.issue22843@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

David is correct that the current phrasing is correct.  The phase 'x has a boolean value of True' means 'bool(x) is True', which is always true for match objects, as well as for non-zero numbers, non-empty collections, and many other things.  This does *not* imply equality between the object and its boolean value.  In fact, nearly all objects are not equal to their boolean value.  Clayton could just as well as have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-surprising result.

There is nothing special about boolean values in this respect.  The string value of x is str(x) and in general, x != str(x).  (This also sometimes confuses people.)  Similarly, if x has an integral value int(x), it does not necessarily equal that value: int(3.1459) != 3.

I think the doc is fine as is.  The fact that "3 is considered to be '3' in a display context" does not mean that we do not write "the string value of 3 is '3'".  It is fundamental to Python that essentially all objects o have a string value str(o) and a boolean value bool(o) and that those mappings are sometimes used automatically for display and logic.

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

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

From report at bugs.python.org  Fri Nov 14 22:25:16 2014
From: report at bugs.python.org (Clayton Kirkwood)
Date: Fri, 14 Nov 2014 21:25:16 +0000
Subject: [docs] [issue22843] doc error: 6.2.4. Match Objects
In-Reply-To: <1415999014.71.0.778448837562.issue22843@psf.upfronthosting.co.za>
Message-ID: <06ea01d00051$6945afb0$3bd10f10$@us>


Clayton Kirkwood added the comment:

Cool

>-----Original Message-----
>From: Terry J. Reedy [mailto:report at bugs.python.org]
>Sent: Friday, November 14, 2014 1:04 PM
>To: crk at godblessthe.us
>Subject: [issue22843] doc error: 6.2.4. Match Objects
>
>
>Terry J. Reedy added the comment:
>
>David is correct that the current phrasing is correct.  The phase 'x has
>a boolean value of True' means 'bool(x) is True', which is always true
>for match objects, as well as for non-zero numbers, non-empty
>collections, and many other things.  This does *not* imply equality
>between the object and its boolean value.  In fact, nearly all objects
>are not equal to their boolean value.  Clayton could just as well as
>have written "blah = 'a'" or "blah = 1 + 1j" and gotten the name non-
>surprising result.
>
>There is nothing special about boolean values in this respect.  The
>string value of x is str(x) and in general, x != str(x).  (This also
>sometimes confuses people.)  Similarly, if x has an integral value
>int(x), it does not necessarily equal that value: int(3.1459) != 3.
>
>I think the doc is fine as is.  The fact that "3 is considered to be '3'
>in a display context" does not mean that we do not write "the string
>value of 3 is '3'".  It is fundamental to Python that essentially all
>objects o have a string value str(o) and a boolean value bool(o) and
>that those mappings are sometimes used automatically for display and
>logic.
>
>----------
>nosy: +terry.reedy
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue22843>
>_______________________________________

----------

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

From report at bugs.python.org  Fri Nov 14 22:35:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 21:35:29 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416000929.26.0.647445882875.issue22863@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

New stuff is marked "New in version 2.7.9.", etc.  The Idle chapter (reletively new in the Library Reference itself) has the same problem if new or quasi-new features in micro-releases are added to the doc before the release.

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

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

From report at bugs.python.org  Fri Nov 14 22:51:15 2014
From: report at bugs.python.org (Ryan Hartkopf)
Date: Fri, 14 Nov 2014 21:51:15 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1416001875.71.0.388075828475.issue9694@psf.upfronthosting.co.za>


Ryan Hartkopf added the comment:

Personally, 'options' is the first word that comes to mind other than 'arguments' (which is confusing for obvious reasons). But I think we can all agree that any of these candidates are less ambiguous than 'optional arguments'! It's been 4 years, let's put this one to bed!

----------
nosy: +rhartkopf
Added file: http://bugs.python.org/file37200/argparse_option.patch

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

From report at bugs.python.org  Fri Nov 14 22:55:19 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 14 Nov 2014 21:55:19 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
In-Reply-To: <1416000929.26.0.647445882875.issue22863@psf.upfronthosting.co.za>
Message-ID: <54667A40.4040406@egenix.com>


Marc-Andre Lemburg added the comment:

On 14.11.2014 22:35, Terry J. Reedy wrote:
> New stuff is marked "New in version 2.7.9.", etc.  The Idle chapter (reletively new in the Library Reference itself) has the same problem if new or quasi-new features in micro-releases are added to the doc before the release.

I know, but there are so many additions in the ssl module that it's
very difficult to tell what actually was part of earlier Python 2.7
releases.

I think best would be to link to the release URL Bejamin mentioned
for "2.7.8" and provide the trunk version as "2.7 (trunk)".
The same should probably be done for the other releases listed
in the selector.

----------

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

From report at bugs.python.org  Fri Nov 14 23:18:07 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 14 Nov 2014 22:18:07 +0000
Subject: [docs] [issue22867] document behavior of calling atexit.register()
	while	atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1416003487.6.0.730108868678.issue22867@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/issue22867>
_______________________________________

From report at bugs.python.org  Sat Nov 15 00:18:25 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 14 Nov 2014 23:18:25 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416007104.96.0.927390322372.issue22863@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that "x.y.z" should be reserved for the frozen release version of the docs and that the current ongoing version should be "x.y (trunk)" or "x.y.z+".  This was true without new features in a micro release, but did not matter so much.  Leaving Idle aside, I am not sure how we should handle the new exception in other stdlib modules.  There may or may not be more documented additions past 2.7.9.

----------

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

From report at bugs.python.org  Sat Nov 15 01:19:21 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 15 Nov 2014 00:19:21 +0000
Subject: [docs] [issue22863] https://docs.python.org/ should make a true
	2.7.8	version available
In-Reply-To: <1415888918.09.0.104485569089.issue22863@psf.upfronthosting.co.za>
Message-ID: <1416010761.35.0.621398147922.issue22863@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/issue22863>
_______________________________________

From report at bugs.python.org  Sat Nov 15 06:08:00 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 15 Nov 2014 05:08:00 +0000
Subject: [docs] [issue22868] Minor error in the example of filter()
In-Reply-To: <1415946863.39.0.61005418871.issue22868@psf.upfronthosting.co.za>
Message-ID: <1416028080.63.0.864311103121.issue22868@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved

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

From report at bugs.python.org  Sun Nov 16 04:25:58 2014
From: report at bugs.python.org (Roy Smith)
Date: Sun, 16 Nov 2014 03:25:58 +0000
Subject: [docs] [issue22880] hmac.new docs show optional args incorrectly
Message-ID: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>


New submission from Roy Smith:

At https://docs.python.org/2/library/hmac.html, hmac.new() is shown as

hmac.new(key[, msg[, digestmod]])

This implies that digestmod can only be given if msg is given.  This is incorrect.  Either can be given without the other.

----------
assignee: docs at python
components: Documentation
messages: 231231
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: hmac.new docs show optional args incorrectly
versions: Python 2.7

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

From report at bugs.python.org  Sun Nov 16 09:22:59 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 16 Nov 2014 08:22:59 +0000
Subject: [docs] [issue22880] hmac.new docs show optional args incorrectly
In-Reply-To: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>
Message-ID: <1416126179.08.0.121560201279.issue22880@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but the signature is correct.

>From https://docs.python.org/devguide/documenting.html#information-units

    "The signature should include the parameters, enclosing optional parameters in brackets."

See also http://sphinx-doc.org/domains.html#python-signatures

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

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

From report at bugs.python.org  Sun Nov 16 14:07:51 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 13:07:51 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
Message-ID: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>


New submission from Ludovic Gasc:

Hi,

To install easily Python 3.4.2 on Linux, I use Pythonz: http://saghul.github.io/pythonz/

I've discovered that, depends on the packages already installed on Linux, I don't have the same Python each time after compilation on servers.
Some features could missing, like pip, if you don't install some packages.

I've made a pull request in Pythonz with the list of packages you need to avoid that: https://github.com/saghul/pythonz#before-installing-pythons-via-pythonz

But, for me, this packages list should be in official Python documentation directly.

I've tested this packages list on Debian (Squeeze, Wheezy, Jessie, Sid), Ubuntu (12.04, 14.04) and CentOS 6.

Thanks for the merge.

Regards.

----------
assignee: docs at python
components: Documentation
files: build_dep_python.patch
keywords: patch
messages: 231245
nosy: Ludovic.Gasc, docs at python
priority: normal
severity: normal
status: open
title: [patch] Linux packages you need to compile Python with all dependencies
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file37208/build_dep_python.patch

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

From report at bugs.python.org  Sun Nov 16 17:54:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Nov 2014 16:54:44 +0000
Subject: [docs] [issue22880] hmac.new docs show optional args incorrectly
In-Reply-To: <1416108358.14.0.735594371986.issue22880@psf.upfronthosting.co.za>
Message-ID: <1416156884.23.0.453731466503.issue22880@psf.upfronthosting.co.za>


R. David Murray added the comment:

To be clear: this was/is the python2 documentation style.  In python3 we've switched to using keyword argument notation in functions that support specifying optional arguments via keyword (which is many more of the C functions than in python2).

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

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

From report at bugs.python.org  Sun Nov 16 18:00:49 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 16 Nov 2014 17:00:49 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416157249.51.0.373639683782.issue22882@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think it is a good idea for us to try to track which packages are needed and what they are named by the various downstreams.  We could document the optional modules by project name, though.  Note also that the devguide does point to the "umbrella" downstream packages that pull in the dependencies needed to build python, where those exist.

It is likely that that section should cross link to the devguide.  The devguide didn't exist when it was written.

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

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

From report at bugs.python.org  Sun Nov 16 21:01:31 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 20:01:31 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416168091.48.0.23281864511.issue22882@psf.upfronthosting.co.za>


Ludovic Gasc added the comment:

I'm not agree with you: I've lost a lot of time to find all packages I need for that, I've merged information from several blog posts.
I imagine that I'm not alone with this problem.

If you move this information in devguide, most persons don't find this.

Moreover, the names of packages are pretty stable across Linux versions, I don't think we will have a lot of exceptions.

----------

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

From report at bugs.python.org  Sun Nov 16 21:14:35 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 16 Nov 2014 20:14:35 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416168875.4.0.06849445229.issue22882@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

For Ubuntu/debian you can just run:
$ sudo apt-get build-dep python3

----------
nosy: +asvetlov

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

From report at bugs.python.org  Sun Nov 16 21:46:30 2014
From: report at bugs.python.org (Ludovic Gasc)
Date: Sun, 16 Nov 2014 20:46:30 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416170790.34.0.00118688608051.issue22882@psf.upfronthosting.co.za>


Ludovic Gasc added the comment:

> $ sudo apt-get build-dep python3

Good to know, I will test for my next deployment.
The only problem with that, if you use a old Debian with a Python3 that need less dependencies that actual version.
But you can add a line for that in documentation if we have the case one day.

----------

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

From report at bugs.python.org  Mon Nov 17 04:31:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:31:43 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416195103.83.0.626052853135.issue22882@psf.upfronthosting.co.za>


R. David Murray added the comment:

The fact that it cost you a lot of time buttresses my point.  Any documentation we write is likely to get stale; it is only the downstream that knows when these things change and could maintain such a document.  And the easy answer is as Andrew indicated, which is maintained by downstream.  That said, if the various downstreams are using a unified set of names, then the equation would change.  The fact that you had separate sections for separate distributions argues that that is not (yet?) the case, though.

The build instructions in the devguide are more likely to be kept up to date, which is why I suggested we should cross link to them from the main build documentation.

----------

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

From report at bugs.python.org  Mon Nov 17 04:31:51 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:31:51 +0000
Subject: [docs] [issue22882] [patch] Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416195111.91.0.317083494697.issue22882@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.6

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

From report at bugs.python.org  Mon Nov 17 04:48:22 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 03:48:22 +0000
Subject: [docs] [issue22882] Document Linux packages you need to compile
	Python with	all dependencies
In-Reply-To: <1416143270.93.0.294099488714.issue22882@psf.upfronthosting.co.za>
Message-ID: <1416196102.56.0.14568028228.issue22882@psf.upfronthosting.co.za>


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


----------
title: [patch] Linux packages you need to compile Python with all dependencies -> Document Linux packages you need to compile Python with all dependencies

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

From report at bugs.python.org  Mon Nov 17 09:50:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 08:50:52 +0000
Subject: [docs] [issue18697] Unify arguments names in Unicode object C
	API	documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1416214252.43.0.606415203602.issue18697@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The same issue exists for other types. E.g. PyLong_* functions have Python long argument named as p, obj and pylong, PyFloat_* -- p and pyfloat, PyList_* -- p and list, PyDict_* -- p, a and mapping, PyBytes_* -- o, obj, string and bytes.

----------

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

From report at bugs.python.org  Mon Nov 17 16:37:18 2014
From: report at bugs.python.org (Martin Gignac)
Date: Mon, 17 Nov 2014 15:37:18 +0000
Subject: [docs] [issue22892] Typo in Library's 'threading' module section
Message-ID: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>


New submission from Martin Gignac:

There is an extraenous asterisk in the constructor description for class 'threading.Thread' in section 17.1.2. "Thread Objects" of the 'threading' module in the Python Standard Library documenation.

(patch attached)

----------
assignee: docs at python
components: Documentation
files: threading.rst.patch
keywords: patch
messages: 231284
nosy: docs at python, techstone
priority: normal
severity: normal
status: open
title: Typo in Library's 'threading' module section
versions: Python 3.4
Added file: http://bugs.python.org/file37214/threading.rst.patch

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

From report at bugs.python.org  Mon Nov 17 16:48:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 17 Nov 2014 15:48:39 +0000
Subject: [docs] [issue22892] Typo in Library's 'threading' module section
In-Reply-To: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>
Message-ID: <1416239319.61.0.0449546754397.issue22892@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for taking the time to make a report, but that is not a typo.  That asterisk indicates that daemon is a keyword only argument, and is standard python3 syntax.  You can see it if you follow the source link to the threading module.

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

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

From report at bugs.python.org  Mon Nov 17 17:02:06 2014
From: report at bugs.python.org (Martin Gignac)
Date: Mon, 17 Nov 2014 16:02:06 +0000
Subject: [docs] [issue22892] Typo in Library's 'threading' module section
In-Reply-To: <1416238638.39.0.769056339447.issue22892@psf.upfronthosting.co.za>
Message-ID: <1416240126.45.0.208656854259.issue22892@psf.upfronthosting.co.za>


Martin Gignac added the comment:

Sorry for that. I've read up PEP 3102 and now understand what you meant.

Sorry for the noise.

----------

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

From report at bugs.python.org  Mon Nov 17 22:20:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Nov 2014 21:20:52 +0000
Subject: [docs] [issue18688] Document undocumented Unicode object API
In-Reply-To: <1375989166.23.0.200448183394.issue18688@psf.upfronthosting.co.za>
Message-ID: <1416259253.0.0.39602346767.issue18688@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.3

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

From nhammond at sevone.com  Fri Nov 14 21:02:08 2014
From: nhammond at sevone.com (Nathan Hammond)
Date: Fri, 14 Nov 2014 15:02:08 -0500
Subject: [docs] Documentation Bug - 404 Error
Message-ID: <CAMROhvH-KtRWAq+Ko=QqU=kNW3YS-WZPessGedYuCp6UBwfciQ@mail.gmail.com>

Page:
https://docs.python.org/2.7/tutorial/controlflow.html#intermezzo-coding-style

Sentence: For Python, *PEP 8* <http://www.python.org/dev/peps/pep-0008> has
emerged as the style guide that most projects adhere to; it promotes a very
readable and eye-pleasing coding style. Every Python developer should read
it at some point; here are the most important points extracted for you

The link for PEP8 (https://www.python.org/dev/peps/pep-0008) goes to a
custom 404 error page.

-- 
 
------------------------------

SevOne, Inc. reserves the right to monitor the transmission of this message 
and to take corrective action against any misuse or abuse of its e-mail 
system or other components of its network.

The information contained in this e-mail may be confidential and/or legally 
privileged. It is intended solely for the addressee.  If the reader of this 
message is not an intended recipient, you are hereby notified that any 
unauthorized review, use, disclosure, dissemination, distribution, or 
copying of this communication, or any of its contents, is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please reply to the sender and destroy all copies of the message. 
 To contact us directly, send to postmaster at sevone.com. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141114/47d6cfaa/attachment-0001.html>

From nipun at nepdroid.com  Sat Nov 15 09:50:23 2014
From: nipun at nepdroid.com (Nipun Shakya)
Date: Sat, 15 Nov 2014 14:35:23 +0545
Subject: [docs] Regarding 3.4.2 Documentation download
Message-ID: <CAN8u9hQTTj4eiXeNcbe7t2SA+pQVmDFjFU6YF0dsR1un0Z=bMw@mail.gmail.com>

Dear admin,

It is sad to let you know that only the EPUB format of the documentation is
successfully downloaded. The other documentations available in formats like
PDF and US letter formats are stuck with downloads. The download remains
incomplete.

Please fix this.


Regards,
Nipun Shakya
Nepdroid Innovations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141115/a21e118c/attachment-0001.html>

From eddy at chaos.org.uk  Mon Nov 17 15:24:24 2014
From: eddy at chaos.org.uk (Edward Welbourne)
Date: Mon, 17 Nov 2014 14:24:24 +0000
Subject: [docs] doctest documentation suggestion
Message-ID: <E1XqNE8-0007fL-GN@utter.chaos.org.uk>

Hi doc-team,

Various comments upon reading:
https://docs.python.org/2/library/doctest.html

In documenting doctest.IGNORE_EXCEPTION_DETAIL, you give an example that
expects "ValueError: 42" (an obvious reference to HHGTTG) and points out
that it'll pass (when the option is enabled) for "ValueError: 3*14",
which is perfectly valid arithmetic for 42; the example would be
marginally more specific if it used ValueError: 6*9, since the fact that
6*9 isn't equal to 42 (unless you use base thirteen) avoids a (very
unlikely) potential confusion for the reader who might think the 3*14
only worked because 3*14 = 42.  Of course, the real reason for
suggesting this change is that 6*9 is what HHGTTG ends up giving us as
the question whose answer is 42.


Further down, in 25.2.3.6. Directives, I notice the syntax BNFL includes
visible backslashes that presumably shouldn't be; directive_options ends
in "\*" rather than simply "*" and the various uses of '|' are all '\|'
instead.


In 25.2.3.7. Warnings, where you mention I/2.**J, the mathematician in
me wants you to call them "diadic rationals", but the programmer me is
not persuaded it belongs in this documentation !  If the numerator's
binary representation, after stripping all leading and trailing zeros,
is too long then even a number of this form is not in fact safe.


Under doctest.testfile, I see:
> Optional argument parser specifies a DocTestParser (or subclass) that
> should be used to extract tests from the files. It defaults to a
> normal parser (i.e., DocTestParser()).

I am left unclear as to whether this argument should be the class or an
instance of it.  I suspect the latter, in which case the "(or subclass)"
should say "(or subclass instance)"; or "a DocTestParser (or subclass)"
should say "a DocTestParser (or subclass) instance".  This phrasing also
appears elsewhere in the page, wherever a parser argument appears.


Under doctest.testmod, I see:
> Also test examples reachable from dict m.__test__

with no hint that classes within m are similarly searched for __test__
dict()s, which I had understood the informal introduction to say would
also be searched.  That was section 25.2.3.1, which actually, just after
talking about the module's .__test__, just said:

> Any classes found are recursively searched similarly, to test
> docstrings in their contained methods and nested classes.

I guess that didn't actually say classes are searched for __test__ after
all, but putting this right after the __test__ discussion - and using
"similarly" - left me interpolating that.  If classes within the module
are not checked for a __test__ attribute, I think it would be clearer to
move the "recurse into classes" paragraph from the end of 25.2.3.1 to
before the .__test__ complication, which would then be clearly
applicable only to the module itself (it starts "In addition...").

Back in doctest.testmod's Basic API documentation, right after talking
about finding things in .__test__, it says:

> Only docstrings attached to objects belonging to module m are searched.

which may mislead a reader into thinking that values of .__test__ are
ignored if they don't belong to the module.  I think this sentence would
be better expressed (anyway) as:

  Only objects belonging to module m are searched for docstrings.

thus making it clear that the "only" is limiting the hunt for
docstrings, not limiting the entries in .__test__.  I think we can take
as give the search, within each docstring, for interactive examples.

	Eddy.

From report at bugs.python.org  Wed Nov 19 06:08:20 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 19 Nov 2014 05:08:20 +0000
Subject: [docs] [issue22867] document behavior of calling atexit.register()
	while	atexit._run_exitfuncs is running
In-Reply-To: <1415911957.21.0.792604038872.issue22867@psf.upfronthosting.co.za>
Message-ID: <1416373700.52.0.791964052479.issue22867@psf.upfronthosting.co.za>


Ethan Furman added the comment:

>From a post by Ian Kelly (https://mail.python.org/pipermail/python-list/2014-November/681073.html)
--------------------------------------------------------------
In fact it seems the behavior does differ between Python 2.7 and Python 3.4:

$ cat testatexit.py
import atexit

@atexit.register
def main():
  atexit.register(goodbye)

@atexit.register
def goodbye():
  print("Goodbye")
$ python2 testatexit.py
Goodbye
Goodbye
$ python3 testatexit.py
Goodbye

----------

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

From report at bugs.python.org  Wed Nov 19 10:15:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Nov 2014 09:15:37 +0000
Subject: [docs] [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#",
	but "Py_ssize_t" for "w#", etc.
In-Reply-To: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>
Message-ID: <1416388537.68.0.691714947955.issue20296@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov 19 16:38:16 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Nov 2014 15:38:16 +0000
Subject: [docs] [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#",
	but "Py_ssize_t" for "w#", etc.
In-Reply-To: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>
Message-ID: <1416411496.39.0.378873857953.issue20296@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo, serhiy.storchaka

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

From report at bugs.python.org  Fri Nov 21 18:46:47 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 21 Nov 2014 17:46:47 +0000
Subject: [docs] [issue22394] Update documentation building to use venv and
	pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1416592007.36.0.250950848773.issue22394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'm going to at least update the Makefile to have a ``make venv`` that will do the steps necessary to create a venv and then check out the necessary tools. It should also be set up so that running the command with a pre-existing venv will update it. This should all lead to commands like ``make html PYTHON=venv/bin/python3`` to work.

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

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

From report at bugs.python.org  Sat Nov 22 01:21:32 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 00:21:32 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1416615692.71.0.0295565415553.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Anybody?

----------

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

From report at bugs.python.org  Sat Nov 22 03:22:43 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Nov 2014 02:22:43 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1416615692.71.0.0295565415553.issue19980@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-OUobYbJqVkGkdE4zAVtoUOfY3_d5FOrCbQAMxZuDGgeA@mail.gmail.com>


Zachary Ware added the comment:

Mark, did you test your latest patch?

----------

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

From ggstuart at gmail.com  Tue Nov 18 18:42:27 2014
From: ggstuart at gmail.com (Graeme Stuart)
Date: Tue, 18 Nov 2014 17:42:27 +0000
Subject: [docs] collections.Counter - incorrect usage in documentation
Message-ID: <CAMq9tBkvwHrauPgNNE=a=of97_MC01c3G-v1BZbFCjnENh__cA@mail.gmail.com>

Hi,

I think this section in the docs
<https://docs.python.org/2/library/collections.html#counter-objects> shows
incorrect and confusing usage for the Counter class.

>>> # Tally occurrences of words in a list>>> cnt = Counter()>>> for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:...     cnt[word] += 1>>> cntCounter({'blue': 3, 'red': 2, 'green': 1})


The example provided iterates over a list of words and manually calculates
the totals as would be done when using e.g. a defaultdict(int) approach. It
uses no features that the Counter specifically provides.

The point of the Counter class is that it does this work for you. The
correct usage is as follows:

>>> words = ['red', 'blue', 'red', 'green', 'blue', 'blue']
>>> cnt = Counter(words)
>>> cnt
Counter({'blue': 3, 'red': 2, 'green': 1})
>>> cnt.items()
[('blue', 3), ('red', 2), ('green', 1)]

This example could be used to replace the existing one. Perhaps the
existing example could be used to demonstrate how to do the same task
without a Counter for comparison?

Cheers

Graeme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141118/780141ea/attachment.html>

From jure.erznoznik at gmail.com  Wed Nov 19 10:45:58 2014
From: jure.erznoznik at gmail.com (=?UTF-8?Q?Jure_Erzno=C5=BEnik?=)
Date: Wed, 19 Nov 2014 10:45:58 +0100
Subject: [docs] decimal module
Message-ID: <CAJ=9zifYCsx5sb0c5igB=9DjaWZxz=n1V4WnvrP05ZEyEVZGQw@mail.gmail.com>

I'm porting my code from 2.7 to 3.4.
I have noticed that Decimal.quantize (C version) no longer has the fourth
parameter (watchexp).
Documentation even states that it will be removed in 3.4, but the .py
version and the documentation still have it.

LP,
Jure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141119/0f2d33f5/attachment.html>

From report at bugs.python.org  Sat Nov 22 09:05:14 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 22 Nov 2014 08:05:14 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1416643514.72.0.965994018504.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Did I test the last patch?  I would hope so but I simply can't remember as it's nearly four months ago, sorry :(

----------

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

From report at bugs.python.org  Sat Nov 22 14:57:36 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 22 Nov 2014 13:57:36 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1416643514.72.0.965994018504.issue19980@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-NZ4oxP00s9--ddp6MZzStUAvvt5KY2S5OBQ=AcSTW1BQ@mail.gmail.com>


Zachary Ware added the comment:

In that case, it would be good to make sure it still applies and passes the
tests. Last time I tried it didn't, and I was called away before I could
leave a note to that effect (for which I am sorry).  However, I don't have
a strong enough opinion on this issue for me to have fixed your patch or
even to have kept it in mind to come back to later.

----------

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

From report at bugs.python.org  Sat Nov 22 21:49:39 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 22 Nov 2014 20:49:39 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
Message-ID: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

https://docs.python.org/3/reference/datamodel#object.__iter__

> This method should return a new iterator object that can iterate over all the objects
> in the container. For mappings, it should iterate over the keys of the container, and
> should also be made available as the method keys().

In 3.x, d.__iter__() is not equivalent to d.keys() but to iter(d.keys()).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 231529
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc for __iter__ makes inexact comment about dict.__iter__
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Nov 22 23:36:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 22 Nov 2014 22:36:32 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416695792.59.0.445054635301.issue22918@psf.upfronthosting.co.za>


R. David Murray added the comment:

They aren't equivalent in python2, either.  I think probably the wording should be changed to something like "and the method keys() should return an iterable that provides access to the same data".

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

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

From report at bugs.python.org  Sun Nov 23 02:05:39 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Nov 2014 01:05:39 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416704739.33.0.322065390953.issue22918@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The Python 2 doc is alright, the same line says that d.__iter__() is equivalent to d.iterkeys().

----------

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

From report at bugs.python.org  Sun Nov 23 06:49:55 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 23 Nov 2014 05:49:55 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416721795.76.0.419857747596.issue22918@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  So the python3 docs should say "and should be equivalent to iter(dict.keys())" ?  Or maybe the whole phrase should just be dropped.

----------

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

From report at bugs.python.org  Sun Nov 23 17:43:33 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 23 Nov 2014 16:43:33 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <1416761013.82.0.538173931178.issue20467@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thoughts?

----------
keywords: +patch
stage:  -> patch review
versions: +Python 3.5
Added file: http://bugs.python.org/file37255/issue20467.stoneleaf.01.patch

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

From report at bugs.python.org  Sun Nov 23 17:57:49 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 23 Nov 2014 16:57:49 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1416761869.62.0.057149085704.issue22918@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I think the first half of the sentence is enough: ?For mappings, it should iterate over the keys of the container.?

----------

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

From report at bugs.python.org  Mon Nov 24 18:10:36 2014
From: report at bugs.python.org (newbie)
Date: Mon, 24 Nov 2014 17:10:36 +0000
Subject: [docs] [issue22933] Misleading sentence in doc for shutil.move
Message-ID: <1416849036.72.0.766895523282.issue22933@psf.upfronthosting.co.za>


New submission from newbie:

First sentence of 3rd paragraph of 10.10. "shutil" documentation for shutil.move command, "The destination directory must not already exist", is misleading and contradicts other information in the entry.  I took it to mean that if dst did not exist, python would create it as a directory.  What actually happens is that python renames src to dst. In my test, I was moving several files to a new directory, and the result was a file with the pathname dst and contents matching the last move command, consistent with the behavior described in the rest of the paragraph and the following one. When I changed the code to create the directory with os.mkdirs before calling shutil.move, it worked as I wanted, so obviously there's nothing wrong with the destination directory already existing. The preceding paragraph implies this with its description of behavior when dst refers to a directory.  I suggest removing this sentence, and maybe adding some text indicating what to do if you want to move a file to a new directory.
I was using Python 2.7.5 on Windows, and branch 2.7.8 of the documentation (there does not appear to be a branch 2.7.5 available.)

----------
assignee: docs at python
components: Documentation
messages: 231612
nosy: docs at python, newbie
priority: normal
severity: normal
status: open
title: Misleading sentence in doc for shutil.move
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Mon Nov 24 19:32:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 24 Nov 2014 18:32:32 +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: <1416853951.96.0.685665226746.issue22933@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think you are correct that that sentence should just be deleted.  The preceding sentence should start "If the destination is an existing directory..."

I also wonder if shutil should be changed to use os.replace, but that is a separate issue.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Nov 24 22:46:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:46:56 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <20141124214651.126764.4523@psf.io>


Roundup Robot added the comment:

New changeset 268ceaa78cf9 by Berker Peksag in branch '3.4':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/268ceaa78cf9

New changeset c2b36196b7f5 by Berker Peksag in branch 'default':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/c2b36196b7f5

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

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

From report at bugs.python.org  Mon Nov 24 22:50:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Nov 2014 21:50:35 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <20141124215032.126778.75897@psf.io>


Roundup Robot added the comment:

New changeset e504c3bc6897 by Berker Peksag in branch '2.7':
Issue #20351: Add examples for csv.DictReader and csv.DictWriter.
https://hg.python.org/cpython/rev/e504c3bc6897

----------

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

From report at bugs.python.org  Mon Nov 24 22:51:50 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 24 Nov 2014 21:51:50 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1416865910.28.0.336071442123.issue20351@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Charles-Axel.

----------
assignee: rhettinger -> berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Nov 25 09:57:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:57:51 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905871.59.0.538406814567.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please look at the patch? I touches only docs and comments.

----------
keywords: +needs review

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

From report at bugs.python.org  Tue Nov 25 09:58:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:58:59 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905939.84.0.585694407559.issue22581@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg231643

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

From report at bugs.python.org  Tue Nov 25 09:59:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 08:59:20 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416905960.15.0.443806831058.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please look at the patch? It touches only docs and comments.

----------

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

From report at bugs.python.org  Tue Nov 25 16:02:30 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 25 Nov 2014 15:02:30 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416927750.52.0.373958647688.issue22581@psf.upfronthosting.co.za>


R. David Murray added the comment:

There's no review link.  And no obvious reason why there isn't.  Could you try regenerating the patch and uploading it again?

----------

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

From report at bugs.python.org  Tue Nov 25 16:32:50 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 25 Nov 2014 15:32:50 +0000
Subject: [docs] [issue22581] Other mentions of the buffer protocol
In-Reply-To: <1412785100.97.0.773176507587.issue22581@psf.upfronthosting.co.za>
Message-ID: <1416929570.06.0.688188042415.issue22581@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Regenerated for review. I don't know why Rietweld didn't like previous patch.

----------
Added file: http://bugs.python.org/file37276/bytes_like.patch

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

From report at bugs.python.org  Tue Nov 25 20:52:38 2014
From: report at bugs.python.org (Jordan)
Date: Tue, 25 Nov 2014 19:52:38 +0000
Subject: [docs] [issue22942] Language Reference - optional comma
Message-ID: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>


New submission from Jordan:

# I would like to report three bugs in the
# Language Reference Python 3.4.2

#################################
# bug 1: Typo in parameter_list #
#################################

# In 8.6 the rule for parameter_list should be corrected: The first "|" should be "("

# parameter_list ::=  (defparameter ",")*
#                     | "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# This rule was correct in 3.3 but has been changed with issue #21439, I guess.

                    
###############################################################################
# bug 2: print(*(1,2),) is allowed according to the syntax - but not accepted #
###############################################################################

# In 6.3.4:
# call                 ::=  primary "(" [argument_list [","] | comprehension] ")"
# argument_list        ::=  positional_arguments ["," keyword_arguments]
#                             ["," "*" expression] ["," keyword_arguments]
#                             ["," "**" expression]
#                           | keyword_arguments ["," "*" expression]
#                             ["," keyword_arguments] ["," "**" expression]
#                           | "*" expression ["," keyword_arguments] ["," "**" expression]
#                           | "**" expression

# Why is this wrong?
print(1,2,)     # is allowed
print(*(1,2))   # is allowed
#print(*(1,2),) # is allowed according to the syntax - but not accepted

# I guess the trailing comma is only allowed when there is no *-argument
# as it is in the rule for parameter_list

###########################################################
# bug 3: decorator rule allows (aditional) trailing comma #
###########################################################

# In 8.6:
# decorator      ::=  "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE
# parameter_list ::=  (defparameter ",")*
#                     ( "*" [parameter] ("," defparameter)* ["," "**" parameter]
#                     | "**" parameter
#                     | defparameter [","] )

# Why is this wrong?
def klammer(klammer_left,klammer_right):
    def klammer_decorator(func):
        def func_wrapper(name):
            return klammer_left + func(name) + klammer_right
        return func_wrapper
    return klammer_decorator

@klammer("<",">",)   # is allowed
#@klammer("<",">",,) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli")) 

@klammer(*("<",">"))   # is allowed
#@klammer(*("<",">"),) # is allowed according to the syntax - but is not accepted
def get_text(name):
    return "Hallo " + name
print(get_text("Uli"))

# I guess the decorator rule might be changed to: 
# decorator      ::=  "@" dotted_name ["(" [parameter_list      ] ")"] NEWLINE
# The other appearences of parameter_list have no optional comma.

----------
assignee: docs at python
components: Documentation
messages: 231680
nosy: docs at python, jordan
priority: normal
severity: normal
status: open
title: Language Reference - optional comma
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Tue Nov 25 21:15:37 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 25 Nov 2014 20:15:37 +0000
Subject: [docs] [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1416946537.31.0.144095230229.issue22942@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/issue22942>
_______________________________________

From report at bugs.python.org  Wed Nov 26 16:54:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Nov 2014 15:54:15 +0000
Subject: [docs] [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417017255.81.0.950981932251.issue22949@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it should be documented.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
priority: normal -> low
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 26 18:59:39 2014
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 26 Nov 2014 17:59:39 +0000
Subject: [docs] [issue22949] fnmatch.translate doesn't add ^ at the beginning
In-Reply-To: <1417012488.81.0.131238508635.issue22949@psf.upfronthosting.co.za>
Message-ID: <1417024778.95.0.763632507504.issue22949@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I notice that it puts the inline flags at the end. It would be better to put them at the start.

----------

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

From report at bugs.python.org  Wed Nov 26 22:35:09 2014
From: report at bugs.python.org (Davin Potts)
Date: Wed, 26 Nov 2014 21:35:09 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
Message-ID: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>


New submission from Davin Potts:

The introduction section of the multiprocessing module's documentation does not adhere to the python dev guidelines for keeping things in the affirmative tone.

Problem description:
Specifically, the intro section contains a warning block that, while conveying something important, both 1) potentially creates worry/concern in the mind of the reader new to this module, and 2) ideally belongs somewhere more relevant/appropriate than the intro section.  Also, the intro section contains an example code block that does not attempt to provide a simple example to advance understanding and boost the reader's confidence through trying this example -- instead it demonstrates what not to do and the consequences of doing so in an attempt to drive home one key point with the reader.

Suggested changes:
* The warning text block can be moved to a section discussing synchronization without losing the important information being shared or sharing it too late to be useful.
* To make the key point to the reader in the intro about the availability/importability of functions, etc. to child processes, the affirmative tone can be used in describing the good pattern/practice being employed in a usable/valid/working example.


Further comment:  Similar issues could be raised with other parts of the multiprocessing docs but this issue is concerned only with the intro section.

----------
assignee: docs at python
components: Documentation
messages: 231731
nosy: davin, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing doc introduction not in affirmative tone
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 26 22:45:08 2014
From: report at bugs.python.org (Davin Potts)
Date: Wed, 26 Nov 2014 21:45:08 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417038308.85.0.925512024605.issue22952@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attached is a proposed patch for the 2.7 branch.

It provides 2 changes to the documentation:
1) Moves the warning text block regarding synchronization functionality not necessarily being available on all systems to the "Synchronization between processes" section (Section 16.6.1.3 in the 2.7 docs).
2) Adds a paragraph introducing (in the affirmative tone) a good/common practice as shown in a working example to drive home the key point about importability by subprocesses.  The original example of what not to do has been preserved by moving it to the "Using a pool of workers" section (Section 16.6.1.5 in the 2.7 docs).

Note that this patch does not attempt to resolve the issue of :class:`Pool` not being resolved by Sphinx to properly point at the multiprocessing.pool.Pool class description.  This issue appears addressed in the 3.4 docs but not in some other branches.

----------
keywords: +patch
Added file: http://bugs.python.org/file37290/multiprocessing_27.patch

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

From report at bugs.python.org  Thu Nov 27 02:37:58 2014
From: report at bugs.python.org (Davin Potts)
Date: Thu, 27 Nov 2014 01:37:58 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417052278.73.0.61884021565.issue22952@psf.upfronthosting.co.za>


Davin Potts added the comment:

Attached is a proposed patch for the 3.4 branch.

The same modifications are made in this patch as in the patch for the 2.7 branch, with two minor tweaks:
1) The affirmative tone example uses Pool in a with statement as is supported since 3.3.
2) References in the added/moved text are properly resolving (in Sphinx) to the class definition for Pool.


This patch should also work against the 3.3 branch (though should not be applied to 3.2 as the context manager behavior had not yet been added to Pool in 3.2 -- the example in the intro would need changing for this to be applied to 3.2 is all).

----------
Added file: http://bugs.python.org/file37291/multiprocessing_34.patch

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

From report at bugs.python.org  Thu Nov 27 02:51:45 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Nov 2014 01:51:45 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417053105.67.0.547656205552.issue22952@psf.upfronthosting.co.za>


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


----------
nosy: +sbt
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 27 04:13:10 2014
From: report at bugs.python.org (Davin Potts)
Date: Thu, 27 Nov 2014 03:13:10 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417057990.97.0.493458550372.issue22952@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/issue22952>
_______________________________________

From mikebuc at alumni.nd.edu  Wed Nov 26 05:09:59 2014
From: mikebuc at alumni.nd.edu (Mike Buc)
Date: Tue, 25 Nov 2014 20:09:59 -0800
Subject: [docs] Broken doc links
Message-ID: <010901d0092e$dbc9b780$935d2680$@alumni.nd.edu>

FYI

All the documentation download links on this page are broken:

https://docs.python.org/2/download.html

 

Mike

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141125/1beddedf/attachment-0001.html>

From cszhiyue at gmail.com  Wed Nov 26 11:16:25 2014
From: cszhiyue at gmail.com (cszhiyue at gmail.com)
Date: Wed, 26 Nov 2014 18:16:25 +0800
Subject: [docs] I can't download Python 2.7.9rc1 Document
Message-ID: <201411261816224903177@gmail.com>

Hi:
    I just want to download "Python 2.7.9rc1 Document" on the website.  Link is https://docs.python.org/2/download.html
The page appears 404 error.So I can't do it. I hope you can help me. thx.


jabari.dai
Blog:ruochenchen.com
email:cszhiyue at gmail.com
QQ:245392756


---
????????????????? avast! ????????????
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141126/c1196d99/attachment-0001.html>

From james.tcheou-koan-sing at dbf.gov.pf  Wed Nov 26 18:25:33 2014
From: james.tcheou-koan-sing at dbf.gov.pf (TCHEOU-KOAN-SING James)
Date: Wed, 26 Nov 2014 07:25:33 -1000
Subject: [docs] broken links
Message-ID: <54760D0D.9030700@dbf.gov.pf>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141126/93fb0870/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0064x0069 logo_polynesie_francaise.jpg
Type: image/jpeg
Size: 5103 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20141126/93fb0870/attachment-0001.jpg>

From atlusine at gmail.com  Wed Nov 26 20:32:43 2014
From: atlusine at gmail.com (Lusine Atanesyan)
Date: Wed, 26 Nov 2014 23:32:43 +0400
Subject: [docs] Python bug.
Message-ID: <CAA6td+OfjoABm6PPz-SJ_fSvCXfEP=HX7EB=qEMVvPHNwBLDEg@mail.gmail.com>

Hi,

I found a pyhton bug. Here is the description:

*Summary:*
      It is impossible to change tuple to list.

*Overview description.*
      It is impossible to change tuple to list when there is a independent
list with the "list" name.

*Steps to reproduce:*
       >>> list = [1, 2, 3]
       >>> tup = (5, 6, 7)
       >>> list(tup)

*Actual result:*
      The following error is generated:
           Traceback (most recent call last):
           File "<stdin>", line 1, in <module>
           TypeError: 'list' object is not callable

*Expect result:*
      Either it should be possible to change the tuple to list or the error
should generated when creating a list with the "list" name.

*OS:*
     Ubuntu 12.04 (64 bit)
     Python version: Python 2.7.5+

If you need more clarification please write me.

Regards,

*Lusine Atanesyan*Software Engineer

*"Instigate" CJSC, Gyumri Branch*
1 Alex Manoogian St., Gyumri, Armenia
Tel: +374-60-464701
www.instigatedesign.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141126/5b8b8184/attachment-0001.html>

From g73500 at yahoo.co.uk  Wed Nov 26 21:32:46 2014
From: g73500 at yahoo.co.uk (Graham)
Date: Wed, 26 Nov 2014 20:32:46 +0000
Subject: [docs] Python docs - downloads not found 404
Message-ID: <1417033966.50410.YahooMailBasic@web171401.mail.ir2.yahoo.com>

Hi,

I've just tried to download the latest Python 2 docs from
https://docs.python.org/2/download.html

but they all seem to respond with a 404, at about 20:30GMT.
I do note that it says they were updated today

regards

graham

From james.lowden at continuum.io  Thu Nov 27 03:43:41 2014
From: james.lowden at continuum.io (James Lowden)
Date: Wed, 26 Nov 2014 21:43:41 -0500
Subject: [docs] Fwd: reporting python bugs
In-Reply-To: <8803ECC292F8AF4D903FEA98026CAB1C9D3468@OPC-AD-EXMBX02.AD.SEC.GOV>
References: <8803ECC292F8AF4D903FEA98026CAB1C9D3468@OPC-AD-EXMBX02.AD.SEC.GOV>
Message-ID: <CAPq8Ga6xH+Jj4WYZu8TChtzUmQ8USB+ikRe5tSg+oyTTv3vNWw@mail.gmail.com>

?The pydoc.py documentation
<https://docs.python.org/2/library/pydoc.html?highlight=pydoc> does  not
mention that it honors environment variables.  Specifically, the pager used
is PAGER.  On Windows this is especially useful if you install git, which
supplies GNU less.  By setting PAGER and writing a little .cmd file to
invoke pydoc.py, the pydoc command-line Windows experience becomes
tolerable, lifted out of the circa 1986 more.com feature desert.

Note that if used with git's GNU less, the PAGER environment variable value
should use forward slashes (C:/path/to/less.exe).  Git also honors the
PAGER variable, but interprets backslashes as escapes.  pydoc apparently
treats it as an opaque string, benefiting from the little-known fact that
win32 functions accept either as a directory separator.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141126/6d53eaff/attachment.html>

From zachary.ware+pydocs at gmail.com  Thu Nov 27 05:01:26 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 26 Nov 2014 22:01:26 -0600
Subject: [docs] Python bug.
In-Reply-To: <CAA6td+OfjoABm6PPz-SJ_fSvCXfEP=HX7EB=qEMVvPHNwBLDEg@mail.gmail.com>
References: <CAA6td+OfjoABm6PPz-SJ_fSvCXfEP=HX7EB=qEMVvPHNwBLDEg@mail.gmail.com>
Message-ID: <CAKJDb-Pmh19fquyGs7qJh6t21ZBOgvWaLhWQe2=LKOSn3MQ5uw@mail.gmail.com>

Hi Lusine,

First, I'd like to note that this is not the correct list for
reporting bugs with Python itself; this list is for discussion of
Python's documentation.  That being said...

On Wed, Nov 26, 2014 at 1:32 PM, Lusine Atanesyan <atlusine at gmail.com> wrote:
> Hi,
>
> I found a pyhton bug. Here is the description:
>
> Summary:
>       It is impossible to change tuple to list.
>
> Overview description.
>       It is impossible to change tuple to list when there is a independent
> list with the "list" name.
>
> Steps to reproduce:
>        >>> list = [1, 2, 3]
>        >>> tup = (5, 6, 7)
>        >>> list(tup)
>
> Actual result:
>       The following error is generated:
>            Traceback (most recent call last):
>            File "<stdin>", line 1, in <module>
>            TypeError: 'list' object is not callable

This is the expected result.  By using the name "list" for a list
object, you are shadowing the built-in name "list", which is the name
of the list object constructor.  Python's name resolution algorithm
first checks for a local name, followed by a global name if no local
is found, followed by a built-in name (a member of the builtins (or
__builtin__ in Python2) module).  Since executing "list = [1,2,3]"
creates a local name "list", it is found before the built-in name
"list"; list objects are not callable, hence the error you got.  Note
that it doesn't actually matter what you define the local name "list"
to be:

>>> list = "this is not a list"
>>> tup = (4,5,6)
>>> list(tup)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object is not callable

> Expect result:
>       Either it should be possible to change the tuple to list or the error
> should generated when creating a list with the "list" name.

Name shadowing can be a very useful feature, allowing things like (in
Python 3) redefining the name "print" to be a wrapper around
"log.debug", so it's not going away.  The real solution here is to
either just not use the name "list" in a local scope (a lot of people
use "lst" or "list_" or just "l" if your font distinguishes between
"l" and "I" properly), or to import builtins (or __builtin__ in Python
2) and use "builtins.list" instead of just "list" when you need the
built-in list.  It's also possible to do something extraordinarily
ugly like "type([])(tup)", but that's just going a little too far :)

Hope this helps,
-- 
Zach

From report at bugs.python.org  Thu Nov 27 05:17:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 04:17:18 +0000
Subject: [docs] [issue22952] multiprocessing doc introduction not in
	affirmative tone
In-Reply-To: <1417037709.37.0.435561396576.issue22952@psf.upfronthosting.co.za>
Message-ID: <1417061838.31.0.794024134213.issue22952@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 It looks like the relevant information has been preserved while adding an example where the module is being used as designed.

----------

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

From zachary.ware+pydocs at gmail.com  Thu Nov 27 07:00:47 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 27 Nov 2014 00:00:47 -0600
Subject: [docs] Fwd: reporting python bugs
In-Reply-To: <CAPq8Ga6xH+Jj4WYZu8TChtzUmQ8USB+ikRe5tSg+oyTTv3vNWw@mail.gmail.com>
References: <8803ECC292F8AF4D903FEA98026CAB1C9D3468@OPC-AD-EXMBX02.AD.SEC.GOV>
 <CAPq8Ga6xH+Jj4WYZu8TChtzUmQ8USB+ikRe5tSg+oyTTv3vNWw@mail.gmail.com>
Message-ID: <CAKJDb-NUWO8b0pEibMzTpo-3_xotVWNR3-wdTrYoWJQW3s_imA@mail.gmail.com>

Hi James,

On Wed, Nov 26, 2014 at 8:43 PM, James Lowden <james.lowden at continuum.io> wrote:
> The pydoc.py documentation does  not mention that it honors environment
> variables.  Specifically, the pager used is PAGER.  On Windows this is
> especially useful if you install git, which supplies GNU less.  By setting
> PAGER and writing a little .cmd file to invoke pydoc.py, the pydoc
> command-line Windows experience becomes tolerable, lifted out of the circa
> 1986 more.com feature desert.
>
> Note that if used with git's GNU less, the PAGER environment variable value
> should use forward slashes (C:/path/to/less.exe).  Git also honors the PAGER
> variable, but interprets backslashes as escapes.  pydoc apparently treats it
> as an opaque string, benefiting from the little-known fact that win32
> functions accept either as a directory separator.

Thanks for the report!  I've added a small blurb about PAGER to the pydoc docs.

Regards,
-- 
Zach

From report at bugs.python.org  Thu Nov 27 07:10:32 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 27 Nov 2014 06:10:32 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417068631.91.0.789603487732.issue21514@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Serhiy, can you take this one.  The patch passes both mine and Bob's review; however, it doesn't apply cleanly to 2.7 and 3.4.  I haven't had the time to do the needed backports.

----------
assignee: rhettinger -> serhiy.storchaka
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Nov 27 18:51:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 27 Nov 2014 17:51:16 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <20141127175112.116318.70029@psf.io>


Roundup Robot added the comment:

New changeset 7e534e18a99a by Serhiy Storchaka in branch '2.7':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/7e534e18a99a

New changeset 89bb4384f1e1 by Serhiy Storchaka in branch '3.4':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/89bb4384f1e1

New changeset aced2548345a by Serhiy Storchaka in branch 'default':
Issue #21514: The documentation of the json module now refers to new JSON RFC
https://hg.python.org/cpython/rev/aced2548345a

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

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

From report at bugs.python.org  Thu Nov 27 19:11:06 2014
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 27 Nov 2014 18:11:06 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417111866.74.0.37847609521.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Thanks Serhiy!

----------

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

From report at bugs.python.org  Thu Nov 27 20:29:04 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Nov 2014 19:29:04 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417116544.19.0.43370918783.issue21514@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov 27 20:31:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Nov 2014 19:31:05 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1417116665.4.0.0703604941148.issue21514@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Chris for your patch.

----------

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

From report at bugs.python.org  Fri Nov 28 17:56:06 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 28 Nov 2014 16:56:06 +0000
Subject: [docs] [issue22394] Update documentation building to use venv and
	pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1417193766.41.0.810736838275.issue22394@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Attached is a patch against Doc/Makefile to add a venv command to create a venv that can be used to build the documentation. Georg, can you give me an LGTM so I can commit this?

----------
assignee: brett.cannon -> georg.brandl
keywords: +patch
nosy: +georg.brandl
stage: needs patch -> patch review
Added file: http://bugs.python.org/file37307/doc_venv.diff

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

From report at bugs.python.org  Fri Nov 28 18:55:27 2014
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 28 Nov 2014 17:55:27 +0000
Subject: [docs] [issue22394] Update documentation building to use venv and
	pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1417197327.92.0.550735508494.issue22394@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sure.  (The PyPI name is uppercased, but I guess it doesn't matter.)

----------

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

From rkanade at redhat.com  Fri Nov 28 09:39:27 2014
From: rkanade at redhat.com (Rohan Kanade)
Date: Fri, 28 Nov 2014 03:39:27 -0500 (EST)
Subject: [docs] Links for download docs for 2.7.9rc1 are 404
In-Reply-To: <877275565.6524004.1417163930271.JavaMail.zimbra@redhat.com>
Message-ID: <991114902.6524172.1417163967850.JavaMail.zimbra@redhat.com>

Hi, 

The links for https://docs.python.org/2/download.html "Download Python 2.7.9rc1 Documentation" are all not found 404.

Please check

Regards,
Rohan Kanade

From 86890288 at qq.com  Fri Nov 28 10:28:32 2014
From: 86890288 at qq.com (=?ISO-8859-1?B?U3RhcnNlZUtFcg==?=)
Date: Fri, 28 Nov 2014 17:28:32 +0800
Subject: [docs] Response "404" when download python 2.7 documents
Message-ID: <tencent_116944740B41C38E5F17B7A7@qq.com>

Hi,
 
Cant't download python 2.7 documents from https://docs.python.org/2/download.html
 
Response 404.
 Br,
 Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141128/be44703d/attachment.html>

From atlusine at gmail.com  Fri Nov 28 21:19:18 2014
From: atlusine at gmail.com (Lusine Atanesyan)
Date: Sat, 29 Nov 2014 00:19:18 +0400
Subject: [docs] Python bug.
In-Reply-To: <CAKJDb-Pmh19fquyGs7qJh6t21ZBOgvWaLhWQe2=LKOSn3MQ5uw@mail.gmail.com>
References: <CAA6td+OfjoABm6PPz-SJ_fSvCXfEP=HX7EB=qEMVvPHNwBLDEg@mail.gmail.com>
 <CAKJDb-Pmh19fquyGs7qJh6t21ZBOgvWaLhWQe2=LKOSn3MQ5uw@mail.gmail.com>
Message-ID: <CAA6td+Nn66b7gdRshGs72GVnFYgveyZyR6LOjmf84EVkQurfNA@mail.gmail.com>

Hi,

Thanks a lot for the clarification.

Regards,
Lusine Atanesyan

2014-11-27 8:01 GMT+04:00 Zachary Ware <zachary.ware+pydocs at gmail.com>:

> Hi Lusine,
>
> First, I'd like to note that this is not the correct list for
> reporting bugs with Python itself; this list is for discussion of
> Python's documentation.  That being said...
>
> On Wed, Nov 26, 2014 at 1:32 PM, Lusine Atanesyan <atlusine at gmail.com>
> wrote:
> > Hi,
> >
> > I found a pyhton bug. Here is the description:
> >
> > Summary:
> >       It is impossible to change tuple to list.
> >
> > Overview description.
> >       It is impossible to change tuple to list when there is a
> independent
> > list with the "list" name.
> >
> > Steps to reproduce:
> >        >>> list = [1, 2, 3]
> >        >>> tup = (5, 6, 7)
> >        >>> list(tup)
> >
> > Actual result:
> >       The following error is generated:
> >            Traceback (most recent call last):
> >            File "<stdin>", line 1, in <module>
> >            TypeError: 'list' object is not callable
>
> This is the expected result.  By using the name "list" for a list
> object, you are shadowing the built-in name "list", which is the name
> of the list object constructor.  Python's name resolution algorithm
> first checks for a local name, followed by a global name if no local
> is found, followed by a built-in name (a member of the builtins (or
> __builtin__ in Python2) module).  Since executing "list = [1,2,3]"
> creates a local name "list", it is found before the built-in name
> "list"; list objects are not callable, hence the error you got.  Note
> that it doesn't actually matter what you define the local name "list"
> to be:
>
> >>> list = "this is not a list"
> >>> tup = (4,5,6)
> >>> list(tup)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'str' object is not callable
>
> > Expect result:
> >       Either it should be possible to change the tuple to list or the
> error
> > should generated when creating a list with the "list" name.
>
> Name shadowing can be a very useful feature, allowing things like (in
> Python 3) redefining the name "print" to be a wrapper around
> "log.debug", so it's not going away.  The real solution here is to
> either just not use the name "list" in a local scope (a lot of people
> use "lst" or "list_" or just "l" if your font distinguishes between
> "l" and "I" properly), or to import builtins (or __builtin__ in Python
> 2) and use "builtins.list" instead of just "list" when you need the
> built-in list.  It's also possible to do something extraordinarily
> ugly like "type([])(tup)", but that's just going a little too far :)
>
> Hope this helps,
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141129/67190121/attachment.html>

From report at bugs.python.org  Sat Nov 29 01:25:50 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Nov 2014 00:25:50 +0000
Subject: [docs] [issue22918] Doc for __iter__ makes inexact comment
	about	dict.__iter__
In-Reply-To: <1416689379.36.0.290921977035.issue22918@psf.upfronthosting.co.za>
Message-ID: <1417220750.55.0.199733641342.issue22918@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Since .iterkeys is gone, I thing the ', and' part should just be dropped.

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

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

From report at bugs.python.org  Sun Nov 30 21:34:25 2014
From: report at bugs.python.org (Simeon Visser)
Date: Sun, 30 Nov 2014 20:34:25 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
In-Reply-To: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>
Message-ID: <1417379665.32.0.132646352635.issue20467@psf.upfronthosting.co.za>


Simeon Visser added the comment:

Is it worth clarifying that __init__ can return a value but only the value None? The following won't raise a TypeError:

class O(object):
    def __init__(self):
        return None

Admittedly the "return None" is the default behaviour but people may attempt this in order to "block creation" of the instance (as __new__ is less well-known, I have seen the above attempted on Stack Overflow: http://stackoverflow.com/questions/26896941/proper-way-to-terminate-object-creation-inside-of-init/)

----------
nosy: +simeon.visser

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

From kira199417 at 126.com  Sat Nov 29 02:18:58 2014
From: kira199417 at 126.com (1)
Date: Sat, 29 Nov 2014 09:18:58 +0800 (CST)
Subject: [docs] encounters a problem while downloading documentation
Message-ID: <f707311.eb4.149f9212060.Coremail.kira199417@126.com>

When I start to downloading the  Python 2.7.9rc1 Documentation, it came out to be a 404 Not Found. I don't know why.Please help me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141129/d52b7181/attachment.html>

From andi.grooms at gmail.com  Sat Nov 29 02:59:30 2014
From: andi.grooms at gmail.com (Andrea Grooms)
Date: Fri, 28 Nov 2014 19:59:30 -0600
Subject: [docs] dead links
Message-ID: <CAB5M40-Sk_6h1qhwC3wH_Odd9Ofw45O_X-9TJfAYJCvr8PZrwQ@mail.gmail.com>

To whom it may concern,

On Download Python 2.7.9rc1 Documentation page the download links are dead
and the 3.x pages seem to work.

Regards,
Andi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141128/3c5efe61/attachment.html>

From fourfires_d at hotmail.com  Sat Nov 29 21:35:53 2014
From: fourfires_d at hotmail.com (Yanyan Ding)
Date: Sat, 29 Nov 2014 20:35:53 +0000
Subject: [docs] =?utf-8?q?cannot_download_any_format_of_2=2E7=2E9rc1?=
Message-ID: <BLU406-EAS162BFFB6AEC56B3216A2A92917C0@phx.gbl>

hi,

not sure if it's my own problem, I've tried both Chrome and IE, all links of all format in this page:

https://docs.python.org/2/download.html

showing ?404 Not Found?

cannot be downloaded, apparently I could just use online doc. 

hope get it fixed?






Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20141129/c99e51a8/attachment.html>

From raul.martinez5660 at icloud.com  Sun Nov 30 16:07:44 2014
From: raul.martinez5660 at icloud.com (Raul Martinez)
Date: Sun, 30 Nov 2014 09:07:44 -0600
Subject: [docs] 404
Message-ID: <F50E60BF-B720-4081-8753-DF80E34ABB29@icloud.com>

When trying to download the documentation pdf file i get a 404 error

From cogle at oglefarm.com  Sun Nov 30 15:25:14 2014
From: cogle at oglefarm.com (Carolyn)
Date: Sun, 30 Nov 2014 06:25:14 -0800
Subject: [docs] Virus?
Message-ID: <547B28CA.1060900@oglefarm.com>

Hi,

I did not install Python on my computer, but think I have someone 
looking at the info on my computer.  How can I uninstall.  When I turn 
on my computer I get a message "beginning logger file".  I'm very 
concerned about it.  I've been on a lot of job sites and am concerned 
I've picked up a bug.

-- 
Carolyn

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