From report at bugs.python.org  Sun Jan  1 18:03:59 2017
From: report at bugs.python.org (Michael Mrozek)
Date: Sun, 01 Jan 2017 23:03:59 +0000
Subject: [docs] [issue29129] Copy/paste error in "8.13.14.1.1. Using auto"
Message-ID: <1483311839.39.0.725935533948.issue29129@psf.upfronthosting.co.za>


New submission from Michael Mrozek:

The "8.13.14.1.1 Using auto" section ( https://docs.python.org/3/library/enum.html#using-auto ) looks like it was copied from the subsequent "8.13.14.1.2 Using object" section, and a reference to "object" wasn't changed to "auto" in the first line.

----------
assignee: docs at python
components: Documentation
messages: 284434
nosy: docs at python, mrozekma
priority: normal
severity: normal
status: open
title: Copy/paste error in "8.13.14.1.1. Using auto"
versions: Python 3.6

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

From songofacandy at gmail.com  Sun Jan  1 19:56:59 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Mon, 2 Jan 2017 09:56:59 +0900
Subject: [docs] reference doc problem
In-Reply-To: <20161231151755.68228616@monolith.infinux.org>
References: <20161231151755.68228616@monolith.infinux.org>
Message-ID: <CAEfz+TyR5Yiuu-BM3ohT5zFYdOsw1-H1JnR+BeiJxxhotNWqUQ@mail.gmail.com>

Yes.

`is`, `and`, `or`, `not` are both keyword and operator.

keyword means it's reserved word for language.
User can't use the word for name.
But how language uses the keyword is different thing.

Some keywords (def, if, for...) are used for syntax.
Some keywords (and, is, ...) are used for operator.


On Sun, Jan 1, 2017 at 5:17 AM, Christopher Barry <cbarry at symbiaudix.com> wrote:
>
> https://docs.python.org/3.5/reference/lexical_analysis.html#keywords
>
> describes 'is' as a keyword, yet
>
> https://docs.python.org/3.5/reference/datamodel.html#objects-values-and-types
>
> describes 'is' as an operator.
>
> Which is it? If it really is an operator (too?), shouldn't it be here:
>
> https://docs.python.org/3.5/reference/lexical_analysis.html#operators
>
> as well?
>
> --
> Regards,
> Christopher Barry
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>

From report at bugs.python.org  Sun Jan  1 21:43:14 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jan 2017 02:43:14 +0000
Subject: [docs] [issue29024] Add Kivy entry to Graphic User Interface FAQ
Message-ID: <20170102024311.28640.90420.FAF2A31E@psf.io>


New submission from Roundup Robot:

New changeset d41aa32f7f3c by Berker Peksag in branch '3.5':
Issue #29024: Add Kivy entry to GUI FAQ
https://hg.python.org/cpython/rev/d41aa32f7f3c

New changeset ee25895d9d65 by Berker Peksag in branch '3.6':
Issue #29024: Merge from 3.5
https://hg.python.org/cpython/rev/ee25895d9d65

New changeset 4eb4cf6ac154 by Berker Peksag in branch 'default':
Issue #29024: Merge from 3.6
https://hg.python.org/cpython/rev/4eb4cf6ac154

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

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

From report at bugs.python.org  Sun Jan  1 21:43:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Jan 2017 02:43:48 +0000
Subject: [docs] [issue29024] Add Kivy entry to Graphic User Interface FAQ
In-Reply-To: <20170102024311.28640.90420.FAF2A31E@psf.io>
Message-ID: <1483325028.72.0.0624429435663.issue29024@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch!

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

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

From report at bugs.python.org  Sun Jan  1 21:49:06 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jan 2017 02:49:06 +0000
Subject: [docs] [issue29129] Copy/paste error in "8.13.14.1.1. Using auto"
In-Reply-To: <1483311839.39.0.725935533948.issue29129@psf.upfronthosting.co.za>
Message-ID: <20170102024903.124199.60880.6B444FD6@psf.io>


Roundup Robot added the comment:

New changeset 5698d84d0187 by Berker Peksag in branch '3.6':
Issue #29129: Fix typo in "Using auto" section
https://hg.python.org/cpython/rev/5698d84d0187

New changeset 337d78a4a7bf by Berker Peksag in branch 'default':
Issue #29129: Merge from 3.6
https://hg.python.org/cpython/rev/337d78a4a7bf

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

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

From report at bugs.python.org  Sun Jan  1 21:49:47 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Jan 2017 02:49:47 +0000
Subject: [docs] [issue29129] Copy/paste error in "8.13.14.1.1. Using auto"
In-Reply-To: <1483311839.39.0.725935533948.issue29129@psf.upfronthosting.co.za>
Message-ID: <1483325387.27.0.558788388976.issue29129@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch! Thanks for the report, Michael.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.7

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

From report at bugs.python.org  Sun Jan  1 21:59:05 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jan 2017 02:59:05 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <20170102025902.25578.85467.9B0FB0B8@psf.io>


Roundup Robot added the comment:

New changeset 721df314d45a by Berker Peksag in branch '3.5':
Issue #29012: Remove outdated information about __bases__
https://hg.python.org/cpython/rev/721df314d45a

New changeset 019125fb6d66 by Berker Peksag in branch '3.6':
Issue #29012: Merge from 3.5
https://hg.python.org/cpython/rev/019125fb6d66

New changeset 454426dbff83 by Berker Peksag in branch 'default':
Issue #29012: Merge from 3.6
https://hg.python.org/cpython/rev/454426dbff83

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

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

From report at bugs.python.org  Sun Jan  1 21:59:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Jan 2017 02:59:48 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1483325988.9.0.158606399812.issue29012@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Jim.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jan  1 22:12:15 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 Jan 2017 03:12:15 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <20170102031213.21509.93331.E2AF9767@psf.io>


Roundup Robot added the comment:

New changeset 4685cd33087b by Berker Peksag in branch '3.5':
Issue #29013: Fix allowZip64 documentation
https://hg.python.org/cpython/rev/4685cd33087b

New changeset 7c5075a14459 by Berker Peksag in branch '3.6':
Issue #29013: Merge from 3.5
https://hg.python.org/cpython/rev/7c5075a14459

New changeset 6ca0f3fcf82f by Berker Peksag in branch 'default':
Issue #29013: Merge from 3.6
https://hg.python.org/cpython/rev/6ca0f3fcf82f

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

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

From report at bugs.python.org  Sun Jan  1 22:13:23 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 Jan 2017 03:13:23 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1483326803.86.0.223111238622.issue29013@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the analysis, Monte!

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

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

From report at bugs.python.org  Mon Jan  2 01:22:28 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jan 2017 06:22:28 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1483338148.94.0.349558659091.issue29013@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation was correct. The zipfile module supports *reading* ZIP files up to 4 GiB without the ZIP64 extension, but it requires allowZip64=True for *writing* over 2 GiB files to the ZIP file.

The 2 GiB limit is safer because generated ZIP files can be read by implementations that interpret 32-bit sizes as signed. For example Java don't have unsigned integers. And zipfile and zipimport in old Python versions unpack some fields as signed integers.

----------
nosy: +serhiy.storchaka
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

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

From report at bugs.python.org  Mon Jan  2 01:27:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 Jan 2017 06:27:25 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1483338444.98.0.225790659044.issue29012@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think "possible a singleton" can be removed too. It doesn't add any useful information, any tuple is possible a singleton.

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

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

From report at bugs.python.org  Mon Jan  2 03:14:50 2017
From: report at bugs.python.org (Monte Davidoff)
Date: Mon, 02 Jan 2017 08:14:50 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1483344890.13.0.900364558946.issue29013@psf.upfronthosting.co.za>


Monte Davidoff added the comment:

Serhiy, thank you for the correction and the additional information. I tried reading a zip file larger than 4 GiB with allowZip64=False, and it worked, so it looks like allowZip64 only applies to writing. I suggest we fix the inconsistency in the documentation as follows:

(1) In the description of the zipfile.ZipFile class, revert the change back to:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB."

(2) Change the second paragraph in the zipfile module documentation from:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 4 GiB in size)."

to:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 2 GiB in size)."

----------

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

From report at bugs.python.org  Mon Jan  2 08:00:12 2017
From: report at bugs.python.org (Evan)
Date: Mon, 02 Jan 2017 13:00:12 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
Message-ID: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>


New submission from Evan:

https://docs.python.org/3/library/shlex.html#improved-compatibility-with-shells

The code sample here does not match the output - the first line is labelled 'New' and the second line 'Old'.

----------
assignee: docs at python
components: Documentation
messages: 284481
nosy: docs at python, evan_
priority: normal
severity: normal
status: open
title: Minor inaccuracy in shlex.shlex punctuation_chars example
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Jan  2 12:06:09 2017
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 02 Jan 2017 17:06:09 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483376769.74.0.330747878241.issue29133@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Thank you. The patch fixes it and makes the example under doctest.

----------
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file46114/issue29133.patch

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

From report at bugs.python.org  Mon Jan  2 17:33:14 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 02 Jan 2017 22:33:14 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1483396394.41.0.188047797478.issue29012@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Yes, I agree with that it seems redundant after the change. I'm attaching another small patch based on the committed one to trim that off.

----------
Added file: http://bugs.python.org/file46117/fixbasesdoc2.patch

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

From report at bugs.python.org  Mon Jan  2 19:33:51 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jan 2017 00:33:51 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <20170103003347.28640.60947.39BFE939@psf.io>


Roundup Robot added the comment:

New changeset 1aba7cbbcc27 by Berker Peksag in branch '3.5':
Issue #29012: Remove another outdated information
https://hg.python.org/cpython/rev/1aba7cbbcc27

New changeset 7ef5b02b228a by Berker Peksag in branch '3.6':
Issue #29012: Merge from 3.5
https://hg.python.org/cpython/rev/7ef5b02b228a

New changeset f05165a9cae6 by Berker Peksag in branch 'default':
Issue #29012: Merge from 3.6
https://hg.python.org/cpython/rev/f05165a9cae6

----------

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

From report at bugs.python.org  Mon Jan  2 19:35:28 2017
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 Jan 2017 00:35:28 +0000
Subject: [docs] [issue29012] __bases__ is a tuple (possibly empty or a
 singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1483403728.9.0.571700035702.issue29012@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good point, Serhiy. Thanks for the patch, Jim. I've now removed the "possible a singleton" part.

----------

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

From report at bugs.python.org  Mon Jan  2 19:57:11 2017
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 Jan 2017 00:57:11 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1483405031.1.0.575413683793.issue29013@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Right, that's my fault. Apparently I missed the "[...] zipfile will create [...]" part :) What do you think about Monte's suggested changes Serhiy? Should we just revert 4685cd33087b (1) or do both (1) and (2)?

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

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

From report at bugs.python.org  Mon Jan  2 21:18:08 2017
From: report at bugs.python.org (Evan)
Date: Tue, 03 Jan 2017 02:18:08 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483409888.18.0.264487649291.issue29133@psf.upfronthosting.co.za>


Evan added the comment:

Sorry for not being more clear in the original report - the error is in the code, not in the output. The old behavior is punct=False, the new is punct=True.

----------

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

From report at bugs.python.org  Tue Jan  3 05:40:56 2017
From: report at bugs.python.org (SilentGhost)
Date: Tue, 03 Jan 2017 10:40:56 +0000
Subject: [docs] [issue29134] contextlib doc bug
In-Reply-To: <1483376051.72.0.678487921628.issue29134@psf.upfronthosting.co.za>
Message-ID: <1483440056.02.0.377246300821.issue29134@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Jan  3 06:24:44 2017
From: report at bugs.python.org (Michael Felt)
Date: Tue, 03 Jan 2017 11:24:44 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1483442684.24.0.164406889944.issue28845@psf.upfronthosting.co.za>


Michael Felt added the comment:

FWIW: just build python-2.7.13 using xlC - and ncurses-6.0 installed.

root at x064:[/data/prj/python/python2-2.7.13]
root at x064:[/data/prj/python/python2-2.7.13]./python
Python 2.7.13 (default, Jan  3 2017, 11:16:59) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
>>> from curses import panel
>>> def mkpanel(scr):
...  win = curses.newwin(8,8,1,1)
...  pan = panel.new_panel(win)
...
>>> curses.wrapper(mkpanel)
>>>

So, even for AIX 5.3 and Python2.7 this test seems solved. If the above is all that is needed!

----------

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

From report at bugs.python.org  Tue Jan  3 07:49:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Jan 2017 12:49:51 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1483447791.4.0.598910199971.issue28911@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  3 08:21:22 2017
From: report at bugs.python.org (Michael Felt)
Date: Tue, 03 Jan 2017 13:21:22 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1483449682.05.0.737624194721.issue28845@psf.upfronthosting.co.za>


Michael Felt added the comment:

I request that you review issue27435 - in particular msg284557 - as I feel ctypes implementation for AIX is broken - at least as far as the supporting routines are concerned.

When you know the "magic" one can call ctypes.CDLL() and it 'works'. ctypes.util.find_library() always returns None (maybe it works if a stack of GNU tools are also loaded, but not on a 'generic' AIX install)

ctypes.LibraryLoader() is always successful (i.e., no Traceback) but I am (personally) unsure of the actual return value. It feels like a false positive.

Thank you for your time and consideration!

p.s. - a "fix/patch" is nearly accepted for Python3.7 (see issue26439) - needs more for the docs - however, I feel is is a great short-coming to limit this to versions that are yet to come!

----------

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

From report at bugs.python.org  Tue Jan  3 09:24:27 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Jan 2017 14:24:27 +0000
Subject: [docs] [issue29092] Sync os.stat's doc and doc string
In-Reply-To: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>
Message-ID: <1483453467.66.0.23948125032.issue29092@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's a recent change, before path type was always str.

----------
nosy: +haypo, serhiy.storchaka

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

From report at bugs.python.org  Tue Jan  3 09:25:36 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Jan 2017 14:25:36 +0000
Subject: [docs] [issue29092] Sync os.stat's doc and doc string
In-Reply-To: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>
Message-ID: <1483453536.73.0.924322329779.issue29092@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ignore my comment, I was thinking to something else (recent os.scandir change on Windows).

----------

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

From report at bugs.python.org  Tue Jan  3 09:35:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 Jan 2017 14:35:54 +0000
Subject: [docs] [issue27671] FAQ: len() is still function for good reason.
In-Reply-To: <1470214886.13.0.870924776007.issue27671@psf.upfronthosting.co.za>
Message-ID: <1483454154.04.0.0313572625067.issue27671@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  3 11:52:28 2017
From: report at bugs.python.org (Marco Buttu)
Date: Tue, 03 Jan 2017 16:52:28 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483462348.17.0.14058561118.issue29133@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Yes, you are right. Here is a patch.

----------
Added file: http://bugs.python.org/file46128/issue29133_2nd.patch

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

From report at bugs.python.org  Tue Jan  3 16:12:51 2017
From: report at bugs.python.org (John Parejko)
Date: Tue, 03 Jan 2017 21:12:51 +0000
Subject: [docs] [issue29146] Confusing "invalid token" exception when
 integers have leading zero
Message-ID: <1483477971.7.0.132370199799.issue29146@psf.upfronthosting.co.za>


New submission from John Parejko:

As described in PEP-3127, the "leading-zeros" formatting for octal was removed from python 3. This is a good thing(tm), but the recommendation of that PEP to improve the error message of the raised exception[1] was apparently never implemented. I just ran into this while with some recently-ported python2 code, and it took a while to figure out the problem.

Although this is going to be less of a problem with time as people convert to pure python3, it will be very helpful during the transition period.

>>> 0o007
7
>>> 007
  File "<stdin>", line 1
    007
      ^
SyntaxError: invalid token


1: https://www.python.org/dev/peps/pep-3127/#id17

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Documentation, Interpreter Core
messages: 284591
nosy: John Parejko, docs at python
priority: normal
severity: normal
status: open
title: Confusing "invalid token" exception when integers have leading zero
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Jan  3 16:31:04 2017
From: report at bugs.python.org (John Parejko)
Date: Tue, 03 Jan 2017 21:31:04 +0000
Subject: [docs] [issue29146] Confusing "invalid token" exception when
 integers have leading zero
In-Reply-To: <1483477971.7.0.132370199799.issue29146@psf.upfronthosting.co.za>
Message-ID: <1483479064.81.0.527151005614.issue29146@psf.upfronthosting.co.za>


John Parejko added the comment:

Ah, I finally found a related issue, and it looks like it has patches! https://bugs.python.org/issue20608

If someone could check that over and merge it, that would be wonderful!

----------

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

From report at bugs.python.org  Tue Jan  3 17:58:20 2017
From: report at bugs.python.org (Evan)
Date: Tue, 03 Jan 2017 22:58:20 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483484300.23.0.763777692003.issue29133@psf.upfronthosting.co.za>


Evan added the comment:

Second patch looks good, thanks. Do you also want to doctest that?

----------

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

From report at bugs.python.org  Tue Jan  3 21:57:54 2017
From: report at bugs.python.org (Greg Bengeult)
Date: Wed, 04 Jan 2017 02:57:54 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <1483498674.53.0.73466442702.issue16026@psf.upfronthosting.co.za>


Greg Bengeult added the comment:

Here's a revised patch file for Python 3.7. This is my first ever submission to an open source project, so please be gentle.

----------
nosy: +gbengeult
versions:  -Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file46132/csv.rst-patch

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

From report at bugs.python.org  Wed Jan  4 00:09:06 2017
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 04 Jan 2017 05:09:06 +0000
Subject: [docs] [issue29134] contextlib doc bug
In-Reply-To: <1483376051.72.0.678487921628.issue29134@psf.upfronthosting.co.za>
Message-ID: <1483506546.83.0.111829364604.issue29134@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

I am going to vote for "not a bug" here. From the context is it understood that the `ContextBaseClass` is to be provided by the user.

> Existing context managers that already have a base class can be extended by using ContextDecorator as a mixin class:

The idea here is the illustrate the Mixin possibility with a Base class and not to provide a full example with Base class code as well.

@Marco, also not a good ticket add more doc strings to this module.rst. If the docs of those can be improved, they can done separately, concentrating on all the possible improvements.

----------
nosy: +orsenthil
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed Jan  4 00:55:19 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 Jan 2017 05:55:19 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <1483509319.74.0.604623710606.issue16026@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Welcome and thanks for the patch, Greg. csv.rst-patch looks good to me. I will commit it this week if there are no objections.

Documentation updates can go into all active branches so I'm adding 3.5 and 3.6 back (we can pass 2.7 at this point since this is a trivial change)

----------
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed Jan  4 04:14:58 2017
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 04 Jan 2017 09:14:58 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483521298.67.0.658350031768.issue29133@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I did not add the doctest directive on purpose. In fact, if in the future we start running the doctests with buildbot (see issue27200), the tests related to this issue will pass only for Python >= 3.6. If we _currently_ want the doctests to pass for every Python version, I see only two solutions:

1) we do not have to doctest the example, as I did in issue29133_2nd.patch
2) we have to apply two patches, one with doctests (for the doc to be tested with Python >= 3.6), and another one without doctests (for the doc to be tested with Python < 3.6).

I think the best solution is to add an option to the doctest directive, that allows us to specify for which Python version the tests have to be run:

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

I would like the commiters to give a feedback about this, because if they think  this solution is doable, then I will spend the time to work on the Sphinx issue.

----------

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

From report at bugs.python.org  Wed Jan  4 04:27:25 2017
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 04 Jan 2017 09:27:25 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483522045.18.0.0173938486514.issue29133@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


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

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

From report at bugs.python.org  Wed Jan  4 10:56:37 2017
From: report at bugs.python.org (Kyle Altendorf)
Date: Wed, 04 Jan 2017 15:56:37 +0000
Subject: [docs] [issue29134] contextlib doc bug
In-Reply-To: <1483376051.72.0.678487921628.issue29134@psf.upfronthosting.co.za>
Message-ID: <1483545397.35.0.595536295683.issue29134@psf.upfronthosting.co.za>


Kyle Altendorf added the comment:

I would think that the idea of simply adding some reference to `User` such as was suggested with `UserDefinedContextClass` would be reasonable and helpful.  This doesn't involve any more code merely a more explanatory name.

----------
nosy: +altendky

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

From report at bugs.python.org  Wed Jan  4 18:40:45 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 Jan 2017 23:40:45 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <1483573245.3.0.882368752233.issue29023@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The wording can perhaps be made more precise.  However, this needs to be the end of this series of tracker items which are turning into time wasters.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Thu Jan  5 01:47:59 2017
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 05 Jan 2017 06:47:59 +0000
Subject: [docs] [issue29165] Use forward compatible macro in example code
 for creating new type
Message-ID: <1483598879.57.0.52341008423.issue29165@psf.upfronthosting.co.za>


New submission from INADA Naoki:

https://docs.python.org/2.7/extending/newtypes.html#the-basics uses PyObject_HEAD_INIT for type object header.

static PyTypeObject noddy_NoddyType = {
    PyObject_HEAD_INIT(NULL)
    0,                         /*ob_size*/

This code isn't compatible with Python 3.  In Python 3, PyVarObject_HEAD_INIT is used instead.
https://docs.python.org/3.6/extending/newtypes.html#the-basics

static PyTypeObject noddy_NoddyType = {
    PyVarObject_HEAD_INIT(NULL, 0)

This code is compatible with Python 2.


This example code can be copy and pasted when creating new extension.
If people start writing Python 2 extension, and forward port it to Python 3,
this small incompatibility cause compile error.

Let's use more forward compatible and short code for example.

----------
assignee: docs at python
components: Documentation
messages: 284709
nosy: docs at python, inada.naoki
priority: normal
severity: normal
status: open
title: Use forward compatible macro in example code for creating new type
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan  5 04:01:24 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Jan 2017 09:01:24 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <1483606884.84.0.473574263649.issue29023@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg284677

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

From report at bugs.python.org  Thu Jan  5 04:02:25 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Jan 2017 09:02:25 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <1483606945.96.0.596432909066.issue29023@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan  5 04:03:06 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 Jan 2017 09:03:06 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <1483606986.67.0.885581141612.issue29023@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attached patch simplifies, improves, and syncs the main docs with the docstrings.

----------

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

From report at bugs.python.org  Fri Jan  6 04:58:44 2017
From: report at bugs.python.org (Jonathan Roach)
Date: Fri, 06 Jan 2017 09:58:44 +0000
Subject: [docs] [issue29175] Documentation for File objects missing
Message-ID: <1483696723.95.0.735667565924.issue29175@psf.upfronthosting.co.za>


New submission from Jonathan Roach:

The file documentation (as seen in python.org) went missing in 3.3. In 2.7.13 it can be found in 'The Python Standard Library' as section '5.9 File Objects', between '5.8 Mapping Types' and '5.10 memory view type'. In 3.3 and onwards this section is no longer present, and, as far as I can tell, is not present elsewhere in the documentation.
[related: in 'The Python Tutorial' section '7.2.1 Methods of File Objects' the inline references to the file object methods are shown as references, but without a target]

----------
assignee: docs at python
components: Documentation
messages: 284806
nosy: docs at python, eric.araujo, ezio.melotti, georg.brandl, jonroach at icloud.com
priority: normal
severity: normal
status: open
title: Documentation for File objects missing
type: behavior
versions: 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/issue29175>
_______________________________________

From report at bugs.python.org  Fri Jan  6 09:28:56 2017
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 06 Jan 2017 14:28:56 +0000
Subject: [docs] [issue29179] Py_UNUSED is not documented
Message-ID: <1483712936.43.0.521596791461.issue29179@psf.upfronthosting.co.za>


New submission from Petr Viktorin:

The Py_UNUSED macro, which was added in Python 3.4, is not documented.
Is this an omission, or is it undocumented on purpose?
I can prepare a patch if it's the former.


The macro was added in: http://bugs.python.org/issue19976
and referenced in: http://bugs.python.org/issue26179
Usage on Github: https://github.com/search?q=py_unused&type=Code

----------
assignee: docs at python
components: Documentation
messages: 284821
nosy: docs at python, encukou
priority: normal
severity: normal
status: open
title: Py_UNUSED is not documented
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Jan  6 10:33:15 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 Jan 2017 15:33:15 +0000
Subject: [docs] [issue29175] Tutorial links to file object methods are
 broken.
In-Reply-To: <1483696723.95.0.735667565924.issue29175@psf.upfronthosting.co.za>
Message-ID: <1483716795.41.0.96556643183.issue29175@psf.upfronthosting.co.za>


R. David Murray added the comment:

The tutorial links are definitely bugs, and the section may need some tweaking.  The 'file object' documentation is replaced by the io module, which completely defines the file object API.  There is a link from the 'file object' glossary entry to the IO module indicating this.

Only 3.6 and 3.7 docs get documentation updates at this point, so I've removed the others from versions (we use versions to say where things will get fixed).  (Well, 3.5 docs can still get updates at the moment, but that won't last long, final is soon.)

----------
nosy: +r.david.murray
title: Documentation for File objects missing -> Tutorial links to file object methods are broken.
versions:  -Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jan  6 15:47:31 2017
From: report at bugs.python.org (Jonathan Roach)
Date: Fri, 06 Jan 2017 20:47:31 +0000
Subject: [docs] [issue29175] Tutorial links to file object methods are
 broken.
In-Reply-To: <1483696723.95.0.735667565924.issue29175@psf.upfronthosting.co.za>
Message-ID: <1483735651.49.0.411905360251.issue29175@psf.upfronthosting.co.za>


Jonathan Roach added the comment:

OK, I understand that the older versions aren't going to be revised - that makes sense.

I think part of the reason I submitted this is the reader's path from the open() documentation to the most relevant part of the io documentation (the interface) is long and narrow: open()->file object(in the Glossary)->io(see note)..and then scroll several pages down.
Note: the link to io from the 'file object' glossary entry is visually tiny, and in last paragraph - effectively making it almost invisible. This also seems to be the only place in the chain of links from open() which gets you to the io documentation.
When trying to find the interface documentation I tried the visually bigger, earlier links and ended up like I was being given the run-around through the various glossary entries.
As a documentation user I'd ideally like a direct link (which is a bit visually bigger than 'io') from open() to the relevant, interface section of the io documentation. However, upstanding you have a better feel for the tone of the documentation, I can see you might take a different route.

----------

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

From report at bugs.python.org  Fri Jan  6 19:13:53 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jan 2017 00:13:53 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <20170107001341.27780.99181.CAD1F858@psf.io>


Roundup Robot added the comment:

New changeset 7d6ebd206cd6 by Raymond Hettinger in branch '2.7':
Issue #29023:  Clarify that ints and longs are always deterministic seeds for random.
https://hg.python.org/cpython/rev/7d6ebd206cd6

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

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

From report at bugs.python.org  Fri Jan  6 19:14:13 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jan 2017 00:14:13 +0000
Subject: [docs] [issue29023] Results of random.seed() call with integer
 argument should be claimed deterministic.
In-Reply-To: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>
Message-ID: <1483748053.15.0.13516509703.issue29023@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan  6 19:35:17 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jan 2017 00:35:17 +0000
Subject: [docs] [issue29179] Py_UNUSED is not documented
In-Reply-To: <1483712936.43.0.521596791461.issue29179@psf.upfronthosting.co.za>
Message-ID: <1483749318.0.0.875388700463.issue29179@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  7 00:49:55 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Jan 2017 05:49:55 +0000
Subject: [docs] [issue29189] Broken indentation in FancyURLopener
 documentation
Message-ID: <1483768195.47.0.481112354487.issue29189@psf.upfronthosting.co.za>


New submission from Berker Peksag:

I noticed this while taking a look at urllib docs for issue 29182. Indentation of prompt_user_passwd() is broken and it looks like it's part of the note directive: https://docs.python.org/2/library/urllib.html#urllib.FancyURLopener.prompt_user_passwd

Python 3 version renders fine: https://docs.python.org/3/library/urllib.request.html#urllib.request.FancyURLopener.prompt_user_passwd

Here is a patch.

----------
assignee: docs at python
components: Documentation
files: docfix.diff
keywords: patch
messages: 284888
nosy: berker.peksag, docs at python, orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: Broken indentation in FancyURLopener documentation
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file46183/docfix.diff

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

From report at bugs.python.org  Sat Jan  7 00:53:46 2017
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 07 Jan 2017 05:53:46 +0000
Subject: [docs] [issue29189] Broken indentation in FancyURLopener
 documentation
In-Reply-To: <1483768195.47.0.481112354487.issue29189@psf.upfronthosting.co.za>
Message-ID: <1483768426.87.0.446168583265.issue29189@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

The patch looks good to me, and can committed. Thanks!

----------

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

From report at bugs.python.org  Sat Jan  7 01:14:31 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jan 2017 06:14:31 +0000
Subject: [docs] [issue29189] Broken indentation in FancyURLopener
 documentation
In-Reply-To: <1483768195.47.0.481112354487.issue29189@psf.upfronthosting.co.za>
Message-ID: <20170107061408.27780.64086.ACDB4519@psf.io>


Roundup Robot added the comment:

New changeset 31172ecb9e40 by Berker Peksag in branch '2.7':
Issue #29189: Fix broken indentation in FancyURLopener documentation
https://hg.python.org/cpython/rev/31172ecb9e40

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

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

From report at bugs.python.org  Sat Jan  7 01:15:01 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Jan 2017 06:15:01 +0000
Subject: [docs] [issue29189] Broken indentation in FancyURLopener
 documentation
In-Reply-To: <1483768195.47.0.481112354487.issue29189@psf.upfronthosting.co.za>
Message-ID: <1483769701.69.0.570265498553.issue29189@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the review, Senthil.

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

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

From report at bugs.python.org  Sat Jan  7 01:31:33 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Jan 2017 06:31:33 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <1483770693.28.0.869797838811.issue16026@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patches James and Greg!

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

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

From report at bugs.python.org  Sat Jan  7 01:32:23 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 Jan 2017 06:32:23 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <20170107063035.26952.99555.6F543B6B@psf.io>


Roundup Robot added the comment:

New changeset 198edd926751 by Berker Peksag in branch '3.6':
Issue #16026: Fix parameter names of DictReader and DictWriter
https://hg.python.org/cpython/rev/198edd926751

New changeset 63c5531cfdf7 by Berker Peksag in branch 'default':
Issue #16026: Merge from 3.6
https://hg.python.org/cpython/rev/63c5531cfdf7

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

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

From report at bugs.python.org  Sat Jan  7 01:49:43 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 Jan 2017 06:49:43 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483771783.19.0.436198408517.issue29133@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I'd probably write it without the for loop:

    text = "a && b; c && d || e; f >'abc'; (def \"ghi\")"

    result = shlex.shlex(text)
    print(f"Old behavior: {list(result)}")

    result = shlex.shlex(text, punctuation_chars=True)
    print(f"New behavior: {list(result)}")

Or just:

    >>> import shlex
    >>> text = "a && b; c && d || e; f >'abc'; (def \"ghi\")"
    >>> list(shlex.shlex(text))
    ['a', '&', '&', 'b', ';', 'c', '&', '&', 'd', '|', '|', 'e', ';', 'f', '>', "'abc'", ';', '(', 'def', '"ghi"', ')']
    >>> list(shlex.shlex(text, punctuation_chars=True))
    ['a', '&&', 'b', ';', 'c', '&&', 'd', '||', 'e', ';', 'f', '>', "'abc'", ';', '(', 'def', '"ghi"', ')']

(Adding Vinay to nosy list to get his feedback since he wrote the original example.)

----------
nosy: +berker.peksag, vinay.sajip
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sat Jan  7 06:31:27 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 07 Jan 2017 11:31:27 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483788687.11.0.948047863374.issue29133@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'm fine with removing the loop, as there are only ever going to be the two cases - so Berker's suggestion would seem to cover both doctest and unittest cases.

----------

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

From report at bugs.python.org  Sat Jan  7 17:00:24 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 Jan 2017 22:00:24 +0000
Subject: [docs] [issue29002] typing.AnyStr doc is unclear about python2
 unicode support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1483826424.12.0.441569386406.issue29002@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I agree that it would just be confusing if the Python 3 docs were to explain Python 2 specific things.  Maybe this should be explained in the mypy docs (or maybe it's really a mypy bug).  Can you open an issue there?

----------
nosy: +gvanrossum
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Jan  8 01:09:09 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 Jan 2017 06:09:09 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlOTE4Ml0gZG9jdW1lbnQg4oCcLS3igJ0gYXMgYSB3?=
 =?utf-8?q?ay_to_distinguish_option_w/_narg=3D=27+=27_from_positional_argu?=
 =?utf-8?q?ment_in_argparse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1483855749.23.0.817254418316.issue9182@psf.upfronthosting.co.za>


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


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

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

From limanetocc at gmail.com  Wed Jan  4 09:12:07 2017
From: limanetocc at gmail.com (lima neto)
Date: Wed, 4 Jan 2017 11:12:07 -0300
Subject: [docs] Documentation error
Message-ID: <CALmuh3UUdOrz5EnrEiNzY+T5yRiMvPmTNjK7-qSw50xh+Li5Fw@mail.gmail.com>

I think I've found a typo in your documentation, here it follows the print,
I think the error is located in the part where you say:

"This method will return normally if the mail is accepted for at least one
recipient. Otherwise it will raise an exception. That is, if this method
does not raise an exception, then someone should get your mail. If this
method does not raise an exception, it returns a dictionary, with one entry
for each recipient that was refused. Each entry contains a tuple of the
SMTP error code and the accompanying error message sent by the server."

was it not suppose to say:

"This method will return normally if the mail is accepted for at least one
recipient. Otherwise it will raise an exception. That is, if this method
does not raise an exception, then someone should get your mail. If this
method DOES raise an exception, it returns a dictionary, with one entry for
each recipient that was refused. Each entry contains a tuple of the SMTP
error code and the accompanying error message sent by the server.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170104/e737ab03/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Captura de Tela 2017-01-04 a?s 11.09.37.png
Type: image/png
Size: 192292 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20170104/e737ab03/attachment-0001.png>

From nani345 at gmail.com  Fri Jan  6 14:21:03 2017
From: nani345 at gmail.com (Dhananjay Naniwadekar)
Date: Fri, 6 Jan 2017 11:21:03 -0800
Subject: [docs] A badly documented page
Message-ID: <CA+CYXsL4L-NQ+jeKdFa=1Xb351yQ60kMJfhaPgZYoJOVBkkA+Q@mail.gmail.com>

Refer, please : https://docs.python.org/2/howto/argparse.html
    Search for the first instance of : args.square
When you want to show that : Square of 5 is 25, calling the number '5'
args.square is very counterintuitive. If you call it args.base_number, it
does not at once tell whether the square or cube or root of the base is
being calcaulated. Calling it args.num_to_be_squared is too long. But
calling it args.square is so confusing.

print  args.num**2    ## print the square of the number
   reads better, and is not confusing.

- dn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170106/355e0d5c/attachment.html>

From report at bugs.python.org  Mon Jan  9 06:19:05 2017
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 09 Jan 2017 11:19:05 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <1483960745.59.0.662363618907.issue29133@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is a 3rd patch with the Berker's suggestion. I just limited the output to 79 characters per line, and made use of the +NORMALIZE_WHITESPACE option  (to normalize the newline inside the output).

----------
Added file: http://bugs.python.org/file46225/issue29133_3rd.patch

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

From report at bugs.python.org  Mon Jan  9 11:48:44 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jan 2017 16:48:44 +0000
Subject: [docs] [issue29133] Minor inaccuracy in shlex.shlex
 punctuation_chars example
In-Reply-To: <1483362012.78.0.704413629859.issue29133@psf.upfronthosting.co.za>
Message-ID: <20170109164838.93968.59336.1FF98EC5@psf.io>


Roundup Robot added the comment:

New changeset af5b34b2d169 by Vinay Sajip in branch '3.6':
Fixes #29133: clarified shlex documentation.
https://hg.python.org/cpython/rev/af5b34b2d169

New changeset e3d820c0c884 by Vinay Sajip in branch 'default':
Closes #29133: merged update from 3.6.
https://hg.python.org/cpython/rev/e3d820c0c884

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

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

From report at bugs.python.org  Mon Jan  9 17:43:26 2017
From: report at bugs.python.org (David Muller)
Date: Mon, 09 Jan 2017 22:43:26 +0000
Subject: [docs] [issue29217] Documentation for uuid has wrong description
 for variant
Message-ID: <1484001806.43.0.207679570942.issue29217@psf.upfronthosting.co.za>


New submission from David Muller:

The documentation's description for uuid.variant says that its value is one of several integer constants, but those constants are actually strings.

----------
assignee: docs at python
components: Documentation
messages: 285079
nosy: TigerhawkT3, docs at python
priority: normal
severity: normal
status: open
title: Documentation for uuid has wrong description for variant
type: behavior
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/issue29217>
_______________________________________

From report at bugs.python.org  Mon Jan  9 19:52:33 2017
From: report at bugs.python.org (paul j3)
Date: Tue, 10 Jan 2017 00:52:33 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlOTE4Ml0gZG9jdW1lbnQg4oCcLS3igJ0gYXMgYSB3?=
 =?utf-8?q?ay_to_distinguish_option_w/_narg=3D=27+=27_from_positional_argu?=
 =?utf-8?q?ment_in_argparse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1484009553.7.0.00291409192098.issue9182@psf.upfronthosting.co.za>


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


----------
nosy: +paul.j3

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

From report at bugs.python.org  Mon Jan  9 22:32:55 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 Jan 2017 03:32:55 +0000
Subject: [docs] [issue29217] Documentation for uuid has wrong description
 for variant
In-Reply-To: <1484001806.43.0.207679570942.issue29217@psf.upfronthosting.co.za>
Message-ID: <20170110033252.103882.65874.E7B4A085@psf.io>


Roundup Robot added the comment:

New changeset 0d4e0a736688 by Xiang Zhang in branch '2.7':
Issue #29217: Fix the wrong type description of UUID.variant.
https://hg.python.org/cpython/rev/0d4e0a736688

New changeset 1f8e8e16e996 by Xiang Zhang in branch '3.5':
Issue #29217: Fix the wrong type description of UUID.variant.
https://hg.python.org/cpython/rev/1f8e8e16e996

New changeset aabb9360ff93 by Xiang Zhang in branch '3.6':
Issue #29217: Merge 3.5.
https://hg.python.org/cpython/rev/aabb9360ff93

New changeset a30cdf366c02 by Xiang Zhang in branch 'default':
Issue #29217: Merge 3.6.
https://hg.python.org/cpython/rev/a30cdf366c02

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

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

From report at bugs.python.org  Mon Jan  9 22:34:28 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 Jan 2017 03:34:28 +0000
Subject: [docs] [issue29217] Documentation for uuid has wrong description
 for variant
In-Reply-To: <1484001806.43.0.207679570942.issue29217@psf.upfronthosting.co.za>
Message-ID: <1484019268.31.0.46780657659.issue29217@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your report David. :-) I simply remove the type description since I think the type of the constants doesn't matter here.

----------
nosy: +xiang.zhang
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 10 03:48:40 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 Jan 2017 08:48:40 +0000
Subject: [docs] [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <1484038120.3.0.225079902091.issue15657@psf.upfronthosting.co.za>


Martin Panter added the comment:

.
The documentation did not get merged properly into 3.6+. And even in 3.5, under METH_KEYWORDS, I propose to change ?The flag is typically combined with METH_VARARGS? to ?The flag must be combined . . .?.

The remaining issue15657_36.diff patch looks out of date. There is a _PyCFunction_FastCallDict() function that appears to also need adjusting.

But instead of changing the value of METH_KEYWORDS, wouldn?t it be safer to just accept METH_KEYWORDS (= 2) on its own as a valid value? This is what Python 2 does. Essentially, revert the first hunk of

https://hg.python.org/cpython/diff/b7bfa780a882/Objects/methodobject.c

but without METH_OLDARGS, whose value was zero anyway.

BTW, the statement did not need to be removed in Python 2, but IMO it?s fine now without the statment. The statement was added in revision 1564c6839e6b.

----------
nosy: +martin.panter
versions: +Python 3.7

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

From report at bugs.python.org  Tue Jan 10 20:17:40 2017
From: report at bugs.python.org (Maciej Piechorka)
Date: Wed, 11 Jan 2017 01:17:40 +0000
Subject: [docs] [issue29236] 'an ASCII string of one or more PEM-encoded
 certificates' needs to be unicode
Message-ID: <1484097460.25.0.906949156541.issue29236@psf.upfronthosting.co.za>


New submission from Maciej Piechorka:

In documentation it is specified that cadata parameter in load_verify_locations is 'an ASCII string of one or more PEM-encoded certificates'. However the code is actually determining it based on PyUnicode_Check function so the 'ASCII string' actually needs to be unicode object. In Python 3 it seems to be fixed by checking by PyObject_GetBuffer.

----------
assignee: docs at python
components: Documentation, SSL
messages: 285176
nosy: docs at python, uzytkownik
priority: normal
severity: normal
status: open
title: 'an ASCII string of one or more PEM-encoded certificates' needs to be unicode
versions: Python 2.7

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

From report at bugs.python.org  Wed Jan 11 05:28:19 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Wed, 11 Jan 2017 10:28:19 +0000
Subject: [docs] [issue29239] Fix wrong issue number in what's new entry
Message-ID: <1484130499.73.0.330808807544.issue29239@psf.upfronthosting.co.za>


Changes by Jim Fasarakis-Hilliard <d.f.hilliard at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: fix_issue.patch
keywords: patch
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: Fix wrong issue number in what's new entry
versions: Python 3.6
Added file: http://bugs.python.org/file46256/fix_issue.patch

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

From report at bugs.python.org  Wed Jan 11 07:16:00 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jan 2017 12:16:00 +0000
Subject: [docs] [issue29239] Fix wrong issue number in what's new entry
Message-ID: <20170111121424.1300.47311.61AECB9E@psf.io>


New submission from Roundup Robot:

New changeset 114b03fa4c04 by Martin Panter in branch '3.6':
Issue #29239: Fix --enable-optimizations bug number
https://hg.python.org/cpython/rev/114b03fa4c04

New changeset 4e29c7f2b3e5 by Martin Panter in branch 'default':
Issue #29239: Merge bug number from 3.6
https://hg.python.org/cpython/rev/4e29c7f2b3e5

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

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

From report at bugs.python.org  Wed Jan 11 07:16:01 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 Jan 2017 12:16:01 +0000
Subject: [docs] [issue15657] Error in Python 3 docs for PyMethodDef
In-Reply-To: <1344970966.7.0.115664419243.issue15657@psf.upfronthosting.co.za>
Message-ID: <20170111121424.1300.61365.6050961A@psf.io>


Roundup Robot added the comment:

New changeset d7d2d24003f5 by Martin Panter in branch '3.5':
Issue #15657: METH_KEYWORDS cannot be used alone in Python 3
https://hg.python.org/cpython/rev/d7d2d24003f5

New changeset c140e72492a4 by Martin Panter in branch '3.6':
Issue #15657: Delete incorrect statement from PyMethodDef documentation
https://hg.python.org/cpython/rev/c140e72492a4

New changeset 021fd2ff7ca4 by Martin Panter in branch '3.6':
Issue #15657: Merge other doc fix from 3.5
https://hg.python.org/cpython/rev/021fd2ff7ca4

New changeset 1058e151049a by Martin Panter in branch 'default':
Issue #15657: Merge METH_KEYWORDS doc from 3.6
https://hg.python.org/cpython/rev/1058e151049a

----------

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

From report at bugs.python.org  Wed Jan 11 07:23:46 2017
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 Jan 2017 12:23:46 +0000
Subject: [docs] [issue29239] Fix wrong issue number in what's new entry
In-Reply-To: <20170111121424.1300.47311.61AECB9E@psf.io>
Message-ID: <1484137426.87.0.118289891904.issue29239@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Jim

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Wed Jan 11 16:17:04 2017
From: report at bugs.python.org (Greg Bengeult)
Date: Wed, 11 Jan 2017 21:17:04 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1484169424.21.0.0184029686476.issue11681@psf.upfronthosting.co.za>


Greg Bengeult added the comment:

I have attached a patch for 2.7 that adds -b and -bb to the command line documentation in Modules/main.c and Doc/library/cmdline.rst, following the suggested text provided by Martin.

Interestingly, unicode(), bytearray(), and str() don't seem to be transitive in 2.7.

>>> u"3" == str(3)
True

>>> str(3) == bytearray("3")
True

>>> u"3" == bytearray("3")
False

----------
nosy: +gbengeult
Added file: http://bugs.python.org/file46261/b_option.patch

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

From report at bugs.python.org  Wed Jan 11 22:06:54 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Jan 2017 03:06:54 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1484190413.78.0.255991674941.issue11681@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, the lack of transitivity comes from the fact that:

    >>> u"3" == str(3)
    True

Is really shorthand for:

    >>> u"3" == str(3).decode("ascii")
    True

However, the implicit decoding only triggers for *exactly* bytes instances, so in the bytearray case it needs to be explicit:

    >>> u"3" == bytearray(b"3").decode("ascii")
    True

----------

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

From report at bugs.python.org  Wed Jan 11 22:26:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 Jan 2017 03:26:37 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1484191597.92.0.889246117789.issue11681@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Added some review comments on the patch. The only critical one was changing a :class:`bytes` reference to :class:`unicode`, but I also suggested it may be worth mentioning that it *doesn't* enable warnings about all binary/text comparisons the way the Python 3 one does.

----------

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

From report at bugs.python.org  Wed Jan 11 23:23:54 2017
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 12 Jan 2017 04:23:54 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
Message-ID: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>


New submission from Nathaniel Smith:

The documentation for select.epoll.poll doesn't document the return value at all, which is somewhat important information :-)

I think it's a list of (fd, eventmask) tuples?

https://docs.python.org/3.7/library/select.html#select.epoll.poll

----------
assignee: docs at python
components: Documentation
messages: 285285
nosy: docs at python, njs
priority: normal
severity: normal
status: open
title: Document return value of epoll.poll
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From keith.briggs at bt.com  Tue Jan 10 07:10:56 2017
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Tue, 10 Jan 2017 12:10:56 +0000
Subject: [docs] spelling error at
 https://docs.python.org/3/library/bisect.html#module-bisect
Message-ID: <e2d6c868e5904a8192aba93fcfcc234a@rew09926dag05a.domain1.systemhost.net>

"straight-forward" should be "straightforward".


Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170110/3e2bc7d5/attachment.html>

From ncoghlan at gmail.com  Wed Jan 11 22:24:40 2017
From: ncoghlan at gmail.com (ncoghlan at gmail.com)
Date: Thu, 12 Jan 2017 03:24:40 -0000
Subject: [docs] -b option undocumented (issue 11681)
Message-ID: <20170112032440.3772.92752@psf.upfronthosting.co.za>


http://bugs.python.org/review/11681/diff/19720/Doc/using/cmdline.rst
File Doc/using/cmdline.rst (right):

http://bugs.python.org/review/11681/diff/19720/Doc/using/cmdline.rst#newcode196
Doc/using/cmdline.rst:196: Issue a warning when comparing :class:`bytes`
with :class:`bytearray`.
For 2.x, :class:`unicode` is the relevant cross-reference here.

It may also be worth adding a second paragraph explicitly mentioning the
difference from the Python 3 flag:

====
Note that, unlike the corresponding Python 3.x flag, this will NOT emit
warnings for comparisons between :class:`str` and :class:`unicode`.
Instead, the ``str`` instance will be implicitly decoded to ``unicode``
and Unicode comparison used.
====

http://bugs.python.org/review/11681/diff/19720/Doc/using/cmdline.rst#newcode199
Doc/using/cmdline.rst:199: .. versionchanged:: 3.5
3.x versionchanged notes are left out of the 2.x docs

However, this should have a "versionadded" note for 2.6 (since it was
added as part of a merge back from the Py3k branch).

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

From report at bugs.python.org  Thu Jan 12 06:32:45 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 Jan 2017 11:32:45 +0000
Subject: [docs] [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1484220765.76.0.501247866149.issue29249@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

** is supported not just as a prefix. Path('./Lib').glob('**/*.py') emits the same paths as Path('.').glob('Lib/**/*.py'). But ** is supported only in glob(), not in match(). The support of ** in match() is not documented. Would be worth to document explicitly that it is not supported.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, serhiy.storchaka
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Jan 12 07:04:20 2017
From: report at bugs.python.org (Martin Panter)
Date: Thu, 12 Jan 2017 12:04:20 +0000
Subject: [docs] [issue29251] Class __dict__ is only a mapping proxy
Message-ID: <1484222660.7.0.65822313324.issue29251@psf.upfronthosting.co.za>


New submission from Martin Panter:

The __dict__ attribute of class objects is documented as being a (standard) dictionary, but implemented with a proxy object. I propose to clarify the documentation in ?Custom classes? under <https://docs.python.org/3.5/reference/datamodel.html#the-standard-type-hierarchy>, and in <https://docs.python.org/3.5/library/functions.html#type>.

I believe my changes are also applicable to Python 2, as long as I point out the proxy is specific to ?new-style? classes.

----------
assignee: docs at python
components: Documentation
files: class-dict.patch
keywords: patch
messages: 285313
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Class __dict__ is only a mapping proxy
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46268/class-dict.patch

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

From report at bugs.python.org  Thu Jan 12 08:23:31 2017
From: report at bugs.python.org (Jon Walsh)
Date: Thu, 12 Jan 2017 13:23:31 +0000
Subject: [docs] [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1484227411.74.0.773110730581.issue29249@psf.upfronthosting.co.za>


Jon Walsh added the comment:

Seems a bit strange to not have glob() and match() working the same though. Is there any reason for that?

----------

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

From report at bugs.python.org  Thu Jan 12 11:42:13 2017
From: report at bugs.python.org (Suraj Kumar)
Date: Thu, 12 Jan 2017 16:42:13 +0000
Subject: [docs] [issue29254] Documentation Error
Message-ID: <1484239333.41.0.299474192201.issue29254@psf.upfronthosting.co.za>


New submission from Suraj Kumar:

Hi,

I have found one documentation mistake in section 3.1.2. Strings saying
"""Note how the start is always included, and the end always excluded. This makes sure that s[:i] + s[i:] is always equal to s:
>>>word = 'Python'
>>> word[:2] + word[2:]
'Python'
"""

I think instead of 'the end always excluded' it should be 'the end always included'.

If my observation is correct, please do the needful change.

Thanks & Regards,
Suraj

----------
assignee: docs at python
components: Documentation
messages: 285331
nosy: Suraj Kumar, docs at python
priority: normal
severity: normal
status: open
title: Documentation Error
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Jan 12 12:04:49 2017
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 12 Jan 2017 17:04:49 +0000
Subject: [docs] [issue29254] Documentation Error
In-Reply-To: <1484239333.41.0.299474192201.issue29254@psf.upfronthosting.co.za>
Message-ID: <1484240689.25.0.8791147234.issue29254@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Given `slice[start:end]`:

What this line is trying to say is that the slice index is inclusive for the start parameter and exclusive for the end parameter.

In mathematical/interval notation this would look like [start, end)

As a quick example look at the word "Python"
Index  012345
Letter Python

If you do word[:2], the result is 'Py', notice how the t is excluded.

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

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

From report at bugs.python.org  Thu Jan 12 12:13:54 2017
From: report at bugs.python.org (Greg Bengeult)
Date: Thu, 12 Jan 2017 17:13:54 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1484241234.52.0.285488378364.issue11681@psf.upfronthosting.co.za>


Greg Bengeult added the comment:

Thanks for the :class: markup edits. I'm still learning this stuff.

----------

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

From report at bugs.python.org  Thu Jan 12 12:56:27 2017
From: report at bugs.python.org (Greg Bengeult)
Date: Thu, 12 Jan 2017 17:56:27 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <1484243787.89.0.287957486674.issue28130@psf.upfronthosting.co.za>


Greg Bengeult added the comment:

How about this documentation patch for tzset()? Most of the verbiage comes from the Linux tzset() man page. I can also generate a similar patch for 2.7 if it's needed.

----------
nosy: +gbengeult
versions: +Python 3.7
Added file: http://bugs.python.org/file46275/tzset_rst.patch

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

From report at bugs.python.org  Thu Jan 12 13:24:41 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 12 Jan 2017 18:24:41 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <1484245480.97.0.192208541081.issue28130@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Committed in ec3b08b361c0.  Thanks, Greg.

Leaving open until 2.7 docs are fixed as well.

----------
resolution:  -> fixed
stage:  -> resolved
versions: +Python 2.7 -Python 3.6

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

From report at bugs.python.org  Thu Jan 12 13:27:29 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Jan 2017 18:27:29 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <20170112182725.96191.57437.A022A36E@psf.io>


Roundup Robot added the comment:

New changeset ec3b08b361c0 by Alexander Belopolsky in branch 'default':
Closes #28130: Documented that time.tzset() updates time module globals.
https://hg.python.org/cpython/rev/ec3b08b361c0

----------
nosy: +python-dev
status: open -> closed

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

From report at bugs.python.org  Thu Jan 12 13:33:01 2017
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 12 Jan 2017 18:33:01 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <1484245981.64.0.172965913979.issue28130@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <alexander.belopolsky at gmail.com>:


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

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

From report at bugs.python.org  Thu Jan 12 14:38:55 2017
From: report at bugs.python.org (Greg Bengeult)
Date: Thu, 12 Jan 2017 19:38:55 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <1484249935.22.0.406829764042.issue28130@psf.upfronthosting.co.za>


Greg Bengeult added the comment:

Here's the 2.7 patch.

----------
Added file: http://bugs.python.org/file46276/tzset_rst_27.patch

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

From report at bugs.python.org  Thu Jan 12 15:06:45 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 Jan 2017 20:06:45 +0000
Subject: [docs] [issue28130] Document that time.tzset updates time module
 globals
In-Reply-To: <1473782506.71.0.242774514927.issue28130@psf.upfronthosting.co.za>
Message-ID: <20170112200642.96977.65371.E7147C6E@psf.io>


Roundup Robot added the comment:

New changeset 8578757cc3a6 by Alexander Belopolsky in branch '2.7':
Closes #28130: Documented that time.tzset() updates time module globals.
https://hg.python.org/cpython/rev/8578757cc3a6

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

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

From report at bugs.python.org  Thu Jan 12 19:48:36 2017
From: report at bugs.python.org (Gerald Britton)
Date: Fri, 13 Jan 2017 00:48:36 +0000
Subject: [docs] [issue29257] Possible error in discussion of Abstract Base
 Classes and abstract properties
Message-ID: <1484268516.3.0.750896526181.issue29257@psf.upfronthosting.co.za>


New submission from Gerald Britton:

I was rereading the 2.7 docs  about abstract base classes the other day.  I found this:

"This defines a read-only property; you can also define a read-write abstract property using the ?long? form of property declaration:"

along with an example.  so I copied the example and put in a little surrounding code:


from abc import ABCMeta, abstractproperty

class C:
    __metaclass__ = ABCMeta
    def getx(self): pass
    def setx(self, value): pass
    x = abstractproperty(getx, setx)
 
class D(C):
    @property
    def x(self):self._x
 
d = D()    
print(d)   

When I ran this, I expected an exception, since I defined a read/write abstract property but only implemented the read operation.  However, the example runs fine. That is the class D can be instantiated without error.  Of course I cannot set the property since I didn't implement that part.

Now, If I don't implement the property at all, I can' instantiate the class.  I get:

"TypeError: Can't instantiate abstract class D with abstract methods x"

which is what I would expect.  What I don't understand is why I don't get a similar error when I implement the read operation for the property but not the write operation.

If this actually doesn't work (catching the non-implementation at instantiation time), then why is it documented this way?  To me at least the doc implies that it *will* raise on the missing write property implementation.

If ABCs are working as intended, can the documentation be changed to reflect that as per my experience above?  If the documentation is correct, can the ABC implementation be modified to function that way?

----------
assignee: docs at python
components: Documentation
messages: 285356
nosy: docs at python, gbritton
priority: normal
severity: normal
status: open
title: Possible error in discussion of Abstract Base Classes and abstract properties
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 12 20:26:58 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 13 Jan 2017 01:26:58 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484270817.68.0.532574592541.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

@christian.heimes Would you look merge-hashlib-blake2.patch?
This is blocker of our document translation project.

----------

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

From report at bugs.python.org  Thu Jan 12 21:41:34 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 13 Jan 2017 02:41:34 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484275294.7.0.266741937665.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Although I am +1 for merging it before but these days I find it's not the only case. There are also two unittest.mock entries. This is just FYI, no opinion on this issue.

----------

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

From report at bugs.python.org  Fri Jan 13 03:14:13 2017
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 13 Jan 2017 08:14:13 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484295253.21.0.529524309158.issue29062@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Go ahead if it makes your work easier. I kept the file separate because the blake2 documentation is maintained externally. It's not going to change any time soon, though. Let's merge it.

----------

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

From report at bugs.python.org  Fri Jan 13 05:31:28 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jan 2017 10:31:28 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20170113103125.56631.16719.36DA1B6E@psf.io>


Roundup Robot added the comment:

New changeset 799ed3122456 by INADA Naoki in branch '3.6':
Issue #29062: Merge hashlib-blake2.rst into hashlib.rst
https://hg.python.org/cpython/rev/799ed3122456

New changeset 380e63b7fc82 by INADA Naoki in branch 'default':
Issue #29062: Merge hashlib-blake2.rst into hashlib.rst
https://hg.python.org/cpython/rev/380e63b7fc82

----------

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

From report at bugs.python.org  Fri Jan 13 05:32:30 2017
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 13 Jan 2017 10:32:30 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484303550.8.0.772295482579.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Thanks.

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

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

From report at bugs.python.org  Fri Jan 13 13:17:54 2017
From: report at bugs.python.org (Lisa Roach)
Date: Fri, 13 Jan 2017 18:17:54 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1484331474.46.0.558237777572.issue28911@psf.upfronthosting.co.za>


Lisa Roach added the comment:

It took me a little while to wrap my brain around this, but you are definitely right that the documentation is not sufficient, your changes are an improvement. 

My wonder is, should we change the documentation or be looking at the code itself? I have always interpreted the method as asserting that only one call was made with the matching signature. If I want to test for call count I can just assert mock.call_count == 1.

The code could instead look like this: 

def assert_called_once_with(_mock_self, *args, **kwargs):
    self = _mock_self
    if not self.mock_calls.count(call(*args, **kwargs)) == 1:
        msg = ("Expected '%s' to be called once with %r %r. Called %s times."          % (self._mock_name or 'mock', args, kwargs, self.mock_calls.count(call(*args,  **kwargs))))
        raise AssertionError(msg)


Then again, if users have been using this to assert that the call_count is one (which is likely since it is in the examples documentation), this change would break backwards functionality.

Thoughts?

----------
nosy: +lisroach

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

From report at bugs.python.org  Sat Jan 14 01:54:13 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 Jan 2017 06:54:13 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484376853.11.0.439051021782.issue29062@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like Doc/tools/susp-ignored.csv needs updating:

$ make -C Doc/ suspicious
[. . .]
writing output... [ 49%] library/hashlib                                        
WARNING: [library/hashlib:502] ":vatrogasac" found in ">>> cookie = b'user:vatrogasac'"
WARNING: [library/hashlib:502] ":vatrogasac" found in "user:vatrogasac,349cf904533767ed2d755279a8df84d0"
WARNING: [library/hashlib:502] ":policajac" found in ">>> compare_digest(b'user:policajac', sig)"
WARNING: [library/hashlib:646] ":LEAF" found in "... h00 = blake2b(buf[0:LEAF_SIZE], fanout=FANOUT, depth=DEPTH,"
[. . .]
WARNING: Found 4/327 unused rules:
library/hashlib-blake2,,:vatrogasac,>>> cookie = b'user:vatrogasac'
library/hashlib-blake2,,:vatrogasac,user:vatrogasac,349cf904533767ed2d755279a8df84d0
library/hashlib-blake2,,:policajac,>>> compare_digest(b'user:policajac', sig)
library/hashlib-blake2,,:LEAF,h00 = blake2b(buf[0:LEAF_SIZE], fanout=FANOUT, depth=DEPTH,
build finished with problems, 7 warnings.
make[1]: *** [build] Error 1
make[1]: Leaving directory `/media/disk/home/proj/python/cpython/Doc'
Suspicious check complete; look for any errors in the above output or in build/suspicious/suspicious.csv.  If all issues are false positives, append that file to tools/susp-ignored.csv.
make: *** [suspicious] Error 1

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

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

From report at bugs.python.org  Sat Jan 14 02:30:59 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 Jan 2017 07:30:59 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
Message-ID: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>


New submission from Martin Panter:

The ?unittest? documentation has ?tests cases? written a few times. This doesn?t seem right to me, but I thought I should get a second opinion in case I missed something.

----------
assignee: docs at python
components: Documentation
files: tests-cases.patch
keywords: patch
messages: 285468
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Change ?tests cases? ? ?test cases?
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46288/tests-cases.patch

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

From report at bugs.python.org  Sat Jan 14 05:17:21 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jan 2017 10:17:21 +0000
Subject: [docs] [issue15527] Double parens in functions references
In-Reply-To: <1343833557.96.0.948912415493.issue15527@psf.upfronthosting.co.za>
Message-ID: <20170114101718.10896.68923.7AF5B961@psf.io>


Roundup Robot added the comment:

New changeset be4da80b493e by Martin Panter in branch '2.7':
Issue #15527: remove double parens by changing markup.
https://hg.python.org/cpython/rev/be4da80b493e

----------

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

From report at bugs.python.org  Sat Jan 14 07:05:06 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 14 Jan 2017 12:05:06 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20170114120503.3334.40121.48B34CC2@psf.io>


Roundup Robot added the comment:

New changeset ea0c488b9bac by INADA Naoki in branch '3.6':
Issue #29062: Doc: Fix make suspicious
https://hg.python.org/cpython/rev/ea0c488b9bac

New changeset 5c48fbe12cb8 by INADA Naoki in branch 'default':
Issue #29062: Doc: Fix make suspicious
https://hg.python.org/cpython/rev/5c48fbe12cb8

----------

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

From report at bugs.python.org  Sat Jan 14 07:06:30 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 14 Jan 2017 12:06:30 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484395590.83.0.435201163659.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Martin, thank you for pointing it out.
I hadn't know about suspicious check.

----------

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

From report at bugs.python.org  Sat Jan 14 08:28:44 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 Jan 2017 13:28:44 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
In-Reply-To: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>
Message-ID: <1484400524.83.0.900543751682.issue29274@psf.upfronthosting.co.za>


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


----------
nosy: +michael.foord

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

From report at bugs.python.org  Sat Jan 14 08:53:30 2017
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 14 Jan 2017 13:53:30 +0000
Subject: [docs] [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1484402010.23.0.295462642667.issue29062@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Sat Jan 14 10:46:18 2017
From: report at bugs.python.org (Elizabeth Myers)
Date: Sat, 14 Jan 2017 15:46:18 +0000
Subject: [docs] [issue29275] time module still has Y2K issues note
Message-ID: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>


New submission from Elizabeth Myers:

It's 2017. I think it's time to remove the Y2K warning from this: https://docs.python.org/3/library/time.html :P. It's 17 years past the sell-by date for that notice.

----------
assignee: docs at python
components: Documentation
messages: 285489
nosy: Elizacat, docs at python
priority: normal
severity: normal
status: open
title: time module still has Y2K issues note
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/issue29275>
_______________________________________

From report at bugs.python.org  Sat Jan 14 10:50:47 2017
From: report at bugs.python.org (Elizabeth Myers)
Date: Sat, 14 Jan 2017 15:50:47 +0000
Subject: [docs] [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1484409047.0.0.0210297807065.issue29275@psf.upfronthosting.co.za>


Changes by Elizabeth Myers <elizabeth at interlinked.me>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sat Jan 14 13:14:32 2017
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 Jan 2017 18:14:32 +0000
Subject: [docs] [issue29275] time module still has Y2K issues note
In-Reply-To: <1484408778.39.0.526783015881.issue29275@psf.upfronthosting.co.za>
Message-ID: <1484417672.36.0.0819679795931.issue29275@psf.upfronthosting.co.za>


SilentGhost added the comment:

The main message there is about the parsing of the two-digit year, so while it might worth it to remove the mention of Y2K, it would only be a minor change.

----------
nosy: +SilentGhost

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

From zdanevich.vitaly at ya.ru  Sat Jan 14 04:01:17 2017
From: zdanevich.vitaly at ya.ru (Vitaly Zdanevich)
Date: Sat, 14 Jan 2017 12:01:17 +0300
Subject: [docs] man
Message-ID: <487911484384477@web19h.yandex.ru>

Hi, thank you for documentation. I am about this page https://docs.python.org/3/download.html - is there any way to read all Python-documentation in man of info? Take a look at this page http://php.net/download-docs.php where mentioned man-like solution `pear install doc.php.net/pman` - maybe exists something like that for Python? not only pydoc, but all content that I can download from https://docs.python.org/3/download.html ?

From report at bugs.python.org  Sun Jan 15 11:53:39 2017
From: report at bugs.python.org (Kushal Das)
Date: Sun, 15 Jan 2017 16:53:39 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
In-Reply-To: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>
Message-ID: <1484499219.76.0.791632070141.issue29274@psf.upfronthosting.co.za>


Kushal Das added the comment:

The patch looks good to me.

----------
nosy: +kushal.das

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

From joncrawfurd at aol.com  Sun Jan 15 18:18:29 2017
From: joncrawfurd at aol.com (Jon Crawfurd)
Date: Sun, 15 Jan 2017 18:18:29 -0500
Subject: [docs] ipaddress Tutorial
Message-ID: <062101d26f85$aee98a00$0cbc9e00$@aol.com>

Python Team,

               I have an enhanced ipaddress tutorial that I like to offer
the Python community, but I'm not sure what to do with it.

               I'm a long time network engineer learning Python for personal
enrichment.  The ipaddress module tutorial information that I found online
is adequate, but I thought it could (and should) be enhanced, and decided to
give it a go.  The attached includes my enhanced documentation plus an IPv4
subnetting training program that I coded to take advantage of the ipaddress
module functions.

               Recommendations for a next step?

Cordially,

Jon Crawfurd

____________________________________________________________________________

"The ultimate measure of a man is not where he stands in moments of comfort
and 

 convenience, but where he stands at times of challenge and controversy."

Martin Luther King

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170115/7da636a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python ipaddress.zip
Type: application/x-zip-compressed
Size: 668709 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20170115/7da636a2/attachment-0001.bin>

From report at bugs.python.org  Mon Jan 16 04:20:00 2017
From: report at bugs.python.org (Alexey Popravka)
Date: Mon, 16 Jan 2017 09:20:00 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
Message-ID: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>


New submission from Alexey Popravka:

json.loads function was changed in Python 3.6 to accept
bytes and bytearrays, however documentation is missing
`versionchanged` block describing this changes.

----------
assignee: docs at python
components: Documentation
messages: 285545
nosy: Alexey Popravka, docs at python
priority: normal
severity: normal
status: open
title: json.loads documentation missing "versionchanged" statement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Jan 16 04:28:40 2017
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 Jan 2017 09:28:40 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
In-Reply-To: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>
Message-ID: <1484558920.27.0.462990243528.issue29274@psf.upfronthosting.co.za>


Michael Foord added the comment:

Yep, looks like an improvement to me!

----------

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

From report at bugs.python.org  Mon Jan 16 11:03:05 2017
From: report at bugs.python.org (Michael Foord)
Date: Mon, 16 Jan 2017 16:03:05 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1484582585.14.0.435969902795.issue28911@psf.upfronthosting.co.za>


Michael Foord added the comment:

I like the documentation improvement, thank you.

(The purpose of the method is to combine an assert about the arguments the method was called with and an assertion that it was only called once. To change the semantics would be both undesirable and backwards incompatible.)

----------

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

From report at bugs.python.org  Mon Jan 16 11:42:44 2017
From: report at bugs.python.org (John Taylor)
Date: Mon, 16 Jan 2017 16:42:44 +0000
Subject: [docs] [issue29284] Include thread_name_prefix in the
 concurrent.futures.ThreadPoolExecutor example 17.4.2.1
Message-ID: <1484584964.59.0.239435362381.issue29284@psf.upfronthosting.co.za>


New submission from John Taylor:

Please include how to use the thread_name_prefix method argument (new to Python 3.6) in the example: 17.4.2.1. ThreadPoolExecutor Example

----------
assignee: docs at python
components: Documentation
messages: 285572
nosy: docs at python, jftuga
priority: normal
severity: normal
status: open
title: Include thread_name_prefix  in the concurrent.futures.ThreadPoolExecutor example 17.4.2.1
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue Jan 17 03:04:31 2017
From: report at bugs.python.org (ipolcak)
Date: Tue, 17 Jan 2017 08:04:31 +0000
Subject: [docs] [issue29291] Misleading text in the documentation of re
 library for non-greedy match
Message-ID: <1484640271.49.0.239743289753.issue29291@psf.upfronthosting.co.za>


New submission from ipolcak:

The text about non-greedy match in the documentation for re library is misleading.

The docs for py2.7 (https://docs.python.org/2.7/library/re.html) and 3.6 (https://docs.python.org/3.6/library/re.html) says: "The '*', '+', and '?' qualifiers are all greedy; they match as much text as possible. Sometimes this behaviour isn?t desired; if the RE <.*> is matched against <a> b <c>, it will match the entire string, and not just <a>. Adding ? after the qualifier makes it perform the match in non-greedy or minimal fashion; as few characters as possible will be matched. Using the RE <.*?> will match only <a>."

The docs for py3.4 (https://docs.python.org/3.4/library/re.html) offers a little bit different example:
"The '*', '+', and '?' qualifiers are all greedy; they match as much text as possible. Sometimes this behaviour isn?t desired; if the RE <.*> is matched against '<H1>title</H1>', it will match the entire string, and not just '<H1>'. Adding '?' after the qualifier makes it perform the match in non-greedy or minimal fashion; as few characters as possible will be matched. Using .*? in the previous expression will match only '<H1>'."

However, in reality if the non-greedy match is not successful, it might fallback to the greedy match, see:

>>> import re
>>> a = re.compile(r"<.*?><span>")
>>> a.match("<a> b <c><span>")
<_sre.SRE_Match object; span=(0, 15), match='<a> b <c><span>'>
>>> a.search("<a> b <c><span>")
<_sre.SRE_Match object; span=(0, 15), match='<a> b <c><span>'>

So the '<.*?>' part of the regex matches '<a> b <c>' in this example. I propose to add to the documentation the following text:

"However, note that even the non-greedy version can match additional text, for example consider the RE '(<.*>)<d>' to be matched against '<a> b <c><d>'. The match is successful and the unnamed group contains '<a> b <c>'."

----------
assignee: docs at python
components: Documentation
messages: 285619
nosy: docs at python, ipolcak
priority: normal
severity: normal
status: open
title: Misleading text in the documentation of re library for non-greedy match
type: behavior
versions: Python 2.7, Python 3.4, Python 3.6

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

From report at bugs.python.org  Tue Jan 17 03:06:20 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 17 Jan 2017 08:06:20 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
Message-ID: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The signature of PyEval_EvalCodeEx now gets a "PyObject *kwdefs" parameter but the doc doesn't mention it.

----------
assignee: docs at python
components: Documentation
messages: 285620
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Missing a parameter in PyEval_EvalCodeEx doc
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Jan 17 03:27:40 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 17 Jan 2017 08:27:40 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484641660.13.0.812700548375.issue29292@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
keywords: +easy
stage:  -> needs patch

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

From report at bugs.python.org  Tue Jan 17 03:44:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 Jan 2017 08:44:38 +0000
Subject: [docs] [issue29291] Misleading text in the documentation of re
 library for non-greedy match
In-Reply-To: <1484640271.49.0.239743289753.issue29291@psf.upfronthosting.co.za>
Message-ID: <1484642678.25.0.58851498287.issue29291@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation doesn't look incorrect to me. The non-greedy match doesn't fallback to the greedy match, it always matches as few characters as *possible* will be matched. For example a.match("<a> b <c><span><d> e <f><span>") matches "<a> b <c><span>", not "<a> b <c><span><d> e <f><span>".

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

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

From report at bugs.python.org  Tue Jan 17 03:52:10 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 17 Jan 2017 08:52:10 +0000
Subject: [docs] [issue29291] Misleading text in the documentation of re
 library for non-greedy match
In-Reply-To: <1484640271.49.0.239743289753.issue29291@psf.upfronthosting.co.za>
Message-ID: <1484643130.44.0.926027573719.issue29291@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This doesn't look like a bug in the doc to me.

----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Tue Jan 17 04:11:37 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 17 Jan 2017 09:11:37 +0000
Subject: [docs] [issue29291] Misleading text in the documentation of re
 library for non-greedy match
In-Reply-To: <1484640271.49.0.239743289753.issue29291@psf.upfronthosting.co.za>
Message-ID: <1484644297.16.0.312385892757.issue29291@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I concur with Serhiy and Xiang that the docs are correct as-is.  Also IMO, the proposed rewording will cause more confusion than it cures.  Since this issue hasn't previously come up in the rather long life span of the re module, it suggests that most folks are getting the understanding they need from the existing docs.

I think it is the job for regex tutorials (rather than the main docs) to show when to use "<.*?><span>" versus "<[^>]*><span>".

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

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

From 1067511899 at qq.com  Tue Jan 17 03:47:20 2017
From: 1067511899 at qq.com (1067511899 at qq.com)
Date: Tue, 17 Jan 2017 16:47:20 +0800
Subject: [docs] python3.4 cookiejar can't get cookies
Message-ID: <2017011716471911643945@qq.com>

Hi?

    sorry for my poor English first,I am a Chinese.

    when access http://hd.chinatax.gov.cn/guoshui/main.jsp  the  firefox can get cookie and you can find it by devtools,but cookiejar can't.

    the full description is posted :https://www.reddit.com/r/learnpython/comments/5o9olm/about_cookiesheaderssomething_already_drive_me_mad/?st=iy16b0iq&sh=a5a7e960,A 

   and after I debug into the code,I find the problem :
   https://www.reddit.com/r/learnpython/comments/5ogqfi/a_bug_of_anaconda34or_may_be_a_bug_of_python34/ 

   python read headers from web server successfully.but when to parse it to class email.message.Message(policy=compat32),a problem happens.

   if the headers contains something like: Cache-Control : No-cache, I mean there is blank(one or more) beside the ':',the feedparser.py lines:227 will go wrong.

because lines:35_37:
# RFC 2822 $3.6.8 Optional fields.  ftext is %d33-57 / %d59-126, Any character
# except controls, SP, and ":".
headerRE = re.compile(r'^(From |[\041-\071\073-\176]*:|[\t ])')

I read RFC 2822 $3.6.8,and yes,the headerRE has no mistake,but as you can see,the headers can be created by programmer,and blank beside ':' do happen,so my suggestion is :
headerRE = re.compile(r'^(From |[\041-\071\073-\176]*\s*:\s*|[\t ])')

this may not strict fulfile the RFC,but it acts exactly like other web browser,such firefox,etc.

if meet some web site that not strict fulfile the RFC,no matter cookiejar or requests will not get the cookie right.but that not make sense,because web browser can.

btw:I changed my feedparser.py,because I need scraw web site in my work.

there are also another way to solve the problem,but I think that is really not pythonic.

import http.cookiejar, urllib.request

cj = http.cookiejar.CookieJar()
opener = urllib.request.build_opener(urllib.request.HTTPCookieProcessor(cj))

r = opener.open("http://hd.chinatax.gov.cn/guoshui/main.jsp")

pls=r.info().get_payload().split('\r\n')
cookiels=[]
for x in pls:
    if x.strip():
        tmp=x.split(':')
        if tmp[0]=='Set-Cookie':
            cookiels.append(tmp[1])
            print(tmp)
cookie='.'.join(cookiels)
print(cookie)


Thanks.

yours . Mengwei lee




1067511899 at qq.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170117/67cf57e2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 13.gif
Type: image/gif
Size: 1736 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20170117/67cf57e2/attachment-0001.gif>

From report at bugs.python.org  Tue Jan 17 11:22:34 2017
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 17 Jan 2017 16:22:34 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484670154.86.0.129286533174.issue29292@psf.upfronthosting.co.za>


Ammar Askar added the comment:

It looks like a basic description of kwdefs was added as part of this commit: https://github.com/python/cpython/commit/7811a5d1c93f2aa0b357444eeb3f1ddc242ac57a

"keywords and defaults," however, the kwdefs argument was never added to the prototype.

I've attached a patch which adds the argument to the prototype and clarifies the language a little bit.

----------
keywords: +patch
nosy: +ammar2
Added file: http://bugs.python.org/file46318/kwdefs_docs.diff

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

From report at bugs.python.org  Tue Jan 17 11:36:12 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 17 Jan 2017 16:36:12 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484670972.18.0.758022274816.issue29292@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> "keywords and defaults," however, the kwdefs argument was never added to the prototype.

I don't think this is about the missing "kwdefs". I think "arrays of arguments, keywords and defaults" is a whole part describing "PyObject **args, int argcount, PyObject **kws, int kwcount, PyObject **defs, int defcount". "kwdefs" is a dict containing the default values of keyword-only parameters in Py3? I am not sure.

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

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

From report at bugs.python.org  Wed Jan 18 07:30:13 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jan 2017 12:30:13 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
In-Reply-To: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>
Message-ID: <20170118123009.56146.58791.4C9BFF20@psf.io>


Roundup Robot added the comment:

New changeset f2fe00653d07 by Martin Panter in branch '3.5':
Issue #29274: tests cases ? test cases
https://hg.python.org/cpython/rev/f2fe00653d07

New changeset 145da99b3df2 by Martin Panter in branch '3.6':
Issue 29274: Merge doc fixes from 3.5
https://hg.python.org/cpython/rev/145da99b3df2

New changeset f093f88f8a5c by Martin Panter in branch 'default':
Issue 29274: Merge doc fixes from 3.6
https://hg.python.org/cpython/rev/f093f88f8a5c

New changeset 9b22d52a6d4b by Martin Panter in branch '2.7':
Issue #29274: tests cases ? test cases
https://hg.python.org/cpython/rev/9b22d52a6d4b

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

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

From jjlemire at gmail.com  Tue Jan 17 11:58:19 2017
From: jjlemire at gmail.com (JJ Lemire)
Date: Tue, 17 Jan 2017 11:58:19 -0500
Subject: [docs] Please update dowloadable documentation
Message-ID: <CAO3SRejce1pvxEucCqkt2J=5BNoy5Xduu3PvDX2k=qRXdm2wDg@mail.gmail.com>

Good morning,

the full documentation ONLINE says:

Welcome! This is the documentation for Python 3.6.0, last updated Jan 13,
2017.

the full documentation OFFline says (dowloadable documentation)
Welcome! This is the documentation for Python 3.6.0, last updated Jan 02,
2017.

Please update

Thanks -- Jacques
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170117/f82ac6d0/attachment.html>

From report at bugs.python.org  Wed Jan 18 11:57:41 2017
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 18 Jan 2017 16:57:41 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484758661.14.0.0434573151935.issue29292@psf.upfronthosting.co.za>


Ammar Askar added the comment:

You're completely right, the kwdefs is referring to default arguments for keyword-only-arguments from this PEP: https://www.python.org/dev/peps/pep-3102/

Where as that line is probably referring to "defs", the defaults for normal parameters.

I'll upload an amended patch.

----------

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

From report at bugs.python.org  Wed Jan 18 12:16:19 2017
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 18 Jan 2017 17:16:19 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484759779.15.0.753003823755.issue29292@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file46332/kwdefs_docs.diff2

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

From report at bugs.python.org  Wed Jan 18 15:21:15 2017
From: report at bugs.python.org (Mike Lissner)
Date: Wed, 18 Jan 2017 20:21:15 +0000
Subject: [docs] [issue29315] \b requires raw strings or to be escaped.
 Update docs with that hint?
Message-ID: <1484770875.58.0.864108991771.issue29315@psf.upfronthosting.co.za>


New submission from Mike Lissner:

I just ran into a funny corner case I imagine others are aware of. When you write "\b" in Python, it is a single character: "\x08". So if you try to write a regex like:

words = '\b(.*)\b'

That won't work. But using a raw string will:

words = r'\b(.*)\b'

As will escaping it in this horrible fashion:

words = '\\b(.*)\\b'

I believe this doesn't affect any of the other regex flags, so I wonder if it's worth adding something to the docs to warn about this. I just spent a bunch of time trying to figure out why it seemed like \b wasn't working. A little tip in the docs would have gone a LONG way.

----------
assignee: docs at python
components: Documentation
messages: 285751
nosy: Mike.Lissner, docs at python
priority: normal
severity: normal
status: open
title: \b requires raw strings or to be escaped. Update docs with that hint?
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/issue29315>
_______________________________________

From report at bugs.python.org  Wed Jan 18 15:40:26 2017
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 Jan 2017 20:40:26 +0000
Subject: [docs] =?utf-8?q?=5Bissue29274=5D_Change_=E2=80=9Ctests_cases?=
 =?utf-8?b?4oCdIOKGkiDigJx0ZXN0IGNhc2Vz4oCd?=
In-Reply-To: <1484379059.0.0.00296348115264.issue29274@psf.upfronthosting.co.za>
Message-ID: <1484772026.06.0.215235116988.issue29274@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the feedback

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

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

From report at bugs.python.org  Wed Jan 18 16:11:54 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Jan 2017 21:11:54 +0000
Subject: [docs] [issue29315] \b requires raw strings or to be escaped.
 Update docs with that hint?
In-Reply-To: <1484770875.58.0.864108991771.issue29315@psf.upfronthosting.co.za>
Message-ID: <1484773914.32.0.227732256789.issue29315@psf.upfronthosting.co.za>


R. David Murray added the comment:

One should always use raw strings for regex expressions, and this is already documented in the introduction to the regex module.  Further, in 3.5 using \ in front of characters that aren't special produces a warning, which should reduce the frequency of this mistake.

I don't see that there's anything to do here.

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

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

From report at bugs.python.org  Wed Jan 18 16:53:24 2017
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 18 Jan 2017 21:53:24 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484776404.51.0.521919939604.issue29281@psf.upfronthosting.co.za>


Ammar Askar added the comment:

To anyone more experienced with python documentation, is behavior like this actually supposed to be documented? For some more historical context,

the support for bytes in the json module was removed in this issue: https://bugs.python.org/issue4136

and then re-added in this one: 
https://bugs.python.org/issue17909

----------
nosy: +ammar2

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

From report at bugs.python.org  Wed Jan 18 17:14:03 2017
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 Jan 2017 22:14:03 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484777642.97.0.727715900325.issue29281@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, this should be documented with a versionchanged.  The removal was for python3 so we didn't need a versionchanged there; it was just a difference from python2, and the python3 docs were "restarted" with (almost) no back references to python2.

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

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

From report at bugs.python.org  Thu Jan 19 08:04:56 2017
From: report at bugs.python.org (Arne de Laat)
Date: Thu, 19 Jan 2017 13:04:56 +0000
Subject: [docs] [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1484831096.7.0.627293028368.issue28911@psf.upfronthosting.co.za>


Arne de Laat added the comment:

Unfortunately there cant be commas in the method name, that would clarify the name. It should be read as 'assert called once, with ...' not 'assert called once with ...'.

I have often used the method to test something was called only once, and with the specified arguments.

It seems that it is more difficult (i.e. no single method) to check if only one call was made with the specified arguments (allowing for more calls with other arguments), perhaps that could be added. Something like 'assert_once_called_with' or 'assert_one_call_with'.

----------
nosy: +153957

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

From report at bugs.python.org  Thu Jan 19 09:26:43 2017
From: report at bugs.python.org (RK-5wWm9h)
Date: Thu, 19 Jan 2017 14:26:43 +0000
Subject: [docs] [issue29321] Wrong documentation for unicode and str
 comparison
Message-ID: <1484836003.73.0.224345826816.issue29321@psf.upfronthosting.co.za>


New submission from RK-5wWm9h:

PROBLEM (IN BRIEF):

In the currently published 2.7.13 The Python Language Reference manual, section 5.9 "Comparisons" (https://docs.python.org/2/reference/expressions.html#comparisons):

    "If both are numbers, they are converted to a common type. Otherwise, objects of different types always compare unequal..."

This an *incorrect (and misleading) statement*.


PROPOSED FIX:

Insert a new sentence, to give this resulting text:

    "If both are numbers, they are converted to a common type. If one is str and the other unicode, they are compared as below. Otherwise, objects of different types always compare unequal..."


DETAILS, JUSTIFICATION, CORRECTNESS, ETC:

The behaviour that a str and a unicode object -- despite being objects of different types -- may compare equal, is explicitly stated several paragraphs later:

    "* Strings are compared lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior. [4]"

Text in the 2.7.13 The Python Standard Library (Library Reference manual) is careful to cover this unicode - str case (https://docs.python.org/2/library/stdtypes.html#comparisons):

    "Objects of different types, except different numeric types and different string types, never compare equal; such objects are ordered consistently but arbitrarily (so that sorting a heterogeneous array yields a consistent result)."


IMPACT AND RELATED BUG:

The current incorrect text is really misleading for anyone reading the Language Ref.  It's easy to see the categorical statement and stop reading because your question has been answered.

Further, the Library ref about unicode and str (The Python Standard Library (Library Reference manual) section 5.6 "Sequence Types": https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange), links here.  Link text: "(For full details see Comparisons in the language reference.)".

(Aside: That paragraph has a mistake similar to this present bug: it says "to compare equal, every element must compare equal and the two sequences must be of the same type"; I'll file a separate bug for it.)

PS: First time reporting a Python bug; following https://docs.python.org/2/bugs.html.  Hope I did ok!  :-)

----------
assignee: docs at python
components: Documentation
messages: 285790
nosy: RK-5wWm9h, docs at python
priority: normal
severity: normal
status: open
title: Wrong documentation for unicode and str comparison
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 19 09:40:31 2017
From: report at bugs.python.org (RK-5wWm9h)
Date: Thu, 19 Jan 2017 14:40:31 +0000
Subject: [docs] [issue29323] Wrong documentation (Library) for unicode and
 str comparison
Message-ID: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>


New submission from RK-5wWm9h:

PROBLEM (IN BRIEF):
In the currently published 2.7.13 The Python Standard Library (Library Reference manual) section 5.6 "Sequence Types" (https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange):

    "to compare equal, ... the two sequences must be of the same type"

This an *incorrect (and misleading) statement*, for the unicode and str case.


PROPOSED FIX:

Current full paragraph:

    "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences must be of the same type and have the same length. (For full details see Comparisons in the language reference.)"

Proposed replacement text:

    "Sequence types also support comparisons. In particular, tuples and lists are compared lexicographically by comparing corresponding elements. This means that to compare equal, every element must compare equal and the two sequences 
must be of the same type and have the same length. (Unicode and str are treated as the same type here; for full details see Comparisons in the language reference.)"


DETAILS, JUSTIFICATION, CORRECTNESS, ETC:

The current incorrect text is really misleading.

The behaviour that a str and a unicode object -- despite being objects of different types -- may compare equal, is explicitly stated in the 2.7.13 The Python Language Reference manual, section 5.9 "Comparisons" (https://docs.python.org/2/reference/expressions.html#comparisons):

    "* Strings are compared lexicographically using the numeric equivalents (the result of the built-in function ord()) of their characters. Unicode and 8-bit strings are fully interoperable in this behavior. [4]"

(Aside: Incidentally an earlier paragraph in the Language Ref fails to cover the unicode and str case; see separately filed bug Issue 29321.)

----------
assignee: docs at python
components: Documentation
messages: 285792
nosy: RK-5wWm9h, docs at python
priority: normal
severity: normal
status: open
title: Wrong documentation (Library) for unicode and str comparison
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Jan 19 09:42:45 2017
From: report at bugs.python.org (RK-5wWm9h)
Date: Thu, 19 Jan 2017 14:42:45 +0000
Subject: [docs] [issue29321] Wrong documentation (Language Ref) for unicode
 and str comparison
In-Reply-To: <1484836003.73.0.224345826816.issue29321@psf.upfronthosting.co.za>
Message-ID: <1484836965.89.0.22684661511.issue29321@psf.upfronthosting.co.za>


Changes by RK-5wWm9h <rkistruc at brocade.com>:


----------
title: Wrong documentation for unicode and str comparison -> Wrong documentation (Language Ref) for unicode and str comparison

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

From report at bugs.python.org  Thu Jan 19 11:22:29 2017
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Jan 2017 16:22:29 +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: <1484842949.53.0.854077368691.issue12067@psf.upfronthosting.co.za>


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


----------
dependencies: +Wrong documentation (Language Ref) for unicode and str comparison

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

From report at bugs.python.org  Thu Jan 19 11:31:33 2017
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Jan 2017 16:31:33 +0000
Subject: [docs] [issue29321] Wrong documentation (Language Ref) for unicode
 and str comparison
In-Reply-To: <1484836003.73.0.224345826816.issue29321@psf.upfronthosting.co.za>
Message-ID: <1484843493.0.0.556913284804.issue29321@psf.upfronthosting.co.za>


Martin Panter added the comment:

The Python 3 version of this was rewritten in Issue 12067. It would be good to port the new text to the Python 2 version, although that is not straightforward because of various differences between Python 2 and 3.

That doesn?t rule out making smaller more specific edits in the mean time. However your proposal still seems misleading to only mention str and unicode as special cases. It does not allow for str vs bytearray, set vs frozenset, or custom classes/types implementing their own __eq__() etc methods.

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

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

From report at bugs.python.org  Thu Jan 19 12:28:06 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jan 2017 17:28:06 +0000
Subject: [docs] [issue29323] Wrong documentation (Library) for unicode and
 str comparison
In-Reply-To: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
Message-ID: <1484846886.17.0.226166231676.issue29323@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unicode and string *are* of the same type: basestring.  This is a specific example of the liskov substitution principle, so I don't think it should be called out explicitly in this section.

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

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

From report at bugs.python.org  Thu Jan 19 12:30:53 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jan 2017 17:30:53 +0000
Subject: [docs] [issue29323] Wrong documentation (Library) for unicode and
 str comparison
In-Reply-To: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
Message-ID: <1484847053.39.0.482365580339.issue29323@psf.upfronthosting.co.za>


R. David Murray added the comment:

As per your other issue, though, the real issue is that the two objects must be *comparable*, not that they be of the same type, and the language should probably be updated to reflect that.

----------

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

From report at bugs.python.org  Thu Jan 19 14:47:00 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 Jan 2017 19:47:00 +0000
Subject: [docs] [issue29329] Incorrect documentation for custom `hex()`
 support on Python 2
In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za>
Message-ID: <1484855220.05.0.413083493132.issue29329@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Thu Jan 19 17:36:08 2017
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Jan 2017 22:36:08 +0000
Subject: [docs] [issue29323] Wrong documentation (Library) for unicode and
 str comparison
In-Reply-To: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
Message-ID: <1484865368.31.0.826436488155.issue29323@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you read the whole paragraph carefully, I don't think it is too misleading. "In particular, tuples and lists . . ." suggests the author was just trying to say that a tuple never compares equal to a list. Maybe we just need to make that more obvious?

However there are other problems in this part of the reference about comparing different types. See Issue 22000, about the earlier section on Comparisons of built-in types.

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

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

From report at bugs.python.org  Thu Jan 19 17:48:05 2017
From: report at bugs.python.org (Martin Panter)
Date: Thu, 19 Jan 2017 22:48:05 +0000
Subject: [docs] [issue29330] __slots__ needs documentation
In-Reply-To: <1484865040.1.0.923136956691.issue29330@psf.upfronthosting.co.za>
Message-ID: <1484866085.3.0.686201795195.issue29330@psf.upfronthosting.co.za>


Martin Panter added the comment:

Have you seen <https://docs.python.org/2.7/reference/datamodel.html#slots>? There is also <https://docs.python.org/2.7/glossary.html#term-slots>.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, martin.panter

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

From report at bugs.python.org  Thu Jan 19 17:54:14 2017
From: report at bugs.python.org (saumitra paul)
Date: Thu, 19 Jan 2017 22:54:14 +0000
Subject: [docs] [issue29330] __slots__ needs documentation
In-Reply-To: <1484866085.3.0.686201795195.issue29330@psf.upfronthosting.co.za>
Message-ID: <CANjQuE9VMj746h2g9jdM6NH-PmZkKwnv+Ura2xr7jfEeFFHzmA@mail.gmail.com>


saumitra paul added the comment:

Python 2.7.10 (default, Oct 23 2015, 19:19:21)

[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)] on darwin

Type "help", "copyright", "credits" or "license" for more information.

>>> help(__slots__)

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

NameError: name '__slots__' is not defined

>>> help('__slots__')

no Python documentation found for '__slots__'

>>>

On Thu, Jan 19, 2017 at 2:48 PM, Martin Panter <report at bugs.python.org>
wrote:

>
> Martin Panter added the comment:
>
> Have you seen <https://docs.python.org/2.7/reference/datamodel.html#slots>?
> There is also <https://docs.python.org/2.7/glossary.html#term-slots>.
>
> ----------
> assignee:  -> docs at python
> components: +Documentation
> nosy: +docs at python, martin.panter
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29330>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jan 19 18:31:25 2017
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 19 Jan 2017 23:31:25 +0000
Subject: [docs] [issue29330] __slots__ needs documentation
In-Reply-To: <1484865040.1.0.923136956691.issue29330@psf.upfronthosting.co.za>
Message-ID: <1484868685.03.0.173168413824.issue29330@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Are you suggesting that the Helper class in Lib/pydoc.py should index [sub-]topics by special names such as "__slots__"? Currently you can see the __slots__ documentation via the topics "ATTRIBUTEMETHODS" and "SPECIALMETHODS". The list of topics can be printed via help('topics'). Also when you exit out of help('__') it refers you to the SPECIALMETHODS topic.

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

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

From report at bugs.python.org  Thu Jan 19 18:45:11 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 Jan 2017 23:45:11 +0000
Subject: [docs] [issue29330] __slots__ needs documentation
In-Reply-To: <1484865040.1.0.923136956691.issue29330@psf.upfronthosting.co.za>
Message-ID: <1484869511.45.0.901015332259.issue29330@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/issue29330>
_______________________________________

From report at bugs.python.org  Thu Jan 19 18:53:21 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jan 2017 23:53:21 +0000
Subject: [docs] [issue29323] Wrong documentation (Library) for unicode and
 str comparison
In-Reply-To: <1484836831.64.0.870722472975.issue29323@psf.upfronthosting.co.za>
Message-ID: <1484870001.25.0.778399962666.issue29323@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's a good point, I think that is exactly the issue with that paragraph.

----------

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

From report at bugs.python.org  Thu Jan 19 21:43:08 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 20 Jan 2017 02:43:08 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484880188.16.0.29153849381.issue29292@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Updated patch for review comments

----------
Added file: http://bugs.python.org/file46348/kwdefs_docs.diff3

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

From report at bugs.python.org  Thu Jan 19 21:54:54 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 20 Jan 2017 02:54:54 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484880894.12.0.222744598216.issue29292@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Updated patch to include a cross reference to keyword-only arguments since I think not everyone will know about this rather new feature.

----------
Added file: http://bugs.python.org/file46349/kwdefs_docs.diff4

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

From report at bugs.python.org  Thu Jan 19 22:06:41 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 20 Jan 2017 03:06:41 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484881601.16.0.770985930771.issue29281@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Attached patch adds a versionchanged block to specify that bytes and bytesarray can now be used and the types of encodings it supports (as taken from the whatsnew changes here https://hg.python.org/cpython/rev/e9e1bf9ec2ac#l2.7)

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

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

From report at bugs.python.org  Thu Jan 19 22:34:47 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jan 2017 03:34:47 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <20170120033443.62768.65916.07AD64DB@psf.io>


Roundup Robot added the comment:

New changeset bb76ea32a32f by Xiang Zhang in branch '3.5':
Issue #29292: Update outdated doc of PyEval_EvalCodeEx.
https://hg.python.org/cpython/rev/bb76ea32a32f

New changeset bd121b7517ee by Xiang Zhang in branch '3.6':
Issue #29292: Merge 3.5.
https://hg.python.org/cpython/rev/bd121b7517ee

New changeset ef1146c95860 by Xiang Zhang in branch 'default':
Issue #29292: Merge 3.6.
https://hg.python.org/cpython/rev/ef1146c95860

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

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

From report at bugs.python.org  Thu Jan 19 22:35:38 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 20 Jan 2017 03:35:38 +0000
Subject: [docs] [issue29292] Missing a parameter in PyEval_EvalCodeEx doc
In-Reply-To: <1484640380.78.0.065326592654.issue29292@psf.upfronthosting.co.za>
Message-ID: <1484883338.0.0.608659238103.issue29292@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks Ammar. :-)

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

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

From report at bugs.python.org  Fri Jan 20 00:27:13 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Jan 2017 05:27:13 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484890033.43.0.531717471271.issue29281@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/issue29281>
_______________________________________

From report at bugs.python.org  Fri Jan 20 00:40:52 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jan 2017 05:40:52 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <20170120054008.62405.61681.6B846C05@psf.io>


Roundup Robot added the comment:

New changeset 3452ff9e8f0a by Raymond Hettinger in branch '3.6':
Issue #29281:  Fill-in a missing versionchanged entry
https://hg.python.org/cpython/rev/3452ff9e8f0a

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

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

From report at bugs.python.org  Fri Jan 20 00:41:14 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 20 Jan 2017 05:41:14 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484890874.43.0.991524987995.issue29281@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.

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

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

From report at bugs.python.org  Fri Jan 20 03:53:35 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 Jan 2017 08:53:35 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484902415.25.0.284903257798.issue29281@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The wording looks little misleading. There is the encoding parameter in json.loads(). It is deprecated and ignored.

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

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

From report at bugs.python.org  Fri Jan 20 10:59:08 2017
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 20 Jan 2017 15:59:08 +0000
Subject: [docs] [issue29281] json.loads documentation missing
 "versionchanged" statement
In-Reply-To: <1484558399.93.0.792457597374.issue29281@psf.upfronthosting.co.za>
Message-ID: <1484927948.66.0.40538899925.issue29281@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Which part is misleading, do you think the use of "encoding" could be confused with the argument encoding? 

There is a note right above the versionchanged block that says:

`The other arguments have the same meaning as in load(), except encoding which is ignored and deprecated.`


If that is the concern then I think changing the wording to be, "the encoding of the input string should be ..."

----------

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

From report at bugs.python.org  Sat Jan 21 04:20:13 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jan 2017 09:20:13 +0000
Subject: [docs] [issue28489] Fix comment in tokenizer.c
In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za>
Message-ID: <1484990413.0.0.45966088007.issue28489@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are just 8 legal combinations if ignore case:

>>> import tokenize
>>> sorted({x.lower() for x in tokenize._all_string_prefixes() if x})
['b', 'br', 'f', 'fr', 'r', 'rb', 'rf', 'u']

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

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

From report at bugs.python.org  Sat Jan 21 06:19:11 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 Jan 2017 11:19:11 +0000
Subject: [docs] [issue28489] Fix comment in tokenizer.c
In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za>
Message-ID: <1484997551.64.0.757370184971.issue28489@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Right, that's basically what _all_string_prefixes() does: it starts with the 6 unique prefixes that are case- and order- independent ('b', 'r', 'u', 'f', 'br', 'fr'), and adds the cased and ordered versions.

If you're saying that we should list those 8, and say "with all combinations of case", then I think we'd better off listing the 6 and saying "with all combinations of case and order". That's mainly because if "fbr" gets added, then the list of ordered ones gets larger.

But it's just a comment. I think we should just commit Ryan's last patch.

----------

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

From report at bugs.python.org  Sat Jan 21 06:19:56 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 Jan 2017 11:19:56 +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: <1484997594.76.0.00721475433959.issue12067@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a port of the documentation to Python 2. Main differences:

* Default rules for order comparisons are different
* Not all kinds of objects inherit from object()
* str(), unicode() compatibility
* xrange() only seems to have default comparability
* NAN, ?binary sequences? and sets not listed

----------
Added file: http://bugs.python.org/file46372/expressions-py2.7.diff

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

From report at bugs.python.org  Sat Jan 21 06:24:46 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jan 2017 11:24:46 +0000
Subject: [docs] [issue28489] Fix comment in tokenizer.c
In-Reply-To: <1476984216.11.0.150131580141.issue28489@psf.upfronthosting.co.za>
Message-ID: <1484997886.67.0.769815264476.issue28489@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, I'm just saying that the list of combinations is not so large. Ryan's patch LGTM.

----------

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

From report at bugs.python.org  Sat Jan 21 06:26:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 Jan 2017 11:26:38 +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: <1484997998.38.0.365812788863.issue12067@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 21 23:45:40 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Jan 2017 04:45:40 +0000
Subject: [docs] [issue28785] Clarify the behavior of __eq__() returning
 NotImplemented
In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za>
Message-ID: <1485060340.11.0.609820925518.issue28785@psf.upfronthosting.co.za>


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


----------
title: Clarify the behavior of NotImplemented -> Clarify the behavior of __eq__() returning NotImplemented

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

From report at bugs.python.org  Sat Jan 21 23:54:48 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 Jan 2017 04:54:48 +0000
Subject: [docs] [issue15997] NotImplemented needs to be documented
In-Reply-To: <1348206637.53.0.485410334327.issue15997@psf.upfronthosting.co.za>
Message-ID: <1485060888.48.0.300592668051.issue15997@psf.upfronthosting.co.za>


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


----------
dependencies: +Clarify the behavior of __eq__() returning NotImplemented

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

From report at bugs.python.org  Sun Jan 22 00:18:47 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 Jan 2017 05:18:47 +0000
Subject: [docs] [issue29092] Sync os.stat's doc and doc string
In-Reply-To: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>
Message-ID: <20170122051844.7098.22076.35D19EF1@psf.io>


Roundup Robot added the comment:

New changeset 1f30e114cbc8 by Xiang Zhang in branch '3.5':
Issue #29092: Sync os.stat's doc and docstring on path type.
https://hg.python.org/cpython/rev/1f30e114cbc8

New changeset 409ffea5cccf by Xiang Zhang in branch '3.6':
Issue #29092: Sync os.stat's doc and docstring on path type.
https://hg.python.org/cpython/rev/409ffea5cccf

New changeset cee9d322178f by Xiang Zhang in branch 'default':
Issue #29092: Merge 3.6.
https://hg.python.org/cpython/rev/cee9d322178f

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

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

From report at bugs.python.org  Sun Jan 22 00:19:21 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 22 Jan 2017 05:19:21 +0000
Subject: [docs] [issue29092] Sync os.stat's doc and doc string
In-Reply-To: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>
Message-ID: <1485062361.72.0.328123370672.issue29092@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


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

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

From report at bugs.python.org  Sun Jan 22 01:19:16 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Jan 2017 06:19:16 +0000
Subject: [docs] [issue29341] Missing accepting path-like object in
 docstrings of os module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1485065956.45.0.0312136834785.issue29341@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Jan 22 07:51:17 2017
From: report at bugs.python.org (John Taylor)
Date: Sun, 22 Jan 2017 12:51:17 +0000
Subject: [docs] [issue29284] Include thread_name_prefix in the
 concurrent.futures.ThreadPoolExecutor example 17.4.2.1
In-Reply-To: <1484584964.59.0.239435362381.issue29284@psf.upfronthosting.co.za>
Message-ID: <1485089477.55.0.359256533213.issue29284@psf.upfronthosting.co.za>


John Taylor added the comment:

I have updated the Python 3.6 example for 17.4.2.1. ThreadPoolExecutor Example.  Please see the attachment.  On my system this is the output:

thread name: loader_0
thread name: loader_1
thread name: loader_2
thread name: loader_3
thread name: loader_4
'http://example.com/' page is 1270 bytes
'http://www.foxnews.com/' page is 67351 bytes
'http://www.cnn.com/' page is 137164 bytes
'http://europe.wsj.com/' page is 914169 bytes
'http://www.bbc.co.uk/' page is 229503 bytes

Could you please consider adding this to the official documentation?

----------
Added file: http://bugs.python.org/file46377/ThreadPoolExec_Example.py

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

From ammar at ammaraskar.com  Thu Jan 19 21:59:50 2017
From: ammar at ammaraskar.com (ammar at ammaraskar.com)
Date: Fri, 20 Jan 2017 02:59:50 -0000
Subject: [docs] Missing a parameter in PyEval_EvalCodeEx doc (issue
 29292)
Message-ID: <20170120025950.31913.64118@psf.upfronthosting.co.za>


http://bugs.python.org/review/29292/diff/19784/Doc/c-api/veryhigh.rst
File Doc/c-api/veryhigh.rst (right):

http://bugs.python.org/review/29292/diff/19784/Doc/c-api/veryhigh.rst#newcode307
Doc/c-api/veryhigh.rst:307: a mapping object of local variables, arrays
of arguments, keywords and
Accidentally put a trailing whitespace character here. Should I submit a
new patch with it fixed or do minor fixes like that not need to be made?

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

From rob at robwu.nl  Thu Jan 19 10:52:20 2017
From: rob at robwu.nl (Rob Wu)
Date: Thu, 19 Jan 2017 16:52:20 +0100
Subject: [docs] Wrapped titles have no anchor (e.g.
 email.message_from_binary_file)
Message-ID: <CAA+18=zWoq7XVbpfMEDjCYpsyh+OFnp=YHSqkyvyt-erRxWqtg@mail.gmail.com>

The documentation of email.message_from_binary_file (below
message_from_bytes at
https://docs.python.org/3/library/email.parser.html#email.message_from_bytes
) has no anchor.
This is possibly caused by the fact that in the source, the method
signature is split over two lines:
https://hg.python.org/cpython/file/5b771c662c00/Doc/library/email.parser.rst#l249

If acceptable, an easy fix is to edit the rst file and put the full method
name on one line.
Otherwise the doc generator should be modified to account for multi-line
method signatures.

Kind regards,
 Rob
 https://robwu.nl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170119/970830a0/attachment-0001.html>

From rprior04938 at gmail.com  Sat Jan 21 16:56:58 2017
From: rprior04938 at gmail.com (rprior04938 at gmail.com)
Date: Sat, 21 Jan 2017 16:56:58 -0500
Subject: [docs] Bug? in Documentation 3.5.3
Message-ID: <04bd01d27431$4a59e2f0$df0da8d0$@gmail.com>

The "Parrot" function has the following statement:

                Print("--  This parrot wouldn't",action,end=' ')

 

The interpreter complains that the "end= ' '" statement has invalid syntax.

 

Thanks

 

Rod Prior

Experienced programmer, but Python newbie.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170121/4833a3ab/attachment.html>

From Sally.Hanford at nottingham.ac.uk  Fri Jan 20 10:01:17 2017
From: Sally.Hanford at nottingham.ac.uk (Sally Hanford)
Date: Fri, 20 Jan 2017 15:01:17 +0000
Subject: [docs] broken links?
Message-ID: <VI1PR0601MB2655FE5648E42D1A78B8850ADD710@VI1PR0601MB2655.eurprd06.prod.outlook.com>

Hello there
It looks like the download links are broken on  https://docs.python.org ?
Specifically https://docs.python.org/3.5/download.html
Regards
Sally

Sally Hanford
Libraries and Research and Learning Resources
King's Meadow Campus, Lenton Lane, Nottingham NG7 2NR
t: 0115 84 67973
[cid:image002.jpg at 01D218A0.850ECF60]





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it. 

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170120/97b53144/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 5734 bytes
Desc: image001.jpg
URL: <http://mail.python.org/pipermail/docs/attachments/20170120/97b53144/attachment.jpg>

From storchaka+cpython at gmail.com  Sat Jan 21 07:03:53 2017
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Sat, 21 Jan 2017 12:03:53 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
 12067)
Message-ID: <20170121120353.19879.56670@psf.upfronthosting.co.za>


http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1154
Doc/reference/expressions.rst:1154: 8-bit strings are fully
interoperable in this behavior. [#]_
This description is misleading. Unicode and 8-bit strings are not fully
interoperable.

>>> chr(0xff) == unichr(0xff)
__main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both arguments to Unicode - interpreting them as being unequal
False
>>> chr(0xff) < unichr(0xff)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0:
ordinal not in range(128)

When compare str and unicode, the str operand is converted to Unicode.
If the conversion is failed, values are traited as non-equal.

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1174
Doc/reference/expressions.rst:1174: - For two collections to compare
equal, they must be of the same type, have
> they must be of the same type

Subclasses are comparable with base class or other subclasses of the
same base class.

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1197
Doc/reference/expressions.rst:1197: User-defined classes that customize
their comparison behavior should follow
Would it be worth to document when custom comparison methods should
return NotImplemented?

The hash of hashable user defined classes should be consistent with the
equality.

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

From storchaka+cpython at gmail.com  Sun Jan 22 05:53:41 2017
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Sun, 22 Jan 2017 10:53:41 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
 12067)
Message-ID: <20170122105341.22726.20462@psf.upfronthosting.co.za>


http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1154
Doc/reference/expressions.rst:1154: 8-bit strings are fully
interoperable in this behavior. [#]_
On 2017/01/22 06:22:58, vadmium wrote:
> On 2017/01/21 13:03:53, storchaka wrote:
> > This description is misleading. Unicode and 8-bit strings are not
fully
> > interoperable.
> > 
> > >>> chr(0xff) == unichr(0xff)
> > __main__:1: UnicodeWarning: Unicode equal comparison failed to
convert both
> > arguments to Unicode - interpreting them as being unequal
> > False
> > >>> chr(0xff) < unichr(0xff)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position
0:
> ordinal
> > not in range(128)
> > 
> > When compare str and unicode, the str operand is converted to
Unicode. If the
> > conversion is failed, values are traited as non-equal.
> 
> Okay, I shall replace the second sentence with:
> 
> When comparing an 8-bit string and a Unicode string, the 8-bit string
is
> converted to Unicode. If the conversion fails, the strings are
considered
> unequal.

LGTM. Sorry, I'm not good in reviewing the documentation. I just checked
some technical details. You need other reviewer to checking your wording
or just commit your patch if you are feeling it correct (I trust your
experience and taste).

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

From vadmium+py at gmail.com  Sun Jan 22 00:22:58 2017
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 22 Jan 2017 05:22:58 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
 12067)
Message-ID: <20170122052258.19879.46146@psf.upfronthosting.co.za>


http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1154
Doc/reference/expressions.rst:1154: 8-bit strings are fully
interoperable in this behavior. [#]_
On 2017/01/21 13:03:53, storchaka wrote:
> This description is misleading. Unicode and 8-bit strings are not
fully
> interoperable.
> 
> >>> chr(0xff) == unichr(0xff)
> __main__:1: UnicodeWarning: Unicode equal comparison failed to convert
both
> arguments to Unicode - interpreting them as being unequal
> False
> >>> chr(0xff) < unichr(0xff)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position
0: ordinal
> not in range(128)
> 
> When compare str and unicode, the str operand is converted to Unicode.
If the
> conversion is failed, values are traited as non-equal.

Okay, I shall replace the second sentence with:

When comparing an 8-bit string and a Unicode string, the 8-bit string is
converted to Unicode. If the conversion fails, the strings are
considered unequal.

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1174
Doc/reference/expressions.rst:1174: - For two collections to compare
equal, they must be of the same type, have
On 2017/01/21 13:03:53, storchaka wrote:
> Subclasses are comparable with base class or other subclasses of the
same base
> class.

This would apply equally to the Python 3 version.

Andy originally omitted the ?built-in? clarifier, and wrote ?(or
subtypes of each other)?. But then he wanted to make this specific to
only built-in types, not user-defined subclasses:

https://bugs.python.org/review/12067/diff2/12409:13054/Doc/reference/expressions.rst#oldcode1147

IMO much of the finer details would be better off separately with the
documentation for each type, e.g. in Doc/library/stdtypes.rst. We should
keep the documentation on expressions general. A bit like how the
documentation on function call expressions just points to a different
chapter for the behaviour of each built-in function.

http://bugs.python.org/review/12067/diff/19802/Doc/reference/expressions.rst#newcode1197
Doc/reference/expressions.rst:1197: User-defined classes that customize
their comparison behavior should follow
On 2017/01/21 13:03:53, storchaka wrote:
> Would it be worth to document when custom comparison methods should
return
> NotImplemented?

Perhaps. See <https://bugs.python.org/issue15997>. Some of the details
are already in datamodel.rst under __eq__() etc, but they may make more
sense here under the comparison operators.

For the time being, do you think the link to :meth:`__lt__` in the third
paragraph is enough of a hint?

> The hash of hashable user defined classes should be consistent with
the
> equality.

Agreed. I shall include a bullet point like

* The :func:`hash` result should be consistent with equality. Objects
that are equal should either have the same hash value, or be marked as
unhashable.

This also applies to Python 3.

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

From report at bugs.python.org  Sun Jan 22 14:42:48 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 Jan 2017 19:42:48 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1485114168.37.0.947999423927.issue28749@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

How can we move this issue forward? Marc-Andre, have I answered to your objections?

----------

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

From report at bugs.python.org  Sun Jan 22 17:20:26 2017
From: report at bugs.python.org (Davin Potts)
Date: Sun, 22 Jan 2017 22:20:26 +0000
Subject: [docs] [issue29284] Include thread_name_prefix in the
 concurrent.futures.ThreadPoolExecutor example 17.4.2.1
In-Reply-To: <1484584964.59.0.239435362381.issue29284@psf.upfronthosting.co.za>
Message-ID: <1485123626.84.0.11964024052.issue29284@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin

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

From report at bugs.python.org  Sun Jan 22 20:55:47 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 23 Jan 2017 01:55:47 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1485136547.14.0.760260725822.issue28635@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can this be closed (since 3.6 has been released)? Or is there still more you'd like to do specifically to complete this issue?

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

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

From report at bugs.python.org  Sun Jan 22 22:07:26 2017
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Mon, 23 Jan 2017 03:07:26 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1485140846.07.0.421893314625.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

I'm pretty sure we're done with What's New for 3.6.0, so, unless it's worth keeping this open for any 3.6.x edits, I'm for closing this.

----------

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

From report at bugs.python.org  Sun Jan 22 23:13:12 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 23 Jan 2017 04:13:12 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1485144792.25.0.794549655733.issue28635@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't see any reason to keep this open.  Thanks so much, Elvis and Yury, for doing such a great job again!

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

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

From report at bugs.python.org  Mon Jan 23 01:39:24 2017
From: report at bugs.python.org (Tang Weizhi)
Date: Mon, 23 Jan 2017 06:39:24 +0000
Subject: [docs] [issue29348] this comment 'iff' should be 'if'?
Message-ID: <1485153564.45.0.440343066023.issue29348@psf.upfronthosting.co.za>


New submission from Tang Weizhi:

I think this comment 'if' should be more clearly, or 'iff' is the abbreviation of 'if and only if'?

----------
assignee: docs at python
components: Documentation
messages: 286051
nosy: Tangwz, docs at python
priority: normal
pull_requests: 20
severity: normal
status: open
title: this comment 'iff' should be 'if'?
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan 23 01:46:35 2017
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 23 Jan 2017 06:46:35 +0000
Subject: [docs] [issue29348] this comment 'iff' should be 'if'?
In-Reply-To: <1485153564.45.0.440343066023.issue29348@psf.upfronthosting.co.za>
Message-ID: <1485153995.89.0.537288721033.issue29348@psf.upfronthosting.co.za>


INADA Naoki added the comment:

"iff" is short form of "if and only if".

----------
nosy: +inada.naoki
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Jan 23 04:14:32 2017
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 23 Jan 2017 09:14:32 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1485114168.37.0.947999423927.issue28749@psf.upfronthosting.co.za>
Message-ID: <ed92c452-82d3-7a5a-c016-3c48f2ebd87c@egenix.com>


Marc-Andre Lemburg added the comment:

>> The only part that is not correct is "single string characters".
>> This should read "single bytes" or "bytes strings of length 1".
>
> This is not correct. Decoding mappings map not bytes strings, but
integers.

Looking at the implementation, you're right. AFAIR, the first
incarnation of the charmap codec used single chars in Python 2.
I guess the documentation was never updated when the change was
made to use integers instead.

> And this is not the only incorrect part. Decoding mappings can map to
> multicharacter Unicode strings, not to single Unicode	 characters. Not
just
> None, but the integer 0xfffe and Unicode string '\ufffe' mean "undefined
> mapping".

Yes, this was added later on as well. Apparently the docs
were never updated.

> There are similar incorrectnesses about encoding mappings.

Ok, fair enough, let's remove the two paragraphs.

>> I also don't see where you copied the description. Without some
>> description of what "mappings" are in the context of the charmap
>> codec, it's not easy to understand what the purpose of these
>> APIs is. Please just fix the bytes wording instead of removing the
>> whole intro.
>
> Decoding mappings were desribed in the introduction and in the
description of
> PyUnicode_DecodeCharmap() (both are outdated and incomplete). I merged
and
> corrected descriptions and left it only in one place, since
> PyUnicode_DecodeCharmap() is the only function that needs this. Same for
> encoding mappings. Both decoding and encoding mappings do not have a
relation
> to PyUnicode_Translate(). The paragraph about a LookupError in the
> introduction was totally wrong. I left in the introduction only common
part.
> Other details are too different in decoding, encoding and translation
mappings.
>
>> >> Also, this wording needs to be corrected: "bytes (integers in the
range
>> >> from 0 to 255)". Bytes are not integers. I'd suggest to use the more
>> >> correct wording "bytes strings of length 1".>
>> > The word "bytes" means here not Python bytes object, but is used in
more
>> > common meaning: an integer in the range from 0 to 255.
>> That's confusing, since we use the term "bytes" as referring
>> to the bytes object in Python. Please use "integers in the range
>> 0-255".
>
> Okay, I'll remove the word "bytes" here. But how would you formulate the
> following sentence: "Unmapped bytes (ones which cause a
:exc:`LookupError`) as
> well as mapped to ``None``, ``0xFFFE`` or ``'\ufffe'`` are treated as
"undefined
> mapping" and cause an error."?

Better:

"""
If *mapping* is *NULL*, Latin-1 decoding will be applied.  Else
*mapping* must map bytes ordinals (integers in the range from 0 to 255)
to Unicode strings, integers (which are then interpreted as Unicode
ordinals) or ``None``. Unmapped data bytes - ones which cause a
:exc:`LookupError`, as well as ones which get mapped to ``None``,
``0xFFFE`` or ``'\ufffe'``, are treated as undefined mappings and cause
an error.
"""

>> Aside: The deprecation of PyUnicode_EncodeCharmap() also seems misplaced
>> in this context, since only the Py_UNICODE version of the API is
>> deprecated. The functionality still exists and is useful. An API
>> similar to the _PyUnicode_EncodeCharmap() API should be made publicly
>> available to accommodate for the deprecation, since the mentioned
>> PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString()
>> APIs are not suitable as replacement. PyUnicode_AsCharmapString()
>> doesn't support error handling (strange, BTW) and
>> PyUnicode_AsEncodedString() has a completely unrelated meaning (no
>> idea why it's mentioned here at all).
>
> Only PyUnicode_EncodeCharmap() is deprecated,
PyUnicode_AsCharmapString() is
> not deprecated. I placed the deprecated function just after its
non-deprecated
> counerpart following the pattern for other deprecated functions. If
you prefer
> I'll move both deprecated functions (PyUnicode_EncodeCharmap and
> PyUnicode_TranslateCharmap) together at the end of this section.

No, I'd prefer this deprecation to be undone as long as we
don't have a proper alternative for the API.

Looking at the various deprecations for the Py_UNICODE APIs,
I find that the Unicode API symmetry was severely broken.
In the Python 2 API, we always have an PyUnicode_Encode...() and
corresponding PyUnicode_Decode...() API for every codec.

In Python 3, the encode APIs were apparently all deprecated
due to their use of Py_UNICODE and only the the much less useful
PyUnicode_As...String() APIs were left, which intentionally do not
have an error argument, because they were intended as quick
replacement for PyString_AsString() uses in Python 2.

> I don't know why PyUnicode_AsCharmapString() don't support the errors
> argument. I added PyUnicode_AsEncodedString() as a replacement
(issue19569)
> because this is the only public non-deprecated way to do a charmap
encoding
> with errors handling. There is no exact equivalent, but
> PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString() cover
different
> areas of using PyUnicode_EncodeCharmap().

The only way around this is to have new APIs to reestablish
the previous encoding functionality (only based on
PyObject *unicode instead of Py_UNICODE) at the C API level.

----------

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

From report at bugs.python.org  Mon Jan 23 04:41:21 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 23 Jan 2017 09:41:21 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
Message-ID: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

There's a hidden Python 2 print call in the script that only gets reached after you move the Doc/ folder outside the main CPython directory and run `make html`. 

Additionally, an obsolete way of assuring a file gets closed is used (changed to use `with` statement).

P.S: Tagged this with the Documentation component, maybe build is more applicable but I wasn't sure.

----------
assignee: docs at python
components: Documentation
files: patchlevel.patch
keywords: patch
messages: 286065
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: Update old Python 2 code in Docs/tools/extensions/patchlevel.py
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46387/patchlevel.patch

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

From report at bugs.python.org  Mon Jan 23 06:24:38 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jan 2017 11:24:38 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1485170678.71.0.366248206086.issue28749@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"bytes ordinals" is good term. Thank you. Here is an updated patch.

> No, I'd prefer this deprecation to be undone as long as we
> don't have a proper alternative for the API.

This is different issue.

----------
Added file: http://bugs.python.org/file46389/docs-PyUnicode_Translate-4.patch

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

From report at bugs.python.org  Mon Jan 23 11:49:16 2017
From: report at bugs.python.org (Akira Li)
Date: Mon, 23 Jan 2017 16:49:16 +0000
Subject: [docs] [issue29352] provide the authorative source for s[i:j]
 negative slice indices (<-len(s)) behavior for standard sequences
Message-ID: <1485190156.24.0.631194950251.issue29352@psf.upfronthosting.co.za>


New submission from Akira Li:

I've failed to find where the behavior for negative indices in s[i:j]
expression (i, j < -len(s)) for standard sequences (str, list, etc) is
formally defined.

The observed behavior implemented in PySlice_GetIndicesEx(): If "len(s)
+ i" or "len(s) + j" is negative, use 0. [1] I don't see it in the docs.

        if (*start < 0) *start += length;
        if (*start < 0) *start = (*step < 0) ? -1 : 0;
        ...
        if (*stop < 0) *stop += length;
        if (*stop < 0) *stop = (*step < 0) ? -1 : 0;

The tutorial mentions [2]:

> out of range slice indexes are handled gracefully when used for
> slicing"

slice.indices() documentation says [3]:

> Missing or out-of-bounds indices are handled in a manner consistent
> with regular slices.

Neither define it explicitly.

The behavior for the upper boundary is defined explicitly [4]:

> If *i* or *j* is greater than ``len(s)``, use ``len(s)``

I've added the documentation patch that defines the behavior for the
lower boundary too.

[1] Objects/sliceobject.c
[2] Doc/tutorial/introduction.rst
[3] Doc/reference/datamodel.rst
[4] Doc/library/stdtypes.rst

----------
assignee: docs at python
components: Documentation
files: docs-negative-slice-indices.patch
keywords: patch
messages: 286098
nosy: akira, docs at python
priority: normal
severity: normal
status: open
title: provide the authorative source for s[i:j] negative slice indices (<-len(s)) behavior for standard sequences
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46393/docs-negative-slice-indices.patch

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

From report at bugs.python.org  Mon Jan 23 22:26:19 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Jan 2017 03:26:19 +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: <1485228377.51.0.237127263201.issue12067@psf.upfronthosting.co.za>


Martin Panter added the comment:

Updated patch for 2.7, which I plan to commit soon. Corresponding Py 3 patch coming soon.

----------
Added file: http://bugs.python.org/file46398/expressions-py2.7_v17.diff

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

From report at bugs.python.org  Mon Jan 23 23:06:28 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Jan 2017 04:06:28 +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: <1485230788.65.0.233459475065.issue12067@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file46399/expressions-py3.7_v17.diff

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

From report at bugs.python.org  Tue Jan 24 00:02:41 2017
From: report at bugs.python.org (Martin Panter)
Date: Tue, 24 Jan 2017 05:02:41 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485234161.88.0.776298433417.issue29349@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is it okay to only fix this in 3.5+? 3.4 only gets security fixes now.

Either way, the ?with? statement changes is not a bug fix and should only go into 3.7.

----------
nosy: +martin.panter
stage:  -> commit review

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

From report at bugs.python.org  Tue Jan 24 01:26:51 2017
From: report at bugs.python.org (Emily Morehouse)
Date: Tue, 24 Jan 2017 06:26:51 +0000
Subject: [docs] [issue29341] Missing accepting path-like object in
 docstrings of os module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1485239211.2.0.368814326879.issue29341@psf.upfronthosting.co.za>


Emily Morehouse added the comment:

I see that path-like objects are indeed mentioned in the documentation (Doc/library/os.rst), simply stating "Changed in version 3.6: Supports a path-like object." Other methods, such as os.chroot, also mention such a change.

Comparing the docs mentioned above to the docstrings in Modules/clinic/posixmodule.c.h (and Modules/clinic/posixmodule.c for that matter), there's a clear disparity between the detail in the docs vs brevity in the docstrings (specifically in reference to os.chroot). 

Therefore, my question is: how detailed should the docstrings be and how closely should they match Doc/library/os.rst? I can certainly update the docstrings accordingly.

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

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

From report at bugs.python.org  Tue Jan 24 01:30:04 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 Jan 2017 06:30:04 +0000
Subject: [docs] [issue29189] Broken indentation in FancyURLopener
 documentation
In-Reply-To: <1483768195.47.0.481112354487.issue29189@psf.upfronthosting.co.za>
Message-ID: <20170124063000.24986.40394.FD669311@psf.io>


Roundup Robot added the comment:

New changeset fb2885f9b4dd by Martin Panter in branch '2.7':
Issue #29189: Fix indentation in RST markup
https://hg.python.org/cpython/rev/fb2885f9b4dd

New changeset 75e341d79c99 by Martin Panter in branch '3.5':
Issue #29189: Fix indentation in RST markup
https://hg.python.org/cpython/rev/75e341d79c99

New changeset f0854405c830 by Martin Panter in branch '3.6':
Issues #29189: Merge indentation fixes from 3.5
https://hg.python.org/cpython/rev/f0854405c830

New changeset d654b7c63b48 by Martin Panter in branch 'default':
Issues #29189: Merge indentation fixes from 3.6
https://hg.python.org/cpython/rev/d654b7c63b48

----------

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

From report at bugs.python.org  Tue Jan 24 01:33:10 2017
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 24 Jan 2017 06:33:10 +0000
Subject: [docs] [issue29341] Missing accepting path-like object in
 docstrings of os module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1485239590.65.0.744446830393.issue29341@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't mean to sync the docstring and the documentation totally. But just like os.chown, there are some functions explicitly mention the acceptable types of path parameter in their docstrings. I think since they already mention the types, then make the list complete. For example, I think for os.chown make the list "can be string, bytes, path-like object or open-file-descriptor int" is enough.

----------

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

From report at bugs.python.org  Tue Jan 24 06:59:55 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Tue, 24 Jan 2017 11:59:55 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485259195.77.0.683967058655.issue29349@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I'm breaking these to separate files to make it easier to apply. I also noticed that other files in `Doc/tools/extensions/` use old constructs so I'm not sure about the *with*.

I'm guessing that either it should be changed in other files too or, since it's working fine, leave it as is.

----------
Added file: http://bugs.python.org/file46405/patchlevel_print.patch

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

From report at bugs.python.org  Tue Jan 24 07:00:03 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Tue, 24 Jan 2017 12:00:03 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485259203.33.0.882424389425.issue29349@psf.upfronthosting.co.za>


Changes by Jim Fasarakis-Hilliard <d.f.hilliard at gmail.com>:


Added file: http://bugs.python.org/file46406/patchlevel_with.patch

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

From report at bugs.python.org  Tue Jan 24 14:08:30 2017
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 24 Jan 2017 19:08:30 +0000
Subject: [docs] [issue29352] provide the authorative source for s[i:j]
 negative slice indices (<-len(s)) behavior for standard sequences
In-Reply-To: <1485190156.24.0.631194950251.issue29352@psf.upfronthosting.co.za>
Message-ID: <1485284910.29.0.612565958962.issue29352@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I think the wording could be improved, but there is another option I wanted to put here. Right now, we're being overly detailed about the implementation, specifying the bounds substitutions performed. If we're just trying to describe logical behavior, we could simplify footnote 4 to, dropping explicit descriptions for "out of bounds" cases, getting:

The slice of *s* from *i* to *j* is defined as the sequence of items with index *k* such that ``i <= k < j`` and ``0 <= k < len(s)``. If *i* is omitted or ``None``, use ``0``. If *j* is omitted or ``None``, use ``len(s)``. If *i* is greater than or equal to *j*, the slice is empty.

That avoids needing to be explicit about substitutions in the < -len(s) case and > len(s) cases, since limiting the values of k to the intersection of range(i, j) and range(len(s)) covers both ends. I considered a single range, like ``max(0, i) <= k < min(j, len(s))``, but that wouldn't describe the upper bound on i or the lower bound on j properly, and ``min(max(0, i), len(s)) <= k < min(max(0, j), len(s))`` is ugly. Footnote 3 covers the adjustment for negative values already, which allows for the simpler description.

----------
nosy: +josh.r

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

From report at bugs.python.org  Tue Jan 24 14:58:44 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jan 2017 19:58:44 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1485287924.73.0.947764999468.issue28810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Several third-party bytecode manipulating projects still are not updated to 3.6. Correct documentation is needed for them. Could anyone please make a review of the patch (or maybe totally rewrite it)?

----------

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

From report at bugs.python.org  Tue Jan 24 15:42:16 2017
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Jan 2017 20:42:16 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1485290536.81.0.7502793337.issue28810@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Tue Jan 24 15:42:29 2017
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 Jan 2017 20:42:29 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1485290549.63.0.800067571715.issue28810@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'll review your patch sometime this week, Serhiy.

----------

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

From report at bugs.python.org  Tue Jan 24 16:15:09 2017
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Tue, 24 Jan 2017 21:15:09 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1485292509.41.0.6477115956.issue28845@psf.upfronthosting.co.za>


Eric N. Vander Weele added the comment:

> I request that you review issue27435 - in particular msg284557 - as I feel ctypes implementation for AIX is broken - at least as far as the supporting routines are concerned.

I believe this request is outside the scope of this particular issue.

> [...] AIX to test it.

It appears there is an AIX system in Python's buildbot farm to validate the curses example.  Is the next step have a core maintainer conduct the validation on an AIX system before this can move forward?

----------

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

From senthil at uthcode.com  Wed Jan 25 04:39:15 2017
From: senthil at uthcode.com (senthil at uthcode.com)
Date: Wed, 25 Jan 2017 09:39:15 -0000
Subject: [docs] Suggest PyCharm Community as an editor for Unix
 platforms (issue 26149)
Message-ID: <20170125093915.7264.23506@psf.upfronthosting.co.za>

Reviewed, and +1 to this change.
I found Berker's review comments addressed. Going ahead with committing
this.

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

From shadowranger+python at gmail.com  Tue Jan 24 13:45:12 2017
From: shadowranger+python at gmail.com (shadowranger+python at gmail.com)
Date: Tue, 24 Jan 2017 18:45:12 -0000
Subject: [docs] provide the authorative source for s[i:j] negative slice
 indices (<-len(s)) behavior for standard sequences (issue 29352)
Message-ID: <20170124184512.7264.82171@psf.upfronthosting.co.za>


https://bugs.python.org/review/29352/diff/19815/Doc/library/stdtypes.rst
File Doc/library/stdtypes.rst (right):

https://bugs.python.org/review/29352/diff/19815/Doc/library/stdtypes.rst#newcode937
Doc/library/stdtypes.rst:937: ``len(s)``. If ``len(s) + i`` or ``len(s)
+ j`` is negative, use ``0``. If *i*
I think, to avoid repetition, a footnote cross-reference might make more
sense here:

"If a negative index remains negative after substitution (Note 3), use
``0``."

Or if footnote cross-references are verboten, to match the phrasing for
the previous sentence and simplify the language:

"If *i* or *j* is less than ``-len(s)``, use ``0``."

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

From sjrct0 at gmail.com  Mon Jan 23 10:25:18 2017
From: sjrct0 at gmail.com (Christopher Harding)
Date: Mon, 23 Jan 2017 10:25:18 -0500
Subject: [docs] Incomplete sentence/typo in http.server#send_reponse_only
Message-ID: <CAOYjB7rM2WoUc-wg-rzhXvcj9Agbgy4uXLQWGDxuDzVRidxG4A@mail.gmail.com>

The phrase "The headers not buffered and sent directly the output stream."
does not seem to make sense. Note also there is no space following this
period after this phrase.

Relevant page:
https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.send_response_only
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170123/4d811592/attachment.html>

From report at bugs.python.org  Wed Jan 25 04:46:51 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jan 2017 09:46:51 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <20170125094648.20918.73286.A917AEE8@psf.io>


Roundup Robot added the comment:

New changeset b43e270648a3 by Senthil Kumaran in branch '2.7':
issue26149 - Point to Wiki for Editors and Python IDEs on Unix.
https://hg.python.org/cpython/rev/b43e270648a3

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

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

From report at bugs.python.org  Wed Jan 25 04:48:53 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 Jan 2017 09:48:53 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <20170125094851.21040.44395.6D18BB85@psf.io>


Roundup Robot added the comment:

New changeset 25fc68e22eee by Senthil Kumaran in branch '3.6':
issue26149 - Point to Wiki for Editors and Python IDEs on Unix.
https://hg.python.org/cpython/rev/25fc68e22eee

New changeset 0fd4a3d8e32a by Senthil Kumaran in branch 'default':
[merge 3.6] - issue26149 - Point to Wiki for Editors and Python IDEs on Unix.
https://hg.python.org/cpython/rev/0fd4a3d8e32a

----------

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

From report at bugs.python.org  Wed Jan 25 04:49:26 2017
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 25 Jan 2017 09:49:26 +0000
Subject: [docs] [issue26149] Suggest PyCharm Community as an editor for Unix
 platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1485337766.6.0.361950764566.issue26149@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you, Mariatta.

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

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

From report at bugs.python.org  Wed Jan 25 08:36:09 2017
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 25 Jan 2017 13:36:09 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
Message-ID: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>


New submission from Marco Buttu:

>From the doctest documentation [1]:

"Symbolic names for the flags are supplied as module constants, which can be or'ed together and passed to various functions."

Is there a typo in "...which can be or'ed together..."? Maybe "collected together"?


[1] https://docs.python.org/3/library/doctest.html#option-flags

----------
assignee: docs at python
components: Documentation
messages: 286254
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Typo in doctest documentation
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/issue29371>
_______________________________________

From report at bugs.python.org  Wed Jan 25 08:45:21 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Wed, 25 Jan 2017 13:45:21 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485351921.82.0.963105949839.issue29371@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

>From what I understand, "or'ed" here stands for combining the options using `|` (https://docs.python.org/3/reference/expressions.html#binary-bitwise-operations).

You can see an example of that in the source for `doctest.py` https://hg.python.org/cpython/file/3.6/Lib/doctest.py#l144

----------
nosy: +Jim Fasarakis-Hilliard

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

From report at bugs.python.org  Wed Jan 25 09:13:49 2017
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 25 Jan 2017 14:13:49 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485353629.91.0.075194407263.issue29371@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I think you got the meaning. I have never read it before :/ If you think the meaning is clear enough for everyone, I close the issue.

----------

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

From report at bugs.python.org  Wed Jan 25 09:17:36 2017
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 25 Jan 2017 14:17:36 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485353856.17.0.680473411134.issue29371@psf.upfronthosting.co.za>


Marco Buttu added the comment:

What about this?

"Symbolic names for the flags are supplied as module constants, which can be OR'ed together (flagA | flagB | ...) and passed to various functions."

----------

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

From report at bugs.python.org  Wed Jan 25 12:25:31 2017
From: report at bugs.python.org (Petr MOTEJLEK)
Date: Wed, 25 Jan 2017 17:25:31 +0000
Subject: [docs] [issue29374] Doc bug: signal.sigwait and signal.sigtimedwait
 do not work outside the Main thread
Message-ID: <1485365131.36.0.15146613889.issue29374@psf.upfronthosting.co.za>


New submission from Petr MOTEJLEK:

Hi,

The documentation for signal.signal() clearly states that it is only supposed to be called on MainThread

However, it does not say so for the signal.sigwait() and neither signal.sigtimedwait()

I think this is an error on the documentation side of things (unless I misread it). When either signal.sigwait or signal.sigtimedwait are called outside MainThread, they simply never catch any signals (signal.sigwait blocks indefinitely)

I did not test this on Windows, but on both Linux and OS X the behavior is the same

Consider the below simple code

  import signal
  import os
  def sigwait():
    print("Send me a signal, my PID is {p}".format(p=os.getpid()))  
    print("Got the signal: {i}".format(i=signal.sigwait((signal.SIGUSR1,))))

If sigwait() is called on MainThread and the process receives SIGUSR1, "Got the signal: ..." gets printed. However, calling sigwait in a different thread blocks the thread indefinitely. The behavior is the same with signal.sigtimedwait() as well

----------
assignee: docs at python
components: Documentation
messages: 286269
nosy: docs at python, petr at motejlek.net
priority: normal
severity: normal
status: open
title: Doc bug: signal.sigwait and signal.sigtimedwait do not work outside the Main thread
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Jan 25 16:01:56 2017
From: report at bugs.python.org (Michael Kleehammer)
Date: Wed, 25 Jan 2017 21:01:56 +0000
Subject: [docs] [issue29236] 'an ASCII string of one or more PEM-encoded
 certificates' needs to be unicode
In-Reply-To: <1484097460.25.0.906949156541.issue29236@psf.upfronthosting.co.za>
Message-ID: <1485378116.92.0.478378727006.issue29236@psf.upfronthosting.co.za>


Changes by Michael Kleehammer <michael at kleehammer.com>:


----------
nosy: +mkleehammer

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

From report at bugs.python.org  Wed Jan 25 17:48:25 2017
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 Jan 2017 22:48:25 +0000
Subject: [docs] [issue29374] Doc bug: signal.sigwait and signal.sigtimedwait
 do not work outside the Main thread
In-Reply-To: <1485365131.36.0.15146613889.issue29374@psf.upfronthosting.co.za>
Message-ID: <1485384505.0.0.443124014535.issue29374@psf.upfronthosting.co.za>


Martin Panter added the comment:

This works for me on Linux:

>>> signal.pthread_sigmask(signal.SIG_BLOCK, {signal.SIGUSR1})
set()
>>> import threading
>>> t = threading.Thread(target=sigwait)
>>> t.start()
Send me a signal, my PID is 24197
>>> os.kill(os.getpid(), signal.SIGUSR1)
Got the signal: 10
>>> t.join()

Posix <http://pubs.opengroup.org/onlinepubs/9699919799/functions/sigwait.html> only defines sigwait() if the signals are already blocked. Two reasons behind this come to mind:

1. There would be a race where the signal handler may be called first (or the signal may be ignored) at the OS level, and the sigwait() function will miss the signal and block.

2. If the signal is handled in the context of another thread that isn?t using sigwait(), it may be consumed (handled or ignored) in the context of the other thread, with no effect on your sigwait() call.

This detail of blocking the signal seems to be a common error, so maybe the Python documentation could help point it out. (Issue 25868 comes to mind; there is a test case that IMO should block a signal before waiting for it.)

----------
nosy: +martin.panter
versions:  -Python 3.4

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

From report at bugs.python.org  Thu Jan 26 01:39:29 2017
From: report at bugs.python.org (Caitlin)
Date: Thu, 26 Jan 2017 06:39:29 +0000
Subject: [docs] [issue22651] Open file in a+ mode reads from end of file in
 Python 3.4
In-Reply-To: <1413446231.99.0.734842825619.issue22651@psf.upfronthosting.co.za>
Message-ID: <1485412769.78.0.395282198427.issue22651@psf.upfronthosting.co.za>


Caitlin added the comment:

Yeah, the workaround seemed to work for me when trying to open file on http://buywebsitetrafficreviews.org/, but this should be fixed somehow anyway.

----------
nosy: +caitlinwalker37

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

From report at bugs.python.org  Thu Jan 26 02:56:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Jan 2017 07:56:08 +0000
Subject: [docs] [issue22651] Open file in a+ mode reads from end of file in
 Python 3.4
In-Reply-To: <1413446231.99.0.734842825619.issue22651@psf.upfronthosting.co.za>
Message-ID: <1485417368.92.0.756318092567.issue22651@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg286294

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

From report at bugs.python.org  Thu Jan 26 03:08:35 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 Jan 2017 08:08:35 +0000
Subject: [docs] [issue22651] Open file in a+ mode reads from end of file in
 Python 3.4
In-Reply-To: <1413446231.99.0.734842825619.issue22651@psf.upfronthosting.co.za>
Message-ID: <1485418115.67.0.801853687146.issue22651@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Python 2, it's easy to workaround the issue, just always go the end explicitly:

   f = open(filename, "a+")
   f.seek(0, os.SEEK_END)

Or use the io module which doesn't use the stdio of the C library and has a portable and reliable behaviour:

   f = io.open(filename, "a+")


Georg Brandl: "This is a somewhat unfortunate difference between the major C libs and Python's new IO, but probably too late to change."

Since it's easy to workaround the issue and only one user complained lat 2 years (3 years?), sorry, I close now the issue.

I add this bug to my long list of bugs in the C stdio which won't be fixed in Python 2...
http://haypo-notes.readthedocs.io/python.html#bugs-in-the-c-stdio-used-by-the-python-i-o

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

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

From report at bugs.python.org  Thu Jan 26 11:21:37 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jan 2017 16:21:37 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485447697.52.0.789228428075.issue26355@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Belatedly following up on this, yeah, the RTFD page indicates that the header link should look like:

    <link rel="canonical" href="http://docs.python.org/3/<path>">

----------

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

From report at bugs.python.org  Thu Jan 26 11:25:04 2017
From: report at bugs.python.org (Kaeptm Blaubaer)
Date: Thu, 26 Jan 2017 16:25:04 +0000
Subject: [docs] [issue29378] Invalid example in documentation for PyErr_Fetch
Message-ID: <1485447904.37.0.693014852804.issue29378@psf.upfronthosting.co.za>


New submission from Kaeptm Blaubaer:

In the example are the pointers to pointers to PyObject too many,
because then PyErr_Fetch and PyErr_Restore would get too many pointers to pointers.

----------
assignee: docs at python
components: Documentation
messages: 286321
nosy: Kaeptm Blaubaer, docs at python
priority: normal
severity: normal
status: open
title: Invalid example in documentation for PyErr_Fetch

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

From report at bugs.python.org  Thu Jan 26 12:05:56 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 Jan 2017 17:05:56 +0000
Subject: [docs] [issue29378] Invalid example in documentation for PyErr_Fetch
In-Reply-To: <1485447904.37.0.693014852804.issue29378@psf.upfronthosting.co.za>
Message-ID: <1485450356.96.0.55388065097.issue29378@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The example looks correct to me. Could you please add more information? What example looks correct to you?

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

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

From report at bugs.python.org  Thu Jan 26 17:26:46 2017
From: report at bugs.python.org (Matthias Bussonnier)
Date: Thu, 26 Jan 2017 22:26:46 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485469606.05.0.0489279550073.issue26355@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Does this have to be implemented on the doc build of EOL pythons versions (like 2.6), or can it be a script which is ran once on these old docs ? 


One of the issues I had trying to implement that on other projects was that you don't know in advance what the future pages will be or if it will be gone. So you can go this route[1], in which case it's a 10 line fix that I'm happy to contribute also here. 

Typically `https://docs.python.org/2/c-api/string.html` has no cannonical on 3 whouch you can't know while building with sphinx. 

Or I though about injecting an html comment with a html comment that you search and replace once you publish the "new" version and only if the target page exists on the new version. 


So : 

- is that ok to have non existing cannonical ? 
- is that ok if adding <rel>s on docs is (or requires) a post-sphinx script ? 

1: https://github.com/xonsh/xonsh/pull/1914/files

Thanks

----------
nosy: +mbussonn

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

From report at bugs.python.org  Thu Jan 26 19:14:35 2017
From: report at bugs.python.org (Matthias Bussonnier)
Date: Fri, 27 Jan 2017 00:14:35 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485476075.56.0.64546187859.issue26355@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Here is a patch that add a canonical link to the current documentation that should apply cleanly to 3.4 and above. I can do similar for older versions.

----------
keywords: +patch
Added file: http://bugs.python.org/file46426/cannonical-doc-for-3.4plus.patch

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

From report at bugs.python.org  Fri Jan 27 03:09:41 2017
From: report at bugs.python.org (Manuel Krebber)
Date: Fri, 27 Jan 2017 08:09:41 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485504581.56.0.472971565241.issue26355@psf.upfronthosting.co.za>


Manuel Krebber added the comment:

I create the last diff without creating a commit, so maybe this one works better.

----------
nosy: +Wheerd
Added file: http://bugs.python.org/file46428/slot-wrapper-types.patch

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

From report at bugs.python.org  Fri Jan 27 03:10:11 2017
From: report at bugs.python.org (Manuel Krebber)
Date: Fri, 27 Jan 2017 08:10:11 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485504611.26.0.65901743723.issue26355@psf.upfronthosting.co.za>


Changes by Manuel Krebber <admin at wheerd.de>:


Removed file: http://bugs.python.org/file46428/slot-wrapper-types.patch

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

From report at bugs.python.org  Fri Jan 27 03:12:23 2017
From: report at bugs.python.org (Manuel Krebber)
Date: Fri, 27 Jan 2017 08:12:23 +0000
Subject: [docs] [issue26355] Emit major version based canonical URLs for docs
In-Reply-To: <1455353539.4.0.541474968967.issue26355@psf.upfronthosting.co.za>
Message-ID: <1485504743.13.0.254913015679.issue26355@psf.upfronthosting.co.za>


Manuel Krebber added the comment:

Sorry, I accidentally replied to the worng issue -.-

----------

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

From report at bugs.python.org  Fri Jan 27 08:05:19 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 Jan 2017 13:05:19 +0000
Subject: [docs] [issue28784] shlex.shlex punctuation_chars documentation
 should use posix=True
In-Reply-To: <1479973450.22.0.44978748963.issue28784@psf.upfronthosting.co.za>
Message-ID: <20170127130515.104192.29003.70A07087@psf.io>


Roundup Robot added the comment:

New changeset ff3312ce1d14 by Vinay Sajip in branch '3.6':
Fixes #28784: Clarified use of shlex.shlex with punctuation_chars.
https://hg.python.org/cpython/rev/ff3312ce1d14

New changeset 46f8188f8646 by Vinay Sajip in branch 'default':
Closes #28784: Merged update from 3.6.
https://hg.python.org/cpython/rev/46f8188f8646

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

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

From dougbmorris at yahoo.com  Wed Jan 25 13:23:18 2017
From: dougbmorris at yahoo.com (Douglas Morris)
Date: Wed, 25 Jan 2017 18:23:18 +0000 (UTC)
Subject: [docs] Suggested Edit of re Doc
References: <768231739.683776.1485368598009.ref@mail.yahoo.com>
Message-ID: <768231739.683776.1485368598009@mail.yahoo.com>

Dear Python volunteers,

Thanks for you work. I am learning Python (a newbie) and have a suggestion. The FAQ has an explanation on the syntactical requirement of raw strings, which is nice enough when you are looking at it or remember looking at it. Newbies who read the re documentation first may have a different experience.

The Standard Library Documentation for module re reads in section 6.2 (the beginning of the re documentation):The solution is to use Python?s raw string notation for regular expressionpatterns; backslashes are not handled in any special way in a string literalprefixed with 'r'.
I suggest changing that to:
The solution is to use Python?s raw string notation for regular expressionpatterns. Backslash escapes are not actually replaced in raw strings, but the backslashes are still required to syntactically permit such replacement in subsequent processing. Consequently, the content of string literals with the 'r' prefix have exactly one syntactic requirement: the total number of consecutive backslashes at the end must be even (possibly zero).?Douglas Morris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170125/db143743/attachment.html>

From report at bugs.python.org  Fri Jan 27 10:20:33 2017
From: report at bugs.python.org (Kaeptm Blaubaer)
Date: Fri, 27 Jan 2017 15:20:33 +0000
Subject: [docs] [issue29378] Invalid example in documentation for PyErr_Fetch
In-Reply-To: <1485447904.37.0.693014852804.issue29378@psf.upfronthosting.co.za>
Message-ID: <1485530433.89.0.632395548495.issue29378@psf.upfronthosting.co.za>


Kaeptm Blaubaer added the comment:

I had an outdated version of the documentation.

----------
resolution:  -> out of date
status: open -> closed

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

From report at bugs.python.org  Fri Jan 27 10:42:11 2017
From: report at bugs.python.org (Kaeptm Blaubaer)
Date: Fri, 27 Jan 2017 15:42:11 +0000
Subject: [docs] [issue29378] Invalid example in documentation for PyErr_Fetch
In-Reply-To: <1485447904.37.0.693014852804.issue29378@psf.upfronthosting.co.za>
Message-ID: <1485531731.48.0.307970846646.issue29378@psf.upfronthosting.co.za>


Kaeptm Blaubaer added the comment:

I had no outdated documentation, but the documentation of 3.5.

----------
resolution: out of date -> 
status: closed -> open
versions: +Python 3.5

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

From report at bugs.python.org  Fri Jan 27 12:20:02 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 27 Jan 2017 17:20:02 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference
Message-ID: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

After moving a certain chunk of the 'interpreter.rst' contents to 'appendix.rst' in issue16827 the reference to #! in the section '2.2.3. Source Code Encoding' is currently confusing for new readers.

Attached patches reword the sentence to remove that reference for 3.4+ and 2.7.

----------
assignee: docs at python
components: Documentation
files: interpreter_tut.patch
keywords: patch
messages: 286378
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: Tutorial documentation contains undefined reference
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46438/interpreter_tut.patch

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

From report at bugs.python.org  Fri Jan 27 12:20:26 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 27 Jan 2017 17:20:26 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485537626.62.0.320660714985.issue29381@psf.upfronthosting.co.za>


Changes by Jim Fasarakis-Hilliard <d.f.hilliard at gmail.com>:


----------
title: Tutorial documentation contains undefined reference -> Tutorial documentation contains undefined reference to #!
Added file: http://bugs.python.org/file46439/interpreter_tut2.7.patch

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

From report at bugs.python.org  Fri Jan 27 12:34:15 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 27 Jan 2017 17:34:15 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485538455.75.0.934212559549.issue29371@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I think it is fine as it is but, agree that it could be clearer. I'm simply not experienced enough to know if this change is warranted. 

The docs generally do a great job in being concise (balancing brevity and completeness). A core-dev would be best to judge if brevity should be sacrificed for more complete and clear wording here. 

I suggest waiting to see if any core-dev replies and, if no replies come in after a while, close it.

----------

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

From report at bugs.python.org  Fri Jan 27 14:38:37 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jan 2017 19:38:37 +0000
Subject: [docs] [issue29374] Doc: signal.sig(timed)wait do not work outside
 the main thread
In-Reply-To: <1485365131.36.0.15146613889.issue29374@psf.upfronthosting.co.za>
Message-ID: <1485545917.53.0.303214109584.issue29374@psf.upfronthosting.co.za>


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


----------
title: Doc bug: signal.sigwait and signal.sigtimedwait do not work outside the Main thread -> Doc: signal.sig(timed)wait do not work outside the main thread

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

From report at bugs.python.org  Fri Jan 27 16:25:58 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Jan 2017 21:25:58 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485552358.68.0.523884726607.issue29371@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jan 27 17:23:54 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Jan 2017 22:23:54 +0000
Subject: [docs] [issue29371] Typo in doctest documentation
In-Reply-To: <1485351369.68.0.185486175403.issue29371@psf.upfronthosting.co.za>
Message-ID: <1485555834.77.0.977537279735.issue29371@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Mariatta, would you like to look into this and opine about whether the docs are correct as-is.  If you think a change is warranted, propose a patch.

----------

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

From report at bugs.python.org  Fri Jan 27 17:25:16 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 27 Jan 2017 22:25:16 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485555915.99.0.215320073574.issue29381@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Mariatta, could you check this patch and tell us your recommendation about whether it should be applied, modified, or rejected?

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

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

From report at bugs.python.org  Sat Jan 28 07:09:12 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sat, 28 Jan 2017 12:09:12 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485605352.82.0.657347462657.issue29381@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Hi, Raymond. Is Mariatta responsible for reviewing Documentation submissions? If so, should I nosy Mariatta in any future documentation issues?

----------

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

From report at bugs.python.org  Sat Jan 28 11:39:15 2017
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 28 Jan 2017 16:39:15 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485621555.71.0.804366646736.issue29381@psf.upfronthosting.co.za>


Marco Buttu added the comment:

You wrote: "It is also possible to specify a different encoding for source files. In order to do this, you can use a special comment line that defines the source file encoding::". I think that is not true, because the line have to be the first line, or right below a comment (just one, as in the case of the shebang). For instance, in this case Python apply the declared coding:

  $ cat foo.py
  # The first line is a comment
  # -*- coding: ascii -*-
  print('?')  # Encoded in UTF-8
  $ python foo.py
     ...
  SyntaxError: encoding problem: ascii


In this case it does not:

  $ cat foo.py
  # The first line is a comment
  # and also the sencond line
  # -*- coding: ascii -*-
  print('?')  # Encoded in UTF-8
  $ python foo.py 
  ?

But I think you are right that the current doc is confusing. Maybe yon can write something like this: 

"It is also possible to specify a different encoding for source files. In order to do this, put one special comment line to define the source file encoding:

# -*- coding: encoding -*-

This coding comment has to be the first line of the file, or the second line in case the first one is the #! line."

----------
nosy: +marco.buttu

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

From report at bugs.python.org  Sat Jan 28 11:55:13 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sat, 28 Jan 2017 16:55:13 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485622513.32.0.29575820223.issue29381@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Indeed, this does create an issue. 

The last sentence in the documentation actually specifies where the encoding comment can be but doesn't strictly specify it can be on the second line if and only if preceded by `#!`.

I'm thinking the last sentence should contain the additional change, that is, change it from :

    The special encoding comment must be in the first or second line within the file.

to:

    The special encoding comment must be in the first line, or, if the first line is used to create an executable Python script, the second line within the file.

linking to (https://docs.python.org/3/tutorial/appendix.html#executable-python-scripts) accordingly. 

Let's see what Mariatta says about these proposals. Thanks for noticing.

----------

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

From songofacandy at gmail.com  Sat Jan 28 19:57:58 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Sun, 29 Jan 2017 09:57:58 +0900
Subject: [docs] Creating issue tracker on github
Message-ID: <CAEfz+TzTapv=hYg3krgVM4tGsQJXwSnfUhU5XE+Om+xiQ3dJNQ@mail.gmail.com>

Hi,

Currently, we use Python's issue tracker for documentation bugs.
https://docs.python.org/3/bugs.html#documentation-bugs

But roundup is not easy to use for new people recent days.
I think Github's issue tracker is more friendly for users.

How about creating repository for document bug report?
Maybe, https://github.com/python/docs-issues or
https://github.com/python-docs/issues

Regards,

From report at bugs.python.org  Sat Jan 28 20:25:26 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 Jan 2017 01:25:26 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485653125.37.0.865688234551.issue29381@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Is Mariatta responsible for reviewing Documentation submissions?

No, she is a new core developer and this is a good issue for her to do the initial review and post any thoughts on the subject.  We've all got to start somewhere.

> If so, should I nosy Mariatta in any future documentation issues?

You did everything just right.  Just marking this as a doc patch is sufficient.

----------

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

From berker.peksag at gmail.com  Sun Jan 29 05:06:54 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Sun, 29 Jan 2017 13:06:54 +0300
Subject: [docs] Creating issue tracker on github
In-Reply-To: <CAEfz+TzTapv=hYg3krgVM4tGsQJXwSnfUhU5XE+Om+xiQ3dJNQ@mail.gmail.com>
References: <CAEfz+TzTapv=hYg3krgVM4tGsQJXwSnfUhU5XE+Om+xiQ3dJNQ@mail.gmail.com>
Message-ID: <CAF4280Krb9q6UZskrQ4Z2S56PkpF=JQs3CHO7tsb5Uy=4GGipQ@mail.gmail.com>

On Sun, Jan 29, 2017 at 3:57 AM, INADA Naoki <songofacandy at gmail.com> wrote:
> Hi,
>
> Currently, we use Python's issue tracker for documentation bugs.
> https://docs.python.org/3/bugs.html#documentation-bugs
>
> But roundup is not easy to use for new people recent days.
> I think Github's issue tracker is more friendly for users.
>
> How about creating repository for document bug report?
> Maybe, https://github.com/python/docs-issues or
> https://github.com/python-docs/issues

Please, no. There are already too much trackers to report a problem
and most of the time people find out the wrong one.
https://docs.python.org/3/bugs.html is already suggest an alternative
to bugs.p.o: send an email to this list.

--Berker

From report at bugs.python.org  Sun Jan 29 05:34:26 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jan 2017 10:34:26 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <20170129103424.123333.6349.24324A77@psf.io>


Roundup Robot added the comment:

New changeset ecdc864884a9 by Martin Panter in branch '3.5':
Issue #29349: Fix Python 2 syntax in documentation build code
https://hg.python.org/cpython/rev/ecdc864884a9

New changeset cdcb33f37bf3 by Martin Panter in branch '3.6':
Issues #29349: Merge Py 2 fix 3.5
https://hg.python.org/cpython/rev/cdcb33f37bf3

New changeset db8b917bbfdd by Martin Panter in branch 'default':
Issues #29349: Merge Py 2 fix 3.6
https://hg.python.org/cpython/rev/db8b917bbfdd

New changeset ca7d2af9920e by Martin Panter in branch 'default':
Issues #29349: Add NEWS for 3.7; use ?with? statement
https://hg.python.org/cpython/rev/ca7d2af9920e

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

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

From report at bugs.python.org  Sun Jan 29 05:34:28 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jan 2017 10:34:28 +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: <20170129103424.123333.86772.8400E46E@psf.io>


Roundup Robot added the comment:

New changeset 8c9a86aa222e by Martin Panter in branch '3.5':
Issue #12067: Recommend that hash and equality be consistent
https://hg.python.org/cpython/rev/8c9a86aa222e

New changeset 9702c5f08df1 by Martin Panter in branch '3.6':
Issues #12067: Merge hash recommendation from 3.5
https://hg.python.org/cpython/rev/9702c5f08df1

New changeset 9dbb7bbc1449 by Martin Panter in branch 'default':
Issues #12067: Merge hash recommendation from 3.6
https://hg.python.org/cpython/rev/9dbb7bbc1449

New changeset 8a9904c5cb1d by Martin Panter in branch '2.7':
Issue #12067: Rewrite Comparisons section in the language reference
https://hg.python.org/cpython/rev/8a9904c5cb1d

----------

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

From report at bugs.python.org  Sun Jan 29 05:53:31 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Jan 2017 10:53:31 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485687211.09.0.719648418291.issue29349@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the general rule is to clean up code if you are doing something else in nearby code, but don?t go out of your way with unnecessary cleanups to arbitrary code. Otherwise it adds too much noise to the repository history, review process, risks adding bugs, etc, for little gain.

Anyway, thanks for the patch!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 3.4

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

From report at bugs.python.org  Sun Jan 29 12:11:40 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Jan 2017 17:11:40 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485709900.48.0.744621228596.issue29349@psf.upfronthosting.co.za>


Ned Deily added the comment:

These changes have broken some buildbots, for example, the OS X dmg buildbots which are still using Python 2 for sphinx builds of the docs.  They should be version agnostic as much as possible.

http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/59

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

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

From report at bugs.python.org  Sun Jan 29 16:33:12 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Jan 2017 21:33:12 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485725592.73.0.186929268257.issue29349@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Ned. Do you know what version of Python Sphinx uses (which runs patchlevel.py)?

According to Issue 28039, David set up Python 2.7 so that ?make touch? would work. But the log also uses a python2.5 command, and apparently Python 2.3 also installed on that buildbot.

If we can rely on 2.6+, we just need to add ?from __future__ import print_function?. Otherwise, we may need something like

if sys.stderr is not None:
    sys.stderr.write(...)

and also do something about that ?with? statement.

----------
nosy: +db3l

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

From report at bugs.python.org  Sun Jan 29 16:39:50 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 29 Jan 2017 21:39:50 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485725990.13.0.146934139959.issue29349@psf.upfronthosting.co.za>


Ned Deily added the comment:

Dunno for sure, perhaps David can answer that.  But the Sphinx docs imply that Sphinx 1.4.6 requires at least 2.6 and I don't test the installer build with anything less than 2.7.

----------

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

From report at bugs.python.org  Sun Jan 29 16:40:30 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Jan 2017 21:40:30 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485726030.01.0.924903197101.issue29349@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to <https://bugs.python.org/issue17861#msg217417>, Ned says 2.6+ is already needed to build the Python 3.5 documentation, so maybe Sphinx uses that.

----------

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

From report at bugs.python.org  Sun Jan 29 17:28:46 2017
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Jan 2017 22:28:46 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485728926.47.0.599208119029.issue29349@psf.upfronthosting.co.za>


David Bolen added the comment:

2.7.12 (/usr/local/bin) is used for the build slave and main external commands (such as hg and sphinx) and is in the buildslave path, but 2.5.1 is still the default in /usr/bin so can get used for processes with a restricted environment.  Tiger's original 2.3 is present but unused.

The DMG build-installer script itself runs under 2.5.1, because it specifies "python2.5" in its command to the slave.  I believe that was originally added once the system 2.3 couldn't be used.

During the DMG construction process, a particular step might, I suppose use 2.5.1 or 2.7.12 depending on whether it's internal to the build script, something using the same executable as the script, a subprocess with limited path, or an independent utility (like sphinx) referencing 2.7.

I believe Ned's comment in issue 17861 about 2.6+ is a reference to the sphinx step, which is covered by the fact that sphinx is using the newer 2.7.12.

What appears to break in this specific case is some of the preparation - specifically the Makefile referencing patchlevel is running "python".  That should work (2.7.12) if it inherits the overall build slave environment (which has /usr/local/bin first) but I think the install script filters that, so it's probably getting the /usr/bin/python 2.5.1 version.

I've just changed the default /usr/bin/python to be 2.7 so external processes run by build-installer should get 2.7.  I don't think that will break anything else currently done on the machine, but I'll deal with any fallout if needed.  I'm rerunning build 59 now.

As in issue 28039 there's no immediate need to change the installer script itself, but since it's clearly the last hold out, I'll find some time to test that I've got any pre-requisites for it set up at which point the build master could be changed to remove the python2.5 reference.

----------

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

From report at bugs.python.org  Sun Jan 29 17:38:09 2017
From: report at bugs.python.org (David Bolen)
Date: Sun, 29 Jan 2017 22:38:09 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485729489.56.0.225283612547.issue29349@psf.upfronthosting.co.za>


David Bolen added the comment:

Whoops, I just realized that the patch still needs adjusting to be 2.x compatible, so obviously the extra build still won't work.

But at this point it should be safe to assume 2.6+ such as for the rest of the sphinx processing.

----------

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

From report at bugs.python.org  Sun Jan 29 18:48:17 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jan 2017 23:48:17 +0000
Subject: [docs] [issue11670] configparser read_file now iterates over f,
 docs still say it calls readline
In-Reply-To: <1301047699.5.0.476245530251.issue11670@psf.upfronthosting.co.za>
Message-ID: <20170129234814.50657.5948.0CD014A4@psf.io>


Roundup Robot added the comment:

New changeset e70882558a96 by Martin Panter in branch '3.5':
Issue #11670: readfp(fp) parameter name is different to read_file(f)
https://hg.python.org/cpython/rev/e70882558a96

New changeset e06de6f9cfe5 by Martin Panter in branch '3.6':
Issues #11670: Merge configparser doc from 3.5
https://hg.python.org/cpython/rev/e06de6f9cfe5

New changeset 6db0a62b6aa6 by Martin Panter in branch 'default':
Issues #11670: Merge configparser doc from 3.6
https://hg.python.org/cpython/rev/6db0a62b6aa6

----------

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

From report at bugs.python.org  Sun Jan 29 18:48:17 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 Jan 2017 23:48:17 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <20170129234814.50657.86680.670C576D@psf.io>


Roundup Robot added the comment:

New changeset 9880928ec962 by Martin Panter in branch '3.5':
Issue #29349: Use __future__ print_function; Sphinx may use Python 2.6+
https://hg.python.org/cpython/rev/9880928ec962

New changeset 1708afd284ff by Martin Panter in branch '3.6':
Issues #29349: Merge Py 2.6+ compatibility from 3.5
https://hg.python.org/cpython/rev/1708afd284ff

New changeset e50058ecd808 by Martin Panter in branch 'default':
Issues #29349: Merge Py 2.6+ compatibility from 3.6
https://hg.python.org/cpython/rev/e50058ecd808

----------

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

From report at bugs.python.org  Sun Jan 29 18:53:58 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Jan 2017 23:53:58 +0000
Subject: [docs] [issue29387] Tabs vs spaces FAQ out of date
Message-ID: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za>


New submission from Martin Panter:

The Windows FAQ <https://docs.python.org/release/3.5.2/faq/windows.html#how-do-i-keep-editors-from-inserting-tabs-into-my-python-source> mentions the ?python -t? command-line option, but in Python 3 this option is undocumented (and I understand has no effect):

/media/disk/home/proj/python/cpython/Doc/faq/windows.rst:303: WARNING: unknown option: -t

Also, the reference to the tabnanny script is wrong. It exists as a module (Lib/tabnanny.py), not in Tools/scripts/. This aspect also applies to 2.7.

----------
assignee: docs at python
components: Documentation, Windows
files: tabnanny.patch
keywords: patch
messages: 286460
nosy: docs at python, martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Tabs vs spaces FAQ out of date
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46450/tabnanny.patch

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

From report at bugs.python.org  Sun Jan 29 18:57:29 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 Jan 2017 23:57:29 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485734249.88.0.183192352206.issue29349@psf.upfronthosting.co.za>


Martin Panter added the comment:

I pushed the simpler 2.6-compatible option. Keeping this open to check the buildbot is happy overnight.

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

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

From report at bugs.python.org  Sun Jan 29 21:13:42 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Jan 2017 02:13:42 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485742422.17.0.130984260474.issue29381@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

There are certain rules about the encoding declaration line.
It has to be the first line of the source code, or in the case that the file starts with a unix "shebang" line, then the encoding declaration has to be on the second line. In fact, the first or the second lines of the source code has to follow a certain regular expression. This is all described in PEP 263, but we don't have to repeat all of those here. IMO we can just refer the reader to the PEP.

I've prepared a patch that addresses this. Please review, and let me know if you have additional feedback.

Thanks :)

----------
Added file: http://bugs.python.org/file46452/issue29381.patch

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

From report at bugs.python.org  Sun Jan 29 22:03:02 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 Jan 2017 03:03:02 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485745382.29.0.127450019319.issue29381@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Suggestions:

* Please add a cross-link to from '''UNIX ?shebang? line"''' to 16.1.2. Executable Python Scripts.

* Instead of a link to a PEP (which is outside the main documentation), let's just add an example:

   # /usr/bin/env python3
   # -*- coding: cp-1252 -*-

----------

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

From report at bugs.python.org  Sun Jan 29 22:33:40 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 30 Jan 2017 03:33:40 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485747220.53.0.614995865534.issue29381@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks for the feedback, Raymond. I adjusted my patch.

----------
Added file: http://bugs.python.org/file46453/issue29381v2.patch

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

From report at bugs.python.org  Mon Jan 30 04:02:05 2017
From: report at bugs.python.org (Shmuel Amar)
Date: Mon, 30 Jan 2017 09:02:05 +0000
Subject: [docs] [issue29389] math.isclose signature contains incorrect start
 parameter
Message-ID: <1485766925.53.0.41080948643.issue29389@psf.upfronthosting.co.za>


New submission from Shmuel Amar:

documentation of math.isclose() signature on https://docs.python.org/3/library/math.html#math.isclose is as follows:

    math.isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0)

the third star '*' argument is not allowed inside the function: 
https://hg.python.org/cpython/file/tip/Modules/clinic/mathmodule.c.h#l511

or mentioned in PEP485 here: https://www.python.org/dev/peps/pep-0485/#implementation

and does not work when trying provide more than 2 positional values:

>>> import math
>>> math.isclose(1,2,3, rel_tol=5.)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Function takes at most 2 positional arguments (3 given)

So IMHO to solve this remove the positional argument on the signature of isclose() as it misleading.

----------
assignee: docs at python
components: Documentation
messages: 286474
nosy: Shmuel Amar, docs at python
priority: normal
severity: normal
status: open
title: math.isclose signature contains incorrect start parameter
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Jan 30 04:03:45 2017
From: report at bugs.python.org (Shmuel Amar)
Date: Mon, 30 Jan 2017 09:03:45 +0000
Subject: [docs] [issue29389] math.isclose signature contains incorrect start
 parameter
In-Reply-To: <1485766925.53.0.41080948643.issue29389@psf.upfronthosting.co.za>
Message-ID: <1485767025.21.0.817398920861.issue29389@psf.upfronthosting.co.za>


Shmuel Amar added the comment:

documentation of math.isclose() signature on https://docs.python.org/3/library/math.html#math.isclose is as follows:

    math.isclose(a, b, *, rel_tol=1e-09, abs_tol=0.0)

the third star '*' argument is not allowed inside the function: 
https://hg.python.org/cpython/file/tip/Modules/clinic/mathmodule.c.h#l511

or mentioned in PEP485 here: https://www.python.org/dev/peps/pep-0485/#implementation

and does not work when trying provide more than 2 positional values:

>>> import math
>>> math.isclose(1,2,3, rel_tol=5.)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Function takes at most 2 positional arguments (3 given)

So IMHO to solve this remove the positional argument on the signature of isclose() as it misleading.

----------

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

From report at bugs.python.org  Mon Jan 30 04:06:27 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 30 Jan 2017 09:06:27 +0000
Subject: [docs] [issue29389] math.isclose signature contains incorrect start
 parameter
In-Reply-To: <1485766925.53.0.41080948643.issue29389@psf.upfronthosting.co.za>
Message-ID: <1485767187.73.0.152162258163.issue29389@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I think you're misreading the signature. The '*' is not a parameter in its own right; it's a piece of syntax marking the end of the positional parameters. Everything following that can only be passed by keyword.  See PEP 3102 for an explanation of the syntax.

----------
nosy: +mark.dickinson

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

From report at bugs.python.org  Mon Jan 30 04:09:54 2017
From: report at bugs.python.org (Shmuel Amar)
Date: Mon, 30 Jan 2017 09:09:54 +0000
Subject: [docs] [issue29389] math.isclose signature contains incorrect start
 parameter
In-Reply-To: <1485766925.53.0.41080948643.issue29389@psf.upfronthosting.co.za>
Message-ID: <1485767394.4.0.707683484013.issue29389@psf.upfronthosting.co.za>


Shmuel Amar added the comment:

ok thanks i think it can be closed

----------

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

From songofacandy at gmail.com  Mon Jan 30 04:21:57 2017
From: songofacandy at gmail.com (INADA Naoki)
Date: Mon, 30 Jan 2017 18:21:57 +0900
Subject: [docs] [Python-ideas] https://docs.python.org/fr/ ?
In-Reply-To: <56ED7EBD.5050804@palard.fr>
References: <56ED7EBD.5050804@palard.fr>
Message-ID: <CAEfz+Txw+oh_rP1j4nCEpOzbvEmEU+Z8f8wgEqO7V3yd8HuwzA@mail.gmail.com>

There are some updates about this topic.
 And I have something to discuss to get things forward.

We (Japanese translation team) and Julien start sharing one Transifex project.
Please see this dashboard.  We have nice progress.
https://www.transifex.com/python-doc/python-35/dashboard/

Julien want hosting french documentation at https://docs.python.org/fr/
I don't have strong opinion about where to hosting, but I want to share
more efforts (automated build + hosting) with Julien and other language
communities.

Since Berker Peksag against about hosting translated document on
docs.python.org [1], I'm considering about using github pages.

I got "python-docs" organization already for it [2].  So translated documents
can be hosted on URL like https://python-docs.github.io/py35-ja/ or
https://python-docs.github.io/py35/fr/ .  (first part of the path
should be same to
repository name).

I already uses github pages for testing Japanese translation [3].
It's nice place to host webpage.  We can get https and CDN for free.

[1]: https://github.com/python/docsbuild-scripts/pull/8
[2]: https://github.com/python-docs
[3]: https://python-doc-ja.github.io/py35/


So I want to discuss (and get consensus) about where should we host
translated document.

a) translated docs on docs.python.org / issue tracker on github.com/python-docs/
b) translated docs on python-docs.github.io / issue tracker on
github.com/python-docs/
c) We shouldn't use neither "python-docs" nor "docs.python.org".
Translation should be in other community.
d) Other idea?

What do you think?


Regards,

On Sun, Mar 20, 2016 at 1:30 AM, Julien Palard <julien at palard.fr> wrote:
> o/
>
> The french translation of the Python Documentation [1][2] has translated 20%
> of the pageviews of docs.python.org. I think it's the right moment to push
> it do docs.python.org. So there's some questions ! And I'd like feedback.
>
> TL;DR (with my personal choices):
>  - URL may be "http://docs.python.org/fr/"
>  - For localized variations of languages we should use dash and lowercase
> like "docs.python.org/pt-br/"
>  - po files may be hosted on the python's github
>  - existing script to build doc may be patched to build translations
>  - each translations may crosslink to others
>  - untranslated strings may be visually marked as so
>
> I also opened: http://bugs.python.org/issue26546.
>
> # Chronology, dependencies
>
> The only blocking decision here is the URL, (also reviewing my patch ...),
> with those two, translated docs can be pushed to production, and the other
> steps can be discussed and applied one by one.
>
> # The URL
>
> ## CCTLD vs path vs subdomain
>
> I think we should use a variation of "docs.python.org/fr/" for simplicity
> and clarity.
>
> I think we should avoid using CCTLDs as they're sometime hard or near
> impossible to obtain (may cost a lot of time), also some are expensive, so
> it's time and money we clearly don't need to loose.
>
> Last possibility I see is to use a subdomain, like fr.docs.python.org or
> docs.fr.python.org but I don't think it's the role / responsibility of the
> sub-domain to do it.
>
> So I'm for docs.python.org/LANGUAGE_TAG/ (without moving current
> documentation inside a /en/).
>
> ## Language tag in path
>
> ### Dropping the default locale of a language
>
> I personally think we should not show the region in case it's redundant: so
> to use "fr" instead of "fr-FR", "de" instead of "de-DE", but keeping the
> possibility to use a locale code when it's not redundant like for "pt-br" or
> "de-AT" (German ('de') as used in Austria ('AT')).
>
> I think so because I don't think we'll have a lot of locale variations (like
> de-AT, fr-CH, fr-CA, ...) so it will be most of the time redundant (visually
> heavy, longer to type, longer to read) but we'll still need some locale
> (pt-BR typically).
>
> ### gettext VS IETF language tag format
>
> gettext goes by using an underscore between language and locale [3] and IETF
> goes by using a dash [4][5].
>
> As sphinx is using gettext, and gettext uses underscore we may choose
> underscore too. But URLs are not here to leak the underlying implementation,
> and the IETF looks like to be the standard way to represent language tags.
> Also I visually prefer the dash over the underscore, so I'm for the dash
> here.
>
> ### Lower case vs upper case local tag
>
> RFC 5646 section-2.1 tells us language tags are not case sensitive, yet
> ISO3166-1 recommends that country codes (part of the language tag) be
> capitalized. I personally prefer the all-lowercase one as paths in URLs
> typically are lowercase. I searched for `inurl:"pt-br"` to see if I'm not
> too far away from the usage here and usage seems to agree with me, although
> there's some "pt-BR" in urls.
>
> # Where to host the translated files
>
> Currently we're hosting the *po* files in the afpy's (Francophone
> association for python) [6] github [1] but it may make sense to use (in the
> generation scripts) a more controlled / restricted clone in the python
> github, at least to have a better view of who can push on the documentation.
>
> We may want to choose between aggregating all translations under the same
> git repository but I don't feel it's useful.
>
> # How to
>
> Currently, a python script [7] is used to generate `docs.python.org`, I
> proposed a patch in [8] to make this script clone and build the french
> translation too, it's a simple and effective way, I don't think we need more
> ? Any idea welcome.
>
> In our side, we have a Makefile [12] to build the translated doc which is
> only a thin layer on top of the Sphinx Makefile. So my proposed patch to
> build scripts "just" delegate the build to our Makefile which itself
> delegate the hard work to the Sphinx Makefile.
>
> # Next ?
>
> ## Document how to translate Python
>
> I think I can (should) write a documentation on "how to start a Python doc
> translation project" and "how to migrate existing [9][10][11] python doc
> translation projects to docs.python.org" if french does goes docs.python.org
> because it may hopefully motivate people to do the same, and I think our
> structure is a nice way to do it (A Makefile to generate the doc, all
> versions translated, people mainly working on latest version, scripts to
> propagating translations to older version, etc...).
>
> ## Crosslinking between existing translations
>
> Once the translations are on `docs.python.org`, crosslinks may be
> established so people on a version can be aware of other version, and easily
> switch to them. I'm not a UI/UX man but I think we may have a select box
> right before the existing select box about version, on the top-left corner.
> Right before because it'll reflect the path: /fr/3.5/ -> [select box
> fr][select box 3.5].
>
> ## Marking as "untranslated, you can help" the untranslated paragraphs
>
> The translations will always need work to follow upstream modifications:
> marking untranslated paragraphs as so may transform the "Oh they suck, this
> paragraph is not even translated :-(" to "Hey, nice I can help translating
> that !". There's an opened sphinx-doc ticket to do so [13] but I have not
> worked on it yet. As previously said I'm real bad at designing user
> interfaces, so I don't even visualize how I'd like it to be.
>
>
> [1] http://www.afpy.org/doc/python/3.5/
> [2] https://github.com/afpy/python_doc_fr
> [3] https://www.gnu.org/software/gettext/manual/html_node/Locale-Names.html
> [4] http://tools.ietf.org/html/rfc5646
> [5] https://en.wikipedia.org/wiki/IETF_language_tag
> [6] http://www.afpy.org/
> [7] https://github.com/python/docsbuild-scripts/
> [8] http://bugs.python.org/issue26546
> [9] http://docs.python.jp/3/
> [10] https://github.com/python-doc-ja/python-doc-ja
> [11] http://docs.python.org.ar/tutorial/3/index.html
> [12] https://github.com/AFPy/python_doc_fr/blob/master/Makefile
> [13] https://github.com/sphinx-doc/sphinx/issues/1246
>
> --
> Julien Palard
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

From report at bugs.python.org  Mon Jan 30 05:05:10 2017
From: report at bugs.python.org (Michael Kesper)
Date: Mon, 30 Jan 2017 10:05:10 +0000
Subject: [docs] [issue29390] Python Tutorial should introduce iterators and
 generators
Message-ID: <1485770709.65.0.205484403801.issue29390@psf.upfronthosting.co.za>


New submission from Michael Kesper:

Please look at http://stackoverflow.com/questions/41932287/how-can-i-create-a-loop-for-these-if-statements/41932494?noredirect=1#41932494 

For beginners, it would be good to introduce the concepts of 'pythonic' dealing with sequences (iterators) and streams (generators) as soon as possible and everywhere where sequenceable data structures are discussed.

It is a common idiom in other languages to access members of sequences with counters, risking off-by-one errors or IndexErrors.

If beginners aren't introduced to the 'right' concepts soon enough, they might have a hard time figuring out the 'iterator' way.
Iterators should at least be mentioned in https://docs.python.org/3/tutorial/datastructures.html#looping-techniques.

----------
assignee: docs at python
components: Documentation
messages: 286480
nosy: docs at python, mkesper
priority: normal
severity: normal
status: open
title: Python Tutorial should introduce iterators and generators
type: enhancement

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

From report at bugs.python.org  Mon Jan 30 05:17:23 2017
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 30 Jan 2017 10:17:23 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485771443.4.0.133643776315.issue29381@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The patch LGTM. I think there is just one type (see review). 

By the way, looking at the PEP 0263, the sentence "To define a source code encoding, a magic comment must be placed into the source files either as first or second line in the file" actually is not true. Also because I did not see any point in the PEP that clarifies that the fist line has to be a comment. Maybe it could be deduced by the examples (all using the shebang), but maybe not, and the user could think this is a valid declaration:

print('tr?s jolie')
# -*- coding: ascii -*-

If you think is worth to clarify, I open an issue with a patch for the PEP 0263.

----------

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

From report at bugs.python.org  Mon Jan 30 05:45:14 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 30 Jan 2017 10:45:14 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>
Message-ID: <1485773114.48.0.822987739457.issue29247@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Nathaniel. I agree that the documentation could be improved. Here is a patch. I also moved the constant table to epoll.register() documentation (it's already done in https://docs.python.org/3.7/library/select.html#polling-objects)

It would be great if you could review the patch, thanks!

----------
keywords: +patch
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement
Added file: http://bugs.python.org/file46454/issue29247.diff

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

From report at bugs.python.org  Mon Jan 30 06:37:44 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 30 Jan 2017 11:37:44 +0000
Subject: [docs] [issue29390] Python Tutorial should introduce iterators and
 generators
In-Reply-To: <1485770709.65.0.205484403801.issue29390@psf.upfronthosting.co.za>
Message-ID: <1485776264.88.0.50322214077.issue29390@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

What change do you have in mind for introducing these?

As for my personal opinion, dunno about this. I understand your concerns but dropping more terminology to a new learner early on wouldn't be the best idea in my view. 

>From what I am aware, Python is not becoming one of the *first* languages people learn due to its friendly nature. Adding concepts like generators and iterators when a new user is struggling with appends and mutability doesn't seem like it would help. 

BTW, iterators and generators are discussed in the Classes section of the tutorial, don't you think this suffices?

----------
nosy: +Jim Fasarakis-Hilliard

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

From report at bugs.python.org  Mon Jan 30 06:38:14 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 30 Jan 2017 11:38:14 +0000
Subject: [docs] [issue29390] Python Tutorial should introduce iterators and
 generators
In-Reply-To: <1485770709.65.0.205484403801.issue29390@psf.upfronthosting.co.za>
Message-ID: <1485776294.1.0.419220997034.issue29390@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Typo, is *now* becoming :-)

----------

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

From marco.buttu at gmail.com  Mon Jan 30 06:53:12 2017
From: marco.buttu at gmail.com (marco.buttu at gmail.com)
Date: Mon, 30 Jan 2017 11:53:12 -0000
Subject: [docs] Document return value of epoll.poll (issue 29247)
Message-ID: <20170130115312.1159.89557@psf.upfronthosting.co.za>


https://bugs.python.org/review/29247/diff/19866/Doc/library/select.rst
File Doc/library/select.rst (right):

https://bugs.python.org/review/29247/diff/19866/Doc/library/select.rst#newcode346
Doc/library/select.rst:346: Wait for events. *timeout* in seconds
(float)  Return a list of
On 2017/01/30 12:39:39, marco.buttu wrote:
> Is there a missing dot after (float)? I mean: "...in seconds (float).
Return a
> list

Maybe it is worth indicating that timeout=-1 makes poll wait
indefinitely. What about: "...*timeout* in seconds (float), and
``timeout=-1`` makes poll wait indefinitely. Return..." ?

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

From report at bugs.python.org  Mon Jan 30 06:55:50 2017
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 30 Jan 2017 11:55:50 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>
Message-ID: <1485777350.67.0.554230348871.issue29247@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The patch LGTM. There is just one typo, I think (see review).

----------
nosy: +marco.buttu

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

From berker.peksag at gmail.com  Mon Jan 30 07:13:36 2017
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Mon, 30 Jan 2017 12:13:36 -0000
Subject: [docs] Document return value of epoll.poll (issue 29247)
Message-ID: <20170130121336.31714.57974@psf.upfronthosting.co.za>

On 2017/01/30 12:39:39, marco.buttu wrote:
> https://bugs.python.org/review/29247/diff/19866/Doc/library/select.rst
> File Doc/library/select.rst (right):
> 
>
https://bugs.python.org/review/29247/diff/19866/Doc/library/select.rst#newcode346
> Doc/library/select.rst:346: Wait for events. *timeout* in seconds
(float) 
> Return a list of
> Is there a missing dot after (float)? I mean: "...in seconds (float).
Return a
> list

I agree that the current wording is not ideal. What about

   If *timeout* is a float then the call waits for at most that many
seconds.
   If *timeout* is -1 (the default) then it will wait for an unlimited
period.

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

From report at bugs.python.org  Mon Jan 30 07:14:29 2017
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 30 Jan 2017 12:14:29 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485778469.49.0.114687305482.issue29381@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Added a comment too. Other than that and the comment by Marco it looks fine to me too.

----------

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

From marco.buttu at gmail.com  Mon Jan 30 07:55:49 2017
From: marco.buttu at gmail.com (marco.buttu at gmail.com)
Date: Mon, 30 Jan 2017 12:55:49 -0000
Subject: [docs] Document return value of epoll.poll (issue 29247)
Message-ID: <20170130125549.1159.86789@psf.upfronthosting.co.za>

On 2017/01/30 13:13:36, berkerpeksag wrote:
> 
> I agree that the current wording is not ideal. What about
> 
>    If *timeout* is a float then the call waits for at most that many
seconds.
>    If *timeout* is -1 (the default) then it will wait for an unlimited
period.

The patch you attached is fine to me. I was just pointing out that there
is a missing dot after "(float)". If in addition you integrate with your
last sentence (If *timeout* is -1 (the default) then it will wait for an
unlimited period.), maybe it would also be better.

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

From 01patrickliu at gmail.com  Sun Jan 29 13:31:19 2017
From: 01patrickliu at gmail.com (=?UTF-8?B?5YqJ5qyK6Zme?=)
Date: Mon, 30 Jan 2017 02:31:19 +0800
Subject: [docs] I hope you can build a platform for studying in Traditional
 Chinese.Please
Message-ID: <CAB2Y5Ux=S+j6QrLjv4jbC+Wv13wGU6gY-Cy8RirZHw6aycs1Jw@mail.gmail.com>

Hello: I am the student in junior high school.I would like to learn python,
but there are few traditional Chinese resources on the website, especially
the Python's documents are all in English I can not read it.(
https://docs.python.org/2/)
I hope you can build a platform for studying in Traditional Chinese.Please
Thank yo  very much.
(Taiwan and China are different, the language is also,Taiwan is traditional
Chinese,China is Simplified Chinese)



patrick liu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170130/3bea9a42/attachment.html>

From berker.peksag at gmail.com  Mon Jan 30 08:36:32 2017
From: berker.peksag at gmail.com (berker.peksag at gmail.com)
Date: Mon, 30 Jan 2017 13:36:32 -0000
Subject: [docs] Document return value of epoll.poll (issue 29247)
Message-ID: <20170130133632.1159.40620@psf.upfronthosting.co.za>

On 2017/01/30 13:55:49, marco.buttu wrote:
> On 2017/01/30 13:13:36, berkerpeksag wrote:
> > 
> > I agree that the current wording is not ideal. What about
> > 
> >    If *timeout* is a float then the call waits for at most that many
seconds.
> >    If *timeout* is -1 (the default) then it will wait for an
unlimited period.
> 
> The patch you attached is fine to me. I was just pointing out that
there is a
> missing dot after "(float)". If in addition you integrate with your
last
> sentence (If *timeout* is -1 (the default) then it will wait for an
unlimited
> period.), maybe it would also be better.

You probably right about the typo (I haven't checked yet and I'm not
really good with punctuation rules in English :)), but even if we fix
that typo, current wording doesn't exactly conform with our general
documentation guidelines so I wanted to rewrite the whole sentence.

Thanks for the review!

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

From berker.peksag at gmail.com  Mon Jan 30 10:08:39 2017
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Mon, 30 Jan 2017 18:08:39 +0300
Subject: [docs] [Python-ideas] https://docs.python.org/fr/ ?
In-Reply-To: <CAEfz+Txw+oh_rP1j4nCEpOzbvEmEU+Z8f8wgEqO7V3yd8HuwzA@mail.gmail.com>
References: <56ED7EBD.5050804@palard.fr>
 <CAEfz+Txw+oh_rP1j4nCEpOzbvEmEU+Z8f8wgEqO7V3yd8HuwzA@mail.gmail.com>
Message-ID: <CAF4280J-0cS7wU31qwCG_axGF-CmQ-iA3j1NGkRExY0ZgfN3sA@mail.gmail.com>

On Mon, Jan 30, 2017 at 12:21 PM, INADA Naoki <songofacandy at gmail.com> wrote:
> There are some updates about this topic.
>  And I have something to discuss to get things forward.
>
> We (Japanese translation team) and Julien start sharing one Transifex project.
> Please see this dashboard.  We have nice progress.
> https://www.transifex.com/python-doc/python-35/dashboard/
>
> Julien want hosting french documentation at https://docs.python.org/fr/
> I don't have strong opinion about where to hosting, but I want to share
> more efforts (automated build + hosting) with Julien and other language
> communities.
>
> Since Berker Peksag against about hosting translated document on
> docs.python.org [1], I'm considering about using github pages.
>
> I got "python-docs" organization already for it [2].  So translated documents
> can be hosted on URL like https://python-docs.github.io/py35-ja/ or
> https://python-docs.github.io/py35/fr/ .  (first part of the path
> should be same to
> repository name).
>
> I already uses github pages for testing Japanese translation [3].
> It's nice place to host webpage.  We can get https and CDN for free.
>
> [1]: https://github.com/python/docsbuild-scripts/pull/8
> [2]: https://github.com/python-docs
> [3]: https://python-doc-ja.github.io/py35/
>
>
> So I want to discuss (and get consensus) about where should we host
> translated document.
>
> a) translated docs on docs.python.org / issue tracker on github.com/python-docs/
> b) translated docs on python-docs.github.io / issue tracker on
> github.com/python-docs/

+1 for b) or any idea that would indicate that the Python developers
don't maintain translations of the official documentation. I don't
have a strong opinion on naming the GitHub organization (maybe
python-docs-translations?) but that can be discussed later. Another
advantage of this approach is that you can have separate issue
trackers for each language (e.g. python-docs-fr) so people can easily
report documentation issues in their native languages.

--Berker

From report at bugs.python.org  Mon Jan 30 13:08:11 2017
From: report at bugs.python.org (Ned Deily)
Date: Mon, 30 Jan 2017 18:08:11 +0000
Subject: [docs] [issue29349] Update old Python 2 code in
 Docs/tools/extensions/patchlevel.py
In-Reply-To: <1485164481.25.0.457345760711.issue29349@psf.upfronthosting.co.za>
Message-ID: <1485799691.17.0.345888385228.issue29349@psf.upfronthosting.co.za>


Ned Deily added the comment:

The fix looks good and the dmg buildbots are happy again.  Thanks, Martin and David.

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

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

From report at bugs.python.org  Mon Jan 30 13:40:32 2017
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jan 2017 18:40:32 +0000
Subject: [docs] [issue22594] Add a link to the regex module in re
 documentation
In-Reply-To: <1412927285.57.0.392292696343.issue22594@psf.upfronthosting.co.za>
Message-ID: <1485801632.04.0.859293394805.issue22594@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> brett.cannon
nosy: +brett.cannon

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

From report at bugs.python.org  Mon Jan 30 15:41:11 2017
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 30 Jan 2017 20:41:11 +0000
Subject: [docs] [issue29389] math.isclose signature contains incorrect start
 parameter
In-Reply-To: <1485766925.53.0.41080948643.issue29389@psf.upfronthosting.co.za>
Message-ID: <1485808871.38.0.798389204495.issue29389@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 30 20:45:02 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 31 Jan 2017 01:45:02 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485827101.93.0.810237540249.issue29381@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks all for the feedback. I updated the patch.

Marco, IMO it's not necessary to update the PEP.
This section of the documentation serves as a tutorial for it, and the update in this patch clarifies the situation.

----------
Added file: http://bugs.python.org/file46458/issue29381v3.patch

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

From report at bugs.python.org  Mon Jan 30 22:22:15 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Jan 2017 03:22:15 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485832935.22.0.583137169133.issue29381@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It looks like everyone is happy and the patch is ready for Mariatta to apply.

The procedure is:
 $ hg pull -u
 $ hg diff                      # Verify it has only your intended patch
 $ hg update 3.6
 $ cd Doc
 $ make html
 $ open build/html/index.html   # Now review generated HTML
 $ hg commit -m "Issue #29381: Clarify ordering of UNIX shebang line as source encoding line"
 $ hg update default
 $ hg merge 3.6
 $ hg diff                      # Verify it has only your intended patch
 $ hg commit -m "merge"
 $ hg push

Then return to this issue, verify the bot has posted the commit.

Write a comment thanking the OP and reviewers.  Then mark the status as "closed" and resolution as "fixed".

----------

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

From report at bugs.python.org  Mon Jan 30 22:23:42 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Jan 2017 03:23:42 +0000
Subject: [docs] [issue29381] Tutorial documentation contains undefined
 reference to #!
In-Reply-To: <1485537602.74.0.811037724367.issue29381@psf.upfronthosting.co.za>
Message-ID: <1485833022.45.0.707673420291.issue29381@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would only post this to 2.7, 3.6 and 3.7.   Also, no Misc/NEWS entry is needed.

----------
versions:  -Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 30 22:41:57 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 31 Jan 2017 03:41:57 +0000
Subject: [docs] [issue29390] Python Tutorial should introduce iterators and
 generators
In-Reply-To: <1485770709.65.0.205484403801.issue29390@psf.upfronthosting.co.za>
Message-ID: <1485834117.67.0.643637751939.issue29390@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

IMO, the iterators are introduced at the correct point.  

There are many topics that one could argue should be introduced early, but of course they can't all go earlier (classes should be introduced earlier because everything in python is an object; namespaces should be introduced earlier because they are core concept that affects everything from function locals, to closures, classes, instances, and modules).

I concur with Jim that dropping more terminology earlier in the tutorial doesn't serve the user well.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

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

From brett at python.org  Mon Jan 30 13:03:43 2017
From: brett at python.org (Brett Cannon)
Date: Mon, 30 Jan 2017 18:03:43 +0000
Subject: [docs] [Python-ideas]  https://docs.python.org/fr/ ?
In-Reply-To: <CAF4280J-0cS7wU31qwCG_axGF-CmQ-iA3j1NGkRExY0ZgfN3sA@mail.gmail.com>
References: <56ED7EBD.5050804@palard.fr>
 <CAEfz+Txw+oh_rP1j4nCEpOzbvEmEU+Z8f8wgEqO7V3yd8HuwzA@mail.gmail.com>
 <CAF4280J-0cS7wU31qwCG_axGF-CmQ-iA3j1NGkRExY0ZgfN3sA@mail.gmail.com>
Message-ID: <CAP1=2W5AxCj7V-Gnq-Dj4hmXJouL3m5=gneDk784x9==LLutPg@mail.gmail.com>

On Mon, 30 Jan 2017 at 07:16 Berker Peksa? <berker.peksag at gmail.com> wrote:

> On Mon, Jan 30, 2017 at 12:21 PM, INADA Naoki <songofacandy at gmail.com>
> wrote:
> > There are some updates about this topic.
> >  And I have something to discuss to get things forward.
> >
> > We (Japanese translation team) and Julien start sharing one Transifex
> project.
> > Please see this dashboard.  We have nice progress.
> > https://www.transifex.com/python-doc/python-35/dashboard/
> >
> > Julien want hosting french documentation at https://docs.python.org/fr/
> > I don't have strong opinion about where to hosting, but I want to share
> > more efforts (automated build + hosting) with Julien and other language
> > communities.
> >
> > Since Berker Peksag against about hosting translated document on
> > docs.python.org [1], I'm considering about using github pages.
> >
> > I got "python-docs" organization already for it [2].  So translated
> documents
> > can be hosted on URL like https://python-docs.github.io/py35-ja/ or
> > https://python-docs.github.io/py35/fr/ .  (first part of the path
> > should be same to
> > repository name).
> >
> > I already uses github pages for testing Japanese translation [3].
> > It's nice place to host webpage.  We can get https and CDN for free.
> >
> > [1]: https://github.com/python/docsbuild-scripts/pull/8
> > [2]: https://github.com/python-docs
> > [3]: https://python-doc-ja.github.io/py35/
> >
> >
> > So I want to discuss (and get consensus) about where should we host
> > translated document.
> >
> > a) translated docs on docs.python.org / issue tracker on
> github.com/python-docs/
> > b) translated docs on python-docs.github.io / issue tracker on
> > github.com/python-docs/
>
> +1 for b) or any idea that would indicate that the Python developers
> don't maintain translations of the official documentation. I don't
> have a strong opinion on naming the GitHub organization (maybe
> python-docs-translations?) but that can be discussed later. Another
> advantage of this approach is that you can have separate issue
> trackers for each language (e.g. python-docs-fr) so people can easily
> report documentation issues in their native languages.
>

Does hosting on Read the Docs makes any of this easier/harder?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170130/6d62de37/attachment.html>

From report at bugs.python.org  Tue Jan 31 10:09:51 2017
From: report at bugs.python.org (Marco Buttu)
Date: Tue, 31 Jan 2017 15:09:51 +0000
Subject: [docs] [issue29387] Tabs vs spaces FAQ out of date
In-Reply-To: <1485734038.81.0.0566253928841.issue29387@psf.upfronthosting.co.za>
Message-ID: <1485875391.91.0.805629095667.issue29387@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Hi Martin, why did you write "Python should report an error if mixed tabs and spaces are causing problems in leading whitespace."? 
Python for sure reports an error in that case. 

Maybe "Python reports an error if..." is a better choice. But my English is really poor, so I can be wrong... I have just this doubt, otherwise the patch is OK to me.

----------
nosy: +marco.buttu

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

From report at bugs.python.org  Tue Jan 31 11:15:23 2017
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 31 Jan 2017 16:15:23 +0000
Subject: [docs] [issue29329] Incorrect documentation for custom `hex()`
 support on Python 2
In-Reply-To: <1484852138.82.0.311515909069.issue29329@psf.upfronthosting.co.za>
Message-ID: <1485879323.11.0.32201853538.issue29329@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Attached patch changes the py2.7 documentation to point out that the method name is __hex__ and its return type is a string.

----------
keywords: +patch
nosy: +ammar2
Added file: http://bugs.python.org/file46466/hex_method.diff

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

From report at bugs.python.org  Tue Jan 31 15:10:17 2017
From: report at bugs.python.org (Gerrit Holl)
Date: Tue, 31 Jan 2017 20:10:17 +0000
Subject: [docs] [issue29401] Python3.6 docs should not have a "what's new in
 Python 3.7" page
Message-ID: <1485893417.06.0.864310985594.issue29401@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

I believe this page is not supposed to exist:

https://docs.python.org/3.6/whatsnew/3.7.html

Nor this one:

https://docs.python.org/3.5/whatsnew/3.6.html

Neither are maintained, nor would I expect them to be.

----------
assignee: docs at python
components: Documentation
messages: 286549
nosy: Gerrit.Holl, docs at python
priority: normal
severity: normal
status: open
title: Python3.6 docs should not have a "what's new in Python 3.7" page
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jan 31 15:39:13 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Jan 2017 20:39:13 +0000
Subject: [docs] [issue29401] Python3.6 docs should not have a "what's new in
 Python 3.7" page
In-Reply-To: <1485893417.06.0.864310985594.issue29401@psf.upfronthosting.co.za>
Message-ID: <1485895153.34.0.835800179374.issue29401@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report.  Those two files should disappear soon.

----------
nosy: +ned.deily
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Tue Jan 31 16:15:42 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 31 Jan 2017 21:15:42 +0000
Subject: [docs] [issue29401] Python3.6 docs should not have a "what's new in
 Python 3.7" page
In-Reply-To: <1485893417.06.0.864310985594.issue29401@psf.upfronthosting.co.za>
Message-ID: <1485897342.88.0.311938259622.issue29401@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved
status: pending -> closed

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

From report at bugs.python.org  Tue Jan 31 20:09:07 2017
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Feb 2017 01:09:07 +0000
Subject: [docs] [issue29407] Remove redundant ensure_future() calls in
 factorial example
Message-ID: <1485911347.12.0.0497985806483.issue29407@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Unless I'm missing something, ensure_future() calls at https://docs.python.org/3.6/library/asyncio-task.html#example-parallel-execution-of-tasks are redundant and can be removed.

Off-topic: Can we use the async/await keywords in asyncio docs now?

----------
assignee: docs at python
components: Documentation, asyncio
files: ensure_future.diff
keywords: patch
messages: 286576
nosy: berker.peksag, docs at python, gvanrossum, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Remove redundant ensure_future() calls in factorial example
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46471/ensure_future.diff

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

From edorum at cisco.com  Tue Jan 31 10:28:25 2017
From: edorum at cisco.com (Einar Dorum (edorum))
Date: Tue, 31 Jan 2017 15:28:25 +0000
Subject: [docs] "31.5.6.3. Importing a source file directly" talks about the
 wrong version of Python
Message-ID: <1485876484259.20886@cisco.com>

In the documentation for importlib under "31.5.6.3. Importing a source file directly" the documentation says Python 3.4 and newer only.

But importlib.util.module_from_spec was introduced in 3.5, which means the code doesn't work in 3.4 but only in 3.5 and later.

So the text should say 3.5 instead of 3.4.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20170131/691e7e17/attachment.html>