From report at bugs.python.org  Sun Jun  1 15:04:51 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jun 2014 13:04:51 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1401627891.71.0.624087798046.issue21580@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file35402/tkinter_bytes.patch

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

From report at bugs.python.org  Sun Jun  1 15:05:54 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jun 2014 13:05:54 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1401627954.92.0.858893200332.issue21580@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file35431/tkinter_bytes.patch

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

From report at bugs.python.org  Sun Jun  1 15:11:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 Jun 2014 13:11:34 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1401628294.08.0.663061944542.issue21580@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Unfortunately we can't use this straightforward and universal solution in Python 2. Here is a patch which adds special workarounds to fix this issue in 2.7.

----------
Added file: http://bugs.python.org/file35432/tkinter_bytes-2.7.patch

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

From report at bugs.python.org  Mon Jun  2 00:38:44 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Jun 2014 22:38:44 +0000
Subject: [docs] [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1401662324.03.0.336008984024.issue21611@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I think there should be a precise definition of what is 
> considered to be a number there.

Sometimes "precise" definitions make the docs harder to use rather than easier.  It is the goal of these docs to basically tell what int() does, not to provide a spec for it.

For most users for the past 20+ years, what we already have was sufficient for them to understand that int('42') returned the integer 42 and that int('xyz') did not have a valid interpretation as an integer.

FWIW, there are other parts of the docs that do have more precise specs about precisely specifies what can go in floats, identifiers, etc.  Those parts of the docs are rarely used or read however, because what we have gets the job done reasonably well.

For comparison look at the docs in other languages where the descriptions tend to be more much pithy, leaving intelligent people to fill in the blanks in a reasonable way.

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

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

From report at bugs.python.org  Mon Jun  2 08:49:06 2014
From: report at bugs.python.org (Dmitry Andreychuk)
Date: Mon, 02 Jun 2014 06:49:06 +0000
Subject: [docs] [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1401691745.98.0.695213556157.issue21611@psf.upfronthosting.co.za>


Dmitry Andreychuk added the comment:

Now I see that my message may look like a suggestion to add an encyclopedic definition of number there. Sorry.

Actually I was talking about requirements for user-defined types to make them work with int(). Something like: "If x has __int__() method return x.__int__(). Else x must be a string, bytes, or bytearray...".

After reading the docstring I was like: Should I just define __int__() for my class to work with int() or maybe int() uses isintance() and my class has also to inherit from numbers.Number?

But maybe It's just me and it's clear for everyone else.

----------

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

From report at bugs.python.org  Mon Jun  2 09:34:13 2014
From: report at bugs.python.org (eryksun)
Date: Mon, 02 Jun 2014 07:34:13 +0000
Subject: [docs] [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1401694453.0.0.341030596727.issue21611@psf.upfronthosting.co.za>


eryksun added the comment:

The constructor tries __trunc__ (truncate toward 0) if __int__ isn't defined. If __trunc__ doesn't return an instance of int, it calls the intermediate result's __int__ method. In terms of the numbers ABCs, numbers.Real requires __trunc__, which should return a numbers.Integral, which requires __int__. 

The special methods __trunc__, __floor__, and __ceil__ aren't documented in the language reference. They're mentioned briefly in the docs for the math functions trunc, floor, and ceil.

----------
nosy: +eryksun

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

From report at bugs.python.org  Mon Jun  2 15:35:34 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Mon, 02 Jun 2014 13:35:34 +0000
Subject: [docs] [issue21637] Add a warning section exaplaining that
	tempfiles are	opened in binary mode
Message-ID: <1401716134.93.0.330807213561.issue21637@psf.upfronthosting.co.za>


New submission from Sebastian Kreft:

Although it is already explained that the default mode of the opened tempfiles is 'w+b' a warning/notice section should be included to make it clearer.

I think this is important as the default for the open function is to return strings and not bytes.

I just had to debug an error with traceback, as traceback.print_exc expects a file capable of handling unicode.

----------
assignee: docs at python
components: Documentation
messages: 219585
nosy: Sebastian.Kreft.Deezer, docs at python
priority: normal
severity: normal
status: open
title: Add a warning section exaplaining that tempfiles are opened in binary mode
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun  2 15:53:02 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:53:02 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717182.31.0.662482731935.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: python_2.7.patch
keywords: patch
nosy: OrangeTux, docs at python
priority: normal
severity: normal
status: open
title: References to other Python version in sidebar of documentation index is not up to date
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35451/python_2.7.patch

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

From report at bugs.python.org  Mon Jun  2 15:53:32 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:53:32 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717212.04.0.923757445916.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


Added file: http://bugs.python.org/file35452/python_3.1.patch

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

From report at bugs.python.org  Mon Jun  2 15:53:42 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:53:42 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717222.4.0.774166011983.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


Added file: http://bugs.python.org/file35453/python_3.2.patch

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

From report at bugs.python.org  Mon Jun  2 15:53:55 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:53:55 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717235.97.0.279500741127.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


Added file: http://bugs.python.org/file35454/python_3.2.patch

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

From report at bugs.python.org  Mon Jun  2 15:54:07 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:54:07 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717247.22.0.642381415317.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


Added file: http://bugs.python.org/file35455/python_3.3.patch

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

From report at bugs.python.org  Mon Jun  2 15:54:22 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:54:22 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717262.82.0.604490695501.issue21640@psf.upfronthosting.co.za>


Changes by Auke Willem Oosterhoff <awoosterhoff at gmail.com>:


Added file: http://bugs.python.org/file35456/python_3.4.patch

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

From report at bugs.python.org  Mon Jun  2 15:55:23 2014
From: report at bugs.python.org (Auke Willem Oosterhoff)
Date: Mon, 02 Jun 2014 13:55:23 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
Message-ID: <1401717323.88.0.779298846083.issue21640@psf.upfronthosting.co.za>


New submission from Auke Willem Oosterhoff:

Most version of the documentation are labeling Python 3.4 as 'in development' and missing reference to Python 3.5.

----------
Added file: http://bugs.python.org/file35457/python_3.5.patch

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

From report at bugs.python.org  Mon Jun  2 16:27:57 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Jun 2014 14:27:57 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1401719277.53.0.438425193404.issue21559@psf.upfronthosting.co.za>


R. David Murray added the comment:

Your second bullet item would seem to me to be the obvious interpretation of the docs.  This is, after all, Python, so 'integer' would refer to Python integers and their operations.  So I agree with Stefan that the docs are correct as they stand.  As he also said, there may be places where OverflowError is currently raised that may not be appropriate, especially since we are dealing with a codebase that once had Python integer operations that *could* overflow.

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

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

From report at bugs.python.org  Mon Jun  2 20:02:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 Jun 2014 18:02:12 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1401732132.91.0.51863470097.issue21559@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I was tempted to close this, but I think there is an issue that 'theme' has implied but not stated clearly enough. The OverflowError entry might be re-written as "Raised when the result of an arithmetic operation involving at least one non-int is too large to be represented. For pairs of ints, MemoryError is raised instead." This much is true. However, the clear implication is that a binary operation on non-ints is the only situation in which OverflowError is raised. But as theme has shown, it is not. In this sense, the doc is incomplete.

Another, unstated, situation is failure of an internal conversion from an int to an internal type. In #20539, #20539, the justification for switching from MemoryError to OverflowError when factorial input grows too large for conversion is that memory is then not filled. In #21444, the justification is history.

A third possibility is that OverflowError is used instead of ValueError when an int fails a simple range check. See #15988: _testcapi.getargs_b requires an int in range(256). -1 and 256 raise OverflowErrors. #7267 is about the same issue. An int not being in range(256) has nothing to do with the merging of integer types in 3.x.

So I think that the docs need a new sentence. Both alternatives can be summarized by "OverflowError may also be raised for integers that are outside a required range." Knowing this might help people debugging such situations.

----------

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

From report at bugs.python.org  Mon Jun  2 20:14:22 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Jun 2014 18:14:22 +0000
Subject: [docs] [issue21533] built-in types dict docs - construct dict from
	iterable, not iterator
In-Reply-To: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za>
Message-ID: <1401732862.22.0.018939801812.issue21533@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, zach.ware
type:  -> enhancement

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

From report at bugs.python.org  Mon Jun  2 20:19:11 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Jun 2014 18:19:11 +0000
Subject: [docs] [issue9196] Improve docs for string interpolation "%s" re
	Unicode	strings
In-Reply-To: <1278572830.17.0.148747735024.issue9196@psf.upfronthosting.co.za>
Message-ID: <1401733151.98.0.102962751152.issue9196@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun  2 20:19:55 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 02 Jun 2014 18:19:55 +0000
Subject: [docs] [issue21547] '!s' formatting documentation bug
In-Reply-To: <1400654359.7.0.699720681212.issue21547@psf.upfronthosting.co.za>
Message-ID: <1401733195.35.0.696758353512.issue21547@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
type:  -> behavior

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

From report at bugs.python.org  Mon Jun  2 20:45:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 Jun 2014 18:45:05 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1401734705.19.0.249925603867.issue21559@psf.upfronthosting.co.za>


R. David Murray added the comment:

"Integers are outside a required range" makes me wonder why it isn't a ValueError.  An OverflowError should be the result of a *computation*, IMO, not a bounds check.

So, maybe add your sentence with the additional phrase "for historical reasons"? :)

----------

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

From report at bugs.python.org  Mon Jun  2 20:52:14 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 Jun 2014 18:52:14 +0000
Subject: [docs] [issue21533] built-in types dict docs - construct dict from
	iterable, not iterator
In-Reply-To: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za>
Message-ID: <1401735134.11.0.37033885802.issue21533@psf.upfronthosting.co.za>


Zachary Ware added the comment:

LGTM.

----------

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

From report at bugs.python.org  Mon Jun  2 23:09:05 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jun 2014 21:09:05 +0000
Subject: [docs] [issue21601] Cancel method for Asyncio Task is not documented
In-Reply-To: <1401340112.56.0.394123736.issue21601@psf.upfronthosting.co.za>
Message-ID: <3gj8Bm3wgGz7LlL@mail.python.org>


Roundup Robot added the comment:

New changeset c2384ca7fc3b by Victor Stinner in branch '3.4':
Issue #21601: Document asyncio.Task.cancel(). Initial patch written by Vajrasky
http://hg.python.org/cpython/rev/c2384ca7fc3b

New changeset 0ee47d3d2664 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #21601: Document asyncio.Task.cancel(). Initial patch written
http://hg.python.org/cpython/rev/0ee47d3d2664

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

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

From report at bugs.python.org  Mon Jun  2 23:10:15 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 02 Jun 2014 21:10:15 +0000
Subject: [docs] [issue21601] Cancel method for Asyncio Task is not documented
In-Reply-To: <1401340112.56.0.394123736.issue21601@psf.upfronthosting.co.za>
Message-ID: <1401743415.38.0.394394096383.issue21601@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the patch.

By the way, the CancelledError from conccurent.futures is not documented and asyncio still has its own asyncio.CancelledError alias which is not documented neither.

----------
nosy: +giampaolo.rodola, gvanrossum, pitrou, yselivanov
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Jun  2 23:32:32 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 02 Jun 2014 21:32:32 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
In-Reply-To: <1401717323.88.0.779298846083.issue21640@psf.upfronthosting.co.za>
Message-ID: <1401744752.07.0.0172431304696.issue21640@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jun  3 02:43:37 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jun 2014 00:43:37 +0000
Subject: [docs] [issue21533] built-in types dict docs - construct dict from
	iterable, not iterator
In-Reply-To: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za>
Message-ID: <3gjDyF734hz7LkS@mail.python.org>


Roundup Robot added the comment:

New changeset 78da27d6f28f by Terry Jan Reedy in branch '2.7':
Issue 21533: Dicts take iterables, not iterators. Patch by Wolfgang Maier.
http://hg.python.org/cpython/rev/78da27d6f28f

New changeset 28665dc3a696 by Terry Jan Reedy in branch '3.4':
Issue 21533: Dicts take iterables, not iterators. Patch by Wolfgang Maier.
http://hg.python.org/cpython/rev/28665dc3a696

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

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

From report at bugs.python.org  Tue Jun  3 02:45:19 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jun 2014 00:45:19 +0000
Subject: [docs] [issue21533] built-in types dict docs - construct dict from
	iterable, not iterator
In-Reply-To: <1400487015.16.0.760931173475.issue21533@psf.upfronthosting.co.za>
Message-ID: <1401756319.45.0.693097438556.issue21533@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for catching this, and for the patch.

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

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

From report at bugs.python.org  Tue Jun  3 07:39:48 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 03 Jun 2014 05:39:48 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
In-Reply-To: <1401717323.88.0.779298846083.issue21640@psf.upfronthosting.co.za>
Message-ID: <1401773988.46.0.743556424202.issue21640@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I see that all the patches are correct. My only worry is since 3.1,3.2 and 3.3 are in security fix only mode, we may not apply it to those. 
2.7, 3.4 and 3.5 ones are okay.

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

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

From report at bugs.python.org  Tue Jun  3 08:02:06 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 03 Jun 2014 06:02:06 +0000
Subject: [docs] [issue21640] References to other Python version in sidebar
	of	documentation index is not up to date
In-Reply-To: <1401717323.88.0.779298846083.issue21640@psf.upfronthosting.co.za>
Message-ID: <1401775326.91.0.416660169243.issue21640@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed the follwing changesets.

2.7 b8655be522d4
3.4 e6dce5611dae
3.5 50c9df76bb77

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

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

From report at bugs.python.org  Tue Jun  3 11:09:57 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jun 2014 09:09:57 +0000
Subject: [docs] [issue21649] Mention "Recommendations for Secure Use of TLS
	and DTLS"
Message-ID: <1401786597.2.0.166065083457.issue21649@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The IETF has a draft for TLS protocol recommendations, perhaps we can mention it in the ssl module docs:

http://tools.ietf.org/html/draft-ietf-uta-tls-bcp

----------
assignee: docs at python
components: Documentation
messages: 219673
nosy: christian.heimes, docs at python, dstufft, giampaolo.rodola, janssen, pitrou
priority: low
severity: normal
status: open
title: Mention "Recommendations for Secure Use of TLS and DTLS"
type: enhancement

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

From report at bugs.python.org  Tue Jun  3 16:35:01 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jun 2014 14:35:01 +0000
Subject: [docs] [issue21439] Numerous minor issues in Language Reference
In-Reply-To: <1399300451.92.0.450554829588.issue21439@psf.upfronthosting.co.za>
Message-ID: <3gjbPc5Lz6z7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset be8492101251 by Zachary Ware in branch '3.4':
Issue #21439: Fix a couple of typos.
http://hg.python.org/cpython/rev/be8492101251

New changeset 99b469758f49 by Zachary Ware in branch 'default':
Issue #21439: Merge with 3.4
http://hg.python.org/cpython/rev/99b469758f49

----------

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

From report at bugs.python.org  Tue Jun  3 17:00:05 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 03 Jun 2014 15:00:05 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1401807605.55.0.168005345906.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Please find attached a first pass at a patch file.  Help('') produces help for the str class as discussed.  I found the difference between help('help') and help() very confusing.  The former produced the help output but left you at the interactive prompt, the latter took you to the help utility.  Both now take you to the help utility.  I've changed the test file but two test fail, here's the output from one as they're virtually identical.

FAIL: test_input_strip (test.test_pydoc.PydocDocTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\cpython\lib\test\test_pydoc.py", line 429, in test_input_strip
    self.assertEqual(expected, result)
AssertionError: 'No P[49 chars]e\'.\nUse help("help") or just help() to get t[66 chars]ass.' != 'No P[49 chars]e\'.\r\nUse help("help") or just help() to get[70 chars]ass.'
- No Python documentation found for 'test.i_am_not_here'.
+ No Python documentation found for 'test.i_am_not_here'.
?                                                        +
- Use help("help") or just help() to get the interactive help utility.
+ Use help("help") or just help() to get the interactive help utility.
?                                                                     +
  Use help(str) for help on the str class.

I can't see where the difference between the .\nUse and .\r\nUse is coming from so thought fresh eyes would do the job.

----------
Added file: http://bugs.python.org/file35472/issue19980.patch

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

From report at bugs.python.org  Tue Jun  3 17:26:54 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 03 Jun 2014 15:26:54 +0000
Subject: [docs] [issue21365] asyncio.Task reference misses the most
	important fact	about it,
	related info spread around intros and example commentary instead
In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za>
Message-ID: <1401809214.86.0.967604386851.issue21365@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Victor, since you wrote much of the asyncio doc, any comment on this request?

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

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

From zachary.ware at gmail.com  Tue Jun  3 19:12:56 2014
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Tue, 03 Jun 2014 17:12:56 -0000
Subject: [docs] Improve help('non-topic') response (issue 19980)
Message-ID: <20140603171256.27996.14679@psf.upfronthosting.co.za>

Other than fixing the test (see comment), this looks pretty good to me.


http://bugs.python.org/review/19980/diff/12043/Lib/test/test_pydoc.py
File Lib/test/test_pydoc.py (right):

http://bugs.python.org/review/19980/diff/12043/Lib/test/test_pydoc.py#newcode210
Lib/test/test_pydoc.py:210: 'Use help(str) for help on the str class.')
Define this as
"""
os.linesep.join(['No Python...',
                 'Use help("...',
                 'Use help(str...',
                ])
"""

to avoid the line ending error you're seeing (which is coming from the
fact that run_pydoc() runs Python in a subprocess, which means output
from it has the system line endings).  See test_capi's
test_forced_io_encoding for another example like this.

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

From report at bugs.python.org  Tue Jun  3 19:13:13 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 03 Jun 2014 17:13:13 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1401815593.0.0.812391842629.issue19980@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Tue Jun  3 23:53:56 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 03 Jun 2014 21:53:56 +0000
Subject: [docs] [issue21637] Add a warning section exaplaining that
	tempfiles are	opened in binary mode
In-Reply-To: <1401716134.93.0.330807213561.issue21637@psf.upfronthosting.co.za>
Message-ID: <1401832436.64.0.50026215468.issue21637@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Adding warnings for something that is clearly documented (both in the constructor prototype line and again in the spelled out documentation of the "mode" argument) is wasteful, particularly when accidental misuse would immediately lead to an exception being thrown the second you attempted to write a str (so there is no risk of partial or silent failure that might lead to an inconsistent state).

As a rule, Python doesn't litter the documentation with warnings unless it's a matter of security or minor version compatibility. This doesn't affect security, behaves identically across all releases of Python 3, etc.

----------
nosy: +josh.rosenberg

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

From report at bugs.python.org  Tue Jun  3 23:58:09 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 03 Jun 2014 21:58:09 +0000
Subject: [docs] [issue21637] Add a warning section exaplaining that
	tempfiles are	opened in binary mode
In-Reply-To: <1401716134.93.0.330807213561.issue21637@psf.upfronthosting.co.za>
Message-ID: <1401832689.14.0.181182072382.issue21637@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun  4 00:12:21 2014
From: report at bugs.python.org (Andrew McKinlay)
Date: Tue, 03 Jun 2014 22:12:21 +0000
Subject: [docs] [issue21653] Row.keys() in sqlite3 returns a list,
	not a tuple
Message-ID: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>


New submission from Andrew McKinlay:

The documentation here (https://docs.python.org/2/library/sqlite3.html#sqlite3.Row.keys) says that the method returns a tuple. It returns a list.

----------
assignee: docs at python
components: Documentation
messages: 219724
nosy: amckinlay, docs at python
priority: normal
severity: normal
status: open
title: Row.keys() in sqlite3 returns a list, not a tuple
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun  4 00:22:28 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 03 Jun 2014 22:22:28 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1401834148.24.0.813897642799.issue21559@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

It usually doesn't just mean "outside a required range", it means "outside the range of values representable due to implementation specific limitations (e.g. the function is converting to a C type)". You don't raise OverflowError because your function only allows values from 0-1000, you raise it because you accept "arbitrary" values that are in fact limited by the definition of int, long, Py_ssize_t, etc. It does get weird when you talk about unsigned values, where they're usually used because negative values aren't logically valid, not merely a side-effect of trying to use more efficient types. Case #3 mentioned in Terry's list is because it's stored as a C unsigned char, which simply doesn't support values outside the range [0,256).

I think of the distinction between ValueError and OverflowError as the difference between "The argument makes no logical sense in context" and "The argument can't be used due to interpreter limitations". I suppose it makes sense to be consistent; if your function only accepts values from 0-1000 on a logical basis, then any OverflowErrors should be converted to ValueErrors (since no change in implementation would alter the accepted logical range).

I'll grant it gets fuzzy when we talk about bytes (after all, the function could choose to use a larger storage type, and probably didn't because program logic dictates that [0,256) is the value range). Not sure how it's possible to handle that, or if it's even worth it when so much code, APIs, and third party modules are saying that implementation limits (OverflowError) trump logical limits (ValueError) when it comes to the exception type.

----------
nosy: +josh.rosenberg

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

From report at bugs.python.org  Wed Jun  4 07:38:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Jun 2014 05:38:57 +0000
Subject: [docs] [issue21653] Row.keys() in sqlite3 returns a list,
	not a tuple
In-Reply-To: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>
Message-ID: <1401860337.66.0.526739540147.issue21653@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun  4 07:41:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 Jun 2014 05:41:44 +0000
Subject: [docs] [issue21653] Row.keys() in sqlite3 returns a list,
	not a tuple
In-Reply-To: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>
Message-ID: <1401860504.0.0.409908097247.issue21653@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jun  4 17:49:35 2014
From: report at bugs.python.org (Steve Dougherty)
Date: Wed, 04 Jun 2014 15:49:35 +0000
Subject: [docs] [issue21661] setuptools documentation: typo
Message-ID: <1401896975.69.0.474580151289.issue21661@psf.upfronthosting.co.za>


New submission from Steve Dougherty:

Typo - "it's" is a contraction for "it is" or "it has." "Its" is the posessive form.

----------
assignee: docs at python
components: Documentation
files: typo1.diff
keywords: patch
messages: 219762
nosy: docs at python, sdougherty
priority: normal
severity: normal
status: open
title: setuptools documentation: typo
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35483/typo1.diff

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

From report at bugs.python.org  Wed Jun  4 18:13:53 2014
From: report at bugs.python.org (Steve Dougherty)
Date: Wed, 04 Jun 2014 16:13:53 +0000
Subject: [docs] [issue21662] datamodel documentation: fix typo and phrasing
Message-ID: <1401898433.15.0.977060998542.issue21662@psf.upfronthosting.co.za>


New submission from Steve Dougherty:

"Should" was missing an o, and putting the reason first makes the sentence flow better.

----------
assignee: docs at python
components: Documentation
files: typo2.diff
keywords: patch
messages: 219763
nosy: docs at python, sdougherty
priority: normal
severity: normal
status: open
title: datamodel documentation: fix typo and phrasing
versions: Python 3.5
Added file: http://bugs.python.org/file35484/typo2.diff

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

From georg at python.org  Thu Jun  5 11:46:40 2014
From: georg at python.org (Georg Brandl)
Date: Thu, 05 Jun 2014 11:46:40 +0200
Subject: [docs] Fwd: Doc suggestions re exceptions
In-Reply-To: <20140605100737.12c30877@dino>
References: <20140605100737.12c30877@dino>
Message-ID: <53903C80.5050708@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1




- -------- Original Message --------
Subject: Doc suggestions re exceptions
Date: Thu, 5 Jun 2014 10:07:37 +0100
From: Mark Summerfield <mark at qtrac.eu>
Organization: Qtrac Ltd.
To: Georg Brandl <georg at python.org>

Hi Georg,

If you look on this page:
https://docs.python.org/3.4/library/getpass.html#module-getpass

The docs for getpass.getuser() say

"...otherwise, an exception is raised."

But does not specify what that exception might be. So now people must
write the catch all

    try:
	user = getpass.getuser()
    except:
	# handle failure

I think as a matter of policy, if a function or method can raise
exceptions, the specific ones (or their base type) should be mentioned
in the documentation so that people can catch just those and not use a
catch-all which might hide bugs.

Thanks!
- -- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    Python and PyQt/PySide - training and consultancy
        "Python in Practice" - ISBN 978-0321905635
            http://www.qtrac.eu/pipbook.html



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlOQPIAACgkQN9GcIYhpnLB6AgCdF2PiYLt3dLYO20pP2Uf/Q1pR
K6gAnAnp4JJGqXXHXJOGVw2q9jMllrS1
=2+h5
-----END PGP SIGNATURE-----

From report at bugs.python.org  Thu Jun  5 13:02:23 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:02:23 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
Message-ID: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Based on the recent python-dev thread, I propose the following "CPython implementation detail" note in the "Strings" entry of https://docs.python.org/3/reference/datamodel.html#objects-values-and-types

"CPython currently guarantees O(1) access to arbitrary code points when indexing and slicing a string. Python implementations are required to index and slice strings as arrays of code points, but are not required to guarantee O(1) access to arbitrary locations within the string. This allows implementations to use variable width encodings for their internal string representation."

----------
assignee: docs at python
components: Documentation
messages: 219793
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Clarify status of O(1) indexing semantics of str objects
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun  5 13:05:12 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Jun 2014 11:05:12 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401966312.45.0.746688823595.issue21667@psf.upfronthosting.co.za>


STINNER Victor added the comment:

str[a:b] returns a substring (characters), not an array of code points (numbers).

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Jun  5 13:06:08 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:06:08 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401966368.93.0.0557044404603.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Guido, I think we need your call on whether or not to add a note about string indexing algorithmic complexity to the language reference, and to approve the exact wording of such a note (my proposed wording is in my initial comment on this issue).

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Thu Jun  5 13:08:38 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:08:38 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401966518.75.0.251393153183.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

No, Python doesn't expose Unicode characters in its data model at all, except in those cases where a code point happens to correspond directly with a character. A length 1 str instance represents a Unicode code point, not a Unicode character.

----------

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

From report at bugs.python.org  Thu Jun  5 13:09:49 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:09:49 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401966589.59.0.0908799943698.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Although, you're right, that section of the data model docs misuses the word "character" to mean something other than what it means in the Unicode spec :(

----------

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

From report at bugs.python.org  Thu Jun  5 13:10:40 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Jun 2014 11:10:40 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401966640.27.0.827426577798.issue21667@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"Python implementations are required to ..."

By the way, Python < 3.3 doesn't implement this requirement :-)

----------

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

From report at bugs.python.org  Thu Jun  5 13:17:54 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:17:54 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401967074.72.0.307894599537.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Saying that ord() and chr() switch between characters and code points is just plain wrong, since characters may be represented as multiple code points.

We may also want to explicitly note that the Unicode normalisation is implementation dependendent, and that CPython doesn't normalise implicitly except where specifically noted (i.e. during lexical analysis).

----------

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

From report at bugs.python.org  Thu Jun  5 13:18:43 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:18:43 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401967123.67.0.326687251478.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, narrow builds have long been broken - that's a large part of why this is now the requirement :)

----------

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

From report at bugs.python.org  Thu Jun  5 13:29:06 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:29:06 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401967746.21.0.269978439035.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Patch attached that also addresses the characters vs code points confusion.

----------
Added file: http://bugs.python.org/file35489/issue21667_clarify_str_specification.rst

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

From report at bugs.python.org  Thu Jun  5 13:29:45 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 11:29:45 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401967785.64.0.908222056285.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I ducked the Unicode normalisation question for now, since that's a *different* can of worms :)

----------

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

From report at bugs.python.org  Thu Jun  5 14:02:59 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Jun 2014 12:02:59 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401969779.51.0.083332544158.issue21667@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Two things:
- I don't think it's very helpful to use the term "code point" without explaining or introducing it ("character" at least can be understood intuitively)
- The mention of slicing is ambiguous: is slicing suppoded to be O(1)? how is indexing related to slicing?

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu Jun  5 14:34:08 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 Jun 2014 12:34:08 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401971648.18.0.0439993458759.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

If someone doesn't understand what "Unicode code point" means, that's going to be the least of their problems when it comes to implementing a conformant Python implementation. We could link to http://unicode.org/glossary/#code_point, but that doesn't really add much beyond "value from 0 to 0x10FFFF". If you try to dive into the formal Unicode spec instead, you end up in a twisty maze of definitions of things that are all closely related, but generally not the same thing (code positions, code units, code spaces, abstract characters, glyphs, graphemes, etc).

The main advantage of using the more formal "code point" over the informal "character" is that it discourages people from assuming they know what they are (with the usual mistaken assumption being that Unicode code points correspond directly to glyphs the way ASCII and Extended ASCII printable characters correspond to their glyphs). The rest of the paragraph then provides the mechanical details of the meaningful interpretations of them in Python (as length 1 strings and as numbers in a particular range) and the operations for translating between those two formats (chr and ord).

Fair point about the slicing - it may be better to just talk about indexing.

----------

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

From report at bugs.python.org  Thu Jun  5 14:37:41 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 Jun 2014 12:37:41 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401971861.83.0.953771961096.issue21667@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Not sure what implementing a conformant Python implementation has to do with this; the language specification should be readable by any interested programmers, IMO.

> If you try to dive into the formal Unicode spec instead, you end up
> in a twisty maze of definitions of things that are all closely 
> related, but generally not the same thing (code positions, code units, 
> code spaces, abstract characters, glyphs, graphemes, etc).

That makes all the less useful to use the "proper term" instead of the more intuitive alternative :-)

----------

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

From report at bugs.python.org  Thu Jun  5 14:45:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 Jun 2014 12:45:52 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401972352.31.0.621886682677.issue21667@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then perhaps we need notes about algorithmic complexity of bytes, bytearray, list and tuple and dict indexing, set.add and set.discard, dict.__delitem__, list.pop, len(), + and += for all basic sequences and containers, memoryview() for bytes, bytearray and array.array, etc, etc.

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

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

From report at bugs.python.org  Thu Jun  5 14:49:03 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 05 Jun 2014 12:49:03 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401972352.31.0.621886682677.issue21667@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZdJLgai1uX3F0tf-WWCGpoNc0CStLP3K34MFZvc4Er=g@mail.gmail.com>


STINNER Victor added the comment:

> Then perhaps we need notes about algorithmic complexity of bytes, bytearray, list and tuple and dict indexing, set.add and set.discard, dict.__delitem__, list.pop, len(), + and += for all basic sequences and containers, memoryview() for bytes, bytearray and array.array, etc, etc.

That would be awesome :-) Please open a new issue for that. We can use
for example these data:
https://wiki.python.org/moin/TimeComplexity

Such data should be close to the definition of the type, or even close
to the method. Maybe directly in the documentation of each method?

----------

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

From report at bugs.python.org  Thu Jun  5 14:51:05 2014
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 05 Jun 2014 12:51:05 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401972665.64.0.124542299942.issue21667@psf.upfronthosting.co.za>


Changes by Chris Angelico <rosuav at gmail.com>:


----------
nosy: +Rosuav

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

From report at bugs.python.org  Thu Jun  5 18:32:42 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 Jun 2014 16:32:42 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1401985962.62.0.0707459516558.issue21667@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't want the O(1) property explicitly denounced in the reference manual. It's fine if the manual is silent on this -- maybe someone can prove that it isn't a problem based on benchmarks of an alternate implementation, but until then, I'm skeptical -- after all we have a bunch of important APIs (indexing, slicing, find()/index(), the re module) that use integer indexes, and some important algorithms/patterns are based off this behavior.

E.g. searching a string for something, returning the position where it's found, and then continuing the search from that position. Even if the basic search uses find() or regex matching, there's still a position being returned and accepted, and if it took O(N) time to find that position in the representation, the whole algorithm could degenerate from O(N) to O(N**2).

I am fine with the changes related to code points.

For the pedants amongst us, surrogates are also code points. A surrogate pair is two code points that encode a single code point. Fortunately we don't have to deal with those any more outside codecs.

----------

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

From report at bugs.python.org  Thu Jun  5 20:40:34 2014
From: report at bugs.python.org (Zoinkity .)
Date: Thu, 05 Jun 2014 18:40:34 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1401993634.68.0.945141699111.issue19548@psf.upfronthosting.co.za>


Zoinkity . added the comment:

One glaring omission is any information about multibyte codecs--the class, its methods, and how to even define one.  

Also, the primary use for codecs.register would be to append a single codec to the lookup registry.  Simple usage of the method only provides lookup for the provided codecs and will not include regularly-accessible ones such as "utf-8".  It would be enormously helpful to provide an example of proper, safe usage.

----------
nosy: +Zoinkity..

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

From report at bugs.python.org  Thu Jun  5 20:41:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jun 2014 18:41:51 +0000
Subject: [docs] [issue21661] setuptools documentation: typo
In-Reply-To: <1401896975.69.0.474580151289.issue21661@psf.upfronthosting.co.za>
Message-ID: <3gkwnW081Pz7Ljw@mail.python.org>


Roundup Robot added the comment:

New changeset a708844c1b8d by Zachary Ware in branch '3.4':
Issue #21661: Fix typo.
http://hg.python.org/cpython/rev/a708844c1b8d

New changeset 1b02b771b1fa by Zachary Ware in branch 'default':
Closes #21661: Merge typo fix.
http://hg.python.org/cpython/rev/1b02b771b1fa

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

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

From report at bugs.python.org  Thu Jun  5 20:52:00 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 05 Jun 2014 18:52:00 +0000
Subject: [docs] [issue21661] setuptools documentation: typo
In-Reply-To: <1401896975.69.0.474580151289.issue21661@psf.upfronthosting.co.za>
Message-ID: <1401994320.4.0.87291949756.issue21661@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report and patch!

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

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

From report at bugs.python.org  Thu Jun  5 21:17:19 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jun 2014 19:17:19 +0000
Subject: [docs] [issue21653] Row.keys() in sqlite3 returns a list,
	not a tuple
In-Reply-To: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>
Message-ID: <3gkxZQ3b0hz7Ljl@mail.python.org>


Roundup Robot added the comment:

New changeset f51ecdac91c8 by R David Murray in branch '2.7':
#21653: fix doc for return type of sqlite3.Row.keys().
http://hg.python.org/cpython/rev/f51ecdac91c8

New changeset 6c890b2739f4 by R David Murray in branch '3.4':
#21653: fix doc for return type of sqlite3.Row.keys().
http://hg.python.org/cpython/rev/6c890b2739f4

New changeset e65cd43d136b by R David Murray in branch 'default':
Merge: #21653: fix doc for return type of sqlite3.Row.keys().
http://hg.python.org/cpython/rev/e65cd43d136b

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

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

From report at bugs.python.org  Thu Jun  5 21:18:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Jun 2014 19:18:47 +0000
Subject: [docs] [issue21653] Row.keys() in sqlite3 returns a list,
	not a tuple
In-Reply-To: <1401833541.21.0.885626221521.issue21653@psf.upfronthosting.co.za>
Message-ID: <1401995927.91.0.223182139918.issue21653@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed.  Thanks for the report.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jun  5 21:33:03 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 Jun 2014 19:33:03 +0000
Subject: [docs] [issue21662] datamodel documentation: fix typo and phrasing
In-Reply-To: <1401898433.15.0.977060998542.issue21662@psf.upfronthosting.co.za>
Message-ID: <3gkxwZ5ywDz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset ead4dee062e3 by R David Murray in branch '3.4':
#21662: fix typo, improve sentence flow
http://hg.python.org/cpython/rev/ead4dee062e3

New changeset 3aa21b5b145a by R David Murray in branch 'default':
Merge #21662: fix typo, improve sentence flow
http://hg.python.org/cpython/rev/3aa21b5b145a

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

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

From report at bugs.python.org  Thu Jun  5 21:35:00 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 Jun 2014 19:35:00 +0000
Subject: [docs] [issue21662] datamodel documentation: fix typo and phrasing
In-Reply-To: <1401898433.15.0.977060998542.issue21662@psf.upfronthosting.co.za>
Message-ID: <1401996900.61.0.244023103346.issue21662@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks.

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

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

From report at bugs.python.org  Fri Jun  6 05:30:32 2014
From: report at bugs.python.org (Anthony Bartoli)
Date: Fri, 06 Jun 2014 03:30:32 +0000
Subject: [docs] [issue21675] Library - Introduction - paragraph 5 - wrong
	ordering
Message-ID: <1402025432.44.0.956815380297.issue21675@psf.upfronthosting.co.za>


New submission from Anthony Bartoli:

>From the library's introduction page:

"This manual is organized ?from the inside out:? it first describes the built-in data types..."

The library manual first describes built-in functions, not data types. 

After built-in functions, it describes built-in constants, built-in types, and built-in exceptions. Lastly, it describes modules grouped by related functionality. 

A suggested re-write *for the entire paragraph*:

"The library manual first documents built-in functions, built-in constants, built-in types, and built-in exceptions. Then it documents modules grouped by related functionality. 

I suggest eliminating the last sentence:

"The ordering of the chapters as well as the ordering of the modules within each chapter is roughly from most relevant to least important."

Importance is subjective and parts of the manual are organized alphabetically, not by relevance / importance.

----------
assignee: docs at python
components: Documentation
messages: 219860
nosy: AnthonyBartoli, docs at python
priority: normal
severity: normal
status: open
title: Library - Introduction - paragraph 5 - wrong ordering
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun  6 13:11:22 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 06 Jun 2014 11:11:22 +0000
Subject: [docs] [issue21365] asyncio.Task reference misses the most
	important fact	about it,
	related info spread around intros and example commentary instead
In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za>
Message-ID: <1402053082.95.0.190191265461.issue21365@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
components: +Asyncio

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

From report at bugs.python.org  Fri Jun  6 13:43:03 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 11:43:03 +0000
Subject: [docs] [issue21437] document that asyncio.ProactorEventLoop doesn't
	support	SSL
In-Reply-To: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za>
Message-ID: <1402054983.62.0.520600808941.issue21437@psf.upfronthosting.co.za>


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


----------
components: +Asyncio

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

From report at bugs.python.org  Fri Jun  6 13:43:34 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 11:43:34 +0000
Subject: [docs] [issue21596] asyncio.wait fails when futures list is empty
In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>
Message-ID: <1402055014.54.0.720213491941.issue21596@psf.upfronthosting.co.za>


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


----------
components: +Asyncio

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

From report at bugs.python.org  Fri Jun  6 13:45:27 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 11:45:27 +0000
Subject: [docs] [issue21443] asyncio logging documentation clarifications
In-Reply-To: <1399321197.68.0.955361534546.issue21443@psf.upfronthosting.co.za>
Message-ID: <1402055127.34.0.365217714581.issue21443@psf.upfronthosting.co.za>


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


----------
components: +Asyncio

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

From report at bugs.python.org  Fri Jun  6 14:28:02 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 12:28:02 +0000
Subject: [docs] [issue21596] asyncio.wait fails when futures list is empty
In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>
Message-ID: <1402057682.7.0.57174343078.issue21596@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Probably this was the intended behavior as I see there's a test case for that. If such, then I would propose to document that behavior.

The code has an explicit check:

    if not fs:
        raise ValueError('Set of coroutines/Futures is empty.')

And yes, the behaviour is tested by test_asyncio.

Attached patch changes mention this behaviour in the documentation. Does it look correct?

----------
keywords: +patch
Added file: http://bugs.python.org/file35496/wait_doc.patch

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

From report at bugs.python.org  Fri Jun  6 14:41:35 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 12:41:35 +0000
Subject: [docs] [issue21680] asyncio: document event loops
Message-ID: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Currently, the different implementations of asyncio event loop are not listed in the documentation. But they are mentionned in some places, like in the subprocess section to mention that Proactor doesn't support subprocess or that they are issues with Kqueue on old Mac OS X versions.

It would be useful to mention at least the name of each event loop.

Each event loop has specific features or different limitations. See for example the issue #21437 which asks to mention that the proactor event loop doesn't support SSL.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 219878
nosy: docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: document event loops
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jun  6 14:42:22 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 06 Jun 2014 12:42:22 +0000
Subject: [docs] [issue21437] document that asyncio.ProactorEventLoop doesn't
	support	SSL
In-Reply-To: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za>
Message-ID: <1402058542.84.0.436083379917.issue21437@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The first problem is that event loops are not documented at all: I created the issue #21680 to document them.

----------

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

From report at bugs.python.org  Fri Jun  6 15:00:46 2014
From: report at bugs.python.org (Sebastian Kreft)
Date: Fri, 06 Jun 2014 13:00:46 +0000
Subject: [docs] [issue21596] asyncio.wait fails when futures list is empty
In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>
Message-ID: <1402059646.21.0.411651137796.issue21596@psf.upfronthosting.co.za>


Sebastian Kreft added the comment:

LGTM.

----------

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

From report at bugs.python.org  Sat Jun  7 15:22:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jun 2014 13:22:28 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <3gm1c40G4GzS13@mail.python.org>


Roundup Robot added the comment:

New changeset 6ffb6909c439 by Nick Coghlan in branch '3.4':
Issue #21667: Clarify string data model description
http://hg.python.org/cpython/rev/6ffb6909c439

New changeset 7c120e77d6f7 by Nick Coghlan in branch 'default':
Merge issue #21667 from 3.4
http://hg.python.org/cpython/rev/7c120e77d6f7

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

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

From report at bugs.python.org  Sat Jun  7 15:26:31 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jun 2014 13:26:31 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1402147591.06.0.0999203250662.issue21667@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've merged the character->code point clarifications, without the implementation detail section.

For the time being, that leaves "doesn't provide O(1) indexing of strings" as the kind of discrepancy that often makes an appearance in "differences from the CPython reference implementation" section that many alternative implementations include.

----------
resolution:  -> later
stage:  -> resolved
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Sat Jun  7 17:07:20 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 07 Jun 2014 15:07:20 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1402153640.01.0.427363626568.issue8840@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is any more work needed here as msg106725 asks about updating doc strings?

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

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

From report at bugs.python.org  Sat Jun  7 17:18:12 2014
From: report at bugs.python.org (Florian Walch)
Date: Sat, 07 Jun 2014 15:18:12 +0000
Subject: [docs] [issue21687] Py_SetPath: Path components separated by colons
Message-ID: <1402154292.52.0.48898043171.issue21687@psf.upfronthosting.co.za>


New submission from Florian Walch:

The documentation for Py_SetPath [1] states:

> The path components should be separated by semicolons.

I believe this should not say "semicolons", but "colons"; the default path as output by Py_GetPath is separated by colons.

[1] https://docs.python.org/3/c-api/init.html#c.Py_SetPath

----------
assignee: docs at python
components: Documentation
messages: 219944
nosy: docs at python, fwalch
priority: normal
severity: normal
status: open
title: Py_SetPath: Path components separated by colons
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun  7 18:47:51 2014
From: report at bugs.python.org (eryksun)
Date: Sat, 07 Jun 2014 16:47:51 +0000
Subject: [docs] [issue21687] Py_SetPath: Path components separated by colons
In-Reply-To: <1402154292.52.0.48898043171.issue21687@psf.upfronthosting.co.za>
Message-ID: <1402159671.58.0.0637636145639.issue21687@psf.upfronthosting.co.za>


eryksun added the comment:

A Windows path uses ":" after the drive letter, e.g. "C:\\Windows", so the delimiter is a semicolon on Windows. Other platforms use a colon.

CPython uses DELIM, which is defined in osdefs.h. This header isn't included by Python.h.

http://hg.python.org/cpython/file/c0e311e010fc/Include/osdefs.h

----------
nosy: +eryksun

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

From report at bugs.python.org  Sat Jun  7 19:48:07 2014
From: report at bugs.python.org (Greg)
Date: Sat, 07 Jun 2014 17:48:07 +0000
Subject: [docs] [issue10503] os.getuid() documentation should be clear on
	what kind	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1402163287.72.0.808820339836.issue10503@psf.upfronthosting.co.za>


Greg added the comment:

Here's a wording change in the documentation to clarify this.

----------
keywords: +patch
nosy: +????????????
Added file: http://bugs.python.org/file35514/mywork.patch

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

From report at bugs.python.org  Sat Jun  7 20:52:49 2014
From: report at bugs.python.org (Emily Zhao)
Date: Sat, 07 Jun 2014 18:52:49 +0000
Subject: [docs] [issue15569] Doc doc: incorrect description of some roles
	as	format-only
In-Reply-To: <1344302647.18.0.307450045197.issue15569@psf.upfronthosting.co.za>
Message-ID: <1402167169.33.0.154222730596.issue15569@psf.upfronthosting.co.za>


Emily Zhao added the comment:

I moved the 3 misplaced roles (envvar, keyword, and option) and changed the description for the new section per Terry's suggestions. Patch is attached and needs to go in the devguide repo.

https://docs.python.org/devguide/docquality.html#helping-with-the-developers-guide

----------
keywords: +patch
nosy: +emily.zhao
Added file: http://bugs.python.org/file35517/issue15569.patch

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

From report at bugs.python.org  Sat Jun  7 21:18:11 2014
From: report at bugs.python.org (Dhanam Prakash)
Date: Sat, 07 Jun 2014 19:18:11 +0000
Subject: [docs] [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1402168691.74.0.59805306873.issue12833@psf.upfronthosting.co.za>


Dhanam Prakash added the comment:

Hi,
submitting a patch for the documentation.
Thanks

----------
hgrepos: +254
keywords: +patch
nosy: +dhanamp
Added file: http://bugs.python.org/file35519/issue12833.patch

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

From report at bugs.python.org  Sat Jun  7 21:31:04 2014
From: report at bugs.python.org (Katherine Busch)
Date: Sat, 07 Jun 2014 19:31:04 +0000
Subject: [docs] [issue21404] Document options used to control compression
	level in	tarfile
In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za>
Message-ID: <1402169464.26.0.699082996479.issue21404@psf.upfronthosting.co.za>


Katherine Busch added the comment:

Here's a patch. The docs built and I inspected the output. Everything looks correct.

----------
keywords: +patch
nosy: +Katherine.Busch
Added file: http://bugs.python.org/file35520/tardocs.patch

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

From report at bugs.python.org  Sat Jun  7 21:34:14 2014
From: report at bugs.python.org (Jessica McKellar)
Date: Sat, 07 Jun 2014 19:34:14 +0000
Subject: [docs] [issue21404] Document options used to control compression
	level in	tarfile
In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za>
Message-ID: <1402169654.23.0.474076510238.issue21404@psf.upfronthosting.co.za>


Changes by Jessica McKellar <jesstess at mit.edu>:


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Jun  7 21:48:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jun 2014 19:48:18 +0000
Subject: [docs] [issue21404] Document options used to control compression
	level in	tarfile
In-Reply-To: <1398892016.48.0.640823521737.issue21404@psf.upfronthosting.co.za>
Message-ID: <3gmB9F48SVz7LnR@mail.python.org>


Roundup Robot added the comment:

New changeset 390b7fd617a9 by Benjamin Peterson in branch '2.7':
document the compress_level argument to tarfile.open (closes #21404)
http://hg.python.org/cpython/rev/390b7fd617a9

New changeset 0c712828fb6e by Benjamin Peterson in branch '3.4':
document the compress_level argument to tarfile.open (closes #21404)
http://hg.python.org/cpython/rev/0c712828fb6e

New changeset 171e8f6c814c by Benjamin Peterson in branch 'default':
merge 3.4 (#21404)
http://hg.python.org/cpython/rev/171e8f6c814c

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

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

From report at bugs.python.org  Sat Jun  7 21:48:22 2014
From: report at bugs.python.org (Yuly Tenorio)
Date: Sat, 07 Jun 2014 19:48:22 +0000
Subject: [docs] [issue21689] Docs for "Using Python on a Macintosh" needs to
	be	updated.
Message-ID: <1402170502.2.0.981560752161.issue21689@psf.upfronthosting.co.za>


New submission from Yuly Tenorio:

"Using Python on a Mac" needs updating since it is pointing to old tools and documentation.

This is related to http://bugs.python.org/issue12594

----------
assignee: docs at python
components: Documentation
messages: 219968
nosy: docs at python, ned.deily, yuly
priority: normal
severity: normal
status: open
title: Docs for "Using Python on a Macintosh" needs to be updated.
versions: Python 3.5

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

From report at bugs.python.org  Sat Jun  7 22:00:19 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jun 2014 20:00:19 +0000
Subject: [docs] [issue12594] Docs for "Using Python on a Macintosh" needs to
	be	updated
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1402171219.82.0.756370901769.issue12594@psf.upfronthosting.co.za>


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


----------
title: Docs for py3k still refer to "MacPython 2.5 folder" -> Docs for "Using Python on a Macintosh" needs to be updated
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun  7 22:01:03 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jun 2014 20:01:03 +0000
Subject: [docs] [issue21689] Docs for "Using Python on a Macintosh" needs to
	be	updated.
In-Reply-To: <1402170502.2.0.981560752161.issue21689@psf.upfronthosting.co.za>
Message-ID: <1402171263.83.0.819229792929.issue21689@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yes but I don't think we need to have two issues open.  Let's make any comments in the already open issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Docs for "Using Python on a Macintosh" needs to be updated

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

From report at bugs.python.org  Sat Jun  7 22:52:00 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jun 2014 20:52:00 +0000
Subject: [docs] [issue10503] os.getuid() documentation should be clear on
	what kind	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <3gmCZl3xTsz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 19172062e5c0 by Benjamin Peterson in branch '3.4':
specify that getuid() returns the real uid (closes #10503)
http://hg.python.org/cpython/rev/19172062e5c0

New changeset 6dfbe504f659 by Benjamin Peterson in branch '2.7':
specify that getuid() returns the real uid (closes #10503)
http://hg.python.org/cpython/rev/6dfbe504f659

New changeset 8866ac6f2269 by Benjamin Peterson in branch 'default':
merge 3.4 (#10503)
http://hg.python.org/cpython/rev/8866ac6f2269

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

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

From report at bugs.python.org  Sat Jun  7 23:12:41 2014
From: report at bugs.python.org (Greg)
Date: Sat, 07 Jun 2014 21:12:41 +0000
Subject: [docs] [issue12706] timeout sentinel in ftplib and poplib
	documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1402175561.41.0.0956033687825.issue12706@psf.upfronthosting.co.za>


Greg added the comment:

In the definition of FTP.connect(), I've changed the code to actually use None as a lack-of-explicit-timeout sentinel instead of -999. For FTP and FTP_TLS, I've changed the documentation to reflect what the code is doing.

----------
keywords: +patch
nosy: +????????????
Added file: http://bugs.python.org/file35524/patch.patch

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

From report at bugs.python.org  Sat Jun  7 23:24:11 2014
From: report at bugs.python.org (Emily Zhao)
Date: Sat, 07 Jun 2014 21:24:11 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1402176251.31.0.252321637432.issue21314@psf.upfronthosting.co.za>


Emily Zhao added the comment:

Can someone close this? I think it's fixed.

----------
nosy: +emily.zhao

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

From report at bugs.python.org  Sat Jun  7 23:25:17 2014
From: report at bugs.python.org (Yuly Tenorio)
Date: Sat, 07 Jun 2014 21:25:17 +0000
Subject: [docs] [issue12594] Docs for "Using Python on a Macintosh" needs to
	be	updated
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1402176317.66.0.715913043212.issue12594@psf.upfronthosting.co.za>


Yuly Tenorio added the comment:

Built with sphinx. No RST errors.

----------
keywords: +patch
nosy: +yuly
Added file: http://bugs.python.org/file35526/pythonusage_mac.patch

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

From report at bugs.python.org  Sat Jun  7 23:38:25 2014
From: report at bugs.python.org (Emily Zhao)
Date: Sat, 07 Jun 2014 21:38:25 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1402177105.73.0.971695834209.issue11681@psf.upfronthosting.co.za>


Emily Zhao added the comment:

Might be worth making this addition from 3 (I'm not sure how to add this to 2)
-b     : issue warnings about str(bytes_instance), str(bytearray_instance)
         and comparing bytes/bytearray with str. (-bb: issue errors)


Building on Martin's example:

On all of these, python2 is
Python 2.7.6 (default, Apr  6 2014, 23:14:26)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.


emily-mba:cpython emily$ python2
>>> bytearray("3") == u"3"
False

emily-mba:cpython emily$ python2 -b
>>> bytearray("3") == u"3"
__main__:1: BytesWarning: Comparison between bytearray and string
False

emily-mba:cpython emily$ python2 -bb
>>> bytearray("3") == u"3"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BytesWarning: Comparison between bytearray and string

----------
nosy: +emily.zhao

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

From report at bugs.python.org  Sat Jun  7 23:44:59 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 07 Jun 2014 21:44:59 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1402177499.53.0.173179933902.issue21314@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The original bug (junk in various doc strings) has been fixed, but I think the positional argument "/" syntax still needs docs. It's a little tricky because "/" is not actually valid syntax; it's just for documentation signatures.

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

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

From report at bugs.python.org  Sat Jun  7 23:59:05 2014
From: report at bugs.python.org (Emily Zhao)
Date: Sat, 07 Jun 2014 21:59:05 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1402178345.69.0.327669573189.issue11681@psf.upfronthosting.co.za>


Emily Zhao added the comment:

Here's an attempt (based on 3's main.c http://hg.python.org/cpython/file/8866ac6f2269/Modules/main.c)

----------
keywords: +patch
Added file: http://bugs.python.org/file35528/issue11681.patch

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

From report at bugs.python.org  Sun Jun  8 00:09:31 2014
From: report at bugs.python.org (Emily Zhao)
Date: Sat, 07 Jun 2014 22:09:31 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1402178970.96.0.668843381758.issue21314@psf.upfronthosting.co.za>


Emily Zhao added the comment:

where's the best place for that documentation to live?

----------

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

From report at bugs.python.org  Sun Jun  8 00:20:23 2014
From: report at bugs.python.org (Ned Deily)
Date: Sat, 07 Jun 2014 22:20:23 +0000
Subject: [docs] [issue12594] Docs for "Using Python on a Macintosh" needs to
	be	updated
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1402179623.29.0.496627959753.issue12594@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thank you for the patch, Yuly!  You've made some good improvements to the current page.  Because the current section is so old and out-of-sync with current practices (as you've noted in your changes) and with the nuances of Python on OS X, a more comprehensive restructuring is needed.  I don't think that trying to refine the section interactively is going to be an efficient process but I will definitely use your suggested changes as a basis.  I assume you have signed (or will be signing) the PSF contributor agreement.  Thanks again!  P.S. When submitting patches, don't forget to run patchcheck first (https://docs.python.org/devguide/patch.html#generation).  It will detect and fix trailing whitespace in lines that would otherwise prevent a patch from being committed in the main cpython hg repo.

----------

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

From report at bugs.python.org  Sun Jun  8 00:40:03 2014
From: report at bugs.python.org (Amandine Lee)
Date: Sat, 07 Jun 2014 22:40:03 +0000
Subject: [docs] [issue12063] tokenize module appears to treat unterminated
	single and	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <1402180803.79.0.727895640798.issue12063@psf.upfronthosting.co.za>


Amandine Lee added the comment:

I confirmed that the behavior acts as described. I added a patch documenting the behavior, built the docs with the patch, and visually confirmed that the docs looks appropriate. 

Ready for review!

----------
keywords: +patch
nosy: +amandine
Added file: http://bugs.python.org/file35532/issue12063.patch

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

From report at bugs.python.org  Sun Jun  8 00:45:36 2014
From: report at bugs.python.org (Renee Chu)
Date: Sat, 07 Jun 2014 22:45:36 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1402181136.42.0.42343663186.issue11974@psf.upfronthosting.co.za>


Renee Chu added the comment:

Submitting a patch for documentation.

----------
hgrepos: +255
keywords: +patch
nosy: +reneighbor
Added file: http://bugs.python.org/file35533/issue11974.patch

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

From report at bugs.python.org  Sun Jun  8 00:46:54 2014
From: report at bugs.python.org (Yayoi Ukai)
Date: Sat, 07 Jun 2014 22:46:54 +0000
Subject: [docs] [issue16667] timezone docs need "versionadded: 3.2"
In-Reply-To: <1355272202.83.0.0809647453086.issue16667@psf.upfronthosting.co.za>
Message-ID: <1402181214.47.0.326580819534.issue16667@psf.upfronthosting.co.za>


Yayoi Ukai added the comment:

I did make patchcheck and make html and checked all versions HTML documents and looks great. Good job!

----------
nosy: +terab

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

From report at bugs.python.org  Sun Jun  8 01:25:03 2014
From: report at bugs.python.org (Julian Gilbey)
Date: Sat, 07 Jun 2014 23:25:03 +0000
Subject: [docs] [issue21690] re documentation: re.compile links to re.search
	/	re.match instead of regex.search / regex.match
Message-ID: <1402183503.23.0.87974807547.issue21690@psf.upfronthosting.co.za>


New submission from Julian Gilbey:

In re.rst, the re.compile documentation says:

   Compile a regular expression pattern into a regular expression object, which
   can be used for matching using its :func:`match` and :func:`search` methods,
   described below.

This results in linking to the re.match and re.search module functions instead of the regex.match and regex.search object methods.  I'm not sure what the correct replacement syntax is, presumably something like :meth:`~regex.match` and :meth:`~regex.search`.

----------
assignee: docs at python
components: Documentation
messages: 219997
nosy: docs at python, jdg
priority: normal
severity: normal
status: open
title: re documentation: re.compile links to re.search / re.match instead of regex.search / regex.match
versions: Python 3.4

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

From report at bugs.python.org  Sun Jun  8 01:26:46 2014
From: report at bugs.python.org (Yuly Tenorio)
Date: Sat, 07 Jun 2014 23:26:46 +0000
Subject: [docs] [issue12594] Docs for "Using Python on a Macintosh" needs to
	be	updated
In-Reply-To: <1311174057.47.0.56455855185.issue12594@psf.upfronthosting.co.za>
Message-ID: <1402183606.57.0.275431621219.issue12594@psf.upfronthosting.co.za>


Yuly Tenorio added the comment:

Ok, I will definitely use that checker next time :) thanks!
Thanks Ned!

----------

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

From report at bugs.python.org  Sun Jun  8 01:43:16 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 Jun 2014 23:43:16 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1402184596.43.0.3364230547.issue11681@psf.upfronthosting.co.za>


Martin Panter added the comment:

Trouble is, in Python 2 bytes() and str() are the same thing, and most of those conditions don?t apply. Maybe something like this is more correct:

-b     : issue warnings about comparing bytearray with unicode.
         (-bb: issue errors)

----------

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

From report at bugs.python.org  Sun Jun  8 02:09:57 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Jun 2014 00:09:57 +0000
Subject: [docs] [issue16667] timezone docs need "versionadded: 3.2"
In-Reply-To: <1355272202.83.0.0809647453086.issue16667@psf.upfronthosting.co.za>
Message-ID: <1402186197.82.0.130878351553.issue16667@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The attached patch combines my changes with Andrew's patch.

----------
versions: +Python 3.5 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file35534/issue16667_v3.diff

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

From report at bugs.python.org  Sun Jun  8 02:56:03 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jun 2014 00:56:03 +0000
Subject: [docs] [issue12063] tokenize module appears to treat unterminated
	single and	double-quoted strings inconsistently
In-Reply-To: <1305209970.17.0.31373709531.issue12063@psf.upfronthosting.co.za>
Message-ID: <3gmK0H5t2Xz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 188e5f42d4aa by Benjamin Peterson in branch '2.7':
document TokenError and unclosed expression behavior (closes #12063)
http://hg.python.org/cpython/rev/188e5f42d4aa

New changeset ddc174c4c7e5 by Benjamin Peterson in branch '3.4':
document TokenError and unclosed expression behavior (closes #12063)
http://hg.python.org/cpython/rev/ddc174c4c7e5

New changeset 3f2f1ffc3ce2 by Benjamin Peterson in branch 'default':
merge 3.4 (#12063)
http://hg.python.org/cpython/rev/3f2f1ffc3ce2

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

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

From report at bugs.python.org  Sun Jun  8 10:17:44 2014
From: report at bugs.python.org (Yann Lebel)
Date: Sun, 08 Jun 2014 08:17:44 +0000
Subject: [docs] [issue21693] Broken link to Pylons in the HOWTO
	TurboGears	documentation
Message-ID: <1402215464.69.0.795640420868.issue21693@psf.upfronthosting.co.za>


New submission from Yann Lebel:

The link to the Pylons framework present at the end of theHOWTO -> HOWTO Use Python in the web -> TurboGears documentation section redirect to a domain that does not exists anymore.

I believe it should be replaced by http://www.pylonsproject.org/

Here is the link to the documentation section
https://docs.python.org/3/howto/webservers.html#turbogears

----------
assignee: docs at python
components: Documentation
messages: 220027
nosy: Yann.Lebel, docs at python
priority: normal
severity: normal
status: open
title: Broken link to Pylons in the HOWTO TurboGears documentation
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sun Jun  8 10:24:39 2014
From: report at bugs.python.org (Yann Lebel)
Date: Sun, 08 Jun 2014 08:24:39 +0000
Subject: [docs] [issue21693] Broken link to Pylons in the HOWTO
	TurboGears	documentation
In-Reply-To: <1402215464.69.0.795640420868.issue21693@psf.upfronthosting.co.za>
Message-ID: <1402215879.37.0.0808792715986.issue21693@psf.upfronthosting.co.za>


Yann Lebel added the comment:

I just noticed that the same broken link exists in the "Other notable frameworks" as well.

Here is the link to the section 
https://docs.python.org/3/howto/webservers.html#other-notable-frameworks

----------

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

From report at bugs.python.org  Mon Jun  9 00:17:01 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 08 Jun 2014 22:17:01 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1402265821.64.0.786832215462.issue11681@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/issue11681>
_______________________________________

From report at bugs.python.org  Mon Jun  9 16:02:51 2014
From: report at bugs.python.org (Milan Oberkirch)
Date: Mon, 09 Jun 2014 14:02:51 +0000
Subject: [docs] [issue20903] smtplib.SMTP raises socket.timeout
In-Reply-To: <1394664754.18.0.260499838693.issue20903@psf.upfronthosting.co.za>
Message-ID: <1402322571.33.0.99865973138.issue20903@psf.upfronthosting.co.za>


Milan Oberkirch added the comment:

Should this task get closed? (see comment above)

----------
nosy: +jesstess

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

From report at bugs.python.org  Mon Jun  9 22:41:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jun 2014 20:41:44 +0000
Subject: [docs] [issue20903] smtplib.SMTP raises socket.timeout
In-Reply-To: <1394664754.18.0.260499838693.issue20903@psf.upfronthosting.co.za>
Message-ID: <3gnRFy6xX2z7Lkk@mail.python.org>


Roundup Robot added the comment:

New changeset 6cd64ef6fc95 by R David Murray in branch '2.7':
#20903: clarify what happens when an smtp connection timeout occurs.
http://hg.python.org/cpython/rev/6cd64ef6fc95

New changeset ca88bcfa5c15 by R David Murray in branch '3.4':
#20903: clarify what happens when an smtp connection timeout occurs.
http://hg.python.org/cpython/rev/ca88bcfa5c15

New changeset 20225460ae0f by R David Murray in branch 'default':
Merge: #20903: clarify what happens when an smtp connection timeout occurs.
http://hg.python.org/cpython/rev/20225460ae0f

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

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

From report at bugs.python.org  Mon Jun  9 22:42:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 09 Jun 2014 20:42:44 +0000
Subject: [docs] [issue20903] smtplib.SMTP raises socket.timeout
In-Reply-To: <1394664754.18.0.260499838693.issue20903@psf.upfronthosting.co.za>
Message-ID: <1402346564.82.0.44034681879.issue20903@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, now that I applied your patch it can be :)  Thanks.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions:  -Python 3.3

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

From report at bugs.python.org  Tue Jun 10 02:19:35 2014
From: report at bugs.python.org (Allen Riddell)
Date: Tue, 10 Jun 2014 00:19:35 +0000
Subject: [docs] [issue21700] Missing mention of DatagramProtocol
	having	connection_made and connection_lost methods
Message-ID: <1402359574.1.0.968660255801.issue21700@psf.upfronthosting.co.za>


New submission from Allen Riddell:

The following important information from PEP 3156 does not appear in the asyncio library documentation:

"""Datagram protocols have connection_made() and connection_lost() methods with the same signatures as stream protocols."""

Indeed, reading the docs it looks like only ``Protocol`` and ``SubprocessProtocol`` have these methods. (See https://docs.python.org/3.4/library/asyncio-protocol.html#connection-callbacks)

The quick fix is to change the lines 275-276 in ``Doc/library/asyncio-protocol.rst`` from:

    These callbacks may be called on Protocol and SubprocessProtocol instances:

to

    These callbacks may be called on Protocol, DatagramProtocol, and SubprocessProtocol instances:

----------
assignee: docs at python
components: Documentation, asyncio
messages: 220130
nosy: ariddell, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Missing mention of DatagramProtocol having connection_made and connection_lost methods
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 09:21:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Jun 2014 07:21:18 +0000
Subject: [docs] [issue21700] Missing mention of DatagramProtocol
	having	connection_made and connection_lost methods
In-Reply-To: <1402359574.1.0.968660255801.issue21700@psf.upfronthosting.co.za>
Message-ID: <3gnjRx2ng7z7Lp4@mail.python.org>


Roundup Robot added the comment:

New changeset 79562a31e5a6 by Victor Stinner in branch '3.4':
Issue #21700: Fix asyncio doc, add DatagramProtocol
http://hg.python.org/cpython/rev/79562a31e5a6

New changeset a8dfdae4c4a0 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #21700: Fix asyncio doc, add DatagramProtocol
http://hg.python.org/cpython/rev/a8dfdae4c4a0

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

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

From report at bugs.python.org  Tue Jun 10 09:23:49 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Jun 2014 07:23:49 +0000
Subject: [docs] [issue21700] Missing mention of DatagramProtocol
	having	connection_made and connection_lost methods
In-Reply-To: <1402359574.1.0.968660255801.issue21700@psf.upfronthosting.co.za>
Message-ID: <1402385029.74.0.253000921895.issue21700@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Fixed. Thanks for the report.

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

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

From report at bugs.python.org  Tue Jun 10 09:35:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Jun 2014 07:35:33 +0000
Subject: [docs] [issue21702] asyncio: remote_addr of
	create_datagram_endpoint() is	not documented
Message-ID: <1402385733.37.0.0697912425381.issue21702@psf.upfronthosting.co.za>


New submission from STINNER Victor:

See issue #21701 for a recent issue about this parameter.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 220147
nosy: ariddell, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: remote_addr of create_datagram_endpoint() is not documented
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 10 11:16:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Jun 2014 09:16:28 +0000
Subject: [docs] [issue21596] asyncio.wait fails when futures list is empty
In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>
Message-ID: <3gnm0q20l5z7Lp5@mail.python.org>


Roundup Robot added the comment:

New changeset 2b3f8b6d6e5c by Victor Stinner in branch '3.4':
Issue #21596: asyncio.wait(): mention that the sequence of futures must not
http://hg.python.org/cpython/rev/2b3f8b6d6e5c

New changeset 68d45a1a3ce0 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #21596: asyncio.wait(): mention that the sequence of futures
http://hg.python.org/cpython/rev/68d45a1a3ce0

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

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

From report at bugs.python.org  Tue Jun 10 11:16:50 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 10 Jun 2014 09:16:50 +0000
Subject: [docs] [issue21596] asyncio.wait fails when futures list is empty
In-Reply-To: <1401294149.12.0.93780466725.issue21596@psf.upfronthosting.co.za>
Message-ID: <1402391810.61.0.521330886149.issue21596@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Fixed. Thanks for the report.

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

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

From report at bugs.python.org  Wed Jun 11 00:57:37 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 10 Jun 2014 22:57:37 +0000
Subject: [docs] [issue13101] Module Doc viewer closes when browser window
	closes on	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1402441057.11.0.304407282855.issue13101@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This works fine for me with Windows 7, Python 3.4.1 and Firefox 29.

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

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

From report at bugs.python.org  Wed Jun 11 01:02:39 2014
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 10 Jun 2014 23:02:39 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1402441359.87.0.778211367294.issue21667@psf.upfronthosting.co.za>


Jim Jewett added the comment:

I think the new wording is an improvement, but keeping the changes minimal left it in an awkward in-between state.

Proposal:

A string is a sequence of Unicode code points.  Strings can include any sequence of code points, including some which are semantically meaningless, or explicitly undefined.

Python doesn't have a :c:type:`char` type; a single code point is represented as a string of length ``1``.  The built-in function :func:`chr` translates an integer in the range ``U+0000 - U+10FFFF`` to the corresponding length ``1`` string object, and :func:`ord` does the reverse.

:meth:`str.encode` provides a concrete representation (as :class:`bytes` in the given text encoding) suitable for transport and communication with non-Python utilities.  :meth:`bytes.decode` decodes such byte sequences into text strings.

----------
nosy: +Jim.Jewett

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

From report at bugs.python.org  Wed Jun 11 01:07:01 2014
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 10 Jun 2014 23:07:01 +0000
Subject: [docs] [issue13101] Module Doc viewer closes when browser window
	closes on	Windows 8
In-Reply-To: <1317753409.09.0.358970019617.issue13101@psf.upfronthosting.co.za>
Message-ID: <1402441621.16.0.128319244362.issue13101@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Wed Jun 11 01:20:46 2014
From: report at bugs.python.org (Jim Jewett)
Date: Tue, 10 Jun 2014 23:20:46 +0000
Subject: [docs] [issue21667] Clarify status of O(1) indexing semantics of
	str objects
In-Reply-To: <1401966142.97.0.682653322291.issue21667@psf.upfronthosting.co.za>
Message-ID: <1402442446.68.0.0725472083721.issue21667@psf.upfronthosting.co.za>


Jim Jewett added the comment:

And even my rewrite showed path dependency; a slight further improvement is to re-order encoding ahead of bytes.  I also added a paragraph that I hope answers the speed issue.

Proposal:

A string is a sequence of Unicode code points.  Strings can include any sequence of code points, including some which are semantically meaningless, or explicitly undefined.

Python doesn't have a :c:type:`char` type; a single code point is represented as a string of length ``1``.  The built-in function :func:`chr` translates an integer in the range ``U+0000 - U+10FFFF`` to the corresponding length ``1`` string object, and :func:`ord` does the reverse.

:meth:`str.encode` provides a concrete representation (in the given text encoding) as a :class:`bytes` object suitable for transport and communication with non-Python utilities.  :meth:`bytes.decode` decodes such byte sequences into text strings.

.. impl-detail::  There are no methods exposing the internal representation of code points within a string.  While the C-API provides some additional constraints on CPython, other implementations are free to use any representation that treats code points (as opposed to either code units or some normalized form of characters) as the unit of measure.

----------

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

From report at bugs.python.org  Wed Jun 11 15:19:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jun 2014 13:19:57 +0000
Subject: [docs] [issue21693] Broken link to Pylons in the HOWTO
	TurboGears	documentation
In-Reply-To: <1402215464.69.0.795640420868.issue21693@psf.upfronthosting.co.za>
Message-ID: <3gpTMJ68PSz7LjZ@mail.python.org>


Roundup Robot added the comment:

New changeset 9438a8aa3622 by Senthil Kumaran in branch '2.7':
#21693 - Fix the broken link for pylons project.
http://hg.python.org/cpython/rev/9438a8aa3622

New changeset 08fa17130fb3 by Senthil Kumaran in branch '3.4':
#21693 - Fix the broken link for pylons project.
http://hg.python.org/cpython/rev/08fa17130fb3

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

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

From report at bugs.python.org  Wed Jun 11 15:20:40 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 11 Jun 2014 13:20:40 +0000
Subject: [docs] [issue21693] Broken link to Pylons in the HOWTO
	TurboGears	documentation
In-Reply-To: <1402215464.69.0.795640420868.issue21693@psf.upfronthosting.co.za>
Message-ID: <1402492840.83.0.312473911067.issue21693@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed these. Thanks for the report.

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

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

From report at bugs.python.org  Wed Jun 11 20:30:15 2014
From: report at bugs.python.org (Reid Price)
Date: Wed, 11 Jun 2014 18:30:15 +0000
Subject: [docs] [issue21726] Unnecessary line in documentation
Message-ID: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>


New submission from Reid Price:

https://docs.python.org/2/distutils/examples.html#pure-python-distribution-by-package

Chrome on Linux

The last (parenthetical) sentence is not needed.

  "(Again, the empty string in package_dir stands for the current directory.)"

because there is no package_dir option in the example.

<------------ Preceding Text ------------>
  ...

If you have sub-packages, they must be explicitly listed in packages, but any entries in package_dir automatically extend to sub-packages. (In other words, the Distutils does not scan your source tree, trying to figure out which directories correspond to Python packages by looking for __init__.py files.) Thus, if the default layout grows a sub-package:

<root>/
        setup.py
        foobar/
                 __init__.py
                 foo.py
                 bar.py
                 subfoo/
                           __init__.py
                           blah.py
then the corresponding setup script would be

from distutils.core import setup
setup(name='foobar',
      version='1.0',
      packages=['foobar', 'foobar.subfoo'],
      )

(Again, the empty string in package_dir stands for the current directory.)

----------
assignee: docs at python
components: Documentation
messages: 220295
nosy: Reid.Price, docs at python
priority: normal
severity: normal
status: open
title: Unnecessary line in documentation
type: enhancement

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

From report at bugs.python.org  Wed Jun 11 20:46:30 2014
From: report at bugs.python.org (Matt Deacalion Stevens)
Date: Wed, 11 Jun 2014 18:46:30 +0000
Subject: [docs] [issue21727] Ambiguous sentence explaining `cycle` in
	itertools	documentation
Message-ID: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>


New submission from Matt Deacalion Stevens:

https://docs.python.org/3.5/library/itertools.html#itertools.cycle

The first sentence sounds a bit ambiguous:
"Make an iterator returning elements from the iterable and saving a copy of each."

Suggestion:
"Make an iterator that returns elements from the iterable and saves a copy of each."

----------
assignee: docs at python
components: Documentation
messages: 220298
nosy: Matt.Deacalion.Stevens, docs at python
priority: normal
severity: normal
status: open
title: Ambiguous sentence explaining `cycle` in itertools documentation
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jun 11 20:56:04 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 11 Jun 2014 18:56:04 +0000
Subject: [docs] [issue21727] Ambiguous sentence explaining `cycle` in
	itertools	documentation
In-Reply-To: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>
Message-ID: <1402512964.14.0.274902296965.issue21727@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +rhettinger
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 12 07:16:23 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jun 2014 05:16:23 +0000
Subject: [docs] [issue21727] Ambiguous sentence explaining `cycle` in
	itertools	documentation
In-Reply-To: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>
Message-ID: <1402550183.38.0.160524696261.issue21727@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I see no real difference here and AFAICT the current wording has not caused any confusion since it was written a decade ago.

----------
assignee: docs at python -> rhettinger
priority: normal -> low

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

From report at bugs.python.org  Thu Jun 12 15:19:12 2014
From: report at bugs.python.org (Matt Deacalion Stevens)
Date: Thu, 12 Jun 2014 13:19:12 +0000
Subject: [docs] [issue21727] Ambiguous sentence explaining `cycle` in
	itertools	documentation
In-Reply-To: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>
Message-ID: <1402579152.34.0.82693964512.issue21727@psf.upfronthosting.co.za>


Matt Deacalion Stevens added the comment:

It's probably just me then. The code example is what helped me grasp `cycle`, not the explanation.

----------

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

From report at bugs.python.org  Thu Jun 12 21:17:59 2014
From: report at bugs.python.org (Karl Richter)
Date: Thu, 12 Jun 2014 19:17:59 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
Message-ID: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>


New submission from Karl Richter:

It would be useful to have a short statement in the docs (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions) that the expression in a list comprehension isn't put into a block, but evaluated against the same block where it is located because intuitively one might think that variables can be overridden in the statement.
This applies to both 2.7 and 3.4.1.

----------
assignee: docs at python
components: Documentation
messages: 220374
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: Add hint about expression in list comprehensions (https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Jun 12 21:51:52 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Jun 2014 19:51:52 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1402602711.96.0.407581429057.issue21739@psf.upfronthosting.co.za>


R. David Murray added the comment:

In 3.x a list comprehension (like a generator expression in 2.x) *is* a separate block:

>>> [x for x in range(3)]
[0, 1, 2]
>>> x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined

I note that this is not in fact mentioned in the python3 version of the tutorial; there it still implies that it is completely equivalent to the unrolled if statement, which would imply it *was* in the same scope.

IMO the 2.7 tutorial is complete in the sense that the "is equivalent to" example is clearly in the same scope, while the python3 tutorial is missing a note that the comprehension is its own scope.  Given the fact that it is *different* between the two, I wonder if it would be appropriate to add a note (footnote?) to that effect to the 2.7 tutorial.  There is such a footnote in the corresponding part of the language reference.

----------
nosy: +r.david.murray
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 22:03:30 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jun 2014 20:03:30 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1402603409.99.0.995404871605.issue21739@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I wouldn't like to use the tutorial to highlight or draw attention a feature/bug that is going away. 

I recommend leaving the tutorial as-is.  For a decade, it has worked well for introducing people to list comprehensions.  More complete implementation specs belong in the Language Reference or in the List Comp PEP.

The tutorial is mainly about showing the normal and correct usage of tools  rather than emphasizing oddities that don't matter to most of the people, most of the time.

If you feel strongly compelled to "just add something", then consider a FAQ entry.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low
type: enhancement -> 
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 12 22:04:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jun 2014 20:04:18 +0000
Subject: [docs] [issue21727] Ambiguous sentence explaining `cycle` in
	itertools	documentation
In-Reply-To: <1402512390.39.0.862134165796.issue21727@psf.upfronthosting.co.za>
Message-ID: <1402603458.07.0.0213967748141.issue21727@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

That's why the code example is there ;-)

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Thu Jun 12 22:08:32 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jun 2014 20:08:32 +0000
Subject: [docs] [issue21726] Unnecessary line in documentation
In-Reply-To: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>
Message-ID: <1402603712.59.0.833016433817.issue21726@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Thu Jun 12 22:12:25 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 Jun 2014 20:12:25 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1402603945.13.0.291930867165.issue21739@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, I have no objection to leaving the 2.7 tutorial alone.  It seems to me that the 3.x tutorial should be fixed, though, because it currently says the unrolled loop is equivalent, but it isn't.  The fact that this applies to all other comprehensions in python3 I think adds weight to the idea of including the information in the tutorial somehow.

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

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

From report at bugs.python.org  Fri Jun 13 02:04:40 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 13 Jun 2014 00:04:40 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1402617879.96.0.478515715954.issue13790@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> '{0:d}'.format('a')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    '{0:d}'.format('a')
ValueError: Unknown format code 'd' for object of type 'str'

Nothing appears to have changed despite "the issue will go away in 3.4" in msg164373.  What should have happened here?

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

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

From report at bugs.python.org  Fri Jun 13 02:32:12 2014
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 13 Jun 2014 00:32:12 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1402619532.08.0.328338914691.issue13790@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I believe that comment was referring to the subject of this bug:

$ ./python
Python 3.4.1+ (3.4:bec6f18dd636, Jun 12 2014, 20:23:30)
[GCC 4.8.1] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> format([], 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
>>> format((), 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
>>> format({}, 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__
>>> format(set(), 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__

With the possible exception of listing the type in this error message, I think these are all fine.


I'm not sure what you'd expect format('a', 'd') to produce other than the error you're seeing. 'd' is in fact an unknown "format code" for str.

>>> format('a', 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'd' for object of type 'str'

----------

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

From report at bugs.python.org  Fri Jun 13 03:21:30 2014
From: report at bugs.python.org (py.user)
Date: Fri, 13 Jun 2014 01:21:30 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1402622490.7.0.370253847935.issue13790@psf.upfronthosting.co.za>


py.user added the comment:

Python 2.7.7 is still printing.

>>> format([], 'd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 'd' for object of type 'str'
>>>

----------

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

From report at bugs.python.org  Fri Jun 13 03:24:04 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 01:24:04 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1402622644.48.0.852381816292.issue13790@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Yes, the deprecation in 3.3 did not apply to 2.7.

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

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

From report at bugs.python.org  Fri Jun 13 03:24:57 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 01:24:57 +0000
Subject: [docs] [issue13790] In str.format an incorrect error message for
	list, tuple, dict, set
In-Reply-To: <1326605478.95.0.601079964751.issue13790@psf.upfronthosting.co.za>
Message-ID: <1402622697.55.0.810207693571.issue13790@psf.upfronthosting.co.za>


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


----------
stage: test needed -> patch review

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

From report at bugs.python.org  Fri Jun 13 06:19:25 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Jun 2014 04:19:25 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
Message-ID: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>


New submission from Ben Hoyt:

Per my email on core-mentorship, the instructions for compiling CPython on Windows at
https://docs.python.org/devguide/setup.html#windows are good, however I did have one issue where the dev guide didn't help. During the link
step, I got this error:

LINK : fatal error LNK1123: failure during conversion to COFF: file
invalid or corrupt

It took me a while to figure out how to fix it. I found this question
on StackOverflow:

http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

The first part of the answer didn't help (because incremental linking
is already disabled). But the second part, kinda tucked away there, is
what fixed it for me -- simply installing Visual Studio 2010 SP1 here:

http://www.microsoft.com/en-us/download/details.aspx?id=23691

After this, I restarted my PC and it linked fine.

So I suggest a small addition to the dev guide to mention this -- adding the following paragraph after the "Python 3.3 and later" paragraph:

-----
You'll also need to install the Visual Studio `Service Pack 1 (SP1)
<http://www.microsoft.com/en-us/download/details.aspx?id=23691>`_. If you
don't install this service pack, you may receive errors like the following
during linking: ``LINK : fatal error LNK1123: failure during conversion to
COFF: file invalid or corrupt``.
-----

Patch attached.

----------
assignee: docs at python
components: Documentation
files: visual_studio_sp1.patch
keywords: patch
messages: 220418
nosy: benhoyt, docs at python
priority: normal
severity: normal
status: open
title: Devguide: mention requirement to install Visual Studio SP1 on Windows
type: enhancement
Added file: http://bugs.python.org/file35607/visual_studio_sp1.patch

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

From report at bugs.python.org  Fri Jun 13 06:20:01 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Jun 2014 04:20:01 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <1402633201.56.0.479499627109.issue21745@psf.upfronthosting.co.za>


Changes by Ben Hoyt <benhoyt at gmail.com>:


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

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

From report at bugs.python.org  Fri Jun 13 06:32:09 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 13 Jun 2014 04:32:09 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <1402633929.21.0.106557643456.issue21745@psf.upfronthosting.co.za>


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


----------
components: +Devguide -Documentation
nosy: +ezio.melotti, steve.dower, zach.ware

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

From report at bugs.python.org  Fri Jun 13 11:13:34 2014
From: report at bugs.python.org (Matthew Gilson)
Date: Fri, 13 Jun 2014 09:13:34 +0000
Subject: [docs] [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1402650814.02.0.726644974091.issue21746@psf.upfronthosting.co.za>


Changes by Matthew Gilson <m.gilson1 at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 2.7

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

From report at bugs.python.org  Fri Jun 13 11:16:14 2014
From: report at bugs.python.org (Matthew Gilson)
Date: Fri, 13 Jun 2014 09:16:14 +0000
Subject: [docs] [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1402650974.03.0.483584329106.issue21746@psf.upfronthosting.co.za>


Matthew Gilson added the comment:

Sorry, forgot to remove the mention of BaseResult ...

----------
Added file: http://bugs.python.org/file35613/python_doc_patch.patch

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

From report at bugs.python.org  Fri Jun 13 11:19:36 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Fri, 13 Jun 2014 09:19:36 +0000
Subject: [docs] [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1402651176.33.0.992058747805.issue21746@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Note that the Python 3 docs also need updating, but need a more extensive patch:

    https://docs.python.org/3/library/urllib.parse.html#structured-parse-results

----------
nosy: +mjpieters

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

From report at bugs.python.org  Fri Jun 13 11:21:45 2014
From: report at bugs.python.org (Matthew Gilson)
Date: Fri, 13 Jun 2014 09:21:45 +0000
Subject: [docs] [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1402651305.52.0.598178895674.issue21746@psf.upfronthosting.co.za>


Matthew Gilson added the comment:

This originally came up on stackoverflow:

http://stackoverflow.com/questions/24200988/modify-url-components-in-python-2/24201020?noredirect=1#24201020

Would it be helpful if I also added a simple example to the docs as in the example there?

----------

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

From report at bugs.python.org  Fri Jun 13 16:39:48 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jun 2014 14:39:48 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <3gql2W22hhz7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 9794412fa62d by Zachary Ware in branch 'default':
Issue #21745: Mention VS2010 SP1 as a solution for error LNK1123.
http://hg.python.org/devguide/rev/9794412fa62d

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

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

From report at bugs.python.org  Fri Jun 13 16:39:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jun 2014 14:39:57 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <3gql2h42XSz7LkW@mail.python.org>


Roundup Robot added the comment:

New changeset 10cca530d14c by Zachary Ware in branch '3.4':
Issue #21745: Mention VS2010 SP1 as a solution for LNK1123 errors
http://hg.python.org/cpython/rev/10cca530d14c

New changeset b5b54073d495 by Zachary Ware in branch 'default':
Issue #21745: Merge with 3.4
http://hg.python.org/cpython/rev/b5b54073d495

----------

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

From report at bugs.python.org  Fri Jun 13 16:44:25 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 13 Jun 2014 14:44:25 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <1402670665.08.0.0644250712219.issue21745@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> zach.ware
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Jun 13 17:03:39 2014
From: report at bugs.python.org (Ben Hoyt)
Date: Fri, 13 Jun 2014 15:03:39 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402633165.65.0.068463465713.issue21745@psf.upfronthosting.co.za>
Message-ID: <1402671819.03.0.888896822423.issue21745@psf.upfronthosting.co.za>


Ben Hoyt added the comment:

Cool, thanks for applying. Out of curiosity, how often is the online devguide HTML updated?

----------

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

From report at bugs.python.org  Fri Jun 13 17:09:25 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 13 Jun 2014 15:09:25 +0000
Subject: [docs] [issue21745] Devguide: mention requirement to install Visual
	Studio	SP1 on Windows
In-Reply-To: <1402671819.03.0.888896822423.issue21745@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-NE+1MQ=wbd5TgGSU5JRKg7ncni7NGUNiZeYg-eO29Siw@mail.gmail.com>


Zachary Ware added the comment:

I'm not sure; I expect your change to be live within a day, probably sooner.

----------

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

From report at bugs.python.org  Fri Jun 13 17:26:31 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 13 Jun 2014 15:26:31 +0000
Subject: [docs] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1402673191.4.0.685429733621.issue7057@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The default build (on Windows anyway)is using tcl/tk 8.6 so I believe that we can take this forward now.

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

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

From report at bugs.python.org  Fri Jun 13 17:30:20 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 13 Jun 2014 15:30:20 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <1402673419.99.0.526693780174.issue19362@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This is a very simple docs patch so could we have it committed please?

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

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

From report at bugs.python.org  Fri Jun 13 18:16:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 16:16:12 +0000
Subject: [docs] [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1402676172.09.0.985269886233.issue7057@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 13 20:34:09 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 18:34:09 +0000
Subject: [docs] [issue21726] Unnecessary line in documentation
In-Reply-To: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>
Message-ID: <1402684449.83.0.943780765249.issue21726@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Jun 13 20:58:36 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jun 2014 18:58:36 +0000
Subject: [docs] [issue21726] Unnecessary line in documentation
In-Reply-To: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>
Message-ID: <3gqrn73GMFz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset cd08e366d619 by Terry Jan Reedy in branch '2.7':
Issue #21726: Remove unnecessary and contextually wrong line.
http://hg.python.org/cpython/rev/cd08e366d619

New changeset efa32fcd7a0b by Terry Jan Reedy in branch '3.4':
Issue #21726: Remove unnecessary and contextually wrong line.
http://hg.python.org/cpython/rev/efa32fcd7a0b

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

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

From report at bugs.python.org  Fri Jun 13 20:59:14 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 18:59:14 +0000
Subject: [docs] [issue21726] Unnecessary line in documentation
In-Reply-To: <1402511415.47.0.115494695808.issue21726@psf.upfronthosting.co.za>
Message-ID: <1402685954.65.0.736666796967.issue21726@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 13 21:07:49 2014
From: report at bugs.python.org (Don Spaulding)
Date: Fri, 13 Jun 2014 19:07:49 +0000
Subject: [docs] [issue21752] Document Backwards Incompatible change to
	logging in 3.4
Message-ID: <1402686469.59.0.301170999664.issue21752@psf.upfronthosting.co.za>


New submission from Don Spaulding:

Discussion of this issue on ML:

https://mail.python.org/pipermail/python-dev/2014-June/135048.html

The behavior of logging.getLevelName changed in Python 3.4.  Previously when passed a string, it would return the corresponding integer value of the level.  In 3.4 it was changed to match the behavior of its documentation.  The patch can be found in issue #18046.

This seems like something that should be documented somewhere.

----------
assignee: docs at python
components: Documentation
messages: 220482
nosy: docs at python, donspaulding
priority: normal
severity: normal
status: open
title: Document Backwards Incompatible change to logging in 3.4
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 13 21:32:37 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 13 Jun 2014 19:32:37 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <1402687957.93.0.404305481065.issue19362@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll apply this (if only to bring this vacuous discussion to a close).

----------
assignee: docs at python -> rhettinger
priority: normal -> low

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

From report at bugs.python.org  Fri Jun 13 22:17:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 Jun 2014 20:17:38 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <1402690658.17.0.889194038847.issue19362@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Raymond, I was planning to do this today along with other small patches (already done). Just say so and I will take it.

----------

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

From report at bugs.python.org  Fri Jun 13 23:23:47 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jun 2014 21:23:47 +0000
Subject: [docs] [issue5904] strftime docs do not explain locale effect on
	result	string
In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>
Message-ID: <3gqw0g0Rqbz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset 31adcc4c4391 by R David Murray in branch '2.7':
#5904: Add sentence about the encoding of strftime's result.
http://hg.python.org/cpython/rev/31adcc4c4391

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

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

From report at bugs.python.org  Fri Jun 13 23:25:24 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 13 Jun 2014 21:25:24 +0000
Subject: [docs] [issue5904] strftime docs do not explain locale effect on
	result	string
In-Reply-To: <1241270739.12.0.286821632978.issue5904@psf.upfronthosting.co.za>
Message-ID: <1402694723.93.0.428523060994.issue5904@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Caelyn.  I used your patch but added a clause showing explicitly how do the unicode conversion.  I decided to not add that to the datetime, docs, since they are already pretty clear.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Jun 14 00:21:49 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 13 Jun 2014 22:21:49 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1402698109.1.0.962527045521.issue6916@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is it worth the effort of committing changes like this when according to https://docs.python.org/3/library/asynchat.html#module-asynchat "This module exists for backwards compatibility only. For new code we recommend using asyncio."?  See also issue6911.

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

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

From report at bugs.python.org  Sat Jun 14 00:24:32 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 13 Jun 2014 22:24:32 +0000
Subject: [docs] [issue21752] Document Backwards Incompatible change to
	logging in 3.4
In-Reply-To: <1402686469.59.0.301170999664.issue21752@psf.upfronthosting.co.za>
Message-ID: <1402698272.56.0.612540803545.issue21752@psf.upfronthosting.co.za>


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


----------
nosy: +vinay.sajip

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

From report at bugs.python.org  Sat Jun 14 04:19:50 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 14 Jun 2014 02:19:50 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <1402712390.65.0.795750064804.issue19362@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Terry.

----------
assignee: rhettinger -> terry.reedy

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

From report at bugs.python.org  Sat Jun 14 10:27:26 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jun 2014 08:27:26 +0000
Subject: [docs] [issue21752] Document Backwards Incompatible change to
	logging in 3.4
In-Reply-To: <1402686469.59.0.301170999664.issue21752@psf.upfronthosting.co.za>
Message-ID: <3grBkP4wwdz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 277d099a134b by Vinay Sajip in branch '3.4':
Issue #21752: Documented change to behaviour of logging.getLevelName().
http://hg.python.org/cpython/rev/277d099a134b

New changeset 174c30103b57 by Vinay Sajip in branch 'default':
Closes #21752: Merged update from 3.4.
http://hg.python.org/cpython/rev/174c30103b57

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

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

From report at bugs.python.org  Sat Jun 14 14:32:08 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Sat, 14 Jun 2014 12:32:08 +0000
Subject: [docs] [issue12617] Mutable Sequence Type can work not only with
	iterable in	slice[i:j] = t
In-Reply-To: <1311385198.6.0.560721842501.issue12617@psf.upfronthosting.co.za>
Message-ID: <1402749128.42.0.325328136004.issue12617@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

This was fixed in the latest versions.

>>> b = bytearray(b'457')
>>> b[:1] = 4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can assign only bytes, buffers, or iterables of ints in range(0, 256)
>>>

----------
nosy: +Claudiu.Popa
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Jun 14 17:04:11 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jun 2014 15:04:11 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <3grMXB6hKvz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset 42a645d74e9d by Giampaolo Rodola' in branch 'default':
fix issue #6916: undocument deprecated asynchat.fifo class.q
http://hg.python.org/cpython/rev/42a645d74e9d

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

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

From report at bugs.python.org  Sat Jun 14 17:05:15 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 14 Jun 2014 15:05:15 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1402758315.55.0.0936910703647.issue6916@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I simply removed asynchat.fifo documentation. Closing this out.

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.5 -Python 3.2

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

From report at bugs.python.org  Sat Jun 14 18:17:58 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 14 Jun 2014 16:17:58 +0000
Subject: [docs] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
Message-ID: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

subprocess_shell in asyncio accepts cmd as a string or a bytes but the test unit, the documentation and the exception indicates that it only accepts a string.

----------
assignee: docs at python
components: Documentation, asyncio
files: fix_doc_asyncio_subprocess_shell.patch
keywords: patch
messages: 220567
nosy: docs at python, gvanrossum, haypo, vajrasky, yselivanov
priority: normal
severity: normal
status: open
title: Not so correct documentation about asyncio.subprocess_shell method
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35634/fix_doc_asyncio_subprocess_shell.patch

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

From report at bugs.python.org  Sat Jun 14 21:18:33 2014
From: report at bugs.python.org (are-you-watching-closely)
Date: Sat, 14 Jun 2014 19:18:33 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
Message-ID: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>


New submission from are-you-watching-closely:

Under this question (https://docs.python.org/2/faq/programming.html#my-program-is-too-slow-how-do-i-speed-it-up) in the 2.7 programming FAQ, it gives a link to an anecdote that Guido van Rossum wrote.

The URL it gives:
http://www.python.org/doc/essays/list2str.html

The correct URL (no .html):
http://www.python.org/doc/essays/list2str

I'm sure there are some people who didn't think to remove the '.html', and couldn't find the story.

Just a quick typo fix.

----------
assignee: docs at python
components: Documentation
messages: 220575
nosy: are-you-watching-closely, docs at python
priority: normal
severity: normal
status: open
title: URL Typo in Documentation FAQ
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 14 21:58:13 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 19:58:13 +0000
Subject: [docs] [issue21760] inspect documentation describes module type
	inaccurately
Message-ID: <1402775893.22.0.955121317915.issue21760@psf.upfronthosting.co.za>


New submission from Eric Snow:

In the documentation for the inspect module, the module type is described with just 2 of its potential 7 attributes.  The language reference[2] and importlib docs[3] both provide an accurate list of module attributes.

Furthermore, the description for __file__ should be fixed.  It should be clear that __file__ reflects the location from which the module was loaded, that location is not necessarily a filename, and the attribute may not exist if the module was not loaded from a specific location (e.g. builtin and frozen modules).  The same goes for __cached__

[1] https://docs.python.org/dev/library/inspect.html#types-and-members
[2] https://docs.python.org/3/reference/import.html#import-related-module-attributes
[3] https://docs.python.org/3/library/importlib.html#importlib.machinery.ModuleSpec

----------
assignee: docs at python
components: Documentation
messages: 220576
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect documentation describes module type inaccurately
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun 14 22:16:28 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 20:16:28 +0000
Subject: [docs] [issue21760] inspect documentation describes module type
	inaccurately
In-Reply-To: <1402775893.22.0.955121317915.issue21760@psf.upfronthosting.co.za>
Message-ID: <1402776988.64.0.844258319726.issue21760@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +brett.cannon, ncoghlan

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

From report at bugs.python.org  Sat Jun 14 22:35:11 2014
From: report at bugs.python.org (Eric Snow)
Date: Sat, 14 Jun 2014 20:35:11 +0000
Subject: [docs] [issue21761] language reference describes the role of
	module.__file__	inaccurately
In-Reply-To: <1402778004.82.0.418404996295.issue21761@psf.upfronthosting.co.za>
Message-ID: <1402778111.46.0.983827410194.issue21761@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Sat Jun 14 22:59:24 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 14 Jun 2014 20:59:24 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <1402779564.84.0.293477467773.issue21759@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Sun Jun 15 00:16:50 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:16:50 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
Message-ID: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

It is currently not perfectly clear what Python (and the standard library) assumes about file-like objects (see e.g. http://article.gmane.org/gmane.comp.python.devel/148199).

The attached doc patch tries to improve the current situation by  stating explicitly that the description of IOBase et al specifies a *mandatory* interface for anything that claims to be file-like.

----------
assignee: docs at python
components: Documentation
files: iobase.diff
keywords: patch
messages: 220588
nosy: benjamin.peterson, docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek, ncoghlan, nikratio, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Clarify requirements for file-like objects
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35636/iobase.diff

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

From report at bugs.python.org  Sun Jun 15 00:47:56 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:47:56 +0000
Subject: [docs] [issue21764] Document that IOBase.__del__ calls self.close
Message-ID: <1402786076.21.0.846118348944.issue21764@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

CPython's io.IOBase.__del__ calls self.close(), but this isn't documented anywhere (and may be surprised for derived classes).

The attached patch extends the documentation.

----------
assignee: docs at python
components: Documentation
files: iobase2.diff
keywords: patch
messages: 220591
nosy: benjamin.peterson, docs at python, eric.araujo, ezio.melotti, georg.brandl, hynek, nikratio, pitrou, stutzbach
priority: normal
severity: normal
status: open
title: Document that IOBase.__del__ calls self.close
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35637/iobase2.diff

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

From report at bugs.python.org  Sun Jun 15 00:48:24 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:48:24 +0000
Subject: [docs] [issue21764] Document that IOBase.__del__ calls self.close
In-Reply-To: <1402786076.21.0.846118348944.issue21764@psf.upfronthosting.co.za>
Message-ID: <1402786104.7.0.253965191933.issue21764@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Added file: http://bugs.python.org/file35638/iobase2.diff

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

From report at bugs.python.org  Sun Jun 15 00:48:32 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 14 Jun 2014 22:48:32 +0000
Subject: [docs] [issue21764] Document that IOBase.__del__ calls self.close
In-Reply-To: <1402786076.21.0.846118348944.issue21764@psf.upfronthosting.co.za>
Message-ID: <1402786112.28.0.778885313221.issue21764@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


Removed file: http://bugs.python.org/file35637/iobase2.diff

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

From report at bugs.python.org  Sun Jun 15 00:49:20 2014
From: report at bugs.python.org (Mike Short)
Date: Sat, 14 Jun 2014 22:49:20 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <1402786160.81.0.577275533539.issue21759@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file35639/programmingfaq.patch

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

From report at bugs.python.org  Sun Jun 15 03:52:21 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jun 2014 01:52:21 +0000
Subject: [docs] [issue21764] Document that IOBase.__del__ calls self.close
In-Reply-To: <1402786076.21.0.846118348944.issue21764@psf.upfronthosting.co.za>
Message-ID: <3grdw43Hc3z7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 601a08fcb507 by Benjamin Peterson in branch '3.4':
document IOBase.__del__'s behavior (closes #21764)
http://hg.python.org/cpython/rev/601a08fcb507

New changeset 4dca82f8d91d by Benjamin Peterson in branch '2.7':
document IOBase.__del__'s behavior (closes #21764)
http://hg.python.org/cpython/rev/4dca82f8d91d

New changeset 787cd41d0404 by Benjamin Peterson in branch 'default':
merge 3.4 (#21764)
http://hg.python.org/cpython/rev/787cd41d0404

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

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

From report at bugs.python.org  Sun Jun 15 11:12:53 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 Jun 2014 09:12:53 +0000
Subject: [docs] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
In-Reply-To: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwatr+FJm984kySAtsFEj0ebtMd0x2LYTLd=y9EU8kdMVQ@mail.gmail.com>


STINNER Victor added the comment:

IMO it's fine to support bytes on UNIX, os.fsencode() is well defined. On
Windows, we may use the same decoder.

----------

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

From report at bugs.python.org  Sun Jun 15 15:29:44 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 Jun 2014 13:29:44 +0000
Subject: [docs] [issue13779] os.walk: bottom-up
In-Reply-To: <1326452589.73.0.0617213643117.issue13779@psf.upfronthosting.co.za>
Message-ID: <1402838984.71.0.983821131428.issue13779@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The OP is happy with the proposed doc patch so can we have this committed please.

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

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

From report at bugs.python.org  Sun Jun 15 16:07:16 2014
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Sun, 15 Jun 2014 14:07:16 +0000
Subject: [docs] [issue21771] name of 2nd parameter to itertools.groupby()
Message-ID: <1402841236.86.0.756808540729.issue21771@psf.upfronthosting.co.za>


New submission from Uwe Kleine-K?nig:

The name of the 2nd parameter to itertools.groupby() is documented inconsitently. Sometimes it's "key", sometimes "keyfunc". The code actually uses "key", so I adapted all occurences I found to "key".

>>> from itertools import groupby
>>> groupby.__doc__
'groupby(iterable[, keyfunc]) -> create an iterator which returns\n(key, sub-iterator) grouped by each value of key(value).\n'

>>> groupby([], keyfunc=lambda x: x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'keyfunc' is an invalid keyword argument for this function

>>> groupby([], key=lambda x: x)
<itertools.groupby object at 0x7fee025d2048>

----------
assignee: docs at python
components: Documentation
files: groupby-keyfunc.patch
keywords: patch
messages: 220639
nosy: docs at python, ukl
priority: normal
severity: normal
status: open
title: name of 2nd parameter to itertools.groupby()
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35645/groupby-keyfunc.patch

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

From report at bugs.python.org  Sun Jun 15 16:54:14 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 Jun 2014 14:54:14 +0000
Subject: [docs] [issue15476] Add "code object" to glossary
In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za>
Message-ID: <1402844054.01.0.64948005045.issue15476@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can this be closed given msg169859 and msg169861?

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

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

From report at bugs.python.org  Sun Jun 15 17:29:34 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 Jun 2014 15:29:34 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1402846174.41.0.68556802469.issue21763@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think that's true, though.  "file like" pretty much means "has the file attributes that I actually use".  That is, it is context dependent (duck typing).

I'm also not sure I see the point in the change.  It is inherent in the definition of what ABCs are.  I think the language should be audited for imperative/prescriptive voice, though:

  Flush and close this stream. If called again, do nothing. Once the file is closed, any operation on the file (e.g. reading or writing) should raise a ValueError.

My use of 'should' there might be controversial, though, since in the default implementation 'will' is correct.  If 'will' is kept, then perhaps some variation of your note would be appropriate.

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

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

From report at bugs.python.org  Sun Jun 15 20:16:31 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 Jun 2014 18:16:31 +0000
Subject: [docs] [issue18959] Create a "Superseded modules" section in
	standard	library ToC
In-Reply-To: <1378559362.61.0.726437189184.issue18959@psf.upfronthosting.co.za>
Message-ID: <1402856191.31.0.862433812922.issue18959@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Would somebody review the attached patch please.

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

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

From report at bugs.python.org  Sun Jun 15 20:20:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jun 2014 18:20:29 +0000
Subject: [docs] [issue15476] Index "code object" and link to code object
	definition
In-Reply-To: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za>
Message-ID: <1402856429.58.0.649571658047.issue15476@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There is no entry for 'code object' (unlike, for instance 'class object'). There is an entry for 'code' and a subentry for 'object' with four links.

The fourth link is to the short definition in the library manual:
https://docs.python.org/3/library/stdtypes.html#index-46
https://docs.python.org/3/library/stdtypes.html#code-objects
is better as it includes the header line. This is the one that should be used elsewhere.

The entry says "See The standard type hierarchy for more information."

The third link is to the long definition in the datamodel section.
https://docs.python.org/3/reference/datamodel.html#index-53
Again, the header line is cut off. I presume this is because the index directive is after rather than before the header line. I think the short definition should point directly here.

The second link is to code objects in the C-API
https://docs.python.org/3/c-api/code.html#index-0

The first link is to marshal, because marshal marshals code objects. 

In other words, the unlabeled links are in the reverse order of what one would want. More helpful would be something like

code object
  C-API
  definition
  marshal

----------
title: Add "code object" to glossary -> Index "code object" and link to code object definition

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

From report at bugs.python.org  Sun Jun 15 20:24:24 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 Jun 2014 18:24:24 +0000
Subject: [docs] [issue14759] BSDDB license missing from liscense page in 2.7.
In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za>
Message-ID: <1402856663.94.0.0999727463729.issue14759@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I think msg160322 and msg160339 are saying this isn't an issue.  If I'm correct it can be closed. If I'm wrong who is best placed to provide the needed patch?

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

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

From report at bugs.python.org  Sun Jun 15 20:50:41 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 15 Jun 2014 18:50:41 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402846174.41.0.68556802469.issue21763@psf.upfronthosting.co.za>
Message-ID: <539DEAF9.70407@rath.org>


Nikolaus Rath added the comment:

On 06/15/2014 08:29 AM, R. David Murray wrote:
> I don't think that's true, though.  "file like" pretty much means "has the file attributes that I actually use".  That is, it is context dependent (duck typing).

Well, but when you pass your file-like object to some function from the
standard library, you don't know what file attributes will be used. So
to make sure that things work as expected, you have to make sure that
your file-like object behaves as prescribed by the IOBase* classes.

> I'm also not sure I see the point in the change.  It is inherent in the definition of what ABCs are. 

True. But not everyone reading the io documentation is familiar enough
with ABCs to immediately make that mental translation.

----------

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

From report at bugs.python.org  Sun Jun 15 22:38:59 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 15 Jun 2014 20:38:59 +0000
Subject: [docs] [issue21771] name of 2nd parameter to itertools.groupby()
In-Reply-To: <1402841236.86.0.756808540729.issue21771@psf.upfronthosting.co.za>
Message-ID: <1402864739.65.0.774929578528.issue21771@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun 15 23:26:02 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 15 Jun 2014 21:26:02 +0000
Subject: [docs] [issue21771] name of 2nd parameter to itertools.groupby()
In-Reply-To: <1402841236.86.0.756808540729.issue21771@psf.upfronthosting.co.za>
Message-ID: <1402867562.12.0.847839991856.issue21771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

There is a bit an inconsistency but it is more helpful than harmful most of the time.  The glossary defines a key-function which is used in a number of places such such as sorted(), min(), nsmallest() and others.  In all those cases, the parameter for the key-function is *key*.

It might feel "more consistent" to call it "key" everywhere, but that leaves out the explanation that *key* represents a key-function.

The other issue is that groupby() returns a (key, sub-iterator) pair where "key" is the result of key-function, not the key itself.

What we have now is imperfect but it does a reasonably good job helping people understand what the function does.  IMO, changing it to be "key" would make the docs less intelligible.

Thank you for the patch, but I'm going to pass on it.

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

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

From report at bugs.python.org  Sun Jun 15 23:49:11 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 Jun 2014 21:49:11 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <539DEAF9.70407@rath.org>
Message-ID: <CADiSq7cTO08un0POtqzXqNLqQEyjM4KEODC_r5ij6GDzcA=iTw@mail.gmail.com>


Nick Coghlan added the comment:

Asking the question "Does it quack and walk *enough* like a duck for my
code to work and my tests to pass?" is part of the nature of ducktyping.

ABCs are definitely a useful guide to expectations, but even there it's
possible to lie to the interpreter and have "required" methods that raise
NotImplementedError, or do an explicit registration without implementing
the full interface.

----------

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

From report at bugs.python.org  Mon Jun 16 00:39:23 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 15 Jun 2014 22:39:23 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1402871962.93.0.795652705838.issue21763@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Maybe I'm missing some important point here, but I think that the documentation ought to tell me how I have to design a file-like object such that it fulfills all expectations of the standard library.

Yes, you can get away with less than that in many situations, but that doesn't mean that the documentation should not tell me about the full set of expectations.

----------

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

From report at bugs.python.org  Mon Jun 16 03:26:34 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Jun 2014 01:26:34 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1402881993.93.0.517500736786.issue21763@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[R David Murray]
>I don't think that's true, though.  "file like" pretty much means 
> "has the file attributes that I actually use".  
> That is, it is context dependent (duck typing).

That is pretty much on-target.  

Also, the phrase "file-like" has been used very loosely from Python's inception.  Laying down a "mandatory" specification doesn't match the reality of how the phrase is used or the way our code has been written.

> Maybe I'm missing some important point here

Yes, I think you are.  That is evident in this and your other tracker items whose theme is "there must be precisely documented rules for everything, all expectations, norms, cultural conventions, patterns must be written down, made precise, and enforced, etc".

Before creating more tracker items, please take time to learn about how Python's history, how it is used, and its cultural norms.  In particular, read the Zen of Python, consider what is meant by duck-typing, what is meant by "a consenting adults language", what is meant by over-specification, etc.  Python is quite different from Java in this regard.

In a quest for "tell me exactly what I have to do", I think you're starting to make-up new rules that don't reflect the underlying reality of  
the actual code or its intended requirements.

I recommend this tracker item be closed for the reasons listed by Nick Coghlan and David Murray.  I think the proposed patch doesn't make the docs better, and that it seeks to create new made-up rules rather than documenting the world as it actually exists.

Side-note:  The place to talk about what "file-like" means is the glossary.   The ABC for files and the term "file-like" are related but are not equal.

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

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

From report at bugs.python.org  Mon Jun 16 05:52:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jun 2014 03:52:12 +0000
Subject: [docs] [issue13779] os.walk: bottom-up
In-Reply-To: <1326452589.73.0.0617213643117.issue13779@psf.upfronthosting.co.za>
Message-ID: <3gsJWt6hwQz7LkP@mail.python.org>


Roundup Robot added the comment:

New changeset 351c1422848f by Benjamin Peterson in branch '2.7':
clarify when the list of subdirectories is read (closes #13779)
http://hg.python.org/cpython/rev/351c1422848f

New changeset b10322b5ef0f by Benjamin Peterson in branch '3.4':
clarify when the list of subdirectories is read (closes #13779)
http://hg.python.org/cpython/rev/b10322b5ef0f

New changeset 1411df211159 by Benjamin Peterson in branch 'default':
merge 3.4 (#13779)
http://hg.python.org/cpython/rev/1411df211159

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

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

From report at bugs.python.org  Mon Jun 16 09:06:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jun 2014 07:06:28 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <3gsNr33gVRz7Lk7@mail.python.org>


Roundup Robot added the comment:

New changeset 95d487abbfd8 by Terry Jan Reedy in branch '2.7':
Issue #19362: Tweek len() doc and docstring to expand the indicated range of
http://hg.python.org/cpython/rev/95d487abbfd8

New changeset 8fcbe41e1242 by Terry Jan Reedy in branch '3.4':
Issue #19362: Tweek len() doc and docstring to expand the indicated range of
http://hg.python.org/cpython/rev/8fcbe41e1242

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

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

From report at bugs.python.org  Mon Jun 16 09:08:34 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Jun 2014 07:08:34 +0000
Subject: [docs] [issue19362] Documentation for len() fails to mention that
	it works	on sets
In-Reply-To: <1382530928.74.0.685857253341.issue19362@psf.upfronthosting.co.za>
Message-ID: <1402902514.47.0.307034512559.issue19362@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Jun 16 09:31:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jun 2014 07:31:51 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <3gsPPM16PFz7Lk8@mail.python.org>


Roundup Robot added the comment:

New changeset 9ba324a20bad by Terry Jan Reedy in branch '3.4':
Issue #21559: Add alternative (historical) reason for OverflowError.
http://hg.python.org/cpython/rev/9ba324a20bad

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

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

From report at bugs.python.org  Mon Jun 16 09:32:56 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Jun 2014 07:32:56 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1402903976.54.0.0486042166551.issue21559@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> resolved

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

From report at bugs.python.org  Mon Jun 16 09:33:06 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 Jun 2014 07:33:06 +0000
Subject: [docs] [issue21559] OverflowError should not happen for integer
	operations
In-Reply-To: <1400841279.05.0.350458307747.issue21559@psf.upfronthosting.co.za>
Message-ID: <1402903986.85.0.183851664064.issue21559@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Mon Jun 16 14:11:56 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 Jun 2014 12:11:56 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <3gsWcW6LXlz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset f254ceec0d45 by Jesus Cea in branch '2.7':
Closes #21759: URL Typo in Documentation FAQ
http://hg.python.org/cpython/rev/f254ceec0d45

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

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

From report at bugs.python.org  Mon Jun 16 14:12:27 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 16 Jun 2014 12:12:27 +0000
Subject: [docs] [issue21759] URL Typo in Documentation FAQ
In-Reply-To: <1402773513.31.0.46337082832.issue21759@psf.upfronthosting.co.za>
Message-ID: <1402920747.72.0.368703500311.issue21759@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Thanks!

----------
nosy: +jcea

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

From techtonik at gmail.com  Fri Jun 13 11:48:38 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Fri, 13 Jun 2014 12:48:38 +0300
Subject: [docs] No reference for string.format()
Message-ID: <CAPkN8xKfY=ojfkpRMZrZw2NQV5XwwBBOHpYfSWU2hdH3kQkc1Q@mail.gmail.com>

I tried to give people a link to string.format() documentation
and found that there is no good example or user reference.

https://docs.python.org/2/library/string.html#formatspec
- what this does first is confuses people, because it is too
abstract and goes deep into some awkward BNF, then lists
a lot of letters, and only then, in the next chapter, is the
example.

It looks like the order is reversed from the usual way people
look:
1. example
2. overview
3. user details
4. developer details


I am not aware of any kind of optional documentation writing
guide for Python? Maybe it is a good way to write one? I
know many people are aware of WriteTheDocs. What people
there say about issues such as this? Is there a systematic
approach to heal that?

-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140613/37d9ec0c/attachment.html>

From wkarani83.sk at gmail.com  Mon Jun 16 15:59:39 2014
From: wkarani83.sk at gmail.com (karani buyabo)
Date: Mon, 16 Jun 2014 16:59:39 +0300
Subject: [docs] manuals
Message-ID: <CACp9OcNdW=CFMQhn8Nybx8A+Hrhjx5AkLxHh7Wp3ijjidadJaQ@mail.gmail.com>

dear sir/madman
i need these manuals so that i can learn how to use these python

-- 
thank u
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140616/bd809dbf/attachment.html>

From jesse at wefu.org  Mon Jun 16 17:31:48 2014
From: jesse at wefu.org (Jesse W)
Date: Mon, 16 Jun 2014 08:31:48 -0700
Subject: [docs] Typo in "Functional Programming HOWTO"
Message-ID: <1402932708.3605.194.camel@zareason-alto4330>

Don't just use its value in expressions unless you're sure that the
``send()`` method will be the only method used resume your generator
function.

is missing a word: "used resume" should be "used to resume".

I may try to file a tracker entry later.

Jesse

From zachary.ware+pydocs at gmail.com  Mon Jun 16 18:15:41 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 16 Jun 2014 11:15:41 -0500
Subject: [docs] Typo in "Functional Programming HOWTO"
In-Reply-To: <1402932708.3605.194.camel@zareason-alto4330>
References: <1402932708.3605.194.camel@zareason-alto4330>
Message-ID: <CAKJDb-Mser4W6ua+pOpvA1br+0pkeV47QVYcPt7X5XbE3uUssA@mail.gmail.com>

On Mon, Jun 16, 2014 at 10:31 AM, Jesse W <jesse at wefu.org> wrote:
> Don't just use its value in expressions unless you're sure that the
> ``send()`` method will be the only method used resume your generator
> function.
>
> is missing a word: "used resume" should be "used to resume".
>
> I may try to file a tracker entry later.

No need, it's already fixed :).  Thanks for the report!

-- 
Zach

From zachary.ware+pydocs at gmail.com  Mon Jun 16 17:46:49 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 16 Jun 2014 10:46:49 -0500
Subject: [docs] manuals
In-Reply-To: <CACp9OcNdW=CFMQhn8Nybx8A+Hrhjx5AkLxHh7Wp3ijjidadJaQ@mail.gmail.com>
References: <CACp9OcNdW=CFMQhn8Nybx8A+Hrhjx5AkLxHh7Wp3ijjidadJaQ@mail.gmail.com>
Message-ID: <CAKJDb-O11PxvRhACrqX1NfYf7uaXyEj2wxzWi+crB8Wnh8PfEg@mail.gmail.com>

Hi,

On Mon, Jun 16, 2014 at 8:59 AM, karani buyabo <wkarani83.sk at gmail.com> wrote:
> dear sir/madman
> i need these manuals so that i can learn how to use these python

You can view the documentation online at https://docs.python.org/3/ or
download it in a format of your choice from
https://docs.python.org/3/download.html

Regards,
-- 
Zach

From report at bugs.python.org  Mon Jun 16 20:01:18 2014
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 16 Jun 2014 18:01:18 +0000
Subject: [docs] [issue21778] PyBuffer_FillInfo() from 3.3
In-Reply-To: <1402927404.66.0.0840543943961.issue21778@psf.upfronthosting.co.za>
Message-ID: <1402941677.98.0.0097780634649.issue21778@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think it's worth adding a note to the docs about passing the flags unmodified inside a getbufferproc.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution: not a bug -> 
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun 16 20:36:54 2014
From: report at bugs.python.org (Giacomo Alzetta)
Date: Mon, 16 Jun 2014 18:36:54 +0000
Subject: [docs] [issue21782] hashable documentation error: shouldn't mention
	id
Message-ID: <1402943814.73.0.280307813498.issue21782@psf.upfronthosting.co.za>


New submission from Giacomo Alzetta:

The documentation for hashable in the glossary (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) is incorrect:

they all compare unequal (except with themselves), **and their hash value is their id().**

It is *not* true that their hash is their id (see relevant SO question: http://stackoverflow.com/questions/24249729/user-defined-class-hash-and-id-and-doc)

Also the documentation for __hash__ (https://docs.python.org/3.4/reference/datamodel.html#object.__hash__) doesn't even mention id().

----------
assignee: docs at python
components: Documentation
messages: 220746
nosy: Giacomo.Alzetta, docs at python
priority: normal
severity: normal
status: open
title: hashable documentation error: shouldn't mention id
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jun 16 21:02:06 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Jun 2014 19:02:06 +0000
Subject: [docs] [issue21782] hashable documentation error: shouldn't mention
	id
In-Reply-To: <1402943814.73.0.280307813498.issue21782@psf.upfronthosting.co.za>
Message-ID: <1402945326.42.0.466523995337.issue21782@psf.upfronthosting.co.za>


R. David Murray added the comment:

The statement is poorly worded.  The id() is the *input* to the hash function used to compute the default __hash__.  This is a CPython implementation detail, though, so perhaps all mention of it should indeed be dropped.

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

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

From report at bugs.python.org  Mon Jun 16 21:24:48 2014
From: report at bugs.python.org (Giacomo Alzetta)
Date: Mon, 16 Jun 2014 19:24:48 +0000
Subject: [docs] [issue21782] hashable documentation error: shouldn't mention
	id
In-Reply-To: <1402943814.73.0.280307813498.issue21782@psf.upfronthosting.co.za>
Message-ID: <1402946688.19.0.885777148748.issue21782@psf.upfronthosting.co.za>


Giacomo Alzetta added the comment:

"their hash value is their id()" seems quite clearly stating that:

>>> class A: pass
... 
>>> a = A()
>>> hash(a) == id(a)

should be true, but:

>>> hash(a) == id(a)
False

(both in python2 and in python3)

The python 2 documentation for the __hash__ special method *does* state that the default implementation returns a value "derived" by id().
I believe there is an inconsistency. In the python2 glossary it should say:

"their hash value is derived from their id()"

While in python3 it shouldn't mention id() at all, since the documentation for __hash__ doesn't mention it at all.

----------

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

From antomsa at hotmail.it  Mon Jun 16 20:34:17 2014
From: antomsa at hotmail.it (Antonio Cota)
Date: Mon, 16 Jun 2014 20:34:17 +0200
Subject: [docs] Return value of hash() and id() of an user-defined class
Message-ID: <BLU436-SMTP1827CECF2078341BDC05BB3D8160@phx.gbl>

https://docs.python.org/3.5/glossary.html#term-hashable

actual docs says:
" Objects which are instances of user-defined classes are hashable by 
default; they all compare unequal (except with themselves), and their 
hash value is theirid() 
<https://docs.python.org/3.3/library/functions.html#id>."

I think it should be:
" Objects which are instances of user-defined classes are hashable by 
default; they all compare unequal (except with themselves), and their 
hash value is *DERIVED* from theirid() 
<https://docs.python.org/3.3/library/functions.html#id>." because hash() 
and id() of an instance of an user-defined class don't return the same 
value.

Best regards,
Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140616/60015edd/attachment.html>

From report at bugs.python.org  Mon Jun 16 22:26:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 Jun 2014 20:26:21 +0000
Subject: [docs] [issue21782] hashable documentation error: shouldn't mention
	id
In-Reply-To: <1402943814.73.0.280307813498.issue21782@psf.upfronthosting.co.za>
Message-ID: <1402950381.33.0.653400422871.issue21782@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I should have been clearer.  By "poorly worded" I meant "id is involved, but the sentence does not correctly describe *how* id is involved".  That is, the sentence is wrong as written.

The implementation is the same in both Python2 and Python3, though the source code organization and how it becomes the default hash is a bit different.

----------

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

From report at bugs.python.org  Mon Jun 16 23:18:08 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Jun 2014 21:18:08 +0000
Subject: [docs] [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1402953488.35.0.196308622362.issue17888@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

In recent months people have been doing some great work on the docs, is this something that one of them could pick up?  I'm sorry that I can't remember any names.

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

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

From report at bugs.python.org  Mon Jun 16 23:53:00 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Jun 2014 21:53:00 +0000
Subject: [docs] [issue8822] datetime naive and aware types should have a
	well-defined	definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1402955580.47.0.875604032758.issue8822@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I like the wording in the patch as it's clearer than the original and so think it should be applied.

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

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

From report at bugs.python.org  Tue Jun 17 00:18:35 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 16 Jun 2014 22:18:35 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402881993.93.0.517500736786.issue21763@psf.upfronthosting.co.za>
Message-ID: <539F6D39.6000703@rath.org>


Nikolaus Rath added the comment:

On 06/15/2014 06:26 PM, Raymond Hettinger wrote:
> Before creating more tracker items, please take time to learn about how Python's history, 
[...]

It'd be nice if you would have at least followed the link to
http://article.gmane.org/gmane.comp.python.devel/148199 before
commenting. In case you still can't spare the time for that: I
explicitly asked on python-dev about this *before* I opened a tracker item.

Apart from that, I think your remarks are neither appropriate nor do
they belong in the tracker.

----------

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

From report at bugs.python.org  Tue Jun 17 00:27:55 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Jun 2014 22:27:55 +0000
Subject: [docs] [issue1635217] Warn against using
	requires/provides/obsoletes in	setup.py
Message-ID: <1402957675.7.0.00799217549469.issue1635217@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 17 00:38:54 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Jun 2014 22:38:54 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1402958334.57.0.598868718573.issue1446619@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The attached patch is simple enough, surely it's a simple decision as to whether or not to commit it?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 17 00:47:06 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 16 Jun 2014 22:47:06 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1402958826.27.0.367214337151.issue11176@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

If we've got some meaningful changes can we please get them committed.  However I'd like to state that with over 4000 issues open we've got better things to do than change docs because somebody doesn't like the use of foo, bar and baz in examples.

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

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

From report at bugs.python.org  Tue Jun 17 04:48:32 2014
From: report at bugs.python.org (abraithwaite)
Date: Tue, 17 Jun 2014 02:48:32 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
Message-ID: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>


New submission from abraithwaite:

Is this expected?  It was very confusing when I cloned a repo that didn't have the __init__.py there when I had just made it, but of course git doesn't track files, only directories.  I had accidentaly done mkdir instead of touch.

$ mkdir pkg/__init__.py
$ touch pkg/foobar.py
$ python
Python 3.4.1 (default, May 19 2014, 17:23:49) 
[GCC 4.9.0 20140507 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import foobar
>>> foobar
<module 'pkg.foobar' from '/home/abraithwaite/pkg/foobar.py'>
>>>

----------
assignee: docs at python
components: Documentation
messages: 220787
nosy: abraithwaite, docs at python
priority: normal
severity: normal
status: open
title: __init__.py can be a directory
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 17 05:30:11 2014
From: report at bugs.python.org (abraithwaite)
Date: Tue, 17 Jun 2014 03:30:11 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1402975811.61.0.722826456882.issue21784@psf.upfronthosting.co.za>


abraithwaite added the comment:

> but of course git doesn't track files, only directories.

but of course git doesn't track *directories*, only *files*.

----------

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

From report at bugs.python.org  Tue Jun 17 06:54:33 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 Jun 2014 04:54:33 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1402980873.39.0.946323912732.issue21784@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Is this expected? 

It is a little weird but usually problematic.  The cause that import checks for the existence of '__init__.py' but doesn't then add isfile() or  isdir() check which would be unnecessary 99.9% of the time.

I classify this a harmless oddity.

----------
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Tue Jun 17 07:38:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 Jun 2014 05:38:49 +0000
Subject: [docs] [issue21785] __getitem__ and __setitem__ try to be smart
	when invoked	with negative slice indices
In-Reply-To: <1402982163.43.0.0546629268469.issue21785@psf.upfronthosting.co.za>
Message-ID: <1402983529.83.0.423225963275.issue21785@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It's too late for a behavior change in 2.7.   That risks breaking code that relies on the current behavior.

However, the docs could be amended to indicate that slices with negative indicies are treated differently from scalar negative indicies, the former get length adjusted automatically and the latter don't.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, rhettinger
priority: normal -> low

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

From report at bugs.python.org  Tue Jun 17 08:28:15 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 Jun 2014 06:28:15 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1402986495.88.0.732382272187.issue21739@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> r.david.murray

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

From report at bugs.python.org  Tue Jun 17 09:10:53 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 Jun 2014 07:10:53 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1402989053.87.0.512678470753.issue21784@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think this is related to PEP 420.

    $ tree pkg/
    pkg/
    ??? foobar.py

    $ python3.2 -c "from pkg import foobar"
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
    ImportError: No module named pkg

But, with Python 3.3 and newer:

    $ python3.3 -c "from pkg import foobar"
    hello

See https://docs.python.org/3/whatsnew/3.3.html#pep-420-implicit-namespace-packages for the whatsnew entry.

----------
nosy: +berker.peksag, eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> pending

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

From report at bugs.python.org  Tue Jun 17 09:54:58 2014
From: report at bugs.python.org (Konstantin Tretyakov)
Date: Tue, 17 Jun 2014 07:54:58 +0000
Subject: [docs] [issue21785] __getitem__ and __setitem__ try to be smart
	when invoked	with negative slice indices
In-Reply-To: <1402982163.43.0.0546629268469.issue21785@psf.upfronthosting.co.za>
Message-ID: <1402991698.89.0.209245572763.issue21785@psf.upfronthosting.co.za>


Konstantin Tretyakov added the comment:

Do note that things are not as simple as "slices with negative indices are treated differently from scalar negative indicies".

Namely, behaviour differs whether you use [] or .__getitem__, and whether you use [a:b] or [slice(a,b)]. This does not make sense from a specification perspective, but has to be made clear in the docs then.

Besides, Jython does not have this problem and I presume other Python implementations might also be fine (e.g. PyPy or whatever else there exists, couldn't test now).

Hence, although fixing the docs does seem like a simple solution, if you want to regard the docs as a "specification of the Python language" rather than a list of particular CPython features, this won't be reasonable.

----------

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

From report at bugs.python.org  Tue Jun 17 09:59:30 2014
From: report at bugs.python.org (eryksun)
Date: Tue, 17 Jun 2014 07:59:30 +0000
Subject: [docs] [issue21785] __getitem__ and __setitem__ try to be smart
	when invoked	with negative slice indices
In-Reply-To: <1402982163.43.0.0546629268469.issue21785@psf.upfronthosting.co.za>
Message-ID: <1402991970.16.0.401963919786.issue21785@psf.upfronthosting.co.za>


eryksun added the comment:

Refer to the documentation for deprecated __getslice__ when slicing an instance of a classic class:

https://docs.python.org/2/reference/datamodel.html#object.__getslice__

The SLICE+3 implementation (apply_slice) calls PySequence_GetSlice if both index values can be converted to Py_ssize_t integers and if the type defines sq_slice (instance_slice for the "instance" type). The "instance" type is used for an instance of a classic class. This predates unification of Python classes and types.

apply_slice
http://hg.python.org/cpython/file/f89216059edf/Python/ceval.c#l4383

PySequence_GetSlice
http://hg.python.org/cpython/file/f89216059edf/Objects/abstract.c#l1995

instance_slice
http://hg.python.org/cpython/file/f89216059edf/Objects/classobject.c#l1177

A new-style class, i.e. a class that subclasses object, would have to define or inherit __getslice__ in order for the C sq_slice slot to be defined. But __getslice__ is deprecated and shouldn't be implemented  unless you have to override it in a subclass of a built-in type. 

When sq_slice doesn't exist, apply_slice instead calls PyObject_GetItem with a slice object:

    class A(object):
        def __getitem__(self, index):
            return index.start
        def __len__(self):
            return 10

    >>> A()[-1:10]
    -1

By the way, you don't observe the behavior in Python 3 because it doesn't have classic classes, and the __getslice__, __setslice__, and __delslice__ methods are not in its data model.

----------
components: +Interpreter Core -Documentation
nosy: +eryksun

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

From report at bugs.python.org  Tue Jun 17 10:05:15 2014
From: report at bugs.python.org (Konstantin Tretyakov)
Date: Tue, 17 Jun 2014 08:05:15 +0000
Subject: [docs] [issue21785] __getitem__ and __setitem__ try to be smart
	when invoked	with negative slice indices
In-Reply-To: <1402982163.43.0.0546629268469.issue21785@psf.upfronthosting.co.za>
Message-ID: <1402992314.96.0.554681937099.issue21785@psf.upfronthosting.co.za>


Konstantin Tretyakov added the comment:

Aha, I see. I knew I'd get bitten by not explicitly subclassing (object) one day.

In any case, adding a reference to this issue into the docs of __getitem__ and __setitem__ would probably save someone some hours of utter confusion in the future.

----------

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

From report at bugs.python.org  Tue Jun 17 16:07:14 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jun 2014 14:07:14 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1403014034.86.0.103235757476.issue21763@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nikolaus: while I agree that Raymond's comments were a bit strongly worded, it doesn't read to me as if the thread you link to is on point for this issue.  The thread was focused on a *specific* question, that of calling close twice.  The question of what the docs mean by "a file like object" is a different question.  Specifically, you will note that "duck typing" never came up in that thread (as far as I remember).

As Raymond indicated, a glossary entry would be appropriate, and would reference the ABCs.

This entry already exists; although it is labeled "file object", it mentions that they are also called "file like objects".  It would be appropriate to link mentions of the phrase "file like object" in the docs to this glossary term, if they aren't already.

----------

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

From report at bugs.python.org  Tue Jun 17 16:25:06 2014
From: report at bugs.python.org (abraithwaite)
Date: Tue, 17 Jun 2014 14:25:06 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1403015106.55.0.120760764138.issue21784@psf.upfronthosting.co.za>


abraithwaite added the comment:

Interesting.  I saw the same behavior on 2.7.7 as well:

$ python2
Python 2.7.7 (default, Jun  3 2014, 01:46:20) 
[GCC 4.9.0 20140521 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pkg import foobar
>>> foobar
<module 'pkg.foobar' from 'pkg/foobar.py'>
>>> 

Anyways, it doesn't bother me too much.  I opened a ticket because I couldn't find an already open bug about it or any reference to it on google (although the keywords aren't great for google searches).

Cheers!

----------
resolution: not a bug -> 
status: pending -> open

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

From report at bugs.python.org  Tue Jun 17 17:54:12 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Jun 2014 15:54:12 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1403020452.41.0.63305940734.issue21784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the issue #7732.

----------
nosy: +haypo

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

From report at bugs.python.org  Tue Jun 17 18:00:59 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 Jun 2014 16:00:59 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1403020859.06.0.67105118032.issue21784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I remember that I added an check in Python 3.2 on the file type to explicitly reject directories:
http://hg.python.org/cpython/rev/125887a41a6f

+            if (stat(buf, &statbuf) == 0 && S_ISDIR(statbuf.st_mode))
+                /* it's a directory */
+                fp = NULL;
+            else

I wrote this change in the C code, I didn't report the change to the Python code (importlib).

A huge work was also done in importlib to reduce the number of calls to stat(). So maybe a check was dropped by mistake?

----------

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

From report at bugs.python.org  Tue Jun 17 18:23:08 2014
From: report at bugs.python.org (Eric Radman)
Date: Tue, 17 Jun 2014 16:23:08 +0000
Subject: [docs] [issue21791] Proper return status of os.WNOHANG is not
	always (0, 0)
Message-ID: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za>


New submission from Eric Radman:

The documentation for the WNOHANG flag (https://docs.python.org/3.4/library/os.html#os.WNOHANG) suggests that a return value of (0, 0) indicates success. This is not always true, the second value may contain a value even on success. On OpenBSD 5.5 this is an exaple status of a process that is still running:

pid, status = os.waitpid(pid, os.WNOHANG)
(0, -168927460)

It would be more accurate to say that if pid==0 then the process is running and that status is platform dependent.

----------
assignee: docs at python
components: Documentation
messages: 220843
nosy: docs at python, eradman
priority: normal
severity: normal
status: open
title: Proper return status of os.WNOHANG is not always (0, 0)
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Jun 17 19:59:17 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Jun 2014 17:59:17 +0000
Subject: [docs] [issue9499] Python C/API Execution namespace undocumented.
	(patch	included)
In-Reply-To: <1280873534.19.0.920563075759.issue9499@psf.upfronthosting.co.za>
Message-ID: <1403027957.62.0.357780726155.issue9499@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can somebody review this small patch please.

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

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

From report at bugs.python.org  Tue Jun 17 20:02:08 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Jun 2014 18:02:08 +0000
Subject: [docs] [issue8997] Write documentation for
	codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1403028128.85.0.385735857909.issue8997@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Slipped under the radar?

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

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

From report at bugs.python.org  Tue Jun 17 20:47:34 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 17 Jun 2014 18:47:34 +0000
Subject: [docs] [issue10170] Relationship between turtle speed setting and
	actual	speed is not documented
In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>
Message-ID: <1403030854.85.0.675873764475.issue10170@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

IIRC somebody has been working on the turtle code and/or docs recently, if I'm correct presumably they could pick this issue up?

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

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

From report at bugs.python.org  Tue Jun 17 21:13:20 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 Jun 2014 19:13:20 +0000
Subject: [docs] [issue10170] Relationship between turtle speed setting and
	actual	speed is not documented
In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>
Message-ID: <1403032400.21.0.293256314884.issue10170@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.2

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

From report at bugs.python.org  Tue Jun 17 22:13:35 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 17 Jun 2014 20:13:35 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1403014034.86.0.103235757476.issue21763@psf.upfronthosting.co.za>
 (R. David Murray's message of "Tue, 17 Jun 2014 14:07:14 +0000")
Message-ID: <87fvj3z444.fsf@rath.org>


Nikolaus Rath added the comment:

"R. David Murray" <report at bugs.python.org> writes:
> R. David Murray added the comment:
>
> Nikolaus: while I agree that Raymond's comments were a bit strongly
> worded, it doesn't read to me as if the thread you link to is on point
> for this issue.  The thread was focused on a *specific* question, that
> of calling close twice.  The question of what the docs mean by "a file
> like object" is a different question.  Specifically, you will note
> that "duck typing" never came up in that thread (as far as I
> remember).

That's quite correct. But did not come up in the original issue report
either - that's why I still don't understand why we're discussing it
here at all.

My line of thought was as follows:

 - Standard library assumes that close() is idempotent in many places
 - Currently this isn't documented clearly
 - The best place to make it more explicit seemed to be the description
   of IOBase
 - However, changing the description of only IOBase.close() could easily
   give the impression that close() is somehow special, and that
   fewer/no assumptions are made in the standard lbirary about the
   presence/behavior of the other methods (e.g. fileno or readable).
 - Therefore, to me the best course of action seemed to add a paragraph
   explicitly describing that the standard library may assume that 
   *any* method/attribute of a stream object behaves as described for
   IOBase.

I still don't see how this contradicts / interacts with the concept of
duck typing. I think the documentation (with and without the patch)
clearly implies that you can implement an object that does not have the
full IOBase API and successfully hand it to some standard library
function - it's just that in that case you can't complain if it
breaks.

Or is the point of contention just the title of this issue? Maybe it was
poorly chosen, I guess "Clarify standard library's expectations from
stream objects" would have been better.

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             ?Time flies like an arrow, fruit flies like a Banana.?

----------

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

From report at bugs.python.org  Tue Jun 17 22:28:20 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jun 2014 20:28:20 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1403036900.88.0.316582973409.issue21763@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, but we think it's pretty clear.  The glossary entry says file object interfaces are defined by the classes in the io module.  As do the io module docs.  Perhaps the first sentence of the io docs could be modified to strengthen that (but it already does link to the glossary entry which is explicit that the io module defines the interfaces).

On the other hand, your statement that "few or no other assumptions are made" is, while not accurate, not *wrong*, in the following sense:  *if* a standard library module depends on file attributes and methods, then it expects them to conform to the io module interfaces.  If it does not depend on a particular part of the API, then a duck type class doesn't actually have to implement that API in order to work with that standard library module.  Of course, we might change what elements of the file API are depended on, but hopefully we only do that kind of change in a feature release.  I'm sure we have made such changes while fixing bugs, though, so if you want to be *sure* of forward compatibility, you should indeed implement the full io-specified interface in your file-like class.  Which is one reason the ABCs provide default implementations for most of the methods.  It makes it really easy to build a future-proofed duck type.

----------

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

From report at bugs.python.org  Tue Jun 17 22:32:42 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jun 2014 20:32:42 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1403037162.28.0.286589949549.issue21763@psf.upfronthosting.co.za>


R. David Murray added the comment:

Re-reading my last paragraph, I see that I'm pretty much agreeing with you.  So the contention is more that we don't think your suggested patch is necessary.  Especially since, unlike your patch wording says, in fact most of the methods *are* implemented in the classes.

----------

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

From report at bugs.python.org  Tue Jun 17 22:34:28 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 17 Jun 2014 20:34:28 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1403037268.16.0.771977184042.issue21763@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Rather than a note, there could be a separate section for guidelines when implementing one's own IO classes. Assuming there's anything significant to put in such a section, that is :-)

----------

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

From report at bugs.python.org  Tue Jun 17 22:42:35 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 17 Jun 2014 20:42:35 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1403036900.88.0.316582973409.issue21763@psf.upfronthosting.co.za>
Message-ID: <53A0A838.5050406@rath.org>


Nikolaus Rath added the comment:

On 06/17/2014 01:28 PM, R. David Murray wrote:
> Well, but we think it's pretty clear.

This wasn't the impression that I had from the thread on python-devel,
but I'll accept your judgement on that. I'll be more restrained when
being asked for suggestions in the future.

----------

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

From report at bugs.python.org  Tue Jun 17 22:59:05 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jun 2014 20:59:05 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1402784210.73.0.906295011088.issue21763@psf.upfronthosting.co.za>
Message-ID: <1403038745.76.0.418771035787.issue21763@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe Antoine was suggesting that you suggest wording that would make it clear (rather than implied) that close was idempotent, but "This method has no effect if the file is already closed" seems pretty unambiguous to me, so I don't really see anything to do there (and presumably neither did you :)  Which means your patch here wasn't really what Antoine was suggesting.

But please don't hesitate to offer improvements in any context, solicited or not.  You just have to be prepared for pushback, because open source :)  And when shifting from mailing list to bug tracker, you may invoke a different audience with different perceptions of the problem.

Now, two alternate suggestions have been made here in reaction to your suggestion: strengthening the "this is also a specification" sense of the first sentence in the IO docs, and writing a separate section on implementing your own IO classes.  You could take a crack at either of those if you like.  Neither of these would have been suggested if you hadn't posted your thoughts on what to do and engaged in this discussion, so it is a positive contribution even if your patch is not accepted.

----------

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

From report at bugs.python.org  Tue Jun 17 23:52:47 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 17 Jun 2014 21:52:47 +0000
Subject: [docs] [issue21763] Clarify requirements for file-like objects
In-Reply-To: <1403038745.76.0.418771035787.issue21763@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eNNYNsv387rZ9twOkS1ciSne6cXUVUmXSFm5yZA7v0sQ@mail.gmail.com>


Nick Coghlan added the comment:

I can add a third suggestion: a "HOWTO" guide on implementing and using
file-like objects. It's actually a somewhat complex topic with various
trade-offs involved, particularly in Python 3 where the differences between
binary and text IO are greater. It could also point users to existing
file-like objects that they may have missed (like the spooled temporary
file support in tempfile).

On the more specific matter at hand, I think "close() is idempotent" is not
only one of our most pervasive assumptions about file-like objects, but
also an assumption we tend to make about resources *in general*.

----------

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

From cocoatomo77 at gmail.com  Wed Jun 18 02:13:31 2014
From: cocoatomo77 at gmail.com (tomo cocoa)
Date: Wed, 18 Jun 2014 09:13:31 +0900
Subject: [docs] typo: "was is" should be "was"
Message-ID: <CAN_7T0JjywkDmvc_LQ9RYvAm=v-dpP=xmJbxKgJoA=aHoETBYg@mail.gmail.com>

Hello,

I am a Japanese translator of Python documents.

I found a typo on
https://docs.python.org/3.4/library/ossaudiodev.html#ossaudiodev.oss_mixer_device.get
.

   Raises OSSAudioError if an invalid control was is specified
   ?
   Raises OSSAudioError if an invalid control was specified

Perhaps, a following sentence may also has a typo, but I am not sure.

   or OSError if an unsupported control is specified
   ?
   or OSError if an unsupported control was specified


Regards,
cocoatomo

-- 
class Cocoatomo:
    name = 'cocoatomo'
    email_address = 'cocoatomo77 at gmail.com'
    twitter_id = '@cocoatomo'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140618/704047e2/attachment.html>

From zachary.ware+pydocs at gmail.com  Wed Jun 18 05:38:01 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 17 Jun 2014 22:38:01 -0500
Subject: [docs] typo: "was is" should be "was"
In-Reply-To: <CAN_7T0JjywkDmvc_LQ9RYvAm=v-dpP=xmJbxKgJoA=aHoETBYg@mail.gmail.com>
References: <CAN_7T0JjywkDmvc_LQ9RYvAm=v-dpP=xmJbxKgJoA=aHoETBYg@mail.gmail.com>
Message-ID: <CAKJDb-Ntb7Vjho5DkCk4596pkfmxTAWiSZSbVc1=vnfH5tr=ZQ@mail.gmail.com>

On Tue, Jun 17, 2014 at 7:13 PM, tomo cocoa <cocoatomo77 at gmail.com> wrote:
> Hello,
>
> I am a Japanese translator of Python documents.
>
> I found a typo on
> https://docs.python.org/3.4/library/ossaudiodev.html#ossaudiodev.oss_mixer_device.get.
>
>    Raises OSSAudioError if an invalid control was is specified
>    ?
>    Raises OSSAudioError if an invalid control was specified
>
> Perhaps, a following sentence may also has a typo, but I am not sure.
>
>    or OSError if an unsupported control is specified
>    ?
>    or OSError if an unsupported control was specified

Thanks for the report!  This has been fixed.

-- 
Zach

From report at bugs.python.org  Wed Jun 18 21:48:29 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 18 Jun 2014 19:48:29 +0000
Subject: [docs] [issue1576313] os.execvp[e] on win32 fails for current
	directory
Message-ID: <1403120909.05.0.720690350199.issue1576313@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'd intended to write a patch but got confused as msg51241 talks about "execlp() in msvcrt" but execlp is in the os module.  Please advise.

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

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

From report at bugs.python.org  Wed Jun 18 22:14:11 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Jun 2014 20:14:11 +0000
Subject: [docs] [issue1576313] os.execvp[e] on win32 fails for current
	directory
Message-ID: <1403122451.22.0.301118667532.issue1576313@psf.upfronthosting.co.za>


R. David Murray added the comment:

os.execlp *wraps* the interface of the same name in the platform C library.  On Windows, that is execlp in the msvcrt[*].  On Linux, it is usually the execlp in glibc.

[*] 'crt' stands for 'C runtime'.

----------

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

From report at bugs.python.org  Thu Jun 19 12:51:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jun 2014 10:51:28 +0000
Subject: [docs] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
In-Reply-To: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>
Message-ID: <3gvKhH5DQPz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset 24c356168cc8 by Victor Stinner in branch '3.4':
Closes #21758: asyncio doc: mention explicitly that subprocess parameters are
http://hg.python.org/cpython/rev/24c356168cc8

New changeset b57cdb945bf9 by Victor Stinner in branch 'default':
(Merge 3.4) Closes #21758: asyncio doc: mention explicitly that subprocess
http://hg.python.org/cpython/rev/b57cdb945bf9

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

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

From report at bugs.python.org  Thu Jun 19 12:52:45 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Jun 2014 10:52:45 +0000
Subject: [docs] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
In-Reply-To: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>
Message-ID: <1403175165.23.0.916440882041.issue21758@psf.upfronthosting.co.za>


STINNER Victor added the comment:

A "string" can be a bytes string or a character string. I modified the documentation to be more explicitly, but IMO it's fine to keep "string" term in unit tests and error messages. You should not get the "string" error message if you pass a bytes or str object.

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

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

From report at bugs.python.org  Thu Jun 19 13:13:11 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Jun 2014 11:13:11 +0000
Subject: [docs] [issue21365] asyncio.Task reference misses the most
	important fact	about it,
	related info spread around intros and example commentary instead
In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za>
Message-ID: <1403176391.62.0.329123824101.issue21365@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Victor, since you wrote much of the asyncio doc, any comment on this request?

Please write a patch. The change is ok.

----------

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

From report at bugs.python.org  Thu Jun 19 13:23:07 2014
From: report at bugs.python.org (SylvainDe)
Date: Thu, 19 Jun 2014 11:23:07 +0000
Subject: [docs] [issue16399] argparse: append action with default list adds
	to list	instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1403176987.86.0.170251328022.issue16399@psf.upfronthosting.co.za>


SylvainDe added the comment:

As this is likely not to get solved, is there a recommanded way to work around this issue ?

Here's what I have done :

  import argparse
  def main():
      """Main function"""
      parser = argparse.ArgumentParser()
      parser.add_argument('--foo', action='append')
      for arg_str in ['--foo 1 --foo 2', '']:
          args = parser.parse_args(arg_str.split())
          if not args.foo:
              args.foo = ['default', 'value']
          print(args)

printing

  Namespace(foo=['1', '2'])
  Namespace(foo=['default', 'value'])

as expected but I wanted to know if there a more argparse-y way to do this. I have tried using `set_defaults` without any success.

Also, as pointed out the doc for optparse describes the behavior in a simple way : "The append action calls the append method on the current value of the option. This means that any default value specified must have an append method. It also means that if the default value is non-empty, the default elements will be present in the parsed value for the option, with any values from the command line appended after those default values".

----------
nosy: +SylvainDe

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

From report at bugs.python.org  Thu Jun 19 16:09:58 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 14:09:58 +0000
Subject: [docs] [issue1576313] os.execvp[e] on win32 fails for current
	directory
Message-ID: <1403186998.64.0.180273453247.issue1576313@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The patch deliberately says Windows msvcrt to distinguish it from the Python module of the same name.

----------
Added file: http://bugs.python.org/file35690/Issue1576313.diff

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

From report at bugs.python.org  Thu Jun 19 16:23:28 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 14:23:28 +0000
Subject: [docs] [issue11352] Update cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1403187808.4.0.087014712062.issue11352@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Pierre can you submit a clean patch as requested in msg214267?

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

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

From report at bugs.python.org  Thu Jun 19 16:33:37 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 14:33:37 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1403188417.77.0.639145046246.issue9739@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Terry is this something you could take on?

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

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

From report at bugs.python.org  Thu Jun 19 17:40:51 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Jun 2014 15:40:51 +0000
Subject: [docs] [issue21758] Not so correct documentation
	about	asyncio.subprocess_shell method
In-Reply-To: <1402762678.44.0.429008087381.issue21758@psf.upfronthosting.co.za>
Message-ID: <1403192451.21.0.322915381364.issue21758@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jun 19 17:44:27 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 15:44:27 +0000
Subject: [docs] [issue18017] ctypes.PyDLL documentation
In-Reply-To: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>
Message-ID: <1403192667.53.0.89819412782.issue18017@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Marc can you prepare a patch for this issue?

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

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

From report at bugs.python.org  Thu Jun 19 17:46:06 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 15:46:06 +0000
Subject: [docs] [issue16272] C-API documentation clarification for
	tp_dictoffset
In-Reply-To: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>
Message-ID: <1403192766.75.0.422885420256.issue16272@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Chris can you prepare a patch for this?

----------
nosy: +BreamoreBoy
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 19 17:54:02 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 15:54:02 +0000
Subject: [docs] [issue18612] More elaborate documentation on how list
	comprehensions	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1403193242.02.0.416785709333.issue18612@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Both list comprehension and generator expression are defined in the glossary https://docs.python.org/3/glossary.html, so what else can be done?

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

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

From report at bugs.python.org  Thu Jun 19 17:58:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 15:58:04 +0000
Subject: [docs] [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
In-Reply-To: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>
Message-ID: <1403193484.65.0.683968345549.issue18669@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a comment on this please.

----------
nosy: +BreamoreBoy
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 19 18:02:24 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 16:02:24 +0000
Subject: [docs] [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1403193744.19.0.905784067043.issue18588@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Steven you're into timeit, do you have anything to add here?

----------
nosy: +BreamoreBoy, steven.daprano

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

From report at bugs.python.org  Thu Jun 19 18:04:58 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 16:04:58 +0000
Subject: [docs] [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1403193898.21.0.197732566567.issue18703@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It looks as if there's nothing to be done here, is that correct?

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

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

From report at bugs.python.org  Thu Jun 19 18:10:56 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 16:10:56 +0000
Subject: [docs] [issue6673] Uncaught comprehension SyntaxError eats up all
	memory
In-Reply-To: <1249826985.41.0.2934011008.issue6673@psf.upfronthosting.co.za>
Message-ID: <1403194256.19.0.504662555361.issue6673@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Assuming that documentation changes are needed, who's best placed to do them?

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

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

From report at bugs.python.org  Thu Jun 19 18:18:47 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 Jun 2014 16:18:47 +0000
Subject: [docs] [issue21680] asyncio: document event loops
In-Reply-To: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>
Message-ID: <1403194727.26.0.994063048608.issue21680@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Windows, the default event loop is _WindowsSelectorEventLoop which calls select.select(). On Windows, select() only accepts socket handles:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms740141%28v=vs.85%29.aspx

Only file descriptors of sockets are accepted for add_reader() and add_writer()? This event loop doesn't support subprocesses. 


On Windows, the proactor event loop can be used instead to support subprocesses. But this event loop doesn't support add_reader() nor add_writer() :-( This event loop doesn't support SSL.


On Windows, the granularity of the monotonic time is usually 15.6 msec. I don't know if it's interesting to mention it. The resolution is different if HPET is enabled on Windows.


On Mac OS X older than 10.9 (Mavericks), selectors.KqueueSelector is the default selector but it doesn't character devices like PTY. The SelectorEventLoop can be used with SelectSelector or PollSelector to handle character devices on Mac OS X 10.6 (Snow Leopard) and later.

----------

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

From report at bugs.python.org  Thu Jun 19 18:22:50 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 19 Jun 2014 16:22:50 +0000
Subject: [docs] [issue16399] argparse: append action with default list adds
	to list	instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1403194970.66.0.0372070419653.issue16399@psf.upfronthosting.co.za>


paul j3 added the comment:

It should be easy to write a subclass of Action, or append Action, that does what you want.  It just needs a different `__call__` method.  You just need a way of identifying an default that needs to be overwritten as opposed to appended to.


    def __call__(self, parser, namespace, values, option_string=None):
        current_value = getattr(namspace, self.dest)
        if 'current_value is default':
            setattr(namespace, self.dest, values)
            return
        else:
            # the normal append action
            items = _copy.copy(_ensure_value(namespace, self.dest, []))
            items.append(values)
            setattr(namespace, self.dest, items)

People on StackOverFlow might have other ideas.

----------

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

From report at bugs.python.org  Thu Jun 19 18:25:16 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jun 2014 16:25:16 +0000
Subject: [docs] [issue18703] To change the doc of html/faq/gui.html
In-Reply-To: <1376157675.52.0.120458668025.issue18703@psf.upfronthosting.co.za>
Message-ID: <1403195116.61.0.380054583523.issue18703@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jun 19 19:12:25 2014
From: report at bugs.python.org (uglemat)
Date: Thu, 19 Jun 2014 17:12:25 +0000
Subject: [docs] [issue18612] More elaborate documentation on how list
	comprehensions	and generator expressions relate to each other
In-Reply-To: <1375356212.93.0.797789110077.issue18612@psf.upfronthosting.co.za>
Message-ID: <1403197945.03.0.525797278829.issue18612@psf.upfronthosting.co.za>


uglemat added the comment:

Yeah, I guess it's pretty obvious that generator expressions are not list comprehensions from the glossary. I'll close the bug.

----------
status: open -> closed

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

From report at bugs.python.org  Thu Jun 19 19:40:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 19 Jun 2014 17:40:04 +0000
Subject: [docs] [issue20068] collections.Counter documentation leaves out
	interesting	usecase
In-Reply-To: <1388040167.94.0.902280065341.issue20068@psf.upfronthosting.co.za>
Message-ID: <1403199604.48.0.681964254421.issue20068@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm -0 on this as it seems to be six of one, half a dozen of the other,  but I don't get the final say :)

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

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

From report at bugs.python.org  Thu Jun 19 22:05:28 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Jun 2014 20:05:28 +0000
Subject: [docs] [issue20068] collections.Counter documentation leaves out
	interesting	usecase
In-Reply-To: <1388040167.94.0.902280065341.issue20068@psf.upfronthosting.co.za>
Message-ID: <1403208328.14.0.390682688628.issue20068@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The introductory example already shows both ways of using a Counter:

1) How to tally one at a time:

   cnt = Counter()
   for word in ['red', 'blue', 'red', 'green', 'blue', 'blue']:
       cnt[word] += 1

2) How to count directly from a list:

    words = re.findall(r'\w+', open('hamlet.txt').read().lower())
    Counter(words).most_common(10)

----------
assignee: docs at python -> rhettinger
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Thu Jun 19 22:19:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Jun 2014 20:19:49 +0000
Subject: [docs] [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1403209189.22.0.954241795.issue18588@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I did find it somewhat confusing when trying to interpret 
> the timeit documentation.

Perhaps that is a good thing.  Making good, repeatable, meaningful timings  where you have a clear interpretation of the results is non-trivial, learned skill.   Cross-checking results and explaining differences are fundamental skills.  There is really no reason the docs should try to make it look easier that it really is (running the tool is easy, but interpreting results sometimes isn't).

> Being a somewhat pedantic and trivial patch, I'm fine if you 
> want to close it wontfix.

That is reasonable.  I don't that this has caused any actual impediment to learning how to use timeit.  The docs have been somewhat successful in that regard.

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

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

From report at bugs.python.org  Thu Jun 19 22:43:29 2014
From: report at bugs.python.org (eryksun)
Date: Thu, 19 Jun 2014 20:43:29 +0000
Subject: [docs] [issue16272] C-API documentation clarification for
	tp_dictoffset
In-Reply-To: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>
Message-ID: <1403210609.72.0.838886216012.issue16272@psf.upfronthosting.co.za>


eryksun added the comment:

It could also mention the generic getter and setter functions for the PyGetSetDef that were added in 3.3: PyType_GenericGetDict and PyType_GenericSetDict.

https://docs.python.org/3/c-api/object.html#c.PyType_GenericGetDict

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Jun 19 23:31:12 2014
From: report at bugs.python.org (eryksun)
Date: Thu, 19 Jun 2014 21:31:12 +0000
Subject: [docs] [issue18017] ctypes.PyDLL documentation
In-Reply-To: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>
Message-ID: <1403213472.06.0.460148928217.issue18017@psf.upfronthosting.co.za>


eryksun added the comment:

16.17.2.2 already has a warning after it introduces CDLL, OleDLL, and WinDLL:

    The Python global interpreter lock is released before 
    calling any function exported by these libraries, and 
    reacquired afterwards.

It links to the glossary entry:

    https://docs.python.org/3/glossary.html#term-global-interpreter-lock

It wouldn't hurt to elaborate and box this warning.

Subsequently, PyDLL is documented to *not* release the GIL. Also,  section 16.17.2.4 documents that CFUNCTYPE and WINFUNCTYPE functions release the GIL and PYFUNCTYPE functions will *not* release the GIL.

----------
nosy: +eryksun

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

From report at bugs.python.org  Thu Jun 19 23:55:39 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 Jun 2014 21:55:39 +0000
Subject: [docs] [issue21690] re documentation: re.compile links to re.search
	/	re.match instead of regex.search / regex.match
In-Reply-To: <1402183503.23.0.87974807547.issue21690@psf.upfronthosting.co.za>
Message-ID: <3gvcQf3JV1z7Ljm@mail.python.org>


Roundup Robot added the comment:

New changeset 88a1f3cf4ed9 by Ezio Melotti in branch '2.7':
#21690: fix a couple of links in the docs of the re module.  Noticed by Julian Gilbey.
http://hg.python.org/cpython/rev/88a1f3cf4ed9

New changeset 9090348a920d by Ezio Melotti in branch '3.4':
#21690: fix a couple of links in the docs of the re module.  Noticed by Julian Gilbey.
http://hg.python.org/cpython/rev/9090348a920d

New changeset 590ad80784bf by Ezio Melotti in branch 'default':
#21690: merge with 3.4.
http://hg.python.org/cpython/rev/590ad80784bf

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

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

From report at bugs.python.org  Thu Jun 19 23:56:49 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 21:56:49 +0000
Subject: [docs] [issue21690] re documentation: re.compile links to re.search
	/	re.match instead of regex.search / regex.match
In-Reply-To: <1402183503.23.0.87974807547.issue21690@psf.upfronthosting.co.za>
Message-ID: <1403215009.44.0.907363626139.issue21690@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
stage:  -> resolved
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Fri Jun 20 00:06:04 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 22:06:04 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1403215564.18.0.200513839521.issue21739@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

If we don't want to go into the details of why it's not equivalent, using "roughly equivalent" might be enough.

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Fri Jun 20 00:35:47 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 22:35:47 +0000
Subject: [docs] [issue20091] An index entry for __main__ in "30.5 runpy" is
	missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <1403217347.83.0.449886969554.issue20091@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 20 00:53:35 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 22:53:35 +0000
Subject: [docs] [issue17006] Add advice on best practices for hashing secrets
In-Reply-To: <1358758082.76.0.415880124971.issue17006@psf.upfronthosting.co.za>
Message-ID: <1403218415.04.0.887821846999.issue17006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 20 00:55:50 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 22:55:50 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing
	in	tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1403218550.47.0.106782036381.issue17383@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Jun 20 01:06:10 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 19 Jun 2014 23:06:10 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1403219170.74.0.877384137953.issue17462@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Fri Jun 20 02:01:05 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 20 Jun 2014 00:01:05 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <1403222465.49.0.130283014248.issue15588@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a review on this fairly small patch please.

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

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

From report at bugs.python.org  Fri Jun 20 03:20:14 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Jun 2014 01:20:14 +0000
Subject: [docs] [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1403227214.05.0.729953177034.issue9739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps after the Google Summer of Code project is done (mid-August).

----------

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

From report at bugs.python.org  Fri Jun 20 04:50:32 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Jun 2014 02:50:32 +0000
Subject: [docs] [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1403232632.78.0.56764037786.issue17888@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 20 08:47:22 2014
From: report at bugs.python.org (marc)
Date: Fri, 20 Jun 2014 06:47:22 +0000
Subject: [docs] [issue18017] ctypes.PyDLL documentation
In-Reply-To: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>
Message-ID: <1403246842.93.0.547226561975.issue18017@psf.upfronthosting.co.za>


marc added the comment:

I think the problem was a combination of two issues.

First, the warning in 16.17.2.2 is a bit hidden. Kind of squeezed in 
between CDLL, etc and PyDLL. In contrast, 16.17.2.4 does a much better 
job, because it restates the fact that the GIL is released at each and 
every item. I think this is much better, because chances are high that 
you actually read the entry completely. In contrast, in case you 
are in a hurry you might miss the warning in 16.17.2.2

I think the second problem was that back then I was not aware of the 
fact that you need the GIL to call the Python/C API. That was a bit 
stupid indeed. But as a Python beginner it was just not obvious. Maybe 
the Introduction of the Python/C API needs some work, too. No GIL 
mentioned at https://docs.python.org/3/c-api/intro.html.
Furthermore, the examples at 
https://docs.python.org/3/extending/extending.html also do not talk 
about the GIL.

----------
nosy: +marc at bruenink.de

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

From report at bugs.python.org  Fri Jun 20 10:27:10 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 20 Jun 2014 08:27:10 +0000
Subject: [docs] [issue20091] An index entry for __main__ in "30.5 runpy" is
	missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <1403252829.98.0.754971150261.issue20091@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Attached patch adds the index entry.

----------
keywords: +patch
nosy: +orsenthil
Added file: http://bugs.python.org/file35703/20091.patch

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

From report at bugs.python.org  Fri Jun 20 10:38:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jun 2014 08:38:46 +0000
Subject: [docs] [issue20091] An index entry for __main__ in "30.5 runpy" is
	missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <3gvthj1fGgz7Ljv@mail.python.org>


Roundup Robot added the comment:

New changeset d641c096b1f5 by Senthil Kumaran in branch '2.7':
issue 20091 - index entry for __main__ in runpy docs.
http://hg.python.org/cpython/rev/d641c096b1f5

New changeset 1727dcfff233 by Senthil Kumaran in branch '3.4':
issue 20091 - index entry for __main__ in runpy docs.
http://hg.python.org/cpython/rev/1727dcfff233

New changeset fd9f7bdd7472 by Senthil Kumaran in branch 'default':
merge from 3.4
http://hg.python.org/cpython/rev/fd9f7bdd7472

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

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

From report at bugs.python.org  Fri Jun 20 10:39:28 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 20 Jun 2014 08:39:28 +0000
Subject: [docs] [issue20091] An index entry for __main__ in "30.5 runpy" is
	missing
In-Reply-To: <1388243842.91.0.578293707742.issue20091@psf.upfronthosting.co.za>
Message-ID: <1403253568.44.0.960271077573.issue20091@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Fixed in all active branches.

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

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

From report at bugs.python.org  Fri Jun 20 10:41:04 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 20 Jun 2014 08:41:04 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <1403253663.91.0.457550917546.issue15588@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please do review it, Mark.

----------

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

From report at bugs.python.org  Fri Jun 20 11:18:24 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Jun 2014 09:18:24 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
Message-ID: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch creates a stat_result class in the os documentation and complete the documentation of each field. It makes possible to link directly an attribute of this class in the documentation, which is useful for the new st_file_attributes (issue #21719) for example.

----------
assignee: docs at python
components: Documentation
files: stat_result.patch
keywords: patch
messages: 221080
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: Enhance doc of os.stat_result
versions: Python 3.5
Added file: http://bugs.python.org/file35704/stat_result.patch

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

From report at bugs.python.org  Fri Jun 20 12:02:12 2014
From: report at bugs.python.org (Vincent Besanceney)
Date: Fri, 20 Jun 2014 10:02:12 +0000
Subject: [docs] [issue21814] object.__setattr__ or super(...).__setattr__?
Message-ID: <1403258532.08.0.198623829613.issue21814@psf.upfronthosting.co.za>


New submission from Vincent Besanceney:

In: https://docs.python.org/2.7/reference/datamodel.html#customizing-attribute-access

Regarding the description of __setattr__ method: "For new-style classes, rather than accessing the instance dictionary, it should call the base class method with the same name, for example, object.__setattr__(self, name, value)."

Wouldn't it be more consistent for new-style classes, instead of calling "object.__setattr__(self, name, value)", to call "super(<ClassName>, self).__setattr__(name, value)"?

----------
assignee: docs at python
components: Documentation
messages: 221082
nosy: docs at python, vincentbesanceney
priority: normal
severity: normal
status: open
title: object.__setattr__ or super(...).__setattr__?
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 20 15:17:50 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 Jun 2014 13:17:50 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
In-Reply-To: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>
Message-ID: <1403270269.94.0.933784842635.issue21813@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Rietveld didn't like an escape code at the beginning of your patch; here's the last 12,039 bytes of it which will hopefully make Rietveld happy.

----------
nosy: +zach.ware
Added file: http://bugs.python.org/file35705/stat_result.patch

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

From report at bugs.python.org  Fri Jun 20 15:38:48 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 Jun 2014 13:38:48 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
In-Reply-To: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>
Message-ID: <1403271528.15.0.617859712365.issue21813@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> ...an escape code at the beginning of your patch...

Yeah, these days I suffer because of the issue #19884 (readline issue in Mercurial).

----------

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

From zachary.ware at gmail.com  Fri Jun 20 15:42:32 2014
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Fri, 20 Jun 2014 13:42:32 -0000
Subject: [docs] Enhance doc of os.stat_result (issue 21813)
Message-ID: <20140620134232.11691.81687@psf.upfronthosting.co.za>

I like it, just a few nits picked.


http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1883
Doc/library/os.rst:1883: :ref:`not following symlinks
<follow_symlinks>`.
This paragraph confuses me: path_fd is not a parameter, but specifying a
file descriptor has already been mentioned; follow_symlinks has already
been mentioned as well.  The dir_fd parameter hasn't been mentioned,
though.

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1892
Doc/library/os.rst:1892: posix.stat_result(st_mode=33188,
st_ino=7876932, st_dev=234881026,
Is this still accurate? On Windows, at least, stat_result reprs show
"os.stat_result" rather than "<platform os module name>.stat_result".

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1904
Doc/library/os.rst:1904: .. versionadded:: 3.3
Kind of late on this, but shouldn't this be a versionchanged rather than
versionadded?  The note on st_file_attributes probably should be, too.

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1951
Doc/library/os.rst:1951: .. st_atime
attribute::

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode2043
Doc/library/os.rst:2043: Create of the file.
Creator

http://bugs.python.org/review/21813/diff/12221/Doc/whatsnew/3.5.rst
File Doc/whatsnew/3.5.rst (right):

http://bugs.python.org/review/21813/diff/12221/Doc/whatsnew/3.5.rst#newcode182
Doc/whatsnew/3.5.rst:182: * :class:`os.stat_result` now has a
:attr:`os.stat_result.st_file_attributes`
I'd rather hide the `os.stat_result` on st_file_attributes
(:attr:`~os.stat_result.st_file_attributes`) since the line starts with
'os.stat_result now has...'.

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

From report at bugs.python.org  Fri Jun 20 17:23:06 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 20 Jun 2014 15:23:06 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1403277786.44.0.484236160187.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can somebody set the stage to patch review and give my patch the once over please, thanks.

----------

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

From report at bugs.python.org  Fri Jun 20 20:25:42 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Jun 2014 18:25:42 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1403288742.34.0.782370801131.issue19980@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Jun 20 23:08:55 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 Jun 2014 21:08:55 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1403298535.71.0.748205673604.issue21784@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun 21 00:56:55 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Jun 2014 22:56:55 +0000
Subject: [docs] [issue21784] __init__.py can be a directory
In-Reply-To: <1402973312.89.0.00365270476425.issue21784@psf.upfronthosting.co.za>
Message-ID: <1403305015.24.0.108053361966.issue21784@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> So maybe a check was dropped by mistake?

Why do we care?  For the most part, Linux treats directories as files (if I do a mkdir twice, the error is "mkdir: tmp: File exists".  We don't care about the other flags rwx so why should we care about d?

Python should avoid adding superfluous checks when it doesn't have to.

> Anyways, it doesn't bother me too much.

AFAICT, it hasn't bothered anyone.

----------

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

From report at bugs.python.org  Sat Jun 21 00:57:03 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 20 Jun 2014 22:57:03 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403305023.11.0.600441494951.issue6916@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I don't think removing the documentation for a deprecated item is a good solution.  If people find it somewhere (old code, googling, via dir()) and find no related documentation, they might keep using it.
If it's clearly documented that the item exists but it's deprecated, people will avoid it (or at least be aware of what it does and the reason why it's deprecated).

I think it would be better to add back the documentation with a deprecated-removed directive, and possibly add warnings in the code (if they are not there already).  In future versions we can remove code and docs together.

----------
keywords: +easy -patch
resolution: fixed -> 
stage: patch review -> needs patch
status: closed -> open
type:  -> enhancement

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

From report at bugs.python.org  Sat Jun 21 01:28:08 2014
From: report at bugs.python.org (Angus Taggart)
Date: Fri, 20 Jun 2014 23:28:08 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
	module, not cookielib.Cookie class
Message-ID: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>


New submission from Angus Taggart:

all the links to Cookie class in the cookielib documentation point to Cookie module.


for example:

CookieJar.set_cookie(cookie)

    Set a *Cookie*, without checking with policy to see whether or not it should be set.


cookie in the documentation links to
https://docs.python.org/2/library/cookie.html#module-Cookie

cookie in the documentation should link to
https://docs.python.org/2/library/cookielib.html#cookielib.Cookie

----------
assignee: docs at python
components: Documentation
messages: 221133
nosy: Ajtag, docs at python
priority: normal
severity: normal
status: open
title: cookielib documentation references Cookie module, not cookielib.Cookie class
versions: Python 2.7

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

From report at bugs.python.org  Sat Jun 21 04:01:51 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 02:01:51 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403316111.07.0.718732797981.issue6916@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I don't think removing the documentation for a deprecated item is a good solution.

Dedocumenting is a reasonable thing to do and I believe we've done it several times before, leaving code only so as to not break anything.  I expect this code to get zero maintenance as it fades into oblivion.

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

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

From report at bugs.python.org  Sat Jun 21 04:14:15 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 02:14:15 +0000
Subject: [docs] [issue21814] object.__setattr__ or super(...).__setattr__?
In-Reply-To: <1403258532.08.0.198623829613.issue21814@psf.upfronthosting.co.za>
Message-ID: <1403316855.8.0.180141866295.issue21814@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Wouldn't it be more consistent for new-style classes,
> instead of calling "object.__setattr__(self, name, value)",
> to call "super(<ClassName>, self).__setattr__(name, value)"?

That's not always the right thing to do.  Calling object.__setattr__ gives a known, guaranteed behavior.   Using super however relies on an MRO calculation that may send the super call outside the inheritance tree to a methods that wasn't expecting to be called. 

Put another way, super was designed for cooperative multiple inheritance with implies an element of coordinated cooperation that isn't always present.

I think the current advice should stand.  We aren't advising people to always use super instead of calling a parent class method directly.  Part of the reason is that super can be much trickier that people expect.

Also, in Python 2.7 super() doesn't have the same magical but clean invocation it has in Python 3.  The two argument form isn't as elegant looking or as easy to get right.

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

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

From report at bugs.python.org  Sat Jun 21 04:55:30 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 02:55:30 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1403319330.65.0.86424703161.issue17462@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.  It reads well and is informative.

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

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

From report at bugs.python.org  Sat Jun 21 05:24:45 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 03:24:45 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403321085.64.0.757277480331.issue11974@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 21 09:41:06 2014
From: report at bugs.python.org (Vincent Besanceney)
Date: Sat, 21 Jun 2014 07:41:06 +0000
Subject: [docs] [issue21814] object.__setattr__ or super(...).__setattr__?
In-Reply-To: <1403258532.08.0.198623829613.issue21814@psf.upfronthosting.co.za>
Message-ID: <1403336466.2.0.207375320833.issue21814@psf.upfronthosting.co.za>


Vincent Besanceney added the comment:

If I understand it right, in a simple case like this:

  class Foo(object):

    def __setattr__(self, name, value):
      # some logic, then...
      super(Foo, self).__setattr__(name, value)

calling super is equivalent to calling object.__setattr__, but doesn't have any added-value since there's no cooperative multiple inheritance involved, in that case we are better off calling the parent class method directly.

If Foo evolves to have multiple ancestors, object has a __setattr__ method and that object is always the last class in the MRO chain, so any sequence of calls to super(..).__setattr__ is guaranteed to end with a call to object.__setattr__ method (assuming ancestors __setattr__ method, if any, calls super as well), and that may be what we want, i.e. to also benefit from an ancestor __setattr__ method.

Hmm, this last point may be too specific if not out of scope in regards to the documentation. Falling back to the original need, from the documentation "If __setattr__() wants to assign to an instance attribute...", so as you said, "calling object.__setattr__ gives a known, guaranteed behavior".

----------

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

From report at bugs.python.org  Sat Jun 21 10:20:48 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 21 Jun 2014 08:20:48 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403338848.23.0.936352147237.issue6916@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

IMHO until the code is there, the documentation also should be there -- even if it just to acknowledge the existence of the code and signal its deprecation.  Whether the code is eventually removed or not it's a separate issue.

----------

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

From report at bugs.python.org  Sat Jun 21 13:59:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jun 2014 11:59:34 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <3gwb5x63Gcz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 233168a2a656 by Giampaolo Rodola' in branch 'default':
#6916: raise a deprecation warning if using asynchat.fifo
http://hg.python.org/cpython/rev/233168a2a656

----------

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

From report at bugs.python.org  Sat Jun 21 14:01:53 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 21 Jun 2014 12:01:53 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403352113.83.0.713647320564.issue6916@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Signaling the deprecation or just the existence of asynchat.fifo really isn't worth the effort because the code is no longer used since fifo was replaced with a deque in python 2.6.
Basically it's dead code and the only reason it remained there is because there were some complaints about a compatibility breakage when the 2.6 patch was applied, but I remember fifo class had nothing to do with it.
FWIW I added a deprecation warning and scheduled asynchat.fifo for removal in python 3.6 but IMO it is not worth it to mention it in the doc.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Sat Jun 21 18:18:47 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 16:18:47 +0000
Subject: [docs] [issue21814] object.__setattr__ or super(...).__setattr__?
In-Reply-To: <1403258532.08.0.198623829613.issue21814@psf.upfronthosting.co.za>
Message-ID: <1403367527.12.0.409328413558.issue21814@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> If I understand it right, in a simple case like this: 
 ...
> calling super is equivalent to calling object.__setattr__,

It is not equivalent.  Instances of Foo() would behave equivalently but it might do something different for subclasses of Foo.  If you're interested in learning more about super(), have a look at:  http://rhettinger.wordpress.com/2011/05/26/super-considered-super/

In the meantime, I'm closing this because we do not make that blanket advice to always use super() instead of a direct call to a parent.  Sometimes you want one and sometimes you want the other depending on what you're trying to do.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Sat Jun 21 21:04:02 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 19:04:02 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403377442.72.0.913361875387.issue6916@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The tests are failing:

======================================================================
ERROR: test_basic (test.test_asynchat.TestFifo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/raymond/cpython/Lib/test/test_asynchat.py", line 266, in test_basic
    assert issubclass(w[0].category, DeprecationWarning)
IndexError: list index out of range

======================================================================
ERROR: test_given_list (test.test_asynchat.TestFifo)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/raymond/cpython/Lib/test/test_asynchat.py", line 283, in test_given_list
    assert issubclass(w[0].category, DeprecationWarning)
IndexError: list index out of range

----------

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

From report at bugs.python.org  Sat Jun 21 21:04:16 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 19:04:16 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403377456.16.0.253694676735.issue6916@psf.upfronthosting.co.za>


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


----------
priority: normal -> high
resolution: fixed -> 

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

From report at bugs.python.org  Sat Jun 21 23:59:10 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 21:59:10 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403387950.08.0.248446391069.issue11974@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Renee, thanks for the patch.  It looks pretty good.

I've reworked a bit to accomplish the following:

* Added a short introductory a short discussion about class variables versus instance variables.  This addresses other questions that tend to arise irrespective of mutability.

* Referenced the related discussion in"A Word About Names and Objects".

* Referenced the term "mutable" in the glossary.

* change "dangerous" to "unexpected" in accordance with the style guide and following Guido's own wording on the subject.

* Change the class names from "A" and "B" to a "Dog" class because readers tend to find that the more abstract "A" and "B" examples are a little harder to follow.

----------
Added file: http://bugs.python.org/file35716/class_instance_variables.diff

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

From report at bugs.python.org  Sun Jun 22 00:09:50 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 22:09:50 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403388590.07.0.704096796126.issue11974@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file35716/class_instance_variables.diff

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

From report at bugs.python.org  Sun Jun 22 00:10:05 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 21 Jun 2014 22:10:05 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403388605.28.0.0159089311082.issue11974@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file35717/class_instance_variables.diff

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

From report at bugs.python.org  Sun Jun 22 12:44:17 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jun 2014 10:44:17 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <3gx9Nc3g1Vz7Lkr@mail.python.org>


Roundup Robot added the comment:

New changeset aeeb385e61e4 by Giampaolo Rodola' in branch 'default':
#6916: attempt to fix BB failure
http://hg.python.org/cpython/rev/aeeb385e61e4

----------

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

From report at bugs.python.org  Sun Jun 22 16:39:52 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 22 Jun 2014 14:39:52 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1403447992.1.0.878998998811.issue6916@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Would using assertWarns be more suitable here? Attached a patch.

----------
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file35722/use-assertwarns.diff

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

From report at bugs.python.org  Sun Jun 22 17:49:33 2014
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 22 Jun 2014 15:49:33 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
	module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1403452173.39.0.597481796373.issue21818@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

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

From report at bugs.python.org  Sun Jun 22 20:18:54 2014
From: report at bugs.python.org (Andy Almonte)
Date: Sun, 22 Jun 2014 18:18:54 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
	not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1403461134.22.0.902182806088.issue21297@psf.upfronthosting.co.za>


Changes by Andy Almonte <andy.almonte at gmail.com>:


----------
nosy: +Andy.Almonte

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

From report at bugs.python.org  Sun Jun 22 20:24:59 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 22 Jun 2014 18:24:59 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403461499.35.0.243305741095.issue11974@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/issue11974>
_______________________________________

From report at bugs.python.org  Sun Jun 22 21:47:50 2014
From: report at bugs.python.org (jhao)
Date: Sun, 22 Jun 2014 19:47:50 +0000
Subject: [docs] [issue1398781] Example in section 5.3 "Pure Embedding"
	doesn't work.
Message-ID: <1403466470.52.0.603152233709.issue1398781@psf.upfronthosting.co.za>


jhao added the comment:

I have updated the example in the doc. This default behavior is introduced because of security reason as detailed in http://bugs.python.org/issue5753

----------
hgrepos: +261
nosy: +jhao

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

From report at bugs.python.org  Mon Jun 23 01:27:16 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jun 2014 23:27:16 +0000
Subject: [docs] [issue16667] timezone docs need "versionadded: 3.2"
In-Reply-To: <1355272202.83.0.0809647453086.issue16667@psf.upfronthosting.co.za>
Message-ID: <3gxVJz2zwQz7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset b32174cad588 by Benjamin Peterson in branch '3.4':
some timezone doc improvements (closes #16667)
http://hg.python.org/cpython/rev/b32174cad588

New changeset 7dc94337ef67 by Benjamin Peterson in branch 'default':
merge 3.4 (#16667)
http://hg.python.org/cpython/rev/7dc94337ef67

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

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

From report at bugs.python.org  Mon Jun 23 15:05:19 2014
From: report at bugs.python.org (Terry Chia)
Date: Mon, 23 Jun 2014 13:05:19 +0000
Subject: [docs] [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1403528719.81.0.841290918993.issue17888@psf.upfronthosting.co.za>


Terry Chia added the comment:

Hello,

I have attached a patch that should resolve this issue. Do let me know if anything needs fixing as this is my first contribution.

----------
keywords: +patch
nosy: +terry.chia
Added file: http://bugs.python.org/file35739/issue17888.patch

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

From report at bugs.python.org  Mon Jun 23 21:36:26 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 Jun 2014 19:36:26 +0000
Subject: [docs] [issue14013] tarfile should expose supported formats
In-Reply-To: <1329236847.51.0.270430673151.issue14013@psf.upfronthosting.co.za>
Message-ID: <1403552185.76.0.0933374741846.issue14013@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I've updated ?ric's patch. Minor changes:
- Updated versionadded directive
- A couple of cosmetic changes (e.g. removed brackets in the list comprehension)

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +berker.peksag
versions: +Python 3.5 -Python 3.3
Added file: http://bugs.python.org/file35742/issue14013.diff

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

From report at bugs.python.org  Tue Jun 24 03:03:30 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jun 2014 01:03:30 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <3gy8PX5pgYz7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset 8e0b7393e921 by Raymond Hettinger in branch '2.7':
Issue #11974:  Add tutorial section on class and instance variables
http://hg.python.org/cpython/rev/8e0b7393e921

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

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

From report at bugs.python.org  Tue Jun 24 03:11:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jun 2014 01:11:49 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403572309.04.0.292165594319.issue11974@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jun 24 03:12:41 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jun 2014 01:12:41 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403572361.64.0.424067243179.issue11974@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll load this into 3.4 and 3.5 shortly.

----------

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

From report at bugs.python.org  Tue Jun 24 13:49:52 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jun 2014 11:49:52 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
Message-ID: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Docstrings for seek() and truncate() methods of FileIO declare that they return None. Actually they return truncated size and new position respectively.

----------
assignee: docs at python
components: Documentation, IO
keywords: easy
messages: 221452
nosy: benjamin.peterson, docs at python, hynek, pitrou, serhiy.storchaka, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: Correct FileIO docstrings
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun 24 16:43:15 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Jun 2014 14:43:15 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <1403620995.22.0.30935879036.issue15588@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Just one small query on the patch (more for my own benefit than anything else).  In the rst file there's now no difference between the wording for the quotetabs positional argument to encode and the keyword argument to encodestring.  Is there a rule (of thumb) that covers this situation?  Other than that LGTM.

----------

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

From report at bugs.python.org  Tue Jun 24 16:56:08 2014
From: report at bugs.python.org (Terry Chia)
Date: Tue, 24 Jun 2014 14:56:08 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <1403621768.36.0.860912238058.issue21860@psf.upfronthosting.co.za>


Terry Chia added the comment:

Is this acceptable?

----------
keywords: +patch
nosy: +terry.chia
Added file: http://bugs.python.org/file35770/issue21860.patch

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

From report at bugs.python.org  Tue Jun 24 17:04:50 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Jun 2014 15:04:50 +0000
Subject: [docs] [issue12622] failfast argument to TextTestRunner not
	documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1403622290.93.0.452103379865.issue12622@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Slipped under the radar?

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

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

From report at bugs.python.org  Tue Jun 24 17:45:26 2014
From: report at bugs.python.org (Claudiu Popa)
Date: Tue, 24 Jun 2014 15:45:26 +0000
Subject: [docs] [issue12622] failfast argument to TextTestRunner not
	documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1403624726.22.0.0110398978701.issue12622@psf.upfronthosting.co.za>


Claudiu Popa added the comment:

Mark, why not contributing a patch? Seems pretty straight forward to write it.

----------
nosy: +Claudiu.Popa

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

From report at bugs.python.org  Tue Jun 24 18:19:14 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jun 2014 16:19:14 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <1403626754.66.0.787678742186.issue15588@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, that's a good catch.  For a keyword argument, we generally do mention the default value in the text, and it looks like we still should in that instance, especially since it *is* different that it is a keyword argument and not positional like the method to which the text is giving a back-reference.

----------

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

From report at bugs.python.org  Tue Jun 24 22:04:00 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jun 2014 20:04:00 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <3gydjW4ms8z7Ll9@mail.python.org>


Roundup Robot added the comment:

New changeset 8e5e04a1497f by Raymond Hettinger in branch '3.4':
Issue #11974:  Add tutorial section on class and instance variables
http://hg.python.org/cpython/rev/8e5e04a1497f

----------

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

From report at bugs.python.org  Tue Jun 24 22:05:10 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jun 2014 20:05:10 +0000
Subject: [docs] [issue11974] Class definition gotcha.. should this be
	documented	somewhere?
In-Reply-To: <1304274889.3.0.162053692496.issue11974@psf.upfronthosting.co.za>
Message-ID: <1403640310.3.0.164144265435.issue11974@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.

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

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

From report at bugs.python.org  Tue Jun 24 22:09:45 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Jun 2014 20:09:45 +0000
Subject: [docs] [issue12842] Docs: first parameter of tp_richcompare()
	always has the	correct type
In-Reply-To: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>
Message-ID: <1403640585.14.0.634004668104.issue12842@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The patch has never been applied.  I'm not qualified to state whether or not it is correct.

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

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

From report at bugs.python.org  Tue Jun 24 22:28:07 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 24 Jun 2014 20:28:07 +0000
Subject: [docs] [issue12887] Documenting all SO_* constants in socket module
In-Reply-To: <1314987180.49.0.607596056761.issue12887@psf.upfronthosting.co.za>
Message-ID: <1403641687.7.0.108318346626.issue12887@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Sandro do you want to follow this up?  msg142613 was on #12781.

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

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

From report at bugs.python.org  Wed Jun 25 01:41:00 2014
From: report at bugs.python.org (Peibolvig)
Date: Tue, 24 Jun 2014 23:41:00 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
Message-ID: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>


New submission from Peibolvig:

At point 9.8 of the 3.4.1 version documentation, ( https://docs.python.org/3/tutorial/classes.html#exceptions-are-classes-too ), there is an example of two ways to use the 'raise' statement:
raise Class
raise Instance

The next two lines, state: 
"In the first form, Class must be an instance of type or of a class derived from it. The first form is a shorthand for: raise Class()"

That only says something about the first form twice.
I think that the correct way would be:
"In the first form, Class must be an instance of type or of a class derived from it. The SECOND form is a shorthand for: raise Class()"

----------
assignee: docs at python
components: Documentation
messages: 221511
nosy: Peibolvig, docs at python
priority: normal
severity: normal
status: open
title: Error in documentation of point 9.8 'Exceptions are classes too'
versions: Python 3.4

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

From report at bugs.python.org  Wed Jun 25 02:09:24 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 25 Jun 2014 00:09:24 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1403654964.4.0.200831465732.issue21864@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

No. The first form, raise Class, is in fact a shorthand for raise Class(). That's the point. You only actually raise instances, but if you pass it a class directly, it instantiates it by calling its constructor with no arguments. The second form is not described explicitly, but the example shows it in use. An instance of an Exception class is explicitly created.

----------
nosy: +josh.rosenberg

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

From report at bugs.python.org  Wed Jun 25 02:25:29 2014
From: report at bugs.python.org (Peibolvig)
Date: Wed, 25 Jun 2014 00:25:29 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1403655929.1.0.25131704722.issue21864@psf.upfronthosting.co.za>


Peibolvig added the comment:

Oh, I see. Thanks for the clarification.

May I suggest to include that clarification into the documentation somehow? I think it would be easier to understand the point of the raises doing that.

Maybe this suggestion could fit:
In the first form, Class must be an instance of type or of a class derived from it. The first form is a shorthand for:
raise Class()
"'raise' will always use an instance. If a class is passed instead of an instance, it will instantiate it first using the constructor with no arguments."


Again, thanks for the clarification.

----------

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

From report at bugs.python.org  Wed Jun 25 03:19:07 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 25 Jun 2014 01:19:07 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1403659147.9.0.584799509329.issue21864@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I think the section could use some additional rewording actually. The wording about deriving from type dates back to the Python 2 days; nowadays, all exceptions are actually required to derive from BaseException. The section definitely needs rewording.

----------

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

From report at bugs.python.org  Wed Jun 25 05:39:05 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jun 2014 03:39:05 +0000
Subject: [docs] [issue21441] Buffer Protocol Documentation Error
In-Reply-To: <1399314483.29.0.410069597608.issue21441@psf.upfronthosting.co.za>
Message-ID: <3gyqpc5MGfz7Ljx@mail.python.org>


Roundup Robot added the comment:

New changeset 92d691c3ca00 by Jesus Cea in branch '3.3':
Closes #21441: Reorder elements in documentation to match actual order in the code
http://hg.python.org/cpython/rev/92d691c3ca00

New changeset d9da4b77624b by Jesus Cea in branch '3.4':
MERGE: Closes #21441: Reorder elements in documentation to match actual order in the code
http://hg.python.org/cpython/rev/d9da4b77624b

New changeset 5e6c4070a785 by Jesus Cea in branch 'default':
MERGE: Closes #21441: Reorder elements in documentation to match actual order in the code
http://hg.python.org/cpython/rev/5e6c4070a785

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

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

From report at bugs.python.org  Wed Jun 25 05:39:59 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 25 Jun 2014 03:39:59 +0000
Subject: [docs] [issue21441] Buffer Protocol Documentation Error
In-Reply-To: <1399314483.29.0.410069597608.issue21441@psf.upfronthosting.co.za>
Message-ID: <1403667599.22.0.876428540751.issue21441@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Thanks, Jake.

----------
nosy: +jcea

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

From report at bugs.python.org  Wed Jun 25 09:54:34 2014
From: report at bugs.python.org (IronGrid)
Date: Wed, 25 Jun 2014 07:54:34 +0000
Subject: [docs] [issue18669] curses.chgat() moves cursor,
	documentation says it shouldn't
In-Reply-To: <1375800170.73.0.20062232661.issue18669@psf.upfronthosting.co.za>
Message-ID: <1403682874.73.0.59960898758.issue18669@psf.upfronthosting.co.za>


IronGrid added the comment:

I get this error with 3.2.3, running Debian Stable.

It's annoying because this error prevents curses apps from being able to highlight the current line.

----------
nosy: +IronGrid
versions: +Python 3.2

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

From report at bugs.python.org  Wed Jun 25 10:13:27 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jun 2014 08:13:27 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <3gyxvB5mmJz7Ljf@mail.python.org>


Roundup Robot added the comment:

New changeset b4130b2f7748 by Senthil Kumaran in branch 'default':
merge from 3.4
http://hg.python.org/cpython/rev/b4130b2f7748

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

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

From report at bugs.python.org  Wed Jun 25 10:14:51 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 25 Jun 2014 08:14:51 +0000
Subject: [docs] [issue15588] quopri: encodestring and decodestring handle
	bytes, not strings
In-Reply-To: <1344411059.45.0.404148694214.issue15588@psf.upfronthosting.co.za>
Message-ID: <1403684091.4.0.714900881028.issue15588@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the review, Mark. Addressed that and committed the changes in changeset 606a18938476 (3.4)
changeset b4130b2f7748 (3.5)

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 25 13:06:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jun 2014 11:06:51 +0000
Subject: [docs] [issue20872] dbm/gdbm/ndbm close methods are not document
In-Reply-To: <1394297879.28.0.882591650164.issue20872@psf.upfronthosting.co.za>
Message-ID: <3gz1lG4N7Cz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset de44bc26a00a by Jesus Cea in branch '2.7':
Closes #20872: dbm/gdbm/ndbm close methods are not documented
http://hg.python.org/cpython/rev/de44bc26a00a

New changeset cf156cfb12e7 by Jesus Cea in branch '3.3':
Closes #20872: dbm/gdbm/ndbm close methods are not documented
http://hg.python.org/cpython/rev/cf156cfb12e7

New changeset 88fb216b99fb by Jesus Cea in branch '3.4':
MERGE: Closes #20872: dbm/gdbm/ndbm close methods are not documented
http://hg.python.org/cpython/rev/88fb216b99fb

New changeset 90dd9eec1230 by Jesus Cea in branch 'default':
MERGE: Closes #20872: dbm/gdbm/ndbm close methods are not documented
http://hg.python.org/cpython/rev/90dd9eec1230

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

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

From report at bugs.python.org  Wed Jun 25 13:08:07 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 25 Jun 2014 11:08:07 +0000
Subject: [docs] [issue20872] dbm/gdbm/ndbm close methods are not document
In-Reply-To: <1394297879.28.0.882591650164.issue20872@psf.upfronthosting.co.za>
Message-ID: <1403694487.59.0.290485428464.issue20872@psf.upfronthosting.co.za>


Jes?s Cea Avi?n added the comment:

Thanks, David and Berker.

----------
nosy: +jcea

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

From report at bugs.python.org  Wed Jun 25 14:04:03 2014
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 25 Jun 2014 12:04:03 +0000
Subject: [docs] [issue21778] PyBuffer_FillInfo() from 3.3
In-Reply-To: <1402927404.66.0.0840543943961.issue21778@psf.upfronthosting.co.za>
Message-ID: <1403697843.31.0.64401570816.issue21778@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From electro.adrix at gmail.com  Mon Jun 23 18:21:51 2014
From: electro.adrix at gmail.com (Adrix Remi)
Date: Mon, 23 Jun 2014 18:21:51 +0200
Subject: [docs] Issue in urllib2 doc for python 3.0 to 3.?
Message-ID: <CALQPeFC0TT=9BBr0iOn2WFD-ArdpVE2yZ9rfAJt-AjDJdBZRBg@mail.gmail.com>

The issue is in the Handling Exeption
<https://docs.python.org/3.2/howto/urllib2.html#handling-exceptions> part
and more precisely in the last example
<https://docs.python.org/3.2/howto/urllib2.html#number-2>.

The order of the exception catching part is false:
It's like that in the doc :
------------------------------
from urllib.request import Request, urlopen
from urllib.error import  URLError
req = Request(someurl)
try:
    response = urlopen(req)
except URLError as e:
    if hasattr(e, 'reason'):
        print('We failed to reach a server.') # URLError handling
        print('Reason: ', e.reason)
    elif hasattr(e, 'code'):
        print('The server couldn\'t fulfill the request.') # HTTPError
handling
        print('Error code: ', e.code)
else:
    # everything is fine
------------------------------

and the correct order is :
------------------------------
from urllib.request import Request, urlopen
from urllib.error import  URLError
req = Request(someurl)
try:
    response = urlopen(req)
except URLError as e:
    if hasattr(e, 'code'):
        print('The server couldn\'t fulfill the request.') # HTTPError
handling
        print('Error code: ', e.code)
    elif hasattr(e, 'reason'):
        print('We failed to reach a server.') # URLError handling
        print('Reason: ', e.reason)
else:
    # everything is fine
------------------------------

Because, just as explained over the example (in the doc), if the URLError
handling comes first it will also catch the HTTPError.

I hope I'm clear enough

Have a nice day :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140623/637ca506/attachment.html>

From xmichaelm at gmail.com  Tue Jun 24 15:11:06 2014
From: xmichaelm at gmail.com (Michael Mumcuoglu)
Date: Tue, 24 Jun 2014 16:11:06 +0300
Subject: [docs] datetime documentation bug
Message-ID: <CAFHU4kt9wQW9D4HsEgRBzKN5LpyzQb9RupWYr0m08xfaDYSzyQ@mail.gmail.com>

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

%X example for (en_US) is wrong. It should be "09:30:00 PM"

> python
>>> import locale; locale.setlocale(locale.LC_ALL, 'en_US.utf8')
>>> import datetime; print datetime.datetime.now().strftime('%x %X')
06/24/2014 04:07:18 PM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140624/3182a43f/attachment.html>

From senthil at uthcode.com  Wed Jun 25 23:08:48 2014
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 25 Jun 2014 14:08:48 -0700
Subject: [docs] Issue in urllib2 doc for python 3.0 to 3.?
In-Reply-To: <CALQPeFC0TT=9BBr0iOn2WFD-ArdpVE2yZ9rfAJt-AjDJdBZRBg@mail.gmail.com>
References: <CALQPeFC0TT=9BBr0iOn2WFD-ArdpVE2yZ9rfAJt-AjDJdBZRBg@mail.gmail.com>
Message-ID: <CAPOVWOS6-_0B4rTddEY4iezzdrV6Vfc7qf8pq1_9srCed0GC6g@mail.gmail.com>

Hello Adrix,

The tutorial mentions about Exception hierarchy and URLError catches
HTTPError exception too.
Once that is caught as e, you can refer to the attributes e.code and
e.reason.

So the current example is good as it is.

Thanks!
Senthil

On Mon, Jun 23, 2014 at 9:21 AM, Adrix Remi <electro.adrix at gmail.com> wrote:

> try:
>     response = urlopen(req)
> except URLError as e:
>     if hasattr(e, 'code'):
>         print('The server couldn\'t fulfill the request.') # HTTPError
> handling
>         print('Error code: ', e.code)
>     elif hasattr(e, 'reason'):
>         print('We failed to reach a server.') # URLError handling
>         print('Reason: ', e.reason)
> else:
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140625/eebed020/attachment-0001.html>

From report at bugs.python.org  Wed Jun 25 23:38:30 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 25 Jun 2014 21:38:30 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1403732310.26.0.068814647402.issue12954@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@paul j3 can you prepare a patch for this?

----------
nosy: +BreamoreBoy
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 26 00:36:38 2014
From: report at bugs.python.org (paul j3)
Date: Wed, 25 Jun 2014 22:36:38 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1403735798.6.0.146992943438.issue12954@psf.upfronthosting.co.za>


paul j3 added the comment:

It will take a while to reconstruct the circumstances behind this issue.  I think I was working through some online class examples, working in the Eclipse pydev environment.  Currently I'm mostly working in linux, and not doing much with multiprocessing.  Looks like most, if not all, the examples are already protected with the 'if __name__' clause.

----------

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

From report at bugs.python.org  Thu Jun 26 01:42:06 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 25 Jun 2014 23:42:06 +0000
Subject: [docs] [issue13074] Improve documentation of locale encoding
	functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1403739726.82.0.173416826125.issue13074@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Hopefully the patch speaks for itself.

----------
keywords: +patch
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file35782/Issue13074.diff

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

From report at bugs.python.org  Thu Jun 26 01:49:45 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 25 Jun 2014 23:49:45 +0000
Subject: [docs] [issue13213] generator.throw() behavior
In-Reply-To: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za>
Message-ID: <1403740185.19.0.043227433041.issue13213@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Petri can you propose a patch for this?

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

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

From report at bugs.python.org  Thu Jun 26 09:51:33 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 26 Jun 2014 07:51:33 +0000
Subject: [docs] [issue13074] Improve documentation of locale encoding
	functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1403769093.08.0.0315613941513.issue13074@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The two functions serve a different purpose.

getdefautltlocale() specifically avoids calling setlocale() and is thread-safe on Unix. It's purpose is to return the default locale string, not only the encoding.

getpreferredencoding() only returns the encoding, but on Unix has to call setlocale() to return correct results and thus is not thread-safe.

Martin's comment doesn't address this difference and I don't agree with it.

Regarding the different results, I guess this could be solved by having both function pass the data obtained from the system through _parse_localname() before returning it, but that would have to be a handled in a new issue report.

----------

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

From report at bugs.python.org  Thu Jun 26 16:33:10 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Jun 2014 14:33:10 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1403793190.5.0.475161701823.issue21864@psf.upfronthosting.co.za>


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


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

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

From andresdavidsoto at gmail.com  Thu Jun 26 02:42:04 2014
From: andresdavidsoto at gmail.com (=?UTF-8?B?QW5kcsOpcyBTb3Rv?=)
Date: Wed, 25 Jun 2014 19:42:04 -0500
Subject: [docs] Bug
Message-ID: <CABmZAwESCWEqQmeYn46Kr0J73Un_dOdBjnk7ejxTFV7oJZFC5A@mail.gmail.com>

I am on python 2.7.6 and my program does not run for a SyntaxError: invalid
syntax with no reason
if e == 1:
 print "Escudo: Tabla de madera. Usos:",eus
elif e == 2:
 print("Escudo: Escudo de madera. Usos:",eus
elif e == 3:
 print("Escudo: Escudo de piedra. Usos:",eus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140625/5a64c311/attachment.html>

From michael.sasser at sassernet.de  Thu Jun 26 05:48:44 2014
From: michael.sasser at sassernet.de (Michael Sasser)
Date: Thu, 26 Jun 2014 05:48:44 +0200
Subject: [docs] Docs: Little fault in shutil documentation
Message-ID: <CAFY5E7D-=5ms9YncvMB7VzBYVfrAkDqP3eBRridM_gfh+P0CUw@mail.gmail.com>

Hi,

since Python 3.3 the exception of shutil.copyfile() has been changed
from IOError to OSError. You need to correct this part of the
description in Version 3.3, 3.4 and 3.5:

[...]
Changed in version 3.3: IOError used to be raised instead of OSError.
Added follow_symlinks argument. Now returns dst.
[...]

From zachary.ware+pydocs at gmail.com  Thu Jun 26 19:00:51 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 26 Jun 2014 12:00:51 -0500
Subject: [docs] Bug
In-Reply-To: <CABmZAwESCWEqQmeYn46Kr0J73Un_dOdBjnk7ejxTFV7oJZFC5A@mail.gmail.com>
References: <CABmZAwESCWEqQmeYn46Kr0J73Un_dOdBjnk7ejxTFV7oJZFC5A@mail.gmail.com>
Message-ID: <CAKJDb-Nnq8rJbwQVvhT-jTjqCALTP5_thZWBYdabT5Q6Z1bxsQ@mail.gmail.com>

Hi Andr?s,

First off, this in not the proper venue for usage questions like this.
This list is meant for discussion or bug reports about the Python
documentation.  You would be better served to ask on
python-list at python.org, which is intended for any discussion
pertaining to Python or its usage.

That said...

2014-06-25 19:42 GMT-05:00 Andr?s Soto <andresdavidsoto at gmail.com>:
> I am on python 2.7.6 and my program does not run for a SyntaxError: invalid
> syntax with no reason
> if e == 1:
>  print "Escudo: Tabla de madera. Usos:",eus
> elif e == 2:
>  print("Escudo: Escudo de madera. Usos:",eus

You have an open parenthesis on this line, but no close parenthesis.
Since you're using Python 2.7, you can leave off the parentheses, or
use them, but you can't go half-way :).  I would suggest either using
the parentheses anyway for forward-compatibility with Python 3, but
the choice is yours.  Note that there is also the "from __future__
import print_function" directive which can make forward-compatibility
even better (and easier).

> elif e == 3:
>  print("Escudo: Escudo de piedra. Usos:",eus

And when you fix the line above, this one has the same issue.

I hope this helps, and if you have any follow-up questions, please
forward them to python-list.

Regards,
-- 
Zach

From zachary.ware+pydocs at gmail.com  Thu Jun 26 19:06:12 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 26 Jun 2014 12:06:12 -0500
Subject: [docs] Docs: Little fault in shutil documentation
In-Reply-To: <CAFY5E7D-=5ms9YncvMB7VzBYVfrAkDqP3eBRridM_gfh+P0CUw@mail.gmail.com>
References: <CAFY5E7D-=5ms9YncvMB7VzBYVfrAkDqP3eBRridM_gfh+P0CUw@mail.gmail.com>
Message-ID: <CAKJDb-Nng-GxsYwT0ZbJ7HxM++mhOnY5ikoZ+o5jv_LCW_McWw@mail.gmail.com>

Hi Michael,

On Wed, Jun 25, 2014 at 10:48 PM, Michael Sasser
<michael.sasser at sassernet.de> wrote:
> Hi,
>
> since Python 3.3 the exception of shutil.copyfile() has been changed
> from IOError to OSError. You need to correct this part of the
> description in Version 3.3, 3.4 and 3.5:
>
> [...]
> Changed in version 3.3: IOError used to be raised instead of OSError.
> Added follow_symlinks argument. Now returns dst.
> [...]

I apologize, but I don't understand your request; the part of the docs
that you quoted already says that OSError is now raised instead of
IOError (although, in reality, both are the same Exception now).  It
would not take much to convince me that there is a better wording for
that note, though; is that what you were going for?

Regards,
-- 
Zach

From report at bugs.python.org  Thu Jun 26 19:42:43 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 26 Jun 2014 17:42:43 +0000
Subject: [docs] [issue8387] use universal newline mode in csv module examples
In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>
Message-ID: <1403804563.7.0.0592724826595.issue8387@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@sfinnie can we please have a response to the question first asked by Antoine and repeated by Jessica, thanks.

----------

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

From report at bugs.python.org  Thu Jun 26 20:48:07 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Jun 2014 18:48:07 +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: <1403808487.54.0.0710883023844.issue20351@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
versions:  -Python 3.3

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

From report at bugs.python.org  Thu Jun 26 20:52:58 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Jun 2014 18:52:58 +0000
Subject: [docs] [issue21746] urlparse.BaseResult no longer exists
In-Reply-To: <1402650592.68.0.838750531809.issue21746@psf.upfronthosting.co.za>
Message-ID: <1403808778.07.0.977157568509.issue21746@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag, orsenthil

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

From report at bugs.python.org  Thu Jun 26 22:30:04 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jun 2014 20:30:04 +0000
Subject: [docs] [issue19897] Use python as executable instead of python3 in
	Python 2	docs
Message-ID: <3gztBg5ZHnz7Ljf@mail.python.org>


New submission from Roundup Robot:

New changeset eb0921b2100b by Berker Peksag in branch '2.7':
Issue #19897: Use python as executable instead of python3.
http://hg.python.org/cpython/rev/eb0921b2100b

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

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

From report at bugs.python.org  Thu Jun 26 22:31:39 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 26 Jun 2014 20:31:39 +0000
Subject: [docs] [issue19897] Use python as executable instead of python3 in
	Python 2	docs
In-Reply-To: <3gztBg5ZHnz7Ljf@mail.python.org>
Message-ID: <1403814699.78.0.71982300288.issue19897@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Fri Jun 27 04:23:36 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Fri, 27 Jun 2014 02:23:36 +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: <1403835816.57.0.730830174027.issue20351@psf.upfronthosting.co.za>


Charles-Axel Dein added the comment:

Updated patch following review.

----------
Added file: http://bugs.python.org/file35790/add_csvdict_examples.patch

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

From report at bugs.python.org  Fri Jun 27 06:25:17 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Jun 2014 04:25:17 +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: <1403843117.29.0.49151783304.issue20351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun 27 21:29:54 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jun 2014 19:29:54 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
	are	classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1403897394.68.0.484780488018.issue21864@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The preceding sentence "There are two new valid (semantic) forms for the raise statement" is obsolete also as there is no other form (other than 'raise', which should not be in the tutorial previously). To rewrite this section for 3.x would require looking at what has already been said about exceptions and raise. It seems to have been written for ancient python where raise 'somestring' was the norm.

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

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

From report at bugs.python.org  Fri Jun 27 22:54:38 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 27 Jun 2014 20:54:38 +0000
Subject: [docs] [issue11385] TextTestRunner methods are not documented
In-Reply-To: <1299176734.52.0.359265322214.issue11385@psf.upfronthosting.co.za>
Message-ID: <1403902478.05.0.265962172711.issue11385@psf.upfronthosting.co.za>


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


----------
type:  -> behavior
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jun 27 22:56:05 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 27 Jun 2014 20:56:05 +0000
Subject: [docs] [issue11389] unittest: no way to control verbosity of
	doctests from	cmd
In-Reply-To: <1299182245.29.0.387603597674.issue11389@psf.upfronthosting.co.za>
Message-ID: <1403902565.28.0.475507996476.issue11389@psf.upfronthosting.co.za>


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


----------
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Jun 28 02:03:38 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 Jun 2014 00:03:38 +0000
Subject: [docs] [issue20961] Fix usages of the note directive in the
	documentation
In-Reply-To: <1395066655.93.0.683819910553.issue20961@psf.upfronthosting.co.za>
Message-ID: <1403913818.59.0.461933699895.issue20961@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

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

From berker.peksag at gmail.com  Sat Jun 28 02:20:17 2014
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sat, 28 Jun 2014 03:20:17 +0300
Subject: [docs] Typo in urllib2 docs
In-Reply-To: <CACekEaV-7JzUmK8_98k=NbOXnC-3--vBdAowM6Z2mPyKFhA6qw@mail.gmail.com>
References: <CACekEaV-7JzUmK8_98k=NbOXnC-3--vBdAowM6Z2mPyKFhA6qw@mail.gmail.com>
Message-ID: <CAF4280LgRavJV7L9sZQTM67F28GBGzY7=BAA8mc652gpTPCcsw@mail.gmail.com>

On Fri, Dec 27, 2013 at 3:49 AM, Dmitry Chaplinsky
<chaplinsky.dmitry at gmail.com> wrote:
> http://docs.python.org/2/library/urllib2.html
>
> This function returns a file-like object with two additional methods:
>
> geturl() ? return the URL of the resource retrieved, commonly used to
> determine if a redirect was followed
> info() ? return the meta-information of the page, such as headers, in the
> form of an mimetools.Message instance (see Quick Reference to HTTP Headers)
> getcode() ? return the HTTP status code of the response.
>
> docs says about two methods but 3 are listed.

Hi Dmitry,

Thanks for the report. This has been fixed.

http://hg.python.org/cpython/rev/8552f3031753

--Berker

>
> WBR, Dmitry
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>

From report at bugs.python.org  Sat Jun 28 03:01:47 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 Jun 2014 01:01:47 +0000
Subject: [docs] [issue11165] Document PyEval_Call* functions
In-Reply-To: <1297292171.0.0.0899611103523.issue11165@psf.upfronthosting.co.za>
Message-ID: <1403917307.75.0.763779239172.issue11165@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Nick I assume that this still needs doing.  msg128249 says you've removed the easy tag but it still shows in the keywords list.

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

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

From report at bugs.python.org  Sat Jun 28 04:05:40 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 Jun 2014 02:05:40 +0000
Subject: [docs] [issue13277] tzinfo subclasses information
In-Reply-To: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>
Message-ID: <1403921140.8.0.875899522475.issue13277@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I don't understand the implications of timezone stuff at all so can a guru on the subject please comment on this.

----------
nosy: +BreamoreBoy
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Jun 28 04:26:14 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 28 Jun 2014 02:26:14 +0000
Subject: [docs] [issue13277] tzinfo subclasses information
In-Reply-To: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>
Message-ID: <1403922373.99.0.523906103891.issue13277@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I would say this is a doc issue.  There are some tzinfo algorithms that depend on utcoffset(dt)-dst(dt) being invariant, but this is the part of datetime library that I have never fully understood.

What I do understand is that conversion from local time to UTC or another timezone is a hard and not always solvable problem (some local times are invalid and some are ambiguous).  (If some local government decides that 00:59 should be followed by 02:00, one is hard pressed to figure out what 01:30 local time is in UTC.)

I think documentation should emphasize the fact that the standard library only supports fixed offset timezones.  It is up to the application programmer or a 3rd party library to figure out which fixed offset is appropriate in which case.

----------
components: +Documentation
nosy: +tim.peters

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

From report at bugs.python.org  Sat Jun 28 15:32:35 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 Jun 2014 13:32:35 +0000
Subject: [docs] [issue13354] tcpserver should document non-threaded
	long-living	connections
In-Reply-To: <1320570611.72.0.286817751979.issue13354@psf.upfronthosting.co.za>
Message-ID: <1403962355.49.0.453776484157.issue13354@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Am I barking up the wrong tree, or should the docs now refer to the new asyncio module aka Tulip when mentioning "asynchronous behaviour"?

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

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

From report at bugs.python.org  Sat Jun 28 16:12:58 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 Jun 2014 14:12:58 +0000
Subject: [docs] [issue13421] PyCFunction_* are not documented anywhere
In-Reply-To: <1321553683.63.0.825049607384.issue13421@psf.upfronthosting.co.za>
Message-ID: <1403964778.0.0.529504177641.issue13421@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

ping.

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

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

From report at bugs.python.org  Sat Jun 28 20:21:36 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 Jun 2014 18:21:36 +0000
Subject: [docs] [issue13456] Providing a custom HTTPResponse class to
	HTTPConnection
In-Reply-To: <1321988533.96.0.72454390842.issue13456@psf.upfronthosting.co.za>
Message-ID: <1403979696.65.0.0188640078188.issue13456@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

ping.

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

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

From report at bugs.python.org  Sun Jun 29 11:12:09 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jun 2014 09:12:09 +0000
Subject: [docs] [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1404033129.44.0.292126458168.issue18588@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I tried to run those timings again and the values I got from the terminal are close to the ones I got from the interactive interpreter.
I'm not sure why when I wrote those examples I got such different values.
It would be fine with me to update them and avoid confusion.

> In command-line invocation the gc is disabled.
> And timit.repeat() is used instead of timit.timit().

Looking at the current code it seems to me that the command-line uses timeit.repeat(), that repeat calls timeit.timeit(), and that timeit.timeit() disables the gc.  Maybe back then it was different; that would explain why I got different results.

----------

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

From report at bugs.python.org  Sun Jun 29 12:07:59 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jun 2014 10:07:59 +0000
Subject: [docs] [issue21575] list.sort() should show arguments in tutorial
In-Reply-To: <1401021385.55.0.784639264396.issue21575@psf.upfronthosting.co.za>
Message-ID: <1404036479.7.0.171575187585.issue21575@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved
type:  -> enhancement

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

From report at bugs.python.org  Sun Jun 29 12:22:25 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jun 2014 10:22:25 +0000
Subject: [docs] [issue16701] Docs missing the behavior of += (in-place add)
	for lists.
In-Reply-To: <1355690474.0.0.76209480062.issue16701@psf.upfronthosting.co.za>
Message-ID: <1404037345.6.0.808665975662.issue16701@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jun 29 12:23:07 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 29 Jun 2014 10:23:07 +0000
Subject: [docs] [issue21358] Augmented assignment doc: clarify 'only
	evaluated once'
In-Reply-To: <1398544739.49.0.840910165962.issue21358@psf.upfronthosting.co.za>
Message-ID: <1404037387.7.0.314571754897.issue21358@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/issue21358>
_______________________________________

From report at bugs.python.org  Sun Jun 29 15:32:27 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 29 Jun 2014 13:32:27 +0000
Subject: [docs] [issue14547] Python symlink to script behaves unexpectedly
In-Reply-To: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za>
Message-ID: <1404048747.2.0.937600189526.issue14547@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I've removed Tests from the components list as I don't think it belongs there.

----------
components:  -Tests
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun 29 20:08:31 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 29 Jun 2014 18:08:31 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1404065311.76.0.0156115092861.issue15243@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Does the documentation need amending, yes or no?

----------
components:  -Tests
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jun 29 20:45:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 29 Jun 2014 18:45:04 +0000
Subject: [docs] [issue13649] termios.ICANON is not documented
In-Reply-To: <1324566585.96.0.744911903947.issue13649@psf.upfronthosting.co.za>
Message-ID: <1404067504.72.0.421876522953.issue13649@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm inclined to close as "won't fix" as the third paragraph of the docs states "This module also defines all the constants needed to work with the functions provided here; these have the same name as their counterparts in C. Please refer to your system documentation for more information on using these terminal control interfaces."

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

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

From report at bugs.python.org  Mon Jun 30 00:17:00 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jun 2014 22:17:00 +0000
Subject: [docs] [issue21778] PyBuffer_FillInfo() from 3.3
In-Reply-To: <1402927404.66.0.0840543943961.issue21778@psf.upfronthosting.co.za>
Message-ID: <3h1mQg1mLZz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 49cdb04bfcc6 by Stefan Krah in branch '3.4':
Issue #21778:  Clarify use of flags if PyBuffer_FillInfo() is used inside a
http://hg.python.org/cpython/rev/49cdb04bfcc6

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

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

From report at bugs.python.org  Mon Jun 30 00:18:22 2014
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 29 Jun 2014 22:18:22 +0000
Subject: [docs] [issue21778] PyBuffer_FillInfo() from 3.3
In-Reply-To: <1402927404.66.0.0840543943961.issue21778@psf.upfronthosting.co.za>
Message-ID: <1404080302.86.0.580342622564.issue21778@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


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

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

From report at bugs.python.org  Mon Jun 30 00:43:00 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Jun 2014 22:43:00 +0000
Subject: [docs] [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1404081780.26.0.974000620872.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

MODULE DOCS section is no longer present in pydoc generated pages.

----------
resolution: accepted -> out of date
status: open -> closed

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

From report at bugs.python.org  Mon Jun 30 00:54:33 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Jun 2014 22:54:33 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1404082473.47.0.660897667748.issue7229@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

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

From report at bugs.python.org  Mon Jun 30 01:23:39 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Jun 2014 23:23:39 +0000
Subject: [docs] [issue8810] TZ offset description is unclear in docs
In-Reply-To: <1274718021.16.0.883294684947.issue8810@psf.upfronthosting.co.za>
Message-ID: <1404084219.69.0.71392416179.issue8810@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Isn't this a duplicate of #9305?

----------
assignee: belopolsky -> 
versions: +Python 3.5 -Python 3.2

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

From report at bugs.python.org  Mon Jun 30 01:26:34 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Jun 2014 23:26:34 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1404084394.37.0.454897865991.issue9305@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


----------
dependencies: +Don't use east/west of UTC in date/time documentation

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

From report at bugs.python.org  Mon Jun 30 01:28:03 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 29 Jun 2014 23:28:03 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1404084483.49.0.451932417033.issue9305@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

This seems to be touching the same areas as #9305.

----------
assignee: belopolsky -> 

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

From report at bugs.python.org  Mon Jun 30 05:36:47 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Jun 2014 03:36:47 +0000
Subject: [docs] [issue7229] Manual entry for time.daylight can be misleading
In-Reply-To: <1256723052.19.0.148648938954.issue7229@psf.upfronthosting.co.za>
Message-ID: <1404099407.47.0.358552989687.issue7229@psf.upfronthosting.co.za>


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


----------
stage: patch review -> resolved

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

From berker.peksag at gmail.com  Mon Jun 30 10:32:08 2014
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 30 Jun 2014 11:32:08 +0300
Subject: [docs] Documentation error in function getaddrinfo in socket
	module
In-Reply-To: <1363119201.10987.YahooMailNeo@web120202.mail.ne1.yahoo.com>
References: <1363119201.10987.YahooMailNeo@web120202.mail.ne1.yahoo.com>
Message-ID: <CAF4280K7U4PQ2WdB7QAqkMynCGrqCVb3kQK2bsj2XuVj8_Wwvw@mail.gmail.com>

On Tue, Mar 12, 2013 at 10:13 PM, Krishna Kumar Thakur
<krishnak.thakur at yahoo.com> wrote:
>
>  Hi,
>
> python version : 3.3.0
>
> Description : getaddrinfo() function expecting 'type' as the keyword
> argument but
> the function documentation says 'socktype' .
>
> please see the below output
>>>> help(getaddrinfo)
> Help on built-in function getaddrinfo in module _socket:
>
> getaddrinfo(...)
>     getaddrinfo(host, port [, family, socktype, proto, flags])
>         -> list of (family, socktype, proto, canonname, sockaddr)
>
>>>> getaddrinfo.__doc__
> 'getaddrinfo(host, port [, family, socktype, proto, flags])\n    -> list of
> (family, socktype, proto, canonname, sockaddr)\n\nResolve host and port into
> addrinfo struct.'
>
> so if the function is called
>>>> i = getaddrinfo('www.python.org','http',socktype = SOCK_STREAM)
> Traceback (most recent call last):
>   File "<pyshell#20>", line 1, in <module>
>     i = getaddrinfo('www.python.org','http',socktype = SOCK_STREAM)
> TypeError: 'socktype' is an invalid keyword argument for this function
>
> then I have found the correct keyword argument as 'type' in python 3.3
> official documentation.
> Its not the major issue but sometimes it confuses.
>
> As I appreciate python, so I felt its my duty to help make this language
> error free
> as much as possible. :)

Hi,

Fixed. Thanks for the report!

--Berker

>
> ________________________________
> Thank You
>
> Krishna Kumar Thakur
> Contact: +91-7411251885
> E_mail: krishnak.thakur at yahoo.com
>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

From report at bugs.python.org  Mon Jun 30 10:51:12 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Jun 2014 08:51:12 +0000
Subject: [docs] [issue11762] Ast doc: warning and version number
In-Reply-To: <1301933761.05.0.937546235723.issue11762@psf.upfronthosting.co.za>
Message-ID: <1404118272.88.0.824591622055.issue11762@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> 1. Add a warning similar to the one for the dis module.

The current documentation says:

    "The abstract syntax itself might change with each Python release; [...]"

https://docs.python.org/3.4/library/ast.html

> 2. Add a full entry for __version__. Currently (3.2):

ast.__version__ has been removed in issue 12273.

Closing this as "out of date".

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Jun 30 20:15:02 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Jun 2014 18:15:02 +0000
Subject: [docs] [issue13231] sys.settrace - document 'some other code
	blocks' for	'call' event type
In-Reply-To: <1319096421.5.0.420840017987.issue13231@psf.upfronthosting.co.za>
Message-ID: <1404152102.43.0.97405943771.issue13231@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I find this request excessive.  The first sentence for sys.settrace states "Set the system?s trace function, which allows you to implement a Python source code debugger in Python".  I suspect that anyone wanting to write a debugger would know the Python and its documentation better than the back of their hand.  So I say close as "won't fix" but I wouldn't argue if anyone disagreed and wanted to provide a patch.

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

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

From report at bugs.python.org  Mon Jun 30 20:28:15 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Jun 2014 18:28:15 +0000
Subject: [docs] [issue13743] xml.dom.minidom.Document class is not documented
In-Reply-To: <1326114378.06.0.424770823698.issue13743@psf.upfronthosting.co.za>
Message-ID: <1404152895.26.0.932536913508.issue13743@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This https://docs.python.org/3/library/xml.dom.minidom.html#module-xml.dom.minidom currently states under section 20.7.1 "The definition of the DOM API for Python is given as part of the xml.dom module documentation. This section lists the differences between the API and xml.dom.minidom.".  The Document object is described here https://docs.python.org/3/library/xml.dom.html#document-objects

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

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

From report at bugs.python.org  Mon Jun 30 23:32:45 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 30 Jun 2014 21:32:45 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1404163965.05.0.062795088816.issue14787@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Note that this is reference from #15358.

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From ezio.melotti at gmail.com  Sun Jun 29 12:05:02 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 29 Jun 2014 10:05:02 -0000
Subject: [docs] Improve the "introduction" page of the tutorial (issue
	14097)
Message-ID: <20140629100502.2014.82221@psf.upfronthosting.co.za>

I added a few minor comments, otherwise the patch LGTM.


http://bugs.python.org/review/14097/diff/11998/Doc/tutorial/introduction.rst
File Doc/tutorial/introduction.rst (right):

http://bugs.python.org/review/14097/diff/11998/Doc/tutorial/introduction.rst#newcode68
Doc/tutorial/introduction.rst:68: remainders can be calculated with the
``%`` operator::
I would do s/, and remainders/. The remainder/
Also you could say "no matter what the types of the operands are".

http://bugs.python.org/review/14097/diff/11998/Doc/tutorial/introduction.rst#newcode70
Doc/tutorial/introduction.rst:70: >>> 17 / 3  # integer division returns
an int
Here you could say "# int / int -> int", and on the next line "int /
float -> float".
This emphasizes that the result depends on the input type, rather than
the names of the two types of divisions.

http://bugs.python.org/review/14097/diff/11998/Doc/tutorial/introduction.rst#newcode72
Doc/tutorial/introduction.rst:72: >>> 17 / 3.0 # classic division
returns a float
Two spaces before the #

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

From mike.brading at mike-brading.com  Mon Jun 30 11:30:25 2014
From: mike.brading at mike-brading.com (Mike Brading)
Date: Mon, 30 Jun 2014 10:30:25 +0100
Subject: [docs] python docs downloads at
	https://docs.python.org/2/download.html
Message-ID: <003c01cf9445$f9fc0090$edf401b0$@brading@mike-brading.com>

All download links seem to be broken. Please let me know when they are
fixed.

 

Thanks

 

Mike

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140630/941b7e2c/attachment-0001.html>

From tomnyberg at gmail.com  Mon Jun 30 12:05:56 2014
From: tomnyberg at gmail.com (Thomas Nyberg)
Date: Mon, 30 Jun 2014 18:05:56 +0800
Subject: [docs] Broken docs links
Message-ID: <53B13684.7040004@gmail.com>

None of the links on this site appear to be working:

https://docs.python.org/2.7/download.html

Cheers,
Thomas

From vo.on3z at gmail.com  Mon Jun 30 12:14:46 2014
From: vo.on3z at gmail.com (Vladimir Linevich)
Date: Mon, 30 Jun 2014 13:14:46 +0300
Subject: [docs] 404 on 2.7 docs
Message-ID: <CANEy+hKSVQUofoh9x-iC6B6axfWZXonEP5Pj-Ubz6u+vfxeBNw@mail.gmail.com>

Hi guys!

Looks like there are no 2.7 docs archives available for download here
<https://docs.python.org/2.7/download.html>.
Please fix it when you have time.

Thanks a lot,
Volodymyr.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140630/e96a6f5c/attachment.html>

From echoquote at gmail.com  Mon Jun 30 20:13:55 2014
From: echoquote at gmail.com (Ricky Wilson)
Date: Mon, 30 Jun 2014 14:13:55 -0400
Subject: [docs] Broken links
Message-ID: <CAGuXmJgAFYZ=WT273narucTvXGmqduz1HTre6hhx1GD29M+K1g@mail.gmail.com>

*These links are broken.*
Format Packed as .zipPacked as .tar.bz2 PDF (US-Letter paper size)Download
<https://docs.python.org/2/archives/python-2.7.8-docs-pdf-letter.zip> (ca.
8 MB) Download
<https://docs.python.org/2/archives/python-2.7.8-docs-pdf-letter.tar.bz2> (ca.
8 MB) PDF (A4 paper size)Download
<https://docs.python.org/2/archives/python-2.7.8-docs-pdf-a4.zip> (ca. 8 MB)
Download
<https://docs.python.org/2/archives/python-2.7.8-docs-pdf-a4.tar.bz2> (ca.
8 MB) HTMLDownload
<https://docs.python.org/2/archives/python-2.7.8-docs-html.zip> (ca. 6 MB)
Download <https://docs.python.org/2/archives/python-2.7.8-docs-html.tar.bz2>
(ca.
4 MB) Plain TextDownload
<https://docs.python.org/2/archives/python-2.7.8-docs-text.zip> (ca. 2 MB)
Download <https://docs.python.org/2/archives/python-2.7.8-docs-text.tar.bz2>
(ca.
1.5 MB)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140630/bc0ac05f/attachment.html>

From weems at weems.de  Mon Jun 30 22:51:22 2014
From: weems at weems.de (Michael Weems)
Date: Mon, 30 Jun 2014 15:51:22 -0500
Subject: [docs] docs html 404
Message-ID: <etPan.53b1cdca.6f143fcf.18c@Luke-Sycles-MacBook-Pro-Core2Duo-15-Ozone.local>


Experiencing 404 error for the following url to documentation:?https://docs.python.org/2.7/archives/python-2.7.8-docs-html.zip

- Michael Weems

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