From report at bugs.python.org  Mon Sep  1 03:25:04 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Sep 2014 01:25:04 +0000
Subject: [docs] [issue22318] unitest documentation on assertItemsEqual
	misleading
In-Reply-To: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za>
Message-ID: <1409534703.88.0.72525192785.issue22318@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm not sure what you saw when "reading the code".  I don't see any 'a is b' in there (only 'elem is NULL', which is correct).  

This has nothing to do with unittest, and everything to do with how == is defined/implemented in python.  The invariant is that if two objects are equal, their hashes *must* be equal, and the hash check is used as a fastpath to skip items that are not equal without doing a full comparison. If you implement __eq__, you must implement __hash__ (or set it to None, thus marking the objects as not hashable).  Not doing so is an error in Python3 (and probably also in python2 if you are using new style classes, but I didn't check).

So, it is your objects that are buggy, I'm afraid, not unittest.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep  1 03:47:13 2014
From: report at bugs.python.org (Hideaki Muranami)
Date: Mon, 01 Sep 2014 01:47:13 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
Message-ID: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>


New submission from Hideaki Muranami:

Link of "Developer FAQ" on https://docs.python.org/3.4/faq/general.html#how-do-i-obtain-a-copy-of-the-python-source is invalid.

----------
assignee: docs at python
components: Documentation
messages: 226199
nosy: docs at python, mnamihdk
priority: normal
severity: normal
status: open
title: Invalid link in General Python FAQ
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  1 04:02:42 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Sep 2014 02:02:42 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>
Message-ID: <1409536962.32.0.625904829913.issue22316@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Just like for other binary operators (except for the ones mentioned as always needing spaces), the spaces around ":" are neither mandatory nor objectionable.  I am not making up a new rule, this is how I've always thought -- we just have to make it explicit that x[1: n] is wrong.

How about this:

- However, in a slice the colon acts like a binary operator, and
  should have equal amounts on either side (treating it as the
  operator with the lowest priority).  In an extended slice, both
  colons must have the same amount of spacing applied.  Exception:
  when a slice parameter is omitted, the space is omitted. ::

  Yes::

      ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
      ham[lower:upper], ham[lower:upper:], ham[lower::step]
      ham[lower+offset : upper+offset]
      ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)]
      ham[lower + offset : upper + offset]

  No::

      ham[lower + offset:upper + offset]
      ham[1: 9], ham[1 :9], ham[1:9 :3]
      ham[lower : : upper]
      ham[ : upper]

----------

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

From report at bugs.python.org  Mon Sep  1 05:10:11 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 01 Sep 2014 03:10:11 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409536962.32.0.625904829913.issue22316@psf.upfronthosting.co.za>
Message-ID: <CADiSq7cjxFMBq4aozHJ4i7yKx17PvwJOH2UST_7DdP_t-ucGtw@mail.gmail.com>


Nick Coghlan added the comment:

Looks good to me! (and covers several cases that hadn't occurred to me
before)

----------

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

From report at bugs.python.org  Mon Sep  1 05:20:30 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Sep 2014 03:20:30 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>
Message-ID: <1409541630.72.0.657776831876.issue22316@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Committed rev e98737176f1d.

If there's more discussion I can add more.

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

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

From report at bugs.python.org  Mon Sep  1 05:22:48 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 01 Sep 2014 03:22:48 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>
Message-ID: <1409541768.37.0.704948468956.issue22316@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Does anyone care that there is now one bullet in the "avoid spaces ..." list that isn't strictly about avoiding spaces?

----------

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

From report at bugs.python.org  Mon Sep  1 06:36:27 2014
From: report at bugs.python.org (Josh Lynn)
Date: Mon, 01 Sep 2014 04:36:27 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409546187.89.0.549790604341.issue22320@psf.upfronthosting.co.za>


Josh Lynn added the comment:

Hello. I'm new to contributing to Python and this looks like a decent place to start. Please bear with me. 

Just to be sure, should the link of "Developer FAQ" be https://docs.python.org/devguide/faq.html?

----------
nosy: +josh.lynn

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

From report at bugs.python.org  Mon Sep  1 06:57:01 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Sep 2014 04:57:01 +0000
Subject: [docs] [issue22318] unitest documentation on assertItemsEqual
	misleading
In-Reply-To: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za>
Message-ID: <1409547421.59.0.757717488694.issue22318@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is is an object identity test, by the way, it has nothing to do with __hash__.

----------

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

From report at bugs.python.org  Mon Sep  1 07:11:03 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Sep 2014 05:11:03 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409548263.63.0.0827939919538.issue22320@psf.upfronthosting.co.za>


Ned Deily added the comment:

Hideaki, thanks for the report.
Josh, yes

----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Sep  1 07:27:00 2014
From: report at bugs.python.org (Josh Lynn)
Date: Mon, 01 Sep 2014 05:27:00 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409549220.57.0.610347461891.issue22320@psf.upfronthosting.co.za>


Josh Lynn added the comment:

Ned, thank you! 

This patch updates the link in the General FAQ from a broken link to be "https://docs.python.org/devguide/faq.html".

----------
keywords: +patch
Added file: http://bugs.python.org/file36517/faqLinkUpdate.patch

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

From report at bugs.python.org  Mon Sep  1 07:29:28 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 01 Sep 2014 05:29:28 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409549368.2.0.476084718895.issue22320@psf.upfronthosting.co.za>


Berker Peksag added the comment:

We can use https://docs.python.org/devguide/setup.html in that paragraph. It has more information about compiling Python.

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Sep  1 07:45:45 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Sep 2014 05:45:45 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409550345.36.0.323489370949.issue22320@psf.upfronthosting.co.za>


Ned Deily added the comment:

Good point, Berker. The general FAQ predates the Developer's Guide.  Josh, your patch looked good; would you care to update it?  In any case, if you plan to contribute further patches (and we hope you do), please be sure to fill out a contributor form (https://docs.python.org/devguide/patch.html#licensing).

----------

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

From report at bugs.python.org  Mon Sep  1 07:58:55 2014
From: report at bugs.python.org (Josh Lynn)
Date: Mon, 01 Sep 2014 05:58:55 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409551135.0.0.89570720989.issue22320@psf.upfronthosting.co.za>


Josh Lynn added the comment:

That page makes more sense! I have updated the paragraph to link to the "Getting Started Guide" at https://docs.python.org/devguide/setup.html

Ned, I have signed a contributor form so it should be recorded soon. I plan on this being the first of many contributions :) 

Thank you!

----------
Added file: http://bugs.python.org/file36518/faqLinkUpdate.2.patch

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

From report at bugs.python.org  Mon Sep  1 09:08:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 01 Sep 2014 07:08:43 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <3hmjF61cTxz7Ln0@mail.python.org>


Roundup Robot added the comment:

New changeset 241f9aa9fb89 by Ned Deily in branch '2.7':
Issue #22320: Fix broken link in the General Python FAQ.
http://hg.python.org/cpython/rev/241f9aa9fb89

New changeset 3eaba8a0cb3a by Ned Deily in branch '3.4':
Issue #22320: Fix broken link in the General Python FAQ.
http://hg.python.org/cpython/rev/3eaba8a0cb3a

New changeset c81e2b6eccd8 by Ned Deily in branch 'default':
Issue #22320: merge from 3.4
http://hg.python.org/cpython/rev/c81e2b6eccd8

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

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

From report at bugs.python.org  Mon Sep  1 09:13:19 2014
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Sep 2014 07:13:19 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409555599.23.0.597224104546.issue22320@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks again for the patch!  (I did change the wording slightly.)

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

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

From report at bugs.python.org  Mon Sep  1 09:14:23 2014
From: report at bugs.python.org (Josh Lynn)
Date: Mon, 01 Sep 2014 07:14:23 +0000
Subject: [docs] [issue22320] Invalid link in General Python FAQ
In-Reply-To: <1409536033.16.0.941096686527.issue22320@psf.upfronthosting.co.za>
Message-ID: <1409555663.51.0.38169230589.issue22320@psf.upfronthosting.co.za>


Josh Lynn added the comment:

No problem! Thank you!

----------

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

From report at bugs.python.org  Mon Sep  1 09:19:46 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Sep 2014 07:19:46 +0000
Subject: [docs] [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1409555986.07.0.166380126132.issue10240@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep  1 21:57:54 2014
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Mon, 01 Sep 2014 19:57:54 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
In-Reply-To: <1409345812.89.0.82925514828.issue22301@psf.upfronthosting.co.za>
Message-ID: <87egvv9kqo.fsf@tumbolandia.net>


Michele Orr? added the comment:

"R. David Murray" <report at bugs.python.org> writes:

> Since we want to encourage people to use the context, that sounds
> reasonable for 3.x at least. 
Concerning this specific proposition, I really don't see the point in
having .starttls() not simply accepting a SSLContext as argument, as
imaplib.IMAP4.starttls is already doing, for example.

----------

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

From report at bugs.python.org  Mon Sep  1 23:55:14 2014
From: report at bugs.python.org (Mike Short)
Date: Mon, 01 Sep 2014 21:55:14 +0000
Subject: [docs] [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1409608514.83.0.750571804628.issue22154@psf.upfronthosting.co.za>


Mike Short added the comment:

Context manager comment & code snippet added to zipfile doc - patch attached.

----------
keywords: +patch
nosy: +Mike.Short
Added file: http://bugs.python.org/file36521/zipfile.patch

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

From report at bugs.python.org  Tue Sep  2 03:11:04 2014
From: report at bugs.python.org (Mike Short)
Date: Tue, 02 Sep 2014 01:11:04 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409620264.3.0.679574575505.issue19826@psf.upfronthosting.co.za>


Mike Short added the comment:

Addition to bugs.html to describe submitting bugs via email

----------
keywords: +patch
nosy: +Mike.Short
Added file: http://bugs.python.org/file36525/bugs.patch

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

From report at bugs.python.org  Tue Sep  2 03:11:53 2014
From: report at bugs.python.org (Mike Short)
Date: Tue, 02 Sep 2014 01:11:53 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409620313.0.0.942317396933.issue19826@psf.upfronthosting.co.za>


Mike Short added the comment:

Same addition to the Python Dev Guide - seemed more appropriate on the tracker page vs. the triaging page.

----------
Added file: http://bugs.python.org/file36526/tracker.patch

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

From report at bugs.python.org  Tue Sep  2 03:26:29 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Sep 2014 01:26:29 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409621189.67.0.236413917793.issue19826@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'd be just as happy to not document this.  The fact that you need an account first means that people will try to submit without an account, and get a bounce.  It also works better when people reply on the bug tracker rather than by email.  I'd not want to take the capability away, but I'd prefer to not document or encourage it.  That, however, is just my opinion.

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

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

From report at bugs.python.org  Tue Sep  2 09:13:12 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 02 Sep 2014 07:13:12 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409641992.65.0.218802592028.issue19826@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I agree with David, I've noticed several messages recently that are mostly untrimmed replies to email so essentially have no actual content.

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

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

From report at bugs.python.org  Tue Sep  2 16:03:35 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Sep 2014 14:03:35 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409666615.75.0.25477132053.issue19826@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And I agree with David and Mark. Thanks for the attempt at a patch, Mike, but in hindsight we are going to have to turn down your contribution.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Sep  2 16:22:47 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 02 Sep 2014 14:22:47 +0000
Subject: [docs] [issue19826] Document that bug reporting by email is possible
In-Reply-To: <1385668245.52.0.0107396832211.issue19826@psf.upfronthosting.co.za>
Message-ID: <1409667767.05.0.777260037346.issue19826@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> resolved

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

From report at bugs.python.org  Tue Sep  2 22:25:03 2014
From: report at bugs.python.org (Oliver Smith)
Date: Tue, 02 Sep 2014 20:25:03 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1409689502.97.0.987534998228.issue9694@psf.upfronthosting.co.za>


Oliver Smith added the comment:

The term "optional arguments" is a poorly formed adjectival suffix of "option". What it's trying to say is "these are kwargs" rather than "these arguments are not compulsory".

I ran into this issue with 3.4 and was looking to file a simple change request:

In early DOS/Linux days we called these "switches". I suggest we simply change the default wording from "optional arguments" to "switches".

----------
nosy: +Oliver.Smith
Added file: http://bugs.python.org/file36528/parrot.py

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

From report at bugs.python.org  Wed Sep  3 00:11:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 02 Sep 2014 22:11:38 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1409695898.1.0.476319057241.issue9694@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

To me, the mistake is contrasting 'positional' versus 'optional'.  The proper contrasts are 'positional' versus 'named' or 'keyword'  -- I believe these are mutually exclusive for command lines -- and 'required' versus 'optional.  The two axes (contrasts) are orthogonal. Where are optional positional parameters listed?  If, as I presume, they are listed as 'positional' and given that all keyword arguments are already listed in the so-called 'optional' section, I think we should regard 'optional' as a misspelling of 'keyword'.  That is a word already familiar to python programmers. The change should only be made in default for the same reason we do not correct minor errors in exception messages in bugfix releases.

----------

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

From report at bugs.python.org  Wed Sep  3 01:29:40 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Sep 2014 23:29:40 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1409700580.7.0.427260047855.issue9694@psf.upfronthosting.co.za>


R. David Murray added the comment:

In unix parlance, they are arguments and options (or, sometimes, flags).  And then required or not required.  So, argparse follows unix precedent here, except that it calls them "optional arguments", because everything is added via add_argument.  Which is why I suggested changing the label to just 'options'.  But I could see using 'switches' instead, that's less ambiguous, and is the term used on Windows (albeit with a different standard syntax).  However, every unix man page uses the term 'options'.

I definitely think 'keywords' is not a good idea.  That's crossing the streams (python parlance versus shell parlance).  argparse is building a bridge to the shell world, and should use its terminology for the bits of shell stuff it is implementing...most especially in the default help display.

Note that, reading the issue history, the argparse maintainer is urging a doc change only (how to fix the help if you run into this issue), not a behavior change.

----------

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

From report at bugs.python.org  Wed Sep  3 11:38:58 2014
From: report at bugs.python.org (Geoffrey Bache)
Date: Wed, 03 Sep 2014 09:38:58 +0000
Subject: [docs] [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1409737138.89.0.136246964403.issue15451@psf.upfronthosting.co.za>


Changes by Geoffrey Bache <gjb1002 at users.sourceforge.net>:


----------
nosy: +gjb1002

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

From report at bugs.python.org  Wed Sep  3 18:54:29 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 03 Sep 2014 16:54:29 +0000
Subject: [docs] [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1409763269.48.0.952518411268.issue15451@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  5 00:25:42 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Thu, 04 Sep 2014 22:25:42 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1409869542.46.0.355938912343.issue21228@psf.upfronthosting.co.za>


Evens Fortun? added the comment:

Hi,

>From my limited experience reporting documentation issues, I see that it's better to submit a patch than to only report an issue. So, I've tried to look into the source code to figure out what was going on. I have attached a patch that I'm submitting to you for review hoping I doing everything right.

What was reported as ambiguous in this issue is the description of the return value of the function urllib.request.urlopen() for http and https URLs. It was mentionned that it should be an http.client.HTTPResponse object but it implied that something may have been different about this object. 

To understand why I'm may now be able to assert what's being said in that patch, follow me in the source code. It's based on revision c499cc2c4a06. If you don't care about all the walkthrough you can skip to step 9.

   1. We want to describe the return value of the urllib.request.urlopen() for http and https URLs
   2. The urlopen() function is defined in Lib/urllib/request.py starting on line 138. Its return value is the return value function of the opener.open() method (line 153)
      * This opener object is defined in one of these locations:
         * On line 150 as the return value of the module function build_opener() (this return value is cached in the _opener module variable)
         * On line 152 as the value cached in the _opener module variable
         * On line 148 still as the return value of the module function build_opener() in the case if you want to access an HTTPS URL and you provide a cafile, capath or cadefault argument
      * So either way, the opener object come from the build_opener directly or indirectly.
   3. The build_opener() function is defined starting on line 505. Its return value (line 539) is an instance of the OpenerDirector class (line 514). The OpenerDirector class is defined starting on line 363.
      a. Before returning its return value, after some checks (lines 522-530, 535-536), build_opener() calls the OpenerDirector().add_handler() with an instance of some of the classes defined in the default_classes list (line 515-518). What matters to us is the HTTPHandler class and the HTTPSHandler class (line 520).
      b. The OpenerDirector().add_handler() method (line 375) takes the HTTPHandler class (line 1196) and:
         * Insert the HTTPHandler.http_open() method in the list stored as the value of OpenerDirector().handle_open['http'].
         * Insert the HTTPHandler.http_request() method in the list stored as the value of OpenerDirector().process_request['http'].
      c. For HTTPSHandler (line 1203) is the same thing but :
         * HTTPSHandler.https_open() for OpenerDirector().handle_open['https']
         * HTTPSHandler.https_request() for OpenerDirector().process_request['https']
   4. I remind you that we are looking for the return value of the method open() of an instance of the OpenerDirector class (see point number 2). This method is defined starting on line 437.
   5. The OpenDirector.open() method's return value is the response variable (line 463)
   6. This variable is defined on lines 461 and 455.
      a. The loop on lines 458-461 tries to find in his handlers (the OpenerDirector().process_response dictionary) a response processor (a XXX.http_response() method) which isn't defined in HTTPHandler or HTTPSHandler. (a http_response() method is defined in HTTPErrorProcessor [line 564] and in HTTPCookieProcessor [line 1231] but in each of these cases, these classes don't modify the response value)
      b. So response variable's value is the return value of OpenerDirector()._open(req, data) on line 455. 
         * The req argument is a Request instance (line 440) or something that has the same interface, I guess (line 442). The Request class is defined on line 253.
         * The data argument is included in the constructor of the Request instance (line 440 and then on line 262) or added to the object provided (line 444). Afterwards, it won't be used directly?(OpenerDirector()._open() receives it as an argument but won't use it in its body)
   7. OpenerDirector()._open() is defined on line 465. It will call OpenerDirector()._call_chain() up to three times depending on whether a result has been found (lines 468-469, 474-475). 
      * OpenerDirector()._call_chain() is defined on line 426. All it does is calling the handlers registered in the dictionnary provided (the chain argument) until one returns something else than None and returns it.
      * In our case (retrieving http and http resources):
         a. The first call (line 466) will return None since HTTPHandler or HTTPSHandler don't have a default_open() method (in fact, no handler defined in this file has a default_open() method)
         b. The second call will work since HTTPHandler.http_open() (line 1198) and HTTPSHandler.https_open() (line 1212) exists. Their return values will be enventually what we are looking for.
   8. HTTPHandler.http_open() and HTTPSHandler.https_open() returns the return value of do_open() method defined (on line 1134) in their mutual superclass AbstractHTTPHandler (line 1086). They will call it with http.client.HTTPConnection and req in the case of HTTPHandler and http.client.HTTPSConnection and req in the case of HTTPSHandler with a few other arguments.
   9. OpenerDirector().do_open() creates a http.client.HTTPSConnection object (line 1144) and calls its request() method (line 1173) and if it works, calls its getreponse() method (line 1178). This return value is the HTTPResponse object we are looking for.
   10. Finally we get our answer: 
      * On line 1186, an url attribute is added to this HTTPResponse object
      * On line 1192, the msg attribute is replaced by the reason attribute

I hope this is what was needed to close this issue. Otherwise, just tell me what is missing.

Oh and there seems that there are be many things that could be refactored. Can I do it and open issues about them??

----------
keywords: +patch
Added file: http://bugs.python.org/file36539/issue21228.patch

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

From report at bugs.python.org  Fri Sep  5 08:56:38 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Sep 2014 06:56:38 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1409900198.9.0.291598985745.issue21228@psf.upfronthosting.co.za>


Martin Panter added the comment:

With this patch, there is no longer any implication that the returned object implements the ?addinfourl? interface. Perhaps that should be added back. Or maybe add it to the HTTPResponse class documentation itself? There is a comment that says the methods are there ?for compatibility with old-style urllib responses?, although it seems to me they also make the class compatible with Python 3?s new ?urllib?:

http://hg.python.org/cpython/file/c499cc2c4a06/Lib/http/client.py#l772

It is good to document the ?msg? attribute and its inconsistency, since I have found this is required to implement your own BaseHandler.default_open(). However I?m not so sure if it is necessary to document the ?url? attribute. Why not encourage using geturl() instead, since it is already documented, at least for non-HTTP responses?

I also saw a comment against the ?msg? attribute which mentions deprecating something, but it is not clear what:
http://hg.python.org/cpython/file/c499cc2c4a06/Lib/urllib/request.py#l1187

----------

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

From report at bugs.python.org  Fri Sep  5 13:55:29 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 05 Sep 2014 11:55:29 +0000
Subject: [docs] [issue22341] Python 3 crc32 documentation clarifications
Message-ID: <1409918129.4.0.321897542374.issue22341@psf.upfronthosting.co.za>


New submission from Martin Panter:

This is regarding the Python 3 documentation for binascii.crc32(), <https://docs.python.org/dev/library/binascii.html#binascii.crc32>. It repeatedly recommends correcting the sign by doing crc32() & 0xFFFFFFFF, but it is not immediately clear why. Only after reading the Python 2 documentation does one realise that the value is always unsigned for Python 3, so you only really need the workaround if you want to support earlier Pythons.

I also suggest documenting the initial CRC input value, which is zero. Suggested wording:

binascii.crc32(data[, crc])
Compute CRC-32, the 32-bit checksum of ?data?, starting with the given ?crc?. The default initial value is zero. The algorithm is consistent with the ZIP file checksum. Since the algorithm is designed for use as a checksum algorithm, it is not suitable for use as a general hash algorithm. Use as follows:

print(binascii.crc32(b"hello world"))
# Or, in two pieces:
crc = binascii.crc32(b"hello", 0)
crc = binascii.crc32(b" world", crc)
print('crc32 = {:#010x}'.format(crc))

I would simply drop the notice box with the workaround, because I gather that the Python 3 documentation generally omits Python 2 details. (There are no ?new in version 2.4 tags? for instance.) Otherwise, clarify if ?packed binary format? is a reference to the ?struct? module, or something else.

Similar fixes are probably appropriate for zlib.crc32() and zlib.alder32().

Also, what is the relationship between binascii.crc32() and zlib.crc32()? I vaguely remember reading that ?zlib? is not always available, so I tend to use ?binascii? instead. Is there any advantage in using the ?zlib? version? The ?hashlib? documentation points to ?zlib? without mentioning ?binascii? at all.

----------
assignee: docs at python
components: Documentation
messages: 226419
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Python 3 crc32 documentation clarifications
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep  5 16:12:14 2014
From: report at bugs.python.org (Gael Robin)
Date: Fri, 05 Sep 2014 14:12:14 +0000
Subject: [docs] [issue22342] Fix typo in PEP 380 -- Syntax for Delegating to
	a	Subgenerator
Message-ID: <1409926334.06.0.657946256906.issue22342@psf.upfronthosting.co.za>


New submission from Gael Robin:

The first line of the Refactoring Principle subsection of the Rationale section contains the following typo :

"It should be possible to take an section of code"

should be

"It should be possible to take a section of code"

----------
assignee: docs at python
components: Documentation
messages: 226425
nosy: Gael.Robin, docs at python
priority: normal
severity: normal
status: open
title: Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator
type: enhancement

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

From report at bugs.python.org  Fri Sep  5 21:09:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 05 Sep 2014 19:09:04 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1409944144.06.0.724352216197.issue8840@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can this be closed or what?

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

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

From report at bugs.python.org  Fri Sep  5 22:07:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Sep 2014 20:07:49 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1409947669.17.0.252551830935.issue8840@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The docstring is unchanged from before the behavior change and to me still has problems a. to d. listed in msg106698.  The manual entry seems too longs to just copy, but I would not know know to condense it.

----------

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

From report at bugs.python.org  Fri Sep  5 22:28:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Sep 2014 20:28:57 +0000
Subject: [docs] [issue22342] Fix typo in PEP 380 -- Syntax for Delegating to
	a	Subgenerator
In-Reply-To: <1409926334.06.0.657946256906.issue22342@psf.upfronthosting.co.za>
Message-ID: <3hqVpc3MMpz7LkP@mail.python.org>


Roundup Robot added the comment:

New changeset 4b03ae00a76b by Benjamin Peterson in branch 'default':
use correct article (closes #22342)
http://hg.python.org/peps/rev/4b03ae00a76b

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

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

From report at bugs.python.org  Fri Sep  5 22:38:33 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Sep 2014 20:38:33 +0000
Subject: [docs] [issue20643] Strange dot in documentation (after
	generator.close)
In-Reply-To: <1392587871.68.0.444276628486.issue20643@psf.upfronthosting.co.za>
Message-ID: <3hqW1j04w0z7Ljt@mail.python.org>


Roundup Robot added the comment:

New changeset bc4e26755a13 by Serhiy Storchaka in branch '3.4':
Issue #20643: Removed unneeded (and wrong) class directives.
http://hg.python.org/cpython/rev/bc4e26755a13

New changeset 060e347c9a23 by Serhiy Storchaka in branch 'default':
Issue #20643: Removed unneeded (and wrong) class directives.
http://hg.python.org/cpython/rev/060e347c9a23

New changeset 6dba9db360d0 by Serhiy Storchaka in branch '2.7':
Issue #20643: Fixed references to the next() method (distinguish from the
http://hg.python.org/cpython/rev/6dba9db360d0

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

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

From report at bugs.python.org  Fri Sep  5 22:50:58 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 05 Sep 2014 20:50:58 +0000
Subject: [docs] [issue20643] Strange dot in documentation (after
	generator.close)
In-Reply-To: <1392587871.68.0.444276628486.issue20643@psf.upfronthosting.co.za>
Message-ID: <1409950258.6.0.0295544547724.issue20643@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Fri Sep  5 23:02:07 2014
From: report at bugs.python.org (py.user)
Date: Fri, 05 Sep 2014 21:02:07 +0000
Subject: [docs] [issue22344] Reorganize unittest.mock docs into linear manner
Message-ID: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>


New submission from py.user:

Now, it's very inconvenient to learn this documentation. It's not compact (could be reduced in 2 or even 3 times). It repeats itself: many examples copy-pasted unchangeably. And it cites to terms that placed under those cites, so people should start at the bottom to anderstand what it's talking about on the top.

Remember Zen "If the implementation is hard to explain, it's a bad idea."

- Move the MagicMock description to the point between Mock and PropertyMock descriptions
- Remove "copy-paste" examples
- Rename print to print() and StringIO to io
- Split the Autospecing section to several chunks

----------
assignee: docs at python
components: Documentation
messages: 226456
nosy: docs at python, py.user
priority: normal
severity: normal
status: open
title: Reorganize unittest.mock docs into linear manner
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Sep  5 23:13:19 2014
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Fri, 05 Sep 2014 21:13:19 +0000
Subject: [docs] [issue22345] https://docs.python.org/release/1.4/ returns 403
Message-ID: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za>


New submission from Zbyszek J?drzejewski-Szmek:

This is the last link on https://www.python.org/doc/versions/.

----------
assignee: docs at python
components: Documentation
messages: 226457
nosy: docs at python, zbysz
priority: normal
severity: normal
status: open
title: https://docs.python.org/release/1.4/ returns 403

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

From report at bugs.python.org  Fri Sep  5 23:21:01 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Sep 2014 21:21:01 +0000
Subject: [docs] [issue22345] https://docs.python.org/release/1.4/ returns 403
In-Reply-To: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za>
Message-ID: <1409952061.32.0.490101444595.issue22345@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> benjamin.peterson
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Sep  5 23:28:23 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Sep 2014 21:28:23 +0000
Subject: [docs] [issue22345] https://docs.python.org/release/1.4/ returns 403
In-Reply-To: <1409951599.8.0.482931497215.issue22345@psf.upfronthosting.co.za>
Message-ID: <1409952503.23.0.0423411681622.issue22345@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


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

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

From report at bugs.python.org  Fri Sep  5 23:43:50 2014
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Sep 2014 21:43:50 +0000
Subject: [docs] [issue22344] Reorganize unittest.mock docs into linear manner
In-Reply-To: <1409950927.16.0.630847623783.issue22344@psf.upfronthosting.co.za>
Message-ID: <1409953430.74.0.699071547717.issue22344@psf.upfronthosting.co.za>


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


----------
nosy: +michael.foord
versions: +Python 3.5

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

From report at bugs.python.org  Sat Sep  6 03:29:13 2014
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 06 Sep 2014 01:29:13 +0000
Subject: [docs] [issue22346] asyncio documentation does not mention
	provisional status
Message-ID: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za>


New submission from Thomas Kluyver:

>From PEP 411:

"""
A package will be marked provisional by a notice in its documentation page and its docstring. The following paragraph will be added as a note at the top of the documentation page:

    The <X> package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the package) may occur if deemed necessary by the core developers.
"""

PEP 3156 says that asyncio is in provisional status until Python 3.5, but the main asyncio page in the docs does not even mention this, let alone having the new warning:
https://docs.python.org/3/library/asyncio.html

I freely admit this is nitpicking, but if the idea of provisional status is to be taken seriously, I think asyncio, as a very high profile new package, should set a good example of it.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 226463
nosy: docs at python, gvanrossum, haypo, takluyver, yselivanov
priority: normal
severity: normal
status: open
title: asyncio documentation does not mention provisional status
versions: Python 3.4

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

From report at bugs.python.org  Sat Sep  6 04:28:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Sep 2014 02:28:51 +0000
Subject: [docs] [issue22346] asyncio documentation does not mention
	provisional status
In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za>
Message-ID: <3hqfnt0WMdz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset f8f3e83c9528 by Guido van Rossum in branch 'default':
Add PEP-411-compliant note about asyncio being provisional. Fixes issue #22346.
http://hg.python.org/cpython/rev/f8f3e83c9528

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

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

From report at bugs.python.org  Sat Sep  6 04:29:20 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Sep 2014 02:29:20 +0000
Subject: [docs] [issue22346] asyncio documentation does not mention
	provisional status
In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za>
Message-ID: <1409970560.47.0.603381818295.issue22346@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks!

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

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

From matyas at cs.wisc.edu  Thu Sep  4 18:21:37 2014
From: matyas at cs.wisc.edu (=?UTF-8?B?TcOhdHnDoXMgU2VsbWVjaQ==?=)
Date: Thu, 04 Sep 2014 11:21:37 -0500
Subject: [docs] bug: 'io' module documentation does not specify if
 readline() keeps the newline terminator
Message-ID: <54089191.7050001@cs.wisc.edu>

Hi,

I can't tell from reading the library reference whether doing
    line = file.readline()
or
    for line in file:
puts the newline terminator (if there is one) in 'line' or not.

The file object documentation in the Python 2 docs does specify this,
but that has been removed in Python 3.

Could someone take a look?

Thanks,
-Mat


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3521 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.python.org/pipermail/docs/attachments/20140904/b0879caf/attachment.bin>

From juanvazquez2 at icloud.com  Fri Sep  5 03:29:54 2014
From: juanvazquez2 at icloud.com (Juan Vazquez)
Date: Thu, 04 Sep 2014 21:29:54 -0400
Subject: [docs] elif function
Message-ID: <E1CFA54D-E07D-46F1-978B-B528C2E183D0@icloud.com>

Hi,

I am using the elif function on 3.3.5 version of Python. However, when  I input the the function in this form:

>>> ph = float(input('Enter the pH level: '))
Enter the pH level: 8.6
>>> if ph < 7.0:
	print(ph, "is acidic.")
>>> elif ph > 7.0:
	    
SyntaxError: unindent does not match any outer indentation level. 

Any ideas how to fix this?

Thanks

Juan

From georg at python.org  Sat Sep  6 09:12:56 2014
From: georg at python.org (Georg Brandl)
Date: Sat, 06 Sep 2014 09:12:56 +0200
Subject: [docs] elif function
In-Reply-To: <E1CFA54D-E07D-46F1-978B-B528C2E183D0@icloud.com>
References: <E1CFA54D-E07D-46F1-978B-B528C2E183D0@icloud.com>
Message-ID: <540AB3F8.4000209@python.org>

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

On 09/05/2014 03:29 AM, Juan Vazquez wrote:
> Hi,
> 
> I am using the elif function on 3.3.5 version of Python. However, when  I
> input the the function in this form:
> 
>>>> ph = float(input('Enter the pH level: '))
> Enter the pH level: 8.6
>>>> if ph < 7.0:
> print(ph, "is acidic.")
>>>> elif ph > 7.0:
>  SyntaxError: unindent does not match any outer indentation level.
> 
> Any ideas how to fix this?

Hi Juan,

this definitely works correctly. Are you sure you did not put a space in front
of the "elif"?

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlQKs/gACgkQN9GcIYhpnLBzJgCffSuv9EV9F2HfFlx5OMHLGywR
asAAoKM0RJg2nso3Ee0JWw3RMs4kiJ0c
=SlLV
-----END PGP SIGNATURE-----

From report at bugs.python.org  Sat Sep  6 11:47:20 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 06 Sep 2014 09:47:20 +0000
Subject: [docs] [issue22346] asyncio documentation does not mention
	provisional status
In-Reply-To: <1409966953.11.0.406607337237.issue22346@psf.upfronthosting.co.za>
Message-ID: <3hqrWq5G44z7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset fefe7822e6b8 by Nick Coghlan in branch '3.4':
Issue #22346: also include asyncio PEP 411 notice in 3.4
http://hg.python.org/cpython/rev/fefe7822e6b8

----------

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

From report at bugs.python.org  Sat Sep  6 19:17:58 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 06 Sep 2014 17:17:58 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1410023878.27.0.0816209916129.issue12067@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

- This bug should discuss doc updates, not question the rules.

- The rules have evolved over time and the docs stayed behind.

- We should definitely update the 2.7 docs as well as the 3.4 and 3.5 (in development) docs.  The 2.7 docs need to be different than the 3.x docs.

- The language reference manual should clearly state the rules so that implementers can use them as guidelines for implementation.

- There are several sets of relevant rules:

(a) How is each operator translated into a series of lookups and method calls, etc.  It's similar to other binary operators except that the reverse for __lt__ is __gt__ instead of __rlt__, and there's an extra rule that if __ne__ doesn't exist we compute __eq__ and take the opposite.

(b) The default implementation (e.g. default == falls back to 'is', < raises TypeError).

(c) The rules for built-in types, especially numbers (if there are still special cases that aren't explained by the __xx__ methods on the various numeric types).

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

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

From report at bugs.python.org  Sun Sep  7 01:18:10 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 06 Sep 2014 23:18:10 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1410045490.11.0.880626014689.issue12067@psf.upfronthosting.co.za>


Martin Panter added the comment:

The point about ?a != b? deferring to ?not a.__eq__(b)? is not documented anywhere that I am aware of. In fact the opposite is currently documented at <https://docs.python.org/release/3.4.0/reference/datamodel.html#richcmpfuncs>, so maybe this needs to be fixed, one way or another.

----------

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

From report at bugs.python.org  Sun Sep  7 06:13:26 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Sep 2014 04:13:26 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1410045490.11.0.880626014689.issue12067@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLumqMJLVFRrzBZL=fE88R6sVUxF0viXM3zUXn7ZgjWmA@mail.gmail.com>


Guido van Rossum added the comment:

That's a pretty new feature. Someone probably forgot to clean up all the
places where it was documented.

On Sat, Sep 6, 2014 at 4:18 PM, Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> The point about ?a != b? deferring to ?not a.__eq__(b)? is not documented
> anywhere that I am aware of. In fact the opposite is currently documented
> at <
> https://docs.python.org/release/3.4.0/reference/datamodel.html#richcmpfuncs>,
> so maybe this needs to be fixed, one way or another.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue12067>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sun Sep  7 14:35:32 2014
From: report at bugs.python.org (Mateusz Dobrowolny)
Date: Sun, 07 Sep 2014 12:35:32 +0000
Subject: [docs] [issue22353] re.findall() documentation lacks information
	about	finding THE LAST iteration of reoeated capturing group
	(greedy)
Message-ID: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za>


New submission from Mateusz Dobrowolny:

Python 3.4.1, Windows.
help(re.findall) shows me:
findall(pattern, string, flags=0)
    Return a list of all non-overlapping matches in the string.

    If one or more capturing groups are present in the pattern, return
    a list of groups; this will be a list of tuples if the pattern
    has more than one group.

    Empty matches are included in the result.

It seems like there is missing information regarding greedy groups, i.e. (regular_expression)*
Please take a look at my example:

-------------EXAMPLE-------------
import re

text = 'To configure your editing environment, use the Editor settings page and its child pages. There is also a ' \
       'Quick Switch Scheme command that lets you change color schemes, themes, keymaps, etc. with a couple of ' \
       'keystrokes.'
print('Text to be searched: \n' + text)
print('\nSarching method: re.findall()')

regexp_result = re.findall(r'\w+(\s+\w+)', text)
print('\nRegexp rule: r\'\w+(\s+\w+)\' \nFound: ' + str(regexp_result))
print('This works as expected: findall() returns a list of groups (\s+\w+), and the groups are from non-overlapping matches.')

regexp_result = re.findall(r'\w+(\s+\w+)*', text)
print('\nHow about making the group greedy? Here we go: \nRegexp rule: r\'\w+(\s+\w+)*\' \nFound: ' + str(regexp_result))
print('This is a little bit unexpected for me: findall() returns THE LAST MATCHING group only, parsing from-left-to-righ.')

regexp_result_list = re.findall(r'(\w+(\s+\w+)*)', text)
first_group = list(i for i, j in regexp_result_list)
print('\nThe solution is to put an extra group aroung the whole RE: \nRegexp rule: r\'(\w+(\s+\w+)*)\' \nFound: ' + str(first_group))
print('So finally I can get all strings I am looking for, just like expected from the FINDALL method, by accessing first elements in tuples.')
----------END OF EXAMPLE-------------


I found the solution when practicing on this page:
http://regex101.com/#python
Entering:
REGULAR EXPRESSION: \w+(\s+\w+)*
TEST STRING: To configure your editing environment, use the Editor settings page and its child pages. There is also a Quick Switch Scheme command that lets you change color schemes, themes, keymaps, etc. with a couple of keystrokes.

it showed me on the right side with nice color-coding:
1st Capturing group (\s+\w+)*
Quantifier: Between zero and unlimited times, as many times as possible, giving back as needed [greedy]
Note: A repeated capturing group will only capture the last iteration. Put a capturing group around the repeated group to capture all iterations or use a non-capturing group instead if you're not interested in the data




I think some information regarding repeated groups should be included as well in Python documentation.

BTW: I have one extra question.
Searching for 'findall' in this tracker I found this issue:
http://bugs.python.org/issue3384

It looks like information about ordering information is no longer in 3.4.1 documentation. Shouldn't this be there?

Kind Regards

----------
assignee: docs at python
components: Documentation
messages: 226534
nosy: Mateusz.Dobrowolny, docs at python
priority: normal
severity: normal
status: open
title: re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy)
versions: Python 3.4

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

From report at bugs.python.org  Sun Sep  7 14:49:20 2014
From: report at bugs.python.org (Mateusz Dobrowolny)
Date: Sun, 07 Sep 2014 12:49:20 +0000
Subject: [docs] [issue22353] re.findall() documentation lacks information
	about	finding THE LAST iteration of repeated capturing group
	(greedy)
In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za>
Message-ID: <1410094160.23.0.6869534965.issue22353@psf.upfronthosting.co.za>


Changes by Mateusz Dobrowolny <mateusz.dobrowolny at gmail.com>:


----------
title: re.findall() documentation lacks information about finding THE LAST iteration of reoeated capturing group (greedy) -> re.findall() documentation lacks information about finding THE LAST iteration of repeated capturing group (greedy)

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

From report at bugs.python.org  Sun Sep  7 19:20:44 2014
From: report at bugs.python.org (Akira Li)
Date: Sun, 07 Sep 2014 17:20:44 +0000
Subject: [docs] [issue22356] mention explicitly that stdlib assumes
	gmtime(0) epoch	is 1970
Message-ID: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za>


New submission from Akira Li:

See discussion on Python-ideas
https://mail.python.org/pipermail/python-ideas/2014-September/029228.html

----------
assignee: docs at python
components: Documentation
files: docs-time-epoch_is_1970.diff
keywords: patch
messages: 226539
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: mention explicitly that stdlib assumes gmtime(0) epoch is 1970
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36567/docs-time-epoch_is_1970.diff

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

From report at bugs.python.org  Sun Sep  7 22:30:31 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 07 Sep 2014 20:30:31 +0000
Subject: [docs] [issue22353] re.findall() documentation lacks information
	about	finding THE LAST iteration of repeated capturing group
	(greedy)
In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za>
Message-ID: <1410121831.18.0.460353214891.issue22353@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Do you have a specific sentence or paragraph in mind that could be added?

Be aware help() just shows what's in the docstring, which is typically abbreviated.  The full docs are on docs.python.org.  Can you find what you need there?

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

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

From report at bugs.python.org  Sun Sep  7 23:23:13 2014
From: report at bugs.python.org (Iestyn Elfick)
Date: Sun, 07 Sep 2014 21:23:13 +0000
Subject: [docs] [issue22357] inspect module documentation make no reference
	to	__qualname__ attribute
Message-ID: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>


New submission from Iestyn Elfick:

The documentation for the 'inspect' module should list the '__qualname__' attribute for 'method', 'function' and 'builtin' types in section '29.12.1 Types and members'.

----------
assignee: docs at python
components: Documentation
messages: 226545
nosy: docs at python, isedev
priority: normal
severity: normal
status: open
title: inspect module documentation make no reference to __qualname__ attribute
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon Sep  8 00:48:44 2014
From: report at bugs.python.org (Iestyn Elfick)
Date: Sun, 07 Sep 2014 22:48:44 +0000
Subject: [docs] [issue22357] inspect module documentation makes no reference
	to	__qualname__ attribute
In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>
Message-ID: <1410130124.8.0.0951827235039.issue22357@psf.upfronthosting.co.za>


Changes by Iestyn Elfick <isedev at gmail.com>:


----------
title: inspect module documentation make no reference to __qualname__ attribute -> inspect module documentation makes no reference to __qualname__ attribute

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

From report at bugs.python.org  Mon Sep  8 12:15:45 2014
From: report at bugs.python.org (Mateusz Dobrowolny)
Date: Mon, 08 Sep 2014 10:15:45 +0000
Subject: [docs] [issue22353] re.findall() documentation lacks information
	about	finding THE LAST iteration of repeated capturing group
	(greedy)
In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za>
Message-ID: <1410171345.37.0.592776261776.issue22353@psf.upfronthosting.co.za>


Mateusz Dobrowolny added the comment:

The official help
https://docs.python.org/3/library/re.html?highlight=findall#re.findall
in fact contains more information, especially the one mentioned in http://bugs.python.org/issue3384.

Regarding my issue - I am afraid it was my misunderstanding, because it looks like Regular Expressions return always LAST match and Python re.findall reutrns what it is said to be: the list of groups.
And since I repeat a captured group, I get only the last match.

More here for example here:
http://www.regular-expressions.info/captureall.html

I was learning regexp yesterday, and first I reported this without knowing everytnig about capturing groups.

If returning the last match for repeting a capturing group is defined within RegEx itself, than there is no need to mention it in Python documentation...

----------

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

From report at bugs.python.org  Mon Sep  8 15:47:33 2014
From: report at bugs.python.org (Robert)
Date: Mon, 08 Sep 2014 13:47:33 +0000
Subject: [docs] [issue21929] Rounding properly
In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za>
Message-ID: <1410184053.09.0.0656930820794.issue21929@psf.upfronthosting.co.za>


Robert added the comment:

I'm not sure if this is related or not, but on 3.4.1 I get the following: 

>>> print(round(float(3/2)))
2 (as expected)
>>> print(round(float(5/2)))
2 (expected 3, as float should round .5 up)

----------
nosy: +fenofonts

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

From report at bugs.python.org  Mon Sep  8 17:09:11 2014
From: report at bugs.python.org (Geoffrey Spear)
Date: Mon, 08 Sep 2014 15:09:11 +0000
Subject: [docs] [issue21929] Rounding properly
In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za>
Message-ID: <1410188951.57.0.836244382495.issue21929@psf.upfronthosting.co.za>


Geoffrey Spear added the comment:

Robert:

That is not related. Python 3's round() function, as documented, rounds halves to the even choice; what you describe is the expected behavior.

----------
nosy: +geoffreyspear

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

From report at bugs.python.org  Mon Sep  8 19:01:52 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 08 Sep 2014 17:01:52 +0000
Subject: [docs] [issue22353] re.findall() documentation lacks information
	about	finding THE LAST iteration of repeated capturing group
	(greedy)
In-Reply-To: <1410093332.63.0.87948506622.issue22353@psf.upfronthosting.co.za>
Message-ID: <1410195712.47.0.599537056041.issue22353@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Then let's close this issue.

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

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

From report at bugs.python.org  Mon Sep  8 21:39:44 2014
From: report at bugs.python.org (Robert Collins)
Date: Mon, 08 Sep 2014 19:39:44 +0000
Subject: [docs] [issue17401] io.FileIO closefd parameter is not documented
	nor shown	in repr
In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za>
Message-ID: <1410205184.02.0.162284443563.issue17401@psf.upfronthosting.co.za>


Robert Collins added the comment:

Its more than just a docs issue - "AFAICT it isn't possible to tell if closefd is set after the object is created."

The presence of the parameter in the signature is there, but it isn't documented *where the bulk of the FileIO parameters are* - there are docs for mode for instance. Why would we force users to follow breadcrumbs for one parameter but not other ones?

----------

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

From report at bugs.python.org  Mon Sep  8 21:56:44 2014
From: report at bugs.python.org (Robert Collins)
Date: Mon, 08 Sep 2014 19:56:44 +0000
Subject: [docs] [issue17401] io.FileIO closefd parameter is not documented
	nor shown	in repr
In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za>
Message-ID: <1410206204.36.0.108166812266.issue17401@psf.upfronthosting.co.za>


Robert Collins added the comment:

Oh - the the 'open' function docs are fine - they are just a pointer. I was specifically referring to the class docs around line 513 of Doc/library/io.rst.

Attached is a patch that changes repr to show this attribute and extends the docs to document this as part of FileIO.

----------
keywords: +patch
Added file: http://bugs.python.org/file36574/issue17401.patch

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

From report at bugs.python.org  Tue Sep  9 18:21:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Sep 2014 16:21:20 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
Message-ID: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Both terms are used in the documentation. Currently "context manager" wins (with score 225:19 in rst files). We should unify terminology across the documentation.

----------
assignee: docs at python
components: Documentation
messages: 226643
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: "context management protocol" vs "context manager protocol"
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue Sep  9 19:11:06 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Sep 2014 17:11:06 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <1410282666.43.0.578999550412.issue22369@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think "context management protocol" is the better English phrasing.  (grepping just for the full phrase I make it 38 vs 22, but I of course I may have missed some that are broken across lines).

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

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

From report at bugs.python.org  Tue Sep  9 20:25:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 09 Sep 2014 18:25:14 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <1410287112.86.0.131014684333.issue22369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You are right, I missed that the "context manager" is separate term.

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file36585/doc_context_management_protocol.patch

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

From report at bugs.python.org  Tue Sep  9 21:24:12 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Sep 2014 19:24:12 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <1410290652.68.0.630165275664.issue22369@psf.upfronthosting.co.za>


R. David Murray added the comment:

Patch looks fine to me.  I don't know that the HISTORY/NEWS changes are really needed, but I suppose they don't hurt.

----------

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

From report at bugs.python.org  Tue Sep  9 22:58:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Sep 2014 20:58:12 +0000
Subject: [docs] [issue22374] Replace contextmanager example and improve
	explanation
Message-ID: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager
The current html contextmanager example is 'not recommended' for actual use, because there are better ways to accomplish the same goal.  To me, is also unsatifactory in that the context management is only metaphorical (conceptual) and not actual.

I propose the following as a replacement. It actually manages context and is, I believe, both useful and currently* the best way to accomplish the goal of temporarily monkeypatching a module,  It was directly inspired by #20752, see msg226657, though there have been other issues where monkeypatching as a solution has been discussed.

---
from contextlib import contextmanager
import itertools as its

@contextmanager
def mp(ob, attr, new):
    old = getattr(ob, attr)
    setattr(ob, attr, new)
    yield
    setattr(ob, attr, old)

def f(): pass

print(its.count, its.cycle)
with mp(its, 'count', f), mp(its, 'cycle', f):
    print(its.count, its.cycle)
print(its.count, its.cycle)

# <class 'itertools.count'>
# <function f at 0x00000000035A91E0>
# <class 'itertools.count'>
---

I am aware that the above does not follow the current style, which I dislike, of confusingly mixing together batch file code and interactive input code.  I think the above is how the example should be written.  It would work even better if Sphinx gave comment lines a different background color. (A '##' prefix could be used to differentiate code comments from commented-out output lines.)

In the same section, I find the following paragraph a bit confusing (perhaps is tries to say too much):

"contextmanager() uses ContextDecorator so the context managers it creates can be used as decorators as well as in with statements. When used as a decorator, a new generator instance is implicitly created on each function call (this allows the otherwise ?one-shot? context managers created by contextmanager() to meet the requirement that context managers support multiple invocations in order to be used as decorators)."

I am guessing that this means, among other things, that ContextDecorator is necessary and sufficient to use mp twice in one with statement.  I intentionally added the double use to the example to make this possibility clear.

* The only better way I know of would be if mp (spelled out as 'monkeypatch' were considered useful enough to be added to contextlib.

----------
assignee: docs at python
components: Documentation
messages: 226661
nosy: docs at python, ncoghlan, terry.reedy
priority: normal
severity: normal
status: open
title: Replace contextmanager example and improve explanation
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 10 07:07:24 2014
From: report at bugs.python.org (Elizabeth Myers)
Date: Wed, 10 Sep 2014 05:07:24 +0000
Subject: [docs] [issue22380] Y2K compliance section in FAQ is 14 years too
	old
Message-ID: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

As seen at https://docs.python.org/3/faq/general.html#is-python-y2k-year-2000-compliant; this is 2014 - Y2K compliance hasn't been a relevant topic for, well, 14 years, and I doubt this is a "frequently asked question" nowadays. The "As of August 2003" portion is even out of date (11 years old!).

IMHO this ought to be taken out of the docs, unless this is still something people are asking about.

----------
assignee: docs at python
components: Documentation
messages: 226678
nosy: Elizacat, docs at python
priority: normal
severity: normal
status: open
title: Y2K compliance section in FAQ is 14 years too old
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 10 09:21:53 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Sep 2014 07:21:53 +0000
Subject: [docs] [issue22374] Replace contextmanager example and improve
	explanation
In-Reply-To: <1410296292.35.0.34327651623.issue22374@psf.upfronthosting.co.za>
Message-ID: <1410333713.51.0.736097908905.issue22374@psf.upfronthosting.co.za>


Martin Panter added the comment:

You should probably use try / finally in your context manager to always restore the attribute. Having said that, I recently wrote a similar context manager, and then later discovered there is already ?unittest.mock.patch? and/or ?unittest.mock.patch.object? via Issue 11664, which apparently can do this job.

----------
nosy: +vadmium

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

From report at bugs.python.org  Wed Sep 10 21:43:42 2014
From: report at bugs.python.org (Rose Ames)
Date: Wed, 10 Sep 2014 19:43:42 +0000
Subject: [docs] [issue21739] Add hint about expression in list
	comprehensions	(https://docs.python.org/2/tutorial/datastructures.html#list-comprehensions)
In-Reply-To: <1402600679.26.0.179499997563.issue21739@psf.upfronthosting.co.za>
Message-ID: <1410378222.14.0.0512328259251.issue21739@psf.upfronthosting.co.za>


Rose Ames added the comment:

Fwiw, I've seen a beginner be confused by this.  Patch attached.

----------
keywords: +patch
nosy: +superluser
Added file: http://bugs.python.org/file36593/reword.patch

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

From report at bugs.python.org  Wed Sep 10 21:51:11 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Wed, 10 Sep 2014 19:51:11 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410378671.63.0.911761188338.issue21228@psf.upfronthosting.co.za>


Evens Fortun? added the comment:

Well, there wasn't any indication before that the returned object was implementing the "addinfourl" interface. So I don't think we have lost anything. In what situation this interface is useful?? The following comment (that you had highlighted in your comment) gives the impression that theses methods are there only to provide compatibility with clients using old-styles responses. 

http://hg.python.org/cpython/file/c499cc2c4a06/Lib/http/client.py#l772

That would imply that newer clients would usually not use these methods. If you want to document this, I think the "addinfourl" interface should then be better described somewhere else where it would include the fact that the HTTPResponse class implements it.

Anyway, I don't see the advantage of using a getter method (like geturl()) instead of accessing directly the attribute. For me, this is less pythonic. If you ever have to attach a behaviour to the access of this attribute, a property could then be defined.

----------

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

From report at bugs.python.org  Wed Sep 10 22:22:13 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Sep 2014 20:22:13 +0000
Subject: [docs] [issue22380] Y2K compliance section in FAQ is 14 years too
	old
In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za>
Message-ID: <1410380533.41.0.660207663772.issue22380@psf.upfronthosting.co.za>


Georg Brandl added the comment:

+1

----------
nosy: +georg.brandl
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Sep 10 22:24:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Sep 2014 20:24:05 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <1410380645.13.0.183410946036.issue22369@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Wed Sep 10 22:46:21 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Sep 2014 20:46:21 +0000
Subject: [docs] [issue22380] Y2K compliance section in FAQ is 14 years too
	old
In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za>
Message-ID: <1410381981.13.0.082261903421.issue22380@psf.upfronthosting.co.za>


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


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

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

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


R. David Murray added the comment:

Thanks!

While this patch does sort-of go into a detail, it seems to me like it does it in a tutorial-appropriate fashion.  I'm +1 on applying this.

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

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

From report at bugs.python.org  Wed Sep 10 22:59:48 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Sep 2014 20:59:48 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <3htbFw0ng7z7Ll2@mail.python.org>


Roundup Robot added the comment:

New changeset cc5b183a2ad4 by Serhiy Storchaka in branch '3.4':
Issue #22369: Change "context manager protocol" to "context management protocol".
http://hg.python.org/cpython/rev/cc5b183a2ad4

New changeset ad568d52af4b by Serhiy Storchaka in branch 'default':
Issue #22369: Change "context manager protocol" to "context management protocol".
http://hg.python.org/cpython/rev/ad568d52af4b

New changeset e62082a70b6b by Serhiy Storchaka in branch '2.7':
Issue #22369: Change "context manager protocol" to "context management protocol".
http://hg.python.org/cpython/rev/e62082a70b6b

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

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

From report at bugs.python.org  Wed Sep 10 23:01:31 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Sep 2014 21:01:31 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410382890.96.0.529540838496.issue21228@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed, geturl is deprecated.  I'm not sure where you see it documented, I don't see it.

----------

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

From report at bugs.python.org  Wed Sep 10 23:13:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Sep 2014 21:13:50 +0000
Subject: [docs] [issue22380] Y2K compliance section in FAQ is 14 years too
	old
In-Reply-To: <1410325644.2.0.420860619285.issue22380@psf.upfronthosting.co.za>
Message-ID: <3htbZ54SVlz7Lk5@mail.python.org>


Roundup Robot added the comment:

New changeset 071a2620917f by Benjamin Peterson in branch '3.4':
y2k compliance, lol (closes #22380)
http://hg.python.org/cpython/rev/071a2620917f

New changeset 02c94b9451f8 by Benjamin Peterson in branch '2.7':
y2k compliance, lol (closes #22380)
http://hg.python.org/cpython/rev/02c94b9451f8

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

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

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

From report at bugs.python.org  Wed Sep 10 23:25:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 10 Sep 2014 21:25:06 +0000
Subject: [docs] [issue22369] "context management protocol" vs "context
	manager	protocol"
In-Reply-To: <1410279680.04.0.486393108686.issue22369@psf.upfronthosting.co.za>
Message-ID: <1410384306.53.0.494242395614.issue22369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you David.

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

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

From report at bugs.python.org  Thu Sep 11 00:03:37 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Wed, 10 Sep 2014 22:03:37 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410386617.64.0.91037598042.issue21228@psf.upfronthosting.co.za>


Evens Fortun? added the comment:

To be honest, it may be inspired by what's written a few lines lower, for ftp, files dans data urls even though the return object is not the same as the http(s) urls

http://hg.python.org/cpython/file/c499cc2c4a06/Doc/library/urllib.request.rst#l75

----------

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

From report at bugs.python.org  Thu Sep 11 00:15:01 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Sep 2014 22:15:01 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410387301.0.0.77962574681.issue21228@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I was looking at the http docs.  I wonder if we just missed the urllib docs when we made the changes.  Either that, or I'm misremembering things.

----------

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

From report at bugs.python.org  Thu Sep 11 02:01:21 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Sep 2014 00:01:21 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410393680.91.0.627619860838.issue21228@psf.upfronthosting.co.za>


Martin Panter added the comment:

By removing the ?addinfourl? methods for HTTP responses, you are making it unnecessarily hard to handle header fields and metadata from the response. I do not know of any other documented way of getting the eventual redirect target, other than geturl(). And code to parse the Content-Type, which I understand is also returned for file: URLs, would start to get ugly (untested):

info = getattr(response, "info", None)
if info:
    type = info().get_content_type()  # Easy!
else:
    import cgi
    type = cgi.parse_header(response.getheader("Content-Type))[0]

Since a HTTP status code only seems to be returned for HTTP responses, deprecating or removing getcode() in favour of ?HTTPResponse.status? might be okay, but I think info() and geturl() should stay.

Maybe a ?url? attribute is more Pythonic, but as far as I am aware that has never been documented for Python 2 or 3 for any URL type. I would not expect much existing code to be using it, and deprecating geturl() seems like a needless annoyance.

----------

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

From report at bugs.python.org  Thu Sep 11 06:24:12 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Sep 2014 04:24:12 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410409452.9.0.221344279314.issue21228@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think I'm thinking of the Request API, and not the Response API.  So ignore my comments about deprecation, I'm not sure what the status is.

----------

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

From report at bugs.python.org  Thu Sep 11 07:20:47 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Thu, 11 Sep 2014 05:20:47 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410412847.09.0.415441717436.issue21228@psf.upfronthosting.co.za>


Evens Fortun? added the comment:

Look, the subject of this issue is to clarify the methods of the urllib.request.urlopen()'s return value for http(s) URLs. Nobody seemed to work on this for 4 months. That's why I tried to submit a patch after looking into the code to try to do my part to help.

If you think that my patch is not clear enough and would need to be more precise or maybe even that it is plain wrong, please submit a new patch with your ideas so that we can close eventually this issue.

I really didn't think that it would get this complicated?

----------

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

From report at bugs.python.org  Thu Sep 11 10:32:00 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Sep 2014 08:32:00 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410424320.33.0.320401704547.issue21228@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fair enough, challenge accepted! Here is my attempt. I have explicitly made the info(), geturl() and getcode() methods available for all cases, and used Evens?s wording for the modified ?msg? attribute, but dropped mentioning the ?url? attribute.

----------
Added file: http://bugs.python.org/file36597/addinfourl-first.patch

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

From report at bugs.python.org  Thu Sep 11 14:31:17 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Sep 2014 12:31:17 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
Message-ID: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Here is a patch which converts "Contributed by" notes in whatsnews to most prevalent style. This means:

* Previous sentence ends by a period and the "Contributed" is titled.
* The note ends by a period and it is placed before closing parent.
* The note is separated from previous sentence by two spaces or newline (as any sentences).

Overwhelming majority of "Contributed by" notes are written in this style (except of unfinished 3.5 whatsnews).

----------
assignee: docs at python
components: Documentation
files: doc_contributed_by_style.patch
keywords: patch
messages: 226767
nosy: docs at python, r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Unify style of "Contributed by" notes
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36598/doc_contributed_by_style.patch

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

From report at bugs.python.org  Thu Sep 11 14:45:24 2014
From: report at bugs.python.org (=?utf-8?q?Evens_Fortun=C3=A9?=)
Date: Thu, 11 Sep 2014 12:45:24 +0000
Subject: [docs] [issue21228] Missing enumeration of HTTPResponse Objects
	methods of	urllib.request.urlopen's http.client.HTTPResponse?
In-Reply-To: <1397520483.48.0.224250148615.issue21228@psf.upfronthosting.co.za>
Message-ID: <1410439524.54.0.688753929296.issue21228@psf.upfronthosting.co.za>


Evens Fortun? added the comment:

I'm satisfied with this new patch.

----------

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

From report at bugs.python.org  Thu Sep 11 20:52:33 2014
From: report at bugs.python.org (David Gilman)
Date: Thu, 11 Sep 2014 18:52:33 +0000
Subject: [docs] [issue22392] Clarify documentation of __getinitargs__
Message-ID: <1410461552.96.0.589396040073.issue22392@psf.upfronthosting.co.za>


New submission from David Gilman:

Implementations of __getinitargs__ return a tuple of the positional arguments for __init__.   This wasn't initially apparent to me after reading the docs: I thought you were passing a tuple (args, kwargs) that would get called f(*args, **kwargs) and had to go to the pickle implementation to find out what you were supposed to do.

The proposed documentation enhancement: mention that you're just supposed to return a tuple of positional args and that it doesn't support kwargs.

----------
assignee: docs at python
components: Documentation
messages: 226795
nosy: David.Gilman, docs at python
priority: normal
severity: normal
status: open
title: Clarify documentation of __getinitargs__
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 12 06:30:46 2014
From: report at bugs.python.org (Donald Stufft)
Date: Fri, 12 Sep 2014 04:30:46 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1410496245.87.0.82577225578.issue22224@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Just to close the gap on this, most of the PSF web properties that go through Fastly have been switched over to a set of IP addresses that are dedicated to the PSF. So if someone does an IP ban they are blocking us.

I just made the switch in DNS so it'll take hold as that propagates.

----------

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

From report at bugs.python.org  Fri Sep 12 16:37:26 2014
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 12 Sep 2014 14:37:26 +0000
Subject: [docs] [issue22394] Update documentation building to use venv and
	pip
Message-ID: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>


New submission from Brett Cannon:

Now that we have ensurepip, is there any reason to not have the Doc/ Makefile create a venv for building the docs instead of requiring people to install sphinx into either their global Python interpreter or some venv outside of their checkout? Basically it would be like going back to the old Makefile of checking out the code but instead do a better isolation job and let pip manage fetching everything, updating the projects, etc.

----------
assignee: docs at python
components: Documentation
messages: 226821
nosy: brett.cannon, docs at python
priority: low
severity: normal
stage: needs patch
status: open
title: Update documentation building to use venv and pip
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 12 18:54:24 2014
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 12 Sep 2014 16:54:24 +0000
Subject: [docs] [issue22356] mention explicitly that stdlib assumes
	gmtime(0) epoch	is 1970
In-Reply-To: <1410110444.5.0.966357232963.issue22356@psf.upfronthosting.co.za>
Message-ID: <1410540864.27.0.170017791276.issue22356@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Fri Sep 12 22:27:49 2014
From: report at bugs.python.org (Philippe Dessauw)
Date: Fri, 12 Sep 2014 20:27:49 +0000
Subject: [docs] [issue22399] Doc: missing anchor for dict in
	library/functions.html
Message-ID: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za>


New submission from Philippe Dessauw:

There is a missing anchor for the dict functions in the documentation at library/functions.html. It is present in the documentation of all python version.

It seems to impact cross-referencing in Sphinx (using intersphinx).

----------
assignee: docs at python
components: Documentation
messages: 226845
nosy: docs at python, pdessauw
priority: normal
severity: normal
status: open
title: Doc: missing anchor for dict in library/functions.html
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Sat Sep 13 01:04:54 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Sep 2014 23:04:54 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree with making a complete and separate sentence.  There are 3 variations.
--
Add parenthetical note after last sentence.  (Contributed by me.)
--
Add note on next line after short line.
(Contributed by me.
--
Add note after a blank line.

(Contributed by me.)
--

I guess version 2 will be formatted the same as version 1. In 3.4 What's New I only say one instance of the 3rd, blank line style, for the multi-paragraph Improvements to Codec Handling, which it arguable was appropriate.

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

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

From report at bugs.python.org  Sat Sep 13 01:10:33 2014
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 12 Sep 2014 23:10:33 +0000
Subject: [docs] [issue22394] Update documentation building to use venv and
	pip
In-Reply-To: <1410532646.93.0.821580086561.issue22394@psf.upfronthosting.co.za>
Message-ID: <1410563433.85.0.754418012181.issue22394@psf.upfronthosting.co.za>


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


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

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

From jjlemire at gmail.com  Sun Sep  7 15:29:52 2014
From: jjlemire at gmail.com (JJ Lemire)
Date: Sun, 7 Sep 2014 09:29:52 -0400
Subject: [docs] Website bug -- can't download HTML documentation
Message-ID: <CAO3SReiCP4BGE9ZtLtx_3sP9+WRsHfhY=snE7dvxKfau6+KSfg@mail.gmail.com>

Good morning,

I can't download HTML documentation Packed as .tar.bz2

web page: https://docs.python.org/3/download.html

nginx gives me an error.

Thanks
/JL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140907/f0c821da/attachment-0001.html>

From qwefgh90 at naver.com  Mon Sep  8 10:32:57 2014
From: qwefgh90 at naver.com (=?UTF-8?B?7LWc7LC97JuQ?=)
Date: Mon, 8 Sep 2014 17:32:57 +0900 (KST)
Subject: [docs] =?utf-8?q?hello=2C_is_it_possible_to_translating_python_do?=
 =?utf-8?q?cumention=3F?=
Message-ID: <a09296e63e7ad63ee1f3856c2e907959@cweb16.nm.nhnsystem.com>

hello I'm a student who like python and related projects.
 
I'm interested in translate docs to Korean.
 
for example, following URL
https://docs.python.org/2/extending/extending.html 
 
1)I want to translate "https://docs.python.org/2/extending/extending.html" to korean
2)And can I link original page with translated page ?
 
Thank you for reading e-mail!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140908/57004d38/attachment-0001.html>

From dam at opencsw.org  Tue Sep  9 16:34:55 2014
From: dam at opencsw.org (Dagobert Michelsen)
Date: Tue, 9 Sep 2014 16:34:55 +0200
Subject: [docs] Packages for Solaris
Message-ID: <D32B1062-AA9E-4250-9E43-3403FF535C3C@opencsw.org>

Hi,

please note that Blastwave closed its doors as package provider for Solaris as listed here:
  https://docs.python.org/2/using/unix.html

However, OpenCSW continues to provide CSW-packages for Python at
  http://www.opencsw.org
Various versions of Python are available and can be installed with
  pkgutil -i python27
  pkgutil -i python33

Best regards

  ? Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2418 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20140909/3ff25d79/attachment-0001.bin>

From nmarler at sawgrassconsulting.com  Tue Sep  9 23:30:55 2014
From: nmarler at sawgrassconsulting.com (Nathaniel Marler)
Date: Tue, 9 Sep 2014 16:30:55 -0500
Subject: [docs] Operator Precedence - Improvement
Message-ID: <CADPYNO-26M+OatML1K2f2tqRYFmYVVbtWsSRc-uzOD_Y+7+znw@mail.gmail.com>

https://docs.python.org/2/reference/expressions.html#operator-precedence

1. I find it odd/confusing that the table lists operators low to high.
Wouldn't it be clearer to order the table high to low? (iow, operators with
higher precedence are higher on the table)

2. The paragraph above the table describes how "Operators in the same box
group left to right (except for...", which could be ambiguous. I believe
the "left to right" description refers to an expression, and not to the
left-to-right ordering of operators in the table. As written, it could
imply that there is some importance to the left-to-right order of how
operators are listed within the same row in the table (I don't think that
is true)

Proposed fix: "Operators in the same box group left to right *in an
expression* (except..."

Nate
--
Sawgrass Consulting, Inc.
479-659-4223
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140909/f9a1c272/attachment.html>

From phillip.m.feldman at ngc.com  Wed Sep 10 00:31:09 2014
From: phillip.m.feldman at ngc.com (Feldman, Phillip M (AS))
Date: Tue, 9 Sep 2014 22:31:09 +0000
Subject: [docs] Queue.PriorityQueue
Message-ID: <BB89F916BE10B948B6CF950E0608388D21416F13@XMBC3087.northgrum.com>

I?d like to propose a rewording of the documentation for Queue.qsize() in line with Robert?s explanation below.

Phillip

From: Engineering Support (Enthought Premium Support) [mailto:epd.gold at enthought.com]
Sent: Sunday, August 24, 2014 9:59 AM
To: Feldman, Phillip M (AS)
Subject: EXT :Re: Queue.PriorityQueue

##- Please type your reply above this line -##

Your request (# 36243) has been solved.

To reopen this request, reply to this email or click this link:
http://support.enthought.com/requests/36243 (requires Enthought subscriber login)

Engineering Support (Enthought)

Aug 24 11:59

In single-threaded use, it is perfectly exact. In multi-threaded use, it is exact only while qsize() holds the lock, which it releases just before it returns. It is possible that the interpreter may switch to another thread right after the lock is released but before your code receives the value. That other thread may change the size of the queue.

Robert Kern




Phillip Feldman

Aug 24 00:48

From time to time I used Queue.PriorityQueue. It appears to work well, but I?m concerned about the following (from https://docs.python.org/2/library/queue.html):

Queue.qsize()

Return the approximate size of the queue.

I wonder why this returns the approximate size of the queue, and whether there is a way to get the exact size.

Phillip


This email is a service from Enthought. Delivered by Zendesk<http://www.zendesk.com>.
Message-Id:31KJ5MQM_53fa19d650ba6_21f03fd7632b332c79721_sprut
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140909/90bcb6a0/attachment.html>

From songofacandy at gmail.com  Sat Sep 13 15:24:54 2014
From: songofacandy at gmail.com (INADA Naoki)
Date: Sat, 13 Sep 2014 22:24:54 +0900
Subject: [docs] hello, is it possible to translating python documention?
In-Reply-To: <a09296e63e7ad63ee1f3856c2e907959@cweb16.nm.nhnsystem.com>
References: <a09296e63e7ad63ee1f3856c2e907959@cweb16.nm.nhnsystem.com>
Message-ID: <CAEfz+TxKVxQ_sjz4VWNtatYgSBmDzO1iPySttevVv6-bz_JziA@mail.gmail.com>

We do it on Japanese.

http://docs.python.jp/3/library/functions.html#delattr

When you hover hedding, link to original appears.

On Mon, Sep 8, 2014 at 5:32 PM, ??? <qwefgh90 at naver.com> wrote:

> hello I'm a student who like python and related projects.
>
>
>
> I'm interested in translate docs to Korean.
>
>
>
> for example, following URL
>
> https://docs.python.org/2/extending/extending.html
>
>
>
> 1)I want to translate "https://docs.python.org/2/extending/extending.html"
> to korean
>
> 2)And can I link original page with translated page ?
>
>
>
> Thank you for reading e-mail!
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>


-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140913/780cf1ad/attachment.html>

From report at bugs.python.org  Sat Sep 13 15:39:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Sep 2014 13:39:39 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za>
 <1410563093.99.0.0752332288692.issue22388@psf.upfronthosting.co.za>
Message-ID: <20140913133937.6880E250E0B@webabinitio.net>


R. David Murray added the comment:

Yep, that's exactly the logic I used for "trailing parenthetical
sentence" versus "trailing parenthetical paragraph": whether or not what
was being referenced was a single paragraph for a block of paragraphs.

I went through and made 3.4 consistent, so there should be no changes
there.  Likewise the editors of earlier whats new should have made those
consistent, and it is probably best not to second guess the editor
absent a glaring typo.

If you want to make 3.5 "currently consistent" by all means do so.
However, a final edit pass (or passes) will be needed at release time
whatever you do now.

----------

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

From report at bugs.python.org  Sat Sep 13 18:05:07 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 13 Sep 2014 16:05:07 +0000
Subject: [docs] [issue22388] Unify style of "Contributed by" notes
In-Reply-To: <1410438675.22.0.0998241704025.issue22388@psf.upfronthosting.co.za>
Message-ID: <1410624307.48.0.891192288521.issue22388@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If don't make these editions now, inconsistent lines will provoke inconsistency in future additions.

----------

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

From marrtinmiko at gmail.com  Sat Sep 13 14:18:01 2014
From: marrtinmiko at gmail.com (Martin Miko)
Date: Sat, 13 Sep 2014 14:18:01 +0200
Subject: [docs] ssl module documentation containing references to python
	2.7.9
Message-ID: <CADPpF_2H1DUA-jK56dgQ1AusccRgcT+tkZmsogF1HWKhfZVS+Q@mail.gmail.com>

Hello,

on several places here [1], are references like: "New in version 2.7.9." or
"Changed in version 2.7.9:". As I'm not able to find any reference to this
version, latest on download page and elsewhere is 2.7.8, is this a bug, or
just a "future" version of docs? Thanks!

[1] https://docs.python.org/2/library/ssl.html

Best regards,
Martin Miko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140913/bec8fa82/attachment.html>

From report at bugs.python.org  Sun Sep 14 07:46:39 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 14 Sep 2014 05:46:39 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
Message-ID: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>


New submission from paul j3:

When there's a conflict involving an argument that was added via 'parents', and the conflict handler is 'resolve', the action in the parent parser may be damaged, rendering that parent unsuitable for further use.

In this example, 2 parents have the same '--config' argument:
  
    parent1 = argparse.ArgumentParser(add_help=False) 
    parent1.add_argument('--config')

    parent2 = argparse.ArgumentParser(add_help=False)
    parent2.add_argument('--config')

    parser = argparse.ArgumentParser(parents=[parent1,parent2],
        conflict_handler='resolve')

The actions of the 3 parsers are (from the ._actions list):

               (id,          dest,    option_strings)
    parent1:  [(3077384012L, 'config', [])]    # empty option_strings

    parent2:  [(3076863628L, 'config', ['--config'])]

    parser:   [(3076864428L, 'help', ['-h', '--help']),
               (3076863628L, 'config', ['--config'])]  # same id

The 'config' Action from 'parent1' is first copied to 'parser' by reference (this is important).  When 'config' from 'parent2' is copied, there's a conflict.  '_handle_conflict_resolve()' attempts to remove the first Action, so it can add the second.  But in the process it ends up deleting the 'option_strings' values from the original action.

So now 'parent1' has an action in its 'optionals' argument group with an empty option_strings list.  It would display as an 'optionals' but parse as a 'positionals'.  'parent1' can no longer be safely used as a parent for another (sub)parser, nor used as a parser itself.

The same sort of thing would happen, if, as suggested in the documentation:

    "Sometimes (e.g. when using parents_) it may be useful to simply
     override any older arguments with the same option string." 

In test_argparse.py, 'resolve' is only tested once, with a simple case of two 'add_argument' statements.  The 'parents' class tests a couple of cases of conflicting actions (for positionals and optionals), but does nothing with the 'resolve' handler.

------------------------------

Possible fixes:

- change the documentation to warn against reusing such a parent parser

- test the 'resolve' conflict handler more thoroughly

- rewrite this conflict handler so it does not modify the action in the parent

- possibly change the 'parents' mechanism so it does a deep copy of actions.

References:

http://stackoverflow.com/questions/25818651/argparse-conflict-resolver-for-options-in-subcommands-turns-keyword-argument-int

http://bugs.python.org/issue15271 
argparse: repeatedly specifying the same argument ignores the previous ones

http://bugs.python.org/issue19462
Add remove_argument() method to argparse.ArgumentParser

http://bugs.python.org/issue15428
add "Name Collision" section to argparse docs

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
messages: 226862
nosy: docs at python, paul.j3
priority: normal
severity: normal
status: open
title: argparse: 'resolve' conflict handler damages the actions of the parent parser
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 14 21:40:02 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 14 Sep 2014 19:40:02 +0000
Subject: [docs] [issue17668] re.split loses characters matching ungrouped
	parts of a	pattern
In-Reply-To: <1365445138.49.0.018016443065.issue17668@psf.upfronthosting.co.za>
Message-ID: <1410723602.15.0.722142528208.issue17668@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
stage: needs patch -> resolved
status: pending -> closed

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

From report at bugs.python.org  Wed Sep 17 04:15:54 2014
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 17 Sep 2014 02:15:54 +0000
Subject: [docs] [issue21738] Enum docs claim replacing __new__ is not
	possible
In-Reply-To: <1402598145.45.0.559693441236.issue21738@psf.upfronthosting.co.za>
Message-ID: <1410920154.52.0.259712912492.issue21738@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee: ethan.furman -> docs at python
nosy: +docs at python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Sep 17 09:03:17 2014
From: report at bugs.python.org (paul j3)
Date: Wed, 17 Sep 2014 07:03:17 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1410937396.98.0.462407509287.issue22401@psf.upfronthosting.co.za>


paul j3 added the comment:

'sample3.py' contains a '_handle_conflict_parent' function.

With the help of a change in '_add_container_actions' it determines whether a conflicting action occurs in multiple parsers (and argument_groups).  If it does, it deletes it from the correct group, without altering either the action, or other parsers.

If the action occurs in only 1 group, then the 'resolve' method is used.

The testing script mixes parents, subparsers, and various conflicts.

----------
Added file: http://bugs.python.org/file36635/sample3.py

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

From senthil at uthcode.com  Wed Sep 17 12:59:49 2014
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 17 Sep 2014 18:59:49 +0800
Subject: [docs] hello, is it possible to translating python documention?
In-Reply-To: <a09296e63e7ad63ee1f3856c2e907959@cweb16.nm.nhnsystem.com>
References: <a09296e63e7ad63ee1f3856c2e907959@cweb16.nm.nhnsystem.com>
Message-ID: <CAPOVWOR8Ri5BPK3qK+h3n_o-ya8H517dja0zbJdixBuQoyHLtQ@mail.gmail.com>

On Mon, Sep 8, 2014 at 4:32 PM, ??? <qwefgh90 at naver.com> wrote:

> I'm interested in translate docs to Korean.


The docs are maintained in the repository itself -
https://hg.python.org/cpython/
And you could checkout the docs and do the korean translation for the docs
and commit them to repo (in github or bitbucket).
Once it is a significant size, you could email PSF and request for pointing
a link in the python.org website itself.

I think there is a special interest group for translators (
https://mail.python.org/mailman/listinfo/i18n-sig) and you could ping that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140917/469f498d/attachment.html>

From report at bugs.python.org  Thu Sep 18 04:31:19 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 02:31:19 +0000
Subject: [docs] [issue14824] reprlib documentation references string module
In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za>
Message-ID: <1411007479.51.0.981799817816.issue14824@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Sep 18 05:04:57 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Sep 2014 03:04:57 +0000
Subject: [docs] [issue14824] reprlib documentation references string module
In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za>
Message-ID: <20140918030452.82459.36943@mail.hg.python.org>


Roundup Robot added the comment:

New changeset e9968782c9ba by Berker Peksag in branch '3.4':
Issue #14824: Update Repr.repr_TYPE documentation to use correct name mangling implementation.
https://hg.python.org/cpython/rev/e9968782c9ba

New changeset a0372781eafb by Berker Peksag in branch 'default':
Issue #14824: Update Repr.repr_TYPE documentation to use correct name mangling implementation.
https://hg.python.org/cpython/rev/a0372781eafb

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

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

From report at bugs.python.org  Thu Sep 18 05:08:22 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 03:08:22 +0000
Subject: [docs] [issue14824] reprlib documentation references string module
In-Reply-To: <1337147544.42.0.726566417701.issue14824@psf.upfronthosting.co.za>
Message-ID: <1411009702.43.0.785968523323.issue14824@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> I don't know why we would ever have a space in a typename, ever (and if someone does awful hacks to get to that state, he should probably also do awful hacks to make reprlib work properly).

That part of the code has been added 22 years ago: https://hg.python.org/cpython/rev/a0d4c5ef1d5d#l9.22 So probably the reason is that the code is just old. 

Thanks for the patch, Chris!

----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Sep 18 05:09:47 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 03:09:47 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <1411009787.15.0.316008447731.issue16827@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 18 05:10:48 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 03:10:48 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <1411009848.32.0.0111634619887.issue16827@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Thu Sep 18 05:17:50 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 03:17:50 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <1411010270.42.0.688728201436.issue16827@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, James. Did you see my review comments on Rietveld? Please see at http://bugs.python.org/review/16827/#ps11699

----------

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

From report at bugs.python.org  Thu Sep 18 06:07:27 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 18 Sep 2014 04:07:27 +0000
Subject: [docs] [issue22399] Doc: missing anchor for dict in
	library/functions.html
In-Reply-To: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za>
Message-ID: <1411013247.68.0.499032577273.issue22399@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 18 07:55:33 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 18 Sep 2014 05:55:33 +0000
Subject: [docs] [issue22399] Doc: missing anchor for dict in
	library/functions.html
In-Reply-To: <1410553668.99.0.783608222954.issue22399@psf.upfronthosting.co.za>
Message-ID: <1411019733.1.0.259403547577.issue22399@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The anchor for dict is on the "standard types" page: https://docs.python.org/2/library/stdtypes.html#dict

You'll have to use :class: not :func: to get it linked.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Thu Sep 18 09:25:51 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 18 Sep 2014 07:25:51 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411025151.38.0.0551266950056.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Added file: http://bugs.python.org/file36648/sample3.py

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

From report at bugs.python.org  Thu Sep 18 09:26:14 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 18 Sep 2014 07:26:14 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411025174.29.0.617955067114.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Removed file: http://bugs.python.org/file36635/sample3.py

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

From report at bugs.python.org  Thu Sep 18 15:38:10 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Sep 2014 13:38:10 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <20140918133757.110108.41732@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 2e3a81a0fa14 by Senthil Kumaran in branch '2.7':
Issue #16827: Make Interpreter introduction section of the tutorial more
https://hg.python.org/cpython/rev/2e3a81a0fa14

New changeset 1e81c7a261a7 by Senthil Kumaran in branch '3.4':
Issue #16827: Make Interpreter introduction section of the tutorial more
https://hg.python.org/cpython/rev/1e81c7a261a7

New changeset ea401e7c55e4 by Senthil Kumaran in branch 'default':
merge from 3.4
https://hg.python.org/cpython/rev/ea401e7c55e4

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

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

From report at bugs.python.org  Thu Sep 18 15:40:24 2014
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Sep 2014 13:40:24 +0000
Subject: [docs] [issue16827] Remove the relatively advanced content from
	section 2 in	tutorial
In-Reply-To: <1356964896.19.0.673901752517.issue16827@psf.upfronthosting.co.za>
Message-ID: <1411047624.15.0.688083078141.issue16827@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I addressed Berker Peksag's review comments on Jame's patch, tested the local building of docs, verified the content and looks.

Committed this in 2.7, 3.4 and 3.5.

Thank you all!

----------
assignee: docs at python -> orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Sep 18 16:26:28 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Sep 2014 14:26:28 +0000
Subject: [docs] [issue22436] logging geteffectivelevel does not document its
	return	value
Message-ID: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za>


New submission from R. David Murray:

https://docs.python.org/3/library/logging.html#logging.Logger.getEffectiveLevel

This says the logging level is returned, but it doesn't mention that what is returned is an integer, nor does it link to whatever method is needed to convert the integer return value into the symbolic name that the user has been using elsewhere in interacting with logging.  Indeed, the section that shows the mapping between names and numbers implies that the user of the library never needs to worry about the numbers unless they are creating a new level, but if they want to use getEffectiveLevel, this is not true.

----------
assignee: docs at python
components: Documentation
messages: 227047
nosy: docs at python, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: logging geteffectivelevel does not document its return value
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Sep 18 18:36:07 2014
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 18 Sep 2014 16:36:07 +0000
Subject: [docs] [issue22436] logging geteffectivelevel does not document its
	return	value
In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za>
Message-ID: <1411058166.99.0.939844705761.issue22436@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Users generally use integer values when specifying logging levels, unless they are e.g. using the configuration machinery, when they will specify strings (just because the configuration is in text files).

I will update the documentation to try to make things clearer.

----------

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

From report at bugs.python.org  Thu Sep 18 19:03:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 18 Sep 2014 17:03:18 +0000
Subject: [docs] [issue22436] logging geteffectivelevel does not document its
	return	value
In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za>
Message-ID: <20140918170241.110108.40471@mail.hg.python.org>


Roundup Robot added the comment:

New changeset dd17c3eda73c by Vinay Sajip in branch '2.7':
Issue #22436: Improved documentation for getEffectiveLevel() and getLevelName().
https://hg.python.org/cpython/rev/dd17c3eda73c

New changeset 72a91df86b07 by Vinay Sajip in branch '3.4':
Issue #22436: Improved documentation for getEffectiveLevel() and getLevelName().
https://hg.python.org/cpython/rev/72a91df86b07

New changeset 49dfe2630ae3 by Vinay Sajip in branch 'default':
Closes #22436: Merged documentation update from 3.4.
https://hg.python.org/cpython/rev/49dfe2630ae3

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

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

From report at bugs.python.org  Thu Sep 18 19:53:15 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Sep 2014 17:53:15 +0000
Subject: [docs] [issue22436] logging geteffectivelevel does not document its
	return	value
In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za>
Message-ID: <1411062795.13.0.429007156207.issue22436@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, yes, I was just being dense, because the context I was in was exactly that context: configuration via strings.  Probably no change is required, but if can think of way of making it obvious to someone thinking crooked like I was that would be great.

----------

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

From report at bugs.python.org  Thu Sep 18 19:54:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Sep 2014 17:54:21 +0000
Subject: [docs] [issue22436] logging geteffectivelevel does not document its
	return	value
In-Reply-To: <1411050388.19.0.961403060223.issue22436@psf.upfronthosting.co.za>
Message-ID: <1411062861.25.0.939776032213.issue22436@psf.upfronthosting.co.za>


R. David Murray added the comment:

Woops, should have looked at the rest of my email.  Yes, that change looks great.

----------

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

From report at bugs.python.org  Fri Sep 19 08:08:06 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 19 Sep 2014 06:08:06 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411106886.02.0.251677719167.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Added file: http://bugs.python.org/file36656/sample3.py

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

From report at bugs.python.org  Fri Sep 19 08:08:27 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 19 Sep 2014 06:08:27 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411106907.58.0.126480084542.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Removed file: http://bugs.python.org/file36648/sample3.py

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

From report at bugs.python.org  Sun Sep 21 01:00:16 2014
From: report at bugs.python.org (paul j3)
Date: Sat, 20 Sep 2014 23:00:16 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411254016.65.0.250359163383.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
nosy: +bethard

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

From report at bugs.python.org  Mon Sep 22 00:54:27 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 21 Sep 2014 22:54:27 +0000
Subject: [docs] [issue22456] __base__ undocumented
Message-ID: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis:

__bases__ is documented, but __base__ is not.

$ grep -r __base__ Doc
$ grep -r __bases__ Doc
Doc/c-api/object.rst:are different objects, *B*'s :attr:`~class.__bases__` attribute is searched in
Doc/c-api/object.rst:a depth-first fashion for *A* --- the presence of the :attr:`~class.__bases__`
Doc/extending/newtypes.rst:   in its :attr:`~class.__bases__`, or else it will not be able to call your type's
Doc/library/email.headerregistry.rst:    class's ``__bases__`` list.
Doc/library/functions.rst:   tuple itemizes the base classes and becomes the :attr:`~class.__bases__`
Doc/library/stdtypes.rst:.. attribute:: class.__bases__
Doc/reference/datamodel.rst:      single: __bases__ (class attribute)
Doc/reference/datamodel.rst:   dictionary containing the class's namespace; :attr:`~class.__bases__` is a
Doc/whatsnew/2.3.rst:  removed: you can now assign to the :attr:`__name__` and :attr:`__bases__`
Doc/whatsnew/2.3.rst:  assigned to :attr:`__bases__` along the lines of those relating to assigning to

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 227241
nosy: Arfrever, docs at python
priority: normal
severity: normal
status: open
title: __base__ undocumented
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep 22 01:46:14 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Sep 2014 23:46:14 +0000
Subject: [docs] [issue22456] __base__ undocumented
In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za>
Message-ID: <1411343174.0.0.985234972689.issue22456@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think that __base__ was intended to be a non-guaranteed implementation detail for new-style classes just like  __dictoffset__ and __flags__ .

----------
nosy: +gvanrossum, rhettinger

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

From report at bugs.python.org  Mon Sep 22 02:07:09 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Sep 2014 00:07:09 +0000
Subject: [docs] [issue22456] __base__ undocumented
In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za>
Message-ID: <1411344429.63.0.95531745115.issue22456@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Raymond is correct. __base__ is closely tied to the C implementation.  I think it might be worth a mention, but with an explicit note that it is CPython-specific.  It is sometimes useful, e.g. when wondering why a certain case of multiple inheritance is rejected.

----------

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

From report at bugs.python.org  Mon Sep 22 02:13:38 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 22 Sep 2014 00:13:38 +0000
Subject: [docs] [issue22456] __base__ undocumented
In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za>
Message-ID: <1411344818.14.0.873058165922.issue22456@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

__base__ exists also in Jython and PyPy.

----------

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

From report at bugs.python.org  Mon Sep 22 04:44:01 2014
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Sep 2014 02:44:01 +0000
Subject: [docs] [issue1159] os.getenv() not updated after external module
	uses C	putenv()
In-Reply-To: <1189668127.19.0.0258251668017.issue1159@psf.upfronthosting.co.za>
Message-ID: <1411353841.55.0.706675034743.issue1159@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From report at bugs.python.org  Mon Sep 22 10:32:10 2014
From: report at bugs.python.org (SebKL)
Date: Mon, 22 Sep 2014 08:32:10 +0000
Subject: [docs] [issue22459] str.strip() documentation: wrong example
Message-ID: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za>


New submission from SebKL:

The following example is wrong:
https://docs.python.org/3.4/library/stdtypes.html?highlight=split#str.split

>>> '1,2,3'.split(',', maxsplit=1)
['1', '2 3']

Is actually returning (note the missing , ):
>>> '1,2,3'.split(',', maxsplit=1)
['1', '2,3']

----------
assignee: docs at python
components: Documentation
messages: 227257
nosy: SebKL, docs at python
priority: normal
severity: normal
status: open
title: str.strip() documentation: wrong example
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Sep 22 11:46:35 2014
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Mon, 22 Sep 2014 09:46:35 +0000
Subject: [docs] [issue22459] str.strip() documentation: wrong example
In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za>
Message-ID: <1411379195.55.0.989785638429.issue22459@psf.upfronthosting.co.za>


Ra?l Cumplido added the comment:

As it is a simple one I will try to submit a patch today or tomorrow. This will be my first contribution to Python.

----------
nosy: +raulcd

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

From report at bugs.python.org  Mon Sep 22 21:53:33 2014
From: report at bugs.python.org (Pau Amma)
Date: Mon, 22 Sep 2014 19:53:33 +0000
Subject: [docs] [issue22465] Number agreement error in section 3.2 of web
	docs
Message-ID: <1411415613.69.0.707690037263.issue22465@psf.upfronthosting.co.za>


New submission from Pau Amma:

In https://docs.python.org/2/reference/datamodel.html#the-standard-type-hierarchy, under "numbers.Real (float)", in sentence

  "the savings in processor and memory usage that are usually the reason for using these is dwarfed by the overhead of using objects in Python"

either "is dwarfed" should be "are dwarfed" (preferred) or "are usually" should be "is usually"

----------
assignee: docs at python
components: Documentation
messages: 227304
nosy: docs at python, pauamma
priority: normal
severity: normal
status: open
title: Number agreement error in section 3.2 of web docs
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 22 23:17:14 2014
From: report at bugs.python.org (=?utf-8?q?Ra=C3=BAl_Cumplido?=)
Date: Mon, 22 Sep 2014 21:17:14 +0000
Subject: [docs] [issue22459] str.strip() documentation: wrong example
In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za>
Message-ID: <1411420634.08.0.780874191646.issue22459@psf.upfronthosting.co.za>


Ra?l Cumplido added the comment:

It was also incorrect on the example for bytes split:
>>> b'1,2,3'.split(b',', maxsplit=1)
      [b'1', b'2 3']

Patch submitted.

----------
keywords: +patch
Added file: http://bugs.python.org/file36692/issue22459.patch

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

From report at bugs.python.org  Tue Sep 23 04:31:54 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 23 Sep 2014 02:31:54 +0000
Subject: [docs] [issue22459] str.strip() documentation: wrong example
In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za>
Message-ID: <1411439514.32.0.74948708165.issue22459@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

LGTM. About a straightforward as it gets.

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

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

From report at bugs.python.org  Tue Sep 23 04:44:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 23 Sep 2014 02:44:44 +0000
Subject: [docs] [issue22459] str.strip() documentation: wrong example
In-Reply-To: <1411374730.07.0.0715795458179.issue22459@psf.upfronthosting.co.za>
Message-ID: <20140923024436.50574.92846@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 8eb4eec8626c by Benjamin Peterson in branch '3.4':
fix error in split() examples (closes #22459)
https://hg.python.org/cpython/rev/8eb4eec8626c

New changeset 6dcc96fa3970 by Benjamin Peterson in branch 'default':
merge 3.4 (#22459)
https://hg.python.org/cpython/rev/6dcc96fa3970

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

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

From iwabako at gmail.com  Tue Sep 23 16:20:33 2014
From: iwabako at gmail.com (iwabako at gmail.com)
Date: Tue, 23 Sep 2014 14:20:33 -0000
Subject: [docs] extended slice behavior inconsistent with docs (issue
	1446619)
Message-ID: <20140923142033.32487.31093@psf.upfronthosting.co.za>

Added comment on the patch proposed by bethard.
This patch has been open for 3+ years, can we proceed it as it's still
an issue in the current document?


http://bugs.python.org/review/1446619/diff/2262/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

http://bugs.python.org/review/1446619/diff/2262/Doc/library/stdtypes.rst#newcode959
Doc/library/stdtypes.rst:959: negative.  If *i* or *j* are omitted or
``None``, they become
According to this description, when *i* or *j* is equal to ``len(s)``
and *k* is negative, *i* (or *j*) remains to be ``len(s)``, but it
should be ``len(s) - 1``.

We should say something like this:

When *k* is positive and *i* (or *j*) is greater than ``len(s)``, *i*
(*j*) becomes ``len(s)``. When *k* is negative and *i* (or *j*) is equal
to or greater than ``len(s)``, *i* (*j*) becomes ``len(s) - 1``.

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

From report at bugs.python.org  Tue Sep 23 16:26:15 2014
From: report at bugs.python.org (Fumihiro Bessho)
Date: Tue, 23 Sep 2014 14:26:15 +0000
Subject: [docs] [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1411482375.14.0.56127920348.issue1446619@psf.upfronthosting.co.za>


Fumihiro Bessho added the comment:

I also wondered the same thing today and found this issue.

I've added my comment on the patch to make the change more precise. Can anyone move it ahead and update the document?

----------
nosy: +bessho

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

From report at bugs.python.org  Wed Sep 24 01:46:15 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Sep 2014 23:46:15 +0000
Subject: [docs] [issue22473] The gloss on asyncio "future with run_forever"
	example	is confusing
Message-ID: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za>


New submission from R. David Murray:

In https://docs.python.org/3/library/asyncio-task.html#example-future-with-run-forever we have the sentence

  In this example, the future is responsible to display the result and to stop the loop.

We could dune up the English by rewriting it:

  In this example, the future is responsible for displaying the result and stopping the loop.

But that isn't quite true.  It is the callback associated with the future that is displaying the result and stopping the loop.  So, perhaps the correct gloss is:

  In this example, the got_result callback is responsible for displaying the result and stopping the loop.

----------
assignee: docs at python
components: Documentation
messages: 227398
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: The gloss on asyncio "future with run_forever" example is confusing
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 24 02:02:23 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Sep 2014 00:02:23 +0000
Subject: [docs] [issue22474] No explanation of how a task gets destroyed in
	asyncio	'task' documentation
Message-ID: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za>


New submission from R. David Murray:

In https://docs.python.org/3/library/asyncio-task.html#task, there is a note about a warning being logged if a pending task is destroyed.  The section does not explain or link to an explanation of how a task might get destroyed.  Nor does it define pending, but that seems reasonably clear from context (ie: the future has not completed).

The example linked to does not show how the pending task got destroyed, it only shows an example of the resulting logging, with not enough information to really understand what the final line of the error message is reporting (is kill_me an asyncio API, or the name of the task, or the future it is wrapping?)

----------
assignee: docs at python
components: Documentation
messages: 227400
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: No explanation of how a task gets destroyed in asyncio 'task' documentation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 24 02:51:49 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Sep 2014 00:51:49 +0000
Subject: [docs] [issue22475] asyncio task get_stack documentation seems to
	contradict	itself
Message-ID: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za>


New submission from R. David Murray:

The get_stack method docs say:

"If the coroutine is active, returns the stack where it was suspended."

I presume this means something more like "if the coroutine is not done...", since in English you can't be both active *and* suspended.  Or does it mean "last suspended"?

Then it talks about limit and how stacks limit returns newest frames while with tracebacks it is oldest frames...but the last sentence says that for suspended coroutines only one frame is returned.

So there is a definite lack of clarity here: can we get multiple frames if the coroutine is not suspended (in which case that first sentence seems likely to be the 'last suspended' interpretation), or for non-tracebacks can we only ever get one frame, in which case why talk about limit returning the newest frames for stacks?

----------
assignee: docs at python
components: Documentation
messages: 227401
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: asyncio task get_stack documentation seems to contradict itself
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 24 03:34:04 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Sep 2014 01:34:04 +0000
Subject: [docs] [issue22476] asyncio task chapter confusion about 'task',
	'future', and 'schedule'
Message-ID: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za>


New submission from R. David Murray:

Sorry for creating all these doc issues, but I'm reading these docs for the first time, and I figure it is good to capture my confusion now in the hopes that they can be clarified for other people's first readthroughs.

In the task chapter, we have Futures introduced.  (As an aside, it is interesting that the link to the concurrent.futures.Future docs start by saying "you should never instantiate this class directly", but the asyncio examples show direct instantiation of a future, but this difference is not mentioned in the asyncio docs when discussing the differences between them).  We then see an example that appears to include scheduling a future via asyncio.async, because there is a specific mention of how we can attach a callback after it is scheduled but before the event loop is started.

Then tasks are introduced with the text:

  Schedule the execution of a coroutine: wrap it in a future.  A task is a subclass of Future.

Now, having read a bit more elsewhere in the docs, I see that a Future is scheduled by its creation, and the call to async on the future in the previous example is a NOOP.  But that is *not* the implication of the text (see below as well).  So, there are several points of dissonance here.  One is that the implication is we pass Task a coroutine and it *wraps* it in a Future.  But a Task *is* a Future.  So do we have a Future using another Future to wrap a coroutine, or what?  Another point of dissonance is that this phrasing implies that the *act* of wrapping the coroutine in a Future is what schedules it, yet when we introduced Future we apparently had to schedule it explicitly.  So I think there needs to be a mention of scheduling in the Future section.

But this then brings up the question of what exactly it is that Task does that differs from what a regular Future does, a question that is only partially answered by the documentation, because what 'scheduled' means for a regular Future isn't spelled out in the Future section.
  
Which I think means that what we really need is an overview document that puts all these concepts together into a conceptual framework, so that the documentation of the individual pieces makes sense.

As a followon point, the gloss on example of parallel execution of tasks says "A task is automatically scheduled for execution when it is created.  The event loop stops when all tasks are done."  This reads very strangely to me.  The first sentence seems to be pointing out the difference between this example and the previous one with Future where we had to explicitly schedule it (by calling async which creates a task...).  But it seems that that isn't true...so why is that sentence there? The second sentence presumably refers to the fact that run_until_complete runs the event loop until all scheduled tasks are complete..because they are wrapped in 'wait'.  But wait is not cross referenced or mentioned in the gloss, so I had to think about it carefully and look up wait to conclude that that was what it meant.

Of course, I could be more confused than necessary because I started reading with the 'task' chapter, but I don't see an overview chapter in the doc tree.

----------
assignee: docs at python
components: Documentation
messages: 227405
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: asyncio task chapter confusion about 'task', 'future', and 'schedule'
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Sep 24 10:50:30 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Sep 2014 08:50:30 +0000
Subject: [docs] [issue22476] asyncio task chapter confusion about 'task',
	'future', and 'schedule'
In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za>
Message-ID: <1411548630.69.0.560305552399.issue22476@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

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

From report at bugs.python.org  Wed Sep 24 10:50:39 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Sep 2014 08:50:39 +0000
Subject: [docs] [issue22475] asyncio task get_stack documentation seems to
	contradict	itself
In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za>
Message-ID: <1411548639.94.0.621102132431.issue22475@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

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

From report at bugs.python.org  Wed Sep 24 10:50:50 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Sep 2014 08:50:50 +0000
Subject: [docs] [issue22474] No explanation of how a task gets destroyed in
	asyncio	'task' documentation
In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za>
Message-ID: <1411548650.89.0.26297672696.issue22474@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

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

From report at bugs.python.org  Wed Sep 24 10:51:00 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Sep 2014 08:51:00 +0000
Subject: [docs] [issue22473] The gloss on asyncio "future with run_forever"
	example	is confusing
In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za>
Message-ID: <1411548660.0.0.0061755520351.issue22473@psf.upfronthosting.co.za>


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


----------
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov

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

From report at bugs.python.org  Wed Sep 24 11:44:11 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Sep 2014 09:44:11 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <20140924094404.99099.35827@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 2058d94f32dd by Berker Peksag in branch '3.4':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/2058d94f32dd

New changeset de645efe6a9b by Berker Peksag in branch 'default':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/de645efe6a9b

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

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

From report at bugs.python.org  Wed Sep 24 11:45:36 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 24 Sep 2014 09:45:36 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <1411551936.78.0.823747007553.issue21860@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Terry.

----------
assignee: haypo -> berker.peksag
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Wed Sep 24 11:54:27 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Sep 2014 09:54:27 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <20140924095421.82039.91609@mail.hg.python.org>


Roundup Robot added the comment:

New changeset be2746c565c2 by Berker Peksag in branch '2.7':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/be2746c565c2

----------

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

From report at bugs.python.org  Wed Sep 24 16:27:09 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:27:09 +0000
Subject: [docs] [issue22476] asyncio task chapter confusion about 'task',
	'future', and 'schedule'
In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za>
Message-ID: <1411568829.4.0.584415736052.issue22476@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I know that the "18.5.3. Tasks and coroutines" section of the documentation is probably the worst section :-( Feel free to suggest changes with a patch!

I started to enhance the documentation of the Task class, but there is still a lot of work to enhance the whole section.


> "We then see an example that appears to include scheduling a future via asyncio.async, because there is a specific mention of how we can attach a callback after it is scheduled but before the event loop is started."

I guess that you are talking about this example?
https://docs.python.org/dev/library/asyncio-task.html#example-future-with-run-until-complete

You cannot "schedule" a Future object. A Future object doesn't contain code. It only schedules callbacks when set_result() or set_exception() is called.

In this example, a call to the slow_operation coroutine function is scheduled: "slow_operation(future)" creates a coroutine object which is wrapped into a Task object. A coroutine is disconnected from the event loop. The role of the task is to schedule the execution of a coroutine object.

It becomes more complex when you know that the Task class inherits from the Future class :-/


> "I see that a Future is scheduled by its creation"

Again, this is wrong. You cannot "schedule a future". You can schedule a coroutine object by creating a task wrapping it.


> As a followon point, the gloss on example of parallel execution of tasks says "A task is automatically scheduled for execution when it is created.  The event loop stops when all tasks are done."  This reads very strangely to me.  The first sentence seems to be pointing out the difference between this example and the previous one with Future where we had to explicitly schedule it (by calling async which creates a task...).  But it seems that that isn't true...so why is that sentence there? The second sentence presumably refers to the fact that run_until_complete runs the event loop until all scheduled tasks are complete..because they are wrapped in 'wait'.  But wait is not cross referenced or mentioned in the gloss, so I had to think about it carefully and look up wait to conclude that that was what it meant.

Hum, I summarized too many information in "The event loop stops when all tasks are done." In fact, the example stops when run_until_complete() finished its job.

----------

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

From report at bugs.python.org  Wed Sep 24 16:28:04 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:28:04 +0000
Subject: [docs] [issue22475] asyncio task get_stack documentation seems to
	contradict	itself
In-Reply-To: <1411519909.22.0.512722932689.issue22475@psf.upfronthosting.co.za>
Message-ID: <1411568884.9.0.974002895905.issue22475@psf.upfronthosting.co.za>


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


----------
components: +asyncio

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

From report at bugs.python.org  Wed Sep 24 16:28:20 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:28:20 +0000
Subject: [docs] [issue22474] No explanation of how a task gets destroyed in
	asyncio	'task' documentation
In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za>
Message-ID: <1411568900.18.0.985026091436.issue22474@psf.upfronthosting.co.za>


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


----------
components: +asyncio

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

From report at bugs.python.org  Wed Sep 24 16:34:24 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:34:24 +0000
Subject: [docs] [issue22474] No explanation of how a task gets destroyed in
	asyncio	'task' documentation
In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za>
Message-ID: <1411569264.2.0.783244376509.issue22474@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"destroyed" means "collected by the garbage collector", when the last reference the task objected was cleared. To be honest, I have no idea who keeps a reference to tasks nor how the "pending task destroyed" bug occurs.

"pending" means that the execution of the coroutine object didn't finish. In fact, it's related to Task.done(): a task is pending is task.done() is False.

There is a corner case: if task.cancel() was called but the coroutine object was not executed yet to handle the CancelledError, the task is still "pending".

Maybe "pending" is not the best word, and "not done" is better.

----------

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

From report at bugs.python.org  Wed Sep 24 16:39:37 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:39:37 +0000
Subject: [docs] [issue22473] The gloss on asyncio "future with run_forever"
	example	is confusing
In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za>
Message-ID: <1411569576.95.0.192479972417.issue22473@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"But that isn't quite true.  It is the callback associated with the future that is displaying the result and stopping the loop."

I wrote this example to show that setting the result of a future can schedule a callback. I mean something like:

"In this example, the future is used to link slow_operation() to got_result(): when slow_operation() is done, got_result() is called with the result."

The main idea behind Future is to chain callbacks and the link is done externally. It's different from this design:

    def slow_operation(done_callback):
        ...
        done_callback()

----------

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

From report at bugs.python.org  Wed Sep 24 16:42:21 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:42:21 +0000
Subject: [docs] [issue22473] The gloss on asyncio "future with run_forever"
	example	is confusing
In-Reply-To: <1411515975.42.0.282827755318.issue22473@psf.upfronthosting.co.za>
Message-ID: <1411569741.48.0.754115151964.issue22473@psf.upfronthosting.co.za>


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


----------
components: +asyncio

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

From report at bugs.python.org  Wed Sep 24 16:50:01 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Sep 2014 14:50:01 +0000
Subject: [docs] [issue22476] asyncio task chapter confusion about 'task',
	'future', and 'schedule'
In-Reply-To: <1411522444.59.0.775206973129.issue22476@psf.upfronthosting.co.za>
Message-ID: <1411570201.83.0.838721548718.issue22476@psf.upfronthosting.co.za>


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


----------
components: +asyncio

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

From eliot at yelp.com  Fri Sep 19 18:51:36 2014
From: eliot at yelp.com (Eliot Alter)
Date: Fri, 19 Sep 2014 09:51:36 -0700
Subject: [docs] Documentation typo in json docs
Message-ID: <CAO-Gz-5vrHgjQkDxGNfDo59OZug-66XdsM_19WB4U3LM9th4RA@mail.gmail.com>

https://docs.python.org/2/library/json.html

When describing how to use json.tool, you provide the following example
code:

$ echo '{"json":"obj"}' | python *-mjson.tool*
{
    "json": "obj"
}
$ echo '{1.2:3.4}' | python *-mjson.tool*
Expecting property name enclosed in double quotes: line 1 column 2 (char 1)


However, there is no space between the *-m* and the *json.tool*. There
should be a space in those 2 places.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140919/82c6abb9/attachment.html>

From lo94610 at gmail.com  Tue Sep 23 06:10:28 2014
From: lo94610 at gmail.com (L Ogden)
Date: Mon, 22 Sep 2014 21:10:28 -0700
Subject: [docs] 404 error
Message-ID: <CAB3tDxNbC004fX95G-H_u0E00i64fOrTYC5py_sV3fcVXN3UhA@mail.gmail.com>

Hi Pythoners,
I'm trying to download the 3.4.2rc1 documentation but keep getting a 404
error. Just downloaded Python to this laptop and had no trouble with that
or with getting to any of your other pages. I'm seeing this error only when
I try to download the PDF documentation. Give a shout when it is working
again.
Thanks,
Laura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140922/331094dd/attachment.html>

From amirkhan at fortinet.com  Tue Sep 23 08:54:16 2014
From: amirkhan at fortinet.com (Amir Khan)
Date: Tue, 23 Sep 2014 07:54:16 +0100
Subject: [docs] 404 error
Message-ID: <FACA5913-6C72-4F10-827C-F914F915128D@fortinet.com>

I'm trying to download the docs for python 3. I'm getting a 404 error:

https://docs.python.org/3/archives/python-3.4.2rc1-docs-html.zip

Amir

?
Amir Khan | Senior Account Manager | Fortinet - High Performance Network Security
email amirkhan at fortinet.com | phone +44 7876 658333 | skype amirphone

Typos courtesy of my mobile device 

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140923/0797ce19/attachment.html>

From frankguz at verizon.net  Wed Sep 24 03:27:36 2014
From: frankguz at verizon.net (Frank Guziewicz)
Date: Tue, 23 Sep 2014 20:27:36 -0500
Subject: [docs] Error Msg: 404 Server not Found
Message-ID: <54221E08.2080805@verizon.net>

I am on the "Documents.html" page, and no matter which item I select to 
download,
I get the message quoted in the subject line.
H E L P:-(
Frank

From rui.joaquim at uni.lu  Wed Sep 24 14:56:04 2014
From: rui.joaquim at uni.lu (Rui JOAQUIM)
Date: Wed, 24 Sep 2014 12:56:04 +0000
Subject: [docs] 404 error in the docs links
Message-ID: <0372550419515C499D829EBF17B05B530504DEFF@hoshi.uni.lux>

Hi,

I'm trying to download the documentation but I get a 404 error message!?

Can you please check what's happening with the download links.

Kind regards,
Rui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140924/b446df37/attachment.html>

From dbavery at gmail.com  Wed Sep 24 18:30:34 2014
From: dbavery at gmail.com (Devin Avery)
Date: Wed, 24 Sep 2014 12:30:34 -0400
Subject: [docs] Download links are returning 404
Message-ID: <C493E375-4ED8-46DD-9B9C-F01EF68D4743@gmail.com>

Hello -

I am trying to download the python text in an offline and the download links are giving me a 404.

The links I am using are here:

https://docs.python.org/3/download.html

Are these expected to be valid links?

Thank you,

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

From leftmybike at gmail.com  Fri Sep 19 22:31:37 2014
From: leftmybike at gmail.com (Iain Scott)
Date: Fri, 19 Sep 2014 21:31:37 +0100
Subject: [docs] DLL File
Message-ID: <CACq0XH0aTs=d0bL2smc+r7Emr1ih3j4Pu-_eH8P_G6m+zFs=iQ@mail.gmail.com>

The windows installer set up  package for Python 3.4.1 message .....A DLL
file required for this install to complete could not be run. My system
processor AMD E-450 APU. Windows 7 pro. 64 bit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140919/de90567c/attachment-0001.html>

From report at bugs.python.org  Wed Sep 24 20:15:08 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 24 Sep 2014 18:15:08 +0000
Subject: [docs] [issue22484] Build doc archives for RC versions
Message-ID: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The attached patch partly reverts https://hg.python.org/cpython/rev/48033d90c61d#l2.126 since it breaks building doc archives for RC versions:

- https://mail.python.org/pipermail/docs/2014-September/020211.html
- https://mail.python.org/pipermail/docs/2014-September/020214.html
- https://mail.python.org/pipermail/docs/2014-September/020215.html

See https://hg.python.org/cpython/rev/ecfb6f8a7bcf for the original changeset.

----------
assignee: docs at python
components: Documentation
files: autobuild.diff
keywords: patch
messages: 227479
nosy: benjamin.peterson, berker.peksag, docs at python
priority: high
severity: normal
stage: patch review
status: open
title: Build doc archives for RC versions
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36711/autobuild.diff

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

From report at bugs.python.org  Wed Sep 24 20:18:21 2014
From: report at bugs.python.org (Carol Willing)
Date: Wed, 24 Sep 2014 18:18:21 +0000
Subject: [docs] [issue22485] Documentation download links (3.4.2
Message-ID: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za>


New submission from Carol Willing:

As reported by a couple of users on the python-docs mailing list:

Python 3.4.2rc1 docs are giving a 404 Not Found when clicking on the links to download (https://docs.python.org/3.4/download.html).

Python 3.5.0a0 links download docs correctly (https://docs.python.org/3.5/download.html).

If I option-click on a Mac, I can download Python 3.4.2rc1 docs; however, the direct links 404.

----------
assignee: docs at python
components: Documentation
messages: 227480
nosy: docs at python, willingc
priority: normal
severity: normal
status: open
title: Documentation download links (3.4.2
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed Sep 24 20:19:54 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Sep 2014 18:19:54 +0000
Subject: [docs] [issue22485] Documentation download links (3.4.2
In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za>
Message-ID: <1411582794.85.0.0209858601522.issue22485@psf.upfronthosting.co.za>


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


----------
nosy: +larry, terry.reedy

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

From report at bugs.python.org  Wed Sep 24 20:21:11 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 24 Sep 2014 18:21:11 +0000
Subject: [docs] [issue22485] Documentation download links (3.4.2
In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za>
Message-ID: <1411582871.67.0.837768813589.issue22485@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 22484.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Build doc archives for RC versions

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

From report at bugs.python.org  Wed Sep 24 20:29:31 2014
From: report at bugs.python.org (Carol Willing)
Date: Wed, 24 Sep 2014 18:29:31 +0000
Subject: [docs] [issue22485] Documentation download links (3.4.2
In-Reply-To: <1411582701.15.0.026465273673.issue22485@psf.upfronthosting.co.za>
Message-ID: <1411583371.01.0.567262044414.issue22485@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Berker. I'm glad it's being addressed and you have submitted a patch.

----------

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

From report at bugs.python.org  Wed Sep 24 20:33:20 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 24 Sep 2014 18:33:20 +0000
Subject: [docs] [issue22484] Build doc archives for RC versions
In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za>
Message-ID: <1411583600.3.0.890716859374.issue22484@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why would this not also be an issue for alpha/beta?

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

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

From willingc at willingconsulting.com  Wed Sep 24 20:13:49 2014
From: willingc at willingconsulting.com (Carol Willing)
Date: Wed, 24 Sep 2014 11:13:49 -0700
Subject: [docs] Download links are returning 404
In-Reply-To: <C493E375-4ED8-46DD-9B9C-F01EF68D4743@gmail.com>
References: <C493E375-4ED8-46DD-9B9C-F01EF68D4743@gmail.com>
Message-ID: <542309DD.1090405@willingconsulting.com>

Python 3.4.2rc1 docs are giving a 404 Not Found when clicking on the 
links to download (https://docs.python.org/3.4/download.html).

Python 3.5.0a0 links download docs correctly 
(https://docs.python.org/3.5/download.html).

If I option-click on a Mac, I can download Python 3.4.2rc1 docs; 
however, the direct links 404.

Carol

On 24/09/2014 09:30, Devin Avery wrote:
> Hello -
>
> I am trying to download the python text in an offline and the download 
> links are giving me a 404.
>
> The links I am using are here:
>
> https://docs.python.org/3/download.html
>
> Are these expected to be valid links?
>
> Thank you,
>
> Devin
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs


-- 
*Carol Willing*
Developer | Willing Consulting
+1 760 456 9366 | https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140924/f8886c46/attachment-0001.html>

From John.Jeffers at ge.com  Wed Sep 24 17:59:21 2014
From: John.Jeffers at ge.com (Jeffers, John (GE Oil & Gas))
Date: Wed, 24 Sep 2014 15:59:21 +0000
Subject: [docs] Broken Link 3.4.2rc1 Python Docs
Message-ID: <A64A85CF2DC1DB4BB9D004B506CA2D0E06FA1A7F@ALPURAPA09.e2k.ad.ge.com>

Gentlemen

Just to point out the links to the documentation

https://docs.python.org/3.4/download.html  (3.4.2rc1)
Return Error 404  (Your other pages are fine)!

A link broke.

Regards John

John Jeffers, P.Eng.
Sr. Manufacturing Engineer
TRS Engineer
GE Oil & Gas, D&S
Lufkin Automation
811 Willow Oak Drive
Missouri City, TX 77489
Office (281) 495-1100
Cisco (281) 410-6156
Cell: (903) 445-5491

GE imagination at work
Please update to my new email address john.jeffers at ge.com<mailto:john.jeffers at ge.com>
CONFIDENTIALITY NOTICE: This email transmission, including any attachments, is intended only for the named recipient(s) and may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you have received this transmission in error, or are not the named recipient(s), please notify sender immediately by return email and permanently delete this transmission, including any attachments.

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

From senthil at uthcode.com  Thu Sep 25 01:24:53 2014
From: senthil at uthcode.com (Senthil Kumaran)
Date: Thu, 25 Sep 2014 07:24:53 +0800
Subject: [docs] Broken Link 3.4.2rc1 Python Docs
In-Reply-To: <A64A85CF2DC1DB4BB9D004B506CA2D0E06FA1A7F@ALPURAPA09.e2k.ad.ge.com>
References: <A64A85CF2DC1DB4BB9D004B506CA2D0E06FA1A7F@ALPURAPA09.e2k.ad.ge.com>
Message-ID: <CAPOVWOTURvPuCmU8puDbprNdFoyQCoBS8YVq+1=RLGAmMpZmgw@mail.gmail.com>

On Wed, Sep 24, 2014 at 11:59 PM, Jeffers, John (GE Oil & Gas) <
John.Jeffers at ge.com> wrote:

>  Gentlemen
>
>
>
> Just to point out the links to the documentation
>
>
>
> https://docs.python.org/3.4/download.html  (3.4.2rc1)
>
> Return Error 404  (Your other pages are fine)!
>
>
>

Thanks for the report.
Created http://bugs.python.org/issue22488 to track and fix it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140925/1064a583/attachment.html>

From report at bugs.python.org  Thu Sep 25 01:43:18 2014
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Sep 2014 23:43:18 +0000
Subject: [docs] [issue22484] Build doc archives for RC versions,
	docs download broken for 3.4.2rc1
In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za>
Message-ID: <1411602198.0.0.784169064929.issue22484@psf.upfronthosting.co.za>


Ned Deily added the comment:

This problem is currently resulting in 404's for 3.4.2rc1 documention downloads, e.g. the links on:

https://docs.python.org/3.4/download.html

----------
nosy: +ned.deily
priority: high -> critical
title: Build doc archives for RC versions -> Build doc archives for RC versions, docs download broken for 3.4.2rc1

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

From report at bugs.python.org  Thu Sep 25 02:23:24 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Sep 2014 00:23:24 +0000
Subject: [docs] [issue22484] Build doc archives for RC versions,
	docs download broken for 3.4.2rc1
In-Reply-To: <1411582508.1.0.277862654649.issue22484@psf.upfronthosting.co.za>
Message-ID: <20140925002312.123967.37125@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 8ce21ffc6df5 by Benjamin Peterson in branch '3.4':
allow archives for rc releases to be built (closes #22484)
https://hg.python.org/cpython/rev/8ce21ffc6df5

New changeset 7d6297450943 by Benjamin Peterson in branch 'default':
merge 3.4 (#22484)
https://hg.python.org/cpython/rev/7d6297450943

New changeset 22a46f05ce23 by Benjamin Peterson in branch '2.7':
allow archives for rc releases to be built (closes #22484)
https://hg.python.org/cpython/rev/22a46f05ce23

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

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

From report at bugs.python.org  Thu Sep 25 09:25:47 2014
From: report at bugs.python.org (theme)
Date: Thu, 25 Sep 2014 07:25:47 +0000
Subject: [docs] [issue12946] PyModule_GetDict() claims it can never fail,
	but it can
In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>
Message-ID: <1411629947.36.0.470834764346.issue12946@psf.upfronthosting.co.za>


Changes by theme <theemathas at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep 25 09:33:18 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Sep 2014 07:33:18 +0000
Subject: [docs] [issue12946] PyModule_GetDict() claims it can never fail,
	but it can
In-Reply-To: <1315585192.34.0.742122652176.issue12946@psf.upfronthosting.co.za>
Message-ID: <1411630398.0.0.71339139477.issue12946@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I gave two reasons why this function can fail, and one turns out to be assumed-to-be-dead code. 

If the call to PyDict_New() is never called, the test can be replaced with an assertion.

----------

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

From tracdhiraj at gmail.com  Wed Sep 24 22:38:19 2014
From: tracdhiraj at gmail.com (Dhiraj Sahni)
Date: Thu, 25 Sep 2014 02:08:19 +0530
Subject: [docs] Documentation link not working
Message-ID: <CAK7BhUs0Lip+yudDkEGScRdosc0oM-Aa_z5XequgZT8g5RmeAg@mail.gmail.com>

HI,
I was just trying to download the documentation for python 3.4.1 for
windows 7 64 bit but I am sorry to say that the Links are broken

PDF (US-Letter paper size)Download
<https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-pdf-letter.zip> (ca.
8 MB)
PDF (A4 paper size)Download
<https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-pdf-a4.zip> (ca.
8 MB)HTMLDownload
<https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-html.zip> (ca. 6
MB)Plain TextDownload
<https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-text.zip> (ca. 2
MB)EPUBDownload
<https://docs.python.org/3.4/archives/python-3.4.2rc1-docs.epub> (ca. 4.5
MB)

Just wanted to bring to your notice.
-- 
Bye for now
With Regards
Dhiraj Sahni

Legal Disclaimer:
This Website/ E-mail are vulnerable to data corruption, interception,
tampering, viruses as well as delivery errors and we do not accept
liability for any consequence that may arise therefrom.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140925/51a862e9/attachment.html>

From report at bugs.python.org  Fri Sep 26 06:06:45 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 26 Sep 2014 04:06:45 +0000
Subject: [docs] [issue22474] No explanation of how a task gets destroyed in
	asyncio	'task' documentation
In-Reply-To: <1411516943.46.0.304192335953.issue22474@psf.upfronthosting.co.za>
Message-ID: <1411704405.82.0.295233426018.issue22474@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
nosy: +vadmium

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

From senthil at uthcode.com  Fri Sep 26 09:19:16 2014
From: senthil at uthcode.com (Senthil Kumaran)
Date: Fri, 26 Sep 2014 15:19:16 +0800
Subject: [docs] Documentation link not working
In-Reply-To: <CAK7BhUs0Lip+yudDkEGScRdosc0oM-Aa_z5XequgZT8g5RmeAg@mail.gmail.com>
References: <CAK7BhUs0Lip+yudDkEGScRdosc0oM-Aa_z5XequgZT8g5RmeAg@mail.gmail.com>
Message-ID: <CAPOVWOSZ1bpVEcnje3iYODcN5BmGohF6et2VCESgud9Bg0hf3Q@mail.gmail.com>

This should be working again now. Just verified.
The relevant bug  http://bugs.python.org/issue22484 was closed yesterday.

Thanks!




On Thu, Sep 25, 2014 at 4:38 AM, Dhiraj Sahni <tracdhiraj at gmail.com> wrote:

> HI,
> I was just trying to download the documentation for python 3.4.1 for
> windows 7 64 bit but I am sorry to say that the Links are broken
>
> PDF (US-Letter paper size)Download
> <https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-pdf-letter.zip> (ca.
> 8 MB)
> PDF (A4 paper size)Download
> <https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-pdf-a4.zip> (ca.
> 8 MB)HTMLDownload
> <https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-html.zip> (ca.
> 6 MB)Plain TextDownload
> <https://docs.python.org/3.4/archives/python-3.4.2rc1-docs-text.zip> (ca.
> 2 MB)EPUBDownload
> <https://docs.python.org/3.4/archives/python-3.4.2rc1-docs.epub> (ca. 4.5
> MB)
>
> Just wanted to bring to your notice.
> --
> Bye for now
> With Regards
> Dhiraj Sahni
>
> Legal Disclaimer:
> This Website/ E-mail are vulnerable to data corruption, interception,
> tampering, viruses as well as delivery errors and we do not accept
> liability for any consequence that may arise therefrom.
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140926/61f60b0d/attachment.html>

From report at bugs.python.org  Fri Sep 26 09:20:19 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 26 Sep 2014 07:20:19 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411716019.34.0.525841468133.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Added file: http://bugs.python.org/file36728/sample3.py

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

From report at bugs.python.org  Fri Sep 26 09:20:35 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 26 Sep 2014 07:20:35 +0000
Subject: [docs] [issue22401] argparse: 'resolve' conflict handler damages
	the actions	of the parent parser
In-Reply-To: <1410673598.78.0.274465754789.issue22401@psf.upfronthosting.co.za>
Message-ID: <1411716035.07.0.133363212173.issue22401@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


Removed file: http://bugs.python.org/file36656/sample3.py

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

From report at bugs.python.org  Fri Sep 26 14:34:55 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Sep 2014 12:34:55 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <20140926123450.82055.49466@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 84313c61e60d by Berker Peksag in branch '3.4':
Issue #17462: Add a paragraph about advantages of argparse over optparse.
https://hg.python.org/cpython/rev/84313c61e60d

New changeset 45e1c0029aff by Berker Peksag in branch 'default':
Issue #17462: Add a paragraph about advantages of argparse over optparse.
https://hg.python.org/cpython/rev/45e1c0029aff

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

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

From report at bugs.python.org  Fri Sep 26 14:38:58 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 26 Sep 2014 12:38:58 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <20140926123854.82106.21688@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 4eb847e7ddde by Berker Peksag in branch '2.7':
Issue #17462: Add a paragraph about advantages of argparse over optparse.
https://hg.python.org/cpython/rev/4eb847e7ddde

----------

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

From report at bugs.python.org  Fri Sep 26 14:40:25 2014
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 26 Sep 2014 12:40:25 +0000
Subject: [docs] [issue17462] argparse FAQ: how it is different from optparse
In-Reply-To: <1363624948.23.0.605198582935.issue17462@psf.upfronthosting.co.za>
Message-ID: <1411735225.17.0.200457731014.issue17462@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Anastasia.

----------
assignee: eric.araujo -> berker.peksag
keywords: +easy
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Sep 27 16:29:15 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Sep 2014 14:29:15 +0000
Subject: [docs] [issue20164] Undocumented KeyError from os.path.expanduser
In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za>
Message-ID: <1411828155.03.0.487407799421.issue20164@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sat Sep 27 16:32:21 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Sep 2014 14:32:21 +0000
Subject: [docs] [issue15414] os.path.join behavior on Windows (ntpath.join)
	is	unexpected and not well documented
In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>
Message-ID: <1411828341.22.0.801324413092.issue15414@psf.upfronthosting.co.za>


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


----------
keywords: +needs review
stage:  -> patch review
versions: +Python 2.7

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

From report at bugs.python.org  Sat Sep 27 17:02:55 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 27 Sep 2014 15:02:55 +0000
Subject: [docs] [issue18855] Inconsistent README filenames
In-Reply-To: <1377616570.1.0.108273179071.issue18855@psf.upfronthosting.co.za>
Message-ID: <1411830175.98.0.442625980672.issue18855@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sat Sep 27 18:30:33 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 27 Sep 2014 16:30:33 +0000
Subject: [docs] [issue20140] UnicodeDecodeError in ntpath.py when home dir
	contains	non-ascii signs
In-Reply-To: <1389005031.99.0.692658963376.issue20140@psf.upfronthosting.co.za>
Message-ID: <1411835433.03.0.884770202373.issue20140@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks to me as documentation issue. Unfortunately it is not explicitly documented that os.path.join() shouldn't mix str and unicode components (except ascii-only str, such as '.').

There is relevant note in 3.x documentation. It should be adapted to 2.7.

----------
assignee:  -> docs at python
components: +Documentation -Windows
keywords: +easy
nosy: +docs at python, serhiy.storchaka
stage:  -> needs patch
type: crash -> behavior

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

From report at bugs.python.org  Sat Sep 27 18:38:31 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Sep 2014 16:38:31 +0000
Subject: [docs] [issue11479] Add discussion of trailing backslash in raw
	string to	tutorial
In-Reply-To: <1299985803.24.0.199507309731.issue11479@psf.upfronthosting.co.za>
Message-ID: <1411835910.93.0.564871376486.issue11479@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm on a quest to clear my 'commit ready' queue.  This issue needs to go back to 'needs patch' stage...I'll leave it to someone else to rewrite my original patch based on the feedback, since it is unlikely I will get back to it any time soon.  I'll commit it if someone else does the revision and moves it back to commit review, though ;)

----------
stage: commit review -> needs patch
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Sep 27 21:03:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 27 Sep 2014 19:03:12 +0000
Subject: [docs] [issue20974] email module docs say not compatible with
	current python	version
In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za>
Message-ID: <20140927190310.82106.32354@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 2eea52c287b7 by R David Murray in branch '3.4':
#20974: Update version table in email intro.
https://hg.python.org/cpython/rev/2eea52c287b7

New changeset 655b34cd8871 by R David Murray in branch 'default':
Merge: #20974: Update version table in email intro.
https://hg.python.org/cpython/rev/655b34cd8871

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

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

From report at bugs.python.org  Sat Sep 27 21:07:24 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Sep 2014 19:07:24 +0000
Subject: [docs] [issue20974] email module docs say not compatible with
	current python	version
In-Reply-To: <1395176910.11.0.458502603486.issue20974@psf.upfronthosting.co.za>
Message-ID: <1411844844.41.0.517083634097.issue20974@psf.upfronthosting.co.za>


R. David Murray added the comment:

I've updated the table (thanks for the patch) but noted that after 5.1/3.2 there is no independent email version.  I'd like to just delete __version__ in 3.5, but I don't know if I have to deprecate the constant first :)  It didn't get updated in 3.3 or 3.4, so it isn't *accurate* in any case.

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

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

From report at bugs.python.org  Sat Sep 27 22:09:20 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 27 Sep 2014 20:09:20 +0000
Subject: [docs] [issue10702] bytes and bytearray methods are not documented
In-Reply-To: <1292347564.88.0.542769666771.issue10702@psf.upfronthosting.co.za>
Message-ID: <1411848560.13.0.0759501657962.issue10702@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed in issue 21777.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Sep 27 22:10:04 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 27 Sep 2014 20:10:04 +0000
Subject: [docs] [issue16252] bytes and bytearray methods are undocumented
In-Reply-To: <1350414656.76.0.593225775655.issue16252@psf.upfronthosting.co.za>
Message-ID: <1411848604.87.0.799061495617.issue16252@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed in issue 21777.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Sep 28 00:31:15 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 27 Sep 2014 22:31:15 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1411857074.91.0.155337712774.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

Here is my version of Ezio's patch.

----------
Added file: http://bugs.python.org/file36748/mutable_faq.patch

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

From report at bugs.python.org  Sun Sep 28 03:34:47 2014
From: report at bugs.python.org (Prof Oak)
Date: Sun, 28 Sep 2014 01:34:47 +0000
Subject: [docs] [issue22509] Website incorrect link
Message-ID: <1411868086.99.0.320325997195.issue22509@psf.upfronthosting.co.za>


New submission from Prof Oak:

On the python.org website, if you follow the link to PFS on the top, then click on the media tab (not any of the items in the dropdown menu), it takes you to this web page: https://www.python.org/inner/

It looks to be a sample page.

----------
assignee: docs at python
components: Documentation
messages: 227745
nosy: Prof.Oak, docs at python
priority: normal
severity: normal
status: open
title: Website incorrect link
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Sep 28 03:49:08 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Sep 2014 01:49:08 +0000
Subject: [docs] [issue20164] Undocumented KeyError from os.path.expanduser
In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za>
Message-ID: <1411868948.17.0.98501292219.issue20164@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think the doc should be considered correct and posixpath buggy.  The ntpath code checks for the existence of HOME and substitutes before returning the arg unchanged, as documented.

    if 'HOME' in os.environ:
        userhome = os.environ['HOME']
    elif 'USERPROFILE' in os.environ:
        userhome = os.environ['USERPROFILE']
    elif not 'HOMEPATH' in os.environ:
        return path
    <create userhome from HOMEDRIVE and HOMEPATH

--
The pwd doc already says " KeyError is raised if the entry asked for cannot be found.", so this is not an issue.

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +terry.reedy
stage: needs patch -> test needed

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

From report at bugs.python.org  Sun Sep 28 04:03:17 2014
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Sep 2014 02:03:17 +0000
Subject: [docs] [issue22509] Website incorrect link
In-Reply-To: <1411868086.99.0.320325997195.issue22509@psf.upfronthosting.co.za>
Message-ID: <1411869797.86.0.421908709091.issue22509@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  However, as noted on the python.org web site help page, https://www.python.org/about/help/, the place to report web site problems is here: https://github.com/python/pythondotorg/issues/

I've opened a new issue there on your behalf:

https://github.com/python/pythondotorg/issues/479

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep 29 16:24:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 29 Sep 2014 14:24:34 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <20140929142415.100039.26253@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 138f54622841 by R David Murray in branch '3.4':
#20135: FAQ entry for list mutation.  (See also 6375bf34fff6.)
https://hg.python.org/cpython/rev/138f54622841

New changeset 3d924bbfdcbc by R David Murray in branch 'default':
Merge: #20135: FAQ entry for list mutation.  (See also 90b07d422bd9.)
https://hg.python.org/cpython/rev/3d924bbfdcbc

New changeset 2b9db1fce82e by R David Murray in branch '2.7':
#20135: FAQ entry for list mutation.
https://hg.python.org/cpython/rev/2b9db1fce82e

----------

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

From report at bugs.python.org  Mon Sep 29 16:26:26 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Sep 2014 14:26:26 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1412000786.21.0.691431952298.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

I accidentally committed the patch early to 3.4/3.5.  I've now addressed Ezio's review comment per my suggestion on the review, and committed it to 2.7 as well.

Thanks everyone for your contributions.

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

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

From Clive.Darke at qa.com  Fri Sep 26 10:49:25 2014
From: Clive.Darke at qa.com (Darke, Clive)
Date: Fri, 26 Sep 2014 08:49:25 +0000
Subject: [docs] Downloading 3.4.1 documentation
Message-ID: <b03bf13d571446cbb8a21407c3dbcaa7@CSUKLEEX02.corp.group.local>

https://docs.python.org/3.4/download.html? shows 3.4.2rc1 documentation, not 3.4.1 doc.


How do I download 3.4.1 documentation?

Clive Darke
Principal Technologist - Open Source Programming
QA
Vale House Pynes Hill Exeter Devon EX2 5AZ

Email     clive.darke at qa.com
Web       www.qa.com

________________________________

QA works with organisations to transform performance through learning. We are dedicated to making our clients more successful through the provision of world-class training services.
To find out more visit www.qa.com

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

QA Ltd. Rath House, 55-65 Uxbridge Road, Slough, Berkshire,SL1 1SG.
QA Ltd. is a company registered in England with company registration number:2413137

Scanned by ICRITICAL

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

From ezio.melotti at gmail.com  Sun Sep 28 00:38:47 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sat, 27 Sep 2014 22:38:47 -0000
Subject: [docs] FAQ need list mutation answers (issue 20135)
Message-ID: <20140927223847.10096.12771@psf.upfronthosting.co.za>

LGTM except a couple of minor nits.


http://bugs.python.org/review/20135/diff/12949/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/20135/diff/12949/Doc/faq/programming.rst#newcode476
Doc/faq/programming.rst:476: object, accessing either one of them
accesses the modified value ``[10]``.
I don't like the term "access" too much, especially since it's repeated
twice.
Maybe the second instance could be replaced with "results in"?

http://bugs.python.org/review/20135/diff/12949/Doc/faq/programming.rst#newcode506
Doc/faq/programming.rst:506: has different behaviors with different
types:  the augmented assignment
There's a double space after the colon (not sure if intentional).

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

From rdmurray at bitdance.com  Sun Sep 28 01:14:21 2014
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Sat, 27 Sep 2014 23:14:21 -0000
Subject: [docs] FAQ need list mutation answers (issue 20135)
Message-ID: <20140927231421.10096.5683@psf.upfronthosting.co.za>


http://bugs.python.org/review/20135/diff/12949/Doc/faq/programming.rst
File Doc/faq/programming.rst (right):

http://bugs.python.org/review/20135/diff/12949/Doc/faq/programming.rst#newcode476
Doc/faq/programming.rst:476: object, accessing either one of them
accesses the modified value ``[10]``.
On 2014/09/28 00:38:47, ezio.melotti wrote:
> I don't like the term "access" too much, especially since it's
repeated twice.
> Maybe the second instance could be replaced with "results in"?

How about replacing the first one with "using either name accesses
the..."

I can't think of better word than access, since I already used 'refer'
in the first part of the sentence, and I want to emphasize that what you
*get* when you use the name is the object.

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

From report at bugs.python.org  Tue Sep 30 00:57:00 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 29 Sep 2014 22:57:00 +0000
Subject: [docs] [issue8350] Document lack of support for keyword arguments
	in C	functions
In-Reply-To: <1270764159.26.0.287104770145.issue8350@psf.upfronthosting.co.za>
Message-ID: <1412031420.09.0.236769702026.issue8350@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Has the Argument Clinic had an impact on this or is that a different kettle of fish?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Sep 30 00:58:16 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 29 Sep 2014 22:58:16 +0000
Subject: [docs] [issue10789] Lock.acquire documentation is misleading
In-Reply-To: <1293644478.45.0.40426107256.issue10789@psf.upfronthosting.co.za>
Message-ID: <1412031496.34.0.585730926647.issue10789@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Has the Argument Clinic had an impact on this or is that a different kettle of fish?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1

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

From report at bugs.python.org  Tue Sep 30 01:18:37 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 29 Sep 2014 23:18:37 +0000
Subject: [docs] [issue10938] Provide links to system specific strftime/ptime
	docs
In-Reply-To: <1295378779.48.0.643087757109.issue10938@psf.upfronthosting.co.za>
Message-ID: <1412032717.83.0.19073522864.issue10938@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Humberto could you provide a patch for this?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Sep 30 14:59:10 2014
From: report at bugs.python.org (anupama srinivas murthy)
Date: Tue, 30 Sep 2014 12:59:10 +0000
Subject: [docs] [issue22456] __base__ undocumented
In-Reply-To: <1411340067.19.0.0232279983568.issue22456@psf.upfronthosting.co.za>
Message-ID: <1412081950.7.0.478046895834.issue22456@psf.upfronthosting.co.za>


anupama srinivas murthy added the comment:

I have documented the function in object.rst file. I do not know the use of the function and have not mentioned that. My documentation is based on what I understood from the comments below and the explanation here:
http://code.activestate.com/lists/python-list/334282/

----------
keywords: +patch
nosy: +anupama.srinivas.murthy
Added file: http://bugs.python.org/file36760/function-documentation.patch

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

From report at bugs.python.org  Tue Sep 30 18:39:31 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Sep 2014 16:39:31 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412095171.57.0.167469844656.issue22525@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep 30 19:16:21 2014
From: report at bugs.python.org (Chris Adams)
Date: Tue, 30 Sep 2014 17:16:21 +0000
Subject: [docs] [issue20164] Undocumented KeyError from os.path.expanduser
In-Reply-To: <1389111327.1.0.12442170212.issue20164@psf.upfronthosting.co.za>
Message-ID: <1412097381.22.0.767121386578.issue20164@psf.upfronthosting.co.za>


Chris Adams added the comment:

I agree that making the code match the docs would be preferable ? an unexpected KeyError might be easier to track down that way but it'd still surprise most developers.

re:pwd docs, the formatting in https://hg.python.org/cpython/file/8e9df3414185/Doc/library/pwd.rst makes it easy to miss the KeyError note ? it's at the end of a paragraph after a table and since "entry" is a generic term it's possible to misread it as applying to fields within the record rather than the record itself. I think it would at least be worth adding a newline and perhaps explicitly noting that it applies to any function which returns a password database entry. 

Given that there are only two functions which it applies to, it might be best to simply add a note to each of them for people who use "pydoc pwd.getpwduid" or an IDE and don't see the module-level docs but that's getting a bit contrived.

----------

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

From report at bugs.python.org  Tue Sep 30 19:29:54 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2014 17:29:54 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412098194.27.0.896828717597.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I agree that the wording can be improved.  The term "expression" is used here loosely, but should be clarified.

"a+b" with numbers a, b must be handled in order to evaluate complex literals as in "1+1j".

Allowing operator expressions with literals is possible, but much more complex than the current implementation.  A simple implementation is not safe: you can induce basically unbounded CPU and memory usage with no effort (try "9**9**9" or "[None] * 9**9").

As for the usefulness, this function is useful to "read back" literal values and containers as stringified by repr().  This can for example be used for serialization in a format that is similar to but more powerful than JSON.

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

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

From report at bugs.python.org  Tue Sep 30 19:37:15 2014
From: report at bugs.python.org (Behdad Esfahbod)
Date: Tue, 30 Sep 2014 17:37:15 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412098635.39.0.140201793271.issue22525@psf.upfronthosting.co.za>


Behdad Esfahbod added the comment:

I think it should be made much more clear that this is not a blanket "safe eval() replacement".

Re complex literals, note that Python 2.7.x only implemented the binary plus operator if the second argument was complex.  This seems to have been relaxed in Python 3.

Regarding DoS attack with a safe eval(), I understand the concern, but that's still a huge improvement over security risks of eval().

----------

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

From report at bugs.python.org  Tue Sep 30 19:40:31 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2014 17:40:31 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412098831.08.0.82619239068.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The function is still called literal_eval(), not safe_eval().

I'm not saying a safe eval() isn't useful.  But an implementation that is only partly safe is not going to help anyone.

----------

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

From report at bugs.python.org  Tue Sep 30 19:44:25 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2014 17:44:25 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412099065.66.0.508005111777.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Attaching proposed doc change.

----------
keywords: +patch
Added file: http://bugs.python.org/file36764/ast_literal_eval_clarify.patch

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

From report at bugs.python.org  Tue Sep 30 19:47:32 2014
From: report at bugs.python.org (Behdad Esfahbod)
Date: Tue, 30 Sep 2014 17:47:32 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412099252.53.0.4739406377.issue22525@psf.upfronthosting.co.za>


Behdad Esfahbod added the comment:

Thanks.  In your proposed text:

+ Safely evaluate an expression node or a string containing a Python literal or container display.

I suggest changing it to "...containing a single Python literal or..."

Ie, adding "single".

----------

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

From report at bugs.python.org  Tue Sep 30 20:39:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 18:39:04 +0000
Subject: [docs] [issue8041] No documentation for
	Py_TPFLAGS_HAVE_STACKLESS_EXTENSION	or Py_TPFLAGS_HAVE_VERSION_TAG.
In-Reply-To: <1267544098.65.0.440493208051.issue8041@psf.upfronthosting.co.za>
Message-ID: <1412102344.0.0.072558211615.issue8041@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Daniel could you supply a patch for this?

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

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

From report at bugs.python.org  Tue Sep 30 20:49:23 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 18:49:23 +0000
Subject: [docs] [issue18675] Daemon Threads can seg fault
In-Reply-To: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za>
Message-ID: <1412102963.45.0.689745242911.issue18675@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Thomas can you provide a patch for this issue?

----------
nosy: +BreamoreBoy
versions:  -Python 2.6

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

From report at bugs.python.org  Tue Sep 30 20:56:36 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 18:56:36 +0000
Subject: [docs] [issue18729] In unittest.TestLoader.discover doc select the
	name of	load_tests function
In-Reply-To: <1376418287.73.0.835584535115.issue18729@psf.upfronthosting.co.za>
Message-ID: <1412103396.47.0.703215771865.issue18729@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The patch simply adds backticks markup around load_tests.

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

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

From report at bugs.python.org  Tue Sep 30 21:01:41 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Sep 2014 19:01:41 +0000
Subject: [docs] [issue22527] Documentation warnings
Message-ID: <1412103701.09.0.111850399137.issue22527@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

I get the following warnings when building the doc:

                                                                              
$ make html
sphinx-build -b html -d build/doctrees -D latex_paper_size=  . build/html 
Running Sphinx v1.2.1
loading pickled environment... done
building [html]: targets for 65 source files that are out of date
updating environment: 1 added, 66 changed, 0 removed
reading sources... [100%] whatsnew/changelog                                           
/home/antoine/cpython/default/Doc/library/compileall.rst:23: WARNING: Malformed option description u'directory ...', should look like "-opt args", "--opt args" or "/opt args"
/home/antoine/cpython/default/Doc/library/compileall.rst:23: WARNING: Malformed option description u'file ...', should look like "-opt args", "--opt args" or "/opt args"
/home/antoine/cpython/default/Doc/library/json.rst:593: WARNING: Malformed option description u'infile', should look like "-opt args", "--opt args" or "/opt args"
/home/antoine/cpython/default/Doc/library/json.rst:611: WARNING: Malformed option description u'outfile', should look like "-opt args", "--opt args" or "/opt args"
/home/antoine/cpython/default/Doc/tutorial/appendix.rst:69: WARNING: duplicate label tut-startup, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst
/home/antoine/cpython/default/Doc/tutorial/appendix.rst:16: WARNING: duplicate label tut-error, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst
/home/antoine/cpython/default/Doc/tutorial/appendix.rst:102: WARNING: duplicate label tut-customize, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst
/home/antoine/cpython/default/Doc/tutorial/appendix.rst:38: WARNING: duplicate label tut-scripts, other instance in /home/antoine/cpython/default/Doc/tutorial/interpreter.rst
/home/antoine/cpython/default/Doc/using/cmdline.rst:167: WARNING: Malformed option description u'-?', should look like "-opt args", "--opt args" or "/opt args"

----------
assignee: docs at python
components: Documentation
messages: 227978
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: Documentation warnings
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Sep 30 21:21:24 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2014 19:21:24 +0000
Subject: [docs] [issue22527] Documentation warnings
In-Reply-To: <1412103701.09.0.111850399137.issue22527@psf.upfronthosting.co.za>
Message-ID: <1412104884.91.0.679941290971.issue22527@psf.upfronthosting.co.za>


Georg Brandl added the comment:

These are a bug in Sphinx 1.2.1 and fixed in 1.2.2.

----------
nosy: +georg.brandl
resolution:  -> third party
status: open -> closed

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

From report at bugs.python.org  Tue Sep 30 21:27:00 2014
From: report at bugs.python.org (Thomas Guettler)
Date: Tue, 30 Sep 2014 19:27:00 +0000
Subject: [docs] [issue18675] Daemon Threads can seg fault
In-Reply-To: <1375867396.76.0.697227657582.issue18675@psf.upfronthosting.co.za>
Message-ID: <1412105220.24.0.219918488339.issue18675@psf.upfronthosting.co.za>


Thomas Guettler added the comment:

What kind of patch do you want? Documentation patch or fixing the bug in the interpreter?

I am not a native speaker, that's why I avoid documentation patches.

For me, the issue is solved. It is documented in stackoverflow and here.

Since Python2 will be gone sooner or later, I don't want to invest hours into fixing this at interpreter level.

Should I close the issue?

----------

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

From report at bugs.python.org  Tue Sep 30 21:29:23 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 19:29:23 +0000
Subject: [docs] [issue19071] Documentation on what self is for module-level
	functions	is misleading/wrong.
In-Reply-To: <1379849996.18.0.35390897499.issue19071@psf.upfronthosting.co.za>
Message-ID: <1412105363.29.0.0467227373091.issue19071@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

At this stage is this something that we'd want to back port or fix in 2.7 or would a doc change suffice?

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

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

From report at bugs.python.org  Tue Sep 30 21:33:20 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Sep 2014 19:33:20 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412105600.02.0.956038671831.issue22525@psf.upfronthosting.co.za>


R. David Murray added the comment:

It should probably also say "or a container display containing only literals".  (That's a lot of "contain" :)

(I had the same confusion the first time I read these docs, BTW).

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

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

From report at bugs.python.org  Tue Sep 30 21:40:24 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Sep 2014 19:40:24 +0000
Subject: [docs] [issue22525] ast.literal_eval() doesn't do what the
	documentation says
In-Reply-To: <1412089039.94.0.626035759284.issue22525@psf.upfronthosting.co.za>
Message-ID: <1412106024.27.0.68880969701.issue22525@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sure, feel free to reword.

An example or two might also be helpful.

----------

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

From report at bugs.python.org  Tue Sep 30 21:45:40 2014
From: report at bugs.python.org (Friedrich Spee von Langenfeld)
Date: Tue, 30 Sep 2014 19:45:40 +0000
Subject: [docs] [issue22528] Missing hint to source code
Message-ID: <1412106340.24.0.431957287455.issue22528@psf.upfronthosting.co.za>


New submission from Friedrich Spee von Langenfeld:

Nearly every module entry in the documentation has a headline with the pattern <module name -- description>, followed (in the second line) by <Source code: directory>. In the entry concerning pdb (https://docs.python.org/3/library/pdb.html), there is no hint where the source code is located. This is especially annoying, because the user of the Python Debugger is explicitely invented to extend the module?s capabilities ("The debugger is extensible ? it is actually defined as the class Pdb. This is currently undocumented but easily understood by reading the source."). A link to the source code should be added as the second line. The same thing should done for symtable, compileall and perhaps some other modules, which I haven?t checked by now.

----------
assignee: docs at python
components: Documentation
messages: 227989
nosy: Friedrich.Spee.von.Langenfeld, docs at python
priority: normal
severity: normal
status: open
title: Missing hint to source code

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

From report at bugs.python.org  Tue Sep 30 22:02:39 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 30 Sep 2014 20:02:39 +0000
Subject: [docs] [issue22528] Missing hint to source code
In-Reply-To: <1412106340.24.0.431957287455.issue22528@psf.upfronthosting.co.za>
Message-ID: <20140930200231.23199.30926@mail.hg.python.org>


Roundup Robot added the comment:

New changeset 04f82abdfb6d by Benjamin Peterson in branch '3.4':
add link to pdb source (closes #22528)
https://hg.python.org/cpython/rev/04f82abdfb6d

New changeset d49b9c8ee8ed by Benjamin Peterson in branch '2.7':
add link to pdb source (closes #22528)
https://hg.python.org/cpython/rev/d49b9c8ee8ed

New changeset 26b767fec7e2 by Benjamin Peterson in branch 'default':
merge 3.4 (#22528)
https://hg.python.org/cpython/rev/26b767fec7e2

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

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

From report at bugs.python.org  Tue Sep 30 23:12:54 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 21:12:54 +0000
Subject: [docs] [issue7436] Define 'object with assignable attributes'
In-Reply-To: <1259961781.03.0.33355289278.issue7436@psf.upfronthosting.co.za>
Message-ID: <1412111574.91.0.769182101504.issue7436@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Terry can you pick this one up?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Sep 30 23:18:58 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 30 Sep 2014 21:18:58 +0000
Subject: [docs] [issue11023] pep 227 missing text
In-Reply-To: <1296134235.25.0.738218358402.issue11023@psf.upfronthosting.co.za>
Message-ID: <1412111938.11.0.863417969876.issue11023@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

PEP 227 (Not 277 as wrongly quoted in one place) is about Statically Nested Scopes.  There are several XXX place holders in the current doc.  For all I know it would be possible to simply remove all of them, but who is best placed to give a definitive answer?

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

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

From spumer-tm at yandex.ru  Tue Sep 30 08:00:40 2014
From: spumer-tm at yandex.ru (spumer)
Date: Tue, 30 Sep 2014 12:00:40 +0600
Subject: [docs] Typo in BrokenProcessPool import
Message-ID: <832791412056840@web4o.yandex.ru>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140930/041511c4/attachment-0001.html>

From ion.freeman at baml.com  Tue Sep 30 18:56:40 2014
From: ion.freeman at baml.com (Freeman, Ion)
Date: Tue, 30 Sep 2014 16:56:40 +0000
Subject: [docs] Version list in 2.6.9 documentation
Message-ID: <46A5D27F9843904FA541A40D85DC790A74A7FDAD@smtp_mail.bankofamerica.com>

This is maybe not a core doc bug, but the 2.6.9 documentation is coming up on a year old, and has an outdated view of later versions.

>From the welcome page<https://docs.python.org/2.6/>:
Docs for other versions
*       Python 2.7 (stable)<http://docs.python.org/2.7/>
*       Python 3.1 (stable)<http://docs.python.org/3.1/>
*       Python 3.2 (in development)<http://docs.python.org/dev/py3k/>
*       Old versions<http://www.python.org/doc/versions/>

Python 3.2 is no longer in development. That should probably look more like

Docs for other versions
*       Python 2.7 (stable)<http://docs.python.org/2.7/>
*       Python 3.4 (stable)<http://docs.python.org/3.1/>
*       Python 3.5 (in development)<http://docs.python.org/dev/py3k/>
*       Old versions<http://www.python.org/doc/versions/>


Ion Freeman
ion.freeman at baml.com<mailto:ion.freeman at baml.com>
NY3-004-07-01
212 449 0987
Upgrade to MSIE 11<http://productbuzz.bankofamerica.com/Lists/Product%20Manager%20Announcements/DispForm.aspx?ID=467&Source=http%3A%2F%2Fproductbuzz%2Ebankofamerica%2Ecom%2FPages%2FProducts%2FInternetExplorer%2Easpx>
One Facility<https://fedsso.bankofamerica.com/idp/startSSO.ping?PartnerSpId=touchcom>



----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140930/84913bcf/attachment-0001.html>