From report at bugs.python.org  Mon Jun  1 01:11:35 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2015 23:11:35 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1433113895.67.0.914767386937.issue24323@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun  1 21:05:08 2015
From: report at bugs.python.org (July Tikhonov)
Date: Mon, 01 Jun 2015 19:05:08 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
	references	"identifiers"
Message-ID: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>


New submission from July Tikhonov:

Documentation of Template says:

$identifier names a substitution placeholder matching a mapping key of "identifier". By default, "identifier" must spell a Python identifier. The first non-identifier character after the $ character terminates this placeholder specification.


While it was true when these lines were written, Python 3 has greatly extended identifier character set, and it no longer matches the set of characters used by Template:

>>> Template('$foo123??').substitute(foo=1, foo123=2, foo123??=3)
'2??'

I propose clarifying documentation.

Actually extending character set is backward-incompatible, although it won't be if restricted to "${identifier}" syntax.

----------
assignee: docs at python
components: Documentation
messages: 244607
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: string.Template documentation incorrectly references "identifiers"
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  1 22:18:45 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jun 2015 20:18:45 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
	references	"identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1433189925.18.0.207308252517.issue24351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun  1 23:25:14 2015
From: report at bugs.python.org (Brandon Milam)
Date: Mon, 01 Jun 2015 21:25:14 +0000
Subject: [docs] [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1433193914.07.0.672204317652.issue12020@psf.upfronthosting.co.za>


Brandon Milam added the comment:

I've been looking over the issue and the error is just raised by the stdout change not the stderr change (when the stdout line is commented out in the setAutoFlush function no error is raised). The flush method doesn't seem to be required as Serhiy pointed out since the script still is able to run. This is the cause for the error, however and I think that the required subset of methods for stdout objects to avoid errors could be clarified in the documentation. This documentation addition I think would be best under the sys.stdout info rather than under io.TextIOBase since the error can be raised without going through this class at all like in the original post.

I would like to add this documentation under sys.stdout as required subset of methods that must be defined and was wondering if there were any other methods than flush() that would need to be defined.

----------
nosy: +jbmilam

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

From report at bugs.python.org  Tue Jun  2 00:21:33 2015
From: report at bugs.python.org (Graham Oliver)
Date: Mon, 01 Jun 2015 22:21:33 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
Message-ID: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>


New submission from Graham Oliver:

See my question here
https://groups.google.com/forum/#!topic/comp.lang.python/BUmyc_hzAsA
In particular Carl Meyer's response
https://groups.google.com/d/msg/comp.lang.python/BUmyc_hzAsA/-cT-N-g_LL4J

I am not sure what is possible with venv but I would suggest that the statement 'allowing creation of environments with various Python versions' needs to be clarified and / or altered.

Thanks
Graham

----------
assignee: docs at python
components: Documentation
messages: 244618
nosy: Graham.Oliver, docs at python
priority: normal
severity: normal
status: open
title: venv documentation incorrect / misleading
versions: Python 3.3

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

From report at bugs.python.org  Tue Jun  2 00:25:07 2015
From: report at bugs.python.org (Graham Oliver)
Date: Mon, 01 Jun 2015 22:25:07 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433197507.58.0.57645517095.issue24356@psf.upfronthosting.co.za>


Graham Oliver added the comment:

See also
https://groups.google.com/d/msg/comp.lang.python/BUmyc_hzAsA/Nx5QgT1gzYEJ

----------

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

From report at bugs.python.org  Tue Jun  2 02:59:40 2015
From: report at bugs.python.org (Paul Marks)
Date: Tue, 02 Jun 2015 00:59:40 +0000
Subject: [docs] [issue24357] www.python.org lost IPv6 connectivity
Message-ID: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>


New submission from Paul Marks:

Python's web servers were formerly reachable from IPv6 clients, as evidenced by this example code for socket.getaddrinfo():

https://docs.python.org/3/library/socket.html#socket.getaddrinfo

But today, www.python.org is IPv4-only:

>>> import socket
>>> socket.getaddrinfo("www.python.org", 80, proto=socket.IPPROTO_TCP)
[(<AddressFamily.AF_INET: 2>, <SocketType.SOCK_STREAM: 1>, 6, '', ('23.235.40.223', 80))]

Please either restore IPv6 connectivity to www.python.org, or accept the shame and defeat of pointing the documentation to someone else's domain.

----------
assignee: docs at python
components: Documentation
messages: 244625
nosy: Paul Marks, docs at python
priority: normal
severity: normal
status: open
title: www.python.org lost IPv6 connectivity

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

From report at bugs.python.org  Tue Jun  2 03:16:45 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Jun 2015 01:16:45 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show
	IPv6	connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <1433207805.83.0.728763385933.issue24357@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report. According to the PSF Infrastructure Team, www.python.org currently does not support IPv6 because the Content Delivery Network that we now use does not support it yet.  One Python URL that does support IPv6:

>>> socket.getaddrinfo("hg.python.org", 80, proto=socket.IPPROTO_TCP)
[(<AddressFamily.AF_INET6: 10>, <SocketType.SOCK_STREAM: 1>, 6, '', ('2001:4802:7901:0:e60a:1375:0:4', 80, 0, 0)), (<AddressFamily.AF_INET: 2>, <SocketType.SOCK_STREAM: 1>, 6, '', ('104.130.43.97', 80))]

----------
keywords: +easy
nosy: +ned.deily
stage:  -> needs patch
title: www.python.org lost IPv6 connectivity -> Change socket.getaddrinfo example to show IPv6 connectivity
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  2 03:18:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2015 01:18:15 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433207895.56.0.15691890375.issue24356@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  We don't in general mention 2.7 in the python3 docs (in fact I found only one mention of it, in the logging package docs).  I suppose this might be confusing enough to warrant it.  But it might be better to rewrite that sentence to make it clear that the python binary you get in your virtual environment is the one that the venv command comes from.  That should make it pretty clear you can't use it with 2.7, since 2.7 doesn't include venv.

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

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

From report at bugs.python.org  Tue Jun  2 03:58:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jun 2015 01:58:02 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show
	IPv6	connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <20150602015759.4340.72639@psf.io>


Roundup Robot added the comment:

New changeset b461d900fdb5 by Ned Deily in branch '3.4':
Issue #24357: Change host in socket.getaddrinfo example to one that
https://hg.python.org/cpython/rev/b461d900fdb5

New changeset 22b77f859521 by Ned Deily in branch '3.5':
Issue #24357: merge from 3.4
https://hg.python.org/cpython/rev/22b77f859521

New changeset 7c7b1fffafdf by Ned Deily in branch 'default':
Issue #24357: merge from 3.5
https://hg.python.org/cpython/rev/7c7b1fffafdf

New changeset 30da21d2fa4f by Ned Deily in branch '2.7':
Issue #24357: Change host in socket.getaddrinfo example to one that
https://hg.python.org/cpython/rev/30da21d2fa4f

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

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

From report at bugs.python.org  Tue Jun  2 04:06:51 2015
From: report at bugs.python.org (Graham Oliver)
Date: Tue, 02 Jun 2015 02:06:51 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433210811.41.0.644784154893.issue24356@psf.upfronthosting.co.za>


Graham Oliver added the comment:

ok current version
Each virtual environment has its own Python binary (allowing creation of environments with various Python versions) and can have its own independent set of installed Python packages in its site directories.

Suggested Alternative
Each virtual environment has its own isolated Python binary (which matches the version used to create it) and can have its own independent set of installed Python packages in its site directories.

----------

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

From report at bugs.python.org  Tue Jun  2 04:24:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jun 2015 02:24:55 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show IPv6
 connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <20150602022451.91795.3440@psf.io>


Roundup Robot added the comment:

New changeset acf4dbd99d11 by Ned Deily in branch '3.4':
Issue #24357: fix typo
https://hg.python.org/cpython/rev/acf4dbd99d11

New changeset fcb415e5b40b by Ned Deily in branch '3.5':
Issue #24357: merge from 3.4
https://hg.python.org/cpython/rev/fcb415e5b40b

New changeset 74ff057c2c83 by Ned Deily in branch 'default':
Issue #24357: merge from 3.5
https://hg.python.org/cpython/rev/74ff057c2c83

----------

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

From report at bugs.python.org  Tue Jun  2 04:30:31 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 02 Jun 2015 02:30:31 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433212231.71.0.77577503315.issue24356@psf.upfronthosting.co.za>


Carol Willing added the comment:

Current version
Each virtual environment has its own Python binary (allowing creation of environments with various Python versions) and can have its own independent set of installed Python packages in its site directories.

Another suggested revision
Since its introduction in Python 3.3, venv may be used to create a virtual environment with its own Python binary and optionally its own independent set of installed Python packages in its site directories. Multiple virtual environments permit various Python versions to exist on a system.

David and Graham,
Perhaps moving the "see also" box (see also Python Packaging User Guide: Creating and using virtual environments) closer to the top, perhaps under the pep reference, would be helpful for the user.

Virtual environments are confusing for those new to Python since there are many "env"s such as venv, pyvenv, virtualenv, virtualenvwrapper, pyenv tool, and myenv used in many examples.

Carol

----------
nosy: +willingc

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

From report at bugs.python.org  Tue Jun  2 04:37:47 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2015 02:37:47 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433212667.71.0.646167931469.issue24356@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think Graham's formulation provides more information.  venv already has a "new in python 3.3" at the top (just before that sentence), so putting that in the text feels redundant.

On the other hand, the current placement of the 'see also' box looks odd, unless the packaging authority doesn't mention virtual environments on Windows (and if it doesn't, it should!).  I agree that moving that up to just after the PEP reference is probably a good idea.

----------

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

From report at bugs.python.org  Tue Jun  2 04:39:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jun 2015 02:39:15 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show IPv6
 connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <20150602023912.83489.98264@psf.io>


Roundup Robot added the comment:

New changeset fb12d742b70c by Ned Deily in branch '3.4':
Issue #24357: fix real typo
https://hg.python.org/cpython/rev/fb12d742b70c

New changeset 5bfa78bf0607 by Ned Deily in branch '3.5':
Issue #24357: merge from 3.4
https://hg.python.org/cpython/rev/5bfa78bf0607

New changeset 421847aa0b22 by Ned Deily in branch 'default':
Issue #24357: merge from 3.5
https://hg.python.org/cpython/rev/421847aa0b22

----------

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

From report at bugs.python.org  Tue Jun  2 04:41:15 2015
From: report at bugs.python.org (Carol Willing)
Date: Tue, 02 Jun 2015 02:41:15 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433212875.82.0.321356770013.issue24356@psf.upfronthosting.co.za>


Carol Willing added the comment:

David,

Sounds good to me. I'll submit a patch with Graham's suggested text and move the See also box up right after the PEP reference.

Thanks,
Carol

----------

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

From report at bugs.python.org  Tue Jun  2 04:45:04 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Jun 2015 02:45:04 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show IPv6
 connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <1433213104.19.0.915096913929.issue24357@psf.upfronthosting.co.za>


Ned Deily added the comment:

We decided to use google.com as an example instead.  (And I tested the tracker upgrade by fixing the wrong initial typo that I had made.)

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

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

From report at bugs.python.org  Tue Jun  2 06:22:16 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 02 Jun 2015 04:22:16 +0000
Subject: [docs] [issue24357] Change socket.getaddrinfo example to show IPv6
 connectivity
In-Reply-To: <1433206780.04.0.828660872449.issue24357@psf.upfronthosting.co.za>
Message-ID: <20150602042213.91787.33670@psf.io>


Roundup Robot added the comment:

New changeset 5ae3418fe63e by Ned Deily in branch '2.7':
Issue #24357: use example.org instead
https://hg.python.org/cpython/rev/5ae3418fe63e

New changeset dbf3aa36bea7 by Ned Deily in branch '3.4':
Issue #24357: use example.org instead
https://hg.python.org/cpython/rev/dbf3aa36bea7

New changeset d751900d0406 by Ned Deily in branch '3.5':
Issue #24357: merge from 3.4
https://hg.python.org/cpython/rev/d751900d0406

New changeset e09cefe1e5b8 by Ned Deily in branch 'default':
Issue #24357: merge from 3.5
https://hg.python.org/cpython/rev/e09cefe1e5b8

----------

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

From report at bugs.python.org  Tue Jun  2 06:59:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 02 Jun 2015 04:59:51 +0000
Subject: [docs] [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1433221191.4.0.187395834887.issue12020@psf.upfronthosting.co.za>


Martin Panter added the comment:

I wouldn?t expect to see a message for stderr because there is nowhere else to send the message. However with my patch for Issue 5319, at least we get a non-zero exit status.

Brandon: I agree this should be under sys.stdin/out/err; I wasn?t saying to put it under the io.TextIOBase documentation. What I meant was one option would be to refer to that class as a duck-typing API. Say something like: ?sys.stdout [etc] may be replaced with other objects, as long as they implement [the write-only parts, etc of] the TextIOBase API [optionally ?buffer? etc]?. Exact details to be determined.

----------

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

From lists at studiosola.com  Tue Jun  2 08:01:21 2015
From: lists at studiosola.com (Kevin LaTona)
Date: Mon, 1 Jun 2015 23:01:21 -0700
Subject: [docs] Mac -- Python 2.7.10 still is not using newer OpenSSL on new
	installs
Message-ID: <F4136102-5108-499B-BD35-48ADFC148ACC@studiosola.com>



The current shipping Mac package for Python 2.7.10 installed on a OS X 10.8.5 machine currently still is reverting back and using Apple's older OpenSSL.

I read in the readm.txt file that this problem was patched to load newer version of OpenSSL.

I've been trying to compile source and all suggestions I have been able to find on the net of how to add newer openSSL to Python 2.7/x have failed as well.

I can get Python to compile but have not been able to link that to newer OpenSSL.

I am not sure if the new install is not overwriting some older file or the new linking is not working on the OS X version.

Please let me know what I can do to fix this?

Thanks
-Kevin


Last login: Mon Jun  1 21:56:59 on ttys000
$ python

Python 2.7.10 (v2.7.10:15c95b7d81dc, May 23 2015, 09:33:12) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin


>>> import ssl
>>> print (ssl.OPENSSL_VERSION)
OpenSSL 0.9.8y 5 Feb 2013
>>> 



From tiffanysaran at yahoo.com  Mon Jun  1 23:10:26 2015
From: tiffanysaran at yahoo.com (Tiffany Sara)
Date: Mon, 1 Jun 2015 21:10:26 +0000 (UTC)
Subject: [docs] Can't open IDLE (Python GUI) on Windows 7
Message-ID: <150549703.3420280.1433193026834.JavaMail.yahoo@mail.yahoo.com>

Hi,
I downloaded Python 2.7 today on my Windows 7. I am able to open python via command line, but I can't open IDLE Python GUI at all. Whenever I double-click on the program nothing opens. I tried looking online for suggestions but I couldn't find anything applicable to Windows 7 64 bit. I am very new to coding, so I don't know how to solve this problem. Any help would be great.
Thanks,
Tiffany Saran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150601/682fadaf/attachment.html>

From p.andrefreitas at gmail.com  Tue Jun  2 16:12:17 2015
From: p.andrefreitas at gmail.com (=?UTF-8?Q?Andr=C3=A9_Freitas?=)
Date: Tue, 02 Jun 2015 14:12:17 +0000
Subject: [docs] Can't open IDLE (Python GUI) on Windows 7
In-Reply-To: <150549703.3420280.1433193026834.JavaMail.yahoo@mail.yahoo.com>
References: <150549703.3420280.1433193026834.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAMkX=YVk9r5EfJz0utEmTk6cmV_XVGPNwJbVPzezx3x4cMEHqg@mail.gmail.com>

Hi Tiffany,
This kind of questions are not for the docs mailing list :)

Anyway, I can help you: if you are having problems with the IDLE you can
use the Atom Editor <https://atom.io/> or an IDE like Pycharm Community
Edition <https://www.jetbrains.com/pycharm/>.

Python is the best language to start learning about programming so you have
a lot of resources online to (just Google it):

   - Python Course at Code Academy
   <http://www.codecademy.com/pt/tracks/python>
   - Python Documentation <https://docs.python.org/3/>
   - Youtube <https://www.youtube.com/results?search_query=python>

I recommend you using Python 3.x instead of 2.x due a lot of improvements.

Good luck and may the force be with you.

-- Andr? Freitas

Em ter, 2 de jun de 2015 ?s 08:20, Tiffany Sara via docs <docs at python.org>
escreveu:

> Hi,
>
> I downloaded Python 2.7 today on my Windows 7. I am able to open python
> via command line, but I can't open IDLE Python GUI at all. Whenever I
> double-click on the program nothing opens. I tried looking online for
> suggestions but I couldn't find anything applicable to Windows 7 64 bit. I
> am very new to coding, so I don't know how to solve this problem. Any help
> would be great.
>
> Thanks,
>
> Tiffany Saran
> _______________________________________________
> 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/20150602/9bb4a24e/attachment.html>

From report at bugs.python.org  Tue Jun  2 21:33:54 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Jun 2015 19:33:54 +0000
Subject: [docs] [issue22725] improve documentation for enumerate() (built-in
	function)
In-Reply-To: <1414208636.74.0.462392063973.issue22725@psf.upfronthosting.co.za>
Message-ID: <1433273634.64.0.618633661969.issue22725@psf.upfronthosting.co.za>


R. David Murray added the comment:

Per Raymond's last message, closing this as rejected.

----------
assignee: rhettinger -> docs at python
stage: needs patch -> resolved

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

From guido at python.org  Wed Jun  3 02:28:22 2015
From: guido at python.org (guido at python.org)
Date: Wed, 03 Jun 2015 00:28:22 -0000
Subject: [docs] PEP 484 docs (issue 24272)
Message-ID: <20150603002822.15287.34661@psf.upfronthosting.co.za>

Thank you again! I have made a full pass this time. I should mention
that I'm going on a long vacation starting this weekend so I may not be
available to do another round of review. But I may be able to commit
this if you address (most of) my feedback by Friday.


http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode31
Doc/library/typing.rst:31: Url = str
Maybe use a more complex example, e.g.

  Vector = List[float]

? (It's okay if that's a forward reference to syntax that hasn't been
explained yet.)

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode33
Doc/library/typing.rst:33: Callable
Can you also document the special form Callable[..., <type>]? Here "..."
is a literal ellipsis, and the meaning is "don't type-check the args"
(it's described in the PEP).

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode59
Doc/library/typing.rst:59: from typing import Mapping, Set
Unfortunately we renamed the ABC Set to AbstractSet, and Set refers to
(the generic variant of) the concrete type 'set'. Maybe change the
example to use Sequence, which is an ABC?  (To clarify, the example with
Set[Employee] works, but it isn't using an ABC.)

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode80
Doc/library/typing.rst:80: A user-defined class can be defined as a
generic.
"a generic" -> either "generic" or "a generic class".

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode84
Doc/library/typing.rst:84: from typing import TypeVar, Generic
The example should also include "from logging import Logger".

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode103
Doc/library/typing.rst:103: self.logger.info('{}: {}'.format(self.name
message))
Missing comma after self.name.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode118
Doc/library/typing.rst:118: be constrained::
The mention of "constrained" here dangles a bit -- there's no example
immediately following of a constrained type variable.  (I think it's
different in the PEP.)

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode166
Doc/library/typing.rst:166: When the type of a value is object, the type
checker will reject almost all
I'd use `object`.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode173
Doc/library/typing.rst:173: Version and platform checking
Drop this section.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode196
Doc/library/typing.rst:196: def foo(x: AnyStr, y: AnyStr = ...) ->
AnyStr: ...
There is no definition of AnyStr, so this dangles a bit.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode204
Doc/library/typing.rst:204: .. class:: Any(Final, metaclass=AnyMeta,
_root=True)
Don't mention the base classes. This also applies below.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode208
Doc/library/typing.rst:208: * Any object is an instance of Any.
I'd use `Any` for all places where the word "Any" refers to the special
object `Any`.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode229
Doc/library/typing.rst:229: '''Return a list containing n references to
x.'''
I strongly prefer """ for docstrings.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode237
Doc/library/typing.rst:237: of (str, str) -> str and (bytes, bytes) ->
bytes.  Also note
You're slacking on the backticks here. :-)

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode242
Doc/library/typing.rst:242: issubclass(C, T) is true for any class C,
and issubclass(str, A)
Actually, issubclass() involving type variables or other special objects
will probably start failing too in one of the next betas. Perhaps it's
better to say something like "you shouldn't use these".

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode250
Doc/library/typing.rst:250: Type variables can be introspected. e.g.::
I prefer not to document this for now.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode258
Doc/library/typing.rst:258: .. class:: Union(Final, metaclass=UnionMeta,
_root=True)
Again, please don't list the base classes. (Same for every class below).

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode266
Doc/library/typing.rst:266: * None as an argument is a special case and
is replaced by
This is not unique to union -- this applies everywhere. So probably move
it up ahead.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode285
Doc/library/typing.rst:285: * When two arguments have a subclass
relationship, the least
We're on thin ice with this bullet. I'd like to drop it. (The PEP
doesn't say this.)

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode294
Doc/library/typing.rst:294: * Corollary: if Any is present it is the
sole survivor, e.g.::
I'd remove "Corollary:" -- this is just another rule.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode298
Doc/library/typing.rst:298: * Similar for object::
I'd drop this too.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode302
Doc/library/typing.rst:302: * To cut a tie: `Union[object, Any] ==
Union[Any, object] == Any`.
Drop this too.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode318
Doc/library/typing.rst:318: Tuple type; Tuple[X, Y] is the cross-product
type of X and Y.
I'd drop the "cross-product" concept -- it's very type-theoretic. I'd
just say this is the type of a tuple of two items with the first item of
type X and the second of type Y.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode324
Doc/library/typing.rst:324: To specify a variable-length tuple of
homogeneous type, use `Sequence[T]`.
The PEP actually also supports Tuple[t, ...]. (And I'd use a lowercase t
because it doesn't have to be a type variable. Maybe use Tuple[int, ...]
as an example.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode335
Doc/library/typing.rst:335: such function types are rarely used as
callback types.
But do add Callable[..., t] as a way to spell callable of any args
returning t.

Also note that plain Callable is equivalent to Callable[..., Any].

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode337
Doc/library/typing.rst:337: .. class:: Generic(metaclass=GenericMeta)
This looks (mostly?) redundant with the earlier discussion of Generic.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode352
Doc/library/typing.rst:352: def lookup_name(mapping: Mapping, key: KT,
default: VT) -> VT:
Actually we changed our mind about this and you must write Mapping[KT,
VT] here (essentially making this the same as the next example).

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode445
Doc/library/typing.rst:445: .. function:: get_type_hints(obj,
globalns=None, localns=None)
I prefer not to document globalns/localns at this time.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode453
Doc/library/typing.rst:453: .. warning::
Just drop this warning.

http://bugs.python.org/review/24272/diff/14930/Doc/library/typing.rst#newcode469
Doc/library/typing.rst:469: .. function:: overload(func)
Consider leaving this out.

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

From report at bugs.python.org  Wed Jun  3 15:10:46 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Jun 2015 13:10:46 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
Message-ID: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

The documentation for ssl.wrap_socket()'s ssl_version parameter says "ssl_version={see docs}". But as far as I can tell, there's no reason not to document it as PROTOCOL_SSLv23, since that's what it actually is in the code.

My use case is that I'm producing a utility function for an RFC-5804 Manage Sieve client, which implements starttls(). I want to expose most of wrap_sockets()'s parameters, and pass them in to ssl.wrap_socket() itself. In order to do so, I need to specify the default values to match wrap_socket(). But ssl_version's default isn't documented.

Is the reason to allow us to change the default in a bug fix release? If that's the case, I suggest creating a sentinel value, like ssl.DEFAULT_PROTOCOL, and have that be the documented default. Then I could declare my parameter as defaulting to ssl.DEFAULT_PROTOCOL, pass it in to ssl.wrap_socket(), and have it use the "current" default.

If that's a desirable solution, I'll happily write a patch. If so, it would just apply to 3.6, but if we just want to document the actual value of ssl_version, then it would apply to the versions I've selected.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 244742
nosy: docs at python, eric.smith
priority: low
severity: normal
status: open
title: Documentation for ssl.wrap_socket's ssl_version parameter is odd
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From vadmium+py at gmail.com  Wed Jun  3 15:20:30 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 03 Jun 2015 13:20:30 -0000
Subject: [docs] xml.etree.ElementTree.Element.text does not conform to
 the documentation (issue 24079)
Message-ID: <20150603132030.5493.52713@psf.upfronthosting.co.za>


https://bugs.python.org/review/24079/diff/14986/Doc/library/xml.etree.elementtree.rst
File Doc/library/xml.etree.elementtree.rst (right):

https://bugs.python.org/review/24079/diff/14986/Doc/library/xml.etree.elementtree.rst#newcode657
Doc/library/xml.etree.elementtree.rst:657: and the next tag.  The *tail*
attribute holds any text between the
On 2015/05/30 07:35:22, scoder wrote:
> Not strictly true, e.g. "<tag />abc<next-tag/>" - is "abc" in text or
tail here?

Tail only, being equivalent to <tag></tag>abc<next-tag/>. Hopefully this
is also illustrated by the <d/> tag in J?r?me?s example.

> Also, I think the usual wording is "opening" and "closing" tag.

Actually, I?m changing it to use ?start tag?, but keeping ?end tag?.
These terms are used in other parts of the page, XML specifications,
etc.

https://bugs.python.org/review/24079/

From report at bugs.python.org  Wed Jun  3 15:37:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 03 Jun 2015 13:37:14 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
 conform to the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1433338634.12.0.850483287873.issue24079@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay, here is a version with most of the wording reverted to J?r?me?s suggestion. I only left my itertext() example, and the grouping of text and tail together. If there are any more bits that are incorrect or unclear please identify them.

----------
Added file: http://bugs.python.org/file39606/etree-text.v2.patch

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

From report at bugs.python.org  Wed Jun  3 15:48:18 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Jun 2015 13:48:18 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
Message-ID: <1433339298.69.0.231472669954.issue24372@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It occurs to me that None would also be a fine default, and probably the smarter choice.

Then wrap_socket could say:
if ssl_version is None:
  ssl_version = PROTOCOL_SSLv23

And we could change the default as needed, without being held to the actual value. And wrapper code, like mine, would declare a default of None and things would continue to work across versions.

----------

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

From report at bugs.python.org  Wed Jun  3 15:52:04 2015
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jun 2015 13:52:04 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
Message-ID: <1433339524.8.0.605145520054.issue24372@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

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

From report at bugs.python.org  Wed Jun  3 15:54:25 2015
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jun 2015 13:54:25 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
Message-ID: <1433339665.91.0.120750041861.issue24372@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'd like to deprecate ssl.wrap_socket() in favor of SSLContext.wrap_socket(). Libraries should rather accept a context than expose the awkward interface of ssl.wrap_socket(). A context object is far more powerful and easier to use.

----------

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

From report at bugs.python.org  Wed Jun  3 16:09:54 2015
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 03 Jun 2015 14:09:54 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
Message-ID: <1433340594.69.0.984249982862.issue24372@psf.upfronthosting.co.za>


Christian Heimes added the comment:

DISCLAIMER:

I'm currently planning and researching two SSL related PEPs. One PEP is about SSLContext.

I like to standardize a minimal interface for SSL context object, so libraries can deal with any abitrary SSL implementation. With just one small addition and an SSLContext ABC, every library could then support stdlib ssl, PyOpenSSL, GnuTLS, NSS, PyQT/PySide QSslSocket and even non-standard sockets like NSPR PRFileDesc and QTcpSocket.

My idea only works with a SSL context object. So I'm interested that people use the new feature rather then the old ssl.wrap_socket() function. :)

----------

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

From report at bugs.python.org  Wed Jun  3 16:14:06 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 03 Jun 2015 14:14:06 +0000
Subject: [docs] [issue24372] Documentation for ssl.wrap_socket's ssl_version
 parameter is odd
In-Reply-To: <1433337046.56.0.760667574061.issue24372@psf.upfronthosting.co.za>
Message-ID: <1433340845.98.0.115328342967.issue24372@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I have a requirement to support 2.7.5, so SSLContext is currently a problem for me.

I realize that 2.7 could at best get a documentation change.

----------

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

From doctortrahan at gmail.com  Wed Jun  3 21:18:23 2015
From: doctortrahan at gmail.com (Richard Trahan)
Date: Wed, 3 Jun 2015 15:18:23 -0400
Subject: [docs] Python tutorial
Message-ID: <CAPxwp291F_PETm82qUOEgJ2BZV6UYo+ucghgSByrg7-GMTa0Vg@mail.gmail.com>

I am a noob in Python (but not in programming), and am reading the
tutorial. Generally it is well-written, but section 6.4 on packages is
obscure. "Package" is not actually defined anywhere. The last two
paragraphs of this section are unclear. The terms module, submodule,
package, subpackage, item, and name are all very confusing. There is no
comprehensible explanation of __init__.py and how it affects the search for
modules.

Missing from the tutorial is a description of the most-used string
functions. The ones in the standard library are not the most common. Look
at the Java String API to see many functions which are not found in the
Python Standard Library in the tutorial.

I would like to see a large section on this web site dealing with the issue
of why almost nothing works as advertised in what is supposed to be a
simple computer language. Getting a Python program to work requires
numerous kludges found in countless blogs. For example, even on the first
execution of a module, the garbage collection system will wipe out an image
object before it is used in the very module in which it is created. I found
a blog which says the fix is to save the image object to a widget variable
There is no explanation of why this works. There are hundreds of tricks
like that all over the Internet, which are not explained in the tutorial or
any other official documentation.

There are also installation problems. Why does Ubuntu install version 2.7
from its Software Center? If 3.3 is downloaded explicitly, it doesn't work
with any version of IDLE or Spyder available on Ubuntu. These types of
issues are very annoying to someone just trying to learn the language.
There should be a section in the tutorial on all this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150603/5a3f7182/attachment.html>

From report at bugs.python.org  Thu Jun  4 23:42:05 2015
From: report at bugs.python.org (Brandon Milam)
Date: Thu, 04 Jun 2015 21:42:05 +0000
Subject: [docs] [issue24148] 'cum' not a valid sort key for
	pstats.Stats.sort_stats
In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za>
Message-ID: <1433454125.85.0.111669615955.issue24148@psf.upfronthosting.co.za>


Brandon Milam added the comment:

They are correct. 'cum' is not one of the available keywords and so here is the fix changing it to say 'cumulative' for consistency as ramiro suggested.

----------
keywords: +patch
nosy: +jbmilam
Added file: http://bugs.python.org/file39627/profile_example_fix.patch

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

From report at bugs.python.org  Fri Jun  5 04:28:45 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Jun 2015 02:28:45 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1433471325.24.0.348184651824.issue24351@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jun  5 13:48:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Jun 2015 11:48:59 +0000
Subject: [docs] [issue24148] 'cum' not a valid sort key for
	pstats.Stats.sort_stats
In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za>
Message-ID: <20150605114855.25588.81255@psf.io>


Roundup Robot added the comment:

New changeset bfc043eab54e by Berker Peksag in branch '3.4':
Issue #24148: Fix incorrect Stats.sort_stats() example.
https://hg.python.org/cpython/rev/bfc043eab54e

New changeset ffb7019d70cf by Berker Peksag in branch '3.5':
Issue #24148: Fix incorrect Stats.sort_stats() example.
https://hg.python.org/cpython/rev/ffb7019d70cf

New changeset 123419b216e0 by Berker Peksag in branch 'default':
Issue #24148: Fix incorrect Stats.sort_stats() example.
https://hg.python.org/cpython/rev/123419b216e0

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

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

From report at bugs.python.org  Fri Jun  5 13:50:49 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 05 Jun 2015 11:50:49 +0000
Subject: [docs] [issue24148] 'cum' not a valid sort key for
	pstats.Stats.sort_stats
In-Reply-To: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za>
Message-ID: <1433505049.26.0.0140648831078.issue24148@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed! Thanks for the report, ramiro and thanks for the patch, Brandon.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun  5 14:18:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 05 Jun 2015 12:18:14 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <20150605121811.11547.15627@psf.io>


Roundup Robot added the comment:

New changeset 9377ffb9eaf2 by Berker Peksag in branch '3.4':
Issue #23659: Document **fmtparams in csv.register_dialect docstring.
https://hg.python.org/cpython/rev/9377ffb9eaf2

New changeset eee64e72d294 by Berker Peksag in branch '3.5':
Issue #23659: Document **fmtparams in csv.register_dialect docstring.
https://hg.python.org/cpython/rev/eee64e72d294

New changeset a3fbf1fe8fa6 by Berker Peksag in branch 'default':
Issue #23659: Document **fmtparams in csv.register_dialect docstring.
https://hg.python.org/cpython/rev/a3fbf1fe8fa6

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

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

From report at bugs.python.org  Fri Jun  5 14:19:52 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 05 Jun 2015 12:19:52 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1433506792.09.0.409245487743.issue23659@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From report at bugs.python.org  Fri Jun  5 14:33:54 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 05 Jun 2015 12:33:54 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
 not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1433507634.38.0.469940809132.issue21297@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch looks good to me, thanks! Could you also convert your test script to a test case and add it in Lib/test/test_csv.py?

----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.6

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

From report at bugs.python.org  Fri Jun  5 17:08:48 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 05 Jun 2015 15:08:48 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
 conform to the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1433516928.58.0.889120708273.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Looks good to me.

----------

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

From report at bugs.python.org  Fri Jun  5 18:46:00 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Jun 2015 16:46:00 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1433522760.43.0.299431720786.issue24351@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Rather than change the code, which strives to keep the "Simple" in PEP 292's title, I'd rather just update the documentation to define what "identifier" means here.  E.g.

"
* ``$identifier`` names a substitution placeholder matching a mapping key of
  ``"identifier"``.  By default, ``"identifier"`` is restricted to any
  case-insensitive ASCII alphanumeric string (including underscores) that
  starts with an underscore or ASCII letter.  The first non-identifier
  character after the ``$`` character terminates this placeholder
  specification.
"

----------

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

From report at bugs.python.org  Fri Jun  5 19:37:29 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jun 2015 17:37:29 +0000
Subject: [docs] [issue24330] Idle doc: explain "Configure Idle" not in
 "Options" on OSX, etc.
In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za>
Message-ID: <1433525849.21.0.0140470257117.issue24330@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: "Configure Idle" not in "Options" -> Idle doc: explain "Configure Idle" not in "Options" on OSX, etc.

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

From report at bugs.python.org  Fri Jun  5 19:39:09 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Jun 2015 17:39:09 +0000
Subject: [docs] [issue24330] Idle doc: explain "Configure Idle" not in
 "Options" on OSX, etc.
In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za>
Message-ID: <1433525949.59.0.465471487576.issue24330@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun  6 16:30:08 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 06 Jun 2015 14:30:08 +0000
Subject: [docs] [issue14586] TypeError: truncate() takes no keyword arguments
In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za>
Message-ID: <1433601008.9.0.148649302947.issue14586@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/issue14586>
_______________________________________

From report at bugs.python.org  Sat Jun  6 17:30:54 2015
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 06 Jun 2015 15:30:54 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433604654.09.0.439327042236.issue24195@psf.upfronthosting.co.za>


Ram Rachum added the comment:

A problem I just realized with Brian's 2-line implementation of `filter`: It doesn't work for iterables which aren't sequences, since it attempts to exhaust the iterable twice. So if you have a non-sequence you'll have to make it into a sequence first.

----------

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

From report at bugs.python.org  Sun Jun  7 00:01:34 2015
From: report at bugs.python.org (Christie)
Date: Sat, 06 Jun 2015 22:01:34 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1433628093.42.0.907860004998.issue18576@psf.upfronthosting.co.za>


Christie added the comment:

@ncoghlan I've taken the test.rst changes from the previous diff and reviewed them against the latest script_helper (including updates from issue24033). Nothing had fallen behind, but I've added what was missing.

* I've realized that spawn_python and the helper run_python I added in issue24033 are basically the same so I will reconcile those
* Is there some way to load the docstrings from script_helper.py in test.rst instead of writing explanations for each method twice?

----------
Added file: http://bugs.python.org/file39645/issue18576.patch

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

From report at bugs.python.org  Sun Jun  7 02:44:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Jun 2015 00:44:53 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1433637893.34.0.398784452306.issue18576@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you diffed your patch from a public revision in the main repository, there should be a nice ?Review? link. Anyway, here are some comments on issue18576.patch:

+.. function:: assert_python_ok(*args, **env_vars)
+
+   Runs the interpreter with *args* and optional environment
+   variables, asserting that *env_vars* succeeds (``rc == 0``).

Perhaps you mean *env_vars* are the optional environment variables, and that the interpreter is asserted to have succeeded.

Also maybe clarify where the *__cleanenv* and *__isolated* keywords come from? Function signatures? Also applies to assert_python_failure(), run_python/_until_end().

Maybe it is worth mentioning that assert_python_ok/failure() strip whitespace from the stderr stream. I seem to remember being tricked by this (writing a test to ensure stderr ended in a newline or something).

+   ``stdout`` are configured as binary pipes and ``stderr`` is merged with
+   ``stdout``..

There are two full stops above here..

I encourage you to start sentences with capital letters (although I admit sometimes other people do not agree with this). Suggestions:

+   *kw* is passed through to subprocess.Popen as additional keyword
+   arguments.
=> The *kw* arguments are passed through to subprocess.Popen.

+   *source* is a Unicode string which will be written to the file as UTF-8.
=> The *source* argument is a Unicode string which will be written to the file as UTF-8.

+   *depth* controls how many deeply nested the package is.
=> The *depth* argument controls how deeply nested the package is.

+   Creates a new zip archive in the given directory, containing the specified
+   Python script/module

Needs one of those full stops I mentioned earlier :)

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

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

From report at bugs.python.org  Sun Jun  7 03:04:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 07 Jun 2015 01:04:49 +0000
Subject: [docs] [issue14586] TypeError: truncate() takes no keyword arguments
In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za>
Message-ID: <1433639089.64.0.861298462756.issue14586@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 23738 and PEP 457 for fixing the documentation instead, possibly something like truncate(size=None, /). Also, Issue 17003 has changed some of the keywords to be more consistent, making parts of this patch incorrect.

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

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

From report at bugs.python.org  Sun Jun  7 07:45:02 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Jun 2015 05:45:02 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1433655902.86.0.349167589574.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As far as using docstrings for the online docs goes, there are some useful Sphinx add-ons that we've never enabled for the main Python docs (like autodoc, blockdiag, seqdiag) that could be good options to have available. For autodoc in particular, we prefer to avoid it for the main docs because "good docstring" and "good prose documentation" don't necessarily look alike. For ease of maintenance of test.support though, I think the "write a good docstring, get the online docs for free" rationale is a compelling one (since these docs are core contributor facing, rather than being aimed at Python users in general)

docs at python.org would be the place to ask about the appropriateness of enabling some Sphinx add-ons. While enabling them seems like a reasonable idea to me, I don't personally know if there are actually technical issues with the idea, or if there just hasn't been a volunteer to add/enable them and update https://docs.python.org/devguide/documenting.html accordingly.

----------

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

From report at bugs.python.org  Sun Jun  7 15:32:16 2015
From: report at bugs.python.org (Geoff Shannon)
Date: Sun, 07 Jun 2015 13:32:16 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1433683936.43.0.0830036618056.issue22865@psf.upfronthosting.co.za>


Geoff Shannon added the comment:

Hey, pinging this issue.  Hoping someone has time to take a look at it.

----------

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

From report at bugs.python.org  Sun Jun  7 17:05:10 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 07 Jun 2015 15:05:10 +0000
Subject: [docs] [issue14003] __self__ on built-in functions is not as
	documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1433689510.49.0.29900521837.issue14003@psf.upfronthosting.co.za>


Changes by Dmitry Kazakov <jsbfox at gmail.com>:


----------
nosy: +vlth

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

From report at bugs.python.org  Sun Jun  7 17:13:32 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 07 Jun 2015 15:13:32 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1433690012.25.0.498572509515.issue22865@psf.upfronthosting.co.za>


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


----------
nosy: +twouters

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

From report at bugs.python.org  Sun Jun  7 19:45:25 2015
From: report at bugs.python.org (Fabian)
Date: Sun, 07 Jun 2015 17:45:25 +0000
Subject: [docs] [issue24404] Python 2.7.0's BZ2File does not support
	with-statements
Message-ID: <1433699124.98.0.649145124993.issue24404@psf.upfronthosting.co.za>


New submission from Fabian:

I had a weird bug recently where someone tried to use the with-statement on a BZ2File. According to the documentation it was added in 2.7 and looking at https://hg.python.org/cpython/rev/5d5d9074f4ca it looks like it was added together with the support in gzip.

But after I've installed 2.7.0 I could use the with-statement on gzip but not in BZ2File:

Python 2.7 (r27:82500, Jun  7 2015, 19:01:29) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
...   c = f.read()
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: __exit__

So I've installed 2.7.1 and sure enough it works there:

Python 2.7.1 (r271:86832, Jun  7 2015, 19:21:02) 
[GCC 4.8.3 20140911 (Red Hat 4.8.3-7)] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> import bz2
>>> with bz2.BZ2File('tests/data/xml/article-pyrus.xml.bz2') as f:
...   c = f.read()
... 
>>> 

I guess the documentation needs be updated that since Python 2.7.1 BZ2File supports the with-statement.

See also: https://phabricator.wikimedia.org/T101649

----------
assignee: docs at python
components: Documentation
messages: 244962
nosy: docs at python, xZise
priority: normal
severity: normal
status: open
title: Python 2.7.0's BZ2File does not support with-statements
versions: Python 2.7

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

From report at bugs.python.org  Sun Jun  7 20:10:23 2015
From: report at bugs.python.org (eryksun)
Date: Sun, 07 Jun 2015 18:10:23 +0000
Subject: [docs] [issue14003] __self__ on built-in functions is not as
	documented
In-Reply-To: <1329159935.3.0.264942191971.issue14003@psf.upfronthosting.co.za>
Message-ID: <1433700623.56.0.0396390927839.issue14003@psf.upfronthosting.co.za>


eryksun added the comment:

In Python 2 [Py_InitModule4][1] optionally allows setting __self__ on module functions, but no module in the standard library actually uses this. It's always None. This is no longer optional with Python 3's [PyModule_Create][2]. Built-in module functions instantiated the normal way can be considered as methods of the module in which they're defined. However, some modules may specially instantiate functions for which __self__ is None, such as codecs.strict_errors.

    >>> codecs.strict_errors.__self__ is None
    True

[1]: https://docs.python.org/2/c-api/allocation.html#c.Py_InitModule4
[2]: https://docs.python.org/3/c-api/module.html#c.PyModule_Create

----------
nosy: +eryksun

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

From report at bugs.python.org  Sun Jun  7 20:25:29 2015
From: report at bugs.python.org (Christie)
Date: Sun, 07 Jun 2015 18:25:29 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1433701529.44.0.528125522094.issue18576@psf.upfronthosting.co.za>


Christie added the comment:

> If you diffed your patch from a public revision in the main repository, there should be a nice ?Review? link.

Ah, thanks @vadmium!!! I've been confused about why some patches get review links and others do not >.<

I'll have a new patch up shortly which is diffed against a public revision and has your suggested changes.

> For autodoc in particular, we prefer to avoid it for the main docs because "good docstring" and "good prose documentation" don't necessarily look alike. 

@ncoghlan for some reason I thought that the main docs were also auto generated from docstrings in the actual modules, but I can see now that that isn't the case.

I'll reach out to docs at python.org to see how they feel about autogenerating the test.support docs.

----------

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

From Payne at mail.python.org  Sun Jun  7 22:53:07 2015
From: Payne at mail.python.org (Payne at mail.python.org)
Date: Sun, 07 Jun 2015 13:53:07 -0700
Subject: [docs] Small suggestion
Message-ID: <E1Z1hZ5-0000La-00@p166.freret.org>

 1:43 pm Sun 7 Jun 2015

As I read the excellent Pythons documentation, I occasionally come across rhetorical constructions that might be improved.  Here's one prom ython-2.7.10-docs-html/reference/simple_stmts.html#the-exec-statement

    The first expression should evaluate to either a
    Unicode string, a Latin-1 encoded string, an open file
    object, a code object, or a tuple.

"Either" introduces *two* items, as in "either True or False ."  In the sentence above it's used to introduce four items.  It would be better to omit the "either" and say

    The first expression should evaluate to a Unicode
    string, a Latin-1 encoded string, an open file object,
    a code object, or a tuple.

If the organization is interested in receiving further rhetorical suggestions, I will send them along.

Payne Freret

From report at bugs.python.org  Mon Jun  8 03:07:32 2015
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Jun 2015 01:07:32 +0000
Subject: [docs] [issue24404] Python 2.7.0's BZ2File does not support
	with-statements
In-Reply-To: <1433699124.98.0.649145124993.issue24404@psf.upfronthosting.co.za>
Message-ID: <1433725652.03.0.765441905115.issue24404@psf.upfronthosting.co.za>


Ned Deily added the comment:

The misbehavior in Python 2.7 was due to a bug as documented in Issue9928, a bug that unfortunately was not discovered until just after 2.7 was initially released.  The fix for Issue9928 was first included in 2.7.1 as you discovered.  So the documentation has always been correct in intent.  For Python versions in maintenance mode, like 2.7.x and 3.4.x, we only provide fixes for the most recent minor release of each (e.g. currently 2.7.10 and 3.4.3), so Python 2.7 was no longer supported once Python 2.7.1 was released and those events were nearly five years and many minor versions ago.  It's a bit of a judgement call in this case but I don't think there's a compelling reason to change the documentation now.  The current version of the 2.7 documentation is intended to reflect the current state of Python 2.7, e.g. 2.7.10, which it does.  And we hope that no one is still using 2.7(.0).

----------
nosy: +ned.deily
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> weird oddity with bz2 context manager

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

From report at bugs.python.org  Mon Jun  8 04:06:16 2015
From: report at bugs.python.org (Martin Blais)
Date: Mon, 08 Jun 2015 02:06:16 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
 about mem mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1433729176.57.0.407888042767.issue24278@psf.upfronthosting.co.za>


Martin Blais added the comment:

LGTM! Thanks for making the change.

----------

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

From report at bugs.python.org  Mon Jun  8 08:27:29 2015
From: report at bugs.python.org (Tal Einat)
Date: Mon, 08 Jun 2015 06:27:29 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
 legacy convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1433744849.8.0.730366241879.issue20346@psf.upfronthosting.co.za>


Tal Einat added the comment:

This patch was applied in changeset 57a27aae7836.

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

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

From report at bugs.python.org  Mon Jun  8 13:21:15 2015
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Jun 2015 11:21:15 +0000
Subject: [docs] [issue24405] Missing code markup in "Expressions"
	documentation
Message-ID: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>


New submission from Gareth Rees:

The "Expressions" documentation contains the text:

> * Sets and frozensets define comparison operators to mean subset and superset
>  tests.  Those relations do not define total orderings (the two sets ``{1,2}``
>  and {2,3} are not equal, nor subsets of one another, nor supersets of one
>  another).

Here {2,3} should be marked up as code (like {1,2}) but is not.

----------
assignee: docs at python
components: Documentation
files: markup.patch
keywords: patch
messages: 244996
nosy: Gareth.Rees, docs at python
priority: normal
severity: normal
status: open
title: Missing code markup in "Expressions" documentation
type: enhancement
Added file: http://bugs.python.org/file39657/markup.patch

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

From report at bugs.python.org  Mon Jun  8 13:32:38 2015
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Jun 2015 11:32:38 +0000
Subject: [docs] [issue24406] "Bulit-in Types" documentation doesn't explain
 how dictionaries are compared for equality
Message-ID: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>


New submission from Gareth Rees:

The "Built-in Types" section of the library documentation does not explain how two dictionaries are compared for equality.

The place where this is documented is under "Comparisons" in the Language Reference:

> Mappings (dictionaries) compare equal if and only if they have the same (key, value) pairs.

but it is not obvious from the section on dictionaries in "Built-in Types" that this is where to look.

(Contrast with the situation for sequences and sets, where "Built-in Types" does explain how these objects are compared for equality.)

I suggest that the "Built-in Types" section should explain how two dictionaries are tested for equality.

----------
assignee: docs at python
components: Documentation
files: dict-equality.patch
keywords: patch
messages: 244998
nosy: Gareth.Rees, docs at python
priority: normal
severity: normal
status: open
title: "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality
type: enhancement
Added file: http://bugs.python.org/file39658/dict-equality.patch

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

From report at bugs.python.org  Mon Jun  8 13:33:51 2015
From: report at bugs.python.org (Gareth Rees)
Date: Mon, 08 Jun 2015 11:33:51 +0000
Subject: [docs] [issue24406] "Built-in Types" documentation doesn't explain
 how dictionaries are compared for equality
In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>
Message-ID: <1433763231.27.0.0202427606522.issue24406@psf.upfronthosting.co.za>


Changes by Gareth Rees <gdr at garethrees.org>:


----------
title: "Bulit-in Types" documentation doesn't explain how dictionaries are compared for equality -> "Built-in Types" documentation doesn't explain how dictionaries are compared for equality

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

From report at bugs.python.org  Mon Jun  8 16:31:54 2015
From: report at bugs.python.org (Brian Quinlan)
Date: Mon, 08 Jun 2015 14:31:54 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433773913.99.0.934479897228.issue24195@psf.upfronthosting.co.za>


Brian Quinlan added the comment:

Actually it immediately converts the iterable into a list. Recall:

def filter(self, fn, iterable, timeout=None):
  l = list(iterable)  # iterable => list
  return (item for (item, keep) in zip(l, self.map(fn, l, timeout)) if keep)

----------

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

From report at bugs.python.org  Mon Jun  8 18:39:08 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 08 Jun 2015 16:39:08 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433781548.64.0.934978963419.issue24195@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The recipe will work in simple situations.

In more complex situations:

  - infinite iterator
  - really large iterator (millions of items)
  - high work load to produce next iteration

the recipe will either have a severe impact on performance or fail entirely.

----------

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

From report at bugs.python.org  Mon Jun  8 18:44:05 2015
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 08 Jun 2015 16:44:05 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433781845.88.0.727517283866.issue24195@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Ethan: That's what I also thought, but then I figured that you're creating N futures anyway with an item attached to each, so it's on the same scale as creating a list, no?

----------

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

From report at bugs.python.org  Mon Jun  8 19:10:15 2015
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 08 Jun 2015 17:10:15 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433783415.87.0.702064824066.issue24195@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The recipe creates a list before it ever starts processing, while Executor.filter() starts processing with the first item.

----------

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

From report at bugs.python.org  Mon Jun  8 19:11:33 2015
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 08 Jun 2015 17:11:33 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1433783493.7.0.695783215537.issue24195@psf.upfronthosting.co.za>


Ram Rachum added the comment:

Right, so it might be garbage-collecting the items before the futures are done being created, so the whole list wouldn't need to be saved in memory. I understand now.

----------

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

From report at bugs.python.org  Tue Jun  9 15:24:58 2015
From: report at bugs.python.org (Tal Einat)
Date: Tue, 09 Jun 2015 13:24:58 +0000
Subject: [docs] [issue24356] venv documentation incorrect / misleading
In-Reply-To: <1433197293.5.0.203233804739.issue24356@psf.upfronthosting.co.za>
Message-ID: <1433856298.71.0.254932333699.issue24356@psf.upfronthosting.co.za>


Tal Einat added the comment:

See also the recent addition of a section on venv to the Tutorial section of the docs (Doc/tutorial/venv.rst, issue23891). The wording there and in the module docs should at least be consistent with each other.

----------
nosy: +taleinat

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

From report at bugs.python.org  Tue Jun  9 15:38:06 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 09 Jun 2015 13:38:06 +0000
Subject: [docs] [issue24417] Type-specific documentation for __format__
	methods
Message-ID: <1433857085.94.0.53514781812.issue24417@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I am only now just prying my fingers off printf-style string
formatting. The new syntax always seemed Perl-like to me, so I ignored
it. Finally, yesterday, I got some cheat sheet pointers from
comp.lang.python and dove in.

I hit a minor roadblock when I couldn't find any type-specific
documentation for the various __format__ methods. In the documentation
on the format() builtin
(https://docs.python.org/3.5/library/functions.html#format) I read,
"The interpretation of format_spec will depend on the type of the
value argument..." which led me to believe I would find something
about (for example) float.__format__ in the section on floats
(https://docs.python.org/3.5/library/stdtypes.html#typesnumeric).

I realize now that the documentation for many formats is in the string
documentation
(https://docs.python.org/3.5/library/string.html#formatspec), but I
think it would still be useful to have at least stubs in the
documentation for the __format__ method of the various builtin types,
even if all those stubs to is refer the reader to the string
documentation.

I started to work on a patch, but I quickly got myself confused about
where to describe <sometype>.__format__. Perhaps it's time that
stdtypes.rst is broken into multiple files, with the structure of the
documentation for the various builtin types made more uniform. For
instance, int and float have sections describing methods, while list,
tuple, set, and dict don't.

----------
assignee: docs at python
components: Documentation
messages: 245063
nosy: docs at python, skip.montanaro
priority: normal
severity: normal
status: open
title: Type-specific documentation for __format__ methods

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

From report at bugs.python.org  Tue Jun  9 16:33:23 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 09 Jun 2015 14:33:23 +0000
Subject: [docs] [issue24417] Type-specific documentation for __format__
	methods
In-Reply-To: <1433857085.94.0.53514781812.issue24417@psf.upfronthosting.co.za>
Message-ID: <1433860403.84.0.136292389539.issue24417@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Tue Jun  9 18:02:59 2015
From: report at bugs.python.org (Tal Einat)
Date: Tue, 09 Jun 2015 16:02:59 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1433865779.33.0.452501015763.issue24351@psf.upfronthosting.co.za>


Tal Einat added the comment:

+1 for keeping the current behavior and fixing the docs.

----------
nosy: +taleinat

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

From report at bugs.python.org  Tue Jun  9 20:24:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 09 Jun 2015 18:24:47 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <20150609182444.17685.65607@psf.io>


Roundup Robot added the comment:

New changeset 20bf84cd38bc by Barry Warsaw in branch '3.4':
- Issue #24351: Clarify what is meant by "identifier" in the context of
https://hg.python.org/cpython/rev/20bf84cd38bc

New changeset 0fa48f581fe3 by Barry Warsaw in branch '3.5':
- Issue #24351: Clarify what is meant by "identifier" in the context of
https://hg.python.org/cpython/rev/0fa48f581fe3

New changeset 1cdedc9a9e9f by Barry Warsaw in branch 'default':
- Issue #24351: Clarify what is meant by "identifier" in the context of
https://hg.python.org/cpython/rev/1cdedc9a9e9f

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

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

From report at bugs.python.org  Tue Jun  9 20:27:19 2015
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Jun 2015 18:27:19 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1433874439.13.0.827131740981.issue24351@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


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

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

From report at bugs.python.org  Wed Jun 10 06:04:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 10 Jun 2015 04:04:16 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
Message-ID: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>


New submission from Martin Panter:

After the documentation was rearranged by Issue 23342 (revision f0a00ee094ff), the ?older high-level APIs? lost the paragraphs that said ?The arguments shown above are merely the most common ones?. Given the limited signatures of call(), check_call() and check_output(), it is now too easy to assume that these functions do not accept the less-common Popen arguments.

Also, in that issue I discovered an awkward edge case: there is actually no default value for the check_output() input parameter. Without an ?input? parameter, the subprocess inherits its parent?s input, but input=None is equivalent to passing an empty string of the correct type.

This patch hopefully fixes both problems.

----------
assignee: docs at python
components: Documentation
files: high-args.patch
keywords: patch
messages: 245111
nosy: docs at python, takluyver, vadmium
priority: normal
severity: normal
status: open
title: Documentation regressions from adding subprocess.run()
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39671/high-args.patch

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

From report at bugs.python.org  Wed Jun 10 06:38:58 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 10 Jun 2015 04:38:58 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1433911138.76.0.310119496641.issue24420@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
stage:  -> patch review

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

From av.rogozhnikov at tensor.ru  Tue Jun  9 16:22:59 2015
From: av.rogozhnikov at tensor.ru (=?koi8-r?B?8s/Hz9bOycvP1yDhzsHUz8zJyg==?=)
Date: Tue, 09 Jun 2015 19:22:59 +0500
Subject: [docs] Examples on page
Message-ID: <op.xzyvklp0dzi0id@r66-rogozhnikov.region.tensor.ru>

https://docs.python.org/3.3/whatsnew/2.0.html#xml-modules

1) Exampeles code style does not match PEP 8.
2) `print` function without braces.

From zachary.ware+pydocs at gmail.com  Wed Jun 10 08:04:55 2015
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 10 Jun 2015 01:04:55 -0500
Subject: [docs] Examples on page
In-Reply-To: <op.xzyvklp0dzi0id@r66-rogozhnikov.region.tensor.ru>
References: <op.xzyvklp0dzi0id@r66-rogozhnikov.region.tensor.ru>
Message-ID: <CAKJDb-OvUH+sZec7KAbP4f=ga-bpLL8zNwBW2O4TO8FdaujgKg@mail.gmail.com>

Hi,

On Tue, Jun 9, 2015 at 9:22 AM, ?????????? ????????
<av.rogozhnikov at tensor.ru> wrote:
> https://docs.python.org/3.3/whatsnew/2.0.html#xml-modules
>
> 1) Exampeles code style does not match PEP 8.
> 2) `print` function without braces.

While the examples are admittedly not ideal (anymore), they're part of
a historical document and won't be changed.  "What's New?" documents
are rarely adjusted after release, and especially not when the release
in question (2.0) is 15 years old :)

Thanks for the report, anyway!

-- 
Zach

From report at bugs.python.org  Wed Jun 10 14:34:37 2015
From: report at bugs.python.org (Stefan Tatschner)
Date: Wed, 10 Jun 2015 12:34:37 +0000
Subject: [docs] [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
Message-ID: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za>


New submission from Stefan Tatschner:

A list item which describes the changes of #22631 is badly indented. The attached (trivial) patch fixes that problem.

----------
assignee: docs at python
components: Documentation
files: fix-indentation.patch
keywords: patch
messages: 245127
nosy: docs at python, rumpelsepp
priority: normal
severity: normal
status: open
title: Fix wrong indentation in Doc/whatsnew/3.5.rst
versions: Python 3.5
Added file: http://bugs.python.org/file39673/fix-indentation.patch

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

From report at bugs.python.org  Wed Jun 10 21:04:04 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 10 Jun 2015 19:04:04 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1433963044.0.0.807363564143.issue24420@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks, this looks good to me.

----------

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

From report at bugs.python.org  Thu Jun 11 00:44:44 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 10 Jun 2015 22:44:44 +0000
Subject: [docs] [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
In-Reply-To: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za>
Message-ID: <20150610224441.40314.83058@psf.io>


Roundup Robot added the comment:

New changeset 4e7dcf64bba7 by Ned Deily in branch '3.5':
Issue #24423: Fix formatting error in 3.5 whatsnew
https://hg.python.org/cpython/rev/4e7dcf64bba7

New changeset 3156dd82df2d by Ned Deily in branch 'default':
Issue #24423: merger from 3.5
https://hg.python.org/cpython/rev/3156dd82df2d

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

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

From report at bugs.python.org  Thu Jun 11 00:45:20 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 10 Jun 2015 22:45:20 +0000
Subject: [docs] [issue24423] Fix wrong indentation in Doc/whatsnew/3.5.rst
In-Reply-To: <1433939677.74.0.149159718564.issue24423@psf.upfronthosting.co.za>
Message-ID: <1433976320.66.0.334203153785.issue24423@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jun 11 06:40:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Jun 2015 04:40:54 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1433997654.03.0.334834953151.issue23391@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch with the following changes. Let me know what you think.

* Added extra markup for OSError attributes and constructor signature
* Explained how ?winerror? works with and without Windows
* Added ?filename2? argument
* Update tests for filename2 defaulting to None

For reference, the argument handling seems to be in oserror_parse_args(), at Objects/exceptions.c:724, and related functions.

----------
versions: +Python 3.6
Added file: http://bugs.python.org/file39678/os-error-args.v2.patch

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

From report at bugs.python.org  Thu Jun 11 09:01:29 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jun 2015 07:01:29 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1434006089.2.0.332777930235.issue24420@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jun 11 09:06:34 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jun 2015 07:06:34 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1434006394.29.0.552108847173.issue23391@psf.upfronthosting.co.za>


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


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

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

From storchaka at gmail.com  Thu Jun 11 09:32:45 2015
From: storchaka at gmail.com (storchaka at gmail.com)
Date: Thu, 11 Jun 2015 07:32:45 -0000
Subject: [docs] Documentation of EnvironmentError (OSError) arguments
 disappeared (issue 23391)
Message-ID: <20150611073245.15473.51072@psf.upfronthosting.co.za>


http://bugs.python.org/review/23391/diff/15063/Doc/library/exceptions.rst
File Doc/library/exceptions.rst (right):

http://bugs.python.org/review/23391/diff/15063/Doc/library/exceptions.rst#newcode234
Doc/library/exceptions.rst:234: .. exception:: OSError([arg])
May be use form OSError(*args)? OSError() accepts more than 5 arguments.

http://bugs.python.org/review/23391/diff/15063/Doc/library/exceptions.rst#newcode247
Doc/library/exceptions.rst:247: specified.  For backwards compatibility,
if three arguments are passed,
"if 2 to 5 arguments are passed"

And only in that case the below attribute are set from args. Otherwise
they are set to None.

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

From report at bugs.python.org  Thu Jun 11 09:36:50 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 11 Jun 2015 07:36:50 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1434008210.74.0.705479189976.issue23391@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It should be documented (if still not) that OSError() constructor can return an instance of OSError subclass, depending on errno value.

>>> OSError(errno.ENOENT, 'no such file')
FileNotFoundError(2, 'no such file')

----------

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

From report at bugs.python.org  Thu Jun 11 10:08:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Jun 2015 08:08:06 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1434010086.18.0.472046505737.issue23391@psf.upfronthosting.co.za>


Martin Panter added the comment:

Good point Serhiy about returning subclasses. I?ll see about making that more explicit if I can?t find it already documented somewhere.

Regarding the number of arguments, I resisted documenting what happens to extra arguments since the behaviour has changed over time, and it doesn?t seem that it would be very useful. IMO it would be better to say passing extra arguments is not supported. But if others disagree, I can have a go at documenting the existing and/or past behaviour.

Python 3.3.3 under Wine:
>>> OSError(None, "Not found", "file", 3).args 
(2, 'Not found', 'file', 3)
>>> OSError(ENOENT, "Not found", "file", None).args
(2, 'Not found', 'file', None)

Python 3.6.0a0 under Linux:
>>> OSError(ENOENT, "Not found", "file", None).args
(2, 'Not found')

----------

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

From report at bugs.python.org  Thu Jun 11 10:57:50 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Jun 2015 08:57:50 +0000
Subject: [docs] [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1434013070.11.0.25163221808.issue12833@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks find for Python 3. The sample code should probably be adapted to raw_input() for Python 2.

----------
nosy: +vadmium
stage: needs patch -> commit review
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jun 11 11:07:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 11 Jun 2015 09:07:39 +0000
Subject: [docs] [issue12833] raw_input misbehaves when readline is imported
In-Reply-To: <1314205212.4.0.313319940132.issue12833@psf.upfronthosting.co.za>
Message-ID: <1434013659.6.0.712584403453.issue12833@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually, there should either be a space before the double-colons, or the full stops should be removed. So either of these options:

. . . when a backspace is typed. ::
. . . when a backspace is typed::

----------

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

From report at bugs.python.org  Thu Jun 11 18:32:20 2015
From: report at bugs.python.org (=?utf-8?b?0J7Qu9C10LMg0JjQstCw0L3QvtCy?=)
Date: Thu, 11 Jun 2015 16:32:20 +0000
Subject: [docs] [issue24433] There is no asyncio.ensure_future in Python
	3.4.3
Message-ID: <1434040340.54.0.582208217128.issue24433@psf.upfronthosting.co.za>


New submission from ???? ??????:

Docs claims there there is asyncio.ensure_future

https://docs.python.org/3/library/asyncio-task.html?highlight=ensure_future#asyncio.ensure_future

but example from docs does'nt work:

import asyncio

loop = asyncio.get_event_loop()
tasks = [
    asyncio.ensure_future(print("asasda")),

]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()

Fails with:

AttributeError: 'module' object has no attribute 'ensure_future'

----------
assignee: docs at python
components: Documentation
messages: 245176
nosy: docs at python, ???? ??????
priority: normal
severity: normal
status: open
title: There is no asyncio.ensure_future in Python 3.4.3
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jun 11 18:38:10 2015
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 11 Jun 2015 16:38:10 +0000
Subject: [docs] [issue24433] There is no asyncio.ensure_future in Python
	3.4.3
In-Reply-To: <1434040340.54.0.582208217128.issue24433@psf.upfronthosting.co.za>
Message-ID: <1434040690.48.0.4119663846.issue24433@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The docs also say "New in version 3.4.4" :)

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jun 11 23:12:50 2015
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Freitas?=)
Date: Thu, 11 Jun 2015 21:12:50 +0000
Subject: [docs] [issue24330] Idle doc: explain "Configure Idle" not in
 "Options" on OSX, etc.
In-Reply-To: <1432962360.31.0.591497904103.issue24330@psf.upfronthosting.co.za>
Message-ID: <1434057170.37.0.47119155852.issue24330@psf.upfronthosting.co.za>


Andr? Freitas added the comment:

I have added the explanation in the Docs and IDLE help file. Found also that IDLE help.txt is out of sync with the Docs and needs to be fixed. I will open a new Issue.

----------
keywords: +patch
nosy: +Andr? Freitas
Added file: http://bugs.python.org/file39686/patch.diff

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

From report at bugs.python.org  Fri Jun 12 03:48:53 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Jun 2015 01:48:53 +0000
Subject: [docs] [issue23391] Documentation of EnvironmentError (OSError)
 arguments disappeared
In-Reply-To: <1423026410.5.0.815744351944.issue23391@psf.upfronthosting.co.za>
Message-ID: <1434073733.12.0.425867143119.issue23391@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch, clarifying that the constructor can raise a subclass.

If you still think I need to add something about extra arguments, or how the ?args? attribute is set, let me know.

----------
Added file: http://bugs.python.org/file39690/os-error-args.v3.patch

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

From prashikchoure at gmail.com  Wed Jun 10 07:04:36 2015
From: prashikchoure at gmail.com (prashikchoure at gmail.com)
Date: Wed, 10 Jun 2015 10:34:36 +0530
Subject: [docs] Pl
Message-ID: <29FB55BE-DDC5-4360-ADF4-50FEF75974F7@gmail.com>


Please send me a dictionary 

From report at bugs.python.org  Fri Jun 12 16:04:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Jun 2015 14:04:26 +0000
Subject: [docs] [issue24087] Documentation doesn't explain the term
 "coroutine" (PEP 342)
In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za>
Message-ID: <1434117866.22.0.673247885342.issue24087@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect the patch is out of date due to PEP 492 and Issue 24180 (?await? syntax for coroutines). But maybe the current glossary entry could be refined to also mention generators.

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

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

From report at bugs.python.org  Fri Jun 12 16:46:06 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 12 Jun 2015 14:46:06 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
Message-ID: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>


New submission from Martin Panter:

Today I tried playing with the new ?async def? functionality in the interactive interpreter, based on reading the documentation. Here are some bits that surprised me, so could be the focus of further documentation. (Initial documentation added in Issue 24180.)

1. Confusion between coroutine and generator terms

<coroutine object f at 0x7f9a5ae45200>
AttributeError: 'generator' object has no attribute '__await__'
<class 'generator'>
TypeError: coroutine-objects do not support iteration
TypeError: can't send non-None value to a just-started generator

Is it a coroutine object, or a generator object? The error messages etc seem to be split between the two terms. I guess the underlying implementation is closely shared between the two types, so old error messages still say ?generator?, while new ones say ?coroutine?. So there may not be an easy fix, but it was initially disconcerting. Perhaps a statement somewhere explaining coroutine instances are (based on / modified / a kind of / evolved from) generator instance objects, as appropriate.

2. Properties of a coroutine instance object

<https://docs.python.org/dev/reference/datamodel.html#awaitable-objects> suggests that a coroutine instance should implement __await__(), but it apparently does not.

How to drive through the coroutine?s await points? This should be documented, and linked from relevant places in the documentation; perhaps the ?coroutine? glossary entry, ?async? statement, and ?await? expression. The best clue that I found in the current documentation was <https://docs.python.org/dev/library/collections.abc.html#collections.abc.Coroutine>, suggesting to use send().

Without having studied the PEP recently, I was expecting __await__() to be implemented, and invoking it would be similar to calling next() on an old-skool generator-iterator. Instead I see that calling __await__() is semantically more like __iter__(): it is only invoked once per ?await? expression, and the return value is iterated over.

3. Allergic reaction to ?await? on the same line as ?async def?

>>> async def f(): await A(())
SyntaxError: invalid syntax

I see this is mentioned in the PEP that this is necessary so that ?await? doesn?t have to be made a strict language keyword. But it should also be in the documentation.

4. Coroutine instances don?t implement the Coroutine ABC

>>> isinstance(c, Coroutine)
True
>>> hasattr(Coroutine, "__await__")
True
>>> hasattr(c, "__await__")
False

Reading closely, the documentation says ?coroutine compatible classes?, but given the liberal use of ?coroutine? everywhere, I think there should be a more obvious warning of how much a coroutine is a Coroutine.

----------
assignee: docs at python
components: Documentation
messages: 245256
nosy: docs at python, vadmium, yselivanov
priority: normal
severity: normal
status: open
title: Feedback for awaitable coroutine documentation
type: enhancement
versions: Python 3.5, Python 3.6

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

From rainyel at nauta.cu  Fri Jun 12 16:31:24 2015
From: rainyel at nauta.cu (Rayniel)
Date: Fri, 12 Jun 2015 10:31:24 -0400
Subject: [docs] (no subject)
Message-ID: <3f9375c2-626e-4d42-aae5-a627f0db5a6f@email.android.com>

Hey, why python haven't a suggestions or comments email?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150612/1b70326b/attachment.html>

From willingc at willingconsulting.com  Fri Jun 12 18:52:34 2015
From: willingc at willingconsulting.com (Carol Willing)
Date: Fri, 12 Jun 2015 09:52:34 -0700
Subject: [docs] (no subject)
In-Reply-To: <3f9375c2-626e-4d42-aae5-a627f0db5a6f@email.android.com>
References: <3f9375c2-626e-4d42-aae5-a627f0db5a6f@email.android.com>
Message-ID: <557B0E52.5050903@willingconsulting.com>

Rayniel, You may submit comments and suggestions on the mailing lists :)

Here is a FAQ which should help:
https://docs.python.org/3/faq/general.html#is-there-a-newsgroup-or-mailing-list-devoted-to-python

On 6/12/15 7:31 AM, Rayniel wrote:
> Hey, why python haven't a suggestions or comments email? 


-- 
*Carol Willing*
Developer | Willing Consulting
https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150612/2e5e6865/attachment.html>

From report at bugs.python.org  Fri Jun 12 21:32:26 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Jun 2015 19:32:26 +0000
Subject: [docs] [issue24405] Missing code markup in "Expressions"
	documentation
In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>
Message-ID: <1434137546.79.0.395762177319.issue24405@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is Py3 only (Py 2 has no set displays) in Reference Manual, 6.9. Comparisons.  (Please provide such info with reports.)  Will fix.

----------
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 12 21:46:20 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Jun 2015 19:46:20 +0000
Subject: [docs] [issue24405] Missing code markup in "Expressions"
	documentation
In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>
Message-ID: <20150612194617.19332.4526@psf.io>


Roundup Robot added the comment:

New changeset ccb0f43964e0 by Terry Jan Reedy in branch '3.4':
Closes issue #24405: mark set display as code.
https://hg.python.org/cpython/rev/ccb0f43964e0

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

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

From report at bugs.python.org  Fri Jun 12 21:46:58 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Jun 2015 19:46:58 +0000
Subject: [docs] [issue24405] Missing code markup in "Expressions"
	documentation
In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>
Message-ID: <1434138418.61.0.593651273581.issue24405@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage: needs patch -> resolved
type: enhancement -> behavior

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

From report at bugs.python.org  Fri Jun 12 22:12:48 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Jun 2015 20:12:48 +0000
Subject: [docs] [issue24406] "Built-in Types" doc doesn't explain dict
	comparison.
In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>
Message-ID: <1434139968.23.0.467252935777.issue24406@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The 3.4 sequence section also has this: "Sequences of the same type also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements."  I agree that dicts should have a similar sentence or two. Neither the sequence or (frozen)set sections reference the language manual, so I will leave that out.

----------
nosy: +terry.reedy
title: "Built-in Types" documentation doesn't explain how dictionaries are compared for equality -> "Built-in Types" doc doesn't explain dict comparison.
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 12 22:49:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 12 Jun 2015 20:49:33 +0000
Subject: [docs] [issue24406] "Built-in Types" doc doesn't explain dict
	comparison.
In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>
Message-ID: <20150612204930.20445.8184@psf.io>


Roundup Robot added the comment:

New changeset d775fad1db43 by Terry Jan Reedy in branch '2.7':
Issue #24406: Add sentences on dict comparisons, similar to those for Sequence
https://hg.python.org/cpython/rev/d775fad1db43

New changeset 4e816c324846 by Terry Jan Reedy in branch '3.4':
Issue #24406: Add sentences on dict comparisons, similar to those for Sequence
https://hg.python.org/cpython/rev/4e816c324846

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

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

From report at bugs.python.org  Fri Jun 12 22:52:34 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Jun 2015 20:52:34 +0000
Subject: [docs] [issue24406] "Built-in Types" doc doesn't explain dict
	comparison.
In-Reply-To: <1433763158.1.0.945531416377.issue24406@psf.upfronthosting.co.za>
Message-ID: <1434142354.67.0.903013031144.issue24406@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 13 02:08:22 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 13 Jun 2015 00:08:22 +0000
Subject: [docs] [issue24405] Missing code markup in "Expressions"
	documentation
In-Reply-To: <1433762475.42.0.565039564472.issue24405@psf.upfronthosting.co.za>
Message-ID: <1434154102.82.0.991631524643.issue24405@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jun 13 06:10:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Jun 2015 04:10:12 +0000
Subject: [docs] [issue24442] Readline Bindings Don't Report Any Error On
 Completer Function Exception
In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za>
Message-ID: <1434168612.1.0.542632881773.issue24442@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun 13 06:56:30 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 13 Jun 2015 04:56:30 +0000
Subject: [docs] [issue24442] Readline Bindings Don't Report Any Error On
 Completer Function Exception
In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za>
Message-ID: <1434171390.24.0.227542870639.issue24442@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/issue24442>
_______________________________________

From report at bugs.python.org  Sat Jun 13 08:41:15 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Sat, 13 Jun 2015 06:41:15 +0000
Subject: [docs] [issue24443] Link for clear and wait missing in EventObjects
Message-ID: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za>


New submission from Jaivish Kothari:

https://docs.python.org/2/library/threading.html#threading.Event.set

links missing for wait and clear .
set() is linked though.

Line: "

An event object manages an internal flag that can be set to true with the set() method and reset to false with the clear() method. The wait() method blocks until the flag is true.

"

----------
assignee: docs at python
components: Documentation
files: Fix_link.patch
keywords: patch
messages: 245294
nosy: berker.peksag, docs at python, georg.brandl, janonymous, janonymous, tim.golden, willingc
priority: normal
severity: normal
status: open
title: Link for clear and wait missing in EventObjects
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39702/Fix_link.patch

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

From report at bugs.python.org  Sat Jun 13 10:05:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 13 Jun 2015 08:05:33 +0000
Subject: [docs] [issue24443] Link for clear and wait missing in EventObjects
In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za>
Message-ID: <20150613080530.91498.48646@psf.io>


Roundup Robot added the comment:

New changeset a985b6455fde by Berker Peksag in branch '2.7':
Issue #24443: Fix links for Event.clear() and Event.wait() methods.
https://hg.python.org/cpython/rev/a985b6455fde

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

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

From report at bugs.python.org  Sat Jun 13 10:06:22 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 13 Jun 2015 08:06:22 +0000
Subject: [docs] [issue24443] Link for clear and wait missing in EventObjects
In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za>
Message-ID: <1434182782.68.0.567118323924.issue24443@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Jaivish!

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

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

From report at bugs.python.org  Sat Jun 13 11:05:26 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Sat, 13 Jun 2015 09:05:26 +0000
Subject: [docs] [issue24443] Link for clear and wait missing in EventObjects
In-Reply-To: <1434177675.51.0.151907138721.issue24443@psf.upfronthosting.co.za>
Message-ID: <1434186326.01.0.904529804067.issue24443@psf.upfronthosting.co.za>


Jaivish Kothari added the comment:

My Pleasure sir :)

----------

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

From report at bugs.python.org  Sun Jun 14 14:46:39 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 14 Jun 2015 12:46:39 +0000
Subject: [docs] [issue24087] Documentation doesn't explain the term
 "coroutine" (PEP 342)
In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za>
Message-ID: <1434285999.32.0.0575830762335.issue24087@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a new patch:

* Clarified some recent instances of ?coroutine? as ?native coroutine? (term taken from PEP 492)
* Put ?coroutine? before ?coroutine function? in the glossary.
* Merge ?Use as coroutines? section into new coroutine compound statement documentation
* Add links to glossary entry
* Added one mention of the new ?async? coroutines to ?asyncio?. I understand this is meant to be supported in 3.5, but still needs more documentation work.

----------
versions: +Python 3.6
Added file: http://bugs.python.org/file39707/coroutine_docs.v2.patch

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

From report at bugs.python.org  Mon Jun 15 00:14:21 2015
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 14 Jun 2015 22:14:21 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
Message-ID: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak:

https://docs.python.org/3.4/library/webbrowser.html#module-webbrowser

Visit the link and read the first sentence of the 3rd paragraph. You'll notice that there are two "the" words by the end of that sentence. That's obviously a typo. Please fix it. The typo, however, is not present in the documentation for Python 3.5. Don't know why the 3.4 branch of the docs wasn't fixed as well.

----------
assignee: docs at python
components: Documentation
messages: 245352
nosy: Pikec, docs at python
priority: normal
severity: normal
status: open
title: A typo of doubled "the" words in the doc (easy fix)
versions: Python 3.4

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

From report at bugs.python.org  Mon Jun 15 01:05:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jun 2015 23:05:53 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <1434323153.9.0.855635100919.issue24453@psf.upfronthosting.co.za>


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


----------
keywords: +easy

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

From report at bugs.python.org  Mon Jun 15 01:06:01 2015
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 14 Jun 2015 23:06:01 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <1434323161.14.0.738612233485.issue24453@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The default version was fixed in issue21528, changeset db302b88fdb6. perhaps it simply needs to be backported.

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

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

From report at bugs.python.org  Mon Jun 15 01:07:41 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jun 2015 23:07:41 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <1434323261.23.0.694223925844.issue24453@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun 15 01:09:15 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 14 Jun 2015 23:09:15 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <20150614230912.112065.49459@psf.io>


Roundup Robot added the comment:

New changeset 7b74a89b9c26 by Raymond Hettinger in branch '3.4':
Issue #24453:  Fix doubled word.
https://hg.python.org/cpython/rev/7b74a89b9c26

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

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

From report at bugs.python.org  Mon Jun 15 01:13:10 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Jun 2015 23:13:10 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <1434323590.31.0.0356482887029.issue24453@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun 15 02:37:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Jun 2015 00:37:24 +0000
Subject: [docs] [issue24453] A typo of doubled "the" words in the doc (easy
	fix)
In-Reply-To: <1434320060.96.0.386004077097.issue24453@psf.upfronthosting.co.za>
Message-ID: <20150615003716.1354.74716@psf.io>


Roundup Robot added the comment:

New changeset 3ded282f9615 by Senthil Kumaran in branch '3.4':
Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple documentation typos.
https://hg.python.org/cpython/rev/3ded282f9615

New changeset 9a0c5ffe7420 by Senthil Kumaran in branch 'default':
null merge with 3.4
https://hg.python.org/cpython/rev/9a0c5ffe7420

----------

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

From report at bugs.python.org  Mon Jun 15 02:37:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 15 Jun 2015 00:37:24 +0000
Subject: [docs] [issue21528] Fix a number of typos in the documentation
In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za>
Message-ID: <20150615003716.1354.5512@psf.io>


Roundup Robot added the comment:

New changeset 3ded282f9615 by Senthil Kumaran in branch '3.4':
Back porting changeset db302b88fdb6 to 3.4 branch, which fixed multiple documentation typos.
https://hg.python.org/cpython/rev/3ded282f9615

New changeset 9a0c5ffe7420 by Senthil Kumaran in branch 'default':
null merge with 3.4
https://hg.python.org/cpython/rev/9a0c5ffe7420

----------

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

From report at bugs.python.org  Mon Jun 15 08:57:51 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 15 Jun 2015 06:57:51 +0000
Subject: [docs] [issue24351] string.Template documentation incorrectly
 references "identifiers"
In-Reply-To: <1433185507.96.0.480439174285.issue24351@psf.upfronthosting.co.za>
Message-ID: <1434351471.07.0.970715469862.issue24351@psf.upfronthosting.co.za>


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


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

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

From vadmium+py at gmail.com  Sun Jun 14 15:11:45 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 14 Jun 2015 13:11:45 -0000
Subject: [docs] Documentation doesn't explain the term "coroutine" (PEP
 342) (issue 24087)
Message-ID: <20150614131145.14600.73452@psf.upfronthosting.co.za>


http://bugs.python.org/review/24087/diff/14757/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/24087/diff/14757/Doc/glossary.rst#newcode150
Doc/glossary.rst:150: A generator function that works along with an
event loop or trampoline
On 2015/04/30 23:22:31, Jim.J.Jewett wrote:
> Is it a "generator function" or just a "generator", with "generator
function"
> being the thing you call to create it?  For reference, I'm looking at
> https://docs.python.org/3/reference/expressions.html#yield-expressions

New patch says coroutines may be implemented using generator functions,
which should cover all cases :)

http://bugs.python.org/review/24087/diff/15085/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/24087/diff/15085/Doc/glossary.rst#newcode177
Doc/glossary.rst:177: coroutine to yield control to other routines
without blocking.
Didn?t see the old comment about blocking when I wrote this patch.
Perhaps we should just drop the last bit:

They can be sheduled . . . to allow one coroutine to yield control to
other routines.

http://bugs.python.org/review/24087/diff/15085/Doc/library/inspect.rst
File Doc/library/inspect.rst (left):

http://bugs.python.org/review/24087/diff/15085/Doc/library/inspect.rst#oldcode300
Doc/library/inspect.rst:300: or :func:`asyncio.coroutine`.
Self review: Need to restore @asyncio.coroutine reference

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

From report at bugs.python.org  Mon Jun 15 16:47:29 2015
From: report at bugs.python.org (Paul Moore)
Date: Mon, 15 Jun 2015 14:47:29 +0000
Subject: [docs] [issue24087] Documentation doesn't explain the term
 "coroutine" (PEP 342)
In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za>
Message-ID: <1434379649.13.0.924897072812.issue24087@psf.upfronthosting.co.za>


Paul Moore added the comment:

Personally, I'm OK with the wording in the 3.5.0b2 docs, as far as basic terminology and glossary-style information goes.

I think coroutines, async, and event loops are badly under-documented in the broader context, though - there is very little in the docs explaining the concepts and constraints[1] of Python's async features. Unfortunately, the people with the knowledge of the subject are likely to be too close to the details to be able to write beginner-level documentation, and beginners don't know enough (by definition) to do so. I'm trying to do some playing round with creating my own async framework to get a better understanding of how things should work, but it's slow going and honestly I don't feel I've got anything much I could write up at this point.

[1] For example, how Python's implementation differs from other languages or "theoretical" discussions of coroutines in the literature.

----------

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

From report at bugs.python.org  Tue Jun 16 00:59:04 2015
From: report at bugs.python.org (Perry Randall)
Date: Mon, 15 Jun 2015 22:59:04 +0000
Subject: [docs] [issue24442] Readline Bindings Don't Report Any Error On
 Completer Function Exception
In-Reply-To: <1434164276.99.0.684259947249.issue24442@psf.upfronthosting.co.za>
Message-ID: <1434409144.31.0.176950452539.issue24442@psf.upfronthosting.co.za>


Perry Randall added the comment:

Decided to update the documentation instead

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

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

From report at bugs.python.org  Tue Jun 16 01:39:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 15 Jun 2015 23:39:48 +0000
Subject: [docs] [issue24087] Documentation doesn't explain the term
 "coroutine" (PEP 342)
In-Reply-To: <1430425552.31.0.779606074615.issue24087@psf.upfronthosting.co.za>
Message-ID: <1434411588.78.0.5893234948.issue24087@psf.upfronthosting.co.za>


Martin Panter added the comment:

Okay. The biggest thing that concerns me at the moment to do with the term is that there are too many related but different, specific meanings, that I suspect could be confusing, including:

1. Generators (and presumably also the new ?async? native coroutines), compatible with ?asyncio?: <https://docs.python.org/3.5/library/asyncio-task.html#coroutines>

2. PEP 492 ?native? coroutines: <https://docs.python.org/3.5/glossary.html#term-coroutine-function>

Okay maybe some of the new wording is not needed any more. I plan to try documenting some basic stuff about the new PEP 492 coroutines in Issue 24439. Maybe I will incorporate the ?native coroutine? clarifications from my patch here at the same time.

----------

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

From report at bugs.python.org  Tue Jun 16 05:41:52 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 16 Jun 2015 03:41:52 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1434426112.48.0.163613846281.issue24439@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems that Issue 24400 may implement __await__() for native coroutine instances, making points 1, 2 and 4 mainly redundant. This would also bypass a fifth problem: the need for the mandatory yet largely useless send(None) argument.

I am posting async-doc.patch, with these changes:

* Distinguish between PEP 492?s ?native coroutines? and other coroutines such as those already supported by asyncio and PEP 342 (?yield? expression and generator cleanup)
* Move ?coroutine? before ?coroutine function? in the glossary.
* Add links to ?coroutine? glossary
* Point 3: Explain about ?async? and ?await? becoming reserved keywords after a ?def? header line
* Part of point 2: List native coroutine instance methods and hint at relationship with generator iterator instances

Still to do: how to drive an awaitable coroutine. Currently it seems you have to call coro.send(None), but if the current patch for Issue 24400 were applied, I think it would become next(coro), so I will leave this for later.

----------
dependencies: +Awaitable ABC incompatible with functools.singledispatch
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file39714/async-doc.patch

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

From report at bugs.python.org  Tue Jun 16 13:07:47 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 16 Jun 2015 11:07:47 +0000
Subject: [docs] [issue24458] Documentation for PEP 489
Message-ID: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

Hello,
Here is a patch documenting PEP 489.

I don't feel comfortable rewriting the tutorial [0] yet: before the issue with callbacks/module state [1] is solved, which is 3.6 material, multi-phase init is not suitable for all modules.
So everything in PEP 489 is described in reference-style documentation.


[0] https://docs.python.org/3/extending/extending.html
[1] https://www.python.org/dev/peps/pep-0489/#module-state-and-c-level-callbacks

----------
assignee: docs at python
components: Documentation
files: pep489-docs.patch
keywords: patch
messages: 245419
nosy: brett.cannon, docs at python, encukou, eric.snow, ncoghlan
priority: normal
severity: normal
status: open
title: Documentation for PEP 489
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39715/pep489-docs.patch

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

From report at bugs.python.org  Tue Jun 16 22:51:35 2015
From: report at bugs.python.org (Antony Lee)
Date: Tue, 16 Jun 2015 20:51:35 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
Message-ID: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>


New submission from Antony Lee:

The man page doesn't mention PYTHONFAULTHANDER in the list of environment variables (I haven't thoroughly checked that everyone else is there, either).  I would also suggest reordering the environment variables in alphabetical order.

----------
assignee: docs at python
components: Documentation
messages: 245422
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Mention PYTHONFAULTHANDLER in the man page
versions: Python 3.5

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

From report at bugs.python.org  Tue Jun 16 23:07:21 2015
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Jun 2015 21:07:21 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1434488841.53.0.761849027289.issue24459@psf.upfronthosting.co.za>


STINNER Victor added the comment:

PYTHONASYNCIODEBUG and PYTHONTRACEMALLOC are also missing.

I didn't know that Python has a manual page :-) (Misc/python.man)

Note: I added these 3 environment variables ;-)

----------
nosy: +haypo

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

From noonanes at gmail.com  Wed Jun 17 02:55:49 2015
From: noonanes at gmail.com (Noonan)
Date: Tue, 16 Jun 2015 17:55:49 -0700
Subject: [docs] (correction)Bug in ETree
Message-ID: <CADJH+11wtpbn+K1yVgp90eO-aNCYBR-xzi92=aZZxuo9SsX8MQ@mail.gmail.com>

Sorry my last email sent prematurely, I'm not sure how. I was using a
hotkey for pasing when it accidently sent.

I'm running Python version:

3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit
(AMD64)]

When I do a .findall or .find on an Element object of an ElementTree from
xml.etree, xpath queries (of the format './/<tagname>') aren't letting me
retrieve children that aren't direct descendants of the Element object.
Also, the documentation doesn't clearly show/when how to use XPath queries,
it just mentions that you can use them instead. A lot of python
documentation is like this and it leads to a lot of tinkering and then
frustration when it doesn't work. Stack overflow said the same solution,
but really, I think it's sad when your documentation needs stack overflow
for clarification. Documentation is by no means fast, but the depth should
be better than a quick search on Google/Bing.

This page is the one I used to read up on it. But I actually found better
depth/examples in StackOverflow or the site of the guy that I think wrote
Etree before you guys integrated it into Python.

https://docs.python.org/3/library/xml.etree.elementtree.html?highlight=xml

Thanks!

-Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150616/1a8762b4/attachment.html>

From senthil at uthcode.com  Wed Jun 17 15:10:03 2015
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 17 Jun 2015 06:10:03 -0700
Subject: [docs] (correction)Bug in ETree
In-Reply-To: <CADJH+11wtpbn+K1yVgp90eO-aNCYBR-xzi92=aZZxuo9SsX8MQ@mail.gmail.com>
References: <CADJH+11wtpbn+K1yVgp90eO-aNCYBR-xzi92=aZZxuo9SsX8MQ@mail.gmail.com>
Message-ID: <20D01178D105409DA4973C36B21ECE41@uthcode.com>

Hello Noonan,

In general, I agree that docs could see improvement in listing examples.  

Specifically what was the bug in ET object?s .findall or .find ?

Here I use the example listed in the docs and works fine for me.

$ ./python.exe
Python 3.4.3+ (3.4:3ded282f9615, Jun 17 2015, 06:05:20)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.etree.ElementTree as ET
>>> tree = ET.parse('country_data.xml')
>>> root = tree.getroot()
>>> root.findall(".")
[<Element 'data' at 0x10ea87b88>]
>>> root.findall("./country/neighbor")
[<Element 'neighbor' at 0x10eb63868>, <Element 'neighbor' at 0x10eb638b8>, <Element 'neighbor' at 0x10eb63a48>, <Element 'neighbor' at 0x10eb63bd8>, <Element 'neighbor' at 0x10eb63c28>]
>>> root.findall(".//year/..[@name='Singapore']")
[<Element 'country' at 0x10eb63908>]
>>> root.findall(".//*[@name='Singapore']/year")
[<Element 'year' at 0x10eb639a8>]
>>> root.findall(".//neighbor[2]")
[<Element 'neighbor' at 0x10eb638b8>, <Element 'neighbor' at 0x10eb63c28>]



Thanks,
Senthil


--  
Senthil Kumaran




On Tuesday, June 16, 2015 at 5:55 PM, Noonan wrote:

> Sorry my last email sent prematurely, I'm not sure how. I was using a hotkey for pasing when it accidently sent.
>  
> I'm running Python version:
>  
> 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit (AMD64)]
>  
> When I do a .findall or .find on an Element object of an ElementTree from xml.etree, xpath queries (of the format './/<tagname>') aren't letting me retrieve children that aren't direct descendants of the Element object. Also, the documentation doesn't clearly show/when how to use XPath queries, it just mentions that you can use them instead. A lot of python documentation is like this and it leads to a lot of tinkering and then frustration when it doesn't work. Stack overflow said the same solution, but really, I think it's sad when your documentation needs stack overflow for clarification. Documentation is by no means fast, but the depth should be better than a quick search on Google/Bing.  
>  
> This page is the one I used to read up on it. But I actually found better depth/examples in StackOverflow or the site of the guy that I think wrote Etree before you guys integrated it into Python.  
>  
> https://docs.python.org/3/library/xml.etree.elementtree.html?highlight=xml
>  
> Thanks!
>  
> -Eric
>  
> _______________________________________________
> docs mailing list
> docs at python.org (mailto: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/20150617/81e58d93/attachment.html>

From report at bugs.python.org  Wed Jun 17 16:16:02 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Jun 2015 14:16:02 +0000
Subject: [docs] [issue24460] urlencode() of dictionary not as expected
In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za>
Message-ID: <1434550562.85.0.377691802986.issue24460@psf.upfronthosting.co.za>


R. David Murray added the comment:

That behavior is complex enough that I think it would be worth adding an example of it to the examples section (and maybe linking directly from the doseq explanation to that specific example).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jun 17 16:27:39 2015
From: report at bugs.python.org (David Rueter)
Date: Wed, 17 Jun 2015 14:27:39 +0000
Subject: [docs] [issue24460] urlencode() of dictionary not as expected
In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za>
Message-ID: <1434551259.8.0.384206646092.issue24460@psf.upfronthosting.co.za>


David Rueter added the comment:

Ah hah! Indeed, urlencode() does work on dictionaries as expected when doseq=True. Thank you for clarifying.

FWIW I had read the documentation and the referenced examples multiple times. I would like to make a few documentation suggestions for clarity.

1 ) Update https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlencode 

Where documentation currently says: "When a sequence of two-element tuples is used as the query argument, the first element of each tuple is a key and the second is a value. The value element in itself can be a sequence and in that case, if the optional parameter doseq is evaluates to True, individual key=value pairs separated by '&' are generated for each element of the value sequence for the key. The order of parameters in the encoded string will match the order of parameter tuples in the sequence."

Perhaps instead the following would be more clear:  "The query argument may be a sequence of two-element tuples where the first element of each tuple is a key and the second is a value.  However the optional parameter doseq must then be set to True in order to reliably generate individual key=value pairs separated by '&' for each element of the value sequence for the key, and to preserve the sequence of the elements in the query parameter."

2) Update https://docs.python.org/3/library/urllib.request.html#urllib-examples

The examples are referenced from the documentation: "Refer to urllib examples to find out how urlencode method can be used for generating query string for a URL or data for POST."  However the example page provides contradictory information and examples for this specific use case.

Currently the examples page says:  "The urllib.parse.urlencode() function takes a mapping or sequence of 2-tuples and returns a string in this format. It should be encoded to bytes before being used as the data parameter. The charset parameter in Content-Type header may be used to specify the encoding. If charset parameter is not sent with the Content-Type header, the server following the HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1 encoding. It is advisable to use charset parameter with encoding used in Content-Type header with the Request."

Perhaps instead the following would be more clear:  "The urllib.parse.urlencode() query parameter can accept a mapping or sequence of 2-tuples and return a string in this format if the optional parameter doseq is set to True. It should be encoded to bytes before being used as the query parameter. The charset parameter in Content-Type header may be used to specify the encoding. If charset parameter is not sent with the Content-Type header, the server following the HTTP 1.1 recommendation may assume that the data is encoded in ISO-8859-1 encoding. It is advisable to use charset parameter with encoding used in Content-Type header with the Request."

3) Also on the example page, there are examples of urlencode operating on dictionaries where doseq is not provided. This is confusing.  It would be better to show doseq = True:

Here is an example session that uses the GET method to retrieve a URL containing parameters:
...
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})
...
The following example uses the POST method instead. Note that params output from urlencode is encoded to bytes before it is sent to urlopen as data:
...
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0})

I suggest that these examples read:
>>> data = urllib.parse.urlencode({'spam': 1, 'eggs': 2, 'bacon': 0}, doseq=true)

----------

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

From report at bugs.python.org  Wed Jun 17 18:52:45 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 17 Jun 2015 16:52:45 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1434559965.08.0.225666222717.issue24439@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Martin, thanks a lot for the feedback and patch! I'll review the patch when issue24400 lands.

----------
assignee: docs at python -> yselivanov
nosy: +ncoghlan

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

From adrienplg at gmail.com  Thu Jun 18 08:10:11 2015
From: adrienplg at gmail.com (Adrien Pouligny)
Date: Thu, 18 Jun 2015 06:10:11 -0000
Subject: [docs] Python doc link broken
Message-ID: <AAFC69FE-F04C-429E-A2B9-617E1CDD885B@gmail.com>

Hi,

The links to download the documentation are broken and return a 404 error.

Thanks,
Adrien

From noonanes at gmail.com  Wed Jun 17 18:10:15 2015
From: noonanes at gmail.com (Noonan)
Date: Wed, 17 Jun 2015 09:10:15 -0700
Subject: [docs] (correction)Bug in ETree
In-Reply-To: <20D01178D105409DA4973C36B21ECE41@uthcode.com>
References: <CADJH+11wtpbn+K1yVgp90eO-aNCYBR-xzi92=aZZxuo9SsX8MQ@mail.gmail.com>
 <20D01178D105409DA4973C36B21ECE41@uthcode.com>
Message-ID: <CADJH+11OnHAwz_YB4ZuRJmGO9sF1QCj2z7aEzkcXRx-yQKWM=g@mail.gmail.com>

>From what I see, it's working fine for you, but I'm running an older
version of Python. THis version of python is shipped with the VHDs my
company packages for maintenance. Do you know if this was fixed since
October?

On Wed, Jun 17, 2015 at 6:10 AM, Senthil Kumaran <senthil at uthcode.com>
wrote:

> Hello Noonan,
>
> In general, I agree that docs could see improvement in listing examples.
>
> Specifically what was the bug in ET object?s .findall or .find ?
>
> Here I use the example listed in the docs and works fine for me.
>
> $ ./python.exe
> Python 3.4.3+ (3.4:3ded282f9615, Jun 17 2015, 06:05:20)
> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import xml.etree.ElementTree as ET
> >>> tree = ET.parse('country_data.xml')
> >>> root = tree.getroot()
> >>> root.findall(".")
> [<Element 'data' at 0x10ea87b88>]
> >>> root.findall("./country/neighbor")
> [<Element 'neighbor' at 0x10eb63868>, <Element 'neighbor' at 0x10eb638b8>,
> <Element 'neighbor' at 0x10eb63a48>, <Element 'neighbor' at 0x10eb63bd8>,
> <Element 'neighbor' at 0x10eb63c28>]
> >>> root.findall(".//year/..[@name='Singapore']")
> [<Element 'country' at 0x10eb63908>]
> >>> root.findall(".//*[@name='Singapore']/year")
> [<Element 'year' at 0x10eb639a8>]
> >>> root.findall(".//neighbor[2]")
> [<Element 'neighbor' at 0x10eb638b8>, <Element 'neighbor' at 0x10eb63c28>]
>
>
> Thanks,
> Senthil
>
> --
> Senthil Kumaran
>
> On Tuesday, June 16, 2015 at 5:55 PM, Noonan wrote:
>
> Sorry my last email sent prematurely, I'm not sure how. I was using a
> hotkey for pasing when it accidently sent.
>
> I'm running Python version:
>
> 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit
> (AMD64)]
>
> When I do a .findall or .find on an Element object of an ElementTree from
> xml.etree, xpath queries (of the format './/<tagname>') aren't letting me
> retrieve children that aren't direct descendants of the Element object.
> Also, the documentation doesn't clearly show/when how to use XPath queries,
> it just mentions that you can use them instead. A lot of python
> documentation is like this and it leads to a lot of tinkering and then
> frustration when it doesn't work. Stack overflow said the same solution,
> but really, I think it's sad when your documentation needs stack overflow
> for clarification. Documentation is by no means fast, but the depth should
> be better than a quick search on Google/Bing.
>
> This page is the one I used to read up on it. But I actually found better
> depth/examples in StackOverflow or the site of the guy that I think wrote
> Etree before you guys integrated it into Python.
>
> https://docs.python.org/3/library/xml.etree.elementtree.html?highlight=xml
>
> Thanks!
>
> -Eric
>
> _______________________________________________
> 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/20150617/516daa5c/attachment.html>

From noonanes at gmail.com  Wed Jun 17 20:03:36 2015
From: noonanes at gmail.com (Noonan)
Date: Wed, 17 Jun 2015 11:03:36 -0700
Subject: [docs] (correction)Bug in ETree
In-Reply-To: <CADJH+11OnHAwz_YB4ZuRJmGO9sF1QCj2z7aEzkcXRx-yQKWM=g@mail.gmail.com>
References: <CADJH+11wtpbn+K1yVgp90eO-aNCYBR-xzi92=aZZxuo9SsX8MQ@mail.gmail.com>
 <20D01178D105409DA4973C36B21ECE41@uthcode.com>
 <CADJH+11OnHAwz_YB4ZuRJmGO9sF1QCj2z7aEzkcXRx-yQKWM=g@mail.gmail.com>
Message-ID: <CADJH+104gQ5UfD9fx+517-od92JgHjjsouVULr03xVMsOiSdpA@mail.gmail.com>

Actually the problem was on my end,

XML

<EVENT>

<VmEventLog xmlns:auto-ns2='http://schemas.microsoft.com/win/2004/08/events'
xmlns='http://www.microsoft.com/Windows/Virtualization/Events'>
<VmName>b9be59fa-251f-4d76-bfa0-d9e682aad571</VmName><VmId>5B8C5EC7-D265-49E0-98E3-77D7E168AA06</VmId>

</VMEventLog>
</EVENT>

The VMName tag is what I was trying to pull and the VMName tag implicitly
has {http://www.microsoft.com/Windows/Virtualization/Events} prepended from
the parent in its tag name, so instead of searching for VmName I had to
call the api with {
http://www.microsoft.com/Windows/Virtualization/Events}VmName. I guess
that's a piece of XML I didn't pick up. I didn't know what the xmlns
attribute does.

Sorry.


-Eric


On Wed, Jun 17, 2015 at 9:10 AM, Noonan <noonanes at gmail.com> wrote:

> From what I see, it's working fine for you, but I'm running an older
> version of Python. THis version of python is shipped with the VHDs my
> company packages for maintenance. Do you know if this was fixed since
> October?
>
> On Wed, Jun 17, 2015 at 6:10 AM, Senthil Kumaran <senthil at uthcode.com>
> wrote:
>
>> Hello Noonan,
>>
>> In general, I agree that docs could see improvement in listing examples.
>>
>> Specifically what was the bug in ET object?s .findall or .find ?
>>
>> Here I use the example listed in the docs and works fine for me.
>>
>> $ ./python.exe
>> Python 3.4.3+ (3.4:3ded282f9615, Jun 17 2015, 06:05:20)
>> [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import xml.etree.ElementTree as ET
>> >>> tree = ET.parse('country_data.xml')
>> >>> root = tree.getroot()
>> >>> root.findall(".")
>> [<Element 'data' at 0x10ea87b88>]
>> >>> root.findall("./country/neighbor")
>> [<Element 'neighbor' at 0x10eb63868>, <Element 'neighbor' at
>> 0x10eb638b8>, <Element 'neighbor' at 0x10eb63a48>, <Element 'neighbor' at
>> 0x10eb63bd8>, <Element 'neighbor' at 0x10eb63c28>]
>> >>> root.findall(".//year/..[@name='Singapore']")
>> [<Element 'country' at 0x10eb63908>]
>> >>> root.findall(".//*[@name='Singapore']/year")
>> [<Element 'year' at 0x10eb639a8>]
>> >>> root.findall(".//neighbor[2]")
>> [<Element 'neighbor' at 0x10eb638b8>, <Element 'neighbor' at 0x10eb63c28>]
>>
>>
>> Thanks,
>> Senthil
>>
>> --
>> Senthil Kumaran
>>
>> On Tuesday, June 16, 2015 at 5:55 PM, Noonan wrote:
>>
>> Sorry my last email sent prematurely, I'm not sure how. I was using a
>> hotkey for pasing when it accidently sent.
>>
>> I'm running Python version:
>>
>> 3.4.2 (v3.4.2:ab2c023a9432, Oct  6 2014, 22:16:31) [MSC v.1600 64 bit
>> (AMD64)]
>>
>> When I do a .findall or .find on an Element object of an ElementTree from
>> xml.etree, xpath queries (of the format './/<tagname>') aren't letting me
>> retrieve children that aren't direct descendants of the Element object.
>> Also, the documentation doesn't clearly show/when how to use XPath queries,
>> it just mentions that you can use them instead. A lot of python
>> documentation is like this and it leads to a lot of tinkering and then
>> frustration when it doesn't work. Stack overflow said the same solution,
>> but really, I think it's sad when your documentation needs stack overflow
>> for clarification. Documentation is by no means fast, but the depth should
>> be better than a quick search on Google/Bing.
>>
>> This page is the one I used to read up on it. But I actually found better
>> depth/examples in StackOverflow or the site of the guy that I think wrote
>> Etree before you guys integrated it into Python.
>>
>> https://docs.python.org/3/library/xml.etree.elementtree.html?highlight=xml
>>
>> Thanks!
>>
>> -Eric
>>
>> _______________________________________________
>> 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/20150617/ef25b10f/attachment.html>

From zhj7032 at 163.com  Wed Jun 17 09:16:00 2015
From: zhj7032 at 163.com (=?GBK?B?1ty6+r2o?=)
Date: Wed, 17 Jun 2015 15:16:00 +0800 (CST)
Subject: [docs] seek help for python problem
Message-ID: <36424185.8df6.14e005fe168.Coremail.zhj7032@163.com>

Dear Mr./Miss.:
I'm a graduate student of Fudan University in China. Recently I install Wincoot software and launch it, but find a problem saying Key 99 not found in <python> key bindings. Please help me with that.
Thank you so much!


Sincerely yours, 
Hj Zhou
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150617/41233b60/attachment-0001.html>

From report at bugs.python.org  Thu Jun 18 12:35:57 2015
From: report at bugs.python.org (Tal Einat)
Date: Thu, 18 Jun 2015 10:35:57 +0000
Subject: [docs] [issue23020] New matmul operator crashes modules compiled
 with CPython3.4
In-Reply-To: <1418128303.35.0.105853053103.issue23020@psf.upfronthosting.co.za>
Message-ID: <1434623757.7.0.585655636063.issue23020@psf.upfronthosting.co.za>


Changes by Tal Einat <taleinat at gmail.com>:


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

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

From techtonik at gmail.com  Thu Jun 18 13:33:15 2015
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 18 Jun 2015 14:33:15 +0300
Subject: [docs] make_server host parameter in underdocumented
Message-ID: <CAPkN8xLQKoJ-XiOHR41-eNKnHyd0Lzgs2tmDZT1c9_gZ7J6Fyw@mail.gmail.com>

Hi,

In https://docs.python.org/2/library/wsgiref.html#wsgiref.simple_server.make_server
example mentions host='', but doesn't clarify if that will make server
listen on localhost or on all interfaces.

-- 
anatoly t.

From report at bugs.python.org  Thu Jun 18 16:33:16 2015
From: report at bugs.python.org (alanf)
Date: Thu, 18 Jun 2015 14:33:16 +0000
Subject: [docs] [issue24466] extend_path explanation in documentation is
	ambiguous
Message-ID: <1434637996.53.0.698059319376.issue24466@psf.upfronthosting.co.za>


New submission from alanf:

The description of pkgutil.extend_path in the doc (e.g., https://docs.python.org/2/library/pkgutil.html , https://docs.python.org/3/library/pkgutil.html ) is so ambiguous that I had to run a test to understand its behavior.

The doc says:

This will add to the package?s __path__ all subdirectories of directories on sys.path named after the package.

It wasn't clear to me how this should be parsed. Using parentheses to group the clauses, there's this possibility :

(1) This will add to the package?s __path__ all (subdirectories of directories on sys.path) named after the package.

That is, given all subdirectories of directories on sys.path, find the ones that are named after the package, and add them to the package's __path__.

or:

(2) This will add to the package?s __path__ all subdirectories of (directories on sys.path named after the package).

That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__.

or: 

(3) This will add to the package?s __path__ all subdirectories of ((directories on sys.path) named after the package).

That is, given all directories on sys.path that are named after the package, add all their subdirectories to the package's __path__.

or:

(4) This will add to the package?s __path__ all (subdirectories of (directories on sys.path)) named after the package.

That is, given all directories on sys.path, add any of their subdirectories that are named after the package to the package's __path__.

It was also unclear to me whether the subdirectories were meant to be traversed recursively.

My testing indicates that (4) is the correct parse, and that the subdirectories are not meant to be traversed recursively.

I suggest this wording: For each directory on sys.path that has a subdirectory that matches the package name, add the subdirectory to the package's __path__.

----------
assignee: docs at python
components: Documentation
messages: 245468
nosy: alanf, docs at python
priority: normal
severity: normal
status: open
title: extend_path explanation in documentation is ambiguous
type: enhancement
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri Jun 19 00:24:48 2015
From: report at bugs.python.org (Brandon Milam)
Date: Thu, 18 Jun 2015 22:24:48 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
 not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1434666287.8.0.482260618167.issue21297@psf.upfronthosting.co.za>


Brandon Milam added the comment:

This is my first attempt at working with the test suite but I believe this is what you were asking for. Due to this being my first attempt at writing tests I have included it as a separate patch file. Any further changes just let me know.

----------
Added file: http://bugs.python.org/file39732/skipinitialspace_test.patch

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

From report at bugs.python.org  Fri Jun 19 19:05:37 2015
From: report at bugs.python.org (Zahari Dim)
Date: Fri, 19 Jun 2015 17:05:37 +0000
Subject: [docs] [issue24475] The docs never define what a pool "task" is
Message-ID: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za>


New submission from Zahari Dim:

See:

http://stackoverflow.com/questions/30943161/multiprocessing-pool-with-maxtasksperchild-produces-equal-pids

The documentation never makes clear what a "task" in the context of Pool.map. At best, it says:

"This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. The (approximate) size of these chunks can be specified by setting chunksize to a positive integer."

in the map documentation. However it does not say how this chunks are calculated by default, making the maxtasksperchild argument not very useful. The fact that a function evaluated by map is not a "task" should be much clearer in the documentation.

Also, in the examples, such as:

 with multiprocessing.Pool(PROCESSES) as pool:
        #
        # Tests
        #

        TASKS = [(mul, (i, 7)) for i in range(10)] + \
                [(plus, (i, 8)) for i in range(10)]

        results = [pool.apply_async(calculate, t) for t in TASKS]
        imap_it = pool.imap(calculatestar, TASKS)
        imap_unordered_it = pool.imap_unordered(calculatestar, TASKS)

TASKS are not actually "tasks" but rather "task groups".

----------
assignee: docs at python
components: Documentation
messages: 245509
nosy: Zahari.Dim, docs at python
priority: normal
severity: normal
status: open
title: The docs never define what a pool "task" is
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 19 21:22:08 2015
From: report at bugs.python.org (levkivskyi)
Date: Fri, 19 Jun 2015 19:22:08 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434741728.83.0.147732201218.issue24129@psf.upfronthosting.co.za>


levkivskyi added the comment:

Should I invite someone to review the patch or just wait? How the things are organized here?

----------

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

From report at bugs.python.org  Fri Jun 19 21:47:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Jun 2015 19:47:00 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434743220.26.0.736367463071.issue24129@psf.upfronthosting.co.za>


R. David Murray added the comment:

In this particular case, just wait (now that you have pinged the issue).  Raymond is the most likely person to figure out how to phrase this better, but it isn't obvious what the best way to explain this is.  I don't think your explanation is exactly correct, but I don't know enough about how class name resolution is implemented to explain what's wrong with it, I just know it doesn't feel quite right :)  (Of course, I might be wrong.)

Ping the issue again in a few weeks if there is no action.

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

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

From report at bugs.python.org  Fri Jun 19 21:58:54 2015
From: report at bugs.python.org (Eric Snow)
Date: Fri, 19 Jun 2015 19:58:54 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434743934.37.0.259004408532.issue24129@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've left a review.  That said, we need to be sure this behavior is intentional.  The fact that it skips the "nonlocal" scope(s) smells like a bug to me.

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

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

From report at bugs.python.org  Fri Jun 19 22:15:39 2015
From: report at bugs.python.org (Ned Deily)
Date: Fri, 19 Jun 2015 20:15:39 +0000
Subject: [docs] [issue24475] The docs never define what a pool "task" is
In-Reply-To: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za>
Message-ID: <1434744939.59.0.720817883957.issue24475@psf.upfronthosting.co.za>


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


----------
nosy: +davin, sbt
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun 20 00:50:16 2015
From: report at bugs.python.org (levkivskyi)
Date: Fri, 19 Jun 2015 22:50:16 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434754216.06.0.776422121577.issue24129@psf.upfronthosting.co.za>


levkivskyi added the comment:

Eric, thank you for the review. I have incorporated proposed changes in second version of the patch.
Concerning the question whether it is a bug, it also smells like a bug to me, but Guido said 13 years ago that this should not be changed: https://mail.python.org/pipermail/python-dev/2002-April/023428.html and it stayed like this since then. However, things changed a bit in Python 3.4 with the introduction of the LOAD_CLASSDEREF opcode. Perhaps, we should ask Guido again :) What do you think?

----------
Added file: http://bugs.python.org/file39744/classdoc_v2.patch

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

From report at bugs.python.org  Sat Jun 20 01:18:56 2015
From: report at bugs.python.org (Eric Snow)
Date: Fri, 19 Jun 2015 23:18:56 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434755936.93.0.501794140707.issue24129@psf.upfronthosting.co.za>


Eric Snow added the comment:

I expect you'll get the same response, especially given potential (though slight) chance for backward-compatibility issues.  What I find curious is Guido's reference to "the rule that class bodies don't play the nested
scopes game" (and his subsequent explanation).  Is there something about that in the language reference?  If so, the patch should be updated to link to that section.  If not then it should be added to the language reference.

That said, it wouldn't hurt to ask on python-dev, particularly in light of that new opcode.

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

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

From report at bugs.python.org  Sat Jun 20 03:29:19 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Jun 2015 01:29:19 +0000
Subject: [docs] [issue24460] urlencode() of dictionary not as expected
In-Reply-To: <1434523722.13.0.839663684524.issue24460@psf.upfronthosting.co.za>
Message-ID: <1434763759.4.0.0553450565888.issue24460@psf.upfronthosting.co.za>


Martin Panter added the comment:

1. urlencode(): I agree the documentation is unclear. But David Rueter?s suggestion does not help much. I think doseq=True is meant to also work for a mapping query (as in original post), and is not required in the sequence-of-tuples mode if each tuple has a single parameter value. Perhaps something like this could work instead:

?When a sequence of two-element tuples is used as *query*, the first element of each tuple is a key and the second specifies one or more values. If *doseq* is true, each *query* (mapping or sequence) item can specify a sequence of values; if *doseq* is false (the default), each item specifies a single value. The order of parameters in the encoded string will match the order of items in *query* and the order of values in an item.?

2. urlopen(data=...) and Request(data=...): I don?t see the contradiction. It looks like David Rueter?s suggestion only changes the first sentence, to say doseq=True is required to get the urlencoded format, but this is not required. See also Issue 23360 about my own problems with this bit of the documentation.

3. Examples: Again, I do not see why doseq=True should be shown when it is simpler without. But an example of when it is useful would be good, as R David Murray suggested.

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

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

From report at bugs.python.org  Sat Jun 20 08:25:51 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Jun 2015 06:25:51 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
 what shell=True does
In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>
Message-ID: <1434781551.42.0.507283620628.issue20344@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it might be better to leave the platform-specific details in the full Popen description, not under Frequently Used Arguments. I suggest to use 20344_4.patch:

* Move existing pointer to Popen constructor details up to top of section
* Explain the escaping and quoting of a sequence only applies to Windows
* Remove claim that a string simply names a program without arguments; appears to be only half true under Windows
* Clarify shell=True command is normally a string, not a sequence
* Drop new description of Unix shell argument sequence in favour of existing description under Popen
* Move warning about Windows shell argument sequence under Popen

----------
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file39747/20344_4.patch

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

From report at bugs.python.org  Sat Jun 20 09:02:57 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Jun 2015 07:02:57 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434783777.11.0.762876377533.issue24129@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The "normal rules for name resolution" reference here is referring to the name lookup rules as they existed prior to the introduction of lexical scoping for functions. It's a dated way of describing it, as the current behaviour of functions has now been around long enough that a lot of folks will consider *that* normal, and the module, class and exec scoping rules to be the unusual case (as levkivskyi has here).

However, I've spent far too many hours staring at CPython compiler internals to be able to suggest a helpful rewording that will make sense to folks that *haven't* done that, so I'll instead provide the relevant background info to see if others can come up with a concise rewording of the reference docs :)

Prior to Python 2.1, Python didn't have closure support, and hence nested functions and classes couldn't see variables in outer scopes at all - they could see their local scope, the module globals, and the builtins. That changed with the introduction of nested scopes as a __future__ import in Python 2.1 and the default behaviour in 2.2: https://www.python.org/dev/peps/pep-0227/

As a result of that change, the compiler now keeps track of "function locals" at compile time, and *emits different code for references to them*. Where early versions of CPython only had LOAD_NAME and LOAD_GLOBAL in the bytecode, these days we now also have LOAD_FAST (function local), LOAD_CLOSURE (function local referenced as a nonlocal), LOAD_DEREF (function nonlocal) and LOAD_CLASSDEREF (class nonlocal). The latter four opcodes will *only* be emitted in a function body - they'll never be emitted for module level code (include the bodies of module level class definitions). If you attempt to reference a function local before a value has been assigned, you'll get UnboundLocalError rather than NameError.

The name lookup rules used for execution of class bodies are thus the same ones used for the exec() builtin with two namespace arguments: there is a local namespace where name assignments happen, and name lookups check the local, global and builtin namespaces in that order. The code is executed line by line, so if a name is referenced before it has been assigned locally, then it may find a global or builtin of that name. Classes that are defined inside a function may refer to lexically scoped local variables from the class body, but class variables are not themselves visible to function definitions nested inside a class scope (i.e. method definitions).

These rules are also used for module level execution and exec() with a single namespace argument, except that the local namespace and the global namespace refer to the same namespace.

----------

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

From report at bugs.python.org  Sat Jun 20 09:10:26 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Jun 2015 07:10:26 +0000
Subject: [docs] [issue21279] str.translate documentation incomplete
In-Reply-To: <1397696482.87.0.486412592823.issue21279@psf.upfronthosting.co.za>
Message-ID: <1434784226.54.0.961387288542.issue21279@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v6 looks okay, so I think it is ready to commit.

----------
stage: patch review -> commit review
versions: +Python 3.6

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

From report at bugs.python.org  Sat Jun 20 09:14:09 2015
From: report at bugs.python.org (levkivskyi)
Date: Sat, 20 Jun 2015 07:14:09 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434784449.21.0.645004703882.issue24129@psf.upfronthosting.co.za>


levkivskyi added the comment:

Eric, the "rule" that classes don't play the nested scopes game is explained at beginning of the same section, but the explanation is "one sided" it only explains that names defined in classes are not visible inside functions.
Nick, thank you for the thorough explanation. I will try to improve the wording. It looks like a bit more substantial changes are needed.

----------

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

From report at bugs.python.org  Sat Jun 20 10:24:30 2015
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 20 Jun 2015 08:24:30 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434788670.41.0.786904910717.issue24129@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Related to http://bugs.python.org/issue19979 and others mentioned there.

----------
nosy: +arigo

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

From report at bugs.python.org  Sat Jun 20 14:00:48 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Jun 2015 12:00:48 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1434801648.68.0.699010370724.issue14911@psf.upfronthosting.co.za>


Martin Panter added the comment:

See Issue 13213 for some analysis of the behaviour of different combinations of arguments.

The docstring should be changed if necessary, but in this case I don?t see what needs changing. The argument names perhaps, just for consistency?s sake?

----------
nosy: +vadmium
versions: +Python 3.4, Python 3.5, Python 3.6 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jun 20 14:02:41 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 20 Jun 2015 12:02:41 +0000
Subject: [docs] [issue13213] generator.throw() behavior
In-Reply-To: <1318961803.9.0.966531589594.issue13213@psf.upfronthosting.co.za>
Message-ID: <1434801761.09.0.658244580138.issue13213@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> generator.throw() documentation inaccurate

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

From report at bugs.python.org  Sat Jun 20 15:55:42 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 20 Jun 2015 13:55:42 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434808542.24.0.0130776914893.issue24129@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Eric, I have submitted a new version of the patch. Could you please make a review? Nick, it will be interesting to hear your opinion too.

I tried to follow such rules:
1. Explanation should be succinct yet clear
2. It should tell as less as possible about implementation details
3. Minimize necessary changes

It turns out that these goals could be achieved by 
a) simply reshuffling and structuring the existing text to separate the exceptions (classes, etc.) from the general case;
and
b) adding some minor clarifications.

Armin, thank you for the link. It looks like this is a really old discussion.

PS: Unfortunately, the diff after reshuffling of the text looks big and cumbersome, in fact the changes are minimal.

----------
Added file: http://bugs.python.org/file39749/classdoc-v3.patch

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

From ericsnowcurrently at gmail.com  Fri Jun 19 21:57:02 2015
From: ericsnowcurrently at gmail.com (ericsnowcurrently at gmail.com)
Date: Fri, 19 Jun 2015 19:57:02 -0000
Subject: [docs] Incorrect (misleading) statement in the execution model
 documentation (issue 24129)
Message-ID: <20150619195702.24978.99819@psf.upfronthosting.co.za>


http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst
File Doc/reference/executionmodel.rst (right):

http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst#newcode148
Doc/reference/executionmodel.rst:148: Free variables follow the normal
rules for name resolution,
It may be more clear to say:

These references follow the normal rules for name resolution with one
exception.  Unbound local variables are looked up in the global
namespace. ...

http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst#newcode149
Doc/reference/executionmodel.rst:149: while unbound local variables are
looked up in the global namespace.
If we stick with the current working, I'd suggest starting a new
sentence at "while".

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

From ncoghlan at gmail.com  Sat Jun 20 16:08:18 2015
From: ncoghlan at gmail.com (ncoghlan at gmail.com)
Date: Sat, 20 Jun 2015 14:08:18 -0000
Subject: [docs] Incorrect (misleading) statement in the execution model
 documentation (issue 24129)
Message-ID: <20150620140818.24437.19695@psf.upfronthosting.co.za>

This looks like a solid improvement to me, just a couple of minor tweaks
suggested.


http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst
File Doc/reference/executionmodel.rst (right):

http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst#newcode108
Doc/reference/executionmodel.rst:108: name refers to a local variable
that has not been bound, an
For the second sentence, I'd suggest: "If the current scope is a
function scope, and the name refers to a local variable that has not yet
been bound to a value at the point where the name is used, an
:exc:`UnboundLocalError` exception is raised."

http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst#newcode135
Doc/reference/executionmodel.rst:135: to previously bound variables in
the nearest enclosing scope excluding globals.
I'd change the ending here to: "nearest enclosing function scope.
:exc:`SyntaxError` is raised at compile time if the given name does not
exist in any enclosing function scope."

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

From report at bugs.python.org  Sun Jun 21 15:57:11 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 21 Jun 2015 13:57:11 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434895031.28.0.617519115266.issue24129@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Nick, thank you for a review, I have made a new patch with all the previous comments taken into account.

----------
Added file: http://bugs.python.org/file39759/classdoc-v4.patch

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

From report at bugs.python.org  Mon Jun 22 00:02:30 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 21 Jun 2015 22:02:30 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
 default scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <1434924150.59.0.87222781342.issue23684@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM. Added a minor question on Rietveld.

----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag
stage: patch review -> commit review

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

From berker.peksag at gmail.com  Mon Jun 22 00:01:42 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Sun, 21 Jun 2015 22:01:42 -0000
Subject: [docs] urlparse() documentation does not account for default scheme
	(issue 23684)
Message-ID: <20150621220142.9944.64171@psf.upfronthosting.co.za>

The patch looks good to me. You don't need to send another patch. I can
do the last modifications and apply it.

Thanks!


http://bugs.python.org/review/23684/diff/14992/Doc/library/urllib.parse.rst
File Doc/library/urllib.parse.rst (right):

http://bugs.python.org/review/23684/diff/14992/Doc/library/urllib.parse.rst#newcode95
Doc/library/urllib.parse.rst:95: | :attr:`scheme`   | 0     | URL scheme
specifier     | *scheme* argument    |
"argument" looks incorrect to me. Can this be "value of *scheme*",
"*scheme* parameter" or something else?

See also
https://docs.python.org/3/faq/programming.html#faq-argument-vs-parameter

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

From vadmium+py at gmail.com  Mon Jun 22 01:31:25 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 21 Jun 2015 23:31:25 -0000
Subject: [docs] urlparse() documentation does not account for default
 scheme (issue 23684)
Message-ID: <20150621233125.9908.84573@psf.upfronthosting.co.za>

Reviewers: berkerpeksag,


http://bugs.python.org/review/23684/diff/14992/Doc/library/urllib.parse.rst
File Doc/library/urllib.parse.rst (right):

http://bugs.python.org/review/23684/diff/14992/Doc/library/urllib.parse.rst#newcode95
Doc/library/urllib.parse.rst:95: | :attr:`scheme`   | 0     | URL scheme
specifier     | *scheme* argument    |
On 2015/06/22 00:01:42, berkerpeksag wrote:
> "argument" looks incorrect to me. Can this be "value of *scheme*",
"*scheme*
> parameter" or something else?

Yes ?*scheme* parameter? would be good. Originally I though ?argument?
would be more correct, but I agree it feels strange when we are not
talking about a concrete value.

Demian suggested ?value of *scheme*?, but I though this might sound like
the attribute ?scheme? defaults to itself.



Please review this at http://bugs.python.org/review/23684/

Affected files:
  Doc/library/urllib.parse.rst
  Lib/test/test_urlparse.py


# HG changeset patch
# Parent 04162e06323f369c1468d2009b4d8ba6805a6b0c

diff -r 04162e06323f Doc/library/urllib.parse.rst
--- a/Doc/library/urllib.parse.rst	Sun May 31 09:16:13 2015 +0300
+++ b/Doc/library/urllib.parse.rst	Sun May 31 10:15:38 2015 +0000
@@ -76,13 +76,15 @@
        ParseResult(scheme='', netloc='', path='help/Python.html', params='',
                   query='', fragment='')
 
-   If the *scheme* argument is specified, it gives the default addressing
-   scheme, to be used only if the URL does not specify one.  The default value for
-   this argument is the empty string.
+   The *scheme* argument gives the default addressing scheme, to be
+   used only if the URL does not specify one.  It should be the same type
+   (text or bytes) as *urlstring*, except that the default value ``''`` is
+   always allowed, and is automatically converted to ``b''`` if appropriate.
 
    If the *allow_fragments* argument is false, fragment identifiers are not
-   recognized and parsed as part of the preceding component.  The default value
-   for this argument is :const:`True`.
+   recognized.  Instead, they are parsed as part of the path, parameters
+   or query component, and :attr:`fragment` is set to the empty string in
+   the return value.
 
    The return value is actually an instance of a subclass of :class:`tuple`.  This
    class has the following additional read-only convenience attributes:
@@ -90,7 +92,7 @@
    +------------------+-------+--------------------------+----------------------+
    | Attribute        | Index | Value                    | Value if not present |
    +==================+=======+==========================+======================+
-   | :attr:`scheme`   | 0     | URL scheme specifier     | empty string         |
+   | :attr:`scheme`   | 0     | URL scheme specifier     | *scheme* argument    |
    +------------------+-------+--------------------------+----------------------+
    | :attr:`netloc`   | 1     | Network location part    | empty string         |
    +------------------+-------+--------------------------+----------------------+
@@ -206,7 +208,7 @@
    +------------------+-------+-------------------------+----------------------+
    | Attribute        | Index | Value                   | Value if not present |
    +==================+=======+=========================+======================+
-   | :attr:`scheme`   | 0     | URL scheme specifier    | empty string         |
+   | :attr:`scheme`   | 0     | URL scheme specifier    | *scheme* argument    |
    +------------------+-------+-------------------------+----------------------+
    | :attr:`netloc`   | 1     | Network location part   | empty string         |
    +------------------+-------+-------------------------+----------------------+
diff -r 04162e06323f Lib/test/test_urlparse.py
--- a/Lib/test/test_urlparse.py	Sun May 31 09:16:13 2015 +0300
+++ b/Lib/test/test_urlparse.py	Sun May 31 10:15:38 2015 +0000
@@ -686,6 +686,47 @@
         self.assertEqual(urllib.parse.urlparse(b"x-newscheme://foo.com/stuff?query"),
                          (b'x-newscheme', b'foo.com', b'/stuff', b'', b'query', b''))
 
+    def test_default_scheme(self):
+        # Exercise the scheme parameter of urlparse() and urlsplit()
+        for func in (urllib.parse.urlparse, urllib.parse.urlsplit):
+            with self.subTest(func):
+                result = func("http://example.net/", "ftp")
+                self.assertEqual(result.scheme, "http")
+                result = func(b"http://example.net/", b"ftp")
+                self.assertEqual(result.scheme, b"http")
+                self.assertEqual(func("path", "ftp").scheme, "ftp")
+                self.assertEqual(func("path", scheme="ftp").scheme, "ftp")
+                self.assertEqual(func(b"path", scheme=b"ftp").scheme, b"ftp")
+                self.assertEqual(func("path").scheme, "")
+                self.assertEqual(func(b"path").scheme, b"")
+                self.assertEqual(func(b"path", "").scheme, b"")
+
+    def test_parse_fragments(self):
+        # Exercise the allow_fragments parameter of urlparse() and urlsplit()
+        tests = (
+            ("http:#frag", "path"),
+            ("//example.net#frag", "path"),
+            ("index.html#frag", "path"),
+            (";a=b#frag", "params"),
+            ("?a=b#frag", "query"),
+            ("#frag", "path"),
+        )
+        for url, attr in tests:
+            for func in (urllib.parse.urlparse, urllib.parse.urlsplit):
+                if attr == "params" and func is urllib.parse.urlsplit:
+                    attr = "path"
+                with self.subTest(url=url, func=func):
+                    result = func(url, allow_fragments=False)
+                    self.assertEqual(result.fragment, "")
+                    self.assertTrue(getattr(result, attr).endswith("#frag"))
+                    self.assertEqual(func(url, "", False).fragment, "")
+
+                    result = func(url, allow_fragments=True)
+                    self.assertEqual(result.fragment, "frag")
+                    self.assertFalse(getattr(result, attr).endswith("frag"))
+                    self.assertEqual(func(url, "", True).fragment, "frag")
+                    self.assertEqual(func(url).fragment, "frag")
+
     def test_mixed_types_rejected(self):
         # Several functions that process either strings or ASCII encoded bytes
         # accept multiple arguments. Check they reject mixed type input



From report at bugs.python.org  Mon Jun 22 05:43:18 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jun 2015 03:43:18 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1434944598.24.0.440643196484.issue24439@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Martin, if you want to help with the documentation, it would be great if you can help me with updating asyncio coroutines section: https://docs.python.org/3.5/library/asyncio-task.html#coroutines

----------

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

From report at bugs.python.org  Mon Jun 22 08:32:54 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Jun 2015 06:32:54 +0000
Subject: [docs] [issue23750] Clarify difference between
 os.system/subprocess.call in section "Replacing os.system()"
In-Reply-To: <1427120891.65.0.0570880238086.issue23750@psf.upfronthosting.co.za>
Message-ID: <1434954774.38.0.147192927321.issue23750@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch:

* Use different return value variable names and point out that they are encoded differently
* Add another bullet point about signal handling
* Fix os.system() documentation of the return value. My understanding is it is the C standard that does not define the return value, and Posix essentially means Unix.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39767/system-subprocess.patch

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

From report at bugs.python.org  Mon Jun 22 08:39:33 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Jun 2015 06:39:33 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1434955173.7.0.0717252234868.issue24420@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jun 22 14:00:36 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Jun 2015 12:00:36 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1434974436.12.0.0473100135758.issue24439@psf.upfronthosting.co.za>


Martin Panter added the comment:

When I update my patch I can try updating the asyncio section. However I have only had limited experience with asyncio, so feel free to suggest things to add. Here is a list of things I think may need changing:

* ?async def? routines are allowed in addition to generators in asyncio (e.g. in Task constructor)
* Other awaitables are also accepted as asyncio coroutines
* List of ?yield from? actions could be augmented with ?await?, ?async for?, etc
* The coroutines provided by asyncio are both iterable and awaitable, so they may be used with both ?yield from? and ?await?
* Change references of asyncio.async() to ensure_future()

----------

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

From report at bugs.python.org  Mon Jun 22 16:24:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 22 Jun 2015 14:24:29 +0000
Subject: [docs] =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_?=
 =?utf-8?b?4oaSIGVuc3VyZV9mdXR1cmUoKQ==?=
Message-ID: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za>


New submission from Martin Panter:

The async() function is marked as deprecated in 3.4.4. This patch replaces most references to it with references to ensure_future(). The exception is <https://docs.python.org/3.4/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_task>, which suggests using it in Python < 3.4.2.

----------
assignee: docs at python
components: Documentation, asyncio
files: ensure_future.patch
keywords: patch
messages: 245631
nosy: docs at python, gvanrossum, haypo, vadmium, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Change asyncio.async() ? ensure_future()
versions: Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39771/ensure_future.patch

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

From report at bugs.python.org  Mon Jun 22 16:56:22 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jun 2015 14:56:22 +0000
Subject: [docs] =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_?=
 =?utf-8?b?4oaSIGVuc3VyZV9mdXR1cmUoKQ==?=
In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za>
Message-ID: <1434984982.87.0.172580090102.issue24487@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Martin, I believe this was done as part of issue24180, see this commit https://hg.python.org/cpython/rev/9d9e445d25dc

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

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

From report at bugs.python.org  Mon Jun 22 17:01:27 2015
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 22 Jun 2015 15:01:27 +0000
Subject: [docs] =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_?=
 =?utf-8?b?4oaSIGVuc3VyZV9mdXR1cmUoKQ==?=
In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za>
Message-ID: <1434985287.6.0.263703186926.issue24487@psf.upfronthosting.co.za>


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


----------
resolution: not a bug -> out of date
stage: patch review -> resolved

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

From report at bugs.python.org  Mon Jun 22 20:34:53 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jun 2015 18:34:53 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1434998093.88.0.137107827783.issue24439@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi Martin,

I've left you some feedback in the code review.

> * ?async def? routines are allowed in addition to generators in asyncio (e.g. in Task constructor)

Right. I think we need to add some code samples too.

> * Other awaitables are also accepted as asyncio coroutines

Depending on where, I guess. asyncio.Task should only accept when asyncio.iscoroutine is true -- abc.Coroutine, types.GeneratorType.

> * List of ?yield from? actions could be augmented with ?await?, ?async for?, etc

Not sure what you mean here.

> * The coroutines provided by asyncio are both iterable and awaitable, so they may be used with both ?yield from? and ?await?

Right.

We also need to make sure that it's documented that in order to have "yield from native_coro()", you have to decorate the gen function with 'asyncio.coroutine'.

And we should mention that if you're targeting Python 3.5+ you should use the new syntax.

> * Change references of asyncio.async() to ensure_future()

This is already done ;)

Thanks!

----------
nosy: +asvetlov, gvanrossum, haypo

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

From report at bugs.python.org  Mon Jun 22 20:56:26 2015
From: report at bugs.python.org (Evgeny Kapun)
Date: Mon, 22 Jun 2015 18:56:26 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1434999386.51.0.613963440595.issue24129@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

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

From report at bugs.python.org  Tue Jun 23 04:58:21 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Jun 2015 02:58:21 +0000
Subject: [docs] =?utf-8?q?=5Bissue24487=5D_Change_asyncio=2Easync=28=29_?=
 =?utf-8?b?4oaSIGVuc3VyZV9mdXR1cmUoKQ==?=
In-Reply-To: <1434983069.7.0.469854953168.issue24487@psf.upfronthosting.co.za>
Message-ID: <1435028300.97.0.230813325912.issue24487@psf.upfronthosting.co.za>


Martin Panter added the comment:

There are a few references left in that revision. For instance <https://docs.python.org/3.5/library/asyncio-task.html#coroutines> still suggests scheduling a coroutine by calling async(). But depending on the context this may cause a syntax error in 3.5, so I think it should suggest calling ensure_future() instead.

----------

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

From vadmium+py at gmail.com  Tue Jun 23 08:16:05 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Tue, 23 Jun 2015 06:16:05 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue
	24439)
Message-ID: <20150623061605.16083.8521@psf.upfronthosting.co.za>

Reviewers: Yury.Selivanov,


https://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio-task.rst
File Doc/library/asyncio-task.rst (right):

https://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio-task.rst#newcode11
Doc/library/asyncio-task.rst:11: A :term:`coroutine` is
:term:`generator` that follows certain conventions.  For
On 2015/06/22 20:23:12, Yury.Selivanov wrote:
> Again, no need to reference "coroutine" term here. Coroutines in
asyncio is a
> bit broader thing than 'async def' coroutine objects defined in the
glossary. 

In my upcoming patch I have reworded this so that the glossary reference
is used in the context of native coroutines.

> We need a separate sub-section for native coroutines though.

So far, I have kept it all in the one section but expanded it to cover
both using native Python coroutines and generator-based coroutines.

https://bugs.python.org/review/24439/diff/15090/Doc/library/dis.rst
File Doc/library/dis.rst (right):

https://bugs.python.org/review/24439/diff/15090/Doc/library/dis.rst#newcode516
Doc/library/dis.rst:516: returns ``o`` if ``o`` is a native coroutine
object, or resolves
On 2015/06/22 20:23:12, Yury.Selivanov wrote:
> .. if ``o`` is a native or generator-based coroutine object ..

Replacing with ?native coroutine object or one derived from
:func:`types.coroutine` ?, to avoid confusing with PEP 342 and asyncio
generator-based coroutines.

https://bugs.python.org/review/24439/diff/15090/Doc/library/types.rst
File Doc/library/types.rst (right):

https://bugs.python.org/review/24439/diff/15090/Doc/library/types.rst#newcode283
Doc/library/types.rst:283: compatible with native coroutines.
On 2015/06/22 20:23:12, Yury.Selivanov wrote:
> This bit was also updated, please rebase.

I don?t think anything got changed here. Did you have anything in mind?

I intend to add that the returned objects are awaitable, but do not
implement __await__().

https://bugs.python.org/review/24439/diff/15090/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

https://bugs.python.org/review/24439/diff/15090/Doc/reference/datamodel.rst#newcode629
Doc/reference/datamodel.rst:629: Native coroutine objects are similar to
the objects returned by
On 2015/06/22 20:23:12, Yury.Selivanov wrote:
> Since we've merged issue 24400, I think we need to briefly document
each of
> those methods (send, close, throw) with references to generators docs
for more
> details.

I?m thinking of putting a proper full explanation of each method in a
new Native Coroutine Objects subsection near the bottom.



Please review this at https://bugs.python.org/review/24439/

Affected files:
  Doc/glossary.rst
  Doc/howto/functional.rst
  Doc/library/asyncio-task.rst
  Doc/library/asyncio.rst
  Doc/library/collections.abc.rst
  Doc/library/dis.rst
  Doc/library/inspect.rst
  Doc/library/sys.rst
  Doc/library/types.rst
  Doc/reference/compound_stmts.rst
  Doc/reference/datamodel.rst
  Doc/reference/expressions.rst



From levkivskyi at gmail.com  Sun Jun 21 15:54:03 2015
From: levkivskyi at gmail.com (levkivskyi at gmail.com)
Date: Sun, 21 Jun 2015 13:54:03 -0000
Subject: [docs] Incorrect (misleading) statement in the execution model
 documentation (issue 24129)
Message-ID: <20150621135403.28230.55751@psf.upfronthosting.co.za>

Reviewers: eric.snow, Nick Coghlan,


http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst
File Doc/reference/executionmodel.rst (right):

http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst#newcode148
Doc/reference/executionmodel.rst:148: Free variables follow the normal
rules for name resolution,
On 2015/06/19 21:57:02, eric.snow wrote:
> It may be more clear to say:
> 
> These references follow the normal rules for name resolution with one
exception.
>  Unbound local variables are looked up in the global namespace. ...

Done.

http://bugs.python.org/review/24129/diff/14851/Doc/reference/executionmodel.rst#newcode149
Doc/reference/executionmodel.rst:149: while unbound local variables are
looked up in the global namespace.
On 2015/06/19 21:57:02, eric.snow wrote:
> If we stick with the current working, I'd suggest starting a new
sentence at
> "while".

I have changed the wording here to the one proposed in the previous
comment.

http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst
File Doc/reference/executionmodel.rst (right):

http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst#newcode108
Doc/reference/executionmodel.rst:108: name refers to a local variable
that has not been bound, an
On 2015/06/20 16:08:18, Nick Coghlan wrote:
> For the second sentence, I'd suggest: "If the current scope is a
function scope,
> and the name refers to a local variable that has not yet been bound to
a value
> at the point where the name is used, an :exc:`UnboundLocalError`
exception is
> raised."

Done.

http://bugs.python.org/review/24129/diff/15117/Doc/reference/executionmodel.rst#newcode135
Doc/reference/executionmodel.rst:135: to previously bound variables in
the nearest enclosing scope excluding globals.
On 2015/06/20 16:08:18, Nick Coghlan wrote:
> I'd change the ending here to: "nearest enclosing function scope.
> :exc:`SyntaxError` is raised at compile time if the given name does
not exist in
> any enclosing function scope."

Done.



Please review this at http://bugs.python.org/review/24129/

Affected files:
  Doc/reference/executionmodel.rst



From yselivanov at gmail.com  Mon Jun 22 20:23:12 2015
From: yselivanov at gmail.com (yselivanov at gmail.com)
Date: Mon, 22 Jun 2015 18:23:12 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue 24439)
Message-ID: <20150622182312.16083.58575@psf.upfronthosting.co.za>


http://bugs.python.org/review/24439/diff/15090/Doc/howto/functional.rst
File Doc/howto/functional.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/howto/functional.rst#newcode611
Doc/howto/functional.rst:611: a more generalized form of subroutines.
I don't think we need a reference to the term here.  Coroutines defined
in the glossary section are what 'async def' functions return, not a
generic definition.

http://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio-task.rst
File Doc/library/asyncio-task.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio-task.rst#newcode11
Doc/library/asyncio-task.rst:11: A :term:`coroutine` is
:term:`generator` that follows certain conventions.  For
Again, no need to reference "coroutine" term here. Coroutines in asyncio
is a bit broader thing than 'async def' coroutine objects defined in the
glossary. 

We need a separate sub-section for native coroutines though.

http://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio.rst
File Doc/library/asyncio.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/library/asyncio.rst#newcode21
Doc/library/asyncio.rst:21: code using :term:`coroutines <coroutine>`,
Remove the ref, please.

http://bugs.python.org/review/24439/diff/15090/Doc/library/dis.rst
File Doc/library/dis.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/library/dis.rst#newcode516
Doc/library/dis.rst:516: returns ``o`` if ``o`` is a native coroutine
object, or resolves
.. if ``o`` is a native or generator-based coroutine object ..

If you look at _PyCoro_GetAwaitableIter you'll see that it tests
PyCoro_CheckExact *or* (PyCoro_CheckExact && CO_ITERABLE_COROUTINE)

http://bugs.python.org/review/24439/diff/15090/Doc/library/inspect.rst
File Doc/library/inspect.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/library/inspect.rst#newcode294
Doc/library/inspect.rst:294: Return true if the object is a native
Please rebase your patch on top of the most recent default branch. I
think I've updated some of these docs already.

http://bugs.python.org/review/24439/diff/15090/Doc/library/types.rst
File Doc/library/types.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/library/types.rst#newcode283
Doc/library/types.rst:283: compatible with native coroutines.
This bit was also updated, please rebase.

http://bugs.python.org/review/24439/diff/15090/Doc/reference/compound_stmts.rst
File Doc/reference/compound_stmts.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/reference/compound_stmts.rst#newcode671
Doc/reference/compound_stmts.rst:671: Coroutines may also be implemented
using :term:`generators <generator>`,
I don't think we need a reference to generators here, it's not relevant
to the new syntax (at least in this particular file).

http://bugs.python.org/review/24439/diff/15090/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/24439/diff/15090/Doc/reference/datamodel.rst#newcode629
Doc/reference/datamodel.rst:629: Native coroutine objects are similar to
the objects returned by
Since we've merged issue 24400, I think we need to briefly document each
of those methods (send, close, throw) with references to generators docs
for more details.

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

From report at bugs.python.org  Tue Jun 23 14:26:34 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 23 Jun 2015 12:26:34 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435062393.55.0.520607608788.issue24439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch with more improvements to the coroutine documentation, including:

* Remove expansion of ?coroutine? glossary to include generators; it was not my original intention of this bug. Perhaps this can be dealt with separately in Issue 24087 if other people agree there is a problem.
* Add Native Coroutine Objects section to /Doc/reference/datamodel.rst describing each method
* Tweak coroutine and wrapper object doc strings to avoid generator terms
* Mention native coroutines and ?await? in the asyncio Coroutines section, where the existing text only mentions generators and ?yield from?
* Also recommend native coroutines, @asyncio.coroutine for calling native coroutines, etc

I changed two of the asyncio coroutine examples to use ?async def? rather than generators. There is a third example that still uses generators which I did not change, because I would also have to update the sequence diagram.

----------
Added file: http://bugs.python.org/file39788/async-doc.v2.patch

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

From ncoghlan at gmail.com  Tue Jun 23 15:22:18 2015
From: ncoghlan at gmail.com (ncoghlan at gmail.com)
Date: Tue, 23 Jun 2015 13:22:18 -0000
Subject: [docs] Documentation for PEP 489 (issue 24458)
Message-ID: <20150623132218.27893.26253@psf.upfronthosting.co.za>

Sorry for the delay reviewing this - the beta release revealed some
aspects of the async/await changes we thought could be deferred to 3.6
really needed to be addressed for 3.5 after all.

Back on topic, I really like the revised structure for these docs.

Mostly some minor comments regarding typos and formatting, one
substantive question, but there's one substantive suggestion about
providing some rationale for why we read the module name from the spec
by default, and not from the C level definition.


http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst
File Doc/c-api/module.rst (right):

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode134
Doc/c-api/module.rst:134: or request "multi-phase initialization" by
returning definition struct itself.
Typo, should be: "... returning the definition struct ..."

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode245
Doc/c-api/module.rst:245: The distinction is similar to the __new__ and
__init__ methods of classes.
These don't need to be cross-references, but should probably be flagged
as monospace: ``__new__`` and ``__init__``.

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode263
Doc/c-api/module.rst:263: ``m_slots``. Before it is returned, the
PyModuleDef instance must be
Monospace for ``PyModuleDef``

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode276
Doc/c-api/module.rst:276: PyModuleDef_Slot structures:
Monospace for ``PyModuleDef_Slot``

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode301
Doc/c-api/module.rst:301: The function receives a ModuleSpec instance,
as defined in PEP 451,
Cross reference to
https://docs.python.org/3/library/importlib.html?#importlib.machinery.ModuleSpec
from ModuleSpec

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode302
Doc/c-api/module.rst:302: and the PyModuleDef instance.
Monospace for ``PyModuleDef``. I won't comment on any more of these, you
get the idea :)

However, I also belatedly note that
https://docs.python.org/devguide/documenting.html is silent on the
question of whether or not to monospace names when not cross-referencing
them. Up to you if you'd prefer to seek clarification from the docs
mailing list before deciding one way or the other.

http://bugs.python.org/review/24458/diff/15091/Doc/c-api/module.rst#newcode315
Doc/c-api/module.rst:315: definition.
Perhaps worth mentioning that this allows extension modules to
dynamically adjust to their place in the module hierarchy and be
imported under different names through symlinks, all while sharing a
single module definition.

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

From report at bugs.python.org  Tue Jun 23 15:23:45 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jun 2015 13:23:45 +0000
Subject: [docs] [issue24458] Documentation for PEP 489
In-Reply-To: <1434452866.14.0.181014085851.issue24458@psf.upfronthosting.co.za>
Message-ID: <1435065825.23.0.477138284052.issue24458@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Leaving the tutorial alone until the callback problem is resolved makes sense to me.

The patch overall looks good, I sent a few more detailed comments via Rietveld.

----------

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

From yselivanov at gmail.com  Tue Jun 23 18:51:10 2015
From: yselivanov at gmail.com (yselivanov at gmail.com)
Date: Tue, 23 Jun 2015 16:51:10 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue
	24439)
Message-ID: <20150623165110.1474.29121@psf.upfronthosting.co.za>

Martin,

Thanks for the update!

My main concern with this version is about introducing the "native
coroutine" terminology.  While it was a necessary thing to do in PEP
492, I really doubt that we should use it in Python docs.


http://bugs.python.org/review/24439/diff/15143/Doc/glossary.rst
File Doc/glossary.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/glossary.rst#newcode181
Doc/glossary.rst:181: coroutine function` is defined with the
:keyword:`async def` statement,
Martin, I'm not sure we should use the "native coroutine" term.  I'd
really prefer to just use "coroutine" for "async def"/"await" objects,
and "generator-based coroutine" for "yield & yield from" ones.

99% of people don't use generators as coroutines (at least directly).
Some Python users know that generators can be coroutines, but that's
mostly those who use asyncio/twisted/tornado frameworks. In asyncio we
have a "coroutine" decorator, that in a sense, "converts" a generator
into a coroutine.

Hopefully, in the near future, Python users won't use generators as
coroutines, and I don't want them to be confused why we have the
"native" terminology.

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst
File Doc/library/asyncio-task.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst#newcode16
Doc/library/asyncio-task.rst:16: :func:`@asyncio.coroutine
<asyncio.coroutine>`.  This is mainly
"Documentation purposes" is one thing.

Another is compatibility with native coroutines.  If you have a
coroutine:

  def foo():
    yield from o

and a native coroutine bar:

   async def bar():
     await foo()

Then you have to decorate 'foo' with "asyncio.coroutine". Otherwise it's
not going to work.

I'd say that it's encouraged to use the decorator on generator-based
coroutine functions for documentation purposes *and* for compatibility
with PEP 492 coroutines.

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst#newcode70
Doc/library/asyncio-task.rst:70: the generator to call native
coroutines.
Let's also explicitly state that there is no need to decorate 'async
def' functions.

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst#newcode94
Doc/library/asyncio-task.rst:94: async def hello_world():
I think we should leave one example of generator based coroutines...

http://bugs.python.org/review/24439/diff/15143/Doc/library/collections.abc.rst
File Doc/library/collections.abc.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/library/collections.abc.rst#newcode169
Doc/library/collections.abc.rst:169: the generator methods defined in
:pep:`342`, namely:
Since we now have a dedicated section for coroutines in datamodel.rst we
need to update these refs to "coroutine.send" etc.

http://bugs.python.org/review/24439/diff/15143/Doc/library/dis.rst
File Doc/library/dis.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/library/dis.rst#newcode525
Doc/library/dis.rst:525: one derived from :func:`types.coroutine`, or
resolves
This isn't right too.  types.coroutine either patches the generator
function's code object, or wraps it in a special object with __await__.

Since this is a pretty low level documentation, let's just rephrase it
to something like this:

[...] returns ``o`` if ``o`` is a native coroutine object or a generator
object with CO_ITERABLE_COROUTINE flag, or resolves [...]

http://bugs.python.org/review/24439/diff/15143/Doc/library/types.rst
File Doc/library/types.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/library/types.rst#newcode293
Doc/library/types.rst:293: it may not necessarily implement the
:meth:`__await__` method.
Please take a look at my other patch:
http://bugs.python.org/review/24325/patch/15133/57450

Ideally we should combine the two

http://bugs.python.org/review/24439/diff/15143/Doc/reference/datamodel.rst
File Doc/reference/datamodel.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/reference/datamodel.rst#newcode2278
Doc/reference/datamodel.rst:2278: Native :term:`coroutine` objects are
awaitable.  The :term:`generator
Let's wrap "The :term:`generator [..]" in a ".. note::" section?

http://bugs.python.org/review/24439/diff/15143/Doc/reference/datamodel.rst#newcode2296
Doc/reference/datamodel.rst:2296: Native Coroutine Objects
Again, I'd prefer to drop "Native"

http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c
File Objects/genobject.c (right):

http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c#newcode913
Objects/genobject.c:913: {"close",(PyCFunction)coro_wrapper_close,
METH_NOARGS, coro_close_doc},
Please rebase your patch -- this code was updated in 24400.

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

From report at bugs.python.org  Tue Jun 23 21:09:33 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 23 Jun 2015 19:09:33 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
 execution model documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1435086572.87.0.425668457641.issue24129@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

It looks like on python-dev (http://www.mail-archive.com/python-dev at python.org/msg88256.html) there is an agreement that this behavior should not be changed (at least not in the nearest future). If there are no more comments/suggestions, then maybe one could accept the latest patch?

----------

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

From vadmium+py at gmail.com  Wed Jun 24 00:36:43 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Tue, 23 Jun 2015 22:36:43 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue
	24439)
Message-ID: <20150623223643.2153.39421@psf.upfronthosting.co.za>


http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst
File Doc/library/asyncio-task.rst (right):

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst#newcode16
Doc/library/asyncio-task.rst:16: :func:`@asyncio.coroutine
<asyncio.coroutine>`.  This is mainly
On 2015/06/23 18:51:10, Yury.Selivanov wrote:
> I'd say that it's encouraged to use the decorator on generator-based
coroutine
> functions for documentation purposes *and* for compatibility with PEP
492
> coroutines.

Okay. I need to mention the compatibility works in both directions.

http://bugs.python.org/review/24439/diff/15143/Doc/library/asyncio-task.rst#newcode94
Doc/library/asyncio-task.rst:94: async def hello_world():
On 2015/06/23 18:51:10, Yury.Selivanov wrote:
> I think we should leave one example of generator based coroutines...

Perhaps duplicate the second one, to contrast ?await? with ?yield from?.

http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c
File Objects/genobject.c (right):

http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c#newcode913
Objects/genobject.c:913: {"close",(PyCFunction)coro_wrapper_close,
METH_NOARGS, coro_close_doc},
On 2015/06/23 18:51:10, Yury.Selivanov wrote:
> Please rebase your patch -- this code was updated in 24400.

This patch is actually based on revision 44253ce374fc (your #24400
commit into the default branch). It _added_ the coro_wrapper_methods,
but they refer to the generator doc strings, not the coroutine doc
strings. I can?t see anywhere that they have been _updated_, so rebasing
won?t do anything (unless you?re sitting on code that you forgot to
commit).

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

From report at bugs.python.org  Wed Jun 24 06:04:29 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Jun 2015 04:04:29 +0000
Subject: [docs] [issue12920] Document that inspect.getsource only works for
 objects loaded from files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1435118669.12.0.525930121865.issue12920@psf.upfronthosting.co.za>


Ned Deily added the comment:

In duplicate Issue24491, zorceta notes: "Both python.exe and IDLE can't. IPython is able to, as it inserts REPL input into linecache."

----------
nosy: +ned.deily, zorceta
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jun 24 06:14:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 04:14:45 +0000
Subject: [docs] [issue23639] Not documented special names
In-Reply-To: <1426072501.09.0.6383465164.issue23639@psf.upfronthosting.co.za>
Message-ID: <1435119284.82.0.473852871504.issue23639@psf.upfronthosting.co.za>


Martin Panter added the comment:

index-special.patch is a patch that adds index entries to the existing documentation that I found above.

----------
keywords: +patch
versions: +Python 3.6
Added file: http://bugs.python.org/file39793/index-special.patch

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

From report at bugs.python.org  Wed Jun 24 07:45:05 2015
From: report at bugs.python.org (Zorceta)
Date: Wed, 24 Jun 2015 05:45:05 +0000
Subject: [docs] [issue12920] inspect.getsource only works for objects loaded
 from files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1435124705.17.0.300544785906.issue12920@psf.upfronthosting.co.za>


Zorceta added the comment:

When provided object is not from a file, like input in interactive shell, `inspect` internals will check for it in `linecache`, which official Python shell and IDLE won't put interactive shell input into, yet. This can be simply solved.

Whether interactive shell input can be put into `linecache` may be a problem, but it'll make life easier, as interactive shell saves time from edit-save-run 'loop'.

btw, I changed the title, since I don't think, what original author thought need to be documented, is absolutely right.

----------
title: Document that inspect.getsource only works for objects loaded from files, not interactive session -> inspect.getsource only works for objects loaded from files, not interactive session

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

From report at bugs.python.org  Wed Jun 24 07:46:39 2015
From: report at bugs.python.org (Zorceta)
Date: Wed, 24 Jun 2015 05:46:39 +0000
Subject: [docs] [issue12920] inspect.getsource only works for objects loaded
 from files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1435124799.02.0.0604997955481.issue12920@psf.upfronthosting.co.za>


Changes by Zorceta <zorceta at gmail.com>:


----------
components: +IDLE, Interpreter Core -Documentation

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

From report at bugs.python.org  Wed Jun 24 12:17:13 2015
From: report at bugs.python.org (=?utf-8?b?SmFrdWIgS2FkbMSNw61r?=)
Date: Wed, 24 Jun 2015 10:17:13 +0000
Subject: [docs] [issue24496] Non-idiomatic examples in gzip docs
Message-ID: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za>


New submission from Jakub Kadl??k:

Hello, I think there are awesome example code snippets in gzip documentation. No doubt, they helped me a lot.

The only problem is that they are not idiomatic. They look like C more than Python.

I suggest following patch

----------
assignee: docs at python
components: Documentation
files: idiomatic-gzip.diff
keywords: patch
messages: 245729
nosy: FrostyX, docs at python
priority: normal
severity: normal
status: open
title: Non-idiomatic examples in gzip docs
type: enhancement
Added file: http://bugs.python.org/file39796/idiomatic-gzip.diff

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

From report at bugs.python.org  Wed Jun 24 13:04:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 11:04:23 +0000
Subject: [docs] [issue24496] Non-idiomatic examples in gzip docs
In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za>
Message-ID: <1435143863.01.0.185734309698.issue24496@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like this is for Python 2. I agree with the change, but I suggest back-porting revisions 35c53e7e2280, a01992e219c0 and ae1528beae67 (Issue 21146) instead, to match the Python 3 documentation.

----------
nosy: +vadmium
versions: +Python 2.7

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

From vadmium+py at gmail.com  Wed Jun 24 14:25:02 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 24 Jun 2015 12:25:02 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue
	24439)
Message-ID: <20150624122502.2153.39203@psf.upfronthosting.co.za>


https://bugs.python.org/review/24439/diff/15143/Doc/library/types.rst
File Doc/library/types.rst (right):

https://bugs.python.org/review/24439/diff/15143/Doc/library/types.rst#newcode293
Doc/library/types.rst:293: it may not necessarily implement the
:meth:`__await__` method.
On 2015/06/23 18:51:10, Yury.Selivanov wrote:
> Please take a look at my other patch:
> http://bugs.python.org/review/24325/patch/15133/57450
> 
> Ideally we should combine the two

I will include your changes in my patch. I understand the documentation
changes are valid even without the sped-up C implementation.

https://bugs.python.org/review/24439/

From report at bugs.python.org  Wed Jun 24 14:36:05 2015
From: report at bugs.python.org (mattyw)
Date: Wed, 24 Jun 2015 12:36:05 +0000
Subject: [docs] [issue24497] test_decimal.py contains a dead link
Message-ID: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za>


New submission from mattyw:

The comments in test_decimal contain a url for downloading tests written by  Mike Cowlishaw:

Cowlishaw's tests can be downloaded from:                                       
                                                                               
    www2.hursley.ibm.com/decimal/dectest.zip

Python 3.4.3 contains an updated url:
http://speleotrove.com/decimal/dectest.zip

It seems like the url should be updated in 2.7 as well

----------
assignee: docs at python
components: Documentation
messages: 245734
nosy: docs at python, mattyw
priority: normal
severity: normal
status: open
title: test_decimal.py contains a dead link
versions: Python 2.7

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

From report at bugs.python.org  Wed Jun 24 14:42:06 2015
From: report at bugs.python.org (mattyw)
Date: Wed, 24 Jun 2015 12:42:06 +0000
Subject: [docs] [issue24497] test_decimal.py contains a dead link
In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za>
Message-ID: <1435149726.43.0.731806037841.issue24497@psf.upfronthosting.co.za>


Changes by mattyw <mattyw at me.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file39797/24497.patch

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

From d33tah at gmail.com  Wed Jun 24 14:52:34 2015
From: d33tah at gmail.com (Jacek Wielemborek)
Date: Wed, 24 Jun 2015 14:52:34 +0200
Subject: [docs] logging.config - turn the "note" into a "warning"
Message-ID: <558AA812.5040804@gmail.com>

Hi,

Somewhere on StackOverflow, I saw a recommendation to use logging.config
instead of hardcoding things [1]. I took a look at the sample config
file and immediately noticed that this can be a security risk. I checked
the documentation for this module [2] for such notes and found a few
ones, but marked as "Note" instead of "Warning. Compare this to
subprocess documentation [3]. I believe that this should be unified.

Cheers,
d33tah

[1] http://stackoverflow.com/a/30752753/1091116
[2] https://docs.python.org/2/library/logging.config
[3] https://docs.python.org/2/library/subprocess.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/docs/attachments/20150624/338a1376/attachment.sig>

From report at bugs.python.org  Wed Jun 24 15:11:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 13:11:56 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435151510.45.0.508296018377.issue24439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for reviewing this Yury. Here is a new patch:

* Drop the ?native? term; distinguish by referring to ?async def? where necessary
* Add generator version of display_date() coroutine example
* Change chained coroutine example over to ?async def? and updated sequence diagram
* Change one other example over (then I ran into Issue 24495)
* Include Yury?s new documentation for @types.coroutine from Issue 24325

----------
Added file: http://bugs.python.org/file39798/async-doc.v3.patch

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

From report at bugs.python.org  Wed Jun 24 15:13:43 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 13:13:43 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435151623.42.0.013730889743.issue24439@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file39799/tulip_coro.png

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

From yselivanov at gmail.com  Wed Jun 24 15:35:32 2015
From: yselivanov at gmail.com (yselivanov at gmail.com)
Date: Wed, 24 Jun 2015 13:35:32 -0000
Subject: [docs] Feedback for awaitable coroutine documentation (issue
	24439)
Message-ID: <20150624133532.1911.69865@psf.upfronthosting.co.za>

LGTM. Will commit it soon.


http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c
File Objects/genobject.c (right):

http://bugs.python.org/review/24439/diff/15143/Objects/genobject.c#newcode913
Objects/genobject.c:913: {"close",(PyCFunction)coro_wrapper_close,
METH_NOARGS, coro_close_doc},
I could have sworn I did that change myself in 24400! :)

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

From report at bugs.python.org  Wed Jun 24 16:52:33 2015
From: report at bugs.python.org (Jens Diemer)
Date: Wed, 24 Jun 2015 14:52:33 +0000
Subject: [docs] [issue19894] zipfile ignores deflate level settings in
	zipinfo object
In-Reply-To: <1386235609.47.0.431866049959.issue19894@psf.upfronthosting.co.za>
Message-ID: <1435157552.89.0.411587704802.issue19894@psf.upfronthosting.co.za>


Jens Diemer added the comment:

IMHO it should be possible to set compression level not only for DEFLATE.
And it should be similar with the tarfile API.

Seems that http://bugs.python.org/issue21417 will cover this.

----------
nosy: +jens

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

From report at bugs.python.org  Wed Jun 24 17:04:57 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Jun 2015 15:04:57 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <20150624150454.29618.46250@psf.io>


Roundup Robot added the comment:

New changeset e31aad001fdb by Yury Selivanov in branch '3.5':
Issue #24439: Improve PEP 492 related docs.
https://hg.python.org/cpython/rev/e31aad001fdb

New changeset d99770da3b2a by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24439)
https://hg.python.org/cpython/rev/d99770da3b2a

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

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

From report at bugs.python.org  Wed Jun 24 17:06:25 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jun 2015 15:06:25 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435158385.16.0.978857893167.issue24439@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Committed. Thanks a lot, Martin!

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

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

From report at bugs.python.org  Wed Jun 24 22:37:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 24 Jun 2015 20:37:46 +0000
Subject: [docs] [issue24497] test_decimal.py contains a dead link
In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za>
Message-ID: <20150624203717.24638.1189@psf.io>


Roundup Robot added the comment:

New changeset 37c827d9dda4 by Ned Deily in branch '2.7':
Issue #24497: update link in test_decimal comments
https://hg.python.org/cpython/rev/37c827d9dda4

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

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

From report at bugs.python.org  Wed Jun 24 22:38:29 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Jun 2015 20:38:29 +0000
Subject: [docs] [issue24497] test_decimal.py contains a dead link
In-Reply-To: <1435149364.96.0.261968389532.issue24497@psf.upfronthosting.co.za>
Message-ID: <1435178309.27.0.332285530116.issue24497@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for noticing!

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jun 25 01:38:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 24 Jun 2015 23:38:47 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435189127.61.0.50109414093.issue24439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Yury. It looks like you missed my updated /Doc/library/tulip_coro.dia file. Here it is separately, in case you are having trouble extracting it from the patch.

----------
Added file: http://bugs.python.org/file39810/tulip_coro.dia

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

From report at bugs.python.org  Thu Jun 25 09:38:21 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 25 Jun 2015 07:38:21 +0000
Subject: [docs] [issue24509] Undocumented features of asyncio: call_at,
	call_later
In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>
Message-ID: <1435217901.55.0.627589560329.issue24509@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, asyncio
nosy: +docs at python, gvanrossum, haypo, yselivanov
type:  -> enhancement

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

From report at bugs.python.org  Thu Jun 25 09:52:10 2015
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 25 Jun 2015 07:52:10 +0000
Subject: [docs] [issue24509] Undocumented features of asyncio: call_at,
	call_later
In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>
Message-ID: <1435218730.86.0.179996178006.issue24509@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Documentatin of call_soon() and call_later() contain the sentence "An instance of asyncio.Handle is returned." with a link to Handle which shows the cancel() method:

https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_soon

https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.BaseEventLoop.call_later

Can you please suggest a new sentence to explain that a Handle can be cancelled?

----------

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

From report at bugs.python.org  Thu Jun 25 11:35:08 2015
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Thu, 25 Jun 2015 09:35:08 +0000
Subject: [docs] [issue24509] Undocumented features of asyncio: call_at,
	call_later
In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>
Message-ID: <1435224908.21.0.364468086884.issue24509@psf.upfronthosting.co.za>


???? ????????? added the comment:

For delayed execution methods:

"Returned handle is actually timer object. That timer can be deactivated using asyncio.Handle.cancel() method, so registered callback won't be called".

For other callback registration methods:

"Returned handle may be used to unregister callback using asyncio.Handle.cancel(), so registered callback won't be called".


Also:
1. Documentation of .cancel does not say if it is allowed to cancel cancelled handle.
2. Documentation does not say if it is allowed to cancel timer, that was already fired.

----------

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

From report at bugs.python.org  Thu Jun 25 17:48:59 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jun 2015 15:48:59 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <20150625154856.62221.93095@psf.io>


Roundup Robot added the comment:

New changeset e9c34e16f445 by Yury Selivanov in branch '3.5':
Issue #24439: Update tulip_coro.dia
https://hg.python.org/cpython/rev/e9c34e16f445

New changeset 15b8a62da6ff by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #24439)
https://hg.python.org/cpython/rev/15b8a62da6ff

----------

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

From report at bugs.python.org  Thu Jun 25 17:51:12 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jun 2015 15:51:12 +0000
Subject: [docs] [issue24439] Feedback for awaitable coroutine documentation
In-Reply-To: <1434120366.17.0.865771176653.issue24439@psf.upfronthosting.co.za>
Message-ID: <1435247471.97.0.607625516162.issue24439@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Martin, it's now updated.

(As for why it wasn't applied in the first place, I guess standard MacOS `patch` command fails to apply git binary diffs)

----------

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

From report at bugs.python.org  Thu Jun 25 19:50:52 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jun 2015 17:50:52 +0000
Subject: [docs] [issue24509] Undocumented features of asyncio: call_at,
	call_later
In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>
Message-ID: <20150625175049.28495.34877@psf.io>


Roundup Robot added the comment:

New changeset 3199ec504dbe by Yury Selivanov in branch '3.4':
Issue #24509: Clarify Handle.cancel() and loop.call_* methods.
https://hg.python.org/cpython/rev/3199ec504dbe

New changeset fc69dd6aea55 by Yury Selivanov in branch '3.5':
Merge 3.4 (issue #24509)
https://hg.python.org/cpython/rev/fc69dd6aea55

New changeset 9aad116baee8 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24509)
https://hg.python.org/cpython/rev/9aad116baee8

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

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

From report at bugs.python.org  Thu Jun 25 19:52:08 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jun 2015 17:52:08 +0000
Subject: [docs] [issue24509] Undocumented features of asyncio: call_at,
	call_later
In-Reply-To: <1435217870.26.0.229926734137.issue24509@psf.upfronthosting.co.za>
Message-ID: <1435254728.2.0.766202955204.issue24509@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks for reporting this Mark!

----------
resolution:  -> fixed
stage:  -> commit review
status: open -> closed
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jun 25 22:39:03 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jun 2015 20:39:03 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
 default scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <20150625203900.14147.60424@psf.io>


Roundup Robot added the comment:

New changeset 368db4b1ced9 by Berker Peksag in branch '3.4':
Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects.
https://hg.python.org/cpython/rev/368db4b1ced9

New changeset 68629ebe0fee by Berker Peksag in branch '3.5':
Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects.
https://hg.python.org/cpython/rev/68629ebe0fee

New changeset 7846aadbd4f5 by Berker Peksag in branch 'default':
Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects.
https://hg.python.org/cpython/rev/7846aadbd4f5

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

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

From report at bugs.python.org  Thu Jun 25 22:46:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jun 2015 20:46:51 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
 default scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <20150625204648.35967.93025@psf.io>


Roundup Robot added the comment:

New changeset 7bf9e10fc32f by Berker Peksag in branch '2.7':
Issue #23684: Clarify the return value of the scheme attribute of ParseResult and SplitResult objects.
https://hg.python.org/cpython/rev/7bf9e10fc32f

----------

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

From report at bugs.python.org  Thu Jun 25 22:48:05 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 25 Jun 2015 20:48:05 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
 default scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <1435265285.0.0.488702143286.issue23684@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Martin.

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

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

From report at bugs.python.org  Thu Jun 25 22:56:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 25 Jun 2015 20:56:50 +0000
Subject: [docs] [issue24496] Non-idiomatic examples in gzip docs
In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za>
Message-ID: <20150625205647.16794.84470@psf.io>


Roundup Robot added the comment:

New changeset 10eea15880db by Berker Peksag in branch '2.7':
Issue #24496: Backport gzip examples to Python 2.
https://hg.python.org/cpython/rev/10eea15880db

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

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

From report at bugs.python.org  Thu Jun 25 22:59:41 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 25 Jun 2015 20:59:41 +0000
Subject: [docs] [issue24496] Non-idiomatic examples in gzip docs
In-Reply-To: <1435141033.01.0.69017919729.issue24496@psf.upfronthosting.co.za>
Message-ID: <1435265981.81.0.298421895945.issue24496@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Jakub. I've updated the patch to match ae1528beae67 (thanks Martin) and commit it.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From berker.peksag at gmail.com  Thu Jun 25 23:31:14 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Thu, 25 Jun 2015 21:31:14 -0000
Subject: [docs] Documentation regressions from adding subprocess.run()
	(issue 24420)
Message-ID: <20150625213114.9098.44960@psf.upfronthosting.co.za>


http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst
File Doc/library/subprocess.rst (right):

http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst#newcode880
Doc/library/subprocess.rst:880: .. function:: check_output(args, *[,
input], stdin=None, stderr=None, shell=False, universal_newlines=False,
timeout=None)
I think we can now remove *input* from the signature.

The following paragraph makes the *input* parameter's presence
redundant:

+   The arguments shown above are merely the most common ones.
+   The full function signature is largely the same as that of
:func:`run` -
+   most arguments are passed directly through to that interface.
+   The differences are that explicitly passing ``input=None`` is not
+   supported, and that *stdout* is not permitted as an argument, as
+   it is used internally to collect the output from the subprocess.

Also, without ``[, input],``, the signature looks more readable to me.

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

From report at bugs.python.org  Thu Jun 25 23:32:42 2015
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 25 Jun 2015 21:32:42 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1435267962.91.0.666043694374.issue24420@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM, too. I just left a comment on Rietveld.

Thanks!

----------

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

From vadmium+py at gmail.com  Fri Jun 26 02:32:56 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Fri, 26 Jun 2015 00:32:56 -0000
Subject: [docs] Documentation regressions from adding subprocess.run()
	(issue 24420)
Message-ID: <20150626003256.9249.82680@psf.upfronthosting.co.za>

Reviewers: berkerpeksag,


http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst
File Doc/library/subprocess.rst (right):

http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst#newcode880
Doc/library/subprocess.rst:880: .. function:: check_output(args, *[,
input], stdin=None, stderr=None, shell=False, universal_newlines=False,
timeout=None)
On 2015/06/25 23:31:14, berkerpeksag wrote:
> I think we can now remove *input* from the signature.

Yes I agree. I might tweak the new paragraph and the ?versionchanged?
note to add more context, though.



Please review this at http://bugs.python.org/review/24420/

Affected files:
  Doc/library/subprocess.rst


# HG changeset patch
# Parent 1cdedc9a9e9ff2f71f3e192fb8feaa8ba9f55c02

diff -r 1cdedc9a9e9f Doc/library/subprocess.rst
--- a/Doc/library/subprocess.rst	Tue Jun 09 14:24:30 2015 -0400
+++ b/Doc/library/subprocess.rst	Wed Jun 10 04:01:37 2015 +0000
@@ -825,7 +825,7 @@
 .. function:: call(args, *, stdin=None, stdout=None, stderr=None, shell=False, timeout=None)
 
    Run the command described by *args*.  Wait for command to complete, then
-   return the :attr:`returncode` attribute.
+   return the :attr:`~Popen.returncode` attribute.
 
    This is equivalent to::
 
@@ -833,6 +833,11 @@
 
    (except that the *input* and *check* parameters are not supported)
 
+   The arguments shown above are merely the most
+   common ones. The full function signature is largely the
+   same as that of the :class:`Popen` constructor - this function passes all
+   supplied arguments other than *timeout* directly through to that interface.
+
    .. note::
 
       Do not use ``stdout=PIPE`` or ``stderr=PIPE`` with this
@@ -856,6 +861,11 @@
 
    (except that the *input* parameter is not supported)
 
+   The arguments shown above are merely the most
+   common ones. The full function signature is largely the
+   same as that of the :class:`Popen` constructor - this function passes all
+   supplied arguments other than *timeout* directly through to that interface.
+
    .. note::
 
       Do not use ``stdout=PIPE`` or ``stderr=PIPE`` with this
@@ -867,7 +877,7 @@
       *timeout* was added.
 
 
-.. function:: check_output(args, *, input=None, stdin=None, stderr=None, shell=False, universal_newlines=False, timeout=None)
+.. function:: check_output(args, *[, input], stdin=None, stderr=None, shell=False, universal_newlines=False, timeout=None)
 
    Run command with arguments and return its output.
 
@@ -880,6 +890,13 @@
 
        run(..., check=True, stdout=PIPE).stdout
 
+   The arguments shown above are merely the most common ones.
+   The full function signature is largely the same as that of :func:`run` -
+   most arguments are passed directly through to that interface.
+   The differences are that explicitly passing ``input=None`` is not
+   supported, and that *stdout* is not permitted as an argument, as
+   it is used internally to collect the output from the subprocess.
+
    By default, this function will return the data as encoded bytes. The actual
    encoding of the output data may depend on the command being invoked, so the
    decoding to text will often need to be handled at the application level.



From report at bugs.python.org  Fri Jun 26 11:49:10 2015
From: report at bugs.python.org (Luc Saffre)
Date: Fri, 26 Jun 2015 09:49:10 +0000
Subject: [docs] [issue24515] docstring of isinstance
Message-ID: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za>


New submission from Luc Saffre:

The docstring of built-in function 'isinstance' should explain that if the classinfo is a tuple, the object must be instance of *any* (not *all*) of the class objects.

----------
assignee: docs at python
components: Documentation
messages: 245841
nosy: Luc Saffre, docs at python
priority: normal
severity: normal
status: open
title: docstring of isinstance
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Jun 26 11:58:18 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 26 Jun 2015 09:58:18 +0000
Subject: [docs] [issue24515] docstring of isinstance
In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za>
Message-ID: <1435312698.26.0.656282412319.issue24515@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

It already does:

"The form using a tuple, isinstance(x, (A, B, ...)), is a shortcut
for isinstance(x, A) or isinstance(x, B) or ... (etc.)."

If it were "all", it would use "and", not "or".

I don't think any change is needed. Do you have a suggestion for new wording? If not, I'm going to close this issue.

----------
nosy: +steven.daprano

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

From berker.peksag at gmail.com  Fri Jun 26 13:16:58 2015
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Fri, 26 Jun 2015 11:16:58 -0000
Subject: [docs] Documentation regressions from adding subprocess.run()
	(issue 24420)
Message-ID: <20150626111658.9591.99669@psf.upfronthosting.co.za>


http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst
File Doc/library/subprocess.rst (right):

http://bugs.python.org/review/24420/diff/15059/Doc/library/subprocess.rst#newcode880
Doc/library/subprocess.rst:880: .. function:: check_output(args, *[,
input], stdin=None, stderr=None, shell=False, universal_newlines=False,
timeout=None)
On 2015/06/26 02:32:56, vadmium wrote:
> On 2015/06/25 23:31:14, berkerpeksag wrote:
> > I think we can now remove *input* from the signature.
> 
> Yes I agree. I might tweak the new paragraph and the ?versionchanged?
note to
> add more context, though.

Yes, that would be better.

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

From report at bugs.python.org  Fri Jun 26 15:05:40 2015
From: report at bugs.python.org (Petr Messner)
Date: Fri, 26 Jun 2015 13:05:40 +0000
Subject: [docs] [issue24516] SSL create_default_socket purpose
 insufficiently documented
Message-ID: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za>


New submission from Petr Messner:

Please, is it possible to put more information about the purpose parameter to the documentation of ssl.create_default_context()? It's not obvious that SERVER_AUTH should be used for client sockets and not server sockets. It took me a while to discover this, while all I was getting was only "SSLEOFError: EOF occurred in violation of protocol" (which is also not helpful).

This is especially confusing, because OpenSSL uses serverAuth and clientAuth (for extendedKeyUsage configuration) in the exactly opposite meaning.

----------
assignee: docs at python
components: Documentation
messages: 245852
nosy: docs at python, messa
priority: normal
severity: normal
status: open
title: SSL create_default_socket purpose insufficiently documented
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Fri Jun 26 15:29:40 2015
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 26 Jun 2015 13:29:40 +0000
Subject: [docs] [issue24516] SSL create_default_socket purpose
 insufficiently documented
In-Reply-To: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za>
Message-ID: <1435325380.68.0.467720873084.issue24516@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python uses serverAuth and clientAuth in the exact same meaning as EKU (extended key usage). In order to create X.509 cert for a web server, it should have EKU "SSL/TLS Web Server Authentication". On the other hand a client must validate the cert for a specific purpose, too. So the client creates a context with purpose SERVER_AUTH. This loads only trust anchors which are flagged with EKU "SSL/TLS Web Server Authentication".

For TLS/SSL server it is the other way around. The server side uses a context with CLIENT_AUTH to load only root certs that can validate client certs. Other purposes aren't supported because Python's ssl does neither support S/MIME nor code signing.

https://docs.python.org/2/library/ssl.html#ssl.SSLContext.load_default_certs explains the purpose flags, too.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Fri Jun 26 22:14:06 2015
From: report at bugs.python.org (dendory)
Date: Fri, 26 Jun 2015 20:14:06 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1435349646.62.0.0589439583662.issue20281@psf.upfronthosting.co.za>


dendory added the comment:

Why is the focus on documentation entries when the real work should be on trying to make this function to work on all platforms?

I understand that Windows's implementation of strftime() defines %z and %Z to return the same thing, but timezone information is still available in other ways. For example, _get_timezone() returns the offset in seconds between localtime and UTC. I don't have VC++ 2010 installed so I can't test it but this seems like a fairly simple thing to fix. Just take that result and multiply.

ref: https://msdn.microsoft.com/en-us/library/38wx0s70%28v=vs.100%29.aspx

----------
nosy: +dendory

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

From report at bugs.python.org  Fri Jun 26 22:25:44 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 26 Jun 2015 20:25:44 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1435350344.92.0.400284840172.issue20281@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because there's a different issue for making strftime system independent, issue 3173.

----------

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

From report at bugs.python.org  Fri Jun 26 23:20:18 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jun 2015 21:20:18 +0000
Subject: [docs] [issue24515] docstring of isinstance
In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za>
Message-ID: <1435353618.07.0.903720805027.issue24515@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that the tuple explanation if ok.  But "Return whether an object is an instance of a class or of a subclass thereof." (3.5) seems wrong.  I believe 'subclass' should be 'superclass'.
    
>>> class C: pass

>>> class Csub(C): pass

>>> isinstance(C(), Csub)
False
>>> isinstance(Csub(), C)
True

----------
nosy: +terry.reedy
versions: +Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun 27 00:15:00 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 26 Jun 2015 22:15:00 +0000
Subject: [docs] [issue24515] docstring of isinstance
In-Reply-To: <1435353618.07.0.903720805027.issue24515@psf.upfronthosting.co.za>
Message-ID: <20150626221442.GW20701@ando.pearwood.info>


Steven D'Aprano added the comment:

On Fri, Jun 26, 2015 at 09:20:18PM +0000, Terry J. Reedy wrote:

> I agree that the tuple explanation if ok.  But "Return whether an 
> object is an instance of a class or of a subclass thereof." (3.5) 
> seems wrong.  I believe 'subclass' should be 'superclass'.

No, the current description is correct.

> >>> class C: pass
> >>> class Csub(C): pass
> >>> isinstance(C(), Csub)
> False

In this case, the instance C() is an instance of a *superclass* of 
Csub, and isinstance returns False.

> >>> isinstance(Csub(), C)
> True

In this case, the instance Csub() is an instance of a *subclass* of C, 
and isinstance returns True.

----------

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

From report at bugs.python.org  Sat Jun 27 01:42:41 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Jun 2015 23:42:41 +0000
Subject: [docs] [issue24515] docstring of isinstance
In-Reply-To: <1435312150.5.0.444169583356.issue24515@psf.upfronthosting.co.za>
Message-ID: <1435362161.18.0.268709741818.issue24515@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Right.  Close this unless something else is offered.

----------

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

From report at bugs.python.org  Sat Jun 27 03:10:37 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 27 Jun 2015 01:10:37 +0000
Subject: [docs] [issue24516] SSL create_default_socket purpose
 insufficiently documented
In-Reply-To: <1435323940.35.0.0347196481189.issue24516@psf.upfronthosting.co.za>
Message-ID: <1435367437.06.0.307393791204.issue24516@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/issue24516>
_______________________________________

From report at bugs.python.org  Sun Jun 28 08:03:43 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jun 2015 06:03:43 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1435471423.57.0.142255924526.issue18576@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: ncoghlan -> 

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

From report at bugs.python.org  Mon Jun 29 00:28:59 2015
From: report at bugs.python.org (Christie)
Date: Sun, 28 Jun 2015 22:28:59 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1435530539.4.0.0158614084571.issue18576@psf.upfronthosting.co.za>


Christie added the comment:

Hey @vadmium!

I've finally responded to your review feedback. I've attached a new patch, hopefully this time actually review-able. I've removed the docs for methods I added in @24033 so that this could be merged without it.

Let me know if you have any more feedback, or if this could be merged.

Thanks!

----------
Added file: http://bugs.python.org/file39827/issue18576.patch

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

From report at bugs.python.org  Mon Jun 29 08:54:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jun 2015 06:54:24 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
 dict get updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1435560863.71.0.0546205650454.issue17546@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is another attempt with different words:

'''
.. note::
   The dictionary returned by :func:`locals` is an accurate snapshot of the local namespace at the time it is called.  If the namespace changes after the call, the dictionary may become out of date, but it may also automatically update at any time.  The contents of the dictionary should not be modified by the user; it is undefined whether such changes affect the namespace or not.
'''

----------

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

From report at bugs.python.org  Mon Jun 29 09:39:56 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 29 Jun 2015 07:39:56 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
 dict get updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1435563596.56.0.885463560799.issue17546@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I mostly like Martin's suggested wording, but would also note that I filed issue 17960 to tighten up the requirements for when we expect assigning to locals() to work.

To save folks reading the whole referenced email, I think it would be worth defining that modifying the namespace returned by locals() will affect the runtime namespace at module and class scope and when using exec, but will have no effect at function scope (as locals() returns a copy of the namespace in that case).

----------

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

From report at bugs.python.org  Mon Jun 29 10:19:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jun 2015 08:19:05 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1435565945.22.0.394027004807.issue18576@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left some more comments on Reitveld. The main one is I think stderr gets stripped with assert_python_ok(), but I don?t think stdout is touched. Correct me if I?m wrong though.

----------

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

From report at bugs.python.org  Mon Jun 29 10:48:31 2015
From: report at bugs.python.org (Vincent Legoll)
Date: Mon, 29 Jun 2015 08:48:31 +0000
Subject: [docs] [issue24525] [doc] missing word
Message-ID: <1435567711.2.0.215374180363.issue24525@psf.upfronthosting.co.za>


New submission from Vincent Legoll:

Here is a patch to fix a missing word in the urllib doc

----------
assignee: docs at python
components: Documentation
files: python-doc-fix.hgpatch
messages: 245927
nosy: docs at python, vincent-legoll
priority: normal
severity: normal
status: open
title: [doc] missing word
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file39828/python-doc-fix.hgpatch

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

From report at bugs.python.org  Mon Jun 29 14:11:31 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jun 2015 12:11:31 +0000
Subject: [docs] [issue11352] Update cgi module doc
In-Reply-To: <1298895261.86.0.965235067518.issue11352@psf.upfronthosting.co.za>
Message-ID: <1435579891.31.0.386411618296.issue11352@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

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

From report at bugs.python.org  Mon Jun 29 14:22:27 2015
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jun 2015 12:22:27 +0000
Subject: [docs] [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1435580547.34.0.147137628407.issue24272@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

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

From report at bugs.python.org  Mon Jun 29 15:25:29 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jun 2015 13:25:29 +0000
Subject: [docs] [issue24420] Documentation regressions from adding
	subprocess.run()
In-Reply-To: <1433909056.73.0.964707918197.issue24420@psf.upfronthosting.co.za>
Message-ID: <1435584329.71.0.627193044653.issue24420@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch dropping the [, input] parameter from the signature. I also removed the bit about *stdout*, since it should be obvious from the equivalent run() call given, and equally applies to *check*.

----------
Added file: http://bugs.python.org/file39831/high-args.v2.patch

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

From report at bugs.python.org  Mon Jun 29 17:09:56 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 29 Jun 2015 15:09:56 +0000
Subject: [docs] [issue17546] Document the circumstances where the locals()
 dict get updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1435590596.59.0.134132228015.issue17546@psf.upfronthosting.co.za>


Martin Panter added the comment:

I quickly scanned through the email thread from Issue 17960. I guess it makes sense to specify that locals() can be used to directly get a class?s namespace. Probably doesn?t hurt to say locals() is equivalent to globals() at module level, although this seems like a fairly redundant feature.

Here is locals_doc.03.patch, which uses my wording for function namespaces, and also adds more for class and global namespaces, as suggested by Nick.

----------
Added file: http://bugs.python.org/file39833/locals_doc.03.patch

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

From report at bugs.python.org  Mon Jun 29 17:42:25 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Jun 2015 15:42:25 +0000
Subject: [docs] [issue24531] please document that no code preceding encoding
 declaration is allowed
Message-ID: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>


New submission from Jakub Wilk:

If the encoding is declared on the second line, the first line must not contain anything except comments. However, this fact is not documented.

The Python Language reference says only that "the encoding declaration must appear on a line of its own";
and PEP 263 says only that "there must not be any Python statement on the line that contains the encoding declaration".

For example, Python ignores this encoding declaration:

spam = True
# encoding=ISO-8859-2

despite the fact that it appears on a line of its own.

----------
assignee: docs at python
components: Documentation
messages: 245946
nosy: docs at python, jwilk
priority: normal
severity: normal
status: open
title: please document that no code preceding encoding declaration is allowed

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

From report at bugs.python.org  Mon Jun 29 18:25:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Jun 2015 16:25:12 +0000
Subject: [docs] [issue24531] please document that no code preceding encoding
 declaration is allowed
In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>
Message-ID: <1435595112.83.0.484213096521.issue24531@psf.upfronthosting.co.za>


R. David Murray added the comment:

What docs are you looking at? https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations? I suspect the author thought that "If a comment in the first or second line..." implied both lines needed to be comments, but I agree that the wording is not clear.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun 29 21:50:17 2015
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Jun 2015 19:50:17 +0000
Subject: [docs] [issue24531] please document that no code preceding encoding
 declaration is allowed
In-Reply-To: <1435592545.23.0.229313024646.issue24531@psf.upfronthosting.co.za>
Message-ID: <1435607417.43.0.194588490515.issue24531@psf.upfronthosting.co.za>


Jakub Wilk added the comment:

Right, I meant <https://docs.python.org/3/reference/lexical_analysis.html#encoding-declarations>.

----------

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

From report at bugs.python.org  Mon Jun 29 22:41:47 2015
From: report at bugs.python.org (Daniel Neuberger)
Date: Mon, 29 Jun 2015 20:41:47 +0000
Subject: [docs] [issue24475] The docs never define what a pool "task" is
In-Reply-To: <1434733537.74.0.146405679971.issue24475@psf.upfronthosting.co.za>
Message-ID: <1435610507.7.0.000954062471978.issue24475@psf.upfronthosting.co.za>


Daniel Neuberger added the comment:

I second this. I was definitely confused at first and it took me a little while of googling to realize that jobs are not what one (at least me) would intuitively think they are.

----------
nosy: +Daniel Neuberger

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

From report at bugs.python.org  Mon Jun 29 22:44:43 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Jun 2015 20:44:43 +0000
Subject: [docs] [issue3530] ast.NodeTransformer doc bug
In-Reply-To: <1218248774.79.0.612230512704.issue3530@psf.upfronthosting.co.za>
Message-ID: <1435610683.78.0.840867406363.issue3530@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am reopening this as a doc bug because RewriteName is a copy (with 'ast.' prefixes added) of a buggy example in the doc. The bug is that the new .value Name and Str attributes do not get the required 'lineno' and 'col_offset' attributes.  As Armin said, copy_location is not recursive and does not fix children of the node it fixes.  Also, the recursive .visit method does not recurse into children of replacement nodes (and if it did, the new Str node would still not be fixed).

The fix could be to reuse the Name node and add another copy_location call: the following works.

    def visit_Name(self, node):
        return ast.copy_location(
            ast.Subscript(
                value=node,
                slice=ast.Index(value=ast.copy_location(
                    ast.Str(s=node.id), node)),
                ctx=node.ctx),
            node)

but I think this illustrates that comment in the fix_missing_locations() entry that locations are "tedious to fill in for generated nodes".  So I think the doc fix should use Armin's version of RewriteName and say to call fix_missing_locations on the result of .visit if new nodes are added.  (I checked that his code still works in 3.5).

The entry for NodeTransformer might mention that .visit does not recurse into replacement nodes.

The missing lineno error came up in this python-list thread:
https://mail.python.org/pipermail/python-list/2015-June/693316.html

----------
assignee:  -> docs at python
components: +Documentation
nosy: +benjamin.peterson, docs at python, terry.reedy
resolution: not a bug -> 
stage:  -> needs patch
status: closed -> open
title: ast.NodeTransformer bug -> ast.NodeTransformer doc bug
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 -Python 2.6

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

From vadmium+py at gmail.com  Mon Jun 29 10:15:44 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Mon, 29 Jun 2015 08:15:44 -0000
Subject: [docs] Rename and document test.script_helper as
 test.support.script_helper (issue 18576)
Message-ID: <20150629081544.10221.5135@psf.upfronthosting.co.za>


https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst
File Doc/library/test.rst (right):

https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst#newcode652
Doc/library/test.rst:652: variables *env_vars*, asserting that run
succeeds (``rc == 0``).
(return code is zero) might be better, to match the term used in the
next paragraph

https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst#newcode655
Doc/library/test.rst:655: appropriate :exc:`AssertionError`` for a
non-zero return code containing
Single back-tick at end of :exc:`AssertionError`

https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst#newcode658
Doc/library/test.rst:658: Trailing whitespace will be stripped from both
stdout and stderr.
I believe it?s only the stderr. See the strip_python_stderr() call.

https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst#newcode671
Doc/library/test.rst:671: variables, asserting that *env_vars* fails
(``rc != 0``).
asserting that the run fails (return code is nonzero), [similar to
above]

https://bugs.python.org/review/18576/diff/15165/Doc/library/test.rst#newcode786
Doc/library/test.rst:786: Returns True if our `sys.executable
interpreter` requires environment
Maybe this should be something like ?:data:`sys.executable` interpreter?

https://bugs.python.org/review/18576/