From report at bugs.python.org  Fri Dec  1 00:22:05 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Dec 2017 05:22:05 +0000
Subject: [docs] [issue32190] Separate out legacy introspection APIs in the
 inspect docs
Message-ID: <1512105725.63.0.213398074469.issue32190@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

(Follow up to https://bugs.python.org/issue27172)

The deprecation notice on inspect.getfullargspec has been removed, since we want folks porting from Python 2 to rely on it as part of the porting process, rather than feeling they need to upgrade to using inspect.signature() immediately.

At the same time, we really don't want folks relying on it for *new* code, since it has some inherent limitations (like failing to distinguish positional-only args from positional-and-keyword ones), and some odd historical quirks (like reporting the bound arg as part of the signature for already bound methods).

The subprocess modules clearly separates out the "Older high-level API" https://docs.python.org/3/library/subprocess.html#older-high-level-api to help make it clear that new code should use "subprocess.run" instead.

We could potentially add a similar final section to the inspect documentation for "Legacy introspection APIs".

That would also be useful if https://bugs.python.org/issue31230 is eventually implemented - the current generator and coroutine specific APIs could be moved down to the legacy section for backwards compatibility maintenance, with the type independent API being preferred for new code.

----------
assignee: docs at python
components: Documentation
messages: 307362
nosy: brett.cannon, docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Separate out legacy introspection APIs in the inspect docs
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32190>
_______________________________________

From report at bugs.python.org  Fri Dec  1 00:34:07 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Dec 2017 05:34:07 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <1512106447.81.0.213398074469.issue32145@psf.upfronthosting.co.za>


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

Hmm, I think that may actually qualify as a bug in the `pop_all()` implementation: https://docs.python.org/3/library/contextlib.html#contextlib.ExitStack.pop_all states that it returns an ExitStack instance, not an instance of the current type.

For 3.6 (and hence the online docs), we can fix the recipe to allow for `callback=None` (with the expectation that the callback will be added afterwards).

Barry, I'd be interested in your thoughts on what to do for 3.7+ - we can either leave the current behaviour alone, and amend the documentation, or else change the code to call ExitStack directly, rather than type(self).

I'm leaning towards only changing the docs as being lower risk - folks may be relying on the current behaviour, so changing it may break their code, whereas changing the docs doesn't risk breaking anything.

----------
nosy: +barry
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Fri Dec  1 18:02:33 2017
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Dec 2017 23:02:33 +0000
Subject: [docs] [issue13305] datetime.strftime("%Y") not consistent for
 years < 1000
In-Reply-To: <1320091957.61.0.759691422668.issue13305@psf.upfronthosting.co.za>
Message-ID: <1512169352.94.0.213398074469.issue13305@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

(See also msg307413 in duplicate Issue32195 for more discussion.)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13305>
_______________________________________

From report at bugs.python.org  Sat Dec  2 06:38:07 2017
From: report at bugs.python.org (Sanyam Khurana)
Date: Sat, 02 Dec 2017 11:38:07 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1512214687.63.0.912454111764.issue25910@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +4582
stage:  -> patch review

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

From report at bugs.python.org  Sat Dec  2 10:25:57 2017
From: report at bugs.python.org (Carol Willing)
Date: Sat, 02 Dec 2017 15:25:57 +0000
Subject: [docs] [issue32200] Download of 3.7.0a2 docs giving a 404 error
Message-ID: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>


New submission from Carol Willing <willingc at gmail.com>:

Currently, the 3.7.0a2 doc links are giving 404 errors. 3.6 docs are working just fine.

https://docs.python.org/3.7/archives/python-3.7.0a2-docs-pdf-letter.tar.bz2 results in a 404.

I wasn't sure if I should report here or in python.org issue tracker.

----------
assignee: docs at python
components: Documentation
messages: 307433
nosy: docs at python, willingc
priority: normal
severity: normal
status: open
title: Download of 3.7.0a2 docs giving a 404 error
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 10:44:19 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 15:44:19 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512229459.71.0.213398074469.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

It looks like the 3.6 and 3.7 full doc build has been failing since 2017-10-15.  Seen in /var/log/docsbuild/python37-en.log:

[...]
[3] [4] [5] [6] [7] (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-1.def
) (/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uninames.dat)
(/usr/share/texlive/texmf-dist/tex/latex/ucs/data/uni-1.def)

! Package ucs Error: Unknown Unicode character 383 = U+017F,
(ucs)                possibly declared in uni-1.def.
(ucs)                Type H to see if it is available with options.

See the ucs package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              
                                                  
l.781 Latin small letter dotless i), ??
                                          ? (U+017F, Latin small letter lo...

? 
! Emergency stop.
 ...                                              
                                                  
l.781 Latin small letter dotless i), ??
                                          ? (U+017F, Latin small letter lo...

!  ==> Fatal error occurred, no output PDF file produced!
Transcript written on howto-regex.log.
Latexmk: Index file 'howto-regex.idx' was written
Collected error summary (may duplicate other messages):
  pdflatex: Command for 'pdflatex' gave return code 256
Latexmk: Use the -f option to force complete processing,
 unless error was exceeding maximum runs of latex/pdflatex.
Latexmk: Errors, so I did not complete making targets
make[2]: *** [howto-regex.pdf] Error 12
make[2]: Leaving directory `/srv/docsbuild/python37/Doc/build/latex'
make[1]: *** [dist] Error 2
make[1]: Leaving directory `/srv/docsbuild/python37/Doc'
make: *** [autobuild-dev] Error 2

Julien, can you take a look please?

----------
nosy: +mdk, ned.deily
title: Download of 3.7.0a2 docs giving a 404 error -> Full docs build of 3.6 and 3.7 failing since 2017-10-15
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 12:35:52 2017
From: report at bugs.python.org (Julien Palard)
Date: Sat, 02 Dec 2017 17:35:52 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512236152.07.0.912454111764.issue32200@psf.upfronthosting.co.za>


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


----------
nosy: +jfbu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 12:46:15 2017
From: report at bugs.python.org (Julien Palard)
Date: Sat, 02 Dec 2017 17:46:15 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512236775.62.0.213398074469.issue32200@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Yes, it's related to:
- https://github.com/python/cpython/pull/3940
- https://github.com/python/cpython/pull/4069

Idea is: Unicode characters are not well supported by pdflatex which what's we're using to build our PDF files.

There's two solutions:

- Use xelatex which just works but does not use the same fonts, and the output style is slightly different
- Use hard handcrafted latex macros to make pdflatex work

I'm personally in favor of the xelatex solution (The simple one: the patch even remove some lines from the sphinx conf).

But the handcrafted latex macro have some advantages: they only "whitelist" the actually used characters, so typos are easily spotted, by the cost of adding a new macro each time we use a new out of the recognized set unicode character.

My point of view is: Documentation people should not have to care about Latex, they should not even know we're using latex in the background to build PDFs, so the xelatex looks the right solution to me.

I'm currently running a test build of an un-to-date Python 3.6 with PR 3940 applied to check if it succeed as expected. (I'm personally unable to type the macro to allow "Latin small letter dotless i" to work, so I won't test PR 31589).

It it succeed, I'll also provide screenshot showing the differences between the current PDF (pdflatex) and the xelatex one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 13:15:13 2017
From: report at bugs.python.org (Julien Palard)
Date: Sat, 02 Dec 2017 18:15:13 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512238513.67.0.213398074469.issue32200@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

It works with xelatex (https://github.com/python/cpython/pull/3940), here's the difference:

https://screenshots.firefox.com/wSn4a8WyFMNzXgKm/null
https://screenshots.firefox.com/WmUNljwcO8mImchP/null

The "bold" one is the xelatex one.

In case we want this to be merged, xelatex have already been installed on the build server (https://github.com/python/psf-salt/pull/122).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 14:35:19 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 19:35:19 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512243319.83.0.213398074469.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

Thanks, Julien.  To be clear, are you recommending applying just PR 3940 or also the unique part of PR 4069?  At this point, I am not concerned about the apparent minor difference in appearance; I would just like the downloadable docs to build and be usable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 16:36:30 2017
From: report at bugs.python.org (Julien Palard)
Date: Sat, 02 Dec 2017 21:36:30 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512250590.21.0.213398074469.issue32200@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

I recommand PR 3940, as it's simple, and as I'm still unable to fix issue32200 with PR 4069 (I still don't understand how to write those latex macros).

I'm open to follow the discussion about PR 4069, if one find a nice documentable reproductible protocol to update the list of latex macros to allow for a new character to be added.

Please not the french and japanese documentation may still fail (French should succeed with xelatex, japanese will still fail), which is expected, it's the origigin of PR 3940 and PR 4069, I'm still working on it, also see: https://github.com/python/docsbuild-scripts/pull/34.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:24:41 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 22:24:41 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512253481.3.0.213398074469.issue31589@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff by Ned Deily (Julien Palard) in branch 'master':
bpo-31589 : Build PDF using xelatex for better UTF8 support. (#3940)
https://github.com/python/cpython/commit/7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:24:41 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 22:24:41 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512253481.46.0.912454111764.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff by Ned Deily (Julien Palard) in branch 'master':
bpo-31589 : Build PDF using xelatex for better UTF8 support. (#3940)
https://github.com/python/cpython/commit/7324b5ce8e7c031a0a3832a6a8d7c639111ae0ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:24:55 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Dec 2017 22:24:55 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512253495.36.0.912454111764.issue31589@psf.upfronthosting.co.za>


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


----------
pull_requests: +4595

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:24:55 2017
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Dec 2017 22:24:55 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512253495.48.0.677646281364.issue32200@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4596
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:26:01 2017
From: report at bugs.python.org (Martin Panter)
Date: Sat, 02 Dec 2017 22:26:01 +0000
Subject: [docs] [issue29710] Incorrect representation caveat on bitwise
 operation docs
In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za>
Message-ID: <1512253561.17.0.213398074469.issue29710@psf.upfronthosting.co.za>


Martin Panter <vadmium+py at gmail.com> added the comment:

FWIW I find Mark?s suggestion pretty good:

?Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29710>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:35:11 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 22:35:11 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512254110.96.0.213398074469.issue31589@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 2ad350a713360e89ae6d264924cd28f519b8b22c by Ned Deily (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31589 : Build PDF using xelatex for better UTF8 support. (GH-3940) (#4683)
https://github.com/python/cpython/commit/2ad350a713360e89ae6d264924cd28f519b8b22c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:35:11 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 22:35:11 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512254111.09.0.912454111764.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 2ad350a713360e89ae6d264924cd28f519b8b22c by Ned Deily (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-31589 : Build PDF using xelatex for better UTF8 support. (GH-3940) (#4683)
https://github.com/python/cpython/commit/2ad350a713360e89ae6d264924cd28f519b8b22c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 17:39:26 2017
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Dec 2017 22:39:26 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512254366.53.0.213398074469.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

OK, thanks.  I've pushed PR 3940 to master and backported it to 3.6.  I'll keep this open until we've seen the next full doc build complete successfully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 20:29:03 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Dec 2017 01:29:03 +0000
Subject: [docs] [issue32192] Provide importlib.util.lazy_import helper
 function
In-Reply-To: <1512118241.83.0.213398074469.issue32192@psf.upfronthosting.co.za>
Message-ID: <1512264542.65.0.213398074469.issue32192@psf.upfronthosting.co.za>


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

Maintaining the actual implementation as a third party module seems like a good idea to me, so I'm marking this as a documentation issue instead.

The idea would be to add this as an example of a very basic lazy importer under https://docs.python.org/3/library/importlib.html#examples

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32192>
_______________________________________

From report at bugs.python.org  Sat Dec  2 20:39:30 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Dec 2017 01:39:30 +0000
Subject: [docs] [issue29710] Incorrect representation caveat on bitwise
 operation docs
In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za>
Message-ID: <1512265170.5.0.213398074469.issue29710@psf.upfronthosting.co.za>


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

I like Mark's phrasing as well. For precision, I'd still like to give an exact algorithmic formulation of what "large enough" means in this context, though.

Something like:

    Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs. ("Large enough" for this purpose is ``1 + max(x.bit_length(), y
.bit_length()``, with the extra bit being needed to handle sign extension appropriately)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29710>
_______________________________________

From report at bugs.python.org  Sat Dec  2 22:21:15 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 03 Dec 2017 03:21:15 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512271275.88.0.213398074469.issue32200@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

I verified that the download links for Python 3.7.0a2  (English) are now working.

The French and Japanese docs downloads are still 404.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sat Dec  2 22:43:41 2017
From: report at bugs.python.org (Tim Peters)
Date: Sun, 03 Dec 2017 03:43:41 +0000
Subject: [docs] [issue29710] Incorrect representation caveat on bitwise
 operation docs
In-Reply-To: <1488551919.31.0.20533072889.issue29710@psf.upfronthosting.co.za>
Message-ID: <1512272621.6.0.213398074469.issue29710@psf.upfronthosting.co.za>


Tim Peters <tim at python.org> added the comment:

To answer the old accusation ;-), no, this isn't my wording.  I _always_ explain that Python's integer bit operations act as if the integers were stored in 2's-complement representation but with an infinite number of sign bits.  That's all.  That provides insight.

For example, then it's dead obvious that `-1 == ~0` (both an infinite solid string of 1 bits); that for any integer `i`, `-1 ^ i == ~i" (both flip each bit in `i`); and that for any positive integers `i` and `j` it's necessarily the case that `-i ^ -j` is positive (because the infinite strings of sign bits cancel out).

The reference manual is under no obligation to explain how to _implement_ this illusion, and I don't think it's helpful to try.  People here are struggling to explain how to pick a number of bits "big enough" to make it all work out on a case by case basis, but the single answer "infinity" is big enough to apply in all cases ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29710>
_______________________________________

From report at bugs.python.org  Sun Dec  3 03:28:03 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 03 Dec 2017 08:28:03 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512289683.27.0.213398074469.issue32200@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Japanese is failing expectedly (may work with platex but not xelatex), but I hoped french to build. But the build server is giving:

    ! Improper discretionary list.
    <recently read> }
                
    l.359 ...{PyObject} \PYG{o}{*}\PYG{n}{t}\PYG{p}{;}
                                                  
    ? 
    ! Emergency stop.

I suspect it's because we're using an old version of xetex (2013.20140215-1ubuntu0.1) and I tested with a recent one (2017.20171128-1). I'm trying to reproduce the issue locally, and to understand the message.

In any cases, issue 32200 was about build failing since the introduction of the dotless i, which is now fixed, french and japanese problems are tracked here: https://bugs.python.org/issue31589.

I'd close issue 32200.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sun Dec  3 03:41:19 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 03 Dec 2017 08:41:19 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512290479.53.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Due to issue 32200, we switched on xelatex, it however did **not** fixed the french builds as expected, maybe because we're using an old version of xelatex.

The issue:

    ! Improper discretionary list.
    <recently read> }
                
    l.359 ...{PyObject} \PYG{o}{*}\PYG{n}{t}\PYG{p}{;}
                                                  
    ? 
    ! Emergency stop. 

The version of texlive-xetex on the build server: 2013.20140215-1ubuntu0.1

The version I tried: 2017.20171128-1

I'm not having the 2013 version on Debian. I'm trying now with 2014.20141024-2+deb8u1, and I'm trying to understand the error message too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 03:53:21 2017
From: report at bugs.python.org (jfbu)
Date: Sun, 03 Dec 2017 08:53:21 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512291201.66.0.213398074469.issue32200@psf.upfronthosting.co.za>


jfbu <jfbu at free.fr> added the comment:

For info, the xetex problem "Improper discretionary list" is presumably the one seen at  https://github.com/sphinx-doc/sphinx/issues/3546. I asked on xetex mailing list at http://tug.org/pipermail/xetex/2017-March/027056.html to which xetex bug it was related but it appears I got no reply. Hence I don't know the precise xetex release which fixed it, but it is ok with `XeTeX 0.99996`. No action was taken on Sphinx side as this appeared to be a XeTeX bug only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Sun Dec  3 04:09:20 2017
From: report at bugs.python.org (jfbu)
Date: Sun, 03 Dec 2017 09:09:20 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512292160.29.0.213398074469.issue31589@psf.upfronthosting.co.za>


jfbu <jfbu at free.fr> added the comment:

I can confirm the "Improper discretionary list" error from xetex build is a xetex bug which is present at XeTeX 0.99992 and absent at XeTeX 0.99996 and presumably all more recent releases.

It was seen at https://github.com/sphinx-doc/sphinx/issues/3546 and reported to XeTeX mailing list at http://tug.org/pipermail/xetex/2017-March/027056.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 05:43:10 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 03 Dec 2017 10:43:10 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512297790.85.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

XeTeX 0.99996 was released in march 2016, so it's not even in Ubuntu 16.04 Xenial Xerus. On docs.iad1.psf.io we're having Ubuntu 14.04 (an LTS ending around february 2019).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 06:27:17 2017
From: report at bugs.python.org (jfbu)
Date: Sun, 03 Dec 2017 11:27:17 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512300437.8.0.213398074469.issue31589@psf.upfronthosting.co.za>


jfbu <jfbu at free.fr> added the comment:

On-going discussion at http://tug.org/pipermail/xetex/2017-December/027212.html has brought new element that polyglossia's French module is broken with xetex since TeXLive2016. We had only one problem, we now have two on our hands.

Possibly Sphinx could be default use babel + French, not polyglossia + French, as the former is maintained but apparently less so the latter.

I tested that TeXLive 2015 (fully updated) and test document showing the https://github.com/sphinx-doc/sphinx/issues/3546 problem now compiles fine if using 

latex_elements = {
    'babel': r'\usepackage{babel}',
}

in conf.py file, to override polyglossia which is default for Sphinx with xelatex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 06:42:15 2017
From: report at bugs.python.org (Julien Palard)
Date: Sun, 03 Dec 2017 11:42:15 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512301335.9.0.213398074469.issue31589@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

For me, french compile correctly with current state of cpython's conf.py and texlive-xetex 2017.20171128-1, if it helps.

I tried (not enough) and fail to test locally with a texlive-xetex from 2013 (I should try with a VM maybe, Debian won't let me install packages from 2013 on my sid...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 09:24:32 2017
From: report at bugs.python.org (jfbu)
Date: Sun, 03 Dec 2017 14:24:32 +0000
Subject: [docs] [issue31589] Links for French documentation PDF is broken:
 LaTeX issue with non-ASCII characters?
In-Reply-To: <1506416349.22.0.925737411431.issue31589@psf.upfronthosting.co.za>
Message-ID: <1512311072.72.0.213398074469.issue31589@psf.upfronthosting.co.za>


jfbu <jfbu at free.fr> added the comment:

Related https://github.com/sphinx-doc/sphinx/issues/4272

It is stated there that using babel-french in place of polyglossia-french avoids the "Improper discretionary list" xetex problem starting with xetex 0.99992 (i.e. TeXLive 2015) whereas with polyglossia-french the earliest xetex version I could test with success is 0.99996 (TL2016). But starting with TL2016, polyglossia-french as the issue https://github.com/sphinx-doc/sphinx/issues/4272

With TeXLive 2014, using babel-french does not avoid the "Improper discretionary list" xetex problem. I don't know how this maps to Debian packaging. One needs xetex 0.99992 at minimum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31589>
_______________________________________

From report at bugs.python.org  Sun Dec  3 13:18:27 2017
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Dec 2017 18:18:27 +0000
Subject: [docs] [issue32200] Full docs build of 3.6 and 3.7 failing since
 2017-10-15
In-Reply-To: <1512228356.9.0.213398074469.issue32200@psf.upfronthosting.co.za>
Message-ID: <1512325107.87.0.213398074469.issue32200@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:

OK, I'm going to close this.  We can discuss further steps elsewhere.  Thanks for reporting the problem, Carol, and thanks for the quick response, Julien!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32200>
_______________________________________

From report at bugs.python.org  Mon Dec  4 05:08:06 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Dec 2017 10:08:06 +0000
Subject: [docs] [issue32211] Document the bug in re.findall() and
 re.finditer() in 2.7 and 3.6
Message-ID: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>>> re.findall(r'^|\w+', 'two words')
['', 'wo', 'words']

Seems the current behavior was documented incorrectly in issue732120.

It will be fixed in 3.7 (see issue1647489, issue25054), but I hesitate to backport the fix to 3.6 and 2.7 because this can break the user code. For example:

In Python 3.6:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[<_sre.SRE_Match object; span=(4, 4), match=''>, <_sre.SRE_Match object; span=(5, 5), match=''>]

In Python 3.7:

>>> list(re.finditer(r'(?m)^\s*?$', 'foo\n\n\nbar'))
[<re.Match object; span=(4, 4), match=''>, <re.Match object; span=(4, 5), match='\n'>, <re.Match object; span=(5, 5), match=''>]

(This is a real pattern used in the docstring module, but with re.sub()).

The proposed PR documents the current weird behavior in 2.7 and 3.6.

----------
assignee: docs at python
components: Documentation, Regular Expressions
messages: 307546
nosy: docs at python, ezio.melotti, mrabarnett, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document the bug in re.findall() and re.finditer() in 2.7 and 3.6
type: enhancement
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Mon Dec  4 05:12:27 2017
From: report at bugs.python.org (Michal Plichta)
Date: Mon, 04 Dec 2017 10:12:27 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
Message-ID: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>


New submission from Michal Plichta <mplichta at gmail.com>:

my code:

logger = logging.getLogger(name)
logger.setLevel(level=logging.DEBUG)
...
stream_handler = logging.StreamHandler(stream=stdout)
stream_handler.setLevel(logging_level)
stream_handler.setFormatter(fmt=formatter)

and mypy-0.550 complains about fmt vs. form parameter in setFormatter method and level vs. lvl in setLevel method.

ta_cc/cc_logger.py: note: In function "_get_stream_handler":
ta_cc/cc_logger.py:34: error: Unexpected keyword argument "fmt" for "setFormatter" of "Handler"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:147: note: "setFormatter" of "Handler" defined here
ta_cc/cc_logger.py:109: error: Unexpected keyword argument "level" for "setLevel" of "Logger"
/usr/local/lib/mypy/typeshed/stdlib/2and3/logging/__init__.pyi:46: note: "setLevel" of "Logger" defined here

I see in online documentation that indeed there are lvl and form parameters for all 2.7, 3.5 and 3.6 python version. However my Pycharm suggest level and fmt for all my installed python interpreters.

I use:
Pycharm-2017.3
Python 2.7.12
Python 3.5.2
Python 3.6.3

This is copy of my issue of: https://github.com/python/typeshed/issues/1619

----------
assignee: docs at python
components: Documentation
messages: 307547
nosy: Michal Plichta, docs at python
priority: normal
severity: normal
status: open
title: few discrepancy between source and docs in logging
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 05:12:51 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Dec 2017 10:12:51 +0000
Subject: [docs] [issue32211] Document the bug in re.findall() and
 re.finditer() in 2.7 and 3.6
In-Reply-To: <1512382086.34.0.213398074469.issue32211@psf.upfronthosting.co.za>
Message-ID: <1512382371.75.0.912454111764.issue32211@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4608
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32211>
_______________________________________

From report at bugs.python.org  Mon Dec  4 07:54:29 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Dec 2017 12:54:29 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512392069.17.0.213398074469.issue32212@psf.upfronthosting.co.za>


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

I don't understand what the bug is that you are reporting here.  Can you clarify?  mypy isn't part of the stdlib, so an explanation in terms of what's in the stdlib would be helpful.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 08:29:07 2017
From: report at bugs.python.org (Michal Plichta)
Date: Mon, 04 Dec 2017 13:29:07 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512394147.84.0.213398074469.issue32212@psf.upfronthosting.co.za>


Michal Plichta <mplichta at gmail.com> added the comment:

see at typeshed:
https://github.com/python/typeshed/blob/master/stdlib/2and3/logging/__init__.pyi#L147

    def setLevel(self, lvl: Union[int, str]) -> None: ...
    def setFormatter(self, form: 'Formatter') -> None: ...

this match python documentation:
Handler.setLevel(lvl)
Handler.setFormatter(form)

but is source code (logging/__init__.py):
    def setFormatter(self, fmt):
        self.formatter = f

    def setLevel(self, level):
        self.level = _checkLevel(level)

This is not big deal but keyworded arguments have different names fmt, form and level, lvl.

Some tools which perform static code verification are base of *.pyi from typeshed repo and some form source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 08:48:55 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Dec 2017 13:48:55 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512395335.41.0.213398074469.issue32212@psf.upfronthosting.co.za>


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

Ah.  I'm guessing Vinay will probably want to fix the docs, then, since that's less disruptive backward compatibility wise.

----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 08:50:26 2017
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Dec 2017 13:50:26 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512395426.84.0.912454111764.issue32212@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Mon Dec  4 08:54:46 2017
From: report at bugs.python.org (Chirag Rathod)
Date: Mon, 04 Dec 2017 13:54:46 +0000
Subject: [docs] [issue32035] Documentation of zipfile.ZipFile().writestr()
 fails to mention that 'data' may also be bytes
In-Reply-To: <1510757660.91.0.213398074469.issue32035@psf.upfronthosting.co.za>
Message-ID: <1512395686.75.0.912454111764.issue32035@psf.upfronthosting.co.za>


Change by Chirag Rathod <chiragr83 at gmail.com>:


----------
keywords: +patch
pull_requests: +4610
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32035>
_______________________________________

From report at bugs.python.org  Mon Dec  4 09:28:26 2017
From: report at bugs.python.org (Michal Plichta)
Date: Mon, 04 Dec 2017 14:28:26 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512397706.29.0.213398074469.issue32212@psf.upfronthosting.co.za>


Michal Plichta <mplichta at gmail.com> added the comment:

Nice, btw maybe other parameters in logging's docs needs to be corrected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From mariatta.wijaya at gmail.com  Mon Dec  4 10:44:32 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Mon, 4 Dec 2017 07:44:32 -0800
Subject: [docs] Incorrect Syntax
In-Reply-To: <L-8KNso--3-0@tutanota.com>
References: <L-8KNso--3-0@tutanota.com>
Message-ID: <CAGbohnYKszO+kJaKZtFs90z7D=doYgf5dOErYrPjfybLAxVO5w@mail.gmail.com>

The example in the documentation works.

It should look like this:
>
> >>> import pprint
> >>> t = [[[['black', 'cyan'], 'white', ['green', 'red']], [['magenta',
> ... 'yellow'], 'blue']]
> ...
> >>> pprint.pprint(t, width=30)
>

Your example does not. It is missing one "]".

Mariatta Wijaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171204/5d75a72e/attachment.html>

From report at bugs.python.org  Mon Dec  4 14:37:22 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Dec 2017 19:37:22 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512416242.84.0.213398074469.issue32208@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The changes you are proposing sound reasonable to me.  Would you like to submit a pull request for them?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
stage:  -> needs patch
versions:  -Python 3.4, Python 3.5, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Mon Dec  4 19:38:49 2017
From: report at bugs.python.org (Garrett Berg)
Date: Tue, 05 Dec 2017 00:38:49 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512434329.95.0.213398074469.issue32208@psf.upfronthosting.co.za>


Garrett Berg <googberg at gmail.com> added the comment:

Gave it a shot!

----------
keywords: +patch
pull_requests: +4620
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Mon Dec  4 21:05:11 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 05 Dec 2017 02:05:11 +0000
Subject: [docs] [issue32216] Document PEP 557 Data Classes
Message-ID: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

The documentation needs to be added.

----------
assignee: docs at python
components: Documentation
messages: 307614
nosy: docs at python, eric.smith
priority: high
severity: normal
status: open
title: Document PEP 557 Data Classes
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From nsigrist at gmail.com  Mon Dec  4 22:22:37 2017
From: nsigrist at gmail.com (Sigrist)
Date: Mon, 4 Dec 2017 19:22:37 -0800
Subject: [docs] Thank you for the font fix
Message-ID: <86D19690-F308-427F-AE90-17039DD4DADB@s383.jpl.nasa.gov>

Thank you for eliminating the Type 3 fonts from the docs -- much nicer now to read with the Type 1 fonts. Great documentation set. 
-- Norbert

From report at bugs.python.org  Wed Dec  6 11:39:36 2017
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Dec 2017 16:39:36 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1512578376.63.0.213398074469.issue25910@psf.upfronthosting.co.za>


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


New changeset 1b4587a2462fc05a14be87123083322103a1f55b by Victor Stinner (Sanyam Khurana) in branch 'master':
bpo-25910: Fixes redirection from http to https (#4674)
https://github.com/python/cpython/commit/1b4587a2462fc05a14be87123083322103a1f55b


----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Dec  6 12:10:53 2017
From: report at bugs.python.org (Jim Fulton)
Date: Wed, 06 Dec 2017 17:10:53 +0000
Subject: [docs] [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1512580253.92.0.912454111764.issue25910@psf.upfronthosting.co.za>


Change by Jim Fulton <jim at jimfulton.info>:


----------
nosy:  -j1m

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

From report at bugs.python.org  Wed Dec  6 13:33:11 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 06 Dec 2017 18:33:11 +0000
Subject: [docs] [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1512585191.29.0.213398074469.issue13322@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

For added fun: at least one part of the standard library doesn't expect None returns from read() in the buffering layer.

>>> import os
>>> r, w = os.pipe2(os.O_NONBLOCK)
>>> f = os.fdopen(r, 'r')
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/izbyshev/workspace/cpython/Lib/codecs.py", line 321, in decode
    data = self.buffer + input
TypeError: can't concat NoneType to bytes

Note that nonblock-none.patch doesn't seem to address that.

----------
nosy: +izbyshev
versions: +Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Wed Dec  6 13:57:04 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Dec 2017 18:57:04 +0000
Subject: [docs] [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1512586624.32.0.213398074469.issue13322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Generally I doubt anyone is using the non-blocking semantics of the Python 3 I/O stack.  People doing non-blocking I/O generally do it with sockets instead, which tend to reproduce quite literally the POSIX behaviour and error codes.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Wed Dec  6 15:22:26 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 06 Dec 2017 20:22:26 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512591746.92.0.213398074469.issue32212@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't have a problem with tweaking the documentation where discrepancies are found between source and doc for keyword arguments, but in both the examples you give, the arguments are positional, not keyword. Therefore in my opinion your code should be e.g.

logger.setLevel(logging.DEBUG)

and

stream_handler.setFormatter(formatter)

without using keyword arguments. For positionals, as I see it, the name shouldn't matter, nor should any minor discrepancy between doc and source.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Wed Dec  6 16:14:40 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 06 Dec 2017 21:14:40 +0000
Subject: [docs] [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1512594880.0.0.213398074469.issue13322@psf.upfronthosting.co.za>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Yes, your claim is confirmed by the fact that there have been little interest in this issue since 2011. Still, non-blocking behavior is incorrectly specified in the docs and is inconsistent (as investigated by Martin). And obscure errors like in my example or in Issue 13858 show that I/O stack is confused too. To prevent people from tripping on it, would you consider recommending against usage of I/O stack for non-blocking operations in io module docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Wed Dec  6 18:12:36 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Dec 2017 23:12:36 +0000
Subject: [docs] [issue13322] buffered read() and write() does not raise
 BlockingIOError
In-Reply-To: <1320246535.71.0.465783773129.issue13322@psf.upfronthosting.co.za>
Message-ID: <1512601956.01.0.213398074469.issue13322@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, I think adding a note in the docs is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13322>
_______________________________________

From report at bugs.python.org  Wed Dec  6 21:05:36 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 07 Dec 2017 02:05:36 +0000
Subject: [docs] [issue31972] Inherited docstrings for pathlib classes are
 confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1512612336.55.0.912454111764.issue31972@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +4644
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From report at bugs.python.org  Wed Dec  6 21:37:30 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Dec 2017 02:37:30 +0000
Subject: [docs] [issue31972] Inherited docstrings for pathlib classes are
 confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1512614250.58.0.912454111764.issue31972@psf.upfronthosting.co.za>


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


----------
pull_requests:  -4644

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From report at bugs.python.org  Wed Dec  6 21:40:30 2017
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 07 Dec 2017 02:40:30 +0000
Subject: [docs] [issue31972] Inherited docstrings for pathlib classes are
 confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1512614430.16.0.912454111764.issue31972@psf.upfronthosting.co.za>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +4645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From report at bugs.python.org  Thu Dec  7 00:10:37 2017
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Dec 2017 05:10:37 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512623437.64.0.213398074469.issue32212@psf.upfronthosting.co.za>


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

It does matter, though, because in Python you can specify a positional argument as if it were a keyword argument if you use the name from the source rather than the documented name.  We have made other doc corrections along these lines.  We've even done it for C functions where you can't specify the argument as if it were a keyword argument, though that is considerably more rare.

That's a different question from the question of whether typing/linters should care, though.  Arguably they should recommend specifying them as positionals.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Thu Dec  7 03:18:39 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Dec 2017 08:18:39 +0000
Subject: [docs] [issue31972] Inherited docstrings for pathlib classes are
 confusing
In-Reply-To: <1510081543.19.0.213398074469.issue31972@psf.upfronthosting.co.za>
Message-ID: <1512634719.71.0.912454111764.issue31972@psf.upfronthosting.co.za>


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


----------
pull_requests:  -4645

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31972>
_______________________________________

From eko.infinity at gmail.com  Wed Dec  6 17:25:17 2017
From: eko.infinity at gmail.com (eko budiyanto)
Date: Thu, 7 Dec 2017 05:25:17 +0700
Subject: [docs] Broken link
Message-ID: <CAPiEhi+uzXW=LjEpg8C9=gJFde3PRU_UqNvR3bpNBuR80ayYdw@mail.gmail.com>

I was try to download the Docs from this link:
https://docs.python.org/3/download.html. but all the link give me 404.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171207/0b253550/attachment.html>

From varunchalla1729 at gmail.com  Thu Dec  7 04:29:13 2017
From: varunchalla1729 at gmail.com (Varun Challa)
Date: Thu, 7 Dec 2017 14:59:13 +0530
Subject: [docs] Requesting IDLE Source Code
Message-ID: <CAEzLL+nhqtDqs+VX_zO7_RiDh0SnWyq-oemhWkyfEkqPF60W0w@mail.gmail.com>

Hi ,

My Name is Varun Challa.
I am learning Tkinter Module in Pyhton.I came to know that Python IDLE
editor is written in Tkinter.
so I am requesting you please send me the IDLE source code.

Thank You In Advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171207/dbb0da69/attachment.html>

From zachary.ware+pydocs at gmail.com  Thu Dec  7 11:26:34 2017
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 7 Dec 2017 10:26:34 -0600
Subject: [docs] Requesting IDLE Source Code
In-Reply-To: <CAEzLL+nhqtDqs+VX_zO7_RiDh0SnWyq-oemhWkyfEkqPF60W0w@mail.gmail.com>
References: <CAEzLL+nhqtDqs+VX_zO7_RiDh0SnWyq-oemhWkyfEkqPF60W0w@mail.gmail.com>
Message-ID: <CAKJDb-NP-ncRPn-7TLW-eVmW3smXCEf8AvCbuPtjMvVcv=pWpw@mail.gmail.com>

On Thu, Dec 7, 2017 at 3:29 AM, Varun Challa <varunchalla1729 at gmail.com> wrote:
> Hi ,
>
> My Name is Varun Challa.

Hi Varun,

> I am learning Tkinter Module in Pyhton.I came to know that Python IDLE
> editor is written in Tkinter.
> so I am requesting you please send me the IDLE source code.

IDLE is bundled as part of the CPython standard library, and as such
its source code can be found within the rest of the CPython source at
https://github.com/python/cpython/tree/master/Lib/idlelib

Regards,
-- 
Zach

From report at bugs.python.org  Thu Dec  7 13:04:30 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Dec 2017 18:04:30 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512669870.18.0.213398074469.issue32208@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset a0374dd34aa25f0895195d388b5ceff43b121b00 by Andrew Svetlov (Garrett Berg) in branch 'master':
bpo-32208: update threading.Semaphore docs and add unit test (#4709)
https://github.com/python/cpython/commit/a0374dd34aa25f0895195d388b5ceff43b121b00


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Thu Dec  7 13:04:35 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Dec 2017 18:04:35 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512669875.95.0.912454111764.issue32208@psf.upfronthosting.co.za>


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


----------
pull_requests: +4653

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Thu Dec  7 13:48:37 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 07 Dec 2017 18:48:37 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512672517.71.0.213398074469.issue32208@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset a04ca12e12b522850e7e9244c250754d3cd36f0a by Andrew Svetlov (Miss Islington (bot)) in branch '3.6':
bpo-32208: update threading.Semaphore docs and add unit test (GH-4709) (#4750)
https://github.com/python/cpython/commit/a04ca12e12b522850e7e9244c250754d3cd36f0a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Thu Dec  7 20:25:20 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Dec 2017 01:25:20 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512696320.28.0.912454111764.issue8722@psf.upfronthosting.co.za>


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


----------
pull_requests: +4657
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Thu Dec  7 20:27:14 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Dec 2017 01:27:14 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512696434.03.0.912454111764.issue8722@psf.upfronthosting.co.za>


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


----------
keywords: +needs review -patch
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Thu Dec  7 21:12:49 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Dec 2017 02:12:49 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512699168.88.0.213398074469.issue8722@psf.upfronthosting.co.za>


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

Cheryl, thank you for reviving this, as it is still needed.  A slightly revised example better illustrates the claim in the doc revision about when __getattr__ is called.

class Foo(object):

    def __init__(self):
        self.foo = 1
        self.data = {"bing": 4}

    def __getattr__(self, name):
        print(f'Getting {name}')
        return self.data.get(name)

    @property
    def bar(self):
        return 3

    @property
    def bing(self):
        raise AttributeError("blarg")

f = Foo()
print('foo', f.foo)
print('__str__', f.__str__)
print('bar', f.bar)
print('bing', f.bing)
f.__getattribute__('bing')

# prints
foo 1
__str__ <method-wrapper '__str__' of Foo object at 0x0000016712378128>
bar 3
Getting bing
bing 4
Traceback (most recent call last):
  File "F:\Python\a\tem2.py", line 24, in <module>
    f.__getattribute__('bing')
  File "F:\Python\a\tem2.py", line 17, in bing
    raise AttributeError("blarg")
AttributeError: blarg

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Thu Dec  7 22:59:12 2017
From: report at bugs.python.org (Nitish)
Date: Fri, 08 Dec 2017 03:59:12 +0000
Subject: [docs] [issue28197] Add start and stop parameters to the
 range.index() ABC method
In-Reply-To: <1474231832.91.0.157673750963.issue28197@psf.upfronthosting.co.za>
Message-ID: <1512705552.77.0.213398074469.issue28197@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

Any comments on the PR?

----------
nosy: +nitishch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28197>
_______________________________________

From report at bugs.python.org  Thu Dec  7 22:59:27 2017
From: report at bugs.python.org (Nitish)
Date: Fri, 08 Dec 2017 03:59:27 +0000
Subject: [docs] [issue31942] Document that support of start and stop
 parameters in the Sequence's index() is optional
In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za>
Message-ID: <1512705567.16.0.213398074469.issue31942@psf.upfronthosting.co.za>


Nitish <nitishchandrachinta at gmail.com> added the comment:

Any comments on the PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31942>
_______________________________________

From report at bugs.python.org  Fri Dec  8 06:41:44 2017
From: report at bugs.python.org (Chirag Rathod)
Date: Fri, 08 Dec 2017 11:41:44 +0000
Subject: [docs] [issue32035] Documentation of zipfile.ZipFile().writestr()
 fails to mention that 'data' may also be bytes
In-Reply-To: <1510757660.91.0.213398074469.issue32035@psf.upfronthosting.co.za>
Message-ID: <1512733304.76.0.912454111764.issue32035@psf.upfronthosting.co.za>


Change by Chirag Rathod <chiragr83 at gmail.com>:


----------
pull_requests: +4660

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32035>
_______________________________________

From report at bugs.python.org  Fri Dec  8 07:42:24 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Dec 2017 12:42:24 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>
Message-ID: <1512736943.59.0.213398074469.issue29247@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Berker,

Are you interested in making a pull request for this patch?  Thanks!

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

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

From report at bugs.python.org  Fri Dec  8 11:32:04 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Dec 2017 16:32:04 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512750723.97.0.213398074469.issue8722@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Terry,

Thanks for clarifying with this example.  I hadn't tried this when I was playing with the other example.  I guess __getattribute__ might be defined by a class, but generally wouldn't be called directly, so the use of __getattr__ and __getattribute__ and the raising of AttributeError is more for an `attributeref` (https://docs.python.org/3/reference/expressions.html#attribute-references) usage?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Fri Dec  8 11:52:14 2017
From: report at bugs.python.org (Dustin Spicuzza)
Date: Fri, 08 Dec 2017 16:52:14 +0000
Subject: [docs] [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1512751934.31.0.213398074469.issue29249@psf.upfronthosting.co.za>


Dustin Spicuzza <dustin at virtualroadside.com> added the comment:

I just ran into this also. It seems like a very strange omission that match and glob don't support the same patterns (and I'm surprised that they don't share more code).

----------
nosy: +virtuald

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

From report at bugs.python.org  Fri Dec  8 12:45:26 2017
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Dec 2017 17:45:26 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512755126.18.0.912454111764.issue32212@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Fri Dec  8 13:17:21 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 08 Dec 2017 18:17:21 +0000
Subject: [docs] [issue32216] Document PEP 557 Data Classes
In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>
Message-ID: <1512757041.87.0.912454111764.issue32216@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From report at bugs.python.org  Fri Dec  8 14:40:12 2017
From: report at bugs.python.org (Dustin Spicuzza)
Date: Fri, 08 Dec 2017 19:40:12 +0000
Subject: [docs] [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1512762012.08.0.213398074469.issue29249@psf.upfronthosting.co.za>


Dustin Spicuzza <dustin at virtualroadside.com> added the comment:

Because of backwards compatibility (despite a statement saying it's not guaranteed for pathlib), I think the best approach would be to create a 'globmatch' function for PurePath instead of modifying the match function, and document that the match function does a different kind of matching. 

This isn't a patch for cpython per se (ironically, don't have time for that this month...), but here's a MIT-licensed gist that patches pathlib2 and adds a globmatch function to it, plus associated tests extracted from pathlib2 and my own ** related tests. Works for me, feel free to do with it as you wish.

https://gist.github.com/virtuald/dd0373bf3f26ec0730adf1da0fb929bb

----------

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

From report at bugs.python.org  Fri Dec  8 20:35:14 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Dec 2017 01:35:14 +0000
Subject: [docs] [issue20285] Improve object.__doc__ and help(object) output
In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>
Message-ID: <1512783314.22.0.912454111764.issue20285@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20285>
_______________________________________

From report at bugs.python.org  Fri Dec  8 21:27:29 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Dec 2017 02:27:29 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512786448.95.0.213398074469.issue8722@psf.upfronthosting.co.za>


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

Before testing, let alone documenting, the status quo, I would like to be sure that suppressing the exception is truly the intended behavior.  Is there a way to get an annotated listing from git (given which patch, and therefore which person, is responsible for each line)?  I will try asking on pydev.

Calling __getattr__ on property failure is a behavior of __getattribute__, not of the property, and I would expect object.__getattribute__ to be tested wherever object is, but I have not found such tests.  If we do add a test, the best model in test_desc.py looks like `def test_module_subclasses(self):`.  The test class would only need __getattr__ and the faulty property.

class Foo(object):
    def __getattr__(self, name):
        print(f'Getattr {name}')
        return True
    @property
    def bing(self):
        print('Property bing')
        raise AttributeError("blarg")

f = Foo()
print(f.bing)

#prints (which would be the log list in a test)
Property bing
Getattr bing
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Fri Dec  8 21:29:44 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Dec 2017 02:29:44 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512786584.6.0.213398074469.issue8722@psf.upfronthosting.co.za>


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

The behavior and doc for __setattr__ and __delattr__ should also be checked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat Dec  9 02:13:48 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Dec 2017 07:13:48 +0000
Subject: [docs] [issue32208] Improve semaphore documentation
In-Reply-To: <1512357480.91.0.213398074469.issue32208@psf.upfronthosting.co.za>
Message-ID: <1512803628.65.0.213398074469.issue32208@psf.upfronthosting.co.za>


Berker Peksag <berker.peksag at gmail.com> added the comment:

According to the discussion at https://github.com/python/cpython/pull/4709#issuecomment-350055732 it was decided to not backport this to 2.7. Closing this as 'fixed'. Thank you, all!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32208>
_______________________________________

From report at bugs.python.org  Sat Dec  9 04:30:13 2017
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 09 Dec 2017 09:30:13 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512811813.77.0.912454111764.issue8722@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat Dec  9 05:06:15 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 09 Dec 2017 10:06:15 +0000
Subject: [docs] [issue32258] Rewrite ayncio docs to use async/await syntax
Message-ID: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

https://bugs.python.org/issue32193 switched asyncio implementation to async/await syntax.

We need to update documentation as well.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 307889
nosy: asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Rewrite ayncio docs to use async/await syntax
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Sat Dec  9 05:30:26 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Dec 2017 10:30:26 +0000
Subject: [docs] [issue32258] Rewrite asyncio docs to use async/await syntax
In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>
Message-ID: <1512815426.36.0.912454111764.issue32258@psf.upfronthosting.co.za>


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


----------
title: Rewrite ayncio docs to use async/await syntax -> Rewrite asyncio docs to use async/await syntax

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Sat Dec  9 05:54:31 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 10:54:31 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512816871.96.0.912454111764.issue32212@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
keywords: +patch
pull_requests: +4668
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 06:09:07 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 11:09:07 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512817746.93.0.213398074469.issue32212@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset a9f8df646aac7fc94ced0aefd1ed2c8566d14d10 by Vinay Sajip in branch 'master':
bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765)
https://github.com/python/cpython/commit/a9f8df646aac7fc94ced0aefd1ed2c8566d14d10


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:06:11 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 12:06:11 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512821171.3.0.912454111764.issue32212@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +4670

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:25:16 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Dec 2017 12:25:16 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512822316.32.0.213398074469.issue8722@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

>> Is there a way to get an annotated listing from git (given which patch, and therefore which person, is responsible for each line)?

Which source did you want to look at?  In github, if you go into any source, you can click on a line and it gives an option for 'git blame'.  That shows the last commit change for each line.  You can then click an icon to see a previous commit, etc.  For the .rst sources, it's a little different and there is a Blame button at the top of the source that will bring up the same view (commit annotations to the left of the source) as right-clicking.

I had posted about git blame a few months ago on core mentorship and Carol Willing mentioned another tool to get all the changes by line.  Here was her post:

Thanks for passing along the tip for others. You may also find the npm package `git-guilt` useful as it will display all the contributors to a particular line's history. https://www.npmjs.com/package/git-guilt <https://www.npmjs.com/package/git-guilt>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:26:31 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 12:26:31 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512822391.72.0.912454111764.issue32212@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
pull_requests: +4671

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:28:18 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 12:28:18 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512822498.85.0.213398074469.issue32212@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 63868181a904c844d8d01e3badfdd5b134acc5fa by Vinay Sajip in branch '3.6':
bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765) (GH-4767)
https://github.com/python/cpython/commit/63868181a904c844d8d01e3badfdd5b134acc5fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:49:14 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 12:49:14 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512823754.37.0.213398074469.issue32212@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 292fce9934280867ca9a65870495f83fca37751e by Vinay Sajip in branch '2.7':
bpo-32212: Updated logging documentation to make parameter names more consistent with source. (GH-4765) (GH-4768)
https://github.com/python/cpython/commit/292fce9934280867ca9a65870495f83fca37751e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 07:51:16 2017
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Dec 2017 12:51:16 +0000
Subject: [docs] [issue32212] few discrepancy between source and docs in
 logging
In-Reply-To: <1512382347.58.0.213398074469.issue32212@psf.upfronthosting.co.za>
Message-ID: <1512823876.68.0.912454111764.issue32212@psf.upfronthosting.co.za>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution: not a bug -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32212>
_______________________________________

From report at bugs.python.org  Sat Dec  9 08:02:53 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Dec 2017 13:02:53 +0000
Subject: [docs] [issue20285] Improve object.__doc__ and help(object) output
In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>
Message-ID: <1512824573.84.0.213398074469.issue20285@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Terry,

I've submitted a PR for this.  Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20285>
_______________________________________

From report at bugs.python.org  Sat Dec  9 13:12:31 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Dec 2017 18:12:31 +0000
Subject: [docs] [issue8722] Documentation for __getattr__
In-Reply-To: <1273896658.97.0.575873001655.issue8722@psf.upfronthosting.co.za>
Message-ID: <1512843151.11.0.213398074469.issue8722@psf.upfronthosting.co.za>


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

Thanks.  I normally look at source in my local clone with an editor.  I found 'view blame' and 'view blame prior' on github.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8722>
_______________________________________

From report at bugs.python.org  Sat Dec  9 14:14:41 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Dec 2017 19:14:41 +0000
Subject: [docs] [issue32261] Online doc does not include
 inspect.classify_class_attrs
Message-ID: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

Documentation for inspect.classify_class_attrs exists in the docstring and, therefore, pydoc, but is not included in the online docs for inspect.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 307912
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Online doc does not include inspect.classify_class_attrs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32261>
_______________________________________

From report at bugs.python.org  Sat Dec  9 14:51:55 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Dec 2017 19:51:55 +0000
Subject: [docs] [issue20285] Improve object.__doc__ and help(object) output
In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>
Message-ID: <1512849115.72.0.213398074469.issue20285@psf.upfronthosting.co.za>


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

After looking at https://en.wiktionary.org/wiki/base I can explain better why 'most base class' is wrong, and felt wrong to participants in the python-list thread.

'Base' is actually two words.  As a noun (or verb), it comes from Ancient Greek ????? (b?sis), a foundation from which other things extend or derive.  As an adjective, it comes from Late Latin bassus (?low?).

In computer science and Python, the couplet 'base class' is being used, it seems to me and apparently others, as a noun-noun compound, meaning, 'foundation class', not as an adjective-noun phrase meaning 'low class' (let along 'depraved class').  However, 'most base class' must be parsed as '(most base) class', with 'base' re-interpreted as the adjective meaning 'low' (or worse).  The switch in meaning of 'base' is similar in 'baseball' versus  'most base ball'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20285>
_______________________________________

From report at bugs.python.org  Sat Dec  9 16:14:47 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Dec 2017 21:14:47 +0000
Subject: [docs] [issue20285] Improve object.__doc__ and help(object) output
In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>
Message-ID: <1512854086.8.0.213398074469.issue20285@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

"Python class" can be read as a user type defined in Python (usually with the "class" statement). The term "class" in the glossary is used with this meaning in contrary to the term "type" which means also builtin and extension types. In Python 3 "object" is a base class of all types, not only user-defined class.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20285>
_______________________________________

From report at bugs.python.org  Sat Dec  9 16:36:38 2017
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 09 Dec 2017 21:36:38 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
Message-ID: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

At least as far back as Python 3.1, the description for Template strings (section 6.1.5 in version 3.6.4rc1 docs) starts by differentiating what Template strings do, as:

Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules:

Since this immediately follows a section describing the "Custom String Formatting" and the "Format Specification Mini-Language", which does a type of substitutions that is {} based, rather than % based, it is hard to grasp exactly why %-based substitutions would be considered "normal". Of course, I know why, due to the % operator, but for someone just reading through chapter 6, it is a reference that raises the mental question "Huh? What is normal %-based substitution? Are Templates abnormal, if %-based substitutions are normal? What did I miss? The previous section was about {}-based substitutions? Are they abnormal, too? What are normal %-based substitutions, anyway?" rather than helping to describe what Templates are and do.

----------
assignee: docs at python
components: Documentation
messages: 307922
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: Template string docs refer to "normal %-based substitutions"
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sat Dec  9 16:58:25 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 09 Dec 2017 21:58:25 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <1512856705.59.0.912454111764.issue32263@psf.upfronthosting.co.za>


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


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sat Dec  9 17:46:19 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Dec 2017 22:46:19 +0000
Subject: [docs] [issue20285] Improve object.__doc__ and help(object) output
In-Reply-To: <1389920351.63.0.12805701843.issue20285@psf.upfronthosting.co.za>
Message-ID: <1512859579.46.0.213398074469.issue20285@psf.upfronthosting.co.za>


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

How about "The starting base class of all types and classes other than itself." (Object.__bases__ = ().)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20285>
_______________________________________

From report at bugs.python.org  Sat Dec  9 19:02:21 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 10 Dec 2017 00:02:21 +0000
Subject: [docs] [issue27505] Missing documentation for setting module
 __class__ attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1512864141.14.0.213398074469.issue27505@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Hi Nick,

I started looking at this issue for documenting #22986 and then found #24912 and #24991.  Has anything changed in the code since 2015 that would make these issues (this one and 24991) obsolete?  It seems there were a lot of ideas flying around, but I couldn't find other tickets (and the code is still in place for 22986 and 24912).  If these haven't been superseded, do you think the discussion on #24991 should be continued or should the documentation mentioned in this issue still be done?

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Sat Dec  9 19:41:24 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Dec 2017 00:41:24 +0000
Subject: [docs] [issue27505] Missing documentation for setting module
 __class__ attribute
In-Reply-To: <1468373521.97.0.915242819681.issue27505@psf.upfronthosting.co.za>
Message-ID: <1512866484.01.0.213398074469.issue27505@psf.upfronthosting.co.za>


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

This is still a valid docs issue, although PEP 562's module __getattr__ and __dir__ will provide a simpler alternative for most of the cases that previously required setting the __class__ attribute: https://www.python.org/dev/peps/pep-0562/

So I've added https://bugs.python.org/issue32225 as a dependency for this issue, as it will likely make sense to figure out a good docs structure for those changes first, and then see if there's any work left to do specifically for this issue: https://bugs.python.org/issue32225#msg307935

Issue #24991 is a fairly different topic - I've added an extra comment there that should help clarify the actual question/proposal.

----------
dependencies: +Implement PEP 562: module __getattr__ and __dir__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27505>
_______________________________________

From report at bugs.python.org  Sat Dec  9 21:38:07 2017
From: report at bugs.python.org (Martin Panter)
Date: Sun, 10 Dec 2017 02:38:07 +0000
Subject: [docs] [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1512873487.62.0.912454111764.issue17972@psf.upfronthosting.co.za>


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


----------
dependencies: +Online doc does not include inspect.classify_class_attrs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Sun Dec 10 04:03:12 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 10 Dec 2017 09:03:12 +0000
Subject: [docs] [issue32258] Rewrite asyncio docs to use async/await syntax
In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>
Message-ID: <1512896592.98.0.912454111764.issue32258@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +4680
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Sun Dec 10 14:36:04 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Dec 2017 19:36:04 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <1512934564.08.0.213398074469.issue32263@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

We can remove the word "normal" but otherwise the docs read fairly well.

FWIW, when there docs were written, the {} new-style string formatting didn't exist, so the wording was reasonable at the time.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sun Dec 10 17:10:57 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 10 Dec 2017 22:10:57 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512934564.08.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <49289BD8-F53F-474D-9C3A-B2757B4BC6C6@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Dec 10, 2017, at 14:36, Raymond Hettinger <report at bugs.python.org> wrote:
> 
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
> 
> We can remove the word "normal" but otherwise the docs read fairly well.

+1

> FWIW, when there docs were written, the {} new-style string formatting didn't exist, so the wording was reasonable at the time.

Exactly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sun Dec 10 19:15:57 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Dec 2017 00:15:57 +0000
Subject: [docs] [issue13553] Tkinter Tk args and Gnome Shell application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1512951357.66.0.912454111764.issue13553@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4687
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Sun Dec 10 19:16:47 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Dec 2017 00:16:47 +0000
Subject: [docs] [issue13553] Tkinter Tk args and Gnome Shell application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1512951407.86.0.912454111764.issue13553@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13553>
_______________________________________

From report at bugs.python.org  Sun Dec 10 19:54:15 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 11 Dec 2017 00:54:15 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <1512953655.85.0.213398074469.issue32145@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I wasn't even aware that pop_all() tries to create the concrete subtype.  I wonder how common subclassing ExitStack is in practice.  (Of course, the answer is that we'll never know.)

For 3.7, we should probably delegate instance creation to a new non-private method, e.g.

    new_stack = self._make_instance()

so *if* you subclass, you can create the new ExitStack subclass instances any way you want.  I would then change the default implementation to make an ExitStack() explicitly, as per the current documentation.

+1 for fixing the recipe and not changing the code for 3.6.  You might want to add a note describing the current behavior for <= 3.6 and indicating that this will change for 3.7+

Finally, while you're at it, is there any reason not to change the recipe to use:

    super().__init__()

instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Sun Dec 10 23:25:53 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Dec 2017 04:25:53 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <1512966353.61.0.213398074469.issue32263@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, this was already fixed in the 3.7 docs.  I don't feel any real need to backport it.

----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sun Dec 10 23:26:05 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Dec 2017 04:26:05 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <1512966365.66.0.912454111764.issue32263@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.4, Python 3.5, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Mon Dec 11 08:42:16 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 13:42:16 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1512999736.11.0.213398074469.issue22671@psf.upfronthosting.co.za>


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


New changeset 1b74f9b77a6fa1d7828986cb79d5b10942ff9141 by Victor Stinner (Sanyam Khurana) in branch 'master':
bpo-22671: Clarify and test default read method implementations (#4568)
https://github.com/python/cpython/commit/1b74f9b77a6fa1d7828986cb79d5b10942ff9141


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Mon Dec 11 08:44:02 2017
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 Dec 2017 13:44:02 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1512999842.81.0.912454111764.issue22671@psf.upfronthosting.co.za>


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


----------
pull_requests: +4695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Mon Dec 11 09:27:32 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 14:27:32 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1513002452.12.0.213398074469.issue22671@psf.upfronthosting.co.za>


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


New changeset 0aa2a1d003b476b954ecdcb7e966bf7f0b75a06b by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-22671: Clarify and test default read method implementations (GH-4568) (#4796)
https://github.com/python/cpython/commit/0aa2a1d003b476b954ecdcb7e966bf7f0b75a06b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Mon Dec 11 09:28:11 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 14:28:11 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1513002491.09.0.213398074469.issue22671@psf.upfronthosting.co.za>


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

Thank you Martin Panter and Sanyam Khurana for the fix.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Mon Dec 11 10:35:55 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 11 Dec 2017 15:35:55 +0000
Subject: [docs] [issue32258] Rewrite asyncio docs to use async/await syntax
In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>
Message-ID: <1513006555.61.0.213398074469.issue32258@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 8874342cf332c3aa3d845155cc4b41b00c2d9e9d by Andrew Svetlov in branch 'master':
bpo-32258: Replace 'yield from' to 'await' in asyncio docs (#4779)
https://github.com/python/cpython/commit/8874342cf332c3aa3d845155cc4b41b00c2d9e9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Mon Dec 11 10:44:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 15:44:08 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513007048.1.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

> Should there be a PR for this?

Feel free to create a PR from my old (4 years old) patch. Just mention my name in the commit message please.

----------

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

From report at bugs.python.org  Mon Dec 11 10:44:45 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 15:44:45 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513007085.92.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

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

I suggest to document them, but explain in the documentation that they must not be used :-)

----------

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

From report at bugs.python.org  Mon Dec 11 10:46:54 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Dec 2017 15:46:54 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513007214.21.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

Ah, PyFrame_GetLineNumber is now documented at Doc/c-api/reflection.rst. But PyFrame_New() is still not documented. So my patch is not completely useful.

@Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError().

----------

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

From report at bugs.python.org  Mon Dec 11 11:00:46 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 11 Dec 2017 16:00:46 +0000
Subject: [docs] [issue32258] Rewrite asyncio docs to use async/await syntax
In-Reply-To: <1512813975.64.0.213398074469.issue32258@psf.upfronthosting.co.za>
Message-ID: <1513008046.12.0.912454111764.issue32258@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32258>
_______________________________________

From report at bugs.python.org  Mon Dec 11 13:24:56 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 11 Dec 2017 18:24:56 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>
Message-ID: <1513016696.67.0.912454111764.issue29247@psf.upfronthosting.co.za>


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


----------
pull_requests: +4697

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

From report at bugs.python.org  Mon Dec 11 13:25:22 2017
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 11 Dec 2017 18:25:22 +0000
Subject: [docs] [issue29247] Document return value of epoll.poll
In-Reply-To: <1484195034.62.0.718564451527.issue29247@psf.upfronthosting.co.za>
Message-ID: <1513016722.6.0.912454111764.issue29247@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon Dec 11 18:12:36 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Dec 2017 23:12:36 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513033956.04.0.213398074469.issue19431@psf.upfronthosting.co.za>


Cheryl Sabella <chekat2 at gmail.com> added the comment:

Thanks Victor and Serhiy.

>> @Cheryl: Maybe convert the PR without PyFrame_FastToLocals() and PyFrame_FastToLocalsWithError().

If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects.  I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst?

Thanks!

----------

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

From report at bugs.python.org  Mon Dec 11 18:24:10 2017
From: report at bugs.python.org (Lior Cohen)
Date: Mon, 11 Dec 2017 23:24:10 +0000
Subject: [docs] [issue26103] Contradiction in definition of "data
 descriptor" between (dotted lookup behavior/datamodel documentation) and
 (inspect lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1513034650.05.0.213398074469.issue26103@psf.upfronthosting.co.za>


Lior Cohen <chnlior at gmail.com> added the comment:

Joining @Serhiy Storchaka last question.
Is the __get__ method existance is a must be a data descriptor?

According to the C implementation in descrobject.h
```
#define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL)
#endif
```
the answer is No.
Does this C code reflect the true definition?

----------
nosy: +chnlior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26103>
_______________________________________

From report at bugs.python.org  Mon Dec 11 19:34:35 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Tue, 12 Dec 2017 00:34:35 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
Message-ID: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>


New submission from Sebastian Rittau <srittau at rittau.biz>:

See https://github.com/python/typing/issues/518 for context.

The typing documentation for 3.6.4rc1 states:

> typing.io ... defines the generic type IO[AnyStr] and aliases TextIO and BinaryIO for respectively IO[str] and IO[bytes].

In the current implementation TextIO and BinaryIO are not aliases, but instead derived from IO. This means that values of type IO[...], and especially IO[Any] can not be assigned where TextIO or BinaryIO is expected.

----------
assignee: docs at python
components: Documentation
messages: 308083
nosy: docs at python, srittau
priority: normal
severity: normal
status: open
title: typing.TextIO and BinaryIO are not aliases of IO[...]
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Mon Dec 11 20:41:34 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Dec 2017 01:41:34 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1513042894.22.0.912454111764.issue26256@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4704
stage:  -> patch review

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

From report at bugs.python.org  Mon Dec 11 20:43:28 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Dec 2017 01:43:28 +0000
Subject: [docs] [issue26256] Fast decimalisation and conversion to other
 bases
In-Reply-To: <1454322513.41.0.794136944555.issue26256@psf.upfronthosting.co.za>
Message-ID: <1513043008.18.0.912454111764.issue26256@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7 -Python 3.4

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

From report at bugs.python.org  Mon Dec 11 21:57:47 2017
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Dec 2017 02:57:47 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513047467.17.0.213398074469.issue32284@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This doc bug should be fixed before 3.6.4 final goes out.

----------
nosy: +gvanrossum, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Tue Dec 12 02:57:42 2017
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 12 Dec 2017 07:57:42 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513065462.42.0.912454111764.issue32284@psf.upfronthosting.co.za>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Tue Dec 12 05:22:37 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 10:22:37 +0000
Subject: [docs] [issue31942] Document that support of start and stop
 parameters in the Sequence's index() is optional
In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za>
Message-ID: <1513074157.86.0.213398074469.issue31942@psf.upfronthosting.co.za>


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


New changeset 5ce0a2a100909104836f53a2c8823006ec46f8ad by Victor Stinner (Nitish Chandra) in branch 'master':
bpo-31942: Document optional support of start and stop attributes in Sequence.index method (#4277)
https://github.com/python/cpython/commit/5ce0a2a100909104836f53a2c8823006ec46f8ad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31942>
_______________________________________

From report at bugs.python.org  Tue Dec 12 05:22:41 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 Dec 2017 10:22:41 +0000
Subject: [docs] [issue31942] Document that support of start and stop
 parameters in the Sequence's index() is optional
In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za>
Message-ID: <1513074161.06.0.912454111764.issue31942@psf.upfronthosting.co.za>


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


----------
pull_requests: +4706

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31942>
_______________________________________

From report at bugs.python.org  Tue Dec 12 05:58:28 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 10:58:28 +0000
Subject: [docs] [issue31942] Document that support of start and stop
 parameters in the Sequence's index() is optional
In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za>
Message-ID: <1513076308.81.0.213398074469.issue31942@psf.upfronthosting.co.za>


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


New changeset 78cd00b799be36a35c9f5cc99ce3bcef31112a5f by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-31942: Document optional support of start and stop attributes in Sequence.index method (GH-4277) (#4811)
https://github.com/python/cpython/commit/78cd00b799be36a35c9f5cc99ce3bcef31112a5f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31942>
_______________________________________

From report at bugs.python.org  Tue Dec 12 05:58:55 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 10:58:55 +0000
Subject: [docs] [issue31942] Document that support of start and stop
 parameters in the Sequence's index() is optional
In-Reply-To: <1509786601.53.0.213398074469.issue31942@psf.upfronthosting.co.za>
Message-ID: <1513076335.58.0.213398074469.issue31942@psf.upfronthosting.co.za>


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

Thanks Nitish Chandra for your doc enhancement!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31942>
_______________________________________

From report at bugs.python.org  Tue Dec 12 06:02:40 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 11:02:40 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513076560.47.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

> If I only convert PyFrame_New() then I would need to add it to as existing page since the patch created a new page for Frame Objects.  I think the right place would be under the current PyFrameObject in Doc/c-api/veryhigh.rst?

Not, it's a very high level API, it's a low level API which should be referenced in the concrete.rst page, as I didn in my patch.

I think it's ok to have a page with only two functions: PyFrame_New() and  PyFrame_GetLineNumber().

Move https://docs.python.org/dev/c-api/reflection.html#c.PyFrame_GetLineNumber into your new doc, but leave something like "See also :c:func:`PyFrame_GetLineNumber`." there.

----------

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

From report at bugs.python.org  Tue Dec 12 06:04:51 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 11:04:51 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513076691.5.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"? Even if it's a rare useful, I think that it's ok to expose PyFrame_FastToLocalsWithError(), and maybe also PyFrame_FastToLocals().

It is useful you want write a debugger in pure C, and don't want to bother with fast locals special case.

----------

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

From report at bugs.python.org  Tue Dec 12 06:53:25 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Dec 2017 11:53:25 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513079605.59.0.213398074469.issue19431@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

frameobject.h is not included in any header file. Some effort was spent for avoiding including it in ceval.h, genobject.h, pystate.h and traceback.h. The whole content of frameobject.h is not available in the limited API. I'm not sure about the status of this API. This is not a very hight level API, but rather a very low level API. If document it, it should be documented on a separate page or on a page together with other low-level API.

> Serhiy: how are you supposed to modify local variables of a frame when these variables are stored in "fast locals"?

Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast(). This is very low-level manipulation. It exposes implementation details (at least you need to access PyFrameObject attributes directly). It should be documented that the most of PyFrame_* API is low-level and implementation specific. PyFrame_GetLineNumber() is an exception.

----------

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

From report at bugs.python.org  Tue Dec 12 06:58:23 2017
From: report at bugs.python.org (Massimiliano Culpo)
Date: Tue, 12 Dec 2017 11:58:23 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
Message-ID: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>


New submission from Massimiliano Culpo <massimiliano.culpo at googlemail.com>:

I am not really sure if what I am reporting is to be considered a bug in the interpreter (slice built-in), a lack in documentation or if it is just me not finding the proper references (in which case feel free to close this and sorry for the noise).

Anyhow, while trying to code a class that mimics built-in lists, I noticed a few seemingly inconsistent behaviors in the use of slices to set items.

This can be reduced down to this very simple example:
```
Python 3.6.2 (default, Jul 29 2017, 00:00:00) 
[GCC 4.8.4] on linux

# 1. Slice has start and stop, step is defaulted to None
>>> a = [1, 2, 3, 4]
>>> a[1:3] = [11, 22, 33, 44]
>>> a
[1, 11, 22, 33, 44, 4]

# 2. Same as above setting explicitly step == 1
>>> a = [1, 2, 3, 4]
>>> a[1:3:1] = [11, 22, 33, 44]
>>> a
[1, 11, 22, 33, 44, 4]

# 3. Trying to do the same thing with step == -1
# (I naively expected either [1, 44, 33, 22, 11, 4] or 2. to fail like 3.)
>>> a = [1, 2, 3, 4]
>>> a[3:1:-1] = [11, 22, 33, 44]
Traceback (most recent call last):
  File "<input>", line 1, in <module>
ValueError: attempt to assign sequence of size 4 to extended slice of size 2
```

Now, the first issue: I tried to search what an "extended slice" is exactly, but found nothing in the docs. What is written here

https://docs.python.org/3/library/functions.html#slice

seems to suggest that an "extended slice" is a slice where `step is not None`, but then I would expect case 2. to behave the same as case 3. So to me it appears as either lack of documentation on the behavior, or a bug in 2.

Second issue: in the same page in the docs it's written

> slice objects are also generated when extended indexing syntax is used. For example: a[start:stop:step] or a[start:stop, i]

I wasn't aware of the second syntax, and tried to use it:
```
>>> a = [1, 2, 3, 4]
>>> a[1:3:1]
[2, 3]
>>> a[1:3, 1]
Traceback (most recent call last):
  File "<input>", line 1, in <module>
TypeError: list indices must be integers or slices, not tuple
```
I guess that's not the result one would expect...

Third issue: slightly related, but here

https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types

I see that the documentation of `insert` reads:

> inserts x into s at the index given by i (same as s[i:i] = [x])

and from the interpreter:
```
help(list.insert)
Help on method_descriptor:
insert(...)
    L.insert(index, object) -- insert object before index

```

Here the fact is that `insert` really behaves like `s[i:i] = [x]`, but in my understanding it doesn't keep the promise to `insert object before index`.
```
# "Out of bounds" on the right
>>> a = [1, 2, 3, 4]
>>> a.insert(101, 11)
>>> a
[1, 2, 3, 4, 11]

# "Out of bounds" on the left
>>> a.insert(-101, 11)
>>> a
[11, 1, 2, 3, 4]
```
I don't know honestly if docs are not clear here, or if it is just me, but I didn't expect this behavior and thought it was worth reporting.

Let me know if you need more information.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 308120
nosy: Massimiliano Culpo, docs at python
priority: normal
severity: normal
status: open
title: Inconsistent behavior with slice assignment?
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 07:39:47 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 12 Dec 2017 12:39:47 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513082387.35.0.213398074469.issue32288@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Please don't report three issues under one ticket, unless they are so closely related that they cannot be separated.

I don't understand what your second issue actually is. You refer to the docs that specify extended syntax as [start:stop:step] but then you tried [start:stop,step] which is correctly an error. (Notice the comma instead of colon.)

And again, your third issue to do with list.insert ... what is your actual bug report? Have you found an example where these aren't equivalent?

alist.insert(pos, value)

alist[pos:pos] = [value]

I don't understand your third bug report here... you show two examples where the insert function works as documented. You say you didn't expect the behaviour, but what behaviour did you expect?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 07:46:19 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Dec 2017 12:46:19 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513082779.44.0.213398074469.issue32288@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Python lists don't implement extended slices, try numpy arrays:

>>> import numpy as np
>>> x = array([[1,2,3], [4,5,6]])
>>> x[:, 2]
array([3, 6])
>>> 
>>> lst = [[1,2,3], [4,5,6]]
>>> lst[:, 2]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: list indices must be integers or slices, not tuple
>>> 

Was there any issue apart from the extended slices?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 08:03:53 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 12 Dec 2017 13:03:53 +0000
Subject: [docs] [issue32289] Glossary does not define "extended slicing"
Message-ID: <1513083833.6.0.213398074469.issue32289@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

Looking at issue 32288, I realised that the glossary doesn't define "extended slicing" or "extended slice", even though they are common terms. Although I thought I know what they meant, on closer reflection I realised I wasn't sure.

Does extended slicing refer to slice *objects* with a stride/step, as opposed to slice objects all the way back in Python 1.3 (yes, *one* point 3) that only had start and end?

Does it refer specifically to the two-colon form of slice *syntax*?

Both? Neither?

https://docs.python.org/3/glossary.html#term-slice

The only documentation I found is from the 2.3 What's New:

https://docs.python.org/2.3/whatsnew/section-slices.html

----------
assignee: docs at python
components: Documentation
messages: 308125
nosy: Massimiliano Culpo, docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Glossary does not define "extended slicing"
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32289>
_______________________________________

From varunchalla1729 at gmail.com  Thu Dec  7 13:44:30 2017
From: varunchalla1729 at gmail.com (Varun Challa)
Date: Fri, 8 Dec 2017 00:14:30 +0530
Subject: [docs] Requesting IDLE Source Code
In-Reply-To: <CAKJDb-NP-ncRPn-7TLW-eVmW3smXCEf8AvCbuPtjMvVcv=pWpw@mail.gmail.com>
References: <CAEzLL+nhqtDqs+VX_zO7_RiDh0SnWyq-oemhWkyfEkqPF60W0w@mail.gmail.com>
 <CAKJDb-NP-ncRPn-7TLW-eVmW3smXCEf8AvCbuPtjMvVcv=pWpw@mail.gmail.com>
Message-ID: <CAEzLL+kHcZXyZeOGXsvah03cf7qPqDGdrC3H+med_dTg5WB28A@mail.gmail.com>

Thanks a lot.

On Dec 7, 2017 9:56 PM, "Zachary Ware" <zachary.ware+pydocs at gmail.com>
wrote:

> On Thu, Dec 7, 2017 at 3:29 AM, Varun Challa <varunchalla1729 at gmail.com>
> wrote:
> > Hi ,
> >
> > My Name is Varun Challa.
>
> Hi Varun,
>
> > I am learning Tkinter Module in Pyhton.I came to know that Python IDLE
> > editor is written in Tkinter.
> > so I am requesting you please send me the IDLE source code.
>
> IDLE is bundled as part of the CPython standard library, and as such
> its source code can be found within the rest of the CPython source at
> https://github.com/python/cpython/tree/master/Lib/idlelib
>
> Regards,
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171208/c609f649/attachment-0001.html>

From report at bugs.python.org  Tue Dec 12 08:05:25 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Dec 2017 13:05:25 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513083925.1.0.213398074469.issue32288@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

I see the first issue now and I agree that Python behaves strangely.

Numpy
=====

>>> x = array([1,2,3])
>>> x[1:2] = [1,2,3,4,5]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot copy sequence with size 5 to array axis with dimension 1


Python
======

>>> lst = [1,2,3]
>>> lst[1:2] = [1,2,3,4,5]
>>> lst
[1, 1, 2, 3, 4, 5, 3]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 08:12:33 2017
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Dec 2017 13:12:33 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1513084353.96.0.213398074469.issue19431@psf.upfronthosting.co.za>


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

> Currently you should call PyFrame_FastToLocalsWithError(), modify directly f_locals, and call PyFrame_LocalsToFast().

When happens if PyFrame_LocalsToFast() isn't called? Does it crash or is it just slower?

----------

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

From report at bugs.python.org  Tue Dec 12 08:37:58 2017
From: report at bugs.python.org (Massimiliano Culpo)
Date: Tue, 12 Dec 2017 13:37:58 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513085877.99.0.213398074469.issue32288@psf.upfronthosting.co.za>


Massimiliano Culpo <massimiliano.culpo at googlemail.com> added the comment:

Steven and Stefan, thanks for the quick replies, even though they are giving slightly different answers to the same questions :-)

@steven.daprano
> You refer to the docs that specify extended syntax as [start:stop:step] but then you tried [start:stop,step] which is correctly an error. (Notice the comma instead of colon.)

Maybe you missed the quote from the docs: "For example: a[start:stop:step] or a[start:stop, i]"

You say that the docs "specify extended syntax as [start:stop:step]". Apparently you're also surprised this syntax exists, and didn't notice that the error is not a SyntaxError, but a TypeError. I argue then that the syntax is there. If I get correctly what @skrah says, he seems to suggest that the syntax is there, but no built-in type is using it. Am I right?

> And again, your third issue to do with list.insert ... what is your actual bug report? Have you found an example where these aren't equivalent?

I didn't say that. I actually said "`insert` really behaves like `s[i:i] = [x]`". But the docs from the interpreter say:
```
help(list.insert)
Help on method_descriptor:
insert(...)
    L.insert(index, object) -- insert object before index

```
What does it mean to insert an object before index 101 or -101 of a 4 items list? I think if the help said "-- same as L[index:index] = [object]" I would have been fine with it.

> Please don't report three issues under one ticket, unless they are so closely related that they cannot be separated.

Apologies if this was not correct (I see you started an issue with a smaller scope). But I thought they were closely related, because all three might have been fixed by a rewording of a few parts of the docs dealing with slices.

@skrah
> I see the first issue now and I agree that Python behaves strangely.

To be clear, I don't have issues with:
```
>>> lst = [1,2,3]
>>> lst[1:2] = [1,2,3,4,5]
>>> lst
[1, 1, 2, 3, 4, 5, 3]
```
in Python, which probably is a widely used idiom to modify lists. 

My concerns are with the fact that you get the same behavior when you use `lst[1:2:1]` (which in my understanding is an extended slice), but you get a `ValueError` for any other value of `slice.step`. That might be something worth clarifying as part of issue32289 maybe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 08:47:31 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Dec 2017 13:47:31 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513086451.82.0.213398074469.issue32288@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Okay, the different meanings of "extended slicing" seem to be an old
problem:

https://mail.python.org/pipermail/tutor/2007-July/055838.html


I assumed it referred to numpy's tuple indexing syntax, but it is
apparently also used for referring to the step value of a single
slice object.


Somehow I've always used the term for the tuple syntax.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 09:10:32 2017
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Dec 2017 14:10:32 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513087832.48.0.213398074469.issue32288@psf.upfronthosting.co.za>


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

It actually makes sense that a slice assignment with a different length replacement list with a step of 1 works but any other step doesn't.  Logically you can see that you can cut out a chunk and replace it with a different sized chunk, but you can't do that if the step is not abs(1).  So a doc tweak may be appropriate.  And it is surprising that -1 doesn't work (but why would you ever use it? :), so that might be a buglet.

For a numpy array, I imagine the rules are different, so an error there on stride 1 is not that surprising either, though *perhaps* there is room for improvement on the numpy side.  (In other words, the stride 1 python behavior is "correct" from a python language perspective.)

And yes, it would be much easier to discuss these separate issues in separate issues.  Now you know for next time :)

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 09:34:22 2017
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 12 Dec 2017 14:34:22 +0000
Subject: [docs] [issue32288] Inconsistent behavior with slice assignment?
In-Reply-To: <1513079903.38.0.213398074469.issue32288@psf.upfronthosting.co.za>
Message-ID: <1513089262.53.0.213398074469.issue32288@psf.upfronthosting.co.za>


Stefan Krah <stefan at bytereef.org> added the comment:

Thanks, David, you are of course right! -- I've worked so much with fixed arrays in the past year that Python's behavior seemed odd and unfathomable. :-)


[Numpy arrays can't adopt that behavior, because growing them would be too expensive.]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32288>
_______________________________________

From report at bugs.python.org  Tue Dec 12 13:18:22 2017
From: report at bugs.python.org (Sanyam Khurana)
Date: Tue, 12 Dec 2017 18:18:22 +0000
Subject: [docs] [issue22671] Typo in class io.BufferedIOBase docs
In-Reply-To: <1413711352.27.0.0253692424247.issue22671@psf.upfronthosting.co.za>
Message-ID: <1513102702.54.0.912454111764.issue22671@psf.upfronthosting.co.za>


Change by Sanyam Khurana <sanyam.khurana01 at gmail.com>:


----------
pull_requests: +4708

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22671>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:08:58 2017
From: report at bugs.python.org (Sebastian Rittau)
Date: Wed, 13 Dec 2017 08:08:58 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513152538.29.0.912454111764.issue32284@psf.upfronthosting.co.za>


Change by Sebastian Rittau <srittau at rittau.biz>:


----------
keywords: +patch
pull_requests: +4723
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:39:15 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 08:39:15 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513154355.91.0.912454111764.issue32284@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:40:01 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 08:40:01 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513154401.2.0.213398074469.issue32284@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset c3e070f84931c847d1b35e7fb36aa71edd6215f6 by Andrew Svetlov (Sebastian Rittau) in branch 'master':
bpo-32284: Fix documentation of BinaryIO and TextIO (#4832)
https://github.com/python/cpython/commit/c3e070f84931c847d1b35e7fb36aa71edd6215f6


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:40:31 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Dec 2017 08:40:31 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513154431.15.0.912454111764.issue32284@psf.upfronthosting.co.za>


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


----------
pull_requests: +4725

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:59:07 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 08:59:07 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513155547.33.0.213398074469.issue32284@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset b0358e8784821867ab05b3d890717c37309be849 by Andrew Svetlov (Miss Islington (bot)) in branch '3.6':
bpo-32284: Fix documentation of BinaryIO and TextIO (GH-4832) (#4833)
https://github.com/python/cpython/commit/b0358e8784821867ab05b3d890717c37309be849


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:59:40 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 08:59:40 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513155580.33.0.912454111764.issue32284@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 03:59:55 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 08:59:55 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513155595.08.0.213398074469.issue32284@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Done

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Wed Dec 13 05:13:31 2017
From: report at bugs.python.org (Maik Ro)
Date: Wed, 13 Dec 2017 10:13:31 +0000
Subject: [docs] [issue32301] Typo in array documentation
Message-ID: <1513160011.36.0.213398074469.issue32301@psf.upfronthosting.co.za>


New submission from Maik Ro <lefthand3r at googlemail.com>:

.. class:: array(typecode[, initializer])

should be 

typecode, [initializer] - comma is in square brackets

----------
assignee: docs at python
components: Documentation
messages: 308195
nosy: Maik Ro, docs at python
priority: normal
severity: normal
status: open
title: Typo in array documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32301>
_______________________________________

From report at bugs.python.org  Wed Dec 13 06:06:50 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 13 Dec 2017 11:06:50 +0000
Subject: [docs] [issue32301] Typo in array documentation
In-Reply-To: <1513160011.36.0.213398074469.issue32301@psf.upfronthosting.co.za>
Message-ID: <1513163210.2.0.213398074469.issue32301@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The given version is correct: the comma is only required if the initializer is given. Your suggested version 

    typecode, [initializer]

implies that the comma is always required whether the initializer is given or not.

If we want to be absolutely pedantic, we could write:

    .. class:: array(typecode[, [initializer]])

as trailing commas are legal in function calls. But I don't think that makes for good documentation.

----------
nosy: +steven.daprano
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32301>
_______________________________________

From dave.cs at thriftechs.com  Tue Dec 12 14:46:57 2017
From: dave.cs at thriftechs.com (David VanderWyst)
Date: Tue, 12 Dec 2017 13:46:57 -0600
Subject: [docs] Suggestion/request
Message-ID: <7cd755bd-ece9-3fba-d77f-63d0f2eb36b0@thriftechs.com>

While the plain text documents are really close, it would be nice to see 
a markdown formatted version of the documentation, even replacing the 
.txt version with a markdown set could be benificial.

Markdown can easily be converted to plain text if necessary, and to html 
for viewing. I'm not sure if there is enough demand for this to make it 
worth it or not, but I would see it as an asset but a bigger undertaking 
than I could do alone.

plain text lacks a lot of the formatting needed to differentiate between 
code comments and code snipits when rendering it directly as markdown 
with tools like md-fileserver. The plain text works great for custom 
search tools when using a local file store for the documentation and 
markdown wouldn't hinder that.


-- 
------------------------------------------------------------------------
David VanderWyst
Owner, Thriftech services <https://thriftechs.com/>
dave.cs at thriftechs.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171212/df6edbff/attachment.html>

From florian.link at mevis.de  Tue Dec 12 09:26:11 2017
From: florian.link at mevis.de (Florian Link)
Date: Tue, 12 Dec 2017 15:26:11 +0100
Subject: [docs] PyImport_ExecCodeModuleWithPathnames documentation is wrong
Message-ID: <58df2f46-ef45-abed-ab9c-eb219b138962@mevis.de>

Hi,

the PyImport_ExecCodeModuleWithPathnames documentation states that the 
char* strings should be encoded in UTF-8.

But looking at the Python C code, it is aparent that 
PyUnicode_DecodeFSDefault is used to convert these string, so the 
documentation need to state the the string should be encoded as in the 
default of the local filesystem.

https://docs.python.org/3/c-api/import.html#c.PyImport_ExecCodeModuleWithPathnames

regards,
Florian

P.S. I ran into this because I passed in UTF-8 and the __file__ 
attribute of the imported modules was wrong afterwards.

-- 
------------------------------------------------------------------------
Florian Link
MeVisLab

Tel.: +49-421-22495 579
Fax:  +49-421-22495 899
www.mevis.de / www.mevislab.de

MeVis Medical Solutions AG
Caroline-Herschel-Str. 1
28359 Bremen
Germany

Trade Registry: Bremen HRB 23791
VAT ID: DE250659412

Executive Board: Marcus Kirchhoff (Chairman), Dr. Robert Hannemann
Chairperson of Supervisory Board: Kimberley E. Honeysett


From tropinin at iptech.kz  Tue Dec 12 23:10:39 2017
From: tropinin at iptech.kz (Oleg Tropinin)
Date: Wed, 13 Dec 2017 10:10:39 +0600
Subject: [docs] Mistake - gzip.open
Message-ID: <1036ac93-32d5-aed6-106c-ce30e3e0461b@iptech.kz>

Hi,

Pls replace "open" to "gzip.open" when code open file.txt.


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

Example of how to GZIP compress an existing file:

import  gzip
import  shutil
with  _open_('file.txt',  'rb')  as  f_in,  gzip.open('file.txt.gz',  'wb')  as  f_out:
     shutil.copyfileobj(f_in,  f_out)



Regards
Oleg Tropinin

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

From senthil at uthcode.com  Wed Dec 13 09:27:57 2017
From: senthil at uthcode.com (Senthil Kumaran)
Date: Wed, 13 Dec 2017 06:27:57 -0800
Subject: [docs] Mistake - gzip.open
In-Reply-To: <1036ac93-32d5-aed6-106c-ce30e3e0461b@iptech.kz>
References: <1036ac93-32d5-aed6-106c-ce30e3e0461b@iptech.kz>
Message-ID: <CAPOVWOQPq5SF-cAJSifbaFzhROYk0YGaSnL1Ugt3HjUMsAqT-g@mail.gmail.com>

Hi Oleg,

The example is correct. Nothing needs to be changed there.

Thanks!

On Tue, Dec 12, 2017 at 8:10 PM, Oleg Tropinin <tropinin at iptech.kz> wrote:

> Hi,
>
> Pls replace "open" to "gzip.open" when code open file.txt.
>
>
> https://docs.python.org/2/library/gzip.html
>
> Example of how to GZIP compress an existing file:
>
> import gzipimport shutilwith *open*('file.txt', 'rb') as f_in, gzip.open('file.txt.gz', 'wb') as f_out:
>     shutil.copyfileobj(f_in, f_out)
>
>
>
> Regards
> Oleg Tropinin
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171213/6cdb0fb0/attachment-0001.html>

From report at bugs.python.org  Wed Dec 13 11:33:05 2017
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 13 Dec 2017 16:33:05 +0000
Subject: [docs] [issue10344] codecs.open() buffering doc needs fix
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1513182785.68.0.677646281364.issue10344@psf.upfronthosting.co.za>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +4731
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10344>
_______________________________________

From mariatta.wijaya at gmail.com  Wed Dec 13 12:39:48 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Wed, 13 Dec 2017 09:39:48 -0800
Subject: [docs] Suggestion/request
In-Reply-To: <7cd755bd-ece9-3fba-d77f-63d0f2eb36b0@thriftechs.com>
References: <7cd755bd-ece9-3fba-d77f-63d0f2eb36b0@thriftechs.com>
Message-ID: <CAGbohnY_qyrfJzbTVTFzEThp5-YU2pt5SNSqsKvBhaQf1qgkTg@mail.gmail.com>

Python documentation are written in Restructured Text and built with
Sphinx. It is not plain text.
We won't be switching from ReST to Markdown.

If what you're after is a downloadable copy of the docs in ReST, it is part
of CPython source code.
You can clone/download it from GitHub: https://github.com/python/cpython


On Dec 13, 2017 5:44 AM, "David VanderWyst" <dave.cs at thriftechs.com> wrote:

While the plain text documents are really close, it would be nice to see a
markdown formatted version of the documentation, even replacing the .txt
version with a markdown set could be benificial.

Markdown can easily be converted to plain text if necessary, and to html
for viewing. I'm not sure if there is enough demand for this to make it
worth it or not, but I would see it as an asset but a bigger undertaking
than I could do alone.

plain text lacks a lot of the formatting needed to differentiate between
code comments and code snipits when rendering it directly as markdown with
tools like md-fileserver. The plain text works great for custom search
tools when using a local file store for the documentation and markdown
wouldn't hinder that.


-- 
------------------------------
David VanderWyst
Owner, Thriftech services <https://thriftechs.com/>
dave.cs at thriftechs.com

_______________________________________________
docs mailing list
docs at python.org
https://mail.python.org/mailman/listinfo/docs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171213/96d8c50b/attachment.html>

From report at bugs.python.org  Wed Dec 13 14:54:21 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 19:54:21 +0000
Subject: [docs] [issue32309] Implement asyncio.create_task() and
 asyncio.run_in_executor shortcuts
Message-ID: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

loop.create_task() and loop.run_in_executor are present very often in user code. But they are require a loop instance, actual call looks like

loop = asyncio.get_running_loop()
loop.create_task(coro())

The proposal adds create_task(coro) and run_in_executor(executor, func, *args) shortcuts for this.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 308238
nosy: asvetlov, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Implement asyncio.create_task() and asyncio.run_in_executor shortcuts
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Wed Dec 13 14:55:39 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 13 Dec 2017 19:55:39 +0000
Subject: [docs] [issue32309] Implement asyncio.create_task() and
 asyncio.run_in_executor shortcuts
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1513194939.15.0.912454111764.issue32309@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
keywords: +patch
pull_requests: +4736
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Wed Dec 13 15:03:46 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 13 Dec 2017 20:03:46 +0000
Subject: [docs] [issue32309] Implement asyncio.create_task() and
 asyncio.run_in_executor shortcuts
In-Reply-To: <1513194861.88.0.213398074469.issue32309@psf.upfronthosting.co.za>
Message-ID: <1513195426.44.0.213398074469.issue32309@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I don't like the low-level API of run_in_executor.  "executor" being the first argument, the inability to pass **kwargs, etc.

I'd expect to see a more high-level API, perhaps the one that supports 'async with':

    async with asyncio.ThreadPool() as pool:
        f1 = pool.run(func1)
        f2 = pool.run(func2)
        r3 = await pool.run(func3)

    r1 = f1.result()
    r2 = f2.result()
    print(r1, r2, r3)

I mean it's great that we can use 'concurrent.futures' in asyncio, but having native asyncio pools implementation would be way more convenient to the users.

In any case, can we focus this issue on the "run_in_executor" API, and open a new one for "create_task"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32309>
_______________________________________

From report at bugs.python.org  Thu Dec 14 09:44:08 2017
From: report at bugs.python.org (Rostislav Kondratenko)
Date: Thu, 14 Dec 2017 14:44:08 +0000
Subject: [docs] [issue32322] Heap type with Py_TPFLAGS_HAVE_GC leads to
 segfault due to not incrementing type object refcout in PyObject_GC_New
Message-ID: <1513262648.0.0.213398074469.issue32322@psf.upfronthosting.co.za>


New submission from Rostislav Kondratenko <grostik at gmail.com>:

If one creates a type with both Py_TPFLAGS_HAVE_GC and Py_TPFLAGS_HEAPTYPE set and implemented, one has to create instances with PyObject_GC_New() per current docs: https://docs.python.org/3.7/c-api/gcsupport.html .

However, PyObject_GC_New() unlike PyType_GenericAlloc() does not increment refcount of a type object. As the refcount is still decremented when instances are destroyed, it leads to steady drain on type object's refcount. Eventually it reaches zero and the type object gets deleted while there are still instances and references to it. And it usually results in crash after a number of instances (20-50 is usually enough) is created and destroyed.

One should either update the docs to point that call to PyType_GenericAlloc() would be sufficient (as it would use _PyObject_GC_Malloc() and increment refcount when appropriate) or update _PyObject_GC_New() code to increment type object's refcount when the type is heap type. Or both.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 308302
nosy: docs at python, rkond
priority: normal
severity: normal
status: open
title: Heap type with Py_TPFLAGS_HAVE_GC leads to segfault due to not incrementing type object refcout in PyObject_GC_New
type: crash
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32322>
_______________________________________

From chensy at mathstat.yorku.ca  Thu Dec 14 10:57:33 2017
From: chensy at mathstat.yorku.ca (Michael)
Date: Thu, 14 Dec 2017 10:57:33 -0500
Subject: [docs] windows help file .chm corrupted
Message-ID: <158666f3-1d03-01e6-7213-90ee39a8f2e0@mathstat.yorku.ca>

Hi, there,

The windows help file .chm is corrupted. No contents are available.

https://www.python.org/ftp/python/3.6.4/python364rc1.chm

-- 
Sincerely Yours,
Michael Chen, Associate Professor
Dept. Math & Stats, York Univ.
Office: TEL 2034
tel.: 416-736-2100 ext. 66677


From report at bugs.python.org  Thu Dec 14 15:44:51 2017
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 14 Dec 2017 20:44:51 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513284291.22.0.912454111764.issue28393@psf.upfronthosting.co.za>


Change by Ville Skytt? <ville.skytta at iki.fi>:


----------
pull_requests: +4762

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Thu Dec 14 15:48:24 2017
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Thu, 14 Dec 2017 20:48:24 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513284504.05.0.213398074469.issue28393@psf.upfronthosting.co.za>


Ville Skytt? <ville.skytta at iki.fi> added the comment:

I'm getting a 500 internatl server error trying to update https://bugs.python.org/review/28393/, so noting here that the latest review issue has been addressed in https://github.com/python/cpython/pull/4871

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Fri Dec 15 05:19:30 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 10:19:30 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513333170.07.0.213398074469.issue28393@psf.upfronthosting.co.za>


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


New changeset 297fd876aad8ef443d8992618de22c46dbda258b by Victor Stinner (Ville Skytt?) in branch 'master':
bpo-28393: Update encoding lookup docs wrt bpo-27938 (#4871)
https://github.com/python/cpython/commit/297fd876aad8ef443d8992618de22c46dbda258b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Fri Dec 15 05:20:02 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Dec 2017 10:20:02 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513333202.93.0.912454111764.issue28393@psf.upfronthosting.co.za>


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


----------
pull_requests: +4776

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Fri Dec 15 09:23:26 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 14:23:26 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513347806.33.0.213398074469.issue28393@psf.upfronthosting.co.za>


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


New changeset 77bf6da7258b4a312e224860ea50ac010aa17c1e by Victor Stinner (Miss Islington (bot)) in branch '3.6':
bpo-28393: Update encoding lookup docs wrt bpo-27938 (GH-4871) (#4881)
https://github.com/python/cpython/commit/77bf6da7258b4a312e224860ea50ac010aa17c1e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Fri Dec 15 09:23:53 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 14:23:53 +0000
Subject: [docs] [issue28393] Update encoding lookup docs wrt #27938
In-Reply-To: <1476013149.31.0.17921258936.issue28393@psf.upfronthosting.co.za>
Message-ID: <1513347833.16.0.213398074469.issue28393@psf.upfronthosting.co.za>


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

Thank you Ville Skytt? for your contribution! I merged your PR and backported it to Python 3.6.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28393>
_______________________________________

From report at bugs.python.org  Fri Dec 15 10:09:10 2017
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Dec 2017 15:09:10 +0000
Subject: [docs] [issue32124] Document functions safe to be called before
 Py_Initialize()
In-Reply-To: <1511529556.02.0.213398074469.issue32124@psf.upfronthosting.co.za>
Message-ID: <1513350550.79.0.912454111764.issue32124@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32124>
_______________________________________

From report at bugs.python.org  Fri Dec 15 15:50:25 2017
From: report at bugs.python.org (Stefan Pochmann)
Date: Fri, 15 Dec 2017 20:50:25 +0000
Subject: [docs] [issue32341] itertools "generators"?
Message-ID: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>


New submission from Stefan Pochmann <stefan.pochmann at gmail.com>:

The itertools page https://docs.python.org/3.6/library/itertools.html says "Combinatoric generators:" above the table with product(), permutations(), etc. But as far as I understand, they're not generators and they don't produce generator iterators. I think the table title should be "Combinatoric iterators:" instead, in line with "Infinite Iterators:" and "Iterators terminating on the shortest input sequence:" of the two tables above it.

Reference:
https://docs.python.org/3/glossary.html#term-generator

----------
assignee: docs at python
components: Documentation
messages: 308425
nosy: Stefan Pochmann, docs at python
priority: normal
severity: normal
status: open
title: itertools "generators"?
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 15:59:22 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Dec 2017 20:59:22 +0000
Subject: [docs] [issue32341] itertools "generators"?
In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>
Message-ID: <1513371562.53.0.213398074469.issue32341@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The term is used in the generic sense rather than the sense of an actual type.  That said, I don't mind changing "Combinatoric generators" to "Combinatoric iterators" for 3.6 and 3.7.   Otherwise, this isn't worth the backport effort.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low
versions:  -Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 16:11:48 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Dec 2017 21:11:48 +0000
Subject: [docs] [issue32341] itertools "generators"?
In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>
Message-ID: <1513372308.98.0.912454111764.issue32341@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4786
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 16:28:31 2017
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 Dec 2017 21:28:31 +0000
Subject: [docs] [issue32341] itertools "generators"?
In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>
Message-ID: <1513373311.13.0.912454111764.issue32341@psf.upfronthosting.co.za>


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


----------
pull_requests: +4790

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 16:30:05 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Dec 2017 21:30:05 +0000
Subject: [docs] [issue32341] itertools "generators"?
In-Reply-To: <1513371025.57.0.213398074469.issue32341@psf.upfronthosting.co.za>
Message-ID: <1513373405.87.0.912454111764.issue32341@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32341>
_______________________________________

From report at bugs.python.org  Fri Dec 15 22:39:59 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Dec 2017 03:39:59 +0000
Subject: [docs] [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1513395599.99.0.912454111764.issue17972@psf.upfronthosting.co.za>


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


----------
type: enhancement -> behavior
versions: +Python 3.7 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Fri Dec 15 22:41:50 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Dec 2017 03:41:50 +0000
Subject: [docs] [issue32261] Online doc does not include
 inspect.classify_class_attrs
In-Reply-To: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za>
Message-ID: <1513395710.78.0.213398074469.issue32261@psf.upfronthosting.co.za>


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

Perhaps this should be closed as a 1/10 duplicate of #17972.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32261>
_______________________________________

From report at bugs.python.org  Fri Dec 15 22:57:44 2017
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Dec 2017 03:57:44 +0000
Subject: [docs] [issue32263] Template string docs refer to "normal %-based
 substitutions"
In-Reply-To: <1512855398.42.0.213398074469.issue32263@psf.upfronthosting.co.za>
Message-ID: <1513396664.79.0.213398074469.issue32263@psf.upfronthosting.co.za>


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

https://github.com/python/cpython/commit/9f74deba784fc8781d13ed564f69c02ed7c331bb

merged by Warsaw (last March).  It removed the whole phrase, "Instead of the normal %-based substitutions,"  I think the other changes would be more worth backporting, (assuming correct for 3.6, which I believe they are) if anything is.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32263>
_______________________________________

From report at bugs.python.org  Sun Dec 17 00:29:21 2017
From: report at bugs.python.org (=?utf-8?b?7JaR7Jyg7ISd?=)
Date: Sun, 17 Dec 2017 05:29:21 +0000
Subject: [docs] [issue32349] Add detailed return value information for
 set.intersection function
Message-ID: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za>


New submission from ??? <ileixe at gmail.com>:

I think it's intentional behavior seems to be minor though.

At a glance, I assume that a.set(b) should return items in a. But I found out the implementation always return items in smaller set.

There is no issue for common case, but custom class can make a trouble. So, I think additional information of return value is helpful.

----------
assignee: docs at python
components: Documentation
messages: 308484
nosy: docs at python, ???
priority: normal
severity: normal
status: open
title: Add detailed return value information for set.intersection function
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32349>
_______________________________________

From report at bugs.python.org  Sun Dec 17 13:28:43 2017
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 17 Dec 2017 18:28:43 +0000
Subject: [docs] [issue32349] Add detailed return value information for
 set.intersection function
In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za>
Message-ID: <1513535323.79.0.213398074469.issue32349@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

To clarify, are you referring to this behaviour?

>>> a = {1, 2, 3}
>>> b = {1.0, 4.0}
>>> a.intersection(b)  # expect {1}
{1.0}

I'd personally expect this to be implementation-dependent: since for set operations you usually only care about objects up to equality, it would be a bit unusual to care whether you get {1} or {1.0} in the above situation, and I'd say the implementation should be free to do whatever's convenient. Making documented guarantees would unnecessarily constrain other implementations.

I suppose one could document the *lack* of a guarantee here ...

----------
nosy: +mark.dickinson, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32349>
_______________________________________

From report at bugs.python.org  Sun Dec 17 15:09:34 2017
From: report at bugs.python.org (Decorater)
Date: Sun, 17 Dec 2017 20:09:34 +0000
Subject: [docs] [issue32353] Add docs about Embedding with an frozen module
 limitation.
Message-ID: <1513541374.74.0.213398074469.issue32353@psf.upfronthosting.co.za>


New submission from Decorater <seandhunt_7 at yahoo.com>:

It seems that 1 thing that bites me is that there is no section on the embedding docs about limitations to using frozen modules in them.

So lets say for example your program has this like in the main function on an embedded python:

```c
  PyRun_SimpleString("import mymodule");
```

And lets say ``mymodule`` is supposed to be an frozen module in that embedded interpreter named ``myprogram``

It would fail to work because it wont be able to find ``mymodule`` when it really should. This doc change should help fix that senerio and hopefully suggest an fix to that senerio as well.

----------
assignee: docs at python
components: Documentation
messages: 308497
nosy: Decorater, docs at python
priority: normal
severity: normal
status: open
title: Add docs about Embedding with an frozen module limitation.
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32353>
_______________________________________

From report at bugs.python.org  Sun Dec 17 15:09:59 2017
From: report at bugs.python.org (Decorater)
Date: Sun, 17 Dec 2017 20:09:59 +0000
Subject: [docs] [issue32353] Add docs about Embedding with an frozen module
 limitation.
In-Reply-To: <1513541374.74.0.213398074469.issue32353@psf.upfronthosting.co.za>
Message-ID: <1513541399.88.0.912454111764.issue32353@psf.upfronthosting.co.za>


Change by Decorater <seandhunt_7 at yahoo.com>:


----------
keywords: +patch
pull_requests: +4804
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32353>
_______________________________________

From report at bugs.python.org  Mon Dec 18 03:00:14 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Dec 2017 08:00:14 +0000
Subject: [docs] [issue32349] Add detailed return value information for
 set.intersection function
In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za>
Message-ID: <1513584014.23.0.213398074469.issue32349@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The implementation detail is not documented because it is not guaranteed.  The behavior has changed over time and other implementation are allowed to do something different.  For example, collections.abc.Set.__and__ has different behavior.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32349>
_______________________________________

From report at bugs.python.org  Mon Dec 18 05:17:27 2017
From: report at bugs.python.org (Mark)
Date: Mon, 18 Dec 2017 10:17:27 +0000
Subject: [docs] [issue32362] multiprocessing.connection.Connection
 misdocumented as multiprocessing.Connection
Message-ID: <1513592247.3.0.213398074469.issue32362@psf.upfronthosting.co.za>


New submission from Mark <markamery at btinternet.com>:

https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Connection purports to document the multiprocessing.Connection class. There's no such thing:

Python 3.6.1 (v3.6.1:69c0db5050, Mar 21 2017, 01:21:04) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import multiprocessing
>>> multiprocessing.Connection
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: module 'multiprocessing' has no attribute 'Connection'

I think it should be multiprocessing.connection.Connection?

----------
assignee: docs at python
components: Documentation
messages: 308539
nosy: Amery, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.connection.Connection misdocumented as multiprocessing.Connection
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32362>
_______________________________________

From report at bugs.python.org  Mon Dec 18 05:21:12 2017
From: report at bugs.python.org (=?utf-8?b?7JaR7Jyg7ISd?=)
Date: Mon, 18 Dec 2017 10:21:12 +0000
Subject: [docs] [issue32349] Add detailed return value information for
 set.intersection function
In-Reply-To: <1513488561.11.0.213398074469.issue32349@psf.upfronthosting.co.za>
Message-ID: <1513592472.21.0.213398074469.issue32349@psf.upfronthosting.co.za>


??? <ileixe at gmail.com> added the comment:

Ok, I got a point of implementation-dependent things. Thank you for comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32349>
_______________________________________

From gherson at snet.net  Sat Dec 16 13:17:26 2017
From: gherson at snet.net (George Herson)
Date: Sat, 16 Dec 2017 18:17:26 +0000 (UTC)
Subject: [docs] confusing sentence correction
References: <590824329.372332.1513448246395.ref@mail.yahoo.com>
Message-ID: <590824329.372332.1513448246395@mail.yahoo.com>

Dear Sir/Ms.,
Just a suggestion (that I think is a good one):?From page?4. More Control Flow Tools ? Python 3.6.4rc1 documentation?simply?remove sentence "When used with a loop, the?else?clause has more in common with the?else?clause of a?try?statement than it does that of?if?statements: a?try?statement?s?else?clause runs when no exception occurs, and a loop?s?else?clause runs when no?break?occurs."??
I think that sentence is unnecessary and needlessly misleading and confusing.? When examined closely, what the documentation specifies is that the else?actually works the same with while as it does with if?(namely that the?else?block is not executed if the loop exits by break).
best regards,George Herson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171216/cc133eb6/attachment-0001.html>

From wagherculano at hotmail.com  Thu Dec 14 18:54:55 2017
From: wagherculano at hotmail.com (Wagner Herculano)
Date: Thu, 14 Dec 2017 23:54:55 +0000
Subject: [docs] f-strings
Message-ID: <BN6PR19MB0946E24821B0A065728B3B73DB0A0@BN6PR19MB0946.namprd19.prod.outlook.com>

Good evening,
I'm Wagner Herculano from Brazil.
I was trying to do a table exercise with number 5 and tried formatting spaces and did not find it in PEP 498 documentation.
Finally I found a way, if possible, include this example in the documentation please.

Below is my script with the desired formatting about table of 5.

n = 5
for i in range(1,11):
    print(f'{n} x {i:>2} = {n*i:>2}')

Result
5 x  1 =  5
5 x  2 = 10
5 x  3 = 15
5 x  4 = 20
5 x  5 = 25
5 x  6 = 30
5 x  7 = 35
5 x  8 = 40
5 x  9 = 45
5 x 10 = 50
-----------
Sorry my English, I needed to use Google Translate

Best Regards,
    Wagner Herculano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171214/2d958c14/attachment.html>

From report at bugs.python.org  Mon Dec 18 09:32:57 2017
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Dec 2017 14:32:57 +0000
Subject: [docs] [issue19847] Setting the default filesystem-encoding
In-Reply-To: <1385850592.6.0.425449057763.issue19847@psf.upfronthosting.co.za>
Message-ID: <1513607577.61.0.213398074469.issue19847@psf.upfronthosting.co.za>


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

Follow-up: the PEP 538 (bpo-28180) and PEP 540 (bpo-29240) have been accepted and implemented in Python 3.7. Python 3.7 will now use UTF-8 by default for the POSIX locale, and the encoding can be forced to UTF-8 using -X utf8 option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19847>
_______________________________________

From duju at haafor.com  Mon Dec 18 08:51:38 2017
From: duju at haafor.com (Dong Uk Ju)
Date: Mon, 18 Dec 2017 13:51:38 +0000
Subject: [docs] Confusing API in Threading module.
Message-ID: <DM3PR12MB0841C6892F87770055F17EF5A80E0@DM3PR12MB0841.namprd12.prod.outlook.com>

Dear Python Managers,


While reading the API for Threading module, I noticed that explanation of Lock.acquire() is really confusing.


Here I attach the original statement.


(Python 2)

Lock.acquire([blocking])<https://docs.python.org/2/library/threading.html#threading.Lock.acquire>

Acquire a lock, blocking or non-blocking.

When invoked with the blocking argument set to True (the default), block until the lock is unlocked, then set it to locked and return True.

When invoked with the blocking argument set to False, do not block. If a call with blocking set to True would block, return False immediately; otherwise, set the lock to locked and return True.


(Python 3)

acquire(blocking=True, timeout=-1)?<https://docs.python.org/3/library/threading.html#threading.Lock.acquire>

Acquire a lock, blocking or non-blocking.

When invoked with the blocking argument set to True (the default), block until the lock is unlocked, then set it to locked and return True.

When invoked with the blocking argument set to False, do not block. If a call with blocking set to Truewould block, return False immediately; otherwise, set the lock to locked and return True.

When invoked with the floating-point timeout argument set to a positive value, block for at most the number of seconds specified by timeout and as long as the lock cannot be acquired. A timeout argument of -1 specifies an unbounded wait. It is forbidden to specify a timeout when blocking is false.

The return value is True if the lock is acquired successfully, False if not (for example if the timeoutexpired).


Both version have statement "When invoked with the blocking argument set to False, do not block. If a call with blocking set to True would block, return False immediately".


The second sentence confuses a lot.


What happen if a call with blocking set to False would block ??

>From my insight, it might also return False immediately and will not block or wait for other working thread.


If my understanding is wrong, prior acquire call's blocking argument matters for later call of acquire.

Then, there should be 4 cases,

1) acquire(True) on acquire(True)

2) acquire(True) on acquire(False)

3) acquire(False) on acquire(True)

4) acquire(False) on acquire(False).


I don't think this works in this way, besides API doesn't specifies those cases.


If my understanding is right,(Prior interpretation is right), I recommend to revise the sentence to "When invoked with the blocking argument set to False, do not block. If acquire() is called with blocking set to False while another thread is working on it(currently locked status), return False immediately."


Please kindly consider this for better python.


Thank you.


Sincerely,

Donguk Ju.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171218/9ac5a35a/attachment-0001.html>

From report at bugs.python.org  Mon Dec 18 21:41:17 2017
From: report at bugs.python.org (Christopher Barker)
Date: Tue, 19 Dec 2017 02:41:17 +0000
Subject: [docs] [issue32216] Document PEP 557 Data Classes
In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>
Message-ID: <1513651277.65.0.213398074469.issue32216@psf.upfronthosting.co.za>


Christopher Barker <Chris.Barker at noaa.gov> added the comment:

It was suggested that I could contirbute to the docs of dataclasses in this issue. Which confuses me, as there doesn't appear to be any content here to comment on. But what the heck:

As I've been annoyingly persistent about on the python-dev list, I think we need to be quite careful about making type hints appear to be a requirement for using dataclasses. In order to counter this, we could:

* have the first couple example be type-less:

@dataclass
class C:
    a: ...   # field without a default
    b: ... = 0 # field with a default

or something like that.

Then purposely introduce "how to add type hints" a bit down in the docs.

----------
nosy: +Chris.Barker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From report at bugs.python.org  Tue Dec 19 02:50:50 2017
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Dec 2017 07:50:50 +0000
Subject: [docs] [issue32284] typing.TextIO and BinaryIO are not aliases of
 IO[...]
In-Reply-To: <1513038875.1.0.213398074469.issue32284@psf.upfronthosting.co.za>
Message-ID: <1513669850.88.0.213398074469.issue32284@psf.upfronthosting.co.za>


Ned Deily <nad at python.org> added the comment:


New changeset 898a3e4901b3b6de9b540e18faa457a6ac3e49bb by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-32284: Fix documentation of BinaryIO and TextIO (GH-4832) (#4833)
https://github.com/python/cpython/commit/898a3e4901b3b6de9b540e18faa457a6ac3e49bb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32284>
_______________________________________

From report at bugs.python.org  Tue Dec 19 09:37:22 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 14:37:22 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513694242.4.0.213398074469.issue32306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hi David,

> what happens behind the scenes is that the call blocks until all results are computed and only then starts yielding them.

The current implementation of the Executor.map() generator is:

        def result_iterator():
            try:
                # reverse to keep finishing order
                fs.reverse()
                while fs:
                    # Careful not to keep a reference to the popped future
                    if timeout is None:
                        yield fs.pop().result()
                    else:
                        yield fs.pop().result(end_time - time.time())
            finally:
                for future in fs:
                    future.cancel()


So it seems to me that results are yielded as soon as they arrive (provided they arrive in the right order).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, pitrou
type: enhancement -> behavior
versions: +Python 3.6, Python 3.7 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Tue Dec 19 09:47:42 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 14:47:42 +0000
Subject: [docs] [issue32374] Document that m_traverse for multi-phase
 initialized modules can be called with m_state=NULL
In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za>
Message-ID: <1513694862.17.0.912454111764.issue32374@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Tue Dec 19 11:29:59 2017
From: report at bugs.python.org (Eric Cousineau)
Date: Tue, 19 Dec 2017 16:29:59 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
Message-ID: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>


New submission from Eric Cousineau <eric.cousineau at tri.global>:

Due to how `PyObject_CallFinalizer` is written in python3, `__del__` will only *ever* be called once.

In my use case, I am experimenting with a feature in `pybind11` to prevent slicing with Python class instances that inherit from pybind11-C++ base classes, which involves detecting when an instance loses all reference in Python (`Py_REFCNT(...) == 0`) but still has reference in C++ (`shared_ptr::count() > 0`), and reviving the Python portion when this situation happens.

In python2, I could do this without a hitch, as a resurrected object could have its `__del__` method called multiple times (through `tp_dealloc` I believe?). But in python3, the object is marked with `_PyGC_SET_FINALIZED(...)`, thus preventing `__del__` from being called again.

It'd be nice to either (a) somehow allow `__del__` to be called naturally without too much fuss or, at the least, (b) have this reflected in the documentation:
https://docs.python.org/3/reference/datamodel.html#object.__del__

See attached `revive_test`. Example execution:

```
$ python2 ./revive_test.py 
Revive
Destroy
[ Done ]

$ python3 ./revive_test.py 
Revive
[ Done ]
```

----------
assignee: docs at python
components: Documentation
files: revive_test.py
messages: 308660
nosy: Eric Cousineau, docs at python
priority: normal
severity: normal
status: open
title: Difference in ressurrection behavior with __del__ in py2 vs. py3
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47339/revive_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 11:33:22 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 16:33:22 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513701202.54.0.213398074469.issue32377@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the report.  Apparently I forgot to update that piece of documentation when PEP 442 was implemented.

----------
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 11:46:38 2017
From: report at bugs.python.org (Eric Cousineau)
Date: Tue, 19 Dec 2017 16:46:38 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513701998.29.0.213398074469.issue32377@psf.upfronthosting.co.za>


Eric Cousineau <eric.cousineau at tri.global> added the comment:

You're welcome, and thank you for the prompt response!

I will say that it feels a tad odd to only have `tp_finalize` be called once for the entire lifetime of the object, while still having the option of it being resurrected.
Is there any way to somehow "un-mark" the object to enable this workflow that I would like to have?

My current hack is to call `_PyGC_SET_FINALIZED(self, 0)` - may I ask if there is a simpler way to do this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 12:13:08 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 17:13:08 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513701998.29.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <08662082-d18c-003a-ce80-4450d851de35@free.fr>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le 19/12/2017 ? 17:46, Eric Cousineau a ?crit?:
> 
> My current hack is to call `_PyGC_SET_FINALIZED(self, 0)` - may I ask if there is a simpler way to do this?

Well... perhaps you could create another PyObject (it's just a wrapper,
right?) since the old one doesn't have any outside references to it
remaining.

Note that calling __del__ only once is also how PyPy works:
http://doc.pypy.org/en/latest/cpython_differences.html#differences-related-to-garbage-collection-strategies

If there is some demand we could expose a higher-level spelling of
`_PyGC_SET_FINALIZED(self, 0)`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 12:39:31 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 17:39:31 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513705171.73.0.912454111764.issue32377@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4822
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 12:47:38 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 17:47:38 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513705658.78.0.213398074469.issue32377@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've proposed a documentation improvement in https://github.com/python/cpython/pull/4927 . Please chime in if you see have issues with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 13:48:47 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 18:48:47 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513709327.96.0.213398074469.issue32377@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 4b965930e8625f77cb0e821daf5cc40e85b45f84 by Antoine Pitrou in branch 'master':
bpo-32377: improve __del__ docs and fix mention about resurrection (#4927)
https://github.com/python/cpython/commit/4b965930e8625f77cb0e821daf5cc40e85b45f84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 13:49:01 2017
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 19 Dec 2017 18:49:01 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513709341.72.0.912454111764.issue32377@psf.upfronthosting.co.za>


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


----------
pull_requests: +4823

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 14:00:19 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 19:00:19 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513710018.97.0.213398074469.issue32377@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset dc5770b161a5e28eeff73a406cd4eddb0676c5b5 by Antoine Pitrou (Miss Islington (bot)) in branch '3.6':
bpo-32377: improve __del__ docs and fix mention about resurrection (GH-4927) (#4929)
https://github.com/python/cpython/commit/dc5770b161a5e28eeff73a406cd4eddb0676c5b5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Tue Dec 19 14:00:56 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Dec 2017 19:00:56 +0000
Subject: [docs] [issue32377] Difference in ressurrection behavior with
 __del__ in py2 vs. py3
In-Reply-To: <1513700999.05.0.213398074469.issue32377@psf.upfronthosting.co.za>
Message-ID: <1513710056.98.0.912454111764.issue32377@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32377>
_______________________________________

From report at bugs.python.org  Wed Dec 20 06:21:24 2017
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Wed, 20 Dec 2017 11:21:24 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513768884.04.0.213398074469.issue32306@psf.upfronthosting.co.za>


David Luke? <dafydd.lukes at gmail.com> added the comment:

Hi Antoine,

Thanks for the response! :) I think the problem lies in the line immediately preceding the code you've posted:

```
fs = [self.submit(fn, *args) for args in zip(*iterables)]
```

In other words, all the jobs are first submitted and their futures stored in a list, which is then iterated over. This approach obviously breaks down when there is a great number of jobs, or when it's part of a pipeline meant for processing jobs continuously as they come.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 06:36:38 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 11:36:38 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513769798.17.0.213398074469.issue32306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I see.  So the problem you are pointing out is that the tasks *arguments* are consumed eagerly.  I agree that may be a problem in some cases, though I think in most cases people are concerned with the *results*.

(note that multiprocessing.Pool() has an imap() method which does what you would like)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 07:06:40 2017
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Wed, 20 Dec 2017 12:06:40 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513771600.8.0.213398074469.issue32306@psf.upfronthosting.co.za>


David Luke? <dafydd.lukes at gmail.com> added the comment:

Yes, sorry for not being quite clear the first time around :)

I eventually found out about Pool.imap (see item 3 on list in OP) and indeed it fits my use case very nicely, but my point was that the documentation is somewhat misleading with respect to the semantics of built-in `map()` in Python 3.

Specifically, I would argue that it is unexpected for a function which claims to be "Equivalent to map(func, *iterables)" to require allocating a list the length of the shortest iterable.

Maybe a code example will make this clearer for potential newcomers to the discussion -- this is what I would expect to happen (= the behavior of built-in `map()` itself), yielding values from the iterable is interleaved with calls to the mapped function:

```
>>> def gen():
...     for i in range(3):
...         print("yielding", i)
...         yield i
...         
>>> def add1(i):
...     print("adding 1 to", i)
...     return i + 1
... 
>>> list(map(add1, gen()))
yielding 0
adding 1 to 0
yielding 1
adding 1 to 1
yielding 2
adding 1 to 2
[1, 2, 3]
```

This is what happens instead with `concurrent.futures.Executor.map()`:

```
>>> def my_map(fn, iterable):
...     lst = list(iterable)
...     for i in lst:
...         yield fn(i)
...         
>>> list(my_map(add1, gen()))
yielding 0
yielding 1
yielding 2
adding 1 to 0
adding 1 to 1
adding 1 to 2
[1, 2, 3]
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 12:53:22 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 17:53:22 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513792402.52.0.912454111764.issue32306@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4839
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 13:06:23 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 18:06:23 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513793183.87.0.213398074469.issue32306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d by Antoine Pitrou in branch 'master':
bpo-32306: Clarify c.f.Executor.map() documentation (#4947)
https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 13:06:39 2017
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Dec 2017 18:06:39 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513793199.93.0.912454111764.issue32306@psf.upfronthosting.co.za>


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


----------
pull_requests: +4840

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 13:19:20 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 18:19:20 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513793960.4.0.213398074469.issue32306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:


New changeset 4aa84e728565a15a82727b9b971126e355f47e9d by Antoine Pitrou (Miss Islington (bot)) in branch '3.6':
bpo-32306: Clarify c.f.Executor.map() documentation (GH-4947) (#4948)
https://github.com/python/cpython/commit/4aa84e728565a15a82727b9b971126e355f47e9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 13:19:42 2017
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Dec 2017 18:19:42 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513793982.52.0.213398074469.issue32306@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the documentation is now clearer.  Closing!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Wed Dec 20 14:57:22 2017
From: report at bugs.python.org (Neil Schemenauer)
Date: Wed, 20 Dec 2017 19:57:22 +0000
Subject: [docs] [issue30492] 'make clinic' does not work for out of tree
 builds / clinic.py is not in the devguide
In-Reply-To: <1495909690.05.0.0866994683674.issue30492@psf.upfronthosting.co.za>
Message-ID: <1513799842.32.0.213398074469.issue30492@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Thanks for fixing this.  I always do my builds in subfolders as well.  It is handy to have multiple builds (debug, opt, profiled) that all use a single source tree.

I don't like to hijack this issue but could we get some of the build bots to do their builds in a subfolder?  I don't know who would be able to make that change.  It would be good to smoke out these kinds of problems early.  Otherwise wierdo's like gps and I don't notice them until later.

If we don't keep this working, we should just rip the ability to do builds outside of the source tree out of the Makefile.  There is no point to maintaining the extra complication if it doesn't actually work.  With git shallow clones, I could live with that.  However, it seems a shame to lose it when it basically currently works fine.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30492>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:05:52 2017
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 20 Dec 2017 20:05:52 +0000
Subject: [docs] [issue30492] 'make clinic' does not work for out of tree
 builds / clinic.py is not in the devguide
In-Reply-To: <1495909690.05.0.0866994683674.issue30492@psf.upfronthosting.co.za>
Message-ID: <1513800352.59.0.213398074469.issue30492@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

> I don't like to hijack this issue but could we get some of the build bots to do their builds in a subfolder?

The buildmaster config is at https://github.com/python/buildmaster-config, feel free to submit a pull request that sets the ware-gentoo bot building out-of-tree.  Victor or I can merge and deploy, but I don't have the bandwidth to make the change myself currently.

----------
nosy: +vstinner, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30492>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:31:42 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 20 Dec 2017 20:31:42 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1513801902.3.0.213398074469.issue28942@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Yury, ping.

----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:31:53 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 20 Dec 2017 20:31:53 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1513801913.4.0.912454111764.issue28942@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:34:07 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 20 Dec 2017 20:34:07 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1513802047.62.0.213398074469.issue28942@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks, I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:38:50 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 20 Dec 2017 20:38:50 +0000
Subject: [docs] [issue29344] sock_recv not detected a coroutine
In-Reply-To: <1485094185.41.0.725056014669.issue29344@psf.upfronthosting.co.za>
Message-ID: <1513802330.42.0.213398074469.issue29344@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

sock_recv was converted into genuine coroutine in Python 3.7

Closing the issue.

----------
nosy: +asvetlov
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29344>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:40:10 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 20 Dec 2017 20:40:10 +0000
Subject: [docs] [issue28697] asyncio.Lock, Condition,
 Semaphore docs don't mention `async with` syntax
In-Reply-To: <1479225811.34.0.0222578393475.issue28697@psf.upfronthosting.co.za>
Message-ID: <1513802409.99.0.213398074469.issue28697@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Fixed by recent docs update for Python 3.7

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28697>
_______________________________________

From report at bugs.python.org  Wed Dec 20 15:47:11 2017
From: report at bugs.python.org (Oleh Prypin)
Date: Wed, 20 Dec 2017 20:47:11 +0000
Subject: [docs] [issue32392] subprocess.run documentation does not have
 **kwargs
Message-ID: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za>


New submission from Oleh Prypin <blaxpirit at gmail.com>:

I was just looking at documentation of https://docs.python.org/3.6/library/subprocess.html#subprocess.run
and thought that it doesn't support passing `env` because the list of supported keyword arguments is exhaustive (no **kwargs). But it does support passing **kwargs to Popen, so that should be specified in the docs.

----------
assignee: docs at python
components: Documentation
messages: 308810
nosy: docs at python, oprypin
priority: normal
severity: normal
status: open
title: subprocess.run documentation does not have **kwargs
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32392>
_______________________________________

From report at bugs.python.org  Wed Dec 20 16:26:36 2017
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Dec 2017 21:26:36 +0000
Subject: [docs] [issue32392] subprocess.run documentation does not have
 **kwargs
In-Reply-To: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za>
Message-ID: <1513805196.04.0.213398074469.issue32392@psf.upfronthosting.co.za>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

But the documentation does say "The arguments shown above are merely the most common ones...The full function signature is largely the same as that of the Popen constructor...", no ?

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32392>
_______________________________________

From report at bugs.python.org  Wed Dec 20 16:28:14 2017
From: report at bugs.python.org (Oleh Prypin)
Date: Wed, 20 Dec 2017 21:28:14 +0000
Subject: [docs] [issue32392] subprocess.run documentation does not have
 **kwargs
In-Reply-To: <1513802831.78.0.213398074469.issue32392@psf.upfronthosting.co.za>
Message-ID: <1513805294.47.0.213398074469.issue32392@psf.upfronthosting.co.za>


Oleh Prypin <blaxpirit at gmail.com> added the comment:

Yes, but the most prominent thing to indicate that is **kwargs in the actual function signature. And, as far as I'm concerned, lack of **kwargs means the function signature is exhaustive and there's no point in looking for fine print somewhere in the middle of the textual description.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32392>
_______________________________________

From report at bugs.python.org  Wed Dec 20 18:00:52 2017
From: report at bugs.python.org (Joseph Hendrey)
Date: Wed, 20 Dec 2017 23:00:52 +0000
Subject: [docs] [issue32393] nav menu jitter in old documentation
Message-ID: <1513810852.69.0.213398074469.issue32393@psf.upfronthosting.co.za>


New submission from Joseph Hendrey <jhendrey at condense.com.au>:

The sidebar navigation menu jitters when scrolling on the 2.7 documentation pages (at least in Chrome).

A seemingly unrelated issue is that the collapse symbol '<<' is a fixed distance from the top of the page rather than staying in the centre (height-wise) of the screen (it should always be visible).

It seems it has been fixed for newer documentation, but since the fix is so simple it would be nice to fix it for the old documentation too. Setting the position property of the span element seems to fix both issues for me (see attached screenshot)

----------
assignee: docs at python
components: Documentation
files: screenshot.JPG
messages: 308834
nosy: Joseph Hendrey, docs at python
priority: normal
severity: normal
status: open
title: nav menu jitter in old documentation
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47343/screenshot.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32393>
_______________________________________

From report at bugs.python.org  Wed Dec 20 19:06:00 2017
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 21 Dec 2017 00:06:00 +0000
Subject: [docs] [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1513814760.6.0.213398074469.issue28942@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Looks like it's working now:

    import asyncio


    async def foo():
        return 32


    async def bar():
        print(f'{await foo()}')


    asyncio.run(bar())

Prints:

    32

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Wed Dec 20 22:49:30 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 21 Dec 2017 03:49:30 +0000
Subject: [docs] [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1513828170.79.0.213398074469.issue31584@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Seems like this is happening again.
English docs are showing Japanese content.
https://github.com/python/pythondotorg/issues/1207

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Wed Dec 20 22:51:02 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 21 Dec 2017 03:51:02 +0000
Subject: [docs] [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1513828262.17.0.213398074469.issue31584@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Hmm only for that one page it seems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Thu Dec 21 01:09:24 2017
From: report at bugs.python.org (Julien Palard)
Date: Thu, 21 Dec 2017 06:09:24 +0000
Subject: [docs] [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1513836564.84.0.213398074469.issue31584@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

Sadly I can't see it, it may have already been fixed by the cron task (I'm 3 hours late).

I grepped on the server to check if there's another page: no one found.

I'll try to fix it by the proposed simple idea that make sense of using different directories for the different builds, will track this in: https://github.com/python/docsbuild-scripts/issues/35

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Thu Dec 21 03:44:55 2017
From: report at bugs.python.org (=?utf-8?q?David_Luke=C5=A1?=)
Date: Thu, 21 Dec 2017 08:44:55 +0000
Subject: [docs] [issue32306] Clarify map API in concurrent.futures
In-Reply-To: <1513185353.85.0.213398074469.issue32306@psf.upfronthosting.co.za>
Message-ID: <1513845895.47.0.213398074469.issue32306@psf.upfronthosting.co.za>


David Luke? <dafydd.lukes at gmail.com> added the comment:

Perfect, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32306>
_______________________________________

From report at bugs.python.org  Thu Dec 21 04:28:56 2017
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 21 Dec 2017 09:28:56 +0000
Subject: [docs] [issue28212] Closing server in asyncio is not efficient
In-Reply-To: <1474362608.68.0.912694843367.issue28212@psf.upfronthosting.co.za>
Message-ID: <1513848536.49.0.213398074469.issue28212@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Superseded by https://bugs.python.org/issue32391

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add StreamWriter.wait_closed()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28212>
_______________________________________

From report at bugs.python.org  Thu Dec 21 09:55:31 2017
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Thu, 21 Dec 2017 14:55:31 +0000
Subject: [docs] [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1513868131.72.0.912454111764.issue17972@psf.upfronthosting.co.za>


Change by Anand Reddy Pandikunta <anand21nanda at gmail.com>:


----------
nosy: +chillaranand

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From chensy at mathstat.yorku.ca  Mon Dec 18 11:41:31 2017
From: chensy at mathstat.yorku.ca (Michael)
Date: Mon, 18 Dec 2017 11:41:31 -0500
Subject: [docs] "Socket Programming HOWTO" by Gordon McMillan is the worst
Message-ID: <e52b58ac-1d79-6d67-9578-cfeddd66c2e3@mathstat.yorku.ca>

howto-sockets.pdf is so terrible that I feel obliged to report it!

It is not a technical howto, but a ridiculous talk-show. How could this 
be an official Python document?

-- 
Sincerely Yours,
Michael


From craigmaceachern at fastmail.com  Mon Dec 18 12:23:37 2017
From: craigmaceachern at fastmail.com (C.D. MacEachern)
Date: Mon, 18 Dec 2017 12:23:37 -0500
Subject: [docs] venv module doc missing command line option
Message-ID: <1513617817.1594017.1208980312.55F649EF@webmail.messagingengine.com>

The documentation for venv on both 3.6.4rc1 and 3.7 is missing a command
line option:

When I run my python 3.6.3 with: 

$ python -m venv -h

There is the long-dash option:
--prompt PROMPT Provides an alternative prompt prefix for this
environment.

There is no mention in the above python doc pages about this in the
28.3.1 section, however there is a brief mention of it in the 28.3.2 API
section.

Thanks,
Craig MacEachern



-- 
  C.D. MacEachern
 craigmaceachern at fastmail.com

From Jens.Schleusener at t-online.de  Tue Dec 19 13:14:38 2017
From: Jens.Schleusener at t-online.de (Jens Schleusener)
Date: Tue, 19 Dec 2017 19:14:38 +0100 (CET)
Subject: [docs] Python 3.6.4 documentation files not available
Message-ID: <alpine.LSU.2.20.1712191909160.4579@schiller.site>

Hi,

on the page

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

all the links are currently dead, for e.g.

  https://docs.python.org/3/archives/python-3.6.4-docs-html.tar.bz2

results in a "404 Not Found".

Probably I am just too impatient and I should wait some hours or days,
but maybe it's a real error.

Regards

Jens

From jhonatan.arenasb at gmail.com  Tue Dec 19 12:00:28 2017
From: jhonatan.arenasb at gmail.com (Danfee33)
Date: Tue, 19 Dec 2017 12:00:28 -0500
Subject: [docs] Download Python 3.6.4 Documentation
Message-ID: <CAMpuQf8F=H0A+S99zpm7pY0DAUCDiDzgW4N2rBoN2PW+mA6VAg@mail.gmail.com>

Good morning,

I'm learning about phyton and i really want to download this documentation
but links are down.

how i can get this documentation about phyton 3.6.4?

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171219/4a658482/attachment.html>

From o.jepps at griffith.edu.au  Tue Dec 19 18:06:35 2017
From: o.jepps at griffith.edu.au (Owen Jepps)
Date: Wed, 20 Dec 2017 09:06:35 +1000
Subject: [docs] wrong links for python 3.6 doc download
Message-ID: <CANgaOnuXcMp1YCO8Fit8BCmDV9Da9k_cOyTaLN-2jUQ6TNer9w@mail.gmail.com>

Hi,
The links to download documentation for python 3.6, at
https://docs.python.org/3/download.html, are broken.  I found the right
ones by cross-checking with the links for 2.7, which are working, but
thought you should know.
All the best (and many thanks for this incredibly useful information
resource that you maintain!)
Owen.


-- 

*Owen Jepps | Senior Lecturer (Mathematics), BSc Program Director*


*School of Natural Sciences / QMNC **Griffith University  **| Nathan campus
| QLD 4111 | Technology *
*(N44) Room 3.24 T +61 7 3735 4464| M +61 430 592 805
| email o.jepps at griffith.edu.au <o.jepps at griffith.edu.au>*

griffith.edu.au


[image:
https://www.griffith.edu.au/__data/assets/image/0006/898008/email-sig.jpg]

Griffith University - CRICOS Provider Number 00233E



PRIVILEGED - PRIVATE AND CONFIDENTIAL

This email and any files transmitted with it are intended solely for the
use of the addressee(s) and may contain information which is confidential
or privileged.  If you receive this email and you are not the addressee or
responsible for delivery of the email to the addressee(s), please disregard
the contents of the email, delete the mail and notify the author
immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171220/6cb57ecb/attachment.html>

From rahmed2 at memphis.edu  Tue Dec 19 16:40:12 2017
From: rahmed2 at memphis.edu (Rayhan Ahmed (rahmed2))
Date: Tue, 19 Dec 2017 21:40:12 +0000
Subject: [docs] Download links are not working
Message-ID: <DM5PR04MB1149463D586DA8F32B78D949E20F0@DM5PR04MB1149.namprd04.prod.outlook.com>

Hi... I followed the link https://docs.python.org/3/download.html to download PDF documents but unfortunately the download links are not working. This is for your kind information.

Download ? Python 3.6.4rc1 documentation<https://docs.python.org/3/download.html>
docs.python.org
To download an archive containing all the documents for this version of Python in one of various formats, follow one of links in this table. The numbers in the table ...

Thank you.


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

From ranyafafi93 at gmail.com  Thu Dec 21 08:19:11 2017
From: ranyafafi93 at gmail.com (Ranya)
Date: Thu, 21 Dec 2017 14:19:11 +0100
Subject: [docs] Python bug report
Message-ID: <CAAqz=gY6RH2ZO3q06tEyq_Ypa6q3zUqnUG=OhAHuUdg+4wBncw@mail.gmail.com>

Hi,
Am trying to use clr.AddReference and clr.AddReferenceToFile, but
python(2.7) keeps making this error:

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    clr.AddReference("UnityEngine")AttributeError: 'module' object has
no attribute 'AddReference'

How can I fix this?
Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171221/daaf7b2a/attachment.html>

From sidney.skinner at gmail.com  Tue Dec 19 08:15:54 2017
From: sidney.skinner at gmail.com (Sidney Skinner)
Date: Tue, 19 Dec 2017 09:15:54 -0400
Subject: [docs] Broken Links
Message-ID: <CALLTMkSmWTM-Ze0S+nQGCoPSU-zJt3mHAM=W_ReSwk_z7bZfsg@mail.gmail.com>

Links for 3.6.4 Docs eg
https://docs.python.org/3/archives/python-3.6.4-docs-pdf-letter.zip are
broken. Only the RC1 links exists
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171219/042c2040/attachment.html>

From report at bugs.python.org  Thu Dec 21 10:28:39 2017
From: report at bugs.python.org (Julien Palard)
Date: Thu, 21 Dec 2017 15:28:39 +0000
Subject: [docs] [issue32393] nav menu jitter in old documentation
In-Reply-To: <1513810852.69.0.213398074469.issue32393@psf.upfronthosting.co.za>
Message-ID: <1513870119.78.0.912454111764.issue32393@psf.upfronthosting.co.za>


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


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32393>
_______________________________________

From mariatta.wijaya at gmail.com  Thu Dec 21 11:08:51 2017
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Thu, 21 Dec 2017 08:08:51 -0800
Subject: [docs] "Socket Programming HOWTO" by Gordon McMillan is the
 worst
In-Reply-To: <e52b58ac-1d79-6d67-9578-cfeddd66c2e3@mathstat.yorku.ca>
References: <e52b58ac-1d79-6d67-9578-cfeddd66c2e3@mathstat.yorku.ca>
Message-ID: <CAGbohnagbpHtMYodnOes50Y4iX4eORFW6Q_a-mODs9HsDZM-Jw@mail.gmail.com>

Your message disrespectful, not a behavior I tolerate in this mailing list.

Mariatta Wijaya

On Mon, Dec 18, 2017 at 8:41 AM, Michael <chensy at mathstat.yorku.ca> wrote:

> howto-sockets.pdf is so terrible that I feel obliged to report it!
>
> It is not a technical howto, but a ridiculous talk-show. How could this be
> an official Python document?
>
> --
> Sincerely Yours,
> Michael
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171221/2ac19ef5/attachment-0001.html>

From report at bugs.python.org  Thu Dec 21 11:19:10 2017
From: report at bugs.python.org (Julien Palard)
Date: Thu, 21 Dec 2017 16:19:10 +0000
Subject: [docs] [issue30607] Extract documentation theme into a separate
 package
In-Reply-To: <1496981279.71.0.300273355047.issue30607@psf.upfronthosting.co.za>
Message-ID: <1513873150.59.0.912454111764.issue30607@psf.upfronthosting.co.za>


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


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30607>
_______________________________________

From report at bugs.python.org  Thu Dec 21 13:57:05 2017
From: report at bugs.python.org (Lior Cohen)
Date: Thu, 21 Dec 2017 18:57:05 +0000
Subject: [docs] [issue32400] inspect.isdatadescriptor  fasle negative
Message-ID: <1513882624.99.0.213398074469.issue32400@psf.upfronthosting.co.za>


New submission from Lior Cohen <chnlior at gmail.com>:

According to the c code in Include/descrobject.h

#define PyDescr_IsData(d) (Py_TYPE(d)->tp_descr_set != NULL)

and according to the "data model" chapter,
a data descriptor is an object who has __set__ and /or __delete__.

the "inspect.isdatadescriptor" checks for existence of __get__ and __set__ which IMHO is wrong. an object with __set__/__delete__ only will return falsely False (should be True).  

This is related to @Serhiy Storchaka comment in issue 26103 opened by @Aaron Hall.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 308895
nosy: chnlior, docs at python
priority: normal
severity: normal
status: open
title: inspect.isdatadescriptor  fasle negative
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32400>
_______________________________________

From report at bugs.python.org  Thu Dec 21 13:57:44 2017
From: report at bugs.python.org (Lior Cohen)
Date: Thu, 21 Dec 2017 18:57:44 +0000
Subject: [docs] [issue32400] inspect.isdatadescriptor  false negative
In-Reply-To: <1513882624.99.0.213398074469.issue32400@psf.upfronthosting.co.za>
Message-ID: <1513882664.8.0.912454111764.issue32400@psf.upfronthosting.co.za>


Change by Lior Cohen <chnlior at gmail.com>:


----------
title: inspect.isdatadescriptor  fasle negative -> inspect.isdatadescriptor  false negative

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32400>
_______________________________________

From report at bugs.python.org  Thu Dec 21 18:37:58 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Dec 2017 23:37:58 +0000
Subject: [docs] [issue32406] Doc: The new dataclasses module is not
 documented
Message-ID: <1513899478.4.0.213398074469.issue32406@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

bpo-32214 "Implement PEP 557: Data Classes" added a new dataclasses module and was closed, but the new module is not documented:
https://docs.python.org/dev/library/dataclasses.html

And it's also missing from What's New in Python 3.7:
https://docs.python.org/dev/whatsnew/3.7.html

----------
assignee: docs at python
components: Documentation
messages: 308918
nosy: docs at python, eric.smith, vstinner
priority: normal
severity: normal
status: open
title: Doc: The new dataclasses module is not documented
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32406>
_______________________________________

From report at bugs.python.org  Thu Dec 21 18:44:19 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 21 Dec 2017 23:44:19 +0000
Subject: [docs] [issue32216] Document PEP 557 Data Classes (dataclasses
 module)
In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>
Message-ID: <1513899859.15.0.912454111764.issue32216@psf.upfronthosting.co.za>


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


----------
title: Document PEP 557 Data Classes -> Document PEP 557 Data Classes (dataclasses module)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From report at bugs.python.org  Thu Dec 21 18:45:25 2017
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 21 Dec 2017 23:45:25 +0000
Subject: [docs] [issue32406] Doc: The new dataclasses module is not
 documented
In-Reply-To: <1513899478.4.0.213398074469.issue32406@psf.upfronthosting.co.za>
Message-ID: <1513899925.53.0.213398074469.issue32406@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

This is a duplicate of #32216, which is no doubt hard to find because the subject doesn't contain "dataclasses". I've fixed that.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32406>
_______________________________________

From report at bugs.python.org  Thu Dec 21 18:48:08 2017
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Dec 2017 23:48:08 +0000
Subject: [docs] [issue32216] Document PEP 557 Data Classes (dataclasses
 module)
In-Reply-To: <1512439511.23.0.213398074469.issue32216@psf.upfronthosting.co.za>
Message-ID: <1513900088.54.0.213398074469.issue32216@psf.upfronthosting.co.za>


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

My Issue32406 has been marked as a duplicate of this one. Copy of my message:

bpo-32214 "Implement PEP 557: Data Classes" added a new dataclasses module and was closed, but the new module is not documented:
https://docs.python.org/dev/library/dataclasses.html

And it's also missing from What's New in Python 3.7:
https://docs.python.org/dev/whatsnew/3.7.html

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32216>
_______________________________________

From report at bugs.python.org  Fri Dec 22 16:59:13 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 22 Dec 2017 21:59:13 +0000
Subject: [docs] [issue32261] Online doc does not include
 inspect.classify_class_attrs
In-Reply-To: <1512846881.17.0.213398074469.issue32261@psf.upfronthosting.co.za>
Message-ID: <1513979953.47.0.912454111764.issue32261@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> inspect module docs omits many functions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32261>
_______________________________________

From report at bugs.python.org  Fri Dec 22 16:59:56 2017
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 22 Dec 2017 21:59:56 +0000
Subject: [docs] [issue17972] inspect module docs omits many functions
In-Reply-To: <1368501068.91.0.677640111487.issue17972@psf.upfronthosting.co.za>
Message-ID: <1513979996.9.0.912454111764.issue17972@psf.upfronthosting.co.za>


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


----------
dependencies:  -Online doc does not include inspect.classify_class_attrs
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17972>
_______________________________________

From report at bugs.python.org  Fri Dec 22 23:35:29 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 23 Dec 2017 04:35:29 +0000
Subject: [docs] [issue32412] help() of bitwise operators should mention sets
 as well
Message-ID: <1514003729.76.0.213398074469.issue32412@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

If you ask for help on the set operators ^ & and | then help docs only talk about them as bitwise operators.

Since sets and frozensets are important, built-in types, the help should mention them as well.

----------
assignee: docs at python
components: Documentation
messages: 308946
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: help() of bitwise operators should mention sets as well
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32412>
_______________________________________

From report at bugs.python.org  Sat Dec 23 00:52:42 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 23 Dec 2017 05:52:42 +0000
Subject: [docs] [issue32413] Document that locals() may return globals()
Message-ID: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

The obvious documentation for locals() fails to mention that when called from the top level of a module (outside of a function or class body) it returns the same dict as globals().

https://docs.python.org/2/library/functions.html#locals

----------
assignee: docs at python
components: Documentation
messages: 308947
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Document that locals() may return globals()
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Sat Dec 23 03:09:45 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Dec 2017 08:09:45 +0000
Subject: [docs] [issue32413] Document that locals() may return globals()
In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>
Message-ID: <1514016585.79.0.912454111764.issue32413@psf.upfronthosting.co.za>


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


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Sat Dec 23 03:12:02 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Dec 2017 08:12:02 +0000
Subject: [docs] [issue32413] Document that locals() may return globals()
In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>
Message-ID: <1514016722.23.0.213398074469.issue32413@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, this isn't a quirk of how locals() works.  Instead, it reflects the more interesting reality that at the top level, locals and globals *are* the same dictionary.   Also, that is not the only occurrence -- if exec() is called with only one dictionary, that dict is used for both locals and globals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From Darko at web.de  Fri Dec 22 13:18:35 2017
From: Darko at web.de (Dominik Begovic)
Date: Fri, 22 Dec 2017 19:18:35 +0100
Subject: [docs] timeit module (3.6.4): examples for CLI in the docs not
 running correctly on windows because of single quotes
Message-ID: <trinity-94fba89b-fe39-49e8-ae2d-a197b388d2df-1513966715919@3c-app-webde-bs04>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171222/06e0617d/attachment-0001.html>

From fjackson1 at btinternet.com  Sat Dec 23 04:51:39 2017
From: fjackson1 at btinternet.com (Frederick Jackson)
Date: Sat, 23 Dec 2017 09:51:39 +0000
Subject: [docs] RPi.GPIO Documentation
Message-ID: <AC07BB70-0359-410C-8635-813676D2D9D8@btinternet.com>

could you guide me to where I can find the document that covers the Library for the use of RPi.GPIO, or is it not included in the Python documentation ?

Kind regards

Frederick

From xukela at qq.com  Sat Dec 23 01:27:43 2017
From: xukela at qq.com (=?ISO-8859-1?B?V2ludGVyIElzIENvbWluZw==?=)
Date: Sat, 23 Dec 2017 14:27:43 +0800
Subject: [docs] About docs
Message-ID: <tencent_F80A7A3243A03ADF96D3AB607476B7728106@qq.com>

When will Chinese documents appear?

From report at bugs.python.org  Sat Dec 23 11:24:04 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Dec 2017 16:24:04 +0000
Subject: [docs] [issue32412] help() of bitwise operators should mention sets
 as well
In-Reply-To: <1514003729.76.0.213398074469.issue32412@psf.upfronthosting.co.za>
Message-ID: <1514046244.76.0.213398074469.issue32412@psf.upfronthosting.co.za>


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

Which help are you talking about?  The Operator Precedence table that you get if you do, eg: help('&')?  I don't think it would be appropriate to mention specialized uses of the operators there, although perhaps we could add a general note about operator overloading in the intro paragraph and use set as the example.  Looking at help('BITWISE'), we could add 'when the arguments are numbers' after the precedence table, but since that section is called 'bitwise' I don't think we even want to mention set there.  Did you have other sections in mind?

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32412>
_______________________________________

From report at bugs.python.org  Sun Dec 24 12:31:13 2017
From: report at bugs.python.org (Srinivas Reddy T)
Date: Sun, 24 Dec 2017 17:31:13 +0000
Subject: [docs] [issue32413] Document that locals() may return globals()
In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>
Message-ID: <1514136673.9.0.912454111764.issue32413@psf.upfronthosting.co.za>


Change by Srinivas  Reddy T <thatiparthysreenivas at gmail.com>:


----------
keywords: +patch
pull_requests: +4893
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Sun Dec 24 12:42:42 2017
From: report at bugs.python.org (Srinivas Reddy T)
Date: Sun, 24 Dec 2017 17:42:42 +0000
Subject: [docs] [issue32413] Document that locals() may return globals()
In-Reply-To: <1514008362.41.0.213398074469.issue32413@psf.upfronthosting.co.za>
Message-ID: <1514137362.08.0.213398074469.issue32413@psf.upfronthosting.co.za>


Srinivas  Reddy T <thatiparthysreenivas at gmail.com> added the comment:

Done. exec(...)'s  documentation covers raymond's comment.

----------
nosy: +thatiparthy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32413>
_______________________________________

From report at bugs.python.org  Mon Dec 25 04:30:41 2017
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Dec 2017 09:30:41 +0000
Subject: [docs] [issue31983] Officially add Py_SETREF and Py_XSETREF
In-Reply-To: <1510158281.4.0.213398074469.issue31983@psf.upfronthosting.co.za>
Message-ID: <1514194241.16.0.213398074469.issue31983@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Since there are objections, it is too early to make this a public C API.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31983>
_______________________________________

From report at bugs.python.org  Mon Dec 25 16:42:57 2017
From: report at bugs.python.org (Julien Palard)
Date: Mon, 25 Dec 2017 21:42:57 +0000
Subject: [docs] [issue31584] Documentation Language mixed up
In-Reply-To: <1506402847.94.0.987670636111.issue31584@psf.upfronthosting.co.za>
Message-ID: <1514238177.53.0.213398074469.issue31584@psf.upfronthosting.co.za>


Julien Palard <julien+python at palard.fr> added the comment:

https://github.com/python/docsbuild-scripts/pull/36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31584>
_______________________________________

From report at bugs.python.org  Mon Dec 25 18:51:50 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Dec 2017 23:51:50 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <1514245910.29.0.213398074469.issue32145@psf.upfronthosting.co.za>


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

Regarding super().__init__(): I added ExitStack to contextlib2 first, so I was thinking in the Py2/3 compatible subset when I wrote the original docs. We can freely change that for the standard library recipes.

Regarding the "how to create a copy" question, while I don't especially like the notion of adding a dedicated semi-public copy method, I think you're right that it may be the best option:

1. Full pickle/copy module support doesn't make sense, since exit stacks are inherently stateful - you can't save them to use later, since you'd need to repeat the setup steps as well, but we don't keep track of what the setup steps actually *were*.

2. `stack.pop_all()` was designed such that if you clone the stack, you ensure that the original stack *won't* call the cleanup callbacks any more. If we were to add a fully public `stack.copy()` method (or `copy.copy(stack)` support via `stack.__copy__()`), then we'd lose that deliberate nudge, and put folks more at risk of "double-free" style bugs, where they run the cleanup functions multiple times.

3. A for-subclasses-only "self._clone()" API could work as follows:

    def _clone(self, new_instance=None):
        if new_instance is None:
            new_instance = type(self)()
        # Clone state here
        return new_instance

Then subclasses could override *just* the instance creation part by doing:

    def _clone(self):
        return super()._clone(self._make_instance())

While also being free to add their own additional state copying code if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Mon Dec 25 19:26:21 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 26 Dec 2017 00:26:21 +0000
Subject: [docs] [issue32374] Document that m_traverse for multi-phase
 initialized modules can be called with m_state=NULL
In-Reply-To: <1513694438.46.0.213398074469.issue32374@psf.upfronthosting.co.za>
Message-ID: <1514247981.89.0.213398074469.issue32374@psf.upfronthosting.co.za>


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

Yep, the requirement for supporting multiple interpreters is just that you either avoid relying on C global state entirely, or else correctly synchronise access to it. Multi-phase initialisation just provides a few nudges in the direction of doing that more consistently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32374>
_______________________________________

From report at bugs.python.org  Tue Dec 26 11:58:39 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 26 Dec 2017 16:58:39 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1514245910.29.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <57C412E0-BCE9-4721-91DE-ABAD44040E2F@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Dec 25, 2017, at 18:51, Nick Coghlan <report at bugs.python.org> wrote:
> 
> 3. A for-subclasses-only "self._clone()" API could work as follows:
> 
>    def _clone(self, new_instance=None):
>        if new_instance is None:
>            new_instance = type(self)()
>        # Clone state here
>        return new_instance
> 
> Then subclasses could override *just* the instance creation part by doing:
> 
>    def _clone(self):
>        return super()._clone(self._make_instance())
> 
> While also being free to add their own additional state copying code if needed.

So _make_instance() wouldn?t be part of ExitStack?s API, but subclasses could implement it (and name it whatever they want of course)?

I?m not sure _clone() is the right name here since that implies to me state copy as well, and I totally agree with your other points.  That?s why I originally suggested _make_instance() would be the name and API in the base class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Thu Dec 28 07:08:12 2017
From: report at bugs.python.org (Old K)
Date: Thu, 28 Dec 2017 12:08:12 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
Message-ID: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>


New submission from Old K <oldk1331 at gmail.com>:

In python3, in the output of help(), there is link
http://docs.python.org/3.6/tutorial/.
It should be made into https.

There are already some issues about changing http links to https:
https://bugs.python.org/issue25910
https://bugs.python.org/issue26736

But this link is still unchanged.

----------
assignee: docs at python
components: Documentation
messages: 309127
nosy: Old K, docs at python
priority: normal
severity: normal
status: open
title: Use HTTPS in help()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 07:17:26 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Dec 2017 12:17:26 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514463446.93.0.912454111764.issue32440@psf.upfronthosting.co.za>


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


----------
keywords: +patch
pull_requests: +4917
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 07:18:30 2017
From: report at bugs.python.org (Old K)
Date: Thu, 28 Dec 2017 12:18:30 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514463510.06.0.213398074469.issue32440@psf.upfronthosting.co.za>


Old K <oldk1331 at gmail.com> added the comment:

I have created a pull request at:

https://github.com/python/cpython/pull/5030

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 09:37:49 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 28 Dec 2017 14:37:49 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514471869.56.0.213398074469.issue32440@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset e5681b9822c633c77ddfeb94585d58895e0ecff5 by Mariatta (oldk) in branch 'master':
bpo-32440: Update the docs URL to https in help() (GH-5030)
https://github.com/python/cpython/commit/e5681b9822c633c77ddfeb94585d58895e0ecff5


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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 09:38:13 2017
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 28 Dec 2017 14:38:13 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514471893.81.0.912454111764.issue32440@psf.upfronthosting.co.za>


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


----------
pull_requests: +4918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 10:16:42 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 28 Dec 2017 15:16:42 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514474201.97.0.213398074469.issue32440@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:


New changeset 6eb232c52a03e31fc47842e70fc7833198744c2b by Mariatta (Miss Islington (bot)) in branch '3.6':
bpo-32440: Update the docs URL to https in help() (GH-5030) (GH-5031)
https://github.com/python/cpython/commit/6eb232c52a03e31fc47842e70fc7833198744c2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Thu Dec 28 10:17:40 2017
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 28 Dec 2017 15:17:40 +0000
Subject: [docs] [issue32440] Use HTTPS in help()
In-Reply-To: <1514462892.59.0.213398074469.issue32440@psf.upfronthosting.co.za>
Message-ID: <1514474260.91.0.213398074469.issue32440@psf.upfronthosting.co.za>


Mariatta Wijaya <mariatta.wijaya at gmail.com> added the comment:

Thanks!

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32440>
_______________________________________

From report at bugs.python.org  Fri Dec 29 08:40:02 2017
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Dec 2017 13:40:02 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1511771653.67.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <1514554802.65.0.213398074469.issue32145@psf.upfronthosting.co.za>


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

I'm not clear on what you mean about allowing arbitrary names for the instance creation function - at that point we're back to subclasses not being able to use the default `pop_all()` implementation at all, and needing to duplicate the state transfer logic in the subclass (which we don't provide a public API to do, since the `_exit_callbacks` queue is deliberately private).

However, I'm thinking we could potentially change `pop_all` *itself* to accept a target object:

    def pop_all(self, *, target=None):
        """Preserve the context stack by transferring it to a new instance

        If a *target* stack is given, it must be either an `ExitStack`
        instance, or else provide a callback registration method akin to `ExitStack.callback`.
        """
        if target is None:
            target = type(self)()
        exit_callbacks = self._exit_callbacks
        self._exit_callbacks = deque()
        if isinstance(target, ExitStack):
            target._exit_callbacks = exit_callbacks
        else:
            for cb in exit_callbacks:
                target.callback(cb)
        return target

The recipe fix would then be to make `Callback.cancel()` look like:

    def cancel(self):
        # We deliberately *don't* clean up the cancelled callback
        self.pop_all(target=ExitStack())

(Tangent: https://bugs.python.org/issue32445 suggests adding a small optimisation to `ExitStack.callback` to skip adding the wrapper when `args` and `kwds` are both empty)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Fri Dec 29 09:15:09 2017
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Dec 2017 14:15:09 +0000
Subject: [docs] [issue32444] python -m venv symlink dependency on how python
 binary is called is not documented
In-Reply-To: <1514515697.43.0.213398074469.issue32444@psf.upfronthosting.co.za>
Message-ID: <1514556909.17.0.213398074469.issue32444@psf.upfronthosting.co.za>


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

Actually, I'm going to reopen this as a doc issue because this behavior is not discussed by the docs that I can see, and it is important to know about when creating a venv.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
title: python -m venv has incongruous behavor creating binaries -> python -m venv symlink dependency on how python binary is called is not documented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32444>
_______________________________________

From report at bugs.python.org  Fri Dec 29 10:03:31 2017
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Dec 2017 15:03:31 +0000
Subject: [docs] [issue32145] Wrong ExitStack Callback recipe
In-Reply-To: <1514554802.65.0.213398074469.issue32145@psf.upfronthosting.co.za>
Message-ID: <E93694CF-95DD-43C4-B1E3-75EEF229CE0C@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Dec 29, 2017, at 08:40, Nick Coghlan <report at bugs.python.org> wrote:
> 
> I'm not clear on what you mean about allowing arbitrary names for the instance creation function -

What I meant was that I don?t see `def _make_instance()` defined in your example, so I didn?t know if that was part of the contract between the base and derived classes, or an ?arbitrary method? that subclasses can come up with.  From the example, it seems like the latter, but I could be misunderstanding your proposal.

> at that point we're back to subclasses not being able to use the default `pop_all()` implementation at all, and needing to duplicate the state transfer logic in the subclass (which we don't provide a public API to do, since the `_exit_callbacks` queue is deliberately private).
> 
> However, I'm thinking we could potentially change `pop_all` *itself* to accept a target object:
> 
>    def pop_all(self, *, target=None):
>        """Preserve the context stack by transferring it to a new instance
> 
>        If a *target* stack is given, it must be either an `ExitStack`
>        instance, or else provide a callback registration method akin to `ExitStack.callback`.
>        """
>        if target is None:
>            target = type(self)()
>        exit_callbacks = self._exit_callbacks
>        self._exit_callbacks = deque()
>        if isinstance(target, ExitStack):
>            target._exit_callbacks = exit_callbacks
>        else:
>            for cb in exit_callbacks:
>                target.callback(cb)
>        return target
> 
> The recipe fix would then be to make `Callback.cancel()` look like:
> 
>    def cancel(self):
>        # We deliberately *don't* clean up the cancelled callback
>        self.pop_all(target=ExitStack())

That?s actually not bad.  I think I like that better than the (IMHO, misnamed) _clone() API.  I?d quibble just a bit about the docstring, since the required API for target is exactly that it have a .callback() method that accepts a single exit callback argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32145>
_______________________________________

From report at bugs.python.org  Fri Dec 29 13:55:48 2017
From: report at bugs.python.org (Marcel Widjaja)
Date: Fri, 29 Dec 2017 18:55:48 +0000
Subject: [docs] [issue12706] timeout sentinel in ftplib and poplib
 documentation
In-Reply-To: <1312705981.24.0.601234287082.issue12706@psf.upfronthosting.co.za>
Message-ID: <1514573747.85.0.213398074469.issue12706@psf.upfronthosting.co.za>


Marcel Widjaja <mwidj at yahoo.com> added the comment:

Greg, I wonder if you are planning to submit a PR for your patch? If not, I'm plan to take your patch, make some minor adjustment and submit a PR.

----------
nosy: +mawidjaj

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

From report at bugs.python.org  Fri Dec 29 22:15:32 2017
From: report at bugs.python.org (mpb)
Date: Sat, 30 Dec 2017 03:15:32 +0000
Subject: [docs] [issue30449] Improve __slots__ datamodel documentation
In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za>
Message-ID: <1514603732.02.0.213398074469.issue30449@psf.upfronthosting.co.za>


mpb <mpb.mail at gmail.com> added the comment:

Can __slots__ be assigned a string?  If so, what are the consequences?  I find the current docs lack clarity.  For example from the docs for 3.7.0a3:

https://docs.python.org/3.7/reference/datamodel.html#slots

>  3.3.2.4. __slots__
>
>  [snip]
>
>  object.__slots__
>    This class variable can be assigned a string,
>    iterable, or sequence of strings [snip]

However, "3.3.2.4.1. Notes on using __slots__" does not discuss what happens when a string is assigned to __slots__.

The "notes" section does discuss assigning a "sequence of strings" to __slots__.

The "notes" section also says: "Any non-string iterable may be assigned to __slots__."

Based on quick experimentation, it appears that the string must be a single identifier.  I get a TypeError if I try to assign "foo bar" to __slots__.  The consequence of a string appears to be that only a single slot is created.  It would be nice if this was stated clearly in the docs.

The docs for 2.7 seem similar to version 3.7.0a3.  So maybe all versions of the docs could be improved regarding the specifics of what happens when you assign a string to __slots__.

----------
nosy: +mpb

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30449>
_______________________________________

From report at bugs.python.org  Sat Dec 30 00:11:56 2017
From: report at bugs.python.org (kandhan)
Date: Sat, 30 Dec 2017 05:11:56 +0000
Subject: [docs] [issue32452] Brackets and Parentheses used in an ambiguous
 way
Message-ID: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>


New submission from kandhan <kandhan.kuhan at gmail.com>:

https://docs.python.org/3/tutorial/classes.html

9.10. Generator Expressions

Some simple generators can be coded succinctly as expressions using a syntax similar to list comprehensions but with "parentheses instead of brackets"

Since parentheses comes under brackets, brackets could be changed to "Square Brackets"

----------
assignee: docs at python
components: Documentation
messages: 309216
nosy: docs at python, kandhan
priority: normal
severity: normal
status: open
title: Brackets and Parentheses used in an ambiguous way
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sat Dec 30 00:15:12 2017
From: report at bugs.python.org (kandhan)
Date: Sat, 30 Dec 2017 05:15:12 +0000
Subject: [docs] [issue32452] Brackets and Parentheses used in an ambiguous
 way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514610911.98.0.213398074469.issue32452@psf.upfronthosting.co.za>


kandhan <kandhan.kuhan at gmail.com> added the comment:

In the above comment,

Line 1 is the URL where it needs improvement

Line 2 and 3 are the actual content in the page that needs improvement

Line 4 is the proposed solution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sat Dec 30 01:31:35 2017
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 30 Dec 2017 06:31:35 +0000
Subject: [docs] [issue32452] Brackets and Parentheses used in an ambiguous
 way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514615495.55.0.213398074469.issue32452@psf.upfronthosting.co.za>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

In British, Australian, New Zealander, and Indian English (and sometimes Canada), at least, "bracket" on its own typically means round brackets () and is rarely if ever used for square brackets [] or curly brackets {} without the adjective.

See for example https://english.stackexchange.com/questions/168762/brackets-vs-parenthesis for a discussion.

Consequently, the phrase "parentheses instead of brackets" reads to us as "parentheses instead of parentheses" would to Americans. In other words, weird and requiring a moment (or three) of thought to translate.

I support the suggested change to "parentheses instead of square brackets" -- it should read more naturally to people in the British Commonwealth and (I hope) shouldn't look too strange to Americans.

My personal preference would be for "round brackets instead of square brackets", but I guess that will be a battle I have no hope of winning *wink*

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sat Dec 30 02:16:12 2017
From: report at bugs.python.org (kandhan)
Date: Sat, 30 Dec 2017 07:16:12 +0000
Subject: [docs] [issue32452] Brackets and Parentheses used in an ambiguous
 way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514618172.67.0.213398074469.issue32452@psf.upfronthosting.co.za>


kandhan <kandhan.kuhan at gmail.com> added the comment:

"round brackets instead of square brackets" sounds better.

Its simple and direct and doesn't require any extra operations other than the required one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sat Dec 30 16:14:03 2017
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Dec 2017 21:14:03 +0000
Subject: [docs] [issue32452] Brackets and Parentheses used in an ambiguous
 way
In-Reply-To: <1514610716.34.0.213398074469.issue32452@psf.upfronthosting.co.za>
Message-ID: <1514668443.61.0.213398074469.issue32452@psf.upfronthosting.co.za>


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

"round brackets" would require just as much thought (if not more...it's not a thing at all in American typographical language) for an American to understand as the unadorned bracket does for the rest of you, so the best compromise is "parenthesis instead of square brackets", since parenthesis is used elsewhere in the docs.

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

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32452>
_______________________________________

From report at bugs.python.org  Sun Dec 31 05:56:12 2017
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Dec 2017 10:56:12 +0000
Subject: [docs] [issue30449] Improve __slots__ datamodel documentation
In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za>
Message-ID: <1514717772.34.0.467229070634.issue30449@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

mpb, I think the docs with respect to strings are fine as-is.  Sometimes if too much detail is put in, it makes the docs harder to read and understand (i.e. it gets in the way of our primary purpose).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30449>
_______________________________________

From report at bugs.python.org  Sun Dec 31 12:41:41 2017
From: report at bugs.python.org (mpb)
Date: Sun, 31 Dec 2017 17:41:41 +0000
Subject: [docs] [issue30449] Improve __slots__ datamodel documentation
In-Reply-To: <1495587707.13.0.0998591622446.issue30449@psf.upfronthosting.co.za>
Message-ID: <1514742101.28.0.467229070634.issue30449@psf.upfronthosting.co.za>


mpb <mpb.mail at gmail.com> added the comment:

@rhettinger

I disagree (but you're the boss).  If a function can take type X as a parameter, I believe docs should also say what the expected behavior is when you call the function and pass it type X, especially when type X is fundamentally different from every other type the function accepts.  (And yes, __slots__ is not a function, but I still find the metaphor apt.) 
 Cheers!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30449>
_______________________________________

From jkneuper at gmail.com  Sun Dec 24 20:08:15 2017
From: jkneuper at gmail.com (James Kneuper)
Date: Mon, 25 Dec 2017 02:08:15 +0100
Subject: [docs] English text doc downloads for 2.7.14 are in Japanese
Message-ID: <CAEDq_wvYtzsJQXwMX-GJ3CM8Cb86zVROW+XGN4MN1p+YqME38Q@mail.gmail.com>

Greetings,

I just downloaded the Python documentation from:
https://docs.python.org/2.7/archives/python-2.7.14-docs-text.zip

Which is linked from this page:
https://docs.python.org/2.7/download.html

And the resulting documents were in Japanese. Same with the bzip2 version.
Thinking there may have been a swap, I tried switching to the Japanese docs
page and hit their download link, but that produced a 404.

The HTML version seems fine so I may just feed those through beautiful soup
for now.

Thought you might want to know :)

Cheers,
-Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171225/3d998176/attachment-0001.html>

From adr.her.arc.95 at gmail.com  Mon Dec 25 15:57:48 2017
From: adr.her.arc.95 at gmail.com (=?UTF-8?Q?Adri=C3=A1n_Herrera_Arcila?=)
Date: Mon, 25 Dec 2017 21:57:48 +0100
Subject: [docs] 7.2 Reading and Writing Files - No empty secondary prompt
 after "with" block
Message-ID: <CAB9FvTEwCEbOZ2a+NoxvfP6w46C06YGqpnRQ+X8n3bPD1FYkEg@mail.gmail.com>

Only happening in docs for Python 3.

The statement:

>>>  with open('workfile') as f:
.  .  .         read_data = f.read()
>>>  f.closed
True

should be:

>>>  with open('workfile') as f:
.  .  .         read_data = f.read()
.  .  .
>>>  f.closed
True

This would avoid people writing the code by themselves (instead of copying
and pasting it) making the mistake of introducing "f.closed" in the
secondary prompt after the end of the "with" compound.

Thanks in advance and have a beautiful day, Adri?n.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171225/6aba0bd0/attachment-0001.html>

From oisin.feeley at gmail.com  Wed Dec 27 14:27:29 2017
From: oisin.feeley at gmail.com (Oisin Feeley)
Date: Wed, 27 Dec 2017 14:27:29 -0500
Subject: [docs] 2.7.14 English text-only Documentation archive contains
 Japanese UTF-8
Message-ID: <CAOHyWkLsYqqwFNgGByNZFd-OQ3Zk1Mtz6YowtuD7DDTF91tUbQ@mail.gmail.com>

Hello,

I just (27 DEC 2017) downloaded the English 2.7.14 archive[1] of the
documentation and find that at least the "csv" module information in the
standard library contains interspersed blocks of (apparently) Japanese and
English characters, with significant blocks of the requisite English text
being entirely replaced.

I am viewing the docs with "less" and "vim" in a BASH shell on GNU/Linux.
The possibly apposite environment variables are set as follows:

BASH shell:
[ush at swift Downloads]$ env | egrep -i '(locale|lang|lc)'
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
GDM_LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8


vim:
Current language:
"LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_ME
SSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en
_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8"

So, is the problem on my end, or is your build-chain linking to the wrong
docs on the web page?

Thank you,

Oisin

1. https://docs.python.org/2/archives/python-2.7.14-docs-text.tar.bz2
(Selected 2.7.14 > English  from the dropdowns)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171227/e97c8141/attachment-0001.html>

From prsiyag at yahoo.co.in  Sat Dec 30 10:35:38 2017
From: prsiyag at yahoo.co.in (P R Siyag)
Date: Sat, 30 Dec 2017 15:35:38 +0000 (UTC)
Subject: [docs] output not correctly shown
References: <407457539.6805352.1514648138111.ref@mail.yahoo.com>
Message-ID: <407457539.6805352.1514648138111@mail.yahoo.com>

On this page:
4. More Control Flow Tools ? Python 3.6.4 documentation


| 
| 
|  | 
4. More Control Flow Tools ? Python 3.6.4 documentation


 |

 |

 |




the output starts with '3 is a prime number'? and not ' '2 is a prime number'? when I run it?:4.4. break and continue Statements, and else Clauses on Loops


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

From todd at wellshub.com  Sat Dec 30 14:01:06 2017
From: todd at wellshub.com (Todd Wells)
Date: Sat, 30 Dec 2017 11:01:06 -0800
Subject: [docs] ElementTree documentation error
Message-ID: <2D07696A-0148-4767-8DBB-5AC65577140C@wellshub.com>

I found this error in the documentation (https://docs.python.org/3.7/library/xml.etree.elementtree.html <https://docs.python.org/3.7/library/xml.etree.elementtree.html> and earlier versions):


xml.etree.ElementTree.tostring(element, encoding="us-ascii", method="xml", *, short_empty_elements=True) <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring>
Generates a string representation of an XML element, including all subelements.  element is an Element <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element> instance.  encoding [1] <https://docs.python.org/3.7/library/xml.etree.elementtree.html#id5> is the output encoding (default is US-ASCII). Use encoding="unicode" to generate a Unicode string (otherwise, a bytestring is generated). method is either "xml", "html" or "text" (default is "xml"). short_empty_elements has the same meaning as in ElementTree.write() <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.ElementTree.write>. Returns an (optionally) encoded string containing the XML data.

The error here is the method value ?text? is not a valid argument as the docs state. The correct value is ?us-ascii?. From an error I encountered:

Traceback (most recent call last):
  File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/test_modify_title_handler.py", line 11, in test_modify_title
    modified = handler.lambda_handler(event, None)
  File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/modify_title_handler.py", line 17, in lambda_handler
    event['body'] = ET.tostring(root, encoding='text', method='xml')
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 1135, in tostring
    short_empty_elements=short_empty_elements)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 759, in write
    with _get_writer(file_or_filename, enc_lower) as write:
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 82, in __enter__
    return next(self.gen)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 831, in _get_writer
    newline="\n")
LookupError: unknown encoding: text

Using ?us-ascii? instead of ?text? works.






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

From todd at wellshub.com  Sat Dec 30 14:03:55 2017
From: todd at wellshub.com (Todd Wells)
Date: Sat, 30 Dec 2017 11:03:55 -0800
Subject: [docs] ElementTree documentation error
In-Reply-To: <2D07696A-0148-4767-8DBB-5AC65577140C@wellshub.com>
References: <2D07696A-0148-4767-8DBB-5AC65577140C@wellshub.com>
Message-ID: <9D0B7591-6DBC-46F6-B33E-9C3600268621@wellshub.com>

Please disregard, I conflated two arguments.


> On Dec 30, 2017, at 11:01 AM, Todd Wells <todd at wellshub.com> wrote:
> 
> I found this error in the documentation (https://docs.python.org/3.7/library/xml.etree.elementtree.html <https://docs.python.org/3.7/library/xml.etree.elementtree.html> and earlier versions):
> 
> 
> xml.etree.ElementTree.tostring(element, encoding="us-ascii", method="xml", *, short_empty_elements=True) <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.tostring>
> Generates a string representation of an XML element, including all subelements.  element is an Element <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.Element> instance.  encoding [1] <https://docs.python.org/3.7/library/xml.etree.elementtree.html#id5> is the output encoding (default is US-ASCII). Use encoding="unicode" to generate a Unicode string (otherwise, a bytestring is generated). method is either "xml", "html" or "text" (default is "xml"). short_empty_elements has the same meaning as in ElementTree.write() <https://docs.python.org/3.7/library/xml.etree.elementtree.html#xml.etree.ElementTree.ElementTree.write>. Returns an (optionally) encoded string containing the XML data.
> 
> The error here is the method value ?text? is not a valid argument as the docs state. The correct value is ?us-ascii?. From an error I encountered:
> 
> Traceback (most recent call last):
>   File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/test_modify_title_handler.py", line 11, in test_modify_title
>     modified = handler.lambda_handler(event, None)
>   File "/Users/todd.wells/Dropbox/thePlatform SA/aws/lambda-ingest-proxy/modify-title-handler/modify_title_handler.py", line 17, in lambda_handler
>     event['body'] = ET.tostring(root, encoding='text', method='xml')
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 1135, in tostring
>     short_empty_elements=short_empty_elements)
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 759, in write
>     with _get_writer(file_or_filename, enc_lower) as write:
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/contextlib.py", line 82, in __enter__
>     return next(self.gen)
>   File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/xml/etree/ElementTree.py", line 831, in _get_writer
>     newline="\n")
> LookupError: unknown encoding: text
> 
> Using ?us-ascii? instead of ?text? works.
> 
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20171230/516e18fd/attachment-0001.html>

From rianvankampen at gmail.com  Sun Dec 31 13:22:30 2017
From: rianvankampen at gmail.com (Rian van Kampen)
Date: Sun, 31 Dec 2017 19:22:30 +0100
Subject: [docs] Bug in python tutorial
Message-ID: <29B035D9-425C-4046-BDE5-941B805C93FF@gmail.com>

Hi, 

Im trying to learn python and i can not get the example of 4.1. If statements to work. 

Every time i fill out x and the first if statement i go to the elif statement. As i put in the colon and hit enter to go to the next line to write the print it executes the lines and gives me a syntax error. The elif statement doesnt come on the same level als the first if statement. I cant find the answer online so could you please help me out? And correct the example of 4.1.? 

Kind regards, 

Rian