From report at bugs.python.org  Wed Aug  2 15:06:01 2017
From: report at bugs.python.org (cwee)
Date: Wed, 02 Aug 2017 19:06:01 +0000
Subject: [docs] [issue31110] Small typo in plistlib docs
Message-ID: <1501700761.19.0.284106835354.issue31110@psf.upfronthosting.co.za>


New submission from cwee:

Starting with 3.4, the docs for plistlib have had a typo:
https://docs.python.org/3.4/library/plistlib.html#plistlib.readPlist
https://docs.python.org/3.5/library/plistlib.html#plistlib.readPlist
https://docs.python.org/3.6/library/plistlib.html#plistlib.readPlist
https://docs.python.org/3.7/library/plistlib.html#plistlib.readPlist

Functions `readPlist` and `readPlistFromBytes` reference the `__getitem_` method, which should be `__getitem__`.

I'd be happy to submit a PR if there's a repo for the site's documentation.

----------
assignee: docs at python
components: Documentation
messages: 299668
nosy: cwee, docs at python
priority: normal
severity: normal
status: open
title: Small typo in plistlib docs
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Aug  3 02:06:59 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Aug 2017 06:06:59 +0000
Subject: [docs] [issue31110] Small typo in plistlib docs
In-Reply-To: <1501700761.19.0.284106835354.issue31110@psf.upfronthosting.co.za>
Message-ID: <1501740419.09.0.474888691041.issue31110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

https://github.com/python/cpython

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

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

From report at bugs.python.org  Thu Aug  3 02:11:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Aug 2017 06:11:51 +0000
Subject: [docs] [issue31110] Small typo in plistlib docs
In-Reply-To: <1501700761.19.0.284106835354.issue31110@psf.upfronthosting.co.za>
Message-ID: <1501740710.97.0.0978053874558.issue31110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

3.4 and 3.5 can take only security fixes. Create a PR for the master branch. After merging it the changes can be cherry-picked into the 3.6 branch. See details in Python Developer?s Guide (https://docs.python.org/devguide/).

----------
stage:  -> needs patch
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug  3 10:43:54 2017
From: report at bugs.python.org (cwee)
Date: Thu, 03 Aug 2017 14:43:54 +0000
Subject: [docs] [issue31110] Small typo in plistlib docs
In-Reply-To: <1501700761.19.0.284106835354.issue31110@psf.upfronthosting.co.za>
Message-ID: <1501771434.89.0.867502767083.issue31110@psf.upfronthosting.co.za>


cwee added the comment:

Just noticed the note was removed in commit edef358ed6d in the latest 3.7 docs. Closing issue.

Thanks for the intro on how to contribute though!

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Aug  3 19:54:21 2017
From: report at bugs.python.org (Benjamin Swan)
Date: Thu, 03 Aug 2017 23:54:21 +0000
Subject: [docs] [issue30882] Built-in list disappeared from Python 2.7
 intersphinx inventory
In-Reply-To: <1499622808.04.0.381858845257.issue30882@psf.upfronthosting.co.za>
Message-ID: <1501804461.8.0.745611754309.issue30882@psf.upfronthosting.co.za>


Changes by Benjamin Swan <qcontinueum at gmail.com>:


----------
nosy: +Benjamin Swan

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

From report at bugs.python.org  Thu Aug  3 21:43:52 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 04 Aug 2017 01:43:52 +0000
Subject: [docs] [issue27470] -3 commandline option documented differently
 via man
In-Reply-To: <1467994985.16.0.513883147731.issue27470@psf.upfronthosting.co.za>
Message-ID: <1501811032.54.0.849951559343.issue27470@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Thu Aug  3 22:00:15 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 04 Aug 2017 02:00:15 +0000
Subject: [docs] [issue27470] -3 commandline option documented differently
 via man
In-Reply-To: <1467994985.16.0.513883147731.issue27470@psf.upfronthosting.co.za>
Message-ID: <1501812015.36.0.155317650264.issue27470@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:


New changeset dd6e4aa113c6db4fcf9d252b5063ab217e8330a2 by Mariatta (Subhendu Ghosh) in branch '2.7':
bpo-27470: Improve doc for commandline -3 option
https://github.com/python/cpython/commit/dd6e4aa113c6db4fcf9d252b5063ab217e8330a2


----------
nosy: +Mariatta

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

From report at bugs.python.org  Thu Aug  3 22:02:55 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 04 Aug 2017 02:02:55 +0000
Subject: [docs] [issue27470] -3 commandline option documented differently
 via man
In-Reply-To: <1467994985.16.0.513883147731.issue27470@psf.upfronthosting.co.za>
Message-ID: <1501812175.79.0.631019517938.issue27470@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Fri Aug  4 07:41:14 2017
From: report at bugs.python.org (Johannes Lade)
Date: Fri, 04 Aug 2017 11:41:14 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
 refers to "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1501846874.37.0.831716987005.issue23702@psf.upfronthosting.co.za>


Johannes Lade added the comment:

This is still a problem. Can please somebody fix this? There are already enough confusing discussion full of wrong information about this topic, so it would be nice if the official documentation would get it right. Also there's multiple Issues for this. Can they be combined into one?
Just one example I found: on https://docs.python.org/3.5/howto/descriptor.html#functions-and-methods

Documentation:
>>> class D(object):
...     def f(self, x):
...         return x
...
>>> d = D()
>>> D.__dict__['f']  # Stored internally as a function
<function f at 0x00C45070>
>>> D.f              # Get from a class becomes an unbound method
<unbound method D.f>
>>> d.f              # Get from an instance becomes a bound method
<bound method D.f of <__main__.D object at 0x00B18C90>>

ipython3.5.3
In [1]: class D(object):
   ...: ...     def f(self, x):
   ...: ...         return x
   ...: ...

In [2]: d = D()

In [3]: D.__dict__['f']  # Stored internally as a function
Out[3]: <function __main__.D.f>

In [4]: D.f              # Get from a class becomes an unbound method
Out[4]: <function __main__.D.f>

In [5]: d.f              # Get from an instance becomes a bound method
Out[5]: <bound method D.f of <__main__.D object at 0x7f4e2e278c18>>

----------
nosy: +Johannes Lade

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

From report at bugs.python.org  Fri Aug  4 07:44:29 2017
From: report at bugs.python.org (Johannes Lade)
Date: Fri, 04 Aug 2017 11:44:29 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
 refers to "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1501847069.3.0.628497285824.issue23702@psf.upfronthosting.co.za>


Johannes Lade added the comment:

And sorry for my lousy manners. Of course I appreciate all the hard work you do! It's just frustrating when you get confused by doc.

----------

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

From report at bugs.python.org  Fri Aug  4 11:33:19 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Aug 2017 15:33:19 +0000
Subject: [docs] [issue23702] docs.python.org/3/howto/descriptor.html still
 refers to "unbound methods"
In-Reply-To: <1426708114.47.0.635748134131.issue23702@psf.upfronthosting.co.za>
Message-ID: <1501860799.44.0.532506528842.issue23702@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

We have a sprint in early September and I'll fix it then.

----------

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

From report at bugs.python.org  Fri Aug  4 22:58:12 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Aug 2017 02:58:12 +0000
Subject: [docs] [issue31082] reduce takes iterable, not just sequence
In-Reply-To: <1501448787.5.0.80084797494.issue31082@psf.upfronthosting.co.za>
Message-ID: <1501901892.36.0.117096650734.issue31082@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, given that the parameters of reduce are currently positional only (by experiment, it has not gotten the C.A. treatment yet), can 'sequence' in the signature in the docstring be changes to 'iterable'?

----------
nosy: +serhiy.storchaka, terry.reedy

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

From report at bugs.python.org  Sat Aug  5 00:26:33 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Aug 2017 04:26:33 +0000
Subject: [docs] [issue31082] reduce takes iterable, not just sequence
In-Reply-To: <1501448787.5.0.80084797494.issue31082@psf.upfronthosting.co.za>
Message-ID: <1501907193.69.0.298170213019.issue31082@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, I think it can. But be aware that "sequence" is used not only in the signature, but in following description.

The term "sequence" in the documentation and the docstring looks to me like a synonym of "iterable", not a reference to collections.abc.Sequence. I don't know how the wording can be improved. Maybe looking at the documentation of builtins filter, map, zip, and itertools functions can help.

----------
nosy: +ncoghlan, rhettinger

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

From report at bugs.python.org  Sun Aug  6 15:00:42 2017
From: report at bugs.python.org (Kevin Shweh)
Date: Sun, 06 Aug 2017 19:00:42 +0000
Subject: [docs] [issue31127] Abstract classes derived from built-in classes
 don't block instance creation
Message-ID: <1502046042.43.0.230510870536.issue31127@psf.upfronthosting.co.za>


New submission from Kevin Shweh:

The only check that prevents instantiating abstract classes is in object.__new__, but most built-in classes never actually call object.__new__. That means you can do stuff like

import abc

class Foo(list, metaclass=abc.ABCMeta):
	@abc.abstractmethod
	def abstract(self):
		pass

Foo()

and the Foo() call will silently succeed.

Ideally, the Foo() call should fail. Other options include having the Foo class definition itself fail, or just making a note in the documentation describing the limitation. (As far as I can see, this is currently undocumented.)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 299810
nosy: Kevin Shweh, docs at python
priority: normal
severity: normal
status: open
title: Abstract classes derived from built-in classes don't block instance creation
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Sun Aug  6 17:39:14 2017
From: report at bugs.python.org (R. David Murray)
Date: Sun, 06 Aug 2017 21:39:14 +0000
Subject: [docs] [issue31127] Abstract classes derived from built-in classes
 don't block instance creation
In-Reply-To: <1502046042.43.0.230510870536.issue31127@psf.upfronthosting.co.za>
Message-ID: <1502055554.72.0.877186875702.issue31127@psf.upfronthosting.co.za>


R. David Murray added the comment:

This is a duplidate of issue 5996.  It is not clear if we are going to treat it as a bug or a doc bug.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> abstract class instantiable when subclassing dict

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

From report at bugs.python.org  Sun Aug  6 18:55:50 2017
From: report at bugs.python.org (Feanil Patel)
Date: Sun, 06 Aug 2017 22:55:50 +0000
Subject: [docs] [issue31128] Allow pydoc to run with an arbitrary hostname
Message-ID: <1502060150.4.0.12208327143.issue31128@psf.upfronthosting.co.za>


New submission from Feanil Patel:

I want to run the pydoc server while doing development inside a container.  However, the pydoc http server only binds to localhost with no option to override this.  This means that if I'm trying to read the docs from a remote machine,  I have to do some network Jiu Jitsu.

Acceptance Criteria:
- Pydoc takes a new argument that overrides the hostname the server binds to.
- Pydoc continues to default to localhost

----------
assignee: docs at python
components: Documentation
messages: 299817
nosy: Feanil Patel, docs at python
priority: normal
severity: normal
status: open
title: Allow pydoc to run with an arbitrary hostname
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sun Aug  6 19:00:34 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Aug 2017 23:00:34 +0000
Subject: [docs] [issue31128] Allow pydoc to run with an arbitrary hostname
In-Reply-To: <1502060150.4.0.12208327143.issue31128@psf.upfronthosting.co.za>
Message-ID: <1502060434.05.0.564896519055.issue31128@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3044

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

From report at bugs.python.org  Mon Aug  7 00:40:14 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Aug 2017 04:40:14 +0000
Subject: [docs] [issue29555] Update Python Software Foundation Copyright Year
In-Reply-To: <1487088120.64.0.260258993464.issue29555@psf.upfronthosting.co.za>
Message-ID: <1502080814.52.0.46999261021.issue29555@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Van, could you take a look at Senthil & Mariatta's questions above regarding our handling of the copyright year in CPython's module headers?

----------
nosy: +ncoghlan, vanl

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

From report at bugs.python.org  Mon Aug  7 01:20:01 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 07 Aug 2017 05:20:01 +0000
Subject: [docs] [issue31082] reduce takes iterable, not just sequence
In-Reply-To: <1501448787.5.0.80084797494.issue31082@psf.upfronthosting.co.za>
Message-ID: <1502083201.89.0.173960348594.issue31082@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Checking older versions of the docs, it looks like we simply haven't reworded those docs since Python 2.0 (when the "list" of the 1.5 docs became "sequence" for 2.0).

So I think the most appropriate resolution here would be to replace the current use of "sequence" with "iterable" in both the code and the documentation.

----------

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

From clanker at gmx.com  Sat Aug  5 12:00:42 2017
From: clanker at gmx.com (Cory Lanker)
Date: Sat, 5 Aug 2017 09:00:42 -0700
Subject: [docs] Potential documentation bug in Python 3 Tutorial about
 locale.setlocale
Message-ID: <E129E48C-D692-454B-9F56-2128445076DB@gmx.com>

Perhaps this is incorrect, but the line in section 11.1:
locale.setlocale(locale.LC_ALL, 'English_United States.1252')
didn?t work. I believe the problem is my platform is Mac OS. The following worked for me but wasn?t obvious:
locale.setlocale(locale.LC_ALL, ?en_US.UTF-8')

Overall, your tutorial is fantastic and I appreciate the effort taken to create it.

Best,
Cory

Cory Lanker

From Shahzeb.Siddiqui at pfizer.com  Wed Aug  2 12:53:21 2017
From: Shahzeb.Siddiqui at pfizer.com (Siddiqui, Shahzeb)
Date: Wed, 2 Aug 2017 16:53:21 +0000
Subject: [docs] trouble uploading package
Message-ID: <04A311CA8BF2B14F8E82B311197ED9E1540A636F@NDHAMREXDB01.amer.pfizer.com>

Can someone help me out in this.

From: Siddiqui, Shahzeb
Sent: Thursday, July 27, 2017 6:29 PM
To: 'docs at python.org'
Subject: trouble uploading package

Hello,

I am trying to upload a python package for the first time. I am getting some issues. I looked at the documentation, and followed the process. I have created my account, and its verified. The upload is failing. Please advise

[siddis14 at amrndhl1157 buildtest-framework]$ python setup.py register sdist upload
running register
running egg_info
writing buildtest_framework.egg-info/PKG-INFO
writing top-level names to buildtest_framework.egg-info/top_level.txt
writing dependency_links to buildtest_framework.egg-info/dependency_links.txt
reading manifest file 'buildtest_framework.egg-info/SOURCES.txt'
writing manifest file 'buildtest_framework.egg-info/SOURCES.txt'
running check
We need to know who you are, so please choose either:
1. use your existing login,
2. register as a new user,
3. have the server generate a new password for you (and email it to you), or
4. quit
Your selection [default 1]:
1
Username: shahzeb.siddiqui
Password:
Registering buildtest-framework to https://upload.pypi.org/legacy/
Server response (410): Project pre-registration is no longer required or supported, so continue directly to uploading files.
running sdist
creating buildtest-framework-1.0.1
creating buildtest-framework-1.0.1/buildtest_framework.egg-info
copying files to buildtest-framework-1.0.1...
copying README.rst -> buildtest-framework-1.0.1
copying setup.py -> buildtest-framework-1.0.1
copying buildtest_framework.egg-info/PKG-INFO -> buildtest-framework-1.0.1/buildtest_framework.egg-info
copying buildtest_framework.egg-info/SOURCES.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info
copying buildtest_framework.egg-info/dependency_links.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info
copying buildtest_framework.egg-info/not-zip-safe -> buildtest-framework-1.0.1/buildtest_framework.egg-info
copying buildtest_framework.egg-info/top_level.txt -> buildtest-framework-1.0.1/buildtest_framework.egg-info
Writing buildtest-framework-1.0.1/setup.cfg
Creating tar archive
removing 'buildtest-framework-1.0.1' (and everything under it)
running upload
Password:
Submitting dist/buildtest-framework-1.0.1.tar.gz to https://upload.pypi.org/legacy/
Upload failed (403): Invalid or non-existent authentication information.
error: Upload failed (403): Invalid or non-existent authentication information.

I have the following file, I didn't make any changes

[siddis14 at amrndhl1157 buildtest-framework]$ cat ~/.pypirc
[distutils]
index-servers =
    pypi

[pypi]
repository: <repository-url>
username: <username>
password: <password>

What is the problem?


Shahzeb Siddiqui
HPC Linux Engineer
B2220-447.2
Groton, CT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170802/1e0e38f1/attachment-0001.html>

From report at bugs.python.org  Mon Aug  7 04:27:24 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Aug 2017 08:27:24 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502094444.27.0.719314713611.issue31045@psf.upfronthosting.co.za>


STINNER Victor added the comment:


New changeset dff9b5f9d62aa0b23f8a255867d09d11890efd1b by Victor Stinner (Julien) in branch 'master':
bpo-31045: Language switch (#2652)
https://github.com/python/cpython/commit/dff9b5f9d62aa0b23f8a255867d09d11890efd1b


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

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

From report at bugs.python.org  Mon Aug  7 22:26:09 2017
From: report at bugs.python.org (Louie Lu)
Date: Tue, 08 Aug 2017 02:26:09 +0000
Subject: [docs] [issue31139] Improve tracemalloc demo code in docs
Message-ID: <1502159168.93.0.181996633352.issue31139@psf.upfronthosting.co.za>


New submission from Louie Lu:

Current tutorial of tracemalloc:
https://docs.python.org/3/library/tracemalloc.html

Current doc using a un-reproducible output, that will confuse the reader. Propose to use the test code `allocate_bytes` to control the memory usage output, provide more meaningful output to reader.

----------
assignee: docs at python
components: Documentation
messages: 299892
nosy: docs at python, haypo, louielu
priority: normal
severity: normal
status: open
title: Improve tracemalloc demo code in docs
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Aug  7 23:40:47 2017
From: report at bugs.python.org (Louie Lu)
Date: Tue, 08 Aug 2017 03:40:47 +0000
Subject: [docs] [issue31139] Improve tracemalloc demo code in docs
In-Reply-To: <1502159168.93.0.181996633352.issue31139@psf.upfronthosting.co.za>
Message-ID: <1502163647.87.0.724387131811.issue31139@psf.upfronthosting.co.za>


Changes by Louie Lu <me at louie.lu>:


----------
pull_requests: +3053

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

From report at bugs.python.org  Tue Aug  8 07:16:25 2017
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 08 Aug 2017 11:16:25 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1502190985.34.0.298935539174.issue25910@psf.upfronthosting.co.za>


Larry Hastings added the comment:


New changeset 14167c9524bd65f231dfd85edc0b938c4781f42a by Larry Hastings (Mariatta) in branch '3.5':
bpo-25910: Update LICENSE (GH-2873) (GH-2968)
https://github.com/python/cpython/commit/14167c9524bd65f231dfd85edc0b938c4781f42a


----------
nosy: +larry

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

From report at bugs.python.org  Tue Aug  8 07:55:44 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Aug 2017 11:55:44 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502193344.9.0.935876677689.issue31045@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3056

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

From report at bugs.python.org  Tue Aug  8 07:56:21 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Aug 2017 11:56:21 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502193381.7.0.567749451224.issue31045@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3058

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

From report at bugs.python.org  Tue Aug  8 08:13:56 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Aug 2017 12:13:56 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502194435.99.0.552122089349.issue31045@psf.upfronthosting.co.za>


STINNER Victor added the comment:


New changeset e93135dbb265e801c0000a19cd9c5428d57d1cf4 by Victor Stinner (Julien Palard) in branch '3.6':
bpo-31045: Language switch (#2652) (#3023)
https://github.com/python/cpython/commit/e93135dbb265e801c0000a19cd9c5428d57d1cf4


----------

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

From report at bugs.python.org  Tue Aug  8 08:14:25 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Aug 2017 12:14:25 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502194465.69.0.982604688458.issue31045@psf.upfronthosting.co.za>


STINNER Victor added the comment:


New changeset 245dafca85097dd8b84f02b01f39f5d32091754b by Victor Stinner (Julien Palard) in branch '2.7':
bpo-31045: Language switch (#2652) (#3024)
https://github.com/python/cpython/commit/245dafca85097dd8b84f02b01f39f5d32091754b


----------

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

From report at bugs.python.org  Tue Aug  8 08:16:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Aug 2017 12:16:26 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502194586.3.0.487436447404.issue31045@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Even if changes are merged, I prefer to wait until the doc at docs.python.org is to date before closing the issue.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Aug  8 10:23:19 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Aug 2017 14:23:19 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502202199.06.0.785707662025.issue22635@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Bug mentionned on a Twitter discussion:
https://twitter.com/zhenech/status/894444040992829441

----------

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

From report at bugs.python.org  Tue Aug  8 11:17:12 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Aug 2017 15:17:12 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502205432.25.0.217985416366.issue31045@psf.upfronthosting.co.za>


Ned Deily added the comment:

For future reference, please make sure to include current release managers on proposed changes like this since doc building and distribution is part of the release process.

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

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

From report at bugs.python.org  Tue Aug  8 11:29:40 2017
From: report at bugs.python.org (Julien Palard)
Date: Tue, 08 Aug 2017 15:29:40 +0000
Subject: [docs] [issue31146] Docs: On non-public translations,
 language picker fallback to "English"
Message-ID: <1502206180.29.0.859774070814.issue31146@psf.upfronthosting.co.za>


New submission from Julien Palard:

As, by default, "english" is selected, and as we're building translations far before rendering them public by adding them to the language switcher, there's a timespan where a human can voluntarily land on a translation with a language switcher unaware of this language.

The language switcher currently defaults to english, so english is selected. As "english" is already selected, one can't select "english" to navigate to the english version.

Solutions may be to just hide the select element on unknown translations, or display the unknown language tag. With more work and a "predicted" list of tags-names, it may be possible to also display the name of the language.


Code is here: https://github.com/python/cpython/blob/master/Doc/tools/static/switchers.js

I'll take a look, but if some want to do it, let me know.

----------
assignee: docs at python
components: Documentation
messages: 299932
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Docs: On non-public translations, language picker fallback to "English"
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Aug  8 11:34:39 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 08 Aug 2017 15:34:39 +0000
Subject: [docs] [issue31146] Docs: On non-public translations,
 language picker fallback to "English"
In-Reply-To: <1502206180.29.0.859774070814.issue31146@psf.upfronthosting.co.za>
Message-ID: <1502206479.2.0.976897715122.issue31146@psf.upfronthosting.co.za>


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


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

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

From songofacandy at gmail.com  Tue Aug  8 13:11:54 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 9 Aug 2017 02:11:54 +0900
Subject: [docs] Enable dynamic compression on docs.python.org
Message-ID: <CAEfz+TzifxM1y_Rda1qKX16g6VgTOBSJWpm_Y6RajLbT2CqM2w@mail.gmail.com>

Hi,

I notice that docs.python.org doesn't serve compressed contents.

I believe docs.python.org uses Fastly.
And Fastly has dynamic automatic gzipping.
https://docs.fastly.com/guides/basic-configuration/enabling-automatic-gzipping

I think it's very nice for many visitors.  And it's easier than configure
gzip_static on nginx.

How about enabling it?

Regards,

INADA Naoki  <songofacandy at gmail.com>

From report at bugs.python.org  Tue Aug  8 22:37:55 2017
From: report at bugs.python.org (Lorem Ipsum)
Date: Wed, 09 Aug 2017 02:37:55 +0000
Subject: [docs] [issue31152] Tutorial wording implies an understanding of a
 concept prior to it being introduced
Message-ID: <1502246275.38.0.890057309211.issue31152@psf.upfronthosting.co.za>


New submission from Lorem Ipsum:

Python 3.5.4 Tutorial Section 8.5. User-defined Exceptions Paragraph 2 (https://docs.python.org/3.5/tutorial/errors.html#user-defined-exceptions) states [emphasis mine]:

"When creating a module that can raise several distinct errors, a common practice is to create a base class for exceptions defined by that module, and SUBCLASS THAT TO create specific exception classes for different error conditions:"

The use of 'subclass' as a verb when it has not been used so prior is confusing, especially to beginners.  The concept of a class is not formally covered until Section 9 and up until this point in the tutorial, 'class' has been used as a noun.  When read with 'subclass' as a noun, the sentence is nonsensical. It may also be that the comma which precedes 'and' is not proper usage. 

Suggested improvement: change "subclass that to create specific classes for..." to "then create specific exception subclasses for..."

"When creating a module that can raise several distinct errors, a common practice is to create a base class for exceptions defined by that module, and then create specific exception subclasses for different error conditions:"

----------
assignee: docs at python
components: Documentation
messages: 299962
nosy: Lorem Ipsum, docs at python
priority: normal
severity: normal
status: open
title: Tutorial wording implies an understanding of a concept prior to it being introduced
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  8 23:28:18 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Aug 2017 03:28:18 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502249298.78.0.521809447135.issue22635@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've added Greg to the nosy list and filed an issue with subprocess32 about this: https://github.com/google/python-subprocess32/issues/30

I did that mainly to make sure they don't inadvertently backport this regression, but also to ask if subprocess32 might potentially provide a way to get the old intended-but-not-actually-tested behaviour back in 3.x.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Tue Aug  8 23:54:09 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Aug 2017 03:54:09 +0000
Subject: [docs] [issue31152] Tutorial wording implies an understanding of a
 concept prior to it being introduced
In-Reply-To: <1502246275.38.0.890057309211.issue31152@psf.upfronthosting.co.za>
Message-ID: <1502250849.25.0.943935476094.issue31152@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It is okay for the tutorial to occasionally have forward references. 
 Python is a fully object oriented language so references to classes and instances will appear in many places.  AFAICT, this particular passage has never caused any reported difficulty for any users.  As it reads now, I find it to be clear and correct guidance.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Wed Aug  9 00:57:10 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Aug 2017 04:57:10 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502254630.09.0.880940337717.issue22635@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I intend subprocess32 to Python 2 only.  Python 3 users should use the standard library subprocess module.

subprocess32 does not include getstatusoutput() or getoutput() functions as those are available in the Python 2 stdlib commands module.

----------

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

From report at bugs.python.org  Wed Aug  9 01:05:04 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Aug 2017 05:05:04 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502255104.52.0.641545383871.issue22635@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

If you want something API compatible that can be used in a Python 2 and 3 application that wants a getstatusoutput() API I think an appropriate place to put it would be to add a commands modules to https://pypi.python.org/pypi/past/ with a consistent getstatusoutput() API.  Either there or something in https://pypi.python.org/pypi/six/.

The inadvertent API difference between 2.7 commands.getstatusoutput() and 3.3.4 subprocess.getstatusoutput() is unfortunate but - I agree - too late to change.  Fixing the documentation to mention the discrepancy is the least worst option.

----------

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

From report at bugs.python.org  Wed Aug  9 02:52:09 2017
From: report at bugs.python.org (SylvainDe)
Date: Wed, 09 Aug 2017 06:52:09 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1502261529.13.0.307059274498.issue26656@psf.upfronthosting.co.za>


SylvainDe added the comment:

@swapnil agarwal I think you can go for it.

----------

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

From report at bugs.python.org  Wed Aug  9 03:38:57 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Aug 2017 07:38:57 +0000
Subject: [docs] [issue31082] reduce takes iterable, not just sequence
In-Reply-To: <1501448787.5.0.80084797494.issue31082@psf.upfronthosting.co.za>
Message-ID: <1502264337.9.0.248278007723.issue31082@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The term "sequence" also is used in the docstring of itertools.starmap() (actually an iterable is accepted).

----------

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

From report at bugs.python.org  Wed Aug  9 03:42:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Aug 2017 07:42:39 +0000
Subject: [docs] [issue31153] Update docstrings of itertools function
Message-ID: <1502264559.87.0.404253644107.issue31153@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Docstrings of some itertools functions look outdated.

1. The docstring of groupby() contains the signature "groupby(iterable[, keyfunc])". But groupby() supports keyword arguments, the name of the second parameter is "key", and its default value is None.

2. accumulate() accepts None as the second argument.

3. The equivalent code of count() has the first parameter "firstval" instead of "start". It uses the "while 1" loop instead of more idiomatic in Python 3 "while True".

4. The term "sequence" is used in the docstring of starmap(), while actually an iterable is accepted. Compare with the docstring of map(). See also issue31082.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 299975
nosy: docs at python, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Update docstrings of itertools function
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Aug  9 03:50:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 09 Aug 2017 07:50:38 +0000
Subject: [docs] [issue31153] Update docstrings of itertools functions
In-Reply-To: <1502264559.87.0.404253644107.issue31153@psf.upfronthosting.co.za>
Message-ID: <1502265038.28.0.185369526511.issue31153@psf.upfronthosting.co.za>


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


----------
title: Update docstrings of itertools function -> Update docstrings of itertools functions

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

From report at bugs.python.org  Wed Aug  9 04:07:01 2017
From: report at bugs.python.org (Alberto Gomez-Casado)
Date: Wed, 09 Aug 2017 08:07:01 +0000
Subject: [docs] [issue31154] Path.replace and Path.rename naming,
 behavior and documentation
Message-ID: <1502266021.69.0.915795011515.issue31154@psf.upfronthosting.co.za>


New submission from Alberto Gomez-Casado:

I find the naming of Path.replace quite unfortunate, coming from the os.path and basestring mindset, the expectation would be that it would change some substring by another substring in the Path instance. Instead, it _moves_ the file indicated by the Path object in the file system. Most of the methods of Path have no effect in the filesystem, and we have here one with a slightly misleading name which goes and moves your files around.

Practically the same operation is done with Path.rename, which is less surprising since it matches popular OS commands/UIs (ren, Rename).

IMHO Path.replace should not exist as is and a keyword modifier (silent?) for Path.rename toggles between the minor behavior differences of the two. 

Additionally:

Both calls lack any kind of return, which leads me to expect after a rename/replace the Path instance would be changed to the new path. This is not the case, after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path. Returning the new path would be another reasonable option. In any case, I think the documentation should mention this behavior explicitly. 

And, while we are at it, having implemented the relatively dangerous replace/rename (along with convenience shorcuts for reading, writing, opening...), why was a Path.copy not included?

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 299976
nosy: Alberto Gomez-Casado, docs at python
priority: normal
severity: normal
status: open
title: Path.replace and Path.rename naming, behavior and documentation
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug  9 05:21:04 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Aug 2017 09:21:04 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502270464.81.0.980131134285.issue22635@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMHO it's too late to change *again* subprocess.getstatusoutput() behaviour. Otherwise, it would mean that a complex test like "if not((3, 4) <= sys.version_info < (3, 7))" would be needed to workaround the bug... Whereas right now, basically we only have to check if we are running on Python 3 or not. (Python 3.0-3.3 is almost not used in the wild.)

Instead we should just *document* the behaviour change using ".. versionchanged:: 3.4" in Doc/library/subprocess.rst.

Any volunteer to do that?

----------

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

From report at bugs.python.org  Wed Aug  9 05:49:19 2017
From: report at bugs.python.org (=?utf-8?q?G=C3=BCnter_Rote?=)
Date: Wed, 09 Aug 2017 09:49:19 +0000
Subject: [docs] [issue31156] Stopiteration terminates while-loop
Message-ID: <1502272159.56.0.437301068833.issue31156@psf.upfronthosting.co.za>


New submission from G?nter Rote:

It should be mentioned in the documentation that 

A StopIteration exception raised in the body of a while loop will terminate (and is caught by) the while-loop, thus leading to graceful termination.

A good place would be here:
1) https://docs.python.org/3/reference/compound_stmts.html#the-while-statement

I don't know how such a StopIteration termination of a while loop
affects the else-clause. This should be clarified.

Here:
2) https://docs.python.org/3/library/exceptions.html#StopIteration
it would be good to explicitly state:

An enclosing while-loop or for-loop acts like an implicit catch for StopIteration. The StopIteration exception will terminate the loop.

(I guess, a for-loop is also just terminated when the StopIteration originates in the BODY of the loop, although this is not the typical case.)

----------
assignee: docs at python
components: Documentation
messages: 299982
nosy: G?nter Rote, docs at python
priority: normal
severity: normal
status: open
title: Stopiteration terminates while-loop
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug  9 07:55:18 2017
From: report at bugs.python.org (Julien Palard)
Date: Wed, 09 Aug 2017 11:55:18 +0000
Subject: [docs] [issue31045] Add a language switch to the Python
 documentation
In-Reply-To: <1501078214.01.0.529111921671.issue31045@psf.upfronthosting.co.za>
Message-ID: <1502279718.51.0.155426109776.issue31045@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


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

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

From paulo.gp at icloud.com  Tue Aug  8 06:45:48 2017
From: paulo.gp at icloud.com (Paulo Portela)
Date: Tue, 08 Aug 2017 10:45:48 +0000 (GMT)
Subject: [docs] Docs - Open Arguments
Message-ID: <ac8f96ae-18c3-43cf-a24f-4aa4dc94a48a@me.com>

Hello Community,

?I think there is a bug with the documentation with the topic "7. Input and Output"
?Link:?https://docs.python.org/3.6/tutorial/inputoutput.html
?
?7.2. Reading and Writing Files
?"open() returns a file object, and is most commonly used with two arguments: open(filename, mode)."
?
?The arguments for this function are open(file, mode).

?https://docs.python.org/3.6/library/functions.html#open
?open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)
?

Best regards
Paulo G.P.

https://about.me/paulogp
https://www.python.org/users/paulogp/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170808/186cd1b8/attachment.html>

From report at bugs.python.org  Wed Aug  9 09:30:18 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Aug 2017 13:30:18 +0000
Subject: [docs] [issue31154] Path.replace and Path.rename naming,
 behavior and documentation
In-Reply-To: <1502266021.69.0.915795011515.issue31154@psf.upfronthosting.co.za>
Message-ID: <1502285418.78.0.945007660307.issue31154@psf.upfronthosting.co.za>


R. David Murray added the comment:

Both the replace and rename functions will remain in the API, as they mirror the os module, not the os itself.  I agree that the naming is unfortunate, but it has the weight of history behind it, so we are stuck with it.  Issue 24229 rejected adding a copy method.  

Having replace and rename return a value strikes me as a good idea.  Please open a separate issue with that enhancement proposal, and nosy 'pitrou', who is the author of the pathlib module.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Aug  9 09:37:55 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Aug 2017 13:37:55 +0000
Subject: [docs] [issue31156] Stopiteration terminates while-loop
In-Reply-To: <1502272159.56.0.437301068833.issue31156@psf.upfronthosting.co.za>
Message-ID: <1502285874.97.0.988111911739.issue31156@psf.upfronthosting.co.za>


R. David Murray added the comment:

>>> while True:
...     raise StopIteration
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
StopIteration

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

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

From report at bugs.python.org  Wed Aug  9 10:22:02 2017
From: report at bugs.python.org (=?utf-8?q?G=C3=BCnter_Rote?=)
Date: Wed, 09 Aug 2017 14:22:02 +0000
Subject: [docs] [issue31156] Stopiteration terminates while-loop
In-Reply-To: <1502272159.56.0.437301068833.issue31156@psf.upfronthosting.co.za>
Message-ID: <1502288522.63.0.578433190572.issue31156@psf.upfronthosting.co.za>


G?nter Rote added the comment:

Sorry, that was my misinterpretation of what happened.
I had been stumbling over an old program I had written, but
apparently it works because the while-loop is inside
a generator function, and the StopIteration is simply
passed on.

Here is a small demonstration example:
>>> def f():
...   for x in range(5):
...     yield x
... 
>>> def g():
...   h=f()
...   while True:
...      yield next(h)+100
...      yield next(h)
... 
>>> list(g())
[100, 1, 102, 3, 104]

(I am beginning to wonder whether this program will be adversely affected by PEP 479 -- Change StopIteration handling inside generators.)

----------
stage:  -> resolved
status: open -> closed
versions: +Python 3.4 -Python 3.6

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

From report at bugs.python.org  Wed Aug  9 11:13:14 2017
From: report at bugs.python.org (Emily Morehouse)
Date: Wed, 09 Aug 2017 15:13:14 +0000
Subject: [docs] [issue31152] Tutorial wording implies an understanding of a
 concept prior to it being introduced
In-Reply-To: <1502246275.38.0.890057309211.issue31152@psf.upfronthosting.co.za>
Message-ID: <1502291594.09.0.417501370421.issue31152@psf.upfronthosting.co.za>


Emily Morehouse added the comment:

I concur with Raymond, particularly because paragraph 1 of section 8.5 links to the Classes tutorial which covers inheritance. I think the documentation is sufficient as is.

----------
nosy: +emilyemorehouse

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

From report at bugs.python.org  Wed Aug  9 11:32:24 2017
From: report at bugs.python.org (Alberto Gomez-Casado)
Date: Wed, 09 Aug 2017 15:32:24 +0000
Subject: [docs] [issue31163] Return destination path in Path.rename and
 Path.replace
Message-ID: <1502292744.48.0.627996317333.issue31163@psf.upfronthosting.co.za>


New submission from Alberto Gomez-Casado:

Extracted from issue31154

Both calls lack any kind of return, which leads me to expect after a rename/replace the Path instance would be changed to the new path. This is not the case (reading the PEP I have seen Path instances are kind of immutable), after the call the Path instance keeps "pointing" to the previous (and quite likely now useless) path. 

Returning the new path would be a reasonable option. In any case, I think the documentation should mention this behavior explicitly.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 300019
nosy: Alberto Gomez-Casado, docs at python, pitrou
priority: normal
severity: normal
status: open
title: Return destination path in Path.rename and Path.replace
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed Aug  9 14:14:33 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 09 Aug 2017 18:14:33 +0000
Subject: [docs] [issue31163] Return destination path in Path.rename and
 Path.replace
In-Reply-To: <1502292744.48.0.627996317333.issue31163@psf.upfronthosting.co.za>
Message-ID: <1502302473.8.0.559509484321.issue31163@psf.upfronthosting.co.za>


R. David Murray added the comment:

I agree.  The normal python convention is that an immutable object returns the new value when an operation "changes" it, while a mutable object returns None.  It seems like replace and rename should follow this convention (and that it would also be convenient).

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

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

From report at bugs.python.org  Wed Aug  9 14:39:08 2017
From: report at bugs.python.org (nicholas kobald)
Date: Wed, 09 Aug 2017 18:39:08 +0000
Subject: [docs] [issue31153] Update docstrings of itertools functions
In-Reply-To: <1502264559.87.0.404253644107.issue31153@psf.upfronthosting.co.za>
Message-ID: <1502303948.9.0.305147733924.issue31153@psf.upfronthosting.co.za>


Changes by nicholas kobald <nick.kobald at gmail.com>:


----------
pull_requests: +3081

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

From report at bugs.python.org  Wed Aug  9 15:14:14 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Aug 2017 19:14:14 +0000
Subject: [docs] [issue31152] Tutorial wording implies an understanding of a
 concept prior to it being introduced
In-Reply-To: <1502246275.38.0.890057309211.issue31152@psf.upfronthosting.co.za>
Message-ID: <1502306054.86.0.130273133577.issue31152@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Emily, thanks for the second review.
Lorem, thanks for the suggestion, but we're going to decline.

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

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

From report at bugs.python.org  Wed Aug  9 15:17:10 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Aug 2017 19:17:10 +0000
Subject: [docs] [issue31153] Update docstrings of itertools functions
In-Reply-To: <1502264559.87.0.404253644107.issue31153@psf.upfronthosting.co.za>
Message-ID: <1502306231.0.0.652489279686.issue31153@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Aug  9 16:11:35 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Aug 2017 20:11:35 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502309495.72.0.0859881533901.issue22635@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I'll get to it.  acassaigne's patches are already a good attempt at that, i'll probably find wording tweaks to make as I apply them.

----------
assignee: docs at python -> gregory.p.smith

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

From report at bugs.python.org  Wed Aug  9 23:18:08 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 10 Aug 2017 03:18:08 +0000
Subject: [docs] [issue22635] subprocess.getstatusoutput changed behavior in
 3.4 (maybe 3.3.4?)
In-Reply-To: <1413320958.05.0.462062330084.issue22635@psf.upfronthosting.co.za>
Message-ID: <1502335087.78.0.0715221240392.issue22635@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Issue filed with six about this: https://github.com/benjaminp/six/issues/207

It turns out to be somewhat timely on that side as well, as it turns out that six has a not-yet-released change adding "six.moves.commands", which doesn't currently account for this inadvertent incompatibility in the way exit codes are reported.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu Aug 10 09:28:01 2017
From: report at bugs.python.org (twisteroid ambassador)
Date: Thu, 10 Aug 2017 13:28:01 +0000
Subject: [docs] [issue31176] Is a UDP transport also a
 ReadTransport/WriteTransport?
Message-ID: <1502371681.86.0.869371272399.issue31176@psf.upfronthosting.co.za>


New submission from twisteroid ambassador:

In docs / Library Reference / asyncio / Transports and Protocols, it is mentioned that "asyncio currently implements transports for TCP, UDP, SSL, and subprocess pipes. The methods available on a transport depend on the transport?s kind." It also lists methods available on a BaseTransport, ReadTransport, WriteTransport, DatagramTransport and BaseSubprocessTransport.

However, the docs does not explain which transports have methods from which base classes, or in other words which base classes each concrete transport class inherits from. And this may not be obvious: for example, a UDP transport certainly is a DatagramTransport, but is it also a ReadTransport, or a WriteTransport?

(I feel like the answer is "no it isn't", but there are plenty of conflicting evidence. The docs show that WriteTransport has write_eof() and can_write_eof() -- methods clearly geared towards stream-like transports, and it duplicates abort() from DatagramTransport, so it would seem like WriteTransport and DatagramTransport are mutually exclusive. On the other hand, the default concrete implementation of _SelectorDatagramTransport actually inherits from Transport which inherits from both ReadTransport and WriteTransport, yet it does not inherit from DatagramTransport; As a result _SelectorDatagramTransport has all the methods from ReadTransport and WriteTransport, but many of them raise NotImplemented. This is why I'm asking this question in the first place: I found that the transport object I got from create_datagram_endpoint() has both pause_reading() and resume_reading() methods that raise NotImplemented, and thought that perhaps some event loop implementations would have these methods working, and I should try to use them. And before you say "UDP doesn't do flow control", asyncio actually does provide flow control for UDP on the writing end: see https://www.mail-archive.com/python-tulip at googlegroups.com/msg00532.html So it's not preposterous that there might be flow control on the reading end as well.)

I think it would be nice if the documentation can state the methods implemented for each type of transport, as the designers of Python intended, so there's a clear expectation of what methods will / should be available across different implementations of event loops and transports. Something along the lines of "The methods available on a transport depend on the transport?s kind: TCP transports support methods declared in BaseTransport, ReadTransport and WriteTransport below, etc."

----------
assignee: docs at python
components: Documentation, asyncio
messages: 300083
nosy: docs at python, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: Is a UDP transport also a ReadTransport/WriteTransport?
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Aug 10 20:11:47 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Aug 2017 00:11:47 +0000
Subject: [docs] [issue30051] Document that the random module doesn't support
 fork
In-Reply-To: <1491989089.77.0.552733144958.issue30051@psf.upfronthosting.co.za>
Message-ID: <1502410307.11.0.681611213277.issue30051@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since Raymond and Antoine don't like the documentation idea, I just close my issue.

Hopefully, Python 3.7 now reseeds automatically random at fork!

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

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

From report at bugs.python.org  Fri Aug 11 01:20:36 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 11 Aug 2017 05:20:36 +0000
Subject: [docs] [issue12887] Documenting all SO_* constants in socket module
In-Reply-To: <1314987180.49.0.607596056761.issue12887@psf.upfronthosting.co.za>
Message-ID: <1502428836.9.0.62580750417.issue12887@psf.upfronthosting.co.za>


Changes by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +3108

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

From report at bugs.python.org  Fri Aug 11 01:20:36 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 11 Aug 2017 05:20:36 +0000
Subject: [docs] [issue14345] Document socket.SOL_SOCKET
In-Reply-To: <1331962982.1.0.381278454339.issue14345@psf.upfronthosting.co.za>
Message-ID: <1502428836.98.0.451231433388.issue14345@psf.upfronthosting.co.za>


Changes by Ammar Askar <ammar at ammaraskar.com>:


----------
pull_requests: +3109

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

From report at bugs.python.org  Fri Aug 11 01:34:58 2017
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Aug 2017 05:34:58 +0000
Subject: [docs] [issue14345] Document socket.SOL_SOCKET
In-Reply-To: <1331962982.1.0.381278454339.issue14345@psf.upfronthosting.co.za>
Message-ID: <1502429698.79.0.74469926492.issue14345@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


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

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

From report at bugs.python.org  Fri Aug 11 02:53:45 2017
From: report at bugs.python.org (Steve Barnes)
Date: Fri, 11 Aug 2017 06:53:45 +0000
Subject: [docs] [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1502434425.81.0.180402591225.issue28972@psf.upfronthosting.co.za>


Steve Barnes added the comment:

Having done some checks for the practicality of auto documenting library items with a -m command line usage I have to say that it will not be so simple. 

Many of the library items that provide useful functionality, including zipfile & tarfile, are implemented as single .py files, rather than as modules so have no __main__.py to trigger the inclusion in auto-generated documentation. 

I also tried searching for standard library items that use `if __name__ == "__main__":` constructs but, of course, many files simply use that to expose tests rather than useful functionality - so that is out as well. I even thought of trying for a regex that would look for this followed, in the same scope by argparse but of course there is no obligation to use it.

And of course main() does not HAVE to be called main so that is out.

Sorry to scotch the idea Eric!

----------
nosy: +Steve Barnes

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

From report at bugs.python.org  Sat Aug 12 13:59:49 2017
From: report at bugs.python.org (=?utf-8?b?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?=)
Date: Sat, 12 Aug 2017 17:59:49 +0000
Subject: [docs] [issue31189] README.rst: installing multiple versions: typo
Message-ID: <1502560789.4.0.0378607685463.issue31189@psf.upfronthosting.co.za>


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

It speaks about pythonX.Y but means python3.${subversion}

diff --git a/README.rst b/README.rst
--- a/README.rst
+++ b/README.rst
@@ -190,7 +190,7 @@ script) you must take care that your primary python executable is not
 overwritten by the installation of a different version.  All files and
 directories installed using ``make altinstall`` contain the major and minor
 version and can thus live side-by-side.  ``make install`` also creates
-``${prefix}/bin/python3`` which refers to ``${prefix}/bin/pythonX.Y``.  If you
+``${prefix}/bin/python3`` which refers to ``${prefix}/bin/python3.X``.  If you
 intend to install multiple versions using the same prefix you must decide which
 version (if any) is your "primary" version.  Install that version using ``make
 install``.  Install all other versions using ``make altinstall``.

----------
assignee: docs at python
components: Documentation
messages: 300205
nosy: dilyan.palauzov, docs at python
priority: normal
severity: normal
status: open
title: README.rst: installing multiple versions: typo
versions: Python 3.7

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

From report at bugs.python.org  Mon Aug 14 11:10:59 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Aug 2017 15:10:59 +0000
Subject: [docs] [issue31201] module test that failed doesn't exist
In-Reply-To: <1502707428.17.0.905101363291.issue31201@psf.upfronthosting.co.za>
Message-ID: <1502723459.44.0.256049938977.issue31201@psf.upfronthosting.co.za>


R. David Murray added the comment:

Replace "test_that_failed" with the name of the test that failed.

The README could be improved by saying:

If any tests fail, you can re-run the failing test(s) in verbose mode.  For example if, 'test_os' and 'test_gdb' failed, you can run::

     make test TESTOPTS="-v test_os test_gdb"

----------
assignee:  -> docs at python
components: +Documentation -Tests
nosy: +docs at python, r.david.murray

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

From report at bugs.python.org  Mon Aug 14 11:21:08 2017
From: report at bugs.python.org (Paulo Matos)
Date: Mon, 14 Aug 2017 15:21:08 +0000
Subject: [docs] [issue31201] module test that failed doesn't exist
In-Reply-To: <1502707428.17.0.905101363291.issue31201@psf.upfronthosting.co.za>
Message-ID: <1502724068.53.0.534711101255.issue31201@psf.upfronthosting.co.za>


Paulo Matos added the comment:

Argh, apologies David. I hadn't noticed the mistake. I simply copy/pasted and was expecting the command line to rerun all the tests that had previously failed. I was assuming the suite had some kind of state that recorded the tests that previously failed and ran only those. :)

----------

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

From report at bugs.python.org  Mon Aug 14 11:28:25 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 14 Aug 2017 15:28:25 +0000
Subject: [docs] [issue31201] module test that failed doesn't exist
In-Reply-To: <1502707428.17.0.905101363291.issue31201@psf.upfronthosting.co.za>
Message-ID: <1502724505.33.0.303714118936.issue31201@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yep, I figured that.  That's why I suggested the clarification to the README, if someone wants to generate a PR for it.

----------

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

From report at bugs.python.org  Mon Aug 14 14:57:13 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 14 Aug 2017 18:57:13 +0000
Subject: [docs] [issue31191] Fix grammar in threading.Barrier docs
In-Reply-To: <1502736895.43.0.873183336096.issue31191@psf.upfronthosting.co.za>
Message-ID: <1502737033.17.0.353223265336.issue31191@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Mon Aug 14 15:22:48 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 14 Aug 2017 19:22:48 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1502738568.67.0.696481417601.issue31024@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Bern?t, I would recommend asking this on Sphinx tracker (I also assigned this to docs at python since this seems to be a purely documentation issue).

https://github.com/sphinx-doc/sphinx

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

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

From Pratik.Surani at mastek.com  Mon Aug 14 14:56:36 2017
From: Pratik.Surani at mastek.com (Pratik B. Surani)
Date: Mon, 14 Aug 2017 18:56:36 +0000
Subject: [docs] Modules section Bug
Message-ID: <HK2PR0601MB1505A1686325F53B3EF94A8F998C0@HK2PR0601MB1505.apcprd06.prod.outlook.com>

Hi,

I could see a bug in the Modules section page of Tutorial https://docs.python.org/3/tutorial/modules.html

Below are the modules in Fibo.py
# Fibonacci numbers module

def fib(n):    # write Fibonacci series up to n
    a, b = 0, 1
    while b < n:
        print(b, end=' ')
        a, b = b, a+b
    print()

def fib2(n):   # return Fibonacci series up to n
    result = []
    a, b = 0, 1
    while b < n:
        result.append(b)
        a, b = b, a+b
    return result

The problem is with the below section:
Fib2(100) doesn't print the data, it just returns the data. So it will first have to be assigned to a variable and then can print that variable.


>>> fibo.fib(1000)

1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987

>>> fibo.fib2(100)

[1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89]

>>> fibo.__name__

'fibo'

Regards,
Pratik Surani
07565987160
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170814/da6ef61c/attachment-0001.html>

From report at bugs.python.org  Wed Aug 16 01:17:39 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 16 Aug 2017 05:17:39 +0000
Subject: [docs] [issue31215] Add version changed notes for OpenSSL 1.1.0
 compatibility
Message-ID: <1502860659.7.0.930691554308.issue31215@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

https://bugs.python.org/issue26470 updated the ssl and hashlib modules in 2.7 and 3.5+ to be compatible with OpenSSL 1.1.0.

However, it's currently unclear what the *minimum* versions actually are for platforms that want to drop support for OpenSSL 1.0.x, and it's particularly unclear in 2.7, as that lacks the deprecation warning for OpenSSL 0.9.8, 1.0.0 and 1.0.1 that was introduced in Python 3.6.

This doesn't rise to the level of something to be documented as a new feature in the 2.7 What's New, but I think a version changed note in the opening section of the `ssl` module documentation would be appropriate:

2.7 branch:

    .. versionchanged: 2.7.13
       Updated to support linking with OpenSSL 1.1.0

3.6 and master branches (immediately before the 3.6 deprecation notice):

    .. versionchanged: 3.5.3
       Updated to support linking with OpenSSL 1.1.0

----------
assignee: docs at python
components: Documentation
messages: 300326
nosy: christian.heimes, docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Add version changed notes for OpenSSL 1.1.0 compatibility
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Aug 16 04:01:23 2017
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 16 Aug 2017 08:01:23 +0000
Subject: [docs] [issue31215] Add version changed notes for OpenSSL 1.1.0
 compatibility
In-Reply-To: <1502860659.7.0.930691554308.issue31215@psf.upfronthosting.co.za>
Message-ID: <1502870483.54.0.803135159727.issue31215@psf.upfronthosting.co.za>


Christian Heimes added the comment:

+1

For reference, Python 3.5 received OpenSSL 1.1.0 support in 3.5.3.

----------

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

From report at bugs.python.org  Thu Aug 17 06:55:01 2017
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 17 Aug 2017 10:55:01 +0000
Subject: [docs] [issue31224] Missing definition of frozen module
Message-ID: <1502967301.1.0.268769760961.issue31224@psf.upfronthosting.co.za>


New submission from Marco Buttu:

In the doc there are several hints [*] to frozen modules, but there is no definition of them.  Do you think we should add a "frozen module" definition to the glossary?

* Doc/library/importlib.rst, Doc/library/imp.rst, Doc/reference/import.rst, ...

----------
assignee: docs at python
components: Documentation
messages: 300405
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Missing definition of frozen module
type: enhancement
versions: Python 3.7

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

From alvin.quiring at shaw.ca  Tue Aug 15 11:52:45 2017
From: alvin.quiring at shaw.ca (Alvin Quiring)
Date: Tue, 15 Aug 2017 08:52:45 -0700
Subject: [docs]
 https://www.python.org/ftp/python/doc/3.4.7rc1/python-3.4.7rc1-docs-pdf-letter.zip
 404 Not Found
Message-ID: <000301d315de$8c884460$a598cd20$@shaw.ca>

Python.org
 
The above download file response returns 404 Not Found.  Please fix.
 
 
Alvin
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170815/eb85cffd/attachment.html>

From j.geurtsen at gmail.com  Wed Aug 16 11:44:30 2017
From: j.geurtsen at gmail.com (Jan)
Date: Wed, 16 Aug 2017 17:44:30 +0200
Subject: [docs] Improve presentation style Python Docs
Message-ID: <CAGOWOtmaTpgBmfh6XcgOCTUnMERDLixqWfKp=5hL-om=mVer-Q@mail.gmail.com>

Would it be possible to change the presentation style of the Python
documentation, so readability and discovery of information is improved
(especially for new users).
This could be achieved by using standardised sections for each module/class
page, making use of HTML tables to structure information (for example the
available functions), and better use of white space to aid overview and
discovery.

The documentation currently sometimes 'feels' like a big blob of text.
Pages can be perceived as long and unstructured, especially if you're a new
user who's not very familiar with the language yet.
https://docs.python.org/3/library/string.html

Example of C# documentation page
https://msdn.microsoft.com/en-us/library/system.string(v=vs.110).aspx
(just an example for inspiration purposes)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170816/b3075359/attachment-0001.html>

From mikhail.domanov at gmail.com  Fri Aug 18 18:47:26 2017
From: mikhail.domanov at gmail.com (Mikhail Domanov)
Date: Sat, 19 Aug 2017 01:47:26 +0300
Subject: [docs] Last version of Zip archive is August 10th
Message-ID: <1922743347.20170819014726@gmail.com>

Hello Python Docs,

I would like to leave a short message in case this is a bug.

If I open page https://docs.python.org/3/download.html
I see "Last updated on: Aug 18, 2017."

But if I download the archive on this same page
https://docs.python.org/3/archives/python-3.6.2-docs-html.zip
and inside this archive I open >> python-3.6.2-docs-html/download.html
I see "Last updated on: Aug 10, 2017."
In fact this zip file has not been updated since August, 10th.

Besides,   I   would  like  to  take this opportunity to thank you for
such a  great  product! It saved me tons of hours on routine tasks.


? ????????? (kind regards),
Mikhail Domanov
Saturday, August 19, 2017
mailto:Mikhail.Domanov at gmail.com
skype: domanov.mikhail


From report at bugs.python.org  Mon Aug 21 12:44:10 2017
From: report at bugs.python.org (Ivan Chernov)
Date: Mon, 21 Aug 2017 16:44:10 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1503333850.29.0.854563952966.issue31065@psf.upfronthosting.co.za>


Changes by Ivan Chernov <chernoffivan at gmail.com>:


----------
pull_requests: +3205

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

From report at bugs.python.org  Mon Aug 21 12:45:27 2017
From: report at bugs.python.org (Ivan Chernov)
Date: Mon, 21 Aug 2017 16:45:27 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1503333927.2.0.372470392987.issue31065@psf.upfronthosting.co.za>


Ivan Chernov added the comment:

Try to solve this issue, because it's pretty simple (:

----------
nosy: +vanadium23

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

From report at bugs.python.org  Mon Aug 21 15:02:17 2017
From: report at bugs.python.org (Ashish Nitin Patil)
Date: Mon, 21 Aug 2017 19:02:17 +0000
Subject: [docs] [issue31252] Operator.itemgetter documentation should
 include dictionary keys example
Message-ID: <1503342137.82.0.389505495838.issue31252@psf.upfronthosting.co.za>


New submission from Ashish Nitin Patil:

Current documentation lacks the example of usage with dictionary keys.

e.g. `itemgetter('sample')({'sample': True, 'How about this': 'Nope'})`

----------
assignee: docs at python
components: Documentation
messages: 300648
nosy: ashishnitinpatil, docs at python
priority: normal
severity: normal
status: open
title: Operator.itemgetter documentation should include dictionary keys example
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Aug 21 23:32:07 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Aug 2017 03:32:07 +0000
Subject: [docs] [issue31252] Operator.itemgetter documentation should
 include dictionary keys example
In-Reply-To: <1503342137.82.0.389505495838.issue31252@psf.upfronthosting.co.za>
Message-ID: <1503372727.48.0.0154407586467.issue31252@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Yes, we can add a dictionary example.  I will likely split it into two lines for clarity.  Perhaps something like:

    >>> soldier = dict(rank='captain', name='dotterbart')
    >>> itemgetter('rank')(soldier)
    'captain'

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Aug 22 10:23:34 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Aug 2017 14:23:34 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503411814.71.0.025104059782.issue31024@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3219

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

From report at bugs.python.org  Tue Aug 22 13:21:08 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Aug 2017 17:21:08 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503422468.41.0.251758060296.issue31024@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Before I spend more time reviewing your patch, can you please explain what you mean by "sphinx fails to find these"? Is there a particular dead link on docs.python.org or a specific query you typed in the search box that failed to find the definition of typing.Tuple?

----------

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

From konstantin.ketskalo at gmail.com  Mon Aug 21 08:05:26 2017
From: konstantin.ketskalo at gmail.com (Constantine Ketskalo)
Date: Mon, 21 Aug 2017 15:05:26 +0300
Subject: [docs] Shortcuts bug in Python IDLE
Message-ID: <CA+ANekM=wJox2pZfdFPL8gPxgCv9pkksUu5PA5wOaSmGCr58WQ@mail.gmail.com>

Hi there.
Thank you for Python, I love this programming language.

I've found a bug with shortcuts. I'm from Ukraine, so I'm working with
English, Ukrainian and Russian languages. But any shortcuts, where alphabet
is involved (like Ctrl+Z, Ctrl+F, Ctrl+V and so on) work only when English
is turned on. This is quite inconvenient. It's possible to work with it,
but still confusing, because you can select something in IDLE, copy it with
shortcut Ctrl+C, then try to paste it to another place and then you find
out that it wasn't copied, because active language is Ukrainian. So you
need to switch to English and repeat everything again.

I'm currently working with Python 3.6.1, Windows 8.1 Embedded enterprize
x64.
Also I've noticed the same under Windows 7, Windows 10 in different
versions of Python.
I believe there where Python 2.7, 2.11, 3.4, 3.5. Not sure about all the
versions exectly, but for sure shortcuts worked the same in all the
versions I've ever tried to use.

I hope this was helpful and I'm sure many developers, that work not only
with English would be really happy if you would fix this.

Thanks again for your time and effort.
Best regards, Constantine.

P.S. I'll right the same message to Issue tracker just in case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170821/49bbf5fa/attachment.html>

From hyphenpointhyphen at gmail.com  Tue Aug 22 14:38:40 2017
From: hyphenpointhyphen at gmail.com (hyphen point)
Date: Tue, 22 Aug 2017 20:38:40 +0200
Subject: [docs] Misnomer on webpage
Message-ID: <CABwdrqq5p+osJ_rNFH1633cDPm-NR8Bf=XKJ6tcioJ7uMFW6gw@mail.gmail.com>

 https://docs.python.org/3.5/tutorial/stdlib.html

I might be wrong (English is not my mother-tongue) but in the following
sentence in section 10.1 seems to be an error.


The built-in dir() <https://docs.python.org/3.5/library/functions.html#dir>
>  and help() <https://docs.python.org/3.5/library/functions.html#help> functions
> are useful as interactive aids for working with large modules like os
> <https://docs.python.org/3.5/library/os.html#module-os>:



Shouldn't the plural of aide be aides?

Greetings, Mat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170822/28eb6230/attachment.html>

From report at bugs.python.org  Tue Aug 22 16:55:28 2017
From: report at bugs.python.org (=?utf-8?b?QmVybsOhdCBHw6Fib3I=?=)
Date: Tue, 22 Aug 2017 20:55:28 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503435328.89.0.653087763477.issue31024@psf.upfronthosting.co.za>


Bern?t G?bor added the comment:

so here's the problem in detail:

Intersphinx (http://www.sphinx-doc.org/en/stable/ext/intersphinx.html) is a built in Sphinx plugin that allows to link to documentation of other projects in your own documentation. For example when specifying the argument of a function which can be either int or string you might specify the argument to be Union[int, str]. In this case Sphinx will generate the type of the argument as this object, where e.g. the Union word will be a link to https://docs.python.org/3/library/typing.html#typing.Union and so on. 

In order to know for which object/function/type what is the correct URL an intersphinx object (which is basically a mapping) needs to be generated. This maps each element to an URL. This intersphinx mapping storage object (available at https://docs.python.org/3/objects.inv and similarly under other version pattern for the according version) is generated from the Python documentation. 

Now there's one indirection as far as this objects.inv goes; it does not actually stores mappings of element to URL, but what instead does it stores a mapping of type to element to url. Where type is here defined as either data/class etc. In order to resolve from an element to an URL both keys need to be correct (the type and the key too). 

For Python 3.6+ the typing.Tuple mapping now fails because according to the documentation the Tuple is under the section data, but once intersphinx looks at the Tuple during documentation generation it deduces it actually is of type class, and tries to locate it there. In order for intersphinx to resolve the correct web page URL, the runtime information of an element need to coincide with it's documentation type. Hence, what this PR tries to fix, migrating the documentation type/section of data to class (as in the meantime under Python 3.6 the Tuple is now a class).

For the end user the fact that this is a class is still hidden, but for the documentation generation tool to resolve the correct URL, the runtime information needs to coincide with the documentation one. We should probably add a unit test that makes sure all runtime "type" matches with documentation "type" in the future. Let's make that the scope of another PR; is now clear?

----------

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

From report at bugs.python.org  Tue Aug 22 18:24:55 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 22 Aug 2017 22:24:55 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503440695.66.0.250430714202.issue31024@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

> For the end user the fact that this is a class is still hidden

I am not sure what you mean by this, but with your PR the rendered docs will literally say ``class typing.Tuple``.

> We should probably add a unit test that makes sure all runtime "type" matches with documentation "type" in the future

I already mention, this was not an omission but a deliberate decision, see http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode444 (and below the same for Callable)

----------

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

From report at bugs.python.org  Tue Aug 22 18:27:47 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 22 Aug 2017 22:27:47 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503440867.52.0.968688407163.issue31024@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks, I am a little closer to understanding now.

> once intersphinx looks at the Tuple during documentation generation it deduces it actually is of type class

How does intersphinx deduce this? Also, does it run when we generate the Python docs, or when you generate the docs for your project (that references the Python docs)? Finally, are there other objects in the typing for which this is a problem? (I guess I could answer this myself once I understand how intersphinx decides whether something is a class or data.)

I also think this is somewhat unfortunate, because it seems that whenever something is changed from "class" to "data" or vice versa, intersphinx will be confused, even though it's easy to give examples where such a change could be backwards compatible.

----------

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

From report at bugs.python.org  Tue Aug 22 18:52:38 2017
From: report at bugs.python.org (Dipti Sherlekar)
Date: Tue, 22 Aug 2017 22:52:38 +0000
Subject: [docs] [issue31262] Documentation Error
Message-ID: <1503442357.91.0.706507107768.issue31262@psf.upfronthosting.co.za>


New submission from Dipti Sherlekar:

Documentation says : In C++ terminology, normally class members (including the data members) are public  

Solution: In C++ the class memebers are private not public by default.

----------
assignee: docs at python
components: Documentation
messages: 300727
nosy: Dipti Sherlekar, docs at python
priority: normal
severity: normal
status: open
title: Documentation Error
versions: Python 3.7

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

From report at bugs.python.org  Tue Aug 22 19:25:22 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Aug 2017 23:25:22 +0000
Subject: [docs] [issue31262] Documentation Error
In-Reply-To: <1503442357.91.0.706507107768.issue31262@psf.upfronthosting.co.za>
Message-ID: <1503444322.64.0.462865267122.issue31262@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, that sentence is telling you what the *Python*'s behavior is, using C++ terminology.  Unlike C++, where class members are private by default, the Python equivalent of class members are public by default.

If you can figure out a clearer way to phrase that you may reopen the issue with your suggestion.

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

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

From report at bugs.python.org  Tue Aug 22 19:28:35 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Aug 2017 23:28:35 +0000
Subject: [docs] [issue31262] Documentation Error
In-Reply-To: <1503442357.91.0.706507107768.issue31262@psf.upfronthosting.co.za>
Message-ID: <1503444515.54.0.861821782735.issue31262@psf.upfronthosting.co.za>


Martin Panter added the comment:

Assuming this is about the Classes section in the tutorial, you seem to be going down the same track as <https://github.com/python/cpython/pull/2696>

----------
nosy: +martin.panter

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

From report at bugs.python.org  Tue Aug 22 19:31:39 2017
From: report at bugs.python.org (Dipti Sherlekar)
Date: Tue, 22 Aug 2017 23:31:39 +0000
Subject: [docs] [issue31262] Documentation Error
In-Reply-To: <1503444515.54.0.861821782735.issue31262@psf.upfronthosting.co.za>
Message-ID: <CACAQWF6CDDJvz4htp2AxiAd1ydBX4oXvTxb8aMGqKRYE-hqsMQ@mail.gmail.com>


Dipti Sherlekar added the comment:

Thanks all.

Dipti
On Tue, Aug 22, 2017 at 4:28 PM Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> Assuming this is about the Classes section in the tutorial, you seem to be
> going down the same track as <https://github.com/python/cpython/pull/2696>
>
> ----------
> nosy: +martin.panter
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue31262>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Aug 22 19:34:26 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 22 Aug 2017 23:34:26 +0000
Subject: [docs] [issue12887] Documenting all SO_* constants in socket module
In-Reply-To: <1314987180.49.0.607596056761.issue12887@psf.upfronthosting.co.za>
Message-ID: <1503444866.16.0.501556554021.issue12887@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Aug 23 01:07:38 2017
From: report at bugs.python.org (=?utf-8?b?QmVybsOhdCBHw6Fib3I=?=)
Date: Wed, 23 Aug 2017 05:07:38 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503464858.28.0.393684130248.issue31024@psf.upfronthosting.co.za>


Bern?t G?bor added the comment:

I suppose when the python.org documentation is generated the objects.inv file gets generated with it (I did not found exactly this piece of code here though). When Sphinx runs, it's intersphinx plugin goes out to python.org, downloads the objects.inv, decodes it, and then tries to map the docstring param/return values/references to URLs. 

Actually intersphinx does not make the deduction of the type. It uses what the users entered in the docstring. In this case the user needs to know for each element to which bucket has been assigned to (e.g. class/data/function/method/exception/macro); and for compatibility reason that needs to stay stable, otherwise with a Python upgrade the user would need to update the code of its docstrings.

That being said for the sake of automation, in my case there actually another sphinx plugin (https://github.com/agronholm/sphinx-autodoc-typehints/blob/master/sphinx_autodoc_typehints.py) which actually generates, on the fly, the type information. So I suppose as a fix for my problem the sphinx_autodoc_typehint could be altered to still give back data, even though this now is a class. I'm not sure though how confident I am on "lying" to users about the data/class; but I suppose it's a necessary evil at this point.

So should we keep everything as it is? When I first identified why Tuple does not have the URL mapped to it, I thought the problem to be the fact that it goes to the wrong bucket (by just inspecting its type): data; but now I see that may not be such a bad thing after all.

----------

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

From report at bugs.python.org  Wed Aug 23 01:27:48 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Aug 2017 05:27:48 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503466068.21.0.746268279745.issue31024@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I think Sphinx is way too complicated for its own good, and it's arguably not the fault of Python's documentation that this doesn't work for you.

I would like to close this issue as "won't fix", except... in a sense Tuple actually *is* a class, since you can subclass from e.g. Tuple[int, str].

@Levikvskyi, what do you think?

----------

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

From report at bugs.python.org  Wed Aug 23 03:40:01 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 23 Aug 2017 07:40:01 +0000
Subject: [docs] [issue31024] typing.Tuple is class but is defined as data
 inside https://docs.python.org/3.6/objects.inv
In-Reply-To: <1500981460.28.0.176331583304.issue31024@psf.upfronthosting.co.za>
Message-ID: <1503474001.0.0.87282898053.issue31024@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

TBH, I think this is a Sphinx problem, not a Python problem. And concerning ``Tuple`` being an actual class I think this is an implementation detail, so that I am closing this as "won't fix".

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

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

From report at bugs.python.org  Wed Aug 23 18:39:12 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 23 Aug 2017 22:39:12 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1503527951.62.0.676644792182.issue26256@psf.upfronthosting.co.za>


Cheryl Sabella added the comment:

Hello,

I came across this issue and was wondering if the FAQ section of the doc might be a good place to mention the presence of FFT, or actually fast number theoretic transform, as Stefan pointed out.

I was also wondering if the short code snippet for the Mersenne prime might be included in the recipes as an example of what decimal is capable of?

----------
nosy: +csabella

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

From report at bugs.python.org  Wed Aug 23 20:43:30 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Aug 2017 00:43:30 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1503535410.05.0.90009535234.issue26256@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

A couple of thoughts:

* It is okay to add a couple lines to the decimal module docs noting a Cpython specific implementation detail that it uses better than expected algorithms which can payoff nicely when used with very large numbers.

* Mersenne prime examples and whatnot belong external to our docs.  I usually put my recipes and examples on the ASPN Python Cookbook.  http://code.activestate.com/recipes/langs/python/

----------
nosy: +rhettinger

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

From report at bugs.python.org  Thu Aug 24 07:13:20 2017
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Aug 2017 11:13:20 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1503573200.77.0.940148803844.issue26256@psf.upfronthosting.co.za>


Stefan Krah added the comment:

pypy-5.8.0-beta0 (Python 3.5.3) is using a very nicely written CFFI wrapper for libmpdec, so it also has the fast bignums.

----------

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

From report at bugs.python.org  Thu Aug 24 07:20:10 2017
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 24 Aug 2017 11:20:10 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1503573610.39.0.320844482847.issue26256@psf.upfronthosting.co.za>


Stefan Krah added the comment:

What needs to be mentioned though is that the context has to be set
for unrounded calculations:

c = getcontext()
c.prec = MAX_PREC
c.Emax = MAX_EMAX
c.Emin = MIN_EMIN


Otherwise some people believe that the bignums are just rounded floating point arithmetic that is expected to be fast (I've seen this misconception somewhere, perhaps on Stackoverflow).

----------

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

From report at bugs.python.org  Thu Aug 24 11:15:57 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 24 Aug 2017 15:15:57 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1503587757.37.0.213984869226.issue12067@psf.upfronthosting.co.za>


Changes by Cheryl Sabella <chekat2 at gmail.com>:


----------
pull_requests: +3238

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

From report at bugs.python.org  Thu Aug 24 11:25:43 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 24 Aug 2017 15:25:43 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1503588342.69.0.694128682875.issue12067@psf.upfronthosting.co.za>


Cheryl Sabella added the comment:

I've created a PR for the changes to test_compare from v16 of the patch.

----------

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

From report at bugs.python.org  Thu Aug 24 12:03:33 2017
From: report at bugs.python.org (Raphael Michel)
Date: Thu, 24 Aug 2017 16:03:33 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
Message-ID: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>


New submission from Raphael Michel:

The documentation given for itertools.zip_longest contains a "roughly equivalent" pure-python implementation of the function that is intended to help the user understand what zip_longest does on a functional level.

However, the given implementation is very complicated to read for newcomers and experienced Python programmers alike, as it uses a custom-defined exception for control flow handling, a nested function, a condition that always is true if any arguments are passed ("while iterators"), as well as two other non-trivial functions from itertools (chain and repeat).

For future reference, this is the currently given implementation:

    def zip_longest(*args, **kwds):
        # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
        fillvalue = kwds.get('fillvalue')
        iterators = [iter(it) for it in args]

        while True:
            exhausted = 0
            values = []

            for it in iterators:
                try:
                    values.append(next(it))
                except StopIteration:
                    values.append(fillvalue)
                    exhausted += 1

            if exhausted < len(args):
                yield tuple(values)
            else:
                break

This is way more complex than necessary to teach the concept of zip_longest. With this issue, I will submit a pull request with a new example implementation that seems to be the same level of "roughly equivalent" but is much easier to read, since it only uses two loops and now complicated flow 

    def zip_longest(*args, **kwds):
        # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
        fillvalue = kwds.get('fillvalue')
        iterators = [iter(it) for it in args]

        while True:
            exhausted = 0
            values = []

            for it in iterators:
                try:
                    values.append(next(it))
                except StopIteration:
                    values.append(fillvalue)
                    exhausted += 1

            if exhausted < len(args):
                yield tuple(values)
            else:
                break


Looking at the C code of the actual implementation, I don't see that any one of the two implementations is obviously "more equivalent". I'm unsure about performance -- I haven't tried them on that but I don't think that's the point of this learning implementation.

I ran all tests from Lib/test/test_itertools.py against both the old and the new implementation. The new implementation fails at 3 tests, while the old implementation failed at four. Two of the remaining failures are related to TypeErrors not being thrown on invalid input, one of them is related to pickling the resulting object. I believe all three of them are fine to ignore in this sample, as it is not relevant to the documentation purpose.

Therefore, I believe the documentation should be changed like suggested. I'd be happy for any feedback or further ideas to improve its readability!

----------
assignee: docs at python
components: Documentation
messages: 300788
nosy: docs at python, rami
priority: normal
severity: normal
status: open
title: Simplify documentation of itertools.zip_longest
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Aug 24 12:06:32 2017
From: report at bugs.python.org (Raphael Michel)
Date: Thu, 24 Aug 2017 16:06:32 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503590792.64.0.997872430145.issue31270@psf.upfronthosting.co.za>


Changes by Raphael Michel <mail at raphaelmichel.de>:


----------
pull_requests: +3239

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

From report at bugs.python.org  Thu Aug 24 12:19:31 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 24 Aug 2017 16:19:31 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503591571.07.0.629107428389.issue31270@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Thu Aug 24 12:30:23 2017
From: report at bugs.python.org (Raphael Michel)
Date: Thu, 24 Aug 2017 16:30:23 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503592223.48.0.262016465806.issue31270@psf.upfronthosting.co.za>


Raphael Michel added the comment:

I just noticed that in my post I accidentally pasted MY implementation twice instead of the old one, sorry for that. Here's the old one for quick comparison:

class ZipExhausted(Exception):
    pass

def zip_longest(*args, **kwds):
    # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
    fillvalue = kwds.get('fillvalue')
    counter = len(args) - 1
    def sentinel():
        nonlocal counter
        if not counter:
            raise ZipExhausted
        counter -= 1
        yield fillvalue
    fillers = repeat(fillvalue)
    iterators = [chain(it, sentinel(), fillers) for it in args]
    try:
        while iterators:
            yield tuple(map(next, iterators))
    except ZipExhausted:
        pass

----------

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

From report at bugs.python.org  Thu Aug 24 14:01:39 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Aug 2017 18:01:39 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503597699.36.0.402833977725.issue31270@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/issue31270>
_______________________________________

From report at bugs.python.org  Thu Aug 24 15:32:34 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Aug 2017 19:32:34 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503603154.36.0.9219785273.issue31270@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for wanting to improve the documentation.

Raymond will address this definitively, but unless I'm mistaken part of the purpose of the examples is to show how the various itertools can be used.  If that is true, then in the context of the overall itertools documentation I think the current example has more teaching value than your suggested revision.

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

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

From report at bugs.python.org  Thu Aug 24 23:21:17 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Aug 2017 03:21:17 +0000
Subject: [docs] [issue31274] Support building against homebrew on macOS
Message-ID: <1503631277.04.0.477315810224.issue31274@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

The devguide does touch on how to build Python from source using homebrew installed libraries on macOS, although I found it to be 1) a bit incomplete; 2) not so easy to discover.

It might make sense to modify configure to autodetect homebrew, or to have a switch to enable linking against homebrew libraries.

Barring that, I'd like to at least update the devguide to include details on how to also build sqlite3 and zlib modules.

----------
assignee: docs at python
components: Build, Documentation
messages: 300819
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: Support building against homebrew on macOS
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Aug 24 23:35:10 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 25 Aug 2017 03:35:10 +0000
Subject: [docs] [issue31274] Support building against homebrew on macOS
In-Reply-To: <1503631277.04.0.477315810224.issue31274@psf.upfronthosting.co.za>
Message-ID: <1503632110.22.0.799025925804.issue31274@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

If you're proposing changes to the devguide, then please file the issue at https://github.com/python/devguide :)

----------
nosy: +Mariatta

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

From report at bugs.python.org  Fri Aug 25 05:33:42 2017
From: report at bugs.python.org (Raphael Michel)
Date: Fri, 25 Aug 2017 09:33:42 +0000
Subject: [docs] [issue31270] Simplify documentation of itertools.zip_longest
In-Reply-To: <1503590613.37.0.607996999117.issue31270@psf.upfronthosting.co.za>
Message-ID: <1503653622.92.0.986650587072.issue31270@psf.upfronthosting.co.za>


Raphael Michel added the comment:

Well, I could think of a way to still use repeat() here that also is pretty clean except for the fact that it fails if all inputs to zip_longest are repeat() iterators themselves (which would here lead to an empty iterator while it would otherwise lead to an infinite one):

    def zip_longest(*args, **kwds):
        # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
        fillvalue = kwds.get('fillvalue')
        iterators = [iter(it) for it in args]

        while True:
            values = []

            for i, it in enumerate(iterators):
                try:
                    values.append(next(it))
                except StopIteration:
                    values.append(fillvalue)
                    iterators[i] = repeat(fillvalue)

            if all(isinstance(it, repeat) for it in iterators):
                break
            else:
                yield tuple(values)

Keeping chain() in use here just for the sake of using it is not worth it, I believe.

----------

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

From spelozo at gmail.com  Wed Aug 23 08:45:05 2017
From: spelozo at gmail.com (Silvia)
Date: Wed, 23 Aug 2017 09:45:05 -0300
Subject: [docs] Download links for 3.4 are broken
Message-ID: <CAGrnTwrpHS1pEjA6VatW1-XgKXkr0qVnRhgLVJV_ciafymJbNg@mail.gmail.com>

The links in https://docs.python.org/3.4/download.html don't work, because
they point to
https://docs.python.org/ftp/python/doc/3.4.7rc1/python-3.4.7rc1-docs-...
They should probably link to the files in
https://www.python.org/ftp/python/doc/3.4.7/ :
https://docs.python.org/ftp/python/doc/3.4.7/python-3.4.7-docs-... (without
rc1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170823/1160cadc/attachment.html>

From report at bugs.python.org  Fri Aug 25 10:26:48 2017
From: report at bugs.python.org (Pauli Virtanen)
Date: Fri, 25 Aug 2017 14:26:48 +0000
Subject: [docs] [issue31276] PyObject_CallFinalizerFromDealloc is
 undocumented
Message-ID: <1503671208.32.0.920107204017.issue31276@psf.upfronthosting.co.za>


New submission from Pauli Virtanen:

It's unclear if PyObject_CallFinalizerFromDealloc is a public function
or not. It is not documented, but it seems there's no other way to
ensure that tp_finalize runs, at least for objects without 
Py_TPFLAGS_HAVE_GC.

In the documentation of tp_finalize (https://docs.python.org/3/c-api/typeobj.html?highlight=tp_finalize#c.PyTypeObject.tp_finalize) 
there is the sentence:

"""It is called either from the garbage collector (if the instance is
part of an isolated reference cycle) or just before the object is 
deallocated."""

However, it appears it is necessary to call it explicitly from any
user-provided tp_dealloc. Indeed, there are several calls to 
PyObject_CallFinalizerFromDealloc in cpython/Modules/* e.g. in
posixmodule.c:ScandirIterator_dealloc

----------
assignee: docs at python
components: Documentation
messages: 300842
nosy: docs at python, pv
priority: normal
severity: normal
status: open
title: PyObject_CallFinalizerFromDealloc is undocumented
versions: Python 3.7

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

From report at bugs.python.org  Sat Aug 26 04:56:21 2017
From: report at bugs.python.org (Elena Oat)
Date: Sat, 26 Aug 2017 08:56:21 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1503737781.16.0.421036364922.issue31065@psf.upfronthosting.co.za>


Elena Oat added the comment:

I've added a sentence saying about the explicit return value.

----------
keywords: +patch
nosy: +Elena.Oat
Added file: http://bugs.python.org/file47102/issue31065.diff

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

From report at bugs.python.org  Sat Aug 26 07:50:35 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Aug 2017 11:50:35 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503748235.54.0.628350856176.issue31283@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

> the documentation states that the two examples I gave should yield identical results.

Got a link to the specific documentation that says this? And a suggested improvement?

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

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

From report at bugs.python.org  Sat Aug 26 09:17:50 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Aug 2017 13:17:50 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503753470.43.0.974789958996.issue26656@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3249

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

From report at bugs.python.org  Sat Aug 26 09:39:26 2017
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 26 Aug 2017 13:39:26 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503754766.39.0.261487701146.issue31283@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

It's not hard to find a link. https://docs.python.org/3.7/reference/compound_stmts.html#class-definitions

But trying to change that to incorporate what OP is asking is a wild goose chase. There are numerous instances when a documentation is referring to a builtin. E.g.

(print): All non-keyword arguments are converted to strings like str() does
(repr): this function makes an attempt to return a string that would yield an object with the same value when passed to eval()
(type): The isinstance() built-in function is recommended for testing the type of an object

Of course, all of these must be changed, since they don't work as advertised if you rebind str, eval or isinstance.

I claim this is nonsense. If anything, we should educate people that when documentation refers to "the builtin X", it doesn't mean "whatever is current referrent of builtins.X". Never. Only "__import__" kinda works this way (though not in builtins, but in globals), and that's mostly a historic accident.

----------

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

From yogitabang24 at gmail.com  Sat Aug 26 09:56:10 2017
From: yogitabang24 at gmail.com (Yogita Bang)
Date: Sat, 26 Aug 2017 19:26:10 +0530
Subject: [docs] Contribution to the development of Python Modules
Message-ID: <CACtR7mfTU+qqdUJV27BrtJG4F-R05f6zCU4_Q-8QBKkSq+0K-w@mail.gmail.com>

Hello Sir/Madam,
Can you guide me through the process of How to contribute to the
development of a feature in Python modules?

Thanks and Regards,
Yogita Bang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170826/cd9bea01/attachment.html>

From report at bugs.python.org  Sat Aug 26 10:34:22 2017
From: report at bugs.python.org (shadowadler)
Date: Sat, 26 Aug 2017 14:34:22 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503758062.71.0.581737586609.issue31283@psf.upfronthosting.co.za>


shadowadler added the comment:

Not at all- what you are talking about is obviously absurd. I am merely asserting that the statement in the docs you point to - that the two statements are equivalent - is untrue, the two statements are not equivalent in their behaviour.

----------

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

From report at bugs.python.org  Sat Aug 26 10:57:54 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Aug 2017 14:57:54 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503759474.75.0.671295418769.issue31283@psf.upfronthosting.co.za>


R. David Murray added the comment:

shadowadler, the documentation assumes *throughout* that you have not created any variable that shadows any standard Python entities.  There is no other rational way to write the documentation.  To change that policy would, as has been pointed out, require disclaimers in thousands of places in the documentation.  That's not something that is going to be done :)

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

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

From report at bugs.python.org  Sat Aug 26 11:03:28 2017
From: report at bugs.python.org (shadowadler)
Date: Sat, 26 Aug 2017 15:03:28 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503759808.88.0.216710357144.issue31283@psf.upfronthosting.co.za>


shadowadler added the comment:

I really don't see that as a logical extension of what I am saying at all. Sure, shadowing builtins changes what they do, but if you're saying the syntax is equivalent then te effect of the shadowing should be consistent.

----------

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

From report at bugs.python.org  Sat Aug 26 11:30:00 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Aug 2017 15:30:00 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503761400.63.0.156593000737.issue31283@psf.upfronthosting.co.za>


R. David Murray added the comment:

I see I didn't specifically address your counter argument ("that would obviously be absurd").  Having thought it it some more, your are right, there *is* a difference between the examples you think it would be absurd to disclaim and your example here.  In python, an entity is identified by an id (which is a memory address in CPython, but that's an implementation detail).  A name is just a convenience label used to refer to that id.  When you rebind a name, you change what id it points to, but any other piece of python that is already using the original id is not affected.  But anything using an indirect reference through another object (such as builtins) *will* see the change.

Your argument, then, is that it is not documented that 'class x:' is using a direct reference to object rather than an indirect reference.  Our argument is that this is obviously the way Python works (the interpreter itself refers directly to the fundamental entities such as the base of the exception hierarchy and object).

The number of places that would need to be changed to make this explicit is much smaller than I was thinking when I closed the issue, but I'm still not convinced it is something that needs to be explicitly documented.  It is just part of the way Python works at a fundamental level, and because it is a *statement* that does not refer to a variable, it is intuitive that it is going to reference the original object, not whatever builtins.object is referring to.

We do say that explicit is better than implicit, but in this case we're talking about a fundamental part of the language, and the specification of how this works probably belongs in some overview section on statements.  On the other hand, are there any examples *other* than class and except where this distinction matters?

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

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

From report at bugs.python.org  Sat Aug 26 11:34:56 2017
From: report at bugs.python.org (shadowadler)
Date: Sat, 26 Aug 2017 15:34:56 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503761696.84.0.308851192138.issue31283@psf.upfronthosting.co.za>


shadowadler added the comment:

You have put that much more precisely than I could have.

I'm not aware that it is an issie elsewhere, but given that I only ran into this today I may not the person best qualified to answer that question.

----------

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

From report at bugs.python.org  Sat Aug 26 13:32:30 2017
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 26 Aug 2017 17:32:30 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503768750.47.0.747964716664.issue31283@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

Sorry, I fail to see the big difference. 

Let's take print as an example:

All non-keyword arguments are converted to strings like str() does and written to the stream, separated by sep and followed by end. Both sep and end must be strings; they can also be None, which means to use the default values. If no objects are given, print() will just write end. The file argument must be an object with a write(string) method; if it is not present or None, sys.stdout will be used.

Is the above so different than writing:

    print(*args, file=f, sep=s, end=e)

is equivalent to

    f.write(s.join(map(str, args))+e)

? In my head, no. It's just that sometimes we use Python, and sometimes English, to describe the semantics.

----------

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

From report at bugs.python.org  Sat Aug 26 14:28:21 2017
From: report at bugs.python.org (shadowadler)
Date: Sat, 26 Aug 2017 18:28:21 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503772101.73.0.482935756024.issue31283@psf.upfronthosting.co.za>


shadowadler added the comment:

The two phrases you present are significantly different- one draws an equivalence. The other does not. That in essence is what this is all about.

The difference between an indirect and direct reference in the class inheritance syntax is neither implied nor mentioned in the documentation. It led me to expect one behaviour and find another. That is the extent of my issue, and the fix seems to be to be small.

----------

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

From report at bugs.python.org  Sat Aug 26 14:57:35 2017
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 26 Aug 2017 18:57:35 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503773855.24.0.142757184076.issue31283@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

I don't know whether the fix is small, since there is no fix that I see yet.

I'd just want to draw your attention to the fact that Python is extremely expressive language: almost nothing is "equivalent" to anything else, if you look hard enough.

Surely, in the docs, in various places it is written that some code is equivalent to some other code, where it's obvious that those are not completely equivalent in your sense.

E.g. "a_list += [1, 2, 3] is equivalent to a_list.extend([1, 2, 3])" (https://docs.python.org/3.5/faq/programming.html?highlight=equivalent#why-did-changing-list-y-also-change-list-x)

where it's obvious that the second one is an expression, while the first one is not. Also, the docs are full of "equivalents" to various idioms from _other programming languages_, where again it's obvious that total behavioral equivalence is not what's intended.

----------

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

From report at bugs.python.org  Sat Aug 26 14:58:41 2017
From: report at bugs.python.org (Elena Oat)
Date: Sat, 26 Aug 2017 18:58:41 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503773920.76.0.662359056175.issue26656@psf.upfronthosting.co.za>


Elena Oat added the comment:

Added the link to the regular expression objects.

----------
keywords: +patch
nosy: +Elena.Oat
Added file: http://bugs.python.org/file47103/issue26656.diff

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

From report at bugs.python.org  Sat Aug 26 15:06:25 2017
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 26 Aug 2017 19:06:25 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503774385.45.0.810022627128.issue31283@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

> On the other hand, are there any examples *other* than class and except where this distinction matters?

Of course. For example, "for" semantics mentions StopIteration. Of course it doesn't mean "whatever builtins.StopIteration currently refers to".

[And in a lot of places it would be possible to say that some builtin is implicit in the statement itself: e.g.

    while t:   is equivalent to   while bool(t):
    for a in b:     is equivalent to    for a in iter(b):

- of course, the docs _don't_ currently say so, so maybe this occurance too should just be deleted. But I still think there are lots of places where docs refer to builtins directly.]

----------

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

From report at bugs.python.org  Sat Aug 26 15:20:56 2017
From: report at bugs.python.org (Emily Morehouse)
Date: Sat, 26 Aug 2017 19:20:56 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503775256.42.0.887861733116.issue26656@psf.upfronthosting.co.za>


Emily Morehouse added the comment:

PR 3211 - LGTM, but is not CLA signed.

Elena, a couple of notes on your patch. Using :ref:`regular expression object <re-objects>` to link to the section of the documentation is preferred, as it does not rely on a consistent URL. Also, be mindful of line lengths, feel free to break lines to avoid this. If you would like to submit a PR on Github for these changes, it can more easily be merged in. (Check https://docs.python.org/devguide/pullrequest.html for more info).

----------

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

From report at bugs.python.org  Sat Aug 26 15:33:51 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 26 Aug 2017 19:33:51 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503776031.47.0.700489139049.issue31283@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I agree with the other commenters and recommend this be closed.  There doesn't seem to be a a useful issue here.  It seems more like a pedantic twisting of words that ignores how Python works (i.e. that you can specify a specific class to inherit from and that it is possible to either shadow or alter builtins).  I don't see any magic here beyond changing a variable name to refer to a new object while previous references (or builtin references) to that name continue to refer to old object.

----------
nosy: +rhettinger

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

From report at bugs.python.org  Sat Aug 26 15:49:09 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 26 Aug 2017 19:49:09 +0000
Subject: [docs] [issue31283] Inconsistent behaviours with explicit and
 implicit inheritance from object
In-Reply-To: <1503738862.98.0.13501343613.issue31283@psf.upfronthosting.co.za>
Message-ID: <1503776949.21.0.0489302223124.issue31283@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, agreed.  The general principle is: if you reference the name, it is looked up in the the builtins namespace at runtime (effectively an indirect reference).  If the syntax doesn't explicitly mention the name, then it is going to be (the equivalent of) a direct reference, and changing builtins won't change it.  So this is really just a specific example of how python namespacing works in general.

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

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

From report at bugs.python.org  Sun Aug 27 07:25:45 2017
From: report at bugs.python.org (Elena Oat)
Date: Sun, 27 Aug 2017 11:25:45 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1503833145.65.0.434925989227.issue31065@psf.upfronthosting.co.za>


Changes by Elena Oat <oat.elena at gmail.com>:


----------
pull_requests: +3258

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

From report at bugs.python.org  Sun Aug 27 07:27:33 2017
From: report at bugs.python.org (Elena Oat)
Date: Sun, 27 Aug 2017 11:27:33 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1503833253.76.0.395231397948.issue31065@psf.upfronthosting.co.za>


Changes by Elena Oat <oat.elena at gmail.com>:


----------
pull_requests:  -3258

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

From report at bugs.python.org  Sun Aug 27 07:29:34 2017
From: report at bugs.python.org (Mike Hoy)
Date: Sun, 27 Aug 2017 11:29:34 +0000
Subject: [docs] [issue31153] Update docstrings of itertools functions
In-Reply-To: <1502264559.87.0.404253644107.issue31153@psf.upfronthosting.co.za>
Message-ID: <1503833374.47.0.0231770098719.issue31153@psf.upfronthosting.co.za>


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


----------
nosy: +vexoxev

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

From report at bugs.python.org  Sun Aug 27 09:54:50 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 27 Aug 2017 13:54:50 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1503842090.4.0.976068435671.issue19431@psf.upfronthosting.co.za>


Cheryl Sabella added the comment:

Victor,

Should there be a PR for this?

----------
nosy: +csabella

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

From hegde.rohit7 at gmail.com  Sun Aug 27 13:32:07 2017
From: hegde.rohit7 at gmail.com (Rohit Hegde)
Date: Sun, 27 Aug 2017 23:02:07 +0530
Subject: [docs] Python documentation downloading on Android
In-Reply-To: <CADKUbzmEAjppQ7NKuxKLCWPdQKwm0Go7SsQU1cGxdXZq1HnfDQ@mail.gmail.com>
References: <CADKUbzmEAjppQ7NKuxKLCWPdQKwm0Go7SsQU1cGxdXZq1HnfDQ@mail.gmail.com>
Message-ID: <CADKUbznN1dr0=K=wDB4z9=fZjUXBraUtQQAOm5jGe-zZzQKb_Q@mail.gmail.com>

Sir/Mam,

Recently I tried to download python 2.7.x documentation on my android
device, but I am getting error 404 status.

Please look into the matter.

Regards
Rohit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170827/098d19a5/attachment.html>

From report at bugs.python.org  Sun Aug 27 18:12:44 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 27 Aug 2017 22:12:44 +0000
Subject: [docs] [issue31191] Fix grammar in threading.Barrier docs
In-Reply-To: <1502736895.43.0.873183336096.issue31191@psf.upfronthosting.co.za>
Message-ID: <1503871964.91.0.985901190063.issue31191@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
pull_requests: +3266

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

From report at bugs.python.org  Sun Aug 27 18:19:11 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 27 Aug 2017 22:19:11 +0000
Subject: [docs] [issue31191] Fix grammar in threading.Barrier docs
In-Reply-To: <1502736895.43.0.873183336096.issue31191@psf.upfronthosting.co.za>
Message-ID: <1503872351.08.0.134393116578.issue31191@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:


New changeset 2dfafa3c565c0b51920269a891fa270848b378d5 by Mariatta in branch '3.6':
bpo-31191: Improve grammar in threading.Barrier docs (GH-3080) (GH-3224)
https://github.com/python/cpython/commit/2dfafa3c565c0b51920269a891fa270848b378d5


----------

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

From report at bugs.python.org  Sun Aug 27 18:19:32 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 27 Aug 2017 22:19:32 +0000
Subject: [docs] [issue31191] Fix grammar in threading.Barrier docs
In-Reply-To: <1502736895.43.0.873183336096.issue31191@psf.upfronthosting.co.za>
Message-ID: <1503872372.22.0.265106510152.issue31191@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


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

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

From report at bugs.python.org  Sun Aug 27 19:14:04 2017
From: report at bugs.python.org (Henk-Jaap Wagenaar)
Date: Sun, 27 Aug 2017 23:14:04 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503875644.82.0.182586271148.issue26656@psf.upfronthosting.co.za>


Henk-Jaap Wagenaar added the comment:

Emily: I've signed the CLA, just waiting for it to be checked.

----------
nosy: +Henk-Jaap Wagenaar

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

From report at bugs.python.org  Mon Aug 28 01:41:22 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 28 Aug 2017 05:41:22 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503898882.51.0.451050874858.issue26656@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:


New changeset ed94a8b2851914bcda3a77b28b25517b8baa91e6 by Mariatta (Henk-Jaap Wagenaar) in branch 'master':
bpo-26656: Improve re.compile documentation (GH-3211)
https://github.com/python/cpython/commit/ed94a8b2851914bcda3a77b28b25517b8baa91e6


----------
nosy: +Mariatta

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

From report at bugs.python.org  Mon Aug 28 01:43:38 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 28 Aug 2017 05:43:38 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503899018.64.0.246558428834.issue26656@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
pull_requests: +3267

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

From report at bugs.python.org  Mon Aug 28 01:50:10 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 28 Aug 2017 05:50:10 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503899410.21.0.389291437266.issue26656@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:


New changeset 83e5c888fff2bf3663952b2bfd3a3ee6c20386ef by Mariatta in branch '3.6':
[3.6] bpo-26656: Improve re.compile documentation (GH-3211) (GH-3225)
https://github.com/python/cpython/commit/83e5c888fff2bf3663952b2bfd3a3ee6c20386ef


----------

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

From report at bugs.python.org  Mon Aug 28 01:52:11 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 28 Aug 2017 05:52:11 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503899531.23.0.0265551899062.issue26656@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

There are two PRs for this issue. 
I accepted the earlier one, and it's been backported to 3.6.

Thanks everyone.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.5

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

From report at bugs.python.org  Mon Aug 28 01:53:50 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Aug 2017 05:53:50 +0000
Subject: [docs] [issue26656] Documentation for re.compile is a bit outdated
In-Reply-To: <1459178484.74.0.770971045402.issue26656@psf.upfronthosting.co.za>
Message-ID: <1503899630.96.0.388932139074.issue26656@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3268

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

From report at bugs.python.org  Mon Aug 28 02:57:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Aug 2017 06:57:16 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1503903436.58.0.178006838579.issue19431@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyFrameObject already is documented in Doc/c-api/veryhigh.rst.
PyFrame_GetLineNumber() already is documented in Doc/c-api/reflection.rst.

PyFrame_FastToLocals() and PyFrame_LocalsToFast() are not documented and have weird interface. I think the use of them should be discouraged.

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

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

From ofnuts at gmx.com  Sun Aug 27 15:55:20 2017
From: ofnuts at gmx.com (Ofnuts)
Date: Sun, 27 Aug 2017 21:55:20 +0200
Subject: [docs] Doc page at https://docs.python.org/2.7/download.html
Message-ID: <53efab03-56e6-05a0-a182-77535edfb039@gmx.com>

All links are down (doc for 2.7.14RC1 not ready yet?).

IMHO since it's a RC the version selector at the bottom right should 
keep a 2.7.13 entry (in fact, many people having to use ancient 2.7.x 
Python versions would still benefit from having easy access to old 2.7.x 
docs).

Cheers.


From rusty29nz at gmail.com  Sun Aug 27 17:16:59 2017
From: rusty29nz at gmail.com (Daz30 .)
Date: Mon, 28 Aug 2017 09:16:59 +1200
Subject: [docs] Python 2 docs download links broken
Message-ID: <CAEg3aXEYCG8yd2juWwQrqzGUMaeRcvxo=mnvCNOZuX=LJ4sP7Q@mail.gmail.com>

Hi there,

Just letting you know the Python2 doc links are broken, unable to download
the pdf of both versions listed on the download page
https://docs.python.org/2/download.html

Are they listed else where? and is there a single pdf document for these
docs as well?

Thanks
Darian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170828/7d9a6301/attachment-0001.html>

From jphschipper at gmail.com  Mon Aug 28 04:11:28 2017
From: jphschipper at gmail.com (Hans Schipper)
Date: Mon, 28 Aug 2017 10:11:28 +0200
Subject: [docs] problem with downloading docs
Message-ID: <CALhmumUsMqMADS2=Hxr4K082EvwKqj27UBFaE6ivtFZvWcnQMw@mail.gmail.com>

Hi

 I am trying to download the
Python 2.7.14rc1 Documentation
but I got this error
[image: Inline afbeelding 1]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170828/a2739d29/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 42680 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20170828/a2739d29/attachment-0001.png>

From report at bugs.python.org  Mon Aug 28 14:55:35 2017
From: report at bugs.python.org (Pablo)
Date: Mon, 28 Aug 2017 18:55:35 +0000
Subject: [docs] [issue31294] ZeroMQSocketListener and ZeroMQSocketHandler
 examples in the Logging Cookbook not working
Message-ID: <1503946535.18.0.843983247211.issue31294@psf.upfronthosting.co.za>


New submission from Pablo:

There are two documentation issues regarding the ZeroMQSocketListener and ZeroMQSocketHandler examples in the Logging Cookbook:


The first issue is that in the 'init' method for the 'ZeroMQSocketListener' the base class 'init' is never called and therefore the internal variables are not correctly initialized. This leads to an empty 'handlers' attribute and a undefined 'queue' attribute.

The second issue is that zmq.Socket.send and zmq.Socket.setsockopt only admits bytecode variables and therefore it fails in Python3 when using plain strings.

----------
assignee: docs at python
components: Documentation
messages: 300960
nosy: docs at python, pablogsal
priority: normal
pull_requests: 3273
severity: normal
status: open
title: ZeroMQSocketListener and ZeroMQSocketHandler examples in the Logging Cookbook not working

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

From report at bugs.python.org  Mon Aug 28 15:42:50 2017
From: report at bugs.python.org (Antony Lee)
Date: Mon, 28 Aug 2017 19:42:50 +0000
Subject: [docs] [issue31295] typo in __hash__ docs
Message-ID: <1503949370.09.0.113747018634.issue31295@psf.upfronthosting.co.za>


New submission from Antony Lee:

In https://docs.python.org/3.7/reference/datamodel.html#object.__hash__ I think

x.__hash__() returns an appropriate value such that x == y implies both that x is y and hash(x) == hash(y).

should be

x.__hash__() returns an appropriate value such that x == y and x is y both imply that hash(x) == hash(y).

right?

----------
assignee: docs at python
components: Documentation
messages: 300961
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: typo in __hash__ docs
versions: Python 3.7

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

From report at bugs.python.org  Mon Aug 28 16:00:57 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 28 Aug 2017 20:00:57 +0000
Subject: [docs] [issue31295] typo in __hash__ docs
In-Reply-To: <1503949370.09.0.113747018634.issue31295@psf.upfronthosting.co.za>
Message-ID: <1503950457.22.0.870985929417.issue31295@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, it is correct as worded.  It is talking about the default methods.  With the default methods, x == y implies that x is y.

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

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

From report at bugs.python.org  Tue Aug 29 10:46:26 2017
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 29 Aug 2017 14:46:26 +0000
Subject: [docs] [issue31065] Documentation for Popen.poll is unclear
In-Reply-To: <1501237857.05.0.15004204926.issue31065@psf.upfronthosting.co.za>
Message-ID: <1504017986.17.0.654605426245.issue31065@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:


New changeset 006617ff7d6df3fdedcfe53e94ee2c52cc796437 by Gregory P. Smith (Ivan Chernoff) in branch 'master':
bpo-31065: Add doc about Popen.poll returning None. (#3169)
https://github.com/python/cpython/commit/006617ff7d6df3fdedcfe53e94ee2c52cc796437


----------
nosy: +gregory.p.smith

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

From sravi13288 at gmail.com  Mon Aug 28 19:44:52 2017
From: sravi13288 at gmail.com (sravani jadala)
Date: Mon, 28 Aug 2017 18:44:52 -0500
Subject: [docs] Python Developer Books
Message-ID: <CAJcFh_H4XT6wQQSuOAuurJ8x3g5a08ux0w9-j_1SPzaf9QPCNg@mail.gmail.com>

Hello,

Myself Sravani I have some technical experience now I want to learn Python
and want to get a job as Python developer, I am trying to find the
documentation on your website but I am not able to find the exact
development documentation.

Can you please help me in documentation and video tutorials so that I can
get good knowledge in Python.

Thanks in Advance
-- 



Regards
Sravani Jadala
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170828/6afcbfc8/attachment-0001.html>

From angeldfreitez at gmail.com  Mon Aug 28 20:42:19 2017
From: angeldfreitez at gmail.com (Angel Diaz)
Date: Mon, 28 Aug 2017 20:42:19 -0400
Subject: [docs] i dont dowload python Documentation
Message-ID: <CAE0CY=uyQRXH=CHrXdi614xco7ePFg90vpZuNunSLechgpjGjA@mail.gmail.com>

Please, send me the documentation of python 2.7.12

thanks!!

*Angel Daniel Diaz Freitez*
Software Developer
Phone: +584261302698
Email:   angeldfreitez at gmail.com
Skype:  angeldiaz1994
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170828/43557e0c/attachment-0001.html>

From federico.vaga at vaga.pv.it  Tue Aug 29 04:02:57 2017
From: federico.vaga at vaga.pv.it (Federico Vaga)
Date: Tue, 29 Aug 2017 10:02:57 +0200
Subject: [docs] Python 2.7.14 Doc Download
Message-ID: <3238892.yAKertZskv@harkonnen>

Hello,

I'm trying to download the Python 2.7 documentation but it is impossible due 
to the following error: 

https://docs.python.org/2/archives/python-2.7.14rc1-docs-html.tar.bz2
"404 Not Found"

the same for the other formats.

Thank you in advance

-- 
Federico Vaga
http://www.federicovaga.it/

From atif.k at live.com  Tue Aug 29 11:09:41 2017
From: atif.k at live.com (Atif Khan)
Date: Tue, 29 Aug 2017 15:09:41 +0000
Subject: [docs] Error 404 on download page
Message-ID: <MA1PR01MB08442AC10BCC7494A42CD6ABFC9F0@MA1PR01MB0844.INDPRD01.PROD.OUTLOOK.COM>

Hi,
I can?t download the documentation for Python 2.7.14rc1. All the links come up empty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170829/4d146418/attachment.html>

From report at bugs.python.org  Tue Aug 29 16:13:31 2017
From: report at bugs.python.org (tamas)
Date: Tue, 29 Aug 2017 20:13:31 +0000
Subject: [docs] [issue31304] Update doc for starmap_async error_back kwarg
Message-ID: <1504037611.28.0.102125644209.issue31304@psf.upfronthosting.co.za>


New submission from tamas:

The documentation suggests that multiprocessing.pool.Pool. starmap_async has a kwarg called 'error_back', but it actually has a kwarg called 'error_callback' to handle errors, just like map_async.

Link:
https://docs.python.org/3.7/library/multiprocessing.html#multiprocessing.pool.Pool.starmap_async

----------
assignee: docs at python
components: Documentation
messages: 300999
nosy: docs at python, tamas
priority: normal
severity: normal
status: open
title: Update doc for starmap_async error_back kwarg
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Aug 29 17:39:59 2017
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 29 Aug 2017 21:39:59 +0000
Subject: [docs] [issue30637] Syntax error reported on compile(...),
 but not on compile(..., ast.PyCF_ONLY_AST)
In-Reply-To: <1497271056.08.0.482498543523.issue30637@psf.upfronthosting.co.za>
Message-ID: <1504042799.86.0.125756064491.issue30637@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

> Can you suggest a couple of sentences you would have like to have
> seen, and where?

Thanks, I would suggest to add something like this to the documentation of ast.parse:

"""
``parse`` raises ``SyntaxError`` if the compiled source is invalid, and ``ValueError`` if the source contains null bytes. Note that a successful parse does not guarantee correct syntax of ``source``. Further syntax errors can be detected, and ``SyntaxError`` raised, when the source is compiled to a code object using ``compile`` without the ``ast.PyCF_ONLY_AST`` flag, or executed with ``exec``. For example, a lone ``break`` statement can be parsed, but not converted into a code object or executed.
"""

I don't think the ``compile`` docs need to be changed, partly because they're already sizable, and partly because they don't document individual flags at all. (A reference to the ``ast`` module regarding the flags, like the one for AST objects in the first paragraph, might be a useful addition.)

----------

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

From report at bugs.python.org  Tue Aug 29 22:19:09 2017
From: report at bugs.python.org (Morris Li)
Date: Wed, 30 Aug 2017 02:19:09 +0000
Subject: [docs] [issue31305] 'pydoc -w import' report "no Python
 documentation found for 'import'"
Message-ID: <1504059549.2.0.437424390728.issue31305@psf.upfronthosting.co.za>


Changes by Morris Li <limuyuan91 at 126.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, limuyuan
priority: normal
severity: normal
status: open
title: 'pydoc -w import' report "no Python documentation found for 'import'"
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Aug 29 22:22:41 2017
From: report at bugs.python.org (Morris Li)
Date: Wed, 30 Aug 2017 02:22:41 +0000
Subject: [docs] [issue31305] 'pydoc -w import' report "no Python
 documentation found for 'import'"
Message-ID: <1504059761.52.0.352521869888.issue31305@psf.upfronthosting.co.za>


Changes by Morris Li <limuyuan91 at 126.com>:


----------
versions: +Python 3.5

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

From report at bugs.python.org  Wed Aug 30 18:47:57 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Aug 2017 22:47:57 +0000
Subject: [docs] [issue30096] Update examples in abc documentation to use
 abc.ABC
In-Reply-To: <1492545098.58.0.705598301268.issue30096@psf.upfronthosting.co.za>
Message-ID: <1504133277.16.0.0842571754719.issue30096@psf.upfronthosting.co.za>


?ric Araujo added the comment:


New changeset 122e88a8354e3f75aeaf6211232dac88ac296d54 by ?ric Araujo (Eric Appelt) in branch 'master':
bpo-30096: Use ABC in abc reference examples (#1220)
https://github.com/python/cpython/commit/122e88a8354e3f75aeaf6211232dac88ac296d54


----------
nosy: +merwok

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

From report at bugs.python.org  Wed Aug 30 18:50:00 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 30 Aug 2017 22:50:00 +0000
Subject: [docs] [issue30096] Update examples in abc documentation to use
 abc.ABC
In-Reply-To: <1492545098.58.0.705598301268.issue30096@psf.upfronthosting.co.za>
Message-ID: <1504133400.34.0.0683486651531.issue30096@psf.upfronthosting.co.za>


?ric Araujo added the comment:

Thanks for the patch!  Raymond approved it and I merged it after a minor change.  Now let me read the doc again about backports :)

----------
stage: needs patch -> backport needed
versions: +Python 3.6

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

From report at bugs.python.org  Thu Aug 31 14:32:43 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 31 Aug 2017 18:32:43 +0000
Subject: [docs] [issue30940] Documentation for round() is incorrect.
In-Reply-To: <1500223918.38.0.72996478594.issue30940@psf.upfronthosting.co.za>
Message-ID: <1504204363.19.0.249889766757.issue30940@psf.upfronthosting.co.za>


Changes by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +3300

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

From clemens_max at freenet.de  Thu Aug 31 02:53:14 2017
From: clemens_max at freenet.de (Clemens Max)
Date: Thu, 31 Aug 2017 08:53:14 +0200
Subject: [docs] Download links lead to 404
Message-ID: <000301d32225$d208e910$761abb30$@de>

The links like
<https://docs.python.org/2/archives/python-2.7.14rc1-docs-pdf-a4.zip>
https://docs.python.org/2/archives/python-2.7.14rc1-docs-pdf-a4.zip are
leading to a 404 page.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170831/5b364260/attachment.html>

From jmcook at ara.com  Thu Aug 31 13:46:37 2017
From: jmcook at ara.com (Jon Cook)
Date: Thu, 31 Aug 2017 17:46:37 +0000
Subject: [docs] 404 on website
Message-ID: <7C4AE6E6384B9841984F72A7E4F5F59470690D5E@colo-mail-1.exchange2.ara.wan>

Hello,

When I attempt to download any of the PDF docs from https://docs.python.org/3.5/download.html, I receive a 404 Error.  For example, https://docs.python.org/3.5/archives/python-3.5.4-docs-pdf-letter.tar.bz2 is a 404.

Thanks,
Jon

Jonathan Cook, Ph.D.
Applied Research Associates, Inc.
801 N Quincy St, Suite 700
Arlington, VA  22203
(571) 814-2402



From mohammad.etemaddar at gmail.com  Thu Aug 31 10:07:00 2017
From: mohammad.etemaddar at gmail.com (Mohammad Etemaddar)
Date: Thu, 31 Aug 2017 18:37:00 +0430
Subject: [docs] Error 404 in documentation download
Message-ID: <CALJt1ntM-xw-UqoKA9UX=D4JhNGyGtnT0w9t4=QxZbqJduU9Aw@mail.gmail.com>

Hello,
Thanks a lot for great work about Python and programming and all...
In page https://docs.python.org/3/download.html The "tar.bz2" version of
documents are not present and throw error 404.

Thanks a lot again.
Good job,

Mohammad Etemaddar

*  in   <http://www.linkedin.com/pub/mohammad-etemaddar/9/832/462>*
Programming services: *Python* & *Linux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170831/0299f07c/attachment.html>

From pedroguarimata at gmail.com  Wed Aug 30 23:31:38 2017
From: pedroguarimata at gmail.com (Pedro Guarimata)
Date: Wed, 30 Aug 2017 23:31:38 -0400
Subject: [docs] Links broken
Message-ID: <CAJ8OT6Z=2ZLJO4f1cLZeFuMySObW4d=3H=W4YWcCqoSPevUh1g@mail.gmail.com>

hi the links to download python docs can not be found, error 404. at
30/08/2017

https://docs.python.org/3.6/archives/python-3.6.2-docs-html.zip
https://docs.python.org/3.6/archives/python-3.6.2-docs-html.tar.bz2

thk for your time. have a great day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170830/c355de91/attachment.html>

From rainbowsally at rainbowsally.org  Wed Aug 30 19:55:24 2017
From: rainbowsally at rainbowsally.org (rainbowsally)
Date: Wed, 30 Aug 2017 16:55:24 -0700
Subject: [docs] code bug in doc
Message-ID: <59A7506C.7070909@rainbowsally.org>

In section "4.6. Defining Functions" on this page,

https://docs.python.org/2.7/tutorial/controlflow.html

The code doesn't end with a newline and produces a syntax error due to 
the >>> prompt at the end of the output.

Add another 'print' at the end to correct it.

>>>def  fib(n):     # write Fibonacci series up to n
...      """Print a Fibonacci series up to n."""
...      a,  b  =  0,  1
...      while  a  <  n:
...          print  a,
...          a,  b  =  b,  a+b ... print ''

or something like that.

May also need a note to describe what the comma is doing in the "print 
a" line. This comma isn't mentioned again until the Input and Output docs in
https://docs.python.org/2.7/tutorial/inputoutput.html

>>>for  x  in  range(1,  11):
...      print  repr(x).rjust(2),  repr(x*x).rjust(3),
...      # Note trailing comma on previous line
...      print  repr(x*x*x).rjust(4)

But the function of the trailing comma is not explained there either.

Been holding off of learning a new programming language for quite a 
while but I may just take the leap with Python this time.



From rolf at flexcim.ca  Thu Aug 31 15:29:22 2017
From: rolf at flexcim.ca (Robert Rolf)
Date: Thu, 31 Aug 2017 13:29:22 -0600
Subject: [docs] Typo in doc
Message-ID: <CAD076S-gV_EO4mTA4J4ZuVDFq2EFkjzWH1z1KhUa4oiHddgqow@mail.gmail.com>

https://docs.python.org/2/library/stdtypes.html
5.4. Numeric Types ? int
<https://docs.python.org/2/library/functions.html#int>, float
<https://docs.python.org/2/library/functions.html#float>, long
<https://docs.python.org/2/library/functions.html#long>, complex
<https://docs.python.org/2/library/functions.html#complex>?
<https://docs.python.org/2/library/stdtypes.html#numeric-types-int-float-long-complex>
Should be "int, long, float, complex" to match description and ranking in
following discussion.

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170831/f2aa6950/attachment-0001.html>

From sameerpadghan at gmail.com  Wed Aug 30 01:20:10 2017
From: sameerpadghan at gmail.com (Sameer Padghan)
Date: Wed, 30 Aug 2017 10:50:10 +0530
Subject: [docs] Not able to download.
In-Reply-To: <CABauYiRZE_98HmM7wsiQ9T_kzdOxRwS6rduyNEPW6HiPZPpR2A@mail.gmail.com>
References: <CABauYiRZE_98HmM7wsiQ9T_kzdOxRwS6rduyNEPW6HiPZPpR2A@mail.gmail.com>
Message-ID: <CABauYiTWPZ8RvtJkE4P7bsiVgGuPr11US34qWhHF2u3_veA8hg@mail.gmail.com>

Our website is great but I am not able to download the official
documentation pages of python.I hope you will help me as soon as possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170830/1c089710/attachment.html>