From report at bugs.python.org  Mon Aug  1 00:47:58 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 31 Jul 2011 22:47:58 +0000
Subject: [docs] [issue12670] Fix struct code after forward declaration on
	ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/004974.html here's a patch (applicable on 2.7, 3.2 and 3.3) to fix the struct declaration in the "forward declaration" example.

----------
assignee: docs at python
components: Documentation
files: ctypes_fwd_declaration-default.patch
keywords: patch
messages: 141480
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Fix struct code after forward declaration on ctypes doc
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22814/ctypes_fwd_declaration-default.patch

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

From sandro.tosi at gmail.com  Mon Aug  1 00:48:49 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 1 Aug 2011 00:48:49 +0200
Subject: [docs] C code wrong after forward declaration
In-Reply-To: <CAO1Q+je5NX4VEeAtxa-OmLMCTP_pX2GtHAmKCYTn66zefo5iow@mail.gmail.com>
References: <CAO1Q+je5NX4VEeAtxa-OmLMCTP_pX2GtHAmKCYTn66zefo5iow@mail.gmail.com>
Message-ID: <CAPdtAj3e_Lx_ppyW1zZX0-_tBp8XitC1LBkeusFMQBrNjdW5_A@mail.gmail.com>

Hello Albert,

On Tue, Jul 12, 2011 at 02:03, Albert Zeyer <albert.zeyer at rwth-aachen.de> wrote:
> struct cell; /* forward declaration */
>
> struct cell {
> ? ?char *name;
> ? ?struct cell *next;
> };
>

thanks for spotting it! I've just filed
http://bugs.python.org/issue12670 to fix it.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Aug  1 02:01:25 2011
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Aug 2011 00:01:25 +0000
Subject: [docs] [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312156884.94.0.660499732332.issue12648@psf.upfronthosting.co.za>


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

As far as I know, not as a top-level module in an installed version of Python (at least, not without mucking about in the registry).

Shadowing standard library modules is generally a bad idea, and this is one of the reasons.

----------

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

From report at bugs.python.org  Mon Aug  1 04:38:42 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Aug 2011 02:38:42 +0000
Subject: [docs] [issue12668] 3.2 What's New: it's integer->string,
	not the opposite
In-Reply-To: <1312147179.72.0.252519921224.issue12668@psf.upfronthosting.co.za>
Message-ID: <1312166322.11.0.603657166919.issue12668@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug  1 05:54:54 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 01 Aug 2011 03:54:54 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

Reading the C API documentation: extending/newtypes.html

Some problems:

1. In the first paragraph of 2.1 - "to distinguish them from things like [].append", it's unclear what [].append is. Maybe "[] and append"?
2. The C coding convention is unusual and non PEP-7 in 2.1.1 (after "if (self->first == NULL)" in Noddy_new)
3. The previous problem repeats in other instances of Noddy_new in the document


I found these while reading the 2.7 docs, but they could also exist in 3.x (didn't check).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141487
nosy: docs at python, eli.bendersky
priority: low
severity: normal
status: open
title: Some problems in documentation extending/newtypes.html
versions: Python 2.7

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

From remcoj at xs4all.nl  Mon Aug  1 05:17:28 2011
From: remcoj at xs4all.nl (remcoj)
Date: Mon, 01 Aug 2011 11:17:28 +0800
Subject: [docs] Broken link in Python 2.7.2 Tutorial
In-Reply-To: <CAPdtAj0UroQBgHgdWYSRjQQXgPiEdF4+XP761+jEwFs+Y7H45A@mail.gmail.com>
References: <201106260840.31807.remcoj@xs4all.nl>
	<CAPdtAj0UroQBgHgdWYSRjQQXgPiEdF4+XP761+jEwFs+Y7H45A@mail.gmail.com>
Message-ID: <26f8449a99134f13e5d79a2ca5dc88b9@xs4all.nl>

On Sun, 31 Jul 2011 23:30:53 +0200, Sandro Tosi wrote:
> Hello,
> thanks for your email.
>
> On Sun, Jun 26, 2011 at 02:40, Remco Janssen <remcoj at xs4all.nl> 
> wrote:
>> It seems the 'next' links on top and bottom of the '1. Whetting Your 
>> Appetite'
>> page in the Python Tutorial 
>> (http://docs.python.org/tutorial/appetite.html)
>> are broken.
>
> I'm not seeing this behavior right now, can you confirm it's gone?
>
> Regards,

Hi Sandro,

thanks for your reply. The behavior manifested itself shortly after the 
2.7.2 docs were uploaded.
Probably it was a temporary glitch, caused by the uploading of the new 
pages. It does not occur anymore.

Regards,
Remco

From report at bugs.python.org  Mon Aug  1 08:30:25 2011
From: report at bugs.python.org (kota)
Date: Mon, 01 Aug 2011 06:30:25 +0000
Subject: [docs] [issue12648] Wrong import module search order on Windows
In-Reply-To: <1311846003.79.0.904743673634.issue12648@psf.upfronthosting.co.za>
Message-ID: <1312180225.82.0.960530415846.issue12648@psf.upfronthosting.co.za>


kota <nospam.kotarou.dono at gmail.com> added the comment:

Ok. Time to get those people over at glib to fix up their python script then :)

----------

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

From report at bugs.python.org  Mon Aug  1 08:46:31 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Mon, 01 Aug 2011 06:46:31 +0000
Subject: [docs] [issue12631] Mutable Sequence Type in .remove() is
	consistent only	with lists, but not with bytearrays
In-Reply-To: <1311553590.08.0.463284730319.issue12631@psf.upfronthosting.co.za>
Message-ID: <1312181191.53.0.960413344666.issue12631@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
status: open -> closed

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

From sandro.tosi at gmail.com  Mon Aug  1 09:45:52 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 1 Aug 2011 09:45:52 +0200
Subject: [docs] Python-2.3.3/pdf/ref.pdf
In-Reply-To: <CAB7OhvxONoATXFP9nK+7uwjLiXbxN_ga1vV4b-P2tuynfmfz4Q@mail.gmail.com>
References: <CAB7OhvxONoATXFP9nK+7uwjLiXbxN_ga1vV4b-P2tuynfmfz4Q@mail.gmail.com>
Message-ID: <CAPdtAj1h3LvXPaQaG+u7RZJt6wAVuCEeniXumsJ0f7QpttOLOw@mail.gmail.com>

Hello,

On Sun, Jul 31, 2011 at 23:31, t4C+Cq <t4chacko+cq at gmail.com> wrote:
> http://www.compsci.wm.edu/SciClone/documentation/software/compilers/Python-2.3.3/pdf/ref.pdf
> Hi,
> I understand the url above is not yours, but the content is. ?The above pdf
> has an unsual repeating error in that all occurances 'fi' even within the
> middle of a word has become blank! ?I wonder why that occurred?

2.3.3 is a really old release and you should not use it (unless
forced, of course) or refer to its documentation. The latest Python
releases can be found here: http://python.org/download/

> In any case, can you refer me to another availabe pdf versrion of your
> python documentation online?

Probably the best place (and the canonical one) is the one from the
official python website: http://docs.python.org/ for 2.7 and
http://docs.python.org/py3k/ for the current 3.x release.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Mon Aug  1 11:20:22 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 1 Aug 2011 11:20:22 +0200
Subject: [docs] How to start IDLE?
In-Reply-To: <201107302340.33204.giecrilj@stegny.2a.pl>
References: <201107302340.33204.giecrilj@stegny.2a.pl>
Message-ID: <CAPdtAj2b_p_ABXeivL8afdA8QFVbPvZsdGE_uZ3DmySYrLaLAg@mail.gmail.com>

On Sat, Jul 30, 2011 at 23:40, K?i?tof ?elechovski
<giecrilj at stegny.2a.pl> wrote:
> The section 24.5.4.1. "Command line usage" says:
>
>> idle.py [-c command] [-d] [-e] [-s] [-t title] [arg] ...
>
> There is no ?idle.py?, the command is ?idle?.

Well, it's not completely right: in the standard library there's the
'idlelib' that contains the scripts idle.py . At installation time, it
can be renamed, or symliked to a different filename, but idle.py
exists.

>> If the script name is ?-?, no script is executed but an interactive Python session is started; the arguments are still available in sys.argv.
>
> { idle -; } waits for standard input.

exactly, an interactive session :) you can write python commands in
the stdin and then press ctrl-d and have idle executing them, showing
the output; f.e.: echo "import sys; print sys.argv" | idle - "foobar"

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Mon Aug  1 11:40:25 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 1 Aug 2011 11:40:25 +0200
Subject: [docs] Up arrow functionality, Previous input
In-Reply-To: <CABK4Q1BwXuZPA7ue9sVNokKrTgnX_SC+AJzWZEujkgGU2Ku4mQ@mail.gmail.com>
References: <CABK4Q1Ckb09Rayh5LX4=Oh2Sx+XO2=W7T-Cxs=Nb-nV47gn4oA@mail.gmail.com>
	<CAPdtAj1xJ4xDhmWsuR_xutT36Znm5hDJFyw9c7-HyYxXz9EDiA@mail.gmail.com>
	<CABK4Q1BwXuZPA7ue9sVNokKrTgnX_SC+AJzWZEujkgGU2Ku4mQ@mail.gmail.com>
Message-ID: <CAPdtAj2X-ANEG07nwY9WYjs67xCmc98JViX=3W2jD+YmEE3ovg@mail.gmail.com>

On Mon, Aug 1, 2011 at 11:32, Thanh Vu <thavu at ucdavis.edu> wrote:
> My apologies, but this link wasn't very useful. It involves having to
> subscribe to a feed listserv which for just one question, and that
> doesn't seem like it's feasible. Is there a shortcuts list somewhere
> in the documentation, because I couldn't find it.

No, it's not required to subscribe to the list (it's a possibility)
what you have to do it "To post a message to all the list members,
send email to python-list at python.org." so write an email asking for
information to that email address.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Aug  1 12:33:11 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Aug 2011 10:33:11 +0000
Subject: [docs] [issue12667] Better logging.handler.SMTPHandler doc for
	'secure'	argument
In-Reply-To: <1312135278.74.0.984312174238.issue12667@psf.upfronthosting.co.za>
Message-ID: <E1Qnpo4-00044e-As@dinsdale.python.org>


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

New changeset 42f40f53fd73 by Vinay Sajip in branch '2.7':
Closes #12667: Corrected documentation for SMTPHandler secure argument.
http://hg.python.org/cpython/rev/42f40f53fd73

New changeset ba5bd8c1ae27 by Vinay Sajip in branch '3.2':
Closes #12667: Added documentation for SMTPHandler secure argument.
http://hg.python.org/cpython/rev/ba5bd8c1ae27

New changeset 2d69900c0820 by Vinay Sajip in branch 'default':
Closes #12667: Merged fix from 3.2.
http://hg.python.org/cpython/rev/2d69900c0820

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

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

From report at bugs.python.org  Mon Aug  1 15:33:21 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Aug 2011 13:33:21 +0000
Subject: [docs] [issue12436] Missing items in installation/setup instructions
In-Reply-To: <1309305395.29.0.101516779086.issue12436@psf.upfronthosting.co.za>
Message-ID: <1312205601.72.0.981616972386.issue12436@psf.upfronthosting.co.za>


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

I propose that we just narrow the scope of this report.  If you agree with my earlier message, the current docs just need a few patches:

- How to prepare a text editor
- How to run Python code from a file (if the tutorial or using docs don?t already have it).

It would also be nice to have feedback from beginners about our tutorial and using docs: Are they comprehensive and easy to find?

----------
keywords: +easy
status: pending -> open
title: Provide reference to detailed installation instructions -> Missing items in installation/setup instructions
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Aug  1 15:37:49 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 01 Aug 2011 13:37:49 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello, following up http://mail.python.org/pipermail/docs/2011-July/005235.html here's 2 patch (for 3.3 + 3.2 and 2.7) to correct the orientation in the documentation, using turtle.right instead of turtle.left, since the work 'counterclockwise' (even if correct and already used) might be "too heavy". I don't think the sense of the introductory part is voided with the change in the method name instead of fixing what it does.

----------
assignee: docs at python
components: Documentation
files: turtle_right-default.patch
keywords: patch
messages: 141511
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Turtle, fix right/left rotation orientation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22818/turtle_right-default.patch

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

From report at bugs.python.org  Mon Aug  1 15:38:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 01 Aug 2011 13:38:12 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312205892.91.0.0171347733168.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22819/turtle_right-2.7.patch

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

From sandro.tosi at gmail.com  Mon Aug  1 15:39:18 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 1 Aug 2011 15:39:18 +0200
Subject: [docs] Turtle docs
In-Reply-To: <982AB0587FC89F42AB7350C61728A83F1BA8E9@hoosier1.htdteam.local>
References: <982AB0587FC89F42AB7350C61728A83F1BA8E9@hoosier1.htdteam.local>
Message-ID: <CAPdtAj3RBpkpNq7mEzaaJuAcJshbP02MyyzVYPascxB4ODr01g@mail.gmail.com>

Hello Michael,
thanks for your report!

On Wed, Jul 27, 2011 at 21:40, Michael L. Clapp <mlclapp at htdteam.com> wrote:
> Just a small thing. On your web page:
> http://docs.python.org/py3k/library/turtle.html, at about the 4th line down
> it is stated ?Give it the command?turtle.left(25), and it rotates in-place
> 25 degrees clockwise.? That statement needs to be corrected to either say
> ?Give it the command?turtle.right (25), and it rotates in-place 25 degrees
> clockwise.? or? Give it the command?turtle.left(25), and it rotates in-place
> 25 degrees counterclockwise.?

I've just filed http://bugs.python.org/issue12677 to fix it.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Tue Aug  2 00:04:03 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 01 Aug 2011 22:04:03 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312236243.19.0.0597311919996.issue12666@psf.upfronthosting.co.za>


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

I've created a patch to address (1) and (2).

Is there any value in also including this in the 2to3 fixer? I can see that it's a simple translation, but adds complexity to the converted code. I'd be content to go with just a documentation patch. I'll defer to Benjamin or his delegate on whether or not to update 2to3.

----------
hgrepos: +50
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Aug  2 12:53:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:53:23 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoCbB-0002Cz-OI@dinsdale.python.org>


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

New changeset 209ad8920b03 by Senthil Kumaran in branch '2.7':
Fix closes Issue12183 - Explain the Symlink copy behavior in shutil.copytree. Patch by Petri Lehtinen.
http://hg.python.org/cpython/rev/209ad8920b03

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

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

From report at bugs.python.org  Tue Aug  2 12:55:23 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 10:55:23 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoCd8-0002P3-Ej@dinsdale.python.org>


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

New changeset 299992730c87 by Senthil Kumaran in branch '3.2':
Fix closes Issue12183 - Explain the Symlink copy behavior in shutil.copytree. Patch by Petri Lehtinen.
http://hg.python.org/cpython/rev/299992730c87

----------

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

From report at bugs.python.org  Tue Aug  2 12:57:13 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 10:57:13 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1312282633.01.0.810915039861.issue12183@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Petri, Thanks for the patch. It would also be helpful to track -  "shutil.copytree() use lutimes in Python 3.3 to copy symlink metadata if symlinks=True". You can raise a feature request if it is not already raised. Thanks!.

----------

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

From report at bugs.python.org  Tue Aug  2 16:42:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 14:42:40 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <E1QoGB5-00078X-5i@dinsdale.python.org>


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

New changeset 746dc0a2398e by Ezio Melotti in branch 'default':
#12183: merge with 3.2.
http://hg.python.org/cpython/rev/746dc0a2398e

----------

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

From report at bugs.python.org  Tue Aug  2 16:47:58 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 14:47:58 +0000
Subject: [docs] [issue12670] Fix struct code after forward declaration on
	ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <E1QoGGC-0007iu-KM@dinsdale.python.org>


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

New changeset 2aa8dd4df650 by Sandro Tosi in branch '2.7':
#12670: Fix struct code after forward declaration on ctypes doc
http://hg.python.org/cpython/rev/2aa8dd4df650

New changeset 25dd1d3f4b88 by Sandro Tosi in branch '3.2':
#12670: Fix struct code after forward declaration on ctypes doc
http://hg.python.org/cpython/rev/25dd1d3f4b88

New changeset 01192d30365a by Sandro Tosi in branch 'default':
#12670: merge with 3.2
http://hg.python.org/cpython/rev/01192d30365a

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

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

From report at bugs.python.org  Tue Aug  2 16:50:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 14:50:09 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <E1QoGB5-00078X-5i@dinsdale.python.org>
Message-ID: <20110802144955.GA2980@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Ezio,

It was intentional that I did not merge it to default. We want
shutil.copystat to use lutimes which is available in 3.3 and in which
case, we will have to remove this once that change is done.

----------

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

From report at bugs.python.org  Tue Aug  2 16:52:17 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Aug 2011 14:52:17 +0000
Subject: [docs] [issue12183] Document behaviour of shutil.copy2 and copystat
	with	symlinks
In-Reply-To: <1306384920.41.0.626033537775.issue12183@psf.upfronthosting.co.za>
Message-ID: <1312296736.85.0.506919518952.issue12183@psf.upfronthosting.co.za>


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

I applied it because the patch is valid on 3.3 too until we actually change copystat to use lutimes.  If/when shutil is changed the doc can be updated accordingly.

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

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

From report at bugs.python.org  Tue Aug  2 16:57:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 02 Aug 2011 14:57:22 +0000
Subject: [docs] [issue12670] Fix struct code after forward declaration on
	ctypes doc
In-Reply-To: <1312152478.75.0.485993902347.issue12670@psf.upfronthosting.co.za>
Message-ID: <1312297042.1.0.107143029028.issue12670@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  2 17:07:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Aug 2011 15:07:12 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

The devguide documents the 'accepted' resolution as follows:

     Submitted patch was applied, still needs verifying (for example by
     watching the buildbots) that everything went fine. At that point the
     resolution should be set to fixed and the status changed to closed.

I've never run into this usage while working with the tracker.  I *have* seen people set 'accepted' when they want to indicate that the issue is considered valid to be fixed, or that a feature request has been accepted but there's no patch ready for commit yet.

Formally I believe that the 'accepted' resolution is for committed feature requests (since "fixed" doesn't make English sense in that context).  Any other use is creative license :)

----------
assignee: docs at python
components: Documentation
messages: 141568
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Meaning of 'accepted' resolution as documented in devguide

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

From report at bugs.python.org  Tue Aug  2 17:12:55 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Aug 2011 15:12:55 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312297975.14.0.941206176894.issue12682@psf.upfronthosting.co.za>


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


----------
components: +Devguide -Documentation
nosy: +ezio.melotti
resolution:  -> accepted
stage:  -> needs patch

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

From report at bugs.python.org  Tue Aug  2 18:11:21 2011
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 02 Aug 2011 16:11:21 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312301481.27.0.632190621399.issue12682@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


----------
nosy: +stutzbach

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

From report at bugs.python.org  Tue Aug  2 18:32:16 2011
From: report at bugs.python.org (Ross Lagerwall)
Date: Tue, 02 Aug 2011 16:32:16 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312302736.51.0.00268838021513.issue12682@psf.upfronthosting.co.za>


Ross Lagerwall <rosslagerwall at gmail.com> added the comment:

> Formally I believe that the 'accepted' resolution is for committed feature requests

That's what I also thought originally.

Perhaps this should be discussed on Python-Dev to see what people think it should mean?

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

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

From report at bugs.python.org  Tue Aug  2 18:44:57 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 16:44:57 +0000
Subject: [docs] [issue12665] Dictionary view example has error in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <E1QoI5P-0002Ck-Fc@dinsdale.python.org>


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

New changeset a70cdec027e7 by Sandro Tosi in branch '3.2':
#12665: Dictionary view example has error in set operation
http://hg.python.org/cpython/rev/a70cdec027e7

New changeset b2dc821058fe by Sandro Tosi in branch 'default':
#12665: merge with 3.2
http://hg.python.org/cpython/rev/b2dc821058fe

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

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

From report at bugs.python.org  Tue Aug  2 18:47:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 02 Aug 2011 16:47:57 +0000
Subject: [docs] [issue12665] Dictionary view example has error in set ops
In-Reply-To: <1312124912.45.0.454246287313.issue12665@psf.upfronthosting.co.za>
Message-ID: <1312303677.92.0.756239053284.issue12665@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug  2 22:26:53 2011
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Aug 2011 20:26:53 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I say just  go ahead and change  it. I was probably just thinking how I wish we would use it when I wrote that.

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

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

From report at bugs.python.org  Wed Aug  3 01:45:08 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Aug 2011 23:45:08 +0000
Subject: [docs] [issue12663] ArgumentParser.error writes to stderr not to
	stdout
In-Reply-To: <1312122837.61.0.0244813637126.issue12663@psf.upfronthosting.co.za>
Message-ID: <E1QoOe2-0004f2-J4@dinsdale.python.org>


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

New changeset 5ff56995976c by Senthil Kumaran in branch '3.2':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/5ff56995976c

New changeset a5b3d5051fc7 by Senthil Kumaran in branch 'default':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/a5b3d5051fc7

New changeset 1e8dc34ece30 by Senthil Kumaran in branch '2.7':
Fix closes issue12663 - Correcting the ArgumentParser.error description. Patch by Sandro Tosi.
http://hg.python.org/cpython/rev/1e8dc34ece30

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

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

From report at bugs.python.org  Wed Aug  3 01:49:08 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 02 Aug 2011 23:49:08 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312316813.53.0.0637663512554.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110802234859.GA2542@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I propose that we remove 'accepted' as the meaning seems ambiguous and
it is of little practical (/tracking) use.

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

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

From report at bugs.python.org  Wed Aug  3 02:08:19 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Aug 2011 00:08:19 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205892.87.0.0529000411924.issue12677@psf.upfronthosting.co.za>
Message-ID: <20110803000809.GB2542@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

The orientation depends upon the mode, which is explained further
down.
http://docs.python.org/py3k/library/turtle.html#turtle.left

So, the correct fix would be: 
"would turn clockwise/counterclockwise depending upon the mode."

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

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

From report at bugs.python.org  Wed Aug  3 02:26:34 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Aug 2011 00:26:34 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312331194.62.0.608387422364.issue12682@psf.upfronthosting.co.za>


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

It is not ambigous.  As I said, bugs are fixed, feature requests are accepted.

----------

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

From report at bugs.python.org  Wed Aug  3 03:15:09 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 03 Aug 2011 01:15:09 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312334109.0.0.127984307373.issue12682@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I thought "fixed" was enough. A kind of binary state where we say, okay we have it and otherwise no, we don't. I know for feature requests the terminology does not make sense, but I believe I have worked with bug trackers where fixed was the ultimate state where a particular change (be a bug-fix or a feature request) was in the code.

Well, as long as it is helpful, I am fine with it, but too many options can confuse (just as 'accepted' did) and it will be helpful to prune down some.

----------
resolution: accepted -> 

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

From report at bugs.python.org  Wed Aug  3 07:31:54 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 03 Aug 2011 05:31:54 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312349514.27.0.251446599681.issue12682@psf.upfronthosting.co.za>


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

The "Accepted" Resolution was copied from SF. I recall seeing documentation on SF for the resolutions, but can't find that anymore.

I also recall that on SF, the "accepted" resolution was used to indicate that a patch was accepted (be it a bug fix or a feature request), and also in combination with the "open" status (in the sense of an "approved" resolution, also).

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

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

From report at bugs.python.org  Wed Aug  3 08:08:14 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 03 Aug 2011 06:08:14 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312351694.1.0.365298163871.issue12682@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


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

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

From report at bugs.python.org  Wed Aug  3 14:30:59 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Aug 2011 12:30:59 +0000
Subject: [docs] [issue12686] argparse - document (and improve?) use of
	SUPPRESS with	help=
In-Reply-To: <1312356221.08.0.599664751964.issue12686@psf.upfronthosting.co.za>
Message-ID: <1312374659.32.0.188289132073.issue12686@psf.upfronthosting.co.za>


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

This is partly a doc issue, but there also appear to be bugs in the way the existing functionality works (although it is hard to tell for sure since it isn't documented :)

Try using the value argparse.SUPPRESS as the value of help= in various places and you'll see what I mean.

----------
assignee:  -> docs at python
components: +Documentation, Library (Lib) -None
keywords: +easy
nosy: +bethard, docs at python, r.david.murray
stage:  -> needs patch
title: argparse - add 'hide' feature -> argparse - document (and improve?) use of SUPPRESS with help=
versions: +Python 3.3

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

From report at bugs.python.org  Wed Aug  3 14:58:51 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Aug 2011 12:58:51 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312376331.82.0.429815402498.issue12677@psf.upfronthosting.co.za>


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

It seems to me that right() always turns the turtle clockwise, both with the "standard" and the "logo" mode.
I agree that changing left->right and leave clockwise is better than changing clockwise->counterclockwise.
I don't think it's worth mentioning the mode here.
(On a side note: I was expecting the 'turtle' to be an instance of some Turtle class defined in the turtle module, or perhaps a singleton, but it turned out that in 'turtle.right()' turtle is the module itself.  It might be better to say something like "After importing the :mod:`turtle` module, ...".)

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

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

From report at bugs.python.org  Thu Aug  4 15:51:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 13:51:39 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312465899.52.0.650896425535.issue12677@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

As mentioned by Ezio, and I also verified myself, mode() doesn't influence the orientation on left()/right() methods (probably it affects some other functs?). Following was Ezio and I discussed on IRC, I've updated the 2 patches to add a small note that you have to import turtle before trying the mentioned commands.

----------
Added file: http://bugs.python.org/file22834/turtle_right-default-v2.patch

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

From report at bugs.python.org  Thu Aug  4 15:51:50 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Aug 2011 13:51:50 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312465910.25.0.564944815982.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Added file: http://bugs.python.org/file22835/turtle_right-2.7-v2.patch

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

From report at bugs.python.org  Fri Aug  5 18:29:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:29:34 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312561773.92.0.40429463775.issue12666@psf.upfronthosting.co.za>


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

(HTTPS repos are not supported)

----------
hgrepos: +51
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Aug  5 18:30:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Aug 2011 16:30:10 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312561810.64.0.11853642854.issue12666@psf.upfronthosting.co.za>


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

Can you provide a public URI?

----------

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

From report at bugs.python.org  Fri Aug  5 18:33:46 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:33:46 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562026.2.0.690246508375.issue12666@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  5 18:35:00 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:35:00 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562100.8.0.0554563004169.issue12666@psf.upfronthosting.co.za>


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

I don't know how that repo got to be private; I created it just like every other public repo I have, and I thought I was only allowed one private repo (this was my second). In any case, I updated the setting, and now it appears to be accessible via the bug tracker.

----------

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

From report at bugs.python.org  Fri Aug  5 18:39:04 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 05 Aug 2011 16:39:04 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312562344.42.0.745926304197.issue12666@psf.upfronthosting.co.za>


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

I'm not sure how the bugtracker patch mechanism works, but the patch it produced included a lot of changes that I didn't make (changesets already committed to the master repo).

----------
keywords:  -patch

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

From report at bugs.python.org  Fri Aug  5 21:00:18 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Aug 2011 19:00:18 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312570818.58.0.378739613656.issue12666@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  5 21:44:04 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 19:44:04 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312573444.79.0.481702640488.issue12666@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  5 22:00:46 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Aug 2011 20:00:46 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312574446.4.0.119173467739.issue12682@psf.upfronthosting.co.za>


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

Adding a feature 'fixes' the deficiency of its absence. I personally have no use for 'accepted' and find it ambiguous. My best understanding is what David has seen (accepted in principle).

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

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

From report at bugs.python.org  Sat Aug  6 01:03:29 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 23:03:29 +0000
Subject: [docs] [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <1312585409.06.0.166279271437.issue11047@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello, the patch seems indeed to fix a "reverse" description of issue 7902. Was there a reason (given the quite long list of nosy people) why it was not applied? "lack of time" doesn't count :)

----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> commit review
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug  6 01:59:31 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 05 Aug 2011 23:59:31 +0000
Subject: [docs] [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <1312588771.23.0.0481319298586.issue11481@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

A quick reword could be the one attached.

----------
keywords: +patch
nosy: +ezio.melotti, sandro.tosi
stage:  -> patch review
versions: +Python 2.7 -Python 3.1
Added file: http://bugs.python.org/file22843/issue11481.patch

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

From report at bugs.python.org  Sat Aug  6 06:56:40 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Aug 2011 04:56:40 +0000
Subject: [docs] [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1296233608.02.0.630598474753.issue11047@psf.upfronthosting.co.za>
Message-ID: <E1QpYw5-0003L6-Hj@dinsdale.python.org>


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

New changeset 298df0970eec by Senthil Kumaran in branch '2.7':
Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/298df0970eec

New changeset dafdbd0d570a by Senthil Kumaran in branch '3.2':
merge from 2.7 - Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/dafdbd0d570a

New changeset aea6f588230b by Senthil Kumaran in branch 'default':
merge from 3.2 - Fix closes issue11047 - Correct the 2.7 whatsnew description for issue 7902.
http://hg.python.org/cpython/rev/aea6f588230b

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

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

From report at bugs.python.org  Sat Aug  6 06:57:28 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Aug 2011 04:57:28 +0000
Subject: [docs] [issue11047] Bad description for an entry in whatsnew/2.7
In-Reply-To: <1312585409.06.0.166279271437.issue11047@psf.upfronthosting.co.za>
Message-ID: <20110806045720.GB2530@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sandro, perhaps got overlooked. :) But yeah, why wait. Done.

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

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

From report at bugs.python.org  Sat Aug  6 07:38:34 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Aug 2011 05:38:34 +0000
Subject: [docs] [issue12697] timeit documention still refers to the
	timeit.py script
In-Reply-To: <1312560694.46.0.261763175003.issue12697@psf.upfronthosting.co.za>
Message-ID: <1312609114.14.0.108693056245.issue12697@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for the report, Boris Feld and Alexis.

----------
assignee: alexis -> docs at python
nosy: +docs at python, orsenthil

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

From report at bugs.python.org  Sat Aug  6 08:30:38 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Sat, 06 Aug 2011 06:30:38 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312574446.4.0.119173467739.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110806063035.GA2833@ihaa>


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

Terry J. Reedy wrote:
> Adding a feature 'fixes' the deficiency of its absence. I personally
> have no use for 'accepted' and find it ambiguous. My best
> understanding is what David has seen (accepted in principle).

Ditto.

Having separate resolutions for bugs and features makes it harder to
find all issues that have been closed as "bug fixed or feature
accepted", because you cannot select multiple resolutions when
searching.

With one resolution, you can simply search for "fixed" issues. If you
only want to find feature requests that were accepted, search for
type=feature and resolution=fixed.

----------

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

From report at bugs.python.org  Sat Aug  6 14:48:25 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Aug 2011 12:48:25 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312634905.1.0.487832194635.issue12682@psf.upfronthosting.co.za>


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

FWIW that would be fine with me.  Even if there's nothing broken in a feature request, "fixed" applied to feature could mean "the lack of this feature has been fixed".
If the issue is valid, one can say so in a message without marking it as 'accepted'.

----------

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

From report at bugs.python.org  Sat Aug  6 16:53:26 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Aug 2011 14:53:26 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312642406.38.0.803637214788.issue12666@psf.upfronthosting.co.za>


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

I have reported the bugs to the metatracker.  In the meantime, could you manually upload a diff?

----------

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

From report at bugs.python.org  Sat Aug  6 18:18:30 2011
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 06 Aug 2011 16:18:30 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312647510.88.0.632873595887.issue12666@psf.upfronthosting.co.za>


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

I'm attaching the diff at https://bitbucket.org/jaraco/cpython-issue12666/changeset/bc362109eed8

----------
keywords: +patch
Added file: http://bugs.python.org/file22848/cpython-issue12666-bc362109eed8.diff

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

From report at bugs.python.org  Sat Aug  6 19:14:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 06 Aug 2011 17:14:12 +0000
Subject: [docs] [issue11481] The copy module already uses copyreg
In-Reply-To: <1300009670.98.0.0546201477777.issue11481@psf.upfronthosting.co.za>
Message-ID: <1312650852.14.0.973832445388.issue11481@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After quite a long chat with Ezio, I'm just proposing this updated patch:

- it fixes the copy doc, explicitly acknowledging the use of copyreg functionalities
- it rewords the first paragraph of copyreg doc, which was a bit too pickle-centric
- it adds an example to copyreg, to give an initial clue of how it works.

I'd like to hear comments/suggestions about it.

----------
nosy: +fdrake, rhettinger
Added file: http://bugs.python.org/file22849/issue11481-v2.patch

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

From report at bugs.python.org  Sat Aug  6 20:12:27 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 06 Aug 2011 18:12:27 +0000
Subject: [docs] [issue12704] Language References does not specify exception
	raised by	final yield()
Message-ID: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

>From http://docs.python.org/reference/simple_stmts.html#the-yield-statement:

"As of Python version 2.5, the yield statement is now allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator?s close() method will be called, allowing any pending finally clauses to execute."

This strongly suggests that the last-executed yield statement will raise an exception if the generator is closed. If this is the case, it would be great if the documentation could be extended to say what exception is raised.

If this is not the case, it would be great if whatever magic is happening could be documented as well.

----------
assignee: docs at python
components: Documentation
messages: 141724
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Language References does not specify exception raised by final yield()
type: feature request
versions: Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Aug  6 20:29:10 2011
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 06 Aug 2011 18:29:10 +0000
Subject: [docs] [issue12704] Language References does not specify exception
	raised by	final yield()
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1312655350.4.0.122132904025.issue12704@psf.upfronthosting.co.za>


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

>From http://www.python.org/dev/peps/pep-0342/ I believe that the last yield will raise GeneratorExit. So my suggestion is to replace the above mentioned paragraph with:

"""
As of Python version 2.5, yield is an expression rather than a statement and allowed in the try clause of a try ... finally construct. If the generator is not resumed before it is finalized (by reaching a zero reference count or by being garbage collected), the generator-iterator?s close() method will be called, and the yield expression in the generator function will raise GeneratorExit. 

If the generator function raises GeneratorExit (either directly or by not catching it), future calls to the next() method of the generator iterator will raise StopIteration. GeneratorExit exceptions raised by the generator function are catched internally and do not result in a call to sys.excepthook.
"""

----------

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

From report at bugs.python.org  Sun Aug  7 03:44:52 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 01:44:52 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312681492.53.0.638768763935.issue12677@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Sandro - You could go ahead and commit this.

----------

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

From report at bugs.python.org  Sun Aug  7 10:33:01 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:33:01 +0000
Subject: [docs] [issue12706] timeout sentinel in ftplib and poplib
Message-ID: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

- ftplib and poplib, has them as timeout=None, while they default                                                                               
 to socket._GLOBAL_DEFAULT_TIMEOUT object.                                                                                                           
                                                                                                                                                      
This is wrong; someone may pass None thinking it will trigger the                                                                                     
default behaviour, and have nasty surprises.

----------
assignee: docs at python
messages: 141740
nosy: docs at python, orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: timeout sentinel in ftplib and poplib
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Aug  7 10:33:16 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Aug 2011 08:33:16 +0000
Subject: [docs] [issue12706] timeout sentinel in ftplib and poplib
	documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1312705996.79.0.746678952617.issue12706@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
title: timeout sentinel in ftplib and poplib -> timeout sentinel in ftplib and poplib documentation

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

From report at bugs.python.org  Sun Aug  7 17:15:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Aug 2011 15:15:06 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <E1Qq54A-0004FZ-PL@dinsdale.python.org>


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

New changeset a30e6c4bf486 by Sandro Tosi in branch '2.7':
#12677: correct turtle orientation in doc
http://hg.python.org/cpython/rev/a30e6c4bf486

New changeset bf4f65043d7d by Sandro Tosi in branch '3.2':
#12677: correct turtle orientation in doc
http://hg.python.org/cpython/rev/bf4f65043d7d

New changeset a7365994f4d6 by Sandro Tosi in branch 'default':
#12677: merge with 3.2
http://hg.python.org/cpython/rev/a7365994f4d6

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

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

From report at bugs.python.org  Sun Aug  7 17:17:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 15:17:42 +0000
Subject: [docs] [issue12677] Turtle, fix right/left rotation orientation
In-Reply-To: <1312205869.48.0.0607812331908.issue12677@psf.upfronthosting.co.za>
Message-ID: <1312730262.09.0.0136542997894.issue12677@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug  7 23:14:39 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 21:14:39 +0000
Subject: [docs] [issue10741] PyGILState_GetThisThreadState() lacks a doc
	entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1312751679.4.0.898721987395.issue10741@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here attached a very simple patch, made by slightly re-editing the comment in pystate.h.

----------
keywords: +patch
nosy: +ezio.melotti, sandro.tosi
stage:  -> patch review
versions: +Python 3.3 -Python 3.1
Added file: http://bugs.python.org/file22858/issue10741-default.patch

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

From report at bugs.python.org  Mon Aug  8 00:20:31 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 07 Aug 2011 22:20:31 +0000
Subject: [docs] [issue10741] PyGILState_GetThisThreadState() lacks a doc
	entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <E1QqBhu-0006V8-4q@dinsdale.python.org>


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

New changeset 8852e4a9aa1e by Sandro Tosi in branch '2.7':
#10741: add documentation for PyGILState_GetThisThreadState()
http://hg.python.org/cpython/rev/8852e4a9aa1e

New changeset 53b8260b9ea7 by Sandro Tosi in branch '3.2':
#10741: add documentation for PyGILState_GetThisThreadState()
http://hg.python.org/cpython/rev/53b8260b9ea7

New changeset 6adfeec8c482 by Sandro Tosi in branch 'default':
#10741: merge with 3.2
http://hg.python.org/cpython/rev/6adfeec8c482

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

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

From report at bugs.python.org  Mon Aug  8 00:22:13 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sun, 07 Aug 2011 22:22:13 +0000
Subject: [docs] [issue10741] PyGILState_GetThisThreadState() lacks a doc
	entry
In-Reply-To: <1292868592.26.0.469038546855.issue10741@psf.upfronthosting.co.za>
Message-ID: <1312755733.55.0.851014314789.issue10741@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

I just committed an improved version of the proposed patch (thanks Ezio for the review and help!).

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

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

From report at bugs.python.org  Mon Aug  8 00:52:01 2011
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Aug 2011 22:52:01 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312757521.87.0.556592863036.issue12682@psf.upfronthosting.co.za>


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

Well, as long as 'accepted' is under 'resolution', I'm likely to keep using it for feature requests, I suppose because I'm too much of a precisonist.  If someone wants to re-engineer the interface, that would be fine with me :)

I personally don't mind other uses, nor do I find myself searching on resolutions.

----------

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

From sandro.tosi at gmail.com  Mon Aug  8 01:48:29 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Mon, 8 Aug 2011 01:48:29 +0200
Subject: [docs] urllib2.urlopen() seems to have worse documentation than
	urllib.urlopen()
In-Reply-To: <CAG8k2+5sJ4zzBoemvj_p1A9AOZynDxSWwrPhWW-4nVAs+KVRbg@mail.gmail.com>
References: <CAG8k2+5sJ4zzBoemvj_p1A9AOZynDxSWwrPhWW-4nVAs+KVRbg@mail.gmail.com>
Message-ID: <CAPdtAj1SuzXZDMOf_mpgbgw4xet=8SK1q_FdXGyweuK_du9Qiw@mail.gmail.com>

Hello Daniel,

On Tue, Jul 26, 2011 at 22:51, Daniel Holth <dholth at gmail.com> wrote:
> I know I should probably be using httplib9 by now, but
> urllib2.urlopen() doesn't document its return object's getcode()
> method even though it seems to have one as documented in
> urllib.urlopen()

Thanks for your report. While discussing it what was the best way to
fix it, we actually end up with this http://bugs.python.org/issue12707

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Aug  8 12:10:09 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:10:09 +0000
Subject: [docs] [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
Message-ID: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>


New submission from Hynek Schlawack <hs at ox.cx>:

While working on #12708 , I noticed that the error_callback argument of multiprocessing.Pool.map_async() isn't documented (callback is).

----------
assignee: docs at python
components: Documentation
messages: 141763
nosy: docs at python, hynek
priority: normal
severity: normal
status: open
title: In multiprocessing, error_callback isn't documented for map_async
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Aug  8 12:37:12 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 10:37:12 +0000
Subject: [docs] [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312799832.68.0.222354828739.issue12709@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Would you like to provide a doc patch about it? Thanks in advance

----------
nosy: +sandro.tosi
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

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

From report at bugs.python.org  Mon Aug  8 12:50:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Aug 2011 10:50:17 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312757521.87.0.556592863036.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110808105007.GC1992@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

R. David Murray wrote:
>  If someone wants to re-engineer the interface, that would be fine with me :)

Does that mean, that if vote for removing the 'accepted' keyword it
becomes an issue for the meta-tracker?

----------

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

From report at bugs.python.org  Mon Aug  8 12:54:00 2011
From: report at bugs.python.org (Hynek Schlawack)
Date: Mon, 08 Aug 2011 10:54:00 +0000
Subject: [docs] [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312800839.96.0.735383956402.issue12709@psf.upfronthosting.co.za>


Hynek Schlawack <hs at ox.cx> added the comment:

Yeah, if my 3G hadn't failed on me, it would have been already here. :)

As a matter of fact, the argument is discussed in the body of the doc, it just has been omitted in the method definition, so the patch is trivial.

----------
keywords: +patch
Added file: http://bugs.python.org/file22861/map_async-doc-fix.diff

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

From report at bugs.python.org  Mon Aug  8 14:49:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Aug 2011 12:49:07 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312807747.18.0.124597539391.issue12682@psf.upfronthosting.co.za>


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

I think we've moved from discussing a documentation issue to discussing a procedural issue in the development process.  I'm not sure what forum that belongs in, though I believe in the past we have used tracker-discuss for that.

That said, I'm really fine with whatever is decided, and don't think it is that big a deal in any regard.

----------

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

From report at bugs.python.org  Mon Aug  8 15:33:42 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 13:33:42 +0000
Subject: [docs] [issue11836] multiprocessing.queues.SimpleQueue is
	undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1312810422.87.0.519172796839.issue11836@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here's a patch to add SimpleQueue to doc and __all__ .

I didn't document the 'sentinels' argument of SimpleQueue.get() because I got lost into Pipe _pool and can't understand how those sentinels are actually used/useful. Any hint is appreciated :)

----------
nosy: +ezio.melotti, sandro.tosi
stage: needs patch -> patch review
versions: +Python 2.7 -Python 3.1

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

From report at bugs.python.org  Mon Aug  8 15:34:02 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 13:34:02 +0000
Subject: [docs] [issue11836] multiprocessing.queues.SimpleQueue is
	undocumented
In-Reply-To: <1302623785.46.0.16009713021.issue11836@psf.upfronthosting.co.za>
Message-ID: <1312810442.15.0.610146779774.issue11836@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file22863/issue11836-default.patch

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

From report at bugs.python.org  Mon Aug  8 16:23:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 14:23:29 +0000
Subject: [docs] [issue12666] map semantic change not documented in What's New
In-Reply-To: <1312126093.97.0.0321206475431.issue12666@psf.upfronthosting.co.za>
Message-ID: <1312813409.04.0.603191454931.issue12666@psf.upfronthosting.co.za>


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

The content of the patch is very helpful, but I question its location: I?m not sure people will find this nugget in the 3.2+ version of the What?s New in Python 3.0 document (sorry for not bringing that up sooner).  Maybe you could update Doc/library/functions.rst instead, and/or Doc/howto/pyporting.rst?

----------

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

From report at bugs.python.org  Mon Aug  8 16:40:47 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 08 Aug 2011 14:40:47 +0000
Subject: [docs] [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <E1QqR0Y-0006xF-5x@dinsdale.python.org>


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

New changeset b2835b8412e5 by Sandro Tosi in branch '2.7':
#12709: add error_callback argument to map_async documentation
http://hg.python.org/cpython/rev/b2835b8412e5

New changeset 41b816853819 by Sandro Tosi in branch '3.2':
#12709: add error_callback argument to map_async documentation
http://hg.python.org/cpython/rev/41b816853819

New changeset 0c922e7d26e1 by Sandro Tosi in branch 'default':
#12709: merge with 3.2
http://hg.python.org/cpython/rev/0c922e7d26e1

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

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

From report at bugs.python.org  Mon Aug  8 16:41:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 08 Aug 2011 14:41:23 +0000
Subject: [docs] [issue12709] In multiprocessing,
	error_callback isn't documented for map_async
In-Reply-To: <1312798209.69.0.295149725931.issue12709@psf.upfronthosting.co.za>
Message-ID: <1312814483.0.0.673525146888.issue12709@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hynek, thanks for your contribution to Python!

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

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

From report at bugs.python.org  Mon Aug  8 17:52:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:52:34 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312818754.02.0.945275985794.issue12672@psf.upfronthosting.co.za>


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

> it's unclear what [].append is.
It?s crystal clear to me: [].append is a method of a list object, just created here by a literal.  (Maybe you?re not aware that [].append is valid Python.)

> The C coding convention is unusual and non PEP-7 in 2.1.1
Running Tools/scripts/untabify.py on the C codebase reveals problems in Doc/include/*.c, Objects, Python, etc.

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

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

From report at bugs.python.org  Mon Aug  8 17:56:07 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Aug 2011 15:56:07 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312818967.74.0.873684537005.issue12682@psf.upfronthosting.co.za>


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

When we?ve talked about that a few times these last months on the ML or on IRC, the outcome was that accepted means patch is accepted, not bug report is valid.  I?ve never seen accepted used to mean that a feature request is closed; I use fixed for solved bugs and added features alike and don?t see a problem with it.

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

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

From report at bugs.python.org  Mon Aug  8 18:00:39 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 08 Aug 2011 16:00:39 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312819238.98.0.402166041518.issue12682@psf.upfronthosting.co.za>


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

"patch accepted" can be marked with the "commit review" stage.
That should mean "the patch is ready to go in, after a last quick review by the committer that will apply it", even though I've seen it used as "I made the commit but I'm leaving this open until I'm sure everything still works".

----------

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

From giecrilj at stegny.2a.pl  Tue Aug  2 10:34:58 2011
From: giecrilj at stegny.2a.pl (=?iso-8859-2?q?K=F8i=B9tof_=AEelechovski?=)
Date: Tue, 2 Aug 2011 10:34:58 +0200
Subject: [docs] idle.py displays source rather than running
Message-ID: <201108021035.03744.giecrilj@stegny.2a.pl>

== Steps to reproduce ==
{ python /usr/lib64/python2.7/idlelib/idle.py /usr/bin/idle; }

== Expected results ==
According to the text of 24.6.4.1.3, IDLE should run /usr/bin/idle

== Actual results ==
IDLE displays /usr/bin/idle

== Workaround ==
{ python /usr/lib64/python2.7/idlelib/idle.py -r /usr/bin/idle; }

From nicolas.vanheu at gmail.com  Mon Aug  1 19:31:27 2011
From: nicolas.vanheu at gmail.com (Nicolas Vanheuverzwijn)
Date: Mon, 1 Aug 2011 13:31:27 -0400
Subject: [docs] bug in a documentation exemple
Message-ID: <CAEKPcL2qOWwkxwFpzNHHyOB3aJDgAohgJn9mGNKwmJHwxW=8cA@mail.gmail.com>

At http://docs.python.org/tutorial/interpreter.html

Every print should be written with parenthesis I think because 'print
"printtest" ' doesn't work in python 3.0. Print("test") works.

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

From report at bugs.python.org  Mon Aug  8 19:51:31 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Aug 2011 17:51:31 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1312825891.73.0.385610313567.issue12682@psf.upfronthosting.co.za>


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

Changing the dev guide, which I think is definitely needed, is an issue for this tracker. Changing the tracker is an issue for the meta-tracker. Discussing a change might be an issue for python-dev.

I was under the impression once that the tracker fields were going to be reviewed last summer, before the dev guide was written. This could still happen any time.

----------

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

From python at samthompson.com  Wed Aug  3 11:57:39 2011
From: python at samthompson.com (Sam Thompson)
Date: Wed, 03 Aug 2011 19:57:39 +1000
Subject: [docs] Issue: no reference to bytes alias in documentation for
 2.6.x and 2.7 (related to closed issue 1865)
Message-ID: <4E391B93.3020101@samthompson.com>

Hi,

I'm new to Python so might have the wrong end of the stick, however I 
noted that although the py3k porting documentation (e.g. at 
http://docs.python.org/dev/py3k/howto/pyporting.html) says that both 
python 2.6 and 2.7 support use of b"xxx" style literals, there's no 
mention of it in any of the 2.6.x documentation for literals (e.g. 
http://docs.python.org/release/2.6.7/reference/lexical_analysis.html#id7).

I found a closed bug in the issue tracker 
(http://bugs.python.org/issue1865) which appears to originally have 
covered this issue but the version was changed to 2.7 before it was 
resolved (although it's also not fixed in 2.7's version at 
http://docs.python.org/release/2.7/reference/lexical_analysis.html#id7, 
but is fixed in 2.7.1 and 2.7.2).

It looks like the solution used for 2.7.1+ would be appropriate for the 
older versions, since there do not appear to be other substantial 
changes to this part of the documentation between these versions.

Regards,
Sam.
--
Sam Thompson.


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

From t4chacko+cq at gmail.com  Mon Aug  1 17:25:12 2011
From: t4chacko+cq at gmail.com (t4C+Cq)
Date: Mon, 1 Aug 2011 08:25:12 -0700
Subject: [docs] Python-2.3.3/pdf/ref.pdf
In-Reply-To: <CAPdtAj1h3LvXPaQaG+u7RZJt6wAVuCEeniXumsJ0f7QpttOLOw@mail.gmail.com>
References: <CAB7OhvxONoATXFP9nK+7uwjLiXbxN_ga1vV4b-P2tuynfmfz4Q@mail.gmail.com>
	<CAPdtAj1h3LvXPaQaG+u7RZJt6wAVuCEeniXumsJ0f7QpttOLOw@mail.gmail.com>
Message-ID: <CAB7OhvwMoSbJmVcEtjeoUPAbT2duYX048z2FEGQCRfC1MBVaRg@mail.gmail.com>

Hello Sandro,

Thank you very much!  I was just about starting to look at python (php has
been my script language for 15 yrs), so had no clue about current version
etc.  I appreciate you taking the time to reply to me!!

Cn

On Mon, Aug 1, 2011 at 12:45 AM, Sandro Tosi <sandro.tosi at gmail.com> wrote:

> Hello,
>
> On Sun, Jul 31, 2011 at 23:31, t4C+Cq <t4chacko+cq at gmail.com> wrote:
> >
> http://www.compsci.wm.edu/SciClone/documentation/software/compilers/Python-2.3.3/pdf/ref.pdf
> > Hi,
> > I understand the url above is not yours, but the content is.  The above
> pdf
> > has an unsual repeating error in that all occurances 'fi' even within the
> > middle of a word has become blank!  I wonder why that occurred?
>
> 2.3.3 is a really old release and you should not use it (unless
> forced, of course) or refer to its documentation. The latest Python
> releases can be found here: http://python.org/download/
>
> > In any case, can you refer me to another availabe pdf versrion of your
> > python documentation online?
>
> Probably the best place (and the canonical one) is the one from the
> official python website: http://docs.python.org/ for 2.7 and
> http://docs.python.org/py3k/ for the current 3.x release.
>
> Regards,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110801/58ba818e/attachment.html>

From philip at primacystudios.com  Mon Aug  8 20:37:07 2011
From: philip at primacystudios.com (philip at primacystudios.com)
Date: Mon, 08 Aug 2011 11:37:07 -0700
Subject: [docs] Tutorial code is missing a break statement
Message-ID: <a2f9f182c65bdd3192fa12749438673e@primacystudios.com>

  

Hello, 

In section 4.4 "break and continue..." of the v2.7.2
tutorial documentation the loop iterates and returns a different output
than what is depicted.  

Documentation printed output:

2 is a prime
number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2
* 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

Here is the code:


>>> for n in range(2, 10):
...  for x in range(2, n):
...  if n % x ==
0:
...  print n, 'equals', x, '*', n/x
...  break
...  else:
...  # loop
fell through without finding a factor 

...  print n, 'is a prime
number'  

My printed output:  

3 is a prime number
4 equals 2 * 2
5 is
a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7
is a prime number
7 is a prime number
7 is a prime number
7 is a prime
number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3
* 3

I added a break statement to the else clause:

>>> for n in
range(2, 10):
 for x in range(2, n):
 if n% x == 0:
 print n, 'equals',
x, '*', n/x
 break
 else:
 print n, 'is a prime number'
 break

To get
what is in the tutorial:

2 is a prime number
3 is a prime number
4
equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8
equals 2 * 4
9 equals 3 * 3

I hope this helps.

Phil Templeton

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

From senthil at uthcode.com  Tue Aug  9 04:16:08 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Tue, 9 Aug 2011 10:16:08 +0800
Subject: [docs] Tutorial code is missing a break statement
In-Reply-To: <a2f9f182c65bdd3192fa12749438673e@primacystudios.com>
References: <a2f9f182c65bdd3192fa12749438673e@primacystudios.com>
Message-ID: <20110809021608.GA2190@mathmagic>

On Mon, Aug 08, 2011 at 11:37:07AM -0700, philip at primacystudios.com wrote:
> In section 4.4 "break and continue..." of the v2.7.2 tutorial documentation the
> loop iterates and returns a different output than what is depicted. 

Perhaps you did not indent your program correctly. The else goes with
the for statement and not if. I tried the program from the text and it
gives the output as documented.

-- 
Senthil

From report at bugs.python.org  Tue Aug  9 04:29:12 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Aug 2011 02:29:12 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312807747.18.0.124597539391.issue12682@psf.upfronthosting.co.za>
Message-ID: <20110809022903.GB2190@mathmagic>


Senthil Kumaran <senthil at uthcode.com> added the comment:

RDM, yes, unfortunately the direction of the discussion changed from
documentation issue to a process one. Instead of diverting further
into catch all discussion about process/tracker, it would be good idea
to settle this one. Your points definitely counts as you raised
the issue and have experience in dealing with tracker states. What
would you suggest?

----------

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

From report at bugs.python.org  Tue Aug  9 04:40:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 09 Aug 2011 02:40:30 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1312857630.36.0.242503919129.issue12672@psf.upfronthosting.co.za>


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

?ric,
I know perfectly well that [].append is valid Python, but I don't think this is the clearest way to give an example of an object method. I think spelling [].append's meaning more explicitly would be better.

I'm also aware that there are tab problems all over the code base. I'm not suggesting a large cleanup. But I do think that in *example code* in the documentation, it wouldn't hurt to make the code idiomatically styled. After all, this is what people will copy-paste when writing new code.

----------

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

From eliben at gmail.com  Tue Aug  9 09:00:05 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 9 Aug 2011 10:00:05 +0300
Subject: [docs] bug in a documentation exemple
In-Reply-To: <CAEKPcL2qOWwkxwFpzNHHyOB3aJDgAohgJn9mGNKwmJHwxW=8cA@mail.gmail.com>
References: <CAEKPcL2qOWwkxwFpzNHHyOB3aJDgAohgJn9mGNKwmJHwxW=8cA@mail.gmail.com>
Message-ID: <CAF-Rda_qCYZRGBqErkedtjAL5v90+axQVraRAdnWg3GNEGoLzA@mail.gmail.com>

> At?http://docs.python.org/tutorial/interpreter.html
>
> Every print should be written with parenthesis I think because 'print
> "printtest" ' doesn't work in python 3.0. Print("test") works.
>
> --

Please note that at this point, http://docs.python.org points to the
Python 2.7.x documentation

The latest released Python 3.x docs (currently for 3.2.1) are at
http://docs.python.org/py3k/
Eli

From report at bugs.python.org  Tue Aug  9 13:54:12 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 11:54:12 +0000
Subject: [docs] [issue12714] argparse.ArgumentParser.add_argument()
	documentation	error
Message-ID: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>


New submission from Petri Lehtinen <petri at digip.org>:

The documentation of argparse.ArgumentParser.add_argument() says:

* required - Whether or not the command-line option may be omitted (optionals only).

I believe it should be "options only" instead of "optionals only".

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141812
nosy: docs at python, petri.lehtinen
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser.add_argument() documentation error
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  9 14:24:37 2011
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Aug 2011 12:24:37 +0000
Subject: [docs] [issue12714] argparse.ArgumentParser.add_argument()
	documentation	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312892677.46.0.266954006444.issue12714@psf.upfronthosting.co.za>


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

Nope, optionals is what argparse calls them.

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

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

From report at bugs.python.org  Tue Aug  9 14:35:09 2011
From: report at bugs.python.org (Petri Lehtinen)
Date: Tue, 09 Aug 2011 12:35:09 +0000
Subject: [docs] [issue12714] argparse.ArgumentParser.add_argument()
	documentation	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312893309.14.0.812915781754.issue12714@psf.upfronthosting.co.za>


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

Yes, but required=True/False makes an *option* required or optional. Setting required=False is not allowed with *positionals*:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('foo', required=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/argparse.py", line 1262, in add_argument
    kwargs = self._get_positional_kwargs(*args, **kwargs)
  File "/usr/lib/python2.7/argparse.py", line 1367, in _get_positional_kwargs
    raise TypeError(msg)
TypeError: 'required' is an invalid argument for positionals

I assume that this is the case that is being documented here, so it should read "options only" meaning "not allowed for positionals". Am I correct?

----------

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

From report at bugs.python.org  Tue Aug  9 16:41:45 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 14:41:45 +0000
Subject: [docs] [issue12716] Reorganize os docs for files/dirs/fds
Message-ID: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Right now many of the os function docs are split up into "Files and directories" and "file descriptor operations". This means, for example, that fchmod() and fchmodat() are in a different section than chmod(). It would make more sense to organize the docs such that functions that do the same thing are right next to each other.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 141820
nosy: benjamin.peterson, docs at python
priority: low
severity: normal
status: open
title: Reorganize os docs for files/dirs/fds
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug  9 18:11:15 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 16:11:15 +0000
Subject: [docs] [issue8617] Better document user site-packages in site
	module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <E1Qqotd-0006og-Ho@dinsdale.python.org>


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

New changeset 74179a79d673 by ?ric Araujo in branch '3.2':
Improve documentation for PEP 370 support in site module (#8617).
http://hg.python.org/cpython/rev/74179a79d673

New changeset d354802a637d by ?ric Araujo in branch 'default':
Merge doc changes from 3.2 (#8617, #10745).
http://hg.python.org/cpython/rev/d354802a637d

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

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

From report at bugs.python.org  Tue Aug  9 18:42:52 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 16:42:52 +0000
Subject: [docs] [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1312908172.06.0.602420849607.issue12716@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Also, symbolic constants should be close to the functions they are used in. For example, open() flags shouldn't be in their own section.

----------

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

From report at bugs.python.org  Tue Aug  9 22:22:50 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Aug 2011 20:22:50 +0000
Subject: [docs] [issue12719] Direct access to tp_dict can lead to stale
	attributes
In-Reply-To: <1312920990.32.0.154264120854.issue12719@psf.upfronthosting.co.za>
Message-ID: <1312921370.67.0.0508422436594.issue12719@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

This is forbidden, and I agree there should be a doc note. See #1878.

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +benjamin.peterson, docs at python

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

From matthew at woodcraft.me.uk  Tue Aug  9 22:23:52 2011
From: matthew at woodcraft.me.uk (Matthew Woodcraft)
Date: Tue, 9 Aug 2011 21:23:52 +0100
Subject: [docs] Link to heapq source from docs.python.org not working
Message-ID: <20110809202352.GA12073@golux.woodcraft.me.uk>

http://docs.python.org/library/heapq.html contains a link to the heapq source,
at
http://svn.python.org/view/python/branches/release27-maint/Lib/heapq.py?view=markup

I noticed today that that page isn't working properly.

It's saying

An Exception Has Occurred
Python Traceback

Traceback (most recent call last):
  File "/usr/lib/viewvc/lib/viewvc.py", line 4317, in main
    request.run_viewvc()
  File "/usr/lib/viewvc/lib/viewvc.py", line 397, in run_viewvc
    self.view_func(self)
  File "/usr/lib/viewvc/lib/viewvc.py", line 1763, in view_markup
    markup_or_annotate(request, 0)
  File "/usr/lib/viewvc/lib/viewvc.py", line 1696, in markup_or_annotate
    path[-1], mime_type)
  File "/usr/lib/viewvc/lib/viewvc.py", line 1589, in markup_stream_pygments
    encoding='utf-8'), ps)
  File "/usr/lib/pymodules/python2.6/pygments/__init__.py", line 86, in highlight
    return format(lex(code, lexer), formatter, outfile)
  File "/usr/lib/pymodules/python2.6/pygments/__init__.py", line 45, in lex
    return lexer.get_tokens(code)
  File "/usr/lib/pymodules/python2.6/pygments/lexer.py", line 137, in get_tokens
    text = text.decode('utf-8')
  File "/usr/lib/python2.6/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe7 in position 1428: invalid continuation byte


-M-

From mihirjesrani2001 at yahoo.com  Tue Aug  9 19:25:09 2011
From: mihirjesrani2001 at yahoo.com (mihir jesrani)
Date: Tue, 9 Aug 2011 10:25:09 -0700 (PDT)
Subject: [docs] beginner
Message-ID: <1312910709.42916.YahooMailNeo@web110711.mail.gq1.yahoo.com>

hello team,
I am a beginner to the world of coding.Thus could u give me a specific link/url using which i can learn this language.Also i would like to know any groups/resources that may come handy for a novice for me.


Regards,
Mihir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110809/4245dfcf/attachment.html>

From richardterrelive at live.ca  Tue Aug  9 16:03:46 2011
From: richardterrelive at live.ca (Ricky John)
Date: Tue, 9 Aug 2011 09:03:46 -0500
Subject: [docs] math and Cmath lib  interferences
Message-ID: <COL115-W75B2800FF898148980D7AC5200@phx.gbl>





to whom it may concern  here are a few suggestions to make life easier with python at least i hope  
http://docs.python.org/bugs.html
 
mailto:docs at python.org 
 
 I'm not a programmer but i like to use Python with Blender and like to work with Complex numbersbut right now i think there is room for improvement for the Cmath lib or add a new lib may be.
 so here are a few suggestions:
 
1- Interference between math and Cmath lib
 
 
 
 
# http://docs.python.org/library/math.html#module-math
# http://docs.python.org/library/cmath.html#module-cmat
 
 
 if these 2 modules are loaded and you try to find a log10  for a real number you get by default the Cmath.log10(x) with a Complex Result!
 
 i think it would be more logical to default to math.log10(x)  for X being a real number which is not the case right now!
 
 Suggestion:
 
 change the name for Cmath log10  for something like Clog10(x) to get a Complex number for X and the result!
 then by default log10 for X real would be a real number and not a complex one!
 
 Other functions which could be change too:
 
 cmath.sqrt(x)?     ---> cmath.csqrt(x)?
 cmath.log(x[, base])  ---> ?cmath.Clog(x[, base])?
 cmath.exp(x)?    ---> cmath.cexp(x)?
 cmath.acos(x)?    ----> cmath.cacos(x)?
 cmath.asin(x)?    ----> cmath.casin(x)?
 cmath.atan(x)?    ----> cmath.catan(x)?
 cmath.cos(x     ----> cmath.ccos(x
 cmath.sin(x)    ----> cmath.csin(x)
 cmath.tan(x)?    ----> cmath.ctan(x)?
 
 
 cmath.acosh(x)?    ----> cmath.cacosh(x)?
 cmath.asinh(x)?    ----> cmath.casinh(x)?
 cmath.atanh(x)    ----> cmath.atanh(x)
 cmath.atanh(x)?    ----> cmath.catanh(x)?
 
 cmath.cosh(x)?    ----> cmath.ccosh(x)?
 cmath.sinh(x)    ----> cmath.csinh(x)
 
 cmath.tanh(x)?    ----> cmath.ctanh(x)?
 
 
 
 Unless the Argument is complex then it would use the Complex function but for real number it should default to the math lib functions.
 
 
 
 
2 - C math  Polar  operators
 
 Right now it appears that polar operators don't exist 
 
 Suggestion add new polar Operators  + - X / using polar values
 
 Ex:  Z1=120 /__ 0 Radian angle
   z2= 10/__1  Radian angle
 
 New operator Polar +  :   Z1+ Z2  = 120 /__ 0 +  10/__1 
     Polar -  :   Z1/ Z2  = 120 /__ 0 -  10/__1 
     Polar X  :   Z1/ Z2  = 120 /__ 0 X  10/__1 
     Polar /  :   Z1/ Z2  = 120 /__ 0 /  10/__1 
 
 
 Note: In electrical engeenering we very often use polar notation for Voltage current and Z  impedance values
       because it is easier to visualize it  with angle then using the  rectangular form.
       
       I think this would make Cmath more user friendly in any case!    if possible make the angle  like  120D  or  1.5R  for having the flexibiliy  to give angle in degrees or radians!
       
       3-  complex matrix       it might also be very usefull to have the basic capabilities to work with and solve complex matrix      like we do in electrical engeneering calculations       hope this can be inmplemented too may be inside the Cmath lib!
 i hope  these suggestions make sense   and  also hoping these  can be implemented  to make life easier with python thanks & have a nice day  Richard Jean       		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110809/76d4906e/attachment.html>

From report at bugs.python.org  Tue Aug  9 23:17:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Aug 2011 21:17:25 +0000
Subject: [docs] [issue12719] Direct access to tp_dict can lead to stale
	attributes
In-Reply-To: <1312920990.32.0.154264120854.issue12719@psf.upfronthosting.co.za>
Message-ID: <E1Qqtfv-0001qo-BW@dinsdale.python.org>


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

New changeset 6ef65516fd7a by Benjamin Peterson in branch '3.2':
note mutating tp_dict is bad (closes #12719)
http://hg.python.org/cpython/rev/6ef65516fd7a

New changeset 69df5a8d164e by Benjamin Peterson in branch 'default':
merge 3.2 (#12719)
http://hg.python.org/cpython/rev/69df5a8d164e

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

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

From senthil at uthcode.com  Wed Aug 10 15:26:11 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 10 Aug 2011 21:26:11 +0800
Subject: [docs] Link to heapq source from docs.python.org not working
In-Reply-To: <20110809202352.GA12073@golux.woodcraft.me.uk>
References: <20110809202352.GA12073@golux.woodcraft.me.uk>
Message-ID: <20110810132611.GE2116@mathmagic>

On Tue, Aug 09, 2011 at 09:23:52PM +0100, Matthew Woodcraft wrote:
> http://docs.python.org/library/heapq.html contains a link to the heapq source,
> at
> http://svn.python.org/view/python/branches/release27-maint/Lib/heapq.py?view=markup
> 

I see that it is a problem with viewvc software which is not handling
unicode text in HTML markup properly. Probably we can reference the
text version of that module till the viewvc bug is fixed.


Thanks,
Senthil

From report at bugs.python.org  Wed Aug 10 15:53:17 2011
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 10 Aug 2011 13:53:17 +0000
Subject: [docs] [issue12722] Link to heapq source from docs.python.org not
	working
Message-ID: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <senthil at uthcode.com>:

http://mail.python.org/pipermail/docs/2011-August/005336.html

I see that it is a problem with viewvc software which is not handling
unicode text in HTML markup properly. Probably we can reference the
text version of that module till the viewvc bug is fixed.

----------
assignee: docs at python
components: Documentation
messages: 141862
nosy: docs at python, orsenthil
priority: normal
severity: normal
status: open
title: Link to heapq source from docs.python.org not working

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

From report at bugs.python.org  Wed Aug 10 15:55:22 2011
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Aug 2011 13:55:22 +0000
Subject: [docs] [issue12722] Link to heapq source from docs.python.org not
	working
In-Reply-To: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>
Message-ID: <E1Qr9Fg-0002Rl-Ti@dinsdale.python.org>


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

New changeset 9f482b957d77 by Senthil Kumaran in branch '2.7':
Fix closes Issue12722  - link heapq source in the text format in the documentation.
http://hg.python.org/cpython/rev/9f482b957d77

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

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

From senthil at uthcode.com  Wed Aug 10 16:16:36 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 10 Aug 2011 22:16:36 +0800
Subject: [docs] math and Cmath lib  interferences
In-Reply-To: <COL115-W75B2800FF898148980D7AC5200@phx.gbl>
References: <COL115-W75B2800FF898148980D7AC5200@phx.gbl>
Message-ID: <20110810141636.GA3514@mathmagic>

On Tue, Aug 09, 2011 at 09:03:46AM -0500, Ricky John wrote:
>  if these 2 modules are loaded and you try to find a log10  for a real number
> you get by default the Cmath.log10(x) with a Complex Result!
>  
>  i think it would be more logical to default to math.log10(x)  for X being a
> real number which is not the case right now!

Can you raise a bug in bugs.python.org? This is more suitable for
tracker where people interested in maths module may notice, provide
feedback and take appropriate action.

Thanks,
Senthil


From report at bugs.python.org  Wed Aug 10 16:38:41 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Aug 2011 14:38:41 +0000
Subject: [docs] [issue12714] argparse.ArgumentParser.add_argument()
	documentation	error
In-Reply-To: <1312890852.75.0.253280882894.issue12714@psf.upfronthosting.co.za>
Message-ID: <1312987121.12.0.191284721112.issue12714@psf.upfronthosting.co.za>


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

"optionals only" means the same thing as "options only", but 'optionals' is what argparse calls them (as contrasted with positionals).

'optionals' is only used two places in the doc and isn't defined, but its meaning is implied by the section heading ("optional arguments").

----------

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

From sandro.tosi at gmail.com  Thu Aug 11 02:26:49 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 11 Aug 2011 02:26:49 +0200
Subject: [docs] beginner
In-Reply-To: <1312910709.42916.YahooMailNeo@web110711.mail.gq1.yahoo.com>
References: <1312910709.42916.YahooMailNeo@web110711.mail.gq1.yahoo.com>
Message-ID: <CAPdtAj0S7oesCn=vtnEEEtCtd9tz+sBKc_bCjaP031661ZBchg@mail.gmail.com>

Hello Mihir,
thanks for choosing Python :)

On Tue, Aug 9, 2011 at 19:25, mihir jesrani <mihirjesrani2001 at yahoo.com> wrote:
> hello team,
> I am a beginner to the world of coding.Thus could u give me a specific
> link/url using which i can learn this language.

On our documentation there's a tutorial,
http://docs.python.org/tutorial/index.html , meant exactly to get new
people started with Python. Given you're now to Python, please let me
strongly suggest you to start with Python 3 (instead of 2) which is
the future of Python; so the same tutorial for Python 3 is at:
http://docs.python.org/py3k/tutorial/index.html

There are tons of other guides and tutorials and books about start
programming in Python. You can probably ask for more guidance on the
lists below (this mailing list is actually for bugs in the Python
documentation ;) ).

> Also i would like to know any
> groups/resources that may come handy for a novice for me.

It depends a bit on the way you like to interact with people: mailing
list, forum, newsgroup, social networks and so on.

One precious resource is the python-list mailing list, available at:
http://mail.python.org/mailman/listinfo/python-list , where you can
ask any question about Python. I think you can continue your
exploration of Python on python-list.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 11 02:39:46 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 11 Aug 2011 02:39:46 +0200
Subject: [docs] Issue: no reference to bytes alias in documentation for
 2.6.x and 2.7 (related to closed issue 1865)
In-Reply-To: <4E391B93.3020101@samthompson.com>
References: <4E391B93.3020101@samthompson.com>
Message-ID: <CAPdtAj3Fw2xpcMDdOjXwq7C2oy1UGDbi7uCQsoEVccYNJW1xLg@mail.gmail.com>

Hello Sam,
thanks for your email.

On Wed, Aug 3, 2011 at 11:57, Sam Thompson <python at samthompson.com> wrote:
> Hi,
>
> I'm new to Python so might have the wrong end of the stick, however I noted
> that although the py3k porting documentation (e.g. at
> http://docs.python.org/dev/py3k/howto/pyporting.html) says that both python
> 2.6 and 2.7 support use of b"xxx" style literals, there's no mention of it
> in any of the 2.6.x documentation for literals (e.g.
> http://docs.python.org/release/2.6.7/reference/lexical_analysis.html#id7).

Currently, 2.6 is in security-fix only, so its documentation cannot be
change anymore, that's why you don't see it fixed there.

> I found a closed bug in the issue tracker (http://bugs.python.org/issue1865)
> which appears to originally have covered this issue but the version was
> changed to 2.7 before it was resolved (although it's also not fixed in 2.7's
> version at
> http://docs.python.org/release/2.7/reference/lexical_analysis.html#id7, but
> is fixed in 2.7.1 and 2.7.2).
>
> It looks like the solution used for 2.7.1+ would be appropriate for the
> older versions, since there do not appear to be other substantial changes to
> this part of the documentation between these versions.

The way we release Python patch-version (x.x.N where only N is
increased) is meant to replace N-1 and all the previous versions. So
we don't backport documentation (nor code) fixed to 2.7.0 if the fix
is in 2.7.1 and so on.

The links you're using to access teh documentation (I don't know if
only for showing the problem or as a general use) points to a specific
release, that will no longer be updated. So if you want to refer to
the lastest 2.x documentation the correct link is:

http://docs.python.org/

and for Python 3.x it is:

http://docs.python.org/py3k/

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 11 02:48:09 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 11 Aug 2011 02:48:09 +0200
Subject: [docs] idle.py displays source rather than running
In-Reply-To: <201108021035.03744.giecrilj@stegny.2a.pl>
References: <201108021035.03744.giecrilj@stegny.2a.pl>
Message-ID: <CAPdtAj0XJFcCJZCKcUhdaZjpRYvF9E89aTF54aW_SNtkM_d8Pw@mail.gmail.com>

Hello K?i?tof,
thanks for your email.

On Tue, Aug 2, 2011 at 10:34, K?i?tof ?elechovski <giecrilj at stegny.2a.pl> wrote:
> == Steps to reproduce ==
> { python /usr/lib64/python2.7/idlelib/idle.py /usr/bin/idle; }

what do you exactly want to accomplish with this command?

> == Expected results ==
> According to the text of 24.6.4.1.3, IDLE should run /usr/bin/idle

exactly: you can run directly /usr/bin/idle or python
/usr/lib64/python2.7/idlelib/idle.py (on my debian system I can start
idle with: python /usr/lib/python2.6/idlelib/idle.py)

> == Actual results ==
> IDLE displays /usr/bin/idle
>
> == Workaround ==
> { python /usr/lib64/python2.7/idlelib/idle.py -r /usr/bin/idle; }

you're asking idle to start another idle :)

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 11 02:53:42 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 11 Aug 2011 02:53:42 +0200
Subject: [docs] argparse doc example not especially helpful
In-Reply-To: <5395211D-86D6-4B3C-8B5C-7023E4F4AEF5@gmail.com>
References: <5395211D-86D6-4B3C-8B5C-7023E4F4AEF5@gmail.com>
Message-ID: <CAPdtAj0bETg0xZ349Mgs48gF_UFY3-NXkLF+RAXY2UDoVq30QQ@mail.gmail.com>

Hello Tyler,
sorry for this very late reply.

Would you like to provide some code examples for your proposal? That
would help us a lot in improving the doc.

Regards,
Sandro

On Wed, Mar 16, 2011 at 07:39, Tyler J. Barth <tyler.j.barth at gmail.com> wrote:
> I propose an improvement to the documentation for argparse
> (http://docs.python.org/library/argparse.html)
> I posit that the example 15.4.1 is not immediately helpful for the majority
> of people coming to docs.python.org to figure out how to use argparse.
> Though the use of argparse features to effortlessly sum and max the input
> integers is clever (and demonstrates many advanced features), I think most
> people arriving on that page want to know how to do three things:
> -Read in a file ("input.txt")
> -Read in a boolean switch ("-bar", use bar mode or not)
> -Read in a value for a switch ("-foo 6", set variable foo to 6)
> Of course, by hunting through the rest of the documentation you can learn
> how to do all of these basic tasks and more (much, much more).
> The clever sum and max example doesn't help elucidate how to perform these
> simple parses, and by using advanced features actually confuses new users.
> "argparse" has much more power than most people need, and I think it is fair
> to say that it's power obscures how to do the most common tasks. However,
> because "optparse" is deprecated and we all probably want to discourage
> people from rolling their own argument parsers every time they make a new
> simple program, I think there is value in making the "common case" more
> prominent in the example.
> It would encourage adoption of argparse so that when users's programs
> eventually increase in complexity and they do want to expand functionality,
> they would have the full power of argparse at their disposal.
> In summary, my suggestion is:
> -Expand example 15.4.1 to include the most common use cases
> -Consider splitting the "clever" example into a different section to avoid
> confusing new users.
> Sincerely,
> Tyler Barth
>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 11 04:47:55 2011
From: report at bugs.python.org (Cris Simpson)
Date: Thu, 11 Aug 2011 02:47:55 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
Message-ID: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>


New submission from Cris Simpson <crisor at gmail.com>:

In http://docs.python.org/library/socket.html, the description for socket.setdefaulttimeout(timeout) reads: 
    Set the default timeout in *floating seconds* for new socket objects.
[occurs two other times on that page]


"floating seconds" is a confusing construction. 

Suggestion: "float expressing seconds" as per socket.settimeout(value) or "seconds (float)".

----------
assignee: docs at python
components: Documentation
messages: 141892
nosy: Cris.Simpson, docs at python
priority: normal
severity: normal
status: open
title: Docs: Odd phrase "floating seconds" in socket.html
versions: Python 2.6, Python 2.7, Python 3.2

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

From python at samthompson.com  Thu Aug 11 04:00:15 2011
From: python at samthompson.com (Sam Thompson)
Date: Thu, 11 Aug 2011 12:00:15 +1000
Subject: [docs] Issue: no reference to bytes alias in documentation for
 2.6.x and 2.7 (related to closed issue 1865)
In-Reply-To: <CAPdtAj3Fw2xpcMDdOjXwq7C2oy1UGDbi7uCQsoEVccYNJW1xLg@mail.gmail.com>
References: <4E391B93.3020101@samthompson.com>
	<CAPdtAj3Fw2xpcMDdOjXwq7C2oy1UGDbi7uCQsoEVccYNJW1xLg@mail.gmail.com>
Message-ID: <4E4337AF.4040608@samthompson.com>

Sandro,

Thanks for your detailed response. In summary, I appear to have had the 
wrong end of the stick, but I've made some suggestions that may make 
things better for the doc maintainers as well as the users, particularly 
new ones like me. I hope this feedback is helpful. I appreciate the 
efforts that you and the rest of the team make with the documentation; 
please don't infer these comments are made in a critical or cynical spirit.

On 2011/08/11 10:39, Sandro Tosi wrote:
> Hello Sam,
> thanks for your email.
>
> On Wed, Aug 3, 2011 at 11:57, Sam Thompson<python at samthompson.com>  wrote:
>> Hi,
>>
>> I'm new to Python so might have the wrong end of the stick, however I noted
>> that although the py3k porting documentation (e.g. at
>> http://docs.python.org/dev/py3k/howto/pyporting.html) says that both python
>> 2.6 and 2.7 support use of b"xxx" style literals, there's no mention of it
>> in any of the 2.6.x documentation for literals (e.g.
>> http://docs.python.org/release/2.6.7/reference/lexical_analysis.html#id7).
> Currently, 2.6 is in security-fix only, so its documentation cannot be
> change anymore, that's why you don't see it fixed there.
Thanks for explaining this. I could not find any mention of this in the 
documentation itself. While I expect this may be obvious to those "in 
the know", can I suggest that this important policy be explicitly stated 
at the head of the documentation that this applies to, so that:
a) people don't waste your time filing bugs for things you have a policy 
not to fix (note that I'm complaining about the policy - it's fine), and
b) people know that the documentation is not necessarily 100% to be 
relied upon (in light of your comment below about backporting fixes), or 
alternatively, remove this documentation and redirect visitors to the 
up-to date version.
>> I found a closed bug in the issue tracker (http://bugs.python.org/issue1865)
>> which appears to originally have covered this issue but the version was
>> changed to 2.7 before it was resolved (although it's also not fixed in 2.7's
>> version at
>> http://docs.python.org/release/2.7/reference/lexical_analysis.html#id7, but
>> is fixed in 2.7.1 and 2.7.2).
>>
>> It looks like the solution used for 2.7.1+ would be appropriate for the
>> older versions, since there do not appear to be other substantial changes to
>> this part of the documentation between these versions.
> The way we release Python patch-version (x.x.N where only N is
> increased) is meant to replace N-1 and all the previous versions. So
> we don't backport documentation (nor code) fixed to 2.7.0 if the fix
> is in 2.7.1 and so on.
I appreciate this and it certainly explains the policy in relation to 
documentation updates. However, the specific use case I encountered here 
was an attempt to understand which versions of Python 2.x code I wrote 
using this b"" literal construction would be compatible with, since 
versions prior to 2.7.x are still widely deployed.

In hindsight, there may have been another approach (review of issues 
log?) that I could have used to establish the versions that support b"" 
literals. I looked for it in the documentation, noting that there is on 
the page referred to other text that discusses specific version support, 
for example at the top of the page, 3rd paragraph "New in version 2.3: 
An encoding declaration ..." and also the only footnote on this page.

It may be worth providing some more general guidance to users in the 
documentation introductory section(s) about the best way to find out 
which versions support which language constructs, if old documentation 
isn't it. Maybe the "What's new in x?" lists?

> The links you're using to access teh documentation (I don't know if
> only for showing the problem or as a general use) points to a specific
> release, that will no longer be updated. So if you want to refer to
> the lastest 2.x documentation the correct link is:
>
> http://docs.python.org/
>
> and for Python 3.x it is:
>
> http://docs.python.org/py3k/
>
The link I used to access 2.6.7 was in the left navigation of the site 
at the link http://docs.python.org/ under "Docs for other versions". 
It's true that the URLs accessed for other specific releases before 
2.7.2 and 2.6.7 were formed by extrapolation, in order to work out what 
versions of the documentation were affected by the perceived issue. That 
exercise was ultimately worthless, given the policy as now stated.

Instead, my report should have been against the current, maintained 2.x 
documentation, i.e. "Can you please add a reference in this page saying 
which version this significant change to string literals was made?". If 
you take none the other suggestions on board, which is reasonable given 
their scope and impact, can I strongly urge you to at least update the 
current versions of the 2.x and 3.x document for lexical analysis to 
this effect?

Thanks & regards,
Sam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110811/efee5f7b/attachment.html>

From tarmo.tapio at pp.inet.fi  Thu Aug 11 11:36:45 2011
From: tarmo.tapio at pp.inet.fi (Tarmo Tapio)
Date: Thu, 11 Aug 2011 12:36:45 +0300
Subject: [docs] pythonw.exe
Message-ID: <6902E873E8BA4307BFF0E6993B6D5A88@tarmoPC>

Hi
 
This is not docs bug, but I did not find any other place to write.
I'm using scitools (Pythonxy). It plots the curve of the function (Figure
window) but when I try to close Figure window I get the message 'Pythonw.exe
do not answer'. My operation system is windows 7. This happened when I'm
using Matplotlib for ploting. If I use gnuplot for plotting closing works
ok. What is the problem?
 
BR
Tarmo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110811/4925b21d/attachment.html>

From james.bateman at gmail.com  Thu Aug 11 13:19:00 2011
From: james.bateman at gmail.com (James Bateman)
Date: Thu, 11 Aug 2011 12:19:00 +0100
Subject: [docs] Minor grammatical annoyance
Message-ID: <CAPejAD8zvz2zaQR6VEmjc2Jh-wy5k3DDk9LqmG0UK5hi7Mczcw@mail.gmail.com>

In Section 15.11.2. "Window Objects" of
http://docs.python.org/library/curses.html, the note uses "then" when
it should use "than".

"A character means a C character (an ASCII code), rather then a Python
character (a string of length 1)."

Thanks for excellent work.

James

From sandro.tosi at gmail.com  Thu Aug 11 14:22:32 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 11 Aug 2011 14:22:32 +0200
Subject: [docs] pythonw.exe
In-Reply-To: <6902E873E8BA4307BFF0E6993B6D5A88@tarmoPC>
References: <6902E873E8BA4307BFF0E6993B6D5A88@tarmoPC>
Message-ID: <CAPdtAj3u3Fbi0wJW_gcgm8RzCrZh_ntzLP2eYthj8dtrAN2-5g@mail.gmail.com>

Hello Tarmo,

On Thu, Aug 11, 2011 at 11:36, Tarmo Tapio <tarmo.tapio at pp.inet.fi> wrote:
> Hi
>
> This is not docs bug, but I?did not find any other place to write.

You should write to python-list:
http://mail.python.org/mailman/listinfo/python-list (or any other
general purpose python users support forum).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 11 17:19:43 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 15:19:43 +0000
Subject: [docs] [issue12722] Link to heapq source from docs.python.org not
	working
In-Reply-To: <1312984397.54.0.684342441731.issue12722@psf.upfronthosting.co.za>
Message-ID: <1313075983.73.0.814505485935.issue12722@psf.upfronthosting.co.za>


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

The fix committed will be superseded by a link to the Mercurial repo when I fix #11435 (probably tomorrow).

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

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

From report at bugs.python.org  Thu Aug 11 18:02:45 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Aug 2011 16:02:45 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313078565.32.0.00276556211233.issue12672@psf.upfronthosting.co.za>


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

> I know perfectly well that [].append is valid Python,
> but I don't think this is the clearest way to give an example of an
> object method. I think spelling [].append's meaning more explicitly
> would be better.
Would it be clearer if we replaced the literal with a name?

  These C functions are called ?type methods? to distinguish them from
- things like [].append (which we call ?object methods?).
+ methods bound to specific instances (things like sys.path.append),
+ which we call ?object methods?.

> I'm also aware that there are tab problems all over the code base.
> I'm not suggesting a large cleanup.
*I* was suggesting a large cleanup :), but we can do that in another commit.  If you want to clean the example code in Doc/extending or even just in newtypes.rst, I think you can just go ahead.

----------

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

From report at bugs.python.org  Fri Aug 12 04:36:31 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 02:36:31 +0000
Subject: [docs] [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313116591.64.0.0484807939011.issue11230@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

How does this work for modules that have filesystem names different from the one used for import? The issue I'm thinking about is that the Mac HSF+ filesystem keeps its Unicode filenames in (close to) NFD form. That means that a module named "caf\N{LATIN SMALL LETTER E WITH ACUTE}" with 4 graphemes and 4 code points in its name winds up in the filesystem as "cafe\N{COMBINING ACUTE ACCENT}" still with 4 graphemes but now with 5 code points.

I believe (well, suspect; I have empirical evidence not proof) Python stores its own identifiers in NFD, so this may not be quite as much of a problem as it might otherwise be.  Nonetheless, I have had users complain about what HFS+ does with such filenames, although I am not quite sure why. I think it?s because they access a file with 4 chars but they need a 5-char fileglob to wildcard it, so touch "caf\N{LATIN SMALL LETTER E WITH ACUTE}" and then you need a wildcard of "?????" with an extra ? to find it. Kinda weird.

----------
nosy: +tchrist

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

From report at bugs.python.org  Fri Aug 12 10:41:01 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Aug 2011 08:41:01 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QrnIZ-0001P3-Kp@dinsdale.python.org>


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

New changeset 683202530137 by Eli Bendersky in branch 'default':
Issue #12672: fix code samples in extending/newtypes.html for PEP-7 compliance
http://hg.python.org/cpython/rev/683202530137

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

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

From report at bugs.python.org  Fri Aug 12 10:41:36 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:41:36 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313138496.71.0.225286325109.issue12672@psf.upfronthosting.co.za>


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


----------
keywords:  -easy
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Aug 12 10:43:43 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:43:43 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313138623.38.0.455349240903.issue12672@psf.upfronthosting.co.za>


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

> Would it be clearer if we replaced the literal with a name?
>
>  These C functions are called ?type methods? to distinguish them from
> - things like [].append (which we call ?object methods?).
> + methods bound to specific instances (things like sys.path.append),
> + which we call ?object methods?.

No, I don't think this is the intention (bound vs. unbound). I think the distinction is between special methods recognized by Python, and "plain object methods" defined by the user. Not sure how to express this clearly in the docs though.

Re PEP-7 cleanup: done some for extending/newtypes.html - not sure everything is fixed but it's a bit better now.

----------

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

From report at bugs.python.org  Fri Aug 12 10:54:30 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Aug 2011 08:54:30 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313139270.82.0.442008358841.issue12672@psf.upfronthosting.co.za>


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

Maybe it should say:

"... to distinguish them from custom class methods such as list's append"

I think this is more correct, because it clearly refers to the methods placed in the 'tp_methods' field of a type.


... and also drop the (which we call "object methods") since this terminology isn't actually being used in the rest of the article.

----------

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

From report at bugs.python.org  Fri Aug 12 15:13:09 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Fri, 12 Aug 2011 13:13:09 +0000
Subject: [docs] [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313154789.8.0.706204250393.issue11230@psf.upfronthosting.co.za>


Tom Christiansen <tchrist at perl.com> added the comment:

Whoops, I meant that it appears that Python runs its identifiers through NFC.  How that gets along with a filesystem that has quasi-NFD filenames I'm not sure, but it seems like it might be a variant of the case-insensitivity issue in filenames.

----------

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

From report at bugs.python.org  Fri Aug 12 15:18:18 2011
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 12 Aug 2011 13:18:18 +0000
Subject: [docs] [issue11230] "Full unicode import system" not in 3.2
In-Reply-To: <1297926635.95.0.756299771372.issue11230@psf.upfronthosting.co.za>
Message-ID: <1313155098.08.0.592683077737.issue11230@psf.upfronthosting.co.za>


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

> The issue I'm thinking about is that the Mac HSF+ filesystem

There is no issue with HFS+ normalization. The kernel "normalizes" filenames to its own variant, Python doesn't have to care about this.

When you write "import h<? normalized to NFC>" or "import h<? normalized to NFD>", Python tries to open "h<? normalized to NFC>.py": then the HFS+ filename does its own normalization (=> "h<? normalized to its variant of NFD>.py").

----------

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

From report at bugs.python.org  Fri Aug 12 16:43:03 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 12 Aug 2011 14:43:03 +0000
Subject: [docs] [issue12743] C API marshalling doc contains XXX
Message-ID: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>


New submission from JJeffries <jamesjeffries1 at gmail.com>:

The Python C API manual page for data marshaling contains the following paragraph.

XXX What about error detection? It appears that reading past the end of the file will always result in a negative numeric value (where that?s relevant), but it?s not clear that negative values won?t be handled properly when there?s no error. What?s the right way to tell? Should only non-negative values be written using these routines?

I suggest that the XXX should be removed as it is unclear why it's there.

Patch to follow in the next couple of days if others agree.

----------
assignee: docs at python
components: Documentation
messages: 141959
nosy: JJeffries, docs at python
priority: normal
severity: normal
status: open
title: C API marshalling doc contains XXX

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

From report at bugs.python.org  Fri Aug 12 16:47:44 2011
From: report at bugs.python.org (JJeffries)
Date: Fri, 12 Aug 2011 14:47:44 +0000
Subject: [docs] [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1313160464.74.0.302486380395.issue12195@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

While I understand the reluctance to unintentionally push people along a particular path, but I think there is being open on how to use it and not mentioning it. I think that currently the current documentation is the latter and some simple examples showing the syntax would go a long way.

Most of my understanding of annotations has come from the PEP for it and mailing lists.

----------

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

From report at bugs.python.org  Fri Aug 12 17:25:24 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 15:25:24 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313162724.8.0.409535859832.issue12672@psf.upfronthosting.co.za>


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

> I think the distinction is between special methods recognized by
> Python, and "plain object methods" defined by the user.

Do you mean __special__ methods?  Re-reading the whole paragraph, I can?t tell :(

----------

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

From report at bugs.python.org  Fri Aug 12 17:38:33 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Aug 2011 15:38:33 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313163513.21.0.444634760286.issue12672@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug 12 18:20:30 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:20:30 +0000
Subject: [docs] [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1313166030.16.0.677381263816.issue12716@psf.upfronthosting.co.za>


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

+1

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

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

From report at bugs.python.org  Fri Aug 12 18:22:22 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:22:22 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313166142.83.0.10722650534.issue12725@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +eric.araujo
stage:  -> needs patch
versions: +Python 3.3 -Python 2.6

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

From report at bugs.python.org  Fri Aug 12 18:25:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 16:25:46 +0000
Subject: [docs] [issue11233] clarifying Availability: Unix
In-Reply-To: <1297969399.53.0.187875867799.issue11233@psf.upfronthosting.co.za>
Message-ID: <1313166345.85.0.209234362792.issue11233@psf.upfronthosting.co.za>


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

If no-one else has started on this, I?m interested in making a patch to introduce an availability directive.

----------
nosy: +eric.araujo
resolution: works for me -> 
stage:  -> needs patch

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

From sandro.tosi at gmail.com  Fri Aug 12 19:13:12 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 12 Aug 2011 19:13:12 +0200
Subject: [docs] English trans fix for urllib docs
In-Reply-To: <CAP8_LBGPW2rYPdD4Kh2OYqb2FppM8KC_CGG5j_riE-BdDqhYdQ@mail.gmail.com>
References: <CAP8_LBGPW2rYPdD4Kh2OYqb2FppM8KC_CGG5j_riE-BdDqhYdQ@mail.gmail.com>
Message-ID: <CAPdtAj3bGZai=BYNNVimrDo-f+oM_4LQOX5MZHoEhKfbKuEJHQ@mail.gmail.com>

Hello Mike,
thanks for your email.

On Mon, Jul 18, 2011 at 16:19, Mike MacCana <mike at potatolondon.com> wrote:
> Hi folks,
>
> http://docs.python.org/library/urllib.html currently reads:
>
> Warning: When opening HTTPS URLs, it is not attempted to validate the
> server certificate. Use at your own risk!
>
> In English you'd normally use 'does not attempt to' rather than 'it is
> not attempted to'. Suggest:

It is now fixed with: http://hg.python.org/cpython/rev/ba701fb169d1 - thanks!

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Fri Aug 12 19:19:17 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 12 Aug 2011 19:19:17 +0200
Subject: [docs] Function return types
In-Reply-To: <BANLkTikYJyCxzQ_Qy5Byq2+n7KPbwr594w@mail.gmail.com>
References: <BANLkTikYJyCxzQ_Qy5Byq2+n7KPbwr594w@mail.gmail.com>
Message-ID: <CAPdtAj3znSuY+QahG-_GZ9L97orMCwitVNb2rijuPu3RbJq30g@mail.gmail.com>

Hello Sven,
thanks for your email.

On Thu, Jun 2, 2011 at 21:50, Sven Brauch <svenbrauch at googlemail.com> wrote:
> Hi there!
>
> I noticed there's no standard way on docs.python.org in which return
> types of functions are specified. Sometimes the return type can be
> read out of the description, sometimes it can't; but there's no easy
> way to see what kind of data a function is likely to return. What do
> you think about adding such an attribute? I'd be happy to help adding
> those where it seems necessary.

Python is a dynamic typing language, so it doesn't have the concept of
"function return type" (a-la C or Java, where you define in your code
what's the type that function will return), but it's the behavior of
the returned object that defines what it is (duck typing)

I'm sure you can find a lot of material on the web about it, but
there's nothing to be fixed in the doc.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Fri Aug 12 19:31:33 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:31:33 +0000
Subject: [docs] [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1313170293.74.0.0405794255528.issue12743@psf.upfronthosting.co.za>


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

It should be removed if someone is confident that it?s a obsolete comment, or if tests get added to answer the questions in the note.

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

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

From sandro.tosi at gmail.com  Fri Aug 12 19:34:31 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 12 Aug 2011 19:34:31 +0200
Subject: [docs] Minor grammatical annoyance
In-Reply-To: <CAPejAD8zvz2zaQR6VEmjc2Jh-wy5k3DDk9LqmG0UK5hi7Mczcw@mail.gmail.com>
References: <CAPejAD8zvz2zaQR6VEmjc2Jh-wy5k3DDk9LqmG0UK5hi7Mczcw@mail.gmail.com>
Message-ID: <CAPdtAj3hoPAcXT9-R+k-VrSrmNg5sAOhzuvC4Y3RP+xCOLJafw@mail.gmail.com>

Hello James,
thanks fro your email.

On Thu, Aug 11, 2011 at 13:19, James Bateman <james.bateman at gmail.com> wrote:
> In Section 15.11.2. "Window Objects" of
> http://docs.python.org/library/curses.html, the note uses "then" when
> it should use "than".

It is now fixed: http://hg.python.org/cpython/rev/79764f08ffd4 - thanks!

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Fri Aug 12 19:47:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 17:47:28 +0000
Subject: [docs] [issue12706] timeout sentinel in ftplib and poplib
	documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1313171248.72.0.8459922933.issue12706@psf.upfronthosting.co.za>


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


----------
components: +Documentation

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

From report at bugs.python.org  Fri Aug 12 19:56:16 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Aug 2011 17:56:16 +0000
Subject: [docs] [issue12726] explain why locale.getlocale() does not read
	system's	locales
In-Reply-To: <1313054335.82.0.864365511342.issue12726@psf.upfronthosting.co.za>
Message-ID: <1313171776.48.0.616527536467.issue12726@psf.upfronthosting.co.za>


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


----------
nosy: +docs at python, eric.araujo
stage:  -> needs patch
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 12 20:22:29 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:22:29 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313173349.06.0.882343515406.issue12725@psf.upfronthosting.co.za>


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

I agree 'floating seconds' is bad. I think I prefer your second alternative, but settimeout() and setdefaulttimeout should be consistent.

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

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

From report at bugs.python.org  Fri Aug 12 20:58:25 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 18:58:25 +0000
Subject: [docs] [issue12726] explain that locale.getlocale() does not read
	system's	locales
In-Reply-To: <1313054335.82.0.864365511342.issue12726@psf.upfronthosting.co.za>
Message-ID: <1313175505.38.0.302325792409.issue12726@psf.upfronthosting.co.za>


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

Our docs explain behavior without, generally, explaining why. Hence the title change.

'Returns the current setting for the given locale category' seems pretty clear that it returns the current program setting rather than the default system setting. However, 'program' could be added to be clearer.

The previous discussion for locale.getdefaultlocale makes it clear that the starting program locale is (should be) the "portable 'C' locale". I presume you are saying that in this locale, the setting for the default LC_CTYPE category is (None,None). However, this appears to currently only be true for 2.7. So I suppose we could add for 2.7 "In the starting 'C' locale, the LC_CTYPE setting is (None,None)." (Given the next paragraph describing 'C' as a non-standard language code, I would have expected ('C',None), but it is as it is.)

Reading #6203, something different is needed for 3.2 and something else again might be needed for 3.3 depending on what is or is not done.

----------
nosy: +terry.reedy
title: explain why locale.getlocale() does not read system's locales -> explain that locale.getlocale() does not read system's locales

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

From sandro.tosi at gmail.com  Fri Aug 12 21:22:58 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 12 Aug 2011 21:22:58 +0200
Subject: [docs] Issue: no reference to bytes alias in documentation for
 2.6.x and 2.7 (related to closed issue 1865)
In-Reply-To: <4E4337AF.4040608@samthompson.com>
References: <4E391B93.3020101@samthompson.com>
	<CAPdtAj3Fw2xpcMDdOjXwq7C2oy1UGDbi7uCQsoEVccYNJW1xLg@mail.gmail.com>
	<4E4337AF.4040608@samthompson.com>
Message-ID: <CAPdtAj3fG6OwyyS72A5X4Zarz3iU0zfqzto_vL3FzH0TFBBcMg@mail.gmail.com>

Hello Sam,
you wrote a lot, I'll try to reply to all your points, but I'll be
dense: don't take thta for disrespect.

On Thu, Aug 11, 2011 at 04:00, Sam Thompson <python at samthompson.com> wrote:
> Sandro,
>
> Thanks for your detailed response. In summary, I appear to have had the
> wrong end of the stick, but I've made some suggestions that may make things
> better for the doc maintainers as well as the users, particularly new ones
> like me. I hope this feedback is helpful. I appreciate the efforts that you
> and the rest of the team make with the documentation; please don't infer
> these comments are made in a critical or cynical spirit.
>
> On 2011/08/11 10:39, Sandro Tosi wrote:
>
> Hello Sam,
> thanks for your email.
>
> On Wed, Aug 3, 2011 at 11:57, Sam Thompson <python at samthompson.com> wrote:
>
> Hi,
>
> I'm new to Python so might have the wrong end of the stick, however I noted
> that although the py3k porting documentation (e.g. at
> http://docs.python.org/dev/py3k/howto/pyporting.html) says that both python
> 2.6 and 2.7 support use of b"xxx" style literals, there's no mention of it
> in any of the 2.6.x documentation for literals (e.g.
> http://docs.python.org/release/2.6.7/reference/lexical_analysis.html#id7).
>
> Currently, 2.6 is in security-fix only, so its documentation cannot be
> change anymore, that's why you don't see it fixed there.
>
> Thanks for explaining this. I could not find any mention of this in the
> documentation itself. While I expect this may be obvious to those "in the
> know", can I suggest that this important policy be explicitly stated at the
> head of the documentation that this applies to, so that:
> a) people don't waste your time filing bugs for things you have a policy not
> to fix (note that I'm complaining about the policy - it's fine), and
> b) people know that the documentation is not necessarily 100% to be relied
> upon (in light of your comment below about backporting fixes), or
> alternatively, remove this documentation and redirect visitors to the up-to
> date version.

You're actually suggesting to add a banner to every single page of doc
for older release, which is unfeasible. We provide documentation for
older versions "as was" when that version was last released, I don't
see the point in explaining what's the status of a specific version in
its doc.

python.org/doc makes quite clear what are the supported doc version,
linking only one for 2.x and 3.x .

> I found a closed bug in the issue tracker (http://bugs.python.org/issue1865)
> which appears to originally have covered this issue but the version was
> changed to 2.7 before it was resolved (although it's also not fixed in 2.7's
> version at
> http://docs.python.org/release/2.7/reference/lexical_analysis.html#id7, but
> is fixed in 2.7.1 and 2.7.2).
>
> It looks like the solution used for 2.7.1+ would be appropriate for the
> older versions, since there do not appear to be other substantial changes to
> this part of the documentation between these versions.
>
> The way we release Python patch-version (x.x.N where only N is
> increased) is meant to replace N-1 and all the previous versions. So
> we don't backport documentation (nor code) fixed to 2.7.0 if the fix
> is in 2.7.1 and so on.
>
> I appreciate this and it certainly explains the policy in relation to
> documentation updates. However, the specific use case I encountered here was
> an attempt to understand which versions of Python 2.x code I wrote using
> this b"" literal construction would be compatible with, since versions prior
> to 2.7.x are still widely deployed.
>
> In hindsight, there may have been another approach (review of issues log?)

or the what's new section of the latest documentation.

> that I could have used to establish the versions that support b"" literals.
> I looked for it in the documentation, noting that there is on the page
> referred to other text that discusses specific version support, for example
> at the top of the page, 3rd paragraph "New in version 2.3: An encoding
> declaration ..." and also the only footnote on this page.
>
> It may be worth providing some more general guidance to users in the
> documentation introductory section(s) about the best way to find out which
> versions support which language constructs, if old documentation isn't it.
> Maybe the "What's new in x?" lists?

that's exactly the entry point you're looking for: just note that not
every change ends up there.

> The links you're using to access teh documentation (I don't know if
> only for showing the problem or as a general use) points to a specific
> release, that will no longer be updated. So if you want to refer to
> the lastest 2.x documentation the correct link is:
>
> http://docs.python.org/
>
> and for Python 3.x it is:
>
> http://docs.python.org/py3k/
>
> The link I used to access 2.6.7 was in the left navigation of the site at
> the link http://docs.python.org/ under "Docs for other versions". It's true

exactly, so you didn't use the latest documentation available :) of
course, that's related a version of Python you don't have on your
machine.

> that the URLs accessed for other specific releases before 2.7.2 and 2.6.7
> were formed by extrapolation, in order to work out what versions of the
> documentation were affected by the perceived issue. That exercise was
> ultimately worthless, given the policy as now stated.
>
> Instead, my report should have been against the current, maintained 2.x
> documentation, i.e. "Can you please add a reference in this page saying
> which version this significant change to string literals was made?". If you

sometimes it is done, for example in case we add new methods there's
often a "Added in: X.Y" tag at the end.

> take none the other suggestions on board, which is reasonable given their
> scope and impact, can I strongly urge you to at least update the current
> versions of the 2.x and 3.x document for lexical analysis to this effect?

It *is* fixed, as you said, in 2.7.1 and 2.7.2 : the latter version is
the current one, so case closed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Aug 13 00:43:13 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 13 Aug 2011 00:43:13 +0200
Subject: [docs] usage of the cfunc directive
In-Reply-To: <BANLkTinK3+mr-NRFi-muJDDjv0WRULsoxg@mail.gmail.com>
References: <BANLkTinK3+mr-NRFi-muJDDjv0WRULsoxg@mail.gmail.com>
Message-ID: <CAPdtAj1rbquQY-pmXDEO449=O0T2Nh60sCpv01gxe1XgMXNZHA@mail.gmail.com>

Hello,

On Sun, Jun 12, 2011 at 17:54, tomo cocoa <cocoatomo77 at gmail.com> wrote:
> Hello,
>
> I am a Japanese Python-philia.
>
> There are documentation bug(?) in Python/C API Reference Manual v2.7.2
> and v3.1.3.
> At the explanation on PySequence_ITEM of the page "Sequence Protocol",
> the word "PySequence_Check(o)()" appears.
>
> This word is converted from ":cfunc:`PySequence_Check(o)`" in the
> corresponding Sphinx source.

This is now fixed: http://hg.python.org/cpython/rev/0937a0986b66 - thanks!

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From svenbrauch at googlemail.com  Sat Aug 13 00:38:58 2011
From: svenbrauch at googlemail.com (Sven Brauch)
Date: Sat, 13 Aug 2011 00:38:58 +0200
Subject: [docs] Function return types
In-Reply-To: <CAPdtAj3znSuY+QahG-_GZ9L97orMCwitVNb2rijuPu3RbJq30g@mail.gmail.com>
References: <BANLkTikYJyCxzQ_Qy5Byq2+n7KPbwr594w@mail.gmail.com>
	<CAPdtAj3znSuY+QahG-_GZ9L97orMCwitVNb2rijuPu3RbJq30g@mail.gmail.com>
Message-ID: <CAE_ay6kpb5z=GRmCyOqoFuJviSjPYjEp14Tviq7Z0asYfcVzVg@mail.gmail.com>

Hi there,

I see your point, but still there's not an infinite number of things a
function could return. For example, PIL.Image.new() will always give
an instance of the "Image" class, or len() will always return an
integer. In fact I think it's like this for most functions. Of course,
it's not possible to specify return types for a few exceptions, but
couldn't it be done for those functions where it's easily possible? I
think this would be an improvement.

Best regards,
Sven

2011/8/12 Sandro Tosi <sandro.tosi at gmail.com>:
> Hello Sven,
> thanks for your email.
>
> On Thu, Jun 2, 2011 at 21:50, Sven Brauch <svenbrauch at googlemail.com> wrote:
>> Hi there!
>>
>> I noticed there's no standard way on docs.python.org in which return
>> types of functions are specified. Sometimes the return type can be
>> read out of the description, sometimes it can't; but there's no easy
>> way to see what kind of data a function is likely to return. What do
>> you think about adding such an attribute? I'd be happy to help adding
>> those where it seems necessary.
>
> Python is a dynamic typing language, so it doesn't have the concept of
> "function return type" (a-la C or Java, where you define in your code
> what's the type that function will return), but it's the behavior of
> the returned object that defines what it is (duck typing)
>
> I'm sure you can find a lot of material on the web about it, but
> there's nothing to be fixed in the doc.
>
> Regards,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

From report at bugs.python.org  Sat Aug 13 00:46:49 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Aug 2011 22:46:49 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313189209.05.0.770306685789.issue12731@psf.upfronthosting.co.za>


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

However desireable it would be, I do not believe there is any claim in the manual that the re module follows the evolving Unicode consortium r.e. standard. If I understand, you are saying that this statement in the doc, "Matches Unicode word characters;" is not now correct and should be revised. Was it once correct? Could we add "by an older definition of 'word' character"?

There has been some discussion of adding regex to the stdlib, possibly as a replacement for re. You posts indicate that regex is more improved then some realized, and hence has more incompatibilities that we realized, and hence is less suitable as a strictly backwards-compatible replacement. So I think it needs to be looked at as a parallel addition. I do not know Mathew's current position on the subject.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou, terry.reedy
stage:  -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 13 01:47:35 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 12 Aug 2011 23:47:35 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313192855.73.0.64918411163.issue12672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Eli, I interpreted it the same way you did.  In the doc, "type methods" are those that map directly to PyTypeObject.  Any custom type methods go in tp_methods.  You could almost call the former "PyTypeObject methods" rather than "type methods".  And both are distinct from functions/methods in a type's __dict__...

Also I agree that the "object methods" statement is unnecessary.

----------
nosy: +ericsnow

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

From report at bugs.python.org  Sat Aug 13 01:48:49 2011
From: report at bugs.python.org (Eric Snow)
Date: Fri, 12 Aug 2011 23:48:49 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313192929.69.0.13321920708.issue12672@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

http://docs.python.org/dev/extending/newtypes.html

----------

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

From report at bugs.python.org  Sat Aug 13 02:18:24 2011
From: report at bugs.python.org (Tom Christiansen)
Date: Sat, 13 Aug 2011 00:18:24 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313189209.05.0.770306685789.issue12731@psf.upfronthosting.co.za>
Message-ID: <27372.1313194678@chthon>


Tom Christiansen <tchrist at perl.com> added the comment:

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

> However desireable it would be, I do not believe there is any claim in the =
> manual that the re module follows the evolving Unicode consortium r.e. stan=

My from the hip thought is that if re cannot be fixed to follow
the Unicode Standard, it should be deprecated in favor of code
that can if such is available, because you cannot process Unicode
text with regular expressions otherwise.

> dard. If I understand, you are saying that this statement in the doc, "Matc=
> hes Unicode word characters;" is not now correct and should be revised. Was=
>  it once correct? Could we add "by an older definition of 'word' character"=
> ?

Yes, your hunch is exactly correct.  They once had a lesser definition that
they have now.  It is very very old.  I had to track this down for Java
once.  There is some discussion of a "word_character class" at least 
as far back as tr18v3 from back in 1998.

    http://www.unicode.org/reports/tr18/tr18-3.html

By the time tr18v5 rolled around just a year later in 1999, the overall
document has changed substantially, and you can clearly see its current
shape there.  Word characters are supposed to include all code points with
the Alphabetic property, for example.  

    http://www.unicode.org/reports/tr18/tr18-5.html

However, the word "alphabetic" has *never* been synonymous in 
Unicode with 

    \p{gc=Lu}
    \p{gc=Ll}
    \p{gc=Lt}
    \p{gc=Lm}
    \p{gc=Lo}

as many people incorrectly assume, nor certainly to 

    \p{gc=Lu}
    \p{gc=Ll}
    \p{gc=Lt}

let alone to 

    \p{gc=Lu}
    \p{gc=Ll}

Rather, it has since its creation included code points that are not
letters, such as all GC=Nl and also certain GC=So code points.  And,
notoriously, U+0345. Indeed it is here I first noticed that that Python had
already broken with the Standard, because U+0345 COMBINING GREEK
YPOGEGRAMMENI is GC=Mn, but Alphabetic=True, yet I have shown that 
Python's title method is messing up there.  

I wouldn't spend too much in archaeological digs, though, because lots of
stuff has changed since the less millennium.  It was in tr18v7 from 2003-05
that we hit paydirt, because this is when the famous Annex C of RL1.2a 
fame first appeared:

    http://www.unicode.org/reports/tr18/tr18-7.html#Compatibility_Properties

Notice how it defines \w to be nothing more than \p{alpha}, \p{digit}, and
\p{gc=Pc}.  It does not yet contain the requirement that all Marks be
counted as part of the word, just the few that are alphas -- which the
U+0345 counts for, since it has an uppercase map of a capital iota!

That particular change did not occur until tr18v8 in 2003-08, barely
a scant three months later.

    http://www.unicode.org/reports/tr18/tr18-8.html#Compatibility_Properties

Now at last we see word characters defined in the modern way that we 
have become used to.  They must match any of:

    \p{alpha}
    \p{gc=Mark}
    \p{digit}
    \p{gc=Connector_Punctuation}

BTW, Python is matching  all of 

    \p{GC=N}

meaning

    \p{GC=Nd}
    \p{GC=Nl}
    \p{GC=No}

instead of the required 

    \p{GC=Nd}

which is a synonym for \p{digit}.

I don't know had that happened, because \w has never included
all number code points in Unicode, only the decimal number ones.

That all goes to show why, when citing conformance to some aspect of 
The Unicode Standard, one must be exceedingly careful just how one 
does so!
The Unicode Consortium recognizes this is an issue, and I am pretty
sure I can hear it in your own subtext as well.  

Kindly bear with and forgive me for momentarily sounding like a standard
lawyer.  I do this because to show not just why it is important to get
references to the Unicode Standard correct, but indeed, how to do so.

After I have given the formal requirements, I will then produce
illustrations of various purported claims, some of which meet the
citation requirements, and others which do not.

=======================================================================

To begin with, there is an entire technical report on conformance.
It includes:

    http://unicode.org/reports/tr33/

    The Unicode Standard [Unicode] is a very large and complex standard.
    Because of this complexity, and because of the nature and role of the
    standard, it is often rather difficult to determine, in any particular
    case, just exactly what conformance to the Unicode Standard means.

...

    Conformance claims must be specific to versions of the Unicode
    Standard, but the level of specificity needed for a claim may vary
    according to the nature of the particular conformance claim. Some
    standards developed by the Unicode Consortium require separate
    conformance to a specific version (or later), of the Unicode Standard.
    This version is sometimes called the  base version. In such cases, the
    version of the standard and the version of the Unicode Standard to
    which the conformance claim refers must be compatible.

However, you don't need to read tr33, really, because *the* most important
thing bits about conformance are to be found on pp. 57-58 of Chapter 3 of
the published Unicode Standard:

    http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf

    References to the Unicode Standard

    The documents associated with the major, minor, and update versions are called the major
    reference, minor reference, and update reference, respectively. For example, consider Uni-
    code Version 3.1.1. The major reference for that version is The Unicode Standard, Version
    3.0 (ISBN 0-201-61633-5). The minor reference is Unicode Standard Annex #27, "The Uni-
    code Standard, Version 3.1." The update reference is Unicode Version 3.1.1. The exact list of
    contributory files, Unicode Standard Annexes, and Unicode Character Database files can
    be found at Enumerated Version 3.1.1.

    The reference for this version, Version 6.0.0, of the Unicode Standard, is

         The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined
         by: The Unicode Standard, Version 6.0 (Mountain View, CA: The Uni-
         code Consortium, 2011. ISBN 978-1-936213-01-6)

    References to an update (or minor version prior to Version 5.2.0) include a reference to
    both the major version and the documents modifying it. For the standard citation format
    for other versions of the Unicode Standard, see "Versions" in Section B.6, Other Unicode
    Online Resources.

    Precision in Version Citation

    Because Unicode has an open repertoire with relatively frequent updates, it is important
    not to over-specify the version number. Wherever the precise behavior of all Unicode char-
    acters needs to be cited, the full three-field version number should be used, as in the first
    example below. However, trailing zeros are often omitted, as in the second example. In such
    a case, writing 3.1 is in all respects equivalent to writing 3.1.0.

       1. The Unicode Standard, Version 3.1.1
       2. The Unicode Standard, Version 3.1
       3. The Unicode Standard, Version 3.0 or later
       4. The Unicode Standard

    Where some basic level of content is all that is important, phrasing such as in the third
    example can be used. Where the important information is simply the overall architecture
    and semantics of the Unicode Standard, the version can be omitted entirely, as in example 4.

    References to Unicode Character Properties

    Properties and property values have defined names and abbreviations, such as

	  Property:           General_Category (gc)
	  Property Value: Uppercase_Letter (Lu)

    To reference a given property and property value, these aliases are used, as in this example:

	  The property value Uppercase_Letter from the General_Category prop-
	  erty, as specified in Version 6.0.0 of the Unicode Standard.

    Then cite that version of the standard, using the standard citation format that is provided
    for each version of the Unicode Standard.

    When referencing multi-word properties or property values, it is permissible to omit the
    underscores in these aliases or to replace them by spaces.

    When referencing a Unicode character property, it is customary to prepend the word "Uni-
    code" to the name of the property, unless it is clear from context that the Unicode Standard
    is the source of the specification.

    References to Unicode Algorithms

    A reference to a Unicode algorithm must specify the name of the algorithm or its abbrevia-
    tion, followed by the version of the Unicode Standard, as in this example:

      The Unicode Bidirectional Algorithm, as specified in Version
      6.0.0 of the Unicode Standard.

      See Unicode Standard Annex #9, "Unicode Bidirectional Algorithm,"
      (http://www.unicode.org/reports/tr9/tr9-23.html)

=======================================================================

Now for some concrete citation examples, both correct and dubious.

In the JDK7 documentation for on the Character class we find:

    Character information is based on the Unicode Standard, version 6.0.0.

That one is a perfectly good conformance citation, even if there seems 
a bit of wiggle in "is based on", but no matter.  It is short and does
everything it needs to.

However, in the JDK7 documentation for the Pattern class we
somewhat problematically find:

     Unicode support 

     This class is in conformance with Level 1 of Unicode Technical
     Standard #18: Unicode Regular Expression, plus RL2.1 Canonical
     Equivalents.

And similarly, in the JDK7 documentation for the Normalizer class we find:

    This class provides the method normalize which transforms Unicode
    text into an equivalent composed or decomposed form, allowing for
    easier sorting and searching of text. The normalize method supports
    the standard normalization forms described in  Unicode Standard
    Annex #15 ? Unicode Normalization Forms.

The problem with those second two Java refs is that they to my reading
appear to be in technical violation, for they give neither a full
version number nor a date of publication.  

You *have* to give one or the other, or both.  

Java got themselves into a heap of trouble (so to speak) over
this once before because it turned out that the version of the
document they were actually in conformance with was quite
literally from the previous millennium!!

That's why you need to give versions and publication dates.

Here are some other citations.

First, from the perldelta manpage that the Perl 5.14 release ships with:

       Perl comes with the Unicode 6.0 data base updated with Corrigendum
       #8 <http://www.unicode.org/versions/corrigendum8.html>, with one
       exception noted below.  See <http://unicode.org/versions/Unicode6.0.0/> 
       for details on the new release.  Perl does not support any Unicode 
       provisional properties, including the new ones for this release.

That is quite complete, as it even includes the specific which
corrigenda we follow and explains the matter of properties.

Or this from the perlunicode manpage of that same release:

   Unicode Regular Expression Support Level
       The following list of Unicode supported features for
       regular expressions describes all features currently
       directly supported by core Perl.  The references to "Level
       N" and the section numbers refer to the Unicode Technical
       Standard #18, "Unicode Regular Expressions", version 13,
       from August 2008.

See all that?  Notice how it gives the name of the document, its revision
number, and its publication date.  You don't have to do all that for the
main Unicode release, but you really ought to when referring to individual
technical reports BECAUSE THESE GET UPDATED ASYNCRONOUSLY.

I would suggest you pick a version of tr18 that you conform to,
and state which of its requirements you do and do not meet.

However, I cannot find any version of tr18 that has existed during the
present millennium that Python comes even close to meeting more than one
or two requirements for.  Given that, it may be better to no longer make
any claims regarding Unicode at all.  That seems like back-peddaling to
me, not future-thinking.

Matthew's regex module, however, does *almost* everything right that re
does wrong.  It may be that as with Java's io vs nio classes (and now
heaven forbid nio2!), you actually can't fix the only module and must
create a wholly new namespace.  I cannot answer that.

For RL1.2 proper, the first properties requirement, Java was only missing a
few, so they went and added the missing properties.  I strongly urge you to
do so because you cannot handle Unicode without properties.  Rl1.2 requires
only 11 of them, so it isn't too hard.  Matthew supports many many more.

However, because the \w&c issues are bigger, Java addressed the tr18 RL1.2a
issues differently, this time by creating a new compilation flag called
UNICODE_CHARACTER_CLASSES (with corresponding embedded "(?U)" regex flag.)

Truth be told, even Perl has secret pattern compilation flags to govern
this sort of thing (ascii, locale, unicode), but we (well, I) hope you
never have to use or even notice them.  

That too might be a route forward for Python, although I am not quite sure
how much flexibility and control of your lexical scope you have.  However,
the "from __future_" imports suggest you may have enough to do something
slick so that only people who ask for it get it, and also importantly that
they get it all over the place so don't have to add an extra flag or u'...'
or whatever every single time.  

This isn't something I've looked much into, however.

Hope this clarifies things.

--tom

----------

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

From report at bugs.python.org  Sat Aug 13 02:57:20 2011
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Aug 2011 00:57:20 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313197040.47.0.967107991822.issue12731@psf.upfronthosting.co.za>


Changes by Matthew Barnett <python at mrabarnett.plus.com>:


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

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

From report at bugs.python.org  Sat Aug 13 04:35:56 2011
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Bernardo?=)
Date: Sat, 13 Aug 2011 02:35:56 +0000
Subject: [docs] [issue12745] Python2 or Python3 page
Message-ID: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>


New submission from Jo?o Bernardo <jbvsmo at gmail.com>:

Since 2008 (as far as can remember) the Python Download page has a link to that web page:
http://wiki.python.org/moin/Python2orPython3

I know it's been updated but it keeps saying the same thing since Python 3.0 was launched.

Basically it says that Python 3 is awesome but please don't use it because not everything became compatible. (That's how a newcomer reads it).

I've been using Python 3 as replacement of Python 2 since the launch of 3.1... And now I can't even write a Python 2 code without feeling a little sick.

I pretty much think it's time to tell people to skip learning all that junk the dev team had to remove and start with something much nicer.

Think about it. You'll not have to worry if list comprehensions/generator expressions are available, the conditional operator, the boolean type (and True and False as keywords), decorators, the ability of having `non local` variables, extended tuple unpacking etc etc etc.

If nobody uses the next generation of the language, the developers won't port their code. If they don't port the code, no one can use it...


tl;dr

So I vote for a new page saying something like "Python 3 is the way you should go and, if you can't run something, try asking the developer to port it or choose another tool"

BTW, Those PyPI modules that haven't made any effort to port should be marked as `deprecated`, but that doesn't have anything to do with the change of the aforementioned web page.


-------
Sorry if that doesn't belong to a bug report and erase it if you want.

----------
assignee: docs at python
components: Documentation
messages: 142004
nosy: JBernardo, docs at python
priority: normal
severity: normal
status: open
title: Python2 or Python3 page
versions: Python 3.2, Python 3.3

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

From python at samthompson.com  Sat Aug 13 04:10:58 2011
From: python at samthompson.com (Sam Thompson)
Date: Sat, 13 Aug 2011 12:10:58 +1000
Subject: [docs] Issue: no reference to bytes alias in documentation for
 2.6.x and 2.7 (related to closed issue 1865)
In-Reply-To: <CAPdtAj3fG6OwyyS72A5X4Zarz3iU0zfqzto_vL3FzH0TFBBcMg@mail.gmail.com>
References: <4E391B93.3020101@samthompson.com>
	<CAPdtAj3Fw2xpcMDdOjXwq7C2oy1UGDbi7uCQsoEVccYNJW1xLg@mail.gmail.com>
	<4E4337AF.4040608@samthompson.com>
	<CAPdtAj3fG6OwyyS72A5X4Zarz3iU0zfqzto_vL3FzH0TFBBcMg@mail.gmail.com>
Message-ID: <4E45DD32.1010101@samthompson.com>

Sandro,

On 2011/08/13 05:22, Sandro Tosi wrote:
> Hello Sam,
> you wrote a lot, I'll try to reply to all your points, but I'll be
> dense: don't take thta for disrespect.
None taken. I appreciate you've a lot to do.
> On Thu, Aug 11, 2011 at 04:00, Sam Thompson<python at samthompson.com>  wrote:
>> Sandro,
[snip]
>> Thanks for explaining this. I could not find any mention of this in the
>> documentation itself. While I expect this may be obvious to those "in the
>> know", can I suggest that this important policy be explicitly stated at the
>> head of the documentation that this applies to, so that:
>> a) people don't waste your time filing bugs for things you have a policy not
>> to fix (note that I'm complaining about the policy - it's fine), and
>> b) people know that the documentation is not necessarily 100% to be relied
>> upon (in light of your comment below about backporting fixes), or
>> alternatively, remove this documentation and redirect visitors to the up-to
>> date version.
> You're actually suggesting to add a banner to every single page of doc
> for older release, which is unfeasible. We provide documentation for
> older versions "as was" when that version was last released, I don't
> see the point in explaining what's the status of a specific version in
> its doc.
There is more than one way to address this. As I stated earlier, I 
respect the project's decision not to maintain old versions of the 
documentation. But I have noticed that when projects still offer old 
versions of code or other material for access or download, they are 
usually pretty clear about the fact that it's unmaintained, at least at 
the entry points/download links. I still haven't seen a reference to the 
policy, on python.org, *outside* of the actual docs themselves.

There probably are SSI or other script based solutions (I don't know, 
maybe Python?) that could be used to tag each of these old pages, even 
if you aren't editing them individually; I disagree that it's unfeasible 
entirely, even though I'm not suggesting this approach.
> python.org/doc makes quite clear what are the supported doc version,
> linking only one for 2.x and 3.x .
This is an interesting point. The very first link in the body of this 
page links to a page that lists all the old versions; 
http://www.python.org/doc/versions/, where I don't even need to make up 
the URL to get old documents. So in addition to the links in the 
documentation navigation itself to previous versions, there's actually a 
direct link to each old version. Note, I'm not saying this is a bad 
thing, but this is a perfect candidate page in your currently maintained 
web site (outside of the documentation itself) where a simple sentence 
added at the head, e.g. "Please note that only the latest documentation 
in the 2.x and 3.x series is actively maintained". That's one change to 
one document. I'd say that's feasible, and expresses the policy succinctly.
> [snip]
>
>> It may be worth providing some more general guidance to users in the
>> documentation introductory section(s) about the best way to find out which
>> versions support which language constructs, if old documentation isn't it.
>> Maybe the "What's new in x?" lists?
> that's exactly the entry point you're looking for: just note that not
> every change ends up there.
Thanks for these suggestions. The fact that not every change is not in 
these documents may limit their utility to answer my question "which 
version introduced feature x?". However, I found references to bytes 
literals in the "what's new in 2.6", so I'm comfortable with this advice 
as an approach to my problem in general.
>> The links you're using to access teh documentation (I don't know if
>> only for showing the problem or as a general use) points to a specific
>> release, that will no longer be updated. So if you want to refer to
>> the lastest 2.x documentation the correct link is:
>>
>> http://docs.python.org/
>>
>> and for Python 3.x it is:
>>
>> http://docs.python.org/py3k/
>>
>> The link I used to access 2.6.7 was in the left navigation of the site at
>> the link http://docs.python.org/ under "Docs for other versions". It's true
> exactly, so you didn't use the latest documentation available :) of
> course, that's related a version of Python you don't have on your
> machine.
OK, but I was trying to answer a question about which versions would 
support the b"" literal feature. I knew it wasn't the latest version. At 
the time, I didn't know it wasn't correct, because it wasn't maintained. 
All that needed to change to fix this issue was to disclose this, 
somewhere where I could have seen it. Even better, provide the advice on 
the page http://www.python.org/doc/versions/ in addition to my previous 
suggestion, viz. "Please note that only the latest documentation in the 
2.x and 3.x series is actively maintained. For information on support in 
previous versions, please refer to the "what's new" documentation".
>> that the URLs accessed for other specific releases before 2.7.2 and 2.6.7
>> were formed by extrapolation, in order to work out what versions of the
>> documentation were affected by the perceived issue. That exercise was
>> ultimately worthless, given the policy as now stated.
>>
>> Instead, my report should have been against the current, maintained 2.x
>> documentation, i.e. "Can you please add a reference in this page saying
>> which version this significant change to string literals was made?". If you
> sometimes it is done, for example in case we add new methods there's
> often a "Added in: X.Y" tag at the end.
I think this change is worthy, particularly as the old docs are 
incorrect. Just my view though.
>> take none the other suggestions on board, which is reasonable given their
>> scope and impact, can I strongly urge you to at least update the current
>> versions of the 2.x and 3.x document for lexical analysis to this effect?
> It *is* fixed, as you said, in 2.7.1 and 2.7.2 : the latter version is
> the current one, so case closed.
That's your prerogative, of course. The correctness of the current 
versions was never the problem in relation to this feature. With 
respect, I still think there's a good argument for changes to:
a) Reflect the current policy on documentation maintenance clearly, on 
http://www.python.org/doc/versions/ at the very least.
b) In the case of the Bytes literal change, to add the "Added in: x.y" 
tag you mentioned to the lexical analysis pages for all currently 
maintained document versions.

If you're still not convinced, that's fine; I'll leave it there.

Regards,
Sam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110813/476f9aec/attachment.html>

From report at bugs.python.org  Sat Aug 13 11:40:58 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 09:40:58 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313228458.24.0.01880958111.issue12731@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Aug 13 18:40:51 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 16:40:51 +0000
Subject: [docs] [issue12745] Python2 or Python3 page
In-Reply-To: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>
Message-ID: <1313253651.11.0.447497522063.issue12745@psf.upfronthosting.co.za>


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

It is a wiki page, so you can edit it yourself (you probably need to register, though).
If you think your modifications would be too drastic, perhaps you want to launch a discussion on the python-dev mailing-list about that page and its current contents.

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

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

From report at bugs.python.org  Sat Aug 13 19:36:37 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Aug 2011 17:36:37 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <27372.1313194678@chthon>
Message-ID: <1313256874.3553.2.camel@localhost.localdomain>


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

> However, because the \w&c issues are bigger, Java addressed the tr18 RL1.2a
> issues differently, this time by creating a new compilation flag called
> UNICODE_CHARACTER_CLASSES (with corresponding embedded "(?U)" regex flag.)
> 
> Truth be told, even Perl has secret pattern compilation flags to govern
> this sort of thing (ascii, locale, unicode), but we (well, I) hope you
> never have to use or even notice them.  
> 
> That too might be a route forward for Python, although I am not quite sure
> how much flexibility and control of your lexical scope you have.  However,
> the "from __future_" imports suggest you may have enough to do something
> slick so that only people who ask for it get it, and also importantly that
> they get it all over the place so don't have to add an extra flag or u'...'
> or whatever every single time.  

If the current behaviour is buggy or sub-optimal, I think we should
simply fix it (which might be done by replacing "re" with "regex" if
someone wants to shepherd its inclusion in the stdlib).

By the way, thanks for the detailed explanations, Tom.

----------

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

From report at bugs.python.org  Sun Aug 14 05:52:51 2011
From: report at bugs.python.org (Ben Hayden)
Date: Sun, 14 Aug 2011 03:52:51 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313293971.63.0.900914633457.issue12725@psf.upfronthosting.co.za>


Ben Hayden <hayden767 at gmail.com> added the comment:

I made the suggested second change - both in the docs & the socketmodule.c file. If there's a different way to patch documentation, someone let me know. :D

----------
keywords: +patch
nosy: +beardedp
Added file: http://bugs.python.org/file22896/issue12725.patch

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

From report at bugs.python.org  Sun Aug 14 07:30:06 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Aug 2011 05:30:06 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <E1QsTGu-0005FZ-LZ@dinsdale.python.org>


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

New changeset dfe6f0a603d2 by Ezio Melotti in branch '2.7':
#12725: fix working. Patch by Ben Hayden.
http://hg.python.org/cpython/rev/dfe6f0a603d2

New changeset ab3432a81c26 by Ezio Melotti in branch '3.2':
#12725: fix working. Patch by Ben Hayden.
http://hg.python.org/cpython/rev/ab3432a81c26

New changeset 49e9e34da512 by Ezio Melotti in branch 'default':
#12725: merge with 3.2.
http://hg.python.org/cpython/rev/49e9e34da512

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

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

From report at bugs.python.org  Sun Aug 14 07:31:52 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Aug 2011 05:31:52 +0000
Subject: [docs] [issue12725] Docs: Odd phrase "floating seconds" in
	socket.html
In-Reply-To: <1313030875.76.0.991462005584.issue12725@psf.upfronthosting.co.za>
Message-ID: <1313299912.29.0.574037863861.issue12725@psf.upfronthosting.co.za>


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

Fixed, thanks for the report and the patch!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sun Aug 14 09:20:37 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 14 Aug 2011 07:20:37 +0000
Subject: [docs] [issue12743] C API marshalling doc contains XXX
In-Reply-To: <1313160183.82.0.137409262179.issue12743@psf.upfronthosting.co.za>
Message-ID: <1313306437.27.0.134410199975.issue12743@psf.upfronthosting.co.za>


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

Would you just remove the "XXX" string, or the entire comment? "XXX" is typically used to indicate that something needs to be done, and the comment makes a clear statement as to what it is that needs to be done.

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

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

From report at bugs.python.org  Mon Aug 15 02:21:28 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 00:21:28 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313367688.35.0.32127762405.issue12672@psf.upfronthosting.co.za>


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

I agree that the sentence is a bit confusing and the 'object method' ambiguous. I suspect that the sentence was written years ago. In current Python, [].append is a bound method of class 'builtin_function_or_method'. I *suspect* that the intended contrast, and certainly the important one, is that between C functions, which get added to PyTypeObject structures, and their Python object wrappers that are visible from Python, but which must not be put in the type structure. The varieties of wrappers are irrelevant in this context and for the purpose of avoiding that mistake. So I would rewrite the sentence as:

These C functions are called ?type methods? to distinguish them from Python wrapper objects, such as ``list.append`` or ``[].append``, visible in Python code.

Looking further down,
"Now if you go and look up the definition of PyTypeObject in object.h you?ll see that it has many more fields that the definition above.",
needs 'that' changed to 'than' and I would insert " following tp_doc" after 'fields'.

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

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

From report at bugs.python.org  Mon Aug 15 06:26:32 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 15 Aug 2011 04:26:32 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313382392.13.0.516664560843.issue12672@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug 15 12:30:03 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 10:30:03 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1313404203.74.0.80585032843.issue12731@psf.upfronthosting.co.za>


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

If the regex module works fine here, I think it's better to leave the re module alone and include the regex module in 3.3.

----------

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

From report at bugs.python.org  Mon Aug 15 13:29:03 2011
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Aug 2011 11:29:03 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <E1QsvLp-0003ry-OW@dinsdale.python.org>


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

New changeset 16edc5cf4a79 by Ezio Melotti in branch '3.2':
#12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/16edc5cf4a79

New changeset fb49394f75ed by Ezio Melotti in branch '2.7':
#12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/fb49394f75ed

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

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

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

From report at bugs.python.org  Mon Aug 15 13:29:57 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 11:29:57 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313407797.8.0.966466340051.issue12204@psf.upfronthosting.co.za>


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

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Mon Aug 15 14:05:21 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Aug 2011 12:05:21 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313409921.15.0.463652306347.issue12204@psf.upfronthosting.co.za>


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

Are you sure this should have been backported?  Are there any apps that may be working now but won't be after the next point release?

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

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

From report at bugs.python.org  Mon Aug 15 14:40:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 12:40:44 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412044.54.0.62685309529.issue12204@psf.upfronthosting.co.za>


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

This is only a doc patch, maybe you are confusing this issue with #12266?

----------

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

From report at bugs.python.org  Mon Aug 15 14:47:19 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 15 Aug 2011 12:47:19 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412439.45.0.797327557605.issue12204@psf.upfronthosting.co.za>


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

Right.  I was looking at the other patches that went in in the last 24 hours.

----------

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

From report at bugs.python.org  Mon Aug 15 14:50:11 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Aug 2011 12:50:11 +0000
Subject: [docs] [issue12204] str.upper converts to title
In-Reply-To: <1306644560.56.0.146552718337.issue12204@psf.upfronthosting.co.za>
Message-ID: <1313412611.24.0.872094945914.issue12204@psf.upfronthosting.co.za>


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

It's unlikely that #12266 might break apps.  The behavior changed only for fairly unusual characters, and the old behavior was clearly wrong.
FWIW the str.capitalize() implementation of PyPy doesn't have the bug, and after the fix both CPython and PyPy have the same behavior.

----------

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

From report at bugs.python.org  Tue Aug 16 04:45:06 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 16 Aug 2011 02:45:06 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313462706.63.0.108833753683.issue12672@psf.upfronthosting.co.za>


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

Terry, I'm not 100% sure about what you mean by "Python wrapper objects ... visible from Python", but I think I'll disagree.

There's a big difference between "C functions" in general and "type methods" this document speaks of. Let's leave list aside for a moment, since its being built-in complicates matters a bit, and let's talk about the "Noddy" type this documentation page plays with.

You may implement "normal" methods for Noddy, such as the "name" method added in the first example, by defining an array of PyMethodDef structures and assigning it to tp_methods.

On the other hand, the other tp_ fields imlpement special type methods (used by __new__, __str__, getattr/setattr, and so on). This is the major difference. Both are C functions, but some implement special type methods and some implement "normal" object methods.

If this is also what you meant, I apologize for disagreeing :-)

I believe my latest rephrasing proposal is reflecting the above understanding.

P.S. as for s/that/than/ further down - good catch, will add it to the patch when we decide about the first issue

----------

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

From report at bugs.python.org  Tue Aug 16 06:44:19 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Aug 2011 04:44:19 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313469859.3.0.657392022271.issue12672@psf.upfronthosting.co.za>


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

"the type object determines which (C) functions get called when, for instance, an attribute gets looked up on an object or it is multiplied by another object. These C functions are called ?type methods?

"These C functions" are any of the C functions that are members of the type object. But they are C-level methods.

"to distinguish them from things like [].append (which we call ?object methods?)."

[].append is a Python-level method object that wraps a C function.

My revised suggestion is "... in contrast to PyObject that contain C functions, such as list.append or [].append."

The only contrast that makes sense to me in this context is between directly callable C functions and Py_Objects (which have just been described) that contain a C function. I believe that author is addressing Python programmers who are used to 'method' referring to Python objects whereas the author wants to use 'method' to refer to C functions, which are not Python objects.

Or the sentence could be deleted.

----------

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

From report at bugs.python.org  Tue Aug 16 07:46:07 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 16 Aug 2011 05:46:07 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313473567.46.0.436005479756.issue12672@psf.upfronthosting.co.za>


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

"[].append is a Python-level method object that wraps a C function."

What makes you think that? There's no Python implementation of .append that I know of. Neither is there a Python implementation of the Noddy.name method that is discussed in the page. Both are implemented solely in C and exposed as methods for their respective classes via the tp_methods array.

"Or the sentence could be deleted."

This could be problematic, because the document does refer to "type methods" on several occasions, and it makes sense to define what it means.

----------

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

From report at bugs.python.org  Tue Aug 16 10:17:19 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:17:19 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313482639.28.0.106717139661.issue12758@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Tue Aug 16 10:17:33 2011
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Aug 2011 08:17:33 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313482653.71.0.927438524552.issue12758@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


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

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

From report at bugs.python.org  Tue Aug 16 10:25:54 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 08:25:54 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313483154.51.0.545266104115.issue12758@psf.upfronthosting.co.za>


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

Would dropping 'in UTC' from
"""
Return the time as a floating point number expressed in seconds since the epoch, in UTC.
"""
be an acceptable solution?  AFAIK there are no "non-UTC epochs".

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

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

From report at bugs.python.org  Tue Aug 16 10:27:33 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 08:27:33 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313483252.93.0.273974026474.issue12758@psf.upfronthosting.co.za>


Maxim Koltsov <kolmax94 at gmail.com> added the comment:

Maybe add some words about local timezone?

----------

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

From report at bugs.python.org  Tue Aug 16 11:17:01 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Aug 2011 09:17:01 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313486221.67.0.380443207718.issue12758@psf.upfronthosting.co.za>


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

"""
Return the local time as a floating point number expressed in seconds since the epoch.
"""

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

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

From report at bugs.python.org  Tue Aug 16 11:37:18 2011
From: report at bugs.python.org (Maxim Koltsov)
Date: Tue, 16 Aug 2011 09:37:18 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313487438.52.0.594374700545.issue12758@psf.upfronthosting.co.za>


Maxim Koltsov <kolmax94 at gmail.com> added the comment:

Seems OK to me.

----------

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

From report at bugs.python.org  Tue Aug 16 15:49:19 2011
From: report at bugs.python.org (David Townshend)
Date: Tue, 16 Aug 2011 13:49:19 +0000
Subject: [docs] [issue12760] Add create mode to open()
Message-ID: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>


New submission from David Townshend <aquavitae69 at gmail.com>:

Currently, opening a file with open(file, 'w') overwrites existing files.  It would be useful for open() to raise an error when the file exists.  This proposal is to add a 'c' mode to open, which has the effect to creating a file and opening it for writing, but raising an IOError if it already exists (i.e. the same as os.open(file, os.O_EXCL|os.O_CREAT).

The attached patch implements this, including tests and documentation.

----------
assignee: docs at python
components: Documentation, IO, Library (Lib), Tests
files: open_create.patch
keywords: patch
messages: 142193
nosy: David.Townshend, docs at python
priority: normal
severity: normal
status: open
title: Add create mode to open()
type: feature request
versions: Python 3.3
Added file: http://bugs.python.org/file22910/open_create.patch

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

From report at bugs.python.org  Tue Aug 16 15:57:33 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Aug 2011 13:57:33 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313503053.81.0.529575257958.issue12760@psf.upfronthosting.co.za>


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

I'm not sure that O_EXCL is portable (exist on all platforms) because Python source code uses "#ifdef O_EXCL".

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

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

From report at bugs.python.org  Tue Aug 16 16:53:24 2011
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 16 Aug 2011 14:53:24 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313506404.82.0.925395838331.issue12760@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think this should be brought up on python-ideas or python-dev.

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

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

From report at bugs.python.org  Tue Aug 16 17:37:06 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Tue, 16 Aug 2011 15:37:06 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313509026.46.0.128827885643.issue12760@psf.upfronthosting.co.za>


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

See also issue 12105.
A couple downsides:
- O_EXCL is not necessarily portable (doesn't work well with NFS, maybe not on Windows?)
- O_EXCL is useful, as is O_CLOEXEC: to be consistent, we should also end up adding all other commonly-used flags, which are really OS-specific

Furthermore, you can achieve the same thing with:
os.fdopen(os.open('/etc/fstab', os.O_WRONLY|os.O_CLOEXEC|os.O_CREAT))
it's more verbose, though.

----------
nosy: +neologix

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

From report at bugs.python.org  Tue Aug 16 17:43:21 2011
From: report at bugs.python.org (David Townshend)
Date: Tue, 16 Aug 2011 15:43:21 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313509401.21.0.325489956823.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

It was discussed on python-ideas, but the subject of the thread was actually on shutils.move so it was not really discussed much. I will repost this idea separately.

----------

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

From report at bugs.python.org  Tue Aug 16 19:05:03 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Tue, 16 Aug 2011 17:05:03 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313514303.07.0.799822456146.issue12761@psf.upfronthosting.co.za>


Changes by Gennadiy Zlobin <gennad.zlobin at gmail.com>:


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

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

From report at bugs.python.org  Tue Aug 16 19:26:32 2011
From: report at bugs.python.org (Gennadiy Zlobin)
Date: Tue, 16 Aug 2011 17:26:32 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313515592.87.0.330866146757.issue12761@psf.upfronthosting.co.za>


Changes by Gennadiy Zlobin <gennad.zlobin at gmail.com>:


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

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

From vbartenev at gmail.com  Tue Aug 16 03:38:54 2011
From: vbartenev at gmail.com (Valentin V. Bartenev)
Date: Tue, 16 Aug 2011 05:38:54 +0400
Subject: [docs] BUG: Looping in reverse order
Message-ID: <201108160538.55105.vbartenev@gmail.com>

Hello,

Section 5.6 of the Python 3 Tutorial: http://docs.python.org/py3k/tutorial/datastructures.html#looping-techniques
propose a too complicated way to loop over a sequence in reverse order.

The example teaches bad programming practice:
>>> for i in reversed(range(1, 10, 2)):
...     print(i)
...
9
7
5
3
1

it should be more simple:
>>> for i in range(9, 0, -2):
...     print(i)
... 
9
7
5
3
1

I figure out that the author just wanted to introduce "reversed" function,
but he choose an inappropriate use case.

wbr, Valentin V. Bartenev

From xcoderz at gmail.com  Tue Aug 16 18:43:31 2011
From: xcoderz at gmail.com (Jiachang Xu)
Date: Tue, 16 Aug 2011 12:43:31 -0400
Subject: [docs] threading.Condition.notify() correction
Message-ID: <CAJg_yxwdGBzK_arENUut2bf1wRpJs7AuQB44k8R07KvbkWf-pQ@mail.gmail.com>

Hi,
In the source of *threading.Condition.notify()*, there is a parameter "n" as
well, can the documentation be updated with it?
http://docs.python.org/library/threading.html#threading.Condition.notify

-- 
Jiachang Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110816/5d7ec37a/attachment.html>

From report at bugs.python.org  Tue Aug 16 19:58:23 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 16 Aug 2011 17:58:23 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313517503.59.0.324223326253.issue12761@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
nosy: +ezio.melotti, sandro.tosi
stage:  -> commit review
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 16 20:10:42 2011
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 16 Aug 2011 18:10:42 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <E1QtO65-00042l-59@dinsdale.python.org>


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

New changeset 80ac94ad381e by Sandro Tosi in branch '2.7':
#12761: fix wording of zlib license section
http://hg.python.org/cpython/rev/80ac94ad381e

New changeset 16a02530fd81 by Sandro Tosi in branch '3.2':
#12761: fix wording of zlib license section
http://hg.python.org/cpython/rev/16a02530fd81

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

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

From report at bugs.python.org  Tue Aug 16 20:13:13 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Aug 2011 18:13:13 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313518393.5.0.794128326606.issue12672@psf.upfronthosting.co.za>


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

You are right, I suggested deleting too much. The first half of the sentence is needed to define 'type methods', which is used several more times and is the title of the next section. We need to keep "These C functions are called ?type methods?." In the context of the preceding sentence and later usages, I think this is enough.

The second half of the sentence is intended to refine the definition by contrast, but it fails to do so since we cannot agree on what the contrast is. Since none of the interpretations make complete sense and since 'object methods' is not used again, making its definition irrelevant, I suggest deleting this part: "to distinguish them from things like [].append (which we call ?object methods?).".

----------

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

From report at bugs.python.org  Tue Aug 16 20:13:47 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 16 Aug 2011 18:13:47 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313518427.39.0.6089540662.issue12761@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Jakub for the report and Gennadiy for the patch (that I applied on all the active braches).

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

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

From report at bugs.python.org  Wed Aug 17 02:42:03 2011
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Aug 2011 00:42:03 +0000
Subject: [docs] [issue12758] time.time() returns local time instead of UTC
In-Reply-To: <1313481124.28.0.0943950907585.issue12758@psf.upfronthosting.co.za>
Message-ID: <1313541722.75.0.00986554464106.issue12758@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> Return the local time as a floating point number
> expressed in seconds since the epoch.

No.  Seconds since the epoch is neither local nor UTC.  It is just an elapsed number of seconds since an agreed upon time called the "epoch".  

I would say: "Return the current time as a floating point number representing the number of seconds elapsed since the epoch."  Suggestions for a shorter formulation that would not change the meaning are welcome.  Maybe "Return the number of seconds elapsed since the epoch as a floating point number."

----------

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

From report at bugs.python.org  Wed Aug 17 04:37:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:37:09 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
Message-ID: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User report (Jiachang Xu) from the docs mailing list:

The theading.Condition.notify method has a parameter - n, which isn't documented in the the documentation of the threading module.

1. The parameter should be documented
2. notify() is mentioned multiple times in the docs of threading - perhaps the parameter should be mentioned in more than one place as well
3. The parameter should also be documented in the doc-string of notify in Lib/theading.py - however, this may be a separate issue since currently none of the methods of Condition has docstrings.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142246
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: document threading.Condition.notify
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From eliben at gmail.com  Wed Aug 17 04:38:07 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Wed, 17 Aug 2011 05:38:07 +0300
Subject: [docs] threading.Condition.notify() correction
In-Reply-To: <CAJg_yxwdGBzK_arENUut2bf1wRpJs7AuQB44k8R07KvbkWf-pQ@mail.gmail.com>
References: <CAJg_yxwdGBzK_arENUut2bf1wRpJs7AuQB44k8R07KvbkWf-pQ@mail.gmail.com>
Message-ID: <CAF-Rda9F+E0NqwEv8sD2bObdig6_gqB98fZckNEnifHqO=dMcw@mail.gmail.com>

On Tue, Aug 16, 2011 at 19:43, Jiachang Xu <xcoderz at gmail.com> wrote:
> Hi,
> In the source of threading.Condition.notify(), there is a parameter "n" as
> well, can the documentation be updated with it?
> http://docs.python.org/library/threading.html#threading.Condition.notify
>
> --
> Jiachang Xu

Thanks for your report. I have created
http://bugs.python.org/issue12767 to track this.
Feel free to submit a patch - I promise to review and commit it promptly :-)

Eli

From report at bugs.python.org  Wed Aug 17 04:43:09 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:43:09 +0000
Subject: [docs] [issue12768] docstrings for the threading module
Message-ID: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

The threading module has very few methods with docstrings. Docstrings should be added to all public methods (contents can be borrowed from the documentation).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142247
nosy: docs at python, eli.bendersky
priority: low
severity: normal
stage: needs patch
status: open
title: docstrings for the threading module
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 17 04:43:45 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 02:43:45 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313549025.49.0.478611707029.issue12767@psf.upfronthosting.co.za>


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

Opened Issue 12768 on the general lack of docstrings in the threading module

----------

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

From report at bugs.python.org  Wed Aug 17 13:09:12 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Aug 2011 11:09:12 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313579352.91.0.225034148845.issue12767@psf.upfronthosting.co.za>


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

>From a quick look at the code and docs I suspect that 'n' is an internal implementation detail and not meant to be exposed.  Is there an use case for notifying waiters where n!=1 and n!=len(waiters)?  If my speculation is correct it might be a good idea to refactor this so that notify itself does not take an argument but instead both it an notify_all call an explicitly internal routine _notify.

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

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

From report at bugs.python.org  Wed Aug 17 13:21:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 17 Aug 2011 11:21:19 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313580079.08.0.648427432308.issue12767@psf.upfronthosting.co.za>


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

David, while you make a valid point, consider that 'n' is part of the public API of the threading module (although not documented) and it's conceivable that there is existing code "in the wild" using it. To do what you suggest we should maybe go through a normal deprecation process for this argument first?

Adding Antoine as the listed threading expert.

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

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

From report at bugs.python.org  Wed Aug 17 14:36:07 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Aug 2011 12:36:07 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313584567.25.0.58501169057.issue12767@psf.upfronthosting.co.za>


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

Good point.  Probably, then, we should just put a comment in the code that 'n' is an internal implementation detail and leave it at that.

----------

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

From report at bugs.python.org  Thu Aug 18 04:30:55 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 18 Aug 2011 02:30:55 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313634655.22.0.407945055817.issue12767@psf.upfronthosting.co.za>


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

I asked the user who reported this documentation omission what he's using the 'n' argument for. His reply:

    "Yes I am using the n parameter, it is mainly to implement a subclass of Queue that supports "bulk" get and put operations. This enhances the performance of repeated get/put calls when the Queue is created using multiprocessing.Manager."

----------

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

From report at bugs.python.org  Thu Aug 18 10:00:55 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 08:00:55 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
Message-ID: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>


New submission from Daniel Svensson <dsvensson at gmail.com>:

I've noticed problems with the GC in two applications. In one case the application did not respond to SOAP-requests for 9 seconds, every couple of minutes, when it really shouldn't have taken more than 20ms. In another case we had one operation executed by 20 threads that ought to have taken 0.5 seconds, but instead took about 90 seconds.

Both cases were solved by disabling the garbage collector and hunting down possible circular references. Once this was done, the first example went down to its expected 20ms max latency, and the second one to its 0.5s processing time.


Here is a short python script that demonstrates the issue, the JSON file in this case is 1.2GB large:

> import cjson, time, gc

> def read_json_blob():
>   t0 = time.time()
>   fd = file("mytestfile")
>   data = fd.read()
>   fd.close()
>   t1 = time.time()
>   parsed = cjson.decode(data)
>   t2 = time.time()
>   print "read file in %.2fs, parsed json in %.2fs, total of %.2fs" % \
>                                                   (t1-t0, t2-t1, t2-t0)

> read_json_blob()
read file in 10.57s, parsed json in 531.10s, total of 541.67s

> gc.disable()
> read_json_blob()
read file in 0.59s, parsed json in 15.13s, total of 15.72s

> gc.collect()
0

I don't understand how Python can work like this default, at least not without a warning, to me it looks like a joke gone too far. All documentation ought to recommend people to disable the garbage collector at the first sign of performance problems, or the garbage collector problem should be fixed, this the "Documentation" or "Interpreter Core" Components in the ticket classification.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 142305
nosy: docs at python, dsvensson
priority: normal
severity: normal
status: open
title: immense performance problems related to the garbage collector
type: performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 18 10:05:48 2011
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 18 Aug 2011 08:05:48 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313654748.5.0.381282591623.issue12775@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +durban

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

From report at bugs.python.org  Thu Aug 18 11:26:03 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 09:26:03 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313634655.22.0.407945055817.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313659433.3602.0.camel@localhost.localdomain>


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

> I asked the user who reported this documentation omission what he's
> using the 'n' argument for. His reply:
> 
>     "Yes I am using the n parameter, it is mainly to implement a
> subclass of Queue that supports "bulk" get and put operations. This
> enhances the performance of repeated get/put calls when the Queue is
> created using multiprocessing.Manager."

I think it's fine to document it. It's been there for a long time.
Besides, if we know how to notify one thread, we are certainly able to
notify n of them :)

----------

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

From report at bugs.python.org  Thu Aug 18 13:33:56 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 11:33:56 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>


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

The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas:

O_EXCL is a POSIX standard. It is also supported
under Windows by the _open/_wopen compatibility functions (which we use
for file I/O).

Probably there are very old systems which don't support it, and perhaps
new systems that don't implement it *correctly* (meaning not
atomically); for the former I'd say we just don't care (who's gonna run
Python 3 on a 1995 system?) and for the latter, well, if the OS
designers think it's fine, let's just expose it as it is.

As for NFS, there's an interesting comment from 2007 here:
http://lwn.net/Articles/251971/

?My NFS tester shows that it at least appears to work with Linux,
Solaris and FreeBSD:
http://www.dovecot.org/list/dovecot/2007-July/024102.html. Looking at
Linux 2.6 sources it doesn't look like it tries to implement a racy
O_EXCL check in client side (fs/nfs/nfs3proc.c nfs3_proc_create()), so
the test's results should be correct. I don't know if other OSes do
that. I guess it would be nice to have a better O_EXCL tester which
tries to catch race conditions.?

----------
assignee: docs at python -> 
components:  -Documentation, Tests
nosy: +pitrou

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

From report at bugs.python.org  Thu Aug 18 13:56:54 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 11:56:54 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313668613.93.0.73423824885.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

My aim isn't to add all the commonly used flags, that would be pointless since its already possible using os.open.  The aim is to add a missing feature to the builtin open(), i.e. file creation.  At the moment open() implements read, write, and append, and creation is only implied by write. But in many cases, an explicit creation is desired (i.e, specifically create a new file, with an exception on failure).  It is true that this is possible with os.open, but it is somewhat obscure, especially for beginners, and is not as easy to read as "open(file, 'c')"

----------

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

From report at bugs.python.org  Thu Aug 18 14:11:27 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Aug 2011 12:11:27 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669487.29.0.062520649955.issue12775@psf.upfronthosting.co.za>


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

Which version of Python did you test with?
Can you try with version 3.2?

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

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

From report at bugs.python.org  Thu Aug 18 14:12:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 12:12:46 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669566.74.0.493759504007.issue12775@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Aug 18 14:13:46 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 12:13:46 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313669626.75.0.669972652722.issue12775@psf.upfronthosting.co.za>


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

Can you try to write a short example to reproduce the problem?

----------

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

From sandro.tosi at gmail.com  Thu Aug 18 14:45:31 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 14:45:31 +0200
Subject: [docs] Which version of sphinx?
In-Reply-To: <1307748473.4373.3.camel@debian>
References: <1307058973.29551.2.camel@debian>
	<BANLkTimq78NVBdJzLg=3Jda_yzRUK-N6XQ@mail.gmail.com>
	<1307748473.4373.3.camel@debian>
Message-ID: <CAPdtAj0npUjx1sBJqiOeT0jDgrercbYJ--06U6bopavbX4b-7Q@mail.gmail.com>

On Sat, Jun 11, 2011 at 01:27, Tshepang Lekhonkhobe <tshepang at gmail.com> wrote:
> On Fri, 2011-06-10 at 20:40 +0000, Sandro Tosi wrote:
>> Hello Tshepang,
>>
>> On Thu, Jun 2, 2011 at 23:56, Tshepang Lekhonkhobe <tshepang at gmail.com> wrote:
>> > Hi,
>> >
>> > Is there any reason Sphinx version was specified here:
>> > http://docs.python.org/dev/documenting/building.html?
>>
>> I don't have that clear your question. Are you asking why the version
>> is explict in this command:
>>
>> svn co http://svn.python.org/projects/external/Sphinx-0.6.5/sphinx tools/sphinx
>>
>> or in some other place? can you please be a bit more specific (either
>> in what you think is wrong and how you'd fix it)?
>
> Sorry for not being too clear. I meant, why is that specific version
> required? Why doesn't the link just point to trunk (or tip, in Mercurial
> speak)?

I can think mainly two reason:

- stability: if everyone is building the docs from sphinx tip (and all
other third-party tool) you'll get a mess where for some people the
change works and for others doesn't. Having "written in stone" what's
the version to use, avoid this ambiguity.
- that's because it's what Makefile does: if you look at Doc/Makefile
(of the cpython default branch checkout) you'll see the script is
actually checking out the code from svn.python.org - for strange that
it is, it works.

> I asked because I was looking at the doc, wanting to improve it.
> I imagined it could stem from the fear that later versions could break
> the doc build.

Indeed, just use the tool Python ship: the makefile will DTRT, just follow it :)

If you need help, or guidance, about improving the doc, you can ask
here, on python-dev or refer to the devguide:
http://docs.python.org/devguide/docquality.html

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 18 14:48:52 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 14:48:52 +0200
Subject: [docs] BUG: Looping in reverse order
In-Reply-To: <201108160538.55105.vbartenev@gmail.com>
References: <201108160538.55105.vbartenev@gmail.com>
Message-ID: <CAPdtAj2EXx_ODVJ7BdzStrrjNx_6i3nthVpJFNN_Vr70ZC4G3A@mail.gmail.com>

Hello Valentin,
thanks for your email.

On Tue, Aug 16, 2011 at 03:38, Valentin V. Bartenev <vbartenev at gmail.com> wrote:
> Hello,
>
> Section 5.6 of the Python 3 Tutorial: http://docs.python.org/py3k/tutorial/datastructures.html#looping-techniques
> propose a too complicated way to loop over a sequence in reverse order.
>
> The example teaches bad programming practice:
>>>> for i in reversed(range(1, 10, 2)):
> ... ? ? print(i)
> ...
> 9
> 7
> 5
> 3
> 1
>
> it should be more simple:
>>>> for i in range(9, 0, -2):
> ... ? ? print(i)
> ...
> 9
> 7
> 5
> 3
> 1
>
> I figure out that the author just wanted to introduce "reversed" function,
> but he choose an inappropriate use case.

Indeed, it's just about presenting the reversed() function: in fact,
the next paragraph is about sorted().

Hence, I don't see anything wrong here, and the doc doesn't require an update.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From darren.yin at gmail.com  Thu Aug 18 02:25:37 2011
From: darren.yin at gmail.com (Darren Yin)
Date: Wed, 17 Aug 2011 17:25:37 -0700
Subject: [docs] couple things on the Dos and Donts page
Message-ID: <CAPWDJtU-K+N29yN=CoKYCn-nF9w1B7MhqP_miW42UK+p14CmZA@mail.gmail.com>

http://docs.python.org/howto/doanddont.html

Even in versions where it was accepted, it made the function execution
> slower, because the compiler could not be certain which names are local and
> which are global.


Even in versions where it was accepted, it made the function execution
slower, because the compiler could not be certain which names were local and
which were global.

Currently it mixes past and present tenses in a somewhat awkward manner.

One of the most awful question asked on the newsgroup is why this code:

One of the most awful questions asked on the newsgroup is why this code:
Because it used to just be non-grammatical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110817/5750309c/attachment.html>

From utyf at utyf.net  Thu Aug 18 06:49:51 2011
From: utyf at utyf.net (=?UTF-8?B?0JPQtdC90L3QsNC00LjQuSDQn9C40LvQuNC/0LXQvdC60L4=?=)
Date: Thu, 18 Aug 2011 08:49:51 +0400
Subject: [docs] Little mistake on datetime page
Message-ID: <CA+WMXj6eFVLz6zSX4pJGHrXKsYZkR4vvZSgi+iZxfNQOorhocA@mail.gmail.com>

Hello!

http://docs.python.org/library/datetime.html#timedelta-objects

In examples:

---

>>> ten_years = 10 * year
>>> ten_years, ten_years.days // 365
(datetime.timedelta(3650), 10)

---

should be:

---

>>> ten_years = 10 * year
>>> ten_years, ten_years.days // 3650
(datetime.timedelta(3650), 3650)

---

--

Sincerely, Gennady

From sandro.tosi at gmail.com  Thu Aug 18 15:09:07 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 15:09:07 +0200
Subject: [docs] Little mistake on datetime page
In-Reply-To: <CA+WMXj6eFVLz6zSX4pJGHrXKsYZkR4vvZSgi+iZxfNQOorhocA@mail.gmail.com>
References: <CA+WMXj6eFVLz6zSX4pJGHrXKsYZkR4vvZSgi+iZxfNQOorhocA@mail.gmail.com>
Message-ID: <CAPdtAj3F9b5UJe4ErTrDxssWv0wtDenj+VwcLnjQ98M7yjmVtw@mail.gmail.com>

Hello,
thanks for your email.

2011/8/18 ???????? ????????? <utyf at utyf.net>:
> Hello!
>
> http://docs.python.org/library/datetime.html#timedelta-objects
>
> In examples:
>
> ---
>
>>>> ten_years = 10 * year
>>>> ten_years, ten_years.days // 365
> (datetime.timedelta(3650), 10)
>
> ---
>
> should be:
>
> ---
>
>>>> ten_years = 10 * year
>>>> ten_years, ten_years.days // 3650
> (datetime.timedelta(3650), 3650)

Could you please explain why? If I understand it correctly, what the
example tries to show is that the number of days in ten_years divided
the number of days in a year is 10, which is expected.

Also:

>>> ten_years, ten_years.days // 3650
(datetime.timedelta(3650), 1)

Regards
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 18 15:24:53 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 13:24:53 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313667236.12.0.608700658903.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM3tWTZeWEMPQQqh8X7ykezhjOw-_dU5UgPgdtVMwX3ZKg@mail.gmail.com>


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

> The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas:
>
> O_EXCL is a POSIX standard. It is also supported
> under Windows by the _open/_wopen compatibility functions (which we use
> for file I/O).
>

If it's supported by Windows then I'm OK (not that I personaly care
about Windows :-).

> and is not as easy to read as "open(file, 'c')"

Well, I'd rather have this flag called 'x', to be consistent with
glibc's fopen():

"""
       c (since glibc 2.3.3)
              Do not make the open operation, or subsequent read and write
              operations, thread cancellation points.

       x      Open the file exclusively (like the O_EXCL flag of
open(2)).  If the
              file already exists, fopen() fails, and sets errno to
EEXIST.  This
              flag is ignored for fdopen().
"""

By the way, could you submit your patch as a mercurial diff ("hg diff")?
It makes it easier to review under Rietveld.

----------

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

From report at bugs.python.org  Thu Aug 18 15:28:44 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 13:28:44 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313674124.9.0.556755804215.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

Changing form 'c' to 'x' is easy enough, and if there is already a convention it makes sense to stick to it.

I thought I had done a mercurial diff! I'll try again and resubmit.

----------

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

From sandro.tosi at gmail.com  Thu Aug 18 15:38:59 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 15:38:59 +0200
Subject: [docs] couple things on the Dos and Donts page
In-Reply-To: <CAPWDJtU-K+N29yN=CoKYCn-nF9w1B7MhqP_miW42UK+p14CmZA@mail.gmail.com>
References: <CAPWDJtU-K+N29yN=CoKYCn-nF9w1B7MhqP_miW42UK+p14CmZA@mail.gmail.com>
Message-ID: <CAPdtAj02odDTOgWKyFcXrpEfSK6gB-x+nSwegKej1V6BTDLf=Q@mail.gmail.com>

Hello Darren,
thanks for your email.

On Thu, Aug 18, 2011 at 02:25, Darren Yin <darren.yin at gmail.com> wrote:
> http://docs.python.org/howto/doanddont.html
>>
>> Even in versions where it was accepted, it made the function execution
>> slower, because the compiler could not be certain which names are local and
>> which are global.
>
> Even in versions where it was accepted, it made the function execution
> slower, because the compiler could not be certain which names were local and
> which were global.
> Currently it mixes past and present tenses in a somewhat awkward manner.
>>
>> One of the most awful question asked on the newsgroup is why this code:
>
> One of the most awful questions asked on the newsgroup is why this code:
>
> Because it used to just be non-grammatical.

these are now fixed: http://hg.python.org/cpython/rev/d430a352dab3

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 18 16:02:29 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 14:02:29 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313676148.95.0.290979143574.issue12775@psf.upfronthosting.co.za>


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

There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this.

> Here is a short python script that demonstrates the issue, the JSON
> file in this case is 1.2GB large:

A couple remarks:
- please indicate the Python version you're using
- you should put your test in a script, one with gc.disable() at the top, to avoid using any cache that might be used internally by cjson
- you should perform "echo 3 > /proc/sys/vm/drop_cache" before each run to make sure you start with a cold page/buffer cache (see how fast your file got read the second time you called read_json_blob()?)

----------
nosy: +loewis, neologix, pitrou

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

From report at bugs.python.org  Thu Aug 18 16:15:59 2011
From: report at bugs.python.org (Julian Berman)
Date: Thu, 18 Aug 2011 14:15:59 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313676959.01.0.662829286001.issue12760@psf.upfronthosting.co.za>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

A minor documentation error in io.rst line 475 which was changed to:

+   The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading
+   (default), writing, or appending.

and should have "creating" at the front I assume, like you have it later.

----------
nosy: +Julian

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

From report at bugs.python.org  Thu Aug 18 16:19:17 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:19:17 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <CAH_1eM3tWTZeWEMPQQqh8X7ykezhjOw-_dU5UgPgdtVMwX3ZKg@mail.gmail.com>
Message-ID: <1313677026.3602.2.camel@localhost.localdomain>


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

> Well, I'd rather have this flag called 'x', to be consistent with
> glibc's fopen():
> 
> """
>        c (since glibc 2.3.3)
>               Do not make the open operation, or subsequent read and write
>               operations, thread cancellation points.
> 
>        x      Open the file exclusively (like the O_EXCL flag of
> open(2)).  If the
>               file already exists, fopen() fails, and sets errno to
> EEXIST.  This
>               flag is ignored for fdopen().

Yeah, but I think "exclusively" is quite misleading since it does not
perform any locking of any kind. Also, I don't think we'll ever
integrate the glibc's "c" option in io.open().

----------

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

From report at bugs.python.org  Thu Aug 18 16:29:23 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 14:29:23 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313677763.6.0.701906187158.issue12775@psf.upfronthosting.co.za>


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

As Charles-Fran?ois said: it would be nice to know which Python version you are using. Also, if you could test with 2.7 or 3.2 and the standard json module (or the latest simplejson if you prefer).

Also, while Python's performance is not always excellent, it is quite rare for it to be GC-limited, so the advice you are suggesting we give would be misleading for most use cases.

Note that instead of disabling the GC, you can tune its parameters by calling set_threshold. For example:

  u, v, w = gc.get_threshold()
  gc.set_threshold(u, v * 10, w * 50)

(this will make full collections occur 500 times less often)

Or you could disable the GC only when decoding JSON data and reenable it afterwards.

----------

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

From report at bugs.python.org  Thu Aug 18 16:42:35 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 14:42:35 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313678555.84.0.166217975022.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

The bug note contains a test script. You just have to generate a huge JSON-blob, or allocate 1 GB or so and pickle it down to file and replace the cjson.decode to pickle.loads, pickle is about 20 times faster without GC.

----------

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

From report at bugs.python.org  Thu Aug 18 16:46:38 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 14:46:38 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313678798.0.0.366084090214.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

"Or you could disable the GC only when decoding JSON data and reenable it afterwards."

JSON was just an example, and disabling/enabling the GC is not safe in a multithreaded environment?

----------

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

From report at bugs.python.org  Thu Aug 18 17:07:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 15:07:40 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313678555.84.0.166217975022.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313679930.3602.11.camel@localhost.localdomain>


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

> The bug note contains a test script. You just have to generate a huge
> JSON-blob, or allocate 1 GB or so and pickle it down to file and
> replace the cjson.decode to pickle.loads, pickle is about 20 times
> faster without GC.

You can't say that any "huge JSON blob" will exhibit the same
performance characteristics as yours. I just tested json.loads() with a
rather trivial 300MB JSON string, and it took a couple of seconds (on
2.7). Does it reproduce your workload? I don't know.

> disabling/enabling the GC is not safe in a multithreaded environment?

You are right that disabling/enabling the GC is a global setting. But
that still leaves the option of tuning the parameters.

----------

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

From report at bugs.python.org  Thu Aug 18 17:14:16 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Thu, 18 Aug 2011 15:14:16 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313680456.87.0.302575181883.issue12760@psf.upfronthosting.co.za>


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

> Yeah, but I think "exclusively" is quite misleading since it does not
> perform any locking of any kind.

It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX.

Furthermore, there's an added bonus: actually, with the old I/O layer, one can already pass an 'x' flag to open, since it just calls fopen:
"""
cf at neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/tmp/foo", O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0666) = 3
cf at neobox:~$ strace -e open python -c "open('/tmp/foo', 'wx')"
[...]
open("/usr/lib/pymodules/python2.6/<string>", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
IOError: [Errno 17] File exists: '/tmp/foo'
"""

I don't know if it's documented behavior, but the OP in issue 12105 was using it with python 2.
Changing it to 'x' would make such code backward-compatible.

Finally, when I read open('/tmp/foo', 'wx'), it's immediately clear to me what's going on, while I'd have to look at open()'s documentation to find out what the 'c' flag does.

----------

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

From report at bugs.python.org  Thu Aug 18 17:16:34 2011
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Aug 2011 15:16:34 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313680594.46.0.591277806052.issue12760@psf.upfronthosting.co.za>


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

> I don't know if it's documented behavior

See #12103: it is not documented.

----------

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

From report at bugs.python.org  Thu Aug 18 17:40:30 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 15:40:30 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313682030.9.0.605692997639.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

Working on getting a reasonable large file to test with on my laptop where I have 2.6, 2.7, 3.2. The Python version where the problem became apparent was 2.5.2 as the software is deployed on Debian Lenny.

----------

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

From report at bugs.python.org  Thu Aug 18 18:06:35 2011
From: report at bugs.python.org (David Townshend)
Date: Thu, 18 Aug 2011 16:06:35 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1313683595.52.0.268324784337.issue12760@psf.upfronthosting.co.za>


David Townshend <aquavitae69 at gmail.com> added the comment:

I hope this patch suits you better :-)

I've updated the documentation typo (thanks for pointing that out). I've also changed 'c' to 'x', since I think that if there is a convention we should stick to it.  I don't think that it matters if the glibc docs say 'exclusive', as long it its clear in the python docs what it does, which I think it is. Having said that, I don't really have a strong opinion either way, so I'll happily change it back to 'c' if its preferred.

----------
Added file: http://bugs.python.org/file22935/open_create_x-2.patch

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

From report at bugs.python.org  Thu Aug 18 18:23:23 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:23:23 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313684603.6.0.954302955841.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

using: (except in python2.5 case where simplejson is used, which ought to be the same thing right?)
import time, gc, json, sys

def read_json_blob():
	t0 = time.time()
	fd = open("datatest1.json")
	data = fd.read()
	fd.close()
	t1 = time.time()
	parsed = json.loads(data)
	t2 = time.time()
	print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % (t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
	gc.disable()

read_json_blob()
print(gc.collect())

daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python3.2 gc.py nogc
read file in 1.34s, parsed json in 2.74s, total of 4.07s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python3.2 gc.py
read file in 1.33s, parsed json in 2.71s, total of 4.05s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 56.03s, total of 56.92s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 56.38s, total of 57.27s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py
read file in 0.89s, parsed json in 3.87s, total of 4.75s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py nogc
read file in 0.89s, parsed json in 3.91s, total of 4.80s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.11s, parsed json in 53.00s, total of 53.11s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.14s, parsed json in 53.13s, total of 53.28s
0

Everything is equally slow.. no weird things there, except that Python 3.2 seems to take more time to load the file. Nice performance improvement of the json module in 3.2 compared to older Python versions.


Next up. Trying with cjson which decodes via a binary module:

import time, gc, cjson, sys

def read_json_blob():
	t0 = time.time()
	fd = open("datatest1.json")
	data = fd.read()
	fd.close()
	t1 = time.time()
	parsed = cjson.decode(data)
	t2 = time.time()
	print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % (t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
	gc.disable()

read_json_blob()
print(gc.collect())

daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.46s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py nogc
read file in 0.89s, parsed json in 1.53s, total of 2.42s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.7 gc.py
read file in 0.89s, parsed json in 1.54s, total of 2.43s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel at neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.43s, total of 2.32s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.73s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.16s, parsed json in 1.07s, total of 1.23s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.72s
0
daniel at aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 gc.py nogc
read file in 0.14s, parsed json in 1.06s, total of 1.20s

The file is actually a bit too small for good measurement when using cjson, but interesting point here is obviously the huge difference between GC and no GC in Python 2.5, and quite a bit win in 2.6 too, which becomes a lot more apparent with larger files.

Another interesting thing is that Python 2.6 is consistently faster than 2.7 when the GC is disabled in 2.6, compared to both enabled and disabled in 2.7. The cjson isn't compatible with Python 3.2 so I cannot verify how things work there.

So overall it looks like it's less of a problem in newer versions of Python. We are phasing out the software that is deployed on Debian Lenny so it's a problem that will go away. I don't think I have any objections with closing this ticket again.

----------

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

From report at bugs.python.org  Thu Aug 18 18:29:15 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Aug 2011 16:29:15 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313684955.66.0.399949559381.issue12775@psf.upfronthosting.co.za>


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

IIRC the C acceleration for json were added in 2.7/3.2, and are used automatically when you import json.  In the previous releases the json module was implemented in pure Python.  That explains why it's much slower on Python 2.5/6.

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

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

From report at bugs.python.org  Thu Aug 18 18:33:23 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:33:23 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685203.48.0.806721396211.issue12775@psf.upfronthosting.co.za>


Changes by Daniel Svensson <dsvensson at gmail.com>:


----------
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Aug 18 18:35:55 2011
From: report at bugs.python.org (Daniel Svensson)
Date: Thu, 18 Aug 2011 16:35:55 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685355.72.0.404659725785.issue12775@psf.upfronthosting.co.za>


Daniel Svensson <dsvensson at gmail.com> added the comment:

Yes, but this ticket was only opened due to time delta between no-gc and gc, not as much absolute time, but that's a nice improvement.

----------

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

From report at bugs.python.org  Thu Aug 18 18:36:43 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Aug 2011 16:36:43 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313684603.6.0.954302955841.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313685272.3602.14.camel@localhost.localdomain>


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

> So overall it looks like it's less of a problem in newer versions of
> Python. We are phasing out the software that is deployed on Debian
> Lenny so it's a problem that will go away. I don't think I have any
> objections with closing this ticket again.

Thanks for the comprehensive measurements. Indeed I think it doesn't
seem it is a problem in 2.7/3.2.

----------

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

From report at bugs.python.org  Thu Aug 18 18:50:17 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:50:17 +0000
Subject: [docs] [issue12779] Update packaging documentation
In-Reply-To: <1313686169.0.0.406072932055.issue12779@psf.upfronthosting.co.za>
Message-ID: <1313686217.61.0.791036143758.issue12779@psf.upfronthosting.co.za>


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

(Replying to myself so that this report doesn?t show up in the ?Issues without reply? section of the weekly email)

----------
nosy: +docs at python

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

From report at bugs.python.org  Thu Aug 18 18:51:31 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Aug 2011 16:51:31 +0000
Subject: [docs] [issue11553] Docs for: import, packages, site.py, .pth files
In-Reply-To: <1300189190.68.0.0305569633639.issue11553@psf.upfronthosting.co.za>
Message-ID: <1313686291.53.0.861371159209.issue11553@psf.upfronthosting.co.za>


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

FYI, I have updated the site module and distutils/packaging docs to document the PEP 370 features.  There has been no feedback, so I will backport to 2.7 and close the reports.  See linked bugs to read the changesets.

----------

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

From report at bugs.python.org  Thu Aug 18 19:01:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 18 Aug 2011 17:01:57 +0000
Subject: [docs] [issue12761] Typo in Doc/license.rst
In-Reply-To: <1313512901.16.0.106548527378.issue12761@psf.upfronthosting.co.za>
Message-ID: <1313686917.84.0.938989970481.issue12761@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After a closer look (thanks Ezio), the proper patch should be something like:


diff --git a/Doc/license.rst b/Doc/license.rst
--- a/Doc/license.rst
+++ b/Doc/license.rst
@@ -874,9 +874,8 @@
 zlib
 ----
 
-The :mod:`zlib` extension is built using an included copy of the zlib
-sources if the zlib version found on the system is too old to be
-used for the build::
+The :mod:`zlib` extension is built using the zlib version found on the system,
+but an included copy of the zlib sources is shipped for the Windows build::
 
   Copyright (C) 1995-2011 Jean-loup Gailly and Mark Adler


because the embedded zlib is not used in the linux build (but always the system one, and if absent, no zlib module is built) while we have several references of Modules/zlib/ files in PC/VC* and PCbuild/*.vcproj (that I can't read); adding to nosy the windows expert to have their opinion.

----------
nosy: +brian.curtin, tim.golden
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

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

From sandro.tosi at gmail.com  Thu Aug 18 19:25:42 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 19:25:42 +0200
Subject: [docs] Suggest for documentation
In-Reply-To: <BANLkTinHft5=hEsxrSvM3GkO+5M=DYLxmQ@mail.gmail.com>
References: <BANLkTinHft5=hEsxrSvM3GkO+5M=DYLxmQ@mail.gmail.com>
Message-ID: <CAPdtAj3sq8kivR0wbHqAYgQKn83pyyvo68hn66X=EARqZZ4sBg@mail.gmail.com>

Hello ?lker,

On Mon, Apr 18, 2011 at 16:54, ?lker Arg?n <ilkerargin1989 at gmail.com> wrote:
> Hi,
> The documentation is very informative. However, I can not find the return
> values of methods( for example: list methods ) in the documentation. It
> would be a better documentation if you added them to the documentation.

Could you please explain it a bit better? what do you mean with
'return values of methods'? maybe you can take a method as example and
show us how you would like to change the doc for it.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 18 19:30:25 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 19:30:25 +0200
Subject: [docs] Addition of a very useful link about encodings
In-Reply-To: <BANLkTi=QmC8+sJZ7MLt8Jq0m1q8sY2Zwzw@mail.gmail.com>
References: <BANLkTi=QmC8+sJZ7MLt8Jq0m1q8sY2Zwzw@mail.gmail.com>
Message-ID: <CAPdtAj0+Su-cP1OD_6s6WXn=uh_=xQAb7iyTzHK4QSAuMPub3Q@mail.gmail.com>

Hello Fran?ois,
thanks for your email.

On Thu, Apr 14, 2011 at 14:09, Fran?ois ALLAIN <frallain at gmail.com> wrote:
> Hello,
>
> I would like to add this link at this page of the documentation :
>
> http://sebsauvage.net/python/snyppets/index.html#unicode , this is not so
> clear in the HOWTO how to deal efficiently with all these encoding problems.
>
> Hope you will agree on this point,

One of the strength point of the python doc is that you can download
it and browse it offline. Adding a like to a remote webpage don't help
so much in that view. Probably the best action is for you to contact
the author of that page and convince him to write something to be
included on the python official doc: that would be a tremendous help.

Of course, you can also write yourself something for the python doc
and submit for inclusion :) If you need guidance, you just have to
ask.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 18 23:46:28 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 18 Aug 2011 21:46:28 +0000
Subject: [docs] [issue12781] Mention SO_REUSEADDR near socket doc examples
Message-ID: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following up http://mail.python.org/pipermail/docs/2011-April/004025.html here's a patch to add a notice about SO_REUSEADDR after the examples, so even re-running several times and getting that error, wont scare anyone.

----------
assignee: docs at python
components: Documentation
files: socket_resueaddr.patch
keywords: patch
messages: 142403
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Mention SO_REUSEADDR near socket doc examples
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22944/socket_resueaddr.patch

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

From sandro.tosi at gmail.com  Thu Aug 18 23:47:19 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 18 Aug 2011 23:47:19 +0200
Subject: [docs] Socket server example fails on second and sucessive
 runs. Please set SO_REUSEADDR flag.
In-Reply-To: <BANLkTik0Hq0xLe0+-9YD6+g4U5cU-i6i=w@mail.gmail.com>
References: <BANLkTik0Hq0xLe0+-9YD6+g4U5cU-i6i=w@mail.gmail.com>
Message-ID: <CAPdtAj195MGKfnLss9smLUGxUy2k11P_1pfQTuzhFJEaNu3-Cg@mail.gmail.com>

Hi John,

On Tue, Apr 19, 2011 at 07:25, John Hall <johnhall2.0 at gmail.com> wrote:
> The sockets example runs once because but fails on?successive?runs because a
> socket option flag that allows the port number to be readily reused again
> after the program closed is not set.
> http://docs.python.org/library/socket.html#example
> Solution:
> insert
> s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)

thanks for your input: I've just filed
http://bugs.python.org/issue12781 to get this fixed.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Fri Aug 19 00:36:56 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Fri, 19 Aug 2011 00:36:56 +0200
Subject: [docs] groupindex should be groupdict in dict docs
In-Reply-To: <BANLkTimORDWNyfaqTs7JhVZZphZ4AR3nBw@mail.gmail.com>
References: <BANLkTimORDWNyfaqTs7JhVZZphZ4AR3nBw@mail.gmail.com>
Message-ID: <CAPdtAj2L9bvuQTG5FmMw7iPuTADuaVNe5p-W5y0v-QAa4c=HKA@mail.gmail.com>

Hello Kasturi,

On Thu, Apr 14, 2011 at 05:15, Kasturi R <kastur at gmail.com> wrote:
> http://docs.python.org/library/re.html#regular-expression-objects
> /s/groupindex/groupdict

groupindex is correct: why do you think it's not?

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From kastur at gmail.com  Fri Aug 19 01:27:48 2011
From: kastur at gmail.com (Kasturi R)
Date: Thu, 18 Aug 2011 16:27:48 -0700
Subject: [docs] groupindex should be groupdict in dict docs
In-Reply-To: <CAPdtAj2L9bvuQTG5FmMw7iPuTADuaVNe5p-W5y0v-QAa4c=HKA@mail.gmail.com>
References: <BANLkTimORDWNyfaqTs7JhVZZphZ4AR3nBw@mail.gmail.com>
	<CAPdtAj2L9bvuQTG5FmMw7iPuTADuaVNe5p-W5y0v-QAa4c=HKA@mail.gmail.com>
Message-ID: <CAL6CspojfgSph8RbvcsM19+4A-Vd31VJ3rBNWYjF6hugESuJQw@mail.gmail.com>

Never mind, I confused SRE_Pattern and SRE_Match.

re.compile('(?P<id>hello)').search('hello world').groupdict()

re.compile('(?P<id>hello)').groupindex

-k



On Thu, Aug 18, 2011 at 3:36 PM, Sandro Tosi <sandro.tosi at gmail.com> wrote:
> Hello Kasturi,
>
> On Thu, Apr 14, 2011 at 05:15, Kasturi R <kastur at gmail.com> wrote:
>> http://docs.python.org/library/re.html#regular-expression-objects
>> /s/groupindex/groupdict
>
> groupindex is correct: why do you think it's not?
>
> Regards,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>

From report at bugs.python.org  Fri Aug 19 05:32:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 03:32:14 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QuFoa-0003xu-7g@dinsdale.python.org>


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

New changeset d062d482642c by Eli Bendersky in branch '3.2':
Issue #12672: remove confusing part of sentence in documentation
http://hg.python.org/cpython/rev/d062d482642c

New changeset 558f2270cba8 by Eli Bendersky in branch 'default':
Merge from 3.2
http://hg.python.org/cpython/rev/558f2270cba8

----------

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

From report at bugs.python.org  Fri Aug 19 05:34:25 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 03:34:25 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <E1QuFqi-00043X-AD@dinsdale.python.org>


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

New changeset 893f858c600e by Eli Bendersky in branch '2.7':
Issue #12672: remove confusing part of sentence in documentation
http://hg.python.org/cpython/rev/893f858c600e

----------

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

From report at bugs.python.org  Fri Aug 19 05:34:57 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 19 Aug 2011 03:34:57 +0000
Subject: [docs] [issue12672] Some problems in documentation
	extending/newtypes.html
In-Reply-To: <1312170894.35.0.0326753633212.issue12672@psf.upfronthosting.co.za>
Message-ID: <1313724897.83.0.984614265479.issue12672@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug 19 05:37:19 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 19 Aug 2011 03:37:19 +0000
Subject: [docs] [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313725039.34.0.193763705265.issue12781@psf.upfronthosting.co.za>


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

Wouldn't it be better to just add the flag to the example and then explain it in a few sentences?

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

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

From report at bugs.python.org  Fri Aug 19 14:25:14 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:25:14 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <E1QuO8K-0002iS-H2@dinsdale.python.org>


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

New changeset 59f7bbe1236c by ?ric Araujo in branch '3.2':
Remove obsolete term + indicate how to find the program (#1626300).
http://hg.python.org/cpython/rev/59f7bbe1236c

New changeset adaec1a0dd47 by ?ric Araujo in branch '3.2':
Fix instance I missed in 59f7bbe1236c (#1626300)
http://hg.python.org/cpython/rev/adaec1a0dd47

----------

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

From report at bugs.python.org  Fri Aug 19 14:27:37 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:27:37 +0000
Subject: [docs] [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1313756857.49.0.346907065492.issue10149@psf.upfronthosting.co.za>


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

I was about to commit an edited version of your patch (attached) but then I thought we should check whether this isn?t really a bug.  I just don?t see why expat would chunk without paying heed to the newlines if it is supposed to chunk at newlines.

----------
Added file: http://bugs.python.org/file22945/pyexpat.rst.patch

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

From report at bugs.python.org  Fri Aug 19 14:28:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:07 +0000
Subject: [docs] [issue8617] Better document user site-packages in site
	module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <E1QuOBA-0002sS-Qo@dinsdale.python.org>


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

New changeset b3f72b6450f1 by ?ric Araujo in branch '2.7':
Improve documentation for PEP 370 support in site module (#8617).
http://hg.python.org/cpython/rev/b3f72b6450f1

----------

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

From report at bugs.python.org  Fri Aug 19 14:28:07 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 19 Aug 2011 12:28:07 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <E1QuOBA-0002sS-R9@dinsdale.python.org>


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

New changeset e9022dc7a411 by ?ric Araujo in branch '2.7':
Remove obsolete term + indicate how to find the program (#1626300).
http://hg.python.org/cpython/rev/e9022dc7a411

----------

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

From report at bugs.python.org  Fri Aug 19 14:35:36 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 12:35:36 +0000
Subject: [docs] [issue8617] Better document user site-packages in site
	module doc
In-Reply-To: <1273017080.78.0.24275979751.issue8617@psf.upfronthosting.co.za>
Message-ID: <1313757336.79.0.532097544996.issue8617@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug 19 14:58:56 2011
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Aug 2011 12:58:56 +0000
Subject: [docs] [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1313758736.55.0.525286983031.issue10149@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fred at fdrake.net> added the comment:

Chunking of the data is expected with Expat.  There are no promises about *where* chunks are broken; the underlying behavior will break at line endings, but is not limited to that.

Setting buffer_text informs the Python wrapper that it's allowed to combine the chunks reported by the Expat library; this was made optional since it could affect working applications (changing the default with the move to Python 3 may have been acceptable, though).

----------
nosy: +fdrake

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

From report at bugs.python.org  Fri Aug 19 15:15:34 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Aug 2011 13:15:34 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313759734.34.0.475440521447.issue12682@psf.upfronthosting.co.za>


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

I would say I find "accepted" little useful in practice. Removing it would avoid the confusion with its various (intended or not) meanings.

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

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

From report at bugs.python.org  Fri Aug 19 15:16:58 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 13:16:58 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313759818.5.0.265649986064.issue12682@psf.upfronthosting.co.za>


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

+1

Martin, should we convert all the "accepted" to "fixed" before removing it?

----------

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

From report at bugs.python.org  Fri Aug 19 15:33:03 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Aug 2011 13:33:03 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1313760783.84.0.770084926143.issue12409@psf.upfronthosting.co.za>


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

>From IRC:

<fdrake> After last being pressed on this, I got to thinking about it more.  Back in the day, that's all the doc there was about the tool-chain.  With Sphinx standing as a successful independent project, the tool documentation need no longer be part of any of the python.org docs; what's left probably can be moved.
<fdrake> (Yes, I'm withdrawing my objection.)

So, I am in favor of moving the Python-specific parts of Doc/documenting (if any) to the devguide and just link to the upstream Sphinx docs (which are a subset of our Doc/documenting) for the markup and suchlike.

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

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

From report at bugs.python.org  Fri Aug 19 15:48:40 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 13:48:40 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1313761720.59.0.807411594466.issue12409@psf.upfronthosting.co.za>


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

+1

----------

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

From report at bugs.python.org  Fri Aug 19 19:03:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 19 Aug 2011 17:03:57 +0000
Subject: [docs] [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313773437.73.0.656635730425.issue12781@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sure it could be a solution, but I didn't go that way since it *may* complicate the example (which I see a something to get quick ready to test some code, there's always time for improvements later). I'm fine either way.

----------

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

From report at bugs.python.org  Fri Aug 19 20:47:30 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 18:47:30 +0000
Subject: [docs] [issue1626300] 'Installing Python Modules' does not work for
	Windows
Message-ID: <1313779650.23.0.647868967385.issue1626300@psf.upfronthosting.co.za>


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

On my fresh install, double clicking *does* run the file as it should, but the window disappears immediately, erasing output and error tracebacks, unless one adds something like ``input("Hit Enter to quit") at the end of the script so the user can see any output.

----------

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

From report at bugs.python.org  Fri Aug 19 21:27:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 19:27:47 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313782067.5.0.809147765497.issue12682@psf.upfronthosting.co.za>


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

Only if the issue is closed, so that it actually means 'fixed'.
Otherwise, just delete it.

The following data suggests to me that 'accepted' is a de facto synonym for 'fixed' and therefore useless and might as well be removed.
N     Issue category
3290  fixed
    68  open
  3219  closed
     354  feature request (and closed)
     302  behavior
     126  other type
    2437  type not specified
       346  documentation component (and type not specified)
       679  library component

The type field has been, at least in the past, greatly underused. But of the last 679, only 27 were in the last 3 years.

----------

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

From report at bugs.python.org  Fri Aug 19 22:24:47 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 20:24:47 +0000
Subject: [docs] [issue12745] Python2 or Python3 page
In-Reply-To: <1313202956.45.0.192825268179.issue12745@psf.upfronthosting.co.za>
Message-ID: <1313785487.14.0.279690992833.issue12745@psf.upfronthosting.co.za>


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

I agree with your sentiments about Python 2 while being aware that not all agree yet and that the current Wiki page was the result of some heated discussion and compromise. I also agree that the page could use tweaking/updating/rewriting. For one thing the supposed 2010 date in inconsistent with 3.2 being released.

"Python 3 is the future of the language." kind of implies that it is not the current version of the language. I would change that to "Python 3 is the present and future of the language"

I might start with discussion of 3 rather that 2.

I am closing this simply because it is not about changing the CPython repository, which is what the tracker tracks. There is no way to attach and review a wiki diff here.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Aug 19 23:09:36 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Aug 2011 21:09:36 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1313759818.5.0.265649986064.issue12682@psf.upfronthosting.co.za>
Message-ID: <4E4ED10F.8040906@v.loewis.de>


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

> Martin, should we convert all the "accepted" to "fixed" before removing it?

That's not strictly necessary. It would only be retired (roundup does
not support true removal), and as such would then still show up in
issues that currently use it, but not show up elsewhere anymore.

----------

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

From report at bugs.python.org  Fri Aug 19 23:15:20 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Aug 2011 21:15:20 +0000
Subject: [docs] [issue12682] Meaning of 'accepted' resolution as documented
	in	devguide
In-Reply-To: <1312297631.98.0.460065012433.issue12682@psf.upfronthosting.co.za>
Message-ID: <1313788519.9.0.355531766753.issue12682@psf.upfronthosting.co.za>


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

OK, I removed the resolution and its documentation from the devguide in 3f4710b6baf9.

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

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

From report at bugs.python.org  Sat Aug 20 01:02:40 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 19 Aug 2011 23:02:40 +0000
Subject: [docs] [issue12787] xmlrpc.client documentation (MultiCall Objects)
	points	to a broken link
Message-ID: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

following up http://mail.python.org/pipermail/docs/2011-March/003506.html , I verified that indeed

http://www.xmlrpc.com/discuss/msgReader$1208

is broken. I wrote to dave at scripting.com (the address you get when viewing http://www.xmlrpc.com/discuss/) on march and just now I re-wrote again, but I got no reply and the link is still broken.

I tried finding another source for the same doc, but it seems it's only available on xmlrpc.com (or some other dead links). I found, tho, the relative article on the wayback machine:

http://web.archive.org/web/20060624230303/http://www.xmlrpc.com/discuss/msgReader$1208?mode=topic

Now, what should we do about this? remove the link completely? but then how can a user find information about multicalls? should we incorporate that article in our doc (do the licences allow us?)?

Cheers,
Sandro

----------
assignee: docs at python
components: Documentation
messages: 142504
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: needs patch
status: open
title: xmlrpc.client documentation (MultiCall Objects) points to a broken link
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 20 01:02:42 2011
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Aug 2011 23:02:42 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313794962.15.0.578908481397.issue12775@psf.upfronthosting.co.za>


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

2.6 is in security fix only mode and the OP agrees not applicable to current

----------
nosy: +terry.reedy
resolution:  -> out of date
status: open -> closed

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

From sandro.tosi at gmail.com  Sat Aug 20 01:03:16 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 20 Aug 2011 01:03:16 +0200
Subject: [docs] Broken link in Python manual
In-Reply-To: <AANLkTimsw7=SbGqhVtKJdTxcLMWWOPw6QcVkbvqK5S__@mail.gmail.com>
References: <AANLkTikaRQZsg-BHMBof5myHVA6iNNCdp10tpLL1e+P-@mail.gmail.com>
	<AANLkTimsw7=SbGqhVtKJdTxcLMWWOPw6QcVkbvqK5S__@mail.gmail.com>
Message-ID: <CAPdtAj2EVn=jB+i=uqTGxoVrqVt2QLnLNwO1or_NA7=3jCQ9Sw@mail.gmail.com>

2011/3/22 Sandro Tosi <sandro.tosi at gmail.com>:
> Hi ?ukasz,
> thanks for your email.
>
> 2011/3/9 ?ukasz Czerwi?ski <lc277642 at students.mimuw.edu.pl>:
>> Hello,
>> In the beginning
>> of?http://docs.python.org/library/xmlrpclib.html#multicall-objects?there is
>> a broken link in sentence:
>>>
>>> In?http://www.xmlrpc.com/discuss/msgReader%241208,
>
> Indeed it's broken, and in general http://www.xmlrpc.com/discuss . I
> wrote to the webmaster, let's see how it goes.

The link is still broken: I've just filed
http://bugs.python.org/issue12787 to track the issue.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sat Aug 20 01:34:44 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 20 Aug 2011 01:34:44 +0200
Subject: [docs] missing info for the documentation of set.add()
In-Reply-To: <op.vtty10i0f366wy@athina.eecs.qmul.ac.uk>
References: <op.vtty10i0f366wy@athina.eecs.qmul.ac.uk>
Message-ID: <CAPdtAj21EHq3PsPXA8wkKfRD7Sh0+UNkaqkRitp+-n-n+Ws=sw@mail.gmail.com>

Hello Ioannis,
thanks for your email.

On Tue, Apr 12, 2011 at 17:09, Ioannis Tziakos <mail at itziakos.gr> wrote:
> Hi All,
>
> I have noticed that there is a difference in the current documentation for
> python 2.7.1 and
> the doc-string of set.add().
>
> The documentation (http://docs.python.org/library/stdtypes.html#set) reads
>
> --------
> add(elem)
> ? ? ? ?Add element elem to the set.
> --------
>
>
> While python 2.7.1 doc string provides additional info
>
> --------
> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "copyright", "credits" or "license()" for more information.
>>>>
>>>> help(set.add)
>
> Help on method_descriptor:
>
> add(...)
> ? ? ?Add an element to a set.
>
> ? ? ?This has no effect if the element is already present.
>
>>>>
> --------

In mathematics, adding an element to a set that it's already in it, is
a "no-op" , and the same in Python. I don't the small difference
between the docstring (more explicit) and the documentation (that
simply reflect the math behavior) needs any change.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Aug 20 09:16:48 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Aug 2011 07:16:48 +0000
Subject: [docs] [issue12787] xmlrpc.client documentation (MultiCall Objects)
	points	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <1313824608.81.0.337652721933.issue12787@psf.upfronthosting.co.za>


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

AFAIU xmlrpclib.MultiCall implements the technique described on the broken link, and the examples look pretty clear to me, so the user doesn't have to follow the link to understand how to use it.
I think it's good to keep a link around, in case the user wants to understand better how it works, but it could also be in a footnote.

This is what I would do:
  1) write something like "The xmlrpc.MultiCall object provides a way to  encapsulate multiple calls to a remote server into a single request?."
  2) in the footnote write something like "[1]: This approach has been first presented in `a discussion on xmlrpc.com <link-to-web.archive.org>`_."

Possibly you could leave an rst comment explaining that the original link is down and that we are using the web.archive.org one until the page is back up.
FWIW http://www.xmlrpc.com/discuss/topics seems to work, and there are a few discussions from last month, but the links are broken.

----------

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

From report at bugs.python.org  Sat Aug 20 17:08:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 20 Aug 2011 15:08:43 +0000
Subject: [docs] [issue12787] xmlrpc.client documentation (MultiCall Objects)
	points	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <E1QunA9-0005zU-ET@dinsdale.python.org>


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

New changeset e8f878837eae by Sandro Tosi in branch '2.7':
#12787: link original MultiCall proposal to webarchive and in a footnote
http://hg.python.org/cpython/rev/e8f878837eae

New changeset ab11edca2310 by Sandro Tosi in branch '3.2':
#12787: link original MultiCall proposal to webarchive and in a footnote
http://hg.python.org/cpython/rev/ab11edca2310

New changeset 0fa18bc5427b by Sandro Tosi in branch 'default':
#12787: merge with 3.2
http://hg.python.org/cpython/rev/0fa18bc5427b

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

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

From report at bugs.python.org  Sat Aug 20 17:10:22 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 15:10:22 +0000
Subject: [docs] [issue12787] xmlrpc.client documentation (MultiCall Objects)
	points	to a broken link
In-Reply-To: <1313794960.03.0.534154914638.issue12787@psf.upfronthosting.co.za>
Message-ID: <1313853022.49.0.514995244155.issue12787@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Ezio for the suggestions.

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

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

From sandro.tosi at gmail.com  Sat Aug 20 17:59:55 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 20 Aug 2011 17:59:55 +0200
Subject: [docs] I or we, and credits
In-Reply-To: <4DA5E5CD.1050409@underhill.ca>
References: <4DA5E5CD.1050409@underhill.ca>
Message-ID: <CAPdtAj0MdpmK3fvuCQ1Rg_SUf57_c-DUCkHRx5gOfDT2+zDyWA@mail.gmail.com>

Hello Martin,
thanks for your email.

On Wed, Apr 13, 2011 at 20:05, Martin Feuchtwanger <martinf at underhill.ca> wrote:
> I notice the writer or writers of the excellent tutorial occasionally refer
> to themselves in the first person singular (I), but i see nobody credited.
>
> Assuming it is a group effort, by Python Software Foundation, shouldn't the
> writers refer to themselves in the first person plural (we)?
>
> I know i sound picky and critical, but overall, i just want to contribute
> ... to improve things.

Thanks for your suggestion, but we think it's not necessary to change them.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Aug 20 22:54:18 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Aug 2011 20:54:18 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313873658.26.0.612219935206.issue12768@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Aug 20 23:49:07 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 20 Aug 2011 21:49:07 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
Message-ID: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Following http://mail.python.org/pipermail/docs/2011-June/004727.html I've updated the mimetypes module doc.

Some changes I would like to do (but I didn't, since I'd like to hear comments):

- move the example of the module before the definition of MimeTypes class (so right below mimetypes.common_types)
- move all the text about MimeTypes class in the subsection that talks about it.

Comments, as always, are welcome.

----------
assignee: docs at python
components: Documentation
files: mimetypes_doc_update.patch
keywords: patch
messages: 142572
nosy: docs at python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Update mimetypes documentation
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22968/mimetypes_doc_update.patch

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

From sandro.tosi at gmail.com  Sat Aug 20 23:50:49 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 20 Aug 2011 23:50:49 +0200
Subject: [docs] Bug in mimetypes.MimeTypes documentation
In-Reply-To: <BANLkTinUSDUL0Y0MYvMJhDk2VCTq4Ho=8g@mail.gmail.com>
References: <BANLkTinUSDUL0Y0MYvMJhDk2VCTq4Ho=8g@mail.gmail.com>
Message-ID: <CAPdtAj3qDpaQBSq=OKzJgop9L+RNXMYq-OXTMPeQr7nWC1mqBQ@mail.gmail.com>

Hello ?ukasz,
thanks for your email.

2011/6/9 ?ukasz Cie?nik <lukasz.ciesnik at gmail.com>:
> Hello,
>
> I have found that MimeTypes class does not provide same interface
> as mimetypes module does in terms of ``types_map`` and ``common_types``

Actually, there was a lot of missing info in mimetypes doc, so I've
opened http://bugs.python.org/issue12798 to get them fixed.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Aug 21 00:26:08 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 21 Aug 2011 00:26:08 +0200
Subject: [docs] Suggested improvement for Python Tutorial part 7.2 -
 'Reading and writing files'
In-Reply-To: <AANLkTim5yg7fbaHDfoUu6ghi4U6dUT+fYM67-Poe+jPR@mail.gmail.com>
References: <AANLkTim5yg7fbaHDfoUu6ghi4U6dUT+fYM67-Poe+jPR@mail.gmail.com>
Message-ID: <CAPdtAj1hN+wtu+rFRkHF8abWfx+2Hp2p7J_JWq2myznT5vxrZA@mail.gmail.com>

Hello Mark,
thanks for your detailed email.

On Tue, Mar 29, 2011 at 23:47, Mark Ballard <markjballard at googlemail.com> wrote:
> Hello
>
> May I, a mere beginner,? be so bold as to suggest a modification of your
> excellent Python Tutorial?
> I think certain modifications of section 7.2
> (http://docs.python.org/tutorial/inputoutput.html) would be of great
> assistance to beginners.
> First of all, the order in which the different file operations are presented
> could be changed for greater comprehension. Section 7.2 begins the
> beginners' introduction to file objects (after a quick introduction to
> opening/creating files) by giving a rather sizable description of read
> functions, with examples. Since the beginner at this stage hasn't learned
> the first thing about writing to files, she is unlikely to have any test
> files on which to perform the given read functions. This section on reading
> files is therefore redundant until the beginner has got to the section
> further on that describes how to write files, after which she must return to
> the start of the section to do the read samples and effectively read the
> section backwards. It would be more helpful to have the write tutorial
> before the read tutorial.
> In addition to this confusion of ordering, I had some trouble following the
> given read and write examples.
> Please refer to this example transcript of my attempt to follow the
> instructions in section 7.2:
> * STEP 1 - I open a file for reading and writing and write to the file
>>>> f = open('/tmp/workfile', 'r+')
>>>> print f
> <open file '/tmp/workfile', mode 'r+' at 0xb76a31d8>
>>>> f.read()
> ''
>>>> f.write('this is first line of file\n')
>
> * STEP 2 - I attempt to read what I've written, but without success
>>>> f.readline()
> ''
>>>> f.readlines()
> []
>
> * STEP 3 - Bemused, I try writing and reading some more
>>>> f.write('this is a test')
>>>> f.readlines()
> []
>
> * BREAKOUT - Unable to find any explanation in 7.2 I go for help elsewhere
> ? ? ? ? ? ? ? ? ? ? ? ? After some time, I find it in the?Python Tutor mail
> list
> ? ? ? ? ? ? ? ? ? ? ? ? (here:
> http://mail.python.org/pipermail/tutor/2003-July/024154.html)
> * STEP 4 - Using f.close() I successfully read what I've written
> ? ? ? ? ? ? ? ? ?But only one of my previously written lines is there
>>>> f.close()
>>>> f = open('/tmp/workfile', 'r+')
>>>> f.readlines()
> ['this is first line of file\n']
>
> * STEP 5 - Bemused, I try writing another line
> ? ? ? ? ? ? ? ? ?And use the knowledge gleaned from the Python Tutor Mail
> list to reset the file pointer
>>>> f.write('this is second line\n')
>>>> f.readlines()
> []
>>>> f.seek(0)
>>>> f.readlines()
> ['this is first line of file\n']
>
> * STEP 6 - But where are the other lines I've written?
>>>> f.readlines()
> []
> * STEP 7 - Bemused, I write yet another line to the file, reset the pointer
> and read it back
>>>> f.write('this is what where?\n')
>>>> f.seek(0)
>>>> f.readlines()
> ['this is first line of file\n', 'this is what where?\n']
>>>>
>
> For what to me is an inexplicable reason, my last attempt at writing to this
> file seemed to be successful: it read back. But all my previous attempts to
> write a second line have been lost in the ether. Now I'm sure I'll work this
> out eventually. But perhaps the tutorial could clarify some of these points.

I suggest to consult python-list[1] and ask there clarification about
those points.

[1] http://mail.python.org/mailman/listinfo/python-list

> I would like to suggest that one way to improve 7.2 would be to include at
> the beginning of the section, after a simple introduction of write and read
> with basic one line examples, a description of the file pointer and why its
> important in reading back what one has written. It may then use multiple
> line writes and reads to demonstrate how these differ. And perhaps then some
> word on these phantom writes?

could you please log an issue on http://bugs.python.org/ explaining
(possible with concrete examples, even better with a patch) how you
would like to see that part changed?

Thanks in advance,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From matrixhasu at gmail.com  Sun Aug 21 01:05:51 2011
From: matrixhasu at gmail.com (Sandro Tosi)
Date: Sun, 21 Aug 2011 01:05:51 +0200
Subject: [docs] General FAQ - How Stable, rewording
In-Reply-To: <AANLkTin938hqRq85X0EbvbC75=1cWE1iYL-op8poNetG@mail.gmail.com>
References: <AANLkTin938hqRq85X0EbvbC75=1cWE1iYL-op8poNetG@mail.gmail.com>
Message-ID: <CAPdtAj378XbOSFE_PHA2_UAKexBORBAp7cc_1vo7Bqd1t4okfg@mail.gmail.com>

Hello Regis,
thanks for your email.

On Mon, Mar 28, 2011 at 04:36, Regis Frey <RegisFrey at darkfirestudios.com> wrote:
> http://docs.python.org/faq/general.html#how-stable-is-python
> "Python 2 code will generally not run unchanged in Python 3." would
> read more clearly as "Python 2 code often requires changes to run in
> Python 3."

Thanks for your input, but we think it's not necessary to change that sentence.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sun Aug 21 14:03:34 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:03:34 +0000
Subject: [docs] [issue12781] Mention SO_REUSEADDR near socket doc examples
In-Reply-To: <1313703988.58.0.161821822938.issue12781@psf.upfronthosting.co.za>
Message-ID: <1313928214.75.0.461307149615.issue12781@psf.upfronthosting.co.za>


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

+1 to Sandro?s patch.  Documenting all SO_* constants should be another bug; right now, there is only an index entry for ?SO_*?, I suppose for the benefit of C programmers wanting to know where the constants are defined.  I think the reason for not documenting all constants is that people should look them up in a C/kernel reference manual.

----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Sun Aug 21 14:25:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Aug 2011 12:25:28 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1313929528.08.0.737461926517.issue12798@psf.upfronthosting.co.za>


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

> Some changes I would like to do
+1 on those.

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

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

From report at bugs.python.org  Mon Aug 22 06:39:28 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 04:39:28 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313987967.04.0.743295621052.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

Threading module docstrings added for all classes and public methods; mainly used a summarised version of information from the documentation.

----------
keywords: +patch
nosy: +gjcross
Added file: http://bugs.python.org/file22986/threading_docstrings.patch

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

From report at bugs.python.org  Mon Aug 22 06:56:15 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 04:56:15 +0000
Subject: [docs] [issue12767] document threading.Condition.notify
In-Reply-To: <1313548629.79.0.0632318255733.issue12767@psf.upfronthosting.co.za>
Message-ID: <1313988975.84.0.652953683692.issue12767@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

I have added documentation for the 'n' parameter of threading.Condition.notify as part of the overhaul of the threading module's docstrings.

Reference: #12768

----------
nosy: +gjcross

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

From report at bugs.python.org  Mon Aug 22 07:11:15 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:11:15 +0000
Subject: [docs] [issue1215] Python hang when catching a segfault
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313989875.14.0.814244389052.issue1215@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

The documentation for this can now point to the faulthandler module (in Python 3).

----------
nosy: +poolie

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

From report at bugs.python.org  Mon Aug 22 07:11:33 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:11:33 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313987967.04.0.743295621052.issue12768@psf.upfronthosting.co.za>
Message-ID: <CAF-Rda-j0oCzV0_=BSH3NvPWuKmiDgdGWiLjJpHwsCmuh3PvFA@mail.gmail.com>


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

On Mon, Aug 22, 2011 at 07:39, Graeme Cross <report at bugs.python.org> wrote:

>
> Graeme Cross <gjcross at gmail.com> added the comment:
>
> Threading module docstrings added for all classes and public methods;
> mainly used a summarised version of information from the documentation.
>

Thanks for the patch, Graeme.
I will try to find time to review and apply it in a few days, if no one else
will do it until then.

Eli

----------
Added file: http://bugs.python.org/file22987/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12768>
_______________________________________
-------------- next part --------------
<div dir="ltr"><div class="gmail_quote">On Mon, Aug 22, 2011 at 07:39, Graeme Cross <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
Graeme Cross &lt;<a href="mailto:gjcross at gmail.com">gjcross at gmail.com</a>&gt; added the comment:<br>
<br>
Threading module docstrings added for all classes and public methods; mainly used a summarised version of information from the documentation.<br></blockquote></div><br><br>Thanks for the patch, Graeme.<br>I will try to find time to review and apply it in a few days, if no one else will do it until then.<br>

<br>Eli<br></div>

From report at bugs.python.org  Mon Aug 22 07:12:28 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:12:28 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313989948.85.0.257164678379.issue12768@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file22987/unnamed

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

From report at bugs.python.org  Mon Aug 22 07:12:52 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 05:12:52 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313989972.22.0.581278598365.issue12768@psf.upfronthosting.co.za>


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

Graeme - could you specify which version of Python this patch applies to?

----------

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

From report at bugs.python.org  Mon Aug 22 07:15:01 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:15:01 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313990101.47.0.357926028811.issue1215@psf.upfronthosting.co.za>


Changes by Martin Pool <mbp at sourcefrog.net>:


----------
title: Python hang when catching a segfault -> documentation doesn't say that you can't handle C segfaults from python

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

From report at bugs.python.org  Mon Aug 22 07:18:05 2011
From: report at bugs.python.org (Graeme Cross)
Date: Mon, 22 Aug 2011 05:18:05 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1313990285.85.0.624896121738.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

The patch applies to tip.

----------

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

From report at bugs.python.org  Mon Aug 22 07:27:06 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 05:27:06 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1313990826.85.0.105524850764.issue1215@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

This patch tries to improve the documentation a bit more to address the issue that confused tebeka and to advertise faulthandler.  Could someone review or apply it?

----------
keywords: +patch
Added file: http://bugs.python.org/file22989/20110822-1525-signal-doc.diff

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

From report at bugs.python.org  Mon Aug 22 08:05:58 2011
From: report at bugs.python.org (Martin Pool)
Date: Mon, 22 Aug 2011 06:05:58 +0000
Subject: [docs] [issue10713] re module doesn't describe string boundaries
	for \b
In-Reply-To: <1292461535.35.0.85810781117.issue10713@psf.upfronthosting.co.za>
Message-ID: <1313993157.96.0.936422741611.issue10713@psf.upfronthosting.co.za>


Martin Pool <mbp at sourcefrog.net> added the comment:

> Note, 366 above confirms it's never true for an empty string.  The
documentation states that \B "is just the opposite of \b" yet
re.match(r'\b', '') returns None and so does \B so \B isn't the opposite
of \b in all cases.

This is also a bit strange if you follow the Perl line of reasoning of imagining there are non-word characters outside the string.  And, indeed, in Perl, 

  "" =~ /\B/

is true.

So this patch adds some tests for \b behaviour and some docs.  I think possible \B should actually change, but that would be a bigger (perhaps impossible?) change.

----------
keywords: +patch
nosy: +poolie
Added file: http://bugs.python.org/file22991/20110822-1604-re-docs.diff

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

From report at bugs.python.org  Mon Aug 22 09:58:22 2011
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Aug 2011 07:58:22 +0000
Subject: [docs] [issue12775] immense performance problems related to the
	garbage	collector
In-Reply-To: <1313654455.78.0.0130183916122.issue12775@psf.upfronthosting.co.za>
Message-ID: <1313999902.76.0.277264683177.issue12775@psf.upfronthosting.co.za>


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

For the record, the speed improvement in 2.7 likely results from 79276316b94b. GC used to be quadratic with the number of objects, and is now only linear.

----------

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

From report at bugs.python.org  Mon Aug 22 11:33:24 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Aug 2011 09:33:24 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314005604.67.0.439809818887.issue12768@psf.upfronthosting.co.za>


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

The usual procedure for committing to both 3.2 and 3.3 is to apply a patch to 3.2 and then merge it to 3.3 - could you check if the patch also works for 3.2 and if not, generate a patch for 3.2? I will do the merge when committing.

----------

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

From report at bugs.python.org  Mon Aug 22 20:52:09 2011
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Aug 2011 18:52:09 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1313760783.84.0.770084926143.issue12409@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7FyA5og2bhMbqLJETwxgtT2MAH4QxVdnRpt+zqsBsBzA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

+1

----------
Added file: http://bugs.python.org/file23005/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12409>
_______________________________________
-------------- next part --------------
+1<br>

From report at bugs.python.org  Mon Aug 22 23:40:53 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 22 Aug 2011 21:40:53 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314049253.04.0.267230613847.issue12409@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


Removed file: http://bugs.python.org/file23005/unnamed

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

From report at bugs.python.org  Tue Aug 23 00:05:06 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 22 Aug 2011 22:05:06 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314050706.5.0.808608585953.issue12409@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

@Fred: thanks about it :)

@?ric: I just want to have clear in mind what you mean; my original proposal was to move completely, the whole section "Documenting python" to devguide since it contains building instructions and how's the markup works for python. Is your proposal different and so, as I can read, to just move the building part to devguide and the rest of it be left in python documentation with links to sphinx upstream documentation?

But one aspect I think it needs to be done as a prerequisite to this migration is: standardizing the sphinx/tools versions used to build the doc.

devguide is version-agnostic, so we can talk about (without convoluted sentences) only about one way to build the doc.

This was raised several times, even recently, on python-dev so I'm going to resurrect that thread so we can discuss there the pros/cons and then see from the outcome how we can move forward.

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

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

From report at bugs.python.org  Tue Aug 23 01:38:20 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Aug 2011 23:38:20 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314056300.6.0.0554640165983.issue12409@psf.upfronthosting.co.za>


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

My comment was ambiguous, let me rephrase it: I am in favor of moving cpython/Doc/documenting to the devguide.  Then, in the devguide, I would like to remove all the doc that?s just duplicating the upstream Sphinx docs, keeping only links and Python-specific parts.

> But one aspect I think it needs to be done as a prerequisite to this migration is:
> standardizing the sphinx/tools versions used to build the doc.
If this gets rejected, we can move the Documenting tree to the devguide anyway, we?ll just have to add a few paragraphs for 2.7 differences.

----------

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

From report at bugs.python.org  Tue Aug 23 09:24:54 2011
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Aug 2011 07:24:54 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314084294.59.0.810766975389.issue12409@psf.upfronthosting.co.za>


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

+1, and as Eric says, we can do it without changing versions of Sphinx used.

----------

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

From report at bugs.python.org  Tue Aug 23 10:05:20 2011
From: report at bugs.python.org (Roger Li)
Date: Tue, 23 Aug 2011 08:05:20 +0000
Subject: [docs] [issue12823] Broken link in "SSL wrapper for socket objects"
	document
Message-ID: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>


New submission from Roger Li <wormreg at gmail.com>:

In http://docs.python.org/release/3.1.3/library/ssl.html
You will find a link at the bottom named "Introducing SSL and Certificates using OpenSSL", it's a broken link.

The server may be down or not exist, the only version I can find is http://web.archive.org/web/20090429050651/http://old.pseudonym.org/ssl/wwwj-index.html

Please consider to replace the link to the new one.

----------
assignee: docs at python
components: Documentation
messages: 142794
nosy: docs at python, iworm
priority: normal
severity: normal
status: open
title: Broken link in "SSL wrapper for socket objects" document
versions: Python 3.1

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

From report at bugs.python.org  Tue Aug 23 10:49:12 2011
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Aug 2011 08:49:12 +0000
Subject: [docs] [issue12825] Missing and incorrect link to a command line
	option.
Message-ID: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>


New submission from Kyle Simpson <illwhipyou at gmail.com>:

The documentation for the runpy module has a link to the -m command line option. In version 2.7.2 of the docs, the link doesn't exist.

http://docs.python.org/release/2.7/library/runpy.html
http://docs.python.org/release/2.7.2/library/runpy.html

If you run

    touch library/runpy.rst
    make html

then the link is created, but with an anchor of "cmdoption-unittest-discover-m" instead of "cmdoption-m".

http://docs.python.org/release/2.7.2/using/cmdline.html#cmdoption-unittest-discover-m

----------
assignee: docs at python
components: Documentation
messages: 142797
nosy: Kyle.Simpson, docs at python
priority: normal
severity: normal
status: open
title: Missing and incorrect link to a command line option.
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 23 10:53:35 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 08:53:35 +0000
Subject: [docs] [issue12825] Missing and incorrect link to a command line
	option.
In-Reply-To: <1314089351.88.0.463176028953.issue12825@psf.upfronthosting.co.za>
Message-ID: <1314089615.06.0.296743715924.issue12825@psf.upfronthosting.co.za>


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

It?s weird that the docs under /release/2.7 has the link but not the one under /.

----------
nosy: +eric.araujo, georg.brandl

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

From report at bugs.python.org  Tue Aug 23 15:58:43 2011
From: report at bugs.python.org (Kyle Simpson)
Date: Tue, 23 Aug 2011 13:58:43 +0000
Subject: [docs] [issue12602] Missing using docs cross-references
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1314107923.16.0.75507450752.issue12602@psf.upfronthosting.co.za>


Changes by Kyle Simpson <illwhipyou at gmail.com>:


----------
nosy: +Kyle.Simpson

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

From mudge911 at terranne.com  Tue Aug 23 05:21:33 2011
From: mudge911 at terranne.com (T.Hill)
Date: Mon, 22 Aug 2011 20:21:33 -0700
Subject: [docs] Doc link incorrect
Message-ID: <4E531CBD.4030109@terranne.com>

  Found a link that needs to be corrected...
On page:
http://docs.python.org/release/2.6/download

The PLAIN TEXT (zipped) link is:
*http://docs.python.org/ftp/python/doc/2.6/python-2.6-docs-pdf-text.zip*

Should be changed to:
*http://docs.python.org/ftp/python/doc/2.6/python-2.6-docs-text.zip*

Note: Removed "-pdf" before "-text".

Thanks for the documentation...
Cal

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

From aron at ahmadia.net  Tue Aug 23 13:57:02 2011
From: aron at ahmadia.net (Aron Ahmadia)
Date: Tue, 23 Aug 2011 14:57:02 +0300
Subject: [docs] errant documentation in Tutorial Section 2.1 (2.7.2 and 3.2
	are affected)?
Message-ID: <CAPhiW4gmJzZaZ1Sjjev9uENcoMY0jaxQ5zN4+YGJmHG9mpk6fw@mail.gmail.com>

"When a script file is used, it is sometimes useful to be able to run the
script and enter interactive mode afterwards. This can be done by passing *
-i*<http://docs.python.org/using/cmdline.html#cmdoption-unittest-discover-i>
before
the script. (This does not work if the script is read from standard input,
for the same reason as explained in the previous paragraph.)"

Reading the previous paragraph doesn't explain why the Python interpreter
cannot enter interactive mode when a file has replaced stdin, so I am left
to guess that perhaps it is because once the file has been connected to
standard input the interpreter can no longer receive input from the user's
tty.
Thanks,
Aron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110823/21a6ac8f/attachment.html>

From report at bugs.python.org  Tue Aug 23 19:46:57 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 17:46:57 +0000
Subject: [docs] [issue12828] xml.dom.minicompat is not documented
Message-ID: <1314121617.5.0.895410943337.issue12828@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

There's no documentation for xml.dom.minicompat - it's a public module and it should have (even a brief) doc.

----------
assignee: docs at python
components: Documentation
messages: 142845
nosy: docs at python, sandro.tosi
priority: normal
severity: normal
status: open
title: xml.dom.minicompat is not documented
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 23 19:54:27 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Aug 2011 17:54:27 +0000
Subject: [docs] [issue12828] xml.dom.minicompat is not documented
In-Reply-To: <1314121617.5.0.895410943337.issue12828@psf.upfronthosting.co.za>
Message-ID: <1314122067.78.0.678833264538.issue12828@psf.upfronthosting.co.za>


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

I?m not sure at all this module should be treated as anything but an internal detail.  The docstring of xml.dom only mentions two submodules.

----------
components: +XML
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Aug 23 19:57:09 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 17:57:09 +0000
Subject: [docs] [issue12828] xml.dom.minicompat is not documented
In-Reply-To: <1314122067.78.0.678833264538.issue12828@psf.upfronthosting.co.za>
Message-ID: <CAPdtAj1NmCG6UEqGzKmAaXy=obRN_KzK4twxg063Yo7gYHM90g@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I?m not sure at all this module should be treated as anything but an internal detail. ?The docstring of xml.dom only mentions two submodules.

If it's an implementation detail, then probably a small reference in
the module docstring could be helpful.

----------

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

From report at bugs.python.org  Tue Aug 23 20:05:10 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Aug 2011 18:05:10 +0000
Subject: [docs] [issue12823] Broken link in "SSL wrapper for socket objects"
	document
In-Reply-To: <1314086720.91.0.705244554246.issue12823@psf.upfronthosting.co.za>
Message-ID: <1314122710.26.0.416155489511.issue12823@psf.upfronthosting.co.za>


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

I would simply remove the link, or point it to a similar document

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

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

From report at bugs.python.org  Tue Aug 23 23:56:21 2011
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 23 Aug 2011 21:56:21 +0000
Subject: [docs] [issue12798] Update mimetypes documentation
In-Reply-To: <1313876946.82.0.0420181110647.issue12798@psf.upfronthosting.co.za>
Message-ID: <1314136581.49.0.559188560858.issue12798@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Here attached a new patch incorporating Ezio & Eric suggestions.

----------
Added file: http://bugs.python.org/file23021/mimetypes_doc_update-v2.patch

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

From report at bugs.python.org  Wed Aug 24 15:18:14 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:18:14 +0000
Subject: [docs] [issue12832] The documentation for the print function
	should	explain/point to how to control the sys.stdout encoding
Message-ID: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

A common problem encountered when using python3 is writing non-ascii to stdout.  This will work fine if stdout is a terminal and the terminal encoding handles the characters, but will fail if stdout is later redirected to a pipe.  The docs for sys.stdout and for print should contain or point to an explanation of why, and how to solve the problem (ie: how to set the encoding for sys.stdout/sys.stderr).

Note that IMO it makes more sense for sys.stdout to default to the LOCALE encoding, but that should be a separate issue.

----------
assignee: docs at python
components: Documentation
messages: 142880
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: The documentation for the print function should explain/point to how to control the sys.stdout encoding
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 24 15:21:21 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:21:21 +0000
Subject: [docs] [issue12832] The documentation for the print function
	should	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314192081.17.0.0838750904308.issue12832@psf.upfronthosting.co.za>


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

Victor says it defaults to LOCALE in 3.3.  The documentation should still be expanded to mention this even in 3.3, though.

----------

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

From report at bugs.python.org  Wed Aug 24 15:36:16 2011
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Aug 2011 13:36:16 +0000
Subject: [docs] [issue12832] The documentation for the print function
	should	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314192976.85.0.94018944527.issue12832@psf.upfronthosting.co.za>


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

Ah, this was actually fixed in 3.2, so it is only 2.7 where there is the different (and long standing) problem of output of unicode to a pipe.

So, the doc issue boils down to mentioning how the encoding for stdout/stderr is derived (LOCALE, overridden by PYTHONIOENCODING if set, as far as I can tell).

----------

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

From gene_wood at cementhorizon.com  Wed Aug 24 07:19:04 2011
From: gene_wood at cementhorizon.com (Gene Wood)
Date: Tue, 23 Aug 2011 22:19:04 -0700
Subject: [docs] Bug in RE module documentation
Message-ID: <CAOtiKJXgF3QVQccc6_=DHVRbtAPij_ff3MMW-3TmMJ=kn+WYug@mail.gmail.com>

http://docs.python.org/library/re.html#re.compile

The doc says : "Compile a regular expression pattern into a regular
expression object, which can be used for matching using its match() and
search() methods, described below."

However if you do a dir of the resulting object under python 2.6 the object
actually supports all of the methods listed in the doc.

I went around trying to figure out how I was going to upgrade to python 2.7
in order to do a multiline "subn" regex and then found a
stackoverflow.comanswer that indicated you could call "subn" from this
object. I then did a
dir on the object and found it supported all the methods.

I suggest you change the doc to either say :

"Compile a regular expression pattern into a regular expression object,
which can be used for matching using its match(), search(), split(),
findall(), finditer(), sub() and subn() methods, described below."

or

"Compile a regular expression pattern into a regular expression object,
which can be used for matching using any of the methods described below."

-Gene Wood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110823/7433178d/attachment-0001.html>

From liranorevi at gmail.com  Wed Aug 24 13:37:13 2011
From: liranorevi at gmail.com (Liran Orevi)
Date: Wed, 24 Aug 2011 14:37:13 +0300
Subject: [docs] Programming FAQ, range[3] to range(3)
In-Reply-To: <CAM1Q1v35F8nyXwJRyNRDMvs9frgB=6y0sTMeGBhPbbiwRi=znw@mail.gmail.com>
References: <CAM1Q1v35F8nyXwJRyNRDMvs9frgB=6y0sTMeGBhPbbiwRi=znw@mail.gmail.com>
Message-ID: <CAM1Q1v2CGQA5F_cURQAzB_Xan0rc_KPUt_KnYhCZSh+J3oa9oA@mail.gmail.com>

Forget the ':' on the 'fix' below.

On Wed, Aug 24, 2011 at 2:35 PM, Liran Orevi <liranorevi at gmail.com> wrote:

> Hello,
>
> On
> http://docs.python.org/faq/programming.html
>
> for i in range[3]:
>
> Should be:
>
> for i in range(3):
>
> Regards,
> Liran Orevi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110824/e345c7dd/attachment-0001.html>

From liranorevi at gmail.com  Wed Aug 24 13:35:02 2011
From: liranorevi at gmail.com (Liran Orevi)
Date: Wed, 24 Aug 2011 14:35:02 +0300
Subject: [docs] Programming FAQ, range[3] to range(3)
Message-ID: <CAM1Q1v35F8nyXwJRyNRDMvs9frgB=6y0sTMeGBhPbbiwRi=znw@mail.gmail.com>

Hello,

On
http://docs.python.org/faq/programming.html

for i in range[3]:

Should be:

for i in range(3)

Regards,
Liran Orevi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110824/77b0d763/attachment-0001.html>

From report at bugs.python.org  Wed Aug 24 21:18:34 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 19:18:34 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313683595.52.0.268324784337.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM25opowouQ1e-X8p2epg4vXiRZQpwA6jHzU-7HS-V4uzw@mail.gmail.com>


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

So, what was the conclusion of the discussion brought up on python-dev?
I had a feeling some core devs were opposed to this (I'm personally -0).

----------

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

From report at bugs.python.org  Wed Aug 24 22:12:40 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:12:40 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314216760.49.0.0296941385575.issue12760@psf.upfronthosting.co.za>


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

I haven't seen any discussion on python-dev. Have I missed something?

----------

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

From report at bugs.python.org  Wed Aug 24 22:17:22 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Wed, 24 Aug 2011 20:17:22 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1314216760.49.0.0296941385575.issue12760@psf.upfronthosting.co.za>
Message-ID: <CAH_1eM2tfERAErgJLb5dBW0X3ritgQyaZRTYy=RQPsTyTn7tjw@mail.gmail.com>


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

> I haven't seen any discussion on python-dev. Have I missed something?

It was on Python-ideas actually:
http://mail.python.org/pipermail/python-ideas/2011-August/011183.html

----------

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

From report at bugs.python.org  Wed Aug 24 22:35:55 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 20:35:55 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314218155.01.0.812761232737.issue12760@psf.upfronthosting.co.za>


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

Ah, right. Well I think all arguments against it were quite weak (or even wrong). Let's see:

- it's not cross-platform: actually it is (OS_EXCL has been POSIX since at least 1997 (*), and Windows also has it)

- os.open followed by os.fdopen is easy: it isn't that easy to get the incantation right (the pure Python open() in _pyio is 70 lines of code), especially if you want the file object to have the right "name" attribute

- it doesn't fill a use case: actually, avoiding race conditions is an important use case, even though many people may never encounter it (I must admit I myself never really cared about this)

So this looks like a reasonable feature request IMHO.

(*) http://pubs.opengroup.org/onlinepubs/007908799/xsh/open.html

----------

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

From report at bugs.python.org  Wed Aug 24 23:19:03 2011
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 24 Aug 2011 21:19:03 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314220742.96.0.20537441288.issue12760@psf.upfronthosting.co.za>


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

> - os.open followed by os.fdopen is easy: it isn't that easy to get
> the incantation right (the pure Python open() in _pyio is 70 lines
> of code), especially if you want the file object to have the right
> "name" attribute

What if we can override the inner call to os.open()?
For example, io.open() could grow an additional argument "fd_opener" which defaults to the equivalent of os.open.

Then creation mode can be expressed like this:
    open(filename, 'w',
         fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT)
Another use case with openat (see #12797):
    open(filename,
         fd_opener=lambda path, mode: os.openat(fd, path, mode)

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

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

From report at bugs.python.org  Wed Aug 24 23:27:01 2011
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Aug 2011 21:27:01 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314221221.11.0.154973863685.issue12760@psf.upfronthosting.co.za>


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

> What if we can override the inner call to os.open()?
> For example, io.open() could grow an additional argument "fd_opener"
> which defaults to the equivalent of os.open.

I agree it would be a much better situation than what we have now.

----------

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

From report at bugs.python.org  Wed Aug 24 23:34:40 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Aug 2011 21:34:40 +0000
Subject: [docs] [issue12760] Add create mode to open()
In-Reply-To: <1313502559.06.0.415498401391.issue12760@psf.upfronthosting.co.za>
Message-ID: <1314221680.79.0.0220620448642.issue12760@psf.upfronthosting.co.za>


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

>    open(filename, 'w',
>         fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT)

I prefer open(name, "c").

> it doesn't fill a use case: actually, avoiding race conditions
> is an important use case, ...

It may help the issue #8604 (and maybe #8828).

----------

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

From sandro.tosi at gmail.com  Wed Aug 24 23:52:26 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Wed, 24 Aug 2011 23:52:26 +0200
Subject: [docs] Doc link incorrect
In-Reply-To: <4E531CBD.4030109@terranne.com>
References: <4E531CBD.4030109@terranne.com>
Message-ID: <CAPdtAj3U_VbQibP7Tbt0Xb_HMZY7RbEBrkVf149PhG7rTeqhdQ@mail.gmail.com>

Hello,
thanks for your email.

On Tue, Aug 23, 2011 at 05:21, T.Hill <mudge911 at terranne.com> wrote:
> Found a link that needs to be corrected...
> On page:
> http://docs.python.org/release/2.6/download
>
> The PLAIN TEXT (zipped) link is:
> http://docs.python.org/ftp/python/doc/2.6/python-2.6-docs-pdf-text.zip
>
> Should be changed to:
> http://docs.python.org/ftp/python/doc/2.6/python-2.6-docs-text.zip
>
> Note: Removed "-pdf" before "-text".
>
> Thanks for the documentation...
> Cal

I'm adding -www team in the loop, since I was suggested to contact
them to fix those link: Dear WWW team, the links to fix are the "Plain
Text" ones (both) removing -pdf from the path.

Thanks & Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Thu Aug 25 00:19:17 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 25 Aug 2011 00:19:17 +0200
Subject: [docs] Bug in RE module documentation
In-Reply-To: <CAOtiKJXgF3QVQccc6_=DHVRbtAPij_ff3MMW-3TmMJ=kn+WYug@mail.gmail.com>
References: <CAOtiKJXgF3QVQccc6_=DHVRbtAPij_ff3MMW-3TmMJ=kn+WYug@mail.gmail.com>
Message-ID: <CAPdtAj3ZbWEzyniF5SQYu1xJUB-2xK8JZg5ZJfiBpRNeT46K=g@mail.gmail.com>

Hello Gene,
thanks for your email.

On Wed, Aug 24, 2011 at 07:19, Gene Wood <gene_wood at cementhorizon.com> wrote:
> http://docs.python.org/library/re.html#re.compile
> The doc says : "Compile a regular expression pattern into a regular
> expression object, which can be used for matching using its match() and
> search() methods, described below."
> However if you do a dir of the resulting object under python 2.6 the object
> actually supports all of the methods listed in the doc.
> I went around trying to figure out how I was going to upgrade to python 2.7
> in order to do a multiline "subn" regex and then found a stackoverflow.com
> answer that indicated you could call "subn" from this object. I then did a
> dir on the object and found it supported all the methods.

Just let me clarify one thing first: the link you mentioned at the
beginning of the email is referring to python 2.7, so trying to match
that documentation against 2.6 can results in some incongruences and
ambiguities. If you're working on 2.6 (even thought we suggest to
upgrade to the latest supported version, 2.7 in this case) you may
want to refer to the 2.6-specific documentation:
http://docs.python.org/release/2.6/

> I suggest you change the doc to either say :
> "Compile a regular expression pattern into a regular expression object,
> which can be used for matching using its match(), search(), split(),
> findall(), finditer(), sub() and subn() methods, described below."
> or
> "Compile a regular expression pattern into a regular expression object,
> which can be used for matching using any of the methods described below."

With that said above, I don't think the documentation should list all
the available methods form the resulting object. What I think the doc
is trying to do is to give a clue, mentioning the most commonly used
methods.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Thu Aug 25 04:50:38 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 25 Aug 2011 02:50:38 +0000
Subject: [docs] [issue12838] FAQ/Programming typo: range[3] is used
Message-ID: <1314240637.99.0.384249238245.issue12838@psf.upfronthosting.co.za>


New submission from Eli Bendersky <eliben at gmail.com>:

User report from docs at python:


On
http://docs.python.org/faq/programming.html

for i in range[3]:

Should be:

for i in range(3):

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 142952
nosy: docs at python, eli.bendersky
priority: normal
severity: normal
stage: needs patch
status: open
title: FAQ/Programming typo: range[3] is used
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From eliben at gmail.com  Thu Aug 25 04:51:14 2011
From: eliben at gmail.com (Eli Bendersky)
Date: Thu, 25 Aug 2011 05:51:14 +0300
Subject: [docs] Programming FAQ, range[3] to range(3)
In-Reply-To: <CAM1Q1v2CGQA5F_cURQAzB_Xan0rc_KPUt_KnYhCZSh+J3oa9oA@mail.gmail.com>
References: <CAM1Q1v35F8nyXwJRyNRDMvs9frgB=6y0sTMeGBhPbbiwRi=znw@mail.gmail.com>
	<CAM1Q1v2CGQA5F_cURQAzB_Xan0rc_KPUt_KnYhCZSh+J3oa9oA@mail.gmail.com>
Message-ID: <CAF-Rda-03mEYF0QNQoKox4BJppA6iQfM8QKUGtf1yKRjYOOt1A@mail.gmail.com>

Thanks for the report, Liran.

I've opened http://bugs.python.org/issue12838 to track this. Would you like
to submit a patch?

Eli

On Wed, Aug 24, 2011 at 14:37, Liran Orevi <liranorevi at gmail.com> wrote:

> Forget the ':' on the 'fix' below.
>
>
> On Wed, Aug 24, 2011 at 2:35 PM, Liran Orevi <liranorevi at gmail.com> wrote:
>
>> Hello,
>>
>> On
>> http://docs.python.org/faq/programming.html
>>
>> for i in range[3]:
>>
>> Should be:
>>
>> for i in range(3):
>>
>> Regards,
>> Liran Orevi
>>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110825/c468dae0/attachment.html>

From report at bugs.python.org  Thu Aug 25 05:13:23 2011
From: report at bugs.python.org (Zachary Richey)
Date: Thu, 25 Aug 2011 03:13:23 +0000
Subject: [docs] [issue12832] The documentation for the print function
	should	explain/point to how to control the sys.stdout encoding
In-Reply-To: <1314191894.1.0.666645625262.issue12832@psf.upfronthosting.co.za>
Message-ID: <1314242003.75.0.641347985456.issue12832@psf.upfronthosting.co.za>


Zachary Richey <mach1723 at gmail.com> added the comment:

I'm not sure if this is good documentation, but it explains how the encoding is gotten for stdout and stderr.

----------
keywords: +patch
nosy: +mach1723
Added file: http://bugs.python.org/file23042/functions_print_doc.patch

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

From report at bugs.python.org  Thu Aug 25 11:53:17 2011
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Aug 2011 09:53:17 +0000
Subject: [docs] [issue12838] FAQ/Programming typo: range[3] is used
In-Reply-To: <1314240637.99.0.384249238245.issue12838@psf.upfronthosting.co.za>
Message-ID: <E1QwWcO-0002nf-BR@dinsdale.python.org>


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

New changeset 0abe03195d09 by Georg Brandl in branch '3.2':
Close #12838: fix range() call.
http://hg.python.org/cpython/rev/0abe03195d09

New changeset 16a90cdb5ee4 by Georg Brandl in branch '2.7':
Close #12838: fix range() call.
http://hg.python.org/cpython/rev/16a90cdb5ee4

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

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

From gene_wood at cementhorizon.com  Thu Aug 25 05:28:09 2011
From: gene_wood at cementhorizon.com (Gene Wood)
Date: Wed, 24 Aug 2011 20:28:09 -0700
Subject: [docs] Bug in RE module documentation
In-Reply-To: <CAPdtAj3ZbWEzyniF5SQYu1xJUB-2xK8JZg5ZJfiBpRNeT46K=g@mail.gmail.com>
References: <CAOtiKJXgF3QVQccc6_=DHVRbtAPij_ff3MMW-3TmMJ=kn+WYug@mail.gmail.com>
	<CAPdtAj3ZbWEzyniF5SQYu1xJUB-2xK8JZg5ZJfiBpRNeT46K=g@mail.gmail.com>
Message-ID: <CAOtiKJXQwFKDhtshtEUVM-+V6Hsae1iyN954YMKvOCR241cjKg@mail.gmail.com>

Sandro,
   Thanks very much for your response.

Regarding the difference between the 2.6 and 2.7 documentation, indeed
you're correct. I should have sent this link instead :

http://docs.python.org/release/2.6/library/re.html#re.compile

However the text that I'm referring to is identical in the 2.7 and 2.6 docs.

If the intent of this part of the doc is "to give a clue, mentioning the
most commonly used
methods" I would recommend changing the language from :

"Compile a regular expression pattern into a regular expression object,
which can be used for matching using its match() and search() methods,
described below."

which is very specific to something like :

"Compile a regular expression pattern into a regular expression object,
which can be used for matching using methods such as match() and search(),
described below."

which conveys that "match" and "search" are merely the most commonly used
methods and that all methods apply. The existing method implies those 2
methods specifically.

-Gene



On Wed, Aug 24, 2011 at 3:19 PM, Sandro Tosi <sandro.tosi at gmail.com> wrote:

> Hello Gene,
> thanks for your email.
>
> On Wed, Aug 24, 2011 at 07:19, Gene Wood <gene_wood at cementhorizon.com>
> wrote:
> > http://docs.python.org/library/re.html#re.compile
> > The doc says : "Compile a regular expression pattern into a regular
> > expression object, which can be used for matching using its match() and
> > search() methods, described below."
> > However if you do a dir of the resulting object under python 2.6 the
> object
> > actually supports all of the methods listed in the doc.
> > I went around trying to figure out how I was going to upgrade to python
> 2.7
> > in order to do a multiline "subn" regex and then found a
> stackoverflow.com
> > answer that indicated you could call "subn" from this object. I then did
> a
> > dir on the object and found it supported all the methods.
>
> Just let me clarify one thing first: the link you mentioned at the
> beginning of the email is referring to python 2.7, so trying to match
> that documentation against 2.6 can results in some incongruences and
> ambiguities. If you're working on 2.6 (even thought we suggest to
> upgrade to the latest supported version, 2.7 in this case) you may
> want to refer to the 2.6-specific documentation:
> http://docs.python.org/release/2.6/
>
> > I suggest you change the doc to either say :
> > "Compile a regular expression pattern into a regular expression object,
> > which can be used for matching using its match(), search(), split(),
> > findall(), finditer(), sub() and subn() methods, described below."
> > or
> > "Compile a regular expression pattern into a regular expression object,
> > which can be used for matching using any of the methods described below."
>
> With that said above, I don't think the documentation should list all
> the available methods form the resulting object. What I think the doc
> is trying to do is to give a clue, mentioning the most commonly used
> methods.
>
> Regards,
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110824/78b433c5/attachment.html>

From report at bugs.python.org  Thu Aug 25 22:31:25 2011
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Aug 2011 20:31:25 +0000
Subject: [docs] [issue12842] Docs: first parameter of tp_richcompare()
	always has the	correct type
Message-ID: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>


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

I've noticed that assumptions about the operand types in tp_richcompare()
are not always consistent. As far as I can see, the first parameter
in tp_richcompare() is guaranteed to be of the correct type.

But in some places the first parameter's type is still checked:

Objects/cellobject.c:

    if (!PyCell_Check(a) || !PyCell_Check(b)) {


The attached patch makes it clear that the first parameter has
the correct type.

----------
assignee: docs at python
components: Documentation
files: tp_richcompare.diff
keywords: patch
messages: 142991
nosy: docs at python, skrah
priority: normal
severity: normal
status: open
title: Docs: first parameter of tp_richcompare() always has the correct type
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23047/tp_richcompare.diff

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

From sandro.tosi at gmail.com  Thu Aug 25 22:47:38 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Thu, 25 Aug 2011 22:47:38 +0200
Subject: [docs] Bug in RE module documentation
In-Reply-To: <CAOtiKJXQwFKDhtshtEUVM-+V6Hsae1iyN954YMKvOCR241cjKg@mail.gmail.com>
References: <CAOtiKJXgF3QVQccc6_=DHVRbtAPij_ff3MMW-3TmMJ=kn+WYug@mail.gmail.com>
	<CAPdtAj3ZbWEzyniF5SQYu1xJUB-2xK8JZg5ZJfiBpRNeT46K=g@mail.gmail.com>
	<CAOtiKJXQwFKDhtshtEUVM-+V6Hsae1iyN954YMKvOCR241cjKg@mail.gmail.com>
Message-ID: <CAPdtAj0QScRSUr1pBwgZPhJiJvEKduyxuhj+i1ukFRofHg+kAw@mail.gmail.com>

Hi Gene,

On Thu, Aug 25, 2011 at 05:28, Gene Wood <gene_wood at cementhorizon.com> wrote:
> Sandro,
> ? ?Thanks very much for your response.
> Regarding the difference between the 2.6 and 2.7 documentation, indeed
> you're correct. I should have sent this link instead :
> http://docs.python.org/release/2.6/library/re.html#re.compile
> However the text that I'm referring to is identical in the 2.7 and 2.6 docs.

yes, I just wanted to point out that the different documentation could
be backed up by a change on the underlying code.

> If the intent of this part of the doc is "to give a clue, mentioning the
> most commonly used
> methods" I would recommend changing the language from :
> "Compile a regular expression pattern into a regular?expression object,
> which can be used for matching using its match() and?search() methods,
> described below."
>
> which is very specific to something like :
> "Compile a regular expression pattern into a regular?expression object,
> which can be used for matching using methods such as match() and?search(),
> described below."
>
> which conveys that "match" and "search" are merely the most commonly used
> methods and that all methods apply. The existing method implies those 2
> methods specifically.

Well, what I gave you was just my personal interpretation (and so it
might be wrong). It just says that for matching the returned object
has match() and search() methods - but afterall you're reading the
doc, so you can probably sort out that the object has other methods.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Fri Aug 26 16:32:43 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:32:43 +0000
Subject: [docs] [issue9302] distutils API Reference: setup() and
	Extension	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <E1QwxSU-0000Wu-9F@dinsdale.python.org>


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

New changeset 96f0ccb9716d by ?ric Araujo in branch '3.2':
Fix type information in distutils API reference (#9302).
http://hg.python.org/cpython/rev/96f0ccb9716d

New changeset a410b857efe3 by ?ric Araujo in branch 'default':
Merge from 3.2 (#9302 fix and other changes)
http://hg.python.org/cpython/rev/a410b857efe3

New changeset 59b3f845f7a3 by ?ric Araujo in branch 'default':
Synchronize packaging docs with distutils? (includes fix for #9302)
http://hg.python.org/cpython/rev/59b3f845f7a3

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

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

From report at bugs.python.org  Fri Aug 26 16:37:35 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:37:35 +0000
Subject: [docs] [issue9302] distutils API Reference: setup() and
	Extension	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <E1QwxXJ-0000xU-NO@dinsdale.python.org>


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

New changeset 78b26e7720c0 by ?ric Araujo in branch '2.7':
Fix type information in distutils API reference (#9302).
http://hg.python.org/cpython/rev/78b26e7720c0

----------

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

From report at bugs.python.org  Fri Aug 26 16:39:51 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:39:51 +0000
Subject: [docs] [issue11360] In documentation of getopt,
	advertise argparse instead of optparse
In-Reply-To: <1298982503.08.0.830578820579.issue11360@psf.upfronthosting.co.za>
Message-ID: <E1QwxZW-00014Q-0g@dinsdale.python.org>


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

New changeset 40f7a6e71930 by ?ric Araujo in branch '3.2':
Remove outdated pointer to optparse (fixes #11360).
http://hg.python.org/cpython/rev/40f7a6e71930

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

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

From report at bugs.python.org  Fri Aug 26 16:42:02 2011
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Aug 2011 14:42:02 +0000
Subject: [docs] [issue11360] In documentation of getopt,
	advertise argparse instead of optparse
In-Reply-To: <1298982503.08.0.830578820579.issue11360@psf.upfronthosting.co.za>
Message-ID: <E1Qwxbd-0001Nn-77@dinsdale.python.org>


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

New changeset 6d3c645fa52f by ?ric Araujo in branch '2.7':
Remove outdated pointer to optparse (fixes #11360).
http://hg.python.org/cpython/rev/6d3c645fa52f

----------

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

From report at bugs.python.org  Fri Aug 26 17:16:10 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:16:10 +0000
Subject: [docs] [issue12842] Docs: first parameter of tp_richcompare()
	always has the	correct type
In-Reply-To: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>
Message-ID: <1314371770.75.0.385678733539.issue12842@psf.upfronthosting.co.za>


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


----------
keywords: +needs review
stage:  -> patch review
versions:  -Python 3.1

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

From report at bugs.python.org  Fri Aug 26 17:20:46 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:20:46 +0000
Subject: [docs] [issue9302] distutils API Reference: setup() and
	Extension	parameters' description not correct.
In-Reply-To: <1279532605.75.0.42010773345.issue9302@psf.upfronthosting.co.za>
Message-ID: <1314372046.88.0.964481109162.issue9302@psf.upfronthosting.co.za>


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

Improved and committed, thanks again!

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

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

From report at bugs.python.org  Fri Aug 26 17:53:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 15:53:56 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314374036.5.0.165457405362.issue12768@psf.upfronthosting.co.za>


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

I have made a review on Rietveld.

----------

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

From report at bugs.python.org  Fri Aug 26 18:14:56 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Aug 2011 16:14:56 +0000
Subject: [docs] [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1314375296.01.0.515823228405.issue12195@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug 26 18:49:11 2011
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Aug 2011 16:49:11 +0000
Subject: [docs] [issue12195] Little documentation of annotations
In-Reply-To: <1306498933.41.0.74384373818.issue12195@psf.upfronthosting.co.za>
Message-ID: <1314377351.18.0.963573194409.issue12195@psf.upfronthosting.co.za>


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

> some simple examples showing the syntax would go a long way.

Sorry, there as just too many ways to go and we are intentionally not stating which way is preferred.  I've seen many variants  a:[Integral] for a list of integers, a:(int,str) for a 2-tuple of an int and a string, a:(str,file,None) for something that is a string or a file or None, a:'light_years' to indicate units of measure, a:range_check(10.5, 20.1) for range validation, and some variants for converters, adapters, factory functions, documentation aids, etc.

If you want to advance the state of the art, perhaps write a blog post on what you consider to be a best practice.  If a consensus emerges, we 
will follow.

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

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

From report at bugs.python.org  Fri Aug 26 19:14:51 2011
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 26 Aug 2011 17:14:51 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314378891.58.0.254588144548.issue12768@psf.upfronthosting.co.za>


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

?ric, yeah I received an email. Hopefully Graeme did too.

It's a shame a new review isn't notified in the tracker instead.

----------

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

From report at bugs.python.org  Fri Aug 26 23:22:26 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 26 Aug 2011 21:22:26 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314393746.74.0.995031164333.issue12731@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Really?  The re module cannot be salvaged and we should add regex but keep the (buggy) re?  That does not make a lot of sense to me.  I think it should just be fixed in the re module.  Or the re module should be *replaced* by the code from the regex module (but renamed to re, and with certain backwards compatibilities restored, probably).  But I really hope the re module (really: the _sre extension module) can be fixed.  We should also make a habit in our docs of citing specific versions of the Unicode standard, and specific TR numbers and versions where they apply.  (And hopefully we can supply URLs to the Unicode consortium's canonical copies of those documents.)

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

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

From report at bugs.python.org  Sat Aug 27 09:00:40 2011
From: report at bugs.python.org (Graeme Cross)
Date: Sat, 27 Aug 2011 07:00:40 +0000
Subject: [docs] [issue12768] docstrings for the threading module
In-Reply-To: <1313548989.72.0.178892692878.issue12768@psf.upfronthosting.co.za>
Message-ID: <1314428440.66.0.767927091206.issue12768@psf.upfronthosting.co.za>


Graeme Cross <gjcross at gmail.com> added the comment:

I will check that the patch works with 3.2; if not, I'll redo the patch for 3.2.
I will also incorporate the review changes from Ezio and Eric.

----------

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

From report at bugs.python.org  Sat Aug 27 16:27:35 2011
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 27 Aug 2011 14:27:35 +0000
Subject: [docs] [issue12174] Multiprocessing logging levels unclear
In-Reply-To: <1306324447.9.0.976036464224.issue12174@psf.upfronthosting.co.za>
Message-ID: <1314455255.67.0.948973815229.issue12174@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Although the reference docs don't list the numeric values of logging levels, this happened during reorganising of the docs. The table has moved to the HOWTO:

http://docs.python.org/howto/logging.html#logging-levels

That said, I don't understand the need for special logging levels in the multiprocessing package. From the section following the one linked to above:

"Defining your own levels is possible, but should not be necessary, as the existing levels have been chosen on the basis of practical experience. However, if you are convinced that you need custom levels, great care should be exercised when doing this, and it is possibly *a very bad idea to define custom levels if you are developing a library*. That?s because if multiple library authors all define their own custom levels, there is a chance that the logging output from such multiple libraries used together will be difficult for the using developer to control and/or interpret, because a given numeric value might mean different things for different libraries."

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

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

From report at bugs.python.org  Sun Aug 28 08:26:44 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 06:26:44 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314512804.63.0.490952078485.issue12731@psf.upfronthosting.co.za>


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

> Or the re module should be *replaced* by the code from the regex module
> (but renamed to re, and with certain backwards compatibilities
> restored, probably).

This is what I meant.

> But I really hope the re module (really: the _sre extension module)
> can be fixed.

Start fixing these issues from scratch doesn't make much sense IMHO.  We could "extract" the fixes from regex and merge them in re, but then again it's probably easier to just replace the whole module.

> We should also make a habit in our docs of citing specific versions
> of the Unicode standard, and specific TR numbers and versions where 
> they apply.

While this is a good thing it's not always doable.  Usually someone reports a bug related to something specified in some standard and only that part gets fixed.  Sometimes everything else is also updated to follow the whole standard, but often this happens incrementally, so we can't say, e.g., "the re module supports Unicode x.y" unless we go through the whole standard and fix/implements everything.

----------

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

From report at bugs.python.org  Sun Aug 28 08:37:45 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 06:37:45 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314513465.34.0.936618459321.issue12731@psf.upfronthosting.co.za>


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

> But I really hope the re module (really: the _sre extension module)
> can be fixed.

If you mean on 2.7/3.2, then I guess we could extract the fixes from regex, but we have to see if it's doable and someone will have to do it.

Also consider that the regex module is available for 2.7/3.2, so we could suggest the users to use it if they have problems with the re bugs (even if that means having an additional dependency).

ISTM that current plan is:
  * replace re with regex (and rename it) on 3.3 and fix all these bugs;
  * leave 2.7 and 3.2 with the old re and its bugs;
  * let people use the external regex module on 2.7/3.2 if they need to.

If this is not ok, maybe it should be discussed on python-dev.

----------

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

From report at bugs.python.org  Sun Aug 28 18:32:13 2011
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 28 Aug 2011 16:32:13 +0000
Subject: [docs] [issue8426] multiprocessing.Queue fails to get() very large
	objects
In-Reply-To: <1271443086.56.0.51527518355.issue8426@psf.upfronthosting.co.za>
Message-ID: <1314549133.66.0.89098943836.issue8426@psf.upfronthosting.co.za>


Changes by Charles-Fran?ois Natali <neologix at free.fr>:


----------
components: +Documentation -Library (Lib)
nosy: +docs at python
priority: normal -> low

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

From report at bugs.python.org  Sun Aug 28 19:22:45 2011
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Aug 2011 17:22:45 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1314512804.63.0.490952078485.issue12731@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJAmoFC8KZEMXHdCFy5oXjVGc_rnzW3+zGFXntjig1VzA@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

[me]
>> But I really hope the re module (really: the _sre extension module)
>> can be fixed.

[Ezio]
> Start fixing these issues from scratch doesn't make much sense IMHO. ?We could "extract" the fixes from regex and merge them in re, but then again it's probably easier to just replace the whole module.

I have changed my mind at least half-way. I am open to having regex
(with some changes, details TBD) replace re in 3.3. (I am not yet 100%
convinced, but I'm not rejecting it as strongly as I was when I wrote
that comment in this bug. See the ongoing python-dev discussion on
this topic.)

>> We should also make a habit in our docs of citing specific versions
>> of the Unicode standard, and specific TR numbers and versions where
>> they apply.
>
> While this is a good thing it's not always doable. ?Usually someone reports a bug related to something specified in some standard and only that part gets fixed. ?Sometimes everything else is also updated to follow the whole standard, but often this happens incrementally, so we can't say, e.g., "the re module supports Unicode x.y" unless we go through the whole standard and fix/implements everything.

Hm. I think that for Unicode it may actually be important enough to be
consistent in following the whole standard that we should attempt to
be consistent and not just chase bug reports. Now, we may consciously
decide not to implement a certain recommendation of the standard. E.g.
I'm not going to require that IronPython or Jython have string objects
that support O(1) indexing of code points, even (assuming PEP 393 gets
accepted) CPython will have them. But these decisions should be made
explicitly, and documented clearly.

Ideally, we need a "Unicode czar" -- a core developer whose job it is
to keep track of Python's compliance with various parts and versions
of the Unicode standard and who can nudge other developers towards
fixing bugs or implementing features, or update the documentation in
case things don't get added. (I like Tom's approach to Java 1.7, where
he submitted proposed doc fixes explaining the deviations from the
standard. Perhaps a bit passive-aggressive, but it was effective. :-)

----------

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

From report at bugs.python.org  Sun Aug 28 19:58:12 2011
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Aug 2011 17:58:12 +0000
Subject: [docs] [issue12731] python lib re uses obsolete sense of \w in
	full	violation of UTS#18 RL1.2a
In-Reply-To: <1313090311.62.0.0473644856742.issue12731@psf.upfronthosting.co.za>
Message-ID: <1314554292.71.0.65648585928.issue12731@psf.upfronthosting.co.za>


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

> Ideally, we need a "Unicode czar" -- a core developer whose job it is
> to keep track of Python's compliance with various parts and versions
> of the Unicode standard and who can nudge other developers towards
> fixing bugs or implementing features, or update the documentation in
> case things don't get added.

We should first do a full review of the latest Unicode standard and see what's missing.  I think there might be parts of older Unicode versions (even < Unicode 5) that are not yet implemented.  Chapter 3 is a good place where to start, but I'm not sure that's enough -- there are a few TRs that should be considered as well.
If we manage to catch up with Unicode 6, then it shouldn't be too difficult to review the changes that every new version will introduce and open an issue for each (or a single issue if the changes are limited).
FWIW I'm planning to look at the conformance of the UTF codecs and fix them (if necessary) whenever I'll have time.

----------

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

From arnie.hernandez at gmail.com  Sun Aug 28 19:10:50 2011
From: arnie.hernandez at gmail.com (Arnie Hernandez)
Date: Sun, 28 Aug 2011 13:10:50 -0400
Subject: [docs] PDF download
Message-ID: <91014ED4-B6EF-448F-8180-7EA5DE2D3FE9@gmail.com>

I am trying to download the PDF of the python 2.6.6 docs and my iPad can't download the file because it doesn't know what to do with a zip file. Can you please make the uncompressed PDF available.

Ty

Sent from an iPad
-- please excuse any typo's


From sandro.tosi at gmail.com  Sun Aug 28 23:25:26 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 28 Aug 2011 23:25:26 +0200
Subject: [docs] PDF download
In-Reply-To: <91014ED4-B6EF-448F-8180-7EA5DE2D3FE9@gmail.com>
References: <91014ED4-B6EF-448F-8180-7EA5DE2D3FE9@gmail.com>
Message-ID: <CAPdtAj35sXQHzLB7A9X_TFaLu4CHpGf+T8x9K9kKti8HQA5eeg@mail.gmail.com>

Hello Arnie,
thanks for your email.

On Sun, Aug 28, 2011 at 19:10, Arnie Hernandez
<arnie.hernandez at gmail.com> wrote:
> I am trying to download the PDF of the python 2.6.6 docs and my iPad can't download the file because it doesn't know what to do with a zip file. Can you please make the uncompressed PDF available.

The archive you can find on
http://docs.python.org/release/2.6/download.html are there because we
have several PDF files to ship, not just one (big) PDF with all the
text in it (it would be practically un-usable). So you can only find
archives because of this reason.

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Aug 29 18:18:29 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Aug 2011 16:18:29 +0000
Subject: [docs] [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1314634708.88.0.891941886022.issue12833@psf.upfronthosting.co.za>


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

> Still, this behavior is surprising and undesirable. I would suggest
> adding a note to the docs for the readline module
+1.

----------
assignee:  -> docs at python
components: +Documentation -IO, Interpreter Core
nosy: +docs at python
stage: test needed -> needs patch
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 30 00:24:37 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Mon, 29 Aug 2011 22:24:37 +0000
Subject: [docs] [issue12855] open() and codecs.open() treat form-feed
	differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314656677.79.0.459016621394.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I'll suggest a patch for the documentation when I get to my home computer in an hour or two.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
resolution: wont fix -> 
status: closed -> open

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

From report at bugs.python.org  Tue Aug 30 02:57:55 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 00:57:55 +0000
Subject: [docs] [issue12855] open() and codecs.open() treat form-feed
	differently
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314665875.6.0.724419473697.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I'm taking a look at the docs now.

I'm considering adding a table/list of characters python treats as newlines, but it seems like this might fit better as a note in http://docs.python.org/library/stdtypes.html#str.splitlines or somewhere else in stdtypes. I'll start working on it now, but please let me know what you think about this.

This is my first attempt at a patch, so I greatly appreciate your help so far.

----------

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

From report at bugs.python.org  Tue Aug 30 06:45:19 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 04:45:19 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314679519.7.0.470795314113.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I've attached a patch for python2.7 that adds a small not to library/stdtypes.html#str.splitlines explaining which sequences are treated as line breaks:

"""
Note: Python recognizes "\r", "\n", and "\r\n" as line boundaries for strings.

In addition to these, Unicode strings can have line boundaries of u"\x0b", u"\x0c", u"\x85", u"\u2028", and u"\u2029"
"""

Additional thoughts:

* Would it be better to put this note in a different place?

* It looks like \x0b and \x0c (vertical tab and form feed) were first considered line breaks in Python 2.7, probably related to this note from "What's New in 2.7": "The Unicode database provided by the unicodedata module is now used internally to determine which characters are numeric, whitespace, or represent line breaks." It might be worth putting a "changed in 2.7" note somewhere in the docs.

Please let me know of any thoughts you have and I'll be glad to make any desired changes and submit a new patch.

----------
keywords: +patch
title: open() and codecs.open() treat form-feed differently -> linebreak sequences should be better documented
Added file: http://bugs.python.org/file23069/linebreakdoc.py27.patch

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

From Kyle.Monson at pnnl.gov  Tue Aug 30 01:15:34 2011
From: Kyle.Monson at pnnl.gov (Monson, Kyle E)
Date: Mon, 29 Aug 2011 16:15:34 -0700
Subject: [docs] Wrong version availability listed in pkgutil docs.
Message-ID: <EF1A089CA1203C44902A4520E0A57CD40102F30D68BE@EMAIL05.pnl.gov>

In section 30.5. pkgutil it does not list which version of python each function and class became available.

>From what I can see looking at the code in the repo:

2.3 (http://hg.python.org/cpython/file/2.3/Lib/pkgutil.py)
extend_path

2.5 (http://hg.python.org/cpython/file/2.5/Lib/pkgutil.py)
walk_packages
iter_modules
ImpImporter
ImpLoader
get_importer
iter_importers
get_loader
find_loader

2.6 (http://hg.python.org/cpython/file/2.6/Lib/pkgutil.py)
get_data

2.7 and 2.4 did not introduce anything new.

Thanks,
Kyle

__________________________________________________
Kyle Monson
Scientist
Software Engineering & Architecture
Pacific Northwest National Laboratory
902 Battelle Boulevard
P.O. Box 999, MSIN K7-28
Richland, WA  99352 USA
Tel:  509-375-6379
kyle.monson at pnl.gov<mailto:kyle.monson at pnl.gov>
www.pnl.gov<http://www.pnl.gov>



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

From report at bugs.python.org  Tue Aug 30 10:22:54 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 08:22:54 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314692574.67.0.567076643261.issue12855@psf.upfronthosting.co.za>


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

> Would it be better to put this note in a different place?

You may just say that StreamReader.readline() uses unicode.splitlines(), and so point to unicode.splitlines() doc (use :meth:`unicode.splitlines` syntax). unicode.splitlines() is now well documented: line boundaries are not listed, even in Python 3 documentation.

Unicode line boundaries used by Python 2.7 and 3.3:

U+000A: Line feed
U+000B: Line tabulation
U+000C: Form feed
U+000D: Carriage return
U+001C: File separator
U+001D: Group separator
U+001E: Record separator
U+0085: "control"
U+2028: Line separator
U+2029: Paragraph separator

> It looks like \x0b and \x0c (vertical tab and form feed) were first
> considered line breaks in Python 2.7

Correct: U+000B and U+000C were added to Python 2.7 and 3.2.

> It might be worth putting a "changed in 2.7" note somewhere in the docs

We add the following syntax exactly for this:

   .. versionchanged:: 2.6
      Also unset environment variables when calling :meth:`os.environ.clear`
      and :meth:`os.environ.pop`.

If you downloaded Python source code, go into Doc/ directory and run "make html" to compile the doc to HTML.

http://docs.python.org/devguide/setup.html
http://docs.python.org/devguide/docquality.html

----------

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

From report at bugs.python.org  Tue Aug 30 10:23:07 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 08:23:07 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314692587.15.0.427741850033.issue12855@psf.upfronthosting.co.za>


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


----------
components: +Unicode
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Aug 30 16:46:46 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Tue, 30 Aug 2011 14:46:46 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314715606.44.0.47182649975.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I can fix the patch to list all the unicode line boundaries. The three places I've considered putting it are:

1. On the howto/unicode.html

2. Somewhere in the stdtypes.html#typesseq description (maybe with other notes at the bottom)

3. As a note to the stdtypes.html#str.splitlines method description (where it is in the previous patch.)

I can move it to any of these places if you think it's a better fit. I'll fix the list so that it's complete, add a note about \x0b and \x0c being added in 2.7/3.2, and possibly reference it from StreamReader.readline.

After confirming that my documentation matches the style guide, I'll make the docs, test the output, and upload a patch. I can do this for 2.7, 3.2 and 3.3 separately.

Let me know if that sounds good and if you have any further thoughts. I should be able to upload new patches in 10 hours (after work today).

----------

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

From report at bugs.python.org  Tue Aug 30 17:02:52 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 15:02:52 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314716572.46.0.0239774835546.issue12855@psf.upfronthosting.co.za>


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

> 1. On the howto/unicode.html
> 2. Somewhere in the stdtypes.html#typesseq description (maybe with other notes at the bottom)
> 3. As a note to the stdtypes.html#str.splitlines method description (where it is in the previous patch.)

(3) is the best place. For Python 2, you should add a new unicode.splitlines entry, whereas the str.splitlines should be updated in Python 3.

> I can do this for 2.7, 3.2 and 3.3 separately.

You don't have to do it for 3.3: 2.7 and 3.2 are enough (I will do the change in 3.3 using Mercurial).

----------

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

From report at bugs.python.org  Tue Aug 30 18:05:28 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Aug 2011 16:05:28 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1314720328.74.0.525193389857.issue1215@psf.upfronthosting.co.za>


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


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

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

From sandro.tosi at gmail.com  Tue Aug 30 19:48:22 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Tue, 30 Aug 2011 19:48:22 +0200
Subject: [docs] Wrong version availability listed in pkgutil docs.
In-Reply-To: <EF1A089CA1203C44902A4520E0A57CD40102F30D68BE@EMAIL05.pnl.gov>
References: <EF1A089CA1203C44902A4520E0A57CD40102F30D68BE@EMAIL05.pnl.gov>
Message-ID: <CAPdtAj23sZ3FnXgywfnPzsoUgVKcP4-CGkZk8LcL=yP76ME4vA@mail.gmail.com>

Hello Kyle,
thanks for your email.

On Tue, Aug 30, 2011 at 01:15, Monson, Kyle E <Kyle.Monson at pnnl.gov> wrote:
> In section 30.5. pkgutil it does not list which version of python each
> function and class became available.

Thanks for your analysis!

> From what I can see looking at the code in the repo:
>
> 2.3 (http://hg.python.org/cpython/file/2.3/Lib/pkgutil.py)
> extend_path
>
> 2.5 (http://hg.python.org/cpython/file/2.5/Lib/pkgutil.py)
> walk_packages
> iter_modules
> ImpImporter
> ImpLoader
> get_importer
> iter_importers
> get_loader
> find_loader

Currently python supported versions for 2.x series are 2.6 and 2.7,
and so we encourage to update to one of these versions (preferibly
2.7, which is still in bugfix support, while 2.6 is only in security
fix). Adding those ancient information is not worth anymore.

> 2.6 (http://hg.python.org/cpython/file/2.6/Lib/pkgutil.py)
> get_data

but this is a nice addition, so I just committed it:
http://hg.python.org/cpython/rev/4c6b1b2d481a

Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From nazrinasirrmn at yahoo.com  Tue Aug 30 22:20:49 2011
From: nazrinasirrmn at yahoo.com (nazri nasir)
Date: Tue, 30 Aug 2011 21:20:49 +0100 (BST)
Subject: [docs] Suggestion to IDE menu.
Message-ID: <1314735649.37138.YahooMailNeo@web24904.mail.ird.yahoo.com>

Dear Python Team Foundation;
?I would like to suggest that the IDE python (IDLE) should have the [check for updates] function in the IDE menu. I suggest?to put in new menu which is easy to reach. If user want to update the software it become easily and Python will be the best.
?

Thank you,
Yours Sincerely
Lt Commander (ret) Nazri, BEng(UK),MCP.
Design engineering and scientific application by using open source software (Python, Pascal (Lazarus), FBasic, Ruby, Perl, Java(NetBeans), Java(Eclipse), Highlight, Racket, AutoHotkey, Processing, SciLab, PHP, HTML, CSSand close source software Visual Basic 2008/2010, Visual C#, Visual C++, Jscript, F#, WPF, ASP.NET, ASP.NET MVC, Silverlight, Lightswitch, MATLAB, Z80 Coding (ZDS II-eZ80 IDE) in detail.
Design Program including allEngineering Application by using Windows based Application or .NET Frameworkprogramming capabilities.

Top 10 Player of Dominosa on Facebook. http://apps.facebook.com/puzzle-dominosa/ since January 2011.
http://twitter.com/nazrinasir
Phone:+4917632920298? or +4917674137138?or +4915110445855 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110830/bce94e3d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SuggestionToIDE.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 186982 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20110830/bce94e3d/attachment-0001.docx>

From report at bugs.python.org  Tue Aug 30 23:56:03 2011
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 30 Aug 2011 21:56:03 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <1190912724.9.0.418130471784.issue1215@psf.upfronthosting.co.za>
Message-ID: <1314741363.51.0.771027280396.issue1215@psf.upfronthosting.co.za>


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

> def handler(signal, stackframe):
>     print "OUCH"
>     stdout.flush()
>     _exit(1)

What do you want to do on a SIGSEGV? On a real fault, you cannot rely on  Python internal state, you cannot use any Python object. To handle a real SIGSEGV fault, you have to implement a signal handler using only *signal safe* functions.... in C.

See faulthandler_fatal_error() function:
https://github.com/haypo/faulthandler/blob/master/faulthandler.c#L257

> The documentation for this can now point to the faulthandler module
> (in Python 3).

For your information, faulthandler is available for Python older than 3.3 as a third party module:
http://pypi.python.org/pypi/faulthandler

> segfault is the following C module:

For tests, you can use ctypes.string_at(0) to read a word from NULL.

--

faulthandler installs a signal handler for SIGSEGV, SIGFPE, SIGABRT, SIGBUS and SIGILL signals:
http://docs.python.org/dev/library/faulthandler.html

----------

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

From report at bugs.python.org  Wed Aug 31 02:52:01 2011
From: report at bugs.python.org (Martin Pool)
Date: Wed, 31 Aug 2011 00:52:01 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <CAA9uavBKHBZQRYb_oQU-Jpr--BNC34gRbKVdnrOERJ5wx-HLAg@mail.gmail.com>
Message-ID: <CAA9uavBU5TCMFuzwsgLrfHSNjpGu92DENOgfhsR-nujgVV9wfA@mail.gmail.com>


Martin Pool <mbp at sourcefrog.net> added the comment:

On 31 August 2011 07:56, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> def handler(signal, stackframe):
>> ? ? print "OUCH"
>> ? ? stdout.flush()
>> ? ? _exit(1)
>
> What do you want to do on a SIGSEGV? On a real fault, you cannot rely on ?Python internal state, you cannot use any Python object. To handle a real SIGSEGV fault, you have to implement a signal handler using only *signal safe* functions.... in C.

Well, strictly speaking, it is very hard or impossible to write C code
that's guaranteed to be safe after an unexpected segv too; who knows
what might have caused it. ?The odds are probably better that it will work in
in C than in Python. ?At any rate I think it's agreed that the
original code is not supported and it's just the docs that need to
change.

So what do you think of
<http://bugs.python.org/file22989/20110822-1525-signal-doc.diff> ?

----------

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

From report at bugs.python.org  Wed Aug 31 04:35:38 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Wed, 31 Aug 2011 02:35:38 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314758138.69.0.705205578449.issue12855@psf.upfronthosting.co.za>


Matthew Boehm <boehm.matthew at gmail.com> added the comment:

I've attached a patch for 2.7 and will attach one for 3.2 in a minute.

I built the docs for both 2.7 and 3.2 and verified that there were no warnings and that the resulting web pages looked okay.

Things to consider:

* Placement of unicode.splitlines() method: I placed it next to str.splitlines. I didn't want to place it with the unicode methods further down because docs say "The following methods are present only on unicode objects"

* The docs for codecs.readlines() already mentions "Line-endings are implemented using the codec?s decoder method and are included in the list entries if keepends is true." 

* Feel free to make any wording/style suggestions.

----------
Added file: http://bugs.python.org/file23076/linebreakdoc.v2.py27.patch

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

From report at bugs.python.org  Wed Aug 31 04:35:54 2011
From: report at bugs.python.org (Matthew Boehm)
Date: Wed, 31 Aug 2011 02:35:54 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1314758154.53.0.51758924044.issue12855@psf.upfronthosting.co.za>


Changes by Matthew Boehm <boehm.matthew at gmail.com>:


Added file: http://bugs.python.org/file23077/linebreakdoc.v2.py32.patch

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

From report at bugs.python.org  Wed Aug 31 04:41:52 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Wed, 31 Aug 2011 02:41:52 +0000
Subject: [docs] [issue12409] Moving "Documenting Python" to Devguide
In-Reply-To: <1309008968.0.0.644952507743.issue12409@psf.upfronthosting.co.za>
Message-ID: <1314758512.73.0.30244137637.issue12409@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

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

From report at bugs.python.org  Wed Aug 31 05:03:58 2011
From: report at bugs.python.org (Adam Woodbeck)
Date: Wed, 31 Aug 2011 03:03:58 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1314759838.33.0.630414454754.issue11176@psf.upfronthosting.co.za>


Changes by Adam Woodbeck <adam.woodbeck at gmail.com>:


----------
nosy: +adam.woodbeck

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

From report at bugs.python.org  Wed Aug 31 14:02:31 2011
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 31 Aug 2011 12:02:31 +0000
Subject: [docs] [issue1215] documentation doesn't say that you can't handle
	C	segfaults from python
In-Reply-To: <CAA9uavBU5TCMFuzwsgLrfHSNjpGu92DENOgfhsR-nujgVV9wfA@mail.gmail.com>
Message-ID: <201108311402.11025.victor.stinner@haypocalc.com>


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

Le mercredi 31 ao?t 2011 02:52:01, vous avez ?crit :
> > What do you want to do on a SIGSEGV? On a real fault, you cannot rely on
> >  Python internal state, you cannot use any Python object. To handle a
> > real SIGSEGV fault, you have to implement a signal handler using only
> > *signal safe* functions.... in C.
> 
> Well, strictly speaking, it is very hard or impossible to write C code
> that's guaranteed to be safe after an unexpected segv too

It is possible if you only use signal safe functions. I think that no Python 
function is signal safe :-)

----------

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

From senthil at uthcode.com  Wed Aug 31 15:27:41 2011
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 31 Aug 2011 21:27:41 +0800
Subject: [docs] Suggestion to IDE menu.
In-Reply-To: <1314735649.37138.YahooMailNeo@web24904.mail.ird.yahoo.com>
References: <1314735649.37138.YahooMailNeo@web24904.mail.ird.yahoo.com>
Message-ID: <20110831132741.GB3379@mathmagic>

Hello Nazri,

On Tue, Aug 30, 2011 at 09:20:49PM +0100, nazri nasir wrote:
> Dear Python Team Foundation;
>  I would like to suggest that the IDE python (IDLE) should have the [check for
> updates] function in the IDE menu. I suggest to put in new menu which is easy
> to reach. If user want to update the software it become easily and Python will
> be the best.

IDLE is just one of the editors of Python, shipped with Python to
include a demo application as what is possible using Python and
Tkinter libraries. As it does not represent or is anyway indicative of
the Python installed on your system, providing the update button may
not be a right idea.

Also, when you open IDLE from a latest downloaded version
python, you get the updated IDLE as well.

HTH,
Senthil


From report at bugs.python.org  Wed Aug 31 16:42:11 2011
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 31 Aug 2011 14:42:11 +0000
Subject: [docs] [issue11435] Links to source code should now point to hg repo
In-Reply-To: <1299519091.7.0.295996410449.issue11435@psf.upfronthosting.co.za>
Message-ID: <1314801731.26.0.249512778345.issue11435@psf.upfronthosting.co.za>


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

After getting Georg?s greenlight on python-dev, I have adapted the source reST role for 2.7 and updated all links.

----------
status: open -> closed

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

From adam.woodbeck at gmail.com  Wed Aug 31 05:31:05 2011
From: adam.woodbeck at gmail.com (Adam Woodbeck)
Date: Tue, 30 Aug 2011 23:31:05 -0400
Subject: [docs] About
Message-ID: <CAGkRLJofJweq_kAp=z1eLa_B8XixKGg+v2B9vrXBtSaKiDubnA@mail.gmail.com>

I was reading through the Python docs tonight and ran across the About
section.  It contained a comprehensive list of people who contributed to the
Python documentation.  I'm not sure if I qualify, but I contributed patches
for issue10403, issue12369, and issue12278 - all three of which were
accepted.  So if those patches qualify, I would appreciate it if you added
my name to the About page of the Python documentation.

Sincerely,
Adam Woodbeck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20110830/d6396120/attachment.html>

From sandro.tosi at gmail.com  Wed Aug 31 22:11:27 2011
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Wed, 31 Aug 2011 22:11:27 +0200
Subject: [docs] About
In-Reply-To: <CAGkRLJofJweq_kAp=z1eLa_B8XixKGg+v2B9vrXBtSaKiDubnA@mail.gmail.com>
References: <CAGkRLJofJweq_kAp=z1eLa_B8XixKGg+v2B9vrXBtSaKiDubnA@mail.gmail.com>
Message-ID: <CAPdtAj21LMOnb9FK-0Sht_joK4ixX8Yre0O9iW7tCY9V4BVtkw@mail.gmail.com>

Hi Adam,

On Wed, Aug 31, 2011 at 05:31, Adam Woodbeck <adam.woodbeck at gmail.com> wrote:
> I was reading through the Python docs tonight and ran across the About
> section.? It contained a comprehensive list of people who contributed to the
> Python documentation.? I'm not sure if I qualify, but I contributed patches
> for issue10403, issue12369, and issue12278 - all three of which were
> accepted.? So if those patches qualify, I would appreciate it if you added
> my name to the About page of the Python documentation.

That list of names is generated from the file Doc/ACKS.txt on the
cpython repository. I know that page suggests to write a mail here,
but given that file is usually updated by the core developer that
commits your patch, I think it would be better if you ask them how
they feel about it (it might be that they just forgot ;) ).

Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From cbeau at ryerson.ca  Wed Aug 31 22:35:04 2011
From: cbeau at ryerson.ca (Catherine Beauchemin)
Date: Wed, 31 Aug 2011 16:35:04 -0400 (EDT)
Subject: [docs] random.gammavariate doc incomplete
Message-ID: <alpine.DEB.2.02.1108311625030.11509@nyororo.physics.ryerson.ca>


Dear maintainers,

The random.gammavariate online documentation at:

http://docs.python.org/library/random.html#random.gammavariate

is incomplete. At this page it currently states:

Gamma distribution. (Not the gamma function!) Conditions on the parameters 
are alpha > 0 and beta > 0.

whereas the docstring for version 2.7 of random.gammavariate states:

     Gamma distribution.  Not the gamma function!

     Conditions on the parameters are alpha > 0 and beta > 0.

     The probability distribution function is:

                 x ** (alpha - 1) * math.exp(-x / beta)
       pdf(x) =  --------------------------------------
                   math.gamma(alpha) * beta ** alpha


The definition of the pdf in the docstring is a must because otherwise it 
is not possible to understand what the parameters alpha and beta of the 
random.gammavariate function stand for (there are several definitions of 
the gamma distribution in common use). Generally, I would think it would 
be best to explicitly write down the pdf(x) for all random variate 
functions to make it clear what the distribution parameters stand for.

So the online documentation should be updated to match the docstring for 
random.gammavariate.

Thanks,
Catherine.