From report at bugs.python.org  Fri Feb  1 04:02:31 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 03:02:31 +0000
Subject: [docs] [issue17040] Document context manager support for shelf
	objects
In-Reply-To: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>
Message-ID: <3Yy35L1RmfzQ12@mail.python.org>


Roundup Robot added the comment:

New changeset 935a286b8066 by Ezio Melotti in branch 'default':
#17040: document that shelve.open() and the Shelf object can be used as context managers.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/935a286b8066

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

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

From report at bugs.python.org  Fri Feb  1 04:04:29 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:04:29 +0000
Subject: [docs] [issue17040] Document context manager support for shelf
	objects
In-Reply-To: <1359206810.79.0.264675757917.issue17040@psf.upfronthosting.co.za>
Message-ID: <1359687869.7.0.714356224156.issue17040@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/issue17040>
_______________________________________

From report at bugs.python.org  Fri Feb  1 04:20:41 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Feb 2013 03:20:41 +0000
Subject: [docs] [issue16128] hashable documentation error
In-Reply-To: <1349350634.9.0.571993653286.issue16128@psf.upfronthosting.co.za>
Message-ID: <3Yy3VJ5mHCzM75@mail.python.org>


Roundup Robot added the comment:

New changeset 79a021beaf58 by Ezio Melotti in branch '2.7':
#16128: clarify that instances of user-defined classes compare equal with themselves.
http://hg.python.org/cpython/rev/79a021beaf58

New changeset e84c5cf92b6f by Ezio Melotti in branch '3.2':
#16128: clarify that instances of user-defined classes compare equal with themselves.
http://hg.python.org/cpython/rev/e84c5cf92b6f

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

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

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

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

From report at bugs.python.org  Fri Feb  1 04:22:59 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 03:22:59 +0000
Subject: [docs] [issue16128] hashable documentation error
In-Reply-To: <1349350634.9.0.571993653286.issue16128@psf.upfronthosting.co.za>
Message-ID: <1359688979.47.0.43116108659.issue16128@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I addressed the first comment.  The paragraph in datamodel.html looks ok to me, so I left it unchanged.  Feel free to reopen the issue if you have a specific suggestion that could improve that section.

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

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

From report at bugs.python.org  Fri Feb  1 06:25:55 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 01 Feb 2013 05:25:55 +0000
Subject: [docs] [issue13515] Consistent documentation practices for security
	concerns	and considerations
In-Reply-To: <1322726017.57.0.923133254266.issue13515@psf.upfronthosting.co.za>
Message-ID: <1359696355.29.0.828593732293.issue13515@psf.upfronthosting.co.za>


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


----------
nosy: +christian.heimes
type:  -> enhancement

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

From report at bugs.python.org  Fri Feb  1 20:13:58 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Feb 2013 19:13:58 +0000
Subject: [docs] [issue17035] Use new style classes in {class,
	static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <1359746038.05.0.305209561785.issue17035@psf.upfronthosting.co.za>


?ric Araujo added the comment:

LGTM.

----------
nosy: +eric.araujo
stage:  -> patch review

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

From report at bugs.python.org  Fri Feb  1 22:58:01 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 21:58:01 +0000
Subject: [docs] [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1359755881.86.0.492741773682.issue13124@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Did you want to commit this patch yourself, Eric, since you have commit privs now?

----------

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

From report at bugs.python.org  Fri Feb  1 23:43:08 2013
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Feb 2013 22:43:08 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1359758588.05.0.888257899638.issue15369@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

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

From report at bugs.python.org  Sat Feb  2 07:45:13 2013
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 Feb 2013 06:45:13 +0000
Subject: [docs] [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1359787513.52.0.700027897701.issue13124@psf.upfronthosting.co.za>


Eric Snow added the comment:

Yeah, at some point I will. :)  I've been pretty focused on implementing a C-OrderedDict, which I'm (hopefully) wrapping up pretty soon.  Once that happens I'm going to revisit a bunch of the open tickets I have.  If you want to push this sooner than that, feel free. :)

----------

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

From report at bugs.python.org  Sat Feb  2 09:21:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Feb 2013 08:21:19 +0000
Subject: [docs] [issue15116] remove out-of-date Mac application
	scripting	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <3Yyp6k4HYjzPvC@mail.python.org>


Roundup Robot added the comment:

New changeset 7ca742d808b2 by Ned Deily in branch '2.7':
Issue #15116: Remove references to appscript as it is no longer being
http://hg.python.org/cpython/rev/7ca742d808b2

New changeset 0f0256e4a1ef by Ned Deily in branch '3.2':
Issue #15116: Remove references to appscript as it is no longer being
http://hg.python.org/cpython/rev/0f0256e4a1ef

New changeset 1b1f7ec5ddb8 by Ned Deily in branch '3.3':
Issue #15116: merge from 3.2
http://hg.python.org/cpython/rev/1b1f7ec5ddb8

New changeset 6053e0e1f05b by Ned Deily in branch 'default':
Issue #15116: merge from 3.3
http://hg.python.org/cpython/rev/6053e0e1f05b

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

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

From report at bugs.python.org  Sat Feb  2 09:23:29 2013
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Feb 2013 08:23:29 +0000
Subject: [docs] [issue15116] remove out-of-date Mac application
	scripting	documentation
In-Reply-To: <1340204053.19.0.132676348255.issue15116@psf.upfronthosting.co.za>
Message-ID: <1359793409.86.0.641335532805.issue15116@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Sat Feb  2 09:40:54 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Feb 2013 08:40:54 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1359794454.55.0.774772229962.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

These are correct as they are:

Lib/tkinter/tix.py:149:        """Locates a bitmap file of the name name.xpm or name in one of the
Lib/tkinter/tix.py:160:        """Locates an image file of the name name.xpm, name.xbm or name.ppm

Modules/_io/iobase.c:79:    "Change the stream position to byte offset offset. offset is\n"
<I believe the 2nd and 3rd 'offset' are argument names, which would be specially marked in .rst>

Modules/socketmodule.c:3547:           ensures that that doesn't happen. */
Modules/binascii.c:41:** I have attempted to break with this tradition, but I guess that that
Doc/c-api/intro.rst:436::c:func:`sum_sequence` example above.  It so happens that that example doesn't
<'that that' is awkward, but the two 'that's are different>

Modules/posixmodule.c:9747:Return the value of extended attribute attribute on path.\n\
Modules/posixmodule.c:9825:Set extended attribute attribute on path to value.\n\
Modules/posixmodule.c:9890:Remove extended attribute attribute on path.\n\
PC/msvcrtmodule.c:133:Create a C runtime file descriptor from the file handle handle. The\n\
<much like byte offset offset>

Doc/c-api/long.rst:206:   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be
<the re missed the '.'.>

False doubles from typos (which should also be changed):
Lib/test/test_socket.py:845:        # Try udp, but don't barf it it doesn't exist
/it it/if it/

?ric, I am puzzled by your comment. The only two 'the the's in Serhiy's report (that Firefox finds) are

python-gdb.py:1466:        '''Is this frame "collect" within the the garbage-collector?'''
<I suspect 'collect' should be 'collected', but I cannot tell without a link. I am sure 'the the' is wrong.>

Misc/HISTORY:3055:  environment after Distutils set it.  Instead, have Distutils set the the

and both look like wrong doubles and not 'that the'.

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

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

From report at bugs.python.org  Sat Feb  2 22:40:08 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 21:40:08 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1359841208.27.0.901880239337.issue15369@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't really think they deserve documenting.

pystones can arguably be a cheap and easy way of comparing performance of different systems *using the exact same Python interpreter*. It's the only point of running pystones.

As for pybench, it probably had a point when there wasn't anything better, but I don't think it has anymore. We have a much better benchmarks suite right now, and we also have a couple specialized benchmarks in the tools directory.

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

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

From report at bugs.python.org  Sun Feb  3 00:31:56 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Feb 2013 23:31:56 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
Message-ID: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

If you look at http://docs.python.org/dev/library/development.html, you'll see the following outline (stripped for brevity):
     
26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class

26.5. The patchers

26.6. MagicMock and magic method support

26.7. Helpers

26.8. unittest.mock ? getting started

26.9. Further Examples

26.10. 2to3 - Automated Python 2 to 3 code translation


Instead, it should be:

26.4. unittest.mock ? mock object library

    26.4.1. Quick Guide
    26.4.2. The Mock Class
    26.4.3. The patchers
    26.4.4. MagicMock and magic method support
    26.4.5. Helpers

26.5. unittest.mock ? getting started

    26.5.1. Further Examples

26.6. 2to3 - Automated Python 2 to 3 code translation


(I'm also not sure the reference document should come before the getting started document)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 181231
nosy: docs at python, michael.foord, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: unittest.mock has wrong heading levels
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 05:01:11 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Feb 2013 04:01:11 +0000
Subject: [docs] [issue17110] sys.argv docs should explaining how to handle
	encoding	issues
Message-ID: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The sys.argv docs [1] currently contain no mention of the fact that they are Unicode strings decoded from bytes provided by the OS. They also don't explain how to correct a decoding error by reversing Python's implicit conversion and redoing it based on the application's knowledge of the correct encoding, as described at [2]

[1] http://docs.python.org/3/library/sys#sys.argv
[2] http://stackoverflow.com/questions/6981594/sys-argv-as-bytes-in-python-3k/

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181239
nosy: docs at python, ezio.melotti, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: sys.argv docs should explaining how to handle encoding issues
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb  3 05:27:08 2013
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Feb 2013 04:27:08 +0000
Subject: [docs] [issue17110] sys.argv docs should explaining how to handle
	encoding	issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1359865628.85.0.961627016264.issue17110@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


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

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

From report at bugs.python.org  Sun Feb  3 05:36:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Feb 2013 04:36:25 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359866185.24.0.218210088067.issue17109@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/issue17109>
_______________________________________

From report at bugs.python.org  Sun Feb  3 11:47:34 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 10:47:34 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <3YzTK11d4ZzR9V@mail.python.org>


Roundup Robot added the comment:

New changeset 72aee7ee2299 by Georg Brandl in branch '3.3':
Closes #17109: fix heading levels in mock doc.
http://hg.python.org/cpython/rev/72aee7ee2299

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

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

From report at bugs.python.org  Sun Feb  3 11:53:17 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 10:53:17 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359888797.56.0.359212290245.issue17109@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

unittest.mock-examples.rst also needs fixing.

----------

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

From report at bugs.python.org  Sun Feb  3 13:18:14 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sun, 03 Feb 2013 12:18:14 +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: <1359893894.51.0.180980696338.issue16643@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Here's a patch.

----------
keywords: +patch
nosy: +ramchandra.apte
Added file: http://bugs.python.org/file28943/issue16643.patch

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

From report at bugs.python.org  Sun Feb  3 13:38:28 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Feb 2013 12:38:28 +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: <1359895108.99.0.242613383224.issue16643@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Feb  3 13:59:28 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Feb 2013 12:59:28 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <3YzXFD00TzzMhh@mail.python.org>


Roundup Robot added the comment:

New changeset 9040b3714207 by Georg Brandl in branch '3.3':
#17109: fix headings in mock example doc.
http://hg.python.org/cpython/rev/9040b3714207

----------

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

From report at bugs.python.org  Sun Feb  3 15:04:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Feb 2013 14:04:40 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359900280.04.0.321470100823.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, yes.

To clarify for Shai, by the way, the reason this stuff can't change (and the reason there is a new step 3 instead of changing the whole algorithm to be something more sensible) is because of the requirement of maintaining backward compatibility.

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

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

From report at bugs.python.org  Sun Feb  3 15:16:08 2013
From: report at bugs.python.org (Shai Berger)
Date: Sun, 03 Feb 2013 14:16:08 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359900968.31.0.991070098502.issue17108@psf.upfronthosting.co.za>


Shai Berger added the comment:

Hi,

> the reason this stuff can't change [... is] backward compatibility.

Thanks, but this is still unclear to me. The required fix for code that would break because of the change I propose, is removal of dead code which looks misleadingly alive. 

Is the backward-compatibility requirement really that strict?

----------

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

From report at bugs.python.org  Sun Feb  3 15:48:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Feb 2013 14:48:56 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359902936.5.0.667688975894.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  Imagine you have a deployed application, and there happens to be an xx.py file that is masked by a package in it.  You upgrade from pythonX.Y.Z to X.Y.Z+1, and your application is suddenly throwing an error.  Yes it is easy to fix, but we prefer not to break things that way.

Now, could we throw an error in Python 3.4?  It could be discussed, at least.

----------

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

From report at bugs.python.org  Sun Feb  3 15:54:43 2013
From: report at bugs.python.org (Shai Berger)
Date: Sun, 03 Feb 2013 14:54:43 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1359903283.53.0.572878479693.issue17108@psf.upfronthosting.co.za>


Shai Berger added the comment:

Oh, sure, this was unclear of me. I thought you were talking about Python 3.4. I wasn't really expecting this to be fixed in the stable branches.

Thanks,
Shai.

----------

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

From report at bugs.python.org  Sun Feb  3 20:56:40 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 19:56:40 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921400.23.0.60000925023.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

How does the "+" level relate to the convention described here?

http://docs.python.org/devguide/documenting.html#sections

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Sun Feb  3 20:57:25 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 19:57:25 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921445.78.0.938853527643.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Never mind :)

----------

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

From report at bugs.python.org  Sun Feb  3 21:06:26 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 20:06:26 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359921986.51.0.915325663969.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I see why I was confused.  The ~'s are different from -'s.  The tilde level isn't listed in our devguide conventions.

----------

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

From report at bugs.python.org  Sun Feb  3 21:19:16 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Feb 2013 20:19:16 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359921986.51.0.915325663969.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359922578.3415.24.camel@localhost.localdomain>


Antoine Pitrou added the comment:

> I see why I was confused.  The ~'s are different from -'s.  The tilde
> level isn't listed in our devguide conventions.

I think the conventions are just conventions, and docutils / sphinx
don't enforce any order. I may be wrong though.

----------

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

From report at bugs.python.org  Sun Feb  3 22:56:52 2013
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2013 21:56:52 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359928612.02.0.777654333412.issue17109@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Antoine is right.  It's probably ok to remove that suggestion completely.

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

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

From report at bugs.python.org  Sun Feb  3 23:05:56 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 03 Feb 2013 22:05:56 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1359929156.61.0.564447165267.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I think the guidance is still helpful.  I have referred to it often.  It can just be changed to being a suggestion as opposed to "the convention that we use."

----------

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

From report at bugs.python.org  Mon Feb  4 03:15:51 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 02:15:51 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944151.12.0.379392505661.issue17091@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Was this already taken care of? http://docs.python.org/2/library/thread.html?highlight=thread.lock#thread.lock.acquire and http://docs.python.org/3.3/library/_thread.html?highlight=thread.lock#_thread.lock.acquire don't make any mention of returning None.

----------
nosy: +icordasc

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

From report at bugs.python.org  Mon Feb  4 03:27:34 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 02:27:34 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944854.36.0.826852720546.issue17091@psf.upfronthosting.co.za>


R. David Murray added the comment:

Armin is talking about the docstring, not the docs.  That is, what you get if you do help(x.acquire), where x is a Lock object, at the Python prompt.

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

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

From report at bugs.python.org  Mon Feb  4 03:28:03 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 02:28:03 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359944883.43.0.580857621623.issue17091@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Feb  4 03:54:26 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 02:54:26 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359946466.13.0.905217582376.issue17091@psf.upfronthosting.co.za>


Ian Cordasco added the comment:

Thanks. I couldn't find it in the source but I just found Modules/_threadmodule.c

I tested the method from the interpreter to confirm the changes I was making to the docstring. Attached is a diff that covers the change.

----------
Added file: http://bugs.python.org/file28949/doc_fix.txt

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

From report at bugs.python.org  Mon Feb  4 16:30:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Feb 2013 15:30:19 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <3Z0CXp1X1kzSS5@mail.python.org>


Roundup Robot added the comment:

New changeset 0cc51c04aa20 by R David Murray in branch '3.2':
#17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/0cc51c04aa20

New changeset b414b2dfd3d3 by R David Murray in branch '3.3':
merge #17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/b414b2dfd3d3

New changeset a80abb179ba1 by R David Murray in branch 'default':
merge #17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/a80abb179ba1

New changeset 20f0c5398e97 by R David Murray in branch '2.7':
#17091: update docstring for _thread.Lock.acquire.
http://hg.python.org/cpython/rev/20f0c5398e97

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

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

From report at bugs.python.org  Mon Feb  4 16:31:42 2013
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Feb 2013 15:31:42 +0000
Subject: [docs] [issue17091] thread.lock.acquire docstring bug
In-Reply-To: <1359651487.53.0.770851412418.issue17091@psf.upfronthosting.co.za>
Message-ID: <1359991902.87.0.351924208116.issue17091@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Ian.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Mon Feb  4 17:03:40 2013
From: report at bugs.python.org (Ian Cordasco)
Date: Mon, 04 Feb 2013 16:03:40 +0000
Subject: [docs] [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1359993820.89.0.947971044273.issue12779@psf.upfronthosting.co.za>


Changes by Ian Cordasco <graffatcolmingov at gmail.com>:


----------
nosy: +icordasc, larry

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

From report at bugs.python.org  Mon Feb  4 17:20:26 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Feb 2013 16:20:26 +0000
Subject: [docs] [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1359994826.45.0.0488606750931.issue12779@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Packaging is removed from the stdlib and distutils2 is evolving into decoupled libs/tools.  Closing this effort :(

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Feb  5 01:53:23 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 00:53:23 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360025603.03.0.619121284907.issue6696@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can someone review Thomas's patch?  It's nearly a year old...  I just discovered this same issue.

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

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

From report at bugs.python.org  Tue Feb  5 03:51:01 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 02:51:01 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360032660.9.0.818025971936.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I learned a lot of that stuff recently thanks to a tutorial from Greg Ward.  Reviewing the patch now.

----------
stage: needs patch -> patch review
versions: +Python 3.4

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

From report at bugs.python.org  Tue Feb  5 04:06:22 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 03:06:22 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360033582.9.0.329938269362.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Tom, I?m sory your contribution was ignored, and I hope you still get Python bugs email.  The patch is great.  I made comments about contents and form on the code review site; you can follow the ?review? link in the list of files on the top of this page if you didn?t get an email from the review app.

----------

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

From report at bugs.python.org  Tue Feb  5 05:07:21 2013
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2013 04:07:21 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1360033582.9.0.329938269362.issue6696@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJSfivM0frDpPEVBcpE5utuZ9oDB9SYOCb==wwC5+8XSw@mail.gmail.com>


Guido van Rossum added the comment:

Eric, you could also check it in with your own changes added.

How far can we backport docs?

----------

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

From report at bugs.python.org  Tue Feb  5 05:23:44 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 04:23:44 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360038224.47.0.154634711406.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

2.7 and 3.2.

I?ll wait a few days to let Thomas get the email and reply if he wants.

----------

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

From report at bugs.python.org  Tue Feb  5 14:38:36 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 05 Feb 2013 13:38:36 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360071516.23.0.729339029341.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Thanks for the feedback!

I'll incorporate it this weekend and make a new patch, though also feel free to just go ahead and make the changes yourself if you'd rather not wait for me.

----------

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

From report at bugs.python.org  Tue Feb  5 17:09:41 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:09:41 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
Message-ID: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>


New submission from ?ric Araujo:

Title says it all.

----------
assignee: docs at python
components: Documentation
messages: 181450
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: imp doc should direct to importlib
versions: Python 3.1, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb  5 17:20:37 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Feb 2013 16:20:37 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360081237.06.0.188325565043.issue6696@psf.upfronthosting.co.za>


?ric Araujo added the comment:

There is no rush, even if this doesn?t get into the docs distributed with the releases that are due next week-end, people will see it in the online docs a day after it?s committed.

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

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

From report at bugs.python.org  Tue Feb  5 21:32:35 2013
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Feb 2013 20:32:35 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1360096355.92.0.809315249791.issue17135@psf.upfronthosting.co.za>


Eric Snow added the comment:

Agreed.  It should also link to the new import section in the language reference rather than to the import statement.

----------
nosy: +eric.snow

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

From report at bugs.python.org  Wed Feb  6 20:14:10 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Feb 2013 19:14:10 +0000
Subject: [docs] [issue17147] BytesIO should be mentioned in
	SpooledTemporaryFile	documentation
Message-ID: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Currently only StringIO is mentioned (which was inherited from Python 2).

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: SpooledTemporaryFile_document_BytesIO.patch
keywords: patch
messages: 181563
nosy: docs at python, georg.brandl, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: BytesIO should be mentioned in SpooledTemporaryFile documentation
type: compile error
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28983/SpooledTemporaryFile_document_BytesIO.patch

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

From report at bugs.python.org  Wed Feb  6 21:05:53 2013
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 06 Feb 2013 20:05:53 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360181153.35.0.196937483871.issue17145@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Changing array.array would be a new feature, so it cannot go into 2.7.

The documentation could be improved, see also #14198.

----------
assignee:  -> docs at python
components: +Documentation -None
nosy: +docs at python, skrah

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

From report at bugs.python.org  Thu Feb  7 03:15:15 2013
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 07 Feb 2013 02:15:15 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360203315.06.0.720158572265.issue17047@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

These are the ones that I think are wrong:

Doc/c-api/long.rst:206

   Return a C :c:type:`size_t` representation of of *pylong*.  *pylong* must be

Doc/c-api/long.rst:218

   Return a C :c:type:`unsigned PY_LONG_LONG` representation of of *pylong*.

Doc/library/email.policy.rst:330

      line breaks and and any (RFC invalid) binary data it may contain.

Doc/library/ipaddress.rst:395

      These attributes are true for the network as a whole if they are true
      true for both the network address and the broadcast address

Doc/library/ipaddress.rst:454

      ``True`` if this network is partly or wholly contained in *other* or
      or *other* is wholly contained in this network.

Doc/library/ipaddress.rst:584

      These attribute is true for the network as a whole if it is true
      true for both the network address and the broadcast address

Doc/library/ssl.rst:826

   The *server_name_callback* function must return ``None`` to allow the
   the TLS negotiation to continue.  If a TLS failure is required, a constant

Doc/library/stdtypes.rst:2640

      Cast 1D/unsigned char to to 2D/unsigned long::

Doc/library/unittest.mock.rst:1011

    attributes that your production code creates at runtime. It is off by by

Doc/library/xml.dom.rst:359

   children, returning *newChild*. If the node was already in
   in the tree, it is removed first.

Doc/whatsnew/3.3.rst:1539

New attribute attribute :data:`multiprocessing.Process.sentinel` allows a

Include/pyport.h:884

 * also also takes care of Apple's universal builds.

Lib/argparse.py:1143

        - encoding -- The file's encoding. Accepts the same values as the
            the builtin open() function.

Lib/ftplib.py:468

          callback: An optional single parameter callable that is called on
                    on each block of data after it is sent.  [default: None]

Lib/ftplib.py:490

          callback: An optional single parameter callable that is called on
                    on each line after it is sent.  [default: None]

Lib/turtle.py:859

    Thus stops execution of turtle graphics script. Main purpose: use in
    in the Demo-Viewer turtle.Demo.py.

Lib/_pyio.py:306

        Change the stream position to byte offset offset. offset is

[It's referring to the byte-offset parameter called "offset"; the parameter is actually called "pos".]

Lib/concurrent/futures/_base.py:520

            fn: A callable that will take take as many arguments as there are

Lib/distutils/command/install.py:266

            raise DistutilsOptionError("can't combine user with with prefix/"

Lib/distutils/tests/test_install.py:168

        # can't combine user with with prefix/exec_prefix/home or

Lib/email/policy.py:26

    The API extensions enabled by this this policy are currently provisional.

Lib/email/_encoded_words.py:17

# to to the CTE tables, but YAGNI for now.  'q' is Quoted Printable, 'b' is

Lib/email/_header_value_parser.py:1866

    We allow anything except the excluded characters, but but if we find any

Lib/email/mime/text.py:29

        # If no _charset was specified, check to see see if there are non-ascii

Lib/idlelib/extend.txt:57

Here is a complete example example:

Lib/idlelib/extend.txt:75

used to to configure the loading of extensions and to establish key (or, more

Lib/idlelib/rpc.py:4

connect to the Idle process, which listens for the connection.  Since Idle has
has only one client per server, this was not a limitation.

Lib/lib2to3/pgen2/grammar.py:23

    """Pgen parsing tables tables conversion class.

Lib/lib2to3/pgen2/grammar.py:48

                     states, each state is is a list of arcs, and each

Lib/msilib/__init__.py:327

        """Add a file to the current component of the directory, starting a new one
        one if there is no current component. By default, the file name in the source

Lib/test/test_decimal.py:4495

        # Do operations and check that it didn't change change internal objects.

Lib/test/test_socket.py:845

        # Try udp, but don't barf it it doesn't exist

[Should be "if it".]

Lib/tkinter/tix.py:1920

                     Val may be: "auto" -- the width of the column is set the
                     the widest cell in the column; a valid Tk screen distance

Lib/tkinter/tix.py:1944

                     Val may be: "auto" -- the height of the row  is  set  the
                     the highest cell in the row; a valid Tk screen distance

Lib/unittest/mock.py:1447

    attributes that your production code creates at runtime. It is off by by

Modules/ossaudiodev.c:233

   SNDCTL_DSP_{SETFMT,CHANNELS,SPEED} -- that that are called from C

Modules/_heapqmodule.c:91

    /* The leaf at pos is empty now.  Put newitem there, and and bubble

Modules/_heapqmodule.c:431

    /* The leaf at pos is empty now.  Put newitem there, and and bubble

Modules/expat/xmltok.c:1587

           way this can fail to be big-endian UTF-16 if it it's an

Modules/zlib/deflate.c:160

 * IN  assertion: all calls to to UPDATE_HASH are made with consecutive

Modules/zlib/deflate.c:173

 * IN  assertion: all calls to to INSERT_STRING are made with consecutive

Modules/zlib/inftrees.h:44

   returns returns 852, and "enough 30 6 15" for distance codes returns 592.

Modules/zlib/zlib.h:815

   success case, the application may save the current current value of total_in

Modules/_ctypes/callproc.c:23

  'inargs', or a completely fresh tuple, depending on several things (is is a

Modules/_ctypes/libffi/src/dlmalloc.c:103

       else. And if if you are sure that your program using malloc has

Modules/_ctypes/libffi/src/dlmalloc.c:609

  are not even meaningful in this version of malloc.  These fields are
  are instead filled by mallinfo() with other numbers that might be of

Modules/_ctypes/libffi/src/dlmalloc.c:1624

  ensured by making all allocations from the the `lowest' part of any

Modules/_ctypes/libffi/src/dlmalloc.c:1830

  parent pointer.)  If a chunk with the same size an an existing node

[Should be "as an".]

Modules/_ctypes/libffi/src/dlmalloc.c:1835

  smallest is 0x100 <= x < 0x180), which is is divided in half at each

Modules/_ctypes/libffi/src/dlmalloc.c:3444

       (disabled if not MORECORE_CONTIGUOUS or not HAVE_MORECORE or
       or main space is mmapped or a previous contiguous call failed)

Modules/_ctypes/libffi/src/ia64/ffi.c:88

/* Return the size of the C type associated with with TYPE.  Which will

Modules/_ctypes/libffi/src/ia64/ffi.c:188

      /* Similarly, except that that HFA is true for double extended,

Tools/msi/msilib.py:493

        """Add a file to the current component of the directory, starting a new one
        one if there is no current component. By default, the file name in the source

----------
nosy: +mrabarnett

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

From report at bugs.python.org  Thu Feb  7 08:08:56 2013
From: report at bugs.python.org (moijes12)
Date: Thu, 07 Feb 2013 07:08:56 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360220935.85.0.174097921659.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

Hi

Is this still open to work on ?

If yes, what were the review comments from the previous review?

----------
nosy: +moijes12

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

From report at bugs.python.org  Thu Feb  7 09:14:21 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Feb 2013 08:14:21 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360224861.85.0.382956718864.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Lib/tkinter/tix.py:1920
 Val may be: "auto" -- the width of the column is set the
 the widest cell in the column; a valid Tk screen distance

I believe 'the the' should be 'to the width of the'

Lib/tkinter/tix.py:1944
 Val may be: "auto" -- the height of the row  is  set  the
 the highest cell in the row; a valid Tk screen distance

Ditto for heigth instead of width.

----------

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

From report at bugs.python.org  Thu Feb  7 09:17:05 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Feb 2013 08:17:05 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360225025.62.0.0883743040108.issue12768@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/issue12768>
_______________________________________

From report at bugs.python.org  Thu Feb  7 14:15:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Feb 2013 13:15:11 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360242911.3.0.0444624381899.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Terry, do you want to provide a patch?

----------

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

From report at bugs.python.org  Thu Feb  7 16:34:19 2013
From: report at bugs.python.org (Franck Michea)
Date: Thu, 07 Feb 2013 15:34:19 +0000
Subject: [docs] [issue17151] Python 3 changement of behavior with
	__ne__:	documentation not updated
Message-ID: <1360251259.3.0.329716783607.issue17151@psf.upfronthosting.co.za>


New submission from Franck Michea:

Hi. As of python 3, behavior of object.__ne__ changed to call (not object.__eq__) if implemented. This changement can be seen in function object_richcompare in file Objects/typeobject.c.

Documentation didn't change though, still saying[1] that "There are no implied relationships among the comparison operators. [...] Accordingly, when defining __eq__(), one should also define __ne__()".

Maybe a paragraph about this new behavior would be fine? I am not sure if last sentence of last paragraph is what it means, but it was already there in python 2 doc so guess no. I am not sure about how to write it so no patch, sorry.

[1] http://docs.python.org/3.3/reference/datamodel.html#object.__eq__

----------
assignee: docs at python
components: Documentation
messages: 181620
nosy: docs at python, kushou
priority: normal
severity: normal
status: open
title: Python 3 changement of behavior with __ne__: documentation not updated
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Feb  7 17:17:19 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 07 Feb 2013 16:17:19 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360253839.42.0.0176373178992.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Here's a patch for the docs that adds a little clarity.

----------
keywords: +patch
Added file: http://bugs.python.org/file28986/buffer.patch

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

From report at bugs.python.org  Thu Feb  7 17:27:09 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:27:09 +0000
Subject: [docs] [issue17151] Python 3 changement of behavior with
	__ne__:	documentation not updated
In-Reply-To: <1360251259.3.0.329716783607.issue17151@psf.upfronthosting.co.za>
Message-ID: <1360254429.05.0.694038197058.issue17151@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

There's a (long-standing) issue already open for this: #4395.  I'll close this as a duplicate and add a note to that issue;  with any luck, pinging that issue might produce some movement.

----------
nosy: +mark.dickinson
resolution:  -> duplicate
status: open -> closed
superseder:  -> Document auto __ne__ generation; provide a use case for non-trivial __ne__

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

From report at bugs.python.org  Thu Feb  7 17:28:32 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:28:32 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1360254512.04.0.22727183244.issue4395@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Issue #17151 closed as a duplicate of this one.

----------
nosy: +kushou, mark.dickinson

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

From report at bugs.python.org  Thu Feb  7 17:28:53 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2013 16:28:53 +0000
Subject: [docs] [issue4395] Document auto __ne__ generation;
	provide a use case for non-trivial __ne__
In-Reply-To: <1227464493.77.0.130820783094.issue4395@psf.upfronthosting.co.za>
Message-ID: <1360254533.28.0.657327369119.issue4395@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


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

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

From report at bugs.python.org  Thu Feb  7 19:18:25 2013
From: report at bugs.python.org (=?utf-8?q?Germ=C3=A1n_M=2E_Bravo?=)
Date: Thu, 07 Feb 2013 18:18:25 +0000
Subject: [docs] [issue17155] Logging throwing UnicodeEncodeError exception
Message-ID: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>


New submission from Germ?n M. Bravo:

I've seen *a lot* of people using `logging.exception(exc)` to log exceptions. It all seems okay, until the exc object contains unicode strings, at which point logging throes a UnicodeEncodeError exception.

Example: `exc = Exception(u'operaci\xf3n'); logger.error(exc)` throws an exception, while `exc = Exception(u'operaci\xf3n'); logger.error(u"%s", exc)` does not and works as expected.

The problem for this is in the `_fmt` string in logging being `"%(message)s"`, not `u"%(message)s"`, which ends up getting the string (non-unicode) version of the exception object (returned by `getMessage()`) and failing to apply the formatting since the exception contains unicode.

A solution would be to make the default formatting string a unicode string so the object returned by `getMessage()` (the exception) is converted to unicode by making all formatting strings for logging unicode strings: (could be done for example by changing to `unicode(self._fmt) % record.__dict__` the line logging/__init__.py:467).

Other solution could be to encourage users not to use objects as the first argument to the logging methods, and perhaps even log a warning against it if it's done.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 181640
nosy: Kronuz, docs at python, ezio.melotti
priority: normal
severity: normal
status: open
title: Logging throwing UnicodeEncodeError exception
versions: Python 2.7

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

From report at bugs.python.org  Fri Feb  8 00:02:47 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 07 Feb 2013 23:02:47 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360278167.11.0.16356098498.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Strike that patch, this needs a little more love than during-my-first-coffee-of-the-day work. I'll work on it more and submit a follow-up for review.

----------

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

From report at bugs.python.org  Fri Feb  8 02:41:53 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 01:41:53 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360287713.66.0.280128899202.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am working on patch(es) now, against 3.2. But to make 2.7.4/3.2.4, I'd like you to apply, as I am not currently set up to do so properly.
I may do separate patches for doc, lib, module, and others, so none is overwhelming.

----------

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

From report at bugs.python.org  Fri Feb  8 04:41:20 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 03:41:20 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360294879.68.0.830139941054.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

First batch for Lib/*. Separate 3.2 and 2.7 files as the later required deletion of concurrent patch and adjustment of tix and turtle paths.

----------
keywords: +patch
Added file: http://bugs.python.org/file28994/Lib14707-27.diff

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

From report at bugs.python.org  Fri Feb  8 04:44:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 03:44:33 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360295073.71.0.853161688017.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

These of course do not contain patches for new dups introduced in 3.3. I kept a record and will later make a separate patch for those. (I hope before 3.3.1).

----------
Added file: http://bugs.python.org/file28995/Lib14707-32.diff

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

From report at bugs.python.org  Fri Feb  8 07:39:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 06:39:49 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360305589.62.0.354655404688.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

C module files. I cannot find python-gdb.py.

----------
Added file: http://bugs.python.org/file28996/Mod14707-27.diff

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

From report at bugs.python.org  Fri Feb  8 07:40:14 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 06:40:14 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360305614.62.0.0439697662811.issue17047@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file28997/Mod14707-32.diff

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

From report at bugs.python.org  Fri Feb  8 08:24:10 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:24:10 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360308250.06.0.25752956703.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

A majority of doc glitches listed here are new in 3.3. I believe someone make a similar de-double patch some time ago. I put the other 2.7/3.2 fixes here so this is it for those two versions.

----------
Added file: http://bugs.python.org/file28998/Doc17047-27.diff

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

From report at bugs.python.org  Fri Feb  8 08:24:33 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:24:33 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360308273.98.0.606075548587.issue17047@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file28999/Doc17047-32.diff

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

From report at bugs.python.org  Fri Feb  8 08:55:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Feb 2013 07:55:02 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360310102.3.0.66461244851.issue17047@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is for 3.3 and 3.4. It is against tip, but should apply to 3.3 since the lines changed were as reported here for 3.3.

----------
Added file: http://bugs.python.org/file29000/Issue17047-34.diff

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

From report at bugs.python.org  Fri Feb  8 11:18:53 2013
From: report at bugs.python.org (Michael Stahn)
Date: Fri, 08 Feb 2013 10:18:53 +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: <1360318733.71.0.111066004951.issue11448@psf.upfronthosting.co.za>


Michael Stahn added the comment:

I thought the same as Ryan when reading the API. The best way would have been to call "set_tunnel" -> "set_proxy" and to implement the behaviour you expect on this: setting a proxy. There are some more places at this code which are not quite clear eg:

def putheader(self, header, *values):
  """Send a request header line to the server.

Here the methodname "putheader" is ok but the documentation is misleading: this just adds a new header-line to the buffer, it won't send it directly. But that's the problem with naming in APIs: once it's in the code you won't get it changed that fast..

----------
nosy: +m1kes

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

From report at bugs.python.org  Fri Feb  8 16:49:07 2013
From: report at bugs.python.org (Zearin)
Date: Fri, 08 Feb 2013 15:49:07 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1360338547.52.0.728721330274.issue15580@psf.upfronthosting.co.za>


Zearin added the comment:

I agree that globally linking all occurrences of True/False/None is overkill. 

Perhaps linking the first occurrence per webpage would be a good standard?

----

However, I *strongly* believe that:

1. The words be capitalized
2. The words should be marked up as ``True``, ``False``, or ``None``

Of course, these two items only apply when appropriate.  But after attempting this myself in #17074, I can say with certainty that this is the case *most of the time*.

----------

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

From report at bugs.python.org  Fri Feb  8 17:10:40 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 16:10:40 +0000
Subject: [docs] [issue15580] fix True/False/None reST markup
In-Reply-To: <1344390578.71.0.326693298402.issue15580@psf.upfronthosting.co.za>
Message-ID: <1360339840.37.0.904137088926.issue15580@psf.upfronthosting.co.za>


R. David Murray added the comment:

They should be capitalized and marked up as code if they refer to the objects.  If they refer only to (to use bad english) the truthiness or falsiness of the value in question, then they should be lower case and not marked up as code.  Quickly scanning the start of the patch in 17074, about half the changes to true/false markup were incorrect.

Ideally we should never have True unless it is marked up as ``True`` (same for False), but there are *many* cases in the docs where true or false is correct.  My guess would be that those cases outnumber the cases where ``True`` or ``False`` is correct, but I haven't tried to measure :)

----------

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

From report at bugs.python.org  Fri Feb  8 17:15:23 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Feb 2013 16:15:23 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1360340123.0.0.640963377275.issue17047@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I cannot find python-gdb.py.

This is a copy of Tools/gdb/libpython.py.

----------

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

From report at bugs.python.org  Fri Feb  8 18:40:34 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 17:40:34 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360345234.36.0.923601007047.issue17108@psf.upfronthosting.co.za>


?ric Araujo added the comment:

I knew that a package would win over a module, but an initless package does not?  Yuck :(

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

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

From report at bugs.python.org  Fri Feb  8 18:44:16 2013
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Feb 2013 17:44:16 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360345456.61.0.56454718533.issue17108@psf.upfronthosting.co.za>


R. David Murray added the comment:

It has to be that way to preserve backward compatibility, since IIUC before the PEP there was no such thing as "an initless package", it was just a directory that was ignored by import.

----------

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

From report at bugs.python.org  Fri Feb  8 19:54:55 2013
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Feb 2013 18:54:55 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360349695.73.0.644540366428.issue17108@psf.upfronthosting.co.za>


Eric Snow added the comment:

Deprecating pkg/__init__.py and having pkg.py coexist with pkg/ was on the table in an earlier proposal (PEP 402).  In that case pkg/__init__.py would have been tried first for backward compatbility (until eliminated in Python 4 or whenever).  PEP 420 (namespace packages) took a more conservative approach, leaving the question of pkg.py coexisting with pkg/ on the table.

I still find the idea appealing of replacing pkg/__init__.py with simply pkg.py + pkg/.  PEP 402 outlines the rationale pretty well.  Considering that PEP 420 made __init__.py-less packages legal, deprecating __init__.py isn't a huge leap.  The challenge of deciding if a directory is a package is tricky when there is not marker (like __init__.py is), but PEP 420 already tackled that for the most part.

Regardless, it would definitely require a new PEP (likely derived from 402) and some caution, especially since you could argue that people may be relying on the current precedence policy.  It would also take a little bit of work for the implementation, and a bunch of work to make sure the stdlib is happy.

----------

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

From report at bugs.python.org  Fri Feb  8 21:57:00 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:57:00 +0000
Subject: [docs] [issue17147] BytesIO should be mentioned in
	SpooledTemporaryFile	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <1360357020.8.0.418148833409.issue17147@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Typos: whenewer ? whether and has specified ? was specified

Otherwise good to commit.

----------
nosy: +eric.araujo
type: compile error -> enhancement

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

From report at bugs.python.org  Fri Feb  8 21:59:50 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Feb 2013 20:59:50 +0000
Subject: [docs] [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1360357190.79.0.585424757224.issue17155@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Hm the correct way to use exception is:

    except Something:
        logger.exception('problem while doing X')

i.e. this is a generic unicode-to-str-with-default-encoding problem, not something specific to logging.

Vinay, do you think logging should do something smarter than calling str when passed non-str objects?

----------
nosy: +eric.araujo, vinay.sajip
title: Logging throwing UnicodeEncodeError exception -> logging can raise UnicodeEncodeError

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

From report at bugs.python.org  Sat Feb  9 00:07:22 2013
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 08 Feb 2013 23:07:22 +0000
Subject: [docs] [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1360364842.04.0.471800306433.issue17155@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

It is by design that logging accepts arbitrary objects, rather than just strings, see

docs.python.org/howto/logging.html#arbitrary-object-messages

and, as documented, the instance's __str__ will be called by logging calling str() on the instance. If people are being lazy and doing logging.exception(exc) where exc is an exception instance, then they need to change their code. Recall that on Python 2.x, just doing a + b can trigger a UnicodeError because of implicit bytes->Unicode conversions which use ASCII as a default (this is just how Python 2.x works - nothing to do with logging). An arbitrary exception's str() method may or may not be smart with respect to this sort of behaviour. I think the answer is for people to be more aware of Unicode issues and how Python 2.x deals with mixed Unicode and byte data. If the _fmt string you are referring to is the Formatter instance attribute, you can control that by passing whatever you want to the Formatter - a Unicode string, if you wish.

The normal logging exception handling is as per ?ric's example (though of course you can have placeholders and arguments passed to the exception call, as in

    logger.exception('Problem with %r', 'specific data')

I'm closing as invalid, because the example you quoted as working is how people are supposed to use it.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Feb  9 01:46:57 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Feb 2013 00:46:57 +0000
Subject: [docs] [issue17108] import silently prefers package over module
	when both	available
In-Reply-To: <1359844868.64.0.586214844711.issue17108@psf.upfronthosting.co.za>
Message-ID: <1360370817.76.0.959546927013.issue17108@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I looked through both the old 2.7 import statement doc and the new 3.3 import statement doc and import system chapter (5. The import system) and could not find anything about what a Path Based Finder path entry finder does when a particular path entry has multiple candidates (a directory, a file.pyx, and __pycache__/*.pyc entries are all possible).

I also notices that there is no (longer a) description of the simple default search for default installations: sys.modules, builtin modules, and sys.path directories. Up to here, first found rules. If there were such a simplified description, it could be followed by a description of resolution of conflicts within a sys.path directory.

----------
nosy: +terry.reedy
versions: +Python 3.3, Python 3.4 -Python 3.2

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

From report at bugs.python.org  Sat Feb  9 04:37:34 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 09 Feb 2013 03:37:34 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1360381054.48.0.200648532225.issue12768@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

moijes,

Yes, it's open. You can examine the comments for the previous patch by clicking on the "review" link near the patch. You need to be logged in to the issue tracker to see that.

----------

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

From report at bugs.python.org  Sat Feb  9 09:03:18 2013
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Feb 2013 08:03:18 +0000
Subject: [docs] [issue17166] Fix the suggested usage of _dummy_thread module
Message-ID: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The "dummy_thread" module has been renamed to "_dummy_thread" in Python 3:

    >>> import dummy_thread
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    ImportError: No module named 'dummy_thread'

----------
assignee: docs at python
components: Documentation
files: _dummy_thread-usage.diff
keywords: patch
messages: 181721
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix the suggested usage of _dummy_thread module
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29015/_dummy_thread-usage.diff

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

From report at bugs.python.org  Sat Feb  9 10:55:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 09:55:53 +0000
Subject: [docs] [issue17147] BytesIO should be mentioned in
	SpooledTemporaryFile	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <3Z37tc1pkZzSYb@mail.python.org>


Roundup Robot added the comment:

New changeset fb4ed16f35bd by Serhiy Storchaka in branch '3.2':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/fb4ed16f35bd

New changeset 8f772825029f by Serhiy Storchaka in branch '3.3':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/8f772825029f

New changeset c75d065a6bc2 by Serhiy Storchaka in branch 'default':
Issue #17147. Mention BytesIO in SpooledTemporaryFile documentation.
http://hg.python.org/cpython/rev/c75d065a6bc2

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

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

From report at bugs.python.org  Sat Feb  9 10:59:00 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Feb 2013 09:59:00 +0000
Subject: [docs] [issue17147] BytesIO should be mentioned in
	SpooledTemporaryFile	documentation
In-Reply-To: <1360178050.86.0.377232433999.issue17147@psf.upfronthosting.co.za>
Message-ID: <1360403940.41.0.602019331094.issue17147@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for corrections ?ric.

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

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

From report at bugs.python.org  Sat Feb  9 11:33:53 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 10:33:53 +0000
Subject: [docs] [issue17168] test.support 3.x docs mentions stringio.stringio
Message-ID: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

StringIO.StringIO has been renamed to io.StringIO in 3.x.
Attached is a patch with the corrected version which mentions io.StringIO.

----------
assignee: docs at python
components: Documentation
files: issue.patch
keywords: patch
messages: 181729
nosy: docs at python, ramchandra.apte
priority: normal
severity: normal
status: open
title: test.support 3.x docs mentions stringio.stringio
Added file: http://bugs.python.org/file29016/issue.patch

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

From report at bugs.python.org  Sat Feb  9 14:02:48 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 13:02:48 +0000
Subject: [docs] [issue17168] test.support 3.x docs mentions stringio.stringio
In-Reply-To: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>
Message-ID: <1360414968.87.0.771694827359.issue17168@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Please commit or review. This is *very* trivial.

----------

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

From report at bugs.python.org  Sat Feb  9 14:08:39 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 09 Feb 2013 13:08:39 +0000
Subject: [docs] [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <1360415319.16.0.914899533019.issue17166@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

LGTM.

----------
nosy: +ramchandra.apte

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

From report at bugs.python.org  Sat Feb  9 14:58:01 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 13:58:01 +0000
Subject: [docs] [issue17168] test.support 3.x docs mentions stringio.stringio
In-Reply-To: <1360406033.8.0.21634386544.issue17168@psf.upfronthosting.co.za>
Message-ID: <3Z3FG00fLlzMRY@mail.python.org>


Roundup Robot added the comment:

New changeset 474296d6d4a1 by Benjamin Peterson in branch '3.3':
StringIO.StringIO -> io.StringIO (closes #17168)
http://hg.python.org/cpython/rev/474296d6d4a1

New changeset 87e95b853be2 by Benjamin Peterson in branch 'default':
merge 3.3 (#17168)
http://hg.python.org/cpython/rev/87e95b853be2

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

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

From report at bugs.python.org  Sat Feb  9 19:25:29 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Feb 2013 18:25:29 +0000
Subject: [docs] [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <3Z3MBc52QYzSXj@mail.python.org>


Roundup Robot added the comment:

New changeset 6af3afbc7211 by R David Murray in branch '3.2':
#17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/6af3afbc7211

New changeset dfefae8df4f7 by R David Murray in branch '3.3':
Merge: #17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/dfefae8df4f7

New changeset c4512797b879 by R David Murray in branch 'default':
Merge: #17166: fix _dummy_thread import example.
http://hg.python.org/cpython/rev/c4512797b879

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

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

From report at bugs.python.org  Sat Feb  9 19:26:19 2013
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Feb 2013 18:26:19 +0000
Subject: [docs] [issue17166] Fix the suggested usage of _dummy_thread module
In-Reply-To: <1360396998.84.0.582520403426.issue17166@psf.upfronthosting.co.za>
Message-ID: <1360434379.62.0.796430835269.issue17166@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Berker.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun Feb 10 09:24:44 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 10 Feb 2013 08:24:44 +0000
Subject: [docs] [issue8040] documentation pages should link to other
	versions of the	same page
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <1360484684.05.0.117972108114.issue8040@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/issue8040>
_______________________________________

From report at bugs.python.org  Sun Feb 10 09:38:41 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Sun, 10 Feb 2013 08:38:41 +0000
Subject: [docs] [issue17175] update PEP 430
Message-ID: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>


New submission from Tshepang Lekhonkhobe:

The issue referred to has since been resolved.

----------
assignee: docs at python
components: Documentation
files: update.diff
keywords: patch
messages: 181778
nosy: docs at python, tshepang
priority: normal
severity: normal
status: open
title: update PEP 430
Added file: http://bugs.python.org/file29025/update.diff

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

From report at bugs.python.org  Sun Feb 10 19:30:11 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Feb 2013 18:30:11 +0000
Subject: [docs] [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <1360521011.9.0.067599361236.issue17175@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl, ncoghlan

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

From thomaspinckney3 at gmail.com  Mon Feb 11 00:26:53 2013
From: thomaspinckney3 at gmail.com (thomaspinckney3 at gmail.com)
Date: Sun, 10 Feb 2013 23:26:53 -0000
Subject: [docs] Profile objects should be documented (issue 6696)
Message-ID: <20130210232653.10005.85565@psf.upfronthosting.co.za>

Thanks for all of the feedback. I re-applied my patch from last year to
the default branch and went through your suggestions. I'll upload the
new patch tonight.

If you still see issues with this patch feel free to either email
suggestions to me or directly change things yourself, whatever is
easier.


http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst
File Doc/library/profile.rst (left):

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#oldcode173
Doc/library/profile.rst:173: 
It was originally higher up in the docs and I moved it toward the end
since it seemed less important for someone eager to just figure out how
to create a profile.

On 2013/02/05 04:04:09, eric.araujo wrote:
> Was this section moved wholesale or also edited?

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#oldcode583
Doc/library/profile.rst:583: :func:`your_time_func` should return a
single number.  If it returns
Yes, my mistake. I corrected this by going back to the existing text.

On 2013/02/05 04:04:09, eric.araujo wrote:
> This is a divergence from what profile.Profile expects (single number
or list of
> numbers), so I think some part of this section should be kept.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst
File Doc/library/profile.rst (right):

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode13
Doc/library/profile.rst:13: :source:`Modules/_lsprof.c` and
:source:`Lib/pstats.py`
I defer to your judgement here, but I was just going for completeness. I
was earlier trying to understand all of the profiler code and it would
have been convenient to have links to everything in one place. But let
me know what you think is best.

On 2013/02/05 04:04:09, eric.araujo wrote:
> The intention for source code links is to direct people to the modules
that are
> the most readable, to encourage learning from the source in addition
to the
> docs.
> 
> cProfile looks like a thin wrapper to me, so I?m not sure the link
adds value. 
> For _lsprof, adding a link is an interesting idea; no C-coded modules
have
> source links as of now, but I don?t see why they would not.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode73
Doc/library/profile.rst:73: The above action would run :func:`foo` and
print profile results like the
Thanks! Fixed.

On 2013/02/05 04:04:09, eric.araujo wrote:
> :func: is useful to have a link generated, IOW for existing stdlib
functions;
> here simple ``code`` markup would be better.  (I know your patch
inherits this
> minor issue from the existing doc, but just wanted to mention it in
case you?re
> interesting in reST fine points, or for the developer that will end up
> committing the patch).

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode102
Doc/library/profile.rst:102: is the total time spent in this and all
subfunctions (from invocation
Good idea. Done.

On 2013/02/05 04:04:09, eric.araujo wrote:
> I like how the other definitions hint at the meaning of the cryptic
names, e.g.
> mentioning ?total time? for tottime.  Could you maybe use ?cumulative?
here?

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode114
Doc/library/profile.rst:114: same, and only the single figure is
printed.
Reworded. I don't know the answer to the mutual-recursion question you
raised so I didn't change anything about that.

On 2013/02/05 04:04:09, eric.araujo wrote:
> I would rephrase this slightly to say earlier that it?s only recursive
functions
> that print two figures, e.g.:
> 
> When there are two numbers in the first column (for example ``43/3``),
it means
> that the function recursed.  The second value is the number of
primitive calls
> and the former is the actual number of calls.
> 
> (former/latter can be uncommon terms for non-native speakers)
> 
> Question: would ?total? be better than ?actual??
> Question: if A calls B and B calls A, does it show up as recursive
ncalls? 
> (maybe too advanced/useless for this section though)

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode125
Doc/library/profile.rst:125: The file :file:`cProfile.py` can also be
invoked as a script to profile another
Done.

On 2013/02/05 04:04:09, eric.araujo wrote:
> Suggestion: The :mod:`cProfile` module can also etc.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode200
Doc/library/profile.rst:200: The :mod:`profile` and :mod:`cProfile`
Modules
Done

On 2013/02/05 04:04:09, eric.araujo wrote:
> I would have kept ?reference? in this heading, to make the table of
contents
> clear.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode203
Doc/library/profile.rst:203: .. module:: cProfile
I switched them to both point to the module reference.

On 2013/02/05 04:04:09, eric.araujo wrote:
> Both module directives (which create index targets) should probably be
at the
> same location in the file.  Do you think it would be more useful to
point to the
> module reference (this section) or the top of the file?

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode213
Doc/library/profile.rst:213: exec(command, __main__.__dict__,
__main__.__dict__)
I was trying to illustrate an example. I guess I could provide a
different example that somehow referenced the current module or
something? Any ideas?

On 2013/02/05 04:04:09, eric.araujo wrote:
> What module is __main__?  What happens when there is no __main__
module?

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode237
Doc/library/profile.rst:237: the `timer` argument. This must be a
function that returns a single number
Fixed

On 2013/02/05 04:04:09, eric.araujo wrote:
> *timer* (that?s the style used to refer to function parameters in the
doc of the
> function)

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode241
Doc/library/profile.rst:241: time unit would be .001. For best results,
it may be necesary to hard-code
Fixed

On 2013/02/05 04:04:09, eric.araujo wrote:
> ``0.001``

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode242
Doc/library/profile.rst:242: the new timer in the C source of
:source:`Modules/_lsprof.c`.
Removed

On 2013/02/05 04:04:09, eric.araujo wrote:
> These lines of the previous doc don?t seem terribly helpful to me;
people don?t
> routinely edit and recompile Python to get a better profiler.  Remove
it /
> suggest opening a feature request?

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode244
Doc/library/profile.rst:244: Additionall, directly using the
:class:`Profile` class allows formatting
Fixed

On 2013/02/05 04:04:09, eric.araujo wrote:
> Typo in the first word.  May want to rephrase to avoid two adverbs in
a row.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode256
Doc/library/profile.rst:256: .. method:: Profile.enable()
Ah ok. Corrected.

On 2013/02/05 04:04:09, eric.araujo wrote:
> method directives can be nested inside a class directive, which is
nice grouping
> and removes the need to repeat the class name.

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode269
Doc/library/profile.rst:269: .. method:: Profile.print_sats(sort=-1)
oops.

On 2013/02/05 04:04:09, eric.araujo wrote:
> stats :)

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode280
Doc/library/profile.rst:280: Profiles the cmd via :func:`exec`.
Fixed.

On 2013/02/05 04:04:09, eric.araujo wrote:
> Profile*
> 
> (The PEP about docstrings conventions explains that verbs are
commands, not
> descriptions.)

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode288
Doc/library/profile.rst:288: Profiles the specified function call.
Good point!

On 2013/02/05 04:04:09, eric.araujo wrote:
> In the spirit of your other changes to show exactly what?s happening: 
Profile
> ``func(*args, **kwargs)``

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode591
Doc/library/profile.rst:591: pr = profile.Profile(your_time_func)
I added a reference to the bottom of the new section on custom timers. I
don't have 3.3 available to me at the moment so I couldn't actually test
my reference to using time.perf_counter but from the docs it looks like
a reasonable example.

On 2013/02/05 04:04:09, eric.araujo wrote:
> Great place to mention the 3.3-new timer functions!

http://bugs.python.org/review/6696/diff/4889/Doc/library/profile.rst#newcode600
Doc/library/profile.rst:600: Be warned that you should calibrate the
profiler class for the timer function
I added a cross reference.

On 2013/02/05 04:04:09, eric.araujo wrote:
> If I?m not mistaken this is now the first occurence of the term
?calibrate?; it
> would be good to keep some link in the reader?s mind to the section
above that
> explains what it is.

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

From report at bugs.python.org  Mon Feb 11 00:35:16 2013
From: report at bugs.python.org (Tom Pinckney)
Date: Sun, 10 Feb 2013 23:35:16 +0000
Subject: [docs] [issue6696] Profile objects should be documented
In-Reply-To: <1250182637.82.0.304646827828.issue6696@psf.upfronthosting.co.za>
Message-ID: <1360539315.19.0.702866628617.issue6696@psf.upfronthosting.co.za>


Tom Pinckney added the comment:

Draft of new updates based on Eric's feedback. I haven't done a final proof-reading over this patch as I wanted to upload it and see if I'm heading in the right direction first.

----------
Added file: http://bugs.python.org/file29036/patch2.diff

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

From report at bugs.python.org  Mon Feb 11 06:47:24 2013
From: report at bugs.python.org (py.user)
Date: Mon, 11 Feb 2013 05:47:24 +0000
Subject: [docs] [issue17178] In all.__doc__ and any.__doc__ need to clarify
	the	behaviour with an empty iterable like in documentation
Message-ID: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>


New submission from py.user:

>>> help(all)

"
all(...)
    all(iterable) -> bool
    
    Return True if bool(x) is True for all values x in the iterable.
"

>>> all([])
True
>>> bool()
False
>>>

----------
assignee: docs at python
components: Documentation
messages: 181873
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In all.__doc__ and any.__doc__ need to clarify the behaviour with an empty iterable like in documentation
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Feb 11 18:37:59 2013
From: report at bugs.python.org (Franck Michea)
Date: Mon, 11 Feb 2013 17:37:59 +0000
Subject: [docs] [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360604279.14.0.963012671651.issue12077@psf.upfronthosting.co.za>


Franck Michea added the comment:

Here is at least a correction of Descriptors' HowTo. There are two versions since some stuff differs (object inheritance, ...).

Here are some of my interrogations though:
 - RevealAccess is not using instance parameter, so value is shared. Is this intended?
 - Don't really know what to do with "Function and Methods" part. First I don't really understand the relevance of this in a descriptor how-to. Also it is know outdated in python3 version (unbound thing, ...), so what do?
 - In __getattribute__ function, I don't really understand the paramters given to __get__, why None and the instance? But this is probably my fault.

This also doesn't answer the question about the real source that should be kept. What to do?

I also need a proof-read, since english is not my first language... Anyway it's clearly not enough to be published like that

Have a nice day!

----------
keywords: +patch
nosy: +kushou
versions: +Python 3.5
Added file: http://bugs.python.org/file29040/12077_descriptor_howto_python3.patch

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

From report at bugs.python.org  Mon Feb 11 18:38:18 2013
From: report at bugs.python.org (Franck Michea)
Date: Mon, 11 Feb 2013 17:38:18 +0000
Subject: [docs] [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360604298.2.0.994045096305.issue12077@psf.upfronthosting.co.za>


Changes by Franck Michea <franck.michea at gmail.com>:


Added file: http://bugs.python.org/file29041/12077_descriptor_howto_python2.patch

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

From report at bugs.python.org  Mon Feb 11 20:42:49 2013
From: report at bugs.python.org (Roy Smith)
Date: Mon, 11 Feb 2013 19:42:49 +0000
Subject: [docs] [issue15606] re.VERBOSE whitespace behavior not completely
	documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360611769.31.0.967255793546.issue15606@psf.upfronthosting.co.za>


Changes by Roy Smith <roy at panix.com>:


----------
nosy: +roysmith

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

From report at bugs.python.org  Mon Feb 11 20:53:17 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Feb 2013 19:53:17 +0000
Subject: [docs] [issue15606] re.VERBOSE whitespace behavior not completely
	documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360612397.14.0.901652742525.issue15606@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also related issue11204.

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

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

From report at bugs.python.org  Tue Feb 12 01:07:09 2013
From: report at bugs.python.org (Greg Couch)
Date: Tue, 12 Feb 2013 00:07:09 +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: <1360627629.48.0.628654026974.issue16851@psf.upfronthosting.co.za>


Greg Couch added the comment:

In my opinion, the Python 2.7 results are wrong.

In Python 2.7, inspect.ismethod returns True for both bound and unbound methods -- ie., is broken according to the documentation.  As a workaround, I'm using:

def is_bound_method(obj):
    return hasattr(obj, '__self__') and obj.__self__ is not None

is_bound_method also works for methods of classes implemented in C, e.g., int:

>>> a = 1
>>> is_bound_method(a.__add__)
True
>>> is_bound_method(int.__add__)
False

But is not very useful in that case because inspect.getargspec does not work for functions implemented in C.

is_bound_method works unchanged in Python 3, but as noted above, in Python 3, inspect.ismethod properly distinguishes between bound and unbound methods, so it is not necessary.

----------
nosy: +gregcouch

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

From report at bugs.python.org  Tue Feb 12 02:20:00 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Feb 2013 01:20:00 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
Message-ID: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Language manual, section 7.8. The raise statement has no mention of the 'from None' option. Indeed it says "if given, the second expression must be another exception class or instance", which would exclude None.

Library manual, Ch 5. Built-in Exceptions, says
'''
When raising a new exception (rather than using a bare raise to re-raise the exception currently being handled), the implicit exception context can be supplemented with an explicit cause by using from with raise:

raise new_exc from original_exc

The expression following from must be an exception or None. It will be set as __cause__ on the raised exception. Setting __cause__ also implicitly sets the __suppress_context__ attribute to True, so that using raise new_exc from None effectively replaces the old exception with the new one for display purposes (e.g. converting KeyError to AttributeError, while leaving the old exception available in __context__ for introspection when debugging.
'''
I am not sure how much should be copied over, but None should be at least mentioned and perhaps there should be a cross-reference.

I am also not sure how much applies to 3.2, but there is no version-added or -changed note with the above.

----------
assignee: docs at python
components: Documentation
messages: 181939
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document 'from None' in raise statement doc.
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Feb 12 09:25:53 2013
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Feb 2013 08:25:53 +0000
Subject: [docs] [issue12077] Harmonizing descriptor protocol documentation
In-Reply-To: <1305381385.94.0.81554539251.issue12077@psf.upfronthosting.co.za>
Message-ID: <1360657553.61.0.11389932968.issue12077@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> 

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

From berker.peksag at gmail.com  Tue Feb 12 10:20:42 2013
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Tue, 12 Feb 2013 09:20:42 -0000
Subject: [docs] Harmonizing descriptor protocol documentation (issue 12077)
Message-ID: <20130212092042.10005.30326@psf.upfronthosting.co.za>


http://bugs.python.org/review/12077/diff/7351/Doc/howto/descriptor.rst
File Doc/howto/descriptor.rst (right):

http://bugs.python.org/review/12077/diff/7351/Doc/howto/descriptor.rst#newcode393
Doc/howto/descriptor.rst:393: '''Emulate PyStaticMethod_Type() in
Objects/funcobject.c'''
Nit: I would use triple quotes.

See PEP 257:

"For consistency, always use """triple double quotes""" around
docstrings."

http://www.python.org/dev/peps/pep-0257/

http://bugs.python.org/review/12077/diff/7351/Doc/howto/descriptor.rst#newcode419
Doc/howto/descriptor.rst:419: is to create alternate class constructors.
 In Python 2.3, the classmethod
Python 2.3 is almost 10 years old. I think this part can be deleted (at
least in Python 3).

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

From report at bugs.python.org  Tue Feb 12 15:54:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 14:54:57 +0000
Subject: [docs] [issue17193] Use binary prefixes
Message-ID: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Starting around 1998, a number of standards and trade organizations approved standards and recommendations for a new set of binary prefixes that would refer unambiguously to powers of 1024. According to these, the SI prefixes would only be used in the decimal sense, even when referring to data storage capacities: kilobyte and megabyte would denote one thousand bytes and one million bytes respectively (consistent with SI), while new terms such as kibibyte, mebibyte and gibibyte, abbreviated KiB, MiB, and GiB, would denote 1024 bytes, 1048576 bytes, and 1073741824 bytes respectively.[1]

The proposed patch replaces old terms such as kB or KBytes by new terms such as KiB.

[1] http://en.wikipedia.org/wiki/Binary_prefix

----------
assignee: docs at python
components: Documentation
files: binary_prefixes.patch
keywords: easy, patch
messages: 181961
nosy: docs at python, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use binary prefixes
type: enhancement
Added file: http://bugs.python.org/file29049/binary_prefixes.patch

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

From report at bugs.python.org  Tue Feb 12 17:13:38 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 16:13:38 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360685618.37.0.206063877507.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch looks good except for the consistent lack of space between number and unit, e.g. "5MiB" instead of "5 MiB". Is there a reason for this?

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Feb 12 17:37:42 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 16:37:42 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360687062.84.0.731523839757.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, there is a little reason. It looks ugly if a line broken between number and unit (this is possible if we use space). A non-breakable space is better, but it seems that there is no easy way to specify it in ReST. I will be glad to be wrong.

----------

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

From report at bugs.python.org  Tue Feb 12 18:04:49 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 17:04:49 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360688689.64.0.605661724598.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It might be ugly but it's also incorrect formatting to leave the space out. =) And I think it makes it harder to actually read the number.

If you really want to avoid the breaking you can use the tip at http://stackoverflow.com/questions/11830242/non-breaking-space or the Unicode \xa0 literal.

----------

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

From report at bugs.python.org  Tue Feb 12 21:07:31 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Feb 2013 20:07:31 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360699651.33.0.643712530382.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes I have seen these tips and they look complicated enough. Here is an updated patch with spaces between numbers and units.

----------
Added file: http://bugs.python.org/file29052/binary_prefixes_2.patch

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

From report at bugs.python.org  Tue Feb 12 22:13:51 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2013 21:13:51 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360703631.34.0.574001705692.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

LGTM

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Feb 13 04:33:15 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 03:33:15 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360726395.11.0.333643731071.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

This is a gentle ping of this issue.  Can somebody please review and let me know what needs to be done to get this committed?  I did test the patch on 2/12/2013 and it seems to work from the latest 3.4.  Thanks!

----------

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

From report at bugs.python.org  Wed Feb 13 09:05:37 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 08:05:37 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360742737.56.0.212742812052.issue16278@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The doc change looks good to me. I am adding Terry and Ezio to see if they have any comments on wordings in the doc. If not, I can commit this change. I think that this is helpful.

----------
nosy: +ezio.melotti, orsenthil, terry.reedy

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

From report at bugs.python.org  Wed Feb 13 09:10:21 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 08:10:21 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360743021.67.0.0864078681857.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

I commented above that the tests are not very DRY though.  Shouldn't there be tests to check that the documented behavior is correct?

----------

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

From report at bugs.python.org  Wed Feb 13 09:43:42 2013
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Feb 2013 08:43:42 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1360743021.67.0.0864078681857.issue16278@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOSaZNPxDhnBJ08xaJtAAN1ZR__+rKr2W3rY-d4yKS1C9Q@mail.gmail.com>


Senthil Kumaran added the comment:

Chris:  The patch is for the docs. the test code I believe, is for
reference. It would be to run it on different OS and verify the
documentation matches the behavior.I am okay with more than one person
verifying this and I shall do on OS'es I have.

----------

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

From report at bugs.python.org  Wed Feb 13 11:58:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 10:58:22 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360753102.73.0.557959058656.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For what versions can I apply this patch?

----------

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

From report at bugs.python.org  Wed Feb 13 16:31:08 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 15:31:08 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360769468.52.0.127393508468.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Chris,
   I first verified the issue then created some wording and you pointed out that we needed test cases so I created a bunch of test cases.  As you pointed out "I count 2*3*2=12 possibilities to check (excluding src and dst being on different filesystems):" so I created 16 test cases then discovered that the behavior is different on Windows and Unix so all together there are 32 test cases.  Your last comment about the test cases being "Dry" didn't make sense to me.  If you provide specific feedback I would be glad to work on the issue.  The test cases are designed to make sure that the documented behavior is actually how Python performs.  It made the most sense to me to put together two patches one for the test cases and another for the documentation, but maybe that has confused everybody?  If it would help I could submit a single patch.  OSRenameCombinations.py was just for reference to prove to myself that I got all the possible test cases.

I am a fairly new Python contributor and this is my first attempt at writing test cases so I could be missing something.  Thanks for the mentorship and the time required for a little extra guidance.

----------

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

From report at bugs.python.org  Wed Feb 13 16:47:33 2013
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Feb 2013 15:47:33 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360770453.38.0.0923693018631.issue17193@psf.upfronthosting.co.za>


Brett Cannon added the comment:

IMO I say just do 3.4 since it isn't really a bug fix but a cleanup, but I wouldn't object if it was backported.

----------

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

From report at bugs.python.org  Wed Feb 13 18:07:26 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Feb 2013 17:07:26 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360775246.83.0.00886161149961.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then I'll apply this to 3.3 too. This will facilitate support of both versions.

----------
assignee: docs at python -> serhiy.storchaka
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 13 18:08:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 17:08:08 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360775288.93.0.346986698762.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Senthil, in my experience, whenever documentation is added that documents new aspects of behavior (e.g. is not just a rewording of existing documentation), tests are always added simultaneously (if not already present) to ensure that the code doesn't regress against the new documentation.

Todd, DRY means "don't repeat yourself."  You can look it up on Wikipedia, etc.  Identical chunks of code are repeated several times which make it harder for others to see how the test cases differ from each other (as well as making the code harder to maintain).

----------

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

From report at bugs.python.org  Wed Feb 13 18:13:51 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 17:13:51 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360775631.21.0.426559387271.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> If it would help I could submit a single patch.

Yes, a single patch is best.  One way to make code more DRY is refactoring to use helper functions as needed (i.e. same code in multiple places -> one helper function).

----------

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

From report at bugs.python.org  Wed Feb 13 19:06:03 2013
From: report at bugs.python.org (Andrew McNabb)
Date: Wed, 13 Feb 2013 18:06:03 +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: <1360778763.02.0.920870111488.issue14191@psf.upfronthosting.co.za>


Changes by Andrew McNabb <amcnabb at mcnabbs.org>:


----------
nosy: +amcnabb

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

From report at bugs.python.org  Wed Feb 13 19:06:44 2013
From: report at bugs.python.org (Andrew McNabb)
Date: Wed, 13 Feb 2013 18:06:44 +0000
Subject: [docs] [issue15258] argparse documentation: Improve optparse
	section	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1360778804.91.0.311635303864.issue15258@psf.upfronthosting.co.za>


Changes by Andrew McNabb <amcnabb at mcnabbs.org>:


----------
nosy: +amcnabb

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

From report at bugs.python.org  Wed Feb 13 19:59:13 2013
From: report at bugs.python.org (Todd Rovito)
Date: Wed, 13 Feb 2013 18:59:13 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360781953.07.0.448127783494.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Chris,
  Thanks for the clarification.  I thought you were telling me my test cases were dry as in dry humor....I will read-up on the dry concept and see what I can do to consolidate plus I will combine the patches.  Initially I am thinking I could collapse all the test cases into two functions each for their respective operating system.  Would that be ok?

----------

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

From report at bugs.python.org  Wed Feb 13 20:09:53 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 13 Feb 2013 19:09:53 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360782593.31.0.376244737265.issue16278@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

The number of test cases isn't the problem.  Having more but finer-grained test cases is usually preferred in fact.  It's just that the test cases should be sharing code where possible so that they're shorter and easy to see how they differ from one another.

----------

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

From report at bugs.python.org  Thu Feb 14 04:50:16 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 14 Feb 2013 03:50:16 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1360813815.59.0.0227633512248.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've given this some more thought and quite a bit more work and reorganization. I think this clarifies the usage of memoryviews and buffers as well as the C-level API for each.

This is my first run at contributing a patch of any sort, so please let me know if there's anything further needed or any changes are required (or I'm just right out to lunch with this).

----------
Added file: http://bugs.python.org/file29067/buffer.patch

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

From report at bugs.python.org  Thu Feb 14 05:56:02 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Feb 2013 04:56:02 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1360817762.4.0.28366937755.issue16278@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"directory name.Yet a" needs spaces after '.'.

The text is decent English and clear enough sentence by sentence, but the reality and hence the text as a whole is confusing.

I wonder if it would be possible to make a little table

                    dest
                    ----   
Src     file         empty-dir    non-empty-dir
----    -----------------------------------------
file |            |            |

dir

with the behavior for each combination indicated, 'success' or 'OSError', with two lines prefixed with Unix, Win where they differ. Then the differences would be much more obvious.

(A separate issue: Patch says that Windows currently raises a different error in one situation. I think it would be better -- in a future version -- if that were caught and reraised as OSError also.)

----------

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

From report at bugs.python.org  Thu Feb 14 07:47:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 14 Feb 2013 06:47:08 +0000
Subject: [docs] [issue17203] add long option names to unittest discovery docs
Message-ID: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

Currently, unittest's discovery command-line documentation:

http://docs.python.org/dev/library/unittest.html#test-discovery

does not include the long option names (--start-directory, --pattern, and --top-level-directory):

http://hg.python.org/cpython/file/0f827775f7b7/Lib/unittest/main.py#l215

This issue is to add those.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182078
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: add long option names to unittest discovery docs
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Feb 14 11:56:30 2013
From: report at bugs.python.org (py.user)
Date: Thu, 14 Feb 2013 10:56:30 +0000
Subject: [docs] [issue17205] In the help() function the order of methods
	changes
Message-ID: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>


New submission from py.user:

>>> class A:
...   '''class'''
...   def c(self):
...     '''c doc'''
...     pass
...   def b(self):
...     '''b doc'''
...     pass
...   def a(self):
...     '''a doc'''
...     pass
... 
>>> help(A)

class A(builtins.object)
 |  class
 |  
 |  Methods defined here:
 |  
 |  a(self)
 |      a doc
 |  
 |  b(self)
 |      b doc
 |  
 |  c(self)
 |      c doc
 |  
 

When I have many methods ordered in the source in readable order, the help() function is mixing them, so the last method goes to the top and the first method goes to the bottom.

I would like to have an option, whether I want sort them or not.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 182086
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: In the help() function the order of methods changes
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Feb 14 13:39:28 2013
From: report at bugs.python.org (Todd Rovito)
Date: Thu, 14 Feb 2013 12:39:28 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1360817762.4.0.28366937755.issue16278@psf.upfronthosting.co.za>
Message-ID: <C26B99FA-F178-4C9B-B375-AAF604B00D2C@gmail.com>


Todd Rovito added the comment:

Thanks Terry and Chris you guys have supplied great feedback.  I will work on the issue and try to get a new patch updated by end of the weekend (2/18/13).

Sent from my iPhone

On Feb 13, 2013, at 11:56 PM, "Terry J. Reedy" <report at bugs.python.org> wrote:

> 
> Terry J. Reedy added the comment:
> 
> "directory name.Yet a" needs spaces after '.'.
> 
> The text is decent English and clear enough sentence by sentence, but the reality and hence the text as a whole is confusing.
> 
> I wonder if it would be possible to make a little table
> 
>                    dest
>                    ----   
> Src     file         empty-dir    non-empty-dir
> ----    -----------------------------------------
> file |            |            |
> 
> dir
> 
> with the behavior for each combination indicated, 'success' or 'OSError', with two lines prefixed with Unix, Win where they differ. Then the differences would be much more obvious.
> 
> (A separate issue: Patch says that Windows currently raises a different error in one situation. I think it would be better -- in a future version -- if that were caught and reraised as OSError also.)
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16278>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Feb 14 14:30:24 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Thu, 14 Feb 2013 13:30:24 +0000
Subject: [docs] [issue17205] In the help() function the order of methods
	changes
In-Reply-To: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>
Message-ID: <1360848624.38.0.641593769612.issue17205@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Sorry, but there is no way of telling the order as methods are respresented internally as a dictionary. Please close this as invalid.

----------
nosy: +ramchandra.apte

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

From report at bugs.python.org  Thu Feb 14 14:32:25 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 14 Feb 2013 13:32:25 +0000
Subject: [docs] [issue17135] imp doc should direct to importlib
In-Reply-To: <1360080581.61.0.501686856177.issue17135@psf.upfronthosting.co.za>
Message-ID: <1360848745.69.0.09813178592.issue17135@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +brett.cannon
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7 -Python 3.1

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

From report at bugs.python.org  Thu Feb 14 17:14:56 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 16:14:56 +0000
Subject: [docs] [issue17205] In the help() function the order of methods
	changes
In-Reply-To: <1360839390.21.0.289319464698.issue17205@psf.upfronthosting.co.za>
Message-ID: <1360858496.16.0.797771874789.issue17205@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ramchandra is correct.  If you were to implement a "don't sort" flag, what you would get is *random* order (and a different order each time, in 3.3+).

Further, this is Python-interpreter internal data structure we are talking about, so it isn't even an option to use OrderedDict in pydoc.

I'm closing this as "won't fix" because it would certainly be nice to have this ability...but there is no practical way to implement it.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Feb 14 19:31:03 2013
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Feb 2013 18:31:03 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1360866663.75.0.347792269151.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Ping!

If there are no objections, would anyone mind committing this?

----------

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

From report at bugs.python.org  Thu Feb 14 20:16:11 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 19:16:11 +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: <1360869370.97.0.0146498373754.issue14515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't understand a phrase "and is assigned to the target of the as clause on entry to a context". Typo?

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

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

From report at bugs.python.org  Thu Feb 14 22:18:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 Feb 2013 21:18:06 +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: <1360876685.97.0.0898275869696.issue14515@psf.upfronthosting.co.za>


R. David Murray added the comment:

The patch is missing the markup for the 'as' keyword (it should read :keyword:`as`).  If that were added, would the sentence make sense to you?  Would it be clearer to say that the directory name is returned by the __enter__ method?

----------

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

From report at bugs.python.org  Thu Feb 14 22:29:32 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Feb 2013 21:29:32 +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: <1360877372.56.0.958546109872.issue14515@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Aha, now it makes a sense to me.

I don't know which variant will be clear.

----------

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

From report at bugs.python.org  Fri Feb 15 10:24:39 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 09:24:39 +0000
Subject: [docs] [issue17208] add note/warning about daemon threads
Message-ID: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

People are generally not aware of the properties of daemon threads.
I suggest to add a note such as the following:

? Daemon threads are abruptly stopped at shutdown. Their resources (such as open files, database transactions, etc.) may not be released properly. If you want your threads to stop gracefully, make them non-daemonic and use a suitable signalling mechanism such as an Event. ?

----------
assignee: docs at python
components: Documentation
messages: 182133
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: add note/warning about daemon threads
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/issue17208>
_______________________________________

From report at bugs.python.org  Fri Feb 15 10:28:14 2013
From: report at bugs.python.org (Tim Golden)
Date: Fri, 15 Feb 2013 09:28:14 +0000
Subject: [docs] [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <511DFFAA.4010302@timgolden.me.uk>


Tim Golden added the comment:

+1 This is essentially the answer to the naive user's question:

"Why would anyone *not* use daemon threads given that they're less
hassle to manage?"

----------
nosy: +tim.golden

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

From report at bugs.python.org  Fri Feb 15 14:20:26 2013
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 15 Feb 2013 13:20:26 +0000
Subject: [docs] [issue17210] documentation of PyUnicode_Format() states
	wrong	argument type requirements
Message-ID: <1360934426.3.0.547345278452.issue17210@psf.upfronthosting.co.za>


New submission from Stefan Behnel:

The current documentation says:

"""
PyObject* PyUnicode_Format(PyObject *format, PyObject *args)
    Return value: New reference.

    Return a new string object from format and args; this is analogous to format % args. The args argument must be a tuple.
"""

According to the implementation, however, "args" can be a tuple, a unicode string, or an arbitrary mapping, i.e. everything that Python's "%" operator allows for strings as well.

----------
assignee: docs at python
components: Documentation
messages: 182140
nosy: docs at python, scoder
priority: normal
severity: normal
status: open
title: documentation of PyUnicode_Format() states wrong argument type requirements
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 15 18:30:48 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Feb 2013 17:30:48 +0000
Subject: [docs] [issue17178] In all.__doc__ and any.__doc__ need to clarify
	the	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360949448.53.0.447760908164.issue17178@psf.upfronthosting.co.za>


?ric Araujo added the comment:

If someone wants to write the patch for this, feel free to ask (here or on the core-mentorship friendly mailing list) if you need help finding the right C file or anything else.

----------
components: +Interpreter Core -Documentation
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Fri Feb 15 19:44:36 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 18:44:36 +0000
Subject: [docs] [issue17178] In all.__doc__ and any.__doc__ need to clarify
	the	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360953876.05.0.380842812319.issue17178@psf.upfronthosting.co.za>


Ankur Ankan added the comment:

I am a beginner and want to write the patch for this issue, so please help me find the right C file.
Thanks.

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

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

From report at bugs.python.org  Fri Feb 15 19:51:14 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 18:51:14 +0000
Subject: [docs] [issue17178] In all.__doc__ and any.__doc__ need to clarify
	the	behaviour with an empty iterable like in documentation
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360954274.55.0.296706575157.issue17178@psf.upfronthosting.co.za>


Ankur Ankan added the comment:

I guess I have found it. It's bltinmodule.c .

----------

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

From report at bugs.python.org  Fri Feb 15 21:04:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:04:38 +0000
Subject: [docs] [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <3Z756F45vHzSw2@mail.python.org>


Roundup Robot added the comment:

New changeset f306777e0b6d by Ezio Melotti in branch 'default':
#17175: remove outdated paragraph about issue #8040 from PEP 430.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/peps/rev/f306777e0b6d

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

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

From report at bugs.python.org  Fri Feb 15 21:04:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:04:39 +0000
Subject: [docs] [issue8040] documentation pages should link to other
	versions of the	same page
In-Reply-To: <1267543845.91.0.112810116218.issue8040@psf.upfronthosting.co.za>
Message-ID: <3Z756G2mGSzSw2@mail.python.org>


Roundup Robot added the comment:

New changeset f306777e0b6d by Ezio Melotti in branch 'default':
#17175: remove outdated paragraph about issue #8040 from PEP 430.  Patch by Tshepang Lekhonkhobe.
http://hg.python.org/peps/rev/f306777e0b6d

----------

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

From report at bugs.python.org  Fri Feb 15 21:05:51 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 20:05:51 +0000
Subject: [docs] [issue17175] update PEP 430
In-Reply-To: <1360485521.23.0.247947620648.issue17175@psf.upfronthosting.co.za>
Message-ID: <1360958751.02.0.169530103915.issue17175@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for 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/issue17175>
_______________________________________

From report at bugs.python.org  Fri Feb 15 21:30:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:30:38 +0000
Subject: [docs] [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <3Z75hF4hKBzQ2s@mail.python.org>


Roundup Robot added the comment:

New changeset e63c4bc81d9f by Antoine Pitrou in branch '2.7':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/e63c4bc81d9f

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

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

From report at bugs.python.org  Fri Feb 15 21:35:51 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 20:35:51 +0000
Subject: [docs] [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <3Z75pH0H2wzQT1@mail.python.org>


Roundup Robot added the comment:

New changeset 8753a3be4a3c by Antoine Pitrou in branch '3.2':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/8753a3be4a3c

New changeset 917ae89e59ce by Antoine Pitrou in branch '3.3':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/917ae89e59ce

New changeset 8b85f10b5341 by Antoine Pitrou in branch 'default':
Issue #17208: add a note about the termination behaviour of daemon threads.
http://hg.python.org/cpython/rev/8b85f10b5341

----------

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

From report at bugs.python.org  Fri Feb 15 21:36:07 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Feb 2013 20:36:07 +0000
Subject: [docs] [issue17208] add note/warning about daemon threads
In-Reply-To: <1360920279.83.0.716682096448.issue17208@psf.upfronthosting.co.za>
Message-ID: <1360960567.2.0.324114884305.issue17208@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Committed.

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

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

From report at bugs.python.org  Fri Feb 15 21:47:18 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 20:47:18 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360961238.16.0.881112855559.issue17178@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Titles should fit in the box if possible, and this can ;-).

----------
nosy: +terry.reedy
title: In all.__doc__ and any.__doc__ need to clarify the behaviour with an empty iterable like in documentation -> Clarify empty iterable result in any/all.__doc__, as in manual

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

From report at bugs.python.org  Fri Feb 15 22:06:57 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:06:57 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962417.15.0.689872685693.issue17178@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb 15 22:07:48 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:07:48 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962468.5.0.149192411705.issue17178@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file29080/patch.diff

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

From report at bugs.python.org  Fri Feb 15 22:08:52 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:08:52 +0000
Subject: [docs] [issue15606] re.VERBOSE whitespace behavior not completely
	documented
In-Reply-To: <1344534617.67.0.49137100671.issue15606@psf.upfronthosting.co.za>
Message-ID: <1360962532.51.0.723196963586.issue15606@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #17184.

----------

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

From report at bugs.python.org  Fri Feb 15 22:10:13 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:10:13 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1360962613.06.0.571651812831.issue17188@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +benjamin.peterson, ezio.melotti
type:  -> enhancement

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

From report at bugs.python.org  Fri Feb 15 22:12:22 2013
From: report at bugs.python.org (Ankur Ankan)
Date: Fri, 15 Feb 2013 21:12:22 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360962742.85.0.879667975582.issue17178@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file29081/patch.diff

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

From ezio.melotti at gmail.com  Fri Feb 15 22:17:02 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Fri, 15 Feb 2013 21:17:02 -0000
Subject: [docs] Use binary prefixes (issue 17193)
Message-ID: <20130215211702.31646.59237@psf.upfronthosting.co.za>


http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst
File Doc/howto/unicode.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst#newcode459
Doc/howto/unicode.rst:459: chunks (say, 1 KiB or 4 KiB), you need to
write error-handling code to catch the case
I would leave this alone, or possibly change it to "1k or 4k bytes".

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst
File Doc/library/lzma.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode161
Doc/library/lzma.rst:161: :class:`LZMACompressor` object can be as high
as 800 MiB. For this reason,
Why is this MiB?

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode306
Doc/library/lzma.rst:306: 1.5 GiB (inclusive).
Ditto.

http://bugs.python.org/review/17193/diff/7360/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/os.rst#newcode2332
Doc/library/os.rst:2332: is 64 kibibytes on Linux.
I would use KiB.

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst
File Doc/library/tarfile.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst#newcode672
Doc/library/tarfile.rst:672: maximum file size is 8 gibibytes. This is
an old and limited but widely
GiB

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst#newcode676
Doc/library/tarfile.rst:676: linknames, files bigger than 8 gibibytes
and sparse files. It is the de facto
Ditto.

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

From report at bugs.python.org  Fri Feb 15 22:20:58 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:20:58 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360963258.4.0.915757151093.issue17193@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

+1

I left some comments on Rietveld.
The SI standard says that there should be a space between the value and the unit, and I agree that while a no-break space would be better, a regular space is still better than no space at all.
Applying this on 3.3 and default is fine too.

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

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

From report at bugs.python.org  Fri Feb 15 22:38:37 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Feb 2013 21:38:37 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <3Z77Bh2dxNz7Ll4@mail.python.org>


Roundup Robot added the comment:

New changeset 0f7eec78569c by Ezio Melotti in branch '2.7':
#17178: update any()/all() docstrings to document their behavior with empty iterables.  Patch by Ankur Ankan.
http://hg.python.org/cpython/rev/0f7eec78569c

New changeset 1d4849f9e37d by Ezio Melotti in branch '3.2':
#17178: update any()/all() docstrings to document their behavior with empty iterables.  Patch by Ankur Ankan.
http://hg.python.org/cpython/rev/1d4849f9e37d

New changeset 34cfe145b286 by Ezio Melotti in branch '3.3':
#17178: merge with 3.2.
http://hg.python.org/cpython/rev/34cfe145b286

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

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

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

From report at bugs.python.org  Fri Feb 15 22:40:16 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 15 Feb 2013 21:40:16 +0000
Subject: [docs] [issue17178] Clarify empty iterable result in
	any/all.__doc__, as in manual
In-Reply-To: <1360561644.25.0.289819655691.issue17178@psf.upfronthosting.co.za>
Message-ID: <1360964416.13.0.748204688122.issue17178@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

----------
assignee: docs at python -> ezio.melotti
components: +Documentation -Interpreter Core
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Feb 15 23:31:50 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Feb 2013 22:31:50 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1360967510.5.0.770842707114.issue17193@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that we should contribute to ending the confusion. Searching KiB, MiB, GiB (with Google) gives a Wikipedia article as first or second hit, so the meanings of the abbreviations and terms are easily discoverable.

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

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

From ezio.melotti at gmail.com  Fri Feb 15 23:39:47 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Fri, 15 Feb 2013 22:39:47 -0000
Subject: [docs] Use binary prefixes (issue 17193)
Message-ID: <20130215223947.10247.71371@psf.upfronthosting.co.za>


http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst
File Doc/howto/unicode.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst#newcode459
Doc/howto/unicode.rst:459: chunks (say, 1 KiB or 4 KiB), you need to
write error-handling code to catch the case
On 2013/02/15 22:57:38, storchaka wrote:
> On 2013/02/15 22:17:02, ezio.melotti wrote:
> > I would leave this alone, or possibly change it to "1k or 4k bytes".
> 
> I doubt anyone reads the file in chunks of 1000 or 4000 bytes. It's
rather 1024
> or 4096 bytes.

Using powers of 2 is common, but is there any real advantage?  If you
still want to keep powers of 2 I would prefer to use "1024 or 4096
bytes" rather than using KiB.

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst
File Doc/library/lzma.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode161
Doc/library/lzma.rst:161: :class:`LZMACompressor` object can be as high
as 800 MiB. For this reason,
On 2013/02/15 22:57:38, storchaka wrote:
> On 2013/02/15 22:17:02, ezio.melotti wrote:
> > Why is this MiB?
> 
> See for example xz manual. 800 MiB is the memory usage for the
compression with
> preset 9.

That doesn't mean that it's correct :)
800 MiB is equal to 838860800 bytes, and while it might indeed be the
exact value they used, it seems a bit arbitrary to me.

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

From report at bugs.python.org  Sat Feb 16 06:05:12 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Feb 2013 05:05:12 +0000
Subject: [docs] [issue17179] Misleading error from type() when passing
	unknown	keyword argument
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1360991112.28.0.120316277499.issue17179@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The types.new_class docs are quite clear that the supplied keyword arguments are equivalent to those provided in the type header (if you want to pre-populate the namespace, that's what exec_body is for). The problem here is that the dual signature of type (retrieving the type of an existing object, or creating a new one), and the fact that type.__prepare__ ignores all arguments, means the error message is thoroughly misleading when you pass an unknown keyword argument:

>>> type.__prepare__(foo=1)
{}
>>> type("Example", (), {}, foo=1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

>>> class Example(foo=1): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() takes 1 or 3 arguments

>>> import types
>>> types.new_class("Example", (), dict(foo=1))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ncoghlan/devel/py3k/Lib/types.py", line 52, in new_class
    return meta(name, bases, ns, **kwds)
TypeError: type() takes 1 or 3 arguments

The reason type.__prepare__ ignores its arguments is to make it easy for people to use type to anchor a custom metaclass hierarchy and call super().__prepare__(name, bases, **kwds) without needing to worry much about filtering the keyword arguments. (The class machinery intercepts the metaclass hint and never passes it to __prepare__ or the metaclass constructor).

That means the real change needed here is to update type's error message for bad arguments to properly report unknown keyword errors when using the PEP 3115 metaclass API.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: Incorrect use of type function in types.new_class -> Misleading error from type() when passing unknown keyword argument

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

From report at bugs.python.org  Sat Feb 16 06:38:43 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Feb 2013 05:38:43 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1360993123.59.0.346345866584.issue17188@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As Terry notes, the various pieces of "from None" documentation should also have a nearby directive like:

.. versionchanged: 3.3

   :const:`None` permitted as ``Y`` in ``raise X from Y`` 

.. versionadded: 3.3

   The ``__suppress_context__`` attribute to suppress automatic display of the exception context

----------

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

From report at bugs.python.org  Sat Feb 16 13:59:18 2013
From: report at bugs.python.org (July Tikhonov)
Date: Sat, 16 Feb 2013 12:59:18 +0000
Subject: [docs] [issue17215] documentation misprints
Message-ID: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>


New submission from July Tikhonov:

library/io.rst
io.open() signature lacks 'opener' argument.

library/importlib.rst
concreate -> concrete

----------
assignee: docs at python
components: Documentation
files: docs-misprint.diff
keywords: patch
messages: 182219
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: documentation misprints
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29086/docs-misprint.diff

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

From report at bugs.python.org  Sat Feb 16 15:05:36 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Sat, 16 Feb 2013 14:05:36 +0000
Subject: [docs] [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <1361023536.42.0.62445750828.issue17215@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

LGTM.

----------
nosy: +Ramchandra.Apte

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

From report at bugs.python.org  Sat Feb 16 16:31:36 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 16 Feb 2013 15:31:36 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <3Z7b0l49dPzQj1@mail.python.org>


Roundup Robot added the comment:

New changeset c1f846a99c85 by Serhiy Storchaka in branch '3.3':
Issue #17193: Use binary prefixes (KiB, MiB, GiB) for memory units.
http://hg.python.org/cpython/rev/c1f846a99c85

New changeset 73a16d3c066a by Serhiy Storchaka in branch 'default':
Issue #17193: Use binary prefixes (KiB, MiB, GiB) for memory units.
http://hg.python.org/cpython/rev/73a16d3c066a

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

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

From report at bugs.python.org  Sat Feb 16 16:34:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Feb 2013 15:34:01 +0000
Subject: [docs] [issue17193] Use binary prefixes
In-Reply-To: <1360680896.93.0.488268867275.issue17193@psf.upfronthosting.co.za>
Message-ID: <1361028841.26.0.299851451078.issue17193@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you, Ezio, for your comments.

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

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

From report at bugs.python.org  Sat Feb 16 23:30:52 2013
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Sat, 16 Feb 2013 22:30:52 +0000
Subject: [docs] [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361053852.38.0.802573501372.issue17203@psf.upfronthosting.co.za>


Gennadiy Zlobin added the comment:

Hi, here's the patch. Should I provide patches for other branches?

----------
keywords: +patch
nosy: +gennad
Added file: http://bugs.python.org/file29092/17203.patch

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

From report at bugs.python.org  Sat Feb 16 23:48:35 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 16 Feb 2013 22:48:35 +0000
Subject: [docs] [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361054915.67.0.173382849113.issue17203@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, one patch should be fine, though the change should be applied to all branches.

----------

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

From report at bugs.python.org  Sun Feb 17 03:42:38 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 02:42:38 +0000
Subject: [docs] [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1361068958.18.0.974181514073.issue13124@psf.upfronthosting.co.za>


Eric Snow added the comment:

Looking this over, it seems like there were outstanding objections to adding this to the devguide and to the content.  I still think the devguide is the right place and that something like my second patch would be appropriate.

Before I take any time to update the patch, does anyone object to the location or intent of the changes?

Also, I'm fine with adapting/incorporating or linking to Stefan's script.  The whole point is to make it as easy as possible to spin up and run a build slave. :)

----------
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Sun Feb 17 05:09:50 2013
From: report at bugs.python.org (Eric Snow)
Date: Sun, 17 Feb 2013 04:09:50 +0000
Subject: [docs] [issue12633] sys.modules doc entry should reflect
	restrictions
In-Reply-To: <1311569390.98.0.906064511142.issue12633@psf.upfronthosting.co.za>
Message-ID: <1361074190.1.0.135459665141.issue12633@psf.upfronthosting.co.za>


Eric Snow added the comment:

One proposal would lead to the sys module growing descriptors:

http://mail.python.org/pipermail/python-ideas/2013-January/019075.html

In that case, sys.modules could update the underlying interp->modules.

----------

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

From report at bugs.python.org  Sun Feb 17 06:22:33 2013
From: report at bugs.python.org (David Lam)
Date: Sun, 17 Feb 2013 05:22:33 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1361078552.22.0.320453579799.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

Here's a patch which converts all the Doxygen comments in ElementTree.py to docstrings!

Something I noticed was that the 

  from _elementtree import *

...at the bottom of ElementTree.py sort of overwrites the docstrings of the Python module.  So if you did...  `from xml.etree import ElementTree;  help(ElementTree)` from the interpreter, you'll see blank spots for a bunch of classes/methods like Element, ParseError, SubElement etc etc

maybe docstrings should be also added in Modules/_elementtree.c?  perhaps that would be too much copy and pastage, hmmm

----------
keywords: +patch
Added file: http://bugs.python.org/file29095/issue16954.patch

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

From report at bugs.python.org  Sun Feb 17 11:45:49 2013
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 17 Feb 2013 10:45:49 +0000
Subject: [docs] [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1361068958.18.0.974181514073.issue13124@psf.upfronthosting.co.za>
Message-ID: <20130217104549.GA31810@sleipnir.bytereef.org>


Stefan Krah added the comment:

Eric Snow <report at bugs.python.org> wrote:
> Looking this over, it seems like there were outstanding objections to adding this to the devguide and to the content.

I have no issues with the content of the second patch. However, snakebite
has changed the situation a little: We don't need more buildbots, we need
experts in AIX and HP-UX.

For DragonFlyBSD, NetBSD and OpenBSD we'd ideally need someone who reports the
OS bugs (there are a couple) upstream so that the bots finally turn green and
become useful.

So on fact the first paragraph of the patch is now a little outdated.

Given the current situation I think it would be more useful to add

http://mail.python.org/pipermail/python-dev/2012-September/121651.html

to the devguide.

----------

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

From report at bugs.python.org  Sun Feb 17 15:56:39 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 Feb 2013 14:56:39 +0000
Subject: [docs] [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <3Z8B9y4qgBzSfT@mail.python.org>


Roundup Robot added the comment:

New changeset 8c7719b06ba6 by Andrew Svetlov in branch '3.3':
Issue #17215: Fix documentation misprints (patch by July Tikhonov)
http://hg.python.org/cpython/rev/8c7719b06ba6

New changeset 627ebd001708 by Andrew Svetlov in branch 'default':
Issue #17215: Fix documentation misprints (patch by July Tikhonov)
http://hg.python.org/cpython/rev/627ebd001708

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

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

From report at bugs.python.org  Sun Feb 17 15:58:29 2013
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 17 Feb 2013 14:58:29 +0000
Subject: [docs] [issue17215] documentation misprints
In-Reply-To: <1361019558.88.0.148298585178.issue17215@psf.upfronthosting.co.za>
Message-ID: <1361113109.04.0.822619092148.issue17215@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed. July, would you fill Licence agreement http://www.python.org/psf/contrib/?

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

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

From report at bugs.python.org  Sun Feb 17 22:15:43 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 21:15:43 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
Message-ID: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The proposed patch moves some Misc/NEWS entities to more appropriate sections (IDLE, C-API, Tests, Documentation, Tools/Demos). Please review.

----------
assignee: docs at python
components: Documentation
files: NEWS-3.4.patch
keywords: patch
messages: 182282
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Resort Misc/NEWS
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file29107/NEWS-3.4.patch

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

From report at bugs.python.org  Sun Feb 17 23:07:38 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Feb 2013 22:07:38 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361138858.64.0.929200003262.issue17221@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

unittest is a library, not a part of the test suite, so its enhancements should remain in the library section.

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

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

From report at bugs.python.org  Sun Feb 17 23:30:24 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Feb 2013 22:30:24 +0000
Subject: [docs] [issue17047] Fix double double words words
In-Reply-To: <1359274030.35.0.655369465701.issue17047@psf.upfronthosting.co.za>
Message-ID: <1361140224.97.0.134365726055.issue17047@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Feb 18 05:18:29 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 04:18:29 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361161109.86.0.357258510375.issue17221@psf.upfronthosting.co.za>


Ned Deily added the comment:

kbk has requested in the past that IDLE News items be put in Lib/idlelib/News.txt because it is installed with IDLE and there is a button to display it included in the "About IDLE" window.  I know we've not been diligent about doing that, at least, I haven't.  I suppose the items could continue to be put in Misc/NEWS and, prior to each release, copied into the News.txt.  That step could be added to the release manager's checklist.  But, if there are IDLE items in Misc/NEWS, whether duplicated or not, I agree it would be better to have them in their own section.

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

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

From report at bugs.python.org  Mon Feb 18 05:59:11 2013
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 18 Feb 2013 04:59:11 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361163550.99.0.11745719749.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Actually, I have an objection myself.  In merging this patch with another I'm working on, I noticed that I failed to include the new 'idledoc' target in the Makefile usage message.  The attached patch fixes that oversight.

----------
Added file: http://bugs.python.org/file29111/issue16893_makefiles.v2.diff

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

From nad at acm.org  Mon Feb 18 07:55:09 2013
From: nad at acm.org (nad at acm.org)
Date: Mon, 18 Feb 2013 06:55:09 -0000
Subject: [docs] Create IDLE help.txt from Doc/library/idle.rst (issue 16893)
Message-ID: <20130218065509.486.77473@psf.upfronthosting.co.za>

There are a couple of problems with the Makefile changes.  I'm not
convinced that the newly formatted help file is an improvement, though. 
I'll comment further in the issue.


http://bugs.python.org/review/16893/diff/7400/Doc/Makefile
File Doc/Makefile (right):

http://bugs.python.org/review/16893/diff/7400/Doc/Makefile#newcode119
Doc/Makefile:119: idledoc: BULIDER = text
typo: BULIDER -> BUILDER

http://bugs.python.org/review/16893/diff/7400/Doc/Makefile#newcode122
Doc/Makefile:122: @echo "Build finished; now copying
build/text/library/idle.txt to" \
The recipe lines in a Makefile rule have to begin with a TAB character,
not spaces.  Likewise for the following two lines.

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

From report at bugs.python.org  Mon Feb 18 08:04:24 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 07:04:24 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361171064.28.0.872634240334.issue16893@psf.upfronthosting.co.za>


Ned Deily added the comment:

There are a few problems with the proposed patch (v2).  I commented on those in Rietveld.  But, beyond that, I'm not convinced that the generated help.txt is an improvement over the original help.txt.  While it is formatted more consistently (a good thing), it is significantly longer (547 lines vs 369).  Some info is lost in the translation, for one, the menu div bars (---).  Some of the markup looks odd to me as plain text, for example:

    Upon startup with the ``-s`` option, IDLE will execute the file
    referenced by the environment variables ``IDLESTARTUP`` or
    ``PYTHONSTARTUP``. IDLE first checks for ``IDLESTARTUP``; if
    ``IDLESTARTUP`` is present the file referenced is run.  If 
    ``IDLESTARTUP`` is not present, IDLE checks for ``PYTHONSTARTUP``.

Also, I noticed that the deprecation notice, about running without a subprocess, near the end of the help text seems to be missing from the .rst.

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

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

From report at bugs.python.org  Mon Feb 18 08:06:38 2013
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Feb 2013 07:06:38 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361171197.42.0.148509169189.issue16893@psf.upfronthosting.co.za>


Ned Deily added the comment:

For comparison, here's a copy of the new rendered help.txt.

----------
Added file: http://bugs.python.org/file29112/help.txt

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

From report at bugs.python.org  Mon Feb 18 09:14:21 2013
From: report at bugs.python.org (Chris Withers)
Date: Mon, 18 Feb 2013 08:14:21 +0000
Subject: [docs] [issue17179] Misleading error from type() when passing
	unknown	keyword argument
In-Reply-To: <1360991112.28.0.120316277499.issue17179@psf.upfronthosting.co.za>
Message-ID: <5121D8AD.7010506@simplistix.co.uk>


Chris Withers added the comment:

Some background: I hit this problem when adding Python 3 compatibility 
to one of my libraries, where I had the following code:

from types import ClassType
...
class_ = ClassType(n, (sometype, ), dict(class_attr1='foo', 
class_attr2='bar')

It wasn't at all clear how to port this to Python 3, given that 
ClassType was gone.

types.new_class looks fair game, but the help is not exactly helpful:

new_class(name, bases=(), kwds=None, exec_body=None)
     Create a class object dynamically using the appropriate metaclass.

No indication there as to what type should be passed for kwds or exec_body.

I guessed and, by the sound of it, guessed wrong.
I'd certainly agree that the error message is very misleading.

cheers,

Chris

----------

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

From report at bugs.python.org  Mon Feb 18 10:53:40 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 18 Feb 2013 09:53:40 +0000
Subject: [docs] [issue17179] Misleading error from type() when passing
	unknown	keyword argument
In-Reply-To: <1360571201.2.0.86006347662.issue17179@psf.upfronthosting.co.za>
Message-ID: <1361181220.21.0.873212552502.issue17179@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For the simple case where you don't need to provide a metaclass hint, the simplest conversion is actually directly to the 3-argument form of type().

As far as the docstring goes, I don't want to make it as long as the full docs, but it could probably stand to be longer than it is.

----------

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

From report at bugs.python.org  Mon Feb 18 12:16:15 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 11:16:15 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361186171.12.0.249607158968.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Changes for unittest and doctest reverted.

----------
Added file: http://bugs.python.org/file29113/NEWS-3.4_2.patch

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

From report at bugs.python.org  Mon Feb 18 13:14:53 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 18 Feb 2013 12:14:53 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361189693.07.0.204388911426.issue17221@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

I did not realize there was a 'Extension Modules' section.  I have been putting changes to C extensions in the 'Library' section instead.  It looks like most people do the same as me.

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

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

From report at bugs.python.org  Mon Feb 18 13:47:41 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2013 12:47:41 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361189693.07.0.204388911426.issue17221@psf.upfronthosting.co.za>
Message-ID: <689107390.44662973.1361191655667.JavaMail.root@zimbra10-e2.priv.proxad.net>


Antoine Pitrou added the comment:

> I did not realize there was a 'Extension Modules' section.  I have
> been putting changes to C extensions in the 'Library' section
> instead.  It looks like most people do the same as me.

I prefer "Library" as well. I think the "Extension Modules" section
should be yanked.

----------

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

From report at bugs.python.org  Mon Feb 18 14:11:01 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 13:11:01 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361193061.14.0.927077767993.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Was not it be yanked in 1fabff717ef4?

----------

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

From report at bugs.python.org  Mon Feb 18 16:01:00 2013
From: report at bugs.python.org (Richard Oudkerk)
Date: Mon, 18 Feb 2013 15:01:00 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361199660.27.0.0523938648548.issue17221@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> Was not it be yanked in 1fabff717ef4?

Looks like it was reintroduced by this merge changeset:

    http://hg.python.org/cpython/rev/30fc620e240e

----------

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

From report at bugs.python.org  Mon Feb 18 16:04:58 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 15:04:58 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361199898.01.0.0513256946068.issue17221@psf.upfronthosting.co.za>


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


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Mon Feb 18 18:03:58 2013
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Feb 2013 17:03:58 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361207038.57.0.580900112342.issue17221@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

re-yank it.  that was unintentional.  less sections == better.

----------

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

From report at bugs.python.org  Mon Feb 18 18:32:22 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Feb 2013 17:32:22 +0000
Subject: [docs] [issue17221] Resort Misc/NEWS
In-Reply-To: <1361135741.75.0.253129131493.issue17221@psf.upfronthosting.co.za>
Message-ID: <1361208739.6.0.958133959821.issue17221@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an updated patch. Re-yanked "Extension Modules" section. Changes for 3.4 sorted in chronological order.

----------
Added file: http://bugs.python.org/file29116/NEWS-3.4_3.patch

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

From report at bugs.python.org  Tue Feb 19 02:02:56 2013
From: report at bugs.python.org (Todd Rovito)
Date: Tue, 19 Feb 2013 01:02:56 +0000
Subject: [docs] [issue16278] os.rename documentation slightly inaccurate
In-Reply-To: <1350581776.08.0.668682100781.issue16278@psf.upfronthosting.co.za>
Message-ID: <1361235776.18.0.848038206981.issue16278@psf.upfronthosting.co.za>


Todd Rovito added the comment:

Over the weekend I caught this terrible cold and have not been able to work on this issue much.  Hopefully I can complete by next weekend 2/25/2013 thanks for your understanding.

----------

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

From report at bugs.python.org  Tue Feb 19 07:22:52 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:22:52 +0000
Subject: [docs] [issue17231] Mark __del__ not being called in cycles as an
	impl detail
Message-ID: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

Here: http://docs.python.org/2/reference/datamodel.html, as per python-dev discussion

----------
assignee: docs at python
components: Documentation
messages: 182364
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Mark __del__ not being called in cycles as an impl detail
type: behavior

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

From report at bugs.python.org  Tue Feb 19 07:25:01 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 06:25:01 +0000
Subject: [docs] [issue17232] Improve -O docs
Message-ID: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski:

This is what the current documentation says:

-O
Turn on basic optimizations. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.

-OO
Discard docstrings in addition to the -O optimizations.

As far as I know, the only "optimization" that's done is removal of __debug__ sections and assert statements and has been like this for years. Maybe it should say so "-O does not do any optimizations, only removes assert statement" or so.

----------
assignee: docs at python
components: Documentation
messages: 182365
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: Improve -O docs
type: behavior

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

From report at bugs.python.org  Tue Feb 19 09:47:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2013 08:47:45 +0000
Subject: [docs] [issue17231] Mark __del__ not being called in cycles as an
	impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1361263665.4.0.102109600643.issue17231@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Just for the record, the python-dev discussion starts here: http://mail.python.org/pipermail/python-dev/2013-February/124044.html

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

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

From report at bugs.python.org  Tue Feb 19 13:34:30 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Tue, 19 Feb 2013 12:34:30 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361277270.2.0.338875119363.issue17232@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

It should also add that in the future, more optimizations may be added i.e. a peephole optimizer, etc.

----------
nosy: +Ramchandra Apte

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

From report at bugs.python.org  Tue Feb 19 13:40:48 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Tue, 19 Feb 2013 12:40:48 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361277648.6.0.0873018267082.issue17232@psf.upfronthosting.co.za>


Maciej Fijalkowski added the comment:

There were not for at least 10 years. I would also be the first one to strongly object adding optimizations only under -O, because that already changes semantics.

----------

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

From report at bugs.python.org  Tue Feb 19 15:12:03 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 19 Feb 2013 14:12:03 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361283123.37.0.525237678201.issue17232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ramchandra, as it turns out, if we deem an optimization semantically safe, we do it without -O, it we deem it unsafe, we don't do it at all.

Thus, the real effect is to remove assert statements and optimise code as if "__debug__" was replaced by a literal zero (effectively).

So a more meaningful description would be:

-O
Removes assert statements and any code conditional on the value of __debug__. This changes the filename extension for compiled (bytecode) files from .pyc to .pyo. See also PYTHONOPTIMIZE.

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

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

From report at bugs.python.org  Tue Feb 19 15:54:54 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:54:54 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361285694.09.0.348407987159.issue17232@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Feb 19 15:56:16 2013
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Feb 2013 14:56:16 +0000
Subject: [docs] [issue17231] Mark __del__ not being called in cycles as an
	impl detail
In-Reply-To: <1361254972.69.0.594313111975.issue17231@psf.upfronthosting.co.za>
Message-ID: <1361285776.52.0.745956854278.issue17231@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Feb 19 20:06:37 2013
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Tue, 19 Feb 2013 19:06:37 +0000
Subject: [docs] [issue14219] make the Classes tutorial more gentle
In-Reply-To: <1331111619.2.0.272575522063.issue14219@psf.upfronthosting.co.za>
Message-ID: <1361300797.2.0.463467367825.issue14219@psf.upfronthosting.co.za>


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


----------
title: start the Class tutorial in a more gentle manner -> make the Classes tutorial more gentle
versions: +Python 3.4

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

From report at bugs.python.org  Wed Feb 20 06:45:42 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Feb 2013 05:45:42 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1361339142.57.0.936266588276.issue17145@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am looking at this as a naive user, and can only assume that the claims are correct.

+The new C-level buffer API has been backported to Python 2.6 and the
+Python-level :class:`memoryview` object has been backported to Python 2.7.
+To be clear, in Python 2.6 and 2.7, there are two C-level interfaces, both
+exposed by the :ctype:`PyBufferProcs` interface: the new buffer API and the
+old buffer API. The :class:`memoryview` object is the product of the new API
+while :class:`buffer` is the product of the old API (the former of which is
+only available in 2.7+).

This part strikes me as a bit jumbled. Is it necessary to discuss 2.6 in 2.7 docs? the last parenthetical comment repeats what was said in an earlier sentence.

Benjamin, I am adding you because you are listed as an author of the section being revised.

----------
nosy: +benjamin.peterson, terry.reedy
stage:  -> patch review

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

From report at bugs.python.org  Wed Feb 20 07:21:25 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 20 Feb 2013 06:21:25 +0000
Subject: [docs] [issue17145] memoryview(array.array)
In-Reply-To: <1360170754.31.0.614797074916.issue17145@psf.upfronthosting.co.za>
Message-ID: <1361341284.96.0.780415416545.issue17145@psf.upfronthosting.co.za>


Demian Brecht added the comment:

Yes, I agree that passage is a little garbled. I've reworked that particular paragraph in the new patch.

I had included a little information about 2.6 as it was in the revision prior to my patch (and there was also some historical context back to 1.6). I think that 2.6-specific information is irrelevant in this particular doc (after all, it's 2.7-specific and not a change log ;)) and therefore have removed it.

----------
Added file: http://bugs.python.org/file29128/buffer.1.patch

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

From report at bugs.python.org  Wed Feb 20 15:29:51 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:29:51 +0000
Subject: [docs] [issue1398781] Example in section 5.3 "Pure Embedding"
	doesn't work.
Message-ID: <1361370591.16.0.914852906308.issue1398781@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Is this still valid?

----------
nosy: +Ramchandra Apte

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

From report at bugs.python.org  Wed Feb 20 15:45:31 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:45:31 +0000
Subject: [docs] [issue17256] code example should be highlighted
Message-ID: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>


New submission from Ramchandra Apte:

in http://docs.python.org/2/extending/embedding.html#linking-requirements
 the code example isn't highlighted

----------
assignee: docs at python
components: Documentation
messages: 182515
nosy: Ramchandra Apte, docs at python
priority: normal
severity: normal
status: open
title: code example should be highlighted

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

From report at bugs.python.org  Wed Feb 20 15:45:37 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:45:37 +0000
Subject: [docs] [issue17256] code example should be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371537.34.0.293344328704.issue17256@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


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

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

From report at bugs.python.org  Wed Feb 20 15:47:23 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:47:23 +0000
Subject: [docs] [issue17256] code example should be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371643.35.0.633014222455.issue17256@psf.upfronthosting.co.za>


Ramchandra Apte added the comment:

Also in the section above: http://docs.python.org/2/extending/embedding.html#extending-embedded-python , the two code examples should be highlighted.

----------

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

From report at bugs.python.org  Wed Feb 20 15:47:40 2013
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 20 Feb 2013 14:47:40 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361371660.14.0.391010148621.issue17256@psf.upfronthosting.co.za>


Changes by Ramchandra Apte <maniandram01 at gmail.com>:


----------
title: code example should be highlighted -> code example in C API docsshould be highlighted

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

From ezio.melotti at gmail.com  Wed Feb 20 19:55:42 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 20 Feb 2013 18:55:42 -0000
Subject: [docs] Add docstrings for ElementTree module (issue 16954)
Message-ID: <20130220185542.29726.51286@psf.upfronthosting.co.za>


http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py
File Lib/xml/etree/ElementTree.py (right):

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode1
Lib/xml/etree/ElementTree.py:1: """Lightweight XML support for Python
2.3 and later.
The "2.3 and later" part should be removed.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode27
Lib/xml/etree/ElementTree.py:27: And a number of child elements stored
in a Python sequence.
Is this 'children'?

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode157
Lib/xml/etree/ElementTree.py:157: bytestrings or Unicode strings.  'tag'
is the element name.  'attrib' is
I thinks this should be 'ASCII-only byte strings', but I haven't tested
it.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode159
Lib/xml/etree/ElementTree.py:159: contains additional element attributes
given as keyword arguments.
This paragraph could be moved to the constructor docstring, and here the
attributes could be simply listed.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode189
Lib/xml/etree/ElementTree.py:189: def __init__(self, tag, attrib={},
**extra):
This should probably be documented.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode215
Lib/xml/etree/ElementTree.py:215: # (Experimental)
I would keep this in the docstring, or remove it altogether if it's
outdated.

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

From report at bugs.python.org  Wed Feb 20 19:58:57 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 18:58:57 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1361386737.29.0.171964189675.issue16954@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I left a few comments on rietveld.

In the rst docs the markup used for arguments is *arg*, and this is sometimes reflected in docstrings too.  We might want to do this here too, instead of using 'arg' (using 'attr' for attributes it's fine though).

> maybe docstrings should be also added in Modules/_elementtree.c?

Maybe we could have a loop that does something like cfunc.__doc__ = pyfunc.__doc__?

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

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

From report at bugs.python.org  Wed Feb 20 20:04:22 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 19:04:22 +0000
Subject: [docs] [issue13124] Add "Running a Build Slave" page to the devguide
In-Reply-To: <1318011517.56.0.343886781977.issue13124@psf.upfronthosting.co.za>
Message-ID: <1361387062.69.0.0966428397922.issue13124@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Before I take any time to update the patch, does anyone object
> to the location or intent of the changes?

Adding a new page to the devguide seems OK to me.  It makes the devguide bigger, but it can easily be ignored by developers/contributors if they are not interested.

----------

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

From report at bugs.python.org  Wed Feb 20 20:29:08 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 20 Feb 2013 19:29:08 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361388548.2.0.62602421872.issue17256@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Looks like it's because highlightlang:: c is at the top.

----------
nosy: +chris.jerdonek

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

From report at bugs.python.org  Wed Feb 20 20:29:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Feb 2013 19:29:54 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361388594.06.0.086864670017.issue17256@psf.upfronthosting.co.za>


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


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

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

From zachary.ware at gmail.com  Wed Feb 20 20:38:25 2013
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Wed, 20 Feb 2013 19:38:25 -0000
Subject: [docs] Create IDLE help.txt from Doc/library/idle.rst (issue
	16893)
Message-ID: <20130220193825.29726.5157@psf.upfronthosting.co.za>

Reviewers: ned.deily,


http://bugs.python.org/review/16893/diff/7400/Doc/Makefile
File Doc/Makefile (right):

http://bugs.python.org/review/16893/diff/7400/Doc/Makefile#newcode119
Doc/Makefile:119: idledoc: BULIDER = text
On 2013/02/18 07:55:09, ned.deily wrote:
> typo: BULIDER -> BUILDER
That's what I get for poor copying and not testing it myself.  Fixed.

http://bugs.python.org/review/16893/diff/7400/Doc/Makefile#newcode122
Doc/Makefile:122: @echo "Build finished; now copying
build/text/library/idle.txt to" \
On 2013/02/18 07:55:09, ned.deily wrote:
> The recipe lines in a Makefile rule have to begin with a TAB
character, not
> spaces.  Likewise for the following two lines.
That would be the fault of my editor expanding tabs into spaces
sometimes at will, but I didn't know this anyway; thank you.  Fixed.



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

Affected files:
  Doc/Makefile
  Doc/make.bat


diff -r 627ebd001708 Doc/Makefile
--- a/Doc/Makefile	Sun Feb 17 16:56:28 2013 +0200
+++ b/Doc/Makefile	Sun Feb 17 22:57:26 2013 -0600
@@ -31,6 +31,7 @@
 	@echo "  linkcheck  to check all external links for integrity"
 	@echo "  coverage   to check documentation coverage for library and C API"
 	@echo "  doctest    to run doctests in the documentation"
+	@echo "  idledoc    to regenerate the IDLE help file"
 	@echo "  pydoc-topics  to regenerate the pydoc topics file"
 	@echo "  dist       to create a \"dist\" directory with archived docs for download"
 	@echo "  suspicious to check for suspicious markup in output text"
@@ -115,6 +116,13 @@
 	@echo "Building finished; now copy build/pydoc-topics/topics.py" \
 	      "to ../Lib/pydoc_data/topics.py"
 
+idledoc: BULIDER = text
+idledoc: SOURCES = library/idle.rst
+idledoc: build
+    @echo "Build finished; now copying build/text/library/idle.txt to" \
+          "../Lib/idlelib/help.txt."
+    @cp build/text/library/idle.txt ../Lib/idlelib/help.txt
+
 htmlview: html
 	 $(PYTHON) -c "import webbrowser; webbrowser.open('build/html/index.html')"
 
diff -r 627ebd001708 Doc/make.bat
--- a/Doc/make.bat	Sun Feb 17 16:56:28 2013 +0200
+++ b/Doc/make.bat	Sun Feb 17 22:57:26 2013 -0600
@@ -14,6 +14,7 @@
 if "%1" EQU "suspicious" goto build
 if "%1" EQU "linkcheck" goto build
 if "%1" EQU "changes" goto build
+if "%1" EQU "idledoc" goto idledoc
 if "%1" EQU "checkout" goto checkout
 if "%1" EQU "update" goto update
 
@@ -30,6 +31,7 @@
 echo %this% suspicious
 echo %this% linkcheck
 echo %this% changes
+echo %this% idledoc
 echo.
 goto end
 
@@ -47,6 +49,12 @@
 svn update tools/pygments
 goto end
 
+:idledoc
+call make.bat text library\idle.rst
+echo Now copying build/text/library/idle.txt to ../Lib/idlelib/help.txt
+copy build\text\library\idle.txt ..\Lib\idlelib\help.txt
+goto end
+
 :build
 if not exist build mkdir build
 if not exist build\%1 mkdir build\%1



From report at bugs.python.org  Wed Feb 20 20:50:54 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 19:50:54 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361389853.37.0.750180450086.issue16893@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's a new version of the patch, with the fixes that Ned pointed out.

I also tried to address concerns about lost information; menu divisions have been added to Doc/library/idle.rst, along with the blurb about running without a subprocess being deprecated.  Also, every instance of :kbd:`C-x` has been expanded to :kbd:`Control-x`, as that's how help.txt has commands written.  A rather unrelated change that I snuck in while I was editing idle.rst was to move the index markers for Class browser and Path browser to be above those entries rather than below.

The generated help.txt is significantly longer than the old version but I don't think that's all bad.  Most of the extra lines are new whitespace or things that had been a single line being broken up into two.  I personally thought the old help.txt was rather too dense in some places, though I might agree that the generated version is a bit sparse in others.

The paragraph about environment variables does have a rather unfortunate number of backticks, but I don't think it's unreadable.  It's also information that wasn't present in the original help.txt.

Thank you for the review, Ned :)

----------
Added file: http://bugs.python.org/file29133/issue16893.v3.diff

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

From report at bugs.python.org  Wed Feb 20 20:51:08 2013
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Feb 2013 19:51:08 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1361389868.81.0.536831725497.issue16893@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file28725/issue16893.diff

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

From report at bugs.python.org  Wed Feb 20 22:58:01 2013
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Feb 2013 21:58:01 +0000
Subject: [docs] [issue17259] locale.format() rounding is not reliable for
	floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361397481.71.0.837721306994.issue17259@psf.upfronthosting.co.za>


R. David Murray added the comment:

Perhaps Serhiy meant to direct your attention to the "note" in the round docs.  Floating point is tricky.

In Python3 the round is actually "half to even".  I'm not sure what the rounding algorithm is for %f, but I have a suspicion it might be half to even.  I suppose that it ought to be documented.

Note that this applies equally to regular string formatting, it's not something special about the locale module.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, eric.smith, mark.dickinson, r.david.murray
versions: +Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Feb 20 23:40:22 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 20 Feb 2013 22:40:22 +0000
Subject: [docs] [issue17259] locale.format() rounding is not reliable for
	floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361400022.46.0.143542687761.issue17259@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Mark is the ultimate authority here, but my recollection is (and a quick scan of the code shows) that half to even rounding is used in all of our float to string conversions. So that includes %f and float.__format__, among others.

----------

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

From merwok at netwok.org  Wed Feb 20 23:47:06 2013
From: merwok at netwok.org (merwok at netwok.org)
Date: Wed, 20 Feb 2013 22:47:06 -0000
Subject: [docs] Add docstrings for ElementTree module (issue 16954)
Message-ID: <20130220224706.29829.39098@psf.upfronthosting.co.za>


http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py
File Lib/xml/etree/ElementTree.py (right):

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode1
Lib/xml/etree/ElementTree.py:1: """Lightweight XML support for Python
2.3 and later.
Also ?lightweight? is disputed, there was a python-dev thread and a bug
report that lead to the rst docs being edited.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode27
Lib/xml/etree/ElementTree.py:27: And a number of child elements stored
in a Python sequence.
When a noun is used as adjective, it?s used in the singular.  ?child
elements? is correct.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode170
Lib/xml/etree/ElementTree.py:170: """Dictionary of the tag's
attributes."""
s/tag/element/

A tag is the concrete bytes used to mark the beginning and end of an
element.  The thing/concept/object itself, with parent, children and
attributes, is an element.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode189
Lib/xml/etree/ElementTree.py:189: def __init__(self, tag, attrib={},
**extra):
Note that __init__ methods are typically documented in the class
docstring.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode237
Lib/xml/etree/ElementTree.py:237: """
Magic methods don?t usually have docstrings, because they implement
generic methods or protocols that people know how to use.  If you know
that something is iterable, you don?t look at help(something.__iter__),
you know how to use iter or a for loop.  So to document specific meaning
of an __iter__ or __len__ method, I would put information in the class
docstring.  Does that make sense?

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode254
Lib/xml/etree/ElementTree.py:254: """
This docstring is valid for all sequence __getitem__ methods :)  I would
just remove it.

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode295
Lib/xml/etree/ElementTree.py:295: 'elements' is a sequence object with
zero or more elements.
s/sequence object/sequence/

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

From report at bugs.python.org  Thu Feb 21 03:07:00 2013
From: report at bugs.python.org (Kim)
Date: Thu, 21 Feb 2013 02:07:00 +0000
Subject: [docs] [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1361412419.94.0.368515263307.issue17155@psf.upfronthosting.co.za>


Kim added the comment:

I'm running into similar issues with 2.6.7 and logging 0.4.9.6, where unicode strings are fine in print statements and codecs writes, but the same string is giving tracebacks for logging.  If it's an education issue, I'm not finding the education I need ... :-/

import logging
import codecs

# Unicode string
i = u'\u0433\u043e\u0432\u043e\u0440\u0438\u0442\u044a'

# Print statement is fine
print "hi, i'm the string in question in a print statement: %s" % i

# Codecs write is fine
with codecs.open('/tmp/utf8', 'w', 'utf-8') as f:
    f.write(i)

# Logging gives a Traceback
log = logging.getLogger(__name__)
log.setLevel(logging.DEBUG)
handler = logging.FileHandler('/tmp/out', 'w', 'utf-8')
handler.setFormatter(logging.Formatter(u'[%(levelname)s] %(message)s'))
# I've also tried nixing setFormatter and going with the default
log.addHandler(handler)
log.debug(u"process_clusters: From CSV: %s", i)
# I've also tried a bare call to i, with and without the u in the message, and explicitly i.encode('utf8'); all Tracebacks.

----------
nosy: +kiminoa

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

From report at bugs.python.org  Thu Feb 21 04:52:43 2013
From: report at bugs.python.org (Kim)
Date: Thu, 21 Feb 2013 03:52:43 +0000
Subject: [docs] [issue17155] logging can raise UnicodeEncodeError
In-Reply-To: <1360261105.58.0.464994704341.issue17155@psf.upfronthosting.co.za>
Message-ID: <1361418763.18.0.851710858488.issue17155@psf.upfronthosting.co.za>


Kim added the comment:

p.s. Converting to a StreamHandler fixes my issue for now.

----------

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

From report at bugs.python.org  Thu Feb 21 06:31:37 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 05:31:37 +0000
Subject: [docs] [issue17264] Update Building C and C++ Extensions with
	distutils	documentation
Message-ID: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I have removed all mentions about Python 1.4 and 2.0 from the
Doc/extending/building.rst. The Demo/embed/demo.c file has been removed
in 3.x, so I used "_spammodule.c" convention in the examples. The patch
also fixes all the PEP 8 violations in the setup.py examples.

----------
assignee: docs at python
components: Documentation
files: extending_building.diff
keywords: patch
messages: 182580
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Update Building C and C++ Extensions with distutils documentation
versions: Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29139/extending_building.diff

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

From report at bugs.python.org  Thu Feb 21 11:22:53 2013
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 21 Feb 2013 10:22:53 +0000
Subject: [docs] [issue17265] Fix code highlight in the string.Template
	example
Message-ID: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>


New submission from Berker Peksag:

See for the current version:

http://docs.python.org/3.4/library/string.html#string.Template.template

----------
assignee: docs at python
components: Documentation
files: string_template_highlight.diff
keywords: patch
messages: 182584
nosy: berker.peksag, docs at python
priority: normal
severity: normal
status: open
title: Fix code highlight in the string.Template example
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29141/string_template_highlight.diff

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

From ezio.melotti at gmail.com  Thu Feb 21 11:23:27 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Thu, 21 Feb 2013 10:23:27 -0000
Subject: [docs] Add docstrings for ElementTree module (issue 16954)
Message-ID: <20130221102327.17737.58604@psf.upfronthosting.co.za>


http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py
File Lib/xml/etree/ElementTree.py (right):

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode1
Lib/xml/etree/ElementTree.py:1: """Lightweight XML support for Python
2.3 and later.
On 2013/02/20 23:47:06, eric.araujo wrote:
> Also ?lightweight? is disputed, there was a python-dev thread and a
bug report
> that lead to the rst docs being edited.

Wasn't that minidom?

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode27
Lib/xml/etree/ElementTree.py:27: And a number of child elements stored
in a Python sequence.
On 2013/02/20 23:47:06, eric.araujo wrote:
> When a noun is used as adjective, it?s used in the singular.  ?child
elements?
> is correct.

I was referring to the name of the attribute. (I'm not sure there's an
attribute with that name, but if there is we should be consistent.)

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode170
Lib/xml/etree/ElementTree.py:170: """Dictionary of the tag's
attributes."""
On 2013/02/20 23:47:06, eric.araujo wrote:
> s/tag/element/
> 
> A tag is the concrete bytes used to mark the beginning and end of an
element. 
> The thing/concept/object itself, with parent, children and attributes,
is an
> element.

While this is true and I agree it should be fixed, the  term 'tag' seems
to be misused elsewhere too.  For example the tag attribute/argument
refers to the name of the element.

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

From report at bugs.python.org  Thu Feb 21 11:36:10 2013
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 21 Feb 2013 10:36:10 +0000
Subject: [docs] [issue17265] Fix code highlight in the string.Template
	example
In-Reply-To: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>
Message-ID: <3ZBXCY5XnvzNtY@mail.python.org>


Roundup Robot added the comment:

New changeset 943ea41d3ceb by Ezio Melotti in branch '2.7':
#17265: fix highlight in template example.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/943ea41d3ceb

New changeset 1b9de5788698 by Ezio Melotti in branch '3.2':
#17265: fix highlight in template example.  Initial patch by Berker Peksag.
http://hg.python.org/cpython/rev/1b9de5788698

New changeset 0e2d89f34ae5 by Ezio Melotti in branch '3.3':
#17265: merge with 3.2.
http://hg.python.org/cpython/rev/0e2d89f34ae5

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

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

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

From report at bugs.python.org  Thu Feb 21 11:36:54 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 21 Feb 2013 10:36:54 +0000
Subject: [docs] [issue17265] Fix code highlight in the string.Template
	example
In-Reply-To: <1361442173.54.0.636977932686.issue17265@psf.upfronthosting.co.za>
Message-ID: <1361443014.6.0.455200014399.issue17265@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/issue17265>
_______________________________________

From merwok at netwok.org  Thu Feb 21 17:09:08 2013
From: merwok at netwok.org (merwok at netwok.org)
Date: Thu, 21 Feb 2013 16:09:08 -0000
Subject: [docs] Add docstrings for ElementTree module (issue 16954)
Message-ID: <20130221160908.19417.47996@psf.upfronthosting.co.za>


http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py
File Lib/xml/etree/ElementTree.py (right):

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode1
Lib/xml/etree/ElementTree.py:1: """Lightweight XML support for Python
2.3 and later.
Duh yes it was minidom.  The fact that I don?t like the etree interface
made me lump it into the same mental category with minidom :)

http://bugs.python.org/review/16954/diff/7390/Lib/xml/etree/ElementTree.py#newcode27
Lib/xml/etree/ElementTree.py:27: And a number of child elements stored
in a Python sequence.
Well if there is an attribute named ?children? it should be documented
like the other ones (and its English description would still be ?child
elements?).

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

From report at bugs.python.org  Thu Feb 21 17:16:06 2013
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Feb 2013 16:16:06 +0000
Subject: [docs] [issue17264] Update Building C and C++ Extensions with
	distutils	documentation
In-Reply-To: <1361424697.21.0.435186366661.issue17264@psf.upfronthosting.co.za>
Message-ID: <1361463366.01.0.833111108318.issue17264@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks, will tweak and apply.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 2.7

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

From report at bugs.python.org  Thu Feb 21 17:40:30 2013
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Feb 2013 16:40:30 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361464830.28.0.711887161749.issue17268@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The change should also be documented here, http://docs.python.org/2.7/whatsnew/2.7.html#porting-to-python-2-7

----------
assignee:  -> docs at python
components: +Documentation
nosy: +christian.heimes, docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Thu Feb 21 18:37:19 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:37:19 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464598.2.0.488657628625.issue17268@psf.upfronthosting.co.za>
Message-ID: <51265B4C.2040502@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
> 
> After some experiments, it turned out that by simply filling in the tp_methods slot, the problem went away.

Sorry: *tp_methods*, not tp_members.

----------

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

From report at bugs.python.org  Thu Feb 21 18:48:22 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:48:22 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361468902.5.0.878647766194.issue17268@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


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

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

From report at bugs.python.org  Thu Feb 21 18:49:04 2013
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Feb 2013 17:49:04 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464598.2.0.488657628625.issue17268@psf.upfronthosting.co.za>
Message-ID: <51265E0D.1050005@egenix.com>


Marc-Andre Lemburg added the comment:

On 21.02.2013 17:36, Marc-Andre Lemburg wrote:
> After some experiments, it turned out that by simply filling in the tp_methods slot, the problem went away.
> 
> Still, the change to use _PyObject_LookupSpecial() appears to have missed the (older) use case where you don't define tp_members, but instead implement method lookup as part of the tp_getattr slot.

Sorry: *tp_methods*, not tp_members.

----------

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

From report at bugs.python.org  Thu Feb 21 21:11:53 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Feb 2013 20:11:53 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361477513.42.0.118911444363.issue17268@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Feb 21 21:44:06 2013
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2013 20:44:06 +0000
Subject: [docs] [issue17268] Context managers written as C types no longer
	work in	Python 2.7
In-Reply-To: <1361464311.73.0.77004817262.issue17268@psf.upfronthosting.co.za>
Message-ID: <1361479446.25.0.442848178817.issue17268@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is a property of all special methods not just __enter__ and __exit__.

----------

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

From report at bugs.python.org  Fri Feb 22 03:20:37 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 02:20:37 +0000
Subject: [docs] [issue17109] unittest.mock has wrong heading levels
In-Reply-To: <1359847916.06.0.948059142978.issue17109@psf.upfronthosting.co.za>
Message-ID: <1361499637.75.0.754883308332.issue17109@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> It can just be changed to being a suggestion as opposed to "the convention that we use."

I created issue 17270 for this.

----------

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

From report at bugs.python.org  Fri Feb 22 04:04:53 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 03:04:53 +0000
Subject: [docs] [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <3ZBy8N49zCzSrl@mail.python.org>


Roundup Robot added the comment:

New changeset f4ccc5aab287 by Chris Jerdonek in branch '2.7':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/f4ccc5aab287

New changeset c0581f7be196 by Chris Jerdonek in branch '3.2':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/c0581f7be196

New changeset 7d1122c79985 by Chris Jerdonek in branch '3.3':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/7d1122c79985

New changeset bbe5efa9c667 by Chris Jerdonek in branch 'default':
Issue #17203: add long option names to unittest discovery docs.
http://hg.python.org/cpython/rev/bbe5efa9c667

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

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

From report at bugs.python.org  Fri Feb 22 04:05:48 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 22 Feb 2013 03:05:48 +0000
Subject: [docs] [issue17203] add long option names to unittest discovery docs
In-Reply-To: <1360824428.74.0.80014311732.issue17203@psf.upfronthosting.co.za>
Message-ID: <1361502347.99.0.961744099852.issue17203@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Fri Feb 22 06:28:27 2013
From: report at bugs.python.org (Kushal Das)
Date: Fri, 22 Feb 2013 05:28:27 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361510907.21.0.105229629206.issue17256@psf.upfronthosting.co.za>


Kushal Das added the comment:

Following patch solves the problem.

----------
keywords: +patch
nosy: +kushaldas
Added file: http://bugs.python.org/file29154/issue17256.patch

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

From report at bugs.python.org  Fri Feb 22 06:53:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 05:53:38 +0000
Subject: [docs] [issue17035] Use new style classes in {class,
	static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <3ZC1v5213lzSqZ@mail.python.org>


Roundup Robot added the comment:

New changeset 30e7bc28d4f5 by Ezio Melotti in branch '2.7':
#17035: use new style classes in classmethod/staticmethod examples.  Patch by Berker Peksag.
http://hg.python.org/cpython/rev/30e7bc28d4f5

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

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

From report at bugs.python.org  Fri Feb 22 06:53:38 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 05:53:38 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <3ZC1v60mMRzSqZ@mail.python.org>


Roundup Robot added the comment:

New changeset ad55dc7de7fc by Ezio Melotti in branch '2.7':
#17256: fix syntax highlight in embedding example.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/ad55dc7de7fc

New changeset b42e7aeb4235 by Ezio Melotti in branch '3.2':
#17256: fix syntax highlight in embedding example.  Patch by Kushal Das.
http://hg.python.org/cpython/rev/b42e7aeb4235

New changeset 3405d828ce95 by Ezio Melotti in branch '3.3':
#17256: merge with 3.2.
http://hg.python.org/cpython/rev/3405d828ce95

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

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

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

From report at bugs.python.org  Fri Feb 22 06:54:27 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 05:54:27 +0000
Subject: [docs] [issue17035] Use new style classes in {class,
	static}method examples
In-Reply-To: <1359148393.48.0.512379058161.issue17035@psf.upfronthosting.co.za>
Message-ID: <1361512467.39.0.176763798114.issue17035@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: patch review -> committed/rejected
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Fri Feb 22 06:55:04 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 05:55:04 +0000
Subject: [docs] [issue17256] code example in C API docsshould be highlighted
In-Reply-To: <1361371531.01.0.624260307676.issue17256@psf.upfronthosting.co.za>
Message-ID: <1361512504.26.0.425871105102.issue17256@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Fri Feb 22 06:55:23 2013
From: report at bugs.python.org (Jason S Friedman)
Date: Fri, 22 Feb 2013 05:55:23 +0000
Subject: [docs] [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
Message-ID: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>


New submission from Jason S Friedman:

Page is http://docs.python.org/3/library/tempfile.html#module-tempfile.

The code in question currently reads:
>>> f = NamedTemporaryFile(delete=False)
>>> f
<open file '<fdopen>', mode 'w+b' at 0x384698>
>>> f.name
'/var/folders/5q/5qTPn6xq2RaWqk+1Ytw3-U+++TI/-Tmp-/tmpG7V1Y0'
>>> f.write("Hello World!\n")
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

It should read:
>>> import os
>>> from tempfile import NamedTemporaryFile
>>> f = NamedTemporaryFile(delete=False)
>>> f
<tempfile._TemporaryFileWrapper object at 0x29bfc50>
>>> f.name
'/tmp/tmpdxd_85'
>>> f.write("Hello World!\n".encode())
13
>>> f.close()
>>> os.unlink(f.name)
>>> os.path.exists(f.name)
False

----------
assignee: docs at python
components: Documentation
messages: 182640
nosy: docs at python, jsf80238 at gmail.com
priority: normal
severity: normal
status: open
title: NamedTemporaryFile expects bytes, not string in documentation for tempfile module
versions: Python 3.2

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

From report at bugs.python.org  Fri Feb 22 07:29:46 2013
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 Feb 2013 06:29:46 +0000
Subject: [docs] [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
In-Reply-To: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>
Message-ID: <3ZC2hn6qBCzQRJ@mail.python.org>


Roundup Robot added the comment:

New changeset 82343bbf8868 by Ezio Melotti in branch '3.2':
#17271: update example in tempfile docs.
http://hg.python.org/cpython/rev/82343bbf8868

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

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

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

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

From report at bugs.python.org  Fri Feb 22 07:30:18 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 22 Feb 2013 06:30:18 +0000
Subject: [docs] [issue17271] NamedTemporaryFile expects bytes,
	not string in documentation for tempfile module
In-Reply-To: <1361512523.63.0.313343662334.issue17271@psf.upfronthosting.co.za>
Message-ID: <1361514618.79.0.689026109919.issue17271@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.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 22 19:43:37 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:43:37 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558617.16.0.0408448035956.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that we should document exactly what is now. Patch replaces first sentence with Nick's. It is against 3.4, but should be identical for all versions. Maciej, thanks for reminding us to finally fix this.

----------
keywords: +patch
nosy: +terry.reedy
versions: +Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file29165/issue17232.diff

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

From report at bugs.python.org  Fri Feb 22 19:45:12 2013
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Feb 2013 18:45:12 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558711.93.0.445219488516.issue17232@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Should probably be "Remove", not "Removes" (we use infinitives to describe the actions undertaken by a command / option / method ...).

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

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

From report at bugs.python.org  Fri Feb 22 19:46:12 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 18:46:12 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361558772.14.0.387267642871.issue17232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Perhaps '__debug__' need markup, but if so, I don't know how.
And I agree with Antoine.

----------

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

From report at bugs.python.org  Fri Feb 22 20:34:48 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 19:34:48 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361561688.7.0.115266304344.issue17259@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'%.0f' % 5.5, etc, does the same. I agree that consistent 3.x half to even is both correct and and in need of better doc to avoid repeated questions and invalid bug reports.

----------
nosy: +terry.reedy
title: locale.format() rounding is not reliable for floats -> Document round half to even rule for floats
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Feb 22 20:54:57 2013
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Feb 2013 19:54:57 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361562897.48.0.498983348737.issue17259@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Feb 22 21:02:42 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2013 20:02:42 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361563362.94.0.330362417682.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Indeed, in Python 3, round and new-style string formatting both do round-ties-to-even, by design.  Old-style formatting does whatever the underlying OS does, which is typically round-half-away-from-zero.

Python 2 is a bit more of a mess:  in 2.7, new-style formatting does round-ties-to-even, round does round-half-away-from-zero, and old-style formatting continues to do whatever the OS does, just as in Python 3.  And 2.6 is different again (and much more system dependent).

Agreed that this could be better documented for 'format'.  The documentation for the round function is already explicit on this, at least for Python 3.

----------

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

From report at bugs.python.org  Fri Feb 22 21:34:45 2013
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2013 20:34:45 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361565285.83.0.586145904365.issue17259@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Bah.  Ignore me;  I don't know what I'm talking about.  Old-style formatting does round-half-to-even, too.

----------

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

From report at bugs.python.org  Fri Feb 22 23:09:24 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Feb 2013 22:09:24 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
Message-ID: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

More than once, people have noted on python-list that not all built-in classes can be subclassed and that there seems to be no way to find out which, other than to try each. (Today, Daniel Urban pointed out the CPython-specific 'xx.__flags__ & (1 << 10)'.) If the specifics are a Python feature, rather than CPython specific, I think they should be given in the doc.

There is a recent issue, which I cannot find, about re-organizing the Library built-in functions chapter by groups. If this is done, it would be easy to add, in the introduction to built-in classes, a list of which of the named classes can or cannot be subclassed (whichever list is shorter) and note that those not in builtins cannot be.)

----------
assignee: docs at python
components: Documentation
messages: 182703
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Document which named built-in classes can be subclassed
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Feb 22 23:52:35 2013
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 22 Feb 2013 22:52:35 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361573555.85.0.279218452056.issue17279@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/issue17279>
_______________________________________

From report at bugs.python.org  Sat Feb 23 02:39:46 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 01:39:46 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361583586.25.0.377677290242.issue17259@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When I wrote my previous message, I was reading the link above and did not notice that it want to the old 2.7 docs. The 3.x entry is fine.

Perhaps 6.1.3.1. Format Specification Mini-Language could end with
  Rounding of floats is the same as for round().
under the box, with 'round()' linked to its entry.

>From what you said, % does half to even on my system only because that is what MC VC10 does. 4.7.2. printf-style String Formatting could add "Rounding is system dependent" as note 6 (currently missing!).

I removed 2.7 because is seems like a mess and mostly does not use the new rule. But from what you say, only round() itself is different. 'Half-away-from-0' could be added, with a note about changing in py 3.
The note for .format would have to give the rule rather than refer to round(). Did I get it all right?

----------

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

From report at bugs.python.org  Sat Feb 23 02:43:34 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Feb 2013 01:43:34 +0000
Subject: [docs] [issue17273] multiprocessing.pool.Pool task/worker handlers
	are not	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361583814.12.0.571530278531.issue17273@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Arun, can you suggest a sentence to add and where to add it?

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From ezio.melotti at gmail.com  Sat Feb 23 07:51:55 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 23 Feb 2013 06:51:55 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20130223065155.23496.86686@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 ``<``, ``>``,
These should be :meth:`~object.__eq__` (or whatever creates a link to
the __eq__ documention).  The () shouldn't be included.

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

From report at bugs.python.org  Sat Feb 23 09:58:51 2013
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 23 Feb 2013 08:58:51 +0000
Subject: [docs] [issue17259] Document round half to even rule for floats
In-Reply-To: <1361395314.25.0.489128727343.issue17259@psf.upfronthosting.co.za>
Message-ID: <1361609931.09.0.348357108806.issue17259@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I've just looked through the code for 2.7. It uses short float repr for both %-formatting and for float.__format__. So they both use Gay's code, and both should work the same as they do in 3.2+. In all cases, round-half-to-even is used.

It's 2.6 that uses the C library to do float formatting (for both %-formatting and float.__format__).

----------

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

From report at bugs.python.org  Sat Feb 23 11:11:47 2013
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2013 10:11:47 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361614307.91.0.802196814407.issue17232@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for Remove instead of Removes

For the online docs, :const:`__debug__` should work (resolving to http://docs.python.org/3/library/constants.html#__debug__, which is currently described using some slightly brain-bending phrasing)

We should also tweak the output of "python -h" (the help string is in ./Modules/main.c)

----------

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

From report at bugs.python.org  Sat Feb 23 14:20:00 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 23 Feb 2013 13:20:00 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361625600.43.0.749393200519.issue17232@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

+1, I've been bothered by this description of "optimization" for a long time. 

Terry's patch LGTM

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

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

From report at bugs.python.org  Sat Feb 23 14:34:48 2013
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 23 Feb 2013 13:34:48 +0000
Subject: [docs] [issue17232] Improve -O docs
In-Reply-To: <1361255101.21.0.948205073894.issue17232@psf.upfronthosting.co.za>
Message-ID: <1361626488.18.0.0987623061956.issue17232@psf.upfronthosting.co.za>


Maciej Fijalkowski added the comment:

Also IMO -OO should stop talking about optimizations. Maybe "Do what -O does and discard docstrings"?

----------

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

From report at bugs.python.org  Sat Feb 23 16:06:48 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 15:06:48 +0000
Subject: [docs] [issue16695] Clarify fnmatch & glob docs about the handling
	of	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361632008.92.0.462129913634.issue16695@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

I modified the docstring for the glob and iglob to note that the match does not work exactly like fnmatch.

Should this be extended to the documentation too?

----------
keywords: +patch
nosy: +nailor
Added file: http://bugs.python.org/file29172/issue16695.patch

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

From report at bugs.python.org  Sat Feb 23 16:50:45 2013
From: report at bugs.python.org (Jyrki Pulliainen)
Date: Sat, 23 Feb 2013 15:50:45 +0000
Subject: [docs] [issue16695] Clarify fnmatch & glob docs about the handling
	of	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361634645.54.0.604313165634.issue16695@psf.upfronthosting.co.za>


Jyrki Pulliainen added the comment:

Added documentation changes to the glob documentation too, not only docstring.

----------
Added file: http://bugs.python.org/file29176/issue16695_2.patch

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

From report at bugs.python.org  Sat Feb 23 18:06:41 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:06:41 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361639201.34.0.169799205369.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Patch for 2.7, with most references to /tmp removed or replaced.

References remain in Doc/install/index.rst and Doc/library/rexec.rst as they seem to make sense in context.

----------
nosy: +gmwils
Added file: http://bugs.python.org/file29183/Issue8890.patch

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

From report at bugs.python.org  Sat Feb 23 18:07:12 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 17: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: <1361639232.95.0.406477231458.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Attached patch file for the 2.7 branch. They not only touch find(), but also findtext(), which has the mistake in the documentation. Also does some related changes in the module's code comments.

----------
keywords: +patch
nosy: +hheimbuerger
Added file: http://bugs.python.org/file29184/issue11367_branch27.diff

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

From report at bugs.python.org  Sat Feb 23 18:07:55 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 17:07:55 +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: <1361639275.83.0.585654057356.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Almost identical patch for 3.2, just differs in line numbers.

----------
Added file: http://bugs.python.org/file29185/issue11367_branch32.diff

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

From report at bugs.python.org  Sat Feb 23 18:45:31 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:45:31 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361641531.51.0.308528664679.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Attaching patch for 3.2 (Issue8890-3.2.patch)

----------
Added file: http://bugs.python.org/file29190/Issue8890-3.2.patch

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

From report at bugs.python.org  Sat Feb 23 18:46:11 2013
From: report at bugs.python.org (Geoff Wilson)
Date: Sat, 23 Feb 2013 17:46:11 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361641571.15.0.180807521678.issue8890@psf.upfronthosting.co.za>


Geoff Wilson added the comment:

Attaching patch for 3.3 that also works for 3.4/default (Issue8890-3.3.patch)

----------
Added file: http://bugs.python.org/file29191/Issue8890-3.3.patch

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

From report at bugs.python.org  Sat Feb 23 19:38:00 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Sat, 23 Feb 2013 18:38:00 +0000
Subject: [docs] [issue16802] fileno argument to socket.socket() undocumented
In-Reply-To: <1356711151.76.0.423836721045.issue16802@psf.upfronthosting.co.za>
Message-ID: <1361644680.15.0.107505878967.issue16802@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Here's a suggestion for a documentation addition. Comments on tone and content are welcome, and I'm willing to update it and submit modified patch files.

This adds the following note:
      If a file descriptor *fileno* is specified, the other arguments
      are ignored and and the socket with this file descriptor is returned. Unlike
      :meth:`fromfd`, this does not cause a duplication of the file descriptor
      and therefore supports the special case of closing detached socket handles
      on Windows using ``socket.socket(fileno=handle).close()``.

----------
keywords: +patch
nosy: +hheimbuerger
Added file: http://bugs.python.org/file29195/issue16802.diff

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

From report at bugs.python.org  Sat Feb 23 19:39:04 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 18:39:04 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <3ZCyqq3dgPzPkT@mail.python.org>


Roundup Robot added the comment:

New changeset 488957f9b664 by Petri Lehtinen in branch '2.7':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/488957f9b664

New changeset 7556601180c8 by Petri Lehtinen in branch '3.2':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/7556601180c8

New changeset 18e20e146396 by Petri Lehtinen in branch '3.3':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/18e20e146396

New changeset 6b0ca4cb7e4e by Petri Lehtinen in branch 'default':
Issue #8890: Stop advertising an insecure use of /tmp in docs
http://hg.python.org/cpython/rev/6b0ca4cb7e4e

----------

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

From report at bugs.python.org  Sat Feb 23 19:40:07 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 18:40:07 +0000
Subject: [docs] [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1361644807.78.0.660928083912.issue8890@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 3.4

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

From report at bugs.python.org  Sat Feb 23 19:53:41 2013
From: report at bugs.python.org (Andy Holst)
Date: Sat, 23 Feb 2013 18:53:41 +0000
Subject: [docs] [issue15566] tarfile.TarInfo.frombuf documentation is out of
	date
In-Reply-To: <1344248661.48.0.873103438616.issue15566@psf.upfronthosting.co.za>
Message-ID: <1361645621.33.0.188191043887.issue15566@psf.upfronthosting.co.za>


Andy Holst added the comment:

The documentation updated for the tarfile.rst document. The arguments encoding and errors are added to tarfile.TarInfo.frombuf method. Patch uploaded.

----------
keywords: +patch
nosy: +StealthAsimov
Added file: http://bugs.python.org/file29196/issue15566.patch

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

From report at bugs.python.org  Sat Feb 23 19:58:19 2013
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Feb 2013 18:58:19 +0000
Subject: [docs] [issue16695] Clarify fnmatch & glob docs about the handling
	of	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <3ZCzG31x8nzSkP@mail.python.org>


Roundup Robot added the comment:

New changeset 2b96dcdac419 by Petri Lehtinen in branch '2.7':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/2b96dcdac419

New changeset b4434cbca953 by Petri Lehtinen in branch '3.2':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/b4434cbca953

New changeset 3e8b29512b2e by Petri Lehtinen in branch '3.3':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/3e8b29512b2e

New changeset 3fd9970d9e65 by Petri Lehtinen in branch 'default':
Issue #16695: Document how glob handles filenames starting with a dot
http://hg.python.org/cpython/rev/3fd9970d9e65

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

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

From report at bugs.python.org  Sat Feb 23 19:59:02 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 18:59:02 +0000
Subject: [docs] [issue16695] Clarify fnmatch & glob docs about the handling
	of	leading "."s
In-Reply-To: <1355653936.06.0.839482874064.issue16695@psf.upfronthosting.co.za>
Message-ID: <1361645942.54.0.989633393392.issue16695@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

Applied, thanks!

----------
nosy: +petri.lehtinen
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Feb 23 20:24:27 2013
From: report at bugs.python.org (=?utf-8?q?Dennis_M=C3=A5rtensson?=)
Date: Sat, 23 Feb 2013 19:24:27 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1361647467.34.0.590180706532.issue17188@psf.upfronthosting.co.za>


Dennis M?rtensson added the comment:

We have added the from None to the documentation with a explanation and some example code.

----------
keywords: +patch
nosy: +me at dennis.is
Added file: http://bugs.python.org/file29199/patch17188.patch

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

From report at bugs.python.org  Sat Feb 23 21:25:23 2013
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 23 Feb 2013 20:25:23 +0000
Subject: [docs] [issue17188] Document 'from None' in raise statement doc.
In-Reply-To: <1360631999.8.0.76627095073.issue17188@psf.upfronthosting.co.za>
Message-ID: <1361651123.08.0.258039372904.issue17188@psf.upfronthosting.co.za>


Petri Lehtinen added the comment:

The patch should add something to the "The from clause is used for exception..." paragraph, to state that None is also allowed.

It also adds things in a confusing order. I think the new example should go below other examples, and the changedversion and addedversion directives should be the last thing in the section.

----------
nosy: +petri.lehtinen
versions:  -Python 3.2

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

From report at bugs.python.org  Sun Feb 24 01:14:54 2013
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 24 Feb 2013 00:14:54 +0000
Subject: [docs] [issue17282] document the defaultTest parameter to
	unittest.main()
Message-ID: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to document the defaultTest parameter to unittest.main():

http://docs.python.org/dev/library/unittest.html#unittest.main

Note that it is not enough simply to say that *defaultTest* is a "default test name or iterable of test names."  The documentation should also say when *defaultTest* is used based on the value of the *module* and *argv* arguments, etc.

This issue is an offshoot of issue 15132.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 182839
nosy: chris.jerdonek, docs at python, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: document the defaultTest parameter to unittest.main()
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Feb 24 01:45:51 2013
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 24 Feb 2013 00:45:51 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361666751.95.0.577831411078.issue16942@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

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

From report at bugs.python.org  Sun Feb 24 02:18:50 2013
From: report at bugs.python.org (Demian Brecht)
Date: Sun, 24 Feb 2013 01:18:50 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361668730.11.0.302226233003.issue16942@psf.upfronthosting.co.za>


Demian Brecht added the comment:

I've changed FileCookieJar to use the ABCMeta metaclass and updated the concrete implementations. If this patch looks sufficient, I'll make an update to the docs as well.

----------
keywords: +patch
Added file: http://bugs.python.org/file29215/cookiejar_16942.patch

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

From report at bugs.python.org  Sun Feb 24 02:53:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Feb 2013 01:53:01 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361670781.33.0.576202819259.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Such a list might differentiate between classes that are intentionally not subclassed and those for which subclassing simply has not yet been enabled. That might help eliminate the latter list.

When I suggested on the python-ideas 'range' thread that people should best get what they wanted with a range subclass, if that were made possible, Nick C. replied "I wasn't even aware you *couldn't* subclass it (I'd never tried).". Indeed, why would he with no doc.

The types module doc could also use an addition.
Attached subclassable.py produces these lists:
Among named builtin classes, these cannot be subclassed:
bool, memoryview, range, slice, 
Among types classes, these can be subclassed:
ModuleType, SimpleNamespace,

----------
Added file: http://bugs.python.org/file29216/subclassable.py

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

From report at bugs.python.org  Sun Feb 24 03:25:07 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Feb 2013 02:25:07 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361672707.34.0.135579138027.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The list given is for 3.3. 3.2 and 2.7 do not have SimpleNamespace. I do not have and currently cannot build 3.4 to test, but as of this moment, I expect it to be the same. In 2.7, range is xrange. Its types module includes aliases for builtins, such as IntType, so "Among classes that do not have built-in names" would need to be prefixed.

I simple sentence for types should be easy to place. I am not sure about the built-ins list. The bool entry already has "Class bool cannot be subclassed further. Its only instances are False and True (see Boolean Values).", so a general list would be repeating that part. I am thinking of a minimal sentence for the other three entries. "This class cannot be subclassed."

----------

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

From report at bugs.python.org  Sun Feb 24 05:24:56 2013
From: report at bugs.python.org (Arun Babu Neelicattu)
Date: Sun, 24 Feb 2013 04:24:56 +0000
Subject: [docs] [issue17273] multiprocessing.pool.Pool task/worker handlers
	are not	fork safe
In-Reply-To: <1361514053.16.0.91883779216.issue17273@psf.upfronthosting.co.za>
Message-ID: <1361679896.5.0.69308389213.issue17273@psf.upfronthosting.co.za>


Arun Babu Neelicattu added the comment:

Terry, I think the best place to make a note of this would be at [1,2].

As for what should be noted, something along the lines of what Richard mentioned should suffice.

"A pool should only be used by the process that created it (unless you use a managed pool)."

I am not certain what the best way to phrase this would be, but it would also be helpful to note that this will cause unexpected behavior if a script imports a module that uses a Pool and forks (ie. uses Process() or another Pool()). This is how I bumped into this issue.

Hope this helps.

[1] http://docs.python.org/2/library/multiprocessing.html#using-a-pool-of-workers
[2] http://docs.python.org/3/library/multiprocessing.html#using-a-pool-of-workers

----------

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

From report at bugs.python.org  Sun Feb 24 12:43:50 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 11:43:50 +0000
Subject: [docs] [issue17285] subprocess.check_output incorrectly state that
	output is	always bytes
Message-ID: <1361706230.84.0.572016082.issue17285@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

Documentation states:

>>> help( subprocess.check_output )
check_output(*popenargs, timeout=None, **kwargs)
    Run command with arguments and return its output as a byte string.

But the most common usage is:
>>> subprocess.check_output( 'echo test', shell=True, universal_newlines=True )
'test\n'

Which obviously output a text string, not a byte string.

IMHO, one of the example should also be modified to show the existence of this flag, as it is what user want 90% of the times.

----------
assignee: docs at python
components: Documentation
messages: 182868
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: subprocess.check_output incorrectly state that output is always bytes
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 24 13:20:55 2013
From: report at bugs.python.org (Baptiste Lepilleur)
Date: Sun, 24 Feb 2013 12:20:55 +0000
Subject: [docs] [issue17286] Make subprocess handling text output
	with	universal_newlines more obious
Message-ID: <1361708455.88.0.426093416103.issue17286@psf.upfronthosting.co.za>


New submission from Baptiste Lepilleur:

It tooks me a while to figure out that using universal_newlines was the solution to "tell" subprocess that I wanted text string output instead of byte string.

A search on stackoverflow shows that this issue is common and the solution nearly unknown (answer is usually to decode the byte string manually)...

Because dealing with text output is IMHO the most common use case, the subprocess documentation should make it easier to "find" the recipe.

I would suggest changing the documentation so that the universal_newlines is made obvious as it is very important:
1) the first /bin/vikings example be modified to show the use of this flag (at the top of the documentation, most people copy/past that):
  >>> p = subprocess.Popen(args, universal_newlines=True) # Success!
  and at a small comment below the example to explain that flag
2) change other example similarly when that make sense, IMHO:
   - ifconfig example
   - one of the subprocess.check_output example
   - subprocess.check_output() example, consider separating the byte string / text string example for increased visibility
3) consider adding a section with an obvious title "Dealing with binary and text input/output", providing examples and pointer to the correct documentation (I would place it after the convenience functions section for visibility). I think this would help attracting "eye" on this large piece of documentation.

----------
assignee: docs at python
components: Documentation
messages: 182872
nosy: Baptiste.Lepilleur, docs at python
priority: normal
severity: normal
status: open
title: Make subprocess handling text output with universal_newlines more obious
type: enhancement
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Feb 24 16:08:06 2013
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Feb 2013 15:08:06 +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: <1361718486.31.0.0632312411523.issue17285@psf.upfronthosting.co.za>


R. David Murray added the comment:

IMO the statement should read "and return the stdout data".  The point is that check_output calls Popen and accepts all its arguments except for stdout, which it handles itself and returns as the result.  It would probably be good to then follow that up with something like "This will be bytes unless universal_newlines is set True".

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Sun Feb 24 18:32:30 2013
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 24 Feb 2013 17:32:30 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1361727150.25.0.760384260161.issue17279@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Mon Feb 25 15:06:44 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 25 Feb 2013 14:06:44 +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: <1361801204.85.0.0944837966682.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Henrik, there's no need to provide more information in 3.2 and 2.7 than in 3.3 and default. Could you just align your patches with those (i.e. same wording in the documentation)?

----------

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

From report at bugs.python.org  Tue Feb 26 04:15:18 2013
From: report at bugs.python.org (karl)
Date: Tue, 26 Feb 2013 03:15:18 +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: <1361848518.59.0.135991963239.issue11448@psf.upfronthosting.co.za>


karl added the comment:

This is a possible additional example for set_tunnel, modification of python3.3/html/_sources/library/http.client.txt

Hope it helps.

----------
nosy: +karlcow
Added file: http://bugs.python.org/file29243/http.client.patch

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

From report at bugs.python.org  Tue Feb 26 06:53:13 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Feb 2013 05:53:13 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361857993.68.0.316343249104.issue16942@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+class FileCookieJar(CookieJar, metaclass=ABCMeta):
+    """Abstract Base Class for any file-based CookieJar."""

Is it just me or is it a bit strange to derive an abstract base class from a concrete class? Is CookieJar meant to be directly used?

+        with open(self.filename) as f:
+            magic = f.readline()
+            if not self.magic_re.search(magic):
+                f.close()
+                raise LoadError(
+                    "%r does not look like a Netscape format cookies 

f.close() seems not needed as doing that in __exit__ as a major point of with open... statements.

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

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

From report at bugs.python.org  Tue Feb 26 09:51:20 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 26 Feb 2013 08:51:20 +0000
Subject: [docs] [issue15034] Document best practices for exceptions
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1361868679.92.0.020413144422.issue15034@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I'm removing the "devguide" component and update the title accordingly.

----------
components: +Documentation -Devguide
title: Devguide should document best practices for stdlib exceptions -> Document best practices for exceptions

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

From report at bugs.python.org  Tue Feb 26 12:14:45 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Tue, 26 Feb 2013 11:14:45 +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: <1361877285.36.0.958585306209.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

Eli, I tried to preserve the style (and detail) of the rest of the docs of the respective version. If I bring the 3.3 version of find() into 2.7, then it will have a lot less detail than f.e. findall() as a sibling method on the same class: http://docs.python.org/2/library/xml.etree.elementtree.html#xml.etree.ElementTree.ElementTree

Is that intentional? If so, I'll happily provide adjusted patches.

----------

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

From report at bugs.python.org  Tue Feb 26 14:32:43 2013
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 26 Feb 2013 13:32:43 +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: <1361885563.48.0.442263734443.issue11367@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Henrik. Yes, I think the change in 3.3 was intentional in order to avoid duplication that can be a source of errors. If ET.find() does exactly what ET.getroot().find() does, it suffices to mention it with a link. Since Element docs come first and arguably Element's methods are much more widely used, I think it's a good tradeoff. Any duplication is yet another place to remember fixing when problems in the documentation are discovered (like the original problem leading to this issue).

So for consistency you can make all methods point to Element's methods (just backport 3.3's version, but please verify that the code behavior is indeed as documented in earlier versions).

----------

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

From report at bugs.python.org  Tue Feb 26 15:32:42 2013
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 26 Feb 2013 14:32:42 +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: <1361889162.32.0.782802335136.issue11367@psf.upfronthosting.co.za>


anatoly techtonik added the comment:

Thanks for working on this. It is always nice to see things moving.

----------

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

From report at bugs.python.org  Wed Feb 27 01:01:05 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 00:01:05 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1361923265.67.0.917188073167.issue16901@psf.upfronthosting.co.za>


Changes by Demian Brecht <demianbrecht at gmail.com>:


----------
nosy: +dbrecht

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

From report at bugs.python.org  Wed Feb 27 01:45:03 2013
From: report at bugs.python.org (Demian Brecht)
Date: Wed, 27 Feb 2013 00:45:03 +0000
Subject: [docs] [issue16942] urllib still doesn't support persistent
	connections
In-Reply-To: <1357978376.78.0.27832756308.issue16942@psf.upfronthosting.co.za>
Message-ID: <1361925902.95.0.321770562116.issue16942@psf.upfronthosting.co.za>


Demian Brecht added the comment:

http://bugs.python.org/issue1690 seems to be a duplicate of this one (at least the initial report). 16901 (imho) is documented more clearly than this one, so can this one be closed as duplicate?

----------

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

From report at bugs.python.org  Wed Feb 27 07:05:18 2013
From: report at bugs.python.org (Kushal Das)
Date: Wed, 27 Feb 2013 06:05:18 +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: <1361945118.27.0.22227046498.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

Attaching patch with the initial documentation of the macros. It also fixes the typo in the title of stable API section.

----------
keywords: +patch
nosy: +kushaldas
Added file: http://bugs.python.org/file29258/issue15465.patch

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

From ezio.melotti at gmail.com  Wed Feb 27 08:15:20 2013
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Wed, 27 Feb 2013 07:15:20 -0000
Subject: [docs] Improved documentation for C API version info (issue 15465)
Message-ID: <20130227071520.29023.26837@psf.upfronthosting.co.za>


http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst
File Doc/c-api/apiabiversion.rst (right):

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode11
Doc/c-api/apiabiversion.rst:11: then that module will work on the future
Python releases but not on the older
Is the fact that it won't work enforced (e.g. does it fail when the
version is not valid)?  If not I would use a less strong wording, say
that it might not work on earlier versions.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode14
Doc/c-api/apiabiversion.rst:14: For example if the PY_VERSION_HEX is set
to 0x030400a2, the underlying
``PY_VERSION_HEX`` and ``0x030400a2``.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode19
Doc/c-api/apiabiversion.rst:19: | Bits (big endian order) | Meaning     
                                  |
I would use bytes here (and then group the last two in a single entry).

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode21
Doc/c-api/apiabiversion.rst:21: | :const:`1-8`            | 
``PY_MAJOR_VERSION``  (the ``3`` in           |
Double space.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode27
Doc/c-api/apiabiversion.rst:27: | :const:`17-24`          | 
``PY_MICRO_VERSION``  (the ``0`` in           |
Maybe use 01, so it avoids confusion with the other zeros.

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

From demianbrecht at gmail.com  Wed Feb 27 08:58:08 2013
From: demianbrecht at gmail.com (demianbrecht at gmail.com)
Date: Wed, 27 Feb 2013 07:58:08 -0000
Subject: [docs] urllib still doesn't support persistent connections
	(issue 16942)
Message-ID: <20130227075808.14938.46098@psf.upfronthosting.co.za>


http://bugs.python.org/review/16942/diff/7462/Lib/http/cookiejar.py
File Lib/http/cookiejar.py (right):

http://bugs.python.org/review/16942/diff/7462/Lib/http/cookiejar.py#newcode1758
Lib/http/cookiejar.py:1758: pass
On 2013/02/25 09:32:44, berkerpeksag wrote:
> I think the current behavior of the save() method is already correct.

save is an abstractmethod now. I don't see the harm in allowing concrete
classes to call into FileCookieJar.save(self, ...) and having it do
nothing. However, calling into FileCookieJar.save(self, ...) and having
NotImplementedError raised might be a little strange.

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

From kushaldas at gmail.com  Wed Feb 27 11:23:00 2013
From: kushaldas at gmail.com (kushaldas at gmail.com)
Date: Wed, 27 Feb 2013 10:23:00 -0000
Subject: [docs] Improved documentation for C API version info (issue
	15465)
Message-ID: <20130227102300.29022.44999@psf.upfronthosting.co.za>


http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst
File Doc/c-api/apiabiversion.rst (right):

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode11
Doc/c-api/apiabiversion.rst:11: then that module will work on the future
Python releases but not on the older
On 2013/02/27 08:15:20, ezio.melotti wrote:
> Is the fact that it won't work enforced (e.g. does it fail when the
version is
> not valid)?  If not I would use a less strong wording, say that it
might not
> work on earlier versions.
They will fail to load, I will make the required changes.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode14
Doc/c-api/apiabiversion.rst:14: For example if the PY_VERSION_HEX is set
to 0x030400a2, the underlying
On 2013/02/27 08:15:20, ezio.melotti wrote:
> ``PY_VERSION_HEX`` and ``0x030400a2``.

Ok, will also make this change.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode19
Doc/c-api/apiabiversion.rst:19: | Bits (big endian order) | Meaning     
                                  |
On 2013/02/27 08:15:20, ezio.melotti wrote:
> I would use bytes here (and then group the last two in a single
entry).
I followed the explanation in the same way it is done in
http://docs.python.org/3.4/library/sys.html#sys.hexversion

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode21
Doc/c-api/apiabiversion.rst:21: | :const:`1-8`            | 
``PY_MAJOR_VERSION``  (the ``3`` in           |
On 2013/02/27 08:15:20, ezio.melotti wrote:
> Double space.

Ok.

http://bugs.python.org/review/15465/diff/7486/Doc/c-api/apiabiversion.rst#newcode27
Doc/c-api/apiabiversion.rst:27: | :const:`17-24`          | 
``PY_MICRO_VERSION``  (the ``0`` in           |
On 2013/02/27 08:15:20, ezio.melotti wrote:
> Maybe use 01, so it avoids confusion with the other zeros.

Ok, will change the example accordingly.

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

From report at bugs.python.org  Wed Feb 27 11:31:25 2013
From: report at bugs.python.org (Kushal Das)
Date: Wed, 27 Feb 2013 10:31:25 +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: <1361961085.91.0.245142580013.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

Adding the updated patch with changes as suggested in the review

----------
Added file: http://bugs.python.org/file29260/issue15465v2.patch

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

From report at bugs.python.org  Wed Feb 27 19:36:37 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 27 Feb 2013 18:36:37 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1361990197.96.0.0375526252926.issue12768@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


Added file: http://bugs.python.org/file29268/12768_2.patch

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

From report at bugs.python.org  Wed Feb 27 19:40:05 2013
From: report at bugs.python.org (moijes12)
Date: Wed, 27 Feb 2013 18:40:05 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1361990405.2.0.875241088229.issue12768@psf.upfronthosting.co.za>


moijes12 added the comment:

I've attached a new patch with some changes.

----------

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

From report at bugs.python.org  Thu Feb 28 02:14:09 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 28 Feb 2013 01:14:09 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362014038.56.0.256915175466.issue16901@psf.upfronthosting.co.za>


Demian Brecht added the comment:

(Note: Additional context can be found here: http://bugs.python.org/issue16942, which seems to be a dupe of this report)

I haven't had any feedback to my proposal on python-ideas about the removal of LWPCookieJar and MozillaCookieJar and the introduction of LWPCookieProcessor and MozillaCookieProcessor yet (http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be indicative of this change simply not being acceptable. However, on the outside chance that's not the case, I've submitted a patch covering the proposed implementations. All tests pass. 

The patch addresses some of the oddities around FileCookieJar looking, but not behaving as an abstract class as well as inheriting from a concrete class (CookieJar). The change aligns LWPCookies and MozillaCookies with the HTTPCookies. This should fix the questions around why FileCookieJar can't be used directly. If this change looks reasonable, corresponding documentation changes will be made as well.

Note: This change /does/ break backwards compatibility. I'm not sure what the process is for that, so if this change is eventually applied, pointers as to what should be integrated where would be helpful.

----------
keywords: +patch
Added file: http://bugs.python.org/file29275/cookiejar_16901.patch

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

From report at bugs.python.org  Thu Feb 28 02:31:49 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Feb 2013 01:31:49 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362015108.8.0.263206572069.issue16901@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I suspect most people don't use or care much about cookies and cookie jar and do not understand the issue of proposal enough to comment. My feeling is that the patch probably breaks more than is necessary to fix the immediate problem and too much for current releases. For one, just the name change seems unnecessary. I need to look at HTTPCookies before I can say more.

----------

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

From report at bugs.python.org  Thu Feb 28 07:26:39 2013
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Feb 2013 06:26:39 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1362032799.64.0.15307083862.issue17279@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/issue17279>
_______________________________________

From report at bugs.python.org  Thu Feb 28 07:45:06 2013
From: report at bugs.python.org (py.user)
Date: Thu, 28 Feb 2013 06:45:06 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362033906.78.0.397491373711.issue16901@psf.upfronthosting.co.za>


py.user added the comment:

Demian Brecht wrote:
>I haven't had any feedback to my proposal on python-ideas about the >removal of LWPCookieJar and MozillaCookieJar and the introduction of >LWPCookieProcessor and MozillaCookieProcessor yet >(http://thread.gmane.org/gmane.comp.python.ideas/19673), which could be >indicative of this change simply not being acceptable.

all python ideas are discussed in python lists (for users and for developers)

----------

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

From report at bugs.python.org  Thu Feb 28 08:06:04 2013
From: report at bugs.python.org (Kushal Das)
Date: Thu, 28 Feb 2013 07:06:04 +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: <1362035164.73.0.74373749476.issue15465@psf.upfronthosting.co.za>


Kushal Das added the comment:

version 3 of the patch where sys.hexversion table is moved and now a link to api and abi versioning given.

----------
Added file: http://bugs.python.org/file29277/issue15465v3.patch

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

From report at bugs.python.org  Thu Feb 28 08:24:47 2013
From: report at bugs.python.org (Demian Brecht)
Date: Thu, 28 Feb 2013 07:24:47 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362036287.73.0.0507515416224.issue16901@psf.upfronthosting.co.za>


Demian Brecht added the comment:

@Terry: I don't think that the name change is unnecessary as the patch changes the semantics of the the LWP and Mozilla Cookie classes. In the patch, they no longer /are/ a subclass of a CookieJar, but they take a CookieJar object and implement the FileCookieProcessor interface in order to save/load/revert file-based cookies.

This solves the problem of an abstract base class (or at least, what was /intended/ to be an abstract base class prior to abcs: FileCookieJar) extending a concrete class, which doesn't make sense from an architectural standpoint. It also fixes the problem that people are encountering when attempting to instantiate a FileCookieJar object, it doesn't just patch something that's fundamentally broken. It could be my lack of experience with large scale OSS, but I'd prefer a /correct/ fix (especially to something that few actually care about and is seemingly not in heavy use) over a duct taped "just make it work" solution.

I absolutely agree, however, that this is a rather large change (as far as the cookiejar module goes anyway) and shouldn't be taken lightly. However, the cookiejar module /is/ in need of some love and I think that this takes a step to giving it that.

@py.user: My proposal was made to python-ideas. I just prefer gmane to Google Group for links.

----------

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

From report at bugs.python.org  Thu Feb 28 11:19:56 2013
From: report at bugs.python.org (David Lam)
Date: Thu, 28 Feb 2013 10:19:56 +0000
Subject: [docs] [issue16954] Add docstrings for ElementTree module
In-Reply-To: <1358090813.12.0.93631082121.issue16954@psf.upfronthosting.co.za>
Message-ID: <1362046795.22.0.933095701968.issue16954@psf.upfronthosting.co.za>


David Lam added the comment:

here's an updated patch incorporating the feedback from Ezio and Eric:

   - moved docstrings put in some __special__ method names
   - made the description of 'tag' consistent:  'tag' means the elements name (as opposed to 'tag' being a synonym for "element"!)
   - docstring args now *stared* as opposed to 'quoted'


I also gave a shot at copying the existing docstrings into their respective C counterparts.  But it *seems* like you can't do so
that easily for a C extension. Maybe I missed something though: 

>>> from _elementtree import Element as cElement
>>> cElement.__doc__ = 'foobarbaz'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't set attributes of built-in/extension type 'xml.etree.ElementTree.Element'

I see one example in Modules/_json.c where the docstrings were sorta copied and pasted over, so perhaps it's an ok thing to do.

----------
Added file: http://bugs.python.org/file29278/issue16954-v2.patch

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

From report at bugs.python.org  Thu Feb 28 14:54:36 2013
From: report at bugs.python.org (Henrik Heimbuerger)
Date: Thu, 28 Feb 2013 13:54: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: <1362059676.66.0.131529783153.issue11367@psf.upfronthosting.co.za>


Henrik Heimbuerger added the comment:

That sounds good, Eli! I'll check the implementations and then adapt the other ElementTree methods as well. Will take until next week, though.

----------

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

From report at bugs.python.org  Thu Feb 28 21:38:01 2013
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 28 Feb 2013 20:38:01 +0000
Subject: [docs] [issue17279] Document which named built-in classes can be
	subclassed
In-Reply-To: <1361570964.09.0.896873756654.issue17279@psf.upfronthosting.co.za>
Message-ID: <1362083881.66.0.406211986129.issue17279@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From the current python-ideas 'range' thread:
Me: Would it be correct to say (now) that all 4 are intentional omissions? and not merely oversights?
Nick: Yes, I think so. People will have to be *real* convincing to explain a case where composition isn't a more appropriate solution.

----------

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

From report at bugs.python.org  Thu Feb 28 22:32:57 2013
From: report at bugs.python.org (py.user)
Date: Thu, 28 Feb 2013 21:32:57 +0000
Subject: [docs] [issue16901] In http.cookiejar.FileCookieJar() the .load()
	and	.revert() methods don't work
In-Reply-To: <1357688221.9.0.622857187739.issue16901@psf.upfronthosting.co.za>
Message-ID: <1362087177.17.0.115598447311.issue16901@psf.upfronthosting.co.za>


py.user added the comment:

Demian Brecht:
>My proposal was made to python-ideas.

try this
http://mail.python.org/mailman/listinfo/python-dev

----------

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

From Chris.King at corero.com  Mon Feb  4 17:33:58 2013
From: Chris.King at corero.com (Chris King)
Date: Mon, 04 Feb 2013 16:33:58 -0000
Subject: [docs] json module doesn't document exceptions (doc bug report)
Message-ID: <op.wrzpawwqw3e82s@cking-tc-m58>

Hi, the json module documentation  
http://docs.python.org/2/library/json.html doesn't document its behavior  
on ill-formed JSON, so one doesn't know which exceptions to catch except  
for by trial and error.

From chrisbenson56 at att.net  Sun Feb 10 22:19:56 2013
From: chrisbenson56 at att.net (Chris Benson)
Date: Sun, 10 Feb 2013 21:19:56 -0000
Subject: [docs] Incorrect documentation of // (floor) operator
Message-ID: <000001ce07d4$5a154e50$0e3feaf0$@net>

In my Windows CHM Python 3.3.0 documentation there is a mismatch between the
description and the example of the // operator.

The following text and example appears in Section 3.1.1. Numbers:

To do integer division and get an integer result, discarding any fractional
result, there is another operator, //:

>>> # Integer division returns the floor:

... 7//3

2

>>> 7//-3

-3

 

The # comment at the python prompt is correct. This is the floor operator.
The accompanying text is wrong "discarding any fractional result" is NOT the
definition of the floor operator in the case of negative results (second
example). The text description would be true if 7 // -3 resulted in -2,
which it does NOT. A better text description would be this:

To do integer division (with fractional results rounded down to the next
lower whole number), there is the floor operator written as //

 

In other words, the text description applying precise (non-integral)
division to 7 / -3, results in -2.333333., and discarding any fractional
result, would arrive at the answer -2.

The textual description describes the truncation operator, which in the
second given example has a different result. For a mathematical description
of both the floor and truncation operators, please see
http://en.wikipedia.org/wiki/Floor_and_ceiling_functions

 

With thanks, from Chris Benson.

Three degrees in mathematics, and nearly 40 years programming experience.
Teaching Python 3 to my daughter!

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130210/4f2e74f1/attachment-0001.html>

From bob.brusa at gmail.com  Tue Feb 12 12:52:24 2013
From: bob.brusa at gmail.com (Bob Brusa)
Date: Tue, 12 Feb 2013 11:52:24 -0000
Subject: [docs] Python 3.3 Doc on iPad
Message-ID: <CAKMtXi3sKYqQCt0FAe_B9FA5VJPwvLwSG08byYiCo1adzg+ydQ@mail.gmail.com>

Hi,
Reading the documentation (library ref) on pythons web site is difficult on
my iPad. When scrolling up, the text jumps back to the top of the page as
soon as I take my finger off the screen. The /2/ doc does not show this
behavior. /3/ however does it, with Safary  as well as with Chrome. Hope
someone finds out how to fix this.
Regards Bob




-- 
Von Gmail Mobile gesendet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130212/82b83773/attachment-0001.html>

From ameliabob at gmail.com  Wed Feb 13 17:02:23 2013
From: ameliabob at gmail.com (Bob Sawyer)
Date: Wed, 13 Feb 2013 16:02:23 -0000
Subject: [docs] Python Tutorial
Message-ID: <CAN_3pzMdo6Y1-LEQYdOP+m1MORAmreGLYM_UXWMJxF8bEy1kzw@mail.gmail.com>

I am a newbie to Python but not to programming and as I started to go
through the tutorial, I noticed some changes to the language that have not
been reflected in the tutorial.

Specifically,
In 3.1.2 Strings the print command does not have parenthesis around it
i.e print i  instead of print (i)

Ellipses that are shown in 3.2 first Steps to Programming do not appear in
the IDLE 3.3.0 version

As I encounter more I will write again.

Bob Sawyer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130213/389b72c0/attachment-0001.html>

From alex9627 at gmail.com  Thu Feb 14 20:34:12 2013
From: alex9627 at gmail.com (Alex Guerra)
Date: Thu, 14 Feb 2013 19:34:12 -0000
Subject: [docs] Typo in
	http://docs.python.org/2/library/simplehttpserver.html
Message-ID: <CAPc_BB8nBwGoFOK6xHpx-iw6CbjS6=oT2tekQ0u8zx6mzC2oDw@mail.gmail.com>

Hi,

I think there is a typo in
http://docs.python.org/2/library/simplehttpserver.html :

> A 'Content-type:' header

type should be Type in this case.

Thanks.

From colin at uckfield.demon.co.uk  Tue Feb 26 16:12:12 2013
From: colin at uckfield.demon.co.uk (Colin Morley)
Date: Tue, 26 Feb 2013 15:12:12 -0000
Subject: [docs] Function Int()
Message-ID: <001f01ce142f$5039b260$f0ad1720$@demon.co.uk>

Hi

 

I'm not a Python expert - barely a novice, but the entry for the function
INT() on both 2.7 and 3.3 versions is headed 

 

INT(x=0)...

 

Which does not seem to make much sense to me - shouldn't it be INT(x)?

 

(X=0) is true or false (1 or 0)  depending on the value of x.

 

Apologies if this is nonsense

 

Colin

 

Colin Morley

Pippins

Crossroads

Lewdown

Okehampton

Devon

EX20 4DP

01566 783152

colin at uckfield.demon.co.uk

 

  _____  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2899 / Virus Database: 2641/6133 - Release Date: 02/25/13




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2013.0.2899 / Virus Database: 2641/6133 - Release Date: 02/25/13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130226/b5721324/attachment-0001.html>

From cclauss at bluewin.ch  Wed Feb 27 04:40:05 2013
From: cclauss at bluewin.ch (Christian Clauss)
Date: Wed, 27 Feb 2013 03:40:05 -0000
Subject: [docs] Python 2.7.4 release date typo -- Year is 2012 instead of
	2013
Message-ID: <8A93E976-3EDE-4A14-BFD2-7E357B1D0B8F@bluewin.ch>

http://www.python.org/dev/peps/pep-0373/#release-schedule

Planned future release dates:
2.7.4rc1 2013-02-02
2.7.4 2012-02-16.      # 2012 instead of 2013
Both "future" dates are in the past however the final release is 2012 before the rc1 date is 2013.

These dates should both be in 2013 and ideally, both future release dates should be in the future.

Thanks to you all for your great work.  CCC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130227/0339d16a/attachment-0001.html>

From alberth289346 at gmail.com  Thu Feb 28 00:03:28 2013
From: alberth289346 at gmail.com (Albert Hofkamp)
Date: Wed, 27 Feb 2013 23:03:28 -0000
Subject: [docs] Bugs in Python3 division and right-shift docs
Message-ID: <CAEyAk53bDXqgwiSLec63BQotz_9mazu67uVAxCe3su8eigSKpg@mail.gmail.com>

While reporting a doc bug in the right-shift operator, I found another
one in the division description. I combined them both below.


http://docs.python.org/3/reference/expressions.html?highlight=shift#binary-arithmetic-operations
A quote:
" ... The / (division) and // (floor division) operators yield the
quotient of their arguments. The numeric arguments are first converted
to a common type. Integer division yields a float, while floor
division of integers results in an integer; ..."

The term "Integer division" does not get defined here.  Perhaps
"Division of integers yields ..." would be better?




http://docs.python.org/3/reference/expressions.html?highlight=shift#shifting-operations
A quote from 6.7 (Shifting operations) of the python 3 language reference:

"...These operators accept integers as arguments. They shift the first
argument to the left or right by the number of bits given by the
second argument.
A right shift by n bits is defined as division by pow(2,n). A left
shift by n bits is defined as multiplication with pow(2,n). ..."

By the latter sentence, I can interpret 2 >> 5 as 2 / pow(2, 5), which
is 0.0625. On the other hand, 2 >> 5 is 0 according to Python 3.3 .
Perhaps it should say "floor division" in the explanation above?

Albert

From sparklinrose at hotmail.com  Sun Feb 10 16:51:57 2013
From: sparklinrose at hotmail.com (Sparklinrose An American Lotus)
Date: Sun, 10 Feb 2013 15:51:57 -0000
Subject: [docs] trivial issues: missing "break",
 and bad indentation in example in tutorial section 4.4
Message-ID: <SNT144-W2447E6BCE6B28423CB3808D40B0@phx.gbl>





http://docs.python.org/2/tutorial/controlflow.html Example is missing the break in the else: statement, consequently the prime number statements are printed multiple times  Also, 'else:' statement is indented at the same level as the inner 'for' statement, not at the level of the 'if' statementcuriously enough (on Windows Vista, Python2.7) does not complain of thisyou will only get one output statement, "2 is a prime number"Running environment and method:Windows Vista Home Premium SP 2Python 2.7created file 'primes.py'ran in command line window as 'python primes.py'got the single output statement, "2 is a prime number" So, two relatively trivial issues, but the page does say you want to know. Have a good day, and thanks for having this info up there, it is pretty handy as a refresher. Sparklinrose    		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130210/7bcce018/attachment-0001.html>

From zfreeman.nu at gmail.com  Sun Feb 10 21:32:04 2013
From: zfreeman.nu at gmail.com (Zach)
Date: Sun, 10 Feb 2013 20:32:04 -0000
Subject: [docs] Python Documentation Bug
Message-ID: <CAJ+vyDddRfKeV=47wXOGs635sXtd2M7zxVN3XucFTfY_LfcDWA@mail.gmail.com>

Hello,

In the "Data Structures" tutorial, at address
http://docs.python.org/2/tutorial/datastructures.html, in the example

For example, to compute a sequence of numbers not divisible by 2 and 3:
>>>

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

I believe it should read "divisible by 2 *or* 3", based on the resulting
list and function definition of 'f'.

Cheers,
Zach

-- 
Zachary Freeman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130210/9066982b/attachment-0001.html>

From storchaka at gmail.com  Fri Feb 15 22:57:39 2013
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Fri, 15 Feb 2013 21:57:39 -0000
Subject: [docs] Use binary prefixes (issue 17193)
Message-ID: <20130215215738.31646.45869@psf.upfronthosting.co.za>

Reviewers: ezio.melotti,


http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst
File Doc/howto/unicode.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/howto/unicode.rst#newcode459
Doc/howto/unicode.rst:459: chunks (say, 1 KiB or 4 KiB), you need to
write error-handling code to catch the case
On 2013/02/15 22:17:02, ezio.melotti wrote:
> I would leave this alone, or possibly change it to "1k or 4k bytes".

I doubt anyone reads the file in chunks of 1000 or 4000 bytes. It's
rather 1024 or 4096 bytes.

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst
File Doc/library/lzma.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode161
Doc/library/lzma.rst:161: :class:`LZMACompressor` object can be as high
as 800 MiB. For this reason,
On 2013/02/15 22:17:02, ezio.melotti wrote:
> Why is this MiB?

See for example xz manual. 800 MiB is the memory usage for the
compression with preset 9.

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode306
Doc/library/lzma.rst:306: 1.5 GiB (inclusive).
On 2013/02/15 22:17:02, ezio.melotti wrote:
> Ditto.

>From xz manual: "The minimum is 4 KiB.  The maximum for compression is
currently 1.5 GiB."

http://bugs.python.org/review/17193/diff/7360/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/os.rst#newcode2332
Doc/library/os.rst:2332: is 64 kibibytes on Linux.
On 2013/02/15 22:17:02, ezio.melotti wrote:
> I would use KiB.

Done.

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst
File Doc/library/tarfile.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst#newcode672
Doc/library/tarfile.rst:672: maximum file size is 8 gibibytes. This is
an old and limited but widely
On 2013/02/15 22:17:02, ezio.melotti wrote:
> GiB

Done.

http://bugs.python.org/review/17193/diff/7360/Doc/library/tarfile.rst#newcode676
Doc/library/tarfile.rst:676: linknames, files bigger than 8 gibibytes
and sparse files. It is the de facto
On 2013/02/15 22:17:02, ezio.melotti wrote:
> Ditto.

Done.



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

Affected files:
  Doc/howto/unicode.rst
  Doc/library/_thread.rst
  Doc/library/lzma.rst
  Doc/library/os.rst
  Doc/library/posix.rst
  Doc/library/tarfile.rst
  Doc/library/threading.rst
  Doc/library/zipfile.rst
  Modules/_pickle.c


diff -r 7727be7613f9 Doc/howto/unicode.rst
--- a/Doc/howto/unicode.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/howto/unicode.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -456,11 +456,11 @@
 
 One problem is the multi-byte nature of encodings; one Unicode character can be
 represented by several bytes.  If you want to read the file in arbitrary-sized
-chunks (say, 1k or 4k), you need to write error-handling code to catch the case
+chunks (say, 1 KiB or 4 KiB), you need to write error-handling code to catch the case
 where only part of the bytes encoding a single Unicode character are read at the
 end of a chunk.  One solution would be to read the entire file into memory and
 then perform the decoding, but that prevents you from working with files that
-are extremely large; if you need to read a 2GB file, you need 2GB of RAM.
+are extremely large; if you need to read a 2 GiB file, you need 2 GiB of RAM.
 (More, really, since for at least a moment you'd need to have both the encoded
 string and its Unicode version in memory.)
 
diff -r 7727be7613f9 Doc/library/_thread.rst
--- a/Doc/library/_thread.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/_thread.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -93,15 +93,15 @@
    Return the thread stack size used when creating new threads.  The optional
    *size* argument specifies the stack size to be used for subsequently created
    threads, and must be 0 (use platform or configured default) or a positive
-   integer value of at least 32,768 (32kB). If changing the thread stack size is
+   integer value of at least 32,768 (32 KiB). If changing the thread stack size is
    unsupported, a :exc:`RuntimeError` is raised.  If the specified stack size is
-   invalid, a :exc:`ValueError` is raised and the stack size is unmodified.  32kB
+   invalid, a :exc:`ValueError` is raised and the stack size is unmodified.  32 KiB
    is currently the minimum supported stack size value to guarantee sufficient
    stack space for the interpreter itself.  Note that some platforms may have
    particular restrictions on values for the stack size, such as requiring a
-   minimum stack size > 32kB or requiring allocation in multiples of the system
+   minimum stack size > 32 KiB or requiring allocation in multiples of the system
    memory page size - platform documentation should be referred to for more
-   information (4kB pages are common; using multiples of 4096 for the stack size is
+   information (4 KiB pages are common; using multiples of 4096 for the stack size is
    the suggested approach in the absence of more specific information).
    Availability: Windows, systems with POSIX threads.
 
diff -r 7727be7613f9 Doc/library/lzma.rst
--- a/Doc/library/lzma.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/lzma.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -158,7 +158,7 @@
       In addition to being more CPU-intensive, compression with higher presets
       also requires much more memory (and produces output that needs more memory
       to decompress). With preset ``9`` for example, the overhead for an
-      :class:`LZMACompressor` object can be as high as 800MiB. For this reason,
+      :class:`LZMACompressor` object can be as high as 800 MiB. For this reason,
       it is generally best to stick with the default preset.
 
    The *filters* argument (if provided) should be a filter chain specifier.
@@ -302,8 +302,8 @@
 
    * ``preset``: A compression preset to use as a source of default values for
      options that are not specified explicitly.
-   * ``dict_size``: Dictionary size in bytes. This should be between 4KiB and
-     1.5GiB (inclusive).
+   * ``dict_size``: Dictionary size in bytes. This should be between 4 KiB and
+     1.5 GiB (inclusive).
    * ``lc``: Number of literal context bits.
    * ``lp``: Number of literal position bits. The sum ``lc + lp`` must be at
      most 4.
diff -r 7727be7613f9 Doc/library/os.rst
--- a/Doc/library/os.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/os.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -2329,7 +2329,7 @@
 .. data:: XATTR_SIZE_MAX
 
    The maximum size the value of an extended attribute can be. Currently, this
-   is 64 kilobytes on Linux.
+   is 64 kibibytes on Linux.
 
 
 .. data:: XATTR_CREATE
diff -r 7727be7613f9 Doc/library/posix.rst
--- a/Doc/library/posix.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/posix.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -37,7 +37,7 @@
 .. sectionauthor:: Steve Clift <clift at mail.anacapa.net>
 
 Several operating systems (including AIX, HP-UX, Irix and Solaris) provide
-support for files that are larger than 2 GB from a C programming model where
+support for files that are larger than 2 GiB from a C programming model where
 :c:type:`int` and :c:type:`long` are 32-bit values. This is typically accomplished
 by defining the relevant size and offset types as 64-bit values. Such files are
 sometimes referred to as :dfn:`large files`.
diff -r 7727be7613f9 Doc/library/tarfile.rst
--- a/Doc/library/tarfile.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/tarfile.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -669,11 +669,11 @@
 
 * The POSIX.1-1988 ustar format (:const:`USTAR_FORMAT`). It supports filenames
   up to a length of at best 256 characters and linknames up to 100 characters. The
-  maximum file size is 8 gigabytes. This is an old and limited but widely
+  maximum file size is 8 gibibytes. This is an old and limited but widely
   supported format.
 
 * The GNU tar format (:const:`GNU_FORMAT`). It supports long filenames and
-  linknames, files bigger than 8 gigabytes and sparse files. It is the de facto
+  linknames, files bigger than 8 gibibytes and sparse files. It is the de facto
   standard on GNU/Linux systems. :mod:`tarfile` fully supports the GNU tar
   extensions for long names, sparse file support is read-only.
 
diff -r 7727be7613f9 Doc/library/threading.rst
--- a/Doc/library/threading.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/threading.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -80,15 +80,15 @@
    Return the thread stack size used when creating new threads.  The optional
    *size* argument specifies the stack size to be used for subsequently created
    threads, and must be 0 (use platform or configured default) or a positive
-   integer value of at least 32,768 (32kB). If changing the thread stack size is
+   integer value of at least 32,768 (32 KiB). If changing the thread stack size is
    unsupported, a :exc:`RuntimeError` is raised.  If the specified stack size is
-   invalid, a :exc:`ValueError` is raised and the stack size is unmodified.  32kB
+   invalid, a :exc:`ValueError` is raised and the stack size is unmodified.  32 KiB
    is currently the minimum supported stack size value to guarantee sufficient
    stack space for the interpreter itself.  Note that some platforms may have
    particular restrictions on values for the stack size, such as requiring a
-   minimum stack size > 32kB or requiring allocation in multiples of the system
+   minimum stack size > 32 KiB or requiring allocation in multiples of the system
    memory page size - platform documentation should be referred to for more
-   information (4kB pages are common; using multiples of 4096 for the stack size is
+   information (4 KiB pages are common; using multiples of 4096 for the stack size is
    the suggested approach in the absence of more specific information).
    Availability: Windows, systems with POSIX threads.
 
diff -r 7727be7613f9 Doc/library/zipfile.rst
--- a/Doc/library/zipfile.rst	Tue Feb 12 15:33:16 2013 +0100
+++ b/Doc/library/zipfile.rst	Tue Feb 12 22:03:33 2013 +0200
@@ -18,7 +18,7 @@
 
 This module does not currently handle multi-disk ZIP files.
 It can handle ZIP files that use the ZIP64 extensions
-(that is ZIP files that are more than 4 GByte in size).  It supports
+(that is ZIP files that are more than 4 GiB in size).  It supports
 decryption of encrypted files in ZIP archives, but it currently cannot
 create an encrypted file.  Decryption is extremely slow as it is
 implemented in native Python rather than C.
@@ -148,7 +148,7 @@
    (:mod:`zlib`, :mod:`bz2` or :mod:`lzma`) is not available, :exc:`RuntimeError`
    is also raised. The default is :const:`ZIP_STORED`.  If *allowZip64* is
    ``True`` zipfile will create ZIP files that use the ZIP64 extensions when
-   the zipfile is larger than 2 GB. If it is  false (the default) :mod:`zipfile`
+   the zipfile is larger than 2 GiB. If it is  false (the default) :mod:`zipfile`
    will raise an exception when the ZIP file would require ZIP64 extensions.
    ZIP64 extensions are disabled by default because the default :program:`zip`
    and :program:`unzip` commands on Unix (the InfoZIP utilities) don't support
diff -r 7727be7613f9 Modules/_pickle.c
--- a/Modules/_pickle.c	Tue Feb 12 15:33:16 2013 +0100
+++ b/Modules/_pickle.c	Tue Feb 12 22:03:33 2013 +0200
@@ -1788,7 +1788,7 @@
         }
         else {
             PyErr_SetString(PyExc_OverflowError,
-                            "cannot serialize a bytes object larger than 4GB");
+                            "cannot serialize a bytes object larger than 4 GiB");
             return -1;          /* string too large */
         }
 
@@ -1888,7 +1888,7 @@
         size = PyBytes_GET_SIZE(encoded);
         if (size > 0xffffffffL) {
             PyErr_SetString(PyExc_OverflowError,
-                            "cannot serialize a string larger than 4GB");
+                            "cannot serialize a string larger than 4 GiB");
             goto error;          /* string too large */
         }
 



From storchaka at gmail.com  Sat Feb 16 16:27:53 2013
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Sat, 16 Feb 2013 15:27:53 -0000
Subject: [docs] Use binary prefixes (issue 17193)
Message-ID: <20130216152753.10247.87181@psf.upfronthosting.co.za>


http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst
File Doc/library/lzma.rst (right):

http://bugs.python.org/review/17193/diff/7360/Doc/library/lzma.rst#newcode161
Doc/library/lzma.rst:161: :class:`LZMACompressor` object can be as high
as 800 MiB. For this reason,
On 2013/02/15 23:39:47, ezio.melotti wrote:
> On 2013/02/15 22:57:38, storchaka wrote:
> > On 2013/02/15 22:17:02, ezio.melotti wrote:
> > > Why is this MiB?
> > 
> > See for example xz manual. 800 MiB is the memory usage for the
compression
> with
> > preset 9.
> 
> That doesn't mean that it's correct :)
> 800 MiB is equal to 838860800 bytes, and while it might indeed be the
exact
> value they used, it seems a bit arbitrary to me.

I have no reason not to trust the author.

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

From scutweiqiang.yang at gmail.com  Sun Feb 17 12:30:00 2013
From: scutweiqiang.yang at gmail.com (weiqiang.yang)
Date: Sun, 17 Feb 2013 11:30:00 -0000
Subject: [docs] python datetime module doc bug
Message-ID: <5120BF35.4000507@gmail.com>

http://docs.python.org/2/library/datetime.html#module-datetime
-----------
Subclass relationships:
object
    timedelta
    tzinfo
    time
    date
        datetime
-----------
I think it should be
-----------
Subclass relationships:
object
    timedelta
    tzinfo
    time
    date
    datetime
-----------

hope it helps.
weiqiang.Yang


From zhangxiaopan at gmail.com  Wed Feb 27 20:31:57 2013
From: zhangxiaopan at gmail.com (=?UTF-8?B?5byg5bCP5r2Y?=)
Date: Wed, 27 Feb 2013 19:31:57 -0000
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.
Message-ID: <CAPgpG2A6Rv+AQOA1wwws0KzwEEw2x6xBxNRyFf7jBD_bdL6-gA@mail.gmail.com>

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.

-- 
???
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130227/46636ef0/attachment-0001.html>

From David.Ham at imperial.ac.uk  Sat Feb 16 14:50:26 2013
From: David.Ham at imperial.ac.uk (David Ham)
Date: Sat, 16 Feb 2013 13:50:26 -0000
Subject: [docs] Documentation bug in conditional expression.
Message-ID: <CAEt+Ss_CoRuOFd9iC7BACjodbLesR1eh-UX+Cfr7kYH+acPvqQ@mail.gmail.com>

At:
http://docs.python.org/2/reference/expressions.html#conditional-expressions

The bnf for conditional expressions is:

conditional_expression ::=  or_test ["if" or_test "else" expression]

Surely it should be:

conditional_expression ::=  expression ["if" or_test "else" expression]

Regards,

David

-- 
Dr David Ham
Department of Computing
Imperial College London

http://www.imperial.ac.uk/people/david.ham

From ericmaster77 at hotmail.com  Sat Feb 16 16:54:38 2013
From: ericmaster77 at hotmail.com (=?iso-2022-jp?B?RXJpYyBNYXN0ZXIgGyRCIiUbKEI=?=)
Date: Sat, 16 Feb 2013 15:54:38 -0000
Subject: [docs] Problem with the pdf FAQ
Message-ID: <BAY154-W19BF25AC386F1B62BBDA68CE0D0@phx.gbl>



Hello there, 

My name is Eric. I'm from Brazil. I have a comment, and a suggestion to do. :)

I made the download of the python docs. And when I opened the 'faq.pdf', when I go to the page number 10 (the page 16 of 122, on the browser) I can't see the whole page. In the end, there's something that seems a 'cut'. Can you see if it is a problem with my Acrobat or with the doc?

Thank you all. Python rocks. 

See ya.

Eric
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130216/5edea434/attachment-0001.html>

From crackingtoastuk at yahoo.co.uk  Sun Feb 17 01:07:44 2013
From: crackingtoastuk at yahoo.co.uk (Matthew)
Date: Sun, 17 Feb 2013 00:07:44 -0000
Subject: [docs] Error in
	http://docs.python.org/2/library/xml.etree.elementtree.html#finding-interesting-elements
Message-ID: <1361058057.54546.YahooMailNeo@web172001.mail.ir2.yahoo.com>

"Element.text() accesses the element?s text
content"

should read

"Element.text accesses the element?s text
content"

Best wishes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130217/d424f411/attachment.html>

From evillegas at estrasol.com.mx  Wed Feb 20 22:09:25 2013
From: evillegas at estrasol.com.mx (Edgar Villegas)
Date: Wed, 20 Feb 2013 21:09:25 -0000
Subject: [docs] Problem with install python 3
Message-ID: <51253A2D.7080106@estrasol.com.mx>

Hello

I have a problem, when install python on Centos 5 shows me this message 
"By default, distutils will build C++ extension modules with g++ If this 
not intended, then set CXX on the configure command line"

why this happens

Thanks .
-- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130220/3988d615/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edgarv.jpg
Type: image/jpeg
Size: 61754 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20130220/3988d615/attachment-0001.jpg>

From demianbrecht at gmail.com  Sat Feb 23 20:26:21 2013
From: demianbrecht at gmail.com (Demian Brecht)
Date: Sat, 23 Feb 2013 19:26:21 -0000
Subject: [docs] 2.7 memoryview/buffer docs patch
Message-ID: <CAE+T62bwbP+=PveFmO==Pi5S5e=W7KT8XgGVif5c3N0PY4w1-w@mail.gmail.com>

I'm rather new to submitting patches and as such, I'm not sure what
kind of expectations I should have in turnaround time. So, my
apologies if I'm following up on this too soon..

Just curious as to whether or not anyone else has reviewed the patch I
submitted for 2.7's buffer docs. After reading through the docs and
digging through the implementation, I thought that the docs as they
were could have used a little rework, mostly reorganization for
consistency, but some new content was added as well.

http://bugs.python.org/issue17145

Thanks,

--
Demian Brecht
http://demianbrecht.github.com

From HBock at zebra.com  Wed Feb 27 16:35:16 2013
From: HBock at zebra.com (Bock, Harry)
Date: Wed, 27 Feb 2013 15:35:16 -0000
Subject: [docs] Invalid link in "SystemExit" documentation (2.x, Section 6)
Message-ID: <345A300EFDE6A344AD4F35DBC5E1AC8BE7C9A90A99@03S08EXMB01.zebra.lan>

Hi,

I stumbled upon a bug in the "SystemExit" exception documentation for Python 2.x:
http://docs.python.org/2/library/exceptions.html#exceptions.SystemExit

The line "Instances have an attribute code" has a reference to the "code" module:
http://docs.python.org/2/library/code.html#module-code

Which is not what the SystemExit attribute is referring to.  The cross-reference should be removed, and no other change is needed. The documentation explains the attribute well.

Thanks for the great documentation!  Keep up the great work.

[cid:image001.gif at 01CE14D1.DB643160]

Harry Bock
Firmware Test Engineer
ZEBRA TECHNOLOGIES CORPORATION

1 Albion Road
Suite 100
Lincoln, RI 02865-3703
T: +1 401 276 5720
hbock at zebra.com
www.zebra.com<http://www.zebra.com/>





________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130227/59968a12/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 2901 bytes
Desc: image001.gif
URL: <http://mail.python.org/pipermail/docs/attachments/20130227/59968a12/attachment-0001.gif>

From qar at outlook.com  Wed Feb 20 14:24:42 2013
From: qar at outlook.com (=?gb2312?B?hsywssi7?=)
Date: Wed, 20 Feb 2013 13:24:42 -0000
Subject: [docs] document bug report
Message-ID: <BLU002-W1664C00D17252D275271A86BEF60@phx.gbl>

http://docs.python.org/2/library/datetime.html

In python 2.7 datetime module document section 8.1.3 date Objects 
The date object supported operations table, row 1 column 2:
date2 is timedelta.days days removed from date1.
I consider that the word removed should be replaced with moved.





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

From lev.levitsky at phystech.edu  Wed Feb  6 19:23:18 2013
From: lev.levitsky at phystech.edu (Lev Levitsky)
Date: Wed, 06 Feb 2013 18:23:18 -0000
Subject: [docs] Typo in threading.Thread.join docstring
Message-ID: <CAPbZ3gDTumUY8h+6h7t5kMXU0NG419Nz9duMCK9x+6pu0mCSFw@mail.gmail.com>

Hello,

this is super minor, but:

in the doc for threading.Thread.join<http://docs.python.org/library/threading.html#threading.Thread.join>
there
is a typo/grammatical mistake:

It is also an error to
join()<http://docs.python.org/2/library/threading.html#threading.Thread.join>
a
thread before it has been started and *attempts to do so raises* the same
exception.

Best regards,
Lev

-- 
Lev Levitsky
Institute for Energy Problems of Chemical Physics RAS
Laboratory of Physical and Chemical Methods for Structure Analysis
Leninsky pr. 38, bld. 2 119334 Moscow Russia
tel: +7 499 1378257 fax: +7 499 1378257, +7 499 1378258
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130206/ce9f60cc/attachment-0001.html>

From pierpa63 at gmail.com  Mon Feb 11 17:30:26 2013
From: pierpa63 at gmail.com (Pierpaolo Anselmetti)
Date: Mon, 11 Feb 2013 16:30:26 -0000
Subject: [docs] May be a doc mispelling
Message-ID: <CADPu_QyM7QupwCFsA_ZRqANiSP0auqYdqjkWSz79G9Lps15CfA@mail.gmail.com>

Hi,
I'm quite new to Python, so I am not sure, but I think there is a trivial
mispelling in:

http://docs.python.org/3.3/library/random.html#module-random

where

random.randint(*a*,
*b*)<http://docs.python.org/3.3/library/random.html#random.randint>

Return a random integer *N* such that a <= N <= b. Alias for randrange(a,
b+1)

should be


random.randint(*a*,
*b*)<http://docs.python.org/3.3/library/random.html#random.randint>

Return a random integer *N* such that a <= N <= b. Alias for randrange(a, *b,
1)*

Hope this helps, otherwise forgive me for this mail.


Pierpaolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130211/720ff72d/attachment-0001.html>

From michel.samia at firma.seznam.cz  Thu Feb 14 13:40:21 2013
From: michel.samia at firma.seznam.cz (Michel Samia)
Date: Thu, 14 Feb 2013 12:40:21 -0000
Subject: [docs] Array documentation: deprecated link
Message-ID: <511CDAF1.7010203@firma.seznam.cz>

Hi folks,

I found a deprecated link at this page 
http://docs.python.org/2.6/library/array.html In the yellow box at the 
bottom, the link http://numpy.sourceforge.net/ no more exists.

Fix it please to keep Python one of best-documented projects ever :)
Thanks, Michel

From krnoha at gmail.com  Fri Feb 15 11:44:27 2013
From: krnoha at gmail.com (Michal Kratky)
Date: Fri, 15 Feb 2013 10:44:27 -0000
Subject: [docs] python 2.7.3 module re bug
Message-ID: <CADjUJcTQnQCXpe86PaZ6K1zSDiBthzLrkPkkw-W4chwWsB_idw@mail.gmail.com>

Hi,

I use python 2.7.3 which is distributed as a part of Cygwin. I think
there is a bug in the function re.sub() .
Supose I want to escape each of the chars a b c with two backslashes. I write

>>> re.sub( "([abc])" , "\\\\\\1" , "haf")
'h\\af'

This is fine. But when I try to insert just one backslash I am getting

>>> re.sub( "([abc])" , "\\\\1" , "haf")
'h\\1f'

\1 was not interpreted.


Regards Michael Kratky
             Czech Hydrometeorogical Inst.
             Prague

From kankyou_move at hotmail.com  Fri Feb 22 05:47:00 2013
From: kankyou_move at hotmail.com (K MOVE)
Date: Fri, 22 Feb 2013 04:47:00 -0000
Subject: [docs] Broken link
Message-ID: <BAY167-W29224E0289D09C4F768EFBEDF00@phx.gbl>


Python Advocacy HOWTO#Useful Resources
 http://www.pythonology.com/success 
under
Python v2.7.2 documentation>>Python HOWTOs
return: Error 404: File Not Found. 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130222/29c4587f/attachment-0001.html>

From porterleete at gmail.com  Sat Feb 23 19:25:11 2013
From: porterleete at gmail.com (porter leete)
Date: Sat, 23 Feb 2013 18:25:11 -0000
Subject: [docs] Language Reference mentions non-existent section
Message-ID: <CAG0-QA22hzYam5m1wh3jjw_c0+a2D+4=0hNQQLE1b8_u38kvWQ@mail.gmail.com>

In section 3.2 of the Python Language Reference, under the class methods
header it says:

The behaviour of class method objects upon such retrieval is described
above, under *?User-defined methods?*.

There is no header titled "User-defined methods". It should read *"Instance
Methods"*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130223/c0ca2fa9/attachment-0001.html>

From porterleete at gmail.com  Sat Feb 23 19:28:29 2013
From: porterleete at gmail.com (porter leete)
Date: Sat, 23 Feb 2013 18:28:29 -0000
Subject: [docs] Unclear writing
Message-ID: <CAG0-QA0GsNpJUmxiQ-DWn4VHkyvF37iQmNTjZgde1s54VG_bvg@mail.gmail.com>

In the Python Language Reference section 3.2 , under "Instance Methods", it
reads:

"An instance method object combines a class,* a class instance *and any
callable object (normally a user-defined function)."
Later, it says:
"When a user-defined method object is *created by retrieving another method
object from a class *or instance, the behaviour is the same as for a
function object, except that the __func__ attribute of the new instance is
not the original method object but its __func__ attribute."
and
" When an instance method object is* created by retrieving a class method
object from a class* or instance, its __self__ attribute is the class
itself, and its __func__ attribute is the function object underlying the
class method"

This raises the question, is it possible to create an instance method
without any mention of a class instance? If an instance method is "created
by retrieving another method object from a class*", *then where does the
class instance come into play?* *Is it that the class instance is only
required when retrieving a user-defined function object from a class? If
not, where does the class instance come from? Perhaps I'm missing some
obvious context, but the meaning of this seems quite unclear to me.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130223/f96c4522/attachment-0001.html>

From jscatena88 at gmail.com  Tue Feb 26 23:48:44 2013
From: jscatena88 at gmail.com (Jason Scatena)
Date: Tue, 26 Feb 2013 22:48:44 -0000
Subject: [docs] Error in "The Python Tutorial"
Message-ID: <CANvVAoyN9ewWifeULdR_s947WCH4G0JmnYqGeG5dimj495KVLQ@mail.gmail.com>

To Whom it May Concern,
Under the tutorial section "3.1.1 Numbers" I believe there is an error in
the code example block. It shows:

>>> 2+24>>> # This is a comment... 2+24>>> 2+2  # and a comment on the same line as code4>>> (50-5*6)/45>>> # Integer division returns the floor:... 7/32>>> 7/-3-3

Should it not show a double forward slash for the integer division. This is
the results of me trying the code example(copied and pasted directly from
bash):
>>> 7/3
2.3333333333333335
>>> 7//3
2
>>> 7/-3
-2.3333333333333335
>>> 7//-3
-3


Regards,
-Jason Scatena
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130226/7fb82baa/attachment-0001.html>

From jscatena88 at gmail.com  Wed Feb 27 00:13:39 2013
From: jscatena88 at gmail.com (Jason Scatena)
Date: Tue, 26 Feb 2013 23:13:39 -0000
Subject: [docs] Error in "The Python Tutorial"
In-Reply-To: <CANvVAoyN9ewWifeULdR_s947WCH4G0JmnYqGeG5dimj495KVLQ@mail.gmail.com>
References: <CANvVAoyN9ewWifeULdR_s947WCH4G0JmnYqGeG5dimj495KVLQ@mail.gmail.com>
Message-ID: <CANvVAowFkw3gE5YYxnMvzejx0awXkzwDYkBFDRQfsyt-c=6hGQ@mail.gmail.com>

Nevermind I now realize i was looking at the python 2.x documentation not
the python 3 documentation. Scratch my last email.

-Jason Scatena

On Tue, Feb 26, 2013 at 5:48 PM, Jason Scatena <jscatena88 at gmail.com> wrote:

> To Whom it May Concern,
> Under the tutorial section "3.1.1 Numbers" I believe there is an error in
> the code example block. It shows:
>
> >>> 2+24>>> # This is a comment... 2+24>>> 2+2  # and a comment on the same line as code4>>> (50-5*6)/45>>> # Integer division returns the floor:... 7/32>>> 7/-3-3
>
> Should it not show a double forward slash for the integer division. This
> is the results of me trying the code example(copied and pasted directly
> from bash):
> >>> 7/3
> 2.3333333333333335
> >>> 7//3
> 2
> >>> 7/-3
> -2.3333333333333335
> >>> 7//-3
> -3
>
>
> Regards,
> -Jason Scatena
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20130226/83edcf42/attachment-0001.html>