From report at bugs.python.org  Thu Dec  1 00:18:36 2011
From: report at bugs.python.org (Nebelhom)
Date: Wed, 30 Nov 2011 23:18:36 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1322695116.76.0.363956115954.issue13491@psf.upfronthosting.co.za>


Changes by Nebelhom <nebelhom at googlemail.com>:


Added file: http://bugs.python.org/file23823/sqlite_code_update.patch

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

From report at bugs.python.org  Thu Dec  1 05:59:05 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 04:59:05 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the GNU
	readline module
Message-ID: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

The current IOBase documentation [1] reads:

"""
IOBase (and its subclasses) support the iterator protocol, meaning that an IOBase object can be iterated over yielding the lines in a stream. Lines are defined slightly differently depending on whether the stream is a binary stream (yielding bytes), or a text stream (yielding character strings). See readline() below.
"""

Currently the 'readline' link in the last sentence is linking to the GNU readline interface, which is wrong.  Patch attached.

[1] http://docs.python.org/dev/library/io.html?highlight=readlines#io.IOBase

----------
assignee: docs at python
components: Documentation
files: IOBase.readline-doc.patch
keywords: patch
messages: 148702
nosy: docs at python, meador.inge
priority: normal
severity: normal
stage: patch review
status: open
title: IOBase docs incorrectly link to the GNU readline module
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23825/IOBase.readline-doc.patch

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

From report at bugs.python.org  Thu Dec  1 06:12:29 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 01 Dec 2011 05:12:29 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322716349.26.0.421059956417.issue13510@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

I am skeptical that such a note will help.  The iterator behavior is clearly pointed out in the Python Tutorial [1] and in the IOBase documentation [2].  I suspect this bad code pattern is just being copied and pasted from other sources without folks ever even looking at the Python documentation.

[1] http://docs.python.org/dev/tutorial/inputoutput.html?highlight=readlines#methods-of-file-objects
[2] http://docs.python.org/dev/library/io.html#io.IOBase

----------
nosy: +meador.inge

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

From report at bugs.python.org  Thu Dec  1 06:23:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 05:23:25 +0000
Subject: [docs] [issue13510] Clarify that readlines() is not needed to
	iterate over a	file
In-Reply-To: <1322674949.97.0.856520026774.issue13510@psf.upfronthosting.co.za>
Message-ID: <1322717005.66.0.908101980062.issue13510@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW I've seen several persons using "for line in file.readlines(): ..." or even "while 1: line = file.readline()".  IMHO it's a good idea to document that "without sizehint, it's equivalent to list(file)" and that "for line in file: ..." can be used directly.  Even if some people don't read the doc, the ones who do will benefit from this.  The same note might also be added to the docstring (I think it's somewhat common to learn about readlines() through dir(file) + help(file.readlines)).

----------

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

From report at bugs.python.org  Thu Dec  1 08:53:37 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 07:53:37 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
Message-ID: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This issue proposes that we adopt and apply some standard practices when documenting modules that have potential security implications and other cross-cutting errors that may affect multiple interfaces within the module.

Accordingly, the main target is the "Documenting Python" meta-docs, proposing the addition of a new subsection to the Style Guide, with an update to the subprocess module documentation serving as the exemplar of a new recommended style:

======================
2.6 Security Considerations (and Other Concerns)
------------------------------------------------

Some modules provided with Python are inherently exposed to security issues (e.g. shell injection vulnerabilities) due to the purpose of the module (e.g. subprocess invocation). Littering the documentation of these modules with red warning boxes for problems that are due to the task at hand, rather than specifically to Python's support for that task, doesn't make for a good reading experience.

Instead, these security concerns should be gathered into a dedicated "Security Considerations" section within the module's documentation, and cross-referenced from the documentation of affected interfaces with in-line text similar to "Please refer to the :ref:`security-considerations` section for important information on how to avoid common mistakes".

Similarly, if there is a common error that affects many interfaces in a module (e.g. OS level pipe buffers filling up and stalling child processes), these can be documented in a "Common Errors" section and cross-referenced rather than repeated for every affected interface.
======================


(based on the thread at http://mail.python.org/pipermail/python-dev/2011-December/114717.html)

----------
assignee: docs at python
components: Documentation
messages: 148710
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Consistent documentation practices for security concerns and considerations

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

From report at bugs.python.org  Thu Dec  1 09:10:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 08:10:22 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322727022.11.0.935606226368.issue13515@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Grouping the common warnings in a "Security Considerations" section sounds OK, but the warnings should still be visible IMHO.

In my experience, people:
 1) jump right to the doc for the function they are using;
 2) read the example and try to figure out how it works;
 3) if that fails, they read the text.

An inline text with a simple link might then pass unnoticed.  OTOH littering the doc with red boxes is far too noticeable.  Maybe we should use something in between (e.g. a "lighter" CSS for the warnings or a small warning icon).

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

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

From report at bugs.python.org  Thu Dec  1 12:46:58 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 11:46:58 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322740018.11.0.0577605414654.issue13515@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While I acknowledge the point (it's the reason I *didn't* remove those warnings in my recent major update to the subprocess docs), Raymond's right that scattering warnings everywhere in the docs for modules like subprocess isn't the right answer either. For a lot of things people use those modules for (i.e. private scripts with no untrusted user input) the warnings are excessive.

There's only so much we can do to protect novice programmers being given tasks beyond their experience, and only so much readability we should sacrifice in the name of educating people about general programming issues that aren't specific to Python.

----------

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

From report at bugs.python.org  Thu Dec  1 13:12:50 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2011 12:12:50 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322741570.72.0.0455048089177.issue13515@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think we are mixing a few different things here:
1) the content of the warning(s);
2) the position of the warning(s);
3) the style of the warning(s);

Duplicating the same content in each warning is bad, so a specific section that summarizes the problem is good.
Having at least a note with a link to the "Security consideration" section in each affected function is good too, because without them people won't notice it.
Having big red scary boxes is bad, because people are scared of big red things (especially scary ones), and our goal here is to warn, not to scare.

I think the problem with the subprocess doc is that there are many warnings and that they are big and red (and scary).  IMHO changing the style of the warning would already be a step forward the "clean look" advocated by Raymond.  Grouping redundant text and possibly rephrasing it a bit would do the rest.

----------

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

From report at bugs.python.org  Thu Dec  1 14:14:47 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 01 Dec 2011 13:14:47 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322745287.44.0.582922546296.issue13515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I agree 100% with Ezio here.

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

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

From report at bugs.python.org  Thu Dec  1 14:37:15 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2011 13:37:15 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322746635.05.0.461667410876.issue13515@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yep, using notes rather than simple inline links would also be fine with me. So, with "in-line text" changed to "a ReST note", what do people otherwise think about the proposed style guide addition?

----------

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

From report at bugs.python.org  Thu Dec  1 15:14:32 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 01 Dec 2011 14:14:32 +0000
Subject: [docs] [issue1040439] Missing documentation on how to link with
	libpython
Message-ID: <1322748872.36.0.894527699172.issue1040439@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I did a review on Rietveld.

----------

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

From report at bugs.python.org  Fri Dec  2 02:05:11 2011
From: report at bugs.python.org (Adam Forsyth)
Date: Fri, 02 Dec 2011 01:05:11 +0000
Subject: [docs] [issue13003] Bug in equivalent code for
	itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1322787911.72.0.193642596954.issue13003@psf.upfronthosting.co.za>


Adam Forsyth <agforsyth at gmail.com> added the comment:

This is marked as "wont fix" but has been fixed, the resolution should be changed.

----------
nosy: +agforsyth

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

From report at bugs.python.org  Fri Dec  2 04:33:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 02 Dec 2011 03:33:07 +0000
Subject: [docs] [issue13003] Bug in equivalent code for
	itertools.izip_longest
In-Reply-To: <1316321723.69.0.619993124857.issue13003@psf.upfronthosting.co.za>
Message-ID: <1322796786.92.0.540396036653.issue13003@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yep, it appears that Raymond has fixed this in changeset b0065b9087ef

----------
resolution: wont fix -> fixed

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

From report at bugs.python.org  Fri Dec  2 17:31:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:31:07 +0000
Subject: [docs] [issue12005] modulo result of Decimal differs from float/int
In-Reply-To: <1304584519.64.0.99823949629.issue12005@psf.upfronthosting.co.za>
Message-ID: <1322843467.19.0.237415032281.issue12005@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6, Python 3.1

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

From report at bugs.python.org  Fri Dec  2 17:49:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:49:28 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1322844568.33.0.783845954563.issue12067@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Would it be ok to state that:
1) <, >, ==, >=, <=, and != compare the values of two objects;
2) the two objects don't necessarily have to be of the same type;
3) with == and !=, objects of different types compare unequal, unless they define a specific __eq__ and/or __ne__;
4) with <, >, <=, and >=, the comparison of objects of different types raises a TypeError, unless they define specific __lt__, __gt__, __le__, and __ge__;
5) some built-in types define these operations, so it's possible to compare e.g. int and floats;

This should summarize the possible behaviors.  There's no reason IMHO to expose implementation details and to special case built-in types (unless their comparison is actually different and doesn't depend on __eq__, __ne__, etc.).

----------

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

From report at bugs.python.org  Fri Dec  2 17:53:27 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 16:53:27 +0000
Subject: [docs] [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1322844807.59.0.108293816902.issue12208@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

LGTM.

----------
assignee: docs at python -> eric.araujo
nosy: +ezio.melotti
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Dec  2 18:13:48 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:13:48 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the readline
	module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846028.74.0.163759200277.issue13513@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That?s a known behavior of Sphinx.  Please go ahead and commit.

----------
nosy: +eric.araujo
title: IOBase docs incorrectly link to the GNU readline module -> IOBase docs incorrectly link to the readline module

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

From report at bugs.python.org  Fri Dec  2 18:13:58 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:13:58 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the readline
	module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846038.38.0.843679731544.issue13513@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7

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

From report at bugs.python.org  Fri Dec  2 18:16:52 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 02 Dec 2011 17:16:52 +0000
Subject: [docs] [issue13499] uuid documentation example uses invalid
	REPL/doctest	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <1322846211.5.0.896201892878.issue13499@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Please add >>> and commit.

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

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

From report at bugs.python.org  Fri Dec  2 18:21:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:21:12 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the readline
	module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322846472.64.0.872816097193.issue13513@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

+1

----------
nosy: +ezio.melotti
stage: patch review -> commit review

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

From report at bugs.python.org  Fri Dec  2 18:29:19 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 17:29:19 +0000
Subject: [docs] [issue13499] uuid documentation example uses invalid
	REPL/doctest	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <E1RWWvF-0005Is-LN@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset d9e918c8d9d6 by Ezio Melotti in branch '2.7':
#13499: fix example adding >>> before the comments.
http://hg.python.org/cpython/rev/d9e918c8d9d6

New changeset 9e7728dc35e7 by Ezio Melotti in branch '3.2':
#13499: fix example adding >>> before the comments.
http://hg.python.org/cpython/rev/9e7728dc35e7

New changeset 060c7093a81f by Ezio Melotti in branch 'default':
#13499: merge with 3.2.
http://hg.python.org/cpython/rev/060c7093a81f

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

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

From report at bugs.python.org  Fri Dec  2 18:30:00 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:30:00 +0000
Subject: [docs] [issue13499] uuid documentation example uses invalid
	REPL/doctest	syntax
In-Reply-To: <1322576016.96.0.843898665466.issue13499@psf.upfronthosting.co.za>
Message-ID: <1322847000.42.0.534426138228.issue13499@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Done!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 18:49:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 17:49:14 +0000
Subject: [docs] [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <E1RWXEW-00077F-Ik@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2f9c986b46cd by Ezio Melotti in branch '2.7':
#13494: s/cast/convert/.  Also add a link.
http://hg.python.org/cpython/rev/2f9c986b46cd

New changeset 69369fd3514b by Ezio Melotti in branch '3.2':
#13494: s/cast/convert/.  Also add a link.
http://hg.python.org/cpython/rev/69369fd3514b

New changeset 454b97887c5a by Ezio Melotti in branch 'default':
#13494: merge with 3.2.
http://hg.python.org/cpython/rev/454b97887c5a

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

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

From report at bugs.python.org  Fri Dec  2 18:50:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 02 Dec 2011 17:50:40 +0000
Subject: [docs] [issue13494] 'cast' any value to a Boolean?
In-Reply-To: <1322488868.96.0.430179402239.issue13494@psf.upfronthosting.co.za>
Message-ID: <1322848239.99.0.0284732220706.issue13494@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed!

@Eli
At least in the doc, I haven't seen any other suspicious use of 'cast'.

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 20:28:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2011 19:28:37 +0000
Subject: [docs] [issue13439] turtle: Errors in docstrings of onkey and
	onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <E1RWYmh-0007lm-Mn@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 6e03ab9950f6 by Petri Lehtinen in branch '2.7':
Issue #13439: Fix many errors in turtle docstrings.
http://hg.python.org/cpython/rev/6e03ab9950f6

New changeset cc559e1e3bd8 by Petri Lehtinen in branch '3.2':
Issue #13439: Fix many errors in turtle docstrings.
http://hg.python.org/cpython/rev/cc559e1e3bd8

New changeset 8d60c1c89105 by Petri Lehtinen in branch 'default':
Issue #13439: Merge branch 3.2
http://hg.python.org/cpython/rev/8d60c1c89105

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

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

From report at bugs.python.org  Fri Dec  2 20:29:30 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 02 Dec 2011 19:29:30 +0000
Subject: [docs] [issue13439] turtle: Errors in docstrings of onkey and
	onkeypress
In-Reply-To: <1321802124.14.0.262913683551.issue13439@psf.upfronthosting.co.za>
Message-ID: <1322854170.67.0.912222720428.issue13439@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Fixed, thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 22:01:57 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 02 Dec 2011 21:01:57 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1322859717.4.0.357760400016.issue12067@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In Python 3, where all classes inherit from object, the default rules are, by experiment, (which someone can verify from the code) simpler than you stated.

3. By default, == and /= compare identities.
4. By default, order comparisons raise TypeError.
ob <= ob raises even though ob == ob because ob is ob.

I am not sure of the method look-up rules for rich comparisons, but perhaps the following are true:

3) with == and !=, an object is equal to itself and different objects (a is not b) compare unequal, unless the class of the first define a specific __eq__ and __ne__;

4) with <, >, <=, and >=, comparison raises a TypeError, unless the class of the first object defines specific __lt__, __gt__, __le__, and __ge__, or the class of the second defines the reflected method (__ge__ reflects __lt__, etcetera);

What is not clear to me is whether the reflected method is called if the first raises TypeError. The special method names doc (reference 3.3) says "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments. 
...
There are no swapped-argument versions of these methods (to be used when the left argument does not support the operation but the right argument does); rather, __lt__() and __gt__() are each other?s reflection, __le__() and __ge__() are each other?s reflection, and __eq__() and __ne__() are their own reflection."

Does 'not supported' mean 'raises TypeError', 'returns NotImplemented', or both? If the last, I don't really understand the reason for NotImplemented versus TypeError. That point should be clarified in 3.3 also. And 3.3 should be referenced in the comparisons section.

I think point 5 should say a bit more: builtin numbers compare as expected, even when of different types; builtin sequences compare lexicographically.

----------

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

From report at bugs.python.org  Fri Dec  2 22:32:32 2011
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 02 Dec 2011 21:32:32 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322861552.14.0.976712076178.issue13515@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please propose a concrete new styling for the warnings; I think that should be done regardless of the other points.

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

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

From report at bugs.python.org  Fri Dec  2 22:47:50 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 02 Dec 2011 21:47:50 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322862470.76.0.302871897327.issue13515@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also consider writing a security howto guide so that the docs don't become littered with warnings.

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

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

From report at bugs.python.org  Sat Dec  3 09:21:37 2011
From: report at bugs.python.org (Christopher Smith)
Date: Sat, 03 Dec 2011 08:21:37 +0000
Subject: [docs] [issue13439] turtle: Errors in docstrings of onkey and
	onkeypress
In-Reply-To: <1322854170.67.0.912222720428.issue13439@psf.upfronthosting.co.za>
Message-ID: <CAEPTCsMzS623_mb_WNMDZke9MsPLPgBkvGg0obcatL5Zp+7odA@mail.gmail.com>


Christopher Smith <smichr at users.sourceforge.net> added the comment:

> resolution: ?-> fixed
> stage: needs patch -> committed/rejected
> status: open -> closed
>

Nice to see a good thing get even better. Thanks for you work.

Chris Smith

----------

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

From report at bugs.python.org  Sat Dec  3 10:56:30 2011
From: report at bugs.python.org (Urjit Bhatia)
Date: Sat, 03 Dec 2011 09:56:30 +0000
Subject: [docs] [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1322906190.67.0.159266521622.issue13127@psf.upfronthosting.co.za>


Urjit Bhatia <urjitsb87 at gmail.com> added the comment:

Using the same code example as above, I added a simple print statement in the set method being defined in the defproperty and it fired correctly for -

a.childNodes[0].attributes='something'
**My print statement:**in defproperty set for name: attributes
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/urjit/code/mercurial/python/cpython/Lib/xml/dom/minicompat.py", line 106, in set
    "attempt to modify read-only attribute " + repr(name))
xml.dom.NoModificationAllowedErr: attempt to modify read-only attribute 'attributes'

The getter seems to work fine for localName but the setter somehow does not fire.

I have a fix for this but when I am running the test on my ubuntu vm, it doesnt go beyond test_sndhdr. However, when I run that test directly, it is successful. I can submit a patch if this problem is fixed.

----------
nosy: +urjitsb87

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

From report at bugs.python.org  Sat Dec  3 13:08:49 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 12:08:49 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
Message-ID: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

A couple of -1.0 error return codes aren't documented, see for
example PyFloat_AsDouble() and PyComplex_AsCComplex().

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 148789
nosy: docs at python, mark.dickinson, skrah
priority: low
severity: normal
stage: needs patch
status: open
title: Document error return values for PyFloat_* and PyComplex_*
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 13:13:07 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 03 Dec 2011 12:13:07 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322914387.74.0.526467535601.issue13522@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Well, it's sort of documented implicitly:  from

http://docs.python.org/c-api/intro.html#exceptions

"In general, when a function encounters an error, it sets an exception, discards any object references that it owns, and returns an error indicator.  If not documented otherwise, this indicator is either NULL or -1, depending on the function?s return type."

----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Dec  3 13:35:16 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 12:35:16 +0000
Subject: [docs] [issue12965] longobject: documentation improvements
In-Reply-To: <1315846670.45.0.93309834122.issue12965@psf.upfronthosting.co.za>
Message-ID: <1322915716.87.0.409479948893.issue12965@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> Ultimately, I think it would make sense to remove all __int__
> conversions from Objects/longobject.c;

+1

I think this API cleanup is worth some (probably very limited)
breakage in third party modules.

----------

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

From report at bugs.python.org  Sat Dec  3 14:17:22 2011
From: report at bugs.python.org (Nicolas Goutte)
Date: Sat, 03 Dec 2011 13:17:22 +0000
Subject: [docs] [issue13525] Tutorial: Example of Source Code Encoding
	triggers error
Message-ID: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>


New submission from Nicolas Goutte <nicolas.goutte at extragroup.de>:

Current Behaviour

The tutorial of Python 3.2.x has an example to set an encoding in a source file: http://docs.python.org/py3k/tutorial/interpreter.html#source-code-encoding

It explains to set the following line at the start of the source code:
# -*- coding: cp-1252 -*-

However when done exactly so, Python raises the following exception:
SyntaxError: encoding problem: with BOM

The problem seems to be that Python knows Windows codepage 1252 as windows-1252 (its IANA charset name, see http://www.iana.org/assignments/charset-reg/windows-1252 ) or alternatively as cp1252 (without dash) but not as cp-1252 (with dash).

As this is an example in the tutorial is particularly problematic, as users might not understand how to do it correctly.

This is still the case in the tutorial of Python 3.3 alpha: http://docs.python.org/dev/tutorial/interpreter.html#source-code-encoding


Expected Behaviour

The tutorial should give a correct example, for example with:
# -*- coding: windows-1252 -*-

Alternatively a totally other example as for Python 2.7 would be nice too: http://docs.python.org/tutorial/interpreter.html#source-code-encoding


Notes:
I have tested this with following Python implementations:
- Python 3.2.1 (openSUSE 12.1) on Linux
- Python 3.2.2 on Windows 7 SP1 64 Bits
- Python 3.2.2 on MacOS 10.5.8
(Always on the command line; I have not tested in IDLE.)

----------
assignee: docs at python
components: Documentation
files: cp_1252broken.py
messages: 148798
nosy: docs at python, nicolasg
priority: normal
severity: normal
status: open
title: Tutorial: Example of Source Code Encoding triggers error
versions: Python 3.2
Added file: http://bugs.python.org/file23840/cp_1252broken.py

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

From report at bugs.python.org  Sat Dec  3 14:19:06 2011
From: report at bugs.python.org (Nicolas Goutte)
Date: Sat, 03 Dec 2011 13:19:06 +0000
Subject: [docs] [issue13525] Tutorial: Example of Source Code Encoding
	triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1322918346.87.0.25637580748.issue13525@psf.upfronthosting.co.za>


Changes by Nicolas Goutte <nicolas.goutte at extragroup.de>:


Added file: http://bugs.python.org/file23841/windows_1252ok.py

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

From report at bugs.python.org  Sat Dec  3 14:23:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 13:23:54 +0000
Subject: [docs] [issue13525] Tutorial: Example of Source Code Encoding
	triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1322918634.1.0.123312262246.issue13525@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec  3 14:25:52 2011
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 03 Dec 2011 13:25:52 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322918752.35.0.507229459385.issue13522@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Good point. - I just had to figure out if the pattern

    Py_complex c = PyComplex_AsCComplex(w);
    if (c.real == -1.0 && PyErr_Occurred()) {
        ...

will always be reliable in the future. The source of PyComplex_AsCComplex()
suggests that it will, on the other hand in getargs.c the pattern isn't
used.

The passage you quoted is quite clear, so I wouldn't mind if you
close this.

I'm not sure how many people read that passage though. :)

----------

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

From report at bugs.python.org  Sat Dec  3 15:00:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 14:00:36 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <E1RWq8m-0006Nm-Az@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3b505df38fd8 by Jason R. Coombs in branch '3.2':
Issue #12666: Clarifying changes in map for Python 3
http://hg.python.org/cpython/rev/3b505df38fd8

New changeset 0e2812b16f5f by Jason R. Coombs in branch '3.2':
Issue #12666: Added section about map changes.
http://hg.python.org/cpython/rev/0e2812b16f5f

New changeset 51af35bd46f7 by Jason R. Coombs in branch 'default':
Merge fix for Issue #12666 from 3.2
http://hg.python.org/cpython/rev/51af35bd46f7

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

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

From report at bugs.python.org  Sat Dec  3 15:01:20 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Dec 2011 14:01:20 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1322920880.82.0.376982045767.issue12666@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sat Dec  3 15:46:13 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 14:46:13 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <E1RWqqx-0000qB-Q2@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ee94b89f65ab by Jason R. Coombs in branch '2.7':
Issue #13211: Add .reason attribute to HTTPError to implement parent class (URLError) interface.
http://hg.python.org/cpython/rev/ee94b89f65ab

New changeset abfe76a19f63 by Jason R. Coombs in branch '3.2':
Issue #13211: Add .reason attribute to HTTPError to implement parent class (URLError) interface.
http://hg.python.org/cpython/rev/abfe76a19f63

New changeset deb60efd32eb by Jason R. Coombs in branch 'default':
Merged fix for #13211 from 3.2
http://hg.python.org/cpython/rev/deb60efd32eb

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

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

From report at bugs.python.org  Sat Dec  3 15:47:19 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 03 Dec 2011 14:47:19 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322923639.98.0.69097296078.issue13211@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sat Dec  3 15:49:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 14:49:21 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1322923761.51.0.972548476147.issue13498@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Arfrever, belopolsky, draghuram, eric.araujo, gagenellina, georg.brandl, giampaolo.rodola, ijmorlan, terry.reedy, ysj.ray, zooko

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

From report at bugs.python.org  Sat Dec  3 16:01:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 03 Dec 2011 15:01:11 +0000
Subject: [docs] [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <1322924471.2.0.810680234188.issue12208@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you sir.  I fixed the directive markup in 4f860536efa3, I?m committing the rest now.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 16:01:30 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 15:01:30 +0000
Subject: [docs] [issue12208] Glitches in email.policy docs
In-Reply-To: <1306689945.7.0.42467338004.issue12208@psf.upfronthosting.co.za>
Message-ID: <E1RWr5l-0001xS-CQ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9ffb00748a47 by ?ric Araujo in branch 'default':
Fix glitches in email.policy docs (#12208)
http://hg.python.org/cpython/rev/9ffb00748a47

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

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

From report at bugs.python.org  Sat Dec  3 18:12:12 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 17:12:12 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1322932332.51.0.566302385255.issue13522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think it's still a good idea to spell it out explicitly in each function description. The document pointed by Mark is long enough that it's easy to overlook or forget that single important statement.

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

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

From report at bugs.python.org  Sat Dec  3 18:16:21 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 17:16:21 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322932581.75.0.948764751761.issue13515@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, the SSL module has a separate security considerations section:
http://docs.python.org/dev/library/ssl.html#security-considerations

----------

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

From report at bugs.python.org  Sat Dec  3 19:14:05 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:05 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936045.04.0.745211977344.issue13515@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a patch to make the CSS used for warnings and notes less evident by removing the red/gray background color.

----------
keywords: +patch
Added file: http://bugs.python.org/file23842/issue13515.diff

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

From report at bugs.python.org  Sat Dec  3 19:14:36 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:36 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936076.97.0.655445974993.issue13515@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23843/warnnew.png

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

From report at bugs.python.org  Sat Dec  3 19:14:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 03 Dec 2011 18:14:52 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936092.55.0.768533740072.issue13515@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23844/warnold.png

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

From report at bugs.python.org  Sat Dec  3 19:18:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 18:18:35 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322936045.04.0.745211977344.issue13515@psf.upfronthosting.co.za>
Message-ID: <1322936003.3279.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Attached a patch to make the CSS used for warnings and notes less
> evident by removing the red/gray background color.

This really years for an icon, IMO. A bit more indenting would be good,
too, so that it stands out clearly from the rest of the text.

----------

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

From report at bugs.python.org  Sat Dec  3 19:51:45 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2011 18:51:45 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the readline
	module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <E1RWugW-0001SH-O4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset fb8b6d310fb8 by Meador Inge in branch '2.7':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/fb8b6d310fb8

New changeset 9792e812198f by Meador Inge in branch '3.2':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/9792e812198f

New changeset ab5bc05ac223 by Meador Inge in branch 'default':
Issue #13513: IOBase docs incorrectly link to the readline module
http://hg.python.org/cpython/rev/ab5bc05ac223

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

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

From report at bugs.python.org  Sat Dec  3 19:53:38 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 03 Dec 2011 18:53:38 +0000
Subject: [docs] [issue13513] IOBase docs incorrectly link to the readline
	module
In-Reply-To: <1322715545.88.0.889616380344.issue13513@psf.upfronthosting.co.za>
Message-ID: <1322938418.55.0.700291076934.issue13513@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Fixed.  Thanks for the review y'all.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 21:14:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 03 Dec 2011 20:14:56 +0000
Subject: [docs] [issue13527] Remove obsolete mentions in the GUIs page
Message-ID: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The "Other Graphical User Interface Packages" page (library/othergui.html) lists "Python megawidgets" and "Tkinter3000 Widget Construction Kit (WCK)". These two projects look pretty much dead to me, so I'm proposing to remove them.

----------
assignee: docs at python
components: Documentation
messages: 148821
nosy: docs at python, pitrou
priority: low
severity: normal
status: open
title: Remove obsolete mentions in the GUIs page
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Dec  4 02:12:46 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 04 Dec 2011 01:12:46 +0000
Subject: [docs] [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <1322961166.15.0.00817527658873.issue13527@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

+1

----------
keywords: +easy
nosy: +eli.bendersky

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

From report at bugs.python.org  Sun Dec  4 03:05:14 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 02:05:14 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322964313.55.0.773846272627.issue13211@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The 3.x buildbots are all broken: http://www.python.org/dev/buildbot/all/waterfall?category=3.x.stable&category=3.x.unstable

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

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

From report at bugs.python.org  Sun Dec  4 04:35:45 2011
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 04 Dec 2011 03:35:45 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322969745.27.0.420087122501.issue13211@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suspect that this problem is caused by the fix for issue #12555.

----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun Dec  4 05:18:07 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Dec 2011 04:18:07 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1322972287.36.0.74514819901.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Antoine, I think Arfrever is on to something here. It does appear the new test added to test_urllib2 is failing, but for reasons I don't exactly understand. I'm initializing the HTTPError instance according to its signature in urllib.error, but it fails to accept keyword arguments.

I guess for the sake of this test, I can pass positional arguments, though this added limitation should probably be addressed in #12555.

----------

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

From report at bugs.python.org  Sun Dec  4 05:20:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2011 04:20:43 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <E1RX3ZA-00069I-G3@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset a3ddee916808 by Jason R. Coombs in branch 'default':
Pass positional arguments - HTTPError is not accepting keyword arguments. Reference #13211 and #12555.
http://hg.python.org/cpython/rev/a3ddee916808

----------

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

From romainmorlevat at gmail.com  Fri Dec  2 17:18:55 2011
From: romainmorlevat at gmail.com (Romain MORLEVAT)
Date: Fri, 2 Dec 2011 17:18:55 +0100
Subject: [docs] Mistake in the itertools.permutations() exemple code
Message-ID: <CACwsJvfujdMpe3g633ehGXN0dfg_RnJbAmAYTh0mrq74OTpJmw@mail.gmail.com>

Hello,

I think I found a mistake in the itertools.permutations() exemple code (
http://docs.python.org/py3k/library/itertools.html?highlight=itertools#itertools.permutations
)
At the tenth line, the *cycles = range(n, n-r, -1)*, must be *cycles =
list(range(n, n-r, -1))*.

Greetings,

Romain
--
www.romainmorlevat.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111202/a81f5f17/attachment.html>

From georg at python.org  Sun Dec  4 10:41:18 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 04 Dec 2011 10:41:18 +0100
Subject: [docs] slight bug in the docs
In-Reply-To: <4ED5535A.1040700@oracle.com>
References: <4ED5535A.1040700@oracle.com>
Message-ID: <4EDB403E.9040306@python.org>

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

Am 29.11.2011 22:49, schrieb bill murphy:
> 
> Hi,
> 
> I'm not sure if this is a version difference, or simply a bug in the docs.
> 
> Here's what your docs say: 
> (http://docs.python.org/release/2.3.5/tut/node5.html)
> 
>>>> # Integer division returns the floor:
> ... 7/3
> 
> 
> Here's what python on my machine says:
> 
> C:\waggle\qa\server_auto>python Python 3.2.2 (default, Sep  4 2011,
> 09:51:08) [MSC v.1500 32 bit (Intel)] on win 32 Type "help", "copyright",
> "credits" or "license" for more information.
>>>> 7/3
> 2.3333333333333335
> 
> Seems not to be integer division going on... Though I'm not at all clear if
> this is my particular version, or some configuration thing.

Hi Bill,

this is indeed a version difference: the docs you're looking at are, well,
ancient :)

The division operator was changed to "true" division in Python 3; its docs
are at http://docs.python.org/py3k/.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk7bQD4ACgkQN9GcIYhpnLAIHgCglJVeqaK3PR1vbBdx83i7Fd4d
W0oAoIem/wm4Hv85lVedw53VVfDgeocy
=RU1Z
-----END PGP SIGNATURE-----

From shlomif at shlomifish.org  Sun Dec  4 11:04:55 2011
From: shlomif at shlomifish.org (Shlomi Fish)
Date: Sun, 4 Dec 2011 12:04:55 +0200
Subject: [docs] [BUG] Code listing hide button in the tutorial has a typo in
 its tooltip.
Message-ID: <20111204120455.3c141013@lap.shlomifish.org>

Dear sirs,

Throughout the tutorial (on all pages, but including, say
http://docs.python.org/tutorial/classes.html ), the hide button for the interactive code excerpts (marked with a ">>>"), says this in the tooltip:

?Hide the prompts and ouput?

However, "ouput" should be "output".

Please correct it on all pages of the tutorial.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
Stop Using MSIE - http://www.shlomifish.org/no-ie/

Chuck Norris is his own boss. If you hire him, he?ll tell your boss what to
do.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

From georg at python.org  Sun Dec  4 11:53:28 2011
From: georg at python.org (Georg Brandl)
Date: Sun, 04 Dec 2011 11:53:28 +0100
Subject: [docs] [BUG] Code listing hide button in the tutorial has a
 typo in its tooltip.
In-Reply-To: <20111204120455.3c141013@lap.shlomifish.org>
References: <20111204120455.3c141013@lap.shlomifish.org>
Message-ID: <4EDB5128.5090009@python.org>

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

Am 04.12.2011 11:04, schrieb Shlomi Fish:
> Dear sirs,
> 
> Throughout the tutorial (on all pages, but including, say 
> http://docs.python.org/tutorial/classes.html ), the hide button for the 
> interactive code excerpts (marked with a ">>>"), says this in the tooltip:
> 
> ?Hide the prompts and ouput?
> 
> However, "ouput" should be "output".
> 
> Please correct it on all pages of the tutorial.

Hi,

thanks for the report, I've now fixed this in the source, and it will be
online on docs.python.org soon.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk7bUSgACgkQN9GcIYhpnLDVdACeMkOxEeI6L1BWxbhHbMeXxSBL
dKEAnRpOTuSeXA7+20bpmt8qtL2g9Hlj
=fYok
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sun Dec  4 15:19:21 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 04 Dec 2011 14:19:21 +0000
Subject: [docs] [issue13211] urllib2.HTTPError does not have 'reason'
	attribute.
In-Reply-To: <1318943168.93.0.520705450261.issue13211@psf.upfronthosting.co.za>
Message-ID: <1323008361.86.0.462125251287.issue13211@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After yet another commit, the build bots are green again:

http://hg.python.org/cpython/rev/8fa1dc66de5d

----------

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

From shlomif at shlomifish.org  Sun Dec  4 12:38:51 2011
From: shlomif at shlomifish.org (Shlomi Fish)
Date: Sun, 4 Dec 2011 13:38:51 +0200
Subject: [docs] [BUG] Code listing hide button in the tutorial has a
 typo in its tooltip.
In-Reply-To: <4EDB5128.5090009@python.org>
References: <20111204120455.3c141013@lap.shlomifish.org>
	<4EDB5128.5090009@python.org>
Message-ID: <20111204133851.46ac3860@lap.shlomifish.org>

Hi,

On Sun, 04 Dec 2011 11:53:28 +0100
Georg Brandl <georg at python.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 04.12.2011 11:04, schrieb Shlomi Fish:
> > Dear sirs,
> > 
> > Throughout the tutorial (on all pages, but including, say 
> > http://docs.python.org/tutorial/classes.html ), the hide button for the 
> > interactive code excerpts (marked with a ">>>"), says this in the tooltip:
> > 
> > ?Hide the prompts and ouput?
> > 
> > However, "ouput" should be "output".
> > 
> > Please correct it on all pages of the tutorial.
> 
> Hi,
> 
> thanks for the report, 

You're welcome.

> I've now fixed this in the source, and it will be
> online on docs.python.org soon.
> 

Thanks for that, and thanks for the quick reply.

Regards,

	Shlomi Fish

-- 
-----------------------------------------------------------------
Shlomi Fish       http://www.shlomifish.org/
My Public Domain Photos - http://www.flickr.com/photos/shlomif/

Dax: yep, space. Nothing but nothing all around.
    ? Star Trek, ?We, the Living Dead? by Shlomi Fish

Please reply to list if it's a mailing list post - http://shlom.in/reply .

From report at bugs.python.org  Sun Dec  4 18:01:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 17:01:33 +0000
Subject: [docs] [issue13528] Rework performance FAQ
Message-ID: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a slimmed down rewrite of the performance question in the FAQ (also moved around to a dedicated subheader).

----------
assignee: docs at python
components: Documentation
files: perffaq.patch
keywords: patch
messages: 148853
nosy: docs at python, pitrou, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Rework performance FAQ
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23851/perffaq.patch

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

From report at bugs.python.org  Sun Dec  4 23:33:11 2011
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 04 Dec 2011 22:33:11 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1323037991.36.0.192972268921.issue1660009@psf.upfronthosting.co.za>


Changes by Piotr Dobrogost <pd at python.dobrogost.net>:


----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Mon Dec  5 00:05:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2011 23:05:08 +0000
Subject: [docs] [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <E1RXL7K-0004ND-TU@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 2111bf7e5bca by Antoine Pitrou in branch '3.2':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/2111bf7e5bca

New changeset f0008683585c by Antoine Pitrou in branch 'default':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/f0008683585c

New changeset 478b4e9551fa by Antoine Pitrou in branch '2.7':
Issue #13527: remove mention of Python megawidgets and Tkinter3000 WCK
http://hg.python.org/cpython/rev/478b4e9551fa

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

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

From report at bugs.python.org  Mon Dec  5 00:14:26 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 04 Dec 2011 23:14:26 +0000
Subject: [docs] [issue13527] Remove obsolete mentions in the GUIs page
In-Reply-To: <1322943296.54.0.855851973093.issue13527@psf.upfronthosting.co.za>
Message-ID: <1323040466.45.0.825271978347.issue13527@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 04:26:59 2011
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 05 Dec 2011 03:26:59 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
Message-ID: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The docs for os.lseek don't make any mention of its return value.  I believe it's the new offset in the file, but I'm not sure if there are other subtleties to be mentioned.

----------
assignee: docs at python
components: Documentation
messages: 148861
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Docs for os.lseek neglect to mention what it returns
versions: Python 2.7, Python 3.2

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

From report at bugs.python.org  Mon Dec  5 08:27:55 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 05 Dec 2011 07:27:55 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323070075.83.0.072985175067.issue13530@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The only subtlety is that the result is the offset from the beginning, independent of the how value. It may also raise exceptions.

----------
nosy: +loewis

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

From report at bugs.python.org  Mon Dec  5 12:21:16 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 05 Dec 2011 11:21:16 +0000
Subject: [docs] [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1323084076.45.0.999176850561.issue13443@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This section has been removed from the 3.x docs in 3828f81a64e7 and 2aeef275bec8, but it's still there in 2.7.

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

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

From report at bugs.python.org  Mon Dec  5 16:50:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Dec 2011 15:50:27 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1323100227.0.0.200534162018.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The updated patch looks good, I?ll commit it soon.

----------

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

From report at bugs.python.org  Mon Dec  5 16:59:36 2011
From: report at bugs.python.org (Nebelhom)
Date: Mon, 05 Dec 2011 15:59:36 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1323100227.0.0.200534162018.issue13491@psf.upfronthosting.co.za>
Message-ID: <CAHw0e=uS13q8Jz7MSD2PD2LuVGj1tnP8M+QirWvY+55qoXcSUQ@mail.gmail.com>


Nebelhom <nebelhom at googlemail.com> added the comment:

Hi,

thanks for your help and support, mate.

Unfortunately, no word about the createdb.py business (the last bullet
point on the list) and whether it should be referred to in the doc. Should
we just drop this from the adjustments?

Thanks.

Johannes

P.S. Any suggestions where to look in the doc next until your packaging
patch is ready for reviewing?

On Mon, Dec 5, 2011 at 4:50 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> The updated patch looks good, I?ll commit it soon.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue13491>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Dec  5 17:17:41 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 05 Dec 2011 16:17:41 +0000
Subject: [docs] [issue13491] Fixes for sqlite3 doc
In-Reply-To: <1322390027.54.0.855055968281.issue13491@psf.upfronthosting.co.za>
Message-ID: <1323101861.35.0.871726082936.issue13491@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Unfortunately, no word about the createdb.py business (the last bullet point on the list)
> and whether it should be referred to in the doc.
If you make the whitespace more standard, use the tempfile module (to remove the os.remove line) and use with statements, the file is actually very short (so my earlier hypothesis about createdb was wrong :).

I think we could inline it (with a literalinclude directive) or link to it (with :source:`Doc/include/sqlite3/createdb.py`).  Add something like ?If you want to run these examples, run this code to create and populate the initial database? and we?re set.

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

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

From report at bugs.python.org  Tue Dec  6 07:01:25 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 06 Dec 2011 06:01:25 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323151285.62.0.488307196369.issue13530@psf.upfronthosting.co.za>


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


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Tue Dec  6 14:12:17 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2011 13:12:17 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323177137.13.0.74081855.issue13538@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with you that this is inconsistent.  However, having str raise an error is pretty much a non-starter as a suggestion.  str always falls back to the repr; in general str(obj) should always return some value, otherwise the assumptions of a *lot* of Python code would be broken.

Personally I'm not at all sure why str takes encoding and errors arguments (I never use them). I'd rather there be only one way to do that, decode.  In other words, why do we have special case support for byte strings in the str conversion function?

But I don't think that can be changed either, so I think we are stuck with documenting the existing situation better.  Do you want to propose a doc patch?

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, r.david.murray
versions: +Python 3.3

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

From report at bugs.python.org  Tue Dec  6 14:14:32 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 13:14:32 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323177272.46.0.54919678862.issue13538@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Personally I'm not at all sure why str takes encoding and errors
> arguments (I never use them).

Probably because the unicode type also did in 2.x.
And also because it makes it compatible with arbitrary buffer objects:

>>> str(memoryview(b"foo"), "ascii")
'foo'

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

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

From report at bugs.python.org  Tue Dec  6 14:56:41 2011
From: report at bugs.python.org (Guillaume Bouchard)
Date: Tue, 06 Dec 2011 13:56:41 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323179801.38.0.915954488581.issue13538@psf.upfronthosting.co.za>


Guillaume Bouchard <guillaum.bouchard at gmail.com> added the comment:

> str always falls back to the repr; in general str(obj) should always return some value, otherwise the assumptions of a *lot* of Python code would be broken.

Perhaps it may raises a warning ?

ie, the only reason encoding exists if for the conversion of bytes (or something which looks like bytes) to str. Do you think it may be possible to special case the use of str for bytes (and bytesarray) with something like this:

def str(object, encoding=None, errors=None):
    if encoding is not None:
         # usual work
    else:
       if isinstance(object, (bytes, bytesarray)):
             warning('Converting bytes/bytesarray to str without encoding, it may not be what you expect')
             return object.__str__()

But by the way, adding warnings and special case everywhere seems not too pythonic.

> Do you want to propose a doc patch?

The docstring for str() should looks like something like, in my frenglish way of writing english ::

  Create a new string object from the given encoded string.

  If object is bytes, bytesarray or a buffer-like object, encoding and error
  can be set. errors can be 'strict', 'replace' or 'ignore' and defaults to
  'strict'.

  WARNING, if encoding is not set, the object is converted to a nicely
  printable representation, which is totally different from what you may expect.

Perhaps a warning may be added in the on-line documentation, such as ::

  .. warning::
     When str() converts a bytes/bytesarray or a buffer-like object and
     *encoding* is not specified, the result will an unicode nicely printable
     representation, which is totally different from the unicode representation of
     you object using a specified encoding.

Whould you like a .diff on top of the current mercurial repository ?

----------

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

From report at bugs.python.org  Tue Dec  6 15:30:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2011 14:30:26 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323181826.87.0.685107739752.issue13538@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

A diff would be great.

We try to use warnings sparingly, and I don't think this is a case that warrants it.  Possibly a .. note is worthwhile, perhaps with an example for the bytes case, but even that may be too much.

I also wouldn't use the wording "is totally different from what you would expect", since by now I do expect it :).  How about something like "the result will not be the decoded version of the bytes, but instead will be the repr of the object", with a cross link to repr.

----------

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

From report at bugs.python.org  Tue Dec  6 15:56:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Dec 2011 14:56:35 +0000
Subject: [docs] [issue13540] Document the Action API
Message-ID: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In http://docs.python.org/dev/library/argparse.html#action, when describing an arbitrary action, the documentation states, "You can also specify an arbitrary action by passing an object that implements the Action API." This statement does not link to any documentation on the Action API and does not describe the API except to give an example.

Furthermore, the example contradicts the description. The description says "pass an object" but the example passes a class.

The documentation should clarify the text relating to the example and should document the expected interface for a custom action.

----------
assignee: docs at python
components: Documentation
messages: 148921
nosy: docs at python, jason.coombs
priority: low
severity: normal
status: open
title: Document the Action API
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Dec  6 15:57:00 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 06 Dec 2011 14:57:00 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323183420.96.0.892536817728.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
title: Document the Action API -> Document the Action API in argparse

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

From report at bugs.python.org  Tue Dec  6 16:00:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 06 Dec 2011 15:00:19 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323183619.04.0.429338748952.issue13538@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, I forgot to mention it in my previous message, but there is already a warning that you can activate with the -b option:

$ ./python -b
Python 3.3.0a0 (default:6b6c79eba944, Dec  6 2011, 11:11:32) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"")
__main__:1: BytesWarning: str() on a bytes instance
"b''"


And you can even turn it into an error with -bb:

$ ./python -bb
Python 3.3.0a0 (default:6b6c79eba944, Dec  6 2011, 11:11:32) 
[GCC 4.5.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> str(b"")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BytesWarning: str() on a bytes instance


However, -b is highly unlikely to become the default, for the reasons already explained. It was mainly meant to ease porting from Python 2.

----------

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

From report at bugs.python.org  Wed Dec  7 19:45:27 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 07 Dec 2011 18:45:27 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <CAH_1eM3GhXAMbwD+__3ojjdXF5yMVf54QwyD3BjkS5j4t59vug@mail.gmail.com>
Message-ID: <CAH_1eM02EouZ-1X8dgZhEDbDWsPzzh6PxGb-HtdQUHSE4Wd88w@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file23866/event_wait_cleared.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -804,8 +804,9 @@
       floating point number specifying a timeout for the operation in seconds
       (or fractions thereof).
 
-      This method returns the internal flag on exit, so it will always return
-      ``True`` except if a timeout is given and the operation times out.
+      This method returns true if and only if the internal flag has been set to
+      true by another thread, so it will always return ``True`` except if a
+      timeout is given and the operation times out.
 
       .. versionchanged:: 3.1
          Previously, the method always returned ``None``.
diff --git a/Lib/test/lock_tests.py b/Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py
+++ b/Lib/test/lock_tests.py
@@ -353,6 +353,22 @@
         for r, dt in results2:
             self.assertTrue(r)
 
+    def test_set_and_clear(self):
+        # Issue #13502: check that wait() returns true even when the event is
+        # cleared before the waiting thread is woken up.
+        evt = self.eventtype()
+        results = []
+        N = 5
+        def f():
+            results.append(evt.wait(1))
+        b = Bunch(f, N)
+        b.wait_for_started()
+        time.sleep(0.5)
+        evt.set()
+        evt.clear()
+        b.wait_for_finished()
+        self.assertEqual(results, [True] * N)
+
 
 class ConditionTests(BaseTestCase):
     """
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -408,9 +408,10 @@
     def wait(self, timeout=None):
         self._cond.acquire()
         try:
-            if not self._flag:
-                self._cond.wait(timeout)
-            return self._flag
+            signaled = self._flag
+            if not signaled:
+                signaled = self._cond.wait(timeout)
+            return signaled
         finally:
             self._cond.release()
 

From report at bugs.python.org  Wed Dec  7 22:49:54 2011
From: report at bugs.python.org (Matt Long)
Date: Wed, 07 Dec 2011 21:49:54 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
Message-ID: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>


New submission from Matt Long <matt at crocodoc.com>:

The description of nesting list comprehensions in section 5.1.5 of the main Python tutorial (http://docs.python.org/tutorial/datastructures.html#nested-list-comprehensions) is misleading at best and arguably incorrect. Where it says "To avoid apprehension when nesting list comprehensions, read from right to left." This is incorrect and conflicts directly with the comment at the bottom of PEP 202 (http://www.python.org/dev/peps/pep-0202/), which says the last index varies fastest.

Take the following example:

matrix = [[1,2],[3,4],[5,6]]
my_list = []
for row in matrix:
  for number in row
    my_list.append(number)

The current documentation would suggest I do the following to achieve the same result with list comprehensions since the for statements should be read from right to left:

matrix = [[1,2],[3,4],[5,6]]
my_list = [number for number in row for row in matrix]

Running this code will result in an error. The correct form is:

matrix = [[1,2],[3,4],[5,6]]
[number for row in matrix for number in row]

Clearly the nesting order only matters when the inner loop depends on the outer loop as in my example above. There is no such dependency in the documentation's example, which is why it is does not result in an Error.

----------
assignee: docs at python
components: Documentation
messages: 148994
nosy: docs at python, mattlong
priority: normal
severity: normal
status: open
title: Incorrect nested list comprehension documentation
type: behavior
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Thu Dec  8 05:30:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2011 04:30:01 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <CAH_1eM02EouZ-1X8dgZhEDbDWsPzzh6PxGb-HtdQUHSE4Wd88w@mail.gmail.com>
Message-ID: <20111208042958.A625F2500E6@webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

On Wed, 07 Dec 2011 18:45:27 +0000, <report at bugs.python.org> wrote:
> _______________________________________
> diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
> --- a/Doc/library/threading.rst
> +++ b/Doc/library/threading.rst
> @@ -804,8 +804,9 @@
>        floating point number specifying a timeout for the operation in seconds
>        (or fractions thereof).
>  
> -      This method returns the internal flag on exit, so it will always return
> -      ``True`` except if a timeout is given and the operation times out.
> +      This method returns true if and only if the internal flag has been set to
> +      true by another thread, so it will always return ``True`` except if a
> +      timeout is given and the operation times out.

This seems to imply that if the current thread previously set the event,
the wait will return False, which is contradicted by the 'so' statement
(which appears to be correct).

--David

----------

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

From report at bugs.python.org  Thu Dec  8 08:40:42 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 08 Dec 2011 07:40:42 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323330042.0.0.384184423696.issue13502@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

> This seems to imply that if the current thread previously set the event,
> the wait will return False, which is contradicted by the 'so' statement
> (which appears to be correct).

You're probably referring to the "another thread" part...
A suggestion ? I see you're a native speaker :-)

----------

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

From report at bugs.python.org  Thu Dec  8 14:16:52 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Dec 2011 13:16:52 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323350212.9.0.501961277475.issue13549@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Isn't the documentation that you refer to about *nested* list comprehensions, rather than list comprehensions with multiple 'for' clauses?

E.g.,:

    [number for row in matrix for number in row]

is not a nested list comprehension:  it's merely a list comprehension with two 'for' clauses.  But:

    [[number for number in row] for row in matrix]

*is* a nested list comprehension (a list comprehension for which the initial expression is itself a list comprehension), and there the advice to read from right to left seems to make sense to me.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Thu Dec  8 14:17:32 2011
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 08 Dec 2011 13:17:32 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323350252.75.0.758457688627.issue13549@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Mind you, I'm not at all sure about that use of 'apprehension'...

----------

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

From report at bugs.python.org  Thu Dec  8 15:11:28 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 14:11:28 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323353488.31.0.202285234866.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This section could be clearer imho.
First of all there's nothing special about "nested" list comprehensions.  In [expr for elem in seq], expr might be any expression -- including a listcomp.  As with any other expression, the nested listcomp will be executed for each elem in seq, so there's really nothing new to explain here.
The "reading order" is always from left to right, with the expression at the end:
    [expr for x in seq1 for y in seq2 for z in seq3]
     ^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^ ^^^^^^^^^^^^^
     last     first        second         third...

So I agree that "To avoid apprehension when nesting list comprehensions, read from right to left." is a bit confusing/wrongish (is actually correct for listcomp with only a single for, but that's just a coincidence and it's not related to nested listcomps).

The previous section could also be a little clearer, showing the classic example:
    squares = [x**2 for x in range(10)]
and saying that it's equivalent to
    squares = []
    for x in range(10):
        squares.append(x**2)

and, similarly, that
    combs = [(c1, c2) for c1 in 'abc' for c2 in 'xyz']
is equivalent to
    combs = []
    for c1 in 'abc':
        for c2 in 'xyz':
            combs.append((c1, c2))

Showing the "reading direction" with these two equivalents and saying that nested listcomps follow the same rule (because there's nothing different about them), should be enough to make things clear.

In addition, the example with the matrix shouldn't use print in the "expanded" version, but rather something like:
    res = []
    for i in [0, 1, 2]:
        res.append([row[i] for row in mat])
    print res

----------
nosy: +ezio.melotti
stage:  -> needs patch
versions: +Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Thu Dec  8 16:04:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 15:04:11 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323356651.82.0.640543198106.issue13549@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +eric.araujo, terry.reedy
stage: needs patch -> commit review
Added file: http://bugs.python.org/file23882/issue13549.diff

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

From report at bugs.python.org  Thu Dec  8 17:31:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 08 Dec 2011 16:31:54 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323361914.33.0.746658220089.issue13549@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I welcome improvements to this part of the docs.  Nested list comps had me quite confused at first: I had to write and execute them to understand how it worked.  So, the patch looks good to me.  Remarks:

- I?d recommend a few whitespace beautifications, like in ``for x in [1,2,3]`` and ``range(1,6)``.

- You changed ?If the expression would evaluate to a tuple, it must be parenthesized? to ?If the expression is a tuple (e.g. the ``(x, y)`` +in this example), it must be parenthesized?, I guess because either the concept that an expression evaluates to something is (a) incorrect or (b) not appropriate at this stage of the tutorial.  I think there is an example that makes that line more understandable, but it?s in the section about tuples, not here in the listcomp section; you may or may not want to improve that too.

- +1 for the removal of the half-joking half-recommendation not to use nested list comps (?If you've got the stomach for it, list comprehensions can be nested. They are a powerful tool but -- like all powerful tools -- they need to be used carefully, if at all.?).

- Maybe a link to the itertools module is appropriate (either after the combinations example, or after the link to the built-in zip function).

----------

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

From report at bugs.python.org  Thu Dec  8 18:10:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 17:10:20 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323364220.0.0.407171061774.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> - I?d recommend a few whitespace beautifications,
> like in ``for x in [1,2,3]`` and ``range(1,6)``.
Leaving the space out in [1,2,3] makes the expression a bit more readable IMHO*.


>  I think there is an example that makes that line more
> understandable, but it?s in the section about tuples, not here in the 
> listcomp section; you may or may not want to improve that too.
What needs to be parenthesized are tuple literals, and I think people at this point of the tutorial still think that () are required to make a tuple, so they would probably put them anyway.  IOW the example that uses them, the note, and the example that fails are probably enough already.

> - Maybe a link to the itertools module is appropriate (either after 
> the combinations example, or after the link to the built-in zip 
> function).
I was going to add it, but then realized that itertools' functions don't return lists, so they are a bit unrelated (and maybe it's too early to introduce itertools at this point of the tutorial).


* the idea is to separate better different elements, even if the single elements are a bit less readable:
2 * 3          is ok (you are multiplying two numbers)
2*3 + 4*5      is ok (you are adding two products)
2 * 3 + 4 * 5  is less readable (you have to parse the operations)
2 * 3+4 * 5    is misleading (it looks like the product of 3 numbers)
Similarly:
[(1,2,3), (3,4,5), (5,6,7)]  is ok (you have a list with 3 tuples)
[(1, 2, 3), (3, 4, 5), (5, 6, 7)]  is less readable (the space are used to separate both the tuples and the elements in there, and you have to parse the () to see where the tuples start and end).
YMMV though.

----------

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

From report at bugs.python.org  Thu Dec  8 22:43:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 08 Dec 2011 21:43:52 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323380632.13.0.627632508486.issue13549@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Comments:

1. The first sentence is a bit too opinionated for my taste. Consider:

map(f, seq)
[f(x) for x in seq]

The map is *more* concise, by 8 chars, than the list comp and, in *my* opinion, clearer and easier to read without the extra boilerplate and extraneous dummy variable. I would write the first sentence more like:

"List comprehensions provide a concise way to create lists without having to use either a blank list followed by list.append or combinations of map, filter, and lambda expressions."

2. The added examples are nice and should help.

3. "In a list comprehension might contain arbitrary expressions, including other listcomps." is not a sentence. I think this in meant to say: "The initial expression in a list comprehension can be any arbitrary expression, including another list comprehension."

4. I completely agree with removing the scary hobgoblin stuff. In fact, I think the platitudinous next sentence "Nested list comprehensions are a powerful tool but -- like all powerful tools -- they need to be used carefully, if at all." could also go. It does not add anything not better said in what follows. Python is a powerful tool, but -- like all powerful tools -- it needs to by used carefully. Yeah, right ;-).

I believe the later sentence "To avoid apprehension when nesting list comprehensions, read from right to left." means to say "To avoid mis-apprehandion [or misunderstanding] when nesting list comprehension, read from outside in." But even this only indirectly points to what I think is the real danger -- which is to read the nested l.c. as unnested, and hence to get the order of the clauses wrong. In other words, reading
   [[f(x,y) for x in xseq] for y in yseq]
as
   [ f(x,y) for x in xseq  for y in yseq]
I initally made that mistake when reading the nested example. So I think the appropriate warning sentence should be something like:
"The main danger to avoid is reading nested comprehensions as if they were one comprehension with multiple for clauses." This could go after the revised initial sentence in place of the useless platitude.

4. The example is more confusing than need be because of using a symmetric matrix. The literal [0,1,2] is both range(len(mat)) and range(len(mat[0])) but it is only the latter that is relevant. So I strongly urge using an asymmetric matrix (3x4) and suggest using range(4) instead of [0,1,2,3]

So, change "Consider the following example of a 3x3 matrix held as a list containing three lists, one list per row::" to
"Suppose one has a 3x4 matrix implemented as a list of 3 lists of length 4::"

Change mat display accordingly, using 1 to 12.

Change "Now, if you wanted to swap rows and columns, you could use this list comprehension::" to
"The following list comprehension will transpose rows and columns."
>>> [[row[i] for row in mat] for i in range(4)]
[[1, 5, 9], [2, 6, 10], [3, 7, 11], [4, 8, 12]]

I think the more verbose version (slightly modified to match the below) should be followed by an even more (completely) verbose version:

trans = []
for i in range(4):
    transrow = []
    for row in mat:
        transrow.append(row[i])
    trans.append(transrow)
print(trans)

5. "In real world," should be "In the real world,".

----------

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

From report at bugs.python.org  Thu Dec  8 23:42:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 08 Dec 2011 22:42:47 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323384167.02.0.872755317984.issue13549@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23885/issue13549-2.diff

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

From report at bugs.python.org  Fri Dec  9 01:54:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Dec 2011 00:54:45 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323392085.7.0.663910220772.issue13549@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

v.2 looks great to me.

----------

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

From report at bugs.python.org  Fri Dec  9 02:50:00 2011
From: report at bugs.python.org (Michael Foord)
Date: Fri, 09 Dec 2011 01:50:00 +0000
Subject: [docs] [issue13561] os.listdir documentation should mention
	surrogateescape
Message-ID: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Where os.listdir encounters undecodable bytes from the filesystem it uses the surrogateescape handler. As the resulting strings are invalid they can't be encoded without an errorhandler, and so can't be printed (for example).

This should be documented.

----------
assignee: docs at python
components: Documentation
messages: 149070
nosy: docs at python, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: os.listdir documentation should mention surrogateescape
versions: Python 3.3

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

From report at bugs.python.org  Fri Dec  9 03:22:04 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Fri, 09 Dec 2011 02:22:04 +0000
Subject: [docs] [issue13562] Notes about module load path
Message-ID: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>


New submission from Nam Nguyen <bitsink at gmail.com>:

A doc patch to remind Python embedder to set sys.path prior to Py_Initialize. This is to ensure a controlled module load path to work around these issues:

http://bugs.python.org/issue12989
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5983

----------
assignee: docs at python
components: Documentation
files: module.load.path.diff
keywords: patch
messages: 149071
nosy: Nam.Nguyen, docs at python
priority: normal
severity: normal
status: open
title: Notes about module load path
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file23888/module.load.path.diff

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

From folkert.mobiel at gmail.com  Tue Dec  6 15:23:27 2011
From: folkert.mobiel at gmail.com (Folkert van Heusden)
Date: Tue, 6 Dec 2011 15:23:27 +0100
Subject: [docs]
	http://docs.python.org/tutorial/controlflow.html#if-statements
Message-ID: <CAHwprn3NYDAUdQjeu27ftjqfsH4=NG7qK3zjKOyjeeP+fDAp9Q@mail.gmail.com>

Hi,

Regarding the explanation of the if/else construct in Python: maybe you can
add a short explanation to it that while c/c++/java use || and &&, that
python requires 'or' and 'and'.
Took me a while to figure that out :-)


-- 
www.vanheusden.com

bitcoin account: 14ExronPRN44urf4jqPMyoAN46T75MKGgP
msn address: spam at vanheusden.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111206/9a284002/attachment.html>

From pmaupin at gmail.com  Wed Dec  7 01:55:32 2011
From: pmaupin at gmail.com (Patrick Maupin)
Date: Tue, 6 Dec 2011 18:55:32 -0600
Subject: [docs] Apparent bug in python socket howto
Message-ID: <CAPz3yKcFn174eUSFDwkAKC440fVxMvSYqR6TcYrBVjJxi2-LzA@mail.gmail.com>

Thanks for the howto. ?It's a great conceptual introduction, and I was
happy to have it to read when I needed to get my hands a bit dirtier
than using SocketServer.

But the statement ?"If we had used s.bind(('', 80)) [the socket would
only be] visible within the same machine." appears to be incorrect.

As the socket module documentation states, "the empty string
represents INADDR_ANY."

Thanks and best regards,
Patrick Maupin
Austin, Texas

From skeu.grass at gmail.com  Thu Dec  8 08:19:43 2011
From: skeu.grass at gmail.com (skeu.Grass)
Date: Thu, 8 Dec 2011 15:19:43 +0800
Subject: [docs] option -m bug
Message-ID: <2011120815194324489434@gmail.com>

Hi, I found that the description of option '-m' is wrong:
In 
Python v2.7.2 documentation ? Python Setup and Usage ?
1.1.1. Interface options
-m <module-name>
it says As with the -c option, the current directory will be added to the start of sys.path.
But I found that using the "python -m<module-name>" the current directory won't be added to the start of sys.path.
I tested the v2.6.6 v2.7.2 v3.2.2, they all have the problem.
_____________________________
skeu.Grass
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111208/431d80a5/attachment.html>

From anthon at mnt.org  Fri Dec  9 11:52:44 2011
From: anthon at mnt.org (Anthon van der Neut)
Date: Fri, 09 Dec 2011 11:52:44 +0100
Subject: [docs] typo in subprocess doc
Message-ID: <4EE1E87C.1060400@mnt.org>

In the subprocess documentation there is an 'r' missing in the  header 
for the Popen constructor


      17.1.1.2. Popen Constuctor?
      <http://docs.python.org/library/subprocess.html#popen-constuctor>

Popen Constuctor
^^^^^^^^^^^^^^^^

should be

Popen Constructor
^^^^^^^^^^^^^^^^^


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

From report at bugs.python.org  Fri Dec  9 14:44:41 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 09 Dec 2011 13:44:41 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323438280.79.0.520887157014.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

In the first patch I included this example:
+   >>> swapped = []
+   >>> for i in [0, 1, 2]:
+   ...     swapped.append([row[i] for row in mat])
+   ...
+   >>> print swapped
+   [[1, 4, 7], [2, 5, 8], [3, 6, 9]]

Because I applied the following transformation without looking at what expr was (another listcomp in this case):
    res = [expr for elem in seq]
==>
   res = []
   for elem in seq:
       res.append(expr)

If the reader does the same he/she wouldn't have any problem figuring out what is the order of the `for`s, but the second version of the patch only includes a "fully expanded" example:
+   >>> transposed = []
+   >>> for i in range(4):
+   ...     # the following 3 lines implement the nested listcomp
+   ...     transposed_row = []
+   ...     for row in matrix:
+   ...         transposed_row.append(row[i])
+   ...     transposed.append(transposed_row)
+   ...
+   >>> transposed

Here it's easier to confuse the two `for` (not because they are similar, but because there are two of them, whereas in the previous example there's only one).

I added a comment to clarify that the inner loop is the listcomp, but maybe it would be better to show the first example too, followed by the "fully expanded" one, i.e.:

+   [[row[i] for row in mat] for i in range(4)]

+   >>> transposed = []
+   >>> for i in range(4):
+   ...     transposed.append([row[i] for row in mat])
+   ...
+   >>> transposed

+   >>> transposed = []
+   >>> for i in range(4):
+   ...     # the following 3 lines implement the nested listcomp
+   ...     transposed_row = []
+   ...     for row in matrix:
+   ...         transposed_row.append(row[i])
+   ...     transposed.append(transposed_row)
+   ...
+   >>> transposed

The step in the middle shows that in order to get to the "fully expanded" form, it's enough to apply the "usual" listcomp->for+append transformation twice, without worrying about left-to-right vs right-to-left.  Do you think it's worth adding this?

----------

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

From report at bugs.python.org  Fri Dec  9 23:03:26 2011
From: report at bugs.python.org (R. David Murray)
Date: Fri, 09 Dec 2011 22:03:26 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323468206.2.0.462284605234.issue13502@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"set to True, either before the wait call or after the wait starts"

----------

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

From report at bugs.python.org  Fri Dec  9 23:16:44 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2011 22:16:44 +0000
Subject: [docs] [issue13528] Rework performance FAQ
In-Reply-To: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>
Message-ID: <E1RZ8kE-0008AH-JT@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset eb30f2becb79 by Antoine Pitrou in branch '3.2':
Issue #13528: rework the performance question in the programming FAQ
http://hg.python.org/cpython/rev/eb30f2becb79

New changeset 9fe28f52eaaa by Antoine Pitrou in branch 'default':
Issue #13528: rework the performance question in the programming FAQ
http://hg.python.org/cpython/rev/9fe28f52eaaa

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

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

From report at bugs.python.org  Fri Dec  9 23:17:19 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 09 Dec 2011 22:17:19 +0000
Subject: [docs] [issue13528] Rework performance FAQ
In-Reply-To: <1323018091.73.0.846706598362.issue13528@psf.upfronthosting.co.za>
Message-ID: <1323469039.79.0.718466191309.issue13528@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec 10 04:47:43 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Dec 2011 03:47:43 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323488863.42.0.786375924371.issue13549@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Showing both was the intent of my comment. Since I am about 60:40 on that, I was and am  willing for you, having grabbed and pushed the issue, to drop the half-expanded version if you thought it better. With or without, we have improved this section. But I still think showing the intermediate step adds sufficient extra clarity to be worth the 5 or 6 extra lines. While nested list comps are not scary, they can, as I discovered, be confusing with a rushed reading. Anyone who wants to compress nested append loops should also do it in two steps.

----------

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

From report at bugs.python.org  Sat Dec 10 13:57:28 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 10 Dec 2011 12:57:28 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <1323468206.2.0.462284605234.issue13502@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM1+=3+yO_VHrHcZmMUqEa1EpMbLTOYCU2UxawRUxSZ9jA@mail.gmail.com>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

Thanks, here's a patch updated accordingly.

----------
Added file: http://bugs.python.org/file23897/event_wait_cleared-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13502>
_______________________________________
-------------- next part --------------
diff --git a/Doc/library/threading.rst b/Doc/library/threading.rst
--- a/Doc/library/threading.rst
+++ b/Doc/library/threading.rst
@@ -804,8 +804,10 @@
       floating point number specifying a timeout for the operation in seconds
       (or fractions thereof).
 
-      This method returns the internal flag on exit, so it will always return
-      ``True`` except if a timeout is given and the operation times out.
+      This method returns true if and only if the internal flag has been set to
+      true, either before the wait call or after the wait starts, so it will
+      always return ``True`` except if a timeout is given and the operation
+      times out.
 
       .. versionchanged:: 3.1
          Previously, the method always returned ``None``.
diff --git a/Lib/test/lock_tests.py b/Lib/test/lock_tests.py
--- a/Lib/test/lock_tests.py
+++ b/Lib/test/lock_tests.py
@@ -353,6 +353,22 @@
         for r, dt in results2:
             self.assertTrue(r)
 
+    def test_set_and_clear(self):
+        # Issue #13502: check that wait() returns true even when the event is
+        # cleared before the waiting thread is woken up.
+        evt = self.eventtype()
+        results = []
+        N = 5
+        def f():
+            results.append(evt.wait(1))
+        b = Bunch(f, N)
+        b.wait_for_started()
+        time.sleep(0.5)
+        evt.set()
+        evt.clear()
+        b.wait_for_finished()
+        self.assertEqual(results, [True] * N)
+
 
 class ConditionTests(BaseTestCase):
     """
diff --git a/Lib/threading.py b/Lib/threading.py
--- a/Lib/threading.py
+++ b/Lib/threading.py
@@ -408,9 +408,10 @@
     def wait(self, timeout=None):
         self._cond.acquire()
         try:
-            if not self._flag:
-                self._cond.wait(timeout)
-            return self._flag
+            signaled = self._flag
+            if not signaled:
+                signaled = self._cond.wait(timeout)
+            return signaled
         finally:
             self._cond.release()
 

From report at bugs.python.org  Sat Dec 10 14:34:46 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Sat, 10 Dec 2011 13:34:46 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1323524086.41.0.37122368341.issue13530@psf.upfronthosting.co.za>


Changes by Ross Lagerwall <rosslagerwall at gmail.com>:


----------
nosy: +rosslagerwall

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

From report at bugs.python.org  Sat Dec 10 15:23:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Sat, 10 Dec 2011 14:23:59 +0000
Subject: [docs] [issue13502] Documentation for Event.wait return value is
	either	wrong or incomplete
In-Reply-To: <1322599516.14.0.0239672713193.issue13502@psf.upfronthosting.co.za>
Message-ID: <1323527038.98.0.0278460834766.issue13502@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

LGTM.

----------

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

From report at bugs.python.org  Sat Dec 10 16:52:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 15:52:17 +0000
Subject: [docs] [issue13525] Tutorial: Example of Source Code Encoding
	triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1323532337.3.0.144712810592.issue13525@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the detailed bug report.  I thought the normalization performed by the codec lookup system would convert 'cp-1252' to 'cp1252' (its ?real? name, i.e. the name of the module implementing the codec), but it does not.  I?m +1 to removing the hyphen in the example, then.

> Python raises the following exception:
> SyntaxError: encoding problem: with BOM
I reproduced this and it?s surprising.  Maybe there is a bug with error reporting here.

> Alternatively a totally other example as for Python 2.7 would be nice too
This file has seen different changes in 2.7 and 3.2, given that the default encoding is different in 3.x.  I?ll check the history and upload a patch here to get your feedback.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo

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

From report at bugs.python.org  Sat Dec 10 17:03:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:03:27 +0000
Subject: [docs] [issue13538] Docstring of str() and/or behavior
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323533007.36.0.551798983157.issue13538@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A note in the docs (without note/warning directives, just a note) and maybe the docstring would be good.  It should better explain that str has two uses: converting anything to a str (using __str__ or __repr__), decode buffer to str (with encoding and errors arguments).  str(b'') is a case of the first use, not the second (and likewise %s formatting).

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

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

From report at bugs.python.org  Sat Dec 10 17:03:53 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:03:53 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323533033.27.0.0539649914258.issue13538@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Docstring of str() and/or behavior -> Improve doc for str(bytesobject)

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

From report at bugs.python.org  Sat Dec 10 17:21:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:21:43 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323534103.92.0.0228239085299.issue13540@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +bethard, eric.araujo

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

From report at bugs.python.org  Sat Dec 10 17:32:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:32:42 +0000
Subject: [docs] [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323534762.47.0.732721069487.issue13557@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you like to make a doc patch?

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, eric.araujo
resolution: invalid -> 
stage:  -> needs patch
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Dec 10 17:34:00 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:34:00 +0000
Subject: [docs] [issue13561] os.listdir documentation should mention
	surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1323534840.6.0.968872920649.issue13561@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, haypo, loewis

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

From report at bugs.python.org  Sat Dec 10 17:35:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:35:22 +0000
Subject: [docs] [issue13562] Notes about module load path
In-Reply-To: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>
Message-ID: <1323534922.74.0.312577490117.issue13562@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch, I will make a few wording/markup editions if you don?t mind and post the edited version.

----------
nosy: +eric.araujo
versions: +Python 3.3 -Python 2.6, Python 3.1

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

From report at bugs.python.org  Sat Dec 10 17:45:42 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 10 Dec 2011 16:45:42 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323535542.44.0.485291910448.issue13515@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Note sure about icon vs. text (?Warning:?) vs. colors.  I think an icon would be as scary as the current big color boxes.  I like Ezio?s change + Antoine?s indenting suggestion.

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

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

From report at bugs.python.org  Sat Dec 10 18:14:13 2011
From: report at bugs.python.org (Nam Nguyen)
Date: Sat, 10 Dec 2011 17:14:13 +0000
Subject: [docs] [issue13562] Notes about module load path
In-Reply-To: <1323397324.61.0.220189805252.issue13562@psf.upfronthosting.co.za>
Message-ID: <1323537253.45.0.605736136288.issue13562@psf.upfronthosting.co.za>


Nam Nguyen <bitsink at gmail.com> added the comment:

That would be great. Thank you.

----------

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

From report at bugs.python.org  Sat Dec 10 18:19:47 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:19:47 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323537587.69.0.132665995199.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Having both is fine.

I just noticed that the 3.2 docs are different[0], so I tried to merge them:

3.2 says:
"""
List comprehensions provide a concise way to create lists from sequences. Common applications are to make lists where each element is the result of some operations applied to each member of the sequence, or to create a subsequence of those elements that satisfy a certain condition.
"""
I kept this, changing a few minor things.

In 3.2 the examples are divided and each one has a short description.  I reworked them a bit to make them more clear, and added the description inline as a comment.

The section about nested listcomps is the same, so I didn't change it (but it's now a subsection of the list comprehension section).

This is hopefully the final version.

[0]: http://docs.python.org/py3k/tutorial/datastructures.html#list-comprehensions

----------
Added file: http://bugs.python.org/file23900/issue13549-3.diff

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

From report at bugs.python.org  Sat Dec 10 18:29:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:29:12 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323538152.55.0.471510064868.issue13549@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23901/issue13549-3-py32.diff

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

From report at bugs.python.org  Sat Dec 10 18:36:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 10 Dec 2011 17:36:40 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323538600.66.0.895465684296.issue13515@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> I think an icon would be as scary as the current big color boxes.
Especially if I design it.

Georg, is the patch ok if I add a bit of indentation as suggested by Antoine?

----------

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

From report at bugs.python.org  Sat Dec 10 19:05:54 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2011 18:05:54 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1323535542.44.0.485291910448.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323539651.3287.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Note sure about icon vs. text (?Warning:?) vs. colors.  I think an
> icon would be as scary as the current big color boxes.  I like Ezio?s
> change + Antoine?s indenting suggestion.

An icon will only be scary if you chopse a scary one. A "warning" icon
can simply be an exclamation mark or something (*). It would be less
prominent than a box with a red background, while still clearly
separating the warning from the rest of the text (something which a too
small indentation does not).

Icons or drawings also make text documents less austere, which is a good
thing. There are lots of free icon sets out there, so Ezio doesn't have
to train his art skills ;)

(*) to get an idea, search "exclamation mark icon" with Google Images

----------

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

From report at bugs.python.org  Sat Dec 10 19:43:13 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 10 Dec 2011 18:43:13 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1323542593.36.0.559742735038.issue13515@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't really like the combination of the left bar and the background color.  What about making the left bar thicker, and leaving out the background color?

----------

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

From report at bugs.python.org  Sat Dec 10 20:52:05 2011
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 10 Dec 2011 19:52:05 +0000
Subject: [docs] [issue13574] refresh example in doc for Extending and
	Embedding
Message-ID: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The example uses PyInstanceObject which is Python 2 only (old-style classes).

http://docs.python.org/dev/extending/newtypes.html#weak-reference-support

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 149183
nosy: docs at python, flox
priority: normal
severity: normal
stage: needs patch
status: open
title: refresh example in doc for Extending and Embedding
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Dec 10 23:41:46 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 10 Dec 2011 22:41:46 +0000
Subject: [docs] [issue13574] refresh example in doc for Extending and
	Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1323556906.46.0.360123622489.issue13574@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Sun Dec 11 14:58:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 11 Dec 2011 13:58:30 +0000
Subject: [docs] [issue13574] refresh example in doc for Extending and
	Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1323611910.87.0.943345825548.issue13574@psf.upfronthosting.co.za>


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


----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Sun Dec 11 19:26:29 2011
From: report at bugs.python.org (Christopher the Magnificent)
Date: Sun, 11 Dec 2011 18:26:29 +0000
Subject: [docs] [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
Message-ID: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>


New submission from Christopher the Magnificent <ultimate.mac.fanatic at gmail.com>:

observe help(type) and type.__doc__ in Python 3.1:


>>> help(type)
Help on class type in module builtins:

class type(object)
 |  type(object) -> the object's type
 |  type(name, bases, dict) -> a new type
 |  
 |  Methods defined here:
 |  
 |  __call__(...)
 |      x.__call__(...) <==> x(...)
 |  
 |  __delattr__(...)
 |      x.__delattr__('name') <==> del x.name
 |  
 |  __getattribute__(...)
 |      x.__getattribute__('name') <==> x.name
 |  
 |  __init__(...)
 |      x.__init__(...) initializes x; see x.__class__.__doc__ for signature
 |  
 |  __instancecheck__(...)
 |      __instancecheck__() -> check if an object is an instance
 |  
 |  __repr__(...)
 |      x.__repr__() <==> repr(x)
 |  
 |  __setattr__(...)
 |      x.__setattr__('name', value) <==> x.name = value
 |  
 |  __subclasscheck__(...)
 |      __subclasschck__ -> check if an class is a subclass
 |  
 |  __subclasses__(...)
 |      __subclasses__() -> list of immediate subclasses
 |  
 |  mro(...)
 |      mro() -> list
 |      return a type's method resolution order
 |  
 |  ----------------------------------------------------------------------
 |  Data descriptors defined here:
 |  
 |  __abstractmethods__
 |  
 |  __base__
 |  
 |  __bases__
 |  
 |  __basicsize__
 |  
 |  __dict__
 |  
 |  __dictoffset__
 |  
 |  __flags__
 |  
 |  __itemsize__
 |  
 |  __mro__
 |  
 |  __weakrefoffset__
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __new__ = <built-in method __new__ of type object at 0x145600>
 |      T.__new__(S, ...) -> a new object with type S, a subtype of T
 |  
 |  __prepare__ = <built-in method __prepare__ of type object at 0x145600>
 |      __prepare__() -> dict
 |      used to create the namespace for the class statement

>>> type.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new type"
>>> 





observe help(type) and type.__doc__ in Python 3.2:



>>> help(type)
Help on class type in module builtins:

type = <class 'type'>
>>> type.__doc__
"type(object) -> the object's type\ntype(name, bases, dict) -> a new type"
>>> 



It appears that the __doc__ attribute of <class 'type'> is unchanged from Python 3.1 to 3.2, but it is not being displayed by the help function in Python 3.2.

The help function is very important to using Python!  This should be fixed.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 149234
nosy: christopherthemagnificent, docs at python
priority: normal
severity: normal
status: open
title: help() appears to be broken; doesn't display __doc__ for class type when called as help(type)
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Sun Dec 11 20:21:59 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 11 Dec 2011 19:21:59 +0000
Subject: [docs] [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <1323631319.54.0.448651922735.issue13581@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It fails for the same reason as issue1785:

~/python/cpython3.2$ ./python -c "import inspect; inspect.classify_class_attrs(type)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/amauryfa/python/cpython3.2/Lib/inspect.py", line 321, in classify_class_attrs
    obj_via_getattr = getattr(cls, name)
AttributeError: __abstractmethods__

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Mon Dec 12 02:09:04 2011
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 12 Dec 2011 01:09:04 +0000
Subject: [docs] [issue13561] os.listdir documentation should mention
	surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1323652144.01.0.585468917644.issue13561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Can you please write a doc patch?

----------

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

From report at bugs.python.org  Mon Dec 12 03:37:07 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:37:07 +0000
Subject: [docs] [issue12704] Language References does not specify exception
	raised by	final yield()
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1323657427.81.0.647312088736.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Hmm. Does the total lack responses mean agreement, disagreement or lack of interest? I'm attaching a patch against Python 3.3 in the hope of moving this forward.

----------
keywords: +patch
Added file: http://bugs.python.org/file23924/patch_v1.diff

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

From report at bugs.python.org  Mon Dec 12 03:37:44 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 12 Dec 2011 02:37:44 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1323657463.93.0.0884328122614.issue12704@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


----------
title: Language References does not specify exception raised by final yield() -> Language Reference: Clarify behaviour of yield when generator is not resumed

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

From report at bugs.python.org  Mon Dec 12 11:09:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 10:09:45 +0000
Subject: [docs] [issue7867] Proposed FAQ entry on pass-by-? semantics and
	the meaning	of 'variable' in python
In-Reply-To: <1265490255.73.0.743157337936.issue7867@psf.upfronthosting.co.za>
Message-ID: <1323684585.37.0.832066414457.issue7867@psf.upfronthosting.co.za>


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


----------
nosy: +rprosser
versions:  -Python 3.1

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

From grimiznizub at yahoo.com  Sun Dec 11 00:56:38 2011
From: grimiznizub at yahoo.com (Lazar Pancic)
Date: Sat, 10 Dec 2011 15:56:38 -0800 (PST)
Subject: [docs] ironpython web address has changed
Message-ID: <1323561398.62600.YahooMailNeo@web161703.mail.bf1.yahoo.com>

Hi

Just to note, it seems that ironpython homepage address is now:

http://ironpython.net/

The link target should be changed at:

http://docs.python.org/reference/introduction.html?highlight=compiling%20code? .



Best regards
LP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111210/3cb2b0b0/attachment.html>

From kogelnik at gmail.com  Mon Dec 12 07:27:36 2011
From: kogelnik at gmail.com (Chris Kogelnik)
Date: Sun, 11 Dec 2011 22:27:36 -0800
Subject: [docs] multiprocessing / Connection
Message-ID: <4EE59ED8.1030503@gmail.com>

In both the 2.7 an 3.0 docs and online help, in the module 
multiprocessing for the Connection object, the 'recv', 'recv_bytes' and 
'recv_bytes_into' methods do not mention that the routines block until 
data is available.

I think this would be useful to add.

Thanks.

From report at bugs.python.org  Mon Dec 12 13:40:54 2011
From: report at bugs.python.org (Bithin A)
Date: Mon, 12 Dec 2011 12:40:54 +0000
Subject: [docs] [issue13587] Correcting the typos error in
	Doc/howto/urllib2.rst
Message-ID: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>


New submission from Bithin A <bithin2007 at gmail.com>:

In the documentation 'HOWTO Fetch Internet Resources Using urllib2' there is a correction under the heading 'Basic Authentication'

In the line 'The header looks like : ``Www-authenticate: SCHEME realm="REALM"``. ' the word 'Www-authenticate' should be written as 'WWW-Authenticate' . 

Link : docs.python.org/howto/urllib2.html

----------
assignee: docs at python
components: Documentation
messages: 149295
nosy: Bithin.A, docs at python
priority: normal
severity: normal
status: open
title: Correcting the typos error in Doc/howto/urllib2.rst
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 12 17:47:58 2011
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2011 16:47:58 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323708478.47.0.106082270166.issue11468@psf.upfronthosting.co.za>


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


----------
nosy: +berkerpeksag

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

From report at bugs.python.org  Mon Dec 12 18:19:05 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 17:19:05 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323710345.0.0.953947737935.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll be updating this example shortly, but it is intentional that it include only assertEqual, assertTrue, and assertRaises.  Those three are the minimum necessary to get up and running (which is the whole point of the BASIC example).

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

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

From report at bugs.python.org  Mon Dec 12 19:21:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 18:21:52 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323714112.23.0.677198443944.issue11468@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The patch includes only assertEqual, assertTrue, and assertRaises and, except a s/functions/methods/ in the first line, looks good to me.

----------
stage: needs patch -> commit review
versions:  -Python 3.1

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

From report at bugs.python.org  Mon Dec 12 19:38:33 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2011 18:38:33 +0000
Subject: [docs] [issue11468] Improve unittest basic example in the doc
In-Reply-To: <1299867342.41.0.388080450116.issue11468@psf.upfronthosting.co.za>
Message-ID: <1323715113.53.0.650526282827.issue11468@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Ezio, please leave this one for me.

----------

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

From amirouche.boubekki at gmail.com  Mon Dec 12 21:58:29 2011
From: amirouche.boubekki at gmail.com (Amirouche Boubekki)
Date: Mon, 12 Dec 2011 21:58:29 +0100
Subject: [docs] Misleading yield as a statement vs an expression
Message-ID: <CAL7_Mo8PuJ4XCqmFJbSSQYxU=sAHDegQAW5_87JgPLyMcs-J5A@mail.gmail.com>

H?llo,

Documentation about the yield *expression* can be found twice at [1] and
[2]. This is misleading, I think only the [2] is relevant since PEP 342 [3].

HTH,

[1]
http://docs.python.org/reference/expressions.html#grammar-token-yield_atom
[2]
http://docs.python.org/reference/simple_stmts.html#grammar-token-yield_stmt
[3] http://www.python.org/dev/peps/pep-0342/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111212/0d3c7f51/attachment.html>

From report at bugs.python.org  Mon Dec 12 22:24:53 2011
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Mon, 12 Dec 2011 21:24:53 +0000
Subject: [docs] [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1323725093.1.0.803967760911.issue13557@psf.upfronthosting.co.za>


Stephan R.A. Deibel <sdeibel at wingware.com> added the comment:

Here's a patch to the docs that notes the issue and refers the reader to the relevant execution model docs page.  I have also attempted to clarify the "interaction with dynamic features" section of the execution model page.

----------
keywords: +patch
versions:  -Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23937/exec-eval-clarification.diff

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

From report at bugs.python.org  Mon Dec 12 23:41:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:41:13 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323729673.92.0.825161553844.issue13538@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think Eric's suggestion is the proper approach.

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

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

From report at bugs.python.org  Mon Dec 12 23:42:07 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 12 Dec 2011 22:42:07 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1323729727.73.0.451413952675.issue13538@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/issue13538>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:58:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2011 22:58:24 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323730704.25.0.174835535382.issue13540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc specified the Action API as the interface inherited from argparse.Action plus the addition of a custom __call__ method with 4 params (5 with self) as described. That seems mostly adequate to me, unless there is something missing in the parameter descriptions.

I agree that it should be stated if one should pass the class rather than an instance thereof. (But classes are objects, so that is not a 'contradiction'.) If the example is in error, it should be fixed.

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

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

From report at bugs.python.org  Tue Dec 13 14:38:33 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2011 13:38:33 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <E1RaSYv-0000uc-9T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 132158b287d7 by Ezio Melotti in branch '2.7':
#13549: improve tutorial section about listcomps.
http://hg.python.org/cpython/rev/132158b287d7

New changeset ad5c70296c7b by Ezio Melotti in branch '3.2':
#13549: improve tutorial section about listcomps.
http://hg.python.org/cpython/rev/ad5c70296c7b

New changeset 37094a1454ab by Ezio Melotti in branch 'default':
#13549: merge with 3.2.
http://hg.python.org/cpython/rev/37094a1454ab

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

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

From report at bugs.python.org  Tue Dec 13 14:43:22 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 13 Dec 2011 13:43:22 +0000
Subject: [docs] [issue13549] Incorrect nested list comprehension
	documentation
In-Reply-To: <1323294594.34.0.721210305301.issue13549@psf.upfronthosting.co.za>
Message-ID: <1323783802.73.0.939943191077.issue13549@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed.
On a side note, using:
>>> [x, x**2 for x in range(6)]
  File "<stdin>", line 1
    [x, x**2 for x in range(6)]
               ^
SyntaxError: invalid syntax

In the 3.x docs seems to break the hightlight.
With 'File "<stdin>", line 1, in ?' the highlight works fine, so that's what I used.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Dec 13 16:08:31 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2011 15:08:31 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323788911.33.0.311115938702.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

You're right. The documentation isn't incorrect, if you're splitting hairs. But it's not super friendly either.

Questions that the documentation should answer:

1) Does the action always need to be a subclass of an Action, or is that recommended? If it's recommended, replace "easiest" with "recommended".
2) If it does not always need to be a subclass of Action, what is the interface expected of a class for a custom action?
3) If one does use a subclass of Action, are there any hooks that are called at any point? How does one customize an action other than to override __call__? What attributes are available on the object (the example shows .dest only)?
4) What is the action required to do in __call__, if anything? Is there any way to invoke the default behavior (if for example a special case wasn't detected)?

All of these questions can be answered by going to the source, but I've twice now gone to the documentation to reference how to provide a custom action and found the documentation insufficient.

Now that I review the source again, I think I know the answers to those questions.

1) It does not always need to be a subclass of Action, but it is recommended.
2) The action API expects a callable with the following signature: Action(option_strings, dest, nargs=None, const=None, default=None, type=None, choices=None, required=False, help=None, metavar=None) which when called returns another callable accepting the four parameters.
3) Argparse does nothing with the custom action except to call it first with the init parameters, then calls the result with four parameters. If subclassing Action, the default __init__ simply stores each of those parameters as attributes on the object. Most subclasses of Action will override the __init__ to validate the options and raise an exception (typically a ValueError) when the parameters aren't valid.
4) The action is not required to do anything. Most actions will perform some logic and then invoke setattr(namespace, self.dest, result) where result is the result of some logic.

I can see why no one wanted to write this documentation. It's difficult to describe simply.

Here's what I propose:

First, remove the phrase "Action API" which suggests that there's an API outside of subclassing the Action that's recommended.

Second, change "easiest" to "recommended" to using the class.

Third, explain what attributes are available on an object initialized from a subclass of Action. Provide a link to code or other section that describes advanced usage (overriding __init__).

Fourth, explain what is expected when calling an Action instance (i.e. setattr).

Fifth, consider extending the Action class so that __call__ calls an actual named method so that those writing custom actions aren't writing classes with only a __call__ method. Perhaps "invoke". I feel less strongly about this point, but it seems strange that the recommended usage is to write a class with only a __call__ method.

----------

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

From report at bugs.python.org  Tue Dec 13 21:28:03 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 13 Dec 2011 20:28:03 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
Message-ID: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

The default buffering of standard output and standard error has changed in Python 3.x with respect to Python 2.x, and I have been unable to find decent documentation of either the current behaviour, or the change.

(See also http://groups.google.com/group/comp.lang.python/browse_thread/thread/43476d4682059f53#)

Part 1 - the change
-------------------
>From rude experiment it seems that:
a) In Python 2.x, standard error was always unbuffered while standard
output was buffered by default.  In python3, both are buffered. In
both cases, "buffered" means line-buffered when writing to the console
and not line-buffered when redirected to files.
b) In Python 2.x, the "-u" flag meant everything was totally
unbuffered. In Python 3.x, it means that both stdout and stderr are
line-buffered also when redirected to files. 

One important consequence of (a) is, if stderr is redirected
to a file, your program throws an exception and is then subsequently terminated with SIGTERM, you will not see the exception. This will not be expected for someone used to the Python 2.x behaviour.

"What's New in Python 3.0" has this to say about the change (in the section marked "Changes Already Present In Python 2.6"

"# PEP 3116: New I/O Library. The io module is now the standard way of doing file I/O, and the initial values of sys.stdin, sys.stdout and sys.stderr are now instances of io.TextIOBase. [...]"

This seems wrong in that, while the io module was present in Python 2.6, the change noted to sys.stdin, sys.stdout and sys.stderr was not.
Also, it is far from obvious from this note that any externally observable behaviour has changed.

I suggest changing this to 
a) note the buffering changes listed above
b) note the change in meaning of the -u flag
c) Move this to its own section which is not part of changes to Python 2.6 (it's OK to keep the note about the new io module there)

Part 2 - the behaviour
----------------------
a) The documentation for "sys.stdout" and "sys.stderr" does not say anything about their default buffering properties in various situations, nor how this can modified by setting the "-u" flag.

b) The documentation for "-u" is misleading:
"Force the binary layer of the stdin, stdout and stderr streams (which
is available as their buffer attribute) to be unbuffered. The text I/O
layer will still be line-buffered." 

The "still" in the last sentence is only relevant when stdout/stderr are writing to the console. If they are redirected to file, "-u" *modifies the behaviour such that* the text I/O layer will be line-buffered.

----------
assignee: docs at python
components: Documentation
messages: 149408
nosy: docs at python, gjb1002
priority: normal
severity: normal
status: open
title: Improve documentation of stdout/stderr buffering in Python 3.x
type: behavior
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Dec 14 03:07:48 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 02:07:48 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323828468.2.0.862254712146.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

We could force sys.stderr to be always line-buffered if that's better than the current settings.

----------
components: +IO
nosy: +benjamin.peterson, pitrou, stutzbach
versions:  -Python 3.1, Python 3.4

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

From report at bugs.python.org  Wed Dec 14 04:22:03 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Dec 2011 03:22:03 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323832923.54.0.459905532497.issue13597@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

I'm surprised to hear that stderr is line buffered by default. Historically stderr is never buffered (at least on POSIX) and for good reason: errors should be seen immediately

Was this an oversight in migrating stdin/out/err to the new io module?

----------
nosy: +pjenvey

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

From report at bugs.python.org  Wed Dec 14 05:39:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:39:35 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837575.77.0.807495950558.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
hgrepos: +95

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

From report at bugs.python.org  Wed Dec 14 05:44:39 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:44:39 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837879.18.0.709072166135.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've attached a repository and patch with the recommended changes. I created an additional section that includes the documentation for the Action class (specifically the __init__ and __call__ signatures).

I believe this addresses the issues I raised. Any objections to this change? I haven't tested the rendering yet, but I'll do that before pushing to the master if it's adequate.

----------

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

From report at bugs.python.org  Wed Dec 14 05:46:35 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 04:46:35 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323837995.26.0.907463903083.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file23949/956c6d33a57d.diff

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

From report at bugs.python.org  Wed Dec 14 06:25:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Dec 2011 05:25:27 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323840327.81.0.105431690915.issue13540@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My guess from the way the docs are written now is that subclassing from Action and over-riding just the __call__ method is the intended way, not just the recommended. If so, Action is a quasi-private class, only exposed so it could be subclassed with one method given. And if so, one could question whether anything more need be documented.

However, in your patch, you write

"+Many actions also override the ``__init__`` method, validating the parameters to the argument definition and raising a ValueError or other Exception on failure."

What 'many actions' are you referring to? Ones you have written, by referring to the code? Ones you think might be written if the doc were added?

In any case, I would prefer input from Stephen before we expose and thereby freeze the __init__ signature.

----------

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

From report at bugs.python.org  Wed Dec 14 10:26:45 2011
From: report at bugs.python.org (Laurent Mazuel)
Date: Wed, 14 Dec 2011 09:26:45 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1323854805.49.0.292195363639.issue13498@psf.upfronthosting.co.za>


Changes by Laurent Mazuel <laurent.mazuel at gmail.com>:


----------
nosy: +Laurent.Mazuel

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

From report at bugs.python.org  Wed Dec 14 10:47:56 2011
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 14 Dec 2011 09:47:56 +0000
Subject: [docs] [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323856076.57.0.281453400373.issue13600@psf.upfronthosting.co.za>


Ram Rachum <ram at rachum.com> added the comment:

Then I suggest replacing this error message:

    encoder did not return a bytes object (type=str)

and this one:

    'memoryview' object has no attribute 'translate'

With something like:

    Please use `codecs.lookup('rot-13').encode`

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Wed Dec 14 11:48:45 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 10:48:45 +0000
Subject: [docs] [issue13600] rot_13 codec not working
In-Reply-To: <1323852996.8.0.468969751026.issue13600@psf.upfronthosting.co.za>
Message-ID: <1323859725.03.0.86968242117.issue13600@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Issue #7475 discusses fixing the error messages, too.

----------
components: +Library (Lib)
resolution:  -> duplicate
stage: committed/rejected -> 
status: open -> closed
superseder:  -> codecs missing: base64 bz2 hex zlib hex_codec ...

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

From report at bugs.python.org  Wed Dec 14 14:07:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 13:07:43 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323832923.54.0.459905532497.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323868045.3334.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm surprised to hear that stderr is line buffered by default.
> Historically stderr is never buffered (at least on POSIX) and for good
> reason: errors should be seen immediately
> 
> Was this an oversight in migrating stdin/out/err to the new io module?

Until recently it wasn't possible to have an unbuffered text stream with
the new io stack. Now it's possible in write-only mode, although the
open() builtin hasn't been updated for it.

----------

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

From report at bugs.python.org  Wed Dec 14 14:54:31 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2011 13:54:31 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323870871.47.0.480315785399.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Most of the Action subclasses in argparse override __init__ and they raise ValueErrors when the parameters aren't as expected for that argument. This was my reason for adding that comment. If the basic Actions require this level of validation, wouldn't a custom action also want to supply this type of behavior? I'm sure I've overridden Action.__init__ in some of the subclasses I've created, but I don't remember specifically why.

I agree freezing the __init__ signature is undesirable. It would be preferable if the API called a hook for validating the argument parameters against the action. My intention, however, was to document the existing behavior, not influence changes in the behavior.

Perhaps the recommended API really isn't to subclass Action, but to supply a callable that takes the __init__ args which validates the parameters and returns a callable which takes the __call__ args which should set attributes on the namespace. Perhaps the Action class is only one such implementation of the API. Indeed, that was my understanding of the API as it is currently documented before Terry suggested otherwise.

What do you think about instead of documenting the Action class, we formalize the API, similar to how I described it in the previous paragraph, and then suggest that an Action subclass with an overridden __call__ is the most direct way to implement the Action API?


In reviewing the code again, I note that not just most, but all of the Action subclasses override __init__. I also note that not all of them accept the same parameters. For example, the _StoreConstAction does not accept an nargs parameter.

>>> p = argparse.ArgumentParser()
>>> p.add_argument('--awesome-sauce', action="store_const", const=True, nargs=None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python\lib\argparse.py", line 1281, in add_argument
    action = action_class(**kwargs)
TypeError: __init__() got an unexpected keyword argument 'nargs'

So it seems that the Action API is slightly different than I described. The first callable should accept all of the parameters passed to add_argument _except_ for the action parameter itself. I think by indicating this in the API description, we avoid the problem of freezing any additional signature.

I'll take another stab at updating the documentation with these findings.

----------

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

From report at bugs.python.org  Wed Dec 14 19:38:01 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 14 Dec 2011 18:38:01 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323887881.83.0.596639258787.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

I would certainly be in favour of restoring the python 2.x behaviour, at least where standard error is concerned. When writing Python programs, it's important to see exceptions immediately, and not lose them entirely in some circumstances.

I reported this as a documentation bug because I got the impression it was deliberate, mostly from reading http://bugs.python.org/issue4705 and the comp.lang.python thread in the description, but I personally think the Python 2.x behaviour was preferable.

----------
components:  -IO
nosy:  -benjamin.peterson, pitrou, pjenvey, stutzbach
versions: +Python 3.1, Python 3.4

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

From report at bugs.python.org  Wed Dec 14 19:41:03 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 14 Dec 2011 18:41:03 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323888063.78.0.866981965347.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Ooops, seems like I just ran into a bug in the bug tracker too, it seems to have backed out other people's changes. Restoring them...

----------
components: +IO
nosy: +benjamin.peterson, pitrou, pjenvey, stutzbach
versions:  -Python 3.1, Python 3.4

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

From report at bugs.python.org  Wed Dec 14 20:28:55 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 14 Dec 2011 19:28:55 +0000
Subject: [docs] [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323890935.38.0.408295219864.issue13402@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

Attaching an updated patch. The documentation now says that sys.executable may be an empty string. The patch also adds a test to make sure that sys.executable is absolute.

----------
Added file: http://bugs.python.org/file23958/issue13402_v2.patch

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

From report at bugs.python.org  Wed Dec 14 22:15:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 14 Dec 2011 21:15:00 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323897300.71.0.852771913137.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I've opened issue13601 for the possible behaviour change)

----------

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

From report at bugs.python.org  Thu Dec 15 00:11:28 2011
From: report at bugs.python.org (Philip Jenvey)
Date: Wed, 14 Dec 2011 23:11:28 +0000
Subject: [docs] [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323904288.66.0.767522480397.issue13402@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode

----------
nosy: +dino.viehland, pjenvey

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

From report at bugs.python.org  Thu Dec 15 02:13:35 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 01:13:35 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323911614.88.0.97288746639.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

There are a *lot* of characters with semantic significance that are reported by the tokenize module as generic "OP" tokens:

token.LPAR
token.RPAR
token.LSQB
token.RSQB
token.COLON
token.COMMA
token.SEMI
token.PLUS
token.MINUS
token.STAR
token.SLASH
token.VBAR
token.AMPER
token.LESS
token.GREATER
token.EQUAL
token.DOT
token.PERCENT
token.BACKQUOTE
token.LBRACE
token.RBRACE
token.EQEQUAL
token.NOTEQUAL
token.LESSEQUAL
token.GREATEREQUAL
token.TILDE
token.CIRCUMFLEX
token.LEFTSHIFT
token.RIGHTSHIFT
token.DOUBLESTAR
token.PLUSEQUAL
token.MINEQUAL
token.STAREQUAL
token.SLASHEQUAL
token.PERCENTEQUAL
token.AMPEREQUAL
token.VBAREQUAL
token.CIRCUMFLEXEQUAL
token.LEFTSHIFTEQUAL
token.RIGHTSHIFTEQUAL
token.DOUBLESTAREQUAL?
token.DOUBLESLASH
token.DOUBLESLASHEQUAL
token.AT

However, I can't fault tokenize for deciding to treat all of those tokens the same way - for many source code manipulation purposes, these just need to be transcribed literally, and the "OP" token serves that purpose just fine.

As the extensive test updates in the current patch suggest, AMK is also correct that changing this away from always returning "OP" tokens (even for characters with more specialised tokens available) would be a backwards incompatible change.

I think there are two parts to this problem, one documentation related (affecting 2.7, 3.2, 3.3) and another that would be an actual change in 3.3:

1. First, I think 3.3 should add an "exact_type" attribute to TokenInfo instances (without making it part of the tuple-based API). For most tokens, this would be the same as "type", but for OP tokens, it would provide the appropriate more specific token ID.

2. Second, the tokenize module documentation should state *explicitly* which tokens it collapses down into the generic "OP" token, and explain how to use the "string" attribute to recover the more detailed information.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ncoghlan
stage:  -> needs patch
title: function generate_tokens at tokenize.py yields wrong token for colon -> Add new attribute to TokenInfo to report specific token IDs
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec 15 03:06:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 02:06:27 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323914787.82.0.905702258784.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I believe that that list includes all symbols and symbol combinations that are syntactically significant in expressions. This is the generalized meaning of 'operator' that is being used. What do not appear are '#' which marks comments, '_' which is a name char, and '\' which escapes chars within strings. Other symbols within strings will also not be marked as OP tokens. The non-syntactic symbols '$' and '?' are also omitted.

----------

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

From report at bugs.python.org  Thu Dec 15 04:16:53 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 03:16:53 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323919013.83.0.854406512576.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Sure, but what does that have to do with anything? tokenize isn't a general purpose tokenizer, it's specifically for tokenizing Python source code.

The *problem* is that it doesn't currently fully tokenize everything, but doesn't explicitly say that in the module documentation.

Hence my proposed two-fold fix: document the current behaviour explicitly and also add a separate "exact_type" attribute for easy access to the detailed tokenization without doing your own string comparisons.

----------

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

From report at bugs.python.org  Thu Dec 15 05:27:24 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 04:27:24 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323923244.56.0.598142598499.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.3
Added file: http://bugs.python.org/file23961/pep-0393.txt

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

From report at bugs.python.org  Thu Dec 15 06:03:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 05:03:52 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323925431.99.0.243567390098.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If you are responding to me, I am baffled. I gave a concise way to document the current behavior with respect to .OP, which you said you wanted.

----------

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

From report at bugs.python.org  Thu Dec 15 06:48:32 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2011 05:48:32 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323928112.43.0.498634176463.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Ah, I didn't read it as suggested documentation at all - you moved seamlessly from personal commentary to a docs suggestion without separating the two, so it appeared to be a complete non sequitur to me.

As for the docs suggestion, I think it works as the explanation of which tokens are affected once the concept of the token stream simplification is introduced:
=====
To simplify token stream handling, all literal tokens (':', '{', etc) are returned using the generic 'OP' token type. This allows them to be simply handled using common code paths (e.g. for literal transcription directly from input to output). Specific tokens can be distinguished by checking the "string" attribute of OP tokens for a match with the expected character sequence.

The affected tokens are all symbols and symbol combinations that are syntactically significant in expressions (as listed in the token module). Anything which is not an independent token (i.e. '#' which marks comments, '_' which is just part of a name, '\' which is used for line continuations, the contents of string literals and any symbols which are not a defined part of Python's syntax) is completely unaffected by this difference in behaviour.
===========

If "exact_type" is introduced in 3.3, then the first paragraph can be adjusted accordingly.

----------

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

From report at bugs.python.org  Thu Dec 15 08:09:33 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Thu, 15 Dec 2011 07:09:33 +0000
Subject: [docs] [issue13402] Document absoluteness of sys.executable
In-Reply-To: <1321289437.84.0.982753479785.issue13402@psf.upfronthosting.co.za>
Message-ID: <1323932973.7.0.563445719031.issue13402@psf.upfronthosting.co.za>


Petri Lehtinen <petri at digip.org> added the comment:

> sys.executable can be None on Jython (and I believe IronPython) when ran in an 'embedded' mode

In CPython, embedding doesn't change the behavior.

----------

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

From report at bugs.python.org  Thu Dec 15 10:58:42 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 09:58:42 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323943122.05.0.916948465181.issue13604@psf.upfronthosting.co.za>


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


----------
nosy: +haypo, loewis
stage:  -> patch review

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

From report at bugs.python.org  Thu Dec 15 11:16:39 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:16:39 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1323944198.95.0.291707373871.issue13540@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry about being out of contact (I'm flying back and forth between the US and the EU every 4-5 weeks right now), and thanks Terry for bringing this to my attention.

Essentially, the API is:

* The argument to action= must be a callable that accepts at least a "dest" and "option_strings" keyword arguments, and returns some object. The keyword arguments passed to this callable will be dest, option_strings, and whatever other keyword arguments were passed to add_argument().

* The object returned by the action= callable should have attributes "dest", "option_strings", "default", "type", "required", "help", etc. defined in essentially the same way as the add_argument() documentation.

* The object returned by the action= callable should itself be callable, and should accept the arguments (self, parser, namespace, values, option_string=None). This method can do whatever it wants, but as you note, the typical approach is to invoke setattr(namespace, self.dest, ...)

Now, all that said, the easiest way of creating a callable that returns an callable where both have the right signatures and the right attributes is to subclass argparse.Action. In fact, doing it any other way is probably crazy. I'm against changing the name of __call__ to invoke because it removes the possibility of defining an action as a function returning another function (which is currently possible), but I'm all for making the documentation strongly recommend subclassing argparse.Action. I would just say something like:

"You may also specify an arbitrary action by passing a subclass of :class:`argparse.Action`, or another callable object that implements the same interface."

I wouldn't bother to go into more detail about "implements the same interface" - all sane people will just subclass Action. ;-)

As to argparse.Action.__init__, hopefully the above bullet points make it clear that you must accept "dest" and "option_strings", but what other keyword arguments you want to accept are up to you. Be sure to call the superclass __init__ to set any attributes that you didn't accept to appropriate default values. A simple example of accepting an additional keyword argument is the _VersionAction, which accepts a "version" keyword argument that the other actions don't accept. The current "example of a custom action" should probably define __init__ to show how this works.

----------

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

From report at bugs.python.org  Thu Dec 15 11:49:35 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:49:35 +0000
Subject: [docs] [issue10772] Several actions for argparse arguments missing
	from docs
In-Reply-To: <1293327184.11.0.454888760887.issue10772@psf.upfronthosting.co.za>
Message-ID: <1323946175.68.0.00573172519504.issue10772@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me too.

----------

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

From report at bugs.python.org  Thu Dec 15 11:56:44 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 10:56:44 +0000
Subject: [docs] [issue13249] argparse.ArgumentParser() lists arguments in
	the wrong	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1323946604.5.0.632195866467.issue13249@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The ArgumentParser constructor is definitely only intended to be called with keyword arguments, so it's definitely a documentation bug that it doesn't say this. I haven't actually applied the patch, but the basic approach and wording look fine to me.

----------

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

From report at bugs.python.org  Thu Dec 15 13:19:31 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:19:31 +0000
Subject: [docs] [issue12686] argparse - document (and improve?) use of
	SUPPRESS with	help=
In-Reply-To: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>
Message-ID: <1323951571.63.0.997818317045.issue12686@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Could you give some examples of bugs that you observed? Otherwise, this looks like a duplicate of issue 9349.

The intention is that help=SUPPRESS should cause the given argument to not be displayed in the help message. If there are cases where that's not true, then it's definitely a bug.

----------

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

From report at bugs.python.org  Thu Dec 15 13:36:05 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 12:36:05 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1323952565.19.0.681928894785.issue9938@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Thu Dec 15 14:04:10 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 13:04:10 +0000
Subject: [docs] [issue11807] Documentation of add_subparsers lacks
	information about	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1323954250.85.0.805684910473.issue11807@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good. A few minor comments (click "review" by the patch).

----------

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

From report at bugs.python.org  Thu Dec 15 14:28:30 2011
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 15 Dec 2011 13:28:30 +0000
Subject: [docs] [issue13605] document argparse's nargs=REMAINDER
Message-ID: <1323955710.42.0.753468095058.issue13605@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

There is an undocumented value for add_argument's nargs parameter, REMAINDER, which can be used to consume all the remaining arguments. This is commonly useful for command line utilities that dispatch to other command line utilities.

Though undocumented, it has been used successfully by at least a few different people:

http://stackoverflow.com/questions/5826881/how-to-use-argparse-to-collect-arguments-for-a-separate-command-line-without

http://code.google.com/p/argparse/issues/detail?id=52

And I just received an email from yet another user who used it successfully.

So I think it's time to graduate this from a hidden feature to a real documented one.

----------
assignee: docs at python
components: Documentation
messages: 149552
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: document argparse's nargs=REMAINDER
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Dec 15 15:03:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2011 14:03:43 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323957823.18.0.0570232959902.issue13604@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Various comments of the PEP 393 and your patch.

"For compatibility with existing APIs, several representations
may exist in parallel; over time, this compatibility should be phased
out."
and
"For compatibility, redundant representations may be computed."

I never understood this statement: in most cases, PyUnicode_READY() replaces the Py_UNICODE* (wchar_t*) representation by a compact representation.

PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_GET_SIZE(), ... do reallocate a Py_UNICODE* string for a ready string, but I don't think that it is a usual use case. 
PyUnicode_AS_UNICODE() & friends are usually only used to build strings. So this issue should be documented in a section different than the Abstract, maybe in a Limitations section.

So even if a third party module uses the legagy Unicode API, the PEP 393 will still optimize the memory usage thanks to implicit calls to PyUnicode_READY() (done everywhere in Python source code).

In the current code, the most common case where a string has two representations is the conversion to wchar_t* on Windows. PyUnicode_AsUnicode() is used to encode arguments for the Windows Unicode API, and PyUnicode_AsUnicode() keeps the result in the wstr attribute.

Note: there is also the utf8 attribute which may contain a third representation if PyUnicode_AsUTF8() or PyUnicode_AsUTF8AndSize() (or the old _PyUnicode_AsString()) is called.

"Objects for which the maximum character is not given at creation time are called "legacy" objects, created through PyUnicode_FromStringAndSize(NULL, length)."

They can also be created by PyUnicode_FromUnicode().

"Resizing a Unicode string remains possible until it is finalized, generally by calling PyUnicode_READY."

I changed PyUnicode_Resize(): it is now *always* possible to resize a string. The change was required because some decoders overallocate the string, and then resize after decoding the input.

The sentence can be simply removed.

+    + 000 => str is not initialized (data are in wstr)
+    + 001 => 1 byte (Latin-1)
+    + 010 => 2 byte (UCS-2)
+    + 100 => 4 byte (UCS-4)
+    + Other values are reserved at this time.

I don't like binary numbers, I would prefer decimal numbers here. Binary was maybe useful when we used bit masks, but we are now using the C "unsigned int field:bit_size;" trick for a nicer API. With the new values, it is even easier to remember them:

 1 byte <=> kind=1
 2 bytes <=> kind=2
 4 bytes <=> kind=4

"[PyUnicode_AsUTF8] is thus identical to the existing _PyUnicode_AsString, which is removed"

_PyUnicode_AsString() does still exist and is still heavily used (66 calls). It is not documented as deprecated in What's New in Python 3.3 (but it is a private function, so nobody uses it, right?.

"This section summarizes the API additions."

PyUnicode_IS_ASCII() is missing.

PyUnicode_CHARACTER_SIZE() has been removed (use kind directly).

UCS4 utility functions:

Py_UCS4_{strlen, strcpy, strcat, strncpy, strcmp, strncpy, strcmp, strncmp, strchr, strrchr} have been removed.


"The following functions are added to the stable ABI (PEP 384), as they
are independent of the actual representation of Unicode objects: ...
... PyUnicode_WriteChar ...."

PyUnicode_WriteChar() allows to modify an immutable object, which is something specific to CPython. Well, the function does now raise an error if the string is no more modifiable (e.g. more than 1 reference to the string, the hash has already been computed, etc.), but I don't know if it should be added to the stable ABI.

"PyUnicode_AsUnicodeAndSize"

This function was added to Python 3.3 and is directly deprecated. Why adding a function to deprecate it? PyUnicode_AsUnicode() and PyUnicode_GET_SIZE() were not enough?

"Deprecations, Removals, and Incompatibilities"

Missing: PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp


--

A very important point is not well explained: it is very important that a ("final") string is in its canonical representation. It means that a UCS2 string must contain at least a character bigger than U+00FF for example. Not only some optimizations rely on the canonical representation, but also some core methods of the Unicode type.

I tried to list all properties of Unicode objects in the definition of the PyASCIIbject structure. And I implemented checks in _PyUnicode_CheckConsistency(). This method is only available in debug mode.

----------

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

From report at bugs.python.org  Thu Dec 15 16:26:32 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2011 15:26:32 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <E1RbDCY-00015J-Ut@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 313fa7ea6c79 by Antoine Pitrou in branch '3.2':
Issue #13597: Improve documentation of standard streams.
http://hg.python.org/cpython/rev/313fa7ea6c79

New changeset 7343730185a3 by Antoine Pitrou in branch 'default':
Issue #13597: Improve documentation of standard streams.
http://hg.python.org/cpython/rev/7343730185a3

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

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

From report at bugs.python.org  Thu Dec 15 16:27:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 15 Dec 2011 15:27:55 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1323962875.37.0.795666701273.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Should be ok now.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Dec 15 19:42:53 2011
From: report at bugs.python.org (Meador Inge)
Date: Thu, 15 Dec 2011 18:42:53 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323974573.39.0.111466174681.issue2134@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

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

From report at bugs.python.org  Thu Dec 15 20:22:21 2011
From: report at bugs.python.org (Eric Snow)
Date: Thu, 15 Dec 2011 19:22:21 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323976941.51.0.999216192837.issue2134@psf.upfronthosting.co.za>


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


----------
nosy: +eric.snow

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

From report at bugs.python.org  Thu Dec 15 22:15:34 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 21:15:34 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323983734.9.0.354172604735.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23968/pep-0393.txt

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

From report at bugs.python.org  Thu Dec 15 22:20:48 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 15 Dec 2011 21:20:48 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323984048.71.0.813354803625.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

Updated to resolve most of Victor's concerns, but this meant enough changes that I'm not sure it quite counts as editorial only.

A few questions that I couldn't answer:

(1)  Upon string creation, do we want to *promise* to discard the UTF-8 and wstr, so that the caller can memory manage?

(2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp seemed to be there in the code I was looking at.

(3)  I can't justify the born-deprecated function "PyUnicode_AsUnicodeAndSize".  Perhaps rename it with a leading underscore?  Though I'm not sure it is really needed at all.

(4)  I tried to reword the "for compatibility" ... "redundant" part ... but I'm not sure I resolved it.

----------

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

From report at bugs.python.org  Thu Dec 15 23:02:11 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 15 Dec 2011 22:02:11 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323986531.89.0.79873254354.issue2134@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Both the proposed text and 3.3 addition look good to me.

----------

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

From report at bugs.python.org  Thu Dec 15 23:18:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 15 Dec 2011 22:18:25 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1323987505.29.0.740732419141.issue2134@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/issue2134>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:45:27 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Dec 2011 22:45:27 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323957823.18.0.0570232959902.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEA7885.2070206@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> PyUnicode_AsUnicode(), PyUnicode_AS_UNICODE(), PyUnicode_GET_SIZE(),
> ... do reallocate a Py_UNICODE* string for a ready string, but I
> don't think that it is a usual use case.

Define "usual". There were certainly plenty of occurrences of that
in the Python code base, and I believe that extension modules also
use it, provided they care about the content of string objects at all.

> PyUnicode_AS_UNICODE() &
> friends are usually only used to build strings.

No. They are also used to inspect them.

> So even if a third party module uses the legagy Unicode API, the PEP
> 393 will still optimize the memory usage thanks to implicit calls to
> PyUnicode_READY() (done everywhere in Python source code).

... unless they inspect a given Unicode string, in which case it
will use twice the memory (or 1.5x).

> "Resizing a Unicode string remains possible until it is finalized,
> generally by calling PyUnicode_READY."
> 
> I changed PyUnicode_Resize(): it is now *always* possible to resize a
> string. The change was required because some decoders overallocate
> the string, and then resize after decoding the input.
> 
> The sentence can be simply removed.

Well, I meant the resizing of strings that doesn't move the object
in memory (i.e. unicode_resize). You (apparently) changed its signature
to take PyUnicode_Object** (instead of PyUnicode_Object*). It's probably
irrelevant since that's a unicodeobject.c-internal function, anyway.

> "PyUnicode_AsUnicodeAndSize"
> 
> This function was added to Python 3.3 and is directly deprecated. Why
> adding a function to deprecate it? PyUnicode_AsUnicode() and
> PyUnicode_GET_SIZE() were not enough?

If it was not in 3.2, we should certainly remove it right away.

----------

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

From report at bugs.python.org  Thu Dec 15 23:50:05 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 15 Dec 2011 22:50:05 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323984048.71.0.813354803625.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEA799B.7080009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> (1)  Upon string creation, do we want to *promise* to discard the UTF-8 and wstr, so that the caller can memory manage?

I don't understand the question. Assuming "discards" means "releases"
here, then there is no API which releases memory during creation of
the string object - let alone that there is any promise to do so. I'm
also not aware of any candidate buffer that you might want to release.

> (2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp seemed to be there in the code I was looking at.

That's very well possible. What's the question?

> (3)  I can't justify the born-deprecated function "PyUnicode_AsUnicodeAndSize".  Perhaps rename it with a leading underscore?  Though I'm not sure it is really needed at all.

Nobody noticed that it is born-deprecated. If it really is, it should be
removed before the release.

----------

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

From report at bugs.python.org  Fri Dec 16 01:34:32 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:34:32 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323995670.92.0.499848201076.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

>> So even if a third party module uses the legagy Unicode API, the PEP
>> 393 will still optimize the memory usage thanks to implicit calls to
>> PyUnicode_READY() (done everywhere in Python source code).

> ... unless they inspect a given Unicode string, in which case it
> will use twice the memory (or 1.5x).

Why is the utf-8 representation not cached when it is generated for ParseTuple et alia?

It seems like these parameters are likely to either be re-used as parameters (in which case caching makes sense) or not re-used at all (in which case, the whole string can go away).

> Well, I meant the resizing of strings that doesn't move the object
> in memory (i.e. unicode_resize).

This may easily fail because the new size can't be found at that location; wouldn't it be better to just encourage proper sizing in the first place?

>> (1)  Upon string creation, do we want to *promise* to discard
>> the UTF-8 and wstr, so that the caller can memory manage?

> I don't understand the question. Assuming "discards" means
> "releases" here, then there is no API which releases memory
> during creation of the string object - let alone that there is
> any promise to do so. I'm also not aware of any candidate buffer
> that you might want to release.

When a string is created from a wchar_t array, who is responsible for releasing the original wchar_t array?  As I read it now, Python doesn't release the buffer, and the caller can't because maybe Python just pointed to it as memory shared with the canonical representation.  

>> (2)  PyUnicode_AS_DATA(), Py_UNICODE_strncpy, Py_UNICODE_strncmp 
>> seemed to be there in the code I was looking at.

> That's very well possible. What's the question?

Victor listed them as missing.  I now suspect he meant "missing from the PEP list of deprecated functions and macros", and I just misunderstood.

----------
Added file: http://bugs.python.org/file23970/pep-0393.txt

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

From report at bugs.python.org  Fri Dec 16 01:38:51 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 00:38:51 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1323995931.55.0.454843568053.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23971/pep-0393v20111215.patch

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

From report at bugs.python.org  Fri Dec 16 06:41:31 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 05:41:31 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323995670.92.0.499848201076.issue13604@psf.upfronthosting.co.za>
Message-ID: <4EEADA09.7080405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Why is the utf-8 representation not cached when it is generated for
> ParseTuple et alia?

It is.

> When a string is created from a wchar_t array, who is responsible for
> releasing the original wchar_t array?

The caller.

> As I read it now, Python
> doesn't release the buffer, and the caller can't because maybe Python
> just pointed to it as memory shared with the canonical
> representation.

But Python won't; it will always make a copy for itself.

----------

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

From report at bugs.python.org  Fri Dec 16 10:29:17 2011
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 16 Dec 2011 09:29:17 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1324027756.83.0.832480259647.issue11379@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I started a mailing list thread on the same topic:

http://thread.gmane.org/gmane.comp.python.devel/127963

Especially see

http://thread.gmane.org/gmane.comp.python.devel/127963/focus=128162

where I extract a proposal from the discussion. Basically, there should be a note at the top of the xml.dom documentation as follows:

"""
[[Note: The xml.dom.minidom module provides an implementation of the W3C-DOM whose API is similar to that in other programming languages. Users who are unfamiliar with the W3C-DOM interface or who would like to write less code for processing XML files should consider using the xml.etree.ElementTree module instead.]]
"""

I think this should go on the xml.dom.minidom page as well as the xml.dom package page. Hand-wavingly, users who are new to the DOM are more likely to hit the package page first, whereas those who know it already will likely find the MiniDOM page directly.

Note that I'd still encourage the removal of the misleading word "lightweight" until it makes sense to put it back in a meaningful way. I therefore propose the following minimalistic changes to the first paragraph on the minidom page:

"""
xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface. It is intended to be simpler than the full DOM and also [+XXX: provide a] significantly smaller [+XXX: API].
"""

Additionally, the documentation on the xml.sax page would benefit from the following paragraph:

"""
[[Note: The xml.sax package provides an implementation of the SAX interface whose API is similar to that in other programming languages. Users who are unfamiliar with the SAX interface or who would like to write less code for efficient stream processing of XML files should consider using the iterparse() function in the xml.etree.ElementTree module instead.]]
"""

----------

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

From report at bugs.python.org  Fri Dec 16 12:09:21 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 11:09:21 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1299093908.17.0.828802315354.issue11379@psf.upfronthosting.co.za>
Message-ID: <1324033761.17.0.903654175636.issue11379@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> xml.dom.minidom is a [-XXX: light-weight] implementation of the Document Object Model interface.

This is ok.

> It is intended to be simpler than the full DOM and also
> [+XXX: provide a] significantly smaller [+XXX: API].

Doesn't "simpler" here refer to the API already?

Another option is to add somewhere a section like:
"If you have to work with XML, ElementTree is usually the best choice, because it has a simple API and it's efficient [or whatever].  xml.dom.minidom provides a subset of the W3C-DOM API, and xml.sax a SAX interface.", possibly expanding a bit on the differences and showing a minimal example with the 3 different implementations, and then link to it from the other modules' pages.

----------

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

From report at bugs.python.org  Fri Dec 16 13:58:01 2011
From: report at bugs.python.org (Edmund Eyles)
Date: Fri, 16 Dec 2011 12:58:01 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
Message-ID: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>


New submission from Edmund Eyles <hotel at heddonsgate.co.uk>:

The documentation for Python 2.7.2 has a section of examples for the regular expression match() function, based on a poker hand, at section 7.2.6.1.  These examples show a suit of cards as having 14 cards!  The ace is counted twice, as '1' and 'a'.  Remind me not to play poker against the author.  

I would suggest changing the range of the characters that represent the cards' denominations to [2-9tjqka], with a 't' representing a 10, rather than using a '0', and not using either the '0' or the '1'.

----------
assignee: docs at python
components: Documentation
messages: 149619
nosy: Eddie E, docs at python
priority: normal
severity: normal
status: open
title: Small error in regular expression poker hand example
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Dec 16 14:11:46 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:11:46 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324041106.82.0.859152737249.issue13613@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ezio.melotti
keywords: +patch
nosy: +ezio.melotti
stage:  -> commit review
type: behavior -> enhancement
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23977/issue13613.diff

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

From report at bugs.python.org  Fri Dec 16 14:27:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:27:58 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324042078.31.0.895368580077.issue13613@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file23977/issue13613.diff

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

From report at bugs.python.org  Fri Dec 16 14:28:18 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 13:28:18 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324042098.07.0.889145331491.issue13613@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file23978/issue13613.diff

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

From report at bugs.python.org  Fri Dec 16 14:50:21 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 13:50:21 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324043420.57.0.997600776979.issue13604@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

>> Why is the utf-8 representation not cached when it is generated for
>> ParseTuple et alia?

My error -- I read something backwards.

>> When a string is created from a wchar_t array, who is responsible for
>> releasing the original wchar_t array?

> The caller.

OK, I'll document that.

>> As I read it now, Python
>> doesn't release the buffer, and the caller can't because maybe Python
>> just pointed to it as memory shared with the canonical
>> representation.

> But Python won't; it will always make a copy for itself.

I thought I found an example each way, but it is possible that the shared version was something python had already copied.  If not, I'll raise that as a separate issue to get the code changed.

(Note that I may not be able to look at this again until after Christmas, so I'm likely to go silent for a while.)

----------
Added file: http://bugs.python.org/file23979/pep-0393.txt

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

From report at bugs.python.org  Fri Dec 16 14:51:04 2011
From: report at bugs.python.org (Edmund Eyles)
Date: Fri, 16 Dec 2011 13:51:04 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324042098.07.0.889145331491.issue13613@psf.upfronthosting.co.za>
Message-ID: <4EEB4CCD.3090800@heddonsgate.co.uk>


Edmund Eyles <hotel at heddonsgate.co.uk> added the comment:

Changes proposed in file 23978 look good to me!

On 16/12/2011 13:28, Ezio Melotti wrote:
>
> Changes by Ezio Melotti<ezio.melotti at gmail.com>:
>
>
> Added file: http://bugs.python.org/file23978/issue13613.diff
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue13613>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Dec 16 14:52:38 2011
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 16 Dec 2011 13:52:38 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324043558.98.0.186132282802.issue13604@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


Added file: http://bugs.python.org/file23980/pep-0393_20111216.txt.patch

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

From report at bugs.python.org  Fri Dec 16 17:02:33 2011
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 16 Dec 2011 16:02:33 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1324051353.6.0.960734381911.issue13604@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Fri Dec 16 18:59:07 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 16 Dec 2011 17:59:07 +0000
Subject: [docs] [issue11379] Remove "lightweight" from minidom description
In-Reply-To: <1324033761.17.0.903654175636.issue11379@psf.upfronthosting.co.za>
Message-ID: <4EEB86E9.7070802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> "If you have to work with XML, ElementTree is usually the best
> choice, because it has a simple API and it's efficient [or whatever].

I still object such a wording, for many reasons.

----------

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

From report at bugs.python.org  Sat Dec 17 00:20:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2011 23:20:23 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <E1Rbh4f-0003mF-K0@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 766a21ebf82e by Ezio Melotti in branch '2.7':
#13613: fix example in re doc.
http://hg.python.org/cpython/rev/766a21ebf82e

New changeset 0b86da9d6964 by Ezio Melotti in branch '3.2':
#13613: fix example in re doc.
http://hg.python.org/cpython/rev/0b86da9d6964

New changeset f2e1867f33b8 by Ezio Melotti in branch 'default':
#13613: merge with 3.2.
http://hg.python.org/cpython/rev/f2e1867f33b8

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

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

From report at bugs.python.org  Sat Dec 17 00:22:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 16 Dec 2011 23:22:17 +0000
Subject: [docs] [issue13613] Small error in regular expression poker hand
	example
In-Reply-To: <1324040280.95.0.88061677389.issue13613@psf.upfronthosting.co.za>
Message-ID: <1324077737.46.0.913117209608.issue13613@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report!

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec 17 01:03:18 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:03:18 +0000
Subject: [docs] [issue13587] Correcting the typos error in
	Doc/howto/urllib2.rst
In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>
Message-ID: <1324080198.68.0.604965258924.issue13587@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Sat Dec 17 01:06:56 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2011 00:06:56 +0000
Subject: [docs] [issue13587] Correcting the typos error in
	Doc/howto/urllib2.rst
In-Reply-To: <1323693654.01.0.260479490427.issue13587@psf.upfronthosting.co.za>
Message-ID: <1324080415.99.0.065549799555.issue13587@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Error is in 3.2 docs as well.

2.6/3.1 only get security patches. 3.4 is for future enhancements what will not even go into 3.3.

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

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

From rrt at sc3d.org  Wed Dec 14 17:54:30 2011
From: rrt at sc3d.org (Reuben Thomas)
Date: Wed, 14 Dec 2011 16:54:30 +0000
Subject: [docs] Confusion in os.path documentation
Message-ID: <CAOnWdoh6mJVSo43QSBS6rq3KZQdHMe2jb3ReeuG56KOtc5WwGA@mail.gmail.com>

In the following, from the os.path documentation, the second sentence
sounds like it?s referring to a consequence of the first, but it?s
not: normalizing paths containing symbolic links can change their
meaning:
"On Windows, it converts forward slashes to backward slashes. It
should be understood that this may change the meaning of the path if
it contains symbolic links!"
Hence, I suggest the following rewrite:
"On Windows, it converts forward slashes to backward slashes. Note
that normpath() may change the meaning of the path if it contains
symbolic links!"
-- 
http://rrt.sc3d.org

From zwegner at gmail.com  Fri Dec 16 04:03:38 2011
From: zwegner at gmail.com (Zach Wegner)
Date: Thu, 15 Dec 2011 19:03:38 -0800
Subject: [docs] documentation error w/ evaluation order
Message-ID: <CAF=CVUKhProUj5bXe8GD8uzOa525PKgOaZt0Oq_jszEZFxvfkw@mail.gmail.com>

In http://docs.python.org/reference/expressions.html#evaluation-order,
there's a table that contains this entry, giving the order of
evaluation for dict literals:

{expr1: expr2, expr3: expr4}

However, for each item, the value is evaluated before the key, like so:

def ev(r):
    print(r)
    return r

{ev(1): ev(2), ev(3): ev(4)}

prints (under 3.2.2):

2
1
4
3

Thanks,
Zach

From rrt at sc3d.org  Wed Dec 14 17:56:18 2011
From: rrt at sc3d.org (Reuben Thomas)
Date: Wed, 14 Dec 2011 16:56:18 +0000
Subject: [docs] simple_stmts.html improvement
Message-ID: <CAOnWdohFeAoOQDVy=RdgKczfFZU4LYNYA0oTthdc-u0pm3YJ-Q@mail.gmail.com>

In simple_stmts.html?s documentation of del:

"Rather that spelling it out in full details, here are some hints."
would be better
"Rather than spelling it out, here are some hints."
-- 
http://rrt.sc3d.org

From report at bugs.python.org  Sat Dec 17 16:29:43 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 15:29:43 +0000
Subject: [docs] [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324135783.69.0.287983452641.issue11231@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oooh, I missed the important sentence "Accordingly, constructor arguments are interpreted as for bytearray()." The 5 constructors are documented in bytearray doc:

http://docs.python.org/dev/library/functions.html#bytearray

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

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

From report at bugs.python.org  Sat Dec 17 17:24:44 2011
From: report at bugs.python.org (=?utf-8?b?SsOpcsOpbXkgQW5nZXI=?=)
Date: Sat, 17 Dec 2011 16:24:44 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324139084.74.0.908906173157.issue13530@psf.upfronthosting.co.za>


J?r?my Anger <kidanger at gmail.com> added the comment:

Here is a patch which add the return value of lseek into the documentation.

----------
nosy: +kidanger
Added file: http://bugs.python.org/file23988/patch

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

From report at bugs.python.org  Sat Dec 17 17:45:53 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 16:45:53 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324140353.84.0.178749521866.issue13530@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Sat Dec 17 18:09:06 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:09:06 +0000
Subject: [docs] [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324141745.91.0.85783112134.issue11231@psf.upfronthosting.co.za>


brendel <brice.berna at gmail.com> added the comment:

Here is a patch for the docstring of bytes and bytesarray.

----------
nosy: +brendel
Added file: http://bugs.python.org/file23989/patch

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

From report at bugs.python.org  Sat Dec 17 18:17:58 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:17:58 +0000
Subject: [docs] [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324142278.1.0.342376601506.issue11231@psf.upfronthosting.co.za>


Changes by brendel <brice.berna at gmail.com>:


Removed file: http://bugs.python.org/file23989/patch

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

From report at bugs.python.org  Sat Dec 17 18:20:56 2011
From: report at bugs.python.org (brendel)
Date: Sat, 17 Dec 2011 17:20:56 +0000
Subject: [docs] [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <1324142456.36.0.219549379676.issue11231@psf.upfronthosting.co.za>


Changes by brendel <brice.berna at gmail.com>:


Added file: http://bugs.python.org/file23990/patch

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

From report at bugs.python.org  Sat Dec 17 19:07:26 2011
From: report at bugs.python.org (misdre)
Date: Sat, 17 Dec 2011 18:07:26 +0000
Subject: [docs] [issue13561] os.listdir documentation should mention
	surrogateescape
In-Reply-To: <1323395400.31.0.796436036954.issue13561@psf.upfronthosting.co.za>
Message-ID: <1324145246.02.0.0221603578014.issue13561@psf.upfronthosting.co.za>


misdre <misdre+python at gmail.com> added the comment:

Added a small patch to mention surrogateescape and PEP 383.

----------
keywords: +patch
nosy: +misdre
Added file: http://bugs.python.org/file23998/listdir-pep383.patch

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

From report at bugs.python.org  Sat Dec 17 23:13:53 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 22:13:53 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <E1Rc2Vs-0003u3-25@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 46c418d8a480 by Victor Stinner in branch '3.2':
Issue #13530: Document os.lseek() result
http://hg.python.org/cpython/rev/46c418d8a480

New changeset b05caa600c40 by Victor Stinner in branch 'default':
Issue #13530: Document os.lseek() result
http://hg.python.org/cpython/rev/b05caa600c40

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

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

From report at bugs.python.org  Sat Dec 17 23:14:10 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 22:14:10 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324160050.0.0.0617950492022.issue13530@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 17 23:14:19 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2011 22:14:19 +0000
Subject: [docs] [issue13530] Docs for os.lseek neglect to mention what it
	returns
In-Reply-To: <1323055618.88.0.0662410004901.issue13530@psf.upfronthosting.co.za>
Message-ID: <1324160058.93.0.80948369742.issue13530@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Thanks for the patch J?r?my.

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

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

From report at bugs.python.org  Sat Dec 17 23:16:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2011 22:16:58 +0000
Subject: [docs] [issue11231] bytes() constructor is not correctly documented
In-Reply-To: <1297961204.12.0.402679870877.issue11231@psf.upfronthosting.co.za>
Message-ID: <E1Rc2Yr-0004In-0F@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset beac7d6c7be4 by Victor Stinner in branch '3.2':
Issue #11231: Fix bytes and bytearray docstrings
http://hg.python.org/cpython/rev/beac7d6c7be4

New changeset dc670add1e28 by Victor Stinner in branch 'default':
Issue #11231: Fix bytes and bytearray docstrings
http://hg.python.org/cpython/rev/dc670add1e28

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

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

From report at bugs.python.org  Sat Dec 17 23:31:45 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sat, 17 Dec 2011 22:31:45 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324161105.28.0.857975505912.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Hi,

Here is the patch I propose for this issue. This is my first attempt to contribute to Python, so please don't hit me too hard if I did something wrong. :)

When browsing the source code of complexobject.c, I also noticed that the return values of the _Py_c_quot and _Py_c_pow (which return zero in case of error) weren't documented at 

http://docs.python.org/dev/c-api/complex.html#_Py_c_quot

----------
nosy: +arnaudc
Added file: http://bugs.python.org/file24007/patch

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

From report at bugs.python.org  Sat Dec 17 23:47:05 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 17 Dec 2011 22:47:05 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324162025.27.0.657002744237.issue13522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a typo in the patch: it's PyErr_Occurred (two r's), not PyErr_Occured.
Otherwise, looks good to me.

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

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

From report at bugs.python.org  Sun Dec 18 00:05:47 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sat, 17 Dec 2011 23:05:47 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324163147.48.0.303985586938.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

I fixed the typo and the markup.

----------
Added file: http://bugs.python.org/file24009/patch

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

From report at bugs.python.org  Sun Dec 18 01:29:12 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 00:29:12 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1Rc4ce-0007Ke-FZ@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 68cbf6551710 by Antoine Pitrou in branch '3.2':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/68cbf6551710

New changeset 1f096611baf4 by Antoine Pitrou in branch 'default':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/1f096611baf4

New changeset 059e4d752fbe by Antoine Pitrou in branch '2.7':
Issue #13522: document error return values of some float and complex C API functions.
http://hg.python.org/cpython/rev/059e4d752fbe

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

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

From report at bugs.python.org  Sun Dec 18 01:30:09 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 18 Dec 2011 00:30:09 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324168209.38.0.567769453516.issue13522@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed now. Thank you for the patch!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Dec 18 01:46:36 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 00:46:36 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324169196.77.0.976411153859.issue13522@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_Py_c_pow() doc is wrong:

+   If :attr:`exp.imag` is not null, or :attr:`exp.real` is negative,
+   this method returns zero and sets :c:data:`errno` to :c:data:`EDOM`.

The function only fails if num=0 and exp.real < 0 or if num=0 and exp.imag != 0.

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

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

From report at bugs.python.org  Sun Dec 18 02:13:14 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 01:13:14 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324170794.82.0.350430525613.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Fixed.

----------
Added file: http://bugs.python.org/file24014/diff_complex_rst

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

From report at bugs.python.org  Sun Dec 18 02:50:31 2011
From: report at bugs.python.org (Arnaud Calmettes)
Date: Sun, 18 Dec 2011 01:50:31 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324173031.18.0.908892658186.issue13522@psf.upfronthosting.co.za>


Arnaud Calmettes <calmettes.arnaud at gmail.com> added the comment:

Previous patch was also wrong, sorry!

----------
keywords: +patch
Added file: http://bugs.python.org/file24015/complex.rst-2.patch

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

From report at bugs.python.org  Sun Dec 18 02:54:28 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 01:54:28 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1Rc5xL-0003WK-By@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 67a4e8fe650e by Victor Stinner in branch 'default':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/67a4e8fe650e

----------

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

From report at bugs.python.org  Sun Dec 18 02:54:48 2011
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 18 Dec 2011 01:54:48 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <1324173288.64.0.0844377032658.issue13522@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Dec 18 12:32:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2011 11:32:15 +0000
Subject: [docs] [issue13522] Document error return values for PyFloat_*
	and	PyComplex_*
In-Reply-To: <1322914129.32.0.821856252143.issue13522@psf.upfronthosting.co.za>
Message-ID: <E1RcEvR-0004Wx-M4@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset edc981ce8748 by Victor Stinner in branch '3.2':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/edc981ce8748

New changeset 2863470caebb by Victor Stinner in branch '2.7':
Issue #13522: Fix _Py_co_pow() documentation
http://hg.python.org/cpython/rev/2863470caebb

----------

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

From report at bugs.python.org  Sun Dec 18 23:35:51 2011
From: report at bugs.python.org (=?utf-8?q?Filip_Gruszczy=C5=84ski?=)
Date: Sun, 18 Dec 2011 22:35:51 +0000
Subject: [docs] [issue11807] Documentation of add_subparsers lacks
	information about	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1324247751.34.0.866460550027.issue11807@psf.upfronthosting.co.za>


Filip Gruszczy?ski <gruszczy at gmail.com> added the comment:

Fixed patch.

----------
Added file: http://bugs.python.org/file24042/11807_2.patch

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

From report at bugs.python.org  Mon Dec 19 05:51:23 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 04:51:23 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324270283.73.0.22714523648.issue2134@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The proposed documentation text seems too complicated and language expert speaky to me.  We should try to link to standard definitions when possible to reduce the text here.  For example, I believe the "Operators" and "Delimiters" tokens in the "Lexical Analysis" section of the docs (http://docs.python.org/dev/reference/lexical_analysis.html#operators) are exactly what we are trying to describe when referencing "literal tokens" and "affected tokens".

I like Nick's idea to introduce a new attribute for the exact type, while keeping the tuple structure itself backwards compatible.  Attached is a patch for 3.3 that updates the docs, adds exact_type, adds new unit tests, and adds a new CLI option for displaying token names using the exact type.

An example of the new CLI option is:

$ echo '1+2**4' | ./python -m tokenize
1,0-1,1:            NUMBER         '1'            
1,1-1,2:            OP             '+'            
1,2-1,3:            NUMBER         '2'            
1,3-1,5:            OP             '**'           
1,5-1,6:            NUMBER         '4'            
1,6-1,7:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''             
$ echo '1+2**4' | ./python -m tokenize -e
1,0-1,1:            NUMBER         '1'            
1,1-1,2:            PLUS           '+'            
1,2-1,3:            NUMBER         '2'            
1,3-1,5:            DOUBLESTAR     '**'           
1,5-1,6:            NUMBER         '4'            
1,6-1,7:            NEWLINE        '\n'           
2,0-2,0:            ENDMARKER      ''

----------
Added file: http://bugs.python.org/file24045/tokenize-exact-type-v0.patch

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

From report at bugs.python.org  Mon Dec 19 06:07:37 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2011 05:07:37 +0000
Subject: [docs] [issue13387] suggest assertIs(type(obj),
	cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <E1RcVRX-00009Z-Kl@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 88aacd3541ae by Ezio Melotti in branch '2.7':
#13387: rephrase unclear sentence.
http://hg.python.org/cpython/rev/88aacd3541ae

New changeset eccb4795767b by Ezio Melotti in branch '3.2':
#13387: rephrase unclear sentence.
http://hg.python.org/cpython/rev/eccb4795767b

New changeset 064854cef999 by Ezio Melotti in branch 'default':
#13387: merge with 3.2.
http://hg.python.org/cpython/rev/064854cef999

----------

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

From report at bugs.python.org  Mon Dec 19 06:08:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 19 Dec 2011 05:08:15 +0000
Subject: [docs] [issue13387] suggest assertIs(type(obj),
	cls) for exact type checking
In-Reply-To: <1321101802.89.0.94542095022.issue13387@psf.upfronthosting.co.za>
Message-ID: <1324271295.43.0.649272564942.issue13387@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed
type: behavior -> enhancement

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

From report at bugs.python.org  Mon Dec 19 06:30:01 2011
From: report at bugs.python.org (Meador Inge)
Date: Mon, 19 Dec 2011 05:30:01 +0000
Subject: [docs] [issue13632] Update token documentation to reflect actual
	token types
Message-ID: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>


New submission from Meador Inge <meadori at gmail.com>:

The current token documentation is out of date with respect to the currently available token types:

Python 3.3.0a0 (default:766136049b44+, Dec 18 2011, 21:54:42) 
[GCC 4.6.2 20111027 (Red Hat 4.6.2-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import token
>>> token.BACKQUOTE
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'BACKQUOTE'
>>> token.RARROW
51
>>> token.ELLIPSIS
52

The attached patch fixes this.  OK?

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: token-docs-v0.patch
keywords: easy, patch
messages: 149818
nosy: docs at python, georg.brandl, meador.inge
priority: low
severity: normal
stage: patch review
status: open
title: Update token documentation to reflect actual token types
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file24046/token-docs-v0.patch

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

From report at bugs.python.org  Mon Dec 19 06:56:17 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Dec 2011 05:56:17 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324274177.78.0.934794407983.issue2134@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Meador's patch looks good to me. The docs change for 2.7 and 3.2 would be similar, just with text like "Specific tokens can be distinguished by checking the ``string`` attribute of OP tokens for a match with the expected character sequence." replacing the reference to the new "exact_type" attribute.

----------

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

From report at bugs.python.org  Mon Dec 19 17:41:16 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2011 16:41:16 +0000
Subject: [docs] [issue13638] PyErr_SetFromErrnoWithFilenameObject is
	undocumented
Message-ID: <1324312876.6.0.318234215993.issue13638@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Its declaration can be found in Include/pyerrors.h.
Same for PyErr_SetExcFromWindowsErrWithFilenameObject.

----------
assignee: docs at python
components: Documentation
messages: 149877
nosy: arnaudc, docs at python, haypo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject is undocumented
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Dec 19 21:05:08 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Mon, 19 Dec 2011 20:05:08 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324325108.04.0.532988665504.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

The changes are good as far as they go, but they only affect the documentation of sys.stderr and sys.stdout. 

I also suggested changes to the documentation of the "-u" flag, and to "What's New in Python 3.0", can someone look at that also?

----------

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

From report at bugs.python.org  Wed Dec 21 10:01:10 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:01:10 +0000
Subject: [docs] [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <E1RdI2v-0006PF-1W@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 902f694a7b0e by Antoine Pitrou in branch '3.2':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/902f694a7b0e

New changeset b08bf8df8eec by Antoine Pitrou in branch 'default':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/b08bf8df8eec

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

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

From report at bugs.python.org  Wed Dec 21 10:18:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 09:18:06 +0000
Subject: [docs] [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <E1RdIJJ-0008JG-2E@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 13f56cd8dec1 by Antoine Pitrou in branch '2.7':
Issue #1785: Fix inspect and pydoc with misbehaving descriptors.
http://hg.python.org/cpython/rev/13f56cd8dec1

----------

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

From report at bugs.python.org  Wed Dec 21 10:18:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 09:18:55 +0000
Subject: [docs] [issue13581] help() appears to be broken;
	doesn't display __doc__ for class type when called as help(type)
In-Reply-To: <1323627988.99.0.266036261308.issue13581@psf.upfronthosting.co.za>
Message-ID: <1324459135.37.0.0869753387592.issue13581@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now fixed in all 3 branches.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "inspect" gets broken by some descriptors

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

From report at bugs.python.org  Wed Dec 21 11:25:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2011 10:25:31 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <E1RdJMY-0005JC-6j@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 19df72a77b39 by Antoine Pitrou in branch '3.2':
Issue #13597: Fix the documentation of the "-u" command-line option, and wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/19df72a77b39

New changeset 1ab124a6f171 by Antoine Pitrou in branch 'default':
Issue #13597: Fix the documentation of the "-u" command-line option, and wording of "What's new in Python 3.0" about standard streams.
http://hg.python.org/cpython/rev/1ab124a6f171

----------

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

From report at bugs.python.org  Wed Dec 21 11:26:00 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 21 Dec 2011 10:26:00 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324463160.21.0.185292120054.issue13597@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I also suggested changes to the documentation of the "-u" flag, and to 
> "What's New in Python 3.0", can someone look at that also?

Sorry for having overlooked that. This should now be fixed as well.

----------

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

From report at bugs.python.org  Wed Dec 21 17:49:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 21 Dec 2011 16:49:30 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324486170.81.0.161359147392.issue2134@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The cmdoption directive should be used with a program directive.  See library/trace for an example of how to use it and to see the anchors and index entries it generates.

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

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

From report at bugs.python.org  Wed Dec 21 21:50:53 2011
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 21 Dec 2011 20:50:53 +0000
Subject: [docs] [issue13597] Improve documentation of stdout/stderr
	buffering in	Python 3.x
In-Reply-To: <1323808082.9.0.254813684247.issue13597@psf.upfronthosting.co.za>
Message-ID: <1324500653.42.0.261788132816.issue13597@psf.upfronthosting.co.za>


Geoffrey Bache <gjb1002 at users.sourceforge.net> added the comment:

Thanks.

I'm not sure what you've written about the "-u" flag is correct though currently. From experimenting I believe it changes buffering of stdout and stderr to line-buffering also when directed to file, i.e. it does affect the behaviour of the text-layer.

Some other changes might be needed also, but perhaps they should wait until we know whether issue13601 will be accepted.

----------

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

From report at bugs.python.org  Thu Dec 22 08:50:24 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 22 Dec 2011 07:50:24 +0000
Subject: [docs] [issue12922] StringIO and seek()
In-Reply-To: <1315342130.67.0.227650351498.issue12922@psf.upfronthosting.co.za>
Message-ID: <1324540224.22.0.251810642823.issue12922@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would rather document it in TextIOBase:
http://docs.python.org/dev/library/io.html#io.TextIOBase

With text I/O streams, tell() returns an arbitrary "position cookie", meaning you can't meaningfully do arithmetic on it: this is why cur-relative seeking and end-relative seeking isn't supported.

Of course, on StringIO the "arbitrary position cookie" is a perfectly well-defined character offset, so we *could* specifically enhance StringIO.tell. Whether it's a good idea to do it (while arbitrary text files would still have the limitation) is left to debate.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
type: enhancement -> behavior
versions: +Python 2.7

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

From report at bugs.python.org  Thu Dec 22 16:09:46 2011
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 22 Dec 2011 15:09:46 +0000
Subject: [docs] [issue13649] termios.ICANON is not documented
Message-ID: <1324566585.96.0.744911903947.issue13649@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/library/termios.html is missing documentation for ICANON flag used to put terminal to "raw" mode.

It is also worth to place `termios` raw/canonical mode equivalent on `tty` pages, so that people porting C code to Python could understand the hidden magic.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 150098
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: termios.ICANON is not documented
versions: Python 2.7

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

From report at bugs.python.org  Thu Dec 22 16:45:18 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2011 15:45:18 +0000
Subject: [docs] [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <E1RdkpY-0005Np-TL@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c6880edaf6f3 by Senthil Kumaran in branch '2.7':
Issue13443 - Remove the functional module examples from 2.7 (as module is
http://hg.python.org/cpython/rev/c6880edaf6f3

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

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

From report at bugs.python.org  Thu Dec 22 16:46:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 22 Dec 2011 15:46:13 +0000
Subject: [docs] [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1324568773.7.0.618908219843.issue13443@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Fixed this in 2.7.

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

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

From report at bugs.python.org  Fri Dec 23 03:54:36 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 02:54:36 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvHF-0005jQ-9T@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aef79ff1bc9b by Senthil Kumaran in branch '3.2':
Issue12798 - Update mimetypes documentation. Correct the doc section where
http://hg.python.org/cpython/rev/aef79ff1bc9b

New changeset 4b306aee21a4 by Senthil Kumaran in branch 'default':
Merge changes from 3.2
http://hg.python.org/cpython/rev/4b306aee21a4

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

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

From report at bugs.python.org  Fri Dec 23 04:08:50 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 03:08:50 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvV2-0007EQ-D6@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset cfa3fe9d7b1f by Senthil Kumaran in branch '2.7':
porting mimetype doc changes from 3.2.
http://hg.python.org/cpython/rev/cfa3fe9d7b1f

----------

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

From report at bugs.python.org  Fri Dec 23 04:15:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2011 03:15:25 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <E1RdvbQ-0007kh-Dj@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 9c19df6c8ea0 by Senthil Kumaran in branch '3.2':
News entry for Issue12798
http://hg.python.org/cpython/rev/9c19df6c8ea0

----------

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

From report at bugs.python.org  Fri Dec 23 04:21:54 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 23 Dec 2011 03:21:54 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1324610514.24.0.428510749969.issue12798@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Updated the doc with Sandro Tosi's suggested changes in all the codelines.

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

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

From report at bugs.python.org  Fri Dec 23 12:37:06 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:37:06 +0000
Subject: [docs] [issue13656] Document ctypes.util and ctypes.wintypes.
Message-ID: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

Document ctypes.util and ctypes.wintypes.

----------
assignee: docs at python
components: Documentation
messages: 150151
nosy: docs at python, maniram.maniram
priority: normal
severity: normal
status: open
title: Document ctypes.util and ctypes.wintypes.
type: enhancement

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

From report at bugs.python.org  Fri Dec 23 12:38:03 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 23 Dec 2011 11:38:03 +0000
Subject: [docs] [issue13656] Document ctypes.util and ctypes.wintypes.
In-Reply-To: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>
Message-ID: <1324640283.27.0.147746736315.issue13656@psf.upfronthosting.co.za>


Changes by maniram maniram <maniandram01 at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Dec 23 16:31:54 2011
From: report at bugs.python.org (Joshua Landau)
Date: Fri, 23 Dec 2011 15:31:54 +0000
Subject: [docs] [issue13658] Extra clause in class grammar documentation
Message-ID: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>


New submission from Joshua Landau <joshua.landau.ws at gmail.com>:

Inside the grammar for classes[1], the documentation states that the inheritance list can be of type:
"(" [argument_list [","] | comprehension] ")"

The "comprehension" part seems to be superfluous, especially as it is valid grammar without the clause.

The 2.7 docs state just "[expression list]", so either the addition should be justified or the extra clause removed.

[1] http://docs.python.org/py3k/reference/compound_stmts.html#grammar-token-classdef

Please see http://mail.python.org/pipermail/python-list/2011-December/1284989.html for discussion.

----------
assignee: docs at python
components: Documentation
messages: 150169
nosy: Joshua.Landau, docs at python
priority: normal
severity: normal
status: open
title: Extra clause in class grammar documentation
versions: Python 3.2

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

From cocoatomo77 at gmail.com  Wed Dec 21 16:04:36 2011
From: cocoatomo77 at gmail.com (tomo cocoa)
Date: Thu, 22 Dec 2011 00:04:36 +0900
Subject: [docs] documentation bugs
Message-ID: <CAN_7T0JuNezC2dOwNdFhuPSx2y0uEy2ud3zm7Lytzz=ooet+yQ@mail.gmail.com>

Hello,

My name on Web is cocoatomo and I am now translating Python documents
into Japanese.

I found slight bugs in documents.

In library/ttk.rst, explanation for layout method of ttk.Style class,
there are duplicated word "described".

I'm not sure to find out another bug is really bug,
explanation for sticky option of ttk.Style.element_create method
uses 2-byte characters, open double quote??? and close double quote???.


I hope to contribute Python and favor her -- Python -- :)

Regards,

cocoatomo

-- 
class Cocoatomo:
? ? name = 'cocoatomo'
? ? email_address = 'cocoatomo77 at gmail.com'
? ? twitter_id = '@cocoatomo'

From chenweiguo315 at gmail.com  Thu Dec 22 10:51:37 2011
From: chenweiguo315 at gmail.com (=?GB2312?B?s8LOwLn6?=)
Date: Thu, 22 Dec 2011 17:51:37 +0800
Subject: [docs] An error report for python 2.6.5 logging module
Message-ID: <CAPWXXprrXK4+jPf2_+AP6Pr+cv-QmQE5MmpX3oxdXJafRYKmAw@mail.gmail.com>

hi,all:

I want to report an error in Python2.6.5 Logging module like this:

'
*Traceback (most recent call last):*
*  File "/usr/local/lib/python2.6/logging/handlers.py", line 72, in emit*
*    self.doRollover()*
*  File "/usr/local/lib/python2.6/logging/handlers.py", line 324, in
doRollover*
*    os.rename(self.baseFilename, dfn)*
*OSError: [Errno 2] No such file or directory*
*'*
*
*
It happens when use class 'TimedRotatingFileHandler'. After the class
instance creates, if you don't instert any log message into the log file
until the rollover condition meet. so the process will do "doRollover"
function. But this function don't check the source log file whether exist.
At last, this Error happens.

*fix advice*: add 'os.path.exists' function before 'os.rename'.



Best Regards.

Weiguo Chen
Beijing China.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111222/d37256fb/attachment-0001.html>

From ppanaguiton at belairnetworks.com  Thu Dec 22 22:34:58 2011
From: ppanaguiton at belairnetworks.com (Peter Panaguiton)
Date: Thu, 22 Dec 2011 21:34:58 +0000
Subject: [docs] Documentations/description for reading the Python
	docmentation
Message-ID: <33E73FB28E632F4B9977CB31D66CA40D032FAF12@mpbeexchange.gwhosting.local>

Hello,

                I can't find (or maybe there isn't) the guide on how to read the python documentations. The documentations should start with this or at least point to it on its first pages.

-Peter
________________________________

This email, including any attachments, may contain confidential information, privileged material (including material protected by solicitor-client and/or other applicable privileges) or constitute non-public information under securities law(s). Any exploitation of the information contained in this email (including any attachments) by anyone other than the intended recipient is prohibited. If you have received this email in error, please reply to the sender and delete this information from your system as soon as reasonably practicable. Use, dissemination, distribution, reproduction, publication or any other exploitation of this email by unintended recipients is not authorized and may be unlawful.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111222/35809708/attachment-0001.html>

From jmullen10 at rochester.rr.com  Fri Dec 23 08:09:15 2011
From: jmullen10 at rochester.rr.com (Jeff Mullen)
Date: Fri, 23 Dec 2011 02:09:15 -0500
Subject: [docs] Bug in Python Tutorial
Message-ID: <4EF4291B.70608@rochester.rr.com>

Gentlemen:

I am trying to get a Sikuli script going (Sikuli is an extension of 
Python) and have come to your documentation to learn how to affect 
statement grouping in Python. Unfortunately, your documentation is quite 
obscure on this point. Relevant parts of the documentation that I could 
find were as follows:

3.2 First Steps Toward Programming

...

The body of the loop is indented: indentation is Python?s way of 
grouping statements. Python does not (yet!) provide an intelligent input 
line editing facility, so you have to type a tab or space(s) for each 
indented line. In practice you will prepare more complicated input for 
Python with a text editor; most text editors have an auto-indent 
facility. When a compound statement is entered interactively, it must be 
followed by a blank line to indicate completion (since the parser cannot 
guess when you have typed the last line). Note that each line within a 
basic block must be indented by the same amount.

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

and

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

4.4. break and continue Statements, and else Clauses on Loops

The break statement, like in C, breaks out of the smallest enclosing for 
or while loop.

The continue statement, also borrowed from C, continues with the next 
iteration of the loop.

Loop statements may have an else clause; it is executed when the loop 
terminates through exhaustion of the list (with for) or when the 
condition becomes false (with while), but not when the loop is 
terminated by a break statement. This is exemplified by the following 
loop, which searches for prime numbers:
 >>>

 >>> for n in range(2, 10):
... for x in range(2, n):
... if n % x == 0:
... print n, 'equals', x, '*', n/x
... break
... else:
... # loop fell through without finding a factor
... print n, 'is a prime number'
...
2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

(Yes, this is the correct code. Look closely: the else clause belongs to 
the for loop, not the if statement.)

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

This is not sufficient to show me how to code in Python. Note in the 
last sentence, it says that the else clause groups with the for 
statement, not the if statement. It does not, however, explain why. Nor 
does the document anywhere explain how statements are grouped in Python. 
The best I can come up with is that the compiler itself uses the 
indentation level to make this determination--which strikes me as rather 
kludgy, as indentation level is something that different people often 
have different interpretations of.

I would offer more specific wording for your documentation (I've had a 
couple of short stories published, so I can assure you that my writing 
skills are adequate), but I'm not sure how the thing works.

Can you clear up my confusion?

Thanks in advance.

Sincerely,

Jeff Mullen
Computer Programmer
Published Author

From Arnaud.Gomes at ircam.fr  Fri Dec 23 12:16:55 2011
From: Arnaud.Gomes at ircam.fr (Arnaud Gomes-do-Vale)
Date: Fri, 23 Dec 2011 12:16:55 +0100
Subject: [docs] Small error in documentation for syslog library
Message-ID: <y9h7h1n8rmg.fsf@licencieux.ircam.fr>

Hello,

There is a small error in http://docs.python.org/library/syslog.html :
the second argument to syslog.openlog is called logoption, not
logopt. This is for Python 2.7.2, I don't know about other versions.

-- 
Arnaud

From anthon at mnt.org  Fri Dec 23 16:54:10 2011
From: anthon at mnt.org (Anthon van der Neut)
Date: Fri, 23 Dec 2011 16:54:10 +0100
Subject: [docs] format specicifation language missing character in example
Message-ID: <4EF4A422.9090005@mnt.org>

I was using the examples of the usage of .format as an extra testcase 
for pyjamas and found that a '.' was missing in

http://docs.python.org/library/string.html#formatspec

section 7.1.3.2 Format Examples
subsection 'Expressing a percentage':

>>>  'Correct answers: {:.2%}.'.format(points/total)
'Correct answers: 88.64%'

There should be a '.' (dot) before the closing quote in the last line.

Regards
Anthon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111223/85dd000b/attachment.html>

From report at bugs.python.org  Fri Dec 23 22:23:31 2011
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 23 Dec 2011 21:23:31 +0000
Subject: [docs] [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <1324675411.77.0.244028611774.issue13658@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Sat Dec 24 01:19:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 00:19:42 +0000
Subject: [docs] [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <1324685982.2.0.286486126043.issue13658@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 24 02:42:26 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:42:26 +0000
Subject: [docs] [issue13632] Update token documentation to reflect actual
	token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324690946.51.0.444367572147.issue13632@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looks good to me.
help(token) already has the corrections. - BACKQUOTE, + RARROW, ELLIPSIS

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

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

From report at bugs.python.org  Sat Dec 24 02:42:52 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 24 Dec 2011 01:42:52 +0000
Subject: [docs] [issue13632] Update token documentation to reflect actual
	token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324690972.58.0.587581384841.issue13632@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Dec 24 03:02:27 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2011 02:02:27 +0000
Subject: [docs] [issue13658] Extra clause in class grammar documentation
In-Reply-To: <1324654314.35.0.268617299163.issue13658@psf.upfronthosting.co.za>
Message-ID: <E1ReGwK-0002od-JD@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b65007ef59c0 by Benjamin Peterson in branch '3.2':
kill superfluous 'comprehension' case (closes #13658)
http://hg.python.org/cpython/rev/b65007ef59c0

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Dec 24 06:14:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2011 05:14:31 +0000
Subject: [docs] [issue13632] Update token documentation to reflect actual
	token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <E1ReJwD-00052v-V5@dinsdale.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset b7d099e8c136 by Meador Inge in branch '3.2':
Issue #13632: Update token documentation to reflect actual token types
http://hg.python.org/cpython/rev/b7d099e8c136

New changeset 1461327e63b5 by Meador Inge in branch 'default':
Issue #13632: Update token documentation to reflect actual token types
http://hg.python.org/cpython/rev/1461327e63b5

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

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

From report at bugs.python.org  Sat Dec 24 06:18:24 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 05:18:24 +0000
Subject: [docs] [issue13632] Update token documentation to reflect actual
	token types
In-Reply-To: <1324272601.04.0.495106872007.issue13632@psf.upfronthosting.co.za>
Message-ID: <1324703903.88.0.673444537906.issue13632@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Committed.  Thanks for the review Terry.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From sandro.tosi at gmail.com  Sat Dec 24 15:02:40 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 15:02:40 +0100
Subject: [docs] Small error in documentation for syslog library
In-Reply-To: <y9h7h1n8rmg.fsf@licencieux.ircam.fr>
References: <y9h7h1n8rmg.fsf@licencieux.ircam.fr>
Message-ID: <CAPdtAj2KWRRk7m+dBuAutYn4uAbukpirTBUCTsE7rkYP4b8QmA@mail.gmail.com>

Hello Arnaud,

On Fri, Dec 23, 2011 at 12:16, Arnaud Gomes-do-Vale
<Arnaud.Gomes at ircam.fr> wrote:
> There is a small error in http://docs.python.org/library/syslog.html :
> the second argument to syslog.openlog is called logoption, not
> logopt. This is for Python 2.7.2, I don't know about other versions.

Thanks for your report, this has now been fixed with these changesets:
71f7175e2b34 ba2f6978502e ea4ff5528e40 .

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 24 15:40:48 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 15:40:48 +0100
Subject: [docs] An error report for python 2.6.5 logging module
In-Reply-To: <CAPWXXprrXK4+jPf2_+AP6Pr+cv-QmQE5MmpX3oxdXJafRYKmAw@mail.gmail.com>
References: <CAPWXXprrXK4+jPf2_+AP6Pr+cv-QmQE5MmpX3oxdXJafRYKmAw@mail.gmail.com>
Message-ID: <CAPdtAj2UXCLLU8pgPOGEPsQ30=HfaOMN0vLD8G+ykO6bpfhqWg@mail.gmail.com>

Hello Weiguo Chen,

On Thu, Dec 22, 2011 at 10:51, ??? <chenweiguo315 at gmail.com> wrote:
> I want to report an error in Python2.6.5 Logging module like this:

please note a couple of things:

- this mailing list is not for reporting general bugs on Python, but
only for its documentation
- Python 2.6.5 is in security fix-only mode, so no general bugfixes
are performed on this release, so you probably would like to update to
python 2.7 or even to the current Python3 stable release, 3.2

> Traceback (most recent call last):
> ? File "/usr/local/lib/python2.6/logging/handlers.py", line 72, in emit
> ? ? self.doRollover()
> ? File "/usr/local/lib/python2.6/logging/handlers.py", line 324, in
> doRollover
> ? ? os.rename(self.baseFilename, dfn)
> OSError: [Errno 2] No such file or directory
> '
>
> It happens when use class 'TimedRotatingFileHandler'. After the class
> instance creates, if you don't instert any log message into the log file
> until the rollover condition meet. so the process will do "doRollover"
> function. But this function don't check the source log file whether exist.
> At last, this Error happens.
>
> fix advice: add 'os.path.exists' function before 'os.rename'.

Could you please file an issue on http://bugs.python.org/ , possibly
with a sample code to replicate this problem? I've tried with 2.7, but
I was only able to replicate it removing explicitly the filename.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 24 16:06:05 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 16:06:05 +0100
Subject: [docs] format specicifation language missing character in
	example
In-Reply-To: <4EF4A422.9090005@mnt.org>
References: <4EF4A422.9090005@mnt.org>
Message-ID: <CAPdtAj3TimD=fD=iBNc+CB+m9YP0r82xnPyRCw4ghRKbwmXtew@mail.gmail.com>

Hello Anthon,
thanks for your report.

On Fri, Dec 23, 2011 at 16:54, Anthon van der Neut <anthon at mnt.org> wrote:
>>>> 'Correct answers: {:.2%}.'.format(points/total)
> 'Correct answers: 88.64%'
>
> There should be a '.' (dot) before the closing quote in the last line.

I think actually is the dot in the >>> line that has to be removed
(for uniformity with all the other examples) and so I just did with
these changesets: a1edc6e4b49c 6be3cbbe5013 b2f1518660a8

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 24 16:46:17 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 16:46:17 +0100
Subject: [docs] Documentations/description for reading the Python
	docmentation
In-Reply-To: <33E73FB28E632F4B9977CB31D66CA40D032FAF12@mpbeexchange.gwhosting.local>
References: <33E73FB28E632F4B9977CB31D66CA40D032FAF12@mpbeexchange.gwhosting.local>
Message-ID: <CAPdtAj1KC1vnjMyV_NO8vRfbwrLs5BfkEuYb+B4rSLp+XDWxUg@mail.gmail.com>

Hello Peter,

On Thu, Dec 22, 2011 at 22:34, Peter Panaguiton
<ppanaguiton at belairnetworks.com> wrote:
> ??????????????? I can?t find (or maybe there isn?t) the guide on how to read
> the python documentations. The documentations should start with this or at
> least point to it on its first pages.

Could you please explain a bit better what do you expect and what's
missing? For example, on the first page of the documentation there's:
"Tutorial - start here" that seems like the right place to start if
you don't already know where to go.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 24 17:33:02 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 17:33:02 +0100
Subject: [docs] documentation bugs
In-Reply-To: <CAN_7T0JuNezC2dOwNdFhuPSx2y0uEy2ud3zm7Lytzz=ooet+yQ@mail.gmail.com>
References: <CAN_7T0JuNezC2dOwNdFhuPSx2y0uEy2ud3zm7Lytzz=ooet+yQ@mail.gmail.com>
Message-ID: <CAPdtAj21SiggMG1aP2qf0O4kvP6Dkp0wO6N5NvmDNRgTnoEAzA@mail.gmail.com>

Hello cocoatomo

On Wed, Dec 21, 2011 at 16:04, tomo cocoa <cocoatomo77 at gmail.com> wrote:
> In library/ttk.rst, explanation for layout method of ttk.Style class,
> there are duplicated word "described".

could you please provide a link to the documentation you're using?
I've looked at 2.7 and 3.2 doc and I couldn't find what you're
referring to.

> I'm not sure to find out another bug is really bug,
> explanation for sticky option of ttk.Style.element_create method
> uses 2-byte characters, open double quote??? and close double quote???.

for the sticky=spec documentation, right? Given they are not used in
any other place, it would probably be safe to remove it; I'll do it
when I have clear the previous point.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 24 20:06:34 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 20:06:34 +0100
Subject: [docs] simple_stmts.html improvement
In-Reply-To: <CAOnWdohFeAoOQDVy=RdgKczfFZU4LYNYA0oTthdc-u0pm3YJ-Q@mail.gmail.com>
References: <CAOnWdohFeAoOQDVy=RdgKczfFZU4LYNYA0oTthdc-u0pm3YJ-Q@mail.gmail.com>
Message-ID: <CAPdtAj0+-UzPQd+PYh5p=V+PPBERHwKOKFGO1B1TBYCOMPXEVA@mail.gmail.com>

Hello Reuben,

On Wed, Dec 14, 2011 at 17:56, Reuben Thomas <rrt at sc3d.org> wrote:
> In simple_stmts.html?s documentation of del:
>
> "Rather that spelling it out in full details, here are some hints."
> would be better
> "Rather than spelling it out, here are some hints."

I've just fixed the rather that/rather than typo (I didn't feel like
the other words should be removed).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Dec 24 20:20:37 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 24 Dec 2011 19:20:37 +0000
Subject: [docs] [issue11977] Document int.conjugate, .denominator, ...
In-Reply-To: <1304281527.31.0.490855544057.issue11977@psf.upfronthosting.co.za>
Message-ID: <1324754437.33.0.864896716594.issue11977@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Isn't there a way to specify multiple targets for the same entry?
The doc could say that int, float and complex all share some methods/attributes and then either list e.g. int.conjugate, float.conjugate, complex.conjugate with a single description or use just int (or even numbers.Number) and create targets for float and complex too in some other way, so that float.conjugate automatically links to the description of Number.conjugate.
I don't think it's necessary to document all methods/attributes in the same place.  These methods/attributes are not so common, so it's ok to have them documented in the numbers.Number page, for example.  A simple link to the page can then be added to the int/float/complex docs.
See also #4966 for a discussion about the reorganization of the stdtypes page.

----------

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

From sandro.tosi at gmail.com  Sat Dec 24 23:23:37 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 24 Dec 2011 23:23:37 +0100
Subject: [docs] ironpython web address has changed
In-Reply-To: <1323561398.62600.YahooMailNeo@web161703.mail.bf1.yahoo.com>
References: <1323561398.62600.YahooMailNeo@web161703.mail.bf1.yahoo.com>
Message-ID: <CAPdtAj1HYhbXpymvYMgWJktb3p6mCvZgKsk_N1XKPnGny1MdGg@mail.gmail.com>

Hello Lazar,

On Sun, Dec 11, 2011 at 00:56, Lazar Pancic <grimiznizub at yahoo.com> wrote:
> Just to note, it seems that ironpython homepage address is now:
>
> http://ironpython.net/

Thanks for the notice, this has now been fixed with these changesets:
ae5a0aa39e77 2f1f2b0c9d63 c65790aff86d .

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sun Dec 25 00:28:39 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 23:28:39 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324769319.6.0.884522580528.issue2134@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

> The cmdoption directive should be used with a program directive.

Ah, nice.  Thanks for the tip ?ric.

Updated patch attached along with a patch for the 2.7/3.2 doc update attached.

----------
Added file: http://bugs.python.org/file24088/tokenize-exact-type-v1.patch

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

From report at bugs.python.org  Sun Dec 25 00:28:57 2011
From: report at bugs.python.org (Meador Inge)
Date: Sat, 24 Dec 2011 23:28:57 +0000
Subject: [docs] [issue2134] Add new attribute to TokenInfo to report
	specific token	IDs
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1324769337.79.0.152885444904.issue2134@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


Added file: http://bugs.python.org/file24089/tokenize-docs-2.7-3.2.patch

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

From sandro.tosi at gmail.com  Sun Dec 25 11:37:22 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 11:37:22 +0100
Subject: [docs] typo in subprocess doc
In-Reply-To: <4EE1E87C.1060400@mnt.org>
References: <4EE1E87C.1060400@mnt.org>
Message-ID: <CAPdtAj0hOr61nsg_Unm5=biw5gmpa4MjhphvZ4p2Msty3RcHsQ@mail.gmail.com>

Hello Anthon,

On Fri, Dec 9, 2011 at 11:52, Anthon van der Neut <anthon at mnt.org> wrote:
> In the subprocess documentation there is an 'r' missing in the? header for
> the Popen constructor
>
> 17.1.1.2. Popen Constuctor?
>
> Popen Constuctor
> ^^^^^^^^^^^^^^^^
>
> should be
>
> Popen Constructor
> ^^^^^^^^^^^^^^^^^

Thanks, this has now been fixed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From rrt at sc3d.org  Sat Dec 24 20:08:33 2011
From: rrt at sc3d.org (Reuben Thomas)
Date: Sat, 24 Dec 2011 19:08:33 +0000
Subject: [docs] simple_stmts.html improvement
In-Reply-To: <CAOnWdoiHyEhmQZWYuAGS2Qorhx5s8C6L0zLwRJzmwtBLHu6EFg@mail.gmail.com>
References: <CAOnWdohFeAoOQDVy=RdgKczfFZU4LYNYA0oTthdc-u0pm3YJ-Q@mail.gmail.com>
	<CAPdtAj0+-UzPQd+PYh5p=V+PPBERHwKOKFGO1B1TBYCOMPXEVA@mail.gmail.com>
	<CAOnWdoiHyEhmQZWYuAGS2Qorhx5s8C6L0zLwRJzmwtBLHu6EFg@mail.gmail.com>
Message-ID: <CAOnWdoiZLhsLJgTjW_h24CjroBogPF_wg0-uawFCZYFXWsfvJw@mail.gmail.com>

On 24 December 2011 19:08, Reuben Thomas <rrt at sc3d.org> wrote:
>
> "in full details" should then be changed to "in full detail" to be
> correct English.

But that's still not really idiomatic; prefer simply "in full"; hence:

Rather than spelling it out in full, here are some hints.

-- 
http://rrt.sc3d.org

From rrt at sc3d.org  Sat Dec 24 20:08:02 2011
From: rrt at sc3d.org (Reuben Thomas)
Date: Sat, 24 Dec 2011 19:08:02 +0000
Subject: [docs] simple_stmts.html improvement
In-Reply-To: <CAPdtAj0+-UzPQd+PYh5p=V+PPBERHwKOKFGO1B1TBYCOMPXEVA@mail.gmail.com>
References: <CAOnWdohFeAoOQDVy=RdgKczfFZU4LYNYA0oTthdc-u0pm3YJ-Q@mail.gmail.com>
	<CAPdtAj0+-UzPQd+PYh5p=V+PPBERHwKOKFGO1B1TBYCOMPXEVA@mail.gmail.com>
Message-ID: <CAOnWdoiHyEhmQZWYuAGS2Qorhx5s8C6L0zLwRJzmwtBLHu6EFg@mail.gmail.com>

On 24 December 2011 19:06, Sandro Tosi <sandro.tosi at gmail.com> wrote:
> Hello Reuben,
>
> On Wed, Dec 14, 2011 at 17:56, Reuben Thomas <rrt at sc3d.org> wrote:
>> In simple_stmts.html?s documentation of del:
>>
>> "Rather that spelling it out in full details, here are some hints."
>> would be better
>> "Rather than spelling it out, here are some hints."
>
> I've just fixed the rather that/rather than typo (I didn't feel like
> the other words should be removed).

"in full details" should then be changed to "in full detail" to be
correct English.

-- 
http://rrt.sc3d.org

From sandro.tosi at gmail.com  Sun Dec 25 11:54:09 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 11:54:09 +0100
Subject: [docs] documentation bug in library/httplib.rst
In-Reply-To: <CAN_7T0LJvgaeTC5L0=2WM4_k3YZX=KiJVjiMx0pXZs9jOK2Ryg@mail.gmail.com>
References: <CAN_7T0LJvgaeTC5L0=2WM4_k3YZX=KiJVjiMx0pXZs9jOK2Ryg@mail.gmail.com>
Message-ID: <CAPdtAj3ZLXwNZP7LnSgRRJVGwC4Ss1p2L5Q26ny3j7dBDmGmiQ@mail.gmail.com>

Hello tomo,

On Thu, Nov 24, 2011 at 13:43, tomo cocoa <cocoatomo77 at gmail.com> wrote:
> Hello
>
> I am a Japanese Pythonista, who am translating ver2.7 document into Japanese.
>
> I found a miscellaneous document bug in library/httplib.rst.
>
> At the explanation about "HTTPConnection.set_tunnel(host,port=None,
> headers=None)",
> "extra HTTP headers to to sent" would be "extra HTTP headers to sent", I think.

this duplication has been fixed in changeset  a3e48273dce3 , but it
still needed to be 'to send', which I just fixed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Dec 25 14:51:50 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 14:51:50 +0100
Subject: [docs]
	http://docs.python.org/tutorial/controlflow.html#if-statements
In-Reply-To: <CAHwprn3NYDAUdQjeu27ftjqfsH4=NG7qK3zjKOyjeeP+fDAp9Q@mail.gmail.com>
References: <CAHwprn3NYDAUdQjeu27ftjqfsH4=NG7qK3zjKOyjeeP+fDAp9Q@mail.gmail.com>
Message-ID: <CAPdtAj3DUKuouL0SxSY7Az8D86e6MqpaZ=kRccU0b1CViSrGvg@mail.gmail.com>

Hello Folkert,
thanks for your interest in Python doc.

On Tue, Dec 6, 2011 at 15:23, Folkert van Heusden
<folkert.mobiel at gmail.com> wrote:
> Regarding the explanation of the if/else construct in Python: maybe you can
> add a short explanation to it that while c/c++/java use || and &&, that
> python requires 'or' and 'and'.
> Took me a while to figure that out :-)

I don't think that this kind of comparison is correct in the Python
tutorial (f.e. why java and not ruby or any other language?): we need
to give a guide for Python, not a comparison between Python and all
the other languages. There is another part of the tutorial that talks
in details about comparisons:
http://docs.python.org/tutorial/datastructures.html#more-on-conditions
.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Dec 25 15:29:19 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 15:29:19 +0100
Subject: [docs] found an error in documentation
In-Reply-To: <4ECD48B8.1060303@syscom.com.mx>
References: <4ECD48B8.1060303@syscom.com.mx>
Message-ID: <CAPdtAj1Rcam6aTaiTsySyjYB6Konegcrx+a-OB6FQ0aHCMKXAA@mail.gmail.com>

Hello Felipe,
thanks for your email.

On Wed, Nov 23, 2011 at 20:25, Ing. Felipe Martinez
<fmartinez at syscom.com.mx> wrote:
> in 20.17.4.2. SocketServer.UDPServer Example?
> http://docs.python.org/library/socketserver.html#examples
>
> on the line 13 have a error :
...
> 13 ? ? ? print "{} wrote:".format(self.client_address[0]) ? ?# on this line
> have the error, you concatenate whit . and need to be whit +

why do you think this is an error, did you try to run the code? :)
that line is correct and it's using the string formatting syntax:
http://docs.python.org/library/stdtypes.html#str.format

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Dec 25 16:47:25 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 16:47:25 +0100
Subject: [docs] Bug in Python Tutorial
In-Reply-To: <4EF4291B.70608@rochester.rr.com>
References: <4EF4291B.70608@rochester.rr.com>
Message-ID: <CAPdtAj32ZeQZ-eVhFQoxHRUO+umJVoE5bcj9MafkvQi8M-uqkQ@mail.gmail.com>

Hello Jeff,
Thanks for your email. Please note that this mailing list is about
bugs in Python documentation, while it seems your seeking some
guidance and a first kick start in Python programming, and so
python-list is probably the best place for you. Anyhow, I'll try to
give my point-of-view, it might help you nonetheless.

On Fri, Dec 23, 2011 at 08:09, Jeff Mullen <jmullen10 at rochester.rr.com> wrote:
> The body of the loop is indented: indentation is Python?s way of grouping
> statements. Python does not (yet!) provide an intelligent input line editing
> facility, so you have to type a tab or space(s) for each indented line. In
> practice you will prepare more complicated input for Python with a text
> editor; most text editors have an auto-indent facility. When a compound
> statement is entered interactively, it must be followed by a blank line to
> indicate completion (since the parser cannot guess when you have typed the
> last line). Note that each line within a basic block must be indented by the
> same amount.

Ok, this paragraph mixes some tips for entering code in the python
interactive shell and how to group up statements, but it's very clear
about how to group them up: with indentation. statements at the same
indentation level belongs to the same code block.

1 for i in range(10):
2     print i
3     print 2*i
4     for j in range(10):
5         print j

in this small example, line 1 is the first line, below that there's
its code block composed by line 2 and 3 (print statements) and a block
made of line 4-5; line 4 is another for loop which requires a
sub-block of code, composed by only line 5.

Lines 2-4 are indented more than line 1 because the are the for code
block, so they are "nested" below it. the same holds for line 5 in
respect to line 4.


> Loop statements may have an else clause; it is executed when the loop
> terminates through exhaustion of the list (with for) or when the condition
> becomes false (with while), but not when the loop is terminated by a break
> statement. This is exemplified by the following loop, which searches for
> prime numbers:
>>>>
>
>>>> for n in range(2, 10):
> ... for x in range(2, n):
> ... if n % x == 0:
> ... print n, 'equals', x, '*', n/x
> ... break
> ... else:
> ... # loop fell through without finding a factor
> ... print n, 'is a prime number'
> ...
> 2 is a prime number
> 3 is a prime number
> 4 equals 2 * 2
> 5 is a prime number
> 6 equals 2 * 3
> 7 is a prime number
> 8 equals 2 * 4
> 9 equals 3 * 3
>
> (Yes, this is the correct code. Look closely: the else clause belongs to the
> for loop, not the if statement.)
>
> ------------------------
>
> This is not sufficient to show me how to code in Python.

But this is not what you asked in the first part of teh email: you
were looking for information about code block and indentation. for
this task, I find http://docs.python.org/tutorial/index.html quiet
complete.

> Note in the last
> sentence, it says that the else clause groups with the for statement, not
> the if statement. It does not, however, explain why.

It's explained before the code example (and also reported in the text
you cut&pasted in the email): Loop statements may have an else clause;
it is executed when the loop terminates through exhaustion of the list
(with for) or when the condition becomes false (with while), but not
when the loop is terminated by a break  statement.

> Nor does the document
> anywhere explain how statements are grouped in Python.

this part talks about just one aspect of Python language, but the code
block definition is already described in section 3.2, that you cited.

> The best I can come
> up with is that the compiler itself uses the indentation level to make this
> determination

except it's an interpreter :) yes, it's the indentation that matters
to identify code block.

> which strikes me as rather kludgy, as indentation level is
> something that different people often have different interpretations of.

Well, every programming language has its syntax and semantics, for
Python indentation matters, nothing more nothing less.

> Can you clear up my confusion?

I hope it's clear now, else please point to specific aspects that are
still a bit foggy.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Dec 25 17:26:45 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 25 Dec 2011 17:26:45 +0100
Subject: [docs] Mistake in the itertools.permutations() exemple code
In-Reply-To: <CACwsJvfujdMpe3g633ehGXN0dfg_RnJbAmAYTh0mrq74OTpJmw@mail.gmail.com>
References: <CACwsJvfujdMpe3g633ehGXN0dfg_RnJbAmAYTh0mrq74OTpJmw@mail.gmail.com>
Message-ID: <CAPdtAj1Xu7kvfokYfV1=Wscn2nK2zSYZ9LCEsgpVprzeiBnfiA@mail.gmail.com>

Hello Romain,

On Fri, Dec 2, 2011 at 17:18, Romain MORLEVAT <romainmorlevat at gmail.com> wrote:
> Hello,
>
> I think I found a mistake in the itertools.permutations() exemple code
> (http://docs.python.org/py3k/library/itertools.html?highlight=itertools#itertools.permutations)
> At the tenth line, the cycles = range(n, n-r, -1), must be cycles =
> list(range(n, n-r, -1)).

Thanks, this has now been fixed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Dec 26 13:50:09 2011
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2011 12:50:09 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
Message-ID: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

I am one of Japanese translate of Python documents.
We have done translating Python 2.7 document and will start
translating Python 3.2 or 3.3.

I want to use sphinx-i18n and pootle to translate.
But http://pootle.python.org/ is very outdated.
Anyone can update the site?
If nobody maintain the site, could I create Python Document project at http://pootle.locamotion.org/ ?

----------
assignee: docs at python
components: Documentation
messages: 150261
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: pootle.python.org is outdated.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Dec 26 16:42:39 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Mon, 26 Dec 2011 15:42:39 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1324914159.3.0.975247939198.issue12760@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

C11 uses 'x' for this, for what it's worth.

This is not a "duplicate issue". The openat solution is no easier than the os.open solution.

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

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

From report at bugs.python.org  Mon Dec 26 23:01:54 2011
From: report at bugs.python.org (Stephen Kelly)
Date: Mon, 26 Dec 2011 22:01:54 +0000
Subject: [docs] [issue13666] datetime documentation typos
Message-ID: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>


New submission from Stephen Kelly <steveire at gmail.com>:

There are several bugs on 

http://docs.python.org/library/datetime.html

Section 8.1.6 references the method rzinfo.dst(), which does not exist. Presumably this should be tzinfo.dst().

Section 8.1.4 contains an implementation of a GMT2 timezone. There seems to be a bug in the utcoffset() and dst() implementations. The timedelta(hours=2) is in the dst() implementation, but it should be in the uctoffset() implementation. 

The docs for tzinfo.utcoffset() start with 'Return offset of local time from UTC, in minutes east of UTC'. Other methods (eg dst()) also document that the unit to return should be 'minutes'. However, all code samples instead return a timedelta. The documentation I quoted should instead read 'Return offset of local time from UTC as a timedelta, or None'.

----------
assignee: docs at python
components: Documentation
messages: 150272
nosy: docs at python, steveire
priority: normal
severity: normal
status: open
title: datetime documentation typos
versions: Python 2.6

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

From report at bugs.python.org  Tue Dec 27 18:11:35 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2011 17:11:35 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325005895.16.0.187521489854.issue12760@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> C11 uses 'x' for this, for what it's worth.
> 
> This is not a "duplicate issue". The openat solution is no easier than 
> the os.open solution.

Ok, let's re-open then. I'm not sold on the feature, but the fact C11 adds a dedicated letter mode for it could be a good excuse for us to mimick it :)

----------
resolution: duplicate -> 
status: closed -> open
superseder: io.FileIO and io.open should support openat -> 

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

From report at bugs.python.org  Tue Dec 27 20:04:30 2011
From: report at bugs.python.org (Chris Rebert)
Date: Tue, 27 Dec 2011 19:04:30 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325012670.47.0.325577388205.issue12760@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Tue Dec 27 20:08:59 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2011 19:08:59 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325012939.51.0.168451319616.issue13663@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl, loewis

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

From report at bugs.python.org  Wed Dec 28 10:11:10 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:11:10 +0000
Subject: [docs] [issue13667] __contains__ method behavior
Message-ID: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

Hi, I'm working on a class which implements the __contains__ method but the way I would like it to work is by generating an object that will be evaluated later.

It'll return a custom object instead of True/False


class C:
    def __contains__(self, x):
        return "I will evaluate this thing later... Don't bother now"


but when I do:


>>> 1 in C()
True


It seems to evaluate the answer with bool!

Reading the docs (http://docs.python.org/py3k/reference/expressions.html#membership-test-details) It says:

"`x in y` is true if and only if `y.__contains__(x)` is true."

It looks like the docs doesn't match the code and the code is trying to mimic the behavior of lists/tuples where "x in y" is the same as

any(x is e or x == e for e in y)

and always yield True or False.

There is a reason why it is that way?


Thanks!

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 150283
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: __contains__ method behavior
type: behavior
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Dec 28 10:24:38 2011
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 28 Dec 2011 09:24:38 +0000
Subject: [docs] [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064278.32.0.170098322305.issue13667@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

"an object is true" is a short way of saying "bool(obj) is True".  So the docs match the behavior.

Returning the actual object instead of True/False from the "in" operator is a feature request.

----------
assignee: docs at python -> 
nosy: +georg.brandl
type: behavior -> enhancement
versions:  -Python 3.2

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

From report at bugs.python.org  Wed Dec 28 10:29:19 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:29:19 +0000
Subject: [docs] [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064559.81.0.507182971978.issue13667@psf.upfronthosting.co.za>


Jo?o Bernardo <jbvsmo at gmail.com> added the comment:

@Georg Brandl
Oh sorry, now I see... true != True

But still, why is that the default behavior? Shouldn't it use whatever the method returns?

----------
type: enhancement -> behavior
versions: +Python 3.2

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

From report at bugs.python.org  Wed Dec 28 10:34:24 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Wed, 28 Dec 2011 09:34:24 +0000
Subject: [docs] [issue13667] __contains__ method behavior
In-Reply-To: <1325063470.58.0.871415984198.issue13667@psf.upfronthosting.co.za>
Message-ID: <1325064864.05.0.67235479374.issue13667@psf.upfronthosting.co.za>


Changes by Jo?o Bernardo <jbvsmo at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec 29 18:49:23 2011
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 29 Dec 2011 17:49:23 +0000
Subject: [docs] [issue13677] correct docstring for builtin compile
Message-ID: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at gmail.com>:

The current docstring for compile suggests that the flags are strictly for selecting future statements.  These are not the only flags.

It also suggests that the source must be source code and the result will be bytecode, which isn't quite true.

I suggest changing:

"The flags argument, if present, controls which future statements influence the compilation of the code."

to:

"The flags argument, if present, largely controls which future 
statements influence the compilation of the code.  (Additional 
flags are documented in the AST module.)"

----------
assignee: docs at python
components: Documentation
files: bltinmodule.c.patch
keywords: patch
messages: 150337
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: correct docstring for builtin compile
type: behavior
Added file: http://bugs.python.org/file24105/bltinmodule.c.patch

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

From report at bugs.python.org  Fri Dec 30 12:36:08 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Fri, 30 Dec 2011 11:36:08 +0000
Subject: [docs] [issue13682] Documentation of os.fdopen() refers to
	non-existing	bufsize argument of builtin open()
Message-ID: <1325244968.02.0.142917484563.issue13682@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

>From the docs of os.fdopen():

    Return an open file object connected to the file descriptor fd. The
    mode and bufsize arguments have the same meaning as the corresponding
    arguments to the built-in open() function.

However, there's no bufsize argument for builtin open() anymore in py3k.

----------
assignee: docs at python
components: Documentation
messages: 150376
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: Documentation of os.fdopen() refers to non-existing bufsize argument of builtin open()
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec 30 16:01:30 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 30 Dec 2011 15:01:30 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325257290.76.0.372407678665.issue13663@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd rather have you maintain poodle.python.org instead of maintaining Python translations off-site.

----------

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

From report at bugs.python.org  Fri Dec 30 16:34:14 2011
From: report at bugs.python.org (maniram maniram)
Date: Fri, 30 Dec 2011 15:34:14 +0000
Subject: [docs] [issue13683] Docs in Python 3:raise statement mistake
Message-ID: <1325259254.7.0.957455919083.issue13683@psf.upfronthosting.co.za>


New submission from maniram maniram <maniandram01 at gmail.com>:

In the Python 3 docs for the raise statement, http://docs.python.org/py3k/reference/simple_stmts.html#the-raise-statement,the docs say "If no exception is active in the current scope, a TypeError exception is raised indicating that this is an error (if running under IDLE, a queue.Empty exception is raised instead).

This is wrong in Python 3 because raise raises a RuntimeError and IDLE does the same (does not raise a queue.Empty Exception).

The text should be "If no exception is active in the current scope, a RuntimeError exception is raised indicating that this is an error."

----------
assignee: docs at python
components: Documentation
messages: 150382
nosy: docs at python, maniram.maniram
priority: normal
severity: normal
status: open
title: Docs in Python 3:raise statement mistake
versions: Python 3.2

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

From report at bugs.python.org  Fri Dec 30 21:59:05 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 20:59:05 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325278745.44.0.783137736919.issue12760@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> This is not a "duplicate issue". The openat solution is no easier than the os.open
> solution.

Amaury did not suggest to use openat, but the new opener argument to open, which was especially added for use cases such as the one discussed here:

    ...
    open_exclusive = lambda path, mode: os.open(path, mode|os.O_CREAT|os.O_EXCL))
    ...
    fp = open(filename, 'w', opener=open_exclusive)
    ...

That?s why this bug was initially closed as duplicate.

----------

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

From report at bugs.python.org  Fri Dec 30 22:05:04 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:05:04 +0000
Subject: [docs] [issue13656] Document ctypes.util and ctypes.wintypes.
In-Reply-To: <1324640225.55.0.0772852885981.issue13656@psf.upfronthosting.co.za>
Message-ID: <1325279104.52.0.753421346262.issue13656@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

May I ask why you closed this?  From a quick glance, a few functions from ctypes.util are considered public and documented (albeit not with module directives, so I?m not sure the indexing works helpfully for people searching); I don?t know the status of wintypes.

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

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

From report at bugs.python.org  Fri Dec 30 22:29:24 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:29:24 +0000
Subject: [docs] [issue13666] datetime documentation typos
In-Reply-To: <1324936913.94.0.649454454071.issue13666@psf.upfronthosting.co.za>
Message-ID: <1325280564.03.0.0625931300517.issue13666@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.6 only gets security updates.

I verified 'rzinfo' typo in x.1.6 in 2.7 and 3.2. Also in both, tzinfo.utcoffset begins as Stephen claims. I have not verified that this is error.

 Also in both, in x.1.4, class GMT1 has
...     def utcoffset(self, dt):
...         return timedelta(hours=1) + self.dst(dt)
...     def dst(self, dt):
...         if self.dston <=  dt.replace(tzinfo=None) < self.dstoff:
...             return timedelta(hours=1)
...         else:
...             return timedelta(0)

while GMT2 has
...     def utcoffset(self, dt):
...         return timedelta(hours=1) + self.dst(dt)
...     def dst(self, dt):
...         if self.dston <=  dt.replace(tzinfo=None) < self.dstoff:
...             return timedelta(hours=2)
...         else:
...             return timedelta(0)

Stephen is saying that 'hours=1' should here be 'hours=2'. Should '0' by 'hours=1' to be just 1 off from 2?

----------
nosy: +belopolsky, terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 2.6

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

From report at bugs.python.org  Fri Dec 30 22:37:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:37:28 +0000
Subject: [docs] [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1325281048.18.0.332897278772.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Senthil.  I think you applied a patch that did not have consensus.

----------

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

From report at bugs.python.org  Fri Dec 30 22:40:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 30 Dec 2011 21:40:43 +0000
Subject: [docs] [issue13443] wrong links and examples in the functional HOWTO
In-Reply-To: <1321850404.45.0.767133152656.issue13443@psf.upfronthosting.co.za>
Message-ID: <1325281242.96.0.507948749721.issue13443@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hm, it was actually Antoine who removed it.

----------

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

From report at bugs.python.org  Fri Dec 30 22:48:48 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 21:48:48 +0000
Subject: [docs] [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325281728.56.0.466131415715.issue13677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Flags comment applies to 3.2.2 docs and 2.7.2 docs. There is only one additional flag: ast.PyCF_ONLY_AST, so 'flags' should be singular.

As for src and dst, doc has been updated to say 'Compile the source into a code or AST object. ... source can either be a string or an AST object.

'source' should be capitalized.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Dec 30 23:02:45 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 30 Dec 2011 22:02:45 +0000
Subject: [docs] [issue13683] Docs in Python 3:raise statement mistake
In-Reply-To: <1325259254.7.0.957455919083.issue13683@psf.upfronthosting.co.za>
Message-ID: <1325282565.21.0.904256621592.issue13683@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Verified for 3.2.2 cmd window and idle. Fix looks good.

----------
keywords: +patch
nosy: +terry.reedy
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.3

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

From report at bugs.python.org  Fri Dec 30 23:07:19 2011
From: report at bugs.python.org (Devin Jeanpierre)
Date: Fri, 30 Dec 2011 22:07:19 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325282838.91.0.688268261114.issue12760@psf.upfronthosting.co.za>


Devin Jeanpierre <jeanpierreda at gmail.com> added the comment:

> Amaury did not suggest to use openat, but the new opener argument to open, which was especially added for use cases such as the one discussed here:

Sorry, yes. Wrong words, same thought. We can implement this using opener, but we could implement this with os.open before. What's changed, except that there's more ways to do it? (There is slightly more versatility with the opener method, but no more obviousness and no less typing).

My understanding from reading the other thread is that this is not the primary use-case of the new parameter for open(). In fact, this ticket was not really mentioned at all there.

----------

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

From report at bugs.python.org  Fri Dec 30 23:35:21 2011
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 30 Dec 2011 22:35:21 +0000
Subject: [docs] [issue13685] argparse does not sanitize help strings for %
	signs
In-Reply-To: <1325284167.16.0.584942168313.issue13685@psf.upfronthosting.co.za>
Message-ID: <1325284521.31.0.790848225961.issue13685@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is because the help text support substitution, as mentioned here: http://docs.python.org/dev/library/argparse.html#help

It's possible this documentation could be improved.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, eric.smith

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

From report at bugs.python.org  Sat Dec 31 01:37:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 00:37:45 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1325291864.93.0.942110099636.issue12760@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> [...] There is slightly more versatility with the opener method, but no more obviousness
> and no less typing.

I agree with your opinion.  I re-read this report:
- Antoine thinks this fills an important use case, namely avoiding race conditions
- Amaury then suggested the opener argument idea, which was implemented in the openat bug
- Antoine judged it would be better than what we had before

I don?t have a strong opinion on ?opener is generic and good enough? vs. ?not as ice as it could be?.  Antoine seems to agree with you, so your patch will get reviewed and eventually accepted.  Cheers

----------

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

From report at bugs.python.org  Sat Dec 31 02:51:20 2011
From: report at bugs.python.org (Jim Jewett)
Date: Sat, 31 Dec 2011 01:51:20 +0000
Subject: [docs] [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325296280.12.0.629202660134.issue13677@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at gmail.com> added the comment:

I'm not sure we're looking at the same thing.  I was talking about the docstring that shows up at the interactive prompt in response to 
>>> help(compile)

Going to hg.python.org/cpython and selecting branches, then default, then browse, got me to
http://hg.python.org/cpython/file/7010fa9bd190/Python/bltinmodule.c
which still doesn't mention AST.  I also don't see any reference to "src" or "dst", or any "source" that looks like it should be capitalized.

I agree that there is (to my knowledge, at this time) only one additional flag.  I figured ast or future was needed to get the compilation constants, so it made sense to delegate -- but you seem to be reading something newer than I am.

----------

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

From report at bugs.python.org  Sat Dec 31 05:47:27 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2011 04:47:27 +0000
Subject: [docs] [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325306847.0.0.827216573189.issue13677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am aware that the docstring, shown at help(compile), is what you were talking about. The docstring and manuals should say the same thing, or at least not contradict each other, so it is common for both to be out of date and both to be updated at the same time. So I went and looked at the current py2 and py3 docs to see if they also need change. And they do, though not quite as much. src and dst were unofficial abbreviations for source and output, in reference to what you said. Sorry for the confusion.

----------

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

From report at bugs.python.org  Sat Dec 31 06:00:14 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Dec 2011 05:00:14 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
Message-ID: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

I've decided to study the multiprocessing module a bit, and carefully went over the docs (for 2.7). Some small fixes I will commit myself, but a few issues came up on which I'd like some opinion from others. In rough order of appearance in the doc:

1. In the documentation of the 'name' argument of the multiprocessing.Process constructor, it mentions that the length of the generated name depends on the "generation", without elaborating. It could be better to briefly describe the algorithm in a sentence or two.
2. Section 16.6.2.1. is called "Process and exceptions". It only documents one exception from multiprocessing: BufferTooShort. Other exception classes exported by the module aren't documented similarly: ProcessError, TiemoutError, AuthenticationError.
3. AuthenticationError is documented as multiprocessing.connection.AuthenticationError, although in reality it exists in the root multiprocessing module, and multiprocessing.connection just imports it
4. The doc of JoinableQueue.task_done() says "Used by queue consumer threads". Shouldn't that be "consumer processes"?
5. The doc of active_children() should probably mention that it returns a list of Process objects (similarly to what current_process() says)
6. multiprocessing.freeze_support() says "If the freeze_support() line is omitted then trying to run the frozen executable will raise RuntimeError.". *Who* will raise the error?
7. class multiprocessing.Event says "This method returns..." - what method? Seems like an irrelevant documentation piece was intermixed here
8. 16.6.2.7. Managers starts by saying that Managers provide a way to create data which can be shared between different processes. Since it comes right after the section about Shared objects, I think it would be nice to mention in a sentence or two what Managers give above normal synchonized objects in multiprocessing (i.e. sharing between different machines)
9. In the programming guidelines about "Avoid shared state" it says "It is probably best to stick to using queues or pipes for communication between processes rather than using the lower level synchronization primitives from the threading module.". Surely not the "threading" module is meant here?

----------
assignee: docs at python
components: Documentation
messages: 150409
nosy: docs at python, eli.bendersky, pitrou
priority: normal
severity: normal
status: open
title: Some notes on the docs of multiprocessing
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec 31 08:24:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 31 Dec 2011 07:24:45 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1325316285.08.0.179662421191.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

10. Unless I'm missing something entirely obvious, except in the examples it says that Value has a "value" attribute for actual data access. One is expected to look in the docs of ctypes to find that?

----------

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

From report at bugs.python.org  Sat Dec 31 12:19:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:19:10 +0000
Subject: [docs] [issue13677] correct docstring for builtin compile
In-Reply-To: <1325180963.04.0.479072583529.issue13677@psf.upfronthosting.co.za>
Message-ID: <1325330350.66.0.625966558308.issue13677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

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

From report at bugs.python.org  Sat Dec 31 12:22:54 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:22:54 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325330574.33.0.856845419205.issue13663@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Dec 31 12:26:38 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 31 Dec 2011 11:26:38 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325330798.11.0.433467383535.issue13663@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed with Martin.  I would be nice to get a statement on the status of pootle.python.org (social aspects like updating and publishing the translations + organization of teams), but Georg seems busy.

(This would probably be more at home on a mailing list rather than in the CPython bug tracker.)

----------

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

From ori.livneh at gmail.com  Tue Dec 27 04:24:44 2011
From: ori.livneh at gmail.com (Ori Livneh)
Date: Mon, 26 Dec 2011 22:24:44 -0500
Subject: [docs] typo report for packaging.pypi.simple
Message-ID: <CAD2XgA5kT18gd7ujmivy5WfE7nmCg6yyJ+u8YPbH_wYgPQ6QDQ@mail.gmail.com>

http://docs.python.org/dev/library/packaging.pypi.simple.html#usage-exemples

exemples => examples

:D

thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20111226/b57fc440/attachment.html>

From zbyszek at in.waw.pl  Thu Dec 29 11:04:21 2011
From: zbyszek at in.waw.pl (=?UTF-8?B?WmJpZ25pZXcgSsSZZHJ6ZWpld3NraS1Tem1law==?=)
Date: Thu, 29 Dec 2011 11:04:21 +0100
Subject: [docs] broken links on http://docs.python.org/dev/using/unix.html
Message-ID: <4EFC3B25.4060608@in.waw.pl>

Hi,
I just noticed those:

http://www.linux.com/articles/60383 --> 404
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-creating-rpms.html --> 404, redirect to main page

Thanks,
Zbyszek

From ibrahimmuhammads at gmail.com  Fri Dec 30 18:24:52 2011
From: ibrahimmuhammads at gmail.com (muhammad p m)
Date: Fri, 30 Dec 2011 22:54:52 +0530
Subject: [docs] HELP ME PLS
Message-ID: <CANzP_eKf7+whE-OEvpu8VBfP0WV_v0O3+TtWgdc-CNfVUvfEMA@mail.gmail.com>

Sir,
     am doing software engineering in kerala,i would like to know more
about python,i think i can work in python platform please send me the
details or study material of python its a request of a student I think
u never ignore this
-- 
> Regards
>>
>> MUHAMMAD P M
>>
>> Mob: +91 9747078155

From report at bugs.python.org  Sat Dec 31 12:43:17 2011
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 31 Dec 2011 11:43:17 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325331797.5.0.730432316558.issue13663@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I've never really had a hand in pootle.python.org; it was set up by Martin and Robert Lehmann, and Sandro Tosi also wanted to lend a hand...

----------
nosy: +lehmannro, sandro.tosi

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

From report at bugs.python.org  Sat Dec 31 12:49:36 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 31 Dec 2011 11:49:36 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325332176.8.0.647737594731.issue13663@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Yeah, I really would like to help with pootle, but it seems we don't have a current status of the thing + a roadmap to where we want to go.

>From the top of my head, I think we need at least:

- the current setup of the machine/service
- updated packages for pootle + its deps (it should be a debian machine, so I can leverage my DD status to help here)
- plan the migration from the current pootle to the updated one
- start advertise pootle, which is much better than having a lot of people translating python doc on their own websites instead of a central (official) place
- maybe rename the service?

----------

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

From sandro.tosi at gmail.com  Sat Dec 31 13:00:30 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Dec 2011 13:00:30 +0100
Subject: [docs] typo report for packaging.pypi.simple
In-Reply-To: <CAD2XgA5kT18gd7ujmivy5WfE7nmCg6yyJ+u8YPbH_wYgPQ6QDQ@mail.gmail.com>
References: <CAD2XgA5kT18gd7ujmivy5WfE7nmCg6yyJ+u8YPbH_wYgPQ6QDQ@mail.gmail.com>
Message-ID: <CAPdtAj3BgASGZh0qLjHcd6yHP+HRGri2mOoMo7bbsdcMZhmJrQ@mail.gmail.com>

Hello Ori,
thanks for your email

On Tue, Dec 27, 2011 at 04:24, Ori Livneh <ori.livneh at gmail.com> wrote:
> http://docs.python.org/dev/library/packaging.pypi.simple.html#usage-exemples
>
> exemples => examples

this has now fixed in 43b10c2d2553 changeset.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Dec 31 13:02:55 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 31 Dec 2011 13:02:55 +0100
Subject: [docs] HELP ME PLS
In-Reply-To: <CANzP_eKf7+whE-OEvpu8VBfP0WV_v0O3+TtWgdc-CNfVUvfEMA@mail.gmail.com>
References: <CANzP_eKf7+whE-OEvpu8VBfP0WV_v0O3+TtWgdc-CNfVUvfEMA@mail.gmail.com>
Message-ID: <CAPdtAj3ftQs6Z0ow7Vx0+2ZK4ZojvRuMeL3+3a7UHD805BowYg@mail.gmail.com>

Hello muhammad,

On Fri, Dec 30, 2011 at 18:24, muhammad p m <ibrahimmuhammads at gmail.com> wrote:
> Sir,
> ? ? am doing software engineering in kerala,i would like to know more
> about python,i think i can work in python platform please send me the
> details or study material of python its a request of a student I think
> u never ignore this

This request is a bit generic. You can read the whole official Python
documentation at:

- http://docs.python.org/ (for Python 2.7)
- http://docs.python.org/py3k/ (for Python 3.2).

If you're starting from scratch, I encourage you to use python 3.2,
which is the future of the language.

You can probably find additional guidance on the
http://mail.python.org/mailman/listinfo/python-list mailing list
(given this one is about bugs & enhancement on the python docs).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Dec 31 15:31:43 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 31 Dec 2011 14:31:43 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1324903809.07.0.39088932351.issue13663@psf.upfronthosting.co.za>
Message-ID: <1325341903.3.0.41687807089.issue13663@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

naoki: what is your actual complaint about the installation being outdated? Are you referring to the message catalog (documentation version), or the software?

As for the message catalog, I don't think it should be updated too often (only once per Python release), otherwise, translators will have to fight a moving target (which they will have to, anyway, given that the documentation evolves).

Whatever updating procedure is performed: preserving the existing translations and the existing accounts is an absolute must.

I'm not sure what good renaming the service would do; this sounds like bike shedding.

----------

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

From report at bugs.python.org  Sat Dec 31 17:33:02 2011
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 31 Dec 2011 16:33:02 +0000
Subject: [docs] [issue13663] pootle.python.org is outdated.
In-Reply-To: <1325341903.3.0.41687807089.issue13663@psf.upfronthosting.co.za>
Message-ID: <CAEfz+Ty9637Q8sHw+mHZMkyE5+o=a7N6R2X9Q7L5=MHpO7YH0Q@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

On Sat, Dec 31, 2011 at 11:31 PM, Martin v. L?wis
<report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> naoki: what is your actual complaint about the installation being outdated? Are you referring to the message catalog (documentation version), or the software?

I need Python 3.2's message catalog. But updating pootle version is
also nice to me.

> As for the message catalog, I don't think it should be updated too often (only once per Python release), otherwise, translators will have to fight a moving target (which they will have to, anyway, given that the documentation evolves).
>

I agree with you about already released series (~3.2).
I think updating message catalog for beta versions may help releasing new
Python's translated document fast.

The way to manage multiple series is also needed when Python 3.3 is released.

----------

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