From report at bugs.python.org  Fri Mar  1 13:58:25 2013
From: report at bugs.python.org (Christoph Zwerschke)
Date: Fri, 01 Mar 2013 12:58:25 +0000
Subject: [docs] [issue17326] Windows build docs still referring to VS 2008
	in 3.3
Message-ID: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za>


New submission from Christoph Zwerschke:

The first paragraph in PCbuild/readme.txt of Python 3.3 still talks about Visual C++ 2008 Express and Visual Studio 2008. It says that VS 2008 is required at the very least (which may be still true, I'm not sure), but then it also says "the official Python releases are built with this [i.e. the 2008] version of VS", while it seems they have been built with VS 2010 in reality (as the title is also indicating).

----------
assignee: docs at python
components: Documentation
messages: 183259
nosy: cito, docs at python
priority: normal
severity: normal
status: open
title: Windows build docs still referring to VS 2008 in 3.3
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Fri Mar  1 14:00:17 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Mar 2013 13:00:17 +0000
Subject: [docs] [issue17326] Windows build docs still referring to VS 2008
	in 3.3
In-Reply-To: <1362142705.89.0.367756520949.issue17326@psf.upfronthosting.co.za>
Message-ID: <1362142817.77.0.32921209023.issue17326@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar  1 16:04:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2013 15:04:33 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
Message-ID: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>


New submission from Brett Cannon:

<EOM>

----------
assignee: docs at python
components: Documentation
messages: 183262
nosy: brett.cannon, docs at python, ezio.melotti, michael.foord, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unittest.SkipTest
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar  1 19:40:42 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Mar 2013 18:40:42 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1362163242.7.0.878166939556.issue11448@psf.upfronthosting.co.za>


?ric Araujo added the comment:

> This is a possible additional example for set_tunnel,
Thanks.  In general, our tooling expects unified diffs, such as produced by hg diff.

> modification of python3.3/html/_sources/library/http.client.txt
That?s a copy for web hosting, the real source is in Doc/library/http.client.rst (see devguide for more info).

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

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

From report at bugs.python.org  Fri Mar  1 22:31:03 2013
From: report at bugs.python.org (Ernie Hershey)
Date: Fri, 01 Mar 2013 21:31:03 +0000
Subject: [docs] [issue17332] typo in json docs - "convered" should be
	"converted"
Message-ID: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>


New submission from Ernie Hershey:

Hi,

On these pages:

http://docs.python.org/3.4/library/json.html
http://docs.python.org/3.3/library/json.html
http://docs.python.org/3.2/library/json.html
http://docs.python.org/2/library/json.html
http://docs.python.org/2.6/library/json.html

This line says "convered" but should be "converted."

Note Keys in key/value pairs of JSON are always of the type str. When a dictionary is converted into JSON, all the keys of the dictionary are coerced to strings. As a result of this, if a dictionary is convered into JSON and then back into a dictionary, the dictionary may not equal the original one. That is, loads(dumps(x)) != x if x has non-string keys.

----------
assignee: docs at python
components: Documentation
messages: 183293
nosy: docs at python, ernest
priority: normal
severity: normal
status: open
title: typo in json docs - "convered" should be "converted"
type: enhancement
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  1 23:42:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Mar 2013 22:42:31 +0000
Subject: [docs] [issue17309] __bytes__ doesn't work in subclass of int and
	str
In-Reply-To: <1361979686.07.0.236846670702.issue17309@psf.upfronthosting.co.za>
Message-ID: <1362177751.95.0.109015402078.issue17309@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The library doc says that if the source argument for bytes() or bytearray() is a string or integer it is treated a certain way. I believe 'string' and 'integer' are meant to include subclasses of str and int, else it should have said str or int. You have verified that int subclass instances are indeed treated as integers. The following shows that str subclass instances are treated as strings.

class mystr(str):
    def __bytes__(self): return b'hello'
print(bytes(mystr('a')))
raises TypeError: string argument without an encoding

The language reference says "object.__bytes__(self): Called by bytes() to compute a byte-string representation of an object." No exception is given. I see this as a contradiction in the manual, in which case the current behavior rules and the contradiction is removed by changing the doc part that conflicts with behavior. That would mean extending the doc sentence with 'that is not a string or integer'.

However, I am waiting for other opinions for two reasons.

1. The doc also specified special treatment for buffer interface and iterable objects. However, __bytes__ *is* checked first for those objects. 

class myit(list):
    def __bytes__(self): return b'hello'
print (bytes (myit([1,2,3])))
# b'hello'

class mybit(bytes):  # example 
    def __bytes__(self): return b'hello'
print (bytes (mybit(b'a')))
# b'hello'

So the exception is limited to 'strings' and 'integers', making it somewhat inconsistent.

2. If someone gives an str or int subclass a __bytes__ method, they can only mean for it to be called by bytes(), as there is no other use of that special method.

On the third hand, a user of a class who tests its instances before calling bytes with "isinstance(x, (str, int))" instead of "type(x) is str or type(x) is int", likely expects getting normal string or integer behavior. Of course, the same might be true if the test is 'isiterable(x)'.

If behavior were changed, I think it should wait for 3.4 since the current behavior is not clearly a bug to me.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, terry.reedy
title: __bytes__ doesn't work in subclass of int -> __bytes__ doesn't work in subclass of int and str
versions: +Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar  1 23:45:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Mar 2013 22:45:01 +0000
Subject: [docs] [issue17285] subprocess.check_output incorrectly state that
	output is	always bytes
In-Reply-To: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>
Message-ID: <1362177901.48.0.785360125308.issue17285@psf.upfronthosting.co.za>


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


----------
nosy: +terry.reedy
versions: +Python 3.4 -Python 3.1

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

From report at bugs.python.org  Sat Mar  2 00:03:39 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Mar 2013 23:03:39 +0000
Subject: [docs] [issue17309] __bytes__ doesn't work in subclass of int and
	str
In-Reply-To: <1361979686.07.0.236846670702.issue17309@psf.upfronthosting.co.za>
Message-ID: <1362179019.82.0.210337701512.issue17309@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

More data:

class myit(list):
    def __bytes__(self): return b'hello'
print (bytes(b'a'))

class myit(list):
    def __bytes__(self): return b'hello'
print (bytearray (myit([1,2,3])))

# bytearray(b'a')
# bytearray(b'\x01\x02\x03')

class by:
    def __bytes__(self): return b'hello'
# TypeError: 'by' object is not iterable
(Error message is incomplete.)

So bytearray *always* treats objects as specified in its library entry and never calls __bytes__, making its value sometimes unequal as a sequence of bytes from bytes with the same input.

----------

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

From report at bugs.python.org  Sat Mar  2 19:42:21 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Mar 2013 18:42:21 +0000
Subject: [docs] [issue17309] __bytes__ doesn't work in subclass of int and
	str
In-Reply-To: <1361979686.07.0.236846670702.issue17309@psf.upfronthosting.co.za>
Message-ID: <1362249741.84.0.338357934841.issue17309@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This has been fixed recently:

 $ ./python bytes.py 
b'\x00'
b'hello'

----------
nosy: +benjamin.peterson
resolution:  -> out of date
status: open -> closed

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

From mhoy09 at gmail.com  Sat Mar  2 23:12:47 2013
From: mhoy09 at gmail.com (mhoy09 at gmail.com)
Date: Sat, 02 Mar 2013 22:12:47 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20130302221247.16716.69426@psf.upfronthosting.co.za>


http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst#newcode1048
Doc/reference/expressions.rst:1048: specific :meth:`__eq__()` and
:meth:`__ne__()`. With ``<``, ``>``,
On 2013/02/23 07:51:56, ezio.melotti wrote:
> These should be :meth:`~object.__eq__` (or whatever creates a link to
the __eq__
> documention).  The () shouldn't be included.
Currently working on this.

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

From mhoy09 at gmail.com  Sun Mar  3 01:01:17 2013
From: mhoy09 at gmail.com (mhoy09 at gmail.com)
Date: Sun, 03 Mar 2013 00:01:17 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20130303000117.16681.40833@psf.upfronthosting.co.za>

On 2013/02/23 07:51:56, ezio.melotti wrote:
>
http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst
> File Doc/reference/expressions.rst (right):
> 
>
http://bugs.python.org/review/12067/diff/6175/Doc/reference/expressions.rst#newcode1048
> Doc/reference/expressions.rst:1048: specific :meth:`__eq__()` and
> :meth:`__ne__()`. With ``<``, ``>``,
> These should be :meth:`~object.__eq__` (or whatever creates a link to
the __eq__
> documention).  The () shouldn't be included.
It appears that this section of the documentation is vary different from
what I worked on 4 months ago. Can we please get some input as to
whether or not this issue needs to remain open?


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

From mhoy09 at gmail.com  Sun Mar  3 01:01:24 2013
From: mhoy09 at gmail.com (mhoy09 at gmail.com)
Date: Sun, 03 Mar 2013 00:01:24 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20130303000124.16681.86894@psf.upfronthosting.co.za>

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

From report at bugs.python.org  Sun Mar  3 04:19:00 2013
From: report at bugs.python.org (karl)
Date: Sun, 03 Mar 2013 03:19:00 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1362280740.85.0.17514325081.issue11448@psf.upfronthosting.co.za>


karl added the comment:

Ah thanks Eric, I will fix that.

----------

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

From report at bugs.python.org  Sun Mar  3 04:31:21 2013
From: report at bugs.python.org (karl)
Date: Sun, 03 Mar 2013 03:31:21 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1362281481.93.0.810480164829.issue11448@psf.upfronthosting.co.za>


karl added the comment:

ok made a proper patch on the rst file with hg diff.
See issue-11448-1.patch

----------
Added file: http://bugs.python.org/file29293/issue-11448-1.patch

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

From report at bugs.python.org  Sun Mar  3 07:24:49 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Sun, 03 Mar 2013 06:24:49 +0000
Subject: [docs] [issue15542] Documentation incorrectly suggests __init__
	called after	direct __new__ call
In-Reply-To: <1343946223.73.0.562621858875.issue15542@psf.upfronthosting.co.za>
Message-ID: <1362291889.63.0.684694593671.issue15542@psf.upfronthosting.co.za>


Changes by Ankur Ankan <ankurankan at gmail.com>:


----------
nosy: +Ankur.Ankan

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

From report at bugs.python.org  Sun Mar  3 18:04:21 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 Mar 2013 17:04:21 +0000
Subject: [docs] [issue14123] Indicate that there are no current plans to
	deprecate	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1362330261.57.0.800972485022.issue14123@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I can't see too much sense in leaving this open, what are your opinions?

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

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

From report at bugs.python.org  Sun Mar  3 23:15:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 03 Mar 2013 22:15:44 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362348944.19.0.360981452106.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

moijes, did you address the review comments?

Does your patch apply to 3.2?

----------

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

From report at bugs.python.org  Mon Mar  4 04:48:43 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 04 Mar 2013 03:48:43 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362368923.05.0.9229851148.issue16278@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


Removed file: http://bugs.python.org/file27890/OSRename_test_os_3point4.patch

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

From report at bugs.python.org  Mon Mar  4 04:48:54 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 04 Mar 2013 03:48:54 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362368934.41.0.610837828612.issue16278@psf.upfronthosting.co.za>


Changes by Todd Rovito <rovitotv at gmail.com>:


Removed file: http://bugs.python.org/file28071/OSRenameDocs3point4.patch

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

From report at bugs.python.org  Mon Mar  4 04:53:54 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 04 Mar 2013 03:53:54 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362369234.18.0.558563973256.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Combined the test cases and document changes into a single patch.  As suggested by Mr. Terry Reedy I used a table and removed the text.  The table still needs some work but it is a good start.  As suggested by Mr. Jerdonek I tried to make the test cases WETter by setting up the files and directories one time in the setup method then only changing that setup in the actual test case only if needed.  

This patch needs still needs some work but I wanted people to know I had not quit yet.  It still needs to be tested on Windows, which I will do ASAP.  Thanks.

----------
Added file: http://bugs.python.org/file29301/16278OSRenameDocsTest.patch

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

From report at bugs.python.org  Mon Mar  4 13:36:21 2013
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 04 Mar 2013 12:36:21 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1362400580.98.0.603046764475.issue16851@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I agree that the docs for inspect.ismethod() for Python 2 are wrong.

The docs say: "Return true if the object is a bound method written in Python."

However, it also returns True for an unbound method:

>>> class A:
...     def meth(self):
...         pass
... 
>>> A.meth
<unbound method A.meth>
>>> import inspect
>>> inspect.ismethod(A.meth)
True

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

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

From report at bugs.python.org  Mon Mar  4 15:36:39 2013
From: report at bugs.python.org (Phil Elson)
Date: Mon, 04 Mar 2013 14:36:39 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
Message-ID: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>


New submission from Phil Elson:

The example at http://docs.python.org/3.4/howto/descriptor.html#properties does not run due to the old style "raise AttributeError, message" form. 


This patch fixes the problem, and also goes through the docs to remove explicit sub-classing from "object". The only remaining instances of this now are:

$> grep -r -E "class .*\(object\)\:" Doc/*               
Doc/howto/pyporting.rst:   class UnicodeMixin(object):
Doc/reference/compound_stmts.rst:   class Foo(object):
Doc/tools/sphinxext/pyspecific.py:class PyDecoratorMixin(object):
Doc/whatsnew/2.6.rst:    class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   class C(object):
Doc/whatsnew/2.2.rst:   >>> class C(object):


Which are all (minus tools/sphinxext/pyspecific) referring to python2 in some context.

I'm not bound to fixing the explicit object subclassing, so if it is better off not being here, that's fine.

Cheers,

----------
assignee: docs at python
components: Documentation
files: pelson_doc_decorator.diff
keywords: patch
messages: 183458
nosy: docs at python, pelson, rhettinger
priority: normal
severity: normal
status: open
title: Fixed python3 descriptor documentation example + removal of explicit "object" inheritance in docs
versions: Python 3.1
Added file: http://bugs.python.org/file29305/pelson_doc_decorator.diff

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

From report at bugs.python.org  Mon Mar  4 15:54:53 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 04 Mar 2013 14:54:53 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1362408893.19.0.729204972383.issue16575@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

A minimal fix would be to update the documentation.

A more comprehensive fix would be to tweak ctypes to reject unions and bit-fields when running on non-x86 (does this work for ARM and other non-Intel archs?)

An even more comprehensive fix would be to make this work, but that would require forking libffi and should presumably be first implemented upstream.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eli.bendersky
stage:  -> needs patch
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar  4 16:12:58 2013
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 04 Mar 2013 15:12:58 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1362409977.96.0.812954271836.issue16575@psf.upfronthosting.co.za>


Armin Rigo added the comment:

See also http://bugs.python.org/issue16576.

----------

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

From report at bugs.python.org  Mon Mar  4 17:49:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Mar 2013 16:49:07 +0000
Subject: [docs] [issue14123] Indicate that there are no current plans to
	deprecate	printf-style formatting
In-Reply-To: <1330202928.96.0.727285588049.issue14123@psf.upfronthosting.co.za>
Message-ID: <1362415747.39.0.627983522551.issue14123@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The only issue seems about the use of the word "deprecate", but I think it's fine, so I'll close this issue.

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

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

From ezio.melotti at gmail.com  Mon Mar  4 18:15:16 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 04 Mar 2013 17:15:16 -0000
Subject: [docs] os.rename documentation slightly inaccurate (issue 16278)
Message-ID: <20130304171516.5695.16867@psf.upfronthosting.co.za>

I left a few comments.
Most of them apply to several parts of the code, even though I just
commented in a single place.


http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py
File Lib/test/test_os.py (right):

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode55
Lib/test/test_os.py:55: # Tests creating TESTFN and os.rename
I think it would be better to make a separate class for os.rename.  The
changes to setUp/tearDown are only needed for the new tests, but they
are executed for all the old tests too, and that's not necessary.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode62
Lib/test/test_os.py:62: self.rename_src_file = "%s_%d_tmp" %
("test_rename_src_file", \
All the \ are useless and should be removed (or possibly replaced by an
extra set of ()).

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode85
Lib/test/test_os.py:85: if (os.path.exists(self.rename_dst_directory +
"/file.txt")):
Shouldn't this use os.path.join()?
Also "/file.txt" is repeated over and over -- it would be better to use
a variable instead.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode125
Lib/test/test_os.py:125: os.rmdir(self.rename_src_directory)
This could be rewritten as:
files = [support.TESTFN, self.rename_src_file, ...]
for file in files:
    if os.path.exists(file):
        os.unlink(file) 

for the dirs you can have the same 4 lines with rmdir instead, or check
if they are files or dir and use the same loop.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode161
Lib/test/test_os.py:161: @support.cpython_only
Why are this cpython_only?
Does the behavior depend on the CPython implementation or on the OS
and/or underlying posix function?

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode164
Lib/test/test_os.py:164: (sys.platform == 'win32') ), \
All the \ should be removed, and there are also 4 sets of () that are
not necessary and could be removed as well.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode165
Lib/test/test_os.py:165: 'test specific to windows or linux or darwin
only')
Is this because you only tested it on these platforms?
I would run it on other platforms too, and possibly add specific skips
if they fail there (unless of course the failure is caused by a bug that
should be fixed).
If the skip is really necessary I would create a new skip decorator and
use that, instead of repeating this over and over.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode167
Lib/test/test_os.py:167: if ((sys.platform == 'darwin') or
(sys.platform.startswith == "linux")):
All the () are unnecessary and should be removed.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode171
Lib/test/test_os.py:171: [b"beans", b"bacon", b"eggs", b"spam"])
PEP8 says that this should either be indented as

self.assertEqual(fobj.read().splitlines(),
                 [b"beans", b"bacon", b"eggs", b"spam"])

or as

self.assertEqual(
    fobj.read().splitlines(),
    [b"beans", b"bacon", b"eggs", b"spam"])

http://www.python.org/dev/peps/pep-0008/#indentation

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode185
Lib/test/test_os.py:185: os.unlink(self.rename_dst_file) # delete
rename_dst_file
Shouldn't the setUp/tearDown already take care of this?

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode369
Lib/test/test_os.py:369: self.assertRaises(OSError, os.rename,
self.rename_src_file, \
self.assertRaises() can be used as a context manager too, to make the
code more readable.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode396
Lib/test/test_os.py:396:
self.assertEqual(os.path.exists(self.rename_dst_directory), True)
self.assertTrue(os.path.exists(self.rename_dst_directory))

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

From report at bugs.python.org  Mon Mar  4 18:27:47 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Mar 2013 17:27:47 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362418067.39.0.748533119488.issue16278@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Adding more tests is good, even though there are still a few things that should be improved (see comments on rietveld).
Regarding the documentation I'm not sure it's a good idea to be so detailed.  On one hand, if we test the behavior we can make sure that the documentation is accurate, OTOH it might make the docs more confusing and once this behavior is documented it will be difficult to change it (and there might still be exceptions on different platforms/filesystems or if symlinks are involved).
Maybe it would be better to suggest a LBYL approach rather trying to document and deal with all the different combinations.

----------

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

From report at bugs.python.org  Mon Mar  4 18:29:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2013 17:29:57 +0000
Subject: [docs] [issue17332] typo in json docs - "convered" should be
	"converted"
In-Reply-To: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>
Message-ID: <1362418197.52.0.895898572871.issue17332@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.5

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

From report at bugs.python.org  Mon Mar  4 18:30:19 2013
From: report at bugs.python.org (moijes12)
Date: Mon, 04 Mar 2013 17:30:19 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362418219.88.0.703328654353.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

Hi 

I am seen the review comments and made the changes accordingly. I am not sure if my changes apply to 3.2. How do I do that ?

----------

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

From report at bugs.python.org  Mon Mar  4 19:00:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Mar 2013 18:00:18 +0000
Subject: [docs] [issue16851] Hint about correct ismethod and isfunction usage
In-Reply-To: <1357231289.77.0.0608728593688.issue16851@psf.upfronthosting.co.za>
Message-ID: <1362420018.31.0.535883482457.issue16851@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I checked the tests on 2.7 and found this:

        # contrary to spec, ismethod() is also True for unbound methods
        # (see #1785)
        self.assertIn(('f', B.f), inspect.getmembers(B, inspect.ismethod))

#1785 also has some discussion about this.

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

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

From report at bugs.python.org  Mon Mar  4 19:20:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Mar 2013 18:20:15 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362421215.52.0.58959940456.issue12768@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

3.2$ hg imp --no-c http://bugs.python.org/file29268/12768_2.patch
applying http://bugs.python.org/file29268/12768_2.patch
patching file Lib/threading.py
Hunk #3 FAILED at 58
Hunk #4 FAILED at 79
Hunk #5 FAILED at 92
Hunk #6 FAILED at 125
Hunk #10 FAILED at 252
Hunk #12 succeeded at 386 with fuzz 1 (offset 82 lines).
Hunk #13 FAILED at 317
Hunk #17 FAILED at 405
Hunk #22 FAILED at 576
Hunk #23 FAILED at 589
Hunk #30 FAILED at 897
Hunk #33 succeeded at 1124 with fuzz 2 (offset 132 lines).
10 out of 35 hunks FAILED -- saving rejects to file Lib/threading.py.rej
abort: patch failed to apply

>  I am not sure if my changes apply to 3.2. How do I do that ?

You have to switch to the 3.2 branch using "hg up 3.2", and then use "hg import" as showed above to apply the patch.  You will also need to run configure/make again to build 3.2, so you can run tests.

----------

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

From report at bugs.python.org  Mon Mar  4 19:24:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Mar 2013 18:24:57 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362421497.07.0.326281456701.issue12768@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FWIW it applies cleanly on 3.3, but unless we decide to target 3.3+ only, the patch needs to be adapted for 2.7/3.2.

----------

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

From report at bugs.python.org  Tue Mar  5 05:05:14 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 05 Mar 2013 04:05:14 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362456314.33.0.129592963196.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Ezio,
  Thank you or the feedback I will continue to polish the test cases.  As far as the documentation I really like the table and find it easy to read but I could go either way.  If you read the history of this issue other Python Core Developers asked to write test cases and make sure the documentation matches the test cases.  It makes no difference to me I just want to contribute!!!!  Which approach will produce the best results for the Python community? I think the table is a good compromise.

----------

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

From report at bugs.python.org  Tue Mar  5 12:01:03 2013
From: report at bugs.python.org (Kushal Das)
Date: Tue, 05 Mar 2013 11:01:03 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1362481263.81.0.248568784146.issue15465@psf.upfronthosting.co.za>


Changes by Kushal Das <kushaldas at gmail.com>:


Added file: http://bugs.python.org/file29313/issue15465v4.patch

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

From report at bugs.python.org  Tue Mar  5 12:04:13 2013
From: report at bugs.python.org (Kushal Das)
Date: Tue, 05 Mar 2013 11:04:13 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1362481452.96.0.502899141571.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

version 4 of the patch contains a new column in table as Bytes as suggested by Ezio Melotti

----------

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

From eliben at gmail.com  Tue Mar  5 15:26:24 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 5 Mar 2013 06:26:24 -0800
Subject: [docs] undocumented argtypes magic in ctypes?
Message-ID: <CAF-Rda9T=LfviFKqT-qkNDPP9ba-Kg=M41RLac_miA99dXjOAA@mail.gmail.com>

Hello,

While playing with ctypes a bit, I noticed a feature that doesn't appear to
be documented. Suppose I import the readdir_r function (assuming DIRENT is
a correctly declared ctypes.Structure):

DIR_p = c_void_p
DIRENT_p = POINTER(DIRENT)
DIRENT_pp = POINTER(DIRENT_p)

readdir_r = lib.readdir_r
readdir_r.argtypes = [DIR_p, DIRENT_p, DIRENT_pp]
readdir_r.restype = c_int

It seems that I can then call it as follows:

dirent = DIRENT()
result = DIRENT_p()

readdir_r(dir_fd, dirent, result)

Note that while readdir_r takes DIRENT_p and DIRENT_pp as its second and
third args, I pass in just DIRENT and DIRENT_p, accordingly. What I should
have done is use byref() on both, but ctypes seems to have some magic
applied when argtypes declares pointer types. If I use byref, it still
works. However, if I keep the same call and comment out the argtypes
declaration, I get a segfault.

So, is it a feature that should be documented, explicitly discouraged or is
it a bug?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130305/4b4d4637/attachment.html>

From report at bugs.python.org  Tue Mar  5 19:12:15 2013
From: report at bugs.python.org (Vladimir Rutsky)
Date: Tue, 05 Mar 2013 18:12:15 +0000
Subject: [docs] [issue17356] Invalid link to repr() built-in function
	description
Message-ID: <1362507135.12.0.423032726441.issue17356@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

References to built-in function repr() links to repr module (http://docs.python.org/2/library/repr.html#module-repr), but must link to description in http://docs.python.org/2/library/functions.html.

It can be at least in http://docs.python.org/2/library/functions.html (link in table at page top).

----------
assignee: docs at python
components: Documentation
messages: 183538
nosy: docs at python, vrutsky
priority: normal
severity: normal
status: open
title: Invalid link to repr() built-in function description
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 19:50:29 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Mar 2013 18:50:29 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1362509429.26.0.22786968807.issue14489@psf.upfronthosting.co.za>


R. David Murray added the comment:

Confirm that this is not fixed.

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

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

From report at bugs.python.org  Tue Mar  5 19:51:23 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Mar 2013 18:51:23 +0000
Subject: [docs] [issue17356] Invalid link to repr() built-in function
	description
In-Reply-To: <1362507135.12.0.423032726441.issue17356@psf.upfronthosting.co.za>
Message-ID: <1362509483.56.0.232116337658.issue17356@psf.upfronthosting.co.za>


R. David Murray added the comment:

Closing in favor of re-opening issue 14489, which tried to fix this and apparently failed.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> repr() function link on the built-in function documentation is incorrect

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

From report at bugs.python.org  Tue Mar  5 19:51:48 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Mar 2013 18:51:48 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1362509508.68.0.718886368437.issue14489@psf.upfronthosting.co.za>


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


----------
nosy: +vrutsky

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

From report at bugs.python.org  Tue Mar  5 20:01:10 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Mar 2013 19:01:10 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1362510070.19.0.205950491087.issue14489@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/issue14489>
_______________________________________

From report at bugs.python.org  Tue Mar  5 20:40:25 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 Mar 2013 19:40:25 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
Message-ID: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg:

The feature to run a ZIP file containing Python modules is not documented.

It was implemented in Python 2.6:

 * http://bugs.python.org/issue1739468

and mentioned in the "What's new":

 * http://docs.python.org/2/whatsnew/2.6.html?highlight=python%20run%20zip%20files#other-language-changes

but searching the documentation for "__main__.py" returns 0 hits in the docs (for Python 2.7 and 3.4).

I guess "python dir" should also be mentioned somewhere...

----------
assignee: docs at python
components: Documentation
messages: 183550
nosy: docs at python, lemburg
priority: normal
severity: normal
status: open
title: python modules.zip is not documented
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Mar  5 20:48:45 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 05 Mar 2013 19:48:45 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1362512925.34.0.75235502308.issue17359@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

>From http://docs.python.org/3/using/cmdline.html:

  Package names are also permitted. When a package name is supplied instead of a normal module, the interpreter will execute <pkg>.__main__ as the main module. This behaviour is deliberately similar to the handling of directories and zipfiles that are passed to the interpreter as the script argument.

This is for "-m"

Also:

 <script>

    Execute the Python code contained in script, which must be a filesystem path (absolute or relative) referring to either a Python file, a directory containing a __main__.py file, or a zipfile containing a __main__.py file.

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

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

From report at bugs.python.org  Tue Mar  5 23:32:11 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Mar 2013 22:32:11 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362522731.09.0.669170750833.issue17329@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a pair of patches for 3.x and 2.7.  The 3.x patch is actually targeted at default; it has a couple extra instances of ``SkipTest`` that are converted to :exc:`SkipTest` in the patch.

----------
keywords: +patch
versions: +Python 3.3
Added file: http://bugs.python.org/file29318/issue17329.diff

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

From report at bugs.python.org  Tue Mar  5 23:32:39 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Mar 2013 22:32:39 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362522759.66.0.999487804744.issue17329@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file29319/issue17329-2.7.diff

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

From report at bugs.python.org  Tue Mar  5 23:37:55 2013
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 05 Mar 2013 22:37:55 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362523075.45.0.281279449852.issue17329@psf.upfronthosting.co.za>


Zachary Ware added the comment:

In the patches, the description of SkipTest is copied directly from the docstring in Lib/unittest/case.py with a bit of markup added.  It mentions TestResult.skip(), which doesn't exist.  I wonder if that was meant to be TestCase.skipTest()?

----------
type:  -> enhancement
versions: +Python 2.7, Python 3.2

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

From report at bugs.python.org  Wed Mar  6 01:05:40 2013
From: report at bugs.python.org (Tobias Becker)
Date: Wed, 06 Mar 2013 00:05:40 +0000
Subject: [docs] [issue17363] Argument Mixup in PyState_AddModule
Message-ID: <1362528340.9.0.203037073378.issue17363@psf.upfronthosting.co.za>


New submission from Tobias Becker:

http://docs.python.org/3.3/c-api/module.html?highlight=pymodule#PyState_AddModule

the arguments of PyState_AddModule are in wrong order:
currently: int PyState_AddModule(PyModuleDef *def, PyObject *module)
correct: int PyState_AddModule(PyObject *module,PyModuleDef *def)

----------
assignee: docs at python
components: Documentation
messages: 183564
nosy: Tobias.Becker, docs at python
priority: normal
severity: normal
status: open
title: Argument Mixup in PyState_AddModule
versions: Python 3.3

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

From report at bugs.python.org  Wed Mar  6 01:38:17 2013
From: report at bugs.python.org (Topher Brown)
Date: Wed, 06 Mar 2013 00:38:17 +0000
Subject: [docs] [issue17364] Multiprocessing documentation mentions function
	that	doesn't exist
Message-ID: <1362530297.79.0.346292892341.issue17364@psf.upfronthosting.co.za>


New submission from Topher Brown:

multiprocessing documentation (http://docs.python.org/2/library/multiprocessing.html#pipes-and-queues) for multiprocessing.Queue mentions Queue.get_no_wait() as an alias for Queue.get_nowait(). This function does not seem to exist.

----------
assignee: docs at python
components: Documentation
messages: 183566
nosy: Topher.Brown, docs at python
priority: normal
severity: normal
status: open
title: Multiprocessing documentation mentions function that doesn't exist
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  6 01:48:40 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 06 Mar 2013 00:48:40 +0000
Subject: [docs] [issue17364] Multiprocessing documentation mentions function
	that	doesn't exist
In-Reply-To: <1362530297.79.0.346292892341.issue17364@psf.upfronthosting.co.za>
Message-ID: <1362530920.24.0.972348065556.issue17364@psf.upfronthosting.co.za>


Changes by Richard Oudkerk <shibturn at gmail.com>:


----------
nosy: +sbt

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

From report at bugs.python.org  Wed Mar  6 01:59:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Mar 2013 00:59:37 +0000
Subject: [docs] [issue17363] Argument Mixup in PyState_AddModule
In-Reply-To: <1362528340.9.0.203037073378.issue17363@psf.upfronthosting.co.za>
Message-ID: <3ZLGpJ6HFcz7Lkh@mail.python.org>


Roundup Robot added the comment:

New changeset 29d5bc1226f9 by Ezio Melotti in branch '3.3':
#17363: fix arguments in PyState_AddModule and PyState_RemoveModule docs.
http://hg.python.org/cpython/rev/29d5bc1226f9

New changeset 75c0cb169be5 by Ezio Melotti in branch 'default':
#17363: merge with 3.3.
http://hg.python.org/cpython/rev/75c0cb169be5

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

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

From report at bugs.python.org  Wed Mar  6 02:03:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Mar 2013 01:03:39 +0000
Subject: [docs] [issue17363] Argument Mixup in PyState_AddModule
In-Reply-To: <1362528340.9.0.203037073378.issue17363@psf.upfronthosting.co.za>
Message-ID: <1362531819.35.0.382388945307.issue17363@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Wed Mar  6 02:24:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Mar 2013 01:24:07 +0000
Subject: [docs] [issue17364] Multiprocessing documentation mentions function
	that	doesn't exist
In-Reply-To: <1362530297.79.0.346292892341.issue17364@psf.upfronthosting.co.za>
Message-ID: <3ZLHLY2wmVzSlH@mail.python.org>


Roundup Robot added the comment:

New changeset 01a8fcc91d5a by Ezio Melotti in branch '2.7':
#17364: remove documentation for a function that does not exist.
http://hg.python.org/cpython/rev/01a8fcc91d5a

New changeset 4f9de1b18cab by Ezio Melotti in branch '3.2':
#17364: remove documentation for a function that does not exist.
http://hg.python.org/cpython/rev/4f9de1b18cab

New changeset 5e294202f93e by Ezio Melotti in branch '3.3':
#17364: merge with 3.2.
http://hg.python.org/cpython/rev/5e294202f93e

New changeset b87e9b8dc9ad by Ezio Melotti in branch 'default':
#17364: merge with 3.3.
http://hg.python.org/cpython/rev/b87e9b8dc9ad

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

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

From report at bugs.python.org  Wed Mar  6 02:25:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Mar 2013 01:25:22 +0000
Subject: [docs] [issue17364] Multiprocessing documentation mentions function
	that	doesn't exist
In-Reply-To: <1362530297.79.0.346292892341.issue17364@psf.upfronthosting.co.za>
Message-ID: <1362533122.63.0.356889348869.issue17364@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> enhancement
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar  6 02:50:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Mar 2013 01:50:41 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362534641.23.0.98140781839.issue17329@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I wonder if that was meant to be TestCase.skipTest()?

Most likely.

I would document this exception at the end of the "Skipping tests and expected failures".  You could documented it simply as "the exception raised by the skip decorators", and suggest to use TestCase.skipTest() to skip a test rather than just raising this exception directly.

I'm also not sure if the note should be kept -- it seems quite obvious to me that the test will be marked as skipped even if previous assertions succeeded.  Moreover, if the exception is generally not supposed to be used directly there's no need to explain how to use it.

----------

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

From report at bugs.python.org  Wed Mar  6 03:42:54 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Mar 2013 02:42:54 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1362537774.16.0.624716539494.issue15465@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Mostly looks good to me, but the second sentence in the first paragraph of the new section should be deleted. The relationship between PY_LIMITED_API and PY_VERSION_HEX is already covered in the stable ABI docs:

"""In some cases, the stable ABI needs to be extended with new functions. Extensions modules wishing to use these new APIs need to set Py_LIMITED_API to the PY_VERSION_HEX value of the minimum Python version they want to support (e.g. 0x03030000 for Python 3.3). Such modules will work on all subsequent Python releases, but fail to load (because of missing symbols) on the older releases."""

(As a separate issue, it may be worth doing an editing pass on the stable ABI docs - there are a few typos in there, and the layout is a bit odd for a reference doc. We shouldn't hold up this patch for that, though).

----------

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

From report at bugs.python.org  Wed Mar  6 05:10:23 2013
From: report at bugs.python.org (Kushal Das)
Date: Wed, 06 Mar 2013 04:10:23 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1362543023.87.0.938881326326.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

Attached version 5 of the patch with changes based on suggestions of ncoghlan

----------
Added file: http://bugs.python.org/file29321/issue15465v5.patch

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

From report at bugs.python.org  Wed Mar  6 15:43:26 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 06 Mar 2013 14:43:26 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362581005.94.0.520528958264.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I wouldn't expend too much effort on older versions though. So unless it's simple to adapt, IMHO 3.3+ is good enough.

----------

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

From report at bugs.python.org  Wed Mar  6 16:29:13 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 06 Mar 2013 15:29:13 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362583753.39.0.527880351909.issue17329@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fair points.  I had originally put it in the section you suggested, but then decided that it better fit in a new section of its own under "Classes and functions" as that section "describes in depth the API of unittest."  But then, it also makes sense to move the decorators into the new section, and just link to them in the old section.

So, how about this patch?  I'm fine with moving everything back to the old section if I've gone in the wrong direction :).  And I'll create the 2.7 patch after the 3.x version is approved one way or the other.

----------
Added file: http://bugs.python.org/file29328/issue17329.v2.diff

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

From report at bugs.python.org  Wed Mar  6 17:51:00 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 06 Mar 2013 16:51:00 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362588659.28.0.665419178958.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

This patch was built on 3.2(I made the changes on the local repo after running command "hg up 3.2"). I've run the test suite and only test_site failed. This patch has some improvements over 12768_2.patch.

----------
Added file: http://bugs.python.org/file29330/12768_3.patch

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

From report at bugs.python.org  Wed Mar  6 21:53:46 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Mar 2013 20:53:46 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1362603226.16.0.932231346735.issue12768@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I haven't read the patch in detail but I think the reference to Java's threading model could probably be discarded. First, I don't know if it's still true, second, I don't think anyone cares :)

----------
nosy: +pitrou
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Mar  6 22:39:11 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 06 Mar 2013 21:39:11 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1362603226.16.0.932231346735.issue12768@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda8XgOGpAUi3u1EzStVZCcV0Gz5RH7b68YhCsMmXU5qCkg@mail.gmail.com>


Eli Bendersky added the comment:

> I haven't read the patch in detail but I think the reference to Java's
> threading model could probably be discarded. First, I don't know if it's
> still true, second, I don't think anyone cares :)
>
>
I agree. It could be a remnant of a time where the threading library was
very new and so it helped "relating" it to something familiar. These days
there are (thankfully) many programmers coming to Python without any Java
background.

----------

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

From report at bugs.python.org  Thu Mar  7 02:13:04 2013
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 07 Mar 2013 01:13:04 +0000
Subject: [docs] [issue17370] PEP should not if it has been superseded
Message-ID: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>


New submission from Brandon Craig Rhodes:

A friend (@theomn on Twitter) was just working off of PEP-333 when I mentioned to him that PEP-3333, and he had never heard of it, and he expressed the wish that PEPs would have a banner or something at the top if there is a more recent version of them. I think his idea is great, and is like the feature of PyPI where if Google lands you on an old version of a package then it is careful to tell you up at the top that a more recent version is available.

This could extend to all sorts of cross-references that we should maintain: some PEPs have been superseded; others have more recent supplements that people should read as well (think of the relationship between packaging PEPs); PEPs that did not wind up being implemented have cousins who were; and so forth.

Is this something that needs to wait until the New Python Web Site appears, and that would be meta-markup somehow maintained along with the PEP texts themselves? Or should there be a ?Related PEPs? paragraph that we open at the top of each relevant PEP and just include the cross-links as raw updates to the PEP's own restructured text? I'm open to a simple implementation here, so long as we can provide more ?community context? when people land on a PEP.

----------
assignee: docs at python
components: Documentation
messages: 183625
nosy: brandon-rhodes, docs at python
priority: normal
severity: normal
status: open
title: PEP should not if it has been superseded

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

From report at bugs.python.org  Thu Mar  7 02:14:04 2013
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 07 Mar 2013 01:14:04 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362618842.83.0.324293361792.issue17370@psf.upfronthosting.co.za>


Brandon Craig Rhodes added the comment:

(Corrected "not" to "note" in the title and went with "enhancement")

----------
title: PEP should not if it has been superseded -> PEP should note if it has been superseded
type:  -> enhancement

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

From report at bugs.python.org  Thu Mar  7 02:16:12 2013
From: report at bugs.python.org (Brandon Craig Rhodes)
Date: Thu, 07 Mar 2013 01:16:12 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362618971.53.0.100302761968.issue17370@psf.upfronthosting.co.za>


Brandon Craig Rhodes added the comment:

The original inspiration:

https://twitter.com/theomn/status/309468740611891200

----------

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

From report at bugs.python.org  Thu Mar  7 02:24:48 2013
From: report at bugs.python.org (Owen Nelson)
Date: Thu, 07 Mar 2013 01:24:48 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362619488.91.0.542373498993.issue17370@psf.upfronthosting.co.za>


Changes by Owen Nelson <onelson at gmail.com>:


----------
nosy: +Owen.Nelson

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

From report at bugs.python.org  Thu Mar  7 10:24:15 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2013 09:24:15 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
Message-ID: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

It should be an easy task fill-in the missing docstrings using the verbiage in the regular docs.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 183645
nosy: docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Add docstrings to methods in the threading module
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 12:36:17 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 07 Mar 2013 11:36:17 +0000
Subject: [docs] [issue17376] TimedRotatingFileHandler documentation
	regarding 'Week	day' lacking
Message-ID: <1362656177.01.0.275089317243.issue17376@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

Usage of 'W' type is not clear from reading the documentation, specifically how to specify what day-of-week: Doc/library/logging.handlers.rst:291.

An example http://stackoverflow.com/q/14304954/321731.

----------
assignee: docs at python
components: Documentation
messages: 183652
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: TimedRotatingFileHandler documentation regarding 'Week day' lacking
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From eliben at gmail.com  Thu Mar  7 14:25:18 2013
From: eliben at gmail.com (Eli Bendersky)
Date: Thu, 7 Mar 2013 05:25:18 -0800
Subject: [docs] [Python-Dev]  undocumented argtypes magic in ctypes?
In-Reply-To: <kh9u40$hdr$1@ger.gmane.org>
References: <CAF-Rda9T=LfviFKqT-qkNDPP9ba-Kg=M41RLac_miA99dXjOAA@mail.gmail.com>
	<CAL3CFcUoKG=+vaTBMs6nSbgz_gJgxLX3_uK94JLSyEpOY7iy_Q@mail.gmail.com>
	<CAF-Rda_Gs0GT55+=HimkUVa5icS0X=vWBHug8iByq9=C1YEsmA@mail.gmail.com>
	<kh9u40$hdr$1@ger.gmane.org>
Message-ID: <CAF-Rda9oR592_K1dURGziriCC7ACDmJOQAqFhtPPm3tUghs63g@mail.gmail.com>

On Thu, Mar 7, 2013 at 3:37 AM, Thomas Heller <theller at ctypes.org> wrote:

> Am 06.03.2013 18:19, schrieb Eli Bendersky:
>
>>
>>
>>
>> On Wed, Mar 6, 2013 at 8:33 AM, Andrew Svetlov <andrew.svetlov at gmail.com
>> <mailto:andrew.svetlov at gmail.**com <andrew.svetlov at gmail.com>>> wrote:
>>
>>     Looks like bug for me.
>>
>>
>> ctypes seems to auto-convert arguments when argtypes is specified. This
>> fact is documented. However, I'm not sure whether this auto-conversion
>> is advanced enough to apply byref. Because otherwise, DIRENT is
>> certainly not convertible to DIRENT_p
>>
>
> If argtypes specify a 'POINTER(X)' type as an argument, then ctypes
> automatically applies byref() if an 'X' instance is passed to the
> actual call.  This is by design, but I'm not sure if it is documented
> or not.
>
> However, if argtypes is not given, this does (and of course cannot) work.
>

Great, thanks for confirming this, Thomas. I had the feeling it's a
documentation issue (hence I sent it to the docs@ list first), because the
behavior seems very deliberate and looking at the code of ctypes I did see
conversions going on.

Have I missed that this is documented somewhere, or should I open a docs
issue?

Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130307/826417ea/attachment.html>

From report at bugs.python.org  Thu Mar  7 14:33:08 2013
From: report at bugs.python.org (karl)
Date: Thu, 07 Mar 2013 13:33:08 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1362663188.35.0.712733272295.issue17375@psf.upfronthosting.co.za>


karl added the comment:

Here an attempt at fixing it. See issue-17375-1.patch for Python 3.3

Hope it helps.

----------
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file29338/issue-17375-1.patch

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

From report at bugs.python.org  Thu Mar  7 14:42:05 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 07 Mar 2013 13:42:05 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1362663725.61.0.543377871029.issue17375@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Duplicate of #12768?

karl - feel free to review the patch submitted to that issue and offer your insights.

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

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

From report at bugs.python.org  Thu Mar  7 14:45:14 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Mar 2013 13:45:14 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <3ZMClF6KsZz7Lth@mail.python.org>


Roundup Robot added the comment:

New changeset adeafab9a18f by Nick Coghlan in branch '3.3':
Close #15465: Document C API version macros
http://hg.python.org/cpython/rev/adeafab9a18f

New changeset a1373861f62f by Nick Coghlan in branch 'default':
Merge fix for #15465 from 3.3
http://hg.python.org/cpython/rev/a1373861f62f

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Mar  7 14:46:58 2013
From: report at bugs.python.org (karl)
Date: Thu, 07 Mar 2013 13:46:58 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1362664018.77.0.871432045513.issue17375@psf.upfronthosting.co.za>


karl added the comment:

Ah bummer! :) it was already done. :) Well it seems already well commented in the review. :)

Closing this one as duplicate?

----------

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

From report at bugs.python.org  Thu Mar  7 14:58:47 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 07 Mar 2013 13:58:47 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
Message-ID: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>


New submission from Eli Bendersky:

While playing with ctypes a bit, I noticed a feature that doesn't appear to be documented. Suppose I import the readdir_r function (assuming DIRENT is a correctly declared ctypes.Structure):

DIR_p = c_void_p
DIRENT_p = POINTER(DIRENT)
DIRENT_pp = POINTER(DIRENT_p)

readdir_r = lib.readdir_r
readdir_r.argtypes = [DIR_p, DIRENT_p, DIRENT_pp]
readdir_r.restype = c_int

It seems that I can then call it as follows:

dirent = DIRENT()
result = DIRENT_p()

readdir_r(dir_fd, dirent, result)

Note that while readdir_r takes DIRENT_p and DIRENT_pp as its second and third args, I pass in just DIRENT and DIRENT_p, accordingly. What I should have done is use byref() on both, but ctypes seems to have some magic applied when argtypes declares pointer types. If I use byref, it still works. However, if I keep the same call and comment out the argtypes declaration, I get a segfault.

This behavior of ctypes should be documented.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 183661
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that ctypes automatically applies byref() when argtypes declares POINTER
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 15:09:12 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 07 Mar 2013 14:09:12 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
In-Reply-To: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>
Message-ID: <1362665352.31.0.333291515331.issue17378@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Doc patch for 3.2

----------
keywords: +patch
Added file: http://bugs.python.org/file29340/issue17378.1.patch

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

From report at bugs.python.org  Thu Mar  7 15:09:38 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 07 Mar 2013 14:09:38 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
In-Reply-To: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>
Message-ID: <1362665378.99.0.349268776344.issue17378@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, theller

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

From report at bugs.python.org  Thu Mar  7 15:52:32 2013
From: report at bugs.python.org (karl)
Date: Thu, 07 Mar 2013 14:52:32 +0000
Subject: [docs] [issue17376] TimedRotatingFileHandler documentation
	regarding 'Week	day' lacking
In-Reply-To: <1362656177.01.0.275089317243.issue17376@psf.upfronthosting.co.za>
Message-ID: <1362667952.75.0.688431506946.issue17376@psf.upfronthosting.co.za>


karl added the comment:

Is it better like this? See the patch.

----------
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file29341/issue-17376-doc-3.3.patch

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

From report at bugs.python.org  Thu Mar  7 16:06:57 2013
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 07 Mar 2013 15:06:57 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
In-Reply-To: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>
Message-ID: <1362668816.94.0.891641608339.issue17378@psf.upfronthosting.co.za>


Thomas Heller added the comment:

Patch looks good.  Please apply.

----------

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

From report at bugs.python.org  Thu Mar  7 17:28:04 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 07 Mar 2013 16:28:04 +0000
Subject: [docs] [issue8402] Add a function to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1362673683.99.0.978398232974.issue8402@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

I've attached fnmatch_implementation.py, which is a simple pure-Python implementation of the fnmatch function.

It's not as susceptible to catastrophic backtracking as the current re-based one. For example:

fnmatch('a' * 50, '*a*' * 50)

completes quickly.

----------
nosy: +mrabarnett
Added file: http://bugs.python.org/file29343/fnmatch_implementation.py

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

From report at bugs.python.org  Thu Mar  7 17:32:53 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2013 16:32:53 +0000
Subject: [docs] [issue8402] Add a function to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1362673973.81.0.808992724314.issue8402@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it should be a separate issue.

----------

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

From report at bugs.python.org  Thu Mar  7 18:12:17 2013
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Thu, 07 Mar 2013 17:12:17 +0000
Subject: [docs] [issue17380] initproc return value is unclear
Message-ID: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

initproc is declared to return an int, but what returned values mean is not documented. Noddy_init in http://docs.python.org/3/extending/newtypes.html?highlight=initproc#adding-data-and-methods-to-the-basic-example can be seen to return 0 on success and -1 on error, but that's about it.

Also, when I wrote a function which return 1 on error, on every second invocation the exception would be ignored:
static int Reader_init(Reader *self, PyObject *args, PyObject *keywds)
{
    ...
    if (flags && path) {
            PyErr_SetString(PyExc_ValueError, "cannot use both flags and path");
            return 1;
    }
    ...
}

>>> obj(123, '/tmp')
>>> obj(123, '/tmp')
...
ValueError
>>> obj(123, '/tmp')
>>> obj(123, '/tmp')
...
ValueError

I'm not sure how to interpret this since I couldn't find the documentation for the expected value.

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 183689
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: initproc return value is unclear
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar  7 22:54:09 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Mar 2013 21:54:09 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1362693249.15.0.99948841828.issue10224@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Doc/make.bat assumes that this issue has already been resolved:
  if "%PYTHON%" EQU "" set PYTHON=..\pcbuild\python
Even with '_d' appended, as it should be, that does not work for 3.x.
I think that line should be @rem'ed out until it does work.
Does anyone mind if I do so?

I already suggested on #15605 that a workaround be given until it is no longer needed.

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

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

From report at bugs.python.org  Thu Mar  7 23:39:56 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Thu, 07 Mar 2013 22:39:56 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1362695996.48.0.00877117980119.issue10224@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  8 00:55:00 2013
From: report at bugs.python.org (Piotr Kuchta)
Date: Thu, 07 Mar 2013 23:55:00 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
Message-ID: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>


New submission from Piotr Kuchta:

In the 2.7 tutorial, chapter on modules:

 http://docs.python.org/2/tutorial/modules.html#more-on-modules 

I think the last sentence in this paragraph is incorrect:

"Modules can import other modules. It is customary but not required to place all import statements at the beginning of a module (or script, for that matter). The imported module names are placed in the importing module?s global symbol table."

This is not true:

>>> def foo(): import sys
... 
>>> foo()
>>> sys.path
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'sys' is not defined

----------
assignee: docs at python
components: Documentation
messages: 183715
nosy: Piotr.Kuchta, docs at python
priority: normal
severity: normal
status: open
title: Error in documentation /2/tutorial/modules.html#more-on-modules
versions: Python 2.7

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

From report at bugs.python.org  Fri Mar  8 00:58:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Mar 2013 23:58:54 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362700734.18.0.090553479433.issue17383@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It should probably say that they are placed in the namespace where they get imported, but I'm not sure if the concept of namespace has been covered yet at that point of the tutorial.  The sentence probably assume that the modules are getting imported at the beginning of the module (as suggested in the previous sentence), but even in that case I wouldn't use 'global symbol table'.

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

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

From report at bugs.python.org  Fri Mar  8 01:20:24 2013
From: report at bugs.python.org (Ashwini Chaudhary)
Date: Fri, 08 Mar 2013 00:20:24 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362702024.52.0.126449825294.issue17383@psf.upfronthosting.co.za>


Changes by Ashwini Chaudhary <monty.sinngh at gmail.com>:


----------
nosy: +montysinngh

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

From report at bugs.python.org  Fri Mar  8 14:33:58 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Mar 2013 13:33:58 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
In-Reply-To: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>
Message-ID: <3ZMqRn2cx9zNvy@mail.python.org>


Roundup Robot added the comment:

New changeset 76be5efa0d86 by Eli Bendersky in branch '3.2':
Issue #17378: ctypes documentation fix.
http://hg.python.org/cpython/rev/76be5efa0d86

New changeset 2cd2d8f8f72f by Eli Bendersky in branch '3.3':
Issue #17378: ctypes documentation fix.
http://hg.python.org/cpython/rev/2cd2d8f8f72f

New changeset 58c07ba40926 by Eli Bendersky in branch 'default':
Issue #17378: ctypes documentation fix.
http://hg.python.org/cpython/rev/58c07ba40926

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

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

From report at bugs.python.org  Fri Mar  8 14:35:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Mar 2013 13:35:50 +0000
Subject: [docs] [issue17378] Document that ctypes automatically applies
	byref() when	argtypes declares POINTER
In-Reply-To: <1362664727.05.0.222866106319.issue17378@psf.upfronthosting.co.za>
Message-ID: <3ZMqTx53fJzMgy@mail.python.org>


Roundup Robot added the comment:

New changeset 2dd77a12e7bf by Eli Bendersky in branch '2.7':
Closing #17378: ctypes documentation fix.
http://hg.python.org/cpython/rev/2dd77a12e7bf

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

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

From report at bugs.python.org  Fri Mar  8 15:30:18 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Mar 2013 14:30:18 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1362753018.25.0.505213428378.issue17380@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

The return value for error conditions should be -1.

- typeobject.c checks with "< 0"
- in _iomodule.c, there is "== -1"
- and pygobject/gobject/gobjectmodule.c just does::
    if (...tp_init(...))
        PyErr_Print();

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

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

From report at bugs.python.org  Fri Mar  8 15:44:33 2013
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Fri, 08 Mar 2013 14:44:33 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362753018.25.0.505213428378.issue17380@psf.upfronthosting.co.za>
Message-ID: <20130308144432.GH4278@in.waw.pl>


Zbyszek J?drzejewski-Szmek added the comment:

On Fri, Mar 08, 2013 at 02:30:18PM +0000, Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc added the comment:
> 
> The return value for error conditions should be -1.
> 
> - typeobject.c checks with "< 0"
> - in _iomodule.c, there is "== -1"
> - and pygobject/gobject/gobjectmodule.c just does::
>     if (...tp_init(...))
>         PyErr_Print();
That's not very nice. Would it make sense to unify those
checks, e.g. for "initproc() < 0"? Than the documentation
could be updated.

Zbyszek

----------

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

From report at bugs.python.org  Fri Mar  8 15:58:11 2013
From: report at bugs.python.org (karl)
Date: Fri, 08 Mar 2013 14:58:11 +0000
Subject: [docs] [issue17376] TimedRotatingFileHandler documentation
	regarding 'Week	day' lacking
In-Reply-To: <1362656177.01.0.275089317243.issue17376@psf.upfronthosting.co.za>
Message-ID: <1362754691.12.0.949094024423.issue17376@psf.upfronthosting.co.za>


Changes by karl <karl+pythonbugs at la-grange.net>:


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

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

From report at bugs.python.org  Fri Mar  8 16:06:03 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Fri, 08 Mar 2013 15:06:03 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362755163.67.0.347657234464.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Brought the ElementTree docs for find(), findtext() and findall() in line with the default branch (now they are just referencing the methods from Element).

Made the same changes in the method comments of the implementation.

Separate patches for 2.7 and 3.2.

Note that the implementation method comments in default (and I assume 3.3) are still wrong. Would you accept patches for that as well?

----------
Added file: http://bugs.python.org/file29349/issue11367_branch27.txt

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

From report at bugs.python.org  Fri Mar  8 16:07:36 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Fri, 08 Mar 2013 15:07:36 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362755256.7.0.264571719698.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Patch for 3.2.

----------
Added file: http://bugs.python.org/file29350/issue11367_branch32.patch

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

From report at bugs.python.org  Fri Mar  8 16:12:31 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Mar 2013 15:12:31 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362755551.0.0.215957852725.issue17383@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Text sounds correct to me.  It says that imports should happen at the beginning of a module, and that the names of imported modules are placed in the module namespace.  There is an implicit logical link between the two sentences, and the wording of ?symbol table? may be not great at this stage of the tuto, but I don?t see that the text can be interpreted to mean that imports in a function will change the global namespace.  Of course, *I* don?t see it because I?m not the target audience of the tutorial; if you know that import creates an assignment and that assignments have scopes, it?s logical that importing in a function does not create a global name, but beginners reading the tutorial may not know these things yet.  So we could add an example of a module importing and using another module.  If there is a part of the tuto where imports in functions are mentioned (and discouraged), then an example or comment there could also clarify that the imported module name is only local to the function.

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

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

From report at bugs.python.org  Fri Mar  8 17:02:29 2013
From: report at bugs.python.org (Jeff Knupp)
Date: Fri, 08 Mar 2013 16:02:29 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362758549.43.0.924067107884.issue17383@psf.upfronthosting.co.za>


Jeff Knupp added the comment:

I think Piotr's point is the wording of the last sentence is ambiguous. The second statement reads "It is customary *but not required* to place all import statements at the beginning of a module...". The third seems to state that regardless of whether or not you followed the custom, module names are always placed in the global symbol table.

I think the last two sentences need to be rewritten to remove ambiguity. If, at this point, we only want to explain that importing a module makes that modules names available then that's what the documentation should say (even more so if the term "symbol table" hasn't been introduced yet, which would effectively render the entire block useless).

----------
nosy: +jeffknupp

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

From report at bugs.python.org  Fri Mar  8 17:26:51 2013
From: report at bugs.python.org (Piotr Kuchta)
Date: Fri, 08 Mar 2013 16:26:51 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362760010.95.0.369287575815.issue17383@psf.upfronthosting.co.za>


Piotr Kuchta added the comment:

Jeff, thank you: that was exactly what I wanted to point out. The three sentences read in order imply that it doesn't matter whether you import a module at the top level of a script/module or in a function, because the effect is the same, namely the imported symbols end up in the global symbol table, and that obviously is not true.

----------

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

From report at bugs.python.org  Fri Mar  8 17:29:20 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Mar 2013 16:29:20 +0000
Subject: [docs] [issue17383] Error in
	documentation	/2/tutorial/modules.html#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362760160.44.0.425280325386.issue17383@psf.upfronthosting.co.za>


?ric Araujo added the comment:

> It is customary *but not required* to place all import statements at the
> beginning of a module...". The third seems to state that regardless of
> whether or not you followed the custom, module names are always placed in
> the global symbol table

Yes. Not following the usage means placing imports in the middle of the module for example, but it does not imply imports in functions.

----------

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

From report at bugs.python.org  Fri Mar  8 17:32:49 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Mar 2013 16:32:49 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing
	in	tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362760369.75.0.501326153581.issue17383@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Ah, we have it: the tutorial distinguishes between ?it?s customary to put imports near the top of the file? vs. ?later in the file?, and you interpret it as ?it?s customary to put imports at the module top level? vs. ?import in any scope e.g. functions?.  These are actually two different things, covered in different part of the docs: importing at module scope is very much recommended, as imports in functions can lead to nasty side-effects; and then there?s the style issue of putting imports at the beginning of the file, which is what the section we discuss is about.

----------
title: Error in documentation /2/tutorial/modules.html#more-on-modules -> Possibly ambiguous phrasing in tutorial/modules#more-on-modules

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

From report at bugs.python.org  Fri Mar  8 17:45:51 2013
From: report at bugs.python.org (Jeff Knupp)
Date: Fri, 08 Mar 2013 16:45:51 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing
	in	tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362761151.06.0.756040186108.issue17383@psf.upfronthosting.co.za>


Jeff Knupp added the comment:

Of the "two different things", the first (the scope of imported names) is never covered in the documentation. As a result, the text in question seems to imply an import statement can *only* be in module scope. 

>From the reader's perspective: "If I wanted to import something in a class or function it obviously can't be at the top of the file, so I guess I can't do that." The tutorial doesn't disabuse them of this notion.

----------

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

From report at bugs.python.org  Fri Mar  8 17:56:33 2013
From: report at bugs.python.org (Piotr Kuchta)
Date: Fri, 08 Mar 2013 16:56:33 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing
	in	tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1362761793.14.0.357178539039.issue17383@psf.upfronthosting.co.za>


Piotr Kuchta added the comment:

Eric, when you say 'the tutorial distinguishes between ?it?s customary to put imports near the top of the file? vs. ?later in the file?' the last bit is just your interpretation. The tutorial doesn't say "later in the file". Anyway, 'later in the file' does not mean 'later in the file at the top level'.

For me an opposite to "top of the file" is "anywhere else in the file, including functions' and class' definitions later in the file".

Clearly, there is an ambiguity here. And I can tell you that people do get confused by that part of documentation. I know it from discussions with my colleagues at work. Also, I asked a question on StackOverflow, where I quoted the tutorial and gave that example of importing in a function body: http://stackoverflow.com/q/15283821/300886
You can see in the comments that people were surprised seeing the NameError! For me it is clear that this part of the tutorial should be improved.

----------

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

From actonwiley at gmail.com  Fri Mar  8 18:24:35 2013
From: actonwiley at gmail.com (actonwiley at gmail.com)
Date: Fri, 08 Mar 2013 17:24:35 -0000
Subject: [docs] xml.etree.ElementTree.find(all): docs are wrong (issue 11367)
Message-ID: <20130308172435.12067.2597@psf.upfronthosting.co.za>

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

From actonwiley at gmail.com  Fri Mar  8 18:25:02 2013
From: actonwiley at gmail.com (actonwiley at gmail.com)
Date: Fri, 08 Mar 2013 17:25:02 -0000
Subject: [docs] xml.etree.ElementTree.find(all): docs are wrong (issue
	11367)
Message-ID: <20130308172502.12067.98344@psf.upfronthosting.co.za>

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

From actonwiley at gmail.com  Fri Mar  8 19:00:51 2013
From: actonwiley at gmail.com (actonwiley at gmail.com)
Date: Fri, 08 Mar 2013 18:00:51 -0000
Subject: [docs] xml.etree.ElementTree.find(all): docs are wrong (issue
	11367)
Message-ID: <20130308180051.7719.82097@psf.upfronthosting.co.za>

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

From report at bugs.python.org  Fri Mar  8 23:33:15 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 08 Mar 2013 22:33:15 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
Message-ID: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>


New submission from Zachary Ware:

I have found Doc/make.bat to be very useful, but I have hit a few of its limitations now and then.  Thus, I have made extensive modifications to bring it much closer to the way Doc/Makefile works.  Among the things changed in the attached patch:

- Use pushd/popd to make sure everything is done in the Doc directory.

- Allow variables to be set on the command line, e.g.:
       make html "PYTHON2=python"

- Set PYTHON2 and PYTHON3 variables separately; the Sphinx version and associated tools we're currently using want Python 2, which defaults to "py -2".  Other tools, like Tools/scripts/serve.py (the make serve target), expect Python 3; setting the default PYTHON3 searches for python(_d).exe in PCbuild(\amd64), and falls back to "py -3" if not found.

- Set the HTML Help Workshop default path to %ProgramFiles(x86)%\..., if that variable is defined. (If I understand correctly, that variable is only defined on x64 installations, and in cases where it is not defined on x64, %ProgramFiles% silently copies %ProgramFiles(x86)%.)

- Convert target choice to a single for loop, rather than several lines of if.  Anything not in the list falls through to the help message.

- Expand the help message to match the message given by Doc/Makefile

- Add the "clean" target, which does the same as Makefile

- Reimplement "update" to match Makefile (call clean, call checkout.  I do wonder if maybe it should be done the other way around, though; reimplement Makfile's "update" target to simply update the svn checkouts, rather than re-pull them)

- Add separate labels for each target.  The old method of sending everything to :build was very clever and kept the file short, but limited flexibility.  It's also nice to get a message at the end (matching Makefile), which is much easier to do with separate labels.

- Add support for the PAPER environment variable in LaTeX building.

- Add coverage, doctest, pydoc-topics, dist, check, and serve targets.  "dist" cannot be completed in the same way with default tools on Windows, so all it does is build html, text, latex (a4 and letter), and epub and copy them into the dist directory.

- checkout checks for the existence of the checked out packages before checking out

- build calls checkout before building, so you can go right to "make html" instead of having to do "make checkout && make html"

- Add support for SOURCES and SPHINXOPTS environment variables.

Everything seems to work for me, but I've only been able to test on Windows 7 (32 and 64 bit).  I don't believe there's anything in there that doesn't exist in XP, though.  Also, since this version of the file has a lot of labels, this patch does somewhat rely on resolution of issue 17202.  It should probably work without any changes to .hgeol, but that can't be guaranteed.

There are a couple of drawbacks to the patched version; it's a much longer file, and it does lose a good chunk of the elegance of the original solution.  If anyone has any suggestions for regaining some of that elegance without losing any of the functionality, I am of course all ears :). In particular, I'm not a huge fan of having to have "pushd ." at the beginning of every label, but the only other solutions I came up with involved setting and unsetting a "DISALLOW_POPD" variable in several places, and a condition on the popd at :end, or forgetting the pushd/popd thing entirely.

I'm looking forward to hearing what anyone else thinks of this, positive or negative :)

----------
assignee: docs at python
components: Build, Documentation, Windows
files: win_doc_make.diff
keywords: patch
messages: 183768
nosy: christian.heimes, docs at python, zach.ware
priority: normal
severity: normal
status: open
title: Bring Doc/make.bat as close to Doc/Makefile as possible
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29353/win_doc_make.diff

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

From report at bugs.python.org  Fri Mar  8 23:55:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2013 22:55:33 +0000
Subject: [docs] [issue11029] Crash, 2.7.1,
	Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1362783333.0.0.648671265815.issue11029@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have somewhat arbitrary selected #16823 as the issue turned into a tkinter and threads doc issue. I added a note there about mentioning the use of queue.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python quits on running tkinter code with threads

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

From report at bugs.python.org  Sat Mar  9 00:01:40 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2013 23:01:40 +0000
Subject: [docs] [issue16823] Python quits on running tkinter code with
	threads
In-Reply-To: <1356924189.65.0.303016065786.issue16823@psf.upfronthosting.co.za>
Message-ID: <1362783700.05.0.919620880368.issue16823@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From #11029: Doc about tkinter and treads should also give the alternative of using queue.queue to feed data from multiple threads.
See msg127316

----------

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

From report at bugs.python.org  Sat Mar  9 00:27:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Mar 2013 23:27:41 +0000
Subject: [docs] [issue17376] TimedRotatingFileHandler documentation
	regarding 'Week	day' lacking
In-Reply-To: <1362656177.01.0.275089317243.issue17376@psf.upfronthosting.co.za>
Message-ID: <3ZN4cn6mJczPCP@mail.python.org>


Roundup Robot added the comment:

New changeset 56b74b9c81c3 by Vinay Sajip in branch '2.7':
Issue #17376: Clarified documentation for TimedRotatingFileHandler weekday rotation.
http://hg.python.org/cpython/rev/56b74b9c81c3

New changeset 83f07e3a53f4 by Vinay Sajip in branch '3.2':
Issue #17376: Clarified documentation for TimedRotatingFileHandler weekday rotation.
http://hg.python.org/cpython/rev/83f07e3a53f4

New changeset 12239c13db72 by Vinay Sajip in branch '3.3':
Issue #17376: Merged clarification from 3.2.
http://hg.python.org/cpython/rev/12239c13db72

New changeset a8047d1376d5 by Vinay Sajip in branch 'default':
Closes #17376: Merged clarification from 3.3.
http://hg.python.org/cpython/rev/a8047d1376d5

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Mar  9 01:25:16 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 00:25:16 +0000
Subject: [docs] [issue17332] typo in json docs - "convered" should be
	"converted"
In-Reply-To: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>
Message-ID: <1362788716.56.0.626102084924.issue17332@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar  9 01:40:59 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 00:40:59 +0000
Subject: [docs] [issue17332] typo in json docs - "convered" should be
	"converted"
In-Reply-To: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>
Message-ID: <3ZN6FQ5XsFzQ4b@mail.python.org>


Roundup Robot added the comment:

New changeset 9bd2fc35f311 by Terry Jan Reedy in branch '2.7':
Issue #17332: fix json doc typo /convered/converted/ found by Ernie Hershey.
http://hg.python.org/cpython/rev/9bd2fc35f311

New changeset 55fd9810c9ab by Terry Jan Reedy in branch '3.2':
Issue #17332: fix json doc typo /convered/converted/ found by Ernie Hershey.
http://hg.python.org/cpython/rev/55fd9810c9ab

New changeset 8817a09e012c by Terry Jan Reedy in branch '3.3':
Issue #17332: fix json doc typo /convered/converted/ found by Ernie Hershey.
http://hg.python.org/cpython/rev/8817a09e012c

New changeset d86f5686cef9 by Terry Jan Reedy in branch 'default':
Issue #17332: fix json doc typo /convered/converted/ found by Ernie Hershey.
http://hg.python.org/cpython/rev/d86f5686cef9

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

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

From report at bugs.python.org  Sat Mar  9 01:42:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 00:42:10 +0000
Subject: [docs] [issue17332] typo in json docs - "convered" should be
	"converted"
In-Reply-To: <1362173463.23.0.943587603223.issue17332@psf.upfronthosting.co.za>
Message-ID: <1362789730.56.0.752685607217.issue17332@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for the report.

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

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

From report at bugs.python.org  Sat Mar  9 01:58:30 2013
From: report at bugs.python.org (Alex Orange)
Date: Sat, 09 Mar 2013 00:58:30 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
Message-ID: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>


New submission from Alex Orange:

The documentation at http://docs.python.org/2/c-api/typeobj.html#PySequenceMethods is missing sq_slice between sq_item and sq_ass_item. This will mess up anyone trying to use anything after sq_item (that isn't using designated initializers).

----------
assignee: docs at python
components: Documentation
messages: 183779
nosy: Alex.Orange, docs at python
priority: normal
severity: normal
status: open
title: Error in C API documentation of PySequenceMethods
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar  9 04:24:38 2013
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 09 Mar 2013 03:24:38 +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: <1362799478.67.0.857029593784.issue12067@psf.upfronthosting.co.za>


Mike Hoy added the comment:

Considering that the docs have changed does this issue still need to be open?

----------

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

From report at bugs.python.org  Sat Mar  9 04:30:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 03:30:42 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362799842.23.0.594758587101.issue17370@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think you are, in effect, asking for expansion of the 'PEP Header Preamble' section of PEP-0001. I have added some of the PEP editors listed in the PEP as nosy. I will let them decide if this should be discussed elsewhere.

----------
nosy: +barry, brett.cannon, georg.brandl, terry.reedy

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

From report at bugs.python.org  Sat Mar  9 04:35:55 2013
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 09 Mar 2013 03:35:55 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362800155.45.0.636128829003.issue17387@psf.upfronthosting.co.za>


Changes by Mike Hoy <mhoy09 at gmail.com>:


----------
nosy: +mikehoy

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

From report at bugs.python.org  Sat Mar  9 05:02:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 04:02:37 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <3ZNBk43pz0zPyP@mail.python.org>


Roundup Robot added the comment:

New changeset e0ef2bde35c3 by Raymond Hettinger in branch '2.7':
Issue #17375:  Add docstrings to the threading module.
http://hg.python.org/cpython/rev/e0ef2bde35c3

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

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

From report at bugs.python.org  Sat Mar  9 05:21:42 2013
From: report at bugs.python.org (Mike Hoy)
Date: Sat, 09 Mar 2013 04:21:42 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362802902.43.0.00708806222253.issue17387@psf.upfronthosting.co.za>


Mike Hoy added the comment:

Looking through Include/object.h I see that sq_slice is now:

void *was_sq_slice. Can anyone provide any clarification as to where I can find info about sq_slice?

----------

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

From report at bugs.python.org  Sat Mar  9 05:43:56 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 04:43:56 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362804236.21.0.915735336038.issue17351@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The respective howto and examples authors should give their OK for deleting '(object)' in case they are trying to keep one text compatible across 2 and 3. I added the other two to the nosy list.

Doc/howto/descriptor.rst -- Raymond H.
Doc/howto/sorting.rst -- Raymond H.
Doc/howto/logging-cookbook.rst -- Vinay S.
Doc/library/unittest.mock-examples.rst -- Michael F.

Since raise AttributeError(message) works in 2.x, I think that should definitely be changed in descriptor.rst.

I also think the regular docs can be changed without further ado.
Doc/library/contextlib.rst
Doc/library/functions.rst

Phil, your name does not have a Contributor Agreement *. If it should, say so and lets figure out why not. Otherwise, please fill out one at
http://www.python.org/psf/contrib/
Choose paper mail, paper scan and email, or javascript e-form.

----------
nosy: +michael.foord, terry.reedy, vinay.sajip
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2, Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Sat Mar  9 05:44:21 2013
From: report at bugs.python.org (Alex Orange)
Date: Sat, 09 Mar 2013 04:44:21 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362804261.96.0.624771339601.issue17387@psf.upfronthosting.co.za>


Alex Orange added the comment:

If you look at the 2.7.3 version of that file: http://hg.python.org/cpython/file/70274d53c1dd/Include/object.h it has more information. It is a ssizessizeargfunc. I assume it passes the lower and upper bound and expects back a subsequence.

----------

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

From report at bugs.python.org  Sat Mar  9 05:45:01 2013
From: report at bugs.python.org (Alex Orange)
Date: Sat, 09 Mar 2013 04:45:01 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362804301.49.0.566822945752.issue17387@psf.upfronthosting.co.za>


Alex Orange added the comment:

Just to clarify though, that is entirely an assumption as to how it's supposed to be used.

----------

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

From report at bugs.python.org  Sat Mar  9 08:26:48 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 07:26:48 +0000
Subject: [docs] [issue16642] Mention new "kwargs" named tuple parameter in
	sched	module
In-Reply-To: <1354963970.59.0.876106484214.issue16642@psf.upfronthosting.co.za>
Message-ID: <3ZNHFg25gzzPVh@mail.python.org>


Roundup Robot added the comment:

New changeset 258028711466 by Terry Jan Reedy in branch '3.3':
Issue #16642: sched.scheduler timefunc initial default is time.monotonic.
http://hg.python.org/cpython/rev/258028711466

----------

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

From report at bugs.python.org  Sat Mar  9 08:26:50 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 07:26:50 +0000
Subject: [docs] [issue16643] Wrong documented default value for timefunc
	parameter in	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <3ZNHFh0nVTzPB8@mail.python.org>


Roundup Robot added the comment:

New changeset ca56baa46d35 by Terry Jan Reedy in branch 'default':
Merge: closes issue 16643 (not ....2 as in last commit message)
http://hg.python.org/cpython/rev/ca56baa46d35

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Mar  9 08:28:41 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 07:28:41 +0000
Subject: [docs] [issue16643] Wrong documented default value for timefunc
	parameter in	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <1362814121.11.0.422270407227.issue16643@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

3.3 was changed also, but with misdirected message

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

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

From report at bugs.python.org  Sat Mar  9 08:29:11 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 07:29:11 +0000
Subject: [docs] [issue16642] Mention new "kwargs" named tuple parameter in
	sched	module
In-Reply-To: <1354963970.59.0.876106484214.issue16642@psf.upfronthosting.co.za>
Message-ID: <1362814151.13.0.968799620365.issue16642@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar  9 08:34:15 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Mar 2013 07:34:15 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362814455.64.0.913044871135.issue17351@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'm OK with changing the logging cookbook to remove explicit subclassing from "object" in the examples.

----------

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

From report at bugs.python.org  Sat Mar  9 08:43:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 07:43:02 +0000
Subject: [docs] [issue16643] Wrong documented default value for timefunc
	parameter in	sched.scheduler()
In-Reply-To: <1354964381.71.0.639628706124.issue16643@psf.upfronthosting.co.za>
Message-ID: <1362814982.91.0.981244221028.issue16643@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I guess I should have taken the assignment before pushing ;-)

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

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

From report at bugs.python.org  Sat Mar  9 08:57:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 07:57:24 +0000
Subject: [docs] [issue9842] Document ... used in recursive repr of containers
In-Reply-To: <1284336324.93.0.400210409006.issue9842@psf.upfronthosting.co.za>
Message-ID: <1362815844.59.0.950790834173.issue9842@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.3, Python 3.4 -Python 3.1

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

From report at bugs.python.org  Sat Mar  9 14:23:25 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Mar 2013 13:23:25 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1362835405.73.0.852337852786.issue17375@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Raymond - which patch is it? You didn't specify the contributor in the commit. What about the duplicate issue #12768 where someone also worked to supply a patch? 

Also, you've only committed this to 2.7; why?

----------

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

From report at bugs.python.org  Sat Mar  9 14:56:20 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 13:56:20 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <3ZNRv73VM3zQMK@mail.python.org>


Roundup Robot added the comment:

New changeset 0acd9408b6f1 by Eli Bendersky in branch '3.2':
Add warning in ctypes documentation for #16575 and #16576
http://hg.python.org/cpython/rev/0acd9408b6f1

New changeset bfc159f8e4b4 by Eli Bendersky in branch '3.3':
Add warning in ctypes documentation for #16575 and #16576
http://hg.python.org/cpython/rev/bfc159f8e4b4

New changeset 502624235c7b by Eli Bendersky in branch 'default':
Add warning in ctypes documentation for #16575 and #16576
http://hg.python.org/cpython/rev/502624235c7b

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

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

From report at bugs.python.org  Sat Mar  9 14:57:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 13:57:30 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <3ZNRwT4QfpzQP9@mail.python.org>


Roundup Robot added the comment:

New changeset eece32440a52 by Eli Bendersky in branch '2.7':
Add warning in ctypes documentation for #16575 and #16576
http://hg.python.org/cpython/rev/eece32440a52

----------

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

From report at bugs.python.org  Sat Mar  9 15:12:35 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Mar 2013 14:12:35 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362838355.07.0.531022381041.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Henrik, this patch fails to apply to 3.2

applying issue11367_branch32.patch
patching file Doc/library/xml.etree.elementtree.rst
Hunk #1 FAILED at 411
1 out of 1 hunks FAILED -- saving rejects to file Doc/library/xml.etree.elementtree.rst.rej
patching file Lib/xml/etree/ElementTree.py
Hunk #1 FAILED at 704
Hunk #2 FAILED at 725
Hunk #3 FAILED at 750
3 out of 3 hunks FAILED -- saving rejects to file Lib/xml/etree/ElementTree.py.rej
abort: patch failed to apply


I suspect this may be because of line endings. Are you generating the patches on a Windows machine? All patches to Python should be strictly in Unix format (LF for line ending, not CR LF). Can you configure your hg client and / or editor to do this?

I haven't touched Windows for some time but IIRC TortoiseHg does the right thing if your file is proper. In other words, perhaps it's the editor's fault. Your editor should not insert Windows line-endings into a Unix-y file (which Doc/library/xml.etree.elementtree.rst is).

----------

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

From report at bugs.python.org  Sat Mar  9 15:16:50 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Mar 2013 14:16:50 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1362838610.03.0.197713531543.issue17359@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Marc-Andre,  Can this issue be closed or are the docs lacking in some way?

----------

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

From report at bugs.python.org  Sat Mar  9 16:13:10 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Mar 2013 15:13:10 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1362841990.85.0.914962892385.issue16954@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks David, the patch looks good. I will commit it with some slight modifications and touch-ups shortly.

The issue of C extension docstrings vs. Python docstrings is an interesting one. It's a shame that help() shows empty strings, and it's a shame to copy-paste. What do other modules do? It may also be worth asking in python-dev or the docs mailing list and hear suggestions from other developers.

----------

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

From report at bugs.python.org  Sat Mar  9 16:13:43 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2013 15:13:43 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <3ZNTcR1T5yzP1G@mail.python.org>


Roundup Robot added the comment:

New changeset f27d7c1eac4d by Eli Bendersky in branch 'default':
Issue #16954: Add docstrings for ElementTree
http://hg.python.org/cpython/rev/f27d7c1eac4d

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

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

From report at bugs.python.org  Sat Mar  9 17:00:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 09 Mar 2013 16:00:28 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362844828.1.0.599911888572.issue11367@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

You can use patch.py utility from http://python-patch.googlecode.com/svn-history/trunk/patch.py to apply patch that doesn't have this CRLF problem.

----------

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

From report at bugs.python.org  Sat Mar  9 17:32:21 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 09 Mar 2013 16:32:21 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362799842.23.0.594758587101.issue17370@psf.upfronthosting.co.za>
Message-ID: <20130309113222.04961c45@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Mar 09, 2013, at 03:30 AM, Terry J. Reedy wrote:

>I think you are, in effect, asking for expansion of the 'PEP Header Preamble'
>section of PEP-0001. I have added some of the PEP editors listed in the PEP
>as nosy. I will let them decide if this should be discussed elsewhere.

Looks like Benjamin just changed Replaced-By with Superseded-By in PEP 1 and
Replaced with Superseded as a Status.  He also updated a bunch of PEPs with
the new headers, including 333.

He probably should have discussed this with the other PEP editors beforehand,
but in retrospect, it seems fine.

I guess that means you're requesting a new header such as 'Related' which
would contain a list of PEP numbers?  Usually we just put those in the
references (and it's perfectly fine to update a PEP after it's final with new
references - that's why we have a version control system. :)

----------

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

From report at bugs.python.org  Sat Mar  9 20:06:02 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 09 Mar 2013 19:06:02 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1362855962.22.0.00798596310814.issue10224@psf.upfronthosting.co.za>


Zachary Ware added the comment:

> Doc/make.bat assumes that this issue has already been resolved:
>   if "%PYTHON%" EQU "" set PYTHON=..\pcbuild\python
> Even with '_d' appended, as it should be, that does not work for 3.x.
> I think that line should be @rem'ed out until it does work.
> Does anyone mind if I do so?

I have offered an alternative fix for that issue as a part of issue17386.

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

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

From report at bugs.python.org  Sat Mar  9 20:26:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 19:26:21 +0000
Subject: [docs] [issue17370] PEP should note if it has been superseded
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362857181.39.0.0112266585906.issue17370@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think an optional section header, "Related PEPs", to go either at the top or bottom (the two places of most prominence) whould be better than a header with a list of numbers. A section could have a sentence or two for each listing describing the perceived relation.

----------

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

From report at bugs.python.org  Sat Mar  9 20:27:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 09 Mar 2013 19:27:39 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1362857259.24.0.122960651363.issue17386@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar  9 20:29:32 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 19:29:32 +0000
Subject: [docs] [issue17370] PEP should note related PEPs
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362857372.59.0.273672472559.issue17370@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Re-reading the original post, I see that a section (or paragraph) was an option Brandon requested. Changed title to reflect remaining issue.

----------
title: PEP should note if it has been superseded -> PEP should note related PEPs

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

From report at bugs.python.org  Sat Mar  9 21:16:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2013 20:16:12 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1362860172.19.0.743169238961.issue17386@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+1 I would worry more about performance than elegance.

While this is debated, can you provide a mini-patch for at least 3.3+ that corrects the bug of trying to run sphinx with python 3, so that anything but 'make checkout' fails? I would apply that immediately.

----------
nosy: +brian.curtin, terry.reedy, tim.golden

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

From report at bugs.python.org  Sat Mar  9 21:36:12 2013
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 09 Mar 2013 20:36:12 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1362861372.54.0.92373198335.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Sure can.  This one should do it, at least for anyone with 3.3 installed.

----------
Added file: http://bugs.python.org/file29358/win_doc_make_minipatch.diff

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

From report at bugs.python.org  Sat Mar  9 22:54:22 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Mar 2013 21:54:22 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1362866062.81.0.628417510119.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

No, according to the devguide patches for Python have to be created with 'hg diff' and applicable with 'hg patch'. I can fix the patch in a number of ways, but I think it's important for a new contributor to learn how to generate a correct patch that can be applied without extra work. This should help the contributor create more useful patches in the future that get committed quickly.

----------

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

From rovitotv at gmail.com  Sun Mar 10 02:17:18 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Sun, 10 Mar 2013 01:17:18 -0000
Subject: [docs] os.rename documentation slightly inaccurate (issue 16278)
Message-ID: <20130310011718.12067.77967@psf.upfronthosting.co.za>

Ezio,
  Thanks for the review it was excellent.  I got most of them fixed and
will post a new version soon.


http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py
File Lib/test/test_os.py (right):

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode55
Lib/test/test_os.py:55: # Tests creating TESTFN and os.rename
On 2013/03/04 18:15:16, ezio.melotti wrote:
> I think it would be better to make a separate class for os.rename. 
The changes
> to setUp/tearDown are only needed for the new tests, but they are
executed for
> all the old tests too, and that's not necessary.
I agree I only put it in the FileTests class because there was a single
test that already existing in that class.  A new class will make it much
cleaner, good suggestion. Will be implemented in next version.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode62
Lib/test/test_os.py:62: self.rename_src_file = "%s_%d_tmp" %
("test_rename_src_file", \
On 2013/03/04 18:15:16, ezio.melotti wrote:
> All the \ are useless and should be removed (or possibly replaced by
an extra
> set of ()).
I thought those were required but you are right they are not needed so I
removed.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode85
Lib/test/test_os.py:85: if (os.path.exists(self.rename_dst_directory +
"/file.txt")):
On 2013/03/04 18:15:16, ezio.melotti wrote:
> Shouldn't this use os.path.join()?
> Also "/file.txt" is repeated over and over -- it would be better to
use a
> variable instead.
I used os.path.join() and I made a variable all good suggestions. 
Thanks!

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode125
Lib/test/test_os.py:125: os.rmdir(self.rename_src_directory)
On 2013/03/04 18:15:16, ezio.melotti wrote:
> This could be rewritten as:
> files = [support.TESTFN, self.rename_src_file, ...]
> for file in files:
>     if os.path.exists(file):
>         os.unlink(file) 
> 
> for the dirs you can have the same 4 lines with rmdir instead, or
check if they
> are files or dir and use the same loop.
Done.....this is a terrific way to perform the same functions but with
fewer lines of code.  Thank you.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode161
Lib/test/test_os.py:161: @support.cpython_only
On 2013/03/04 18:15:16, ezio.melotti wrote:
> Why are this cpython_only?
> Does the behavior depend on the CPython implementation or on the OS
and/or
> underlying posix function?
Nope, the original test case had this so I included it.  But if you
think it is ok I removed it.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode164
Lib/test/test_os.py:164: (sys.platform == 'win32') ), \
On 2013/03/04 18:15:16, ezio.melotti wrote:
> All the \ should be removed, and there are also 4 sets of () that are
not
> necessary and could be removed as well.
Ok I removed both the \ and the ().  I personally think the () make code
clearer.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode165
Lib/test/test_os.py:165: 'test specific to windows or linux or darwin
only')
On 2013/03/04 18:15:16, ezio.melotti wrote:
> Is this because you only tested it on these platforms?
> I would run it on other platforms too, and possibly add specific skips
if they
> fail there (unless of course the failure is caused by a bug that
should be
> fixed).
> If the skip is really necessary I would create a new skip decorator
and use
> that, instead of repeating this over and over.
I only have access to Mac OS X, Linux, and Windows but would be glad to
try on other platforms if I can get access.  I removed this code for
now.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode167
Lib/test/test_os.py:167: if ((sys.platform == 'darwin') or
(sys.platform.startswith == "linux")):
On 2013/03/04 18:15:16, ezio.melotti wrote:
> All the () are unnecessary and should be removed.
Done....sorry about that just a personal preference.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode171
Lib/test/test_os.py:171: [b"beans", b"bacon", b"eggs", b"spam"])
On 2013/03/04 18:15:16, ezio.melotti wrote:
> PEP8 says that this should either be indented as
> 
> self.assertEqual(fobj.read().splitlines(),
>                  [b"beans", b"bacon", b"eggs", b"spam"])
> 
> or as
> 
> self.assertEqual(
>     fobj.read().splitlines(),
>     [b"beans", b"bacon", b"eggs", b"spam"])
> 
> http://www.python.org/dev/peps/pep-0008/#indentation
Yep that is taken care of in the next version.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode185
Lib/test/test_os.py:185: os.unlink(self.rename_dst_file) # delete
rename_dst_file
On 2013/03/04 18:15:16, ezio.melotti wrote:
> Shouldn't the setUp/tearDown already take care of this?
setUp/teadDown does in most cases.  But for cases when destination
doesn't exist the destination file must be removed.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode369
Lib/test/test_os.py:369: self.assertRaises(OSError, os.rename,
self.rename_src_file, \
On 2013/03/04 18:15:16, ezio.melotti wrote:
> self.assertRaises() can be used as a context manager too, to make the
code more
> readable.
Ummmm....I will have to research context manager.

http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode396
Lib/test/test_os.py:396:
self.assertEqual(os.path.exists(self.rename_dst_directory), True)
On 2013/03/04 18:15:16, ezio.melotti wrote:
> self.assertTrue(os.path.exists(self.rename_dst_directory))
Done....I think the code you suggested is better thanks!

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

From report at bugs.python.org  Sun Mar 10 02:36:21 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Mar 2013 01:36:21 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1362879381.43.0.0551622468321.issue17329@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Mar 10 03:20:18 2013
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 10 Mar 2013 02:20:18 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362882018.05.0.224504079794.issue17387@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/issue17387>
_______________________________________

From report at bugs.python.org  Sun Mar 10 03:28:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Mar 2013 02:28:42 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <3ZNmbF5rhTzQxl@mail.python.org>


Roundup Robot added the comment:

New changeset aea3167355fc by Ezio Melotti in branch '2.7':
#14489: fix wrong link.
http://hg.python.org/cpython/rev/aea3167355fc

----------

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

From report at bugs.python.org  Sun Mar 10 03:30:46 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Mar 2013 02:30:46 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1362882646.72.0.917982864357.issue14489@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The s/:func:`repr`/:func:`.repr`/ committed by Georg got lost in 07b3fc67bf45, however reintroducing it results in this warning:
"Doc/library/functions.rst:1182: WARNING: duplicate object description of repr, other instance in Doc/library/repr.rst, use :noindex: for one of them"
Even after adding the :noindex: the repr() in the table wasn't a link, so I ended up using a workaround that fixed the link and didn't need the :noindex:.

----------
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/issue14489>
_______________________________________

From report at bugs.python.org  Sun Mar 10 04:09:13 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 10 Mar 2013 03:09:13 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362884953.55.0.958945318793.issue17351@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Why is it important to remove subclassing object?  Isn't it still good form to mention object as a base class.

----------
nosy: +nedbat

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

From report at bugs.python.org  Sun Mar 10 04:36:25 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 10 Mar 2013 03:36:25 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362886584.79.0.138072937488.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Version 2 of the patch includes many improvements most of which were suggested by Ezio making the patch a much higher quality.  The patch is very WET at this point.  I still need to test on Windows which I plan to do as soon as I can get my Windows partition in order.  

Thanks for all the great feedback!

----------
Added file: http://bugs.python.org/file29362/16278OSRenameDocsTestV2.patch

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

From report at bugs.python.org  Sun Mar 10 04:39:41 2013
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 10 Mar 2013 03:39:41 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1362886781.24.0.0580418720775.issue17387@psf.upfronthosting.co.za>


Mike Hoy added the comment:

I was looking at 3.4 files. You're right it is in 2.7. Guess you have all the info you need to make a patch for it then?

ssizessizeargfunc PySequenceMethods.sq_slice

It passes the lower and upper bound and expects back a subsequence.

Or is there more to it than that? I cannot for the life of me make any sense out of it. Here I was sitting looking at this thinking it would be very easy doc fix for me but in the end I think I'll bow out.

----------

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

From report at bugs.python.org  Sun Mar 10 05:37:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 10 Mar 2013 04:37:34 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362890254.46.0.976353470171.issue17351@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Why is it important to remove subclassing object?

It's not /important/, but those are just leftovers from 2.x, and there's no reason to keep them around.

> Isn't it still good form to mention object as a base class.

I don't think so (or at least I've never seen anyone suggesting to keep or add "object" explicitly).

The patch LGTM, so unless there's a valid reason to keep the "object" around I'll commit it soon.

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

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

From report at bugs.python.org  Sun Mar 10 07:46:16 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Mar 2013 06:46:16 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362897976.94.0.646320503647.issue17351@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

[Ned]
> Isn't it still good form to mention object as a base class.

I don't think so.  The classes look much cleaner without it.

+1 from for removing (object) from most examples (except for the descriptor howto).

[Terry]
> The respective howto and examples authors should give their 
> OK for deleting '(object)' in case they are trying to keep 
> one text compatible across 2 and 3. I added the other two 
> to the nosy list.

Thanks Terry.  Yes, I would like to keep (object) in the text of the descriptor how-to.  As you said, it keeps the text compatible.  But also, the explicit inheritance from (object) is an aid to clarity in a document that needs to highlight that attribute access occurs in two forms, object.__getattribute__ and type.__getattribute__.

----------

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

From report at bugs.python.org  Sun Mar 10 17:37:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Mar 2013 16:37:38 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <3ZP7Qn3zY8zRf4@mail.python.org>


Roundup Robot added the comment:

New changeset 513c4aaf70d7 by Raymond Hettinger in branch '2.7':
Issue #17351: Modernize the pure Python property() example.
http://hg.python.org/cpython/rev/513c4aaf70d7

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

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

From report at bugs.python.org  Sun Mar 10 17:42:42 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Mar 2013 16:42:42 +0000
Subject: [docs] [issue17351] Fixed python3 descriptor documentation example
	+ removal	of explicit "object" inheritance in docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <3ZP7Xd6LJDzRvh@mail.python.org>


Roundup Robot added the comment:

New changeset bb7e01b5d362 by Raymond Hettinger in branch '3.3':
Issue #17351: Modernize the pure Python property() example.
http://hg.python.org/cpython/rev/bb7e01b5d362

----------

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

From report at bugs.python.org  Sun Mar 10 17:45:37 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Mar 2013 16:45:37 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362933937.88.0.276477437482.issue17351@psf.upfronthosting.co.za>


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


----------
title: Fixed python3 descriptor documentation example + removal of explicit "object" inheritance in docs -> Remove explicit "object" inheritance in Python 3 docs

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

From ezio.melotti at gmail.com  Sun Mar 10 20:57:04 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 10 Mar 2013 19:57:04 -0000
Subject: [docs] In re's named group the name cannot contain unicode
	characters (issue 14462)
Message-ID: <20130310195704.17247.15331@psf.upfronthosting.co.za>

The patch also needs a versionchanged in the docs to say that unicode
names are supported too.


http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py
File Lib/test/test_re.py (right):

http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode197
Lib/test/test_re.py:197:
re.compile('(?P<???????>x)(?P=???????)(?(???????)y)')
Writing non-BMP chars directly in the source is a bit risky -- some
editors might not deal well with it, and in the past we had bugs with
pyc files too.

http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode198
Lib/test/test_re.py:198: self.assertRaises(re.error, re.compile,
'(?P<?>x)')
Maybe add a comment that mentions why this fails (or something like "#
check that valid identifiers works" at the top).

http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode203
Lib/test/test_re.py:203: self.assertRaises(re.error, re.sub, '(?P<a>x)',
r'\g<?>', 'xx')
Do these tests cover all the cases you changed in re.py?

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

From report at bugs.python.org  Sun Mar 10 20:59:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Mar 2013 19:59:25 +0000
Subject: [docs] [issue763043] unable to specify another compiler
Message-ID: <1362945565.74.0.73309927034.issue763043@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Is this still relevant, or should it be closed?

I no 0 idea what either of you think should be changed in the docs and where, and I suspect the same would be true of any other non-disutils expert, so if a patch is needed, it should come from one you two (Matthias?).

Meththias, you are not marked as having a Contributor Agreement on file. Paper forms were lost some years ago. I had to re-submit too. It is even easier now. http://www.python.org/psf/contrib/

----------
nosy: +terry.reedy
versions:  -Python 3.1

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

From report at bugs.python.org  Sun Mar 10 21:03:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Mar 2013 20:03:53 +0000
Subject: [docs] [issue8318] Deprecation of multifile inappropriate or
	incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1362945833.26.0.628849222582.issue8318@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Sun Mar 10 21:04:00 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Mar 2013 20:04:00 +0000
Subject: [docs] [issue8318] Deprecation of multifile inappropriate or
	incomplete
In-Reply-To: <1270489322.03.0.368739706632.issue8318@psf.upfronthosting.co.za>
Message-ID: <1362945840.91.0.0264117460218.issue8318@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> committed/rejected

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

From report at bugs.python.org  Sun Mar 10 21:53:03 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 10 Mar 2013 20:53:03 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362948783.42.0.956394393367.issue17351@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

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

From rovitotv at gmail.com  Mon Mar 11 03:15:07 2013
From: rovitotv at gmail.com (rovitotv at gmail.com)
Date: Mon, 11 Mar 2013 02:15:07 -0000
Subject: [docs] os.rename documentation slightly inaccurate (issue 16278)
Message-ID: <20130311021507.10083.41945@psf.upfronthosting.co.za>

Thanks for the review...I think the patch is getting better and better. 
Soon I should have this tested on Windows, hopefully tonight.


http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py
File Lib/test/test_os.py (right):

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2209
Lib/test/test_os.py:2209: class RenameTests(unittest.TestCase):
On 2013/03/11 00:45:35, vstepanov wrote:
> I have some comments to this patch.
> I think would be better to add two separate test case RenameFileTests
and
> RenameDirTests or something like that.
I actually like it in a single class because alot of the functionality
is the same for testing the rename of a directory or file.  If we
separate it into two classes then I am afraid that we get lots of
repeating which leads to DRY test cases.  See earlier comments in issue.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2215
Lib/test/test_os.py:2215: self.rename_src_file = "%s_%d_tmp" %
("test_rename_src_file",
On 2013/03/11 00:45:35, vstepanov wrote:
> All variables has prefix ``rename_`` (rename_src_file, rename_dst_file
and so
> on), so can use them without this prefix (just src_file, dst_file ...)
Good point....this is a side effect from me moving over to a new class
before it was in the FileTests directory.  Now that we have a
RenameTests class we can remove the rename_ in front of all the
variables this will help readability.  Thanks!

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2216
Lib/test/test_os.py:2216: os.getpid())
On 2013/03/11 00:45:35, vstepanov wrote:
> should not call this method everywhere, use a variable
Yes that will be more efficient, thanks!

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2217
Lib/test/test_os.py:2217: if os.path.exists(self.rename_src_file):
On 2013/03/11 00:45:35, vstepanov wrote:
> There is remove_file_or_directory method, use it for remove exist
files/dirs.
Good point, I don't know how I missed the remove_file_or_directory in
setUp but I did.  Thanks.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2220
Lib/test/test_os.py:2220: os.write(fd, b"beans\n")
On 2013/03/11 00:45:35, vstepanov wrote:
> Really need to write many lines in a file and then split the text on
the line in
> tests? Perhaps enough only one.
I got the original code from test_os.py line 111 in the TestWrite
method.  But it does not have to be that way I think the TestWrite
method was testing writes with binary data, byte array data, and memory
view data.  This is actually easier to read and doing the split lines
doesn't add any value.  Thanks.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2277
Lib/test/test_os.py:2277: if (os.path.isfile(file)):
On 2013/03/11 00:45:35, vstepanov wrote:
> outer parentheses are unnecessary
Yes too much scheme sorry I missed those, they are gone now.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2289
Lib/test/test_os.py:2289: self.assertRaises(OSError, os.rename, src,
dst)
On 2013/03/11 00:45:35, vstepanov wrote:
> I do not see where `src` and `dst` variables are declared
Oops I didn't catch that because I have not tested on Windows yet.  I do
plan to test on Windows soon maybe even tonight.  My Windows partition
is not setup correctly yet since I got my new computer back in October.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2295
Lib/test/test_os.py:2295:
self.remove_file_or_directory(self.rename_dst_file)
On 2013/03/11 00:45:35, vstepanov wrote:
> I think it would be better to create the files/directories in separate
methods
> and call them in tests methods instead of create them in setUp method
and remove
> in each test (except for those that are not removed in tests methods,
they can
> be left in the setUp).
I have been wondering if there is a better approach to all of this. 
According to some of the CPython Committers we have to make the test
case as WET as possible and not repeat ourselves.  Before I was actually
creating the files/directories in the test cases but was not using a
method it took a lot of code.  I could make a version that does that but
use methods to create the files instead then measure the line count to
see which solution is WETTEST.  Let me think about this....

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2326
Lib/test/test_os.py:2326:
self.assertEqual(os.path.exists(self.rename_dst_directory), True)
On 2013/03/11 00:45:35, vstepanov wrote:
> There are unittest.TestCase.assertTrue and
unittest.TestCase.assertFalse
> methods.
Yes I fixed some of them with V2 but V3 now has all of them fixed. 
Thanks.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2402
Lib/test/test_os.py:2402: src = self.rename_src_file + "does_not_exist"
On 2013/03/11 00:45:35, vstepanov wrote:
> I don't see where `src` and `dst` are used.
You are correct I don't need those thanks!


I will post a new version soon....

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

From report at bugs.python.org  Mon Mar 11 03:18:14 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 11 Mar 2013 02:18:14 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362968294.07.0.331693612223.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

V3 added which includes much shorter variable names and a cleanup of the patch.  I still need to test on Windows.

----------
Added file: http://bugs.python.org/file29370/16278OSRenameDocsTestV3.patch

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

From report at bugs.python.org  Mon Mar 11 03:21:24 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 11 Mar 2013 02:21:24 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362968484.32.0.805173835862.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Thanks for the feedback Vitaliy Stepanov that helped alot with the version 3 patch.

----------

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

From report at bugs.python.org  Mon Mar 11 03:46:43 2013
From: report at bugs.python.org (Todd Rovito)
Date: Mon, 11 Mar 2013 02:46:43 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1362970002.78.0.924389185442.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Made some very minor changes to get patch to work on Windows.  Had issues with line ending differences between Unix and Windows. I fixed it so line endings won't be an issue and tested patch on Windows, Linux, and OS X.  

Please feel free to supply feedback or commit.  Thanks.

----------
Added file: http://bugs.python.org/file29371/16278OSRenameDocsTestV4.patch

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

From report at bugs.python.org  Mon Mar 11 05:32:04 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:32:04 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362976324.83.0.754334894479.issue17351@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Note that removing the unnecessary '(object)' may make it worse for e.g. beginners going from 3.x to 2.x, and slightly complicate porting patches.  Raymond approves the removal, yet added '(object)' in a 3.3 doc file in 5eca56b68840

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

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

From report at bugs.python.org  Mon Mar 11 05:33:11 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:33:11 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362976391.79.0.79564027807.issue17351@psf.upfronthosting.co.za>


?ric Araujo added the comment:

The changeset redirector seems broken, here?s the full link: http://hg.python.org/cpython/rev/5eca56b68840

FTR I am still in favor of removal regardless of the possible issues I noted in my previous comment.

----------

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

From report at bugs.python.org  Mon Mar 11 05:37:25 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:37:25 +0000
Subject: [docs] [issue763043] unable to specify another compiler
Message-ID: <1362976645.66.0.285005671735.issue763043@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Starting with Python 2.3, environment variables like CC (familiar to people compiling C projects on unix) are respected.  That?s what I think should be added to the distutils docs, maybe in the reference doc for build_ext, or in the narrative doc talking about extension modules.

----------

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

From report at bugs.python.org  Mon Mar 11 05:58:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:58:01 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362977881.18.0.371320370447.issue17351@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Disregard my comments, I reread only the start of the thread and missed the discussion about the descriptor tutorial.

----------

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

From report at bugs.python.org  Mon Mar 11 05:58:13 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:58:13 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362977893.32.0.0804112576575.issue17351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar 11 05:58:15 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:58:15 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362977895.28.0.918689003585.issue17351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar 11 05:58:17 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:58:17 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362977897.15.0.568368133282.issue17351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Mar 11 05:59:26 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 11 Mar 2013 04:59:26 +0000
Subject: [docs] [issue17359] python modules.zip is not documented
In-Reply-To: <1362512425.64.0.937549165034.issue17359@psf.upfronthosting.co.za>
Message-ID: <1362977966.05.0.20518200416.issue17359@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo, ncoghlan
versions: +Python 3.2 -Python 3.5

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

From report at bugs.python.org  Mon Mar 11 06:20:05 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Mar 2013 05:20:05 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362979205.7.0.444987167042.issue17351@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My rationale for supporting removal is this: People beginning with Py3, which is most beginners in the next decade, seeing (object), might think it necessary in certain cases or that it does something. The descriptor how-to is a) advanced and b) can have a note if needed. People who know Py2 might get a wrong idea either way, but should read some 2 to 3 guide and then will know. If a choice be needed, I would rather cater to future Python learners.

Anyway, we only need Michael's word to know for sure which to patch, or can go ahead without touching mock-examples.

----------

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

From report at bugs.python.org  Mon Mar 11 08:43:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Mar 2013 07:43:41 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <3ZPWXD2lqwzRgd@mail.python.org>


Roundup Robot added the comment:

New changeset 4f745f7d6fca by Ezio Melotti in branch '3.2':
#17351: remove "object" inheritance from docs.  Patch by Phil Elson.
http://hg.python.org/cpython/rev/4f745f7d6fca

New changeset 8b1d3fa3b389 by Ezio Melotti in branch '3.3':
#17351: merge with 3.2.
http://hg.python.org/cpython/rev/8b1d3fa3b389

New changeset b10a9d4f08eb by Ezio Melotti in branch 'default':
#17351: merge with 3.3.
http://hg.python.org/cpython/rev/b10a9d4f08eb

----------

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

From report at bugs.python.org  Mon Mar 11 08:45:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 11 Mar 2013 07:45:12 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362987912.4.0.393001777074.issue17351@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Mon Mar 11 09:08:16 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Mar 2013 08:08:16 +0000
Subject: [docs] [issue17370] PEP should note related PEPs
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1362989296.23.0.767182983412.issue17370@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, I think the problem in this case is specific to the multi-versioned PEPs like the WSGI reference and the metadata standards. In that case, a separate section in the document itself seems more appropriate than a generic header field.

We should consider a similar section for PEP 302 (pointing to the 3.3 language reference) given the length of time that PEP has been the only systematic documentation for the import hooks.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Mon Mar 11 11:09:59 2013
From: report at bugs.python.org (Michael Foord)
Date: Mon, 11 Mar 2013 10:09:59 +0000
Subject: [docs] [issue17351] Remove explicit "object" inheritance in Python
	3 docs
In-Reply-To: <1362407799.21.0.301955058492.issue17351@psf.upfronthosting.co.za>
Message-ID: <1362996599.53.0.44149827218.issue17351@psf.upfronthosting.co.za>


Michael Foord added the comment:

If the consensus is that Python documentation should not include explicit object inheritance then fine to update mock docs accordingly. The backport docs will still use it as they are for Python 2 as well.

----------

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

From report at bugs.python.org  Mon Mar 11 12:10:20 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Mon, 11 Mar 2013 11:10:20 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1363000220.28.0.650394274235.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Eli, I fully understand. I was experimenting with working on Cloud9, but it unfortunately has no easy way to extract individual files, I had to recreate them locally. I hope it is correct now.

----------
Added file: http://bugs.python.org/file29374/issue11367_branch27.patch

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

From report at bugs.python.org  Mon Mar 11 12:10:40 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Mon, 11 Mar 2013 11:10:40 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1363000240.07.0.681033645053.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

for 3.2

----------
Added file: http://bugs.python.org/file29375/issue11367_branch32.patch

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

From report at bugs.python.org  Mon Mar 11 14:46:13 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Mar 2013 13:46:13 +0000
Subject: [docs] [issue17370] PEP should note related PEPs
In-Reply-To: <1362618784.61.0.181108502719.issue17370@psf.upfronthosting.co.za>
Message-ID: <1363009573.0.0.165331297746.issue17370@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

It seems to me that the right thing to add a related PEPs section to any PEP which needs it, but I don't think we need an official header for it.  Thus, I'm closing this PEP as Won't Fix.  Feel free to open new bugs for any specific PEP that needs additional work, or if you have commit privileges, JFDI. :)

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

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

From report at bugs.python.org  Mon Mar 11 15:39:07 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Mar 2013 14:39:07 +0000
Subject: [docs] [issue8402] Add a function to escape metacharacters in
	glob/fnmatch
In-Reply-To: <1271292687.68.0.249436327738.issue8402@psf.upfronthosting.co.za>
Message-ID: <1363012747.09.0.704138875539.issue8402@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Escaping for glob on Windows should not be such trivial. Special characters in the drive part have no special meaning and should not be escaped. I.e. ``escape('//?/c:/Quo vadis?.txt')`` should return ``'//?/c:/Quo vadis[?].txt'``. Perhaps we should move the escape function to the glob module (because it is glob's peculiarity).

Here is a patch for glob.escape().

----------
Added file: http://bugs.python.org/file29380/glob_escape.patch

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

From report at bugs.python.org  Mon Mar 11 18:22:56 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Mon, 11 Mar 2013 17:22:56 +0000
Subject: [docs] [issue17398] document url argument of RobotFileParser
Message-ID: <1363022576.74.0.509640263285.issue17398@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

Looking at the documentation, one would think RobotFileParser does not accept any argument, but it does -- "url".

Documenting this would remove the pain of having to call "set_url()".

----------
assignee: docs at python
components: Documentation
messages: 183979
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: document url argument of RobotFileParser
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 11 22:29:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Mar 2013 21:29:04 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <3ZPsrb38lgzQX4@mail.python.org>


Roundup Robot added the comment:

New changeset 1ecb712fcf22 by Terry Jan Reedy in branch '2.7':
Issue #17047: removed doubled words in Doc/*, Mac/*, and Tool/*
http://hg.python.org/cpython/rev/1ecb712fcf22

New changeset e37647470fcf by Terry Jan Reedy in branch '3.2':
Issue #17047: removed doubled words in Doc/*, Mac/*, and Tool/*
http://hg.python.org/cpython/rev/e37647470fcf

New changeset 629322a13b53 by Terry Jan Reedy in branch '3.3':
Merge with 3.2: Issue #17047: removed doubled words in Doc/*,
http://hg.python.org/cpython/rev/629322a13b53

New changeset c187c145b4c4 by Terry Jan Reedy in branch 'default':
Merge with 3.3: Issue #17047: removed doubled words in Doc/*,
http://hg.python.org/cpython/rev/c187c145b4c4

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

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

From report at bugs.python.org  Mon Mar 11 22:30:36 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Mar 2013 21:30:36 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363037436.03.0.68913989267.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Tools/gdb/libpython.py and some other doubles were fixed by rev81772 on the same day this issue was opened. I suspect that the copy had not been updated.

----------

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

From report at bugs.python.org  Mon Mar 11 22:43:13 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Mar 2013 21:43:13 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363038193.23.0.222683383642.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Terry.

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

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

From report at bugs.python.org  Mon Mar 11 22:47:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Mar 2013 21:47:07 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <3ZPtFQ4hLZzRvT@mail.python.org>


Roundup Robot added the comment:

New changeset e145dddb9d93 by Terry Jan Reedy in branch '2.7':
Issue #17047: remove doubled words found in 2.7 to 3.4 Modules/*,
http://hg.python.org/cpython/rev/e145dddb9d93

New changeset e9ba9f21a828 by Terry Jan Reedy in branch '3.2':
Issue #17047: remove doubled words found in 2.7 to 3.4 Modules/*,
http://hg.python.org/cpython/rev/e9ba9f21a828

New changeset a42195046e39 by Terry Jan Reedy in branch '3.3':
Merge 3.2, Issue #17047: remove doubled words found in 2.7 to 3.4
http://hg.python.org/cpython/rev/a42195046e39

New changeset 4bd13f45d3a2 by Terry Jan Reedy in branch 'default':
Merge 3.3, issue #17047: remove doubled words found in 2.7 to 3.4
http://hg.python.org/cpython/rev/4bd13f45d3a2

----------

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

From report at bugs.python.org  Mon Mar 11 23:00:17 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Mar 2013 22:00:17 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <3ZPtXS1JJqzRMP@mail.python.org>


Roundup Robot added the comment:

New changeset cd0191a9b5c9 by Terry Jan Reedy in branch '2.7':
Issue #17047: remove doubled words found in 2.7 to 3.4 Lib/*,
http://hg.python.org/cpython/rev/cd0191a9b5c9

New changeset 3f5f961262ec by Terry Jan Reedy in branch '3.2':
Issue #17047: remove doubled words found in 2.7 to 3.4 Lib/*,
http://hg.python.org/cpython/rev/3f5f961262ec

New changeset 0547f89aa620 by Terry Jan Reedy in branch '3.3':
Merge 3.2, issue #17047: remove doubled words found in 2.7 to
http://hg.python.org/cpython/rev/0547f89aa620

New changeset 01aa93888917 by Terry Jan Reedy in branch 'default':
Merge 3.3, issue #17047: remove doubled words found in 2.7 to
http://hg.python.org/cpython/rev/01aa93888917

----------

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

From report at bugs.python.org  Mon Mar 11 23:40:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Mar 2013 22:40:12 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <3ZPvQh10dxzRXb@mail.python.org>


Roundup Robot added the comment:

New changeset e9ada209b67f by Terry Jan Reedy in branch '3.3':
Issue #17047: remove doubled words added in 3.3
http://hg.python.org/cpython/rev/e9ada209b67f

New changeset 908d45fdbecd by Terry Jan Reedy in branch 'default':
Merge with 3.3, issue #17047: remove doubled words added in 3.3,
http://hg.python.org/cpython/rev/908d45fdbecd

New changeset 0a26a8b13193 by Terry Jan Reedy in branch 'default':
Issue #17047: remove doubled words added in 3.4,
http://hg.python.org/cpython/rev/0a26a8b13193

----------

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

From report at bugs.python.org  Tue Mar 12 04:13:33 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 03:13:33 +0000
Subject: [docs] [issue17401] io.FileIO closefd parameter is not documented
	nor shown	in repr
In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za>
Message-ID: <1363058013.34.0.874699065067.issue17401@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation, IO, Library (Lib)
nosy: +docs at python, pitrou
type:  -> enhancement
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Mar 12 04:39:13 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2013 03:39:13 +0000
Subject: [docs] [issue16774] Additional recipes for itertools docs
In-Reply-To: <1356381615.1.0.91798699559.issue16774@psf.upfronthosting.co.za>
Message-ID: <1363059553.29.0.843143474726.issue16774@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I will add drop() to the recipes and possibly take_last() which I would rename add tail().

Sorry, I don't have interest in the others.  I don't find them instructive or very useful.

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

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

From report at bugs.python.org  Tue Mar 12 05:11:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 04:11:18 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1363061478.4.0.144502459681.issue17375@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/issue17375>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:14:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 04:14:40 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1363061680.21.0.472333475174.issue15964@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

`make touch` is now in 2.7, so the patch should be updated.

----------

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

From report at bugs.python.org  Tue Mar 12 05:16:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 04:16:07 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1363061767.19.0.30408445788.issue17387@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson, ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Tue Mar 12 07:09:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 06:09:25 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363068564.98.0.368251003313.issue17047@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The files in Modules/_ctypes/libffi/* shouldn't have been changed, but it probably doesn't matter much.  You also got the wrong issue id in Misc/NEWS (c162e2ff15bd).

----------

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

From report at bugs.python.org  Tue Mar 12 07:44:44 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2013 06:44:44 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363070684.11.0.335573757336.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I should have made separate new in 3.3 and new in 3.4 patches to begin with. This suggests that we need to recheck with each version. Serhiy and Mathew, could you post your search re's or scripts to use again on occasion?

I unlinked the 2.7 news notice, rev82624, misdirected to 14707
 Documentation
 -------------
 
+- Issue #14707: remove doubled words in docs and docstrings
+  reported by Serhiy Storchaka and Matthew Barnett.
+
 - Issue #16406: combine the pages for uploading and registering to PyPI.
 
 - Issue #16403: Document how distutils uses the maintainer field in

I am unable to properly add the 2 line NEWS note to 3.2 (or 3.3) as explained in a response on the python-checkins list. The whole file is deleted and added back with three extra lines (I presume they are added), or even with just one blank line added, in a monster 319kb patch. If someone wants to add a corrected version of the above for 3.2,3,4 on *nix, please go ahead.

Ezio, I do not understand your comment. The only change that looks even possibly wrong is 'that that' to 'that', and I am pretty sure I checked the context.

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

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

From report at bugs.python.org  Tue Mar 12 07:56:35 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 06:56:35 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363071395.92.0.414482935704.issue17047@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

AFAIK libffi is maintained externally, so as soon as it gets updated your changes will simply get lost (see #17192).  I replied on your python-checkins email.  If you still have problems I can add the NEWS entry on 3.x.

----------

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

From report at bugs.python.org  Tue Mar 12 08:21:15 2013
From: report at bugs.python.org (py.user)
Date: Tue, 12 Mar 2013 07:21:15 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
Message-ID: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>


New submission from py.user:

http://docs.python.org/3/library/mmap.html

examples use map as a name for the mmap object

----------
assignee: docs at python
components: Documentation
messages: 184015
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In mmap doc examples map() is shadowed
type: performance
versions: Python 3.3

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

From report at bugs.python.org  Tue Mar 12 08:40:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 12 Mar 2013 07:40:56 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <1363074056.69.0.526841185819.issue17402@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type: performance -> enhancement
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Tue Mar 12 13:02:50 2013
From: report at bugs.python.org (Aman Shah)
Date: Tue, 12 Mar 2013 12:02:50 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <1363089770.44.0.153932374121.issue17402@psf.upfronthosting.co.za>


Aman Shah added the comment:

Corrected map -> mymap.

----------
keywords: +patch
nosy: +Aman.Shah
Added file: http://bugs.python.org/file29386/issue17402.patch

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

From report at bugs.python.org  Tue Mar 12 14:07:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Mar 2013 13:07:12 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <3ZQGg33tlJzRhJ@mail.python.org>


Roundup Robot added the comment:

New changeset 958217164846 by Eli Bendersky in branch '3.2':
Issue #11367: fix documentation of some find* methods in ElementTree
http://hg.python.org/cpython/rev/958217164846

New changeset 4012d4b41b2b by Eli Bendersky in branch '3.3':
Issue #11367: fix documentation of some find* methods in ElementTree
http://hg.python.org/cpython/rev/4012d4b41b2b

New changeset 7ae2c90f1ba2 by Eli Bendersky in branch 'default':
Issue #11367: fix documentation of some find* methods in ElementTree
http://hg.python.org/cpython/rev/7ae2c90f1ba2

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

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

From report at bugs.python.org  Tue Mar 12 14:09:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Mar 2013 13:09:09 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <3ZQGjJ3BCdzRkN@mail.python.org>


Roundup Robot added the comment:

New changeset 8e6db2462a77 by Eli Bendersky in branch '2.7':
Issue #11367: fix documentation of some find* methods in ElementTree
http://hg.python.org/cpython/rev/8e6db2462a77

----------

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

From report at bugs.python.org  Tue Mar 12 14:09:54 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 12 Mar 2013 13:09:54 +0000
Subject: [docs] [issue11367] xml.etree.ElementTree.find(all): docs are wrong
In-Reply-To: <1299030271.87.0.648664421014.issue11367@psf.upfronthosting.co.za>
Message-ID: <1363093794.86.0.825559403543.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Thanks for the patches - committed with slight adaptations (in default branch the internal documentation switched from comments to docstrings).

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

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

From report at bugs.python.org  Tue Mar 12 15:48:06 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Mar 2013 14:48:06 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363099686.7.0.520181506254.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Serhiy and Mathew, could you post your search re's or scripts to use again on occasion?

For example:

  find * -type f -name '*.[ch]' -exec egrep -n '\b([a-zA-Z]+) \1\b' '{}' + | grep -v 'long long' | egrep --color '\b([a-zA-Z]+) \1\b'
  find * -type f -name '*.py' -exec egrep -n --color '\b([a-zA-Z]+) \1\b' '{}' +

And similar one-time one-liners for *.rst, *.txt, etc.

----------

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

From report at bugs.python.org  Tue Mar 12 17:29:27 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2013 16:29:27 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363105767.83.0.092859581582.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I emailed the libffi subpatch to libffi-discuss.
Please add the 3.x news entry if you can get to it before I am able.
Then this issue can be closed, though the problem will obviously recur without an automatic check.

----------

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

From report at bugs.python.org  Tue Mar 12 19:06:33 2013
From: report at bugs.python.org (py.user)
Date: Tue, 12 Mar 2013 18:06:33 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <1363111593.42.0.603387033427.issue17402@psf.upfronthosting.co.za>


py.user added the comment:

how about "mm" ?

----------

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

From report at bugs.python.org  Tue Mar 12 19:48:38 2013
From: report at bugs.python.org (py.user)
Date: Tue, 12 Mar 2013 18:48:38 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <1363114118.46.0.110444418173.issue17402@psf.upfronthosting.co.za>


Changes by py.user <bugzilla-mail-box at yandex.ru>:


Added file: http://bugs.python.org/file29390/mm.patch

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

From report at bugs.python.org  Tue Mar 12 21:10:06 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2013 20:10:06 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1363119006.09.0.483934880208.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I added :const: and tweaked -OO entry and -h startup display.
Tested new html and python_d -h. Any other comments before I apply?

----------
assignee: docs at python -> terry.reedy
Added file: http://bugs.python.org/file29392/17232-O.diff

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

From report at bugs.python.org  Tue Mar 12 21:17:37 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Mar 2013 20:17:37 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1363119457.56.0.378806683531.issue17232@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

There's a typo in your patch:

+-O     : remove assert and __debug__-dependent statements; change .py\n\
+         to .pyo; also PYTHONOPTIMIZE=x\n\

should say ".pyc", not ".py".

----------

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

From report at bugs.python.org  Tue Mar 12 21:18:28 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Mar 2013 20:18:28 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1363119508.89.0.88386386819.issue17232@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Also, in 3.2 and higher I'm not sure there's a point in mentioning pyc/pyo files; they're all shelved in __pycache__ now.

----------

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

From report at bugs.python.org  Tue Mar 12 22:28:04 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2013 21:28:04 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1363123684.17.0.297438452578.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I corrected my copy of the .diff.

Since this issue is so far focused on removing the false optimize claim, hiding .pyx info is a new sub-issue. I will follow whatever the consensus is, but since this is a cpython-specific doc and help, I would prefer to give complete info. In fact, I would like to add 'stored in __pycache__' or even 'hidden away in  __pycache__', the latter to suggest that most people should generally forget about them. On Windows, _xxx files like __pycache__ appear in both Command Prompt dir and Explorer file listings, so beginners need to known that __cache__ is both normal and ignorable.

----------

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

From report at bugs.python.org  Wed Mar 13 01:28:09 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Mar 2013 00:28:09 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <3ZQYmm4NsfzNvq@mail.python.org>


Roundup Robot added the comment:

New changeset c226133b1493 by Ezio Melotti in branch '2.7':
#17402: avoid shadowing built-in map in mmap examples.  Initial patch by Aman Shah.
http://hg.python.org/cpython/rev/c226133b1493

New changeset df27ea4bdebd by Ezio Melotti in branch '3.2':
#17402: avoid shadowing built-in map in mmap examples.  Initial patch by Aman Shah.
http://hg.python.org/cpython/rev/df27ea4bdebd

New changeset bf0632a17ab4 by Ezio Melotti in branch '3.3':
#17402: merge with 3.2.
http://hg.python.org/cpython/rev/bf0632a17ab4

New changeset b49971a1e70d by Ezio Melotti in branch 'default':
#17402: merge with 3.3.
http://hg.python.org/cpython/rev/b49971a1e70d

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

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

From report at bugs.python.org  Wed Mar 13 01:29:56 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Mar 2013 00:29:56 +0000
Subject: [docs] [issue17402] In mmap doc examples map() is shadowed
In-Reply-To: <1363072875.55.0.485249450415.issue17402@psf.upfronthosting.co.za>
Message-ID: <1363134596.54.0.52928500553.issue17402@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patches!
(py.user, if you specify your real name, next time I can give you credits too.)

----------
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/issue17402>
_______________________________________

From report at bugs.python.org  Wed Mar 13 02:27:30 2013
From: report at bugs.python.org (Alex Orange)
Date: Wed, 13 Mar 2013 01:27:30 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1363138050.59.0.625855883347.issue17387@psf.upfronthosting.co.za>


Alex Orange added the comment:

I must admit I'm a little new to the development side of things. Can someone point me at a repo or something that the documentation files are in? I'm sort of guessing that the html is the processed output of something.

----------

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

From report at bugs.python.org  Wed Mar 13 03:14:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Mar 2013 02:14:58 +0000
Subject: [docs] [issue17387] Error in C API documentation of
	PySequenceMethods
In-Reply-To: <1362790710.8.0.92948490889.issue17387@psf.upfronthosting.co.za>
Message-ID: <1363140898.36.0.504084541131.issue17387@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See http://docs.python.org/devguide/ and the Doc/c-api dir in the CPython repo.

----------

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

From report at bugs.python.org  Wed Mar 13 07:56:01 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Mar 2013 06:56:01 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1363119508.89.0.88386386819.issue17232@psf.upfronthosting.co.za>
Message-ID: <CADiSq7eCcxbfxri_4JPuJppS7pAuBnaweWGLaTiHcDjVBEwxvg@mail.gmail.com>


Nick Coghlan added the comment:

On Tue, Mar 12, 2013 at 1:18 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou added the comment:
>
> Also, in 3.2 and higher I'm not sure there's a point in mentioning pyc/pyo files; they're all shelved in __pycache__ now.

It still makes a difference for bytecode-only files, which aren't in __pycache__

Cheers,
Nick.

----------

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

From report at bugs.python.org  Wed Mar 13 10:52:34 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Mar 2013 09:52:34 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1362648255.88.0.520762515957.issue17375@psf.upfronthosting.co.za>
Message-ID: <1363168354.37.0.906304635756.issue17375@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> You didn't specify the contributor in the commit.

I'm the contributor.  

> Also, you've only committed this to 2.7; why?
I committed to 2.7 because the 2.7 docs were the source.  
When I get the time, I will build a 3.x version of the update.

----------

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

From report at bugs.python.org  Wed Mar 13 13:43:52 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 Mar 2013 12:43:52 +0000
Subject: [docs] [issue17380] initproc return value is unclear
In-Reply-To: <1362676337.45.0.36627137275.issue17380@psf.upfronthosting.co.za>
Message-ID: <1363178632.72.0.796959051114.issue17380@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Note that all these cases are compatible with "tp_init returns 0 on success and -1 on error".

----------

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

From report at bugs.python.org  Wed Mar 13 14:22:38 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 13 Mar 2013 13:22:38 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1363180958.05.0.829976283345.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

See also #17375

----------

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

From report at bugs.python.org  Wed Mar 13 14:22:42 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 13 Mar 2013 13:22:42 +0000
Subject: [docs] [issue17375] Add docstrings to methods in the threading
	module
In-Reply-To: <1363168354.37.0.906304635756.issue17375@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda9s+WrWZXova+fiskuG4n77zSobKinbHHUyYJUvJsTH+A@mail.gmail.com>


Eli Bendersky added the comment:

On Wed, Mar 13, 2013 at 2:52 AM, Raymond Hettinger
<report at bugs.python.org>wrote:

>
> Raymond Hettinger added the comment:
>
> > You didn't specify the contributor in the commit.
>
> I'm the contributor.
>

Oh, I see. I thought it's taken from one of the two existing patches from
new contributors, either in this issue or #12768.

>
> > Also, you've only committed this to 2.7; why?
> I committed to 2.7 because the 2.7 docs were the source.
> When I get the time, I will build a 3.x version of the update.
>

OK.

----------

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

From report at bugs.python.org  Wed Mar 13 23:14:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Mar 2013 22:14:25 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1363212865.85.0.0436211105595.issue17386@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

2.7 make.bat, which currently downloads sphinx v0.6.7 but not at least one needed file, does not work. See #17412. I asked there whether simply updating the sphinx version, which seems to work, is the right fix. I believe this is currently the only different in make.bat between Python versions.

----------

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

From report at bugs.python.org  Wed Mar 13 23:45:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Mar 2013 22:45:08 +0000
Subject: [docs] [issue17243] The changes made for issue 4074 should be
	documented
In-Reply-To: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>
Message-ID: <1363214708.0.0.341885048071.issue17243@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type: behavior -> enhancement

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

From report at bugs.python.org  Thu Mar 14 00:23:26 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Mar 2013 23:23:26 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363217006.53.0.115014850197.issue13918@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It looks like an implementation detail to me, so I tend to agree with Georg.  I'm not sure if this should be noted in the code though.

----------
nosy: +ezio.melotti
status: open -> pending

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

From report at bugs.python.org  Thu Mar 14 01:03:19 2013
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 14 Mar 2013 00:03:19 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363219399.36.0.369484271943.issue13918@psf.upfronthosting.co.za>


C?dric Krier added the comment:

Then I think we miss a locale.atod to parse string to Decimal

----------
status: pending -> open

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

From report at bugs.python.org  Thu Mar 14 01:33:34 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 00:33:34 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363221214.17.0.0959901989283.issue13918@psf.upfronthosting.co.za>


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


----------
nosy: +mark.dickinson, skrah

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

From report at bugs.python.org  Thu Mar 14 02:42:08 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 Mar 2013 01:42:08 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <3ZRCMg3Py5zRnv@mail.python.org>


Roundup Robot added the comment:

New changeset 9b45873e5a68 by Terry Jan Reedy in branch '3.2':
Issue #17386 make.bat must run with Python 2 until Sphinx runs with Python 3.
http://hg.python.org/cpython/rev/9b45873e5a68

New changeset e45db319e590 by Terry Jan Reedy in branch '3.3':
Merge with 3.2: Issue #17386
http://hg.python.org/cpython/rev/e45db319e590

New changeset 99e72eae35bb by Terry Jan Reedy in branch 'default':
Merge with 3.3: Issue #17386
http://hg.python.org/cpython/rev/99e72eae35bb

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

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

From report at bugs.python.org  Thu Mar 14 02:49:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Mar 2013 01:49:30 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1363225770.54.0.342481937029.issue17386@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I pushed the minipatch but did not add a news item as it may get superseded and will not affect anyone currently setting PYTHON.

----------

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

From report at bugs.python.org  Thu Mar 14 08:39:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 07:39:57 +0000
Subject: [docs] [issue11479] Add discussion of trailing backslash in raw
	string to	tutorial
In-Reply-To: <1299985803.24.0.199507309731.issue11479@psf.upfronthosting.co.za>
Message-ID: <1363246797.86.0.62428872766.issue11479@psf.upfronthosting.co.za>


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


----------
stage: patch review -> commit review

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

From ezio.melotti at gmail.com  Thu Mar 14 08:47:00 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 14 Mar 2013 07:47:00 -0000
Subject: [docs] Improve -O docs (issue 17232)
Message-ID: <20130314074700.30525.72697@psf.upfronthosting.co.za>


http://bugs.python.org/review/17232/diff/7583/Doc/using/cmdline.rst
File Doc/using/cmdline.rst (right):

http://bugs.python.org/review/17232/diff/7583/Doc/using/cmdline.rst#newcode214
Doc/using/cmdline.rst:214: :const:`__debug__`.  Change the filename
extension for compiled
Does this link to the place where __debug__ is documented (assuming
there is such place)?

http://bugs.python.org/review/17232/diff/7583/Doc/using/cmdline.rst#newcode221
Doc/using/cmdline.rst:221: Discard docstrings in addition to what
:option:`-O` does.
What about "Like :option:`-O`, but also discard docstrins."?

http://bugs.python.org/review/17232/diff/7583/Modules/main.c
File Modules/main.c (right):

http://bugs.python.org/review/17232/diff/7583/Modules/main.c#newcode69
Modules/main.c:69: -O     : remove assert and __debug__-dependent
statements; change .py\n\
Shouldn't this be .pyc?

http://bugs.python.org/review/17232/diff/7583/Modules/main.c#newcode71
Modules/main.c:71: -OO    : remove doc-strings in addition to the -O
changes\n\
I would re-use the same wording I proposed for the docs.

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

From report at bugs.python.org  Thu Mar 14 08:47:41 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 07:47:41 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1363247261.13.0.720581104799.issue17232@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a review on rietveld.

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

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

From report at bugs.python.org  Thu Mar 14 09:11:08 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 08:11:08 +0000
Subject: [docs] [issue15575] Tutorial is unclear on multiple imports of a
	module.
In-Reply-To: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za>
Message-ID: <1363248668.21.0.0735742044786.issue15575@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar 14 09:15:43 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 08:15:43 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <1363248943.39.0.0738534774688.issue17414@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, ezio.melotti
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Thu Mar 14 09:17:45 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 08:17:45 +0000
Subject: [docs] [issue14515] tempfile.TemporaryDirectory documented as
	returning	object but returns name
In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>
Message-ID: <1363249065.22.0.681862883148.issue14515@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, terry.reedy
stage: needs patch -> patch review
versions: +Python 3.4

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

From report at bugs.python.org  Thu Mar 14 09:19:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 08:19:59 +0000
Subject: [docs] [issue13604] update PEP 393 (match implementation)
In-Reply-To: <1323923147.38.0.737729792057.issue13604@psf.upfronthosting.co.za>
Message-ID: <1363249199.02.0.836073791771.issue13604@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

What's the status of this?

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

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

From report at bugs.python.org  Thu Mar 14 10:41:24 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 09:41:24 +0000
Subject: [docs] [issue17415] Documentation Ambiguity 1
Message-ID: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

This is the first time I am creating an issue. I may be doing something wrong. I will correct that if you make me aware about it!

Issue with documentation:
Documentation page: http://docs.python.org/3/library/os.path.html
Entry: os.path.normpath(path)
Contention line: "It should be understood that this may change the meaning of the path if it contains symbolic links!"

Ambiguity Source: Contention line immediately follows the line "On Windows, it converts forward slashes to backward slashes." relating contention line to also windows.

Ambiguity: "I think" (i.e. I do not know for sure) that, the contention line should apply to all OS, not just windows. for example, .. after a symlink should, according to me, remove the symlink itself by the normpath function. This would be an incorrect behaviour of the normpath (I consider that incorrect). Hence, should be documented for all OS.

----------
assignee: docs at python
components: Documentation
messages: 184152
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Ambiguity 1
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 10:43:01 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 09:43:01 +0000
Subject: [docs] [issue17416] Documentation Ambiguity 2
Message-ID: <1363254181.3.0.0190813002191.issue17416@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Source page: http://docs.python.org/3/library/os.html
Entry: os.walk(...)

Ambiguity Source: Name of the argument TopDown and / or its description.

The TopDown name is misleading to me. I would suggest BFS or DFS instead. TopDown false would imply to me that the traversal would run bottom up "from" the directory mentioned in the argument list (even though the name of that argument is top, it is confusing indicating a possibility of another naming mistake instead!)

----------
assignee: docs at python
components: Documentation
messages: 184153
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Ambiguity 2
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 11:11:35 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 10:11:35 +0000
Subject: [docs] [issue17417] Documentation Modification Suggestion: os.walk,
	fwalk
Message-ID: <1363255895.31.0.587082771834.issue17417@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Source page: http://docs.python.org/3/library/os.html
Entry: os.walk(...), os.fwalk()

These functions seems to be a generator functions. An expert like yourself may have no trouble to make this out. But for novice (or for people out of touch) like myself would have preferred a starting line of this function as "A generator function that generates file names.... ", rather than currently "Generates file names...."

----------
assignee: docs at python
components: Documentation
messages: 184155
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Modification Suggestion: os.walk, fwalk
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 13:28:46 2013
From: report at bugs.python.org (Anuj Gupta)
Date: Thu, 14 Mar 2013 12:28:46 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <1363264126.62.0.417833866836.issue17414@psf.upfronthosting.co.za>


Anuj Gupta added the comment:

I'm a new contributor so, not sure if I'm missing anything:

The issue seems straightforward to me, the exports should definitely be included in both - the docstring and __all__. Also, default_timer is documented and should be imported as well.

I've contributed a patch for the dev version. After a review, I can submit patches for all remaining versions.

Thanks!

----------
keywords: +patch
nosy: +anuj
Added file: http://bugs.python.org/file29407/timeit_exports.diff

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

From report at bugs.python.org  Thu Mar 14 15:37:43 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Mar 2013 14:37:43 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363271863.26.0.410439089526.issue13918@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I agree with "won't fix" for the original issue. These locale functions
are in effect superseded by PEP 3101 formatting.

For decimal locale specific formatting, use:

format(Decimal("1729.1415927"), "n")


IOW, I don't think new formatting functions should be added to the
locale module.

----------
status: open -> closed

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

From report at bugs.python.org  Thu Mar 14 16:02:41 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Thu, 14 Mar 2013 15:02:41 +0000
Subject: [docs] [issue17418] Documentation Bug
Message-ID: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>


New submission from Gurmeet Singh:

Incompletely explained documentation at 2 places:

1. http://docs.python.org/3/library/functions.html#open

The buffering argument is not correctly explained when setting to a positive argument in binary mode.

2. http://docs.python.org/3/library/os.html#os.open

It is not very clear where to find descriptions of the arguments of this function. Where to find the required information and where to find C run-time documentation could be explained in following preferably:
(Python/C API Reference Manual) http://docs.python.org/3/c-api/index.html and / or 
(The Python Standard Library) http://docs.python.org/3/library and  / or 
(Python Runtime Services) http://docs.python.org/3/library/python.html 

A hyperlink may be added if so felt.

----------
assignee: docs at python
components: Documentation
messages: 184166
nosy: docs at python, gsingh
priority: normal
severity: normal
status: open
title: Documentation Bug
versions: Python 3.3

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

From report at bugs.python.org  Thu Mar 14 16:05:41 2013
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Thu, 14 Mar 2013 15:05:41 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363273541.36.0.489088601072.issue13918@psf.upfronthosting.co.za>


C?dric Krier added the comment:

locale.atof is not about formatting but parsing string into float following the locale.
For now, the only ways I see to parse a string to get a Decimal is to first convert it into float (which is not good if precision matters) or to use the undocumented parameter.

----------
status: closed -> open

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

From report at bugs.python.org  Thu Mar 14 16:44:12 2013
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 14 Mar 2013 15:44:12 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1363273541.36.0.489088601072.issue13918@psf.upfronthosting.co.za>
Message-ID: <20130314154414.GA435@sleipnir.bytereef.org>


Stefan Krah added the comment:

C?dric Krier <report at bugs.python.org> wrote:
> locale.atof is not about formatting but parsing string into float following the locale.

You're right. Sorry, I never use these locale functions. My impression is
that locales are often buggy or differ across platforms (see #16944).

So actually I now agree that making the parameter official is one reasonable
solution.

----------

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

From report at bugs.python.org  Thu Mar 14 21:33:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 14 Mar 2013 20:33:35 +0000
Subject: [docs] [issue17422] language reference should specify restrictions
	on class	namespace
Message-ID: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>


New submission from Eric Snow:

(related to PEP 422 and issue #17044)

The execution namespace from a class definition is passed as the third argument to the metaclass (see builtin___build_class__() in Python/bltinmodule.c).  When applicable, which is almost always, the subsequent call to type.__new__() copies that namespace into a new dict which is in turn exposed via the class's __dict__.

This matters in the case where a metaclass with __prepare__() gets used (or the PEP 422 equivalent).  The language reference[1] should note that the object returned by __prepare__() is copied into a new dict when the class is finally created via the metaclass.

[1] http://docs.python.org/3.4/reference/datamodel.html#customizing-class-creation

----------
assignee: docs at python
components: Documentation
messages: 184188
nosy: docs at python, eric.snow, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: language reference should specify restrictions on class namespace
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Thu Mar 14 22:56:42 2013
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 14 Mar 2013 21:56:42 +0000
Subject: [docs] [issue17422] language reference should specify restrictions
	on class	namespace
In-Reply-To: <1363293215.19.0.289288553848.issue17422@psf.upfronthosting.co.za>
Message-ID: <1363298202.69.0.363219986616.issue17422@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

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

From report at bugs.python.org  Thu Mar 14 23:06:11 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Mar 2013 22:06:11 +0000
Subject: [docs] [issue16471] upgrade to sphinx 1.1
In-Reply-To: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>
Message-ID: <1363298771.33.0.7526225274.issue16471@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

When this is done make.bat should be updated too.

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

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

From report at bugs.python.org  Fri Mar 15 02:10:23 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 01:10:23 +0000
Subject: [docs] [issue16471] upgrade to sphinx 1.1
In-Reply-To: <1352888870.05.0.523269386726.issue16471@psf.upfronthosting.co.za>
Message-ID: <1363309823.58.0.118658397656.issue16471@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This duplicates a part of #10224, which proposes to upgrade all of Sphinx, Jinja2, and Pygments to Python 3 compatible versions (so we can build docs with Py3). In msg175768, Brett claims that all three have such versions.

Chris, if you want to push to only upgrade Sphinx and not the other two, you can re-open. But I'd like to see a justification as I suspect that upgrading the other two will, if anything, be easier (assuming no breakage of current usage).

----------
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Build 3.x documentation using python3.x

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

From report at bugs.python.org  Fri Mar 15 02:39:19 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 01:39:19 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <1363311559.39.0.0486775496138.issue17414@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As long as we are editing the module docstring, the last sentence should be deleted in 3.x patches, and the preceding sentence added to the preceding paragraph.

In 3.3+, the paragraph beginning "The difference in default timer function" is obsolete and should be removed.

Anuj, I believe patch is correct for 2.7, so I do not think more patch versions are needed now.

I see the __all__ change as both behavior fix and enhancement, so I don't know whether there should be one fix or four. I posted "Matching __all__ to doc: bugfix or enhancement?" on pydev to see what other think.

(Reminder to self: remove old code to handle absence of itertools from stdlib. This will break the current patch.)

----------

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

From report at bugs.python.org  Fri Mar 15 07:22:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Mar 2013 06:22:55 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363328575.61.0.847876841839.issue17415@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> I will correct that if you make me aware about it!

Try to use meaningful titles, e.g. "Clarify docs of os.path.normpath()".  See http://docs.python.org/devguide/triaging.html for more informations.

Also if you could provide patches that would be even better.  The devguide explains how to make patches.


For this issue it might be enough to simply swap the two sentences.

----------
keywords: +easy
nosy: +ezio.melotti, terry.reedy
stage:  -> needs patch
title: Documentation Ambiguity 1 -> Clarify docs of os.path.normpath()
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Fri Mar 15 08:04:44 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Mar 2013 07:04:44 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <3ZRyTR30cqzRvB@mail.python.org>


Roundup Robot added the comment:

New changeset dda8a6b8a351 by Terry Jan Reedy in branch 'default':
Issue #17414: Add timeit, repeat, and default_timer to timeit.__all__.
http://hg.python.org/cpython/rev/dda8a6b8a351

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

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

From report at bugs.python.org  Fri Mar 15 08:09:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 07:09:02 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <1363331342.82.0.925028015093.issue17414@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Fred Drake, Eli Bendersky, and in particular, Guido ("I do see that it shouldn't be backported, but I don't see any worries about doing it in 3.4.") said that this is a 3.4-only enhancement.

Anuj, ACKS are alphabetical. ?strand is at the end because that is where ? sorts. Thanks for the patch. We hope to see more.

----------
versions:  -Python 2.6, Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Mar 15 08:10:41 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 07:10:41 +0000
Subject: [docs] [issue17414] timeit.timeit not in __all__ even though
	documented
In-Reply-To: <1363248890.42.0.978472113669.issue17414@psf.upfronthosting.co.za>
Message-ID: <1363331441.12.0.628972751703.issue17414@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 15 08:23:55 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 07:23:55 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363332235.08.0.797891071762.issue17415@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The question is what is the 'this' that may change the patch meaning. It does not seem to me that changing '/' to '\' would do that. So I suspect 'this' refers to 'collapsing'. If so, I suggest the entry be:

    Normalize a pathname (but not the case -- use normcase for that). This collapses redundant separators and up-level references so that A//B, A/B/, A/./B and A/foo/../B all become A/B. This collapsing may change the meaning of the path if it contains symbolic links!  On Windows, normpath also converts forward slashes to backward slashes.

----------
nosy: +loewis, pitrou

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

From report at bugs.python.org  Fri Mar 15 08:42:12 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Mar 2013 07:42:12 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <3ZRzJh16JYzRrw@mail.python.org>


Roundup Robot added the comment:

New changeset 4b28a6a3eda6 by Terry Jan Reedy in branch '3.2':
Issue #17047: Add news entry
http://hg.python.org/cpython/rev/4b28a6a3eda6

New changeset 937989570b42 by Terry Jan Reedy in branch '3.3':
Merge with 3.2: issue #17047 news entry
http://hg.python.org/cpython/rev/937989570b42

New changeset f0a3c2006adb by Terry Jan Reedy in branch 'default':
Merge with 3.2: closes issue #17047
http://hg.python.org/cpython/rev/f0a3c2006adb

----------

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

From report at bugs.python.org  Fri Mar 15 08:43:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 07:43:33 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363333413.05.0.657681971385.issue17047@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 15 08:44:11 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 07:44:11 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1363333451.79.0.162843384987.issue17047@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 15 10:46:35 2013
From: report at bugs.python.org (=?utf-8?q?C=C3=A9dric_Krier?=)
Date: Fri, 15 Mar 2013 09:46:35 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363340795.58.0.76922386695.issue13918@psf.upfronthosting.co.za>


C?dric Krier added the comment:

Here is a patch for the documentation.

----------
keywords: +patch
resolution: wont fix -> 
Added file: http://bugs.python.org/file29414/doc_atof.patch

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

From report at bugs.python.org  Fri Mar 15 17:53:52 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Mar 2013 16:53:52 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1363366431.61.0.22310923402.issue17386@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Applying the minipatch makes the big patch fail to apply, so here's an update.  Also changed in this version of the patch:

- README.txt is updated.  Not all the changes directly relate to this patch, but there were some needed updates in there anyway.  If desired, I can split those into a separate issue, but all the changes are fairly minor.

- Added *VERSION variables for each of the tools for easy overriding and easier-to-find, single place to update.

Terry, you're right about make.bat being very similar between versions.  About the only other difference I saw was the removal of the line that prints the Python version in use, and the version of Pygments used.  I'd be happy to make patches for backporting this as far as desired (assuming, of course, that it is accepted and is desirable to backport :-).

----------
Added file: http://bugs.python.org/file29417/win_doc_make.v2.diff

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

From report at bugs.python.org  Fri Mar 15 17:58:42 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Mar 2013 16:58:42 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1363366722.06.0.232384643094.issue17386@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file29417/win_doc_make.v2.diff

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

From report at bugs.python.org  Fri Mar 15 17:58:59 2013
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 15 Mar 2013 16:58:59 +0000
Subject: [docs] [issue17386] Bring Doc/make.bat as close to Doc/Makefile as
	possible
In-Reply-To: <1362781994.31.0.121984055749.issue17386@psf.upfronthosting.co.za>
Message-ID: <1363366739.62.0.515928281668.issue17386@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file29418/win_doc_make.v2.diff

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

From report at bugs.python.org  Fri Mar 15 19:43:23 2013
From: report at bugs.python.org (=?utf-8?q?Michael_En=C3=9Flin?=)
Date: Fri, 15 Mar 2013 18:43:23 +0000
Subject: [docs] [issue17337] input() and raw_input() do not work correctly
	with	colored prompts
In-Reply-To: <1362236964.85.0.134127148195.issue17337@psf.upfronthosting.co.za>
Message-ID: <1363373002.96.0.556574376262.issue17337@psf.upfronthosting.co.za>


Michael En?lin added the comment:

Terry, i guess you are right; it is indeed not the job of python to know how its terminal will print characters; there is a whole lot of issues to consider, such as terminal unicode support, control characters, ansi escape sequences, terminal-specific escape sequences such as terminal title, etc.
I guess that on UNIX, a lot of that information could be taken from terminfo, to provide a method that guesses the length of a text on the terminal that is referenced in the $TERM environment variable.

In fact, I think this is a design problem of readline; readline should print the prompt, and then try to determine its length via the dedicated escape sequence (if it really needs to know the prompt length). In that case, there would be no way to fix this in python - apart from re-implementing. In conclusion, no, I don't believe the python readline code should be modified, maybe an additional, os- and $TERM-dependent method for adding prompt escapes should be added.

However, the issue should definitely be documented in the readline documentation:
importing readline _will_ break input() if the prompt contains non-printable characters that are not escaped by '\x01' and '\x02' characters.

Hence I have changed the bug components to 'Documentation'.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Fri Mar 15 21:21:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 20:21:07 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363378867.07.0.810263305354.issue13918@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I find the idea of intentionally not documenting a public parameter and the full signature of a function somewhat strange, especially when it is already automatically partially-documented.

>>> import locale
>>> help(locale.atof)
Help on function atof in module locale:

atof(string, func=<class 'float'>)
    Parses a string as a float according to the locale settings.
# 2.7, 3.2, 3.3

Not documenting the full signature of a function seems to me contrary to proper policy. That aside, the func parameter is, to me, a useful feature, not just an implementation detail

The way to have factored out the common normalization without a func parameter is obvious: define a private normalization function.

def _anormalize(string):
    "remove thousands separators, make decimal dot"
    ts = localeconv()['thousands_sep']
    if ts:
        string = string.replace(ts, '')
    #next, replace the decimal point with a dot
    dd = localeconv()['decimal_point']
    if dd:
        string = string.replace(dd, '.')
    return string

def atof(string):
    "Parses a string as a float according to the locale settings."
    return float(_anormalize(string))

def atoi(string):  # changed from str
    "Converts a string to an integer according to the locale settings."
    return int(_anormalize(string))

But Martin von Loewis, the original author did not do this. I would not assume that he "thought that copying 3 lines from atof into atoi was a bad idea." without asking him.  Whatever his conscious intention, the func parameter *does* have the advantage of allowing alternate float string to number converters.  We now have another one in the stdlib besides decimal.Decimal: fractions.Fractions.

>>> locale.atof('99,999.99', F)
Fraction(9999999, 100)
# versus
>>> F(locale.atof('99,999.99'))
Fraction(6871946986405233, 68719476736)

There are also 3rd party float implementations, such as indefinite precision binary floats. Does anyone still object to properly documenting this useful feature? I am willing to do the commits.

As to the patch and atof docstring, I thinks 'converts' (used in atoi docstring) is better than 'parses'.  So I would change both.

----------
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Mar 15 21:48:38 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 20:48:38 +0000
Subject: [docs] [issue17398] document url argument of RobotFileParser
In-Reply-To: <1363022576.74.0.509640263285.issue17398@psf.upfronthosting.co.za>
Message-ID: <1363380518.46.0.367615863245.issue17398@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Mar 15 21:52:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Mar 2013 20:52:03 +0000
Subject: [docs] [issue17398] document url argument of RobotFileParser
In-Reply-To: <1363022576.74.0.509640263285.issue17398@psf.upfronthosting.co.za>
Message-ID: <3ZSJr23PX0zS8R@mail.python.org>


Roundup Robot added the comment:

New changeset 274e68e2a5a6 by Terry Jan Reedy in branch '2.7':
Issue #17398: document url argument of RobotFileParser
http://hg.python.org/cpython/rev/274e68e2a5a6

New changeset 4be7f8da7adf by Terry Jan Reedy in branch '3.2':
Issue #17398: document url argument of RobotFileParser
http://hg.python.org/cpython/rev/4be7f8da7adf

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

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

From report at bugs.python.org  Fri Mar 15 21:53:48 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 20:53:48 +0000
Subject: [docs] [issue17398] document url argument of RobotFileParser
In-Reply-To: <1363022576.74.0.509640263285.issue17398@psf.upfronthosting.co.za>
Message-ID: <1363380828.54.0.680491059194.issue17398@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Agreed.

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

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

From report at bugs.python.org  Fri Mar 15 21:59:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 20:59:42 +0000
Subject: [docs] [issue17337] input() and raw_input() do not work correctly
	with	colored prompts
In-Reply-To: <1362236964.85.0.134127148195.issue17337@psf.upfronthosting.co.za>
Message-ID: <1363381182.55.0.444318215001.issue17337@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Please suggest the specific change in a specific place that you would like to see. Message is ok, patch even better.

----------

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

From report at bugs.python.org  Fri Mar 15 23:05:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 22:05:26 +0000
Subject: [docs] [issue17416] Clarify docs of os.walk()
In-Reply-To: <1363254181.3.0.0190813002191.issue17416@psf.upfronthosting.co.za>
Message-ID: <1363385126.0.0.991731409566.issue17416@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The unambiguous title of your first report was better, so I copied it with a new method name.

Changing a parameter name will break code, so it is essentially never done. In any case, directory trees are considered to grow 'down' from the root directory, and tree walkers recurse 'down' to leaves, even though biological trees usually grow 'up'. You just have to get used to the standard inverted metaphor.

I read the doc entry and I do not see any need to change, so I am closing this.

----------
nosy: +terry.reedy
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed
title: Documentation Ambiguity 2 -> Clarify docs of os.walk()

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

From report at bugs.python.org  Fri Mar 15 23:18:40 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 22:18:40 +0000
Subject: [docs] [issue17417] Documentation Modification Suggestion: os.walk,
	fwalk
In-Reply-To: <1363255895.31.0.587082771834.issue17417@psf.upfronthosting.co.za>
Message-ID: <1363385920.94.0.658861916985.issue17417@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Our standard is to start function doc entries with verbs. In any case, it is irrelevant whether os.walk is a generator function or iterator class. Which is to say, it is not part of the language definition that the object returned by os.walk() is specifically a generator, as opposed to an instance of some other iterator class. Indeed, other implementations might do differently and if we decided to recode os.walk in C to make it faster, it would be an iterator class and not a generator function (which are only written in Python). So 'generate' is being used in a generic sense. 

Ideas like this, and the one about changing 'topdown', would be better floated on python-list.

----------
nosy: +terry.reedy
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Mar 16 00:05:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2013 23:05:33 +0000
Subject: [docs] [issue17418] Documentation for os.open and io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <1363388733.26.0.323692053478.issue17418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is really two issues:

io.open: Your statement about *buffering* not correct is not helpful. Quote the sentence you think is wrong. I am guessing it is "Pass ... an integer > 1 to indicate the size of a fixed-size chunk buffer". Then quote some code from the module or code that uses the module that acts differently from the doc. Then suggest an alternative wording supported by the evidence presented.

os.open:
For *flags*, there already is a link to
http://docs.python.org/3/library/os.html#open-flag-constants
That says "consult the open(2) manual page on Unix or the MSDN on Windows."

I believe mode is ignored on Windows. (Martin, true?)
Any Unix system should document the various bits, but we could say where, as with flags (open(2) also)?

I agree that "see the C run-time documentation" (for flags and mode) is pretty useless as is. This must refer to the C-API manual.  If you can find a specific link for info about flags or mode, it can be added. I do not see anything in the index. It is possible that the sentence is obsolete and should be deleted.

Do note that the note "This function is intended for low-level I/O. For normal usage, use the built-in function open()," strongly implies that one should only use this function with some understanding of the os function that it wraps. This is true for much of the os module.

----------
nosy: +loewis, terry.reedy
stage:  -> needs patch
title: Documentation Bug -> Documentation for os.open and io.open

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

From report at bugs.python.org  Sat Mar 16 02:27:37 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Mar 2013 01:27:37 +0000
Subject: [docs] [issue16057] Subclasses of JSONEncoder should not be
	insturcted to	call JSONEncoder.decode
In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za>
Message-ID: <1363397257.21.0.359928934624.issue16057@psf.upfronthosting.co.za>


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


----------
keywords: +needs review
stage: needs patch -> patch review
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 16 06:04:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Mar 2013 05:04:12 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363410251.99.0.121847421953.issue17415@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Your suggestion -- assuming it's accurate -- looks good to me, however I would get rid of the exclamation mark and move the link to normcase at the end:
"""
Normalize a pathname by collapsing redundant separators and up-level references so that A//B, A/B/, A/./B and A/foo/../B all become A/B. This collapsing may change the meaning of the path if it contains symbolic links.  On Windows, normpath also converts forward slashes to backward slashes.  normpath doesn't normalize the case -- use normcase for that.
"""

----------

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

From report at bugs.python.org  Sat Mar 16 06:16:19 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 16 Mar 2013 05:16:19 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363410978.93.0.0550918690727.issue13918@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The function was introduced by Guido in f5b55311e79d.

I think it would have been better if atof had another name (e.g. _atof) and that atof and atoi were implemented as:

def atof(str):
    return _atof(str, float)
def atoi(str):
    return _atof(str, int)

Even better would have been to have _atof return the string without applying any function, and let e.g. atoi return int(_atof(str)).  This could have been documented publicly and used to build other functions.
However it's probably too late for such refactoring.

----------

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

From report at bugs.python.org  Sat Mar 16 07:29:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Mar 2013 06:29:08 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363415348.73.0.406071973642.issue13918@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The refactoring could be done if we were willing to give the normalize function a public name, so people could write Decimal(delocalize(<localized float string>)) or if we were willing to add atod and atofr (fraction). However, simply adding a few words to the doc is a lot easier.

----------

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

From report at bugs.python.org  Sat Mar 16 11:58:59 2013
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 16 Mar 2013 10:58:59 +0000
Subject: [docs] [issue17437] Difference between open and codecs.open
Message-ID: <1363431539.84.0.0934189958093.issue17437@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In Python 2 the distinction between open() and codes.open() was clear because 'encoding' and 'errors' args were provided by codecs.open only.
This is no longer the case in Python 3 since both args are provided also by open().

I'm probably missing something but regardless I think codecs.open doc [1] should be more clear as to when and why (say) codecs.open(file, encoding='utf8', errors='ignore') should be preferred over open(file, encoding='utf8', errors='ignore').

[1] http://docs.python.org/3/library/codecs.html#codecs.open

----------
assignee: docs at python
components: Documentation
messages: 184303
nosy: docs at python, ezio.melotti, giampaolo.rodola
priority: normal
severity: normal
status: open
title: Difference between open and codecs.open
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 16 12:13:17 2013
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Mar 2013 11:13:17 +0000
Subject: [docs] [issue17437] Difference between open and codecs.open
In-Reply-To: <1363431539.84.0.0934189958093.issue17437@psf.upfronthosting.co.za>
Message-ID: <1363432397.11.0.506325299573.issue17437@psf.upfronthosting.co.za>


STINNER Victor added the comment:

See also the PEP 400. I proposed (in the alternative) to make codecs.open() somehow an alias to open() (and add codecs.open_stream() for "backward compatibility").

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

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

From report at bugs.python.org  Sat Mar 16 13:11:45 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 16 Mar 2013 12:11:45 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
Message-ID: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Strings returned in the object returned from json.load() seem to be always unicode, but it is not documented. Python 2.7

----------
assignee: docs at python
components: Documentation
messages: 184308
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: json.load docs should mention that it always return unicode
versions: Python 2.7

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

From report at bugs.python.org  Sat Mar 16 16:17:58 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 15:17:58 +0000
Subject: [docs] [issue17416] Clarify docs of os.walk()
In-Reply-To: <1363254181.3.0.0190813002191.issue17416@psf.upfronthosting.co.za>
Message-ID: <1363447078.74.0.408568735577.issue17416@psf.upfronthosting.co.za>


Gurmeet Singh added the comment:

Hi Terry,

  I understand it is ok for you. I agree that you are not in favour of changing the argument name. And you are correct that I must get familiar to the convention that has been used. Further since you say, perhaps, I now feel that it may be used in other languages documentation as well.

  But I still seriously 'request' you again to add the word BFS (Breadth First Search) to the "only the documentation" of TopDown = True and "DFS like" for the case of False. If a kid (like me) who reads an algorithms textbook and not familiar with the conventions being followed - 'may' make a mistake and waste time debugging.

----------
resolution: works for me -> 

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

From report at bugs.python.org  Sat Mar 16 17:10:23 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 16:10:23 +0000
Subject: [docs] [issue17418] Documentation for os.open and io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <1363450223.26.0.459137183867.issue17418@psf.upfronthosting.co.za>


Gurmeet Singh added the comment:

Please read the comment completely.

For the first point
___________________
I apologize that there was no mistake in binary mode and I have read it hastily. There is no ambiguity in the binary mode as you said. Reading hastily, I felt '...(only usable in text mode)... applies to all positive values, not just for the case of one. I was wrong there. 

However, text mode buffering description is not clear. Does the positive non unity buffer size value indicates the number of lines or the size in bytes or size of string characters (as per the system encoding) etc. This description could be made clearer (for both the text as well as the binary modes)

I also want to say that buffering is working incorrectly. In fact it is not working at all on windows x86 (I am raising a separate issue for this since that is not a documentation issue). 

For the second point (My answer here is for Windows part only)
____________________
The hyperlink http://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx could be great instead of see C-run time documentation. It explains both "flag" as well as "mode". Actually this is the hyperlink given in the page you mentioned (http://docs.python.org/3/library/os.html#open-flag-constants) - I guess I gave up on this link, since I felt function was largely undocumented and useless.

I really "request" you to mention that C runtime library specification is actually http://msdn.microsoft.com/en-us/library/59ey50w6.aspx - I accidentally found this - there is no simple way (without reading extensively, I guess) to know that Python is actually using Microsoft VC++ at the backend and that the runtime library of that would be of that. So you could mention this on the introductory pages that C-API/Library is actually http://msdn.microsoft.com/en-us/library/59ey50w6.aspx.

_______________________________________________________________
P.S. Please (at least) see my comment on the other documentation ambiguity issue that you have closed already.

----------

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

From report at bugs.python.org  Sat Mar 16 17:38:36 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 16:38:36 +0000
Subject: [docs] [issue17418] Documentation for os.open and io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <1363451916.22.0.0446450658034.issue17418@psf.upfronthosting.co.za>


Gurmeet Singh added the comment:

The issue with buffering problem mentioned in my previous comment has been raised as issue 17440. 
However, I need to apologize again! The statement that buffering is not implemented at all was incorrect - instead read1() was not implemented. See the mentioned issue for more details.

----------

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

From report at bugs.python.org  Sat Mar 16 18:03:43 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 17:03:43 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363453423.47.0.400698136516.issue17415@psf.upfronthosting.co.za>


Gurmeet Singh added the comment:

At the moment, I running late for creating a program - so I apologize that immediately I would not able to work on creating a patch. Later though I may be able to. I am sorry.

To avoid wasted work I think patch should be created only after someone (do not know who though!) has approved of the suggestions.

Thanks for the tips. I will read http://docs.python.org/devguide/triaging.html before posting next - but sorry, that I have posted many issues already without reading your response. 

__________________

You guys have both understood the issues I tried to say. 

The collapsing by '..' kills out sym link without realizing it is symlink - since it does not refer to file system - it is just a string manipulation utility (Again, I cannot commit on this since I have not read the source code or experimented this - it is an educated guess by reading only the docs).

So, I further suggest to add to the description by Ezio Melotti after the line "This collapsing may change the meaning of the path if it contains symbolic links.". We could add the following bracketed line "(since os.path.normpath is just string manipulation utility - unaware of the underlying file system)". This would remove the source of confusion, that we all here have got confused about.

----------

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

From report at bugs.python.org  Sat Mar 16 18:17:22 2013
From: report at bugs.python.org (Gurmeet Singh)
Date: Sat, 16 Mar 2013 17:17:22 +0000
Subject: [docs] [issue17417] Documentation Modification Suggestion: os.walk,
	fwalk
In-Reply-To: <1363255895.31.0.587082771834.issue17417@psf.upfronthosting.co.za>
Message-ID: <1363454242.63.0.187509643861.issue17417@psf.upfronthosting.co.za>


Gurmeet Singh added the comment:

I am sorry to reopen this issue, if you do not like this comment, then I will reopen issues again. 

I am not saying to change the convention of the documentation - I just requested you to say "something" that would indicate that it is function that gives result in multiple calls. Mentioning the "generator" or "iterator" word would help a "novice" (but may not an expert like you) to understand that the object returned by this function needs to be called repeatedly and it does not return a collection of all results.

After reading "... would be better floated on python-list", I do not know if my posting this comment would be termed as bugging?

----------
status: closed -> open

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

From report at bugs.python.org  Sat Mar 16 21:08:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Mar 2013 20:08:47 +0000
Subject: [docs] [issue17418] Documentation for os.open and io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <3ZSvqf4GV8zS5n@mail.python.org>


Roundup Robot added the comment:

New changeset f334a0009586 by Terry Jan Reedy in branch '2.7':
Issue #17418: specify that buffer sizes are bytes.
http://hg.python.org/cpython/rev/f334a0009586

New changeset a9d54ba2370b by Terry Jan Reedy in branch '3.2':
Issue #17418: specify that buffer sizes are bytes as soon as possible.
http://hg.python.org/cpython/rev/a9d54ba2370b

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

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

From report at bugs.python.org  Sat Mar 16 21:14:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Mar 2013 20:14:21 +0000
Subject: [docs] [issue17418] Documentation links for io.open
In-Reply-To: <1363273361.29.0.0702686905061.issue17418@psf.upfronthosting.co.za>
Message-ID: <1363464861.1.0.0408250025273.issue17418@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Most people should know that os i/o buffers are always bytes. But since beginners read the built-in functions page, I augmented the open() entry, which is what you linked to. I will not change the entries in the io module chapter. I consider this part of the issue closed. That leaves the entry for os.open. I changed the title accordingly.

----------
title: Documentation for os.open and io.open -> Documentation links for io.open

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

From report at bugs.python.org  Sat Mar 16 21:39:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Mar 2013 20:39:54 +0000
Subject: [docs] [issue17417] Documentation Modification Suggestion: os.walk,
	fwalk
In-Reply-To: <1363255895.31.0.587082771834.issue17417@psf.upfronthosting.co.za>
Message-ID: <1363466394.42.0.199027607907.issue17417@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Reopening issues closed by a developer is worse than just 'bugging'. It wastes time, distracts from real problems, and if repeated can get your tracker account closed. Don't do it again.

I gave you a suggestion: post on python-list where you can get responses from a variety of people. I read most of the original posts and some of the threads. When discussion indicates to me that there is a real problem, and has perhaps generated a solution, I have often either suggested that the original poster open an issue here or have done so myself.

----------
status: open -> closed

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

From report at bugs.python.org  Sun Mar 17 20:30:57 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Mar 2013 19:30:57 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <3ZTVxX2zJkzRkL@mail.python.org>


Roundup Robot added the comment:

New changeset ff9636af9505 by Terry Jan Reedy in branch '3.2':
Issue #17415: Clarify 'this' referent by moving containing sentence just after
http://hg.python.org/cpython/rev/ff9636af9505

New changeset bceb81b0016e by Terry Jan Reedy in branch '2.7':
Issue #17415: Clarify 'this' referent by moving containing sentence just after
http://hg.python.org/cpython/rev/bceb81b0016e

New changeset 5b5a9bceb228 by Terry Jan Reedy in branch '3.2':
Issue #17415: Trim trailing whitespace
http://hg.python.org/cpython/rev/5b5a9bceb228

New changeset 44b9f59c6ea7 by Terry Jan Reedy in branch '2.7':
Issue #17415: Trim trailing whitespace
http://hg.python.org/cpython/rev/44b9f59c6ea7

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

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

From report at bugs.python.org  Sun Mar 17 20:33:17 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Mar 2013 19:33:17 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363548797.09.0.841546679437.issue17415@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If foo is a symbolic link,  changing A/foo/../B to A/B could change the meaning, so I am sure the rewrite is correct. I used Ezio's version with a few more changes. I particular, I changed 'This collapsing', which is slightly awkward anyway, to 'This string manipulation', which addresses Gurmeet's last comment.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun Mar 17 21:23:44 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Mar 2013 20:23:44 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363551824.81.0.390903765141.issue17415@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

os.path.normpath() works not only with strings but with bytes objects too.

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

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

From report at bugs.python.org  Mon Mar 18 00:03:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Mar 2013 23:03:30 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363561410.11.0.80533581865.issue17415@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The top of the os doc makes it clear that path = byte string or unicode string and I meant 'string' in that generalized sense. I think 'string' is used that way elsewhere in the 3.x docs. I though of 'text manipulation', but as the doc again makes clear, unix byte string paths may not be 'text', which is why byte string paths are needed. That was my thought, anyway.

----------

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

From report at bugs.python.org  Mon Mar 18 00:51:31 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Mar 2013 23:51:31 +0000
Subject: [docs] [issue17416] Clarify docs of os.walk()
In-Reply-To: <1363254181.3.0.0190813002191.issue17416@psf.upfronthosting.co.za>
Message-ID: <1363564291.39.0.0746719704906.issue17416@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I considered your point, re-read the walk entry, and still wish to leave it as it is. First, we are not in the business of providing synonyms for everything. Second, The abbreviations BFS and DFS did not immediately register with me, even though I am quite familiar with the concepts. I expect that many would find them more confusing rather than less. So they would need to be spelled out. There is also the issue of whether the defined topdown behavior is 'exactly' what any particular person would consider 'breadth-first search'. For one thing, walk does not exactly visit leaf-nodes -- it provides a list of them so that the caller can 'visit' them.

Unselecting 'Resolution' amounts to partially reopening an issue. Please don't do that.

----------
resolution:  -> works for me

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

From report at bugs.python.org  Mon Mar 18 03:06:40 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Mar 2013 02:06:40 +0000
Subject: [docs] [issue16057] Subclasses of JSONEncoder should not be
	insturcted to	call JSONEncoder.decode
In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za>
Message-ID: <3ZTgk70nCbzSl5@mail.python.org>


Roundup Robot added the comment:

New changeset 5d56e1214e95 by R David Murray in branch '3.2':
#16057: Clarify why the base method default is called in custom encoders.
http://hg.python.org/cpython/rev/5d56e1214e95

New changeset 5f76e7db97ac by R David Murray in branch '3.3':
Merge #16057: Clarify why the base method default is called in custom encoders.
http://hg.python.org/cpython/rev/5f76e7db97ac

New changeset 406c6fd7e753 by R David Murray in branch 'default':
Merge #16057: Clarify why the base method default is called in custom encoders.
http://hg.python.org/cpython/rev/406c6fd7e753

New changeset ef8ea052bcc4 by R David Murray in branch '2.7':
#16057: Clarify why the base method default is called in custom encoders.
http://hg.python.org/cpython/rev/ef8ea052bcc4

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

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

From report at bugs.python.org  Mon Mar 18 03:40:12 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Mar 2013 02:40:12 +0000
Subject: [docs] [issue16057] Subclasses of JSONEncoder should not be
	insturcted to	call JSONEncoder.decode
In-Reply-To: <1348695643.05.0.172807817425.issue16057@psf.upfronthosting.co.za>
Message-ID: <1363574412.9.0.914007338766.issue16057@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks Kushal.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Mar 18 05:52:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Mar 2013 04:52:02 +0000
Subject: [docs] [issue17415] Clarify docs of os.path.normpath()
In-Reply-To: <1363254084.71.0.566046555071.issue17415@psf.upfronthosting.co.za>
Message-ID: <1363582322.28.0.963605438517.issue17415@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Mar 18 13:26:28 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 18 Mar 2013 12:26:28 +0000
Subject: [docs] [issue16575] ctypes: unions as arguments
In-Reply-To: <1354163044.21.0.431588472559.issue16575@psf.upfronthosting.co.za>
Message-ID: <1363609588.12.0.702509215228.issue16575@psf.upfronthosting.co.za>


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


----------
nosy: +theller

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

From report at bugs.python.org  Mon Mar 18 17:42:28 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Mar 2013 16:42:28 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
Message-ID: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

http://stackoverflow.com/questions/3217673/why-use-argparse-rather-than-optparse

Too many votes. This should be confirmed by the official documentation.

----------
assignee: docs at python
components: Documentation
messages: 184468
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: argparse FAQ: how it is different from optparse

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

From report at bugs.python.org  Mon Mar 18 17:43:50 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 18 Mar 2013 16:43:50 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1363625030.7.0.626490841325.issue17462@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

The patch is welcome

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

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

From report at bugs.python.org  Mon Mar 18 17:47:32 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 18 Mar 2013 16:47:32 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1363625252.46.0.410503039748.issue17462@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Is http://docs.python.org/dev/library/argparse.html#upgrading-optparse-code not enough?

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

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

From report at bugs.python.org  Mon Mar 18 17:54:57 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 18 Mar 2013 16:54:57 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1363625697.6.0.640067349874.issue17462@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

@asvetlov: I still don't have the answer which licence - Academic Free License v2.1 or Apache 2.0 should I choose to license my patches. What is the difference?

Ezio: It explains what you should replace, but doesn't explain why.

----------
versions: +Python 2.7, Python 3.3

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

From report at bugs.python.org  Mon Mar 18 18:35:24 2013
From: report at bugs.python.org (Nick Weinhold)
Date: Mon, 18 Mar 2013 17:35:24 +0000
Subject: [docs] [issue12160] codecs doc: what is StreamCodec?
In-Reply-To: <1306166137.72.0.066960808058.issue12160@psf.upfronthosting.co.za>
Message-ID: <1363628123.98.0.341748336035.issue12160@psf.upfronthosting.co.za>


Nick Weinhold added the comment:

I've noticed that this issue hasn't been looked at in a while, and from looking through the current docucmentation, it looks like this issue still exists. 

I've uploaded a patch with the changes that Marc-Andre mentioned.

----------
nosy: +ncweinhold
Added file: http://bugs.python.org/file29446/codecs_docs.patch

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

From report at bugs.python.org  Tue Mar 19 00:20:20 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Mar 2013 23:20:20 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363648819.98.0.397259103202.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would be great, thanks.

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

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

From report at bugs.python.org  Tue Mar 19 07:45:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Mar 2013 06:45:25 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1363675525.36.0.436059623535.issue17462@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Indeed a paragraph about it could be added at the beginning.

----------
nosy: +bethard
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.2, Python 3.4

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

From report at bugs.python.org  Tue Mar 19 08:17:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 19 Mar 2013 07:17:18 +0000
Subject: [docs] [issue13918] locale.atof documentation is missing func
	argument
In-Reply-To: <1328105541.08.0.458455853203.issue13918@psf.upfronthosting.co.za>
Message-ID: <1363677438.07.0.732090106732.issue13918@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It's easier, but we will be exposing an API that is not too elegant IMHO.  The refactoring could provide a better API, but OTOH it will make it available for 3.4+ only, and it would break backward compatibility if the old API is removed (even though it's not documented, so in theory we could do that).

----------

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

From report at bugs.python.org  Tue Mar 19 20:05:55 2013
From: report at bugs.python.org (Colin Su)
Date: Tue, 19 Mar 2013 19:05:55 +0000
Subject: [docs] [issue1525919] email package quoted printable behaviour
	changed
Message-ID: <1363719955.95.0.658245524554.issue1525919@psf.upfronthosting.co.za>


Changes by Colin Su <littleq0903 at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), email
nosy: +docs at python

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

From report at bugs.python.org  Tue Mar 19 22:43:00 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Mar 2013 21:43:00 +0000
Subject: [docs] [issue1525919] email package quoted printable behaviour
	changed
Message-ID: <1363729380.2.0.77352434284.issue1525919@psf.upfronthosting.co.za>


R. David Murray added the comment:

Reviewing this again, it seems to me that there are two separate issues reported here: (1) set_payload on an existing MIMEText object no longer encodes (but it has now been a long time since it changed). (2) the functions in the encodings module, given an already encoded message, double encode.

(1) is now set in stone.  That is, it is documented as working this way implicitly if you read the set_payload and set_charset docs and has been working that way for a while now.  An explicit note should be added to the MIMEText docs, with a workaround.)

(2) could be fixed, I think, since it is unlikely that anyone would be depending on such behavior.

----------
components: +Library (Lib), email

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

From report at bugs.python.org  Tue Mar 19 23:22:03 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Mar 2013 22:22:03 +0000
Subject: [docs] [issue1525919] email package quoted printable behaviour
	changed
Message-ID: <3ZVpf21zpSzPPY@mail.python.org>


Roundup Robot added the comment:

New changeset ba500b179c3a by R David Murray in branch '3.2':
#1525919: Document MIMEText+set_payload encoding behavior.
http://hg.python.org/cpython/rev/ba500b179c3a

New changeset fcbc28ef96a3 by R David Murray in branch '3.3':
Merge: #1525919: Document MIMEText+set_payload encoding behavior.
http://hg.python.org/cpython/rev/fcbc28ef96a3

New changeset b9e07f20832e by R David Murray in branch 'default':
Merge: #1525919: Document MIMEText+set_payload encoding behavior.
http://hg.python.org/cpython/rev/b9e07f20832e

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

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

From report at bugs.python.org  Tue Mar 19 23:47:33 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Mar 2013 22:47:33 +0000
Subject: [docs] [issue1525919] email package quoted printable behaviour
	changed
Message-ID: <1363733253.47.0.574692562426.issue1525919@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've committed the doc change.  I'm going to be lazy and leave this issue open to deal with the encodings module fix.

----------

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

From report at bugs.python.org  Tue Mar 19 23:48:10 2013
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Mar 2013 22:48:10 +0000
Subject: [docs] [issue1525919] email package content-transfer-encoding
	behaviour	changed
Message-ID: <1363733290.77.0.359756437445.issue1525919@psf.upfronthosting.co.za>


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


----------
title: email package quoted printable behaviour changed -> email package content-transfer-encoding behaviour changed

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

From report at bugs.python.org  Wed Mar 20 07:37:07 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Mar 2013 06:37:07 +0000
Subject: [docs] [issue17285] subprocess.check_output incorrectly state that
	output is	always bytes
In-Reply-To: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>
Message-ID: <3ZW1dG4ZPnzR93@mail.python.org>


Roundup Robot added the comment:

New changeset f4accfad1bf6 by Gregory P. Smith in branch '3.3':
clarifiy the documentation for issue17285. see also commit
http://hg.python.org/cpython/rev/f4accfad1bf6

New changeset d31cab1dabae by Gregory P. Smith in branch 'default':
clarifiy the documentation for issue17285. see also commit
http://hg.python.org/cpython/rev/d31cab1dabae

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

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

From report at bugs.python.org  Wed Mar 20 07:38:08 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 20 Mar 2013 06:38:08 +0000
Subject: [docs] [issue17285] subprocess.check_output incorrectly state that
	output is	always bytes
In-Reply-To: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>
Message-ID: <1363761488.51.0.977718103456.issue17285@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Wed Mar 20 10:45:43 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 20 Mar 2013 09:45:43 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1363772743.69.0.177196188056.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

Hi

Since this is a duplicate of #17375, is the patch not going to make to the review stage at all?

----------

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

From report at bugs.python.org  Wed Mar 20 13:13:39 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 20 Mar 2013 12:13:39 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1363781619.48.0.402162084473.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

moijes12, since Raymond went ahead and committed a patch to 2.7 in #17375, I think patches to other versions should also be based on his patch. The most constructive thing you can do at this point is review his changes in 2.7 and help porting them to 3.x. Also, you can see if anything is missing/wrong since you've gained some experience about the module while writing the docstrings.

I'm sorry it went like that; don't take it personally - open-source development is a bazaar :-)

----------

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

From report at bugs.python.org  Wed Mar 20 14:55:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Mar 2013 13:55:13 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1363787713.43.0.743970343353.issue17329@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Now I get what you were trying to do.
What I don't like is that now the patch splits the section about skipping in two separate parts, while it would be better to keep it together IMHO.
You argument about having the "theory" first and the actual API later makes sense, and it's somewhat mirrored by e.g. the "basic example" section and the detailed API about TestCase and the assert methods later.
If we keep the two parts together we are left with two options:
1) add SkipTest to the existing section as I suggested initially;
2) move the whole section down below where the API is described;

1) it's simpler and it's enough IMHO, but if 2) is better I think it would be better to move it after the "deprecated aliases" section.

Michael, do you have any preference?

----------

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

From report at bugs.python.org  Wed Mar 20 17:28:29 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 20 Mar 2013 16:28:29 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
Message-ID: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

If stack is saved in list and printed to the screen, it will be printed as:
[
  root,
  second,
  last
]

And the last elements is the bottom element. The documentation at http://docs.python.org/3/reference/datamodel.html#frame-objects refers "bottom element" to be the first one. That's confusing. It is better to avoid top/bottom and use first/last or root/terminal.

----------
assignee: docs at python
components: Documentation
messages: 184771
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: References to stack bottom are confusing
versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Mar 20 22:49:13 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2013 21:49:13 +0000
Subject: [docs] [issue15013] smtplib: add low-level APIs to doc?
In-Reply-To: <1338968663.18.0.754320203153.issue15013@psf.upfronthosting.co.za>
Message-ID: <1363816153.46.0.919369956059.issue15013@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

By current standards, we normally document all public methods. 

.rset() and .noop() are trivial, "same as .docmd('funcname')"

.help() is almost trivial, just removing the first field of the reply (I assume a return code). 'returns message part of .putcmd('help')"

.mail(s, options) and .rcpt(r, options) are not so trivial. Explaining the possible options, I presume defined in the rfcs and used elsewhere by other methods, seems beyond the scope of the docs. "Open mail session; for *options* list, see RFCs" might be a possible entry.

.data(msg) also seems complicated in its details. I can see why the author left out such minutia for something that normally should not be called. I would be inclined to just say "Send message to server; see docstring for details."

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

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

From report at bugs.python.org  Thu Mar 21 04:17:13 2013
From: report at bugs.python.org (Cherniavsky Beni)
Date: Thu, 21 Mar 2013 03:17:13 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363835832.43.0.888631080101.issue10224@psf.upfronthosting.co.za>


Cherniavsky Beni added the comment:

After a lot of experimentation, this worked for me to build AND doctest using the local python:

cd Doc/
../python -m venv toolsenv
curl http://python-distribute.org/distribute_setup.py | toolsenv/bin/python
toolsenv/bin/easy_install pip
toolsenv/bin/pip install Sphinx
# EDIT conf.py: add 'toolsenv' to exclude_trees.
toolsenv/bin/sphinx-build -b html -d build/doctrees -D latex_paper_size=  . build/html
toolsenv/bin/sphinx-build -b doctest -d build/doctrees . build/doctest

The tool versions I got:

$ toolsenv/bin/pip list
distribute (0.6.35)
docutils (0.10)
Jinja2 (2.6)
Pygments (1.6)
Sphinx (1.1.3)

HTML: http://dl.dropbox.com/u/132894668/python3-Doc-build/html/index.html
The HTML has no significant differences vs the output of "make html".
It's mostly sphinx html tweaks.  The only user-visible diff I noticed is s/v3.4.0a0/3.4.0a0/.

The doctests are pretty horrible - 559 failed out of 1954!  (attached)
But it's better than 900+ failed with python 2 ("make doctest") and 700+ with python 3.2 that I originally tried via "apt-get install python3-sphinx"...

So let's update the tools ASAP, and start using PYTHON=../python.
The doctests won't get any love unless "make doctest" does the right thing out of the box.

Should I write a Makefile patch using the venv/install from pypi approach?
Or could somebody upload new versions to http://svn.python.org/projects/external/?
(Lack of access there was the reason I went the venv way.
IMHO the ease of future upgrades outweighs the concern of not depending on external sites, but I don't feel strongly about it.)

----------
nosy: +cben
Added file: http://bugs.python.org/file29525/output.txt

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

From report at bugs.python.org  Thu Mar 21 07:20:08 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Mar 2013 06:20:08 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363846808.4.0.825882508285.issue17494@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sorry, I find your suggested termini more confusing.

* first/last: the first that was put onto the stack (i.e. bottom) or the first to be popped off (i.e. top)?

* root/terminal: that makes you think of trees, but a stack is not a tree.

top/bottom is the established wording for referring to a stack's positions, and its internal representation as a list is secondary.

----------
nosy: +georg.brandl
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Thu Mar 21 15:36:01 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Mar 2013 14:36:01 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363876561.09.0.724332379678.issue10224@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Should I write a Makefile patch using the venv/install from pypi approach?
> Or could somebody upload new versions to http://svn.python.org/projects/external/?

I looked at this issue over the past few days and discussed briefly with Georg about it.  The 3 main issues are:
  1) Sphinx and its dependency have a 2to3-able source that needs to be converted to Python 3 before being used.  Should this be done every time or should we provide the already converted source somewhere?
  2) If we go for the latter, should it be on externals/ (which still uses SVN) or on a new hg repo?
  3) since we don't actually need all the history, should we still just clone these repos or is it better to download the source only?

IMHO for 1) it would be better to provide Python3-ready code.  For 2) it would also be nice to get rid of the SVN dependency for the docs so if we are going to use a repo it might be better to make a new one on HG.  For 3), I'm not sure it makes sense to use repos at all if we don't want the history.  If we don't, we would have to put the files somewhere and write some code to download and extract the zip/tarball.  OTOH, if we do, we will be able to use hg to clone and update the repo easily, and, if we still decide not to download the history, we can just use the zip/tarballs already provided by hg.python.org.

----------

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

From report at bugs.python.org  Thu Mar 21 16:13:23 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Mar 2013 15:13:23 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363878803.64.0.49539359011.issue10224@psf.upfronthosting.co.za>


Georg Brandl added the comment:

A problem with using automatic tarballs from hg.python.org is that they take server load to generate, every time someone builds the docs from a new checkout.

----------

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

From report at bugs.python.org  Thu Mar 21 16:44:13 2013
From: report at bugs.python.org (Paul Price)
Date: Thu, 21 Mar 2013 15:44:13 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363880653.58.0.684950697536.issue17409@psf.upfronthosting.co.za>


Paul Price added the comment:

Not sure how you want patches formatted, so I went for 'git format-patch'.

Also, this is my first attempt at writing ReST and my first attempt at writing docs for Python, so you may want to double-check I didn't screw up the syntax or style.  Hopefully this doesn't cause more work than writing it yourself....

----------
keywords: +patch
Added file: http://bugs.python.org/file29530/0001-Docs-clarify-use-of-1-for-resource.setrlimit-Issue17.patch

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

From report at bugs.python.org  Thu Mar 21 16:47:12 2013
From: report at bugs.python.org (Paul Price)
Date: Thu, 21 Mar 2013 15:47:12 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363880832.47.0.829088481794.issue17409@psf.upfronthosting.co.za>


Paul Price added the comment:

P.S. This is relative to the 'default' branch in the public cpython.

----------

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

From report at bugs.python.org  Thu Mar 21 17:11:44 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Mar 2013 16:11:44 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363882304.21.0.610169125052.issue17494@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

stack = []
stack.append(item)
stack.append(item)
stack.append(item)

This is an appropriate explanation of the stack in Python, the first frame is the frame that was put in first.


root/terminal - if you know what a stack is, you won't confuse it with a tree, if you don't - then in my opinion your top/bottom terminology won't help to gain understanding. root/terminal removes the ambiguity.


right/left is also a good alternative. Nobody imagines a stack growing right to left.

----------
resolution: rejected -> remind
status: closed -> pending

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

From report at bugs.python.org  Thu Mar 21 17:26:03 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Mar 2013 16:26:03 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363883163.64.0.645039544554.issue17494@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Using "first" makes some sense, since it's talking about "previous", but I agree it might be confused with the top frame too.  What about this wording then:
-f_back is to the previous stack frame (towards the caller),
-or None if this is the bottom stack frame;
+f_back is to the previous stack frame (towards the caller),
+or None if this is the first frame at the bottom of the stack;

----------
nosy: +ezio.melotti
status: pending -> open

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

From report at bugs.python.org  Thu Mar 21 17:30:49 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Mar 2013 16:30:49 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363883449.74.0.600316557205.issue10224@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Apparently they are cached, and unless the cache expires often, the server doesn't need to regenerate the tarball too often.  However I don't know the details of the caching, and if they can be tweaked.

----------

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

From report at bugs.python.org  Thu Mar 21 17:45:56 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Mar 2013 16:45:56 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363884356.75.0.4909089528.issue17494@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

+or None if this is the first frame (at the bottom of the stack);

I'd avoid top/bottom altogether, but if it is what is needed to reach the consensus then I am fine with that.

----------

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

From report at bugs.python.org  Thu Mar 21 17:48:04 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 16:48:04 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363884484.72.0.181975447664.issue10224@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Mar 21 18:11:52 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 21 Mar 2013 17:11:52 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363885912.87.0.846658510217.issue17494@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Top/bottom is accepted and understood nomenclature when talking about stacks. Think about a stack of plates in the kitchen. You put a new plate on top, you take it out from top. That's it.

Now, lists are just one way to implement stacks, and printing them is also inconclusive in direction. Therefore I don't think we should mix the implementation/definition here and keep top/bottom.

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

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

From report at bugs.python.org  Thu Mar 21 18:23:20 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Mar 2013 17:23:20 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363886600.01.0.314808622238.issue17494@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

It appeared that I always thought that stacks grow down towards the end of memory, but it appears that they are growing down towards the beginning (x86 and friends). Spent some years with assembly to miss that. A shame on me. =)

Even if title of the issue is still true, it is no more actual. I am closing this. Thanks for support.

----------
resolution: remind -> works for me
status: open -> closed

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

From report at bugs.python.org  Thu Mar 21 18:29:16 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 21 Mar 2013 17:29:16 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363886956.47.0.227347731179.issue17494@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I actually find the growth direction confusing sometimes for the same reasons (too much x86 assembly). This is why I wrote this blog post a while back - mainly so I can always look at it and de-confuse myself: http://eli.thegreenplace.net/2011/02/04/where-the-top-of-the-stack-is-on-x86/

----------

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

From report at bugs.python.org  Thu Mar 21 18:29:56 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Mar 2013 17:29:56 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363886995.95.0.317404396991.issue10224@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Ok, that sounds good then.

BTW, for 3.3+ would it make sense instead to create a virtualenv and directly install the required versions from pypi?

----------

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

From report at bugs.python.org  Thu Mar 21 18:38:24 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 21 Mar 2013 17:38:24 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1363887504.43.0.503068418164.issue10224@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I guess if we are willing to write a mini-pip to download the latest release directly from PyPI we could. Since there are no C extensions we don't have to care about the lack of header files in Include if we are going to build from the repo build directly. Or are you more thinking that we just require 3.3 externally to build and not rely on the repo build unless absolutely necessary? Just wondering about when the venv environment copies instead of symlinks the binary.

----------

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

From report at bugs.python.org  Thu Mar 21 19:41:46 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 18:41:46 +0000
Subject: [docs] [issue17505] email.header.Header.__unicode__ does not decode
	header
In-Reply-To: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>
Message-ID: <1363891306.58.0.54271627326.issue17505@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree that this is not the worlds best API.  However, it is the API that we have in 2.7/3.2, and we can't change how Header.__unicode__ behaves without breaking backward compatibility.  

What we could do is add an example of how to use this API to get unicode strings to the top of the docs:

   >>>  unicode(make_header(decode_header('=?gb2312?b?1eLKx9bQzsSy4srUo6E=?=')))
   u'\u8fd9\u662f\u4e2d\u6587\u6d4b\u8bd5\uff01'

But you already know about that.

In Python 3.3 you get this:

   >>> msg = message_from_string("subject: =?gb2312?b?1eLKx9bQzsSy4srUo6E=?=\n\n", policy=default)
   >>> msg['subject']
   '???????'

So, I'll make this a doc bug.

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

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

From report at bugs.python.org  Thu Mar 21 19:49:17 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 18:49:17 +0000
Subject: [docs] [issue17505] email.header.Header.__unicode__ does not decode
	header
In-Reply-To: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>
Message-ID: <1363891757.27.0.391438735931.issue17505@psf.upfronthosting.co.za>


R. David Murray added the comment:

Erg, somehow I failed to read the second half of your message before writing mine...clearly you *didn't* know about that idiom, so the doc patch is obviously an important thing to do.

To clarify about the 3.3 example: the policy=default is key, it tells the email package to use the new (currently provisional) policy code to provide improved handling of header decoding and encoding.

----------

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

From report at bugs.python.org  Thu Mar 21 19:57:16 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Mar 2013 18:57:16 +0000
Subject: [docs] [issue17494] References to stack bottom are confusing
In-Reply-To: <1363796909.72.0.754685300638.issue17494@psf.upfronthosting.co.za>
Message-ID: <1363892236.62.0.812858449637.issue17494@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

@eli.bendersky: The article is awesome. One of the cases when I regret that many interesting Python posts don't have a +1 button. One more chapter about C stack overflow and it will get all top hits. ;)

----------

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

From report at bugs.python.org  Thu Mar 21 20:35:07 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Mar 2013 19:35:07 +0000
Subject: [docs] [issue17383] Possibly ambiguous phrasing
	in	tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1363894507.88.0.656163043088.issue17383@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I was not disagreeing that there was an ambiguity, just trying to explain why some people would understand the text in a different way that what it meant.

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

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

From report at bugs.python.org  Thu Mar 21 21:15:09 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 20:15:09 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363896909.61.0.639205248889.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the patch.  You got the patch mechanics correct.

I did a little experimenting, and at least on my linux box, the exception is raised for any(*) resource whose hard limit is not unlimited.  I'm attaching a revised patch that expresses this.  Do you think this provides sufficient clarification?

One question I have relates to the use of the word 'infinite'.  In the shell, the term 'unlimited' is used, so I'm thinking that's what most people will be familiar with.  On the other hand, the man page for the syscall we are wrapping uses the term 'infinite', so one can argue that it is more correct.  I'm ambivalent about which term to use.

(*) I tested this on NO_PROC, since that's the only other one my shell has a hard limit for, and by setting a hard limit via the shell ulimit command and then using (-1, -1) in the setrlimit call.

----------
Added file: http://bugs.python.org/file29532/setrlimit_doc.patch

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

From report at bugs.python.org  Thu Mar 21 21:19:22 2013
From: report at bugs.python.org (Paul Price)
Date: Thu, 21 Mar 2013 20:19:22 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363897162.92.0.0864870680832.issue17409@psf.upfronthosting.co.za>


Paul Price added the comment:

That's good; it doesn't have what I added to the description of RLIMIT_NOFILE, but perhaps you chose to leave that out on purpose.

Since both "unlimited" and "infinite" are both used in different contexts, perhaps we should use both, e.g., "infinite/unlimited"?

----------

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

From report at bugs.python.org  Thu Mar 21 21:24:02 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 20:24:02 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363897442.14.0.554132133296.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

infinite/unlimited sounds like a good compromise :)

Yes, I left NOFILE out on purpose, because the issue applies to any resource that is not unlimited for whatever reason.

----------

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

From report at bugs.python.org  Thu Mar 21 21:55:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 20:55:51 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363899351.37.0.458405116205.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here's another attempt, using infinite/unlimited .  I noticed that the following paragraph talks specifically about the error raised, so I moved the explanation to that paragraph.

----------
Added file: http://bugs.python.org/file29534/setrlimit_doc.patch

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

From report at bugs.python.org  Thu Mar 21 22:13:18 2013
From: report at bugs.python.org (Paul Price)
Date: Thu, 21 Mar 2013 21:13:18 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363900398.83.0.0888402994755.issue17409@psf.upfronthosting.co.za>


Paul Price added the comment:

You missed out an "is":

   Raises :exc:`ValueError` if an invalid resource is specified, if the new soft
   limit exceeds the hard limit, or if a process tries to raise its hard limit
   (unless the process has an effective UID of super-user).  Specifying an
   infinite/unlmited limit when the hard or system limit for that resource **is** not
   unlimited will result in a :exc:`ValueError`.  ``setrlimit`` may also raise
    :exc:`error` if the underlying system call fails.

----------

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

From report at bugs.python.org  Thu Mar 21 22:17:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2013 21:17:30 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363900650.85.0.941425535954.issue17409@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

in-finite literally means un-limited or un-bounded. However, 'infinte' has also taken on the meaning of 'actual infinity'. So in my algorithms book, when 'actual infinities' are not in play. I describe the set of counts as unbounded. I suggest you go with just 'unlimited'. I believe constructions such as and/or (which some style guides discourage. because they are a bit ugly) should suggest some contrast or difference, rather than exact synonyms but I could be wrong.

----------

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

From report at bugs.python.org  Thu Mar 21 22:33:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 21:33:51 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363901631.53.0.902819097671.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

Terry: well, we're trying to deal with the fact that the setrlimit man page says:

       The  value  RLIM_INFINITY  denotes  no limit on a resource (both in the
       structure returned by getrlimit() and in the structure passed to  setr-
       limit()).

Oh.  RLIM_INFINITY is defined in the module.  Let me update the patch again :)

----------

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

From report at bugs.python.org  Thu Mar 21 22:43:22 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 21:43:22 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363902202.44.0.214178393935.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here's a patch that adds RLIMIT_INFINITY and uses it.  This constant exists in 2.7 and Python3, but has not been previously documented.

----------
Added file: http://bugs.python.org/file29535/setrlimit_doc.patch

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

From report at bugs.python.org  Thu Mar 21 23:09:30 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2013 22:09:30 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363903769.94.0.284765340156.issue17409@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Both old and new have this sentence:
"Raises :exc:`ValueError` if an invalid resource is specified, if the new soft limit exceeds the hard limit, or if a process tries to raise its hard limit (unless the process has an effective UID of super-user)."

This strikes me as a bit awkward and ambiguous. As a naive reader that does not already know the facts, it is unclear whether the (unless...) applies to the overall sentence (Raise...) or just the last clause (if a process...). I would try moving the 'unless...' either before the whole sentence or before the clause, depending on which is true.

----------

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

From report at bugs.python.org  Fri Mar 22 00:42:15 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Mar 2013 23:42:15 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363909335.24.0.0209023418235.issue17409@psf.upfronthosting.co.za>


R. David Murray added the comment:

How about this.

----------
Added file: http://bugs.python.org/file29538/setrlimit_doc.patch

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

From report at bugs.python.org  Fri Mar 22 02:37:36 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2013 01:37:36 +0000
Subject: [docs] [issue17409] resource.setrlimit doesn't respect -1
In-Reply-To: <1363187915.96.0.919342054358.issue17409@psf.upfronthosting.co.za>
Message-ID: <1363916256.96.0.833614808187.issue17409@psf.upfronthosting.co.za>


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


----------
stage:  -> commit review

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

From report at bugs.python.org  Fri Mar 22 12:44:12 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 22 Mar 2013 11:44:12 +0000
Subject: [docs] [issue14979] pdb doc: Explain how to extend debugger instead
	of	sending readers to the source
In-Reply-To: <1338555806.37.0.54245715922.issue14979@psf.upfronthosting.co.za>
Message-ID: <1363952652.12.0.885655666491.issue14979@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

A minimal example of debugger is needed, with the explanation how frame.f_trace is used by debuggers.

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

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

From report at bugs.python.org  Fri Mar 22 19:52:37 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 22 Mar 2013 18:52:37 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
In-Reply-To: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>
Message-ID: <1363978357.01.0.0828642196314.issue17438@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar 22 20:02:53 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 22 Mar 2013 19:02:53 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1363978973.34.0.658656816882.issue17462@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


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

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

From report at bugs.python.org  Sat Mar 23 00:41:39 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 22 Mar 2013 23:41:39 +0000
Subject: [docs] [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1363995699.47.0.540507476785.issue12207@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

PyCF_ONLY_AST is defined in pythonrun.h and referenced in bltinmodule.c, Python-ast.c and pythonrun.c.  Should it be documented or not?

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

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

From report at bugs.python.org  Sat Mar 23 01:26:36 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 23 Mar 2013 00:26:36 +0000
Subject: [docs] [issue14101] example function in tertools.count docstring
	is	misindented
In-Reply-To: <1330027633.46.0.670191761588.issue14101@psf.upfronthosting.co.za>
Message-ID: <1363998396.3.0.562687398497.issue14101@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As this is a trivial patch could it be applied please?

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

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

From report at bugs.python.org  Sat Mar 23 07:48:13 2013
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sat, 23 Mar 2013 06:48:13 +0000
Subject: [docs] [issue17505] email.header.Header.__unicode__ does not decode
	header
In-Reply-To: <1363852013.63.0.253070231302.issue17505@psf.upfronthosting.co.za>
Message-ID: <1364021293.74.0.731309334984.issue17505@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

Thanks for pointing out the make_header(decode_header(...)) idiom, which I was indeed not aware of.  It solves the problem perfectly.

I agree that it is a doc bug.  While make_header is documented on the same place as decode_header and Header itself, it is not explained *why* I should call it if I already have in hand a perfectly valid Header instance.  Specifically, it is not at all clear that while unicode(h) and unicode(make_header(decode_header(h)) will return different things -- I would have expected make_header(decode_header(h)) to return an object indistinguishable from h.

Also, the policy=default parameter in Python 3 sounds great, it's exactly what one would expect.

----------

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

From report at bugs.python.org  Sat Mar 23 13:14:47 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Mar 2013 12:14:47 +0000
Subject: [docs] [issue17529] fix os.senfile() documentation regarding the
	type of	file descriptor
Message-ID: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za>


New submission from Charles-Fran?ois Natali:

os.sendfile() documentation states:
"""
On Solaris, out may be the file descriptor of a regular file or the file descriptor of a socket. On all other platforms, out must be the file descriptor of an open socket.
"""

This isn't true for Linux anymore (changed somewhere around 2.6.33), so it would probably be better to rephrase to something like "all platforms support sockets as out file descriptor, and some platforms allow other types (e.g. regular files) as well".

----------
assignee: docs at python
components: Documentation
messages: 185040
nosy: docs at python, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: fix os.senfile() documentation regarding the type of file descriptor
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 23 13:30:42 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sat, 23 Mar 2013 12:30:42 +0000
Subject: [docs] [issue17529] fix os.sendfile() documentation regarding the
	type of	file descriptor
In-Reply-To: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za>
Message-ID: <1364041842.15.0.685494280268.issue17529@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
title: fix os.senfile() documentation regarding the type of file descriptor -> fix os.sendfile() documentation regarding the type of file descriptor

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

From report at bugs.python.org  Sat Mar 23 13:40:15 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Mar 2013 12:40:15 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
In-Reply-To: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>
Message-ID: <1364042415.71.0.237671737737.issue17438@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

It's documented in the table at http://docs.python.org/2/library/json.html#json.JSONDecoder, but indeed a link to the table should be added in the docs of load/loads (and similarly to the dump/dumps docs too).

----------
keywords: +easy
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Mar 23 14:00:34 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Mar 2013 13:00:34 +0000
Subject: [docs] [issue17529] fix os.sendfile() documentation regarding the
	type of	file descriptor
In-Reply-To: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za>
Message-ID: <1364043634.08.0.859595278014.issue17529@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Sounds good to me.

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

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

From bbayles at gmail.com  Sun Mar  3 01:02:41 2013
From: bbayles at gmail.com (Bo Bayles)
Date: Sun, 03 Mar 2013 00:02:41 -0000
Subject: [docs] Multiprocessing module example problem
Message-ID: <CALqAb4yCnFu12CPFUnQRm0ivMQNMvKSr8FsRaLevNKhZihfjNg@mail.gmail.com>

I noticed that the "A test of `multiprocessing.Pool` class" at
(http://docs.python.org/3/library/multiprocessing.html#examples)
doesn't seem to work as expected.

I'm using Python 3.3 on Windows. I saved the example and ran it. It
gives the correct output until the "Testing callback" section. The
map_async function doesn't seem to be written properly.

I was confused about why the program I was writing didn't work until I
realized the example might be wrong.

If I can figure out a workaround I will write back, but otherwise I
hope the example can be fixed by someone smarter than me.

Thanks,
-Bo

Testing callback:
        *** callbacks failed
                [56] != [56, 0, 1, 8, 27, 64, 125, 216, 343, 512, 729]

From bahamutzero8825 at gmail.com  Sun Mar 10 20:02:45 2013
From: bahamutzero8825 at gmail.com (Andrew Berg)
Date: Sun, 10 Mar 2013 14:02:45 -0500
Subject: [docs] platform.win32_ver() returns more than (version, csd, ptype)
Message-ID: <513CD8D5.3030407@gmail.com>

http://docs.python.org/3.3/library/platform.html#platform.win32_ver

The documentation explicitly states that platform.win32_ver() returns
(version, csd, ptype), but in fact, it returns (release, version, csd,
ptype).

On Windows 8 (Python 3.3 of course):
>>> platform.win32_ver()
('post2008Server', '6.2.9200', '', 'Multiprocessor Free')

From chriswallis at littlewindsor.co.uk  Sun Mar 10 20:37:13 2013
From: chriswallis at littlewindsor.co.uk (Christopher Wallis)
Date: Sun, 10 Mar 2013 19:37:13 +0000
Subject: [docs] Documentation bug?
Message-ID: <CAE5PLj6gPXi330Hrx5ZviUG8nM=7d38CJgVYX7=TPGj8o+niwQ@mail.gmail.com>

In section 4.1....

4.1. if <http://docs.python.org/2/reference/compound_stmts.html#if>Statements

Perhaps the most well-known statement type is the
if<http://docs.python.org/2/reference/compound_stmts.html#if>statement.
For example:

The for <http://docs.python.org/2/reference/compound_stmts.html#for>statement
in Python differs a bit from what you may be used to in C or
Pascal. Rather than always iterating over an arithmetic progression of
numbers (like in Pascal), or giving the user the ability to define both the
iteration step and halting condition (as C), Python?s
for<http://docs.python.org/2/reference/compound_stmts.html#for>statement
iterates over the items of any sequence (a list or a string), in
the order that they appear in the sequence. For example (no pun intended):
>>>

>>> # Measure some strings:... words = ['cat', 'window', 'defenestrate']>>> for w in words:...     print w, len(w)...cat 3window 6defenestrate 12
 If I enter this code into the interpreter, I get a syntax error at
print w, len(w)

My apologies if the problem is in my understanding: I'm new at Python..

Chris Wallis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130310/8e7ef15b/attachment.html>

From brunonar at gmail.com  Wed Mar 20 20:46:35 2013
From: brunonar at gmail.com (Bruno)
Date: Wed, 20 Mar 2013 16:46:35 -0300
Subject: [docs] Bug in time doc.
Message-ID: <CAD2Da5BKL2n7GJ2z+sUv=0vQ40sxsyKP5EPZbGJr6y4QMbNmRQ@mail.gmail.com>

%f is not documented:
http://docs.python.org/3/library/time.html

Unofficial reference:
http://stackoverflow.com/questions/698223/how-can-i-parse-a-time-string-containing-milliseconds-in-it-with-python

Bye.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130320/98711fb4/attachment.html>

From tshepang at gmail.com  Thu Mar  7 18:56:08 2013
From: tshepang at gmail.com (tshepang at gmail.com)
Date: Thu, 07 Mar 2013 17:56:08 -0000
Subject: [docs] TimedRotatingFileHandler documentation regarding 'Week day'
 lacking (issue 17376)
Message-ID: <20130307175607.12340.74570@psf.upfronthosting.co.za>

Reviewers: ,


http://bugs.python.org/review/17376/diff/7548/Doc/library/logging.handlers.rst
File Doc/library/logging.handlers.rst (right):

http://bugs.python.org/review/17376/diff/7548/Doc/library/logging.handlers.rst#newcode320
Doc/library/logging.handlers.rst:320: | ``'W<number>'``| Week day
(0=Monday)   |
LGTM

http://bugs.python.org/review/17376/diff/7548/Doc/library/logging.handlers.rst#newcode326
Doc/library/logging.handlers.rst:326: ``W`` and the number of the day of
the week. Monday is 0, Sunday is 6.
I think it's enough to just change the text on the table. Should be
obvious... the explanation here is redundant.



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

Affected files:
  Doc/library/logging.handlers.rst


diff -r 66d0f6ef2a7f Doc/library/logging.handlers.rst
--- a/Doc/library/logging.handlers.rst	Thu Feb 28 18:03:16 2013 +0200
+++ b/Doc/library/logging.handlers.rst	Thu Mar 07 09:51:33 2013 -0500
@@ -317,11 +317,14 @@
    +----------------+-----------------------+
    | ``'D'``        | Days                  |
    +----------------+-----------------------+
-   | ``'W'``        | Week day (0=Monday)   |
+   | ``'W<number>'``| Week day (0=Monday)   |
    +----------------+-----------------------+
    | ``'midnight'`` | Roll over at midnight |
    +----------------+-----------------------+
 
+   When using a rotation based on the day of the week from Monday to Sunday, use
+   ``W`` and the number of the day of the week. Monday is 0, Sunday is 6.
+
    The system will save old log files by appending extensions to the filename.
    The extensions are date-and-time based, using the strftime format
    ``%Y-%m-%d_%H-%M-%S`` or a leading portion thereof, depending on the



From vitaliy.stepanov at gmail.com  Mon Mar 11 00:45:35 2013
From: vitaliy.stepanov at gmail.com (vitaliy.stepanov at gmail.com)
Date: Sun, 10 Mar 2013 23:45:35 -0000
Subject: [docs] os.rename documentation slightly inaccurate (issue 16278)
Message-ID: <20130310234535.17247.9850@psf.upfronthosting.co.za>

some comments to the patch


http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py
File Lib/test/test_os.py (right):

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2209
Lib/test/test_os.py:2209: class RenameTests(unittest.TestCase):
I have some comments to this patch.
I think would be better to add two separate test case RenameFileTests
and RenameDirTests or something like that.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2215
Lib/test/test_os.py:2215: self.rename_src_file = "%s_%d_tmp" %
("test_rename_src_file",
All variables has prefix ``rename_`` (rename_src_file, rename_dst_file
and so on), so can use them without this prefix (just src_file, dst_file
...)

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2216
Lib/test/test_os.py:2216: os.getpid())
should not call this method everywhere, use a variable

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2217
Lib/test/test_os.py:2217: if os.path.exists(self.rename_src_file):
There is remove_file_or_directory method, use it for remove exist
files/dirs.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2220
Lib/test/test_os.py:2220: os.write(fd, b"beans\n")
Really need to write many lines in a file and then split the text on the
line in tests? Perhaps enough only one.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2277
Lib/test/test_os.py:2277: if (os.path.isfile(file)):
outer parentheses are unnecessary

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2289
Lib/test/test_os.py:2289: self.assertRaises(OSError, os.rename, src,
dst)
I do not see where `src` and `dst` variables are declared

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2295
Lib/test/test_os.py:2295:
self.remove_file_or_directory(self.rename_dst_file)
I think it would be better to create the files/directories in separate
methods and call them in tests methods instead of create them in setUp
method and remove in each test (except for those that are not removed in
tests methods, they can be left in the setUp).

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2326
Lib/test/test_os.py:2326:
self.assertEqual(os.path.exists(self.rename_dst_directory), True)
There are unittest.TestCase.assertTrue and unittest.TestCase.assertFalse
methods.

http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode2402
Lib/test/test_os.py:2402: src = self.rename_src_file + "does_not_exist"
I don't see where `src` and `dst` are used.

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

From TKalt at trustwave.com  Tue Mar 12 22:15:06 2013
From: TKalt at trustwave.com (Tom Kalt)
Date: Tue, 12 Mar 2013 21:15:06 +0000
Subject: [docs] bug in ipaddress module documentation
Message-ID: <D4C870855482434484604001080C5C3604C0DB@SKYMB2.trustwave.com>

There is a slight problem with the documentation for the ipaddress module (http://docs.python.org/3.4/library/ipaddress.html).  In
section 21.28.2.3.1,  operators such as  <, <=, ==, !=  are called "logical operators."  They should be called "relational operators."
http://en.wikipedia.org/wiki/Relational_operator.  Alternatively, sometimes they are called "comparison operators."

By contrast, "logical operator" refers to and, or, xor, etc.

I hope this helps.

Tom Kalt


________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130312/53add92b/attachment-0001.html>

From stevan.white at gmail.com  Mon Mar 18 14:44:32 2013
From: stevan.white at gmail.com (Steve White)
Date: Mon, 18 Mar 2013 14:44:32 +0100
Subject: [docs] User documentation for xml.sax.xmlreader.Locator
Message-ID: <CAEmWKkQPhsGmtrpJtpZUjmPKoONs+WodKuQ+nv=V4RYMRiVa0w@mail.gmail.com>

Hi,

The documentation for xml.sax.xmlreader.Locator leaves something to be
desired, from the point of view of a user (as opposed to someone who
is writing a parser.)

A user, for example, might *just* want to parse an XML file, somehow
keeping track of the element line numbers.

It would be helpful to point out that the Locator interface is
implemented by real parsers, such as those produced by make_parser,
and further to explain how to make use of a locator for a given
parser.

For instance, the (barely documented) ExpatParser which is by default
produced by make_parser, defines its own Locator, ExpatLocator, which
can be used... if only you know it's there and how to use it.

I provided an example at
http://stackoverflow.com/questions/15477363/xml-sax-parser-and-line-numbers-etc

Cheers!

From stevan.white at gmail.com  Mon Mar 18 15:52:36 2013
From: stevan.white at gmail.com (Steve White)
Date: Mon, 18 Mar 2013 15:52:36 +0100
Subject: [docs] User documentation for xml.sax.xmlreader.Locator
In-Reply-To: <CAEmWKkQPhsGmtrpJtpZUjmPKoONs+WodKuQ+nv=V4RYMRiVa0w@mail.gmail.com>
References: <CAEmWKkQPhsGmtrpJtpZUjmPKoONs+WodKuQ+nv=V4RYMRiVa0w@mail.gmail.com>
Message-ID: <CAEmWKkS4txVGiziO6hqSTzEUj8n1TOTq2qXK5bgCSUDsHaUqUQ@mail.gmail.com>

Martijn Pieters and I exlplored the issue was further at that link.

He pointed out that if the superclass initializer of the Handler is
properly called,
then an undocumented private member "._locator" ought to be
initialized, by which
the user could get the needed Locator object.

This is of course very poor.

If this member is to be used, it should be documented, and it should
be documented when it is initialized.

MUCH BETTER would be to provide a public user interface to obtain this
needed member, such as
handler.getDocumentLocator() (and to document that!!)

Cheers!

On Mon, Mar 18, 2013 at 2:44 PM, Steve White <stevan.white at gmail.com> wrote:
> Hi,
>
> The documentation for xml.sax.xmlreader.Locator leaves something to be
> desired, from the point of view of a user (as opposed to someone who
> is writing a parser.)
>
> A user, for example, might *just* want to parse an XML file, somehow
> keeping track of the element line numbers.
>
> It would be helpful to point out that the Locator interface is
> implemented by real parsers, such as those produced by make_parser,
> and further to explain how to make use of a locator for a given
> parser.
>
> For instance, the (barely documented) ExpatParser which is by default
> produced by make_parser, defines its own Locator, ExpatLocator, which
> can be used... if only you know it's there and how to use it.
>
> I provided an example at
> http://stackoverflow.com/questions/15477363/xml-sax-parser-and-line-numbers-etc
>
> Cheers!

From enarkadia at gmail.com  Thu Mar  7 07:15:51 2013
From: enarkadia at gmail.com (Hc Z)
Date: Thu, 07 Mar 2013 06:15:51 -0000
Subject: [docs] Python 3.3 Docs Bug
Message-ID: <CABx0=Miw0fLZFUM0_Pco+j46mCZGTnehwEkE8-qwSm-zCNftfw@mail.gmail.com>

Hello,
      I found a bug in Python, see details in
http://bugs.python.org/issue17371. Also I believe this a bug for Python 3.3
documents.
      Good luck, guys.
Haochen Zhao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130307/962b1c2a/attachment-0001.html>

From ecwilliams at lbl.gov  Fri Mar  8 18:17:24 2013
From: ecwilliams at lbl.gov (Eric Williams)
Date: Fri, 8 Mar 2013 09:17:24 -0800
Subject: [docs] sqlite3 cursor object missing attribute documentation
Message-ID: <CAMBk5dL0ym-B0VOJrrTC36vbX3QM7fRizP1CvCDp8RoRUNRjmQ@mail.gmail.com>

Ref: http://docs.python.org/2/library/sqlite3.html#sqlite3.Cursor.fetchall

The fetchall() method documentation refers to the arraysize attribute of
the cursor object, but the cursor object does not document that attribute
or any others.  I suggest explicitly listing and documenting cursor object
attributes.
--
Eric Williams
ALS Controls Group, LBL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130308/1a606ea1/attachment-0001.html>

From debian at liska.ath.cx  Mon Mar 11 17:43:18 2013
From: debian at liska.ath.cx (Ole Streicher)
Date: Mon, 11 Mar 2013 17:43:18 +0100
Subject: [docs] urllib2.urlopen()
Message-ID: <513E09A6.3090305@liska.ath.cx>

Hi,

I just tried to directly open a tar file from an URL:

---------------------8<-------------------------------
import urllib2
import tarfile

url = "http://ftp.gnu.org/gnu/hello/hello-2.8.tar.gz"
tar = tarfile.open(fileobj = urllib2.urlopen(url))
tar.extractall()
---------------------8<-------------------------------

This doesn't work since urllib2.urlopen() does not return a seekable
file, but tarfile.open() expects one.

This limitation is not mentioned in the documentation of urlopen(),
instead is misleadingly states:

"This function returns a file-like object with two additional methods:
[...]"

I would suggest to add here that the returned object is not seekable, or
a "Socket-like" object or similar.

Oh, and the object has *three* additional methods, not two (geturl(),
info(), getcode()).

Please include me in an replay as I am not subscribed to the list.

Best regards

Ole

From g1234 at arcor.de  Tue Mar 12 17:11:00 2013
From: g1234 at arcor.de (g1234 at arcor.de)
Date: Tue, 12 Mar 2013 17:11:00 +0100 (CET)
Subject: [docs] documentation for 2.7.3 __repr__ and __str__
Message-ID: <1819605272.334777.1363104660482.JavaMail.ngmail@webmail17.arcor-online.net>

Hello,

my name is Richard and I first want to compliment for the great thing of python and of course it's documentation.

I found an issue I would like to discuss in the description of the __repr__ attribute.

It says there about __repr__: "Called by the repr() built-in function ..."

And further: "If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value (given an appropriate environment). If this is not possible, a string of the form <...some useful description...> should be returned."

And about __str__ it says: "... by the print statement to compute the ?informal? string representation of an object. This differs from __repr__() in that it does not have to be a valid Python expression: a more convenient or concise representation may be used instead."

At another place I read that __str__ is supposed to be human readable and that python falls back to __repr__ if there is no __str__ defined.

Lets say we have a Color class which holds the name of the color and it's RGB values, than I would interpret this as have the attributes return something like the following:

__repr__:  "{'name':'red', 'red':255, 'green':0, 'blue':0}"
__str__:    "Color: red [255, 0, 0]"

The first would be readable by a python program and convert to an instance of the Color class and the latter is information rich, compact and alot better human readable. This is supported by the real purpose of the repr() function which is meant to serialize data for persistent storage or to transmit across a wire.

In practice it is alot worse, many classes follow the documentation and have their __repr__ produce something like <xyz object at 0x94738237> which is in no way human readable and information rich. If this is "some useful description" at all, like the documentation asks for, I would deny.

But the documentation suggests for __repr__: "This is typically used for debugging..." Which is wrong from my point of view.

Especially, since I found out, that __repr__ is also, at least sometimes, used in comparison of objects.

Conclusion: I would like to suggest to move the line that starts with: "This is typically used for debugging ...", to the __str__ attribute, suggesting to developers of debugging tools do dispay information rich, compact and human readable information to humans and leave __repr__ for machine to machine communication.

Thanks for taking the time,

Richard

From gfelishia at gmail.com  Wed Mar 13 14:21:07 2013
From: gfelishia at gmail.com (=?ISO-8859-1?Q?Felishia_Gonz=E1lez?=)
Date: Wed, 13 Mar 2013 08:51:07 -0430
Subject: [docs] What about python 3.3 documentation in spanish?
Message-ID: <CANL6Zg=etFuacQY6xwxefoVVpSHzbZwUVjwAtaKO7KMkPP0g9A@mail.gmail.com>

I've been seeking for it.
And it doesn't seem to exist.
Can I translate all this information and ask for donations?
I'm needing a job, I wonder if I can do this.

Felishia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130313/1117d524/attachment.html>

From ejgonzalezviera at fec.luz.edu.ve  Wed Mar 13 16:36:10 2013
From: ejgonzalezviera at fec.luz.edu.ve (ej gonzalez viera)
Date: Wed, 13 Mar 2013 11:06:10 -0430
Subject: [docs] Spanish translation.
Message-ID: <CAKgRWcsTd9+cRURHz2T75t_xFEjKAJbS35c2DCMW_nZXKK1GZg@mail.gmail.com>

Hi I sent you an e-mail before without so much formalism and from my
personal (to play with friends) account.
This is my formal account now let's talk about this.

Firstly I'm a student from FEC-LUZ university, and you can see it's true
because of my institutional e-mail; I've had studies on English language
but my first one is spanish.
At the moment I'm into economic trouble, I've been seeking for a job but I
don't seem to find any as I've just become 18, I'm also studying chemistry
(I use python to model atoms and orbitals and do calculus).
So I wondered what about working for python as a contributing to it? I
would be a really bad developer as I'm just a newbie on it and I just use
it for hobbie.
However I have enough free time like to do an entire translation of the
documentation, that time is supposed to be the time for me to work.
So I was wondering if there's a way to get "donations" for me as I really
want to help with the documentation and I'm poor, I know it's very personal
what I'm asking for but I needed to ask.
I have very good skills at writing (as my mum was a secretary), and I'm
sure I'm able to get into this project of translating it into spanish.

I just would like that, at least some economic help for my studies, food
and medical insurance; not really much I do ask for, at least to post
something telling people to give me some help and in exchange I'll keep
doing translations of the python documentation.
I have a certificate on that, from CEVAZ institute; so I'd like to apply as
a contributor with little donation benefits.

E. Gonz?lez.
FEC-LUZ University
Maracaibo, Zulia, Venezuela.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130313/c68fe145/attachment.html>

From darren.yin at gmail.com  Fri Mar 15 21:30:30 2013
From: darren.yin at gmail.com (Darren Yin)
Date: Fri, 15 Mar 2013 13:30:30 -0700
Subject: [docs] daemon attribute in threading module doesn't have a "new in
 2.6" next to it
Message-ID: <CAPWDJtUMKC4udU-fR-RbTdTdDk1iiDrLW+45rNVKDJTjGXoRPA@mail.gmail.com>

The docs are usually pretty good about saying when features were
introduced, so if a documented property/method doesn't have an explicit
"New in *" next to it, I assume it's valid in python 2.5 at least.

http://docs.python.org/2/library/threading.html#threading.Thread.daemon

--darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130315/12f25e54/attachment.html>

From psionski at gmail.com  Thu Mar 21 21:43:12 2013
From: psionski at gmail.com (Vladislav Zorov)
Date: Thu, 21 Mar 2013 22:43:12 +0200
Subject: [docs] Bug in `itertools.combinations` documentation (equivalent
	function)
Message-ID: <CALHm=7KYAmM021zbXjabS6bGRYvqUqJmALzUhGNEUa1Wx=qPbA@mail.gmail.com>

Hello, dear documentation maintainers!

Present in     : all versions of the documentation (2.6.8 - 3.4.0)
Example URL:
http://docs.python.org/3.4/library/itertools.html#itertools.combinations
Description    : The `else: return` part is incorrectly indented on the
same level as `for`, thus appearing to be part of the `while` loop.

while True:
        for i in reversed(range(r)):
            if indices[i] != i + n - r:
                break
        else:
            return

Thank you for giving me so, so much to read! I hope I didn't misunderstand
the code - forgive me if I did.
--
Best Regards,
Vladislav Zorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130321/faa67dd0/attachment.html>

From jkamens at quantopian.com  Wed Mar  6 16:28:44 2013
From: jkamens at quantopian.com (Jonathan Kamens)
Date: Wed, 06 Mar 2013 15:28:44 -0000
Subject: [docs] Typo in example code for operator.attrgetter
Message-ID: <513760A3.5020206@quantopian.com>

At http://docs.python.org/2/library/operator.html#operator.attrgetter, 
the example code in one instance "resolve_att" where it should be 
"resolve_attr".

Regards,

Jonathan Kamens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130306/18fa0922/attachment-0001.html>

From john at castleamber.com  Mon Mar 11 23:00:11 2013
From: john at castleamber.com (John Bokma)
Date: Mon, 11 Mar 2013 16:00:11 -0600
Subject: [docs] 2.7.3 documentation: "6.4.1. Importing * From a Package"
 sounds/ should be sound/
Message-ID: <513E53EB.6000805@castleamber.com>

http://docs.python.org/2/tutorial/modules.html

"the file sounds/effects/__init__.py "

               ^ should be sound, not sounds.

Regards,
John

From krishnak.thakur at yahoo.com  Tue Mar 12 21:13:21 2013
From: krishnak.thakur at yahoo.com (Krishna Kumar Thakur)
Date: Tue, 12 Mar 2013 13:13:21 -0700 (PDT)
Subject: [docs] Documentation error in function getaddrinfo in socket module
Message-ID: <1363119201.10987.YahooMailNeo@web120202.mail.ne1.yahoo.com>



?Hi,

python version : 3.3.0

Description : getaddrinfo() function expecting 'type' as the keyword argument but
the function documentation says 'socktype' . 

please see the below output
>>> help(getaddrinfo)
Help on built-in function getaddrinfo in module _socket:

getaddrinfo(...)
??? getaddrinfo(host, port [, family, socktype, proto, flags])
??????? -> list of (family, socktype, proto, canonname, sockaddr)
??? 
>>> getaddrinfo.__doc__
'getaddrinfo(host, port [, family, socktype, proto, flags])\n??? -> list of (family, socktype, proto, canonname, sockaddr)\n\nResolve host and port into addrinfo struct.'

so if the function is called 
>>> i = getaddrinfo('www.python.org','http',socktype = SOCK_STREAM)
Traceback (most recent call last):
? File "<pyshell#20>", line 1, in <module>
??? i = getaddrinfo('www.python.org','http',socktype = SOCK_STREAM)
TypeError: 'socktype' is an invalid keyword argument for this function

then I have found the correct keyword argument as 'type' in python 3.3 official documentation.
Its not the major issue but sometimes it confuses.

As I appreciate python, so I felt its my duty to help make this language error free
as much as possible. :)



________________________________
Thank You

Krishna Kumar Thakur
Contact: +91-7411251885
E_mail: krishnak.thakur at yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130312/2326f02c/attachment-0001.html>

From ngbushong at gmail.com  Fri Mar 15 17:06:32 2013
From: ngbushong at gmail.com (Neil Bushong)
Date: Fri, 15 Mar 2013 12:06:32 -0400
Subject: [docs] Trivial os.path documentation bug
Message-ID: <CAARaemcDMao6+Of5fJ8uDmq0e9HLe69U3fbUpVCcM5jPQVm1YA@mail.gmail.com>

Tiny typo: in the Python 3.3 os.makedirs documentation at
http://docs.python.org/3.3/library/os.html#os.makedirs, the sentence saying
"If exist*s*_ok is False (the default), an OSError is raised..." refers to
the keyword argument as "exists_ok" (with an "s"), while the other parts
refer to the keyword parameter as "exist_ok" (without the "s").

Thanks for providing and maintaining all the excellent documentation.

Neil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130315/39d4f7ca/attachment-0001.html>

From magnus at hetland.org  Mon Mar 18 11:28:22 2013
From: magnus at hetland.org (Magnus Lie Hetland)
Date: Mon, 18 Mar 2013 11:28:22 +0100
Subject: [docs] Bug in doc for assertAlmostEqual
Message-ID: <5EBAC09A-C049-40F3-99DD-2C125D96675F@hetland.org>

Hi!

Just noticed a bug here:

  http://docs.python.org/2/library/unittest.html#unittest.TestCase.assertAlmostEqual
  http://docs.python.org/3/library/unittest.html#unittest.TestCase.assertAlmostEqual

There is a sentence that says, "If delta is supplied instead of places then the difference between first and second must be less (or more) than delta."

Judging by the source code (3.3), that should be "less than or equal to (or greater than or equal to) delta", i.e., it's not a strict inequality.

-- 
Magnus Lie Hetland
http://hetland.org



From kenneth.hill at autodesk.com  Mon Mar 18 10:55:40 2013
From: kenneth.hill at autodesk.com (Kenneth Hill)
Date: Mon, 18 Mar 2013 09:55:40 +0000
Subject: [docs] Python 3.3 Module documentation bug: xml.sax
Message-ID: <64B0B97F72D03F45B6FE8F10FCE66E600FE43945@005-TK5MPN2-022.MGDADSK.autodesk.com>

For some reason xml.sax is a child of xml.parsers.expat.errors in the module index.

Currently:

xml.parsers.expat.errors
    xml.parsers.expat.model
    xml.sax
    xml.sax.handler
    xml.sax.saxutils
    xml.sax.xmlreader

I suspect this should be:

xml.parsers
    xml.parsers.expat
        xml.parsers.expat.errors
        xml.parsers.expat.model
xml.sax
    xml.sax.handler
    xml.sax.saxutils
    xml.sax.xmlreader

Regards,
Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130318/c9f586ce/attachment-0001.html>

From pbarandat at gmail.com  Tue Mar 19 10:49:09 2013
From: pbarandat at gmail.com (Peter Barandat)
Date: Tue, 19 Mar 2013 10:49:09 +0100
Subject: [docs] Addition to the sockets howto.
Message-ID: <51483495.7020902@gmail.com>

Hello,

I'm new to python and am trying to create a program that uses sockets.
For this I'm basing myself on : http://docs.python.org/2/howto/sockets.html.

I'd like to propose a small clarification for this page.  Namely to 
state explicitly that the programmer has to "import socket" before 
sockets can be used.
I realise this is probably second nature for those having a bit of 
experience with python. For me, as a newbie, this extra bit of info 
would have helped me a lot.

Regards,
Peter

From magnus at hetland.org  Tue Mar 19 11:58:59 2013
From: magnus at hetland.org (Magnus Lie Hetland)
Date: Tue, 19 Mar 2013 11:58:59 +0100
Subject: [docs] Bug in doc for assertAlmostEqual
In-Reply-To: <5EBAC09A-C049-40F3-99DD-2C125D96675F@hetland.org>
References: <5EBAC09A-C049-40F3-99DD-2C125D96675F@hetland.org>
Message-ID: <98970D37-CA3A-4B7A-B633-3E4870DF3A47@hetland.org>

On Mar 18, 2013, at 11:28 AM, Magnus Lie Hetland <magnus at hetland.org> wrote:

> Judging by the source code (3.3), that should be "less than or equal to (or greater than or equal to) delta", i.e., it's not a strict inequality.


Slight snafu there -- of course, the parenthesis is for the negation, so that should still be "more than" (or "greater than").

-- 
Magnus Lie Hetland
http://hetland.org



From kai at kunfoo.org  Wed Mar 20 16:24:28 2013
From: kai at kunfoo.org (Kai K.)
Date: Wed, 20 Mar 2013 16:24:28 +0100
Subject: [docs] curses documentation
Message-ID: <20130320152425.GG17896@kunfoo.org>

Hey,

There is an error in the parameter list of newwin/subwin/derwin. It
says:
	curses.newwin(nlines, ncols, begin_y, begin_x)

but as far as I understand it should be:
	curses.newwin(ncols, nlines, begin_y, begin_x)
-- 
Gr??e, Kai

"In a world without walls and fences, who needs Windows and Gates?"

From kai at kunfoo.org  Wed Mar 20 16:31:51 2013
From: kai at kunfoo.org (Kai K.)
Date: Wed, 20 Mar 2013 16:31:51 +0100
Subject: [docs] curses documentation
In-Reply-To: <20130320152425.GG17896@kunfoo.org>
References: <20130320152425.GG17896@kunfoo.org>
Message-ID: <20130320153149.GH17896@kunfoo.org>

The documentation is correct. There was a mistake on my side.

Sorry!
-- 
Gr??e, Kai

"In a world without walls and fences, who needs Windows and Gates?"

From micheal.w.wells at gmail.com  Fri Mar 22 17:03:02 2013
From: micheal.w.wells at gmail.com (Micheal Wells)
Date: Fri, 22 Mar 2013 09:03:02 -0700
Subject: [docs] /3/library/argparse.html#module-argparse
Message-ID: <CAKiQ7fV4YDVKPfaiMeLx78BdmN+_aW-7eCs8+mmGPOhAHbx0Lg@mail.gmail.com>

An observation:

In example 16.4.1, a script named 'prog.py' is given, and the user is told
that they may execute it from the command line like so:  $  prog.py

My issue with this, is that it doesn't mention that the script starts with
a shebang or is made executable with chmod +x, and even then the command
would be $ ./prog.py.

A minor gripe, but I think that too much is assumed of the reader.   For
reference:



Assuming the Python code above is saved into a file called prog.py, it can
be run at the command line and provides useful help messages:

$ prog.py -h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130322/6dcb68ae/attachment.html>

From report at bugs.python.org  Sat Mar 23 21:35:00 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 23 Mar 2013 20:35:00 +0000
Subject: [docs] [issue14945] Setup & Usage documentation for selected stdlib
	modules
In-Reply-To: <1338256259.22.0.129056676976.issue14945@psf.upfronthosting.co.za>
Message-ID: <1364070900.77.0.789715165303.issue14945@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions: +Python 3.4

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

From bgailer at gmail.com  Sat Mar 23 23:59:38 2013
From: bgailer at gmail.com (bob gailer)
Date: Sat, 23 Mar 2013 18:59:38 -0400
Subject: [docs] Bug in `itertools.combinations` documentation
 (equivalent function)
In-Reply-To: <CALHm=7KYAmM021zbXjabS6bGRYvqUqJmALzUhGNEUa1Wx=qPbA@mail.gmail.com>
References: <CALHm=7KYAmM021zbXjabS6bGRYvqUqJmALzUhGNEUa1Wx=qPbA@mail.gmail.com>
Message-ID: <514E33DA.8020502@gmail.com>

On 3/21/2013 4:43 PM, Vladislav Zorov wrote:
> Hello, dear documentation maintainers!
>
> Present in     : all versions of the documentation (2.6.8 - 3.4.0)
> Example URL: 
> http://docs.python.org/3.4/library/itertools.html#itertools.combinations
> Description    : The `else: return` part is incorrectly indented on 
> the same level as `for`, thus appearing to be part of the `while` loop.
>
> while True:
>         for i in reversed(range(r)):
>             if indices[i] != i + n - r:
>                 break
>         else:
>             return
>
> Thank you for giving me so, so much to read! I hope I didn't 
> misunderstand the code
Seems you did.

for_stmt ::=  "for" target_list "in" expression_list ":" suite ["else" 
":" suite]

A break <simple_stmts.html#break> statement executed in the first suite 
terminates the loop without executing the else <#else> clause's suite..

> - forgive me if I did.
OK

-- 
Bob Gailer
919-636-4239
Chapel Hill NC

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

From bgailer at gmail.com  Sun Mar 24 00:07:55 2013
From: bgailer at gmail.com (bob gailer)
Date: Sat, 23 Mar 2013 19:07:55 -0400
Subject: [docs] Addition to the sockets howto.
In-Reply-To: <51483495.7020902@gmail.com>
References: <51483495.7020902@gmail.com>
Message-ID: <514E35CB.3060907@gmail.com>

On 3/19/2013 5:49 AM, Peter Barandat wrote:
> http://docs.python.org/2/howto/sockets.html.
>
Mention that the Python distribution includes a socket module and add 
"import socket" to each code example.

-- 
Bob Gailer
919-636-4239
Chapel Hill NC


From report at bugs.python.org  Sun Mar 24 01:40:58 2013
From: report at bugs.python.org (Richard Eames)
Date: Sun, 24 Mar 2013 00:40:58 +0000
Subject: [docs] [issue12920] inspect.getsource fails to get source of local
	classes
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1364085658.97.0.770059296386.issue12920@psf.upfronthosting.co.za>


Changes by Richard Eames <naddiseo at gmail.com>:


----------
nosy: +Naddiseo

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

From report at bugs.python.org  Sun Mar 24 07:42:00 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 24 Mar 2013 06:42:00 +0000
Subject: [docs] [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1364107320.63.0.983657040518.issue12207@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

> In my view, it is adequately documented now, should not be undocumented, and should not be given more prominence either. So I recommend closing this.
+1

----------
nosy: +Ramchandra Apte

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

From report at bugs.python.org  Sun Mar 24 13:20:48 2013
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 24 Mar 2013 12:20:48 +0000
Subject: [docs] [issue17529] fix os.sendfile() documentation regarding the
	type of	file descriptor
In-Reply-To: <1364040887.67.0.333340627096.issue17529@psf.upfronthosting.co.za>
Message-ID: <1364127648.82.0.16965921545.issue17529@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <cf.natali at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file29561/sendfile_doc.diff

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

From bgailer at gmail.com  Sun Mar 24 18:23:47 2013
From: bgailer at gmail.com (bob gailer)
Date: Sun, 24 Mar 2013 13:23:47 -0400
Subject: [docs] Documentation bug?
In-Reply-To: <CAE5PLj6gPXi330Hrx5ZviUG8nM=7d38CJgVYX7=TPGj8o+niwQ@mail.gmail.com>
References: <CAE5PLj6gPXi330Hrx5ZviUG8nM=7d38CJgVYX7=TPGj8o+niwQ@mail.gmail.com>
Message-ID: <514F36A3.8060908@gmail.com>

On 3/10/2013 3:37 PM, Christopher Wallis wrote:
>
>   If I enter this code  into the interpreter, I get a syntax error at  
> print  w,  len(w)
You are probably running a Python 3 version and looking at Python 2 
documentation.

The print statement changed to a function in 3. Try:

print(w,  len(w))

-- 
Bob Gailer
919-636-4239
Chapel Hill NC

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

From report at bugs.python.org  Mon Mar 25 03:46:54 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Mar 2013 02:46:54 +0000
Subject: [docs] [issue12207] Document ast.PyCF_ONLY_AST
In-Reply-To: <1306689830.34.0.885575322408.issue12207@psf.upfronthosting.co.za>
Message-ID: <1364179614.38.0.295072800457.issue12207@psf.upfronthosting.co.za>


?ric Araujo added the comment:

No problem.

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

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

From report at bugs.python.org  Mon Mar 25 03:54:47 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Mar 2013 02:54:47 +0000
Subject: [docs] [issue12920] Document that inspect.getsource only works for
	objects	loaded from files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1364180087.37.0.0216439452602.issue12920@psf.upfronthosting.co.za>


?ric Araujo added the comment:

> It seems to work perfectly on command line though.

If the code is saved in a file, yes, but not in an interactive interpreter.  This is not actually related to IDLE, but to the fact that inspect.getsource merely finds the __file__ attribute of the module object for its argument.  If a module object has no file, the error message indicates that it?s a built-in module (like sys), but this fails to take into account the special __main__ module in an interactive interpreter.

It might be worth it to improve the error message, and in any case the documentation can be improved.

----------
stage:  -> needs patch
title: inspect.getsource fails to get source of local classes -> Document that inspect.getsource only works for objects loaded from files, not interactive session
versions: +Python 3.4

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

From report at bugs.python.org  Mon Mar 25 07:13:04 2013
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 25 Mar 2013 06:13:04 +0000
Subject: [docs] [issue17539] Use the builtins module in the
	unittest.mock.patch	example
Message-ID: <1364191984.35.0.104161135895.issue17539@psf.upfronthosting.co.za>


New submission from Berker Peksag:

(initially reported at http://mail.python.org/pipermail/docs/2013-February/013331.html )

----------
assignee: docs at python
components: Documentation
files: unittest-mock-example.diff
keywords: patch
messages: 185187
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Use the builtins module in the unittest.mock.patch example
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29570/unittest-mock-example.diff

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

From berker.peksag at gmail.com  Mon Mar 25 07:14:22 2013
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 25 Mar 2013 08:14:22 +0200
Subject: [docs] The examples in
 http://docs.python.org/3.3/library/unittest.mock-examples.html for mock
 builtin functions (such as 'open') does not work.
In-Reply-To: <CAPgpG2A6Rv+AQOA1wwws0KzwEEw2x6xBxNRyFf7jBD_bdL6-gA@mail.gmail.com>
References: <CAPgpG2A6Rv+AQOA1wwws0KzwEEw2x6xBxNRyFf7jBD_bdL6-gA@mail.gmail.com>
Message-ID: <CAF4280KL2J5dZR=QYmjD8TnfY9gctE=ZhQtNhFxrkR2RrkNWaw@mail.gmail.com>

On Wed, Feb 27, 2013 at 9:31 PM, ??? <zhangxiaopan at gmail.com> wrote:
> Hi there,
>
> http://docs.python.org/3.3/library/unittest.mock-examples.html
> gives the following example for using unittest.mock module to mock builtin
> functions:
>
>
>>>> mock = MagicMock(return_value = sentinel.file_handle)
>>>> with patch('__builtin__.open', mock):
> ...     handle = open('filename', 'r')
> ...
>>>> mock.assert_called_with('filename', 'r')
>>>> assert handle == sentinel.file_handle, "incorrect file handle returned"
>
>
> By running this example with Python3.3, I received the following error:
>
> ImportError: No module named '__builtin__'
>
> Changing the module name to '__builtins__' does NOT work either.
>
> Changing the module name to 'builtins' DOES work.
>
> Could we fix the document? and could somebody here to explain the difference
> between these names for builtins module?

Thanks for your report. I've opened http://bugs.python.org/issue17539 to fix it.

--Berker

From report at bugs.python.org  Mon Mar 25 12:54:33 2013
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 25 Mar 2013 11:54:33 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364212473.25.0.995326234584.issue17538@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

I feel like there should be a warning in Doc/library/xml.rst too.

Is there any actual reason why we don?t ship defusedxml with Python and add an easy way to monkeypatch so there?s as little passive barriers as possible to use XML ?safely??

I?m sorry I didn?t speak up on when this was discussed on the ML but I found the discussion?depressing.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), XML
nosy: +docs at python, hynek
type:  -> security
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Mar 25 13:16:49 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Mar 2013 12:16:49 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364213809.28.0.841072928225.issue17538@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Donald: Thanks! I'm going to look at your patch later today.

Hynek: Because the preferred way is another: use patched expat and pyexpat C modules of defusedexpat. It's a fix on C level and still allows a sane amount of entity expansions. defusedxml disallows any XML document that smells even a tiny bit. This approach needs a) more reviews and b) an API to enable the limitations-

----------

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

From report at bugs.python.org  Mon Mar 25 19:31:31 2013
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Mar 2013 18:31:31 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364236290.99.0.856201973548.issue17538@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Updated patch with more infos and also a link to defusedexpat.

----------
Added file: http://bugs.python.org/file29572/xmldocs2.diff

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

From report at bugs.python.org  Mon Mar 25 19:45:41 2013
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 25 Mar 2013 18:45:41 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364237141.46.0.0263472877938.issue17538@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Update looks fine to me, I'm not the best at docs I just wanted to get at least a jumping off point.

----------

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

From report at bugs.python.org  Tue Mar 26 01:33:18 2013
From: report at bugs.python.org (jamesob)
Date: Tue, 26 Mar 2013 00:33:18 +0000
Subject: [docs] [issue15575] Tutorial is unclear on multiple imports of a
	module.
In-Reply-To: <1344363062.87.0.467457264308.issue15575@psf.upfronthosting.co.za>
Message-ID: <1364257998.75.0.882625525948.issue15575@psf.upfronthosting.co.za>


jamesob added the comment:

Howdy; attached is a patch containing the doc changes. I figured that some elaboration was in addition to what r.david.murray recommended, so I've included a brief allusion to the problem of equivalent paths.

----------
keywords: +patch
nosy: +jamesob
Added file: http://bugs.python.org/file29575/module_multi_exec_doc_27.patch

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

From report at bugs.python.org  Tue Mar 26 06:19:12 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Mar 2013 05:19:12 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364275152.48.0.905540801768.issue17538@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.

----------
nosy: +eric.araujo
versions: +Python 3.2

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

From report at bugs.python.org  Tue Mar 26 09:22:29 2013
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Tue, 26 Mar 2013 08:22:29 +0000
Subject: [docs] [issue17544] regex code re-raises exceptions on success
In-Reply-To: <1364225248.29.0.538486263378.issue17544@psf.upfronthosting.co.za>
Message-ID: <1364286149.58.0.0861407304606.issue17544@psf.upfronthosting.co.za>


Zden?k Pavlas added the comment:

Yes, found that *certain* IO operations re-raise the error, too.  However, if the Python runtime expects extension writers to keep tstate->curexc_type clear, it should be documented in

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

There's not a single use case of PyErr_Clear() mentioned.

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

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

From report at bugs.python.org  Tue Mar 26 10:21:08 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Mar 2013 09:21:08 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364289668.9.0.0641603508832.issue17538@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Benjaman and Georg, what do the RMs feel about the doc patch?

----------
nosy: +benjamin.peterson, georg.brandl

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

From report at bugs.python.org  Tue Mar 26 10:45:29 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Mar 2013 09:45:29 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364291129.68.0.321863489581.issue17538@psf.upfronthosting.co.za>


Georg Brandl added the comment:

* I would take out the "erroneous" of "erroneous or maliciously constructed" in the disclaimers.  The odds of creating one of the "bombings" by chance are slim.

* The names of attacks in the table are quite opaque if you haven't heard of them.  They should be linked/explained.  (Also, the csv-table construction looks quite strange; a normal reST table would be preferred.)

* I don't think the warning for SAX needs to be repeated three times.

* Not sure the reader will get the reason for having both "defusedxml" and "defusedexpat".

----------

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

From report at bugs.python.org  Tue Mar 26 11:09:42 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Mar 2013 10:09:42 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364292582.84.0.0226412467039.issue17538@psf.upfronthosting.co.za>


Christian Heimes added the comment:

1. sounds fine to me

2. I can copy some text from the README.txt of defusedxml. CSV table was easier to maintain for me. What's a good tool to create and modify sphinx tables?

3. No strong opinion here, better safe than sorry?

4. IMO the warning should mention both. Perhaps a better explanation will help?

----------

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

From report at bugs.python.org  Tue Mar 26 12:36:36 2013
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 26 Mar 2013 11:36:36 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364297795.96.0.9424696659.issue17538@psf.upfronthosting.co.za>


Donald Stufft added the comment:

FWIW I put the warning on all the sax pages just because there's no way to know which page a user will go to if they are coming in via google.

----------

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

From report at bugs.python.org  Tue Mar 26 12:45:08 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Mar 2013 11:45:08 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364298308.52.0.412623319709.issue17538@psf.upfronthosting.co.za>


Georg Brandl added the comment:

2. That would be good.  For this table the "simple" rst tables should be fine:

=====  =====
head   head
=====  =====
body   body
body   body
=====  =====

3. Once per XML logical handling module/package seems quite enough.

4. The warnings only link to the section about "XML Vulnerabilities", which is good.  But that section should not only mention that the defusedxml description explains everything, but also *what the hell* it contains :)

----------

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

From report at bugs.python.org  Tue Mar 26 16:26:24 2013
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Mar 2013 15:26:24 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364311583.49.0.416770545634.issue17538@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here we go again!

----------
stage:  -> patch review
Added file: http://bugs.python.org/file29581/xmldocs3.diff

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

From report at bugs.python.org  Tue Mar 26 16:30:43 2013
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Mar 2013 15:30:43 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <1364311843.43.0.0453707420493.issue17538@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I still see "erroneous" in there... otherwise looks good to me.

----------

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

From report at bugs.python.org  Tue Mar 26 17:53:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 26 Mar 2013 16:53:33 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <3ZZz1m4JhszQ8b@mail.python.org>


Roundup Robot added the comment:

New changeset e7795a178b0a by Christian Heimes in branch '3.2':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/e7795a178b0a

New changeset 65e8ac5f073f by Christian Heimes in branch '3.3':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/65e8ac5f073f

New changeset 1ebefb6ae9a9 by Christian Heimes in branch 'default':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/1ebefb6ae9a9

New changeset e87364449954 by Christian Heimes in branch '2.7':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/e87364449954

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

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

From report at bugs.python.org  Wed Mar 27 08:14:05 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Mar 2013 07:14:05 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364368445.06.0.885089725511.issue17546@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
title: rename type returned by locals() to livedict -> Document the circumstances where the locals() dict gets updated

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

From report at bugs.python.org  Wed Mar 27 11:01:21 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Mar 2013 10:01:21 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364378481.68.0.254579441363.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Raymond, could you please get the title back? You unintentionally hijacked the issue. The "Document the circumstances where the locals() dict gets updated" is not a describing title for this issue - it is one of the possible action items. I'd prefer to see a separate issue to document the stuff that "blocks" this one. It is quite evident that this action is required, but IMHO there is not enough evidence to conclude that it will be sufficient to close this ticket.

Eric, I need more time to answer your questions.

----------

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

From report at bugs.python.org  Wed Mar 27 11:24:15 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Mar 2013 10:24:15 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364379855.68.0.633923022461.issue17546@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

The previous title, "rename type returned by locals() to livedict" did not describe the reality, since locals() returns a regular dict.
[Would you call x.__dict__ a livedict?]

So either this issue should be closed as invalid, because it's based on incorrect understandings of Python internals; or we could improve documentation about locals() in order to remove surprising behavior and (real) confusion in programmers' minds.

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

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

From report at bugs.python.org  Wed Mar 27 13:01:08 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Mar 2013 12:01:08 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364385667.99.0.167979421826.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Eric, here is the code that confirms changed behavior under trace function for both Python 2 and 3 - http://bugs.python.org/file15081/localstest.py

I agree that the documentation fix is necessary, and if you say that it is an easier sell - I tend to believe you. But with this fix the issue is still not fully covered, so it is interesting to know what builds up to the cost of renaming if we come to some common point about the type of this 'dict' from the user point of view.

----------

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

From report at bugs.python.org  Wed Mar 27 13:03:00 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Mar 2013 12:03:00 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364385780.68.0.2563031821.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Amaury, from user's point of view (I am not a core developer - I just need to troubleshoot complicated Python code) the object (the internal structure) returned by locals() has different behavior than a normal dict.

Normal dict in Python is updated by user code (which "I as a user" can see and can inspect for further troubleshooting) and for locals's dict this is not correct. 

If dict and locals's object are of the same type, I'd expect them to be interchangeable.

By proposing a documentation fix as a final remedy, please think about the entry point through which users come to this "trap".

----------

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

From report at bugs.python.org  Wed Mar 27 13:45:05 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Mar 2013 12:45:05 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364388305.27.0.470596674615.issue17546@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> Normal dict in Python is updated by user code (which "I as a user" can
> see and can inspect for further troubleshooting) and for locals's dict
> this is not correct.

Do you have an example?

----------

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

From report at bugs.python.org  Wed Mar 27 14:48:24 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Mar 2013 13:48:24 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364392104.16.0.0467132087827.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Example:

    l = locals()
    z = dict(a=5, b=3)

    lc = dict(l)
    zc = dict(z)

    print(lc == l)
    print(zc == z)

Gives:

    False
    True

----------

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

From report at bugs.python.org  Wed Mar 27 14:59:08 2013
From: report at bugs.python.org (Michael Foord)
Date: Wed, 27 Mar 2013 13:59:08 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1364392748.7.0.377690816724.issue17329@psf.upfronthosting.co.za>


Michael Foord added the comment:

For features like test skipping I would prefer to keep all the documentation together.

----------

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

From bgailer at gmail.com  Wed Mar 27 15:08:34 2013
From: bgailer at gmail.com (bob gailer)
Date: Wed, 27 Mar 2013 10:08:34 -0400
Subject: [docs] [issue17546] Document the circumstances where the
 locals() dict gets	updated
In-Reply-To: <1364392104.16.0.0467132087827.issue17546@psf.upfronthosting.co.za>
References: <1364392104.16.0.0467132087827.issue17546@psf.upfronthosting.co.za>
Message-ID: <5152FD62.3080801@gmail.com>

On 3/27/2013 9:48 AM, anatoly techtonik wrote:
> anatoly techtonik added the comment:
>
> Example:
>
>      l = locals()
>      z = dict(a=5, b=3)
>
>      lc = dict(l)
>      zc = dict(z)
>
>      print(lc == l)
>      print(zc == z)
>
> Gives:
>
>      False
>      True
Expected behavior.
lc is not another reference to locals(). It refers to a new object.
zc = ... updates locals() but not lc

-- 
Bob Gailer
919-636-4239
Chapel Hill NC


From report at bugs.python.org  Wed Mar 27 15:10:24 2013
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Mar 2013 14:10:24 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364393424.67.0.169862687659.issue17546@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This is expected: "zc = xxx" updates locals!
but not the copy.

----------

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

From report at bugs.python.org  Wed Mar 27 15:43:12 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Mar 2013 14:43:12 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364395392.68.0.805581900657.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

> "I as a user" can
> see and can inspect for further troubleshooting

This doesn't work for this example, which was your question.

I still feel like this needs further clarification. For a user this behavior is not expected. User is someone who doesn't know the internal details of Python interpreter (and may not even remember that dict can be modified by reference). If you disagree with me - try to do corridor testing and see how many people will compile it in their head and give you the right answer to this example.

----------

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

From report at bugs.python.org  Wed Mar 27 17:21:51 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Mar 2013 16:21:51 +0000
Subject: [docs] =?utf-8?q?=5Bissue17553=5D_Note_that_distutils=E2=80=99_bd?=
 =?utf-8?q?ist=5Frpm_command_is_not_used_to_build_a_CPython_rpm?=
In-Reply-To: <1364329717.96.0.312657268888.issue17553@psf.upfronthosting.co.za>
Message-ID: <1364401311.87.0.735324479467.issue17553@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Distutils, Documentation -Build
keywords: +easy
nosy: +docs at python, tarek
stage:  -> needs patch
title: python setup.py bdist_rpm is broken -> Note that distutils? bdist_rpm command is not used to build a CPython rpm
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Mar 27 17:58:07 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Mar 2013 16:58:07 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364403487.0.0.135759936409.issue17546@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for the script Anatoly.  That's pretty much what I was imagining from your description.  This definitely reinforces my belief that profiling.

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

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

From report at bugs.python.org  Wed Mar 27 18:55:53 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Mar 2013 17:55:53 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364406953.42.0.61334785695.issue17546@psf.upfronthosting.co.za>


Eric Snow added the comment:

Okay, I found it.  sys.settrace() ultimately results in the setting of tstate->use_tracing to true and sets tstate->c_tracefunc and tstate_c_traceobj (see sys_settrace() in Python/sysmodule.c and PyEval_SetTrace() in Python/ceval.c).  tstate->c_tracefunc() gets set to trace_trampoline() in Python/sysmodule.c and tstate->c_traceobj gets set to your tracing function.

When an execution frame begins, the interpreter sets up tracing.  From Python/ceval.c:1124:

/* tstate->c_tracefunc, if defined, is a
   function that will be called on *every* entry
   to a code block.  Its return value, if not
   None, is a function that will be called at
   the start of each executed line of code.
   (Actually, the function must return itself
   in order to continue tracing.)  The trace
   functions are called with three arguments:
   a pointer to the current frame, a string
   indicating why the function is called, and
   an argument which depends on the situation.
   The global trace function is also called
   whenever an exception is detected. */

So trace_trampoline() gets at the start of each block and once for each line of Python code.  Each time it calls call_trampoline() (also in Python/sysmodule.c).  You'll find that in call_trampoline(), there is a call to PyFrame_FastToLocals() just before it calls your tracing function (at that point called "callback").

When called, PyFrame_FastToLocals() updates the contents of the frame's "slow" locals (f_locals) with the values in the fast locals.  And...wait for it...f_locals is the dict that gets returned by locals().

Thus, when tracing is on, the dict returned by locals() gets updated once per block and once per line of Python code.  That is exactly what you are seeing.

When tracing is not on, PyFrame_FastToLocals() would only be called when you call locals() (inside a function).  It's interesting to note that in that case locals() will return the exact same dictionary:

>>> def f():
...     return locals() is locals()
...
>>> f()
True

Conclusion
----------

The bottom line is that the docs for locals() could stand to have a little more detail for this case (including a link to the docs for tracing at sys.settrace() or wherever).  However, the behavior here is--at present--a CPython implementation detail.  Any note would likely say as much; something like this:

.. function:: locals()

   ...

   Each call to locals() will return the same dictionary, updated to
   the contents of the current local symbol table.

   .. impl-detail::

      Under tracing and profiling in CPython, the dict returned by
      ``locals()`` will be updated at the beginning of each code block
      and at each line of code.  See :func:`sys.settrace`.

The note is really only meaningful for functions since class bodies and modules don't use fast locals and f_locals is set to f_globals (i.e. locals() == globals()).  However, that point is superfluous to the above note since it remains true either way.

----------

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

From report at bugs.python.org  Wed Mar 27 19:01:42 2013
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Mar 2013 18:01:42 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364407302.28.0.640979739963.issue17546@psf.upfronthosting.co.za>


Eric Snow added the comment:

I should also point out that the following from that note may actually also be a CPython implementation detail:

   Each call to locals() will return the same dictionary, updated to
   the contents of the current local symbol table.

We'd want to be sure that such should be expected from all implementations (since it basically adds to the language specification).  Otherwise it should also go in an impl-detail note.

----------

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

From report at bugs.python.org  Wed Mar 27 19:02:12 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Wed, 27 Mar 2013 18:02:12 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364407332.46.0.23068146037.issue17546@psf.upfronthosting.co.za>


Changes by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +nedbat

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

From report at bugs.python.org  Wed Mar 27 19:16:47 2013
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Mar 2013 18:16:47 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <3ZbcqL2dh2zQjT@mail.python.org>


Roundup Robot added the comment:

New changeset cd5c23583fa5 by Ezio Melotti in branch '3.2':
#17329: document unittest.SkipTest.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/cd5c23583fa5

New changeset 4bf2a53b53b6 by Ezio Melotti in branch '3.3':
#17329: merge with 3.2.
http://hg.python.org/cpython/rev/4bf2a53b53b6

New changeset 53cc3dbb1918 by Ezio Melotti in branch 'default':
#17329: merge with 3.3.
http://hg.python.org/cpython/rev/53cc3dbb1918

New changeset 13eb2fd70893 by Ezio Melotti in branch '2.7':
#17329: document unittest.SkipTest.  Initial patch by Zachary Ware.
http://hg.python.org/cpython/rev/13eb2fd70893

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

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

From report at bugs.python.org  Wed Mar 27 19:17:40 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 27 Mar 2013 18:17:40 +0000
Subject: [docs] [issue17329] Document unittest.SkipTest
In-Reply-To: <1362150273.59.0.386989863107.issue17329@psf.upfronthosting.co.za>
Message-ID: <1364408260.24.0.270055273542.issue17329@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Wed Mar 27 20:50:09 2013
From: report at bugs.python.org (Ashwini Chaudhary)
Date: Wed, 27 Mar 2013 19:50:09 +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: <1364413809.96.0.378603953778.issue13510@psf.upfronthosting.co.za>


Changes by Ashwini Chaudhary <monty.sinngh at gmail.com>:


----------
nosy: +montysinngh

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

From report at bugs.python.org  Thu Mar 28 03:09:24 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Mar 2013 02:09:24 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364436564.91.0.750010003627.issue17546@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've indicated that this issue supercedes issue #7083.

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

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

From report at bugs.python.org  Thu Mar 28 07:32:34 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 28 Mar 2013 06:32:34 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364452354.72.0.953077041126.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

It could be the implementation detail if locals() calls were not useful to majority of Python software, and if behavior of its returned dict did not affect the execution flow of user programs (was deterministic for users who should not care about the implementation details).

What I proposed initially is to wrap the locals(), the dict it returns and various calls that update this dict into a pattern called "livedict". This pattern has a defined behavior, and in OOP it would be encapsulated in a single object with one private method locals.__update (called by FastToLocals and other internals), and accessor method locals.todict() (name may vary) to receive a static copy of the live cache. If somebody needs access to real-time updated symbol table, it may request to work with realtime API of this locals object instead. This API is turn could have an implementation detail that transparently provided faster access to the local symbol table than copying dict into cache every time.

Wrapping this into a pattern also makes it easy to communicate details in case other Python implementation breaks this implementation detail of CPython. It may be easier for understanding to start with broken aspect of the pattern without digressing into implementation details, and read about implementation details later, than to go other way around.

----------

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

From report at bugs.python.org  Thu Mar 28 09:12:59 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Mar 2013 08:12:59 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364458379.83.0.0854619463197.issue17546@psf.upfronthosting.co.za>


Georg Brandl added the comment:

locals() being useful to the majority of Python software is news to me...

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

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

From report at bugs.python.org  Thu Mar 28 11:46:08 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Mar 2013 10:46:08 +0000
Subject: [docs] [issue616013] cPickle documentation incomplete
Message-ID: <1364467567.97.0.845903192622.issue616013@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Three years later, I don't think anyone is interested in documenting the outdated cPickle.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Thu Mar 28 12:09:21 2013
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Mar 2013 11:09:21 +0000
Subject: [docs] [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1364468961.85.0.264519988717.issue9986@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Duplicate of #4173.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> PDF documentation: long verbatim lines are cut off at right hand side

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

From report at bugs.python.org  Thu Mar 28 13:18:23 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Thu, 28 Mar 2013 12:18:23 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364473103.04.0.643122825767.issue17546@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Changing the type of the locals() return isn't the right way to solve this problem.  Better docs is the way to do it.  If someone is calling locals(), they should read the docs.  Examining the type of values is discouraged in Python, we shouldn't expect people to discover nonintuitive behavior because the type has been artificially changed to "livedict".

----------

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

From report at bugs.python.org  Thu Mar 28 15:25:02 2013
From: report at bugs.python.org (Paul Moore)
Date: Thu, 28 Mar 2013 14:25:02 +0000
Subject: [docs] [issue15867] make importlib documentation easier to use
In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za>
Message-ID: <1364480702.63.0.862063689941.issue15867@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +pmoore

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

From report at bugs.python.org  Thu Mar 28 17:00:23 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2013 16:00:23 +0000
Subject: [docs] [issue17566] Document that importlib.abc.Loader.module_repr
	is	abstract and thus needed by various other ABCs
Message-ID: <1364486422.93.0.992071692104.issue17566@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Various places list explicitly what abstractmethods are needed to make an ABC work in importlib.abc. Unfortunately when module_repr() came into existence it was made abstract but no other documentation was updated to point out this fact.

----------
assignee: docs at python
components: Documentation
messages: 185453
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document that importlib.abc.Loader.module_repr is abstract and thus needed by various other ABCs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 28 17:04:11 2013
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2013 16:04:11 +0000
Subject: [docs] [issue17567] Clarify
	importlib.abc.PathEntryFinder.find_loader() docs
Message-ID: <1364486651.54.0.521676412907.issue17567@psf.upfronthosting.co.za>


New submission from Brett Cannon:

"An empty list can be used for portion to signify the loader is not part of a package" should have a "namespace" mention in there at least. Links to the namespace loader or namespace package docs would also help.

----------
assignee: docs at python
components: Documentation
messages: 185454
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify importlib.abc.PathEntryFinder.find_loader() docs
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Mar 28 23:51:37 2013
From: report at bugs.python.org (Eric Snow)
Date: Thu, 28 Mar 2013 22:51:37 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364511097.21.0.681852864421.issue17546@psf.upfronthosting.co.za>


Eric Snow added the comment:

> Changing the type of the locals() return isn't the right way to solve
> this problem.  Better docs is the way to do it.  If someone is calling
> locals(), they should read the docs.  Examining the type of values is
> discouraged in Python, we shouldn't expect people to discover
> nonintuitive behavior because the type has been artificially changed
> to "livedict".

+1

Issue #7083 was created to promote a semantic change (ultimately) and it was rejected in deference to a doc change.  That's part of why this ticket was changed to focus on documentation.

My only concern is that locals() has some pretty heavy implementation specifics, so any doc change needs to respect that (or be part of an effort to tighten the spec for locals()).

----------

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

From report at bugs.python.org  Fri Mar 29 01:59:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Mar 2013 00:59:22 +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: <1364518762.47.0.187665973976.issue13510@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.2

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

From report at bugs.python.org  Fri Mar 29 03:02:30 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 29 Mar 2013 02:02:30 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
In-Reply-To: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>
Message-ID: <3ZcR6F1mqszQcY@mail.python.org>


Roundup Robot added the comment:

New changeset 80d7545594ca by Ezio Melotti in branch '2.7':
#17438: add links to the conversion tables in dump(s)/load(s).
http://hg.python.org/cpython/rev/80d7545594ca

New changeset e76952bd4fa5 by Ezio Melotti in branch '3.3':
#17438: add links to the conversion tables in dump(s)/load(s).
http://hg.python.org/cpython/rev/e76952bd4fa5

New changeset 5dcd7ee0716a by Ezio Melotti in branch 'default':
#17438: merge with 3.3.
http://hg.python.org/cpython/rev/5dcd7ee0716a

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

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

From report at bugs.python.org  Fri Mar 29 03:03:12 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Mar 2013 02:03:12 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
In-Reply-To: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>
Message-ID: <1364522592.18.0.311902442198.issue17438@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Fri Mar 29 03:52:23 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 29 Mar 2013 02:52:23 +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: <1364525543.5.0.958136421368.issue13510@psf.upfronthosting.co.za>


Kushal Das added the comment:

Working on a patch for this.

----------
nosy: +kushaldas

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

From report at bugs.python.org  Fri Mar 29 04:27:08 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Mar 2013 03:27:08 +0000
Subject: [docs] [issue15867] make importlib documentation easier to use
In-Reply-To: <1346894563.49.0.339877810223.issue15867@psf.upfronthosting.co.za>
Message-ID: <1364527628.12.0.963896325056.issue15867@psf.upfronthosting.co.za>


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


----------
nosy: +barry

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

From report at bugs.python.org  Fri Mar 29 06:15:46 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 29 Mar 2013 05:15:46 +0000
Subject: [docs] [issue17438] json.load docs should mention that it always
	return	unicode
In-Reply-To: <1363435905.53.0.015044625796.issue17438@psf.upfronthosting.co.za>
Message-ID: <1364534146.04.0.111961383583.issue17438@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Thanks for the fix. ;)

----------

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

From report at bugs.python.org  Fri Mar 29 07:08:32 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 29 Mar 2013 06:08:32 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364537312.44.0.427161091149.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Ok. Maybe I proposed the solution too early. I am fine with doc fix, but given the previous experience I have doubts it will happen. Maybe opening a wiki page with a current draft can help:

   http://wiki.python.org/moin/Locals
    or better
   http://piratepad.net/locals

Describing implementation details is necessary, but they should include a recommendation how to work with locals safely and avoid hitting yourself in the foot if you don't want to read about internals. For that I propose "if you are not interested in implementation details, always copy locals() to dict to avoid potential problems with auto-updating behavior. This is also guaranteed to work with other Python implementations." Is that ok?

----------

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

From report at bugs.python.org  Fri Mar 29 08:54:26 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 29 Mar 2013 07:54:26 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
Message-ID: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

There are 2 broken links at the beginning of Lib/datetime.py.

One other thing, maybe "prototype implemented in Python" is an outdated and/or needless statement?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 185494
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: broken links on Lib/datetime.py docstring
versions: Python 3.4

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

From report at bugs.python.org  Fri Mar 29 21:56:14 2013
From: report at bugs.python.org (paul j3)
Date: Fri, 29 Mar 2013 20:56:14 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1364590574.24.0.02037954914.issue14191@psf.upfronthosting.co.za>


paul j3 added the comment:

Glenn
I looked at your t18a.py test case

    parser = ArgumentParser()
    parser.add_argument('--foo', dest='foo')
    parser.add_argument('--bar', dest='bar')
    parser.add_argument('foz')
    parser.add_argument('baz', nargs='*')

and parse variations on 'a b c d --foo x --bar 1'

I think your main problem is with the 'baz', nargs='*'.  If nargs was changed to '+', 'a --foo x b c d --bar 1' would work, returning {foz='a', bar=['b','c','d']}.

argparse alternates between consuming positional and optionals until it runs out of arguments or argument strings.  But with '*', both 'foz' and 'baz' are consumed with the first set of positional strings {foz='a', baz=[]}.  When it gets to 'b c d' there are no more positional arguments to consume, so they get put into 'extras'.

With nargs='+', 'a b --foo x c d --bar 1' would assign {foz='a', baz=[b]}, and extras=['c','d'].

So while optionals can be interspersed with positionals, they can't be placed within the set of strings intended for one positional. That seems to me to very reasonable (why break up 'b c d'?).  And as your file demonstrates, you can fall back on parse_known_args to handle the extras.

----------
nosy: +paul.j3

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

From report at bugs.python.org  Fri Mar 29 21:57:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 29 Mar 2013 20:57:20 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <1364590639.98.0.94227145758.issue17571@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

This is the module docstring:
"""Concrete date/time and related types -- prototype implemented in Python.

See http://www.zope.org/Members/fdrake/DateTimeWiki/FrontPage

See also http://dir.yahoo.com/Reference/calendars/

For a primer on DST, including many current DST rules, see
http://webexhibits.org/daylightsaving/

For more about DST than you ever wanted to know, see
ftp://elsie.nci.nih.gov/pub/

Sources for time zone and DST data: http://www.twinsun.com/tz/tz-link.htm

This was originally copied from the sandbox of the CPython CVS repository.
Thanks to Tim Peters for suggesting using it.
"""

The first link is broken, the following two links look like more or less random page that can be found by googling, the .gov site might have been useful but it's broken, and the last link looks OK.
I think it would be better to replace the whole docstring with something more descriptive.  I'm not sure those links should be kept at all.

----------
nosy: +belopolsky, ezio.melotti, tim_one

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

From report at bugs.python.org  Fri Mar 29 22:15:58 2013
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 29 Mar 2013 21:15:58 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <1364591758.69.0.795408622281.issue17571@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

Let's just update the docstring:

"""Concrete date/time and related types.

See also http://dir.yahoo.com/Reference/calendars/

For a primer on DST, including many current DST rules, see
http://webexhibits.org/daylightsaving/

Sources for time zone and DST data: http://www.twinsun.com/tz/tz-link.htm

This was originally copied from the sandbox of the CPython CVS repository.
Thanks to Tim Peters for suggesting using it.
"""

----------
nosy: +fdrake

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

From report at bugs.python.org  Fri Mar 29 22:56:39 2013
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Mar 2013 21:56:39 +0000
Subject: [docs] [issue17571] broken links on Lib/datetime.py docstring
In-Reply-To: <1364543666.79.0.123809819447.issue17571@psf.upfronthosting.co.za>
Message-ID: <1364594199.04.0.422388028691.issue17571@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Shouldn't we link to IANA for timezones information?

http://www.iana.org/time-zones/repository/tz-link.html

----------

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

From report at bugs.python.org  Fri Mar 29 23:25:11 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Mar 2013 22:25:11 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
Message-ID: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

operator.index() is just a thin wrapper around PyNumber_Index().  The documentation for operator.index() claims that it is equivalent to calling obj.__index__() but for subclasses of int, this is not true.  In fact, PyNumber_Index() first does (e.g. in Python 3.3) a PyLong_Check() and if that succeeds, the original object is returned *without* doing the moral equivalent in C of calling obj.__index__().  An example:

class myint(int):
    def __index__(self):
        return int(self) + 1

>>> x = myint(7)
>>> x.__index__()
8
>>> from operator import index
>>> index(x)
7

The C API documents PyNumber_Index() as: "Returns the o converted to a Python int on success or NULL with a TypeError exception raised on failure."

Because this has been the behavior of PyNumber_Index() since at least 2.7 (I didn't check farther back), this probably cannot be classified as a bug deserving to be fixed in the code for older Pythons.  It might be worth fixing for Python 3.4, i.e. by moving the index check before the type check.  In the meantime, this is probably a documentation bug.

The C API implies, but should be clearer that if o is an int subtype (int and long in Python 2), it is returned unchanged.  The operator.index() documentation should be amended to describe this behavior for int/long subclasses.

A different alternative would be to leave PyNumber_Index() unchanged, but with the doco fix, and to augment operator.index() to do the PyIndex_Check() first, before calling PyNumber_Index().  That's a little more redundant, but would provide the documented behavior without changing the C API.

----------
assignee: docs at python
components: Documentation
messages: 185522
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: PyNumber_Index() is not int-subclass friendly
type: behavior
versions: 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/issue17576>
_______________________________________

From report at bugs.python.org  Fri Mar 29 23:25:33 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Mar 2013 22:25:33 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1364595933.15.0.0814755470757.issue17576@psf.upfronthosting.co.za>


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


----------
title: PyNumber_Index() is not int-subclass friendly -> PyNumber_Index() is not int-subclass friendly (or operator.index() docos lie)

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

From report at bugs.python.org  Fri Mar 29 23:29:38 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Mar 2013 22:29:38 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1364596178.4.0.170619927624.issue17576@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

You also end up with this nice bit of inconsistency:

>>> x = myint(7)
>>> from operator import index
>>> range(10)[6:x]
range(6, 7)
>>> range(10)[6:x.__index__()]
range(6, 8)
>>> range(10)[6:index(x)]
range(6, 7)
>>> 

Granted, it's insane to have __index__() return a different value like this, but in my specific use case, it's the type of object returned from operator.index() that's the problem.  operator.index() returns the subclass instance while obj.__index__() returns the int.

(The use case is the IntEnum of PEP 435.)

----------

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

From report at bugs.python.org  Sat Mar 30 01:29:36 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 30 Mar 2013 00:29:36 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1364603376.41.0.418321948666.issue17576@psf.upfronthosting.co.za>


Eric Snow added the comment:

Would it be okay to do a check on __index__ after the PyLong_Check() succeeds?  Something like this:

    if (PyLong_Check(item) &&
        item->ob_type->tp_as_number->nb_index == PyLong_Type.tp_as_number->nb_index) {
        Py_INCREF(item);
        return item;
    }

This is something Nick and I were talking about at the sprints regarding fast paths in the abstract API (for mappings and sequences in our case).

----------
nosy: +eric.snow

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

From report at bugs.python.org  Sat Mar 30 01:36:57 2013
From: report at bugs.python.org (Alex Gaynor)
Date: Sat, 30 Mar 2013 00:36:57 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1364603817.23.0.648576968008.issue17576@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

In my opinion that should use PyLong_CheckExact

----------
nosy: +alex

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

From report at bugs.python.org  Sat Mar 30 01:39:42 2013
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 30 Mar 2013 00:39:42 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364603376.41.0.418321948666.issue17576@psf.upfronthosting.co.za>
Message-ID: <20130329203938.6a53389b@limelight.wooz.org>


Barry A. Warsaw added the comment:

On Mar 30, 2013, at 12:29 AM, Eric Snow wrote:

>Would it be okay to do a check on __index__ after the PyLong_Check()
>succeeds?  Something like this:
>
>    if (PyLong_Check(item) &&
>        item->ob_type->tp_as_number->nb_index == PyLong_Type.tp_as_number->nb_index) {
>        Py_INCREF(item);
>        return item;
>    }
>
>This is something Nick and I were talking about at the sprints regarding fast
>paths in the abstract API (for mappings and sequences in our case).

I think that would work, yes.  With this extra check, overriding __index__()
in the subclass should fail this condition and fall back to the
PyIndex_Check() clause.

----------

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

From report at bugs.python.org  Sat Mar 30 03:44:53 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Mar 2013 02:44:53 +0000
Subject: [docs] [issue15331] Codecs docs should explain that the
	bytes-bytes	shorthand aliases are missing
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1364611493.68.0.456567604182.issue15331@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Mar 30 04:56:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Mar 2013 03:56:31 +0000
Subject: [docs] [issue17539] Use the builtins module in the
	unittest.mock.patch	example
In-Reply-To: <1364191984.35.0.104161135895.issue17539@psf.upfronthosting.co.za>
Message-ID: <3Zd5bM0kxPzNZg@mail.python.org>


Roundup Robot added the comment:

New changeset b0c0a03b8033 by Ezio Melotti in branch '3.3':
#17539: fix MagicMock example.  Patch by Berker Peksag.
http://hg.python.org/cpython/rev/b0c0a03b8033

New changeset d5d6209745ab by Ezio Melotti in branch 'default':
#17539: merge with 3.3.
http://hg.python.org/cpython/rev/d5d6209745ab

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

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

From report at bugs.python.org  Sat Mar 30 04:57:07 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 30 Mar 2013 03:57:07 +0000
Subject: [docs] [issue17539] Use the builtins module in the
	unittest.mock.patch	example
In-Reply-To: <1364191984.35.0.104161135895.issue17539@psf.upfronthosting.co.za>
Message-ID: <1364615827.65.0.034379979735.issue17539@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report and the patch!

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

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

From report at bugs.python.org  Sat Mar 30 06:19:26 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2013 05:19:26 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364620766.15.0.81171593122.issue17546@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/issue17546>
_______________________________________

From report at bugs.python.org  Sat Mar 30 06:34:08 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2013 05:34:08 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364621648.5.0.936999282942.issue17546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

After the last exchange on #7083, Guido emailed me that I could/should revised the doc a bit, but he said he did *not* want the details explained because he regards them as CPython implementation details and not part of the language definition. I have not done so yet because of other issues, especially the Idle PEP and related discussion. What is needed is something like

"The relationship between the local namespace and the locals dict is undefined between calls to locals(). Changes to either may or may not be propagated to the other."

Perhaps add "The dict returned by locals() is intended to be used immediately, either for introspection or for passing on to functions such as eval() and exec()." and even "It is not intended to be saved and used later."

What I have not figured out yet is how to integrate the above with the current text.

----------

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

From report at bugs.python.org  Sat Mar 30 08:19:51 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 30 Mar 2013 07:19:51 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1364627991.29.0.953238235916.issue15533@psf.upfronthosting.co.za>


Ned Deily added the comment:

Note, that test_executable_without_cwd now fails when the tests are run from an installed Python.  See Issue17046.

----------

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

From report at bugs.python.org  Sat Mar 30 09:25:44 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 30 Mar 2013 08:25:44 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1364631944.54.0.48100203165.issue17576@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Sat Mar 30 13:09:37 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 30 Mar 2013 12:09:37 +0000
Subject: [docs] [issue1944] Documentation for PyUnicode_AsString (et al.)
	missing.
In-Reply-To: <1201415203.65.0.272410099804.issue1944@psf.upfronthosting.co.za>
Message-ID: <1364645377.35.0.326877424936.issue1944@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is it worth applying the patch given the complete rewrite of unicode for 3.3 via PEP393?

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

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

From report at bugs.python.org  Sat Mar 30 13:50:29 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 30 Mar 2013 12:50:29 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1364647829.71.0.942781858092.issue6627@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg116747 suggests wording for a doc patch.  Could this be applied and this issue closed?  msg117029 talks about a potential feature request.  Was this ever discussed?

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

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

From report at bugs.python.org  Sat Mar 30 15:00:03 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sat, 30 Mar 2013 14:00:03 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364652003.25.0.242332817007.issue17546@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

> them as CPython implementation details and not part of the language definition

What is the formal language definition of locals() then? What behavior and functionality of locals() should be supported by all Python implementations? For a potential language developer, what should locals() calls return to be compatible with this Python definition?

----------

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

From report at bugs.python.org  Sat Mar 30 15:37:33 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Mar 2013 14:37:33 +0000
Subject: [docs] [issue17538] Document XML Vulnerabilties
In-Reply-To: <1364179286.95.0.543859032346.issue17538@psf.upfronthosting.co.za>
Message-ID: <3ZdMq01vLWzMtb@mail.python.org>


Roundup Robot added the comment:

New changeset 91bb6d7ae833 by Christian Heimes in branch '2.7':
Issue 17538: Document XML vulnerabilties
http://hg.python.org/cpython/rev/91bb6d7ae833

----------

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

From report at bugs.python.org  Sat Mar 30 16:16:52 2013
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 30 Mar 2013 15:16:52 +0000
Subject: [docs] [issue9305] Don't use east/west of UTC in date/time
	documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1364656612.48.0.493853389759.issue9305@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Well, we have a patch and it's been discussed here and on #7229, so can we take this forward?

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

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

From report at bugs.python.org  Sat Mar 30 16:28:23 2013
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 30 Mar 2013 15:28:23 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364657303.11.0.662702916044.issue17546@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

I would say it something like this:

"The dictionary returned by locals() is an accurate snapshot of the local namespace at the time it is called.  After the call returns, changes to one may or may not be reflected in the other.  The dictionary may change unpredictably after the call, and how it does is implementation-specific.    Holding a reference to the dictionary may produce surprising effects."

----------

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

From report at bugs.python.org  Sat Mar 30 17:27:29 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2013 16:27:29 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364660849.18.0.88110748065.issue17546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I also think 'free variable' should be replace by 'nonlocal name'.

----------

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

From report at bugs.python.org  Sat Mar 30 20:31:02 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Mar 2013 19:31:02 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364671862.75.0.357477705095.issue17546@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Terry: agreed.

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

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

From report at bugs.python.org  Sat Mar 30 22:53:51 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Mar 2013 21:53:51 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364680431.32.0.403935787504.issue17546@psf.upfronthosting.co.za>


R. David Murray added the comment:

The problem with using 'nonlocal' is that it would naturally be read as 'those names referenced in a nonlocal statement', which I don't think is the case.  Maybe 'non-local', to differentiate it from the keyword?

I'm attaching a patch incorporating my understanding of the suggestions made so far.

----------
keywords: +patch
nosy: +r.david.murray
Added file: http://bugs.python.org/file29614/locals_doc.patch

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

From report at bugs.python.org  Sun Mar 31 00:23:25 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2013 23:23:25 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict	gets	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364685805.56.0.379339592028.issue17546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

/non-local/Non-local/ If we add the hyphen, perhaps we should add 'non-global' also.

Thanks for the concrete draft. It is definitely an improvement.

The last sentence is somewhat redundant with the second. The problem with the last sentence is that it only said that changes to the dict might not propagate back the the namespace, while is is also true that changes to the namespace might or might not propagate to the dict. The new second sentence says both. In addition, I somewhat disagree with 'should not modify'. A person could have a perfectly good reason to do so, but they should not expect propagation of the changes. So I am tempted to drop the last sentence. On the other hand, 'undefined' should be somewhere.

----------

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

From report at bugs.python.org  Sun Mar 31 05:51:41 2013
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 31 Mar 2013 03:51:41 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364701901.6.0.392073956768.issue17583@psf.upfronthosting.co.za>


Roger Serwy added the comment:

I agree that improving IDLE's docs would make it easier to learn and use. There is a tangentially related issue: #16893.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, roger.serwy
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Sun Mar 31 07:03:38 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Mar 2013 05:03:38 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364706218.66.0.637300961982.issue17546@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  Perhaps the last sentence could be "... because changes to the local dict propagating to the local namespace cannot be relied upon to either happen or not happen".  That would make it less redundant, since it would essentially be referencing the previous statement in the specific case of the consequences of modification.

The original included the caution against modifying it, and I think it is valid because of the inconsistent behavior.  Perhaps it could be weakened to "it is not a good idea to modify"?

----------
title: Document the circumstances where the locals() dict gets	updated -> Document the circumstances where the locals() dict get updated

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

From report at bugs.python.org  Sun Mar 31 07:36:25 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 31 Mar 2013 05:36:25 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364706218.66.0.637300961982.issue17546@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+iHNspSZgSv4b_tYtM1easB2pYeumx6RLaZ3h_3--RCw@mail.gmail.com>


anatoly techtonik added the comment:

> ... cannot be relied upon to either happen or not happen...

IMHO this phrase is from Advanced English course.

> The original included the caution against modifying it, and I think it is
valid because of the inconsistent behavior.
> Perhaps it could be weakened to "it is not a good idea to modify"?

Ambiguity already adds fear and uncertainty. Just explaining the
consequences would be good style for the technical doc.

----------

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

From report at bugs.python.org  Sun Mar 31 11:09:36 2013
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 31 Mar 2013 09:09:36 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
	dict get	updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1364720976.68.0.103496427035.issue17546@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +flox

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

From report at bugs.python.org  Sun Mar 31 12:17:35 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 31 Mar 2013 10:17:35 +0000
Subject: [docs] [issue17586] fix typo in contextlib.rst
Message-ID: <1364725055.77.0.738378154281.issue17586@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: typo.diff
keywords: patch
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: fix typo in contextlib.rst
versions: Python 3.4
Added file: http://bugs.python.org/file29619/typo.diff

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

From report at bugs.python.org  Sun Mar 31 13:38:47 2013
From: report at bugs.python.org (Amit Saha)
Date: Sun, 31 Mar 2013 11:38:47 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364729927.94.0.40617292956.issue17583@psf.upfronthosting.co.za>


Amit Saha added the comment:

Hi Todd, 

I just signed the Python contributor agreement electronically.

You probably missed the link to the rSt source in my original report. Here it is [1]. I would want this HOWTO to cover all aspects of IDLE from an user's perspective. 

I have some ideas about what to add, but I would like to hear from you as well.

Thanks.

[1] http://amitsaha.github.com/site/notes/_sources/articles/idle/article.txt

----------

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

From report at bugs.python.org  Sun Mar 31 18:26:46 2013
From: report at bugs.python.org (Todd Rovito)
Date: Sun, 31 Mar 2013 16:26:46 +0000
Subject: [docs] [issue17583] IDLE HOWTO
In-Reply-To: <1364685156.29.0.769214841654.issue17583@psf.upfronthosting.co.za>
Message-ID: <1364747206.49.0.568311104337.issue17583@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Yes I missed the link sorry.  Can you add the rst file to Doc/faq in the tip of the repository then do a hg diff and post the patch as an attachment to this issue?  At that point I will review and send any changes or edits with the review system.  Others can suggest changes as well.

----------

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

From report at bugs.python.org  Sun Mar 31 21:39:15 2013
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 31 Mar 2013 19:39:15 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
Message-ID: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>


New submission from Larry Hastings:

CPython API "functions" implemented as macros can expand into either
rvalues or statements.  Most expand into statements (often using the
do {} while (0) syntactic sugar trick), but occasionally they're legal
as rvalues.

As of this writing Py_INCREF works as an rvalue.  But discussion on
another tracker issue (#17206) proposes changing the implementation
in such a way that it will only be usable as a statement.  Although
it's mildly unlikely, it's certainly possible that this will break
somebody's code.

I propose that the documentation make an explicit ruling on whether
macros are usable as rvalues or as statements.  Perhaps a blanket
statement would suffice, "all macros are only supported for use as
statements except where explicitly noted", then annotate specific
macros that are supported for use as rvalues.  Though that raises the
question of acknowledging in the documentation that some things are
macros--I think the documentation glosses over that fact right now.

Note: I added you three (Georg, Mark, Martin) as I thought you might
have an opinion on this one way or the other.  If you're not interested,
my apologies.

----------
assignee: docs at python
components: Documentation
messages: 185646
nosy: Mark.Shannon, docs at python, georg.brandl, larry, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: Make documentation about  macros in C API explicit about rvalue vs statement
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Sun Mar 31 21:57:15 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 31 Mar 2013 19:57:15 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1364759834.96.0.863248902608.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Ezio, would you like to commit this?

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

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

From report at bugs.python.org  Sun Mar 31 22:01:33 2013
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 31 Mar 2013 20:01:33 +0000
Subject: [docs] [issue15964] SyntaxError in asdl when building 2.7 with
	system Python	3
In-Reply-To: <1347978379.29.0.810502621141.issue15964@psf.upfronthosting.co.za>
Message-ID: <1364760092.98.0.111440368967.issue15964@psf.upfronthosting.co.za>


Roger Serwy added the comment:

I use Arch Linux which has /usr/bin/python as 3.3.0. I can confirm that "touch Include/Python-ast.h Python/Python-ast.c" fixes the problem. 

But would it have been simpler just to convert the print statements to functions so that asdl_c.py would work with Python 3 as well as Python 2?

----------
nosy: +roger.serwy

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

From report at bugs.python.org  Sun Mar 31 22:25:39 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 31 Mar 2013 20:25:39 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1364761539.27.0.101238794031.issue17589@psf.upfronthosting.co.za>


Georg Brandl added the comment:

There are also some macros usable as lvalues, such as Py_REFCNT or Py_SIZE (they aren't documented at all currently).

Anyway, documenting as statement-only unless explicitly stated differently is fine with me.

----------

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

From report at bugs.python.org  Sun Mar 31 22:40:45 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Mar 2013 20:40:45 +0000
Subject: [docs] [issue17589] Make documentation about macros in C API
	explicit about	rvalue vs statement
In-Reply-To: <1364758755.79.0.998719447408.issue17589@psf.upfronthosting.co.za>
Message-ID: <1364762445.03.0.804408849458.issue17589@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Py_INCREF usable as an rvalue sounds more like an accident than a deliberate feature, and it would be IMO counter-productive to codify this behaviour in the docs.

As for the lvalue usage of Py_REFCNT and Py_SIZE, I think it would be better if it were limited to CPython core. But arguably writers of extension types may want to mutate the size field of a varsize object.

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

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

From bernoth at dresearch-fe.de  Mon Mar 25 09:32:39 2013
From: bernoth at dresearch-fe.de (Erik Bernoth)
Date: Mon, 25 Mar 2013 09:32:39 +0100
Subject: [docs] Preparing a Change for Requirementshandling in Python
	projects
Message-ID: <CAJqWTsLq9URMOwusG2KT2YMw-PEr9Kd9jVcKrBe=VUjS8yj7qQ@mail.gmail.com>

Hi Documenters,

some weeks ago I discussed a way to handle installation reqiurements with
the Distutils people [1] and found that the working solution is *not*
described in the documentation [2,3], while what is described in the
documentation is rather confusing and doesn't work. Thus I want to change
that documentation! But because it's my first change to an important
project like Python, I want to make sure about the way to get there. I'd
like your help on this first and hopefully not last change I want to make
to the Python docs!


Prerequisits I bring with me
======================

 * Acceptable Skills with Python (and other programming languages)
 * Wrote different parts of the documentation of a small open source
framework in Sphinx before
 * Ability to create patch files with git, and thus probably also with hg
 * I've read the devguide [4] until and including chapter 7, which led me
to this mailing list
 * An idea about the change I want to make
 * The willingness to see this change to a successful end, even if it takes
days or weeks (actually I already spent some days preparing!)
 * Downloaded and built the CPython 3.4 binary and docs


Challenges for me
===============

 * English isn't my mothertounge (it's German)
 * no plan how to put everything into the different branches yet (verified
the same documentation exists for all w.i.p. python branches)
 * Haven't written the patch file yet


 Problem Details
=============

The chapter 2.4 [2,3] of the distutils documentation has the following
mistakes/problems/unclearness:
 * It describes the usage of an parameter `requires` to the setup()
function, which should tell pip which other packages it needs to install
for the current project to work. That doesn't work.
 * There is another parameter called "install_requires" which does exactly,
what you would expect. If you install the current project to your
virtualenv, then the other packages are downloaded from the pypi server as
well. This one is not mentioned at all.
 * the application of either parameter is pretty much the same, but it is
explained with a lot of text instead of a simple example. The concept isn't
hard to grasp, but the documentation about it is.
 * Some details, like setting spaces at the right points, are not described
precisely enough and are open to interpretation by the learning reader.
Experimenting while learning is nothing people really like to do. They want
to get a clear guide and an example, implement it and see a working result.



Idea for the new version
====================

 1. The list of what you can do (already exists, but change "requires" and
"install_requires"): require, provide and obsolete and a short explanation
what each of them does.
 2. A short example which has all three relationships preferably with a
small diagram (shouldn't be too confusing, because all should be handled
the same way).
 3. The implementation of the corresponding setup() function.
 4. A description of what exactly happens in the setup function.
 5. A description of the grammatical details
 6. A detailed explanation about how to deviate from the example


What I want from you
==================
1) Do you like the idea?
2) Do you agree with the problem?
3) How would you handle the existing but seemingly not working paramter
"requires" and tell the user that he should use "install_requires" instead?
4) How do I go about changing this page for every version? I'd like to
start it for the current default branch and backtrace my way afterwards.
5) Anything unclear?

Cheers,
Erik




[1] http://mail.python.org/pipermail/distutils-sig/2013-February/019743.html
[2]
http://docs.python.org/2.7/distutils/setupscript.html#relationships-between-distributions-and-packages
[3]
http://docs.python.org/3.4/distutils/setupscript.html#relationships-between-distributions-and-packages
[4] http://docs.python.org/devguide/

-- 
Mit freundlichen Gr??en / Kind Regards
Erik Bernoth
Student Assistant, Bachelor of Engineering, Telematics

DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, D-10319 Berlin, Germany
Tel: +49 (30) 515932 - 220
Fax: +49 (30) 515932 - 77
mailto:bernoth at dresearch-fe.de <mailadresse at dresearch-fe.de>
http://www.dresearch-fe.de
Amtsgericht Berlin Charlottenburg, HRB: 130120 B
Ust.-IDNr. DE273952058; WEEE Reg.-Nr. DE 60230558
Gesch?ftsf?hrer: Dr. Michael Weber, Werner M?gle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130325/838ab3fa/attachment-0001.html>

From chriswallis at littlewindsor.co.uk  Tue Mar 26 00:24:01 2013
From: chriswallis at littlewindsor.co.uk (Christopher Wallis)
Date: Mon, 25 Mar 2013 23:24:01 +0000
Subject: [docs] Fwd:  Documentation bug?
In-Reply-To: <CAE5PLj7AXww1KiObCW7zR5x5Tgn4L0+3FM+UtVqSz9=p+HiiRw@mail.gmail.com>
References: <CAE5PLj6gPXi330Hrx5ZviUG8nM=7d38CJgVYX7=TPGj8o+niwQ@mail.gmail.com>
	<514F36A3.8060908@gmail.com>
	<CAE5PLj7AXww1KiObCW7zR5x5Tgn4L0+3FM+UtVqSz9=p+HiiRw@mail.gmail.com>
Message-ID: <CAE5PLj4sfAhsTfaQGXYQssFjJmYeG5vTXuwaVTnHu4fjuSgXJw@mail.gmail.com>

---------- Forwarded message ----------
From: Christopher Wallis <chriswallis at littlewindsor.co.uk>
Date: Mon, Mar 25, 2013 at 11:00 AM
Subject: Re: [docs] Documentation bug?
To: bob gailer <bgailer at gmail.com>


Hi Bob,
Thanks for taking the trouble to reply. I can't try your solution right
now, 'cos my Python machine has just been knocked out by a lightning
strike; but I bet you're right.
Cheers
Chris


On Sun, Mar 24, 2013 at 5:23 PM, bob gailer <bgailer at gmail.com> wrote:

>  On 3/10/2013 3:37 PM, Christopher Wallis wrote:
>
>
>   If I enter this code into the interpreter, I get a syntax error at print w, len(w)
>
>   You are probably running a Python 3 version and looking at Python 2
> documentation.
>
> The print statement changed to a function in 3. Try:
>
> print(w, len(w))
>
>
> --
> Bob Gailer919-636-4239
> Chapel Hill NC
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130325/08a9f897/attachment-0001.html>

From E.F.RiosSoltero at tudelft.nl  Tue Mar 26 20:20:43 2013
From: E.F.RiosSoltero at tudelft.nl (Edgar Fco. Rios Soltero)
Date: Tue, 26 Mar 2013 20:20:43 +0100
Subject: [docs] Small typo in documentation
In-Reply-To: <5151F4B4.8060904@tudelft.nl>
References: <5151F4B4.8060904@tudelft.nl>
Message-ID: <5151F50B.1060803@tudelft.nl>

My mistake. There is no such typo


Edgar

--
TU Delft
Faculty of industrial design engineering
Product engineering section
Landbergstraat 15, Delft, 2628CE, Nederland
Office number: 32 B-0-320
Phone number +31 015 27 83512

On 26/03/13 20:19, Edgar Fco. Rios Soltero wrote:
> Python 3.2.3 documentation ?
> The Python Tutorial ?
> 3. An Informal Introduction to Python ?
> 3.1.4. Lists
>
> It reads:
>
>  >>> # Replace some items:
> ... a[0:2] = [1, 12]
>  >>> a
> [1, 12, 123, 1234]
>
>
> It should be:
>  >>> a[0:2] = [1, 12]
>  >>> a
> [1, 12, 100, 1234]
>
>
> Edgar

From E.F.RiosSoltero at tudelft.nl  Tue Mar 26 20:19:16 2013
From: E.F.RiosSoltero at tudelft.nl (Edgar Fco. Rios Soltero)
Date: Tue, 26 Mar 2013 20:19:16 +0100
Subject: [docs] Small typo in documentation
Message-ID: <5151F4B4.8060904@tudelft.nl>

Python 3.2.3 documentation ?
The Python Tutorial ?
3. An Informal Introduction to Python ?
3.1.4. Lists

It reads:

 >>> # Replace some items:
... a[0:2] = [1, 12]
 >>> a
[1, 12, 123, 1234]


It should be:
 >>> a[0:2] = [1, 12]
 >>> a
[1, 12, 100, 1234]


Edgar
-- 
--
TU Delft
Faculty of industrial design engineering
Product engineering section
Landbergstraat 15, Delft, 2628CE, Nederland
Office number: 32 B-0-320
Phone number +31 015 27 83512

From ortwein at atix.de  Wed Mar 27 10:15:46 2013
From: ortwein at atix.de (Lucas Ortwein)
Date: Wed, 27 Mar 2013 10:15:46 +0100 (CET)
Subject: [docs] Option Parser
In-Reply-To: <1657391554.503775.1364375463868.JavaMail.root@webmail2.atix.de>
Message-ID: <1135415131.503809.1364375746699.JavaMail.root@webmail2.atix.de>

Hello,
I've found a sensefull thing, that should be added to the python documentation (if its possible).
The thing i mean is for the Option Parser Documentation.
It's that, that you can write -- infront of the first negative number and than it wouldnt be evaluated as an option.


Kind Regards, 

Lucas Ortwein
 
______________________________________________________________________________


Lucas Ortwein

(IT-Consultant)

Telefon: +49 (0)89 452 35 38-120
Fax: +49 (0)89 990 17 66-290
E-Mail: ortwein at atix.de
XING: www.xing.com/profile/Lucas_Ortwein

ATIX Informationstechnologie und Consulting AG | Einsteinstra?e 10 |
85716 Unterschlei?heim | www.atix.de

Enterprise Linux einfach online kaufen: www.linux-subscriptions.com

Registergericht: Amtsgericht M?nchen, Registernummer: HRB 168930, USt.-Id.:
DE209485962 | Vorstand: Thomas Merz (Vors.), Marc Grimme, Mark Hlawatschek, Jan R. Bergrath |
Vorsitzender des Aufsichtsrats: Dr. Martin Buss 

From spaghettitoastbook at gmail.com  Sun Mar 31 00:33:02 2013
From: spaghettitoastbook at gmail.com (Anony Mous)
Date: Sat, 30 Mar 2013 19:33:02 -0400
Subject: [docs] Examples in Library/collections.abc in Python 3.3 Docs
Message-ID: <CAOY15XwCW-4qU+UeWKex2WusU71YBxO+OvHxZ4H38B9kP6vYMQ@mail.gmail.com>

I just wanted to mention that the example code on the page for the module
collections.abc (http://docs.python.org/3.3/library/collections.abc.html)
has not been changed to reflect the new collections.abc module. For
example, "collections.Set" is used instead of "collections.abc.Set". Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130330/61839d01/attachment-0001.html>