From report at bugs.python.org  Sat Jun  1 00:17:03 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 01 Jun 2019 04:17:03 +0000
Subject: [docs] [issue37073] clarify functions docs in IO modules and Bytes
 Objects
In-Reply-To: <1559027884.63.0.0963085588001.issue37073@roundup.psfhosted.org>
Message-ID: <1559362623.65.0.249662990398.issue37073@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Sure. Feel free to edit my PR.

----------

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

From report at bugs.python.org  Sat Jun  1 00:26:41 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 01 Jun 2019 04:26:41 +0000
Subject: [docs] [issue37073] clarify functions docs in IO modules and Bytes
 Objects
In-Reply-To: <1559027884.63.0.0963085588001.issue37073@roundup.psfhosted.org>
Message-ID: <1559363201.35.0.530719008613.issue37073@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
keywords: +patch
pull_requests: +13600
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13713

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

From report at bugs.python.org  Sat Jun  1 00:34:23 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 01 Jun 2019 04:34:23 +0000
Subject: [docs] [issue37073] clarify functions docs in IO modules and Bytes
 Objects
In-Reply-To: <1559027884.63.0.0963085588001.issue37073@roundup.psfhosted.org>
Message-ID: <1559363663.61.0.0737923338476.issue37073@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
pull_requests: +13602
pull_request: https://github.com/python/cpython/pull/13715

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

From report at bugs.python.org  Sat Jun  1 02:33:25 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Jun 2019 06:33:25 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559370805.15.0.0616618888819.issue18911@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 5ac0b988fd5f1428efe35329c531c7b5c74d37f6 by Stefan Behnel (Windson yang) in branch 'master':
bpo-18911: clarify that the minidom XML writer receives texts but not bytes (GH-13352)
https://github.com/python/cpython/commit/5ac0b988fd5f1428efe35329c531c7b5c74d37f6


----------

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

From report at bugs.python.org  Sat Jun  1 02:34:15 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Jun 2019 06:34:15 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559370855.76.0.0353618070723.issue18911@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat Jun  1 02:36:41 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Jun 2019 06:36:41 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559371001.69.0.48005719441.issue18911@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
resolution: fixed -> 
stage: resolved -> backport needed
status: closed -> open
versions: +Python 3.7

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

From report at bugs.python.org  Sat Jun  1 02:40:04 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 01 Jun 2019 06:40:04 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559371204.73.0.951276542431.issue18911@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13605
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/13718

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

From report at bugs.python.org  Sat Jun  1 02:58:57 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Jun 2019 06:58:57 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559372337.14.0.217642674434.issue18911@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:


New changeset 18e23f227be59241cbb1eeb6d6669771dd7275fb by Stefan Behnel (Miss Islington (bot)) in branch '3.7':
bpo-18911: clarify that the minidom XML writer receives texts but not bytes (GH-13718)
https://github.com/python/cpython/commit/18e23f227be59241cbb1eeb6d6669771dd7275fb


----------

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

From report at bugs.python.org  Sat Jun  1 03:00:02 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 01 Jun 2019 07:00:02 +0000
Subject: [docs] [issue18911] minidom does not encode correctly when calling
 Document.writexml
In-Reply-To: <1378186619.58.0.930376227557.issue18911@psf.upfronthosting.co.za>
Message-ID: <1559372402.41.0.791622392081.issue18911@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


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

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

From report at bugs.python.org  Sat Jun  1 07:47:09 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 01 Jun 2019 11:47:09 +0000
Subject: [docs] [issue36984] typing docs "versionadded" is inaccurate for
 many attributes
In-Reply-To: <1558416035.31.0.248938950481.issue36984@roundup.psfhosted.org>
Message-ID: <1559389629.16.0.0428476150028.issue36984@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


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

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

From report at bugs.python.org  Sat Jun  1 11:21:51 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 01 Jun 2019 15:21:51 +0000
Subject: [docs] [issue36612] Unittest document is not clear on SetUpClass
 calls
In-Reply-To: <1555070993.71.0.91547720267.issue36612@roundup.psfhosted.org>
Message-ID: <1559402511.21.0.0655292823409.issue36612@roundup.psfhosted.org>


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

@xtreak or @lisroach, any thoughts?  Thanks!

----------
nosy: +cheryl.sabella, lisroach, xtreak

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

From report at bugs.python.org  Sat Jun  1 11:52:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Jun 2019 15:52:01 +0000
Subject: [docs] [issue31968] exec(): method's default arguments from
 dict-inherited globals
In-Reply-To: <1510058956.93.0.213398074469.issue31968@psf.upfronthosting.co.za>
Message-ID: <1559404321.85.0.0722698708172.issue31968@roundup.psfhosted.org>


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


New changeset 059b9ea5ac98f432e41b05d1fa5aab4ffa22df4d by Raymond Hettinger (Anthony Shaw) in branch 'master':
bpo-31968: Documentation -- add clarification on the globals dict for exec() (GH-13140)
https://github.com/python/cpython/commit/059b9ea5ac98f432e41b05d1fa5aab4ffa22df4d


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

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

From report at bugs.python.org  Sat Jun  1 11:53:07 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Jun 2019 15:53:07 +0000
Subject: [docs] [issue31968] exec(): method's default arguments from
 dict-inherited globals
In-Reply-To: <1510058956.93.0.213398074469.issue31968@psf.upfronthosting.co.za>
Message-ID: <1559404387.77.0.0663521337838.issue31968@roundup.psfhosted.org>


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/issue31968>
_______________________________________

From report at bugs.python.org  Sat Jun  1 16:52:11 2019
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Sat, 01 Jun 2019 20:52:11 +0000
Subject: [docs] [issue26468] shutil.copy2 raises OSError if filesystem
 doesn't support chmod
In-Reply-To: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>
Message-ID: <1559422331.3.0.715951081165.issue26468@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy: +Jeffrey.Kintscher

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

From report at bugs.python.org  Sat Jun  1 17:11:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Jun 2019 21:11:50 +0000
Subject: [docs] [issue29414] Change 'the for statement is such an iterator'
 in Tutorial
In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za>
Message-ID: <1559423510.84.0.621116963958.issue29414@roundup.psfhosted.org>


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


New changeset 218e47b61862470477922e9aba1a23fd3dab18ae by Raymond Hettinger (Marco Buttu) in branch 'master':
bpo-29414: Change 'the for statement is such an iterator' in Tutorial (GH-273)
https://github.com/python/cpython/commit/218e47b61862470477922e9aba1a23fd3dab18ae


----------

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

From report at bugs.python.org  Sat Jun  1 17:12:13 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 01 Jun 2019 21:12:13 +0000
Subject: [docs] [issue29414] Change 'the for statement is such an iterator'
 in Tutorial
In-Reply-To: <1485976216.65.0.169866413965.issue29414@psf.upfronthosting.co.za>
Message-ID: <1559423533.32.0.357614489395.issue29414@roundup.psfhosted.org>


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/issue29414>
_______________________________________

From report at bugs.python.org  Sat Jun  1 20:07:20 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 02 Jun 2019 00:07:20 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1559434040.77.0.43284750444.issue36985@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Guido, I remember you were against exposing `ForwardRef` as public at some point, but recently you approved https://github.com/python/cpython/pull/13456 that added it to `typing.__all__`. I don't have any particular opinion on this, but if you don't object, I think it would make sense to add a short section about this to the docs, since it may be exposed at runtime, e.g. in `List['Cls']`.

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

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

From report at bugs.python.org  Sat Jun  1 20:14:56 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 02 Jun 2019 00:14:56 +0000
Subject: [docs] [issue36984] typing docs "versionadded" is inaccurate for
 many attributes
In-Reply-To: <1558416035.31.0.248938950481.issue36984@roundup.psfhosted.org>
Message-ID: <1559434496.33.0.16783590035.issue36984@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13620
pull_request: https://github.com/python/cpython/pull/13737

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

From report at bugs.python.org  Sat Jun  1 20:25:05 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 02 Jun 2019 00:25:05 +0000
Subject: [docs] [issue36984] typing docs "versionadded" is inaccurate for
 many attributes
In-Reply-To: <1558416035.31.0.248938950481.issue36984@roundup.psfhosted.org>
Message-ID: <1559435105.77.0.725723338649.issue36984@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jun  2 05:10:40 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Jun 2019 09:10:40 +0000
Subject: [docs] [issue36879] bug with round() and "numpy floats"
In-Reply-To: <1557521461.62.0.231118714409.issue36879@roundup.psfhosted.org>
Message-ID: <1559466640.11.0.60096823401.issue36879@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> third party
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jun  2 06:27:17 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Jun 2019 10:27:17 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559471237.66.0.182013088254.issue17576@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm working on a PR that finally changes the DeprecationWarnings that Serhiy introduced to TypeErrors; I think that should be acceptable, four Python versions and some years later. With that PR:

- int will always return something of exact type `int` (or raise)
- operator.index will always return something of exact type `int` (or raise)
- PyNumber_Index will always use `__index__` for int subclasses, so this should fix the issue that Barry originally reported (mismatch between `obj.__index__()` and `operator.index(obj)`).

----------

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

From report at bugs.python.org  Sun Jun  2 06:46:42 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Jun 2019 10:46:42 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559472402.12.0.741448106446.issue17576@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
assignee: ethan.furman -> mark.dickinson

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

From report at bugs.python.org  Sun Jun  2 06:56:11 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 02 Jun 2019 10:56:11 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559472971.67.0.369197136374.issue17576@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
pull_requests: +13623
pull_request: https://github.com/python/cpython/pull/13740

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

From report at bugs.python.org  Sun Jun  2 07:11:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 02 Jun 2019 11:11:49 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559473909.82.0.673703627215.issue17576@roundup.psfhosted.org>


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

I am not sure that raising an error is the best option. We can just convert an integer subclass to an exact int using _PyLong_Copy().

I am not sure that converting to an exact int in low-level C API functions is the best option. In many cases we use only the content of the resulting object ignoring its type (when convert it to the C integer or float, to bytes array, to new instance of int subclass). Creating a new exact int is a waste of time.

This is why I withdrawn my patches and this issue is still open.

----------

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

From ola at aquarius.se  Sun Jun  2 08:28:18 2019
From: ola at aquarius.se (Ola K)
Date: Sun, 2 Jun 2019 14:28:18 +0200
Subject: [docs] I understand this is not a bug, but ..
Message-ID: <CA+skKAMuJpta6miBdkBwZYfkbkKXagFCi8PinFLjSt-PAyUN_g@mail.gmail.com>

I understand this is not a bug, but problems like this that feels "too
simple to ask about" form me is really annoying as a newbie because it
opens the lid on the programming culture as a whole I guess and by that I
am referring to the overall messy sea of different languages one have to
decide where to start navigate, the abundance of litterature connected to
the language of choice, the abundance of IDE:s, forums, moduls and packages
vs another enviroment, (yet another galaxy). I understands this is because
programming is used for all walks of life. But yet after months of
studying, navigating, installing, targeting/ choosing platform, I come back
to this "the king has no clothes" question:
What is the difference between an "editor of choice" and a "python
interpreter"? I was following an example wich I now ironically lost among
all my millions of open tabs. I know you can?t help me now because I lost
the adress to that place and because this is not the proper way of asking
questions, but anyway, see this message as a reality check if you feel like
it.

Bye thank you for everything (keeping up the struggle for my better future).
//Ola

For instance, use your favorite text editor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190602/d0b01517/attachment.html>

From report at bugs.python.org  Sun Jun  2 12:18:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 02 Jun 2019 16:18:06 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
Message-ID: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

In the documentation, there are a lot of mismatches regarding function and method signatures that use positional-only arguments with respect to the docstrings (that properly use PEP570 syntax for documenting positional-only parameters).

Not that the official syntax for positional-only parameters is accepted (the "/"), the documentation needs to be updated to reflect positional-only parameters in the functions and methods that use them as covered in the PEP document.

----------
assignee: docs at python
components: Documentation
messages: 344295
nosy: docs at python, pablogsal
priority: normal
severity: normal
status: open
title: Use PEP570 syntax in the documentation
versions: Python 3.8

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

From report at bugs.python.org  Sun Jun  2 12:24:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 02 Jun 2019 16:24:34 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559492674.49.0.968692750494.issue37134@roundup.psfhosted.org>


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


----------
keywords: +easy
stage:  -> needs patch
title: Use PEP570 syntax in the documentation -> [EASY] Use PEP570 syntax in the documentation
type:  -> enhancement

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

From report at bugs.python.org  Sun Jun  2 12:34:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 02 Jun 2019 16:34:17 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559493257.09.0.266525655894.issue37134@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +13626
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/13743

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

From report at bugs.python.org  Sun Jun  2 16:22:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 02 Jun 2019 20:22:01 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559506921.43.0.802954892216.issue17576@roundup.psfhosted.org>


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

Can we at least switch to PyLong_CheckExact?  That would fix Barry's original issue and should run slightly faster.

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

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

From zachary.ware+pydocs at gmail.com  Sun Jun  2 16:21:54 2019
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sun, 2 Jun 2019 15:21:54 -0500
Subject: [docs] I understand this is not a bug, but ..
In-Reply-To: <CA+skKAMuJpta6miBdkBwZYfkbkKXagFCi8PinFLjSt-PAyUN_g@mail.gmail.com>
References: <CA+skKAMuJpta6miBdkBwZYfkbkKXagFCi8PinFLjSt-PAyUN_g@mail.gmail.com>
Message-ID: <CAKJDb-M+ybfqCP7K31gHXnHk-t1c5qES1uou+z3coc_gSLup=Q@mail.gmail.com>

On Sun, Jun 2, 2019 at 8:30 AM Ola K <ola at aquarius.se> wrote:
> What is the difference between an "editor of choice" and a "python interpreter"?

Hi Ola,

This question would be better suited to the python-tutor mailing list,
tutor at python.org (see https://mail.python.org/mailman/listinfo/tutor).
It's a great place to ask questions and learn from some very
knowledgable and friendly people!

To give you an answer, though: a text editor ("editor of choice" being
whichever text editor you like to use) is any program that allows you
to edit plain text files (Notepad on Windows, TextEdit on macOS, or
gedit on Ubuntu, *not* WordPad, Google Docs, or LibreOffice), while a
Python interpreter is the program usually called "python" (or
"python.exe" on Windows) that reads the Python code that you write,
interprets it, and tells the computer what to do.  Usually, programs
are written to a file using a text editor and then the Python
interpreter is directed to run the code in that file, but it is also
possible to input code directly using what is called the "REPL", or
Read-Eval-Print-Loop (however, anything written to the REPL cannot be
simply saved to reuse later).  The standard Python distribution
downloadable from python.org includes IDLE, which is an example of an
IDE (Integrated Development Environment) which provides a text editor
and an interface to the Python interpreter's REPL bundled into one
program.

I hope this answers your question, and I do encourage signing up to
the tutor list for far more in-depth answers to any of your Python
programming questions.

Regards,
Zach

From report at bugs.python.org  Sun Jun  2 17:01:52 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 21:01:52 +0000
Subject: [docs] [issue37014] [First easy issue] fileinput module should
 document that openhook and mode are ignored when reading from stdin
In-Reply-To: <1558545967.04.0.906137299955.issue37014@roundup.psfhosted.org>
Message-ID: <1559509312.56.0.83488611034.issue37014@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:


New changeset aca273e2401ca3151e15e984f400233b7f255e15 by Ezio Melotti (Michele Angrisano) in branch 'master':
bpo-37014: Update docstring and Documentation of fileinput.FileInput(). (GH-13545)
https://github.com/python/cpython/commit/aca273e2401ca3151e15e984f400233b7f255e15


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Jun  2 17:02:03 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 02 Jun 2019 21:02:03 +0000
Subject: [docs] [issue37014] [First easy issue] fileinput module should
 document that openhook and mode are ignored when reading from stdin
In-Reply-To: <1558545967.04.0.906137299955.issue37014@roundup.psfhosted.org>
Message-ID: <1559509323.24.0.473052244848.issue37014@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13634
pull_request: https://github.com/python/cpython/pull/13753

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

From report at bugs.python.org  Sun Jun  2 17:13:42 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 02 Jun 2019 21:13:42 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1559434040.77.0.43284750444.issue36985@roundup.psfhosted.org>
Message-ID: <CAP7+vJKE_uC3caa97RN9rt7sKKMFyKt-V4bOkfAx+Me0rt1hEA@mail.gmail.com>


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

Huh. I think I have mellowed with age. IOW SGTM.

On Sat, Jun 1, 2019 at 17:07 Ivan Levkivskyi <report at bugs.python.org> wrote:

>
> Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:
>
> Guido, I remember you were against exposing `ForwardRef` as public at some
> point, but recently you approved
> https://github.com/python/cpython/pull/13456 that added it to
> `typing.__all__`. I don't have any particular opinion on this, but if you
> don't object, I think it would make sense to add a short section about this
> to the docs, since it may be exposed at runtime, e.g. in `List['Cls']`.
>
> ----------
> nosy: +gvanrossum
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36985>
> _______________________________________
>
-- 
--Guido (mobile)

----------

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

From report at bugs.python.org  Sun Jun  2 17:34:15 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 21:34:15 +0000
Subject: [docs] [issue19184] dis module has incorrect docs for RAISE_VARARGS
In-Reply-To: <1381078012.05.0.236677780468.issue19184@psf.upfronthosting.co.za>
Message-ID: <1559511255.19.0.796714014564.issue19184@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:


New changeset e1179a5096fb12297ececd7a1c79969aa5747e28 by Ezio Melotti (Michele Angrisano) in branch 'master':
bpo-19184: Update the documentation of dis module. (GH-13652)
https://github.com/python/cpython/commit/e1179a5096fb12297ececd7a1c79969aa5747e28


----------
nosy: +ezio.melotti

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

From report at bugs.python.org  Sun Jun  2 17:35:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 02 Jun 2019 21:35:15 +0000
Subject: [docs] [issue19184] dis module has incorrect docs for RAISE_VARARGS
In-Reply-To: <1381078012.05.0.236677780468.issue19184@psf.upfronthosting.co.za>
Message-ID: <1559511315.65.0.78529989868.issue19184@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13636
pull_request: https://github.com/python/cpython/pull/13755

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

From report at bugs.python.org  Sun Jun  2 17:36:37 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 21:36:37 +0000
Subject: [docs] [issue37014] [First easy issue] fileinput module should
 document that openhook and mode are ignored when reading from stdin
In-Reply-To: <1558545967.04.0.906137299955.issue37014@roundup.psfhosted.org>
Message-ID: <1559511397.54.0.493297848972.issue37014@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:


New changeset 6bd438e137a0618b8db949a4751304f541b6674d by Ezio Melotti (Miss Islington (bot)) in branch '3.7':
bpo-37014: Update docstring and Documentation of fileinput.FileInput(). (GH-13545) (GH-13753)
https://github.com/python/cpython/commit/6bd438e137a0618b8db949a4751304f541b6674d


----------

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

From report at bugs.python.org  Sun Jun  2 17:43:10 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 21:43:10 +0000
Subject: [docs] [issue37014] fileinput module should document that openhook
 and mode are ignored when reading from stdin
In-Reply-To: <1558545967.04.0.906137299955.issue37014@roundup.psfhosted.org>
Message-ID: <1559511790.12.0.693011678582.issue37014@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the PRs!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: [First easy issue] fileinput module should document that openhook and mode are ignored when reading from stdin -> fileinput module should document that openhook and mode are ignored when reading from stdin
type:  -> enhancement
versions: +Python 3.8

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

From report at bugs.python.org  Sun Jun  2 17:59:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 02 Jun 2019 21:59:27 +0000
Subject: [docs] [issue32573] All sys attributes (.argv,
 ...) should exist in embedded environments
In-Reply-To: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>
Message-ID: <1559512767.7.0.85770304316.issue32573@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The issue has been fixed in Python 3.8. See PEP 587 and http://docs.python.org/dev/c-api/init_config.html for the larger scope.

For Python 3.7, the fix is trivial: don't add the following 2 lines in your application:

if not hasattr(sys, 'argv'):
    sys.argv = ['']

Python 3.7 Release Manager, Ned Deily, was opposed to change the behavior in a minor release:
https://github.com/python/cpython/pull/13553#issuecomment-496768319

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

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

From bgailer at gmail.com  Sun Jun  2 18:27:11 2019
From: bgailer at gmail.com (Bob Gailer)
Date: Sun, 2 Jun 2019 18:27:11 -0400
Subject: [docs] I understand this is not a bug, but ..
In-Reply-To: <CA+skKAMuJpta6miBdkBwZYfkbkKXagFCi8PinFLjSt-PAyUN_g@mail.gmail.com>
References: <CA+skKAMuJpta6miBdkBwZYfkbkKXagFCi8PinFLjSt-PAyUN_g@mail.gmail.com>
Message-ID: <CAP1rxO5ofA90NQzuVWzbPid5U1ue9u++5mp1_PCd=FmB+8z6zw@mail.gmail.com>

please also make your emails as brief as possible. Most of us don't want to
take the time to Wade through a lot of excess verbiage.

For example:
"What is the difference between a text editor and a python interpreter?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190602/7ea144b4/attachment.html>

From report at bugs.python.org  Sun Jun  2 19:18:53 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 23:18:53 +0000
Subject: [docs] [issue19184] dis module has incorrect docs for RAISE_VARARGS
In-Reply-To: <1381078012.05.0.236677780468.issue19184@psf.upfronthosting.co.za>
Message-ID: <1559517533.76.0.105112291366.issue19184@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:


New changeset 9390e98c3ed9eb9fa414030a2feec1926193af94 by Ezio Melotti (Miss Islington (bot)) in branch '3.7':
bpo-19184: Update the documentation of dis module. (GH-13652) (GH-13755)
https://github.com/python/cpython/commit/9390e98c3ed9eb9fa414030a2feec1926193af94


----------

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

From report at bugs.python.org  Sun Jun  2 19:19:46 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 02 Jun 2019 23:19:46 +0000
Subject: [docs] [issue19184] dis module has incorrect docs for RAISE_VARARGS
In-Reply-To: <1381078012.05.0.236677780468.issue19184@psf.upfronthosting.co.za>
Message-ID: <1559517586.5.0.421036728531.issue19184@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the report and the PRs!

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.7

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

From report at bugs.python.org  Sun Jun  2 20:43:25 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 03 Jun 2019 00:43:25 +0000
Subject: [docs] [issue36896] clarify in types.rst that FunctionTypes & co
 constructors don't have stable signature
In-Reply-To: <1557698610.19.0.556381141599.issue36896@roundup.psfhosted.org>
Message-ID: <1559522604.98.0.518027465992.issue36896@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 13136e83a637a9f1cfbada7e93097005296659b4 by Petr Viktorin (Matthias Bussonnier) in branch 'master':
bpo-36896: Clarify that some types constructors are unstable (GH-13271)
https://github.com/python/cpython/commit/13136e83a637a9f1cfbada7e93097005296659b4


----------

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

From report at bugs.python.org  Sun Jun  2 21:26:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jun 2019 01:26:50 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559525210.09.0.622282845708.issue37134@roundup.psfhosted.org>


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

Do we really want to do this?  ISTM, this would be a regression in the readability of the docs.  100% of the users of the docs will be confronted with this syntax which is mostly irrelevant to them.

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

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

From report at bugs.python.org  Sun Jun  2 21:32:02 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jun 2019 01:32:02 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559525522.67.0.195577237352.issue37134@roundup.psfhosted.org>


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

Guido, was it your intention that this show-up everywhere in the docs.  I had thought the primary motivation was to make it possible to write pure python code that exactly matched a C API.   

ISTM, there is no need to confront every single user of the docs with a notation that is known to be confusing.  From a teacher's point of view, pushing this notation everywhere in the docs changes the priority of the topic.  Formerly, it was an optional intermediate/advanced topic.  But if it is visible everywhere, it becomes an unavoidable day one topic for every single learner (that is if we want them to be able to read and understand the docs).

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

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

From report at bugs.python.org  Sun Jun  2 22:13:08 2019
From: report at bugs.python.org (Windson Yang)
Date: Mon, 03 Jun 2019 02:13:08 +0000
Subject: [docs] [issue26468] shutil.copy2 raises OSError if filesystem
 doesn't support chmod
In-Reply-To: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>
Message-ID: <1559527988.15.0.0463146699511.issue26468@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
keywords: +patch
pull_requests: +13651
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13765

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

From report at bugs.python.org  Sun Jun  2 22:47:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Jun 2019 02:47:11 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559530031.47.0.963150288096.issue37134@roundup.psfhosted.org>


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

Please don?t call on just me. If you really don?t want this, call on the Steering Council.

----------

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

From report at bugs.python.org  Mon Jun  3 00:20:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jun 2019 04:20:45 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559535645.74.0.780137588903.issue37134@roundup.psfhosted.org>


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

Sorry, I thought that as the BDFL delegate for PEP 570, you would be the person to ask. Adding the Steering Council members to the nosy list.

----------
nosy: +barry, brett.cannon, ncoghlan, willingc

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

From jsundownr at gmail.com  Sun Jun  2 17:13:53 2019
From: jsundownr at gmail.com (Jim Osborne)
Date: Sun, 2 Jun 2019 14:13:53 -0700
Subject: [docs] Great Documention
Message-ID: <CAANAWcvPi9zdRk8M3=QK23YCuMK+P-VNEsSyoRf8v-Z06UaeVQ@mail.gmail.com>

Your python documentation is the best I have ever seen ... thanks.

Jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190602/64479631/attachment.html>

From report at bugs.python.org  Mon Jun  3 02:46:54 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Jun 2019 06:46:54 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559544414.65.0.445712205612.issue17576@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Can we at least switch to PyLong_CheckExact?

+1

> I am not sure that converting to an exact int in low-level C API functions is the best option.

I am sure. :-)  The number of naturally-occurring cases where we're actually passing a subtype of `int` that's not exactly `int` should be tiny. So long as there's a PyLong_CheckExact fast path, I don't think there are really any performance concerns here.

And we definitely shouldn't let performance concerns dictate API; get the API right first, _then_ see what can be done about performance without changing the API. It's clear to me that `operator.index(obj)` _should_ give the exact same results as `obj.__index__()`.

I'll split my PR up into two pieces, one for turning the deprecated behaviour into TypeErrors, and a second one that just makes the PyLong_CheckExact change. (I likely won't have time before feature freeze, though. OTOH, the PyLong_CheckExact change could be considered a bugfix.)

----------

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

From report at bugs.python.org  Mon Jun  3 03:10:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 03 Jun 2019 07:10:52 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559545851.95.0.630272206643.issue17576@roundup.psfhosted.org>


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

> Can we at least switch to PyLong_CheckExact?

This is a behavior change and as such should be preceded by a period of warning.

If we go this way I propose to add a FutureWarning for int subclasses with overridden __index__.

As for turning the deprecated behaviour into TypeErrors, we added yet few deprecation warnings in 3.8. Would not be better to turn all of them into TypeErrors at the same time?

----------

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

From report at bugs.python.org  Mon Jun  3 04:57:17 2019
From: report at bugs.python.org (Oleksandr Pavliuk)
Date: Mon, 03 Jun 2019 08:57:17 +0000
Subject: [docs] [issue34788] ipaddress module fails on rfc4007 scoped IPv6
 addresses
In-Reply-To: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>
Message-ID: <1559552237.38.0.591512414707.issue34788@roundup.psfhosted.org>


Change by Oleksandr Pavliuk <ragnarok49 at gmail.com>:


----------
keywords: +patch
pull_requests: +13657
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13772

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

From report at bugs.python.org  Mon Jun  3 06:18:39 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 03 Jun 2019 10:18:39 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559557119.18.0.263430903274.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank you, Raymond, for sharing your concerns regarding this. I am sorry you disagree with this change.

I would want to expose the reasons I think this is important and justified, but please, don't read this
as a way of dismissing your concerns; I really respect your opinion and judgment (as an example, I am waiting
until you are happy with the API in issue17005 even if that meant waiting 2 years until the next release).

1) The docstrings for these functions already show the "/". As Matthias Bussonnier from IPython and Jupyter has expressed
multiple times, there are a ton of users that do not read html documentation and rely solely on the output from help (either
in Jupyter, IPython or CPython). These users find very strange that the signatures of the docstrings differ when they actually
check the html docs. Some examples of the docstrings:

>>> help(zlib.decompress)
    decompress(data, /, wbits=15, bufsize=16384)
    Returns a bytes object containing the uncompressed data.

>> help(codecs.register)
register(search_function, /)
    Register a codec search function.

2) This communicates the users more explicitly how to call the function and what to expect when this happens,
which is the purpose of documenting signatures in the documentation. We are already documenting keyword-only
parameters for the same reasons.

3) This PR is not changing any of the signatures, is just documenting and informing users what the signature is
and how it will behave. Is just expressing information. The documentation must be user-friendly, but also needs to
be technical.

4) We are already documenting positional-only arguments in multiple other functions in the documentation. This PR just
continues doing that. Some examples of the many cases:

https://docs.python.org/3.8/library/functools.html#functools.partialmethod
https://docs.python.org/3.8/library/threading.html#threading.excepthook
https://docs.python.org/3.8/library/inspect.html#inspect.getcallargs
...

5) I give training sessions to different levels (people that are starting to program, Juniors and Seniors) and they are always
confused when the signature of the function in the documentation does not match the docstring or the actual way of calling the function.
This also includes when we use constructs like f(x, ...), f(x, [y=None,]), f(K) -> V or similar because they are not valid Python
signatures and they do not appear elsewhere. In general, my experience is that people want the signature documented as close as possible
to the real signature in the technical documentation.

I wished we could have iterate over this together having a good discussion before involving the steering council, and I am sorry
if you were afraid that your concerns would have not been listened to. Sadly, I have not answered before because it was 1:26 in the morning
here when you posted your message. I have left the PR open and opened an issue because is the normal workflow and because this allows people
to express here their opinion. 

I think this change is important, but I also think of working together and respecting and understanding everyone's point of view
is much more important. If you think me pushing for this change will impact somehow our ability to work together I will close the PR
and the issue.

For now, I won't do anything before the steering council decides what to do.

I apologize to everyone or the wall of text.

----------

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

From report at bugs.python.org  Mon Jun  3 06:34:46 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Jun 2019 10:34:46 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559558086.46.0.701396640952.issue17576@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I've closed the PR. Reassigning back to Ethan.

----------
assignee: mark.dickinson -> ethan.furman
nosy: +ethan.furman

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

From report at bugs.python.org  Mon Jun  3 06:35:23 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 03 Jun 2019 10:35:23 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559558123.77.0.23095889485.issue17576@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy:  -mark.dickinson

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

From report at bugs.python.org  Mon Jun  3 07:23:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Jun 2019 11:23:39 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559561019.18.0.525385349287.issue37134@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-37116.

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

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

From report at bugs.python.org  Mon Jun  3 12:48:36 2019
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Mon, 03 Jun 2019 16:48:36 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
Message-ID: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>


New submission from Geoffrey Sneddon <geoffers+pythonbugs at gmail.com>:

The mixin methods on MappingView and its subclasses all rely on the undocumented MappingView._mapping (set in the undocumented MappingView.__init__).

This should probably be documented at least insofar as Set._from_iterable is.

----------
assignee: docs at python
components: Documentation
messages: 344447
nosy: docs at python, gsnedders
priority: normal
severity: normal
status: open
title: collections.abc.MappingView mixins rely on undocumented _mapping
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jun  3 13:00:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 03 Jun 2019 17:00:53 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559581253.55.0.514907331727.issue37145@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon Jun  3 13:16:22 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jun 2019 17:16:22 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559582182.77.0.155063201001.issue37145@roundup.psfhosted.org>


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

The _mapping attribute is a private implementation detail and should remain undocumented.  A user of mapping views creates that attribute via the __init__() method.

In contrast, _from_iterable is explicitly meant to be overridden because it is the only way to control object creation.

Thank you for the suggestion.

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

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

From report at bugs.python.org  Mon Jun  3 13:28:03 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 03 Jun 2019 17:28:03 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559582883.01.0.383934231129.issue37134@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Mon Jun  3 14:30:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 03 Jun 2019 18:30:40 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559586640.34.0.956339020378.issue37134@roundup.psfhosted.org>


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

> If you think me pushing for this change will impact somehow
> our ability to work together I will close the PR and the issue. 

Not at all.  I always enjoy working with you and appreciate the depth of thinking you bring to every task :-)

Here, we just disagree on whether changing the docs will be a net aid or net detriment to end users.  My belief is that the docs will be less usable, less intuitive, and less approachable.  People using the docs are already alone and in need of help.  Cryptic notation doesn't make this task easier.  While a person can be trained to read this notation, it is my belief that a person shouldn't have to have training to read the docs.

Unlike other decisions where predicting the future is uncertain, we already have some user testing results because the \ notation was exposed in help() via the argument clinic.  The results have not been favorable.  AFAICT not one single user has benefitted from seeing something like this output from help(len):

    len(obj, /)
        Return the number of items in a container.

The / is a stumbling block. My unscientific twitter poll had mostly WTF reactions from end-users. This wasn't limited to beginners -- Steve Holden and David Beazley have both found this notation detrimental to communication.

This week I joined a twitter thread where I needed to defend the existing docs.  The contention was that docs aren't very usable for end-users and that the existing core devs lacked writing skills and were too interested in technical details rather than plain communication. (I mostly disagree with this, but there is another core dev consistently giving this message in talks all around the world).  The essential point here is that there are already usability concerns with the documentation.  My belief is that this PR will make the situation worse.

----------

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

From report at bugs.python.org  Mon Jun  3 14:51:31 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Jun 2019 18:51:31 +0000
Subject: [docs] [issue36868] New behavior of OpenSSL hostname verification
 not exposed, incorrectly documented
In-Reply-To: <1557425747.49.0.948212766878.issue36868@roundup.psfhosted.org>
Message-ID: <1559587890.98.0.151328836607.issue36868@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 47eb2234061524562a4b484e3a395f4fdd6c1b76 by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-36868: Fix what's new for SSLContext.hostname_checks_common_name (GH-13248)
https://github.com/python/cpython/commit/47eb2234061524562a4b484e3a395f4fdd6c1b76


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Jun  3 14:51:40 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Jun 2019 18:51:40 +0000
Subject: [docs] [issue36868] New behavior of OpenSSL hostname verification
 not exposed, incorrectly documented
In-Reply-To: <1557425747.49.0.948212766878.issue36868@roundup.psfhosted.org>
Message-ID: <1559587900.21.0.104563786722.issue36868@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +13669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13784

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

From report at bugs.python.org  Mon Jun  3 15:01:15 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 03 Jun 2019 19:01:15 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559588475.0.0.766825791794.issue37134@roundup.psfhosted.org>


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

I haven't looked at anything in this PR, so just popping in to confirm that the first time I saw stuff like:

    len(obj, /)

in the docs I had no idea at all what it was trying to say.  I thought it was a typo.

Also the second, third, fourth, ..., times I saw it.

However, because Python didn't _accept_ that syntax in my own function definitions, that may well have made it extraordinarily hard to figure out.

If the syntax is going to be accepted now, that does change things to my eyes.  It becomes a question of discoverability then.

I'll note that Googling on

    python slash in formal argument list

turns up an excellent Stackoverflow explanation as its top hit for me today, although not if "slash" is replaced with "/".

----------
nosy: +tim.peters

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

From report at bugs.python.org  Mon Jun  3 15:02:14 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 03 Jun 2019 19:02:14 +0000
Subject: [docs] [issue36868] New behavior of OpenSSL hostname verification
 not exposed, incorrectly documented
In-Reply-To: <1557425747.49.0.948212766878.issue36868@roundup.psfhosted.org>
Message-ID: <1559588534.68.0.531655245365.issue36868@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cad4ff65eb12649cd650059b15d8e12f2ae951ef by Miss Islington (bot) in branch '3.7':
bpo-36868: Fix what's new for SSLContext.hostname_checks_common_name (GH-13248)
https://github.com/python/cpython/commit/cad4ff65eb12649cd650059b15d8e12f2ae951ef


----------

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

From report at bugs.python.org  Mon Jun  3 15:24:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 03 Jun 2019 19:24:57 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559589897.01.0.522570745757.issue37134@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

FYI when Guido said "call on the steering council" I think he meant open an issue at https://github.com/python/steering-council/issues as this will get lost otherwise (i.e. Guido already removed himself from the nosy list so this already doesn't have the whole council participating).

Anyway, from my personal view, I think we should use the syntax. It's officially part of the language at this point and so avoiding it in the docs seems odd, like we're saying that we're ashamed of this syntax and you should pretend it doesn't exist when it does and it isn't going anywhere. Otherwise aren't we're forcing users to realize that the function definition in the docs deviates from what is definable in this one instance and that one has to read the full text to know that something is doable syntactically but we're leaving it out of the docs? It adds inconsistency in what the definition line means IMO based on how we have usually chosen to try and express things in that 'def' line in the docs as succinctly as possible to communicate the semantics of calling that function.

And I realize that Raymond's "unscientific twitter poll had mostly WTF reactions from end-users", but that's also sampling from people who have probably never used the syntax in real life or read docs regularly that use it. I've actually been wanting to use the syntax to say "the name isn't important here" as I've had to already close a PR that wanted to tweak documentation for name consistency where it actually didn't matter because the code used positional-only parameters but they weren't explicitly documented as such. Going back and saying "positional-only" to communicate that everywhere that it applies versus using the syntax we have to express that seems unnecessary to me.

Or put another way, how would you want to update:

len(obj)
        Return the number of items in a container.

to properly reflect the fact that *obj* is positional-only which is now an official concept in the language? We've been glazing over this for ages in the docs because we didn't have a way of expressing it succinctly and it only touched C-implemented code and we lacked a way to state it in Python, but now we have a way to state this fact. You could add a "The **obj** parameter is positional-only.", but to me that requires unnecessary reading of the text body if all I'm doing is checking the parameter order (and maybe the first sentence). And I realize we have gotten away with this until now, but as the concept of positional-only parameters grows that will become more of an issue.

Not using / also means that we're deviating from what help() emits, which could cause its own confusion as more people learn about the new syntax.

----------

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

From report at bugs.python.org  Mon Jun  3 16:49:18 2019
From: report at bugs.python.org (Carol Willing)
Date: Mon, 03 Jun 2019 20:49:18 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559594958.24.0.689891356934.issue37134@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

Tim's message resonated with me. Confusing users is something that I believe that we wish to minimize. I confess that I had a similar reaction as Tim when I saw functions with a trailing `/`. What I did find helpful was adding to the middle of the parameter list as was done in Serihy's earlier PRs.

Since we are balancing technical accuracy with user confusion (docs and docstrings), I propose the following: 

1. Remove the trailing / from 3.8 documentation but leave the / if it occurs in the middle of the parameter list. This increases technical accuracy from pre-3.8 and gives users more time to get comfortable with the change (since end users have found this a confusing area with args kwargs *).

2. Add to the documentation in 3.8 section on positional only parameters a note box that describes that in many/all cases where a / is not specified at the end and no * is found in the parameter list that a trailing slash would be accurate.

3. Give users time to absorb the positional only change in 3.8. Perhaps writing a blog post that explains in detail.

4. Add the trailing / in 3.9 documentation to make consistent with docstrings or improve/create a better directive for function that provides a better accuracy and less confusion. A Sphinx extension may also be made to show a simple user-friendly view and with a click the fully accurate view.

----------

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

From report at bugs.python.org  Mon Jun  3 17:35:29 2019
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Mon, 03 Jun 2019 21:35:29 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559597729.08.0.293471881106.issue37145@roundup.psfhosted.org>


Geoffrey Sneddon <geoffers+pythonbugs at gmail.com> added the comment:

How do you use ItemsView without:

 * relying on __init__ and _mapping, which are both private implementation details, or
 * reimplementing __len__, __contains__, and __iter__?

Given you can't use the mixin implementations of __len__, __contains__, and __iter__ without relying on private implementation details, should they actually be considered mixin implementations? Shouldn't they just be abstract methods given you can't actually use them?

----------

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

From report at bugs.python.org  Mon Jun  3 17:56:55 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 03 Jun 2019 21:56:55 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559599015.5.0.326741084989.issue37134@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I agree with Brett and Carol here.  This is part of the language syntax.  We can educate people to that effect more if desired (I like the blog post idea).  People will figure it out.

We've already got high ranked stackoverflow answers related to this when you search:
 https://stackoverflow.com/questions/24735311/python-what-does-the-slash-mean-in-help-output/
 https://stackoverflow.com/questions/28243832/what-is-the-meaning-of-a-forward-slash-in-a-python-method-signature-as-show/

Today, we don't document what is positional only, adding this notation is an improvement because it communicates that detail to anyone interested in understanding it without adding a pile of text to all sorts of function signatures.

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

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

From report at bugs.python.org  Mon Jun  3 21:06:07 2019
From: report at bugs.python.org (Windson Yang)
Date: Tue, 04 Jun 2019 01:06:07 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
 in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1559610367.53.0.164892989515.issue15474@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Hi, Andr?s Delfino. Are you still working on it?

----------
nosy: +Windson Yang

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

From report at bugs.python.org  Mon Jun  3 21:44:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 01:44:37 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559612677.72.0.972234050603.issue37134@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

A first enhancement would be to add an index entry for "/" at:
https://docs.python.org/dev/genindex-Symbols.html

> I'll note that Googling on: "python slash in formal argument list" ...

We have to find a cute name for the "/ operator" in function definition! Like the "walrus operator" for "x := 1" :-D Nobody is able to find "/" in Google. And I'm not sure that "slash" is accurate enough, since it has multiple meaning.

----------

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

From report at bugs.python.org  Mon Jun  3 21:52:56 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 01:52:56 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559613176.0.0.465204820753.issue37134@roundup.psfhosted.org>


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

I respectfully disagree with logic, "the language now permits this, so we should change all the docs to display it everywhere".  That moves it from optional knowledge to mandatory knowledge, from a day ten lesson to a day one lesson, from "once in a while, a user may benefit from being able to mark arguments as positional-only" to the category of "every single user will see this every time they see the docs".  There is a huge difference.

My almost daily experience with end-users regarding the \ annotation has been decidedly negative.  And my experience as a professional tech writer teaches that "people will just have to figure it out" is not a phrase to live by when it comes to documentation (it is an anti-pattern).

There is no reason that we have to do this to the docs.  Please at least go with Carol's suggestion to defer all the trailing \ annotations for at least another release so that you can get more user feedback.

I know some regard The Zen of Python as just poetry, but the "readability counts" and "beautiful is better than ugly" parts mean something.  Those key attractors to the language should not be discarded lightly.

And while a blog post might be nice, the odds are that fewer than 1% of Python users will ever see it.  Python has millions of users and blog posts are rarely seen by more than tens of thousands.  Even then, blog post knowledge is transient and quickly becomes yesterday's news.  The entire notion of training away the problem is specious; you really shouldn't have to have training to read documentation.

----------

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

From report at bugs.python.org  Mon Jun  3 22:46:07 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 04 Jun 2019 02:46:07 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559616367.27.0.957650702029.issue37134@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> I respectfully disagree with logic, "the language now permits this, so we should change all the docs to display it everywhere".  That moves it from optional knowledge to mandatory knowledge, from a day ten lesson to a day one lesson, from "once in a while, a user may benefit from being able to mark arguments as positional-only" to the category of "every single user will see this every time they see the docs".  There is a huge difference.

A decent part of the reasoning for the PEP was actually to create a standard way to document when arguments to a function are positional-only. By adopting the notation (already used in the numpy documentation IIRC), it makes a concise documentation clear.

Another part of the PEP's reasoning was that this notation is difficult to understand at least partially because it is rarely encountered, so "people don't understand it" as a reason to exclude it from the documentation becomes a bit of a self-fulfilling prophecy.

I am not really an expert in documentation and front-end design, but maybe it would be possible to have some sort of unobtrusive tooltip that activates on signatures that contain positional-only arguments?

----------
nosy: +p-ganssle

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

From report at bugs.python.org  Tue Jun  4 00:20:03 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 04 Jun 2019 04:20:03 +0000
Subject: [docs] [issue21492] email.header.decode_header sometimes returns
 bytes, sometimes str
In-Reply-To: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za>
Message-ID: <1559622003.39.0.829008804188.issue21492@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If we can't fix the behavior, it should at least be documented.

Currently the docs says "This function returns a list of (decoded_string, charset) pairs containing each of the decoded parts of the header.".  One could assume that this means that a Unicode string is returned, but and as far as I can tell, "decoded_string" means decoded from the format used by the header, not from bytes -- in fact the example below shows a byte string.
#24797 suggest an alternative solution, but there is no indications about it in the docs except an easy-to-miss note about the new API at the top.

Coincidentally as I was reporting this issue I also found the recently opened #37139.  There are also a few other reports: #24797, #37139, #32975, #6302, #4661.

If this method is not actually deprecated, I would document the current behavior (i.e. sometimes it returns bytes, sometimes unicode -- bonus points if there's a simple rule to predict which one), explain that it exists for legacy/backward-compatibility reasons, and point to the alternatives.


FWIW here are 3 more samples that show the inconsistency.

>>> from email.header import decode_header
>>> # str + None
>>> h = '\x80SOKCrGxsbw===== <hello at example.com>'; decode_header(h)
[('\x80SOKCrGxsbw===== <hello at example.com>', None)]
>>> # bytes + '', bytes + None
>>> h = '=??b?SOKCrGxsbw=====?= <hello at example.com>'; decode_header(h)
[(b'H\xe2\x82\xacllo', ''), (b' <hello at example.com>', None)]
>>> # bytes + 'utf8', bytes + None
>>> h = '=?utf8?b?SOKCrGxsbw==?= <hello at example.com>'; decode_header(h)
[(b'H\xe2\x82\xacllo', 'utf8'), (b' <hello at example.com>', None)]

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti, louis.abraham at yahoo.fr
resolution: duplicate -> 
stage: resolved -> needs patch
status: closed -> open
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Jun  4 00:54:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 04:54:26 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559624066.55.0.923492034736.issue37134@roundup.psfhosted.org>


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

> Another part of the PEP's reasoning was that this notation
> is difficult to understand at least partially because it 
> is rarely encountered, so "people don't understand it" as 
> a reason to exclude it from the documentation becomes a
> bit of a self-fulfilling prophecy

We know that isn't true because people already see it frequently in the tooltips for C functions.  What I've observed is that after repeated exposures, users learn to treat it as noise and tune it out.  I've not found a single instance where a user found it to be helpful.

----------

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

From report at bugs.python.org  Tue Jun  4 01:12:00 2019
From: report at bugs.python.org (Grant Jenks)
Date: Tue, 04 Jun 2019 05:12:00 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559625120.95.0.604041061355.issue37134@roundup.psfhosted.org>


Grant Jenks <grant.jenks at gmail.com> added the comment:

FWIW, I would rather not see the docs littered with "/". I've taught Python to hundreds of professional software engineers over the last five years and in all that time nobody has ever asked when the args need to be positional. It's easy to experiment to find out and it's historically been an implementation detail. I think the number of times people are surprised is far less than the number of times people never notice at all. As Raymond described, this change will elevate the feature to a day-1 topic and it's pretty useless to a day-1 user. This is another step toward making what I see as an unfortunate implementation detail into formal semantics.

----------
nosy: +grantjenks

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

From report at bugs.python.org  Tue Jun  4 04:39:59 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 08:39:59 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559637599.29.0.153939588139.issue37145@roundup.psfhosted.org>


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

The __init__ method is public.  Here is how to use ItemsView:

>>> from collections.abc import ItemsView
>>> d = dict(python='snake', ruby='gem', go='board game', c='speed of light')
>>> iv = ItemsView(d)
>>> ('python', 'snake') in iv
True
>>> list(iv)
[('python', 'snake'), ('ruby', 'gem'), ('go', 'board game'), ('c', 'speed of light')]
>>> len(iv)
4
>>> d['python'] = 'language'
>>> list(iv)
[('python', 'language'), ('ruby', 'gem'), ('go', 'board game'), ('c', 'speed of light')]

Note, there is no direct access to _mapping.

----------

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

From report at bugs.python.org  Tue Jun  4 06:18:41 2019
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 04 Jun 2019 10:18:41 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
 in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1559643521.14.0.533601676138.issue15474@roundup.psfhosted.org>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Hi Windson Yang! Yes, I'm still working on it. I'll have it ready by the end of June.

----------

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

From report at bugs.python.org  Tue Jun  4 07:09:30 2019
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Tue, 04 Jun 2019 11:09:30 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559646570.89.0.961776035166.issue37145@roundup.psfhosted.org>


Geoffrey Sneddon <geoffers+pythonbugs at gmail.com> added the comment:

Then I guess what I consider a bug is "__init__ is undocumented".

----------

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

From report at bugs.python.org  Tue Jun  4 07:59:26 2019
From: report at bugs.python.org (Guilloux)
Date: Tue, 04 Jun 2019 11:59:26 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
Message-ID: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>


New submission from Guilloux <bugs.python.org at guilloux-fr.net>:

On the page https://docs.python.org/3/library/tkinter.html
there is a link to "Tkinter reference: a GUI for Python" which is "https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html".

BIG PROBLEM : Since several days this link doesn't work any more !!!

It's really important to fix it because most of official online documentation about tkinter was provided by this way !!!

Fortunately i have a copy of the documentation (cf pdf file). I have downloaded this file thanks to the website above just before the link was failed ! (Yes, i know, i'm lucky...)

Unfortunately I can't send you this pdf because I have a message "request entity too large" :-(

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 344549
nosy: docs at python, xameridu
priority: normal
severity: normal
status: open
title: link to official documentation tkinter failed  !!!
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jun  4 08:00:27 2019
From: report at bugs.python.org (Guilloux)
Date: Tue, 04 Jun 2019 12:00:27 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559649627.89.0.733806384821.issue37149@roundup.psfhosted.org>


Guilloux <bugs.python.org at guilloux-fr.net> added the comment:

On the page https://docs.python.org/3/library/tkinter.html
there is a link to "Tkinter reference: a GUI for Python" which is "https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html".

BIG PROBLEM : Since several days this link doesn't work any more !!!

It's really important to fix it because most of official online documentation about tkinter was provided by this way !!!

Fortunately i have a copy of the documentation (cf pdf file). I have downloaded this file thanks to the website above just before the link was failed ! (Yes, i know, i'm lucky...)

----------

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

From report at bugs.python.org  Tue Jun  4 08:06:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Jun 2019 12:06:34 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559649994.81.0.98312190446.issue37149@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

A copy of the URL is present in archive.org [0] . Perhaps the docs could be updated with it.


[0] https://web.archive.org/web/20190524140835/https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html

----------
nosy: +xtreak
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Jun  4 08:11:54 2019
From: report at bugs.python.org (Guilloux)
Date: Tue, 04 Jun 2019 12:11:54 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559650314.02.0.960487036883.issue37149@roundup.psfhosted.org>


Guilloux <bugs.python.org at guilloux-fr.net> added the comment:

The comment of Karthikeyan Singaravelan seems to be a good idea.

Question : is it possible to send a pdf (2.08 MB) to the python tracker ?

----------

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

From unitedclean04 at hotmail.com  Tue Jun  4 08:40:24 2019
From: unitedclean04 at hotmail.com (tom milikic)
Date: Tue, 4 Jun 2019 12:40:24 +0000
Subject: [docs] Fw: Download issues for Python
In-Reply-To: <DM6PR06MB51303BAC98DC82CFD37FAEA0A9150@DM6PR06MB5130.namprd06.prod.outlook.com>
References: <DM6PR06MB513091104FE5FB2DAE7E15F5A9150@DM6PR06MB5130.namprd06.prod.outlook.com>,
 <DM6PR06MB51303BAC98DC82CFD37FAEA0A9150@DM6PR06MB5130.namprd06.prod.outlook.com>
Message-ID: <DM6PR06MB5130D74DE1559BE50E6C8E6AA9150@DM6PR06MB5130.namprd06.prod.outlook.com>


Hi my name is Tom and I come from Brisbane in Australia.  I cannot seem to download Python on my computer as I really need it to help with my Quantitative Finance studies.  It seems to say that some program is missing from my computer?  What do I do? I am running Windows and a Toshiba computer. I have looked in the help section and I still cant seem to fix or find the issue with why it is not downloading onto my computer?

It states that this is missing from my computer -:

api-ms-win-crt-runtime-l1-1-0.dl

Also Python 3.7.2 and Python 3.7.3 appear in my download folders but when I click them nothing happens?

If you can help would be much appreciated

Thanks
Tom


[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>  Virus-free. www.avast.com<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190604/f7885c1a/attachment-0001.html>

From julien at palard.fr  Tue Jun  4 08:50:21 2019
From: julien at palard.fr (Julien Palard)
Date: Tue, 04 Jun 2019 12:50:21 +0000
Subject: [docs] Fw: Download issues for Python
In-Reply-To: <DM6PR06MB5130D74DE1559BE50E6C8E6AA9150@DM6PR06MB5130.namprd06.prod.outlook.com>
References: <DM6PR06MB513091104FE5FB2DAE7E15F5A9150@DM6PR06MB5130.namprd06.prod.outlook.com>
 <DM6PR06MB51303BAC98DC82CFD37FAEA0A9150@DM6PR06MB5130.namprd06.prod.outlook.com>
 <DM6PR06MB5130D74DE1559BE50E6C8E6AA9150@DM6PR06MB5130.namprd06.prod.outlook.com>
Message-ID: <mkijAVSezjPX8LpwjA75Zh6r09WPsyQJ0XQczbiErrvKKXsQbPT09x1a894tepEzhsaG2nlsHOQjJyRYK2mLRcsQ65Iy9Tf84wgQxiF5Si4=@palard.fr>

Hi Tom, I don't get why you mailed legal at python.org and jobs at python.org on this issue... the Python ecosystem run on voluntary workers time and you just took the time of at least 5 of us, this won't help.

> I cannot seem to download Python on my computer

As we're on the documentation mailing list: have you read this part of the documentation: https://docs.python.org/3/using/windows.html?

Bests,
--?
Julien Palard
https://mdk.fr



From julien at palard.fr  Tue Jun  4 09:29:48 2019
From: julien at palard.fr (Julien Palard)
Date: Tue, 04 Jun 2019 13:29:48 +0000
Subject: [docs] Embedding Python in Another Application tutorial problem
In-Reply-To: <SN4PR0201MB35528CAC8A2666ED8B66D826D3190@SN4PR0201MB3552.namprd02.prod.outlook.com>
References: <SN4PR0201MB35528CAC8A2666ED8B66D826D3190@SN4PR0201MB3552.namprd02.prod.outlook.com>
Message-ID: <SdmXE7nV-FflWNX1a4rDjZYbLmcfXLO7ZIsLLYMaBPz8v8vGJ4uyyH_dxTUe0nHLnwYyKAMy_8ppZMwLhDedkKJ0cUmU803NdNyOi6hHrCk=@palard.fr>

Hi Jesse,

>  #include <Python.h>
>                     ^
> compilation terminated.

I'm not a centos user, and the message is very short, but I bet you've not installed the Python headers. It may be provided in a package like "python3-dev" (at least in Debian it's how it's called).

It's probably not the right mailing list to ask for help though, as it does not look like a documentation issue, maybe try https://mail.python.org/mailman/listinfo/python-help?

Bests,
--?
Julien Palard
https://mdk.fr



From report at bugs.python.org  Tue Jun  4 11:18:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 15:18:17 +0000
Subject: [docs] [issue30699] Misleading class names in datetime.tzinfo usage
 examples
In-Reply-To: <1497824156.09.0.152108719585.issue30699@psf.upfronthosting.co.za>
Message-ID: <1559661497.52.0.513611841609.issue30699@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f0b5ae4567637b24035ecda93a3240efc96b6dd9 by Victor Stinner (Mario Corchero) in branch 'master':
bpo-30699: Improve example on datetime tzinfo instances (GH-4290)
https://github.com/python/cpython/commit/f0b5ae4567637b24035ecda93a3240efc96b6dd9


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

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

From report at bugs.python.org  Tue Jun  4 11:18:37 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Jun 2019 15:18:37 +0000
Subject: [docs] [issue30699] Misleading class names in datetime.tzinfo usage
 examples
In-Reply-To: <1497824156.09.0.152108719585.issue30699@psf.upfronthosting.co.za>
Message-ID: <1559661517.09.0.429689149824.issue30699@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13697
pull_request: https://github.com/python/cpython/pull/13811

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

From report at bugs.python.org  Tue Jun  4 11:25:20 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 04 Jun 2019 15:25:20 +0000
Subject: [docs] [issue30699] Misleading class names in datetime.tzinfo usage
 examples
In-Reply-To: <1497824156.09.0.152108719585.issue30699@psf.upfronthosting.co.za>
Message-ID: <1559661920.42.0.525527111718.issue30699@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 12c178799a23b47c5f8ebc072cbdf09a370649ae by Miss Islington (bot) in branch '3.7':
bpo-30699: Improve example on datetime tzinfo instances (GH-4290)
https://github.com/python/cpython/commit/12c178799a23b47c5f8ebc072cbdf09a370649ae


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jun  4 11:29:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 15:29:34 +0000
Subject: [docs] [issue30699] Misleading class names in datetime.tzinfo usage
 examples
In-Reply-To: <1497824156.09.0.152108719585.issue30699@psf.upfronthosting.co.za>
Message-ID: <1559662174.1.0.00318660985434.issue30699@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Mario Corchero for the doc enhancement, and Paul for the review!

Python 2.7 is not affected: datetime has no timeinfo class.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.6

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

From report at bugs.python.org  Tue Jun  4 13:18:28 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 17:18:28 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559668708.35.0.945132415815.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank you, everyone, for expressing clearly your different opinions and concerns. Without disregarding any of the
arguments so far I want to make some further clarifications on some points and why I still think this is important.

> FWIW, I would rather not see the docs littered with "/".

Although I assume there is not the intention, there is absolutely no reason to be disrespectful to the people that
think otherwise. You can express the same idea without implying that the feature is "litter". The same thing applies
to "unfortunate implementation" in another of the sentences that was used.

> This is another step toward making what I see as an unfortunate implementation detail into formal semantics.

The feature has as much formal semantics as it is possible already: is an official part of the language.

One of the things the PEP makes a lot of emphasis is the current status of the feature and how users see the syntax
is precisely caused because of a lack of documentation, exposition and ultimately (and very important) because it was
not valid Python syntax. The fact that many people were thinking that is a typo in the documentation or "noise" is precisely
because of this and I think having it in the docs is crucial for discovery.

Regarding the usefulness of having the syntax for users: is exactly as useful as knowing that some arguments are keyword-only
and those are documented and we did not have any discussion about this. One can disagree and argue that the usefulness of the
feature, when some users consider implementing functions that use both syntaxes, is much different between positional-only and
keyword-only and that one solve more common problems that the other, but that is irrelevant for people reading the documentation:
the relevant thing is that they tell you the restrictions when calling an existing function. And at that point, it does not matter
how common something is or how common is fall into the error condition. Also, take into account that there is a serious difference
between teaching someone how to react to the syntax (you cannot use keyword parameters for these arguments), which is done almost
immediately, and teaching someone when they want to use the syntax themselves on their function. And I want to make clear that I
acknowledge that there is a cognitive burden because there are more cases to remember.

I think documenting the trailing "/" is especially important because now users will find very confusing the fact that functions
only document the "/" in some places. They may start to believe that a trailing "/" is illegal syntax or that the "/" at the end
is optional. This will lead to even more confusion IMHO. This will also perpetuate another thing that the PEP put a lot of focus
on solving, which is removing the dissonance between the signature that appears in the documentation, the one in the help() and docstrings
and the one that inspect.signature will return. Precisely failing to document all cases will make this even more confusing and will severely
alter and bias any feedback that users could provide about any related aspect.

It is possible that some users were thinking that the bare "*" for keyword-only arguments was a typo when it was introduced and maybe
they were thinking that the author meant "*args", but we can all agree that that was not a problem. I don't see why this syntax needs
to have special treatment regarding that. Another sentence of the ZEN of Python reads "Special cases aren't special enough to break the rules"
and the rules at to this point is that there were absolutely no restrictions regarding using new syntax or terminology in the documentation.

I understand the concerns and I take them into account, but for these reasons together with what other core devs are exposing, I think this
syntax should be included into the documentation (including trailing "/") as this was one core motivation for the PEP.

----------

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

From report at bugs.python.org  Tue Jun  4 13:47:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 17:47:39 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559670459.35.0.826268802239.issue37145@roundup.psfhosted.org>


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

> Then I guess what I consider a bug is "__init__ is undocumented".

No, this just how Python works.

----------

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

From report at bugs.python.org  Tue Jun  4 13:52:37 2019
From: report at bugs.python.org (Carol Willing)
Date: Tue, 04 Jun 2019 17:52:37 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559670757.27.0.413115325353.issue37134@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

I echo Pablo's comment about thoughtful discourse as this is discussed.

For library maintainers that are writing APIs that involve workflows across multiple projects maintained by different people, better information and documentation is very important.

We are balancing the needs of different user groups. An all or nothing approach to documenting / and positional only arguments will not serve the different groups well. What will serve them is coming up with an approach that will work (though not perfectly) for each group. In essence, balancing and compromising are critical.

I suggested an approach earlier which I would appreciate folks give a closer look to its merit.

----------

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

From report at bugs.python.org  Tue Jun  4 13:56:06 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 17:56:06 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559670966.97.0.567285398577.issue37145@roundup.psfhosted.org>


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

Hit <submit> too early.

In Python, the norm is that the class name is documented.  When you call the class, the __init__() method gets called automatically (as documented in the language reference and in the tutorial).

For example:

    >>> class A:
            def __init__(self, seq):
                    self._seq = seq
            def __len__(self):
                    return len(self._seq)
      
    >>> a = A('apple')
    >>> len(a)	  
    5

In this example, we document that class "A" can be called with a sequence and that len() can be called on instances of A.  The "dunder" methods are public, but are called and documented indirectly.  The "_seq" attribute is marked as private and would not be documented, since it is an implementation detail and not intended to be accessed directly.

----------

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

From report at bugs.python.org  Tue Jun  4 14:03:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 18:03:43 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559671422.98.0.374316766581.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank you Carol for your comment! Regarding your proposal, I find it it attractive as a compromise in order to make more gentle the introduction of the feature to users. I really appreciate the effort to balance all the different aspects and concerns.

Ccould you extend your thoughts regarding this concern that I have with respect of not including the trailing / in 3.8 but doing it in 3.9:

>I think documenting the trailing "/" is especially important because now users will find very confusing the fact that functions
only document the "/" in some places. They may start to believe that a trailing "/" is illegal syntax or that the "/" at the end
is optional. This will lead to even more confusion IMHO.

Another minor concern that I have is the fear that we will have a similar discussion in the future when the PR adding the trailing / to 3.9 would be added.

----------

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

From report at bugs.python.org  Tue Jun  4 14:35:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 04 Jun 2019 18:35:54 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559673354.35.0.159261843439.issue37149@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Tue Jun  4 15:19:55 2019
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Tue, 04 Jun 2019 19:19:55 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559675995.93.0.709312136732.issue37145@roundup.psfhosted.org>


Geoffrey Sneddon <geoffers+pythonbugs at gmail.com> added the comment:

You've missed my point: the arguments that MappingView.__init__ takes are undocumented. Nowhere mentions class MappingView(mapping), as I would expect from how initializers are documented elsewhere.

----------

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

From report at bugs.python.org  Tue Jun  4 15:20:29 2019
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Tue, 04 Jun 2019 19:20:29 +0000
Subject: [docs] [issue37145] collections.abc.MappingView mixins rely on
 undocumented _mapping
In-Reply-To: <1559580516.49.0.942559591286.issue37145@roundup.psfhosted.org>
Message-ID: <1559676029.9.0.23435885467.issue37145@roundup.psfhosted.org>


Geoffrey Sneddon <geoffers+pythonbugs at gmail.com> added the comment:

Like, where in the documentation can I learn that MappingView's initializer takes an argument "mapping"?

----------

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

From report at bugs.python.org  Tue Jun  4 16:39:03 2019
From: report at bugs.python.org (Brian Skinn)
Date: Tue, 04 Jun 2019 20:39:03 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559680743.92.0.0474131225422.issue37134@roundup.psfhosted.org>


Change by Brian Skinn <bskinn at alum.mit.edu>:


----------
nosy: +bskinn

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

From report at bugs.python.org  Tue Jun  4 17:01:21 2019
From: report at bugs.python.org (Carol Willing)
Date: Tue, 04 Jun 2019 21:01:21 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559682081.77.0.399531463004.issue37134@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

> Could you extend your thoughts regarding this concern that I have with respect of not including the trailing / in 3.8 but doing it in 3.9:

Pablo, Sure thing. I believe that a Sphinx extension (possibly existing sphinx-tabs as suggested by @bskinn in the Steering Council issue or one we develop/find) could give us both a "technically accurate" view and "simplified" view. I wasn't sure if this could/would be ready by 3.8. But I think that it is feasible for 3.9. If we can do it for 3.8, fantastic.

If we do the 3.8/3.9 phased approach, I definitely think the 3.8 docs need to be explicit in stating the what/why/when of the / (still searching for a cute name - right now the best I have is "twig" from another name, virgule, for slash and its Latin derivation). Ultimately, 3.9 should either by Sphinx extension or edit contain the "technically accurate" version.

----------

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

From report at bugs.python.org  Tue Jun  4 17:24:11 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 04 Jun 2019 21:24:11 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
 in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1559683451.88.0.863042129378.issue15474@roundup.psfhosted.org>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If you want some early feedback I believe you can already create a PR and mark it as work-in-progress/don't-merge.

If you need some material you can find the slides of a talk about decorators that I did at
https://www.pycon.it/media/conference/slides/understanding-decorators.pdf
Feel free to take from it whatever you need :)

----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jun  4 17:28:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 21:28:08 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559683688.64.0.720557853959.issue37134@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python has many parameter types: positional-only, positional-or-keyword, keyword only, etc. Even if we don't add "/", it would be nice to have hints when we put the mouse cursor on a function parameter.

Something like:

function: demo(arg1, *, arg2, arg3=None)

arg1 hint: *arg1* is the first mandatory parameter (kind: positional-or-keyword)
arg2 hint: *arg2* is the second mandatory parameter (kind: keyword-only)
arg3 hint: *arg3* is an optional parameter (default: ``None``, kind: keyword-only)

Maybe we can also add hints on '*':

* hint: Marker for keyword-only parameter

... I have no idea how complex it would be to implement such Sphinx extenstion, or maybe even implement it in Sphinx.

----------

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

From report at bugs.python.org  Tue Jun  4 17:29:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 21:29:39 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559683778.99.0.140892804306.issue37134@roundup.psfhosted.org>


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

I don't think inclusion in 3.9 should be automatic.  

The purpose of the deferment is to evaluate the premise, "the only reason people have found this notation confusing was that it wasn't yet valid syntax available for use in their own code."  If that premise turns out to be false, we should think seriously about whether this makes the docs less approachable for everyday users.

This extensive edit of the docs will change the appearance and texture of language from day 1 of a person's exposure to the language.  It warrants careful consideration of the costs and benefits.  Despite what we might wish to be true, the cost side of the equation is definitely not zero.

----------

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

From report at bugs.python.org  Tue Jun  4 17:33:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 21:33:06 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559683986.67.0.189124661675.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Pablo, Sure thing. I believe that a Sphinx extension (possibly existing sphinx-tabs as suggested by @bskinn in the Steering Council issue or one we develop/find) could give us both a "technically accurate" view and "simplified" view. I wasn't sure if this could/would be ready by 3.8. But I think that it is feasible for 3.9. If we can do it for 3.8, fantastic.

Thanks for the quick response and for clarifying that. This looks like a very interesting approach. Would the "simplify" view remove keyword-only argument markers as well? What other features should be hidden in this simplified view?

----------

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

From report at bugs.python.org  Tue Jun  4 17:42:32 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 21:42:32 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559684552.63.0.0326018985757.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>  If that premise turns out to be false, we should think seriously about whether this makes the docs less approachable for everyday users.

We have not done such a thing for any other feature of the language. I think that since this is now a part of the language, it has all the right to be part of the documentation (possibly in some phased process). The contrary will be extremely unfair to the feature and to the PEP process: not a single other case had to fight separately to be included in the language and the documentation. 

And we even have an analogous case: keyword-only argument.

----------

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

From report at bugs.python.org  Tue Jun  4 17:57:29 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 04 Jun 2019 21:57:29 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559685449.2.0.451931870406.issue37134@roundup.psfhosted.org>


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

Language features don't have rights.  People do.  :-)

FWIW, there is precedent.  We have type annotations in the language but don't use them throughout the docs.

In the end, all that matters is usability. If a notion fails a usability test, then we should adapt accordingly.

When it comes to documentation, we also try to minimize how much a person needs to know in order a mentally parse a piece in isolation.  That is a core principle of documentation (the MS Excel docs are an excellent example; a counter-example is Wikipedia's use of the IPA pronunciation notation which is technically superior but is only readable/usable by very few of the readers.).  

P.S. I hope you don't come to personally identify with this patch. I'm a big admirer of your work and am already promoting the feature to my 50,000+ twitter follows.  In this tracker issue, I hope for us a have a dispassionate, honest evaluation of what makes for the best documentation of the language.

----------

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

From report at bugs.python.org  Tue Jun  4 18:09:49 2019
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 04 Jun 2019 22:09:49 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
 in docs
In-Reply-To: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>
Message-ID: <1559686189.76.0.809272589192.issue15474@roundup.psfhosted.org>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Great! I'll definitely give it a look.

I prefer not to make a PR until everything is in its place. You can check the status though:

https://github.com/andresdelfino/cpython/tree/decorators-howto

Fred was very helpful with his insight :)

----------

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

From report at bugs.python.org  Tue Jun  4 18:18:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 22:18:05 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559686685.42.0.60727023241.issue37134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords:  -easy
title: [EASY] Use PEP570 syntax in the documentation -> Use PEP570 syntax in the documentation

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

From report at bugs.python.org  Tue Jun  4 18:19:51 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 22:19:51 +0000
Subject: [docs] [issue37134] [EASY] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559686791.66.0.0591085607455.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> FWIW, there is precedent.  We have type annotations in the language but don't use them throughout the docs.

Although there is some distance between both cases, I think this is an extremely good point to take into account that I have not thought about.

> P.S. I hope you don't come to personally identify with this patch. I'm a big admirer of your work and am already promoting the feature to my 50,000+ twitter follows.  In this tracker issue, I hope for us a have a dispassionate, honest evaluation of what makes for the best documentation of the language.

Not at all :). I will be happy whatever solution we end agreeing to, knowing that we are going through a very thorough discussion. But thank you very much for stopping the discussion to check. I actually apologize if any of my responses have been more passionate than it should have been. I (really!) appreciate your words here and the fact that even if you disagree with this change and the cost of the feature regarding the advantages, you are making a lot of effort to explain the feature to users. Thank you very much for caring about the language, users and having a healthy and productive discussion.

----------
keywords: +easy
title: Use PEP570 syntax in the documentation -> [EASY] Use PEP570 syntax in the documentation

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

From report at bugs.python.org  Tue Jun  4 18:20:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 04 Jun 2019 22:20:06 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559686806.18.0.127849732683.issue37134@roundup.psfhosted.org>


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


----------
title: [EASY] Use PEP570 syntax in the documentation -> Use PEP570 syntax in the documentation

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

From report at bugs.python.org  Tue Jun  4 18:48:25 2019
From: report at bugs.python.org (Julien Palard)
Date: Tue, 04 Jun 2019 22:48:25 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559688505.22.0.668817709249.issue37134@roundup.psfhosted.org>


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

FWIW here's my feedback (as a Python teacher and doc guy):

I find that newcomers are good to ignore what they don't understand, so a newcomer exposed to "foo(a, b, /)" will no run away nor cry, he will just ignore the slash and understand that "foo takes two parameters, a and b" and be happy with it.

Then I think that for more advanced people it's nice to have it:

- It's a way to discover it's a valid syntax
- It's a usefull information to use
- It does not take a lot of space
- It's the truth (I mean, displaying "foo(a, b)" for "foo(a, b, /)" is a kind of a lie, I don't like it)

So I'm +1 for using PEP570 syntax in the documentation.

----------
nosy: +mdk

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

From report at bugs.python.org  Tue Jun  4 19:10:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Jun 2019 23:10:35 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559689835.34.0.906374215653.issue37134@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Tim Peters: "I haven't looked at anything in this PR, so just popping in to confirm that the first time I saw stuff like: len(obj, /) in the docs I had no idea at all what it was trying to say.  I thought it was a typo. (...)"

Carol Willing: "I confess that I had a similar reaction as Tim when I saw functions with a trailing `/`."

I'm quite sure that many users have same reaction the first time they meet "@decorator", "*args", "def func(*, arg)", etc. PEP 570 introduces a syntax which was still illegal in Python 3.7, so it's normal to be surprised when we meet a new syntax.

In a few years, people will be used to that, but will be surprised by yet another new syntax ;-)

The best we can do is to enhance the documentation to properly document "/", directly in the reference documentation. Sphinx is a great help to add links. And we can maybe extend Sphinx to add even more inline hints.

--

The "/" character was discussed in length in the PEP 570. Many people complained... but nobody succeed to came up with a better syntax. The PEP has been accepted and its now part of the *Python language*.

As explained in length in the PEP 570, the "/" syntax is *not* new. For example, it is used for years in Python docstrings. Paul Ganssle also mentioned that this notation is "already used in the numpy documentation IIRC".

--

I don't think that we must hide some syntax like "*args" or "def func(*, arg)" from the doc, just because people learning Python might be surprised at the first read. I don't think that the reference documentation should be used to learn Python. They are way better resources than that to learn Python. Moreover, it's not really written like a tutorial. We have some https://docs.python.org/dev/howto/ for that.

>From my point of view, the *reference* documentation is more used by people who are already used to Python and so know the Python syntax. Trying to hide the real API in the *reference* documentation sounds weird (wrong) to me. The doc should document the real behavior. The PEP 570 makes is possible, whereas previously, the doc was lying.

If you consider that "len(obj, /)" is a typo, maybe we must fix len to accept obj as a keyword parameter? But they are good reasons why it's a positional only parameter. I don't think that anyone wants to change that. The current trend is more the opposite: convert some positional-or-keyword parameters to positional-only parameters, especially for functions taking a single parameter.

In short, I concur with Brett who wrote:

> Anyway, from my personal view, I think we should use the syntax. It's officially part of the language at this point and so avoiding it in the docs seems odd, like we're saying that we're ashamed of this syntax and you should pretend it doesn't exist when it does and it isn't going anywhere. Otherwise aren't we're forcing users to realize that the function definition in the docs deviates from what is definable in this one instance and that one has to read the full text to know that something is doable syntactically but we're leaving it out of the docs? It adds inconsistency in what the definition line means IMO based on how we have usually chosen to try and express things in that 'def' line in the docs as succinctly as possible to communicate the semantics of calling that function.

--

By the way, PR 13743 doesn't modify every single function of the documentation. Only a few files are modified, simply because only few functions accept positional-only parameters. My expectation is more that nobody will notice :-)

----------
keywords:  -easy
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Wed Jun  5 00:38:46 2019
From: report at bugs.python.org (Grant Jenks)
Date: Wed, 05 Jun 2019 04:38:46 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559709526.92.0.659971555285.issue37134@roundup.psfhosted.org>


Grant Jenks <grant.jenks at gmail.com> added the comment:

Pablo, I never intended disrespect toward you personally. And I am sorry my words came across that way. I would rather the feature be one of Python's more esoteric qualities.

I think Carol has described the most reasonable way forward. And in particular, I like this creative idea:

> A Sphinx extension may also be made to show a simple user-friendly view and with a click the fully accurate view.

I agree too with Raymond in this point:

> I don't think inclusion in 3.9 should be automatic.

As anecdata: I showed the PEP and feature to an intermediate class of 15 professional software engineers today. The first question I got was, "when should I use that in my Python code?" And I think the answer is rarely. We reviewed the motivating cases in the PEP and those made sense to them. But I was left feeling concern that if it were prominent and frequent in the docs then people will be likely to imitate, not least of which through simple copy/paste, what they see there without understanding the C-API and why it is that way.

----------

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

From report at bugs.python.org  Wed Jun  5 01:45:57 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Jun 2019 05:45:57 +0000
Subject: [docs] [issue36373] Deprecate explicit loop parameter in all public
 asyncio APIs
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1559713557.76.0.815910367205.issue36373@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6d64a8f49eb321116f585c4b036c81bb976d2d5c by Miss Islington (bot) (Emmanuel Arias) in branch 'master':
bpo-36373:  Deprecate explicit loop parameter in all public asyncio APIs [streams] (GH-13671)
https://github.com/python/cpython/commit/6d64a8f49eb321116f585c4b036c81bb976d2d5c


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jun  5 01:46:20 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Jun 2019 05:46:20 +0000
Subject: [docs] [issue36373] Deprecate explicit loop parameter in all public
 asyncio APIs
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1559713580.24.0.985674768604.issue36373@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13712
pull_request: https://github.com/python/cpython/pull/13833

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

From report at bugs.python.org  Wed Jun  5 02:01:04 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Jun 2019 06:01:04 +0000
Subject: [docs] [issue36373] Deprecate explicit loop parameter in all public
 asyncio APIs
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1559714464.77.0.960507449925.issue36373@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8899b11b95f08e2e03478f2acad336ad5933a2d1 by Miss Islington (bot) in branch '3.8':
bpo-36373:  Deprecate explicit loop parameter in all public asyncio APIs [streams] (GH-13671)
https://github.com/python/cpython/commit/8899b11b95f08e2e03478f2acad336ad5933a2d1


----------

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

From report at bugs.python.org  Wed Jun  5 02:44:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Jun 2019 06:44:27 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559717067.0.0.0978745635766.issue37134@roundup.psfhosted.org>


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

You need to use the PEP 570 syntax if your function/method have a var-keyword parameter, takes arbitrary keyword arguments, and has other parameters beside the var-keyword parameter ("self" counts). And of course the minimal supported Python version should be 3.8.

In PR 13700 the PEP 570 syntax was added in the documentation of functions that use it in the code (like partial() and getcallargs()) and also in the examples of user code where it is needed (like LRU, Callback and Namespace).

PR 13743 adds it the documentation of functions which do not accept arbitrary keywords, but take some of arguments as positional only and others as positional or keyword. It may be surprising, so I think it is better to document this explicitly.

----------

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

From report at bugs.python.org  Wed Jun  5 03:39:45 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 05 Jun 2019 07:39:45 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
 (or operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1559720385.55.0.532067464244.issue17576@roundup.psfhosted.org>


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

Mark, I think you can reopen the PR and merge it in 3.9 now.

As for my proposition to use the FutureWarning first, I think it is not necessary. The behavior change is very subtle and will affects only int subclasses with overridden __index__. Similar changes (preferring __index__ over __int__) have been made in 3.8 without preceding FutureWarning. And similar minor changes were made in the past.

On other hand, I am not sure that __index__ should be used for int subclasses. We already have the int content, so we can create an exact int with _PyLong_Copy().

----------

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

From report at bugs.python.org  Wed Jun  5 08:42:33 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 05 Jun 2019 12:42:33 +0000
Subject: [docs] [issue36675] Doctest directives and comments missing from
 code samples
In-Reply-To: <1555757030.56.0.8094269644.issue36675@roundup.psfhosted.org>
Message-ID: <1559738553.4.0.370627563313.issue36675@roundup.psfhosted.org>


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

;tldr;   There is a global configuration flag to show all the doctest directives for all the docs that are built.  The default is to suppress the doctest directives.  If a global setting isn't desired, then each doctest example will have to be changed individually.


I've looked at the Sphinx documentation for this and there are a few points to reference. 

* `::` defines a Literal block in reST. [1]  A literal block doesn't do anything special except from the last paragraph is this section of the docs: 
   "Code highlighting can be enabled for these literal blocks on a document-wide basis using the `highlight` directive and on a project-wide basis using the `highlight_language` configuration option. The code-block directive can be used to set highlighting on a block-by-block basis. These directives are discussed later."  CPython has the `highlight-language` set to python3.  

* A doctest block does not need to be in a Literal Block. [2]  They are identified automatically. [3]  According to the doc, doctest directives are suppressed from presentation:

    Also, you can give inline doctest options, like in doctest:

    >>> datetime.date.now()   # doctest: +SKIP
    datetime.date(2008, 1, 1)

    They will be respected when the test is run, but stripped from presentation output.

* Any section (doesn't need the single colon (`:`) can have the `code-block` directive on it. [4]  The `code-block` directive can define the language for highlighting.  

Note that in the Sphinx doctest [4] documentation, there is a config option `trim_doctest_flags`, which is True by default.  Setting this to False will show all the doctest directives for all the doctests in the documentation.

The nice thing about the doc build recognizing a section as a doctest is that it adds the toggle in the upper right of the block to 'Hide the toggle and output' so that the example can be copy and pasted more easily.  Changing it into something other than a doctest (like using a `code-block` directive, takes away this option.  Using `trim_doctest_flags=False` retains the hide button.

Options:
1.  Change global setting to false to show all doctest directives.
2.  Change only the blocks where the doctest directives need to be shown, but this makes them lose the 'Hide prompt and output' button.
3.  Add a new option under 'code-block' to control the displaying of the doctest directives at the code-block level. This would override the global setting.  I think this option could be added locally, but may need to be done upstream in Sphinx.



[1] http://www.sphinx-doc.org/en/stable/usage/restructuredtext/basics.html#literal-blocks
[2] http://www.sphinx-doc.org/en/stable/usage/restructuredtext/basics.html#doctest-blocks
[3] http://www.sphinx-doc.org/en/stable/usage/extensions/doctest.html
[4] http://www.sphinx-doc.org/en/stable/usage/restructuredtext/directives.html#showing-code-examples

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Wed Jun  5 09:19:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 05 Jun 2019 13:19:44 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559740784.84.0.097752741837.issue37149@roundup.psfhosted.org>


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

This reference was hosted at a university called New Mexico Tech.  I've been trying to determine if this server is just offline or if it's being sunsetted.  Many google search results still point to infohost.mnt.edu or redirect to that page (not just the tkinter link).  Also, their main webpage (www.nmt.edu) also has a search that redirects results to infohost, so those links are all broken as well.

It seems to me that they just haven't stood up the new site yet or else they haven't changed their redirect, so I would assume that once they find they have broken links, they will fix this.  However, I also found an article that the creator of the tkinter docs has passed away [1].  If the infohost subdomain was his, then they might be moving all of it.

Anyway, I think we should leave the docs as they are for now with the hope they the university will fix the redirect.  If it doesn't get resolved, then we probably need to reach out to them.  Since the author is deceased, I'm not sure how it would work to try to host it somewhere else.  It would be a shame to lose this valuable reference and work.

[1] https://www.nmt.edu/news/2019/nmt_dedicates_shipman_plaque.php

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Wed Jun  5 10:22:27 2019
From: report at bugs.python.org (Guilloux)
Date: Wed, 05 Jun 2019 14:22:27 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559744547.96.0.269773967492.issue37149@roundup.psfhosted.org>


Guilloux <bugs.python.org at guilloux-fr.net> added the comment:

I have read Cheryl Sabella's comment. So I have sent this e-mail :

Objet:	Request about a broken link on your website.
Date:	2019-06-05 16:20
De:	xavier at guilloux-fr.net
?:	thomas.guengerich at nmt.edu, webmaster at nmt.edu, help at nmt.edu


Hello,

For several days the link "https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html" has stopped working. But this link provided access to a prodigious technical documentation related to a Python language module (tkinter).

Can you put this link back in working order (or place a redirect to the new link)?

I draw your attention to the fact that this documentation contributes significantly to the international recognition of your university.

Thanks a lot for the continuation that you will give to this request.

Regards.

Xavier Guilloux.

(following is the same message but in my natural language - French -)

Bonjour,

Depuis plusieurs jours le lien "https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/index.html" ne fonctionne plus. Or ce lien permettait d'acc?der ? une prodigieuse documentation technique en rapport avec un module du langage Python (tkinter).

Pouvez-vous remettre ce lien en ?tat de fonctionnement (ou placer une redirection vers le nouveau lien) ?

J'attire votre attention sur le fait que cette documentation contribue de mani?re importante ? la reconnaissance internationale de votre universit?.

Merci par avance pour la suite que vous donnerez ? cette requ?te.

Cordialement.

Xavier Guilloux.

----------

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

From report at bugs.python.org  Wed Jun  5 10:41:10 2019
From: report at bugs.python.org (Guilloux)
Date: Wed, 05 Jun 2019 14:41:10 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559745670.65.0.646719479373.issue37149@roundup.psfhosted.org>


Guilloux <bugs.python.org at guilloux-fr.net> added the comment:

I have received the answer :

Objet:	Re: Request about a broken link on your website.
Date:	2019-06-05 16:39
De:	New Mexico Tech <help at nmt.edu>
?:	xavier at guilloux-fr.net
Cc:	thomas.guengerich at nmt.edu, webmaster at nmt.edu



Hello,
Unfortunately infohost.nmt.edu has been shut down and we will no longer be supporting that website. The website will not be coming back up. Sorry for the inconvenience.  

-Dorothy 

ITC-UC
NMIMT
Socorro, NM 87801
575-835-5700

----------

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

From report at bugs.python.org  Wed Jun  5 11:46:19 2019
From: report at bugs.python.org (Brian Skinn)
Date: Wed, 05 Jun 2019 15:46:19 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559749579.78.0.427145892824.issue37134@roundup.psfhosted.org>


Brian Skinn <bskinn at alum.mit.edu> added the comment:

First, for anyone interested, there are screenshots and links to docs versions at the SC GH issue (https://github.com/python/steering-council/issues/12#issuecomment-498856524, and following) where we're exploring what the tabbed approach to the PEP570 docs might look like.

Second, I'd like to suggest an additional aspect of the docs situation for consideration.

Regardless of which specific approach is decided upon here, it seems likely the consensus will be a course of action requiring touching the majority (entirety?) of the stdlib API docs. Currently, all of the API docs are manually curated in the .rst, at minimum for the reasons laid out by Victor in bpo25461 (https://bugs.python.org/issue25461#msg253381). If there's any chance that the balance of factors has changed such that using autodoc (or similar) *would* now be preferable, IWSTM that now is a good time to have that discussion, so that an autodoc conversion could be done at the same time as the PEP570 rework.

----------

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

From report at bugs.python.org  Wed Jun  5 13:35:47 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 05 Jun 2019 17:35:47 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559756147.05.0.127952475429.issue37134@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

To help short-circuit this discussion and focus on the desired solution, the steering council came to a decision that can be seen at https://github.com/python/steering-council/issues/12#issuecomment-498874939 :

- for Python 3.8 specifically, we think it makes sense to continue to leave the slashes out of the documentation for the all parameters are positional-only case (i.e. "... , /)") and the all parameters are positional-only & keyword-only case (i.e. "..., /, *, ..." and "..., /, *args, ..."). This question can then be revisited for Python 3.9.

- however, we actively want to see them added for the cases where an API has a mixture of positional-only and positional-or-keyword args (i.e. "..., /, ...")

- we'd like to see the rendered documentation for function signatures enhanced to use tooltips to name the positional-only (bare "/"), keyword-only (bare "*"), additional positional args (named "*"), and additional keyword args (named "**") notations (hyperlinking to a glossary entry could also be interesting, but may be too visually noisy based on how the hyperlinks get rendered)

----------

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

From report at bugs.python.org  Wed Jun  5 16:07:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jun 2019 20:07:09 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559765229.24.0.343971959834.issue37134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Wed Jun  5 16:08:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Jun 2019 20:08:36 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559765316.93.0.777547763034.issue37134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Wed Jun  5 16:09:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 05 Jun 2019 20:09:53 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559765393.74.0.621211616904.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank you very much, everyone, for sharing your comments, views and concerns and thanks to the steering council for helping to reach a conclusion. 

I have updated PR13743 to only modify the functions that fall into the second point of Brett's message as indicated.

----------

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

From report at bugs.python.org  Wed Jun  5 16:24:31 2019
From: report at bugs.python.org (Carol Willing)
Date: Wed, 05 Jun 2019 20:24:31 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559766271.59.0.556327300481.issue37134@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 54edb04aa688c8247570b4f59b5145e3fa417576 by Carol Willing (Pablo Galindo) in branch 'master':
bpo-37134: Add PEP570 notation to the documentation (GH-13743)
https://github.com/python/cpython/commit/54edb04aa688c8247570b4f59b5145e3fa417576


----------

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

From report at bugs.python.org  Wed Jun  5 16:36:00 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 05 Jun 2019 20:36:00 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559766960.07.0.295981854108.issue37134@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


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

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

From william.j.andrea at gmail.com  Wed Jun  5 12:12:21 2019
From: william.j.andrea at gmail.com (William Andrea)
Date: Wed, 5 Jun 2019 12:12:21 -0400
Subject: [docs] Reading a file one character at a time - section 7.2.1
Message-ID: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>

Hi,

Section 7.2.1. Methods of File Objects
<https://docs.python.org/3/tutorial/inputoutput.html#methods-of-file-objects>
says

To read a file?s contents, call f.read(size), which reads some quantity of
> data and returns it as a string (in text mode) or bytes object (in binary
> mode). *size* is an optional numeric argument. When *size* is omitted or
> negative, the entire contents of the file will be read and returned [...].
> Otherwise, at most *size* bytes are read and returned.


The problem is that it says "bytes", but in text mode, f.read(size)
will return *size **characters*. It seems like this just wasn't updated
since Python 2.

It could be rephrased as:

Otherwise, at most *size* characters (in text mode) or *size* bytes (in
> binary mode) are read and returned.
>

By the way, the section on io.TextIOBase.read
<https://docs.python.org/3/library/io.html#io.TextIOBase.read> does not
have this problem.

Thanks,
William Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190605/aa1ca09f/attachment-0001.html>

From julien at palard.fr  Wed Jun  5 16:58:50 2019
From: julien at palard.fr (Julien Palard)
Date: Wed, 05 Jun 2019 20:58:50 +0000
Subject: [docs] Reading a file one character at a time - section 7.2.1
In-Reply-To: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>
References: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>
Message-ID: <bbwI1aAbzWqcSCwTsGQmlBo0t89WjDAvITh0hSSzOApwrH9ihmYe--Iao92zu888VEuxIqfrs5rn9M35Vb82VceIyLkhreAYpzS0NsvrtTs=@palard.fr>

Hi William,

> The problem is that it says "bytes", but in text mode, f.read(size) will return size characters.

You're right, thanks for reporting! Would you like to open a pull request on https://github.com/python/cpython to fix this? If you need any help in doing so, don't hesitate to ask.

(The file is here: https://github.com/python/cpython/blob/master/Doc/tutorial/inputoutput.rst)

Bests,
--?
Julien Palard
https://mdk.fr


From report at bugs.python.org  Wed Jun  5 17:45:06 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 05 Jun 2019 21:45:06 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559771106.62.0.87592524915.issue37134@roundup.psfhosted.org>


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

IIUC sum() should also have a slash in the middle.

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

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

From report at bugs.python.org  Wed Jun  5 18:54:47 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 05 Jun 2019 22:54:47 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559775287.42.0.629364426867.issue37134@roundup.psfhosted.org>


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


----------
pull_requests: +13728
pull_request: https://github.com/python/cpython/pull/13851

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

From report at bugs.python.org  Wed Jun  5 19:11:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 05 Jun 2019 23:11:49 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559776309.24.0.801922161845.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset c4c421d619baf2ff2f7e09f55b7ae22b8f863c7b by Pablo Galindo in branch 'master':
bpo-37134: Use PEP570 syntax for sum() (GH-13851)
https://github.com/python/cpython/commit/c4c421d619baf2ff2f7e09f55b7ae22b8f863c7b


----------

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

From report at bugs.python.org  Wed Jun  5 19:15:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Jun 2019 23:15:22 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559776522.23.0.434370971821.issue37134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13730
pull_request: https://github.com/python/cpython/pull/13854

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

From report at bugs.python.org  Wed Jun  5 19:21:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 05 Jun 2019 23:21:11 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559776871.23.0.301769751057.issue37134@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 23f41a64ea668296fa89e25f3cfa11f63026ecac by Miss Islington (bot) in branch '3.8':
bpo-37134: Use PEP570 syntax for sum() (GH-13851)
https://github.com/python/cpython/commit/23f41a64ea668296fa89e25f3cfa11f63026ecac


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jun  5 22:31:27 2019
From: report at bugs.python.org (Brian Skinn)
Date: Thu, 06 Jun 2019 02:31:27 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559788287.5.0.515673440062.issue37134@roundup.psfhosted.org>


Brian Skinn <bskinn at alum.mit.edu> added the comment:

Brett, to be clear, this sounds like the tabbed solution is not going to be used at this point? If so, I'll pull down the tabbed docs I'm hosting.

----------

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

From report at bugs.python.org  Thu Jun  6 12:06:58 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 06 Jun 2019 16:06:58 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
Message-ID: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

The documentation for super() at https://docs.python.org/3.8/library/functions.html#super does not actually say what super() does. It only says "Return a proxy object that delegates method calls to a parent or sibling class of type" and then gives a bunch of use cases and examples.

If there is one place where we should define exactly what super() does (as opposed to give guidance on how to use it), the stdlib reference should be it.

----------
assignee: docs at python
components: Documentation
messages: 344827
nosy: docs at python, jdemeyer
priority: normal
severity: normal
status: open
title: super() docs don't say what super() does
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Jun  6 12:08:19 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 06 Jun 2019 16:08:19 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1559837299.39.0.620347337533.issue18355@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I opened another doc issue about super(): #37176

----------
nosy: +jdemeyer

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

From report at bugs.python.org  Thu Jun  6 15:22:30 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Jun 2019 19:22:30 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559848950.05.0.12600048584.issue37134@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Brian: Probably not. The worry that came up during the steering council meeting was bifurcating the docs could cause confusion as to why it was different, which one was more "right", etc.

----------

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

From report at bugs.python.org  Thu Jun  6 15:22:52 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 06 Jun 2019 19:22:52 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559848972.03.0.159490724141.issue37134@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Brian: And thanks for the experiment! It was an interesting idea to consider.

----------

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

From report at bugs.python.org  Thu Jun  6 15:35:05 2019
From: report at bugs.python.org (Carol Willing)
Date: Thu, 06 Jun 2019 19:35:05 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559849705.8.0.745376113742.issue37134@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

@brian, Just to echo Brett's words, the Steering Council appreciated the tabbed prototype and your effort to create it. While we may not use it in this particular case, it's great to keep in mind for other places. Thanks for contributing :D

----------

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

From report at bugs.python.org  Thu Jun  6 18:07:05 2019
From: report at bugs.python.org (Brian Skinn)
Date: Thu, 06 Jun 2019 22:07:05 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559858825.69.0.275734989164.issue37134@roundup.psfhosted.org>


Brian Skinn <bskinn at alum.mit.edu> added the comment:

:thumbsup:

Glad I happened to be in the right place at the right time to put it together. I'll leave the tabslash repo up for future reference.

----------

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

From report at bugs.python.org  Thu Jun  6 18:56:17 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 06 Jun 2019 22:56:17 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559858825.69.0.275734989164.issue37134@roundup.psfhosted.org>
Message-ID: <CAP7+vJKJdyHzTsVo2yihP_Sy9834ELPiegcr2cvGOB0Q8zNBmg@mail.gmail.com>


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

Thanks Brian!

----------

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

From report at bugs.python.org  Thu Jun  6 19:03:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 06 Jun 2019 23:03:34 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559862214.89.0.282773708183.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks Brian for the prototype!

I will close this now. We can reopen if something is missing in the future.

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

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

From report at bugs.python.org  Thu Jun  6 19:24:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Jun 2019 23:24:18 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559863458.73.0.122150098897.issue37134@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like the translate() method of bytes and bytearray also needs a "/" in their doc.

I wrote a quick & dirty script to parse C files:
---
import glob

def parse(filename):
    clinic_input = False
    args = False
    positional = False
    func = None
    for line_number, line in enumerate(open(filename)):
        line = line.rstrip()
        if line.startswith("/*[clinic input]"):
            clinic_input = True
            args = False
            positional = False
            func = None
        elif clinic_input and func is None:
            func = line
        elif clinic_input and not args and not line:
            args = True
        elif args and line == "    /":
            positional = True
        elif positional and (line == "    *" or line.startswith("[clinic start generated code]")):
            clinic_input = False
            args = False
            positional = False
            func = None
        elif positional and line:
            print("!!!", filename, line_number, func, repr(line))
        elif not line:
            clinic_input = False
            args = False
            positional = False
            func = None

for filename in glob.glob("*/**.c"):
    parse(filename)
---

Output on the master branch:
---
!!! Modules/_struct.c 2224 unpack_from '    buffer: Py_buffer'
!!! Modules/_struct.c 2225 unpack_from '    offset: Py_ssize_t = 0'
!!! Modules/zlibmodule.c 195 zlib.compress '    level: int(c_default="Z_DEFAULT_COMPRESSION") = Z_DEFAULT_COMPRESSION'
!!! Modules/zlibmodule.c 196 zlib.compress '        Compression level, in 0-9 or -1.'
!!! Modules/zlibmodule.c 314 zlib.decompress '    wbits: int(c_default="MAX_WBITS") = MAX_WBITS'
!!! Modules/zlibmodule.c 315 zlib.decompress '        The window buffer size and container format.'
!!! Modules/zlibmodule.c 316 zlib.decompress '    bufsize: ssize_t(c_default="DEF_BUF_SIZE") = DEF_BUF_SIZE'
!!! Modules/zlibmodule.c 317 zlib.decompress '        The initial output buffer size.'
!!! Modules/zlibmodule.c 744 zlib.Decompress.decompress '    max_length: ssize_t = 0'
!!! Modules/zlibmodule.c 745 zlib.Decompress.decompress '        The maximum allowable length of the decompressed data.'
!!! Modules/zlibmodule.c 746 zlib.Decompress.decompress '        Unconsumed input data will be stored in'
!!! Modules/zlibmodule.c 747 zlib.Decompress.decompress '        the unconsumed_tail attribute.'
!!! Objects/bytearrayobject.c 1197 bytearray.translate '    delete as deletechars: object(c_default="NULL") = b\'\''
!!! Objects/bytesobject.c 2080 bytes.translate '    delete as deletechars: object(c_default="NULL") = b\'\''
!!! Python/bltinmodule.c 2282 sum as builtin_sum '    start: object(c_default="NULL") = 0'
---

----------

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

From report at bugs.python.org  Thu Jun  6 19:29:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 06 Jun 2019 23:29:43 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559863783.89.0.17720460431.issue37134@roundup.psfhosted.org>


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


----------
pull_requests: +13752
pull_request: https://github.com/python/cpython/pull/13874

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

From report at bugs.python.org  Thu Jun  6 19:38:47 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 06 Jun 2019 23:38:47 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559864327.47.0.559053037618.issue37134@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset de76c07a8cd0216c3dce215e4d542e2f45aa022f by Pablo Galindo in branch 'master':
bpo-37134: Add PEP570 notation to the signature of byte{array}.translate (GH-13874)
https://github.com/python/cpython/commit/de76c07a8cd0216c3dce215e4d542e2f45aa022f


----------

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

From report at bugs.python.org  Thu Jun  6 19:39:17 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Jun 2019 23:39:17 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559864357.57.0.471873637709.issue37134@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13753
pull_request: https://github.com/python/cpython/pull/13875

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

From report at bugs.python.org  Thu Jun  6 19:44:53 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 06 Jun 2019 23:44:53 +0000
Subject: [docs] [issue37134] Use PEP570 syntax in the documentation
In-Reply-To: <1559492286.96.0.468855325599.issue37134@roundup.psfhosted.org>
Message-ID: <1559864693.22.0.970388984652.issue37134@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dba4448c63b687204813a5b04c89dd458d5ac45b by Miss Islington (bot) in branch '3.8':
bpo-37134: Add PEP570 notation to the signature of byte{array}.translate (GH-13874)
https://github.com/python/cpython/commit/dba4448c63b687204813a5b04c89dd458d5ac45b


----------

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

From report at bugs.python.org  Thu Jun  6 20:35:08 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 00:35:08 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559867708.44.0.432352649933.issue37176@roundup.psfhosted.org>


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

The docs do say what super does: it returns "a proxy object that delegates method calls to a parent or sibling class of type", just as you quoted. That concise description is (almost) completely accurate and precise.

(I say *almost* because it's not just method calls that it works with, but any attribute lookup.)

What more do you want? That's not a rhetorical question.

I'm not saying that the docs are perfect or cannot be improved, but they look pretty good to me: they tell you what super does, they tell you why you might use it, and show how to use it. What's missing?

(Again, not a rhetorical question.)

I understand that super is a very advanced corner of the language: there's a lot of necessary technical jargon in the docs:

- One already needs to have a good understanding of what super *does* in order to make sense of the sentence describing what it *is*, so there's an element of circular reasoning needed.

- The reader needs to understand that super isn't magical, it just returns an object like any other function, and understand what "proxy object" means, as well as delegation.

- And have an understanding of how inheritance and the MRO work in Python, and the difference between bound and unbound methods/proxies.

But to the experienced reader who knows these concepts, I'm having a hard time seeing what you believe is missing from the docs.

Perhaps there ought to be a "gentle guide to super" somewhere, and the docs could link to that?

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

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

From report at bugs.python.org  Thu Jun  6 20:36:30 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 00:36:30 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559867790.83.0.17981835494.issue37176@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
Removed message: https://bugs.python.org/msg344892

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

From report at bugs.python.org  Thu Jun  6 20:39:55 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 00:39:55 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559867995.12.0.988893524232.issue37176@roundup.psfhosted.org>


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

The docs do say what super does: it returns "a proxy object that delegates method calls to a parent or sibling class of type", just as you quoted. That concise description is (almost) completely accurate and precise.

(I say *almost* because it's not just method calls that it works with, but any attribute lookup.)

What more do you want? That's not a rhetorical question.

I'm not saying that the docs are perfect or cannot be improved, but they look pretty good to me: they tell you what super does, they tell you why you might use it, and show how to use it. What's missing? Again, not a rhetorical question.

I understand that super is a very advanced corner of the language: there's a lot of necessary technical jargon in the docs, e.g.:

- One already needs to have a good understanding of what super *does* in order to make sense of the sentence describing what it *is*, so there's an element of circular reasoning needed.

- The reader needs to understand that super isn't magical, it just returns an object like any other function, and understand what "proxy object" means, as well as delegation.

- And have an understanding of how inheritance and the MRO work in Python, and the difference between bound and unbound methods/proxies.

I think that to the experienced reader who knows these concepts, the docs should be pretty clear and complete.

I'm having a hard time seeing what you believe is missing from the docs. Can you explain further?

Perhaps there ought to be a "gentle guide to super" somewhere, and the docs could link to that?

----------

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

From report at bugs.python.org  Thu Jun  6 20:50:12 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jun 2019 00:50:12 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559868612.96.0.552445883662.issue37176@roundup.psfhosted.org>


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

> It only says "Return a proxy object that delegates method 
> calls to a parent or sibling class of type" and then gives
> a bunch of use cases and examples."  

That wording seems very reasonable to me.

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

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

From report at bugs.python.org  Thu Jun  6 23:46:36 2019
From: report at bugs.python.org (Eric Wieser)
Date: Fri, 07 Jun 2019 03:46:36 +0000
Subject: [docs] [issue37187] CField.size from the ctypes module does not
 behave as documented on bitfields
Message-ID: <1559879196.85.0.0861364976154.issue37187@roundup.psfhosted.org>


New submission from Eric Wieser <wieser.eric at gmail.com>:

This behavior is pretty surprising:

```python
import ctypes

class Simple(ctypes.Structure):
    _fields_ = [
        ('a', ctypes.c_uint8),
        ('b', ctypes.c_uint8),
    ]

class Bitfields(ctypes.Structure):
    _fields_ = [
        ('a', ctypes.c_uint8, 8),
        ('b', ctypes.c_uint8, 8),
    ]

print(Simple.b.size)     # 1
print(Bitfields.b.size)  # 262148
```

The docstring for this field, from `help(type(Bitfields.b).size)`, is:

> Help on getset descriptor _ctypes.CField.size:
>
> size
>    size in bytes of this field

So either the behavior or the docstring needs to change.

----------
assignee: docs at python
components: Documentation
messages: 344895
nosy: Eric Wieser, docs at python
priority: normal
severity: normal
status: open
title: CField.size from the ctypes module does not behave as documented on bitfields

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

From report at bugs.python.org  Fri Jun  7 02:51:30 2019
From: report at bugs.python.org (Eric Wieser)
Date: Fri, 07 Jun 2019 06:51:30 +0000
Subject: [docs] [issue37187] CField.size from the ctypes module does not
 behave as documented on bitfields
In-Reply-To: <1559879196.85.0.0861364976154.issue37187@roundup.psfhosted.org>
Message-ID: <1559890290.45.0.410933664417.issue37187@roundup.psfhosted.org>


Change by Eric Wieser <wieser.eric at gmail.com>:


----------
components: +ctypes
type:  -> behavior

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

From report at bugs.python.org  Fri Jun  7 04:00:34 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 07 Jun 2019 08:00:34 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559894434.84.0.594018142015.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> What more do you want?

Mainly: it says "a parent or sibling class of *type*" but it doesn't explain which class it actually uses.

And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of the object (the second argument to super()).

The zero-argument form super() is not explained at all.

> Perhaps there ought to be a "gentle guide to super" somewhere, and the docs could link to that?

There are plenty of guides like that and in fact that docs already link to https://rhettinger.wordpress.com/2011/05/26/super-considered-super/

----------

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

From report at bugs.python.org  Fri Jun  7 05:50:09 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 09:50:09 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559894434.84.0.594018142015.issue37176@roundup.psfhosted.org>
Message-ID: <20190607095000.GK4221@ando.pearwood.info>


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

On Fri, Jun 07, 2019 at 08:00:34AM +0000, Jeroen Demeyer wrote:
> 
> Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:
> 
> > What more do you want?
> 
> Mainly: it says "a parent or sibling class of *type*" but it doesn't 
> explain which class it actually uses.

Only one of the two arguments is called "type". The other is called 
"object-or-type".

> And the sentence "The __mro__ attribute of the type lists the method 
> resolution search order used by both getattr() and super()" is even 
> wrong or at least confusing: what matters is not the MRO of the type 
> (the first argument to super()) but the MRO of the object (the second 
> argument to super()).

The sentence doesn't talk about the MRO of *type* (the first argument), 
it talks about the __mro__ attribute. It is correct. The __mro__ 
attribute is on the type, not the instance:

py> int.__mro__
(<class 'int'>, <class 'object'>)

py> int().__mro__
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'int' object has no attribute '__mro__'

super() look-ups never start at the instance, they delegate to the 
superclass (or superclasses), not back to the current class, or the 
instance itself.

> The zero-argument form super() is not explained at all.

Yes it is. Look at the example given:

    super().method(arg)    # This does the same thing as:
                           # super(C, self).method(arg)

----------

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

From report at bugs.python.org  Fri Jun  7 05:57:11 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 07 Jun 2019 09:57:11 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559901431.74.0.0354897681455.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Only one of the two arguments is called "type". The other is called 
"object-or-type".

I'm having problems with the first word of "a parent or sibling class of type". The most important part of super() is to *which* class that attribute lookups are delegated to and this is not explained.

> The __mro__ attribute is on the type, not the instance:

Sorry for that. I meant to say:

And the sentence "The __mro__ attribute of the type lists the method resolution search order used by both getattr() and super()" is even wrong or at least confusing: what matters is not the MRO of the type (the first argument to super()) but the MRO of ***the type of*** the object (the second argument to super()).

> Yes it is. Look at the example given:

An example is not an explanation. But it's true, this is the least of my problems with this doc.

----------

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

From report at bugs.python.org  Fri Jun  7 06:00:45 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 07 Jun 2019 10:00:45 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559901645.61.0.0290471616991.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> The sentence doesn't talk about the MRO of *type* (the first argument), 
it talks about the __mro__ attribute.

If you have to explain in a bpo issue how the doc should be read, that proves exactly my point that it's confusing. The fact that it's technically correct if you read it the right way is irrelevant.

----------

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

From report at bugs.python.org  Fri Jun  7 06:56:55 2019
From: report at bugs.python.org (Michele Angrisano)
Date: Fri, 07 Jun 2019 10:56:55 +0000
Subject: [docs] [issue37187] CField.size from the ctypes module does not
 behave as documented on bitfields
In-Reply-To: <1559879196.85.0.0861364976154.issue37187@roundup.psfhosted.org>
Message-ID: <1559905015.92.0.265272653212.issue37187@roundup.psfhosted.org>


Michele Angrisano <michele.angrisano at gmail.com> added the comment:

Hi Eric,

Thank you for the report.
Would you interested to propose a Pull Request for this issue?
You can read the devguide for more info: https://devguide.python.org/

----------
nosy: +amaury.forgeotdarc, belopolsky, mangrisano, meador.inge

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

From report at bugs.python.org  Fri Jun  7 07:34:29 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 11:34:29 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559901431.74.0.0354897681455.issue37176@roundup.psfhosted.org>
Message-ID: <20190607113422.GL4221@ando.pearwood.info>


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

On Fri, Jun 07, 2019 at 09:57:11AM +0000, Jeroen Demeyer wrote:

> I'm having problems with the first word of "a parent or sibling class of type". 

The first word is "a". Did you mean something else or did you mean it 
literally?

If the second case, we have to talk about *a* parent class rather than 
*the* parent class, since Python supports multiple inheritance and a 
class can have more than one parent class.

> The most important part of super() is to *which* class that attribute 
> lookups are delegated to and this is not explained.

Lookups are delegated to a parent or sibling class, exactly as the 
documentation says. Which class that is (whether a parent or sibling) 
can only be determined at runtime.

> And the sentence "The __mro__ attribute of the type lists the method 
> resolution search order used by both getattr() and super()" is even 
> wrong or at least confusing: what matters is not the MRO of the type 
> (the first argument to super()) but the MRO of ***the type of*** the 
> object (the second argument to super()).

I believe that is still wrong.

What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

The MRO of the second argument is not relevant, except to the degree 
that it overlaps with the __mro__ attribute of the first. And it will 
always overlaps, because the second argument must be an instance or 
subclass of the first. But not necessarily *directly* of the first:

object > Parent > A > B > C > D > E > F > instance = F()

If the method is defined in class C, then the super call in C should be 
written:

    class C(B):
        def method(self, arg):
            super().method(arg)  # like super(C, self).method(arg)

and the lookup will start at C.__mro__[1], namely B, precisely as 
expected. If it started back at the type of the instance (self), namely 
class F, the C.method would recursively call itself over and over and 
over again.

If you don't believe me, you can simulate super() working the way you 
suggest by doing this:

# -----%<-----

class A(object):
    def method(self):
        print("from class A")

class B(A):
    def method(self):
        print("bad method")
        # This is bad, don't do it!
        super(type(self), self).method()

class C(B): pass

C().method()

# -----%<-----

For multiple inheritance:

    class C(B, X, Y, Z): ...

we can't generally tell in advance which will be looked at next, since 
that depends on the precise details of the inheritance diagram. But 
whatever the class is, at this point, it is still the __mro__ of C that 
is used, not the MRO of the instance.

The bottom line: what matters is <first argument>.__mro__, exactly as 
documented.

----------

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

From report at bugs.python.org  Fri Jun  7 08:24:49 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 12:24:49 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559901645.61.0.0290471616991.issue37176@roundup.psfhosted.org>
Message-ID: <20190607122440.GM4221@ando.pearwood.info>


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

> If you have to explain in a bpo issue how the doc should be read, that 
> proves exactly my point that it's confusing. The fact that it's 
> technically correct if you read it the right way is irrelevant.

Do you expect the docs to be technically correct when read wrongly? How 
else should people read the docs, except the right way?

If you have *concrete* suggestions for improvements, of course we will 
consider them. I'll start with two concrete improvements:

1. Explicitly document that the zero-argument version is equivalent
to super(__class__, <first argument (usually self)>), and note that 
__class__ here is a special variable populated by the compiler.

The first part of this is already documented in super.__doc__ and the 
second part used to be documented:

https://docs.python.org/3.1/library/functions.html?#super

and I don't think there's any harm in adding it back in.

2. Link to the essay on how the MRO is calculated.

https://www.python.org/download/releases/2.3/mro/

----------

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

From report at bugs.python.org  Fri Jun  7 09:56:45 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 07 Jun 2019 13:56:45 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559915805.1.0.622151012135.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

I'm sorry to say that you're wrong here. super() looks at the MRO of the type of the object (the second argument) (*). It has to do that in order to support diamonds. Consider a diamond like

  D
 / \
B   C
 \ /
  A

(with A as common base class). Now super(B, D()).attr will look in the MRO of D (which is D, B, C, A) and therefore delegate to C.attr. In this case, C does not even appear in the MRO of B.

(*) To be pedantic: in the special case that the second argument is a type itself, it looks at the MRO of the second argument.

----------

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

From report at bugs.python.org  Fri Jun  7 10:01:35 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 07 Jun 2019 14:01:35 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559916095.13.0.518503751681.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

And this last comment is precisely the kind of information which should be explained in the super() docs.

----------

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

From report at bugs.python.org  Fri Jun  7 10:16:39 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 07 Jun 2019 14:16:39 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559916999.18.0.732922763412.issue37176@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Jeroen Demeyer

> I'm sorry to say that you're wrong here. super() looks at the MRO of the type of the object (the second argument) (*).

Exactly! It is funny because I was about to open the same issue this weekend. The documentation of super() is wrong here.

----------
nosy: +maggyero

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

From report at bugs.python.org  Fri Jun  7 11:21:15 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Fri, 07 Jun 2019 15:21:15 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559920875.31.0.876490053842.issue37176@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Steven D'Aprano

> What matters is the __mro__ attribute of the first argument. It matters 
because that is how the MRO actually is searched.

By the way, if it was true (it is not), then what did you think was the purpose of the second parameter of super(type, obj-or-type)?

----------

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

From report at bugs.python.org  Fri Jun  7 14:30:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jun 2019 18:30:38 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559932238.08.0.739275648818.issue37176@roundup.psfhosted.org>


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

Please make a concrete proposal (a PR or somesuch). That will make it much easier to determine whether a particular bit of word-smithing is a improvement.

Of the issues discussed so far, these are the most promising:
* Document how the zero argument form of super() infers its arguments.
* Be clear that it is the mro of type(self) that determines the search path and that the role of super() is to the next in the mro after the current class.

----------
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Jun  7 14:44:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Jun 2019 18:44:38 +0000
Subject: [docs] [issue21492] email.header.decode_header sometimes returns
 bytes, sometimes str
In-Reply-To: <1399972085.94.0.85314895463.issue21492@psf.upfronthosting.co.za>
Message-ID: <1559933078.69.0.716854381991.issue21492@roundup.psfhosted.org>


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


----------
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.3

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

From report at bugs.python.org  Fri Jun  7 16:01:24 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Jun 2019 20:01:24 +0000
Subject: [docs] [issue37149] link to official documentation tkinter failed
 !!!
In-Reply-To: <1559649566.96.0.759993950384.issue37149@roundup.psfhosted.org>
Message-ID: <1559937684.78.0.158413161479.issue37149@roundup.psfhosted.org>


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


----------
Removed message: https://bugs.python.org/msg344550

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

From report at bugs.python.org  Fri Jun  7 19:09:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Jun 2019 23:09:40 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1559948980.2.0.0445530548621.issue18355@roundup.psfhosted.org>


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

I think for now I'll leave this as an external supplement to the documentation.  My previous experience with moving a personal blog post into the main docs didn't go so well.

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

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

From report at bugs.python.org  Fri Jun  7 19:45:38 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 07 Jun 2019 23:45:38 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559915805.1.0.622151012135.issue37176@roundup.psfhosted.org>
Message-ID: <20190607234532.GN4221@ando.pearwood.info>


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

> I'm sorry to say that you're wrong here. 

I'm happy to be corrected.

It is fair to say I failed to take the multiple inheritance case into 
account. Clearly super can't *only* look at the MRO of the first object 
since that will miss the multiple inheritance case, as you point out. 
Thank you.

But neither can it *only* look at the MRO of the second class, because 
that would restart the search at the top of the hierarchy; also if 
type(second argument) was the only thing that mattered, that would make 
the first argument redundant and pointless.

----------

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

From report at bugs.python.org  Fri Jun  7 20:26:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jun 2019 00:26:57 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559953617.5.0.44443094876.issue37176@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Jun  7 23:08:55 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 08 Jun 2019 03:08:55 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559920875.31.0.876490053842.issue37176@roundup.psfhosted.org>
Message-ID: <20190608030849.GO4221@ando.pearwood.info>


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

> > What matters is the __mro__ attribute of the first argument. It matters 
> because that is how the MRO actually is searched.
> 
> By the way, if it was true (it is not), 

Yes, I see that now.

> then what did you think was 
> the purpose of the second parameter of super(type, obj-or-type)?

Given super(T, obj).method the method object is bound to instance obj; 
how else could it return a bound method instead of an unbound one?

----------

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

From william.j.andrea at gmail.com  Fri Jun  7 17:05:53 2019
From: william.j.andrea at gmail.com (William Andrea)
Date: Fri, 7 Jun 2019 17:05:53 -0400
Subject: [docs] Reading a file one character at a time - section 7.2.1
In-Reply-To: <bbwI1aAbzWqcSCwTsGQmlBo0t89WjDAvITh0hSSzOApwrH9ihmYe--Iao92zu888VEuxIqfrs5rn9M35Vb82VceIyLkhreAYpzS0NsvrtTs=@palard.fr>
References: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>
 <bbwI1aAbzWqcSCwTsGQmlBo0t89WjDAvITh0hSSzOApwrH9ihmYe--Iao92zu888VEuxIqfrs5rn9M35Vb82VceIyLkhreAYpzS0NsvrtTs=@palard.fr>
Message-ID: <CAP1E5JFC=EtK8UGhtTtR29C0BBO322BPQ6HM4vTGTqdAi1wM0g@mail.gmail.com>

Hi Julien,

I've created a draft pull request
<https://github.com/python/cpython/pull/13852>. Looks like the next step is
to register on b.p.o., sign the CLA, and open a bug on b.p.o., is that
correct?

William

On Wed, Jun 5, 2019 at 4:58 PM Julien Palard <julien at palard.fr> wrote:

> Hi William,
>
> > The problem is that it says "bytes", but in text mode, f.read(size) will
> return size characters.
>
> You're right, thanks for reporting! Would you like to open a pull request
> on https://github.com/python/cpython to fix this? If you need any help in
> doing so, don't hesitate to ask.
>
> (The file is here:
> https://github.com/python/cpython/blob/master/Doc/tutorial/inputoutput.rst
> )
>
> Bests,
> --
> Julien Palard
> https://mdk.fr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190607/1ad27ab0/attachment.html>

From report at bugs.python.org  Sat Jun  8 06:27:52 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 08 Jun 2019 10:27:52 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559989672.01.0.144658126548.issue37176@roundup.psfhosted.org>


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

Some of the problems brought up here (which sibling or subclass, and which parameter?s MRO) also came up a few years ago in Issue 23674.

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

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

From report at bugs.python.org  Sat Jun  8 06:28:54 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 08 Jun 2019 10:28:54 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1559989734.66.0.564873636961.issue37176@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Steven D'Aprano

> But neither can it *only* look at the MRO of the second class, because that would restart the search at the top of the hierarchy; also if type(second argument) was the only thing that mattered, that would make the first argument redundant and pointless.

Yes of course, but nobody states the opposite. Both parameters are necessary super(type1, obj-or-type2):

? the first one for getting the start class in the MRO, which is the class following type1 in the MRO;
? the second one for getting the MRO, which is type(obj).__mro__ if it is an instance of type1 or type2.__mro__ if it is a subclass of type1, and for binding the function into a method in a super(type1, obj).function expression (as you correctly said in your last message).

Guido's Python equivalent implementation of super() given in his 2002 paper Unifying types and classes in Python 2.2 is very informative:
https://www.python.org/download/releases/2.2.3/descrintro/#cooperation

All this confusion around super() shows that there is room for improvement in the documentation.

@Raymond Hettinger

> Please make a concrete proposal (a PR or somesuch).

I will try to make a PR this weekend if I find some time.

----------

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

From report at bugs.python.org  Sat Jun  8 07:14:36 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 08 Jun 2019 11:14:36 +0000
Subject: [docs] [issue33071] Document that PyPI no longer requires 'register'
In-Reply-To: <1520950887.05.0.467229070634.issue33071@psf.upfronthosting.co.za>
Message-ID: <1559992476.96.0.710162952653.issue33071@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Jun  8 07:51:27 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 08 Jun 2019 11:51:27 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
Message-ID: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

With the current Python equivalent `ClassMethod` implementation of `classmethod` given in Raymond Hettinger's _Descriptor HowTo Guide_, the following code snippet:

```
class A:
    @ClassMethod
    def f(cls, *, x): pass

print(A.f)
A.f(x=3)
```

prints:

> <function ClassMethod.\_\_get\_\_.<locals>.newfunc at 0x106b76268>

and raises:

> TypeError: newfunc() got an unexpected keyword argument 'x'

instead of only printing:

> <bound method A.f of <class '\_\_main\_\_.A'>>

like the `@classmethod` decorator would do.

So the `ClassMethod` implementation fails in two regards:
* it does not return a bound method to a class;
* it does not handle keyword-only arguments.

With this PR `ClassMethod` will correctly emulate `classmethod`. This approach (`types.MethodType`) is already used in the Python equivalent `Function` implementation of functions given earlier in the same guide.

----------
assignee: docs at python
components: Documentation
messages: 345031
nosy: docs at python, eric.araujo, ezio.melotti, maggyero, mdk, rhettinger, willingc
priority: normal
pull_requests: 13785
severity: normal
status: open
title: Correct classmethod emulation in Descriptor HowTo Guide
type: behavior
versions: Python 3.7

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

From julien at palard.fr  Sat Jun  8 11:23:47 2019
From: julien at palard.fr (Julien Palard)
Date: Sat, 08 Jun 2019 15:23:47 +0000
Subject: [docs] Reading a file one character at a time - section 7.2.1
In-Reply-To: <CAP1E5JFC=EtK8UGhtTtR29C0BBO322BPQ6HM4vTGTqdAi1wM0g@mail.gmail.com>
References: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>
 <bbwI1aAbzWqcSCwTsGQmlBo0t89WjDAvITh0hSSzOApwrH9ihmYe--Iao92zu888VEuxIqfrs5rn9M35Vb82VceIyLkhreAYpzS0NsvrtTs=@palard.fr>
 <CAP1E5JFC=EtK8UGhtTtR29C0BBO322BPQ6HM4vTGTqdAi1wM0g@mail.gmail.com>
Message-ID: <F0IQ2HN-WGbH4mi13X7RCMPstO_XrzO4B_xguJ-QG04ZmnBH0lA_Q5etYQaDWrxIjbCOBm7I5wl6SJJ8pZL8Jyhm5OxN8HYQjpT6PgcZ3HU=@palard.fr>

Hi William!

Thanks for taking the time to open a PR, welcome!

> Looks like the next step is to register on b.p.o., sign the CLA, and open a bug on b.p.o., is that correct?

I added labels on your PR to avoid having to write a NEWS entry and opening an issue, we don't do them for such little changes.

However the CLA is mandatory (legal thing).

--?
Julien Palard
https://mdk.fr


From report at bugs.python.org  Sat Jun  8 11:42:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jun 2019 15:42:23 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560008543.54.0.88305096271.issue37203@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Jun  8 11:48:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jun 2019 15:48:39 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560008919.13.0.561973062155.issue37203@roundup.psfhosted.org>


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

This wasn't intended to be an exact equivalent. Instead, it focuses on the key action of classmethod which is prepending the class to the call.  Though less accurate, the current version communicates better.  I suggest adding a short comment to the effect that "newfunc" emulates "types.MethodType(self.f, klass)".

----------

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

From report at bugs.python.org  Sat Jun  8 12:26:43 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sat, 08 Jun 2019 16:26:43 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1560011203.12.0.742115892101.issue37176@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> Some of the problems brought up here (which sibling or subclass, and which parameter?s MRO) also came up a few years ago in Issue 23674.

Indeed. I would actually say that these two issues are duplicates of each other.

----------

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

From report at bugs.python.org  Sat Jun  8 13:49:25 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sat, 08 Jun 2019 17:49:25 +0000
Subject: [docs] [issue36373] Deprecate explicit loop parameter in all public
 asyncio APIs
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1560016165.64.0.236523244268.issue36373@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
pull_requests: +13793
pull_request: https://github.com/python/cpython/pull/13920

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

From report at bugs.python.org  Sat Jun  8 14:15:00 2019
From: report at bugs.python.org (Ken Healy)
Date: Sat, 08 Jun 2019 18:15:00 +0000
Subject: [docs] [issue37205] time.perf_counter() is not system-wide on
 Windows, in disagreement with documentation
Message-ID: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>


New submission from Ken Healy <healykb+pythonbugs at gmail.com>:

The documentation for time.perf_counter() indicates it should return a system-wide value: https://docs.python.org/3/library/time.html#time.perf_counter

This is not true on Windows, as a process-specific offset is subtracted from the underlying QueryPerformanceCounter() value. The code comments indicate this is to reduce precision loss: https://github.com/python/cpython/blob/master/Python/pytime.c#L995-L997

This is relevant in multiprocess applications, where accurate timing is required across multiple processes. Here is a simple test case:

-----------------------------------------------------------
import concurrent.futures
import time

def worker():
    return time.perf_counter()

if __name__ == '__main__':
    pool = concurrent.futures.ProcessPoolExecutor()
    futures = []
    for i in range(3):
        print('Submitting worker {:d} at time.perf_counter() == {:.3f}'.format(i, time.perf_counter()))
        futures.append(pool.submit(worker))
        time.sleep(1)

    for i, f in enumerate(futures):
        print('Worker {:d} started at time.perf_counter() == {:.3f}'.format(i, f.result()))
-----------------------------------------------------------

Output:
-----------------------------------------------------------
C:\...>Python37\python.exe -VV
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 22:22:05)
[MSC v.1916 64 bit (AMD64)]

C:\...>Python37\python.exe perf_counter_across_processes.py
Submitting worker 0 at time.perf_counter() == 0.376
Submitting worker 1 at time.perf_counter() == 1.527
Submitting worker 2 at time.perf_counter() == 2.529
Worker 0 started at time.perf_counter() == 0.380
Worker 1 started at time.perf_counter() == 0.956
Worker 2 started at time.perf_counter() == 1.963
-----------------------------------------------------------

See my stackoverflow question for a comparison with Linux: https://stackoverflow.com/questions/56502111/should-time-perf-counter-be-consistent-across-processes-in-python-on-windows

----------
assignee: docs at python
components: Documentation, Library (Lib), Windows
messages: 345057
nosy: docs at python, kh90909, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jun  8 14:19:40 2019
From: report at bugs.python.org (Ken Healy)
Date: Sat, 08 Jun 2019 18:19:40 +0000
Subject: [docs] [issue37205] time.perf_counter() is not system-wide on
 Windows, in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1560017979.98.0.718285594986.issue37205@roundup.psfhosted.org>


Ken Healy <healykb+pythonbugs at gmail.com> added the comment:

Note that this offset subtraction behavior appears to be inherited from time.clock(), which did not make any guarantees about returning a system-wide value: 

https://github.com/python/cpython/commit/ec89539ccccd6103665a7a5c7234cf09f27c1c72#diff-4a575e94d6ac98a0d82fd93509b6bfd3L91

----------

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

From report at bugs.python.org  Sat Jun  8 17:07:33 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 08 Jun 2019 21:07:33 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560028052.97.0.679820321603.issue37203@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Raymond Hettinger

> Though less accurate, the current version communicates better

I agree that types.MethodType is more accurate but may be less understandable. But in this case I think that the Function class for emulating instance methods should not use types.MethodType either, but a custom newfunc function as well. And **kwargs parameters should be added to both newfunc functions.

----------

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

From report at bugs.python.org  Sat Jun  8 17:14:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jun 2019 21:14:18 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1560028458.73.0.760090177142.issue37176@roundup.psfhosted.org>


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

Yes, issue 23674 seems to be at least a partial duplicate.  We should just get this fixed and close both issues.

Ideally, the text can also be made more compact.  Having eight paragraphs sends an implicit message that this is too complex to understand and that it should be avoided.

One essential goal is that we need to overcome strong preconceptions about about what super() might do versus what it actually does.  Those with experience of super() in other languages tend to presume that it would be a keyword rather than a builtin type that needs to be instantiated, that it can only work within a class, that it has lower computational overhead than it does, that it only calls parents rather than siblings, that search order is controlled by the method using super() rather than the child instance, that operators will work, or that the search order is something is something other than the C3 algorithm.

The core challenge of documenting super() is that it is so different from what a person might imagine.

----------

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

From report at bugs.python.org  Sat Jun  8 17:20:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 08 Jun 2019 21:20:23 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560028823.29.0.844848428234.issue37203@roundup.psfhosted.org>


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

I'm going to close this because 1) I'm working on a somewhat major set of updates this guide already and 2) I think this tracker issue misses the point of what those guide is trying to do (communicating that the class is prepended to the argument stream but not trying to be a fully accurate drop in substitute).  The responsibility for describing in detail what @classmethod does belongs in libstdtypes.rst.  The goal in the descriptor how-to is to give an understanding of how descriptors work.

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

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

From report at bugs.python.org  Sat Jun  8 21:06:51 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 09 Jun 2019 01:06:51 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1560028458.73.0.760090177142.issue37176@roundup.psfhosted.org>
Message-ID: <20190609010644.GP4221@ando.pearwood.info>


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

On Sat, Jun 08, 2019 at 09:14:18PM +0000, Raymond Hettinger wrote:

> Ideally, the text can also be made more compact.  Having eight 
> paragraphs sends an implicit message that this is too complex to 
> understand and that it should be avoided.

But it is complex -- as you point out, there are *at least* seven 
potential misapprehensions here.

super does a lot: there are at least four ways to call it (zero-argument 
form, unbound super, class+instance and class+subclass). And as the old 
"super considered harmful" versus "super considered super" debate shows, 
there are pitfalls in multiple inheritance that people run into.

The challenge here is that for 95% of cases (plucking a number from thin 
air) using super is simple: just follow the example in the docs. But the 
remaining troublesome cases can be very troublesome, and people running 
into those cases do need to understand the gory details.

> One essential goal is that we need to overcome strong preconceptions 
> about about what super() might do versus what it actually does.
[...]

Here's two more that you missed:

- that you should call super with super(type(self), self);

- that unbound super objects dispatch to unbound methods.

At some point or another over the last decade I've misunderstood super 
to do almost all of those things. As this thread shows, I thought I had 
understood it but I still misunderstood the role of the class calling 
super.

----------

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

From report at bugs.python.org  Sun Jun  9 03:09:31 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 09 Jun 2019 07:09:31 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560064171.96.0.794533988618.issue37203@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Raymond Hettinger

> The goal in the descriptor how-to is to give an understanding of how descriptors work.

Okay. So I don't know if that was clear in my last message but that also means replacing the current "Function" implementation:

class Function(object):
    . . .
    def __get__(self, obj, objtype=None):
        "Simulate func_descr_get() in Objects/funcobject.c"
        if obj is None:
            return self
        return types.MethodType(self, obj)

with something like this:

class Function(object):
    . . .
    def __get__(self, obj, objtype=None):
        "Simulate func_descr_get() in Objects/funcobject.c"
        if obj is None:
            return self
        def newfunc(*args, **kwargs):
            return self(obj, *args, **kwargs)
        return newfunc
        # "newfunc" emulates "types.MethodType(self, obj)"

And as you said, adding a similar comment to the "ClassMethod" implementation (and **kwargs):

class ClassMethod(object):
    "Emulate PyClassMethod_Type() in Objects/funcobject.c"

    def __init__(self, f):
        self.f = f

    def __get__(self, obj, klass=None):
        if klass is None:
            klass = type(obj)
        def newfunc(*args, **kwargs):
            return self.f(klass, *args, **kwargs)
        return newfunc
        # "newfunc" emulates "types.MethodType(self.f, klass)"

----------

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

From report at bugs.python.org  Sun Jun  9 08:38:47 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 09 Jun 2019 12:38:47 +0000
Subject: [docs] [issue37209] Add what's new entries for pickle enhancements
Message-ID: <1560083927.43.0.0939739725641.issue37209@roundup.psfhosted.org>


New submission from Antoine Pitrou <pitrou at free.fr>:

The various pickle enhancements in 3.8 (apart from PEP 574) need to be mentioned in the What's New document (`Doc/whatsnew/3.8.rst`).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 345080
nosy: docs at python, ogrisel, pierreglaser, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Add what's new entries for pickle enhancements
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Jun  9 15:14:00 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 09 Jun 2019 19:14:00 +0000
Subject: [docs] [issue36853] inconsistencies in docs builds (Sphinx 2)
In-Reply-To: <1557331408.26.0.606381835406.issue36853@roundup.psfhosted.org>
Message-ID: <1560107640.27.0.761927782797.issue36853@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +13799
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13579

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

From report at bugs.python.org  Sun Jun  9 15:20:49 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 09 Jun 2019 19:20:49 +0000
Subject: [docs] [issue36853] inconsistencies in docs builds (Sphinx 2)
In-Reply-To: <1557331408.26.0.606381835406.issue36853@roundup.psfhosted.org>
Message-ID: <1560108049.63.0.650192993265.issue36853@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
nosy: +Anthony Sottile

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

From report at bugs.python.org  Sun Jun  9 16:52:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Jun 2019 20:52:21 +0000
Subject: [docs] [issue37203] Correct classmethod emulation in Descriptor
 HowTo Guide
In-Reply-To: <1559994687.73.0.550711459072.issue37203@roundup.psfhosted.org>
Message-ID: <1560113541.73.0.408733630897.issue37203@roundup.psfhosted.org>


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

How about taking another look at this after I've finished my more extensive rewrite based on my course materials.

----------

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

From report at bugs.python.org  Mon Jun 10 07:48:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 10 Jun 2019 11:48:23 +0000
Subject: [docs] [issue34677] Event scheduler page example
In-Reply-To: <1536927469.93.0.956365154283.issue34677@psf.upfronthosting.co.za>
Message-ID: <1560167303.92.0.400210621975.issue34677@roundup.psfhosted.org>


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

Thank you for the report.  As others have said, the actual time.time() value for the two `s.enter` events is different even though the `delay` value of 5 seems like it should be the same.  As @xtreak pointed out, the example is clever in showing that using `enter` instead of `enterabs` can make the queue behave in unexpected ways.

Closing as 'not a bug'.

----------
nosy: +cheryl.sabella
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

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

From asn1 at protonmail.com  Mon Jun 10 10:08:51 2019
From: asn1 at protonmail.com (asn1)
Date: Mon, 10 Jun 2019 14:08:51 +0000
Subject: [docs]
 https://docs.python.org/3/using/mac.html#getting-and-installing-macpython -
 wrong for python 3.7.3
Message-ID: <SN0bFzFtQ8lyj1RznF4UnRxObXMb_ktM5OKbFyY7g9XRxML4vBtBuRZOJDf1ni7vKoPLtDi4hH_iXl-S6S0WLq92FBTfN5DC4GqAtiySS8w=@protonmail.com>

Hi,

https://docs.python.org/3/using/mac.html#getting-and-installing-macpython

says

"What you get after installing is a number of things:

-

A MacPython 3.6 folder in your Applications folder."

However, after installing just now

$ /usr/local/bin/python3 -V
Python 3.7.3
I instead found a folder called

/Applications/Python 3.7
Cheers,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190610/de3fa4bc/attachment.html>

From report at bugs.python.org  Mon Jun 10 11:40:22 2019
From: report at bugs.python.org (makdon)
Date: Mon, 10 Jun 2019 15:40:22 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
Message-ID: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>


New submission from makdon <makdon at makdon.me>:

According the mail in docs mailing list, there's a typo in python installation document on Macos. I will check it and create a PR if necessary.


The email says:


https://docs.python.org/3/using/mac.html#getting-and-installing-macpython

says
"What you get after installing is a number of things:

A MacPython 3.6 folder in your Applications folder."

However, after installing just now

$ /usr/local/bin/python3 -V
Python 3.7.3

I instead found a folder called

/Applications/Python 3.7

----------
assignee: docs at python
components: Documentation
messages: 345134
nosy: docs at python, makdon
priority: normal
severity: normal
status: open
title: mac installation document wrong for python 3.7.3
versions: Python 3.7

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

From report at bugs.python.org  Mon Jun 10 11:44:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Jun 2019 15:44:04 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560181444.4.0.861303723832.issue37216@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Relevant email : https://mail.python.org/pipermail/docs/2019-June/041030.html

----------
components: +macOS
nosy: +ned.deily, ronaldoussoren, xtreak

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

From report at bugs.python.org  Mon Jun 10 17:02:15 2019
From: report at bugs.python.org (Alex Willmer)
Date: Mon, 10 Jun 2019 21:02:15 +0000
Subject: [docs] [issue37218] Default hmac.new() digestmod has not been
 removed from documentation
Message-ID: <1560200535.68.0.253007657272.issue37218@roundup.psfhosted.org>


New submission from Alex Willmer <alex at moreati.org.uk>:

Until Python 3.8 hmc.new() defaulted the digestmod argument to 'hmac-md5'. This was deperecated, to be removed in Python 3.8. In Python 3.8.0b1 it is gone, e.g.

Python 3.8.0b1 (default, Jun  6 2019, 03:44:52) 
[GCC 7.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import hmac
>>> hmac.new(b'qwertyuiop').name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/hmac.py", line 146, in new
    return HMAC(key, msg, digestmod)
  File "/usr/lib/python3.8/hmac.py", line 49, in __init__
    raise ValueError('`digestmod` is required.')
ValueError: `digestmod` is required.

but the deprecation note, and the documented signature haven't been updated.

PR incoming

----------
assignee: docs at python
components: Documentation
messages: 345144
nosy: Alex.Willmer, docs at python
priority: normal
severity: normal
status: open
title: Default hmac.new() digestmod has not been removed from documentation
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jun 10 17:20:37 2019
From: report at bugs.python.org (Alex Willmer)
Date: Mon, 10 Jun 2019 21:20:37 +0000
Subject: [docs] [issue37218] Default hmac.new() digestmod has not been
 removed from documentation
In-Reply-To: <1560200535.68.0.253007657272.issue37218@roundup.psfhosted.org>
Message-ID: <1560201637.45.0.769722893883.issue37218@roundup.psfhosted.org>


Alex Willmer <alex at moreati.org.uk> added the comment:

Scratch the part about documented signature, it's still `hmac.new(... digestmod=None)`, the check happens in the body of the function

----------

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

From report at bugs.python.org  Mon Jun 10 17:46:07 2019
From: report at bugs.python.org (Alex Willmer)
Date: Mon, 10 Jun 2019 21:46:07 +0000
Subject: [docs] [issue37218] Default hmac.new() digestmod has not been
 removed from documentation
In-Reply-To: <1560200535.68.0.253007657272.issue37218@roundup.psfhosted.org>
Message-ID: <1560203167.77.0.445248108987.issue37218@roundup.psfhosted.org>


Change by Alex Willmer <alex at moreati.org.uk>:


----------
keywords: +patch
pull_requests: +13814
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13947

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

From report at bugs.python.org  Mon Jun 10 19:39:36 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Mon, 10 Jun 2019 23:39:36 +0000
Subject: [docs] [issue36373] Deprecate explicit loop parameter in all public
 asyncio APIs
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1560209976.8.0.676402594726.issue36373@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
pull_requests: +13818
pull_request: https://github.com/python/cpython/pull/13950

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

From report at bugs.python.org  Mon Jun 10 21:48:04 2019
From: report at bugs.python.org (makdon)
Date: Tue, 11 Jun 2019 01:48:04 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560217684.57.0.00165356779385.issue37216@roundup.psfhosted.org>


makdon <makdon at makdon.me> added the comment:

Thanks xtreak. I am a beginner on python mailing list and now i've learn how to get a link to the email.


And i found a version error on windows installation document on version 3.6.8 that the picture is still using version 3.5:

https://docs.python.org/3.6/using/windows.html#installation-steps

I will check them and create PR for it.

----------

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

From report at bugs.python.org  Mon Jun 10 22:40:29 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Jun 2019 02:40:29 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560220829.91.0.0406252786123.issue37216@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +13829
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/13962

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

From report at bugs.python.org  Mon Jun 10 22:46:03 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Jun 2019 02:46:03 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560221163.72.0.235469592738.issue37216@roundup.psfhosted.org>


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


----------
pull_requests: +13830
pull_request: https://github.com/python/cpython/pull/13963

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

From report at bugs.python.org  Mon Jun 10 22:50:12 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Jun 2019 02:50:12 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560221412.58.0.505857009597.issue37216@roundup.psfhosted.org>


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


----------
pull_requests: +13831
pull_request: https://github.com/python/cpython/pull/13964

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

From report at bugs.python.org  Tue Jun 11 01:37:39 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Jun 2019 05:37:39 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560231459.53.0.842153605865.issue37216@roundup.psfhosted.org>


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


New changeset fe5f8b9ce2e504d4510cc82129d595015d239634 by Ned Deily (Makdon) in branch '3.8':
[3.8] bpo-37216: Fix version and filename in Mac using document (GH-13964)
https://github.com/python/cpython/commit/fe5f8b9ce2e504d4510cc82129d595015d239634


----------

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

From report at bugs.python.org  Tue Jun 11 01:38:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Jun 2019 05:38:28 +0000
Subject: [docs] [issue37216] mac installation document wrong for python 3.7.3
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560231508.95.0.344465691515.issue37216@roundup.psfhosted.org>


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


New changeset c59b1bbbb37bbfc7eb7a9386bb51c7fea838fc2a by Ned Deily (Makdon) in branch '3.7':
[3.7] bpo-37216: Fix version and filename in Mac using document (GH-13963)
https://github.com/python/cpython/commit/c59b1bbbb37bbfc7eb7a9386bb51c7fea838fc2a


----------

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

From report at bugs.python.org  Tue Jun 11 01:42:02 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 11 Jun 2019 05:42:02 +0000
Subject: [docs] [issue37216] "Using Python on a Macintosh" chapter of
 "Python Setup and Usage" doc is out-of-date
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560231722.25.0.376276442792.issue37216@roundup.psfhosted.org>


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


----------
assignee: docs at python -> ned.deily
title: mac installation document wrong for python 3.7.3 -> "Using Python on a Macintosh" chapter of "Python Setup and Usage" doc is out-of-date
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Tue Jun 11 03:11:42 2019
From: report at bugs.python.org (Hong Xu)
Date: Tue, 11 Jun 2019 07:11:42 +0000
Subject: [docs] [issue37225] Signatures of Exceptions not documented
Message-ID: <1560237102.52.0.133464005619.issue37225@roundup.psfhosted.org>


New submission from Hong Xu <hong at topbug.net>:

The "Builtin Exceptions" page does not document the constructors of the listed exception classes. All it says is

> The tuple of arguments given to the exception constructor. Some built-in exceptions (like OSError) expect a certain number of arguments and assign a special meaning to the elements of this tuple, while others are usually called only with a single string giving an error message.

This is quite vague and does not really guide users for individual exception classes.

----------
assignee: docs at python
components: Documentation
messages: 345195
nosy: Hong Xu, docs at python
priority: normal
severity: normal
status: open
title: Signatures of Exceptions not documented
versions: Python 3.7

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

From report at bugs.python.org  Tue Jun 11 03:24:02 2019
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 11 Jun 2019 07:24:02 +0000
Subject: [docs] [issue37216] "Using Python on a Macintosh" chapter of
 "Python Setup and Usage" doc is out-of-date
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560237842.44.0.356011224848.issue37216@roundup.psfhosted.org>


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


----------
pull_requests: +13833
pull_request: https://github.com/python/cpython/pull/13966

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

From report at bugs.python.org  Tue Jun 11 07:11:38 2019
From: report at bugs.python.org (David Jones)
Date: Tue, 11 Jun 2019 11:11:38 +0000
Subject: [docs] [issue36853] inconsistencies in docs builds (Sphinx 2)
In-Reply-To: <1557331408.26.0.606381835406.issue36853@roundup.psfhosted.org>
Message-ID: <1560251498.23.0.646769341033.issue36853@roundup.psfhosted.org>


David Jones <drj at pobox.com> added the comment:

I believe the issue is only triggered if you actually have some suspicious markup in your documentation (which is why your plain build on Sphinx 2 appears to work).

Remove some lines from Doc/tools/susp-ignored.csv to trigger it.

----------
nosy: +drj

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

From janwilmans at gmail.com  Tue Jun 11 05:33:46 2019
From: janwilmans at gmail.com (Jan Wilmans)
Date: Tue, 11 Jun 2019 11:33:46 +0200
Subject: [docs] dead links
Message-ID: <CADtNNhicg=6ArGYVGqCyPEN-7fRg+NvVmf9OkS6oXboUDNXdxw@mail.gmail.com>

https://docs.python.org/3.3/using/windows.html

Just wanted to let you know, these links:

Installing on Windows
<http://diveintopython.net/installing_python/windows.html>in ?Dive into
Python: Python from novice to pro <http://diveintopython.net/index.html>?
by Mark Pilgrim, 2004, ISBN 1-59059-356-1For Windows users
<http://swaroopch.com/text/Byte_of_Python:Installing_Python#For_Windows_users>
in ?Installing Python? in ?A Byte of Python <http://www.byteofpython.info/>?
by Swaroop C H, 2003

are dead.

Also: I'd like to have both python 2.7 and 3.7.x installed on windows, but
of course only one can be associated with .py files at one time. It there a
way to switch without re-installing?

Greetings,

-- 
Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190611/550e32ad/attachment.html>

From report at bugs.python.org  Tue Jun 11 14:09:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 11 Jun 2019 18:09:20 +0000
Subject: [docs] [issue37225] Signatures of Exceptions not documented
In-Reply-To: <1560237102.52.0.133464005619.issue37225@roundup.psfhosted.org>
Message-ID: <1560276560.88.0.0836193340253.issue37225@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

OSError does have its constructor documented at https://docs.python.org/3/library/exceptions.html#OSError (farther down the page I think you're reading; you didn't provide the URL you're referring to so I'm somewhat guessing). It is specifically vague because it varies from exception to exception and you need to check the exception you're using to see if it differs from BaseException.

Thanks for letting us know about your concerns, but I'm closing as "not a bug".

----------
nosy: +brett.cannon
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jun 11 17:52:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Jun 2019 21:52:41 +0000
Subject: [docs] [issue36896] clarify in types.rst that FunctionTypes & co
 constructors don't have stable signature
In-Reply-To: <1557698610.19.0.556381141599.issue36896@roundup.psfhosted.org>
Message-ID: <1560289961.09.0.01747144436.issue36896@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it be the right place to document the new CodeType.replace() method which is designed to help to write "future-proof" code? (not rely on the exact constructor API)

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

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

From report at bugs.python.org  Tue Jun 11 21:12:14 2019
From: report at bugs.python.org (Hong Xu)
Date: Wed, 12 Jun 2019 01:12:14 +0000
Subject: [docs] [issue37225] Signatures of Exceptions not documented
In-Reply-To: <1560237102.52.0.133464005619.issue37225@roundup.psfhosted.org>
Message-ID: <1560301934.19.0.569993683039.issue37225@roundup.psfhosted.org>


Hong Xu <hong at topbug.net> added the comment:

Thanks for your answer, but I believe this is a real document bug. OSError does have its signature documented, but the majority of other exception classes do not do so, neither does BaseException explains a default behavior clearly (see my quote above).

As an example, ValueError accepts multiple arguments and makes use of all of them when given, but from the document, I can barely guess this out.

----------

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

From report at bugs.python.org  Tue Jun 11 23:42:36 2019
From: report at bugs.python.org (laike9m)
Date: Wed, 12 Jun 2019 03:42:36 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560310956.94.0.450562613818.issue32625@roundup.psfhosted.org>


Change by laike9m <laike9m at gmail.com>:


----------
keywords: +patch
pull_requests: +13865
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/13985

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

From report at bugs.python.org  Tue Jun 11 23:46:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 12 Jun 2019 03:46:13 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560311173.56.0.0893883348865.issue32625@roundup.psfhosted.org>


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


New changeset 405f648db7c44b07348582b5101d4716e0ce5ac3 by Serhiy Storchaka (Yao Zuo) in branch 'master':
bpo-32625: Updated documentation for EXTENDED_ARG. (GH-13985)
https://github.com/python/cpython/commit/405f648db7c44b07348582b5101d4716e0ce5ac3


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

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

From report at bugs.python.org  Tue Jun 11 23:46:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Jun 2019 03:46:22 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560311182.14.0.61657575747.issue32625@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13866
pull_request: https://github.com/python/cpython/pull/14002

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

From report at bugs.python.org  Tue Jun 11 23:46:28 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Jun 2019 03:46:28 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560311188.7.0.316967739134.issue32625@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13867
pull_request: https://github.com/python/cpython/pull/14003

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

From report at bugs.python.org  Tue Jun 11 23:51:45 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Jun 2019 03:51:45 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560311505.21.0.54159213034.issue32625@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f0cc1a91f72c7f60adc47ec9a4305d8d85dcb1f2 by Miss Islington (bot) in branch '3.7':
bpo-32625: Updated documentation for EXTENDED_ARG. (GH-13985)
https://github.com/python/cpython/commit/f0cc1a91f72c7f60adc47ec9a4305d8d85dcb1f2


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jun 11 23:54:01 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 12 Jun 2019 03:54:01 +0000
Subject: [docs] [issue32625] Update the dis module documentation to reflect
 switch to wordcode
In-Reply-To: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>
Message-ID: <1560311641.1.0.871520550031.issue32625@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 811f84d55d156e3d05889806d00a8c028d304089 by Miss Islington (bot) in branch '3.8':
bpo-32625: Updated documentation for EXTENDED_ARG. (GH-13985)
https://github.com/python/cpython/commit/811f84d55d156e3d05889806d00a8c028d304089


----------

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

From sommer at hs-albsig.de  Tue Jun 11 16:39:09 2019
From: sommer at hs-albsig.de (Sommer, Lutz)
Date: Tue, 11 Jun 2019 20:39:09 +0000
Subject: [docs] Copyright - Documentation 3.7.3.
Message-ID: <76717a7bb673401581adc7d5cc59faed@hs-albsig.de>

Hi Python-Team,

I have a question with regard to the copyright of the python documentation for 3.7.3.  I am interested to use the documentation for my students according to the following copyright restriction (Source: https://docs.python.org/3/faq/general.html):

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

Are there copyright restrictions on the use of Python?<https://docs.python.org/3/faq/general.html#id6>

You can do anything you want with the source, as long as you leave the copyrights in and display those copyrights in any documentation about Python that you produce. If you honor the copyright rules, it's OK to use Python for commercial use, to sell copies of Python in source or binary form (modified or unmodified), or to sell products that incorporate Python in some form. We would still like to know about all commercial use of Python, of course.
-------------------------------

Correct? If not, please be so kind to let me know what I have to do.

Kind regards

Lutz


**********************************************
Prof. Dr. Lutz Sommer
Dipl.-Ing., Dipl-Kfm., Dipl.-Wirt-Ing.
Wirtschaftsingenieurwesen
Fakult?t Engineering

Albstadt-Sigmaringen University
Johannesstra?e 3
D-72458 Albstadt
Tel.: 07571-732-9531
Fax.: 07571-732-9214
Raum: T016
E-Mail: sommer at hs-albsig.de<mailto:sommer at hs-albsig.de>
**********************************************


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190611/6f5ad991/attachment.html>

From julien at palard.fr  Wed Jun 12 09:16:03 2019
From: julien at palard.fr (Julien Palard)
Date: Wed, 12 Jun 2019 13:16:03 +0000
Subject: [docs] Copyright - Documentation 3.7.3.
In-Reply-To: <76717a7bb673401581adc7d5cc59faed@hs-albsig.de>
References: <76717a7bb673401581adc7d5cc59faed@hs-albsig.de>
Message-ID: <Go-XIZmZtaBi4NWfzDX_XKxinrXbnvvqR_EBJXfAV6oz0C70dzbVNyHA5xtu-IMIiC_xAUDG8m5pbadtX42cKk5oNLb9pgQ77vv68YVrQXs=@palard.fr>

Hi Lutz!

> I have a question with regard to the copyright of the python documentation for 3.7.3.

IANAL but the documentation uses the same licence than the code, so as long as you don't hide the copyrights, you can use the documentation with your students.

If you want a more rigourous reply please contact legal at python dot org.

Bests,
--?
Julien Palard
https://mdk.fr


From report at bugs.python.org  Wed Jun 12 12:15:33 2019
From: report at bugs.python.org (=?utf-8?q?Carlos_Andr=C3=A9_Dantas_de_Lima?=)
Date: Wed, 12 Jun 2019 16:15:33 +0000
Subject: [docs] [issue37176] super() docs don't say what super() does
In-Reply-To: <1559837218.79.0.128349910274.issue37176@roundup.psfhosted.org>
Message-ID: <1560356133.64.0.49098742878.issue37176@roundup.psfhosted.org>


Carlos Andr? Dantas de Lima <eucandre at gmail.com> added the comment:

The method says who you will use some recursion.

----------
nosy: +Carlos Andr? Dantas de Lima

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

From report at bugs.python.org  Wed Jun 12 13:56:35 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 12 Jun 2019 17:56:35 +0000
Subject: [docs] [issue37225] Document BaseException constructor
In-Reply-To: <1560237102.52.0.133464005619.issue37225@roundup.psfhosted.org>
Message-ID: <1560362195.89.0.474243881682.issue37225@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Fair enough. I've changed the title to point out only BaseException needs its constructor documented as every other extension inherits from it and so its cascades down.

----------
resolution: not a bug -> 
status: closed -> open
title: Signatures of Exceptions not documented -> Document BaseException constructor
versions: +Python 3.8

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

From report at bugs.python.org  Wed Jun 12 15:12:36 2019
From: report at bugs.python.org (Alan De Smet)
Date: Wed, 12 Jun 2019 19:12:36 +0000
Subject: [docs] [issue37256] urllib.request.Request documentation
 erroneously refers to the "final two"
Message-ID: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org>


New submission from Alan De Smet <aadesmet at wisc.edu>:

In Doc/library/urllib.request.rst, in the documentation for the class `Request`, it says

```
   The final two arguments are only of interest for correct handling
   of third-party HTTP cookies:
```

However, three arguments follow, not two, and the last is not necessarily related to third-party cookie handling.

I believe replacing "final" with "next" will correct the sentence:

```
   The next two arguments are only of interest for correct handling
   of third-party HTTP cookies:
```

Verified present in the source releases for CPython 3.5.7, 3.6.8, 3.7.3, 3.8.0b1. It is _not_ present in 2.7.16 (as the third parameter didn't yet exist, so the existing phrasing is correct.)

----------
assignee: docs at python
components: Documentation
messages: 345403
nosy: Alan De Smet, docs at python
priority: normal
severity: normal
status: open
title: urllib.request.Request documentation erroneously refers to the "final two"
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun 12 15:13:32 2019
From: report at bugs.python.org (Alan De Smet)
Date: Wed, 12 Jun 2019 19:13:32 +0000
Subject: [docs] [issue37256] urllib.request.Request documentation
 erroneously refers to the "final two"
In-Reply-To: <1560366755.97.0.221740241329.issue37256@roundup.psfhosted.org>
Message-ID: <1560366812.83.0.854845056602.issue37256@roundup.psfhosted.org>


Alan De Smet <aadesmet at wisc.edu> added the comment:

Oops, used to GitHub/GitLab, where Markdown is fair game. Sorry about that. :-)

----------

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

From report at bugs.python.org  Wed Jun 12 17:19:24 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Jun 2019 21:19:24 +0000
Subject: [docs] [issue36689] docs: os.path.commonpath raises ValueError for
 different drives
In-Reply-To: <1555837758.83.0.507858438764.issue36689@roundup.psfhosted.org>
Message-ID: <1560374364.13.0.0882900203528.issue36689@roundup.psfhosted.org>


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

Flagging as Windows issue.

----------
components: +Windows
nosy: +gvanrossum, paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Wed Jun 12 17:32:46 2019
From: report at bugs.python.org (sushma)
Date: Wed, 12 Jun 2019 21:32:46 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1560375165.99.0.766754212659.issue30754@roundup.psfhosted.org>


sushma <sushma.y at gmail.com> added the comment:

I'm going to try and contribute this documentation fix.

----------
nosy: +syadlapalli

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

From report at bugs.python.org  Wed Jun 12 18:05:08 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Jun 2019 22:05:08 +0000
Subject: [docs] [issue36689] docs: os.path.commonpath raises ValueError for
 different drives
In-Reply-To: <1555837758.83.0.507858438764.issue36689@roundup.psfhosted.org>
Message-ID: <1560377108.3.0.473494308546.issue36689@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Wed Jun 12 18:05:40 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Jun 2019 22:05:40 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1560377140.33.0.913882022989.issue30754@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Wed Jun 12 18:15:06 2019
From: report at bugs.python.org (Julian Berman)
Date: Wed, 12 Jun 2019 22:15:06 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1560377140.33.0.913882022989.issue30754@roundup.psfhosted.org>
Message-ID: <CABJQSknT_z6Z9B1o8VtUgo4zCGH4fZj-4pTZv_v2D=4hBihWtA@mail.gmail.com>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

I still disagree :) but docs are better than nothing.

On Wed, Jun 12, 2019, 18:05 Guido van Rossum <report at bugs.python.org> wrote:

>
> Change by Guido van Rossum <guido at python.org>:
>
>
> ----------
> nosy: +gvanrossum
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue30754>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jun 12 20:14:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Jun 2019 00:14:31 +0000
Subject: [docs] [issue37259] Missing Doc/whatsnew/3.9.rst file
Message-ID: <1560384871.35.0.2265684667.issue37259@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

There is no Doc/whatsnew/3.9.rst file yet. How should new features of Python 3.9 be documented?

Does someone know how to create a template for this file?

----------
assignee: docs at python
components: Documentation
messages: 345433
nosy: docs at python, lukasz.langa, ned.deily, vstinner
priority: normal
severity: normal
status: open
title: Missing Doc/whatsnew/3.9.rst file
versions: Python 3.9

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

From report at bugs.python.org  Wed Jun 12 23:35:34 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Jun 2019 03:35:34 +0000
Subject: [docs] [issue37259] Missing Doc/whatsnew/3.9.rst file
In-Reply-To: <1560384871.35.0.2265684667.issue37259@roundup.psfhosted.org>
Message-ID: <1560396934.21.0.425660499701.issue37259@roundup.psfhosted.org>


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

Thanks for the report.  Fixed in PR 14040 (3a2883c313be3aff34c61a42e586f8507ba5945f) in master.

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

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

From report at bugs.python.org  Thu Jun 13 01:04:19 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Jun 2019 05:04:19 +0000
Subject: [docs] [issue37216] "Using Python on a Macintosh" chapter of
 "Python Setup and Usage" doc is out-of-date
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560402259.86.0.357277970922.issue37216@roundup.psfhosted.org>


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


New changeset 905e19a9bf9afd6439ea44fc6a4f3c8631750d6d by Ned Deily (Makdon) in branch 'master':
bpo-37216: update version to 3.9 in mac using document (GH-13966)
https://github.com/python/cpython/commit/905e19a9bf9afd6439ea44fc6a4f3c8631750d6d


----------

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

From report at bugs.python.org  Thu Jun 13 01:07:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 13 Jun 2019 05:07:14 +0000
Subject: [docs] [issue37216] "Using Python on a Macintosh" chapter of
 "Python Setup and Usage" doc is out-of-date
In-Reply-To: <1560181222.28.0.0831029476518.issue37216@roundup.psfhosted.org>
Message-ID: <1560402434.59.0.869625179644.issue37216@roundup.psfhosted.org>


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

Thanks for contributing the PRs!

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

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

From report at bugs.python.org  Thu Jun 13 03:11:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 13 Jun 2019 07:11:37 +0000
Subject: [docs] [issue37259] Missing Doc/whatsnew/3.9.rst file
In-Reply-To: <1560396934.21.0.425660499701.issue37259@roundup.psfhosted.org>
Message-ID: <CA+3bQGE5r7CwY83VbHZ5iYaoVi2A7gRX+SjtEky92tZ1OuL3zA@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Ned!

----------

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

From report at bugs.python.org  Thu Jun 13 03:30:13 2019
From: report at bugs.python.org (makdon)
Date: Thu, 13 Jun 2019 07:30:13 +0000
Subject: [docs] [issue36689] docs: os.path.commonpath raises ValueError for
 different drives
In-Reply-To: <1555837758.83.0.507858438764.issue36689@roundup.psfhosted.org>
Message-ID: <1560411013.65.0.154320032488.issue36689@roundup.psfhosted.org>


makdon <makdon at makdon.me> added the comment:

I create a PR according Windson Yang's suggestion.

----------
keywords: +patch
message_count: 4.0 -> 5.0
nosy: +makdon
nosy_count: 8.0 -> 9.0
pull_requests: +13908
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14045

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

From report at bugs.python.org  Thu Jun 13 21:38:43 2019
From: report at bugs.python.org (Mark Grandi)
Date: Fri, 14 Jun 2019 01:38:43 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1560476323.71.0.734801202833.issue9694@roundup.psfhosted.org>


Mark Grandi <markgrandi at gmail.com> added the comment:

Is there anything that can be done to help this issue move along? I just ran into it just now

----------
nosy: +markgrandi

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

From report at bugs.python.org  Thu Jun 13 23:39:55 2019
From: report at bugs.python.org (paul j3)
Date: Fri, 14 Jun 2019 03:39:55 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
 "optional arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1560483595.81.0.777330334855.issue9694@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

Mark,

Have you tried defining your own Argument Group?  If that didn't work, what fix do you want?  Why?

----------

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

From report at bugs.python.org  Fri Jun 14 06:40:27 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 14 Jun 2019 10:40:27 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560508827.7.0.955888044882.issue28805@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Victor, of the four functions you mentioned:

- _PyObject_FastCallDict: documented by PEP 590

- _PyObject_FastCallKeywords: renamed _PyObject_Vectorcall and documented by PEP 590

- _PyObject_FastCall: not sure if it's useful enough (just use _PyObject_Vectorcall with kwnames=NULL)

- _PyObject_CallNoArg: see #37194

So that leaves documenting METH_FASTCALL.

----------
nosy: +jdemeyer

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

From report at bugs.python.org  Fri Jun 14 08:05:01 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 14 Jun 2019 12:05:01 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560513901.43.0.785053753573.issue28805@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
keywords: +patch
pull_requests: +13938
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14079

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

From report at bugs.python.org  Fri Jun 14 14:02:41 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 14 Jun 2019 18:02:41 +0000
Subject: [docs] [issue37284] Not obvious that new required attrs of
 sys.implementation must have a PEP.
Message-ID: <1560535361.35.0.573554677552.issue37284@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

PEP 421 added sys.implementation for Python implementors to provide values required by stdlib code (e.g. importlib).  That PEP indicates that any new required attributes must go through the PEP process. [1]  That requirement isn't obvious.

To fix that we should add a brief note to the sys.implementation docs [2] identifying the requirement.


[1] https://www.python.org/dev/peps/pep-0421/#adding-new-required-attributes
[2] https://docs.python.org/3/library/sys.html#sys.implementation

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 345624
nosy: cheryl.sabella, docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Not obvious that new required attrs of sys.implementation must have a PEP.
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Jun 15 02:36:32 2019
From: report at bugs.python.org (p)
Date: Sat, 15 Jun 2019 06:36:32 +0000
Subject: [docs] [issue37290] Mistranslation
Message-ID: <1560580592.41.0.231348186327.issue37290@roundup.psfhosted.org>


New submission from p <pybo at getnada.com>:

https://docs.python.org/ja/3.5/library/multiprocessing.html?highlight=multiprocessing#module-multiprocessing
(?????????????????????????????????????????????????????????????????????????????????)

-->???????????????????????????????????????????????????????????????????????

----------
assignee: docs at python
components: Documentation
messages: 345659
nosy: docs at python, p
priority: normal
severity: normal
status: open
title: Mistranslation
versions: Python 3.5

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

From report at bugs.python.org  Sat Jun 15 03:06:29 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 15 Jun 2019 07:06:29 +0000
Subject: [docs] [issue37290] Mistranslation (Japanese)
In-Reply-To: <1560580592.41.0.231348186327.issue37290@roundup.psfhosted.org>
Message-ID: <1560582389.27.0.0995029814417.issue37290@roundup.psfhosted.org>


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


----------
nosy: +cocoatomo
title: Mistranslation -> Mistranslation (Japanese)

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

From report at bugs.python.org  Sat Jun 15 03:37:01 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Sat, 15 Jun 2019 07:37:01 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1560584221.36.0.567513934382.issue34831@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

That was an long two months, apologies.  I've made some fixes based on review comments and cleaned up some more of the code samples.  The primary outstanding pieces are the client component of the chat application case study, and the GUI integration section of the client case study.

----------

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

From report at bugs.python.org  Sat Jun 15 04:23:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Jun 2019 08:23:00 +0000
Subject: [docs] [issue37290] Mistranslation (Japanese)
In-Reply-To: <1560580592.41.0.231348186327.issue37290@roundup.psfhosted.org>
Message-ID: <1560586980.2.0.108419855998.issue37290@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Japanese translation is tracked in GitHub at https://github.com/python/python-docs-ja . I think this can be closed as third party issue and this can be raised as a GitHub issue there.

----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Jun 15 06:16:34 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sat, 15 Jun 2019 10:16:34 +0000
Subject: [docs] [issue37290] Mistranslation (Japanese)
In-Reply-To: <1560580592.41.0.231348186327.issue37290@roundup.psfhosted.org>
Message-ID: <1560593794.89.0.493189839931.issue37290@roundup.psfhosted.org>


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


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jun 16 07:59:07 2019
From: report at bugs.python.org (Franklin? Lee)
Date: Sun, 16 Jun 2019 11:59:07 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
Message-ID: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>


New submission from Franklin? Lee <leewangzhong at gmail.com>:

isinstance:
> If classinfo is not a class (type object), it may be a tuple of type objects, or may recursively contain other such tuples (other sequence types are not accepted).

issubclass:
> classinfo may be a tuple of class objects, in which case every entry in classinfo will be checked.

It is unclear from the docs whether
    issubclass(bool, (int, float))
should return True (because bool is a subclass of int),
or False (because bool is NOT a subclass of float).
(It returns True.)

It's likely also false that every entry will be checked, since presumably the function uses short-circuit logic.

issubclass's doc also doesn't mention the recursive tuple case that isinstance's doc has.

----------
assignee: docs at python
components: Documentation
messages: 345744
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: isinstance/issubclass doc isn't clear on whether it's an AND or an OR.
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sun Jun 16 08:23:06 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Jun 2019 12:23:06 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560687786.85.0.072213613968.issue37307@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Where are you seeing the text you've quoted for isinstance? You've marked as all versions affected, but for the master docs the text for isinstance is different and is unambiguous re treatment of tuple classinfo.

I agree with all your points about issubclass

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

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

From report at bugs.python.org  Sun Jun 16 08:24:53 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Jun 2019 12:24:53 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560687893.56.0.44192817913.issue37307@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

> It's likely also false that every entry will be checked, since presumably the function uses short-circuit logic.

This, however, would be good to verify first.

----------

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

From report at bugs.python.org  Sun Jun 16 08:29:23 2019
From: report at bugs.python.org (Franklin? Lee)
Date: Sun, 16 Jun 2019 12:29:23 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560688163.72.0.10840203127.issue37307@roundup.psfhosted.org>


Franklin? Lee <leewangzhong at gmail.com> added the comment:

My mistake. I selected all versions after checking issubclass for 2.7 and several 3.x, but added the isinstance notes later without paying attention to versions.

I copied the isinstance text from 3.2 docs. As you said, it's not the current text.

----------

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

From report at bugs.python.org  Sun Jun 16 08:32:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 16 Jun 2019 12:32:03 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560688323.49.0.318193890227.issue37307@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

docstring for issubclass is a bit clear on the behavior


issubclass(cls, class_or_tuple, /)
    Return whether 'cls' is a derived from another class or is the same class.

    A tuple, as in ``issubclass(x, (A, B, ...))``, may be given as the target to
    check against. This is equivalent to ``issubclass(x, A) or issubclass(x, B)
    or ...`` etc.

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Jun 16 08:34:32 2019
From: report at bugs.python.org (Franklin? Lee)
Date: Sun, 16 Jun 2019 12:34:32 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560688472.35.0.804002903903.issue37307@roundup.psfhosted.org>


Franklin? Lee <leewangzhong at gmail.com> added the comment:

> > It's likely also false that every entry will be checked, since presumably the function uses short-circuit logic.

> This, however, would be good to verify first.

Verified.
https://github.com/python/cpython/blob/36dcaab7fde5d2e54cdeff5b705b5adcb27726dd/Objects/abstract.c#L2517

It loops through the tuple until it finds success or error.

----------

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

From report at bugs.python.org  Sun Jun 16 08:37:45 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 16 Jun 2019 12:37:45 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1560688665.82.0.3931981019.issue37307@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

It's the same behaviour as for isinstance, could be enough to add "classinfo is treated as in isinstance call" to avoid duplication. This would also solve short-cutting imprecision.

----------

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

From report at bugs.python.org  Sun Jun 16 09:47:43 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Sun, 16 Jun 2019 13:47:43 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1560692863.59.0.800401052014.issue34831@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

FYI I'm going to be using the 3rd-party prompt-toolkit for the chat client. (The server depends only on asyncio only).  I put several hours research into finding a way for the CLI chat client to be not terrible, but it gets very complicated trying to manage stdin and stdout with asyncio.  OTOH prompt-toolkit just gives us exactly what we need, and the code looks short, neat and easy to understand. I hope that's ok (that I'll be mentioning a 3rd party lib in the tutorial).

----------

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

From report at bugs.python.org  Sun Jun 16 11:50:30 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 16 Jun 2019 15:50:30 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1560700230.65.0.293567634164.issue34831@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Jun 16 13:03:26 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 16 Jun 2019 17:03:26 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560704606.76.0.859004453554.issue28805@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5600b5e1b24a3491e83f1b3038a7ea047a34c0bf by Inada Naoki (Jeroen Demeyer) in branch 'master':
bpo-28805: document METH_FASTCALL (GH-14079)
https://github.com/python/cpython/commit/5600b5e1b24a3491e83f1b3038a7ea047a34c0bf


----------
nosy: +inada.naoki

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

From report at bugs.python.org  Sun Jun 16 17:23:22 2019
From: report at bugs.python.org (Gil Forcada Codinachs)
Date: Sun, 16 Jun 2019 21:23:22 +0000
Subject: [docs] [issue9267] Update pickle opcode documentation in
 pickletools for 3.x
In-Reply-To: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za>
Message-ID: <1560720202.5.0.382551649293.issue9267@roundup.psfhosted.org>


Gil Forcada Codinachs <gil.gnome at gmail.com> added the comment:

pickletools documentation is here:

https://docs.python.org/3/library/pickletools.html#module-pickletools

Sources are here:

https://github.com/python/cpython/blob/master/Doc/library/pickletools.rst

----------
nosy: +gforcada

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

From report at bugs.python.org  Sun Jun 16 19:18:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Jun 2019 23:18:39 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560727119.05.0.421008699516.issue28805@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13978
pull_request: https://github.com/python/cpython/pull/14136

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

From report at bugs.python.org  Sun Jun 16 19:18:57 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Jun 2019 23:18:57 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560727137.39.0.0381509226235.issue28805@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +13979
pull_request: https://github.com/python/cpython/pull/14137

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

From report at bugs.python.org  Sun Jun 16 19:24:10 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Jun 2019 23:24:10 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560727450.69.0.722865012859.issue28805@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b101fa7783615051a89500e488708b955eac94c5 by Miss Islington (bot) in branch '3.7':
bpo-28805: document METH_FASTCALL (GH-14079)
https://github.com/python/cpython/commit/b101fa7783615051a89500e488708b955eac94c5


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Jun 16 19:25:40 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 16 Jun 2019 23:25:40 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL and
 _PyObject_FastCall*()
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1560727540.73.0.0257602726188.issue28805@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e784f9f1c3fdd2102aae3fc0fe226408ff3a6029 by Miss Islington (bot) in branch '3.8':
bpo-28805: document METH_FASTCALL (GH-14079)
https://github.com/python/cpython/commit/e784f9f1c3fdd2102aae3fc0fe226408ff3a6029


----------

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

From report at bugs.python.org  Mon Jun 17 05:32:26 2019
From: report at bugs.python.org (Mike Gleen)
Date: Mon, 17 Jun 2019 09:32:26 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560763946.61.0.0866968280494.issue34903@roundup.psfhosted.org>


Change by Mike Gleen <mike.gleen at gmail.com>:


----------
pull_requests: +13990
pull_request: https://github.com/python/cpython/pull/14149

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

From report at bugs.python.org  Mon Jun 17 13:23:43 2019
From: report at bugs.python.org (wim glenn)
Date: Mon, 17 Jun 2019 17:23:43 +0000
Subject: [docs] [issue30052] URL Quoting page links to function Bytes
 instead of defintion
In-Reply-To: <1492001374.68.0.411275444037.issue30052@psf.upfronthosting.co.za>
Message-ID: <1560792223.62.0.845141239898.issue30052@roundup.psfhosted.org>


wim glenn <wim.glenn at gmail.com> added the comment:

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

Usually the little paragraph icon appears when you hover over a function name, giving an anchor link. It's not doing it for bytes or bytearray. 

Was that an unintended consequence of disambiguation from the stdtypes html?

----------
nosy: +wim.glenn

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

From report at bugs.python.org  Mon Jun 17 13:25:28 2019
From: report at bugs.python.org (wim glenn)
Date: Mon, 17 Jun 2019 17:25:28 +0000
Subject: [docs] [issue30052] URL Quoting page links to function Bytes
 instead of defintion
In-Reply-To: <1492001374.68.0.411275444037.issue30052@psf.upfronthosting.co.za>
Message-ID: <1560792328.89.0.635037340147.issue30052@roundup.psfhosted.org>


wim glenn <wim.glenn at gmail.com> added the comment:

This anchor works, by the way: 
 https://docs.python.org/3/library/functions.html#func-bytes

Hopefully someone more fluent in the docs syntax can figure out a way to fix the anchor-link hovers

----------

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

From report at bugs.python.org  Tue Jun 18 14:15:00 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 18 Jun 2019 18:15:00 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560881700.57.0.177907285617.issue34903@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:


New changeset 6b9c204ee77a0de87d6f51a3d4547a18604cef9e by Paul Ganssle (Mike Gleen) in branch 'master':
bpo-34903: Document that some strptime formats only require 1 digit (GH-14149)
https://github.com/python/cpython/commit/6b9c204ee77a0de87d6f51a3d4547a18604cef9e


----------

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

From report at bugs.python.org  Tue Jun 18 14:15:31 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Jun 2019 18:15:31 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560881731.46.0.571479114356.issue34903@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14043
pull_request: https://github.com/python/cpython/pull/14205

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

From report at bugs.python.org  Tue Jun 18 14:55:44 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Jun 2019 18:55:44 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560884144.32.0.794511002928.issue34903@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 452b417e34489614b3003b8d08148269096239d5 by Miss Islington (bot) in branch '3.7':
bpo-34903: Document that some strptime formats only require 1 digit (GH-14149)
https://github.com/python/cpython/commit/452b417e34489614b3003b8d08148269096239d5


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jun 18 14:56:50 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 18 Jun 2019 18:56:50 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560884210.33.0.213725409811.issue34903@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Thanks for the PR, Mike! This is now merged and backported to Python 3.7, so I believe we can close this issue.

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

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

From report at bugs.python.org  Tue Jun 18 14:59:28 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Jun 2019 18:59:28 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560884368.85.0.456137121839.issue34903@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14044
pull_request: https://github.com/python/cpython/pull/14206

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

From report at bugs.python.org  Tue Jun 18 15:21:32 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Jun 2019 19:21:32 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560885692.26.0.407127112526.issue34903@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 35aa0b0ced91cfb48d9dcf80a2ca8683e61f9b3e by Miss Islington (bot) in branch '3.8':
bpo-34903: Document that some strptime formats only require 1 digit (GH-14149)
https://github.com/python/cpython/commit/35aa0b0ced91cfb48d9dcf80a2ca8683e61f9b3e


----------

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

From report at bugs.python.org  Tue Jun 18 16:44:57 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 18 Jun 2019 20:44:57 +0000
Subject: [docs] [issue34903] strptime %d handling of single digit day of
 month
In-Reply-To: <1538724686.61.0.545547206417.issue34903@psf.upfronthosting.co.za>
Message-ID: <1560890697.73.0.0625060125686.issue34903@roundup.psfhosted.org>


Change by Paul Ganssle <p.ganssle at gmail.com>:


----------
resolution:  -> fixed

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

From jibarra4 at live.nmhu.edu  Tue Jun 18 19:58:58 2019
From: jibarra4 at live.nmhu.edu (Ibarra, Jesse)
Date: Tue, 18 Jun 2019 23:58:58 +0000
Subject: [docs] Fw: Embedding Python in Another Application Import Statement
 Bug
In-Reply-To: <SN4PR0201MB3552CD7B8E9B5088F37E791ED3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>
References: <SN4PR0201MB3552CD7B8E9B5088F37E791ED3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>
Message-ID: <SN4PR0201MB355249D19B408E051BE87BB1D3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>



________________________________
From: Ibarra, Jesse
Sent: Tuesday, June 18, 2019 4:56 PM
To: python-list at python.org
Cc: Koh, Aik-Siong
Subject: Embedding Python in Another Application Import Statement Bug

I am running CentOS7:

[jibarra at redsky ~]$ uname -a
Linux redsky.lanl.gov 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I am using Python3.6:

[jibarra at redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

I have successfully ran:
https://docs.python.org/3.6/extending/embedding.html#very-high-level-embedding
https://docs.python.org/3.6/extending/embedding.html#pure-embedding
https://docs.python.org/3.6/extending/embedding.html#extending-embedded-python

I then modify example:
https://docs.python.org/3.6/extending/embedding.html#pure-embedding

To include a class definition without an import statement inside of the Python code. I succesfully run the program and get a result.

The program calls PyImport_Import(pName):
pName is a PyObject equal to "without_numpy_import.py" or "without_numpy_import"

To execute run the following:

[jibarra at redsky NoImportNumpy2]$ gcc -o without_numpy2 -I /usr/include/python3.6m without_numpy2.c -L /usr/bin/python3.6-config -lpython3.6m
[jibarra at redsky NoImportNumpy2]$ ./without_numpy2
Result of: 2 * 2
Return of call : 4
Result of: 2 * 2
Return of call : 4

But when I run the same code and include an import statement in the Python code such as "import numpy" I get:

[jibarra at redsky ImportNumpy2]$ gcc -o with_numpy2 -I /usr/include/python3.6m with_numpy2.c -L /usr/bin/python3.6-config -lpython3.6m
[jibarra at redsky ImportNumpy2]$ ./with_numpy2
Result of: 2 * 2
Return of call : 4
Segmentation fault (core dumped)

I can confirm that I do have numpy library:
[jibarra at redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.array([1, 2, 3])
>>> print(type(a))
<class 'numpy.ndarray'>

I have included two examples of this:
Two_Import_Call
  Has a in-depth call to Python file,class, and variables
Two_Import_Simple
  Has a very simple call to Python file ONLY

Both as these folders contain code with the same issue regarding import statements and running the code again after Py_Finalize();


Please advise.

Thanks,
Jesse Ibarra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190618/91bab0b1/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python_Import_Problem.tar.gz
Type: application/gzip
Size: 1984 bytes
Desc: Python_Import_Problem.tar.gz
URL: <http://mail.python.org/pipermail/docs/attachments/20190618/91bab0b1/attachment.bin>

From report at bugs.python.org  Tue Jun 18 20:19:26 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 19 Jun 2019 00:19:26 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1560903566.22.0.940615934232.issue36985@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +14053
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14216

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

From report at bugs.python.org  Tue Jun 18 20:32:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Jun 2019 00:32:59 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1560904379.15.0.602905640733.issue36985@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14055
pull_request: https://github.com/python/cpython/pull/14217

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

From report at bugs.python.org  Tue Jun 18 20:50:54 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 19 Jun 2019 00:50:54 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1560905454.16.0.323282504305.issue36985@roundup.psfhosted.org>


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


----------
pull_requests: +14058
pull_request: https://github.com/python/cpython/pull/14220

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

From report at bugs.python.org  Tue Jun 18 21:02:18 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Jun 2019 01:02:18 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1560906138.23.0.514514345855.issue36985@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d0587353fe2dece91d2a9b8ddf2696fb5adc233a by Miss Islington (bot) (Ivan Levkivskyi) in branch '3.7':
[3.7] bpo-36985: Document typing.ForwardRef (GH-14216) (GH-14220)
https://github.com/python/cpython/commit/d0587353fe2dece91d2a9b8ddf2696fb5adc233a


----------
nosy: +miss-islington

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

From report at bugs.python.org  Tue Jun 18 21:06:01 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 19 Jun 2019 01:06:01 +0000
Subject: [docs] [issue36985] typing.ForwardRef is undocumented
In-Reply-To: <1558416902.0.0.868432422236.issue36985@roundup.psfhosted.org>
Message-ID: <1560906361.78.0.896707121427.issue36985@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jun 19 00:29:01 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Jun 2019 04:29:01 +0000
Subject: [docs] [issue37205] time.perf_counter() is not system-wide on
 Windows, in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1560918541.2.0.812434917991.issue37205@roundup.psfhosted.org>


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


----------
versions:  -Python 3.5, Python 3.6

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

From bazthelinuxguy at gmail.com  Wed Jun 19 00:26:59 2019
From: bazthelinuxguy at gmail.com (Bryan Zimmer)
Date: Tue, 18 Jun 2019 23:26:59 -0500
Subject: [docs] How do we find information about modules that aren't
 officially part of the python.org canon?
Message-ID: <CAO+c-kG7ofOtTEVgQqAmdSe_Esun4MLMi8yiqc31qXDNRW-HKQ@mail.gmail.com>

June 18, 2019 11:00 PM

Dear folks,

First, allow me to congratulate you on the excellent job you keep doing in
documenting the python that we know and love, the "CPython" canon as we
know it because of your work, published by python.org.

My question is, how do we find any kind of documentation for the many, many
modules that are written by third parties, and not owned or cared for by
python.org?

I began to use Fedora Linux about 6 moths ago, after being a Slackware
aficionado for many more years. I have tried other Linuxes, but for the
purpose of my question, let's stick to the Unix work-alike product known as
Fedora Core -- now we have progressed to issue 30 - Fedora 30, as they call
it.

Fedora 30 has easy-to-use software repositories. In a search I conducted
using the package installer known as "dnfdragora," I discovered a huge
number of modules for both python 2 and 3 (which surprises me - I leaned on
Python 3 and keep forgetting that there are many Python 2 users who are
dedicated to Python and still consider the language their own.)

These modules were written by third parties that are well-integrated with
the Python canon that is documented so well at https://docs.python.org/3/.
The modules appear to be written in a good Python style, and to fulfill
many of the needs of Python users, other than the fairly vast numbers of
modules that I am calling the Python.org canon. The install well into the
sys.path, and many are packages (which I have learned to recognize because
of the file __init__.py in the directory/directories.)

In my case, I discovered a number of python3 modules that help with the
task of writing elegant, consistent, and useful command-line programs.
These are the programs that I like to write, primarily because they may do
work "behind the scenes"," hearkening back to the days when I used to
program in a combination of C and Assembly languages.

For example, there are modules known as python3-cliff and python3-clint,
which claim to offer many useful tools for writers of command-line
programs. And there are at least 8 more that are offered by the same
repositories. I downloaded and installed them, but I didn't know what to do
except read the README.rst file they put in /usr/share/doc/<module name>.
That didn't give me much information I could sink my teeth into. I also
tried studying the source code. I choose python3-cliff. I discovered (so
far) a very interesting collection of classes and some (apparently test
apps, but I didn't know how to run the test apps buried in a package that
includes of the rest of the cliff system. I tried to import them, first
into the python interpreter. But no luck there, except the interpreter
noted there were no mistakes - the classes just left no __main__ section by
which the classes could be tested. Then I tried IDLE, with very little
success, except to verify that the test app and other modules I tried to
run were "just" classes. I browsed the web a bit and so far have come up
with no information regarding python3-cliff.

All this leads me to wonder if some sort of documentation exists, but I
haven't known where to find it. Hopefully you know some things about this
that I clearly don't.

I apologize for the length of this email. I wanted you to get a sense of
what I mean when I ask, "How do we find information about modules that
aren't officially part of the python.org canon?"

Thanks for reading this and I do hope/wish for a response for you, who must
be very busy.

Bryan A. Zimmer
bazthelinuxguy at gmail.com
(651) 492-9388
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190618/91d92c4f/attachment.html>

From report at bugs.python.org  Wed Jun 19 08:39:06 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Wed, 19 Jun 2019 12:39:06 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1560947946.2.0.837492679379.issue34831@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

I'm removing the GUI section of the chat case study. Yury was right, it's not going to add anything useful. The CLI chat client will work well because prompt-toolkit has actual support for asyncio.  Tkinter does not, and I think it'll be better to add a GUI section to this tutorial only once Tkinter gets first-class support for asyncio.

----------

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

From report at bugs.python.org  Wed Jun 19 09:57:38 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 13:57:38 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560952658.64.0.9373736963.issue37331@roundup.psfhosted.org>


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

It is mentioned here:

https://docs.python.org/3/library/logging.handlers.html?highlight=datagramhandler#logging.handlers.SocketHandler.makePickle

although that doesn't go into the detail of the struct.pack format. I'll update the documentation to rectify this.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Wed Jun 19 10:11:41 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:11:41 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560953501.09.0.818509948187.issue37331@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +14070
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14234

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

From report at bugs.python.org  Wed Jun 19 10:30:22 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:30:22 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560954622.57.0.892379243014.issue37331@roundup.psfhosted.org>


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


New changeset f06b569305cf604f070776ea3f800ed61fdd7d61 by Vinay Sajip in branch 'master':
bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234)
https://github.com/python/cpython/commit/f06b569305cf604f070776ea3f800ed61fdd7d61


----------

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

From report at bugs.python.org  Wed Jun 19 10:30:39 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Jun 2019 14:30:39 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560954639.19.0.150699264361.issue37331@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14071
pull_request: https://github.com/python/cpython/pull/14235

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

From report at bugs.python.org  Wed Jun 19 10:30:45 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Jun 2019 14:30:45 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560954645.19.0.205934116425.issue37331@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14072
pull_request: https://github.com/python/cpython/pull/14236

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

From report at bugs.python.org  Wed Jun 19 10:41:57 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:41:57 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560955317.86.0.257040460793.issue37331@roundup.psfhosted.org>


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


New changeset b64e42e931a3598d6f0605ec78673772f97ecd4c by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234) (GH-14236)
https://github.com/python/cpython/commit/b64e42e931a3598d6f0605ec78673772f97ecd4c


----------

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

From report at bugs.python.org  Wed Jun 19 10:42:38 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:42:38 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560955358.76.0.338894797622.issue37331@roundup.psfhosted.org>


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


New changeset d7232f0e4646803f0bbaede6e1fa124156135512 by Vinay Sajip (Miss Islington (bot)) in branch '3.8':
bpo-37331: Clarify format of socket handler messages in the documentation. (GH-14234) (GH-14235)
https://github.com/python/cpython/commit/d7232f0e4646803f0bbaede6e1fa124156135512


----------

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

From report at bugs.python.org  Wed Jun 19 10:43:45 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:43:45 +0000
Subject: [docs] [issue37331] logging.handlers.DatagramHandler sends bad data
 to socketserver.DatagramRequestHandler
In-Reply-To: <1560886622.42.0.564297699997.issue37331@roundup.psfhosted.org>
Message-ID: <1560955425.94.0.650599539405.issue37331@roundup.psfhosted.org>


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


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun 19 10:59:55 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 19 Jun 2019 14:59:55 +0000
Subject: [docs] [issue28890] logging.handlers: Document that QueueListener
 is a daemon thread
Message-ID: <1560956395.72.0.816862676452.issue28890@roundup.psfhosted.org>


New submission from Vinay Sajip <vinay_sajip at yahoo.co.uk>:

Why does that particularly need documenting? If it were a non-daemon thread, that might need documenting as the program would have to join() it or else seem to hang, but what does it matter if it's a daemon thread?

----------

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

From report at bugs.python.org  Wed Jun 19 14:43:37 2019
From: report at bugs.python.org (hai shi)
Date: Wed, 19 Jun 2019 18:43:37 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
Message-ID: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

nb_index's type is unaryfunc

----------
assignee: docs at python
components: Documentation
messages: 346071
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: A type error in typeobj.rst

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

From report at bugs.python.org  Wed Jun 19 14:46:14 2019
From: report at bugs.python.org (hai shi)
Date: Wed, 19 Jun 2019 18:46:14 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1560969974.57.0.0641155511439.issue37342@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +14076
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14241

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

From report at bugs.python.org  Wed Jun 19 15:20:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Jun 2019 19:20:04 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1560972004.88.0.516481671188.issue37342@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This was added with 9e7c92193cc98fd3c2d4751c87851460a33b9118 so adding Eric.

----------
nosy: +eric.snow, xtreak
type:  -> behavior
versions: +Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Jun 19 15:23:52 2019
From: report at bugs.python.org (Tim Hatch)
Date: Wed, 19 Jun 2019 19:23:52 +0000
Subject: [docs] [issue37341] str.format and f-string divergence
In-Reply-To: <1560965806.8.0.169696546862.issue37341@roundup.psfhosted.org>
Message-ID: <1560972232.08.0.177255928283.issue37341@roundup.psfhosted.org>


Tim Hatch <tim at timhatch.com> added the comment:

ok, I suppose it's just documentation then.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Wed Jun 19 23:32:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Jun 2019 03:32:27 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1561001547.88.0.452287586118.issue37342@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bc5caf88ca19b4c8cb9bc912c832b4807a515a60 by Miss Islington (bot) (Hai Shi) in branch 'master':
bpo-37342: Fix the incorrect nb_index's type in typeobj documentation (GH-14241)
https://github.com/python/cpython/commit/bc5caf88ca19b4c8cb9bc912c832b4807a515a60


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Jun 19 23:33:20 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Jun 2019 03:33:20 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1561001600.64.0.020237643335.issue37342@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14084
pull_request: https://github.com/python/cpython/pull/14254

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

From report at bugs.python.org  Wed Jun 19 23:41:44 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Jun 2019 03:41:44 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1561002104.72.0.726501460126.issue37342@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6258c1f7160c1b073a228c9fc49ad5ac894d66ad by Miss Islington (bot) in branch '3.8':
bpo-37342: Fix the incorrect nb_index's type in typeobj documentation (GH-14241)
https://github.com/python/cpython/commit/6258c1f7160c1b073a228c9fc49ad5ac894d66ad


----------

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

From report at bugs.python.org  Thu Jun 20 00:20:20 2019
From: report at bugs.python.org (Ken Healy)
Date: Thu, 20 Jun 2019 04:20:20 +0000
Subject: [docs] [issue37205] time.perf_counter() is not system-wide on
 Windows, in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1561004420.41.0.714810237492.issue37205@roundup.psfhosted.org>


Ken Healy <healykb+pythonbugs at gmail.com> added the comment:

Hi Terry,

I'm new to this so apologies in advance if this is a silly question...can you explain why you removed 3.5 and 3.6 from the versions list? I have tested that the issue is present in 3.6 and the offending code has been present since time.perf_counter() was introduced in 3.3.

It it because these versions are in maintenance-only status or similar, such that this type of bug fix would not be considered?

Thanks,
Ken

----------

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

From report at bugs.python.org  Thu Jun 20 00:36:12 2019
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 20 Jun 2019 04:36:12 +0000
Subject: [docs] [issue37205] time.perf_counter() is not system-wide on
 Windows, in disagreement with documentation
In-Reply-To: <1560017700.11.0.127727162727.issue37205@roundup.psfhosted.org>
Message-ID: <1561005372.73.0.464625756797.issue37205@roundup.psfhosted.org>


Mariatta Wijaya <mariatta at python.org> added the comment:

> can you explain why you removed 3.5 and 3.6 from the versions list? 

3.5 and 3.6 are closed for regular bug fix maintenance. We're only fixing issues in 3.7 and 3.8 now.

Only security fixes will be applied to 3.5 or 3.6, and this issue is not considered a security issue.

More details in https://devguide.python.org/#status-of-python-branches

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

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

From report at bugs.python.org  Thu Jun 20 04:24:57 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 20 Jun 2019 08:24:57 +0000
Subject: [docs] [issue37341] str.format and f-string divergence
In-Reply-To: <1560965806.8.0.169696546862.issue37341@roundup.psfhosted.org>
Message-ID: <1561019096.95.0.766053943957.issue37341@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I've fixed the bpo number in Misc/NEWS.d/3.8.0b1.rst. Thanks for reporting that.

----------

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

From report at bugs.python.org  Thu Jun 20 05:08:56 2019
From: report at bugs.python.org (Tim Hoffmann)
Date: Thu, 20 Jun 2019 09:08:56 +0000
Subject: [docs] [issue37346] Documentation of os not using OSError subclasses
Message-ID: <1561021736.27.0.454231232898.issue37346@roundup.psfhosted.org>


New submission from Tim Hoffmann <tim.hoffmann at posteo.de>:

The documentation of `os` does not use the more specific `OSError` subclasses introduced in PEP 3151.

----------
assignee: docs at python
components: Documentation
messages: 346110
nosy: docs at python, timhoffm
priority: normal
severity: normal
status: open
title: Documentation of os not using OSError subclasses

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

From report at bugs.python.org  Thu Jun 20 05:18:54 2019
From: report at bugs.python.org (Tim Hoffmann)
Date: Thu, 20 Jun 2019 09:18:54 +0000
Subject: [docs] [issue37346] Documentation of os not using OSError subclasses
In-Reply-To: <1561021736.27.0.454231232898.issue37346@roundup.psfhosted.org>
Message-ID: <1561022334.07.0.0836256484378.issue37346@roundup.psfhosted.org>


Change by Tim Hoffmann <tim.hoffmann at posteo.de>:


----------
keywords: +patch
pull_requests: +14090
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14262

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

From report at bugs.python.org  Thu Jun 20 11:53:19 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 20 Jun 2019 15:53:19 +0000
Subject: [docs] [issue37342] A type error in typeobj.rst
In-Reply-To: <1560969817.56.0.0743434767368.issue37342@roundup.psfhosted.org>
Message-ID: <1561045999.89.0.913703783851.issue37342@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Thu Jun 20 12:26:03 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 20 Jun 2019 16:26:03 +0000
Subject: [docs] [issue24772] Smaller viewport shifts the "expand left menu"
 character into the text
In-Reply-To: <1438422511.74.0.548589592521.issue24772@psf.upfronthosting.co.za>
Message-ID: <1561047963.68.0.337179421306.issue24772@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@karl If you are still interested in solving this, open a pull request on https://github.com/python/cpython

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Thu Jun 20 13:17:56 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 20 Jun 2019 17:17:56 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
Message-ID: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In Doc/faq/design.rst there's "with an eye to making it easily tested.".

I'm not native english, but I think "making" is wrong here, maybe "make"?

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 346141
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Typo in documentation: "to making it easy"
type: enhancement

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

From report at bugs.python.org  Thu Jun 20 13:22:26 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 20 Jun 2019 17:22:26 +0000
Subject: [docs] [issue37353] Source code has not always been
 forward-compatible
Message-ID: <1561051346.87.0.0805255025553.issue37353@roundup.psfhosted.org>


New submission from Julien Palard <julien+python at palard.fr>:

In Doc/library/parser.rst I can read:

The parse trees are not typically compatible from one version to another, whereas source code has always been forward-compatible.

But I don't think this is right, I think of print for example.

Maybe just remove ", whereas source code has always been forward-compatible" or rewrite it so say source is just more stable than parse trees?

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 346142
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: Source code has not always been forward-compatible

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

From report at bugs.python.org  Thu Jun 20 13:32:47 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 20 Jun 2019 17:32:47 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561051967.48.0.257824175423.issue37352@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

"making" looks fine to me as a native English speaker.  I'm not sure it's properly correct English, but it's fine colloquially and I don't think "make" would improve it :)

If anything, I'd change "to" to "toward", or possibly replace "an eye to" with "the goal of".

----------
nosy: +zach.ware

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

From report at bugs.python.org  Thu Jun 20 13:34:59 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 20 Jun 2019 17:34:59 +0000
Subject: [docs] [issue37353] Source code has not always been
 forward-compatible
In-Reply-To: <1561051346.87.0.0805255025553.issue37353@roundup.psfhosted.org>
Message-ID: <1561052099.72.0.989185707502.issue37353@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Perhaps just adding "within a major release series" after "forward-compatible" would be sufficient?

----------
nosy: +zach.ware

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

From report at bugs.python.org  Thu Jun 20 13:55:59 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Thu, 20 Jun 2019 17:55:59 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561053359.54.0.0673772809738.issue37352@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

"Writing test suites is very helpful, and you might want to plan your code based on expectation of making it easy for testing."

----------
nosy: +YoSTEALTH

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

From report at bugs.python.org  Thu Jun 20 14:55:12 2019
From: report at bugs.python.org (Carol Willing)
Date: Thu, 20 Jun 2019 18:55:12 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561056912.5.0.584758142615.issue37352@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

I agree with Zach's suggestions.

If I were to rewrite and pass through a grammar checker, I would get closer to this (removing the verbose "an eye to":

Writing test suites is very helpful, and you might want to design your code to make it easily tested.

In other words, it is fine as is or with modifications. :-)

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

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

From report at bugs.python.org  Thu Jun 20 15:01:27 2019
From: report at bugs.python.org (Carol Willing)
Date: Thu, 20 Jun 2019 19:01:27 +0000
Subject: [docs] [issue37353] Source code has not always been
 forward-compatible
In-Reply-To: <1561051346.87.0.0805255025553.issue37353@roundup.psfhosted.org>
Message-ID: <1561057287.46.0.451392339026.issue37353@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

"...though source code has usually been forward-compatible within a major release series."

Agree with your thoughts Julien and Zach. Perhaps remove "whereas" as well.

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

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

From report at bugs.python.org  Thu Jun 20 15:55:35 2019
From: report at bugs.python.org (Prateek Nayak)
Date: Thu, 20 Jun 2019 19:55:35 +0000
Subject: [docs] [issue37353] Source code has not always been
 forward-compatible
In-Reply-To: <1561051346.87.0.0805255025553.issue37353@roundup.psfhosted.org>
Message-ID: <1561060535.76.0.906853311185.issue37353@roundup.psfhosted.org>


Change by Prateek Nayak <lelouch.cpp at gmail.com>:


----------
keywords: +patch
pull_requests: +14101
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14277

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

From report at bugs.python.org  Thu Jun 20 19:43:20 2019
From: report at bugs.python.org (karl)
Date: Thu, 20 Jun 2019 23:43:20 +0000
Subject: [docs] [issue24772] Smaller viewport shifts the "expand left menu"
 character into the text
In-Reply-To: <1438422511.74.0.548589592521.issue24772@psf.upfronthosting.co.za>
Message-ID: <1561074200.44.0.288891391087.issue24772@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

I'm at Mozilla All Hands this week. 
I'll check if my solution still makes sense next week and will make a pull request and/or propose another solution. 
Thanks for the reminder. adding to my calendar.

----------

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

From report at bugs.python.org  Thu Jun 20 21:32:02 2019
From: report at bugs.python.org (YoSTEALTH)
Date: Fri, 21 Jun 2019 01:32:02 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561080722.17.0.220554196191.issue37352@roundup.psfhosted.org>


YoSTEALTH <ritesh at stealthcentral.com> added the comment:

programmers "plan" their code, they don't "design" it, as far as i know!

----------

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

From report at bugs.python.org  Thu Jun 20 22:24:16 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Jun 2019 02:24:16 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561083856.82.0.62394135406.issue37352@roundup.psfhosted.org>


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

It reads fine to me as is.

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

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

From report at bugs.python.org  Thu Jun 20 22:48:26 2019
From: report at bugs.python.org (Mariatta)
Date: Fri, 21 Jun 2019 02:48:26 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561085306.33.0.706057221537.issue37352@roundup.psfhosted.org>


Mariatta <mariatta at python.org> added the comment:

FWIW I agree that "with an eye to ..." sounds too complex. It would be great to change it to "with the goal of...".

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

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

From report at bugs.python.org  Fri Jun 21 03:21:03 2019
From: report at bugs.python.org (Julien Castiaux)
Date: Fri, 21 Jun 2019 07:21:03 +0000
Subject: [docs] [issue28890] logging.handlers: Document that QueueListener
 is a daemon thread
In-Reply-To: <1560956395.72.0.816862676452.issue28890@roundup.psfhosted.org>
Message-ID: <1561101663.92.0.196824848588.issue28890@roundup.psfhosted.org>


Julien Castiaux <julien.castiaux at gmail.com> added the comment:

Hello,

The purpose of the QueueListener is to provide a way to get messages sent by QueueHandlers. I was starting the QueueListener in is own mp.Process and was expecting the start() to hang. As it was not, the process was exiting logging a few messages or not depending on the threads schedule. I had a difficult time debugging it and ended up looking at the source code as the start() method was not stating it was starting a daemon thread.

The documentation now states it, I close the bug.
Regards,

----------
resolution:  -> out of date

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

From report at bugs.python.org  Fri Jun 21 03:28:34 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 21 Jun 2019 07:28:34 +0000
Subject: [docs] [issue28890] logging.handlers: Document that QueueListener
 is a daemon thread
In-Reply-To: <1560956395.72.0.816862676452.issue28890@roundup.psfhosted.org>
Message-ID: <1561102114.78.0.61675571246.issue28890@roundup.psfhosted.org>


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


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

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

From MPlotas at verisk.com  Fri Jun 21 09:41:39 2019
From: MPlotas at verisk.com (Plotas, Matthew)
Date: Fri, 21 Jun 2019 13:41:39 +0000
Subject: [docs] Documentation 404
Message-ID: <046d440ed80144ec9c350ad45f5998df@VAW1PWINFMBXP7.veriskdom.com>

Hi all.

I'm seeing 404 errors on all the documentation links on this page: https://docs.python.org/3/download.html for 3.7.4rc1<https://docs.python.org/3/download.html%20for%203.7.4rc1>. Tried cellular + ethernet so I'm fairly certain the problem is not on my end.

Just a heads up. Thanks for all you guys do.


Matthew Plotas
Field Operations Specialist

Phone: +1.913.749.8476

[Geomni]<http://www.geomni.net/>

[Forbes Global 2000: World's Best Employers]<https://www.forbes.com/world-best-employers/list/#tab:rank_search:Verisk>[Forbes Best Employers For Women]<https://www.forbes.com/best-employers-for-women/list/#search:Verisk>[Great Place to Work]<http://reviews.greatplacetowork.com/verisk-analytics>

Geomni.net<http://www.geomni.net> | Join Our Talent Network<http://www.verisk.com/careers/> | vCard<https://dynasend.com/signatures/vcard/mplotas-at-verisk.com.vcf> | Map<https://www.google.com/maps/place/12901+151st+St,+Olathe,+KS+66062/@38.8528657,-94.770225,13z/data=!4m5!3m4!1s0x87c0bf83ab456925:0xaf57961c4aa9d7c5!8m2!3d38.8528615!4d-94.7352061?hl=en> | Email<mailto:mplotas at verisk.com>

[Blog]<http://www.verisk.com/blog>[LinkedIn]<https://www.linkedin.com/company-beta/24986088/>[Twitter]<http://www.twitter.com/verisk>

Your privacy is important to us. We encourage you to read our candidate privacy notice<https://www.verisk.com/privacy-trademarks-use/verisk-analytics-candidate-privacy-notice/> to learn more about our privacy practices.



________________________________

This email is intended solely for the recipient. It may contain privileged, proprietary or confidential information or material. If you are not the intended recipient, please delete this email and any attachments and notify the sender of the error.

________________________________

Xactware's opt-in mailing list allows you to receive Xactware News that is of interest to you. Visit my.xactware.com today to join or to update your email preferences!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190621/49361d69/attachment.html>

From julien at palard.fr  Fri Jun 21 10:32:32 2019
From: julien at palard.fr (Julien Palard)
Date: Fri, 21 Jun 2019 14:32:32 +0000
Subject: [docs] Documentation 404
In-Reply-To: <046d440ed80144ec9c350ad45f5998df@VAW1PWINFMBXP7.veriskdom.com>
References: <046d440ed80144ec9c350ad45f5998df@VAW1PWINFMBXP7.veriskdom.com>
Message-ID: <8RqlkyUpTJGGiBR1n-784xTC5r_BxT7VS03zgpXr3hMRB1Xxsmpuw4c-QrLxSD9oUX_dCZRgxmU2Yy8fEWjPGxPMzkbUchMlFSASLilgQA8=@palard.fr>

Hi Plotas,

> I?m seeing 404 errors on all the documentation links on this page: https://docs.python.org/3/download.html for 3.7.4rc1. Tried cellular + ethernet so I?m fairly certain the problem is not on my end.

Looks like you tried right in between the HTML docs was published and the PDF were built after the 3.7.4 release. We should try to reduce this time (pdfs are long to build, html is fast to udpate).

I just tried and it works now, can you please try too?

--?
Julien Palard
https://mdk.fr


From report at bugs.python.org  Fri Jun 21 14:57:28 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 21 Jun 2019 18:57:28 +0000
Subject: [docs] [issue37307] isinstance/issubclass doc isn't clear on
 whether it's an AND or an OR.
In-Reply-To: <1560686347.4.0.566273891061.issue37307@roundup.psfhosted.org>
Message-ID: <1561143448.36.0.916564483679.issue37307@roundup.psfhosted.org>


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


----------
versions:  -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 21 17:09:57 2019
From: report at bugs.python.org (Mark Rice)
Date: Fri, 21 Jun 2019 21:09:57 +0000
Subject: [docs] [issue37352] Typo in documentation: "to making it easy"
In-Reply-To: <1561051076.38.0.680855087082.issue37352@roundup.psfhosted.org>
Message-ID: <1561151397.01.0.968389235407.issue37352@roundup.psfhosted.org>


Mark Rice <mrice at nocimed.com> added the comment:

Hi, first time on here. And new to the python bug tracker. But, the sentence might read fine as is, or could be tweaked to say "with an eye toward making it easily tested..." as Zach suggested. It is what my internal grammar alarm jumped to automatically.

----------
nosy: +mrice88

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

From report at bugs.python.org  Fri Jun 21 17:27:29 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 21 Jun 2019 21:27:29 +0000
Subject: [docs] [issue30052] URL Quoting page links to function Bytes
 instead of defintion
In-Reply-To: <1492001374.68.0.411275444037.issue30052@psf.upfronthosting.co.za>
Message-ID: <1561152449.85.0.470182734743.issue30052@roundup.psfhosted.org>


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

Hi @wim.glenn, 

Thanks for the report.  It looks like the same issue applies to all the built-in functions that are handled this way, not just bytearray and bytes.  So, dict, frozenset, list, memoryview, range, set, str, and tuple too.  I'm not sure what the fix is, but I agree that we should take a look.  Can you create a new tracker issue for this?  Thanks!

----------

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

From report at bugs.python.org  Sun Jun 23 00:44:45 2019
From: report at bugs.python.org (Giovanni Cappellotto)
Date: Sun, 23 Jun 2019 04:44:45 +0000
Subject: [docs] [issue37284] Not obvious that new required attrs of
 sys.implementation must have a PEP.
In-Reply-To: <1560535361.35.0.573554677552.issue37284@roundup.psfhosted.org>
Message-ID: <1561265085.12.0.393504953925.issue37284@roundup.psfhosted.org>


Giovanni Cappellotto <potomak84 at gmail.com> added the comment:

Hi,

I'd like to claim this task if nobody else already started working on it.

----------
nosy: +potomak

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

From report at bugs.python.org  Sun Jun 23 07:18:32 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 23 Jun 2019 11:18:32 +0000
Subject: [docs] [issue35181] Doc: Namespace Packages: Inconsistent
 documentation of __loader__ being None
In-Reply-To: <1541543349.68.0.788709270274.issue35181@psf.upfronthosting.co.za>
Message-ID: <1561288712.89.0.729480431626.issue35181@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

@Julien, @Barry

Now that the PRs are merged, I think that we can close this issue.

----------

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

From report at bugs.python.org  Sun Jun 23 07:34:11 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sun, 23 Jun 2019 11:34:11 +0000
Subject: [docs] [issue35181] Doc: Namespace Packages: Inconsistent
 documentation of __loader__ being None
In-Reply-To: <1541543349.68.0.788709270274.issue35181@psf.upfronthosting.co.za>
Message-ID: <1561289651.01.0.603044191447.issue35181@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Oops, sorry, only one of the two PRs has been merged.

----------

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

From report at bugs.python.org  Sun Jun 23 20:07:25 2019
From: report at bugs.python.org (Mark turner)
Date: Mon, 24 Jun 2019 00:07:25 +0000
Subject: [docs] [issue36661] Missing dataclass decorator import in
 dataclasses module docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1561334845.35.0.979195736346.issue36661@roundup.psfhosted.org>


Mark turner <mturner865 at gmail.com> added the comment:

I tried a couple of the examples from the docs and found the setup to be a little confusing
amd inconsistent. For example, the decorator line "@decorator" requires you to use

from dataclasses import dataclass

while the example line "mylist: List[int] = field(default_factory=list)" requires you to use these

import dataclasses
import typing

and must be modified to
mylist: typing.List[int] = dataclasses.field(default_factory=list)

The decorator line could be modified to be
@dataclasses.dataclass
and the from/import line could be eliminated. But that seems awkward.

So, what is are best practices for handling the imports needed by these examples?
And should the examples be updated to be consistent with a best practice set of imports?
Or am I not understanding how this code works?

Also, the intro section states "If any of the added methods already exist on the class, a TypeError will be raised."
This statement seems incorrect and contrdicts the parameter documentation that follows.

----------
nosy: +mturner865

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

From report at bugs.python.org  Sun Jun 23 20:50:12 2019
From: report at bugs.python.org (Giovanni Cappellotto)
Date: Mon, 24 Jun 2019 00:50:12 +0000
Subject: [docs] [issue37284] Not obvious that new required attrs of
 sys.implementation must have a PEP.
In-Reply-To: <1560535361.35.0.573554677552.issue37284@roundup.psfhosted.org>
Message-ID: <1561337412.3.0.782424485772.issue37284@roundup.psfhosted.org>


Change by Giovanni Cappellotto <potomak84 at gmail.com>:


----------
keywords: +patch
pull_requests: +14148
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14328

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

From report at bugs.python.org  Mon Jun 24 01:34:19 2019
From: report at bugs.python.org (Prateek Nayak)
Date: Mon, 24 Jun 2019 05:34:19 +0000
Subject: [docs] [issue36661] Missing dataclass decorator import in
 dataclasses module docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1561354459.02.0.393278676251.issue36661@roundup.psfhosted.org>


Change by Prateek Nayak <lelouch.cpp at gmail.com>:


----------
keywords: +patch
pull_requests: +14149
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14329

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

From report at bugs.python.org  Mon Jun 24 09:18:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 24 Jun 2019 13:18:50 +0000
Subject: [docs] [issue15629] Add to regrtest the ability to run Lib and Doc
 doctests
In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za>
Message-ID: <1561382330.41.0.305914169412.issue15629@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The issue has been fixed by bpo-35240.

commit a22df4896f6b83c8741203118790ae281716bca5
Author: Victor Stinner <vstinner at redhat.com>
Date:   Wed Nov 28 10:24:08 2018 +0100

    bpo-35240: Add "doctest" job to Travis CI (GH-10753)
    
    Create a new "doctest" job in Travis CI to run "make doctest".

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Travis CI: xvfb-run: error: Xvfb failed to start

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

From report at bugs.python.org  Mon Jun 24 11:46:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Jun 2019 15:46:04 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
Message-ID: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

All audit events are marked in the docs with the ".. audit-event:: <name> <args>" syntax.

We should automatically collate these into a single table and generate a new doc page as part of docs build.

----------
assignee: docs at python
components: Documentation
messages: 346417
nosy: christian.heimes, docs at python, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Generate table of audit events for docs
type: enhancement
versions: Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Jun 24 12:11:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Jun 2019 16:11:29 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561392689.25.0.785473165424.issue37390@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Jun 24 14:32:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Jun 2019 18:32:23 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561401143.35.0.935920634686.issue37390@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I just tried an initial attempt at this and a screenshot as attached. I followed the approach similar to the one at https://www.sphinx-doc.org/en/master/development/tutorials/todo.html to gather all todos. The approach was to append all the audit event directives to a list as they are collected. I then created an AuditEventListDirective for post processing once rst files were read and created an empty page with only the audit-event-list-table directive. I rendered the audit items in the list into a table and then replaced the audit-event-list-table directive in the page with the table content. Unfortunately, I couldn't proceed further due to some odd sphinx error during builds on moving this to a new index and limited sphinx skills. 

+1 to the idea. It would be helpful to have all the audit events under one page for reference.

https://github.com/python/cpython/compare/master...tirkarthi:bpo37390

----------
Added file: https://bugs.python.org/file48436/Screen Shot 2019-06-24 at 11.54.58 pm.png

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

From report at bugs.python.org  Mon Jun 24 14:52:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Jun 2019 18:52:52 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561402372.47.0.500611170138.issue37390@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Awesome! I was just making a start on this too, and it looks like we were doing nearly identical work. Happy to let you keep going on it!

Some things that I thought would be worth doing:
* combine equivalent events (warn if names match but arguments are different)
* include links back to the section where they came from
* include a "CPython implementation detail" message, and maybe mention that the table is generated from the docs

I think for the formatting, we'll have to rearrange how the *args* variable is created initially (so that we store the original names, not the `` marked ones) and then use nodes.literal() when adding them later. But this is pushing the boundaries of my Sphinx/docutils skills as well :)

----------

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

From report at bugs.python.org  Mon Jun 24 15:08:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Jun 2019 19:08:04 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561403284.84.0.368020061971.issue37390@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think my approach suffers from the drawback where duplicate items cannot be separated correctly as you have mentioned. Example as below where socket.connect and socket.connect_ex emit same event and I am not able to retrieve the function at which the audit event block is present thus generating the same entry twice in the table. Maybe I need to store some more metadata.

1153:.. method:: socket.connect(address)
1165:   .. audit-event:: socket.connect "self address"
1174:.. method:: socket.connect_ex(address)
1183:   .. audit-event:: socket.connect "self address"

> * include links back to the section where they came from

Sphinx doesn't seem to support hyperlinking to line numbers. One approach would be to just link to the functions that emit the events that could solve the above problem too.

I did this as a PoC and kind of stuck with moving the file to a separate to a different table of content. I also seemed to have hit a sphinx bug that I couldn't get out of and my skills are limited too in Sphinx. I will give it another try over this week to see if I can come up with something mergeable :)

----------

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

From report at bugs.python.org  Mon Jun 24 19:01:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Jun 2019 23:01:38 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561417298.41.0.134175523549.issue37390@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I took your code and made some improvements:

https://github.com/python/cpython/compare/master...zooba:bpo37390

In particular, I added the backlinks from the table (but unfortunately they all go to the line of text we generate for the ..audit-event directive, and not the top of the section :( ) and debugged some of the weirdness of generating tables in docutils.

Feel free to pull my changes and take back over if there's more you want to do!

----------

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

From report at bugs.python.org  Mon Jun 24 19:43:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 24 Jun 2019 23:43:29 +0000
Subject: [docs] [issue25361] Is python-3-5-0.exe compiled with SSE2
 instrutions? If so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1561419809.58.0.313624206469.issue25361@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 8bd2872adbbc7ed5dd0a7593193c52431ae34c8d by Steve Dower (animalize) in branch 'master':
bpo-25361: Enable SSE2 instructions for Windows 32-bit build (GH-12438)
https://github.com/python/cpython/commit/8bd2872adbbc7ed5dd0a7593193c52431ae34c8d


----------

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

From william.j.andrea at gmail.com  Mon Jun 24 14:45:04 2019
From: william.j.andrea at gmail.com (William Andrea)
Date: Mon, 24 Jun 2019 14:45:04 -0400
Subject: [docs] Reading a file one character at a time - section 7.2.1
In-Reply-To: <F0IQ2HN-WGbH4mi13X7RCMPstO_XrzO4B_xguJ-QG04ZmnBH0lA_Q5etYQaDWrxIjbCOBm7I5wl6SJJ8pZL8Jyhm5OxN8HYQjpT6PgcZ3HU=@palard.fr>
References: <CAP1E5JH1S7vtUwqFdr47Gy6F7iO2QsMYc+hUvduhGHq10aU8-Q@mail.gmail.com>
 <bbwI1aAbzWqcSCwTsGQmlBo0t89WjDAvITh0hSSzOApwrH9ihmYe--Iao92zu888VEuxIqfrs5rn9M35Vb82VceIyLkhreAYpzS0NsvrtTs=@palard.fr>
 <CAP1E5JFC=EtK8UGhtTtR29C0BBO322BPQ6HM4vTGTqdAi1wM0g@mail.gmail.com>
 <F0IQ2HN-WGbH4mi13X7RCMPstO_XrzO4B_xguJ-QG04ZmnBH0lA_Q5etYQaDWrxIjbCOBm7I5wl6SJJ8pZL8Jyhm5OxN8HYQjpT6PgcZ3HU=@palard.fr>
Message-ID: <CAP1E5JEzP3BROJVDY7uS_7ZYHNGgv+ve7Y0kUj=-C5RDxHEpnw@mail.gmail.com>

I've signed the CLA and the-knights-who-say-ni have picked it up. I'm just
waiting for review now :)

Also, I skimmed the rest of section 7.2 and saw some other errors/omissions
related to text mode vs binary mode. I'm not sure how to fix all of them,
so should I open a bug on b.p.o.?

On Sat, Jun 8, 2019 at 11:23 AM Julien Palard <julien at palard.fr> wrote:

> Hi William!
>
> Thanks for taking the time to open a PR, welcome!
>
> > Looks like the next step is to register on b.p.o., sign the CLA, and
> open a bug on b.p.o., is that correct?
>
> I added labels on your PR to avoid having to write a NEWS entry and
> opening an issue, we don't do them for such little changes.
>
> However the CLA is mandatory (legal thing).
>
> --
> Julien Palard
> https://mdk.fr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190624/81cea091/attachment.html>

From report at bugs.python.org  Tue Jun 25 09:13:22 2019
From: report at bugs.python.org (Shivaram Lingamneni)
Date: Tue, 25 Jun 2019 13:13:22 +0000
Subject: [docs] [issue31711] ssl.SSLSocket.send(b"") fails
In-Reply-To: <1507282980.19.0.213398074469.issue31711@psf.upfronthosting.co.za>
Message-ID: <1561468402.55.0.86766456115.issue31711@roundup.psfhosted.org>


Shivaram Lingamneni <slingamn at cs.stanford.edu> added the comment:

Are there any possible next steps on this?

This issue is very counterintuitive and challenging to debug --- it commonly presents as a nondeterministic edge case, and it appears to be a failed system call but doesn't show up in strace.

Thanks for your time.

----------
nosy: +slingamn

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

From jibarra4 at live.nmhu.edu  Tue Jun 25 10:41:04 2019
From: jibarra4 at live.nmhu.edu (Ibarra, Jesse)
Date: Tue, 25 Jun 2019 14:41:04 +0000
Subject: [docs] Fw: Embedding Python in Another Application Import Statement
 Bug
In-Reply-To: <SN4PR0201MB355249D19B408E051BE87BB1D3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>
References: <SN4PR0201MB3552CD7B8E9B5088F37E791ED3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>,
 <SN4PR0201MB355249D19B408E051BE87BB1D3EA0@SN4PR0201MB3552.namprd02.prod.outlook.com>
Message-ID: <SN4PR0201MB3552BC1383B0E67CC0EC31AED3E30@SN4PR0201MB3552.namprd02.prod.outlook.com>

Is this ticket still unsolved?

________________________________
From: Ibarra, Jesse
Sent: Tuesday, June 18, 2019 4:58 PM
To: docs at python.org
Cc: Koh, Aik-Siong
Subject: Fw: Embedding Python in Another Application Import Statement Bug



________________________________
From: Ibarra, Jesse
Sent: Tuesday, June 18, 2019 4:56 PM
To: python-list at python.org
Cc: Koh, Aik-Siong
Subject: Embedding Python in Another Application Import Statement Bug

I am running CentOS7:

[jibarra at redsky ~]$ uname -a
Linux redsky.lanl.gov 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I am using Python3.6:

[jibarra at redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

I have successfully ran:
https://docs.python.org/3.6/extending/embedding.html#very-high-level-embedding
https://docs.python.org/3.6/extending/embedding.html#pure-embedding
https://docs.python.org/3.6/extending/embedding.html#extending-embedded-python

I then modify example:
https://docs.python.org/3.6/extending/embedding.html#pure-embedding

To include a class definition without an import statement inside of the Python code. I succesfully run the program and get a result.

The program calls PyImport_Import(pName):
pName is a PyObject equal to "without_numpy_import.py" or "without_numpy_import"

To execute run the following:

[jibarra at redsky NoImportNumpy2]$ gcc -o without_numpy2 -I /usr/include/python3.6m without_numpy2.c -L /usr/bin/python3.6-config -lpython3.6m
[jibarra at redsky NoImportNumpy2]$ ./without_numpy2
Result of: 2 * 2
Return of call : 4
Result of: 2 * 2
Return of call : 4

But when I run the same code and include an import statement in the Python code such as "import numpy" I get:

[jibarra at redsky ImportNumpy2]$ gcc -o with_numpy2 -I /usr/include/python3.6m with_numpy2.c -L /usr/bin/python3.6-config -lpython3.6m
[jibarra at redsky ImportNumpy2]$ ./with_numpy2
Result of: 2 * 2
Return of call : 4
Segmentation fault (core dumped)

I can confirm that I do have numpy library:
[jibarra at redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> a = np.array([1, 2, 3])
>>> print(type(a))
<class 'numpy.ndarray'>

I have included two examples of this:
Two_Import_Call
  Has a in-depth call to Python file,class, and variables
Two_Import_Simple
  Has a very simple call to Python file ONLY

Both as these folders contain code with the same issue regarding import statements and running the code again after Py_Finalize();


Please advise.

Thanks,
Jesse Ibarra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190625/aba25872/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python_Import_Problem.tar.gz
Type: application/gzip
Size: 1984 bytes
Desc: Python_Import_Problem.tar.gz
URL: <http://mail.python.org/pipermail/docs/attachments/20190625/aba25872/attachment-0001.bin>

From jibarra4 at live.nmhu.edu  Tue Jun 25 11:23:35 2019
From: jibarra4 at live.nmhu.edu (Ibarra, Jesse)
Date: Tue, 25 Jun 2019 15:23:35 +0000
Subject: [docs] Python Embedding PyImport_ImportModule
Message-ID: <SN4PR0201MB355282842F02A3914AA4D05AD3E30@SN4PR0201MB3552.namprd02.prod.outlook.com>

I am running CentOS7:

[jibarra at redsky ~]$ uname -a
Linux redsky.lanl.gov 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

I am using Python3.6:
[jibarra at redsky ~]$ python3.6
Python 3.6.8 (default, Apr 25 2019, 21:02:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>


I was sucessfully ran example:
https://docs.python.org/3.6/extending/embedding.html#very-high-level-embedding

I am sucessfully ran https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.minimize.html example and named it Rosenbrock_Function.py:

from scipy.optimize import minimize, rosen, rosen_der
x0 = [1.3, 0.7, 0.8, 1.9, 1.2]
res = minimize(rosen, x0, method='Nelder-Mead', tol=1e-6)
print(res.x)

I then embedded the example using C/Python API:
https://docs.python.org/3.6/extending/embedding.html#pure-embedding

int main(){
  PyObject *pModule, *pName;

  Py_Initialize();
  PyRun_SimpleString("import sys");
  PyRun_SimpleString("sys.path.append('.')");

  pModule = PyImport_ImportModule("Rosenbrock_Function");
  pName = PyImport_ImportModule("Rosenbrock_Function");

  Py_XDECREF(pModule);
  Py_XDECREF(pName);

  Py_Finalize();

  return 0;
}


Why does this code only print the result(array([ 1.,  1.,  1.,  1.,  1.])) once, when I am calling the python code twice?

Please advise,
Jesse Ibarra



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190625/25cd8c34/attachment.html>

From report at bugs.python.org  Tue Jun 25 17:01:17 2019
From: report at bugs.python.org (Brent Gardner)
Date: Tue, 25 Jun 2019 21:01:17 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
Message-ID: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>


New submission from Brent Gardner <bggardner at gmail.com>:

In Python 3.5.3, a socket with type AF_CAN returns a tuple in the form `(interface, )` from getsockname().  In Python 3.7.3, getsockname() returns a string (the name of the interface).  The documentation states "a tuple is used for the AF_CAN address family".  The string will break code that worked in 3.5.3 by raising errors such as "Value Error: too many values to unpack (expected 2)".

Example:

#3.5.3
import socket
s = socket.socket(socket.AF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
s.bind(('vcan0',)) # requires tuple
s.getsockname() # returns tuple: ('vcan0', 29)

#3.7.3
import socket
s = socket.socket(socket.AF_CAN, socket.SOCK_RAW, socket.CAN_RAW)
s.bind(('vcan0',)) # requires tuple
s.getsockname() # returns string: 'vcan0'

----------
assignee: docs at python
components: Documentation
messages: 346559
nosy: Brent Gardner, docs at python
priority: normal
severity: normal
status: open
title: socket.getsockname() returns string instead of tuple
versions: Python 3.7

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

From report at bugs.python.org  Tue Jun 25 17:01:33 2019
From: report at bugs.python.org (Brent Gardner)
Date: Tue, 25 Jun 2019 21:01:33 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1561496493.15.0.420917176308.issue37405@roundup.psfhosted.org>


Change by Brent Gardner <bggardner at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Jun 25 22:51:26 2019
From: report at bugs.python.org (Brent Gardner)
Date: Wed, 26 Jun 2019 02:51:26 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1561517486.62.0.595922102497.issue37405@roundup.psfhosted.org>


Brent Gardner <bggardner at gmail.com> added the comment:

Changed caused by commit effc12f8e9e20d0951d2ba5883587666bd8218e3 to cpython/Modules/socketmodule.c on Sep 6, 2017.

----------
components: +Extension Modules

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

From report at bugs.python.org  Tue Jun 25 22:54:32 2019
From: report at bugs.python.org (Brent Gardner)
Date: Wed, 26 Jun 2019 02:54:32 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1561517672.56.0.041733851545.issue37405@roundup.psfhosted.org>


Brent Gardner <bggardner at gmail.com> added the comment:

Correction, change caused by a30f6d45ac3e72761b96a8df0527182029eaee24 to cpython/Modules/socketmodule.c on Aug 28, 2017.

----------

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

From report at bugs.python.org  Tue Jun 25 23:51:49 2019
From: report at bugs.python.org (Giovanni Cappellotto)
Date: Wed, 26 Jun 2019 03:51:49 +0000
Subject: [docs] [issue13127] xml.dom.Attr.name is not labeled as read-only
In-Reply-To: <1318047492.07.0.217686953928.issue13127@psf.upfronthosting.co.za>
Message-ID: <1561521109.19.0.73619285844.issue13127@roundup.psfhosted.org>


Giovanni Cappellotto <potomak84 at gmail.com> added the comment:

I took a quick look at `minidom.py` and `test_minidom.py`. It seems that you should always use `doc.renameNode(attr, namespace, new_name)` for renaming an attribute (or an element).

When `doc.renameNode` is applied on an attribute node, it removes the attribute from the `ownerElement` and re-set it after renaming it.

For instance:

```
>>> import xml.dom.minidom
>>> from xml.dom import minidom
>>> doc = minidom.parseString("<a href=\"http://foo.com\">foo</a>")
>>> attr = doc.childNodes[0].attributes.item(0)
>>> doc.renameNode(attr, xml.dom.EMPTY_NAMESPACE, "bar")
<xml.dom.minidom.Attr object at 0x7fb27d7ddb00>
>>> doc.toxml()
'<?xml version="1.0" ?><a bar="http://foo.com">foo</a>'
```

I agree that this behavior should be documented somewhere.

Maybe there should be a note/warning in the `name` attribute description. It should says that resetting an attribute `name` won't change the document representation and that `doc.renameNode` should be used instead.

Another approach may be to update the `name` setter implementation to remove and then re-set the attribute in the `ownerElement`.

What do you think it's the best approach:

1. update the doc
2. update the `name` setter implementation

I'd be happy to help to fix this issue.

----------
nosy: +potomak

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

From report at bugs.python.org  Wed Jun 26 01:31:55 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 26 Jun 2019 05:31:55 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1561527115.48.0.521724955803.issue37405@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Jun 26 05:51:57 2019
From: report at bugs.python.org (Cheuk Ting Ho)
Date: Wed, 26 Jun 2019 09:51:57 +0000
Subject: [docs] [issue36661] Missing dataclass decorator import in
 dataclasses module docs
In-Reply-To: <1555616208.44.0.536731608649.issue36661@roundup.psfhosted.org>
Message-ID: <1561542717.46.0.286025415851.issue36661@roundup.psfhosted.org>


Cheuk Ting Ho <cheukting.ho at gmail.com> added the comment:

I agree that for the more confusing ones, it would be better to write out the import statement explicitly.

----------
nosy: +Cheukting

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

From report at bugs.python.org  Wed Jun 26 08:01:59 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 26 Jun 2019 12:01:59 +0000
Subject: [docs] [issue37405] socket.getsockname() returns string instead of
 tuple
In-Reply-To: <1561496477.42.0.179203753139.issue37405@roundup.psfhosted.org>
Message-ID: <1561550519.7.0.914276352214.issue37405@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +14206
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14392

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

From report at bugs.python.org  Wed Jun 26 13:57:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Jun 2019 17:57:05 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561571825.75.0.0504276311298.issue37390@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +14218
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14406

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

From report at bugs.python.org  Wed Jun 26 13:59:30 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 26 Jun 2019 17:59:30 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561571970.46.0.237198807034.issue37390@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think my PR is ready. I had to go through and update all the audit-event tags that existed, since the argument parsing in Sphinx didn't work the way I first thought it did, but now we can provide a back reference manually (or let it auto-generate one to the line with the event).

I also updated some of the event names I recently added so they are more consistent with the existing ones - e.g. poplib.POP3 -> poplib.connect for consistency with socket.connect.

----------

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

From report at bugs.python.org  Wed Jun 26 19:46:04 2019
From: report at bugs.python.org (Jim Li)
Date: Wed, 26 Jun 2019 23:46:04 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
Message-ID: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>


New submission from Jim Li <jimli at bcgsc.ca>:

In Python 2, `__path__` used to be a list, so all of the operations available to list are available, e.g., `insert`; you can also do indexing; e.g., `__path__[0]`.

However, I believe that starting from Python 3, it seems to be a <class '_frozen_importlib_external._NamespacePath'>, and a lot of operations that worked previously stopped working.It seems so abruptive and I can't find any deprecation notice on this.

Previously, one is able to insert an additional path to the front of the list by doing

module.__path__.insert(0, 'src/mypath')

Now the only procedure allowed seems to be append. Is there any way to mimic the old behaviour? Sorry, this is my first question so maybe this issue doesn't deserve any more attention. If there is any documentation that talks about the change of type of the NamespacePath, please kindly lemme know.

Sincerely,

Related issues include https://bugs.python.org/issue35843

----------
assignee: docs at python
components: Documentation
messages: 346701
nosy: docs at python, jimli
priority: normal
severity: normal
status: open
title: Documentation on the change of __path__ in Python 3
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Jun 26 20:10:00 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 27 Jun 2019 00:10:00 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561594200.76.0.307831241674.issue37422@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you provide a short runnable example that used to work and now does not? And please show any error messages you're seeing.

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

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

From report at bugs.python.org  Thu Jun 27 11:39:32 2019
From: report at bugs.python.org (bob gailer)
Date: Thu, 27 Jun 2019 15:39:32 +0000
Subject: [docs] [issue37430] range is not a built-in function
Message-ID: <1561649972.91.0.461406342746.issue37430@roundup.psfhosted.org>


New submission from bob gailer <bgailer at gmail.com>:

In section 8.3 The for statement there is a reference to range as a built-in function. That was true in python 2. Now range is a built-in type.

----------
assignee: docs at python
components: Documentation
messages: 346745
nosy: bgailer, docs at python
priority: normal
severity: normal
status: open
title: range is not a built-in function
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Jun 27 12:19:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 27 Jun 2019 16:19:19 +0000
Subject: [docs] [issue37430] range is not a built-in function
In-Reply-To: <1561649972.91.0.461406342746.issue37430@roundup.psfhosted.org>
Message-ID: <1561652359.92.0.988981448701.issue37430@roundup.psfhosted.org>


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

I presume you are referring to 8.3 of the language reference
https://docs.python.org/3/reference/compound_stmts.html#the-for-statement
which has "the built-in function range()".  Types/classes *are* functions, which is why dist, list, range, etc are listed in "Built-in Functions" in the library reference.  But I agree that the more specific term should be used.

To me, the more severe problem is with the complete sentence.

"Hint: the built-in function range() returns an iterator of integers suitable to emulate the effect of Pascal?s for i := a to b do; e.g., list(range(3)) returns the list [0, 1, 2]."

The now obsolete definition of Python in terms of the now obscure Pascal should be deleted here and anywhere else such remains.  I think the whole sentence should just be deleted.  The whole paragraph and example could otherwise be improved.

----------
nosy: +terry.reedy
versions: +Python 3.9 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu Jun 27 12:32:09 2019
From: report at bugs.python.org (Jim Li)
Date: Thu, 27 Jun 2019 16:32:09 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561653129.68.0.539305158022.issue37422@roundup.psfhosted.org>


Jim Li <jimli at bcgsc.ca> added the comment:

Hi Eric,

Sorry for the late reply. I think I did not accurately describe the issue at all. As a minimal example, set up two virtual environments, one from 2.7.x, one from 3.7.2.

When you are in the virtual environment, do
- pip install protobuf==3.3.0
- python (to go into compiler)
- import google
- print(type(google.__path__))

The 2.7.x would tell you it's a <type 'list'>
The 3.7.2 would tell you it's a <class'_frozen_importlib_external._NamespacePath'>

Since it's not a list, some behaviours are gone, e.g., insert. I'm not trying to manipulate protobuf package's __path__, but trying to upgrade a legacy codebase, the legacy codebase does something like:

module.insert(0, 'some/path'), which breaks under python3, because it's not a list anymore, but a <class'_frozen_importlib_external._NamespacePath'>.


I believe the problem comes from the 'top level entry point'. For example, when you have 2 separate packages but they were organized under the same namespace.

E.g., in their setup.py

Package A:

    packages=[
        "orange",
        "orange.schemas",
    ],
    namespace_packages=["orange"]

Package B:
    packages=[
        "orange",
        "orange.server",
    ],
    namespace_packages=["orange"]

The problem comes from when you try to do `import orange`, and do operations with orange.__path__ here. In Python 2.7, it's a list; in Python 3.7, it's a <class '_frozen_importlib_external._NamespacePath'>

----------

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

From report at bugs.python.org  Thu Jun 27 13:04:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Jun 2019 17:04:31 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561655071.16.0.885729666588.issue37422@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Thu Jun 27 13:48:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 27 Jun 2019 17:48:04 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561657684.08.0.131651162465.issue37390@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 44f91c388a6f4da9ed3300df32ca290b8aa104ea by Steve Dower in branch 'master':
bpo-37390: Add audit event table to documentations (GH-14406)
https://github.com/python/cpython/commit/44f91c388a6f4da9ed3300df32ca290b8aa104ea


----------

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

From report at bugs.python.org  Thu Jun 27 13:48:15 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Jun 2019 17:48:15 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561657695.77.0.233815833872.issue37390@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14245
pull_request: https://github.com/python/cpython/pull/14429

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

From report at bugs.python.org  Thu Jun 27 14:01:45 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 27 Jun 2019 18:01:45 +0000
Subject: [docs] [issue37432] Fix a small param type allocation.rst
Message-ID: <1561658505.32.0.73660058325.issue37432@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: Fix a small param type allocation.rst
type: behavior

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

From report at bugs.python.org  Thu Jun 27 14:03:06 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 27 Jun 2019 18:03:06 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
Message-ID: <1561658586.02.0.0640570834715.issue37432@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
title: Fix a small param type allocation.rst -> Fix a small param type in allocation.rst

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

From report at bugs.python.org  Thu Jun 27 14:04:17 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 27 Jun 2019 18:04:17 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
Message-ID: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>


New submission from SilentGhost <ghost.adh at runbox.com>:

Could you please elaborate on what exactly needs fixing?

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

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

From report at bugs.python.org  Thu Jun 27 14:05:06 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 27 Jun 2019 18:05:06 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561658706.03.0.756673593293.issue37432@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +14246
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14430

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

From report at bugs.python.org  Thu Jun 27 14:07:12 2019
From: report at bugs.python.org (hai shi)
Date: Thu, 27 Jun 2019 18:07:12 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561658832.47.0.864721385463.issue37432@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Due to https://github.com/python/cpython/blob/master/Include/objimpl.h#L102,
`void PyObject_Del(PyObject *op)` should be `void PyObject_Del(void *op)`

----------

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

From report at bugs.python.org  Thu Jun 27 14:07:20 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Jun 2019 18:07:20 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561658840.52.0.861696868234.issue37390@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4fee28aa42dbac7f08a6d2829546b7d8e848034d by Miss Islington (bot) in branch '3.8':
bpo-37390: Add audit event table to documentations (GH-14406)
https://github.com/python/cpython/commit/4fee28aa42dbac7f08a6d2829546b7d8e848034d


----------
nosy: +miss-islington

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

From report at bugs.python.org  Thu Jun 27 14:10:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 27 Jun 2019 18:10:20 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561659020.67.0.655639937781.issue37390@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


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

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

From report at bugs.python.org  Thu Jun 27 19:00:47 2019
From: report at bugs.python.org (bob gailer)
Date: Thu, 27 Jun 2019 23:00:47 +0000
Subject: [docs] [issue37430] range is not a built-in function
In-Reply-To: <1561649972.91.0.461406342746.issue37430@roundup.psfhosted.org>
Message-ID: <1561676447.11.0.719620949302.issue37430@roundup.psfhosted.org>


bob gailer <bgailer at gmail.com> added the comment:

Thanks for explaining. Indeed range appears in __builtins__. It is a surprise to type range and get <class 'range'> in response. sum otoh gives <built-in function sum>. The distinction between function, type and class seems muddy.

When I enter "range" in the index box in the windows documentation display I am offered: 

(1)built-in function, which takes me to the paragraph that started this issue. It does NOT take me to the built-in functions topic, whereas sum does.

(2) object, and range (built-in class)which take me to the built-in types topic. This seems to add to the confusion.

----------

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

From report at bugs.python.org  Thu Jun 27 21:20:52 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 28 Jun 2019 01:20:52 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561684852.37.0.331604896932.issue37422@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

It's a _NamespacePath in 3.7 because there's no __init__.py in the top-level "google" directory, and that makes it a namespace package.

I'm not exactly sure why it works in 2.7, frankly. <time passes> Looking some more: it's because they're playing tricks in a .pth file. I don't recall what the interactions between .pth and namespace packages.

I don't know if Google really means for "google" to be a namespace package, or if it's just a side effect of how they're installing protobuf.

In any event, I don't think we want a _NamespacePath to be modifiable.

----------

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

From report at bugs.python.org  Thu Jun 27 21:21:56 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 28 Jun 2019 01:21:56 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561684916.03.0.426116149636.issue37422@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

And I see you're not asking for changed behavior, just documentation. But I think it is documented that this is how namespace packages work.

----------

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

From report at bugs.python.org  Thu Jun 27 22:37:03 2019
From: report at bugs.python.org (Jim Li)
Date: Fri, 28 Jun 2019 02:37:03 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561689423.42.0.596166004533.issue37422@roundup.psfhosted.org>


Jim Li <jimli at bcgsc.ca> added the comment:

Ah, that started to make sense. To be honest I didn't really pay much attention to the _namespace's documentation, I only looked at that of __path__ and somehow expected it to mention that certain namespace won't be a type<list> anymore.

I will re-read your comments and the docs for _namespace; I was also reading this https://www.python.org/dev/peps/pep-0420/#migrating-from-legacy-namespace-packages

Thanks for the help!

----------

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

From report at bugs.python.org  Fri Jun 28 02:40:50 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Jun 2019 06:40:50 +0000
Subject: [docs] [issue37390] Generate table of audit events for docs
In-Reply-To: <1561391164.88.0.923938823513.issue37390@roundup.psfhosted.org>
Message-ID: <1561704050.02.0.175913348394.issue37390@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks Steve, the page will serve as a good reference to all audit events.

----------

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

From report at bugs.python.org  Fri Jun 28 05:03:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 28 Jun 2019 09:03:21 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561712601.55.0.71183971994.issue37432@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset b4bee03087a3c70cb040e2ce569c828860ed8e87 by Inada Naoki (Hai Shi) in branch 'master':
bpo-37432: Doc: Fix signature of PyObject_Del() (GH-14430)
https://github.com/python/cpython/commit/b4bee03087a3c70cb040e2ce569c828860ed8e87


----------
nosy: +inada.naoki

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

From report at bugs.python.org  Fri Jun 28 05:03:23 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Jun 2019 09:03:23 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561712603.38.0.0846181623399.issue37432@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14257
pull_request: https://github.com/python/cpython/pull/14441

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

From report at bugs.python.org  Fri Jun 28 05:03:32 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Jun 2019 09:03:32 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561712612.12.0.0912385669676.issue37432@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14258
pull_request: https://github.com/python/cpython/pull/14442

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

From report at bugs.python.org  Fri Jun 28 05:16:33 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Jun 2019 09:16:33 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561713393.82.0.892091885711.issue37432@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 99f2f851773c6e481e80e8e157d9f5ad4fc5cbb3 by Miss Islington (bot) in branch '3.7':
bpo-37432: Doc: Fix signature of PyObject_Del() (GH-14430)
https://github.com/python/cpython/commit/99f2f851773c6e481e80e8e157d9f5ad4fc5cbb3


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Jun 28 05:16:39 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 28 Jun 2019 09:16:39 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561713399.19.0.0364970033362.issue37432@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ad00640f936956c3a19834b6cd12b04edf53a776 by Miss Islington (bot) in branch '3.8':
bpo-37432: Doc: Fix signature of PyObject_Del() (GH-14430)
https://github.com/python/cpython/commit/ad00640f936956c3a19834b6cd12b04edf53a776


----------

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

From report at bugs.python.org  Fri Jun 28 05:23:20 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 28 Jun 2019 09:23:20 +0000
Subject: [docs] [issue37438] ConfigParser.set() docs should mention
 allow_no_value
Message-ID: <1561713800.79.0.286500391609.issue37438@roundup.psfhosted.org>


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

Reviewing some code today, I came across a ConfigParser.set() call that only specified the section and key, with the value argument missing.

If you look at the ConfigParser.set() docs, this seems like incorrect code, as those docs indicate that the value argument is a required parameter: https://docs.python.org/3/library/configparser.html#configparser.ConfigParser.set

However, checking the code shows that:

1. "value" has a default value of None
2. if "allow_no_value" is passed to the constructor, passing "None" as the value will be interpreted as a request to add a key-only entry to the section with no equals sign

----------
assignee: docs at python
components: Documentation
messages: 346813
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: ConfigParser.set() docs should mention allow_no_value
type: enhancement
versions: Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jun 28 05:41:52 2019
From: report at bugs.python.org (hai shi)
Date: Fri, 28 Jun 2019 09:41:52 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561714912.63.0.772090971196.issue37432@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Fri Jun 28 10:28:23 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 28 Jun 2019 14:28:23 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561732103.4.0.715667502495.issue37432@roundup.psfhosted.org>


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


----------
resolution:  -> fixed

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

From report at bugs.python.org  Fri Jun 28 10:28:38 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 28 Jun 2019 14:28:38 +0000
Subject: [docs] [issue37432] Fix a small param type in allocation.rst
In-Reply-To: <1561658657.08.0.608872131801.issue37432@roundup.psfhosted.org>
Message-ID: <1561732118.39.0.816763848265.issue37432@roundup.psfhosted.org>


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


----------
versions: +Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Jun 28 13:00:06 2019
From: report at bugs.python.org (hai shi)
Date: Fri, 28 Jun 2019 17:00:06 +0000
Subject: [docs] [issue37441] Fix a param error in exceptions.rst
Message-ID: <1561741206.31.0.47580103034.issue37441@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

Due to https://github.com/python/cpython/blob/master/Python/errors.c#L845-L846,
`PyObject* PyErr_SetImportErrorSubclass(PyObject *msg, PyObject *name, PyObject *path)` should be  `PyObject* PyErr_SetImportErrorSubclass(PyObject *exception, PyObject *msg, PyObject *name, PyObject *path)`

----------
assignee: docs at python
components: Documentation
messages: 346836
nosy: docs at python, shihai1991
priority: normal
severity: normal
status: open
title: Fix a param error in exceptions.rst
type: behavior

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

From report at bugs.python.org  Fri Jun 28 13:04:57 2019
From: report at bugs.python.org (hai shi)
Date: Fri, 28 Jun 2019 17:04:57 +0000
Subject: [docs] [issue37441] Fix a param error in exceptions.rst
In-Reply-To: <1561741206.31.0.47580103034.issue37441@roundup.psfhosted.org>
Message-ID: <1561741497.14.0.114045278308.issue37441@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +14270
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14453

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

From report at bugs.python.org  Fri Jun 28 13:59:26 2019
From: report at bugs.python.org (Prateek Nayak)
Date: Fri, 28 Jun 2019 17:59:26 +0000
Subject: [docs] [issue37438] ConfigParser.set() docs should mention
 allow_no_value
In-Reply-To: <1561713800.79.0.286500391609.issue37438@roundup.psfhosted.org>
Message-ID: <1561744766.23.0.87096398376.issue37438@roundup.psfhosted.org>


Change by Prateek Nayak <lelouch.cpp at gmail.com>:


----------
keywords: +patch
pull_requests: +14272
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/14455

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

From report at bugs.python.org  Fri Jun 28 17:17:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Jun 2019 21:17:23 +0000
Subject: [docs] [issue37422] Documentation on the change of __path__ in
 Python 3
In-Reply-To: <1561592764.17.0.159166057812.issue37422@roundup.psfhosted.org>
Message-ID: <1561756643.57.0.059371043784.issue37422@roundup.psfhosted.org>


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


----------
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Jun 28 17:19:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 28 Jun 2019 21:19:47 +0000
Subject: [docs] [issue37426] getpass.getpass not working with on windows
 when ctrl+v is used to enter the string
In-Reply-To: <1561628977.4.0.232389584594.issue37426@roundup.psfhosted.org>
Message-ID: <1561756787.34.0.146610864237.issue37426@roundup.psfhosted.org>


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

If anything, this seems to be a getpass doc issue.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), Windows
nosy: +docs at python, terry.reedy

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

From report at bugs.python.org  Fri Jun 28 18:26:15 2019
From: report at bugs.python.org (Jeffrey Kintscher)
Date: Fri, 28 Jun 2019 22:26:15 +0000
Subject: [docs] [issue26468] shutil.copy2 raises OSError if filesystem
 doesn't support chmod
In-Reply-To: <1456910519.95.0.44073308632.issue26468@psf.upfronthosting.co.za>
Message-ID: <1561760775.3.0.35158064713.issue26468@roundup.psfhosted.org>


Change by Jeffrey Kintscher <websurfer at surf2c.net>:


----------
nosy:  -Jeffrey.Kintscher

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

From report at bugs.python.org  Sat Jun 29 11:59:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 29 Jun 2019 15:59:20 +0000
Subject: [docs] [issue37430] range is not a built-in function
In-Reply-To: <1561649972.91.0.461406342746.issue37430@roundup.psfhosted.org>
Message-ID: <1561823960.25.0.448472398991.issue37430@roundup.psfhosted.org>


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

Then it appears the indexing could also be improved.

----------

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

From report at bugs.python.org  Sat Jun 29 18:18:45 2019
From: report at bugs.python.org (sushma)
Date: Sat, 29 Jun 2019 22:18:45 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561846725.17.0.939800213592.issue30754@roundup.psfhosted.org>


Change by sushma <sushma.y at gmail.com>:


----------
keywords: +patch
pull_requests: +14286
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/14469

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

From report at bugs.python.org  Sun Jun 30 00:20:21 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:20:21 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561868421.19.0.882552878507.issue30754@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14292
pull_request: https://github.com/python/cpython/pull/14475

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

From report at bugs.python.org  Sun Jun 30 00:20:24 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 30 Jun 2019 04:20:24 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561868424.47.0.684838821305.issue30754@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset eb97b9211e7c99841d6cae8c63893b3525d5a401 by Gregory P. Smith (tmblweed) in branch 'master':
bpo-30754: Document textwrap.dedent blank line behavior. (GH-14469)
https://github.com/python/cpython/commit/eb97b9211e7c99841d6cae8c63893b3525d5a401


----------

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

From report at bugs.python.org  Sun Jun 30 00:21:17 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:21:17 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561868477.23.0.817437469158.issue30754@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14293
pull_request: https://github.com/python/cpython/pull/14476

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

From report at bugs.python.org  Sun Jun 30 00:21:24 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:21:24 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561868484.35.0.512795882378.issue30754@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +14294
pull_request: https://github.com/python/cpython/pull/14477

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

From report at bugs.python.org  Sun Jun 30 00:27:50 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 30 Jun 2019 04:27:50 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561868870.21.0.370479267451.issue30754@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Sun Jun 30 00:38:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:38:15 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561869494.9.0.3881688151.issue30754@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e2e41cd114ae761fbfee4e7c6539f5df5c8c7116 by Miss Islington (bot) in branch '3.7':
bpo-30754: Document textwrap.dedent blank line behavior. (GH-14469)
https://github.com/python/cpython/commit/e2e41cd114ae761fbfee4e7c6539f5df5c8c7116


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Jun 30 00:40:44 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:40:44 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561869644.19.0.523379215193.issue30754@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e133c401a51f08404b68f11d921f0b406283741 by Miss Islington (bot) in branch '3.8':
bpo-30754: Document textwrap.dedent blank line behavior. (GH-14469)
https://github.com/python/cpython/commit/3e133c401a51f08404b68f11d921f0b406283741


----------

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

From report at bugs.python.org  Sun Jun 30 00:41:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 30 Jun 2019 04:41:58 +0000
Subject: [docs] [issue30754] textwrap.dedent mishandles empty lines
In-Reply-To: <1498404324.65.0.525714137023.issue30754@psf.upfronthosting.co.za>
Message-ID: <1561869718.33.0.563410358674.issue30754@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bc60c47169d1cb33f6fbe1ed64c09a536e82e1c3 by Miss Islington (bot) in branch '2.7':
[2.7] bpo-30754: Document textwrap.dedent blank line behavior. (GH-14469) (GH-14475)
https://github.com/python/cpython/commit/bc60c47169d1cb33f6fbe1ed64c09a536e82e1c3


----------

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

From report at bugs.python.org  Sun Jun 30 04:09:11 2019
From: report at bugs.python.org (Avinash Sajjanshetty)
Date: Sun, 30 Jun 2019 08:09:11 +0000
Subject: [docs] [issue36689] docs: os.path.commonpath raises ValueError for
 different drives
In-Reply-To: <1555837758.83.0.507858438764.issue36689@roundup.psfhosted.org>
Message-ID: <1561882151.59.0.734045535109.issue36689@roundup.psfhosted.org>


Avinash Sajjanshetty <hi at avi.im> added the comment:

status of issue should be closed? cos the related PR is already merged

----------
nosy: +avi

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

From report at bugs.python.org  Sun Jun 30 04:34:42 2019
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Jun 2019 08:34:42 +0000
Subject: [docs] [issue36689] docs: os.path.commonpath raises ValueError for
 different drives
In-Reply-To: <1555837758.83.0.507858438764.issue36689@roundup.psfhosted.org>
Message-ID: <1561883682.1.0.956012974554.issue36689@roundup.psfhosted.org>


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

Yes, sure

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

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

From 12358.sunila at gmail.com  Sat Jun 29 10:56:49 2019
From: 12358.sunila at gmail.com (Sunil Bahelia)
Date: Sat, 29 Jun 2019 20:26:49 +0530
Subject: [docs] discrepancy in result by hex()
Message-ID: <CANcpMDbEgX5vB+=2TeK_727A6C0WbXFSUZD1+Ve3gqN+e=7Rrg@mail.gmail.com>

The hex() works fine overall but for numbers less than 16 it doesn't gives
right output
for e.g
>>> hex(15)
'0xf'
where it should have been '0x0f'

I have built a method to do the same:
1)
def int2hex(n):
    val={
                10:"A",
                11:"B",
                12:"C",
                13:"D",
                14:"E",
                15:"F"
                }
    s=""
    if(n<0):
        print("negative number not allowed")
        return
    if(n<16):
        if(n<10):
            return "0x0"+str(n)
        else:
            return "0x"+val.get(n)
    while(n>0):
        z=n%16
        if(z<10):
            s=s+str(z)
        else:
            s=s+val.get(z)
        n=n//16

    return "0x"+s

*OR*
*#using hex function*
def int2hex(n):
    val={
                10:"A",
                11:"B",
                12:"C",
                13:"D",
                14:"E",
                15:"F"
                }
    s=""
    if(n<16):
        if(n<10):
            return "0x0"+str(n)
        else:
            return "0x"+val.get(n)
    else:
        return hex(n)


Regards,
Sunil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20190629/538bdb49/attachment.html>

From report at bugs.python.org  Sun Jun 30 08:23:03 2019
From: report at bugs.python.org (Avinash Sajjanshetty)
Date: Sun, 30 Jun 2019 12:23:03 +0000
Subject: [docs] [issue36497] Undocumented behavior in csv.Sniffer (preferred
 delimiters)
In-Reply-To: <1554126856.48.0.397677994988.issue36497@roundup.psfhosted.org>
Message-ID: <1561897383.12.0.170254543605.issue36497@roundup.psfhosted.org>


Avinash Sajjanshetty <hi at avi.im> added the comment:

can I take up this issue?

----------
nosy: +avi

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

From report at bugs.python.org  Sun Jun 30 18:19:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 30 Jun 2019 22:19:38 +0000
Subject: [docs] [issue37454] Clarify docs for math.log1p()
Message-ID: <1561933178.32.0.315765765879.issue37454@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Currently the docs say, "The result is calculated in a way which is accurate for x near zero."

That is somewhat vague.  Some quick tests show that it is often more accurate than log() for the whole range of 0.0 < x < 1.0; however, for x < 0.0 it is always worse.

Since the function is just a pass-through to the C library, we probably can't make any guarantees.  On the other hand, it is hard to know when this function is preferred without some guidance.

----------
assignee: docs at python
components: Documentation
files: study_log1p.py
messages: 346942
nosy: docs at python, mark.dickinson, rhettinger, tim.peters
priority: low
severity: normal
status: open
title: Clarify docs for math.log1p()
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48448/study_log1p.py

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

From report at bugs.python.org  Sun Jun 30 20:09:37 2019
From: report at bugs.python.org (SoniEx2)
Date: Mon, 01 Jul 2019 00:09:37 +0000
Subject: [docs] [issue37456] FAQ says positional arguments aren't a thing
Message-ID: <1561939777.04.0.384153036015.issue37456@roundup.psfhosted.org>


New submission from SoniEx2 <fakedme at gmail.com>:

https://docs.python.org/3.8/faq/programming.html#what-does-the-slash-in-the-parameter-list-of-a-function-mean

"Note that as of this writing this is only documentational and no valid syntax in Python, although there is PEP 570, which proposes a syntax for position-only parameters in Python."

>From what I understand, they are now a thing. Perhaps it's time to take that out?

----------
assignee: docs at python
components: Documentation
messages: 346947
nosy: SoniEx2, docs at python
priority: normal
severity: normal
status: open
title: FAQ says positional arguments aren't a thing
versions: Python 3.8

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

From report at bugs.python.org  Sun Jun 30 22:51:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 01 Jul 2019 02:51:49 +0000
Subject: [docs] [issue37456] FAQ says positional arguments aren't a thing
In-Reply-To: <1561939777.04.0.384153036015.issue37456@roundup.psfhosted.org>
Message-ID: <1561949509.33.0.821687998502.issue37456@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal

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