From zachary.ware+pydocs at gmail.com  Sat Sep  1 21:51:08 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Sat, 1 Sep 2018 20:51:08 -0500
Subject: [docs] Bug in the glossary documentation.
In-Reply-To: <10328101535302858@sas2-db6b18f976b3.qloud-c.yandex.net>
References: <10328101535302858@sas2-db6b18f976b3.qloud-c.yandex.net>
Message-ID: <CAKJDb-PaGA-ULrwGqvBXqTKQGZE4SOcKAMkbuOnYaHVUV9W9Yw@mail.gmail.com>

On Sat, Sep 1, 2018 at 8:35 PM ?????? ???????? <zoodss at yandex.ru> wrote:
> Term struct sequence, the word "ether" repeated 2 times in the row here: "elements can either be accessed either by index or as an attribute."
>
> I suggest: "elements can ether be accessed by index or as an attribute."
>
> Link - https://docs.python.org/3/glossary.html#term-struct-sequence

Thanks for the report!  This will be fixed by
https://github.com/python/cpython/pull/9030, which will be backported
to all active branches shortly.

> Sorry for poor English.

Your English is quite good enough to catch this error for us, no need
to apologize! :)

-- 
Zach

From report at bugs.python.org  Sun Sep  2 04:02:24 2018
From: report at bugs.python.org (Lorenz Mende)
Date: Sun, 02 Sep 2018 08:02:24 +0000
Subject: [docs] [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1535875344.18.0.56676864532.issue23460@psf.upfronthosting.co.za>


Lorenz Mende <lorenz.mende at gmail.com> added the comment:

I want to bring this issue up again.
As the others correctly stated, either the documentation or the implementation of Decimal 'g' formatting is incorrect.

For floats the implementation suits the docu:
>>> '{:g}'.format(0.00001)
'1e-05'
For decimals:
>>> '{:g}'.format(decimal.Decimal('0.00001'))
'0.00001'

As there is a deviation between documentation and implementation, I advise to modify one of both.

----------
nosy: +LorenzMende

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

From report at bugs.python.org  Sun Sep  2 12:16:15 2018
From: report at bugs.python.org (Windson Yang)
Date: Sun, 02 Sep 2018 16:16:15 +0000
Subject: [docs] [issue34552] Clarify built-in types comparisons
In-Reply-To: <1535693872.67.0.56676864532.issue34552@psf.upfronthosting.co.za>
Message-ID: <1535904975.22.0.902498594338.issue34552@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  2 14:23:40 2018
From: report at bugs.python.org (Tom Berry)
Date: Sun, 02 Sep 2018 18:23:40 +0000
Subject: [docs] [issue34564] Tutorial Section 2.1 Windows Installation Path
 Correction
Message-ID: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za>


New submission from Tom Berry <tom.berryx at gmail.com>:

The listed installation location is incorrect in the 02 Sep 18 release of the tutorial. It shows the default install path as C:\python36 vice C:\Program Files\python37. 

This may be related to an installer issue, as installing single-user places the program in an entirely different directory. Changing the installer to default back to C:\python37 would remove the need to differentiate Program Files (x86) for a 32-bit installer, as well as Program Files\ for the 64-bit. 

Corrected Tutorial attached reflecting change FROM C:\python36 TO C:\Program Files\Python37.

----------
assignee: docs at python
components: Documentation
files: Tutorial_EDIT.pdf
messages: 324482
nosy: aperture, docs at python
priority: normal
severity: normal
status: open
title: Tutorial Section 2.1 Windows Installation Path Correction
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47781/Tutorial_EDIT.pdf

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

From report at bugs.python.org  Sun Sep  2 21:44:21 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:44:21 +0000
Subject: [docs] [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939061.17.0.56676864532.issue34500@psf.upfronthosting.co.za>


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

The change to Tools/scripts/diff.py us effectively a backport of the the patch merged for #7582. The git log  labels it as a2637729f23dc993e820fd92f0d1759ad714c9b2.

The change to Doc/library/difflib.rst does not apply to current 3.x as the test code is no longer present.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Sun Sep  2 21:48:17 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:48:17 +0000
Subject: [docs] [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939297.39.0.56676864532.issue34500@psf.upfronthosting.co.za>


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


New changeset 30af2e737aad427d4da97f8dadeeecff6c2b28f5 by Terry Jan Reedy (Micka?l Schoentgen) in branch '2.7':
bpo-34500: Fix ResourceWarning in difflib.py (GH-8926)
https://github.com/python/cpython/commit/30af2e737aad427d4da97f8dadeeecff6c2b28f5


----------

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

From report at bugs.python.org  Sun Sep  2 21:50:50 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 03 Sep 2018 01:50:50 +0000
Subject: [docs] [issue34500] Fix ResourceWarning in difflib.py
In-Reply-To: <1535209778.67.0.56676864532.issue34500@psf.upfronthosting.co.za>
Message-ID: <1535939450.06.0.56676864532.issue34500@psf.upfronthosting.co.za>


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

Using 'with open' is now standard.  Thanks for the update.
In the message above, /us/is/.

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

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

From report at bugs.python.org  Mon Sep  3 11:55:43 2018
From: report at bugs.python.org (Grant Jenks)
Date: Mon, 03 Sep 2018 15:55:43 +0000
Subject: [docs] [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1535990143.63.0.902498594338.issue34549@psf.upfronthosting.co.za>


Change by Grant Jenks <grant.jenks at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep  3 17:50:11 2018
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 03 Sep 2018 21:50:11 +0000
Subject: [docs] [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1536011411.59.0.56676864532.issue13081@psf.upfronthosting.co.za>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As far as I can tell, this was an application bug in multiprocessing cleanup 7 years ago.  I'm not sure there's really even anything to add to the docs for this, but if anyone disagrees or produces a patch, please reopen.

----------
nosy: +davin, pitrou, zach.ware
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep  4 03:14:15 2018
From: report at bugs.python.org (ron)
Date: Tue, 04 Sep 2018 07:14:15 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1536045255.04.0.56676864532.issue16438@psf.upfronthosting.co.za>


ron <ron at mailinator.com> added the comment:

Any progress on this?

----------
nosy: +ronron

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

From report at bugs.python.org  Tue Sep  4 07:00:46 2018
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 04 Sep 2018 11:00:46 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1536058846.07.0.902498594338.issue16438@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep  4 08:42:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 04 Sep 2018 12:42:52 +0000
Subject: [docs] [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536064972.66.0.56676864532.issue34549@psf.upfronthosting.co.za>


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

Are you asking for a separate section grouping together all the assert methods from different parts which I think is useful. If you are looking for a better link then there is a link in the below text at the start of the page 

> If you are already familiar with the basic concepts of testing, you might want to skip to the list of assert methods.

The text "list of assert methods" links to https://docs.python.org/3.7/library/unittest.html#assert-methods which I hope is what you are looking for.


Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep  4 09:37:29 2018
From: report at bugs.python.org (Nick)
Date: Tue, 04 Sep 2018 13:37:29 +0000
Subject: [docs] [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536068249.12.0.56676864532.issue34549@psf.upfronthosting.co.za>


Nick <manifes7o at gmail.com> added the comment:

Ah, yes! Was searching for one of those helpful "Permalink to this ___" options. Didn't even see the link at the top.

Thank you!

----------

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

From report at bugs.python.org  Wed Sep  5 11:37:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 05 Sep 2018 15:37:22 +0000
Subject: [docs] [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536161842.49.0.56676864532.issue34549@psf.upfronthosting.co.za>


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

You're welcome. Feel free to close this if it answers your question.

Thanks

----------

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

From report at bugs.python.org  Wed Sep  5 12:27:20 2018
From: report at bugs.python.org (Nick)
Date: Wed, 05 Sep 2018 16:27:20 +0000
Subject: [docs] [issue34549] unittest docs could use another header
In-Reply-To: <1535640487.61.0.56676864532.issue34549@psf.upfronthosting.co.za>
Message-ID: <1536164840.32.0.902498594338.issue34549@psf.upfronthosting.co.za>


Change by Nick <manifes7o at gmail.com>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Sep  5 16:39:26 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 05 Sep 2018 20:39:26 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
Message-ID: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

https://docs.python.org/3.8/howto/logging.html#configuring-logging-for-a-library is a bit too short and doesn't answer some questions that I have as a library author about the best ways to use logging in a library.

Should I make use of a single logger object in my library, multiple loggers in a tree, or multiple unrelated loggers? Since I have just one public module, I'm tempted to say that I should just use one logger object.

Should I present as part of my public API the name of the logger object(s) used? Probably - the documentation starts with "When developing a library which uses logging, you should take care to document how the library uses logging - for example, the names of loggers used.". But should I also include the logger objects in my API? If an application wants to reach my logger, why should they use "logging.getLogger(<name that I shared with them>)" rather than "my_library.LOGGER"?

Should I use my library's fully-qualified name as the name of its logger? This seems like a great idea because it's unlikely to bring up any new conflicts. Is it a best practice? Is there any better practice?

The "Configuring Logging for a Library" text could answer these questions, and maybe it should, but... I really think a toy library example that library authors could follow would also help a great deal.

----------
assignee: docs at python
components: Documentation
messages: 324652
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: "Logging HOWTO" should share an example of best practices for using logging in a library
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep  6 00:54:17 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 06 Sep 2018 04:54:17 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536209657.69.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

FWIW, I think the practices vary somewhat widely and that none of your questions have generally agreed upon answers.  Part of the reason that there are so many ways to go is that the package was modeled after Java APIs where the practices and needs were also widely varied.  Given the absence of clear-cut best practices, the docs should probably defer to StackOverflow and various blog posts.

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

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

From report at bugs.python.org  Thu Sep  6 03:40:50 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 06 Sep 2018 07:40:50 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536219650.69.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

Seems like an extra note is reasonable here. I have created a PR for this. Feedback welcome on the wording.

Thanks.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.8

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

From zoodss at yandex.ru  Tue Sep  4 03:35:30 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Tue, 04 Sep 2018 10:35:30 +0300
Subject: [docs] Bug in the glossary documentation.
In-Reply-To: <CAKJDb-PaGA-ULrwGqvBXqTKQGZE4SOcKAMkbuOnYaHVUV9W9Yw@mail.gmail.com>
References: <10328101535302858@sas2-db6b18f976b3.qloud-c.yandex.net>
 <CAKJDb-PaGA-ULrwGqvBXqTKQGZE4SOcKAMkbuOnYaHVUV9W9Yw@mail.gmail.com>
Message-ID: <2156531536046530@iva7-7c2970ec7645.qloud-c.yandex.net>

Thank you, good sir! Will try to help again!

02.09.2018, 04:51, "Zachary Ware" <zachary.ware+pydocs at gmail.com>:
> On Sat, Sep 1, 2018 at 8:35 PM ?????? ???????? <zoodss at yandex.ru> wrote:
>> ?Term struct sequence, the word "ether" repeated 2 times in the row here: "elements can either be accessed either by index or as an attribute."
>>
>> ?I suggest: "elements can ether be accessed by index or as an attribute."
>>
>> ?Link - https://docs.python.org/3/glossary.html#term-struct-sequence
>
> Thanks for the report! This will be fixed by
> https://github.com/python/cpython/pull/9030, which will be backported
> to all active branches shortly.
>
>> ?Sorry for poor English.
>
> Your English is quite good enough to catch this error for us, no need
> to apologize! :)
>
> --
> Zach

--?
? ?????????,
ZooDSS
ZooDSS at yandex.ru


From jcmueller at arcor.de  Tue Sep  4 10:17:12 2018
From: jcmueller at arcor.de (=?UTF-8?Q?Johannes_M=c3=bcller?=)
Date: Tue, 4 Sep 2018 16:17:12 +0200
Subject: [docs] =?utf-8?q?Doc_-_1=2E4=2E_The_Module=E2=80=99s_Method_Tabl?=
 =?utf-8?q?e_and_Initialization_Function?=
Message-ID: <e952970c-8292-d0bd-ffa3-f1c61f64e7d2@arcor.de>

Hi,

It seems like there is a small bug (or a missing detail) in the example 
code of the main function in Chapter "1.4. The Module?s Method Table and 
Initialization Function 
<https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function>".

In the example, the return value of PyImport_ImportModule is discarded. 
In my experience, this may cause a crash in Py_Finalize() if the return 
value is discarded and Py_DECREF is omitted.

Is my assumption correct that the example should actually be extended as 
follows?

> ??? ...
>
> ??? /* Optionally import the module; alternatively,
> ?????? import can be deferred until the embedded script
> ?????? imports it. */
> PyObject *pModule = PyImport_ImportModule("spam");
>
> ??? ...
>
> ??? Py_DECREF(pModule);
> ??? if (Py_FinalizeEx() < 0) {
> ??????? exit(120);
> ??? }
> ??? PyMem_RawFree(program);
> ??? return 0;

Note that I assume that the developer is supposed to keep a reference of 
the module object, such that the garbage collection cannot free the 
module, while the program is using the interpreter. Is this necessary? 
Or can I be 100% sure that the imported module will exist and do it's 
job until I call Py_FinalizeEx(), even if I don't keep a reference of 
the module, i.e., if I decref pModule directly after importing it?

Regards,
Johannes

PS: In my case, the module is a Python output redirector, that's not 
explicitly used in the executed Python scripts and snippets. It is just 
supposed to redirect the output of the entire Python interpreter until I 
call Py_Finalize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180904/dd3a06d8/attachment-0001.html>

From report at bugs.python.org  Thu Sep  6 11:49:54 2018
From: report at bugs.python.org (Tim Lesher)
Date: Thu, 06 Sep 2018 15:49:54 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536248994.35.0.902498594338.issue34590@psf.upfronthosting.co.za>


Change by Tim Lesher <tlesher at gmail.com>:


----------
nosy: +tlesher

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

From report at bugs.python.org  Thu Sep  6 15:17:38 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 06 Sep 2018 19:17:38 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536261458.44.0.56676864532.issue34590@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

Something... related, that may perhaps belong in a separate issue, but that I want to at least mention here because it would be solved if logging-in-libraries best practices were authoritatively documented and exemplified: it's just too consarn easy to "hold [the logging module] wrong" and wind up with "No handlers could be found for logger" log spam: https://www.google.ca/search?q=site:stackoverflow.com+"No+handlers+could+be+found+for+logger". Why should a Logger object need to have .basicConfig() called on it after retrieval (where "retrieval" means "getLogger call") and before use anyway? Why can't it just be ready for use (at least as ready for use as .basicConfig makes it) when passed from the logging module to the logging-using module like nearly any other object passed from the standard library to standard-library-using code?

(The documentation says "No handlers could be found for logger" spam only happens pre-3.2, but some of my users at least think they see it in later Pythons.)

----------

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

From report at bugs.python.org  Thu Sep  6 23:33:00 2018
From: report at bugs.python.org (wim glenn)
Date: Fri, 07 Sep 2018 03:33:00 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536291180.38.0.902498594338.issue28617@psf.upfronthosting.co.za>


Change by wim glenn <wim.glenn at gmail.com>:


----------
pull_requests: +8545
stage: commit review -> patch review

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

From report at bugs.python.org  Fri Sep  7 02:35:02 2018
From: report at bugs.python.org (David Lin)
Date: Fri, 07 Sep 2018 06:35:02 +0000
Subject: [docs] [issue34601] Typo: "which would rather raise MemoryError
 than give up", than or then?
Message-ID: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>


New submission from David Lin <david.dl.lin at nokia-sbell.com>:

https://docs.python.org/3/library/exceptions.html

exception OverflowError
Raised when the result of an arithmetic operation is too large to be represented. This cannot occur for integers (which would rather raise MemoryError than give up). However, for historical reasons, OverflowError is sometimes raised for integers that are outside a required range. Because of the lack of standardization of floating point exception handling in C, most floating point operations are not checked.

In sentence: "which would rather raise MemoryError than give up", should we use "then" instead of "than"?

Thanks,
David Lin

----------
assignee: docs at python
components: Documentation
messages: 324720
nosy: davidlin, docs at python
priority: normal
severity: normal
status: open
title: Typo: "which would rather raise MemoryError than give up", than or then?
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 04:04:41 2018
From: report at bugs.python.org (pms.coder)
Date: Fri, 07 Sep 2018 08:04:41 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536307481.07.0.56676864532.issue34590@psf.upfronthosting.co.za>


pms.coder <pms.coder at yandex.com> added the comment:

I would be happy to see such HOWTO, so we could relay on actual documentation instead of the "Internet".

I think the best approach would be to get those 10-20 questions you ( Nathaniel Manista) just asked and post them to python-dev mailing list, so senior developers/committers could answer them. 

Then we could establish the "gold standard" for logging and write about it in the HOWTO.

----------
nosy: +pms.coder

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

From report at bugs.python.org  Fri Sep  7 04:13:22 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 07 Sep 2018 08:13:22 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536308002.5.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

> Then we could establish the "gold standard" for logging and write 
> about it in the HOWTO.

There really isn't a gold standard.  There are many widely varied logging practices, each adapted to the needs of the application.  The module is complicated primarily because there are so many legitimate techniques and reasons for using those techniques.

> (The documentation says "No handlers could be found for logger" 
> spam only happens pre-3.2, but some of my users at least think
> they see it in later Pythons.)

If you find an actual error in the docs, please make a specific report so that it can be confirmed and fixed.

----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip
versions:  -Python 2.7, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Sep  7 10:22:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:22:00 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
Message-ID: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

For more context, see:

* https://github.com/antirez/redis/issues/3185
* https://www.drupal.org/node/2275877
* https://issues.apache.org/jira/browse/COUCHDB-2248
* https://github.com/django/django/pull/2692

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 324739
nosy: Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Avoid master/slave terminology
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  7 10:26:28 2018
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 07 Sep 2018 14:26:28 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536330388.2.0.56676864532.issue34605@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Do you have examples of where this occurs? 

>From https://github.com/python/cpython/search?p=1&q=master+slave&unscoped_q=master+slave I really only found the openpty function, and the man pages/argument names there already use this terminology so it wouldn't make much sense to change it there.

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

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

From report at bugs.python.org  Fri Sep  7 10:32:23 2018
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 07 Sep 2018 14:32:23 +0000
Subject: [docs] [issue34601] Typo: "which would rather raise MemoryError
 than give up", than or then?
In-Reply-To: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>
Message-ID: <1536330743.04.0.56676864532.issue34601@psf.upfronthosting.co.za>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

"than" is correct; "giving up" in this context would mean "not even trying to allocate the memory and just preemptively raising OverflowError, like non-integer numeric types with limited ranges". Rather than giving up that way, it chooses to try to allocate the huge integer and raises a MemoryError only if that fails.

----------
nosy: +josh.r

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

From report at bugs.python.org  Fri Sep  7 10:35:52 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 07 Sep 2018 14:35:52 +0000
Subject: [docs] [issue34601] Typo: "which would rather raise MemoryError
 than give up", than or then?
In-Reply-To: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>
Message-ID: <1536330952.94.0.56676864532.issue34601@psf.upfronthosting.co.za>


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

See https://www.collinsdictionary.com/dictionary/english/would-rather for an example:

> I have no information one way or the other, but I would rather he do it
> than not do it.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep  7 10:43:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:43:19 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331399.21.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

I'm working on patches to change that.

----------

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

From report at bugs.python.org  Fri Sep  7 10:43:31 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:43:31 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331411.92.0.902498594338.issue34605@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep  7 10:44:46 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:44:46 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536331486.77.0.902498594338.issue34605@psf.upfronthosting.co.za>


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


----------
pull_requests: +8554

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

From report at bugs.python.org  Fri Sep  7 10:47:03 2018
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 07 Sep 2018 14:47:03 +0000
Subject: [docs] [issue34590] "Logging HOWTO" should share an example of best
 practices for using logging in a library
In-Reply-To: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>
Message-ID: <1536331623.11.0.56676864532.issue34590@psf.upfronthosting.co.za>


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

> Should I make use of a single logger object in my library, multiple loggers
> in a tree, or multiple unrelated loggers? Since I have just one public module,
> I'm tempted to say that I should just use one logger object.

Yes. The advanced logging tutorial (part of the HOWTO) states:

"A good convention to use when naming loggers is to use a module-level logger, in each module which uses logging, named as follows:

logger = logging.getLogger(__name__)

This means that logger names track the package/module hierarchy, and it?s intuitively obvious where events are logged just from the logger name."

This seems clear enough to me. Did you look at the whole of the HOWTO? If not, I'd advise you to take the time

> (The documentation says "No handlers could be found for logger" 
> spam only happens pre-3.2, but some of my users at least think
> they see it in later Pythons.)

In 3.2, the change was made to introduce a "handler of last resort" instead of the "no handlers could be found" message, which is only printed if logging.lastResort is set to None or other "false" value (by default, it's set to a console handler at WARNING level emitting to sys.stderr). If you can give specifics of a later Python version where this happens (precise Python version, OS etc.) then we can address it.

Practices vary widely because use cases for logging are widely varied. A simple one-off script has different needs from a product with a long shelf-life, a command-line application has different needs from a long-running server application, a single-author application has different needs from one which is put together from lots of different dependencies by different authors, etc.

> Why should a Logger object need to have .basicConfig() called on
> it after retrieval (where "retrieval" means "getLogger call") and
> before use anyway?

It doesn't. If you want output, you need handlers. The basicConfig() API is just one way of attaching handlers to loggers for simple use cases. The question of handlers is also no concern of a library author, other than the NullHandler part, as the application is where logging should be configured (as mentioned in the "Configuring Logging for a Library" section).

> Then we could establish the "gold standard" for logging and write
> about it in the HOWTO.

There's no one size fits all, I'm afraid, because the package is designed to cover a wide range of use cases, not just the simplest ones. While there is (IMO) comprehensive documentation, specific proposals for improvements will be looked at constructively.

----------

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

From report at bugs.python.org  Fri Sep  7 10:57:23 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:57:23 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332243.33.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

IMHO it's ok to keep the "master" term for:

* Git "master" branch
* "webmaster"
* "postmaster"

To find all impacted files, I used the commend:

git grep -i -E 'master|slave'|grep -v -E 'webmaster|postmaster|/blob/master/'

----------

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

From report at bugs.python.org  Fri Sep  7 10:58:40 2018
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 07 Sep 2018 14:58:40 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332320.26.0.56676864532.issue34605@psf.upfronthosting.co.za>


Ammar Askar <ammar at ammaraskar.com> added the comment:

The libregrtest change looks good but I disagree on the pty/openpty changes. If you look at all the current Linux man pages and documentation, they follow the master/slave terminology. Generally, Python documentation for underlying os functions like fork, stat etc are kept short because the OS documentation is the ultimate resource for them. 

This change causes a deviation from the existing standard and will only serve to make things more confusing, I would suggest deferring it until the actual OS documentation reflects this change as well.

----------

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

From report at bugs.python.org  Fri Sep  7 10:59:52 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:59:52 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332392.01.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

The doctest module has doctest.master symbol:
---
# For backward compatibility, a global instance of a DocTestRunner
# class, updated by testmod.
master = None
---

I'm not sure about changing this one. Here there is no slave, so it's less confusing.

But more generally, maybe it's time to remove this deprecated variable only kept for backward compatibility?

----------

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

From report at bugs.python.org  Fri Sep  7 11:00:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:00:49 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332449.34.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

Tkinter and IDLE are full of "master" variables:

   master: parent for widgets.

It seems to be a keep concept of Tkinter windows.

----------

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

From report at bugs.python.org  Fri Sep  7 11:04:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:04:06 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332646.59.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

nntplib.NNTP() has a slave() method, but this method sends a "SLAVE" command to the NNTP server. Changing that would require to modify the NNTP protocol, that's out of the scope of this issue...

RFC 977 "Network News Transfer Protocol" (NNTP)
Section 3.12: The SLAVE command
https://tools.ietf.org/html/rfc977

----------

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

From report at bugs.python.org  Fri Sep  7 11:06:26 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:06:26 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536332786.42.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

In the C API, PyMemoryViewObject has a mbuf.master attribute, Include/memoryview.h:

---
typedef struct {
    PyObject_HEAD
    int flags;          /* state flags */
    Py_ssize_t exports; /* number of direct memoryview exports */
    Py_buffer master; /* snapshot buffer obtained from the original exporter */
} _PyManagedBufferObject;


/* memoryview state flags */
#define _Py_MEMORYVIEW_RELEASED    0x001  /* access to master buffer blocked */
#define _Py_MEMORYVIEW_C           0x002  /* C-contiguous layout */
#define _Py_MEMORYVIEW_FORTRAN     0x004  /* Fortran contiguous layout */
#define _Py_MEMORYVIEW_SCALAR      0x008  /* scalar: ndim = 0 */
#define _Py_MEMORYVIEW_PIL         0x010  /* PIL-style layout */

typedef struct {
    PyObject_VAR_HEAD
    _PyManagedBufferObject *mbuf; /* managed buffer */
    Py_hash_t hash;               /* hash value for read-only views */
    int flags;                    /* state flags */
    Py_ssize_t exports;           /* number of buffer re-exports */
    Py_buffer view;               /* private copy of the exporter's view */
    PyObject *weakreflist;
    Py_ssize_t ob_array[1];       /* shape, strides, suboffsets */
} PyMemoryViewObject;
---

----------

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

From report at bugs.python.org  Fri Sep  7 11:10:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:10:10 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333010.52.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

sqlite3.dump._iterdump() access to the "sqlite_master" table.... Hum, I don't think that Python chose the name of this table. This issue should be addressed in SQLite, not in Python.

----------

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

From report at bugs.python.org  Fri Sep  7 11:11:33 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:11:33 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333093.61.0.56676864532.issue34605@psf.upfronthosting.co.za>


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

nis module contains the error message: NisError("No NIS master found for any map"), but libnis has a yp_master() function, it's no like Python picked this name. I suggest to keep "master" here to keep Python consistent with libnis. And "NIP master" gives the context of the "master" term.

----------

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

From report at bugs.python.org  Fri Sep  7 11:13:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 07 Sep 2018 15:13:51 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333231.55.0.902498594338.issue34605@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
components:  -asyncio
nosy:  -yselivanov

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

From report at bugs.python.org  Fri Sep  7 11:16:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:16:18 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333378.11.0.902498594338.issue34605@psf.upfronthosting.co.za>


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


----------
pull_requests: +8555

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

From report at bugs.python.org  Fri Sep  7 11:16:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 15:16:38 +0000
Subject: [docs] [issue34605] Avoid master/slave terminology
In-Reply-To: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>
Message-ID: <1536333398.23.0.902498594338.issue34605@psf.upfronthosting.co.za>


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


----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, ctypes, email, macOS

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

From report at bugs.python.org  Fri Sep  7 16:33:34 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 20:33:34 +0000
Subject: [docs] [issue34564] Tutorial Section 2.1 Windows Installation Path
 Correction
In-Reply-To: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za>
Message-ID: <1536352414.13.0.902498594338.issue34564@psf.upfronthosting.co.za>


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


----------
components: +Installation, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Fri Sep  7 17:42:47 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 07 Sep 2018 21:42:47 +0000
Subject: [docs] [issue25514] Improve IDLE's "subprocess didn't make
 connection" message
In-Reply-To: <1446151640.74.0.583734209916.issue25514@psf.upfronthosting.co.za>
Message-ID: <1536356566.77.0.56676864532.issue25514@psf.upfronthosting.co.za>


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

Module shadowing can affect either the gui process or the run process.  #34584 was the latter: debug_obj imports rpc imports socket imports selectors imports math, which was shadowed.

Pyshell starts run.  If run starts OK but cannot connect to pyshell, it displays a 'subprocess cannot connect' message, which now refers to the new doc section, and exits.  If pyshell does does get a connection, it currently displays

    "Subprocess Startup Error",
    "IDLE's subprocess didn't make connection.  Either IDLE can't "
    "start a subprocess or personal firewall software is blocking "
    "the connection.",

This also needs revision, with a reference to the doc section.  And add 'math.py' to shadowed modules.

----------

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

From report at bugs.python.org  Sat Sep  8 03:21:56 2018
From: report at bugs.python.org (taketakeyyy)
Date: Sat, 08 Sep 2018 07:21:56 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
Message-ID: <1536391316.84.0.902498594338.issue34611@psf.upfronthosting.co.za>


Change by taketakeyyy <taketakeyyy at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, taketakeyyy at gmail.com
priority: normal
severity: normal
status: open
title: some examples in 'itertools' modules docs are inaccuracy.
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep  8 06:33:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 10:33:56 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
Message-ID: <1536402836.69.0.902498594338.issue34611@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep  8 07:03:59 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 08 Sep 2018 11:03:59 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
Message-ID: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

@taketakeyyy: Did you mean to include information about *which* examples are inaccurate? This issue isn't really useful without that information.

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

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

From report at bugs.python.org  Sat Sep  8 08:34:30 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 08 Sep 2018 12:34:30 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536410070.71.0.902498594338.issue34580@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag, ghaering

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

From report at bugs.python.org  Sat Sep  8 10:07:43 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 14:07:43 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536415663.79.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <lolbuntu at chown.me> added the comment:

Thanks for working on this bug!

My message focussed on the closing aspect because that was my problem. :)

Maybe the wording should be more general like:
- "Note that this does not automatically call :meth:`close` on the connection object."
+ "Note that this does not automatically handle the connection object."

(I'm not sure if I should comment here or on the PR on gh)

----------

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

From report at bugs.python.org  Sat Sep  8 12:23:34 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 16:23:34 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536423814.43.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

We always explicitly document what the context manager does even if it simply calls an object's close() method. See https://docs.python.org/3/library/fileinput.html#fileinput.input and https://docs.python.org/3/library/shelve.html#shelve.Shelf for example.

In this case, the documentation already explains what the context manager does after the with block finishes (it also explains the behavior on success and error) with a detailed example.

Would adding a "con.close()" line to the example at https://docs.python.org/3/library/sqlite3.html#using-the-connection-as-a-context-manager clarify the behavior for you?

----------
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep  8 13:01:32 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 17:01:32 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536426092.17.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <lolbuntu at chown.me> added the comment:

Thanks, I lacked the greater picture.

Yes, adding a "con.close()" line to the snippet would clarify for me!

----------

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

From report at bugs.python.org  Sat Sep  8 13:07:03 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 17:07:03 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536426092.17.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <CAAjsFLTkp2Nd9oMhwxDbDZB-mdh78o-2FbWpC69XFYAOXCeTmA@mail.gmail.com>


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

Thanks for the comments. I will add `con.close()` to the examples linked.
Should I remove or change this line as per Daniel's comment "Note that this
does not automatically call :meth:`close` on the connection object."

Thanks
-- 

Regards,
Karthikeyan S

----------

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

From report at bugs.python.org  Sat Sep  8 13:21:47 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 17:21:47 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536427307.57.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

> Should I remove or change this line as per Daniel's comment "Note that
> this does not automatically call :meth:`close` on the connection object."

I'd prefer to keep the current wording as-is.

----------

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

From report at bugs.python.org  Sat Sep  8 13:32:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 17:32:52 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536427972.19.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

Thanks, I have pushed a change adding `con.close` at the end of the example and also verified that `./python.exe Doc/includes/sqlite3/ctx_manager.py` works as expected.

Thanks

----------

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

From report at bugs.python.org  Sat Sep  8 13:53:42 2018
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 08 Sep 2018 17:53:42 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536429222.63.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

PR 9079 looks good to me.

I think we can use this as an opportunity to make the rest of the examples in the sqlite3 documentation more consistent and add missing "conn.close()" calls.

----------

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

From report at bugs.python.org  Sat Sep  8 13:57:46 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Sat, 08 Sep 2018 17:57:46 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536429466.56.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <bpo at chown.me> added the comment:

Yes, I would totally support this move as it would show users that it's important to close it!

----------

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

From report at bugs.python.org  Sat Sep  8 14:35:14 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 08 Sep 2018 18:35:14 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536431714.36.0.56676864532.issue34580@psf.upfronthosting.co.za>


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

Sounds good to me too since I copy paste from there time to time and also an unclosed connection doesn't seem to trigger a ResourceWarning it seems. I have pushed a commit to the same PR. I have changed it manually for all the include files. I have ran the files after the PR with the below and I couldn't see any breakages. Let me know if I have missed anything in the include files. I guess there are some more examples in sqlite3.rst but I don't know if it needs to be added on all snippets since they are more focused on the particular function unlike the files in the include folder that has full programs.

Verified with : 

$ ls -1 Doc/includes/sqlite3/*py > sample.txt
$ cat sample.txt | xargs -n 1 ./python.exe

Thanks

----------

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

From report at bugs.python.org  Sat Sep  8 18:29:55 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 22:29:55 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
Message-ID: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Beyond other classes documented as functions (classmethod, enumerate, filter, map, reversed, staticmethod, super and zip), the following issues exist:

* memoryview, range, and tuple are marked as functions
* complex and object treat themselves as functions in their descriptions

Attached PR fixes this.

----------
assignee: docs at python
components: Documentation
messages: 324864
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc Some classes are treated as functions in Built-in Functions
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep  8 18:31:30 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 22:31:30 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536445890.06.0.902498594338.issue34612@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


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

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

From report at bugs.python.org  Sat Sep  8 19:11:13 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Sep 2018 23:11:13 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536448273.79.0.56676864532.issue34612@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm not sure this is an improvement. While it's true that 'complex' is a class, it's described here as a function. Same as 'int'. The fact that it's a function or class isn't so important here.

I suspect it will confuse people to have something described as a class in the section titled 'Built-in Functions'. We wouldn't want to change the section to the more correct 'Built-in Callables'.

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

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

From report at bugs.python.org  Sat Sep  8 19:39:51 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 23:39:51 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536449991.01.0.56676864532.issue34612@psf.upfronthosting.co.za>


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

Please note that several classes are marked as such (e.g., int, float, str, dict, list) and bool for example treats itself as a class in it's description.

Perhaps your concerns applies to all those ocurrences too?

----------

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

From report at bugs.python.org  Sat Sep  8 19:46:09 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 08 Sep 2018 23:46:09 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536450369.25.0.56676864532.issue34612@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Ah, you're correct. I just looked for the word "class" inside the "int" text, and it doesn't appear there: I thought it was deliberately left out. But it does show up in the sub-section header (before "int" itself). Sorry about that.

The text changes look good, then. I don't know enough about Sphinx to know how changing the meta-data affects things.

----------

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

From report at bugs.python.org  Sat Sep  8 20:35:04 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 00:35:04 +0000
Subject: [docs] [issue34612] doc Some classes are treated as functions in
 Built-in Functions
In-Reply-To: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>
Message-ID: <1536453304.33.0.56676864532.issue34612@psf.upfronthosting.co.za>


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

I concur with Eric.  These were marked as functions in the function section of the docs.  Their role as classes is noted in the body.  And their role as complete classes with a listing of their methods is documented elsewhere.

----------
nosy: +rhettinger
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Sep  8 23:56:11 2018
From: report at bugs.python.org (taketakeyyy)
Date: Sun, 09 Sep 2018 03:56:11 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536465371.46.0.902498594338.issue34611@psf.upfronthosting.co.za>


Change by taketakeyyy <taketakeyyy at gmail.com>:


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

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

From report at bugs.python.org  Sun Sep  9 01:45:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 09 Sep 2018 05:45:27 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536471927.31.0.56676864532.issue34611@psf.upfronthosting.co.za>


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

I don't know if it's worth it to edit the results to return Python data structures in the linked PR. The current version is more concise and indicates the general result of the function instead of the actual return values of the function calls which is intentional. Maybe is there some example in itertools that you are referring to that has incorrect results?

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep  9 02:35:46 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 09 Sep 2018 06:35:46 +0000
Subject: [docs] [issue34611] some examples in 'itertools' modules docs are
 inaccuracy.
In-Reply-To: <1536404639.88.0.56676864532.issue34611@psf.upfronthosting.co.za>
Message-ID: <1536474946.31.0.56676864532.issue34611@psf.upfronthosting.co.za>


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

I concur with  Karthikeyan.   The doc examples read fine as-is.  They have worked well for many users for a long time.  It only takes seconds of experimentation to see exactly what is returned.  There is also a plain text description and a rough pure python equivalent.

Marking this as not a bug.  Thank you for looking at the docs, but I'm going to pass on this particular suggestion.

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

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

From report at bugs.python.org  Sun Sep  9 03:00:39 2018
From: report at bugs.python.org (Laurent Peuch)
Date: Sun, 09 Sep 2018 07:00:39 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
Message-ID: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>


New submission from Laurent Peuch <python at worlddomination.be>:

asyncio.StreamReader documentation incorrectly declare its initialization argument "limit" to be "None" by default https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader

In the source code it is set to _DEFAULT_LIMIT https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L353 

_DEFAULT_LIMIT is set to "2 ** 16 # 64 KiB" https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L19

This information is especially needed when you get the exception "asyncio.streams.LimitOverrunError: Separator is not found, and chunk exceed the limit" and want to increase the limit, but you don't have the initial value and you have to look at the source code to get it.

PS: this is my first ticket, I don't know if I should have open one for such a minor detail in the documentation

----------
assignee: docs at python
components: Documentation, asyncio
messages: 324873
nosy: asvetlov, docs at python, psycojoker, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.StreamReader initialization documentation incorrectly declare limit as None
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  9 03:05:55 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 09 Sep 2018 07:05:55 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536476755.06.0.902498594338.issue34613@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep  9 18:21:11 2018
From: report at bugs.python.org (Anees Ahmed)
Date: Sun, 09 Sep 2018 22:21:11 +0000
Subject: [docs] [issue34617] socket.recvfrom(): docs should warn about
 packet truncation when bufsize is insufficient
Message-ID: <1536531671.36.0.56676864532.issue34617@psf.upfronthosting.co.za>


New submission from Anees Ahmed <aneesahmedpro at gmail.com>:

When one is receiving UDP packets (socket.SOCK_DGRAM) using:

    socket.recvfrom(bufsize, flags)

the UDP packet payload is truncated if it was too big to fit into the buffer (decided by `bufsize` here).


This is documented in Linux Docs:

    All receive operations return only one packet.  When the packet is
    smaller than the passed buffer, only that much data is returned; when
    it is bigger, the packet is truncated and the MSG_TRUNC flag is set.
    MSG_WAITALL is not supported.

    Source: http://man7.org/linux/man-pages/man7/udp.7.html


This is also documented in Windows Docs:

    For message-oriented sockets, data is extracted from the first enqueued message, up to the size of the buffer specified. If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost. For UDP if the packet received contains no data (empty), the return value from the recvfrom function function is zero.

    Source: https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-recvfrom


** PYTHON DOCS DO NOT WARN ABOUT THIS AT ALL !!! **

The relevant portion of Python Docs is here: https://docs.python.org/3.7/library/socket.html#socket.socket.recvfrom


I, not knowing this simple fact when I started socket programming today, wasted half an hour finding out what was wrong. This is a very important piece of information that MUST be present in the Python Docs, even though it is present at Linux Docs and Windows Docs.


PROPOSED FIX
------------

Include the warning about packet truncation in the docs.

NOTE: I have only pointed out socket.recvfrom(), but there are other related functions too, e.g. socket.recvfrom_into(), which require the same warning in their docs.

----------
assignee: docs at python
components: Documentation
messages: 324901
nosy: Anees Ahmed, docs at python
priority: normal
severity: normal
status: open
title: socket.recvfrom(): docs should warn about packet truncation when bufsize is insufficient
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  9 22:56:30 2018
From: report at bugs.python.org (kuri8ive)
Date: Mon, 10 Sep 2018 02:56:30 +0000
Subject: [docs] [issue34619] Typo in docs.python.jp
Message-ID: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>


New submission from kuri8ive <1yen.com at gmail.com>:

Typo in https://docs.python.jp/3/tutorial/index.html
"Python Web ???(htts://www.python.org)"
should be
"Python Web ???(https://www.python.org) "

----------
assignee: docs at python
components: Documentation
messages: 324906
nosy: docs at python, kuri8ive
priority: normal
severity: normal
status: open
title: Typo in docs.python.jp
type: enhancement

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

From report at bugs.python.org  Mon Sep 10 02:26:36 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 10 Sep 2018 06:26:36 +0000
Subject: [docs] [issue34619] Typo in docs.python.jp
In-Reply-To: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>
Message-ID: <1536560796.18.0.56676864532.issue34619@psf.upfronthosting.co.za>


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

Thanks for the report. I think translations use Github issues (https://github.com/python/python-docs-ja/issues). https://www.python.org/dev/peps/pep-0545/#language-team tells me "Redirect issues posted on b.p.o to the correct GitHub issue tracker for the language." . I think filing an issue there will help. In case you want to raise a PR the relevant line is available at https://github.com/python/python-docs-ja/blob/29fb57f236ad2230d1aba88bef114633f47a19f9/tutorial/index.po#L44

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 10 13:02:36 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 10 Sep 2018 17:02:36 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536598956.36.0.56676864532.issue26502@psf.upfronthosting.co.za>


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


New changeset 9797b7ae4496627836c55333765e10201a9840e3 by Petr Viktorin (Berker Peksag) in branch 'master':
bpo-26502: Implement FrameSummary.__len__() (GH-8632)
https://github.com/python/cpython/commit/9797b7ae4496627836c55333765e10201a9840e3


----------

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

From report at bugs.python.org  Mon Sep 10 13:29:28 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Mon, 10 Sep 2018 17:29:28 +0000
Subject: [docs] [issue34580] sqlite doc: clarify the scope of the context
 manager
In-Reply-To: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>
Message-ID: <1536600568.37.0.56676864532.issue34580@psf.upfronthosting.co.za>


Daniel Jakots <bpo at chown.me> added the comment:

LGTM

----------

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

From report at bugs.python.org  Mon Sep 10 13:29:46 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 10 Sep 2018 17:29:46 +0000
Subject: [docs] [issue34525] smtplib's authobject return value wrongly
 documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600586.34.0.56676864532.issue34525@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 78deb7f33227972987722bc3fed5bcb45fae869e by Benjamin Peterson (Sebastian Rittau) in branch 'master':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/78deb7f33227972987722bc3fed5bcb45fae869e


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep 10 13:29:55 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 17:29:55 +0000
Subject: [docs] [issue34525] smtplib's authobject return value wrongly
 documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600595.52.0.902498594338.issue34525@psf.upfronthosting.co.za>


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


----------
pull_requests: +8589

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

From report at bugs.python.org  Mon Sep 10 13:30:05 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 17:30:05 +0000
Subject: [docs] [issue34525] smtplib's authobject return value wrongly
 documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536600605.28.0.902498594338.issue34525@psf.upfronthosting.co.za>


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


----------
pull_requests: +8590

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

From report at bugs.python.org  Mon Sep 10 13:50:48 2018
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 10 Sep 2018 17:50:48 +0000
Subject: [docs] [issue34487] enum _sunder_ names mix metaclass and enum
 class attributes
In-Reply-To: <1535121871.11.0.56676864532.issue34487@psf.upfronthosting.co.za>
Message-ID: <1536601848.75.0.902498594338.issue34487@psf.upfronthosting.co.za>


Change by Ethan Furman <ethan at stoneleaf.us>:


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

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

From report at bugs.python.org  Mon Sep 10 14:13:17 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 18:13:17 +0000
Subject: [docs] [issue34525] smtplib's authobject return value wrongly
 documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536603197.62.0.56676864532.issue34525@psf.upfronthosting.co.za>


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


New changeset 011141f312f11b35ac163d9d52fe48e4bb61a814 by Miss Islington (bot) in branch '3.7':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/011141f312f11b35ac163d9d52fe48e4bb61a814


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

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

From report at bugs.python.org  Mon Sep 10 14:16:15 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 10 Sep 2018 18:16:15 +0000
Subject: [docs] [issue34525] smtplib's authobject return value wrongly
 documented
In-Reply-To: <1535422242.76.0.56676864532.issue34525@psf.upfronthosting.co.za>
Message-ID: <1536603375.54.0.56676864532.issue34525@psf.upfronthosting.co.za>


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


New changeset c0db8177dc9a7f79941551576e1faea9724e027d by Miss Islington (bot) in branch '3.6':
closes bpo-34525: Fix smtplib's authobject() documentation (GH-8965)
https://github.com/python/cpython/commit/c0db8177dc9a7f79941551576e1faea9724e027d


----------

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

From report at bugs.python.org  Mon Sep 10 14:23:04 2018
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 10 Sep 2018 18:23:04 +0000
Subject: [docs] [issue34619] Typo in docs.python.jp
In-Reply-To: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>
Message-ID: <1536603784.76.0.56676864532.issue34619@psf.upfronthosting.co.za>


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

Karthikeyan is right that translation bugs should be reported on the GitHub project for the translation.

----------
nosy: +brett.cannon
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Sep 10 15:06:49 2018
From: report at bugs.python.org (Eric Atkin)
Date: Mon, 10 Sep 2018 19:06:49 +0000
Subject: [docs] [issue33609] Document that dicts preserve insertion order
In-Reply-To: <1527023250.35.0.682650639539.issue33609@psf.upfronthosting.co.za>
Message-ID: <1536606409.24.0.56676864532.issue33609@psf.upfronthosting.co.za>


Eric Atkin <eatkin at omnisolutions.biz> added the comment:

It seems the note at the bottom for `object.__hash__(self)` [1] should be updated as well.

[1] https://docs.python.org/3/reference/datamodel.html#object.__hash__

----------
nosy: +Eric Atkin

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

From asmirnovsky at gmail.com  Thu Sep  6 17:51:31 2018
From: asmirnovsky at gmail.com (Smirnov)
Date: Thu, 6 Sep 2018 17:51:31 -0400
Subject: [docs] Pyton 2.7.14 Multiprocessing Pool Join Hanging
Message-ID: <CAKc_y88dbKyiNnaPQu9DTj=vVYccgLcXnayz7QX8ac-3HoUyqg@mail.gmail.com>

  Hi,

  /usr/lib/python2.7/multiprocessing/pool.py hangs intermittently for large
queue sizes.
  My suggested fix is to modify Pool class' join() method thus:

    def join(self):
        debug('joining pool')
        assert self._state in (CLOSE, TERMINATE)
        # moved the join for each subprocess before Pool thead joins
        for p in self._pool:
            p.join()
        # moved Pool thread joins after the subprocesses and add timeouts
        self._worker_handler.join(timeout=30)
        self._task_handler.join(timeout=30)
        self._result_handler.join(time=30)

The bulk of the work is done by subprocesses.  When these are done, the
Pool class' threads should complete very quickly.

I'm fairly certain that the hang or stall happens in the threads' join, not
the subprocesses'.
The timeout on the threads' joins should prevent any hanging.

The only way I've manually been able to reproduce the hanging is by the
below script using the *CalledProcessError exception.*

  Kind Regards,
  -Nazar


--------------------------


import logging
from multiprocessing import Pool, Process
from time import sleep
import random
import pdb
import sys
import os
from subprocess import CalledProcessError


logging.basicConfig(stream=sys.stdout, level=logging.DEBUG)


def f(x):
    pause = random.randint(1,2)
    #print("pid %s start, arg = %s, pause = %s" % (os.getpid(), x, pause))
    if pause % 2 == 0:
        #pause = 9 #9999
        raise CalledProcessError(1,2)
    sleep(0.01)  #pause)
    #print("pid %s finish, arg = %s" % (os.getpid(), x))


def print_status(pl):
    print("\n")
    for proc in pl._pool:
        print("Process %s, pid %s, is_alive %s, exit code %s, unfinished
tasks %s" %
         (proc._name, proc.pid, proc.is_alive(), proc.exitcode,
pl._taskqueue.unfinished_tasks))


import subprocess
def pool_join(proc_pool):
    """
    Join all of the process pool's subprocesses to the main processes
    Python Pool's "join" intermittently hangs for ~1K subprocesses:
STATICQA-5027
    """
    RUN = 0
    CLOSE = 1
    TERMINATE = 2

    # log memory usage
    mem_str = subprocess.check_output(['cat', '/proc/meminfo'])
    logging.info('------ memory usage\n%s' % mem_str)

    logging.info('------ joining process pool')
    assert proc_pool._state in (CLOSE, TERMINATE)
    logging.info('------  proc_pool._worker_handler.join()')
    proc_pool._worker_handler.join()
    logging.info('------ proc_pool._task_handler.join()')
    proc_pool._task_handler.join()
    logging.info('------ proc_pool._result_handler.join()')
    proc_pool._result_handler.join()
    logging.info('------ starting to join each process in POOL')
    for proc in proc_pool._pool:
        logging.info("------ Joining process %s, pid %s, is_alive %s, exit
code %s" %
         (proc._name, proc.pid, proc.is_alive(), proc.exitcode))
        proc.join()
    logging.info("------- All POOL joins are done")



if __name__ == '__main__':
    pl = Pool(6)
    NUM_PROC = 100
    for i in range(1,NUM_PROC):
        res = pl.apply_async(f, (i,))
    pl.close()
    print("Num processes = %s" % len(pl._pool))
    for i in range(4):
        print_status(pl)
        sleep(2)
    print("before join")
    #pl.join()
    pool_join(pl)
    print("after join")
    print_status(pl)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180906/032d6f93/attachment-0001.html>

From rquint at rain.org  Fri Sep  7 11:41:51 2018
From: rquint at rain.org (Richard Quint)
Date: Fri, 7 Sep 2018 08:41:51 -0700
Subject: [docs] A4 pdf files are US-letter
Message-ID: <913edca7-d4ff-ee7b-0774-8871789dbc2e@rain.org>

As of 7 Sept 2018 the python-3.7.0-docs-pdf-a4.zip and 
python-3.7.0-docs-pdf-a4.tar.bz archives contain the US-letter size 
rather than the A4 size pdfs.

Richard Quint


From Sebastian.Val at jpl.nasa.gov  Fri Sep  7 19:09:37 2018
From: Sebastian.Val at jpl.nasa.gov (Val, Sebastian (398E))
Date: Fri, 7 Sep 2018 23:09:37 +0000
Subject: [docs] Documentation bug
Message-ID: <C71A0DF7-8516-42B2-A4FB-261AA648885E@jpl.nasa.gov>

Hello, 

In the "Default Memory Allocators" section of the "Memory Management" page ( https://docs.python.org/3.8/c-api/memory.html#default-memory-allocators ) the last entry in first table ("Default memory allocators") appears to be incorrect.

Instead of the "Configuration column" reading "Release build, without pymalloc" it should read "Debug build, without pymalloc" for that last entry.

As currently written the "Configuration" name of the third and fourth entries is the same, though the 4th entry is a debug build that includes the " + debug" versions of the allocators.

Regards,
 
Sebastian Val
Jet Propulsion Laboratory
 
M/S 168-200
4800 Oak Grove Dr.
Pasadena, California 91109
Phone: (818) 354-9220


From kev at inburke.com  Mon Sep 10 16:15:52 2018
From: kev at inburke.com (Kevin Burke)
Date: Mon, 10 Sep 2018 13:15:52 -0700
Subject: [docs] secrets.compare_digest still ranks poorly for "python
 constant time string comparison"
Message-ID: <CAGs5PJJzXC0FSAVU61L6riXoJucuhpz8_Z3_Z0Ok6so4wR5+TA@mail.gmail.com>

Hi,
I'm not sure of exactly the way to fix this, but I needed to use
constant time string comparison today, and all of the top results on
Google for this problem still point to third party libraries.

Perhaps a targeted effort could generate more links to
https://docs.python.org/3/library/secrets.html, and publicly available
sources and third party libraries could have their README's point to
this library as well.

Kevin

-- 
Kevin Burke
phone: 925.271.7005 | kev.inburke.com

From report at bugs.python.org  Mon Sep 10 16:33:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 10 Sep 2018 20:33:10 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536611590.86.0.902498594338.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 10 21:13:12 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 01:13:12 +0000
Subject: [docs] [issue33460] "..." is used to confusingly indicate many
 different things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536628392.33.0.0269046726804.issue33460@psf.upfronthosting.co.za>


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


New changeset f019579828ed62653e2d41c95278308fa076ccaf by Gregory P. Smith (Lew Kurtz) in branch 'master':
bpo-33460: remove ellipsis that look like continuation prompts (GH-7851)
https://github.com/python/cpython/commit/f019579828ed62653e2d41c95278308fa076ccaf


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

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

From report at bugs.python.org  Mon Sep 10 21:13:21 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 01:13:21 +0000
Subject: [docs] [issue33460] "..." is used to confusingly indicate many
 different things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536628401.13.0.0597535862996.issue33460@psf.upfronthosting.co.za>


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


----------
pull_requests: +8599

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

From report at bugs.python.org  Mon Sep 10 21:47:50 2018
From: report at bugs.python.org (paul j3)
Date: Tue, 11 Sep 2018 01:47:50 +0000
Subject: [docs] [issue32027] argparse allow_abbrev option also controls
 short flag combinations
In-Reply-To: <1510680582.36.0.213398074469.issue32027@psf.upfronthosting.co.za>
Message-ID: <1536630470.35.0.0269046726804.issue32027@psf.upfronthosting.co.za>


paul j3 <ajipanca at gmail.com> added the comment:

The PR 4396 should be closed.

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

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

From report at bugs.python.org  Mon Sep 10 21:49:42 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 01:49:42 +0000
Subject: [docs] [issue33460] "..." is used to confusingly indicate many
 different things in chapter 3
In-Reply-To: <1525995197.73.0.682650639539.issue33460@psf.upfronthosting.co.za>
Message-ID: <1536630582.75.0.0269046726804.issue33460@psf.upfronthosting.co.za>


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


New changeset 037582eb7f4d61604ef2dcc72f896117588eeb3c by Miss Islington (bot) in branch '3.7':
bpo-33460: remove ellipsis that look like continuation prompts (GH-7851)
https://github.com/python/cpython/commit/037582eb7f4d61604ef2dcc72f896117588eeb3c


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

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

From qiny at conzhu.com  Mon Sep 10 23:01:30 2018
From: qiny at conzhu.com (qiny at conzhu.com)
Date: Tue, 11 Sep 2018 11:01:30 +0800
Subject: [docs] Can you support Chinese for document
Message-ID: <428VTN6LsBzFrWS@mail.python.org>

Can you support Chinese? You are losing millions developer!!!

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

From mariatta.wijaya at gmail.com  Tue Sep 11 00:17:01 2018
From: mariatta.wijaya at gmail.com (Mariatta Wijaya)
Date: Mon, 10 Sep 2018 21:17:01 -0700
Subject: [docs] Can you support Chinese for document
In-Reply-To: <428VTN6LsBzFrWS@mail.python.org>
References: <428VTN6LsBzFrWS@mail.python.org>
Message-ID: <CAGbohnZ0ZdzG3b-JOyQFk+u2Df3ykQtMjemydXydiEaDd_+N=Q@mail.gmail.com>

There is an ongoing effort by vokunteers to translate documents into
Chinese language, and the mailing list for that is at doc-sig (
https://mail.python.org/mailman/listinfo/doc-sig)




On Mon, Sep 10, 2018, 8:53 PM <qiny at conzhu.com> wrote:

> Can you support Chinese? You are losing millions developer!!!
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180910/c8990a1f/attachment.html>

From report at bugs.python.org  Tue Sep 11 00:37:36 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 04:37:36 +0000
Subject: [docs] [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536640656.85.0.0269046726804.issue33032@psf.upfronthosting.co.za>


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


New changeset 3666b3c1f695a145adab1bf644c22e564e8eb0ee by Gregory P. Smith (Zackery Spytz) in branch 'master':
bpo-33032: Mention the implicit cache in struct.Struct() docs (GH-7700)
https://github.com/python/cpython/commit/3666b3c1f695a145adab1bf644c22e564e8eb0ee


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

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

From report at bugs.python.org  Tue Sep 11 00:37:45 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:37:45 +0000
Subject: [docs] [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536640665.79.0.0597535862996.issue33032@psf.upfronthosting.co.za>


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


----------
pull_requests: +8604

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

From report at bugs.python.org  Tue Sep 11 00:40:12 2018
From: report at bugs.python.org (Noah Haasis)
Date: Tue, 11 Sep 2018 04:40:12 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1536640812.0.0.0269046726804.issue21314@psf.upfronthosting.co.za>


Noah Haasis <haasis_noah at yahoo.de> added the comment:

Can I work on this?

----------
nosy: +noah.haasis

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

From report at bugs.python.org  Tue Sep 11 00:50:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 04:50:46 +0000
Subject: [docs] [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536641446.48.0.0269046726804.issue33032@psf.upfronthosting.co.za>


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


New changeset 2110f78d92522499836a928d268704fdc5f7a037 by Miss Islington (bot) in branch '3.7':
bpo-33032: Mention the implicit cache in struct.Struct() docs (GH-7700)
https://github.com/python/cpython/commit/2110f78d92522499836a928d268704fdc5f7a037


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

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

From report at bugs.python.org  Tue Sep 11 00:56:29 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 04:56:29 +0000
Subject: [docs] [issue33032] Mention implicit cache in struct.Struct docs
In-Reply-To: <1520551378.96.0.467229070634.issue33032@psf.upfronthosting.co.za>
Message-ID: <1536641789.46.0.0269046726804.issue33032@psf.upfronthosting.co.za>


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

thanks!

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

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

From report at bugs.python.org  Tue Sep 11 01:12:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 05:12:45 +0000
Subject: [docs] [issue33883] doc Mention mypy, pyrex,
 pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536642765.01.0.0269046726804.issue33883@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a37825418649873a0fa971dc7e5e6d142c124574 by Benjamin Peterson (Andr?s Delfino) in branch 'master':
closes bpo-33883: Mention type checkers in the FAQ. (GH-7760)
https://github.com/python/cpython/commit/a37825418649873a0fa971dc7e5e6d142c124574


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep 11 01:12:54 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 05:12:54 +0000
Subject: [docs] [issue33883] doc Mention mypy, pyrex,
 pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536642774.09.0.0597535862996.issue33883@psf.upfronthosting.co.za>


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


----------
pull_requests: +8605

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

From report at bugs.python.org  Tue Sep 11 01:27:05 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 05:27:05 +0000
Subject: [docs] [issue33883] doc Mention mypy, pyrex,
 pytype and PyAnnotate in FAQ
In-Reply-To: <1529196736.16.0.56676864532.issue33883@psf.upfronthosting.co.za>
Message-ID: <1536643625.31.0.0269046726804.issue33883@psf.upfronthosting.co.za>


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


New changeset c9ece5f4a961d4963ed42aefa934eb20f9a7222b by Miss Islington (bot) in branch '3.7':
closes bpo-33883: Mention type checkers in the FAQ. (GH-7760)
https://github.com/python/cpython/commit/c9ece5f4a961d4963ed42aefa934eb20f9a7222b


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

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

From report at bugs.python.org  Tue Sep 11 09:39:51 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 13:39:51 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1536673191.26.0.0269046726804.issue21314@psf.upfronthosting.co.za>


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

Welcome, Noah! Feel free to work on this issue, but please note that there is no consensus on the best place to document / signatures, so you may need to move your changes between locations (e.g. from Doc/faq/programming.rst to Doc/gloassary.rst) before we merge your work.

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

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

From report at bugs.python.org  Tue Sep 11 11:04:47 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 15:04:47 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536678287.61.0.0269046726804.issue28617@psf.upfronthosting.co.za>


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

I think that "types that are :term:`iterable` or implement the :meth:`__contains__` method" is too low-level for this section.

In this section we tell about builtin types. From those the types that support `in` and `not in` are list, tuple, dict, set, frozenset, str, bytes, bytearray, memoryview, and iterator types. We can just enumerate them or use general word. Calling the "sequence types" is not correct, but fortunately all of them are iterable, so that we can say just "iterable types described below". Or enumerate categories of types, as they are named in the below subsections: "iterator types, sequence types, str, binary sequence types, set types and dict", with links to corresponding subsections.

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

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

From report at bugs.python.org  Tue Sep 11 12:54:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 16:54:44 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536684884.68.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 7c7605ff1133cf757cac428c483827f666c7c827 by Yury Selivanov in branch 'master':
bpo-33649: First asyncio docs improvement pass (GH-9142)
https://github.com/python/cpython/commit/7c7605ff1133cf757cac428c483827f666c7c827


----------

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

From report at bugs.python.org  Tue Sep 11 12:58:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 16:58:02 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536685082.23.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The first PR has been just landed.

The plan is to work in 'master' branch and when the docs are ready we backport them to 3.7 in one big PR.

So far the following files were updated/reviewed:

     Doc/library/asyncio-eventloop.rst
     Doc/library/asyncio-eventloops.rst -> Doc/library/asyncio-policy.rst
     Doc/library/asyncio-exceptions.rst
     Doc/library/asyncio-platforms.rst 
     Doc/library/asyncio-policy.rst    
     Doc/library/asyncio-protocol.rst  
     Doc/library/asyncio-queue.rst     
     Doc/library/asyncio-stream.rst    
     Doc/library/asyncio-subprocess.rst 

Please feel free to submit PR to fix/improve the above (but not other files as I'm going to be making some heavy edit passes on them).

----------

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

From report at bugs.python.org  Tue Sep 11 12:58:11 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 16:58:11 +0000
Subject: [docs] [issue33986] asyncio: Typo in documentation:
 BaseSubprocessTransport -> SubprocessTransport
In-Reply-To: <1530139574.74.0.56676864532.issue33986@psf.upfronthosting.co.za>
Message-ID: <1536685091.28.0.0269046726804.issue33986@psf.upfronthosting.co.za>


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

Superseded by #33649

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> asyncio docs overhaul

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

From report at bugs.python.org  Tue Sep 11 13:33:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:33:44 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536687223.95.0.0269046726804.issue26502@psf.upfronthosting.co.za>


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

Thanks for merging this, Petr. What do you think about backporting to 3.7?

----------
components:  -Documentation
versions: +Python 3.8

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

From report at bugs.python.org  Tue Sep 11 13:44:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:44:56 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687896.67.0.0269046726804.issue28617@psf.upfronthosting.co.za>


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


New changeset 08bcf647d8a92e4bd47531588b284c6820b7a7ef by Miss Islington (bot) (wim glenn) in branch 'master':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/08bcf647d8a92e4bd47531588b284c6820b7a7ef


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

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

From report at bugs.python.org  Tue Sep 11 13:45:41 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:45:41 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687941.43.0.0597535862996.issue28617@psf.upfronthosting.co.za>


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


----------
pull_requests: +8612

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

From report at bugs.python.org  Tue Sep 11 13:45:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 17:45:51 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536687951.59.0.0597535862996.issue28617@psf.upfronthosting.co.za>


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


----------
pull_requests: +8613

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

From report at bugs.python.org  Tue Sep 11 13:49:10 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 17:49:10 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536688150.43.0.0269046726804.issue26502@psf.upfronthosting.co.za>


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

I don't think I have a good enough feel for what should, generally, go to 3.7. So take my opinion with a grain of salt.

But honestly, I don't think the issue is important enough -- I've only seen one codebase affected by it, which wasn't hard to fix.

----------

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

From report at bugs.python.org  Tue Sep 11 13:52:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 11 Sep 2018 17:52:41 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536688361.52.0.0597535862996.issue33649@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep 11 13:54:10 2018
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 11 Sep 2018 17:54:10 +0000
Subject: [docs] [issue26502] traceback.extract_tb breaks compatibility by
 returning FrameSummary
In-Reply-To: <1457349348.27.0.253072992901.issue26502@psf.upfronthosting.co.za>
Message-ID: <1536688450.83.0.0269046726804.issue26502@psf.upfronthosting.co.za>


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

Ok, let's close this issue then.

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

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

From report at bugs.python.org  Tue Sep 11 14:13:38 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:13:38 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536689618.22.0.0269046726804.issue28617@psf.upfronthosting.co.za>


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


New changeset 3e648f8371e342ccfa663ad77e82a538fcc8c9fb by Miss Islington (bot) in branch '3.7':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/3e648f8371e342ccfa663ad77e82a538fcc8c9fb


----------

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

From report at bugs.python.org  Tue Sep 11 14:18:19 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:18:19 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536689899.76.0.0269046726804.issue28617@psf.upfronthosting.co.za>


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


New changeset 889f080a4d5cdb1cfb901b953f4b89f3ea806bbe by Miss Islington (bot) in branch '3.6':
bpo-28617 Fixed docs inaccuracies about the types that support membership tests (GH-9086)
https://github.com/python/cpython/commit/889f080a4d5cdb1cfb901b953f4b89f3ea806bbe


----------

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

From report at bugs.python.org  Tue Sep 11 14:38:28 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 11 Sep 2018 18:38:28 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1536691108.09.0.0269046726804.issue28617@psf.upfronthosting.co.za>


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

Humm, why the bot merges in the master branch?

----------

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

From report at bugs.python.org  Tue Sep 11 14:45:31 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:31 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691531.19.0.0269046726804.issue34613@psf.upfronthosting.co.za>


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


New changeset b4ec36200a959da70eba94c19826446a8efdffdd by Miss Islington (bot) (Bram) in branch 'master':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/b4ec36200a959da70eba94c19826446a8efdffdd


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

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

From report at bugs.python.org  Tue Sep 11 14:45:46 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:46 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691546.79.0.0597535862996.issue34613@psf.upfronthosting.co.za>


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


----------
pull_requests: +8614

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

From report at bugs.python.org  Tue Sep 11 14:45:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:45:58 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536691558.51.0.0597535862996.issue34613@psf.upfronthosting.co.za>


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


----------
pull_requests: +8615

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

From report at bugs.python.org  Tue Sep 11 14:57:51 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:57:51 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536692271.63.0.0269046726804.issue34613@psf.upfronthosting.co.za>


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


New changeset cb51dd7cac6a6e2a7ba67fa4cd328a68f630095b by Miss Islington (bot) in branch '3.6':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/cb51dd7cac6a6e2a7ba67fa4cd328a68f630095b


----------

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

From report at bugs.python.org  Tue Sep 11 14:59:33 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 18:59:33 +0000
Subject: [docs] [issue34613] asyncio.StreamReader initialization
 documentation incorrectly declare limit as None
In-Reply-To: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>
Message-ID: <1536692373.88.0.0269046726804.issue34613@psf.upfronthosting.co.za>


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


New changeset e02ca4270ef258162215e345c23025bec27f9eb0 by Miss Islington (bot) in branch '3.7':
bpo-34613: document the correct value of limit argument of asyncio.StreamReader (GH-9121)
https://github.com/python/cpython/commit/e02ca4270ef258162215e345c23025bec27f9eb0


----------

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

From report at bugs.python.org  Tue Sep 11 16:59:28 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:28 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699568.16.0.0269046726804.issue34365@psf.upfronthosting.co.za>


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


New changeset 9c223794c754408644c16349b85dd27fdba8a926 by Miss Islington (bot) (Danish Prakash) in branch 'master':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/9c223794c754408644c16349b85dd27fdba8a926


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

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

From report at bugs.python.org  Tue Sep 11 16:59:47 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:47 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699587.33.0.0597535862996.issue34365@psf.upfronthosting.co.za>


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


----------
pull_requests: +8619

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

From report at bugs.python.org  Tue Sep 11 16:59:58 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 20:59:58 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699598.07.0.0597535862996.issue34365@psf.upfronthosting.co.za>


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


----------
pull_requests: +8620

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

From report at bugs.python.org  Tue Sep 11 17:00:37 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 21:00:37 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536699637.23.0.0269046726804.issue26979@psf.upfronthosting.co.za>


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

I don't think PEP 384 should be updated. It documents the feature as it was added, and shouldn't be used as documentation now.
Instead, Python documentation should be improved to cover all of PEP 389.
I submitted a pull request for that (GH-9154).

For this issue, the fix should be updating C API documentation and, for Pyhon 3.8+, making {*, NULL} slots override the inherited value.

I think the PyType_Spec/PyType_Slot copying should have its own issue.

----------

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

From report at bugs.python.org  Tue Sep 11 17:03:41 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 11 Sep 2018 21:03:41 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536699821.53.0.0269046726804.issue34365@psf.upfronthosting.co.za>


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

Thanks!

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

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

From report at bugs.python.org  Tue Sep 11 17:24:56 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:24:56 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536701096.46.0.0269046726804.issue34365@psf.upfronthosting.co.za>


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


New changeset e2b40f4ce954ea3d35a73541029b2253abd9d245 by Miss Islington (bot) in branch '3.7':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/e2b40f4ce954ea3d35a73541029b2253abd9d245


----------

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

From report at bugs.python.org  Tue Sep 11 17:27:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 11 Sep 2018 21:27:09 +0000
Subject: [docs] [issue34365] datetime's documentation refers to "comparison
 [...] falling back to the default scheme of comparing object addresses"
In-Reply-To: <1533791029.87.0.56676864532.issue34365@psf.upfronthosting.co.za>
Message-ID: <1536701229.89.0.0269046726804.issue34365@psf.upfronthosting.co.za>


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


New changeset 8a2c2d4e1b6b46a9a982e5c064ca4399ec28d55d by Miss Islington (bot) in branch '3.6':
bpo-34365: Update date object documentation (GH-8814)
https://github.com/python/cpython/commit/8a2c2d4e1b6b46a9a982e5c064ca4399ec28d55d


----------

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

From report at bugs.python.org  Tue Sep 11 17:36:26 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Tue, 11 Sep 2018 21:36:26 +0000
Subject: [docs] [issue34538] Remove encouragement to author a base class for
 all Exception subclasses in a module
In-Reply-To: <1535488851.13.0.56676864532.issue34538@psf.upfronthosting.co.za>
Message-ID: <1536701786.83.0.0269046726804.issue34538@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

I?d like to try to steer this conversation back toward what I think is the actionable question: ?does the exemplification of this practice in the Errors and Exceptions portion of The Python Tutorial bring about a net benefit or a net cost to its intended audience??.

What is the benefit? It is that when an author happens to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type* the author is led to define an intermediate class between Exception and the directly-used user-defined Exception subclasses capturing that type in a usable code element.

What readers of the tutorial enjoy this benefit? Pretty much only those authors (who happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*) who are still learning about classes and inheritance. That?s a doubly slim population, isn?t it? Maybe also those who kind of know, but aren?t so sure and could use some reinforcement from seeing in the tutorial something that they independently did on their own in their own code. I wouldn?t think that authors who already know with confidence and from experience about classes and inheritance would benefit from the example in the tutorial, so ?In my experience as a teacher, the possibility doesn't usually occur to people without it having been suggested? comes as a surprise to me. But? okay, them too - but again, only when they happen to be authoring a module *all user-defined Exception subclasses of which satisfy some more-specific-than-Exception type*.

What is the cost? It is that when an author happens to be authoring a module that does *not* have the property that all user-defined Exception subclasses satisfy some more-specific-than-Exception type, the common intermediate class is just bloat. It?s noise disrupting the signal. It undermines the API design advice ?when in doubt, leave it out?. It unnecessarily widens the module?s API. It undermines the API design advice ?classes are the most complex kind of code element in common use so they have the highest value proposition to satisfy to justify their existence?. It violates the Liskov Substitution Principle. Maybe most importantly, it obscures other relationships among the user-defined Exception subclasses in the module such as a superclass shared by some-but-not-all of the module?s user-defined Exception subclasses, if such other relationships exist.

What readers of the tutorial pay this cost? Those who are still learning the language. And those who are following pattern and convention - note that the tutorial contains only one example of user-defined Exception subclasses, and? an unfortunate fact of life of tutorials is that readers are invited to generalize from single examples. And, as I think we?ve seen in this conversation, those who just picked up the practice at one point and have kept it going.

The Exception subclass hierarchy of sqlite3 that was mentioned earlier in this conversation demonstrates exactly this bloat and misapplication - there?s Warning, which is a direct subclass of Exception, and there?s Error, which is also a direct subclass of Exception and has the erroneous specification ?The base class of the other exceptions in this module?, and there?s DatabaseError, which is a subclass of Error, and then there are IntegrityError, ProgrammingError, OperationalError, and NotSupportedError, which inherit from DatabaseError. What?s the use of Error? There are no code elements in the module specified as raising Error. There?s example code in the module showing ?except sqlite3.Error?, but why shouldn?t that be ?except sqlite3.DatabaseError??

It?s a red herring is that the practice appears widely applied in existing Python code - well of course; it?s been exemplified in the tutorial for seventeen years! :-P

One last thing to consider: look at the example specifically - InputError and TransitionError. There?s no elsewhere-in-the-module example code showing a function that has ?Error? in its ?Raises:? specification and could raise either an InputError or a TransitionError, and there?s no outside-of-the-module example code showing a user of the module calling a module function and saving duplicated lines of code because they want to respond to InputErrors and TransitionErrors in exactly the same way.

We should remove the ?Base class for exceptions in this module? Error class from the tutorial?s example because it just isn?t beneficial enough, in enough applicable modules, to enough authors, and it?s more than costly enough, in enough modules to which it doesn?t apply, and to enough authors, even just as noise and API bloat. I don?t know that this could have been calculated from first principles seventeen years ago; I think perhaps it took the experience of having the guidance out there, so rarely merited and so widely implemented, to see it being a net drag.

----------

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

From report at bugs.python.org  Tue Sep 11 17:40:00 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 21:40:00 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536702000.67.0.0269046726804.issue26979@psf.upfronthosting.co.za>


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

Christian, do you have a specific example of the default tp_dealloc doing the wrong thing?

----------

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

From report at bugs.python.org  Tue Sep 11 18:12:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 11 Sep 2018 22:12:05 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536703925.85.0.0597535862996.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8630

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

From report at bugs.python.org  Tue Sep 11 20:10:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Sep 2018 00:10:41 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536711041.15.0.0269046726804.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 8be876e44b2dffb96b551029454cbfb16d697992 by Yury Selivanov in branch 'master':
bpo-33649: Cleanup asyncio/streams and asyncio/synchronization docs (GH-9192)
https://github.com/python/cpython/commit/8be876e44b2dffb96b551029454cbfb16d697992


----------

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

From report at bugs.python.org  Tue Sep 11 20:32:19 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:32:19 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712338.88.0.0269046726804.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 731ff68eeef58babdf2b32dc9a73b141760c2be9 by Benjamin Peterson (Cheryl Sabella) in branch 'master':
closes bpo-25041: Document AF_PACKET socket address format. (GH-4092)
https://github.com/python/cpython/commit/731ff68eeef58babdf2b32dc9a73b141760c2be9


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Sep 11 20:33:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:33:38 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712418.36.0.0597535862996.issue25041@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8641

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

From report at bugs.python.org  Tue Sep 11 20:36:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:36:08 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536712568.91.0.0597535862996.issue25041@psf.upfronthosting.co.za>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +8643

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

From report at bugs.python.org  Tue Sep 11 21:46:39 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 01:46:39 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536716799.24.0.956365154283.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset cadb66e173ded86ebc85b54889db48f66e7af592 by Benjamin Peterson in branch '3.7':
[3.7] closes bpo-25041: Document AF_PACKET socket address format. (GH-9207)
https://github.com/python/cpython/commit/cadb66e173ded86ebc85b54889db48f66e7af592


----------

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

From report at bugs.python.org  Wed Sep 12 01:36:14 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 05:36:14 +0000
Subject: [docs] [issue25041] document AF_PACKET socket address format
In-Reply-To: <1441804077.41.0.782475265278.issue25041@psf.upfronthosting.co.za>
Message-ID: <1536730574.05.0.956365154283.issue25041@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset a00de685c11cf8bdca1f8efa7aab80552d80ddfb by Benjamin Peterson in branch '3.6':
[3.6] closes bpo-25041: Document AF_PACKET socket address format. (GH-9209)
https://github.com/python/cpython/commit/a00de685c11cf8bdca1f8efa7aab80552d80ddfb


----------

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

From zoodss at yandex.ru  Wed Sep 12 13:10:13 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Wed, 12 Sep 2018 20:10:13 +0300
Subject: [docs] Bugs in Python 3.7 documentation.
Message-ID: <3171151536772213@sas1-3713921c63b1.qloud-c.yandex.net>

https://docs.python.org/3/reference/datamodel.html#metaclass-example - 
    "uses an collections.OrderedDict to remember" when it is better to use "uses a collections.OrderedDict to remember"

https://docs.python.org/3/reference/executionmodel.html#exceptions
"Exceptions are a means" - Is it correct to use "a" here? "means" means a lot of them. "a" means one.

"In either case, it prints a stack backtrace" - most of the time in Python documentation term "traceback" is used instead of "backtrace". It may mislead newcomers, so they will think, that this is potentially a new term.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"Due to their side effects on the containing scope, yield expressions are not permitted as part of the implicitly defined scopes used to implement comprehensions and generator expressions (in Python 3.7, such expressions emit DeprecationWarning when compiled, in Python 3.8+ they will emit SyntaxError).." - two periods in the end of the sentence.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"...or automatically when the sub-iterator is a generator (by returning a value from the sub-generator)." - inconsistent use of "sub-iterator" term. Previously subiterator was referenced several times as "subiterator" not "sub-iterator".

If i understood something wrong, then i am sorry.

--?
Sincerely,
ZooDSS
ZooDSS at yandex.ru


From zoodss at yandex.ru  Wed Sep 12 13:25:04 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Wed, 12 Sep 2018 20:25:04 +0300
Subject: [docs] Another bug in Python 3.7 docs.
Message-ID: <6361071536773104@iva4-031ea4da33a1.qloud-c.yandex.net>

https://docs.python.org/3/reference/expressions.html#yield-expressions

Term "sub-generator" is used in PEP 280 without dash ("-") symbol - "subgenerator". At the same time it is used as "sub-generator" 2 times on this page:

"generator (by returning a value from the sub-generator)." - here.

"The proposal to introduce the yield_from syntax, making delegation to sub-generators easy." - and here.

--?
Sincerely,
ZooDSS
ZooDSS at yandex.ru


From report at bugs.python.org  Wed Sep 12 13:49:26 2018
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 12 Sep 2018 17:49:26 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536774566.67.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

Hi Petr,

yes I have that what generated the wrong thing, but it is inside
a specific PySide repository in a big project. Before I try to extract
and simulate that, let me just show it.

All types which had been no heaptypes before were already quite complicated
types which had their own deallocators before, or a 0 if they did not
need one, or better "should not have one".

When switching to the new interface, those deallocators which were 0 were
turned into the default deallocator, which crashed most of the time.

By replacing it by a dummy function fixed the problem. Example:

static PyType_Slot PySideSignalMetaType_slots[] = {
    {Py_tp_methods, (void *)Signal_methods},
    {Py_tp_base, (void *)&PyType_Type},
    {Py_tp_free, (void *)PyObject_GC_Del},
    {Py_tp_dealloc, (void *)SbkDummyDealloc},
    {0, 0}
};
static PyType_Spec PySideSignalMetaType_spec = {
    "PySide2.QtCore.MetaSignal",
    0,
    // sizeof(PyHeapTypeObject) is filled in by PyType_FromSpecWithBases
    // which calls PyType_Ready which calls inherit_special.
    0,
    Py_TPFLAGS_DEFAULT,
    PySideSignalMetaType_slots,
};

You can find the checkins here. This branch contains everything relevant in small steps.

https://github.com/pyside/pyside2-setup/commit/2f0658be36107097810985f2190fe0f2acfba178

The first working transformation was in the commit
"PEP 384-8-HT-4: Successful Restart using PyType_FromSpec".

I have yet no idea how to extract a minimum example that produces this problem.

Summary: 
In a way, without being heaptypes, the old types were dynamic, too, and inserting
something that was not there before was a bad idea.

(sorry, there is more...)

----------

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

From report at bugs.python.org  Wed Sep 12 14:25:02 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:25:02 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536776702.55.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Bumsik Kim <kbumsik at gmail.com>:


----------
pull_requests: +8651

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

From report at bugs.python.org  Wed Sep 12 14:32:01 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 12 Sep 2018 18:32:01 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536777121.2.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset aca819fb494d4801b3e5b5b507b17cab772c1b40 by Yury Selivanov (Bumsik Kim) in branch 'master':
bpo-33649: Fix doc to reflect changes in 47cd10d (or bpo-23347) (GH-9219)
https://github.com/python/cpython/commit/aca819fb494d4801b3e5b5b507b17cab772c1b40


----------

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

From report at bugs.python.org  Wed Sep 12 14:35:21 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:35:21 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536777321.16.0.956365154283.issue33649@psf.upfronthosting.co.za>


Bumsik Kim <kbumsik at gmail.com> added the comment:

Hi, I came from #33986. I noticed that the new doc still does not reflect a design change on SubprocessTransport.close() done in #23347. I made a PR to fix that.

BTW this is opposed to the original PEP 3156: https://www.python.org/dev/peps/pep-3156/#subprocess-transports . I don't know if it is commonly happens.

----------
nosy: +kbumsik

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

From report at bugs.python.org  Wed Sep 12 14:39:03 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Wed, 12 Sep 2018 18:39:03 +0000
Subject: [docs] [issue33986] asyncio: Typo in documentation:
 BaseSubprocessTransport -> SubprocessTransport
In-Reply-To: <1530139574.74.0.56676864532.issue33986@psf.upfronthosting.co.za>
Message-ID: <1536777543.01.0.956365154283.issue33986@psf.upfronthosting.co.za>


Bumsik Kim <kbumsik at gmail.com> added the comment:

#33649 does not solve a problem of SubprocessTransport.close() done in #23347. I made a PR #33649 directly to fix that.

----------

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

From report at bugs.python.org  Wed Sep 12 16:03:24 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 12 Sep 2018 20:03:24 +0000
Subject: [docs] [issue34648] Confirm the type of traceback.format_list
 post-3.5
Message-ID: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

So I'm fixing a bug in typeshed's accounting of the traceback module (https://github.com/python/typeshed/pull/2436) and the documented semantics of traceback.format_list don't quite smell to me what I think they might be intended to be:

1) I know it has the name "format_list", but is it really intended to require a list? Why not a sequence, or a collection, or an iterable? I would think it would be fine to pass an iterable to traceback.format_list. Is it fine?

2) What is the desired component type for the aggregate passed to format_list? In 3.4-and-earlier it was Tuple[str, int, str, Optional[str]], and that still works in 3.5-through-3.8, but is that just backwards compatibility or is that something that users of traceback.format_list should feel encouraged to continue passing into the future?

Sorry for filing a bug just to ask "huh; really?" but... please confirm?

----------
assignee: docs at python
components: Documentation
messages: 325175
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: Confirm the type of traceback.format_list post-3.5
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/issue34648>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:29:15 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 12 Sep 2018 20:29:15 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536784155.39.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

... and while we're here, how about StackSummary.from_list's "a_list" parameter as well:

3) Can it be Iterable? It looks like it can be Iterable? Is it fine for it to be Iterable?

4) Should the component type of "a_list" be FrameSummary? Is the support for Tuple[str, int, str, Optional[str]] merely backward-looking, or is new code encouraged to pass Tuple[str, int, str, Optional[str]] objects?

----------
title: Confirm the type of traceback.format_list post-3.5 -> Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5

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

From report at bugs.python.org  Wed Sep 12 17:16:19 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 12 Sep 2018 21:16:19 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536786979.08.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8664

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

From report at bugs.python.org  Wed Sep 12 17:58:43 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 12 Sep 2018 21:58:43 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536789523.91.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8666

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

From report at bugs.python.org  Wed Sep 12 20:00:59 2018
From: report at bugs.python.org (Sebastian Rittau)
Date: Thu, 13 Sep 2018 00:00:59 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536796859.44.0.249678724859.issue34648@psf.upfronthosting.co.za>


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


----------
nosy: +srittau

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

From report at bugs.python.org  Wed Sep 12 20:05:21 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 13 Sep 2018 00:05:21 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536797120.73.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 5b7cbd602e57265604d6c099fd174b1c7917f861 by Yury Selivanov (Carol Willing) in branch 'master':
bpo-33649: Edit asyncio eventloop doc - second pass (GH-9233)
https://github.com/python/cpython/commit/5b7cbd602e57265604d6c099fd174b1c7917f861


----------

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

From report at bugs.python.org  Thu Sep 13 12:59:34 2018
From: report at bugs.python.org (Farhaan Bukhsh)
Date: Thu, 13 Sep 2018 16:59:34 +0000
Subject: [docs] [issue29341] Missing accepting path-like object in
 docstrings of os module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1536857974.07.0.956365154283.issue29341@psf.upfronthosting.co.za>


Farhaan Bukhsh <farhaan.bukhsh at gmail.com> added the comment:

Hey I would like to make this change which file should I look into?

----------
nosy: +fhackdroid

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

From zoodss at yandex.ru  Thu Sep 13 13:13:52 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Thu, 13 Sep 2018 20:13:52 +0300
Subject: [docs] Several typos in Python 3.7 docs.
Message-ID: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>

https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
"function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."

https://docs.python.org/3/reference/expressions.html#agen.__anext__
"When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".

"the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".

https://docs.python.org/3/reference/expressions.html#agen.athrow
"an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.

Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)

https://docs.python.org/3/reference/expressions.html#parenthesized-forms
"Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.

Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.

--?
Sincerely,
ZooDSS
ZooDSS at yandex.ru



From report at bugs.python.org  Thu Sep 13 14:08:51 2018
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 13 Sep 2018 18:08:51 +0000
Subject: [docs] [issue33239] tempfile module: functions with the 'buffering'
 option are incorrectly documented
In-Reply-To: <1523128962.9.0.682650639539.issue33239@psf.upfronthosting.co.za>
Message-ID: <1536862131.33.0.956365154283.issue33239@psf.upfronthosting.co.za>


Antti Haapala <antti at haapala.name> added the comment:

This week we were bit by this in production. I foolishly thought that the  docs would give me correct default values... It is worse that it didn't actually occur until we went over the limit.

----------
nosy: +ztane

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

From zachary.ware+pydocs at gmail.com  Thu Sep 13 14:13:46 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 13 Sep 2018 11:13:46 -0700
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
Message-ID: <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>

On Thu, Sep 13, 2018 at 10:15 AM ?????? ???????? <zoodss at yandex.ru> wrote:
> https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
> "function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."
>
> https://docs.python.org/3/reference/expressions.html#agen.__anext__
> "When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".
>
> "the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".
>
> https://docs.python.org/3/reference/expressions.html#agen.athrow
> "an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.
>
> Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)
>
> https://docs.python.org/3/reference/expressions.html#parenthesized-forms
> "Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.
>
> Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.

Would you be willing to submit Pull Requests for these issues on
GitHub?  For most of these issues you've found, it should be
sufficient to use the web interface to edit the files (found under
https://github.com/python/cpython/tree/master/Doc).  If not, that's
fine and we can handle things in other ways, but making the changes
yourself might be simpler all around :)

-- 
Zach

From report at bugs.python.org  Thu Sep 13 14:17:57 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 18:17:57 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536862677.66.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8704

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

From report at bugs.python.org  Thu Sep 13 14:25:52 2018
From: report at bugs.python.org (Johannes M.)
Date: Thu, 13 Sep 2018 18:25:52 +0000
Subject: [docs] [issue34665] Py_FinalizeEx() - Bugs & caveats - Add info
 that NumPy and Pandas don't support reinitialization
Message-ID: <1536863152.32.0.956365154283.issue34665@psf.upfronthosting.co.za>


New submission from Johannes M. <jcmueller at posteo.de>:

Since about a decade, it's a know problem that NumPy and Pandas initialization function crashes on reinitialization after a call to Py_Finalize() + Py_Initialize().

[https://github.com/numpy/numpy/issues/8097]
[https://github.com/numpy/numpy/issues/11925]

It seems to be unlikely that this problem gets fixed soon. Due to the popularity of the modules, it would be good to add this information to the documentation of Py_FinalizeEx(), such that developers, who are planning to embed Python get this information already at the moment when they read the documentation.

I would suggest to change the following sentence:

    Some extensions may not work properly if their
    initialization routine is called more than once;

to

    Some extensions, like NumPy and Pandas, may not work properly if their
    initialization routine is called more than once;

----------
assignee: docs at python
components: Documentation
messages: 325275
nosy: docs at python, jcmuel
priority: normal
severity: normal
status: open
title: Py_FinalizeEx() - Bugs & caveats - Add info that NumPy and Pandas don't support reinitialization
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 19:27:31 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 13 Sep 2018 23:27:31 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536881251.45.0.956365154283.issue26979@psf.upfronthosting.co.za>


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

Thanks! I think that explains enough of the issue.

Converting static types to heap ones is just one way you can use PyType_Spec. Another is writing new types, which should work much like Python classes.

So I don't think we should change the default, but rather document the use case. I'd rather update the docs after GH-9154 is merged, so this is blocked now.
 
I'll also try making an explicit `{Py_tp_dealloc, NULL}` override the inherited value, as per Serhiy's suggestion. But it'll only go to 3.8, so it won't help PySide now.

----------

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

From report at bugs.python.org  Thu Sep 13 19:39:12 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 23:39:12 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536881952.79.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8715

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

From report at bugs.python.org  Thu Sep 13 20:14:29 2018
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 14 Sep 2018 00:14:29 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1536884068.66.0.956365154283.issue34648@psf.upfronthosting.co.za>


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

> 1) I know it has the name "format_list", but is it really intended to require a
> list? Why not a sequence, or a collection, or an iterable? I would think it would
> be fine to pass an iterable to traceback.format_list. Is it fine?

In 3.4, format_list() was documented to accept return values of extract_tb() and extract_stack() functions and they both were returned lists:

    def extract_tb(tb, limit=None):
        return list(_extract_tb_iter(tb, limit=limit))

    def extract_stack(f=None, limit=None):
        stack = list(_extract_stack_iter(_get_stack(f), limit=limit))
        stack.reverse()
        return stack

I don't think we support the "pass manually created iterables" case here.

> 2) What is the desired component type for the aggregate passed to
> format_list? In 3.4-and-earlier it was Tuple[str, int, str,
> Optional[str]], and that still works in 3.5-through-3.8, but is that
> just backwards compatibility [...]

Yes, the old API is still supported for backwards compatibility reasons.

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

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

From report at bugs.python.org  Thu Sep 13 21:00:22 2018
From: report at bugs.python.org (Sebastian Bassi)
Date: Fri, 14 Sep 2018 01:00:22 +0000
Subject: [docs] [issue34671] Remove references to Benevolent Dictator
Message-ID: <1536886822.26.0.956365154283.issue34671@psf.upfronthosting.co.za>


New submission from Sebastian Bassi <sbassi at users.sourceforge.net>:

Following the trend initiated at https://bugs.python.org/issue34605, I want to point out that the term dictator has a negative connotation in Argentina and other countries where we suffered bloody dictatorship (30000 dead and missing persons, or "desaparecidos" as we call it).
I understand that the former title BDFL may be funny for most developers, but the term "benevolent dictatorship" (or it Spanish equivalent "dictablanda") was used in Chile by the Pinochet's regime.
This title doesn't reflect the democratic nature of the whole project.
My suggestion is to take this into account when defining PEP-8010 and related documentation.

----------
assignee: docs at python
components: Documentation
messages: 325315
nosy: docs at python, sbassi
priority: normal
severity: normal
status: open
title: Remove references to Benevolent Dictator
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 21:28:24 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 01:28:24 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536888504.62.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 4e824e96491f33c8a8462aa4970c55942064ae76 by Miss Islington (bot) (Carol Willing) in branch 'master':
bpo-33649: Polish asyncio subprocess and sync docs (GH-9285)
https://github.com/python/cpython/commit/4e824e96491f33c8a8462aa4970c55942064ae76


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

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

From report at bugs.python.org  Fri Sep 14 00:28:14 2018
From: report at bugs.python.org (Christian Tismer)
Date: Fri, 14 Sep 2018 04:28:14 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536899294.18.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

Petr, Fine! PySide's problems are solved for now, no worries.
But as mentioned, there is more.


Problem 1)
----------

There is another thing that gives problems:

When creating types which have fields "behind" the normal type fields,
PySide had explicit structs that contained PyHeaptypeObject explicitly,
plus the extra fields.

We changed that into a normal PyType declaration (opaque) and a pointer
expression that dynamically computed the offset.

For that, we needed sizeof(PyType_Type). Ok, that could be solved by Python 
code, but this "trick" is not so obvious and should be documented, or
a variable should be provided that gives the heap type size, dynamically.


Problem 2)
----------

Harder is this:

For some operations, we needed access to fields of normal types, for instance the
tp_new field of PyType_Type. That is not possible, although it would be easy:

PyType_GetSlot forbids access to normal types, rigorously.
But concerning the "normal" type fields, those which are not indirections,
it would cost nothing to allow this for normal types.

This uses a property of types which has not explicitly been used:

* All types have the same basic structure *

That means, we can allow access to all "tp_" fields with simply changing a check
in PyType_GetSlot.

I'm not sure if that information should be made official. May be it should be hidden
and PyType_GetSlot should be made more complicated. But the proposed change comes
at no cost. And the prefixes like "nb_" or "sq_" are still visible, so I don't
think there was an intent to make type structures completely opaque?

For PySide, it was crucial to use that information to compute the offset of
certain fields of normal types, which is a bit of a Pep 384 breach.
We wrote code that verifies that these assumptions are all valid, but I would be 
happy to remove that and revert to only using PyType_GetSlot.

Please let me know if I can help with something!

Cheers - Chris

----------

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

From report at bugs.python.org  Fri Sep 14 00:50:24 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 04:50:24 +0000
Subject: [docs] [issue34552] Clarify built-in types comparisons
In-Reply-To: <1535693872.67.0.56676864532.issue34552@psf.upfronthosting.co.za>
Message-ID: <1536900624.91.0.956365154283.issue34552@psf.upfronthosting.co.za>


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


New changeset 1aeba7458d2aaf8a03b5d443179d122ceb2ccece by Miss Islington (bot) (Windson yang) in branch 'master':
bpo-34552: Clarify built-in types comparisons (GH-9035)
https://github.com/python/cpython/commit/1aeba7458d2aaf8a03b5d443179d122ceb2ccece


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

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

From report at bugs.python.org  Fri Sep 14 03:29:31 2018
From: report at bugs.python.org (Freed_Slave)
Date: Fri, 14 Sep 2018 07:29:31 +0000
Subject: [docs] [issue34675] Avoid terminology related to slavery
Message-ID: <1536910171.17.0.956365154283.issue34675@psf.upfronthosting.co.za>


New submission from Freed_Slave <Freed_Slave at notmailinator.com>:

It is very good to see that "master" and "slave" terminology was removed from the project, however there are still references to "owned" references, as if these references were property. There are also things needing to be "freed" as if they were indentured servants.

I would like to open up discussion about better terminology - and when better terminology has been agreed upon I do not mind submitting a PR to get rid of this exclusive language.

"Freed" terminology:

* https://github.com/python/cpython/search?q=freed&unscoped_q=freed

There are also additional instances were "free" is used instead of "clear" but the context makes it harder to discover with a naive search.

"Owned" terminology:

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=owned&type=

"Master/Slave" terminology, now removed:

* https://bugs.python.org/issue34605

On the topic of inclusive/exclusive terminology, there are other problematic things that should be addressed - either here or in separate issues. However I'd like to draw attention to one particularly sexist email in `test_smtplib.py` "my_mom at great.cooker.com" - hilarious! Not. It especially sticks out among the more generic and inclusive test emails. I particularly like the inclusion of "P?olo <f?o at bar.com>" but then in a test email he makes a sexual innuendo.

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=mom&type=

* Said innuendo: "oh l? l?, know what I mean, know what I mean?\n\n")"

----------
assignee: docs at python
components: Documentation
messages: 325331
nosy: Freed_Slave, docs at python
priority: normal
severity: normal
status: open
title: Avoid terminology related to slavery
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 03:37:36 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 07:37:36 +0000
Subject: [docs] [issue33774] Document that @lru_cache caches based on
 exactly how the function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536910656.92.0.249678724859.issue33774@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 14 03:55:12 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 07:55:12 +0000
Subject: [docs] [issue33774] Document that @lru_cache caches based on
 exactly how the function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536911712.83.0.249678724859.issue33774@psf.upfronthosting.co.za>


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


----------
pull_requests: +8728

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

From report at bugs.python.org  Fri Sep 14 04:14:28 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 14 Sep 2018 08:14:28 +0000
Subject: [docs] [issue33774] Document that @lru_cache caches based on
 exactly how the function arguments are specified
In-Reply-To: <1528217935.32.0.592728768989.issue33774@psf.upfronthosting.co.za>
Message-ID: <1536912868.74.0.249678724859.issue33774@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 14 04:14:30 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 08:14:30 +0000
Subject: [docs] [issue31305] 'pydoc -w import' report "no Python
 documentation found for 'import'"
Message-ID: <1536912870.64.0.956365154283.issue31305@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

> Run "pydoc -w <name>" to write out the HTML documentation for a module
to a file named "<name>.html".

As mentioned in the help this works only for modules and since import is a keyword it throws an error. Maybe this could be added as an enhancement?

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Sep 14 07:20:34 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 14 Sep 2018 11:20:34 +0000
Subject: [docs] [issue34675] Avoid terminology related to slavery
In-Reply-To: <1536910171.17.0.956365154283.issue34675@psf.upfronthosting.co.za>
Message-ID: <1536924034.26.0.956365154283.issue34675@psf.upfronthosting.co.za>


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

No thanks.

----------
nosy: +Mariatta
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep 14 08:02:28 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 14 Sep 2018 12:02:28 +0000
Subject: [docs] [issue34671] Remove references to Benevolent Dictator
In-Reply-To: <1536886822.26.0.956365154283.issue34671@psf.upfronthosting.co.za>
Message-ID: <1536926548.45.0.956365154283.issue34671@psf.upfronthosting.co.za>


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

No thanks.

----------
nosy: +Mariatta
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep 14 08:17:49 2018
From: report at bugs.python.org (mediator42)
Date: Fri, 14 Sep 2018 12:17:49 +0000
Subject: [docs] [issue34677] Event scheduler page example
Message-ID: <1536927469.93.0.956365154283.issue34677@psf.upfronthosting.co.za>


New submission from mediator42 <h.lensch at lmt.uni-saarland.de>:

Hi,
I am pretty confident, that the example you put on the Event scheduler page (https://docs.python.org/3.7/library/sched.html) is somehow strange. 

If the priority argument behave as described, it should print the "keyword" line before the "positional" line, since these events are scheduled for the same time but "keyword" has a higher priority than "positional".

When I run this script on my PC it behaves correctly.

Best reagrds

----------
assignee: docs at python
components: Documentation
messages: 325345
nosy: docs at python, mediator42
priority: normal
severity: normal
status: open
title: Event scheduler page example
type: behavior
versions: Python 3.7

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

From zoodss at yandex.ru  Fri Sep 14 09:07:42 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Fri, 14 Sep 2018 16:07:42 +0300
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
Message-ID: <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>

Well, this is my issue, but i don't know how to use GitHub =( No one teaches this in Russia, but i will try and learn it!

At the same time i would be very thankful if you do this for me for now. =) I will try my best to learn how to use GH.

--
ZooDSS

13.09.2018, 21:13, "Zachary Ware" <zachary.ware+pydocs at gmail.com>:
> On Thu, Sep 13, 2018 at 10:15 AM ?????? ???????? <zoodss at yandex.ru> wrote:
>> ?https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
>> ?"function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."
>>
>> ?https://docs.python.org/3/reference/expressions.html#agen.__anext__
>> ?"When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".
>>
>> ?"the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".
>>
>> ?https://docs.python.org/3/reference/expressions.html#agen.athrow
>> ?"an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.
>>
>> ?Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)
>>
>> ?https://docs.python.org/3/reference/expressions.html#parenthesized-forms
>> ?"Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.
>>
>> ?Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.
>
> Would you be willing to submit Pull Requests for these issues on
> GitHub? For most of these issues you've found, it should be
> sufficient to use the web interface to edit the files (found under
> https://github.com/python/cpython/tree/master/Doc). If not, that's
> fine and we can handle things in other ways, but making the changes
> yourself might be simpler all around :)
>
> --
> Zach

--?
? ?????????,
ZooDSS
ZooDSS at yandex.ru


From report at bugs.python.org  Fri Sep 14 11:48:40 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 15:48:40 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536940120.64.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Carol Willing <willingc at gmail.com>:


----------
pull_requests: +8735

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

From report at bugs.python.org  Fri Sep 14 12:29:24 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 16:29:24 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1536942564.13.0.956365154283.issue26979@psf.upfronthosting.co.za>


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

1) If I understand correctly, this problem could be solved by per-class C storage? Something like PyModuleDef.m_size / PyModule_GetState, but for classes?

2) Making PyType_GetSlot work for static types would not be trivial. 
All types do have the same *basic* structure (the tp_* fields), but the nb_*/sq_*/etc. fields don't need to be in the same order, and might not exist at all.
Even making it work for the tp_* fields only would bake in some assumptions I do want to get rid of.
I'd like to understand your use case better. Do you have a specific example here?

----------

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

From report at bugs.python.org  Fri Sep 14 12:49:47 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 16:49:47 +0000
Subject: [docs] [issue34682] Typo reports on docs@
Message-ID: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

>From ZooDSS (?????? ????????) on docs@:

https://mail.python.org/pipermail/docs/2018-September/037223.html :
"""
https://docs.python.org/3/reference/datamodel.html#metaclass-example - 
    "uses an collections.OrderedDict to remember" when it is better to use "uses a collections.OrderedDict to remember"

https://docs.python.org/3/reference/executionmodel.html#exceptions
"Exceptions are a means" - Is it correct to use "a" here? "means" means a lot of them. "a" means one.

"In either case, it prints a stack backtrace" - most of the time in Python documentation term "traceback" is used instead of "backtrace". It may mislead newcomers, so they will think, that this is potentially a new term.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"Due to their side effects on the containing scope, yield expressions are not permitted as part of the implicitly defined scopes used to implement comprehensions and generator expressions (in Python 3.7, such expressions emit DeprecationWarning when compiled, in Python 3.8+ they will emit SyntaxError).." - two periods in the end of the sentence.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"...or automatically when the sub-iterator is a generator (by returning a value from the sub-generator)." - inconsistent use of "sub-iterator" term. Previously subiterator was referenced several times as "subiterator" not "sub-iterator".

If i understood something wrong, then i am sorry.
"""

https://mail.python.org/pipermail/docs/2018-September/037224.html :
"""
https://docs.python.org/3/reference/expressions.html#yield-expressions

Term "sub-generator" is used in PEP 280 without dash ("-") symbol - "subgenerator". At the same time it is used as "sub-generator" 2 times on this page:

"generator (by returning a value from the sub-generator)." - here.

"The proposal to introduce the yield_from syntax, making delegation to sub-generators easy." - and here.
"""

https://mail.python.org/pipermail/docs/2018-September/037237.html :
"""
https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
"function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."

https://docs.python.org/3/reference/expressions.html#agen.__anext__
"When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".

"the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".

https://docs.python.org/3/reference/expressions.html#agen.athrow
"an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.

Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)

https://docs.python.org/3/reference/expressions.html#parenthesized-forms
"Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.

Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.
"""

----------
assignee: docs at python
components: Documentation
messages: 325362
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Typo reports on docs@
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From zachary.ware+pydocs at gmail.com  Fri Sep 14 12:54:52 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 14 Sep 2018 09:54:52 -0700
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
Message-ID: <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>

On Fri, Sep 14, 2018 at 6:09 AM ?????? ???????? <zoodss at yandex.ru> wrote:
> Well, this is my issue, but i don't know how to use GitHub =( No one teaches this in Russia, but i will try and learn it!
>
> At the same time i would be very thankful if you do this for me for now. =) I will try my best to learn how to use GH.

No problem!  I've opened https://bugs.python.org/issue34682 to track
your reports so they don't get lost (and please let me know if I'm
attributing you incorrectly).  If you are interested in learning how
we (the CPython development team) use GitHub, you may be interested in
joining the core-mentorship at python.org mailing list
(https://mail.python.org/mm3/mailman3/lists/core-mentorship.python.org/)
or having a look through our development guide
(https://devguide.python.org/).  We're happy to help you learn what
you need to fix our bugs :)

Regards,
--
Zach

From report at bugs.python.org  Fri Sep 14 12:58:37 2018
From: report at bugs.python.org (Geoffrey Spear)
Date: Fri, 14 Sep 2018 16:58:37 +0000
Subject: [docs] [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1536944317.91.0.956365154283.issue34682@psf.upfronthosting.co.za>


Geoffrey Spear <geoffspear at gmail.com> added the comment:

"Means" is perfectly acceptable to use as a singular form: http://grammarist.com/usage/means/ (the rest of these all look like legitimate typos)

----------
nosy: +geoffreyspear

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

From zoodss at yandex.ru  Fri Sep 14 13:02:22 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Fri, 14 Sep 2018 20:02:22 +0300
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
Message-ID: <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>

For sure i wanted to join this mailing list! But i didn't (and still don't know) how! Because it doesn't open a page in the browser, and if i need to use some application, then i don't know which one to use. =)

I am always happy to help fix some minor bugs. =)

Yes, you attributing me correctly, but if it is not big of a deal, can you remove my real name and second name from the post? Because, some people on the internet are attracted to me, and they will not miss their chance. =) But if it's a problem, then leave it as it is.

14.09.2018, 19:55, "Zachary Ware" <zachary.ware+pydocs at gmail.com>:
> On Fri, Sep 14, 2018 at 6:09 AM ?????? ???????? <zoodss at yandex.ru> wrote:
>> ?Well, this is my issue, but i don't know how to use GitHub =( No one teaches this in Russia, but i will try and learn it!
>>
>> ?At the same time i would be very thankful if you do this for me for now. =) I will try my best to learn how to use GH.
>
> No problem! I've opened https://bugs.python.org/issue34682 to track
> your reports so they don't get lost (and please let me know if I'm
> attributing you incorrectly). If you are interested in learning how
> we (the CPython development team) use GitHub, you may be interested in
> joining the core-mentorship at python.org mailing list
> (https://mail.python.org/mm3/mailman3/lists/core-mentorship.python.org/)
> or having a look through our development guide
> (https://devguide.python.org/). We're happy to help you learn what
> you need to fix our bugs :)
>
> Regards,
> --
> Zach

--?
? ?????????,
ZooDSS
ZooDSS at yandex.ru


From report at bugs.python.org  Fri Sep 14 13:06:58 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 17:06:58 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536944818.86.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset c9d66f0ed4f07b9d184d22abbfdd4c3c8e2702df by Carol Willing in branch 'master':
bpo-33649 Polish asyncio docs on queues, protocols, and subproccesses (#9306)
https://github.com/python/cpython/commit/c9d66f0ed4f07b9d184d22abbfdd4c3c8e2702df


----------

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

From zoodss at yandex.ru  Fri Sep 14 13:07:04 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Fri, 14 Sep 2018 20:07:04 +0300
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
Message-ID: <6959501536944824@sas1-fb8a605c4548.qloud-c.yandex.net>

Oh, and thank you very much for all the work with issue opening! That was something i didn't notice.

Sincerely,
ZooDSS

14.09.2018, 19:55, "Zachary Ware" <zachary.ware+pydocs at gmail.com>:
> On Fri, Sep 14, 2018 at 6:09 AM ?????? ???????? <zoodss at yandex.ru> wrote:
>> ?Well, this is my issue, but i don't know how to use GitHub =( No one teaches this in Russia, but i will try and learn it!
>>
>> ?At the same time i would be very thankful if you do this for me for now. =) I will try my best to learn how to use GH.
>
> No problem! I've opened https://bugs.python.org/issue34682 to track
> your reports so they don't get lost (and please let me know if I'm
> attributing you incorrectly). If you are interested in learning how
> we (the CPython development team) use GitHub, you may be interested in
> joining the core-mentorship at python.org mailing list
> (https://mail.python.org/mm3/mailman3/lists/core-mentorship.python.org/)
> or having a look through our development guide
> (https://devguide.python.org/). We're happy to help you learn what
> you need to fix our bugs :)
>
> Regards,
> --
> Zach

--?
? ?????????,
ZooDSS
ZooDSS at yandex.ru


From zachary.ware+pydocs at gmail.com  Fri Sep 14 13:25:57 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 14 Sep 2018 10:25:57 -0700
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
 <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>
Message-ID: <CAKJDb-OHnko1TgvgJ975Jys7Gwgo4zcHxpzM=TxqRnn4W+0nPQ@mail.gmail.com>

On Fri, Sep 14, 2018 at 10:04 AM ?????? ???????? <zoodss at yandex.ru> wrote:
> For sure i wanted to join this mailing list! But i didn't (and still don't know) how! Because it doesn't open a page in the browser, and if i need to use some application, then i don't know which one to use. =)

The https://mail.python.org/mm3/mailman3/lists/core-mentorship.python.org/
link should open in your browser (or copying and pasting it into your
address bar should get you to the web page), and from there you can
either create an account ("Sign Up" link in the far upper right
corner) or subscribe without an account at the bottom of the page,
which will allow you to send email to core-mentorship at python.org and
receive replies.

For this (docs at python.org) mailing list, you can subscribe using the
middle section of https://mail.python.org/mailman/listinfo/docs

> I am always happy to help fix some minor bugs. =)
>
> Yes, you attributing me correctly, but if it is not big of a deal, can you remove my real name and second name from the post? Because, some people on the internet are attracted to me, and they will not miss their chance. =) But if it's a problem, then leave it as it is.

I can't change where I've already used your name (or where it's
already attached to your messages to this list (see
https://mail.python.org/pipermail/docs/2018-September/thread.html),
but I can just use ZooDSS from now if you prefer :)

-- 
Zach

From report at bugs.python.org  Fri Sep 14 13:38:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 17:38:00 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536946680.07.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8739

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

From zoodss at yandex.ru  Fri Sep 14 13:40:08 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Fri, 14 Sep 2018 20:40:08 +0300
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <CAKJDb-OHnko1TgvgJ975Jys7Gwgo4zcHxpzM=TxqRnn4W+0nPQ@mail.gmail.com>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
 <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>
 <CAKJDb-OHnko1TgvgJ975Jys7Gwgo4zcHxpzM=TxqRnn4W+0nPQ@mail.gmail.com>
Message-ID: <9917121536946808@myt5-02b80404fd9e.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180914/33c06022/attachment.html>

From report at bugs.python.org  Fri Sep 14 13:48:54 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 17:48:54 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1536947334.12.0.956365154283.issue28955@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset ad8a0004206ba7aec5a8a60fce413da718080db2 by Benjamin Peterson (Tony Flury) in branch 'master':
closes bpo-28955: Clarified comparisons between NaN and number in reference documentation (GH-5982)
https://github.com/python/cpython/commit/ad8a0004206ba7aec5a8a60fce413da718080db2


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Sep 14 13:49:06 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 17:49:06 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1536947346.33.0.249678724859.issue28955@psf.upfronthosting.co.za>


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


----------
pull_requests: +8740

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

From report at bugs.python.org  Fri Sep 14 13:50:23 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 14 Sep 2018 17:50:23 +0000
Subject: [docs] [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1536947423.17.0.956365154283.issue34682@psf.upfronthosting.co.za>


Eric V. Smith <eric at trueblade.com> added the comment:

Agreed with @geoffreyspear: "means" is okay, the rest of the changes look good.

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

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

From report at bugs.python.org  Fri Sep 14 14:05:45 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 14 Sep 2018 18:05:45 +0000
Subject: [docs] [issue28955] Not matched behavior of numeric comparison with
 the documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1536948345.84.0.956365154283.issue28955@psf.upfronthosting.co.za>


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


New changeset ca2fa2841f8e3ce5213a0e8c0abc1d0fdc7d386b by Miss Islington (bot) in branch '3.7':
closes bpo-28955: Clarified comparisons between NaN and number in reference documentation (GH-5982)
https://github.com/python/cpython/commit/ca2fa2841f8e3ce5213a0e8c0abc1d0fdc7d386b


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

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

From report at bugs.python.org  Fri Sep 14 15:11:49 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 19:11:49 +0000
Subject: [docs] [issue24937] Multiple problems in getters & setters in
 capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1536952309.3.0.956365154283.issue24937@psf.upfronthosting.co.za>


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

Well, hasn't this languished for a while.

I've talked with Benjamin, and he's OK with just removing the "Porting Extension Modules to Python 3" HOWTO, and replacing it by links to external guides that do a much better job at documenting this.

Also, Python 2.6 and 3.0 is EOL; it should be fine to scrub capsulethunk.

----------

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

From report at bugs.python.org  Fri Sep 14 15:12:22 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Fri, 14 Sep 2018 19:12:22 +0000
Subject: [docs] [issue24937] Multiple problems in getters & setters in
 capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1536952342.71.0.249678724859.issue24937@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


----------
pull_requests: +8743

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

From report at bugs.python.org  Fri Sep 14 16:32:13 2018
From: report at bugs.python.org (Carol Willing)
Date: Fri, 14 Sep 2018 20:32:13 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536957132.91.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 3faaa8857a42a36383bb18425444e597fc876797 by Carol Willing (Yury Selivanov) in branch 'master':
bpo-33649: Refresh Tasks and Futures pages (#9314)
https://github.com/python/cpython/commit/3faaa8857a42a36383bb18425444e597fc876797


----------

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

From report at bugs.python.org  Fri Sep 14 16:55:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 20:55:44 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536958544.32.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8744

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

From zachary.ware+pydocs at gmail.com  Fri Sep 14 17:28:56 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 14 Sep 2018 14:28:56 -0700
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <9917121536946808@myt5-02b80404fd9e.qloud-c.yandex.net>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
 <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>
 <CAKJDb-OHnko1TgvgJ975Jys7Gwgo4zcHxpzM=TxqRnn4W+0nPQ@mail.gmail.com>
 <9917121536946808@myt5-02b80404fd9e.qloud-c.yandex.net>
Message-ID: <CAKJDb-M3GsGzTt2UuAGOaixAk_wKRcuQVYjLgeTUB__YnzHJdw@mail.gmail.com>

On Fri, Sep 14, 2018 at 10:40 AM ?????? ???????? <zoodss at yandex.ru> wrote:
> Yes, it opens this link, and for some reason Firefox says that there is a "Problem loading page Unable to connect", and "The site could be temporarily unavailable or too busy. Try again in a few moments." And this message i got several times in the past months when i was trying to join list. And the same problem for any link, containing "mail.Python.org". I can see it trying, but nope.

Ah, that is unfortunate.  We have had reports from other Russians
about intermittent problems with connecting to our sites, likely due
to issues beyond our control.  However, you should also be able to
subscribe by sending a message to `<list-name>-join at python.org`, for
example, `core-mentorship-join at python.org`.

-- 
Zach

From report at bugs.python.org  Fri Sep 14 17:33:36 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 21:33:36 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536960816.04.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8748

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

From report at bugs.python.org  Fri Sep 14 17:57:42 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 21:57:42 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536962262.2.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 6c7316439d966cdbc76ffcc005e5d9c563064ba2 by Yury Selivanov in branch 'master':
bpo-33649: Refresh asyncio docs landing page (GH-9322)
https://github.com/python/cpython/commit/6c7316439d966cdbc76ffcc005e5d9c563064ba2


----------

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

From report at bugs.python.org  Fri Sep 14 18:11:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 22:11:28 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536963087.93.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 7372c3bbefb4763dbd1b6d66f7971bef28c0f056 by Yury Selivanov in branch 'master':
bpo-33649: Add high-level APIs cheat-sheet (GH-9319)
https://github.com/python/cpython/commit/7372c3bbefb4763dbd1b6d66f7971bef28c0f056


----------

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

From report at bugs.python.org  Fri Sep 14 18:56:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 22:56:08 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536965768.42.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8749

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

From report at bugs.python.org  Fri Sep 14 19:57:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 14 Sep 2018 23:57:19 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1536969438.49.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 805e27eff65d51f7aea2c00ccbb4f5d44f4499f2 by Yury Selivanov in branch 'master':
bpo-33649: Fix asyncio-dev (GH-9324)
https://github.com/python/cpython/commit/805e27eff65d51f7aea2c00ccbb4f5d44f4499f2


----------

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

From report at bugs.python.org  Sat Sep 15 02:46:39 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 15 Sep 2018 06:46:39 +0000
Subject: [docs] [issue29341] Missing accepting path-like object in
 docstrings of os module functions
In-Reply-To: <1485064061.59.0.597221589705.issue29341@psf.upfronthosting.co.za>
Message-ID: <1536993999.31.0.249678724859.issue29341@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Sep 15 03:14:28 2018
From: report at bugs.python.org (Andreas Lutro)
Date: Sat, 15 Sep 2018 07:14:28 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1536995668.66.0.956365154283.issue25296@psf.upfronthosting.co.za>


Andreas Lutro <anlutro at gmail.com> added the comment:

I see this has been closed, but the page on the devguide is still really hard to find. On the python IRC channel I often see questions about this and I always have a hard time finding the page with the correct information.

If I google "python version support" or "python version end of life" or "python version lifecycle" I don't arrive at that page. For some of these searches I even end up on a separate devcycle[1] page which only contains old versions of python. Compare that to PHP, where the official "supported versions" page is the top result no matter what I search for.

Nevermind the fact that the lifecycle of python versions is relevant to non-developers as well, making it un-intuitive to go to the devguide to find this information.

I really think this needs to be made part of python.org's main website, with some good SEO.

[1] https://devguide.python.org/devcycle/

----------
nosy: +Andreas Lutro

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

From report at bugs.python.org  Sat Sep 15 04:46:29 2018
From: report at bugs.python.org (Christian Tismer)
Date: Sat, 15 Sep 2018 08:46:29 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537001189.7.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

> 1) If I understand correctly, this problem could be solved by
> per-class C storage? Something like PyModuleDef.m_size /
> PyModule_GetState, but for classes?

No. To obtain sizeof(PyType_Type), we simply used the Python code

    type.__basicsize__

It is a simple trick, but probably very few people know this path
to get that info. At least, for me it took way too long ;-)


> 2) Making PyType_GetSlot work for static types would not be trivial.
>  All types do have the same *basic* structure (the tp_* fields), but
> the nb_*/sq_*/etc. fields don't need to be in the same order, and
> might not exist at all. Even making it work for the tp_* fields only
> would bake in some assumptions I do want to get rid of.

That's my question. Do you want to hide the fact that some fields
are direct and others are indirect? I don't think that will ever be 
changed before Python 4.0, so why put this burden on every user, then?

I would simply give access to tp_* for all types and that's it.

> I'd like to
> understand your use case better. Do you have a specific example
> here?

Yes. I need access to PyType_Type's tp_new field.

PyType_Type is a very central structure in Python, and it really hurts
to hide every attribute away.

You can see the use of this field here:
https://github.com/pyside/pyside2-setup/blob/5.11/sources/shiboken2/libshiboken/basewrapper.cpp#L319

    // The meta type creates a new type when the Python programmer extends a wrapped C++ class.
    newfunc type_new = reinterpret_cast<newfunc>(PyType_Type.tp_new);
    SbkObjectType *newType = reinterpret_cast<SbkObjectType*>(type_new(metatype, args, kwds));
    if (!newType)
        return 0;

Not being able to use this field led to many weird workaround attempts, 
which did not really work. We tried to call this function from Python code, 
but then there are several checks which make it impossible to use.

We could maybe generate a heaptype clone of PyType_Type and grab the function
from there. But this is quite obscure and cannot be the recommended way to
get at the tp_new function?

Maybe there also is a way to avoid the use of this function all together.
But we did not want to re-implement a central function of a huge project
that we only understood good enough to change it a bit.

Maybe we approach it again. At that time, it was not even clear that we
would succeed with the limited API. Now that we know, we can try more.

----------

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

From report at bugs.python.org  Sat Sep 15 07:42:56 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 15 Sep 2018 11:42:56 +0000
Subject: [docs] [issue25296] Simple End-of-life guide covering all
 unsupported versions
In-Reply-To: <1443763669.22.0.844106074075.issue25296@psf.upfronthosting.co.za>
Message-ID: <1537011776.03.0.956365154283.issue25296@psf.upfronthosting.co.za>


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

This is not being tracked in:

https://github.com/python/pythondotorg/issues/1302

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

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

From report at bugs.python.org  Sat Sep 15 09:46:30 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 15 Sep 2018 13:46:30 +0000
Subject: [docs] [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1537019190.58.0.249678724859.issue20906@psf.upfronthosting.co.za>


Change by A.M. Kuchling <amk at amk.ca>:


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

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

From report at bugs.python.org  Sat Sep 15 09:46:48 2018
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 15 Sep 2018 13:46:48 +0000
Subject: [docs] [issue34484] Unicode HOWTO incorrectly refers to Private Use
 Area for surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1537019208.37.0.956365154283.issue34484@psf.upfronthosting.co.za>


A.M. Kuchling <amk at amk.ca> added the comment:

Corrected in the unicode-howto-update branch being developed for issue #20906.

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

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

From report at bugs.python.org  Sat Sep 15 10:29:04 2018
From: report at bugs.python.org (Bumsik Kim)
Date: Sat, 15 Sep 2018 14:29:04 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537021744.85.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Bumsik Kim <kbumsik at gmail.com>:


----------
pull_requests: +8753

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

From report at bugs.python.org  Sat Sep 15 10:50:44 2018
From: report at bugs.python.org (Jose Angel Acosta)
Date: Sat, 15 Sep 2018 14:50:44 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
Message-ID: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>


New submission from Jose Angel Acosta <acostaja at gmail.com>:

A request have been srecentrly uddenly committed to avoid Slave/Master wording in python code, I think the "issue"was not enough peer-reviewed, me having slave roots from my african and jewish heritage I dont consider this matter an Issue, but the Wording Slave/Master widely used to depict component relationship is better for understanding the purpose of the component relation than the non-traditional wording schemes as Parent/Worker, specially for those being non-native English readers the change has issues on code readability specially for non-English readers.

Simple, its much easier to understand the meaning of Slave/Master relationship in device functionality than Worker/Helper, I consider the whole issue as an intrusion of the "politically correct" puritanism in areas where is not required.

The main force behind Python success is CODE READABILITY, not  political rightfulness, this should be stopped here,Python itself the language name its an word which remembers snakes a creature considered impure by both Jew/Islamic/Christian religions, by appling the same political rightfulness code to this, Python language should be renamed to something non-offensive to Jew/Islamic/Christians as Bunny, (and this at least doesnt affect language readbility, since "run bunny code" vs "run python code" its easier to understand than "Process Master delegate X Data to Slave process" vs "Parent process Delegate X Data to Worker Process", the later meaning is not as easy to understand, since Parent can be translated in N ways across different languages, I.E. Spanish: Parent could means mother, father, cause while Worker just means Worker (not intrinsically related to cause or mother).

I think the python language should be kept from explicitly offensive wordings not those "niche" offensive wordings when the whole language is named after an animal that is offensive on most cultures (And its not a problem), the same naming process slave/master doesn't denote support to slavery, are just words that its more easy to understand its meaning (given its more uniform) across multiple human languages.

I consider the voting mechanism should consider polls among programmers before commit matters like this in the future, which respectfully I consider ridiculous and I said it with respect to my slave ancestors.

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 325434
nosy: AcostaJA, Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers
type: enhancement

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

From report at bugs.python.org  Sat Sep 15 11:00:53 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 15 Sep 2018 15:00:53 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537023653.73.0.956365154283.issue34694@psf.upfronthosting.co.za>


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

Do you have any concrete propositions?

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

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

From report at bugs.python.org  Sat Sep 15 11:07:01 2018
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 15 Sep 2018 15:07:01 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537024021.05.0.956365154283.issue34694@psf.upfronthosting.co.za>


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

There will be no further discussion about this.

----------
nosy: +Mariatta
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From zoodss at yandex.ru  Sat Sep 15 11:14:02 2018
From: zoodss at yandex.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCb0Y7RiNC90LXQvdC60L4=?=)
Date: Sat, 15 Sep 2018 18:14:02 +0300
Subject: [docs] Several typos in Python 3.7 docs.
In-Reply-To: <CAKJDb-M3GsGzTt2UuAGOaixAk_wKRcuQVYjLgeTUB__YnzHJdw@mail.gmail.com>
References: <2737921536858832@sas2-560de3a0188d.qloud-c.yandex.net>
 <CAKJDb-NfnasUL5GEe1wJph1f2jMY51OXBvXJGLskRrHmKaXo-g@mail.gmail.com>
 <8860921536930462@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M9-00dQXTqqUfyJOZfMaAPOwSEFmT5S0MmMdrUkMSFuQ@mail.gmail.com>
 <9926931536944542@myt4-c0b480c282c8.qloud-c.yandex.net>
 <CAKJDb-OHnko1TgvgJ975Jys7Gwgo4zcHxpzM=TxqRnn4W+0nPQ@mail.gmail.com>
 <9917121536946808@myt5-02b80404fd9e.qloud-c.yandex.net>
 <CAKJDb-M3GsGzTt2UuAGOaixAk_wKRcuQVYjLgeTUB__YnzHJdw@mail.gmail.com>
Message-ID: <7864551537024442@sas2-9bd6ba081e5d.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180915/13217741/attachment.html>

From report at bugs.python.org  Sat Sep 15 23:54:15 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 03:54:15 +0000
Subject: [docs] [issue34701] Asyncio documentation for recursive coroutines
 is lacking
Message-ID: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>


New submission from Azaria Zornberg <a.zornberg96 at gmail.com>:

When an asynchronous coroutine in asyncio awaits or yields from itself, any call to the function is executed somewhat synchronously.

Once the recursive coroutine begins, if it never awaits any other coroutines besides itself, nothing else will be scheduled to run until it has completely finished recursively calling itself and returning.
However, if it ever awaits a different coroutine (even something as small as asyncio.sleep(0)) then other coroutines will be scheduled to run.

It seems, from other documentation, that this is intentional. Other documentation sort of dances around the specifics of how coroutines work with recursion, and only examples of coroutines yielding from each other recursively are provided.

However, this behavior is never explicitly called out. This is confusing for people who write a recursive asyncio coroutine and are perplexed by why it seems to execute synchronously, assuming they ever notice.

I've attached a short script that can be run to exhibit the behavior.
A PR is going to be filed shortly against the python 3.7 branch (as the documentation page for asyncio in 3.8 does not fully exist right now).

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio_await_from_self_example.py
messages: 325468
nosy: asvetlov, azaria.zornberg, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation for recursive coroutines is lacking
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47805/asyncio_await_from_self_example.py

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

From report at bugs.python.org  Sat Sep 15 23:59:43 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 03:59:43 +0000
Subject: [docs] [issue34701] Asyncio documentation for recursive coroutines
 is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537070383.64.0.249678724859.issue34701@psf.upfronthosting.co.za>


Change by Azaria Zornberg <a.zornberg96 at gmail.com>:


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

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

From report at bugs.python.org  Sun Sep 16 00:09:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 16 Sep 2018 04:09:06 +0000
Subject: [docs] [issue34701] Asyncio documentation for recursive coroutines
 is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537070945.43.0.956365154283.issue34701@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

The issue here is not the recursion,  but rather about the fact that coroutines should actually await on IO or other activity in order for the event loop to run them cooperatively.  E.g.

   async def foo():
        await foo()

doesn't really do anything expect calling itself, whereas

   async def foo():
        await sleep(0)
        await foo()

is asking the event loop to sleep for a moment and then recurses into itself.

I'm OK with better clarifying this in the asyncio-dev.rst file.

----------

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

From report at bugs.python.org  Sun Sep 16 00:15:11 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 04:15:11 +0000
Subject: [docs] [issue34701] Asyncio documentation for recursive coroutines
 is lacking
In-Reply-To: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>
Message-ID: <1537071311.34.0.956365154283.issue34701@psf.upfronthosting.co.za>


Azaria Zornberg <a.zornberg96 at gmail.com> added the comment:

Ah, thanks for the clarification!

I first encountered this when having some issues with converting large objects to json. json.dumps happens synchronously, and when executed on an object that was dozens of MB in size, it held up everything for a fair bit of time.
I tried to solve it by recursively running json.dumps on smaller pieces of the thing being converted to json. And that was when I realized that this still wasn't letting other things get scheduled.

When I looked for examples online, I didn't see any of a recursive asyncio coroutine, which is why I assumed the recursion was the issue.


Any advice on better ways to phrase the documentation are greatly appreciated! Alternatively, it sounds like you have a much better understanding of this than I do, so I'm happy to defer to whatever you believe is the correct way to document this. Thanks for the help!

----------

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

From report at bugs.python.org  Sun Sep 16 07:57:43 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 11:57:43 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537099063.01.0.249678724859.issue26979@psf.upfronthosting.co.za>


Change by Neil Schemenauer <nas-python at arctrix.com>:


----------
nosy: +nascheme

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

From report at bugs.python.org  Sun Sep 16 11:01:00 2018
From: report at bugs.python.org (ZooDSS)
Date: Sun, 16 Sep 2018 15:01:00 +0000
Subject: [docs] [issue34682] Typo reports on docs@
In-Reply-To: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>
Message-ID: <1537110060.75.0.956365154283.issue34682@psf.upfronthosting.co.za>


ZooDSS <ZooDSS at yandex.ru> added the comment:

Wanted to add a little bit more, but didn't know where to, so here it goes.

https://docs.python.org/3/reference/expressions.html#membership-test-operations

"The operator not in is defined to have the inverse true value of in." may be better to use "... the inverse truth value of in." as it is used in the next section, for identity comparisons explanation:

"x is not y yields the inverse truth value."


https://docs.python.org/3/reference/expressions.html#is-not

In this section "object identity" is used two times. May be better to say "object's identity", as identity is a part of an object. Object has identity.

"...test for object identity" - here.
"Object identity is determined..." - and here.

----------
nosy: +ZooDSS

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

From report at bugs.python.org  Sun Sep 16 16:37:57 2018
From: report at bugs.python.org (Gabriel Marko)
Date: Sun, 16 Sep 2018 20:37:57 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537130277.51.0.956365154283.issue34694@psf.upfronthosting.co.za>


Gabriel Marko <marko.gabriel.cz at gmail.com> added the comment:

@Mariatta:

> There will be no further discussion about this.

Repeating this over and over again won't solve the (any) issue. This madness reached another level here: https://bugs.python.org/issue34660. That was exactly my point here: https://bugs.python.org/issue34605#msg324825. <sarcasm>But let me guess: There will no (further) discussion about that either.</sarcasm> 

I find this behavior from the Python core developers and representatives simply irresponsible.

----------
nosy: +suic

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

From report at bugs.python.org  Sun Sep 16 18:49:00 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 16 Sep 2018 22:49:00 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537138140.5.0.956365154283.issue34694@psf.upfronthosting.co.za>


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

Jose: The purpose of the tracker is to facilitate patches to the CPython code and docs.  Your post and personal perspective (with 'srecentrly uddenly' corrected),though related, belongs elsewhere, such as python-list.

Gabriel: Insults so not solve issues.  Rather they discourage people from volunteering to improve Python.  They are a violation of the Code of Conduct.  Please consider this a warning and don't repeat.

----------
components:  -2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS

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

From report at bugs.python.org  Sun Sep 16 19:40:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 16 Sep 2018 23:40:47 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537141247.36.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 5cc583d94095ed3bb543fa2f032f9593a6315a52 by Yury Selivanov (Bumsik Kim) in branch 'master':
bpo-33649: Clarify protocol_factory as a method parameter (GH-9330)
https://github.com/python/cpython/commit/5cc583d94095ed3bb543fa2f032f9593a6315a52


----------

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

From report at bugs.python.org  Mon Sep 17 05:25:11 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 17 Sep 2018 09:25:11 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537176311.02.0.956365154283.issue26979@psf.upfronthosting.co.za>


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

Ah! It seems you don't need access to all tp_* slots of any type here, but just to PyType.tp_new ? only one specific type, and only one specific slot.
Specifically, you need a way to create class with a metaclass, from C.

Is that right? Or was this only an example of a larger problem?

(Sorry for drawing the discussion out! Dropping the checks in PyType_GetSlot would be a simple change technically, but it doesn't match my mental model of what the stable ABI should be. I'm hoping to get a better solution for your use case, and others like it.)


> To obtain sizeof(PyType_Type), we simply used the Python code
>     type.__basicsize__
> It is a simple trick, but probably very few people know this path
> to get that info. At least, for me it took way too long ;-)

Well, basicsize might be exposed through Python, but it's still not part of the limited API. Which is fine ? all that means is you might need to change the extension for some future version of Python. I'm sure your tests will tell you when the time comes, and I hope we'll have a better solution then!
BTW, I'm honestly very impressed how far PySide got with the limited API!

----------

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

From report at bugs.python.org  Mon Sep 17 07:35:39 2018
From: report at bugs.python.org (Christian Tismer)
Date: Mon, 17 Sep 2018 11:35:39 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537184139.14.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

> ... Specifically, you need a way to create class with a metaclass, from C.
> 
> Is that right? Or was this only an example of a larger problem?

Yes, you are exactly right. I needed access to very few fields.
In particular:

    PyTypeObject.tp_init
    PyTypeObject.tp_basicsize    (workaround using Python)

    <a_few_types>.tp_dict

The latter would not be necessary for Pep 384, but for my __signature__
extension, but that is another story :)

<basicsize>

> Well, basicsize might be exposed through Python, but it's still not
> part of the limited API. Which is fine ? all that means is you might
> need to change the extension for some future version of Python.

Oh? I thought it is automatically allowed to use if it is exposed
by Python. I thought that the central property of basicsize would be
that it is no longer a constant, but that a size is always there.

Sure, we could have worked without the size and create a more complex 
structure that does not know anything about types. I actually started
with that approach. But in the end I thought it would not hurt to assume 
that there is a (variable) size, as long as we are below Python 4.0 .

> I'm sure your tests will tell you when the time comes, and I hope we'll
> have a better solution then!

Yes, I had a very hard time to convince myself that I _may_ use some
assumptions, as long as I always prove that these assumptions are right.
But in a way, I feel guilty and would prefer to go without any trickery.

> BTW, I'm honestly very impressed how far PySide got with the limited API!

Thank you! I was hoping to get ready after 2 months, when I realized that 
all types needed to be changed. So I pulled teeth, and it took >5 months.
Btw., I don't understand how the PyQt5 guy(s) solved this. Maybe his 
structure is way cleaner and simpler than the PySide mess? I'll ask him.

Ciao -- Chris

----------

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

From report at bugs.python.org  Mon Sep 17 07:57:54 2018
From: report at bugs.python.org (Christian Tismer)
Date: Mon, 17 Sep 2018 11:57:54 +0000
Subject: [docs] [issue26979] The danger of PyType_FromSpec()
In-Reply-To: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>
Message-ID: <1537185474.48.0.956365154283.issue26979@psf.upfronthosting.co.za>


Christian Tismer <tismer at stackless.com> added the comment:

If somebody is interested to see how the transition to the
Limited API was done, here is the documentation that I was
forced to write :)

https://github.com/pyside/pyside2-setup/blob/5.11/sources/shiboken2/libshiboken/pep384impl_doc.rst

----------

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

From report at bugs.python.org  Mon Sep 17 08:15:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:15:07 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186507.11.0.956365154283.issue33216@psf.upfronthosting.co.za>


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


New changeset 5e99b56d6b249995a4fa2bc09c0bb03841f49572 by Serhiy Storchaka in branch 'master':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/5e99b56d6b249995a4fa2bc09c0bb03841f49572


----------

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

From report at bugs.python.org  Mon Sep 17 08:15:20 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:15:20 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186520.46.0.249678724859.issue33216@psf.upfronthosting.co.za>


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


----------
pull_requests: +8777

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

From report at bugs.python.org  Mon Sep 17 08:15:31 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 12:15:31 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186531.3.0.249678724859.issue33216@psf.upfronthosting.co.za>


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


----------
pull_requests: +8778

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

From report at bugs.python.org  Mon Sep 17 08:15:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:15:51 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537186551.16.0.956365154283.issue33216@psf.upfronthosting.co.za>


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


New changeset afa591d7748c66831e6e650108024f3293be33f1 by Serhiy Storchaka in branch '2.7':
[2.7] bpo-33216: Clarify the documentation for CALL_FUNCTION_* (GH-8338) (GH-8783)
https://github.com/python/cpython/commit/afa591d7748c66831e6e650108024f3293be33f1


----------

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

From report at bugs.python.org  Mon Sep 17 08:41:55 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 12:41:55 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537188115.81.0.956365154283.issue33216@psf.upfronthosting.co.za>


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

Thank you Larry for your rewriting.

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

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

From report at bugs.python.org  Mon Sep 17 09:09:37 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:09:37 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537189777.07.0.956365154283.issue33216@psf.upfronthosting.co.za>


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


New changeset f8e34eee74871b3343f6c3545bce41242ba378e8 by Miss Islington (bot) in branch '3.7':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/f8e34eee74871b3343f6c3545bce41242ba378e8


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

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

From report at bugs.python.org  Mon Sep 17 09:09:45 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 13:09:45 +0000
Subject: [docs] [issue33216] [3.5] Wrong order of stack for
 CALL_FUNCTION_VAR and CALL_FUNCTION_VAR_KW
In-Reply-To: <1522784543.83.0.467229070634.issue33216@psf.upfronthosting.co.za>
Message-ID: <1537189785.67.0.956365154283.issue33216@psf.upfronthosting.co.za>


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


New changeset 1e7193bd027a5a4aa1a387e3f201a3e465c25f01 by Miss Islington (bot) in branch '3.6':
bpo-33216: Improve the documentation for CALL_FUNCTION_* (GH-8338) (GH-8784)
https://github.com/python/cpython/commit/1e7193bd027a5a4aa1a387e3f201a3e465c25f01


----------

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

From report at bugs.python.org  Mon Sep 17 12:36:31 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:36:31 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
Message-ID: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>


New submission from Ben Hoyt <benhoyt at gmail.com>:

There are a couple of examples in the "Input and Output" section of the tutorial that use an unusual / non-PEP 8 Python style or whitespace. I think our examples, especially in the tutorial, should reflect good, PEP 8 style. I'll fix these in a PR which I'll attach soon.

----------
assignee: docs at python
components: Documentation
messages: 325550
nosy: akuchling, benhoyt, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Style fixes in examples of "Input and Output" tutorial section
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 17 12:37:05 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:37:05 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537202225.57.0.249678724859.issue34712@psf.upfronthosting.co.za>


Change by Ben Hoyt <benhoyt at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 17 12:37:51 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:37:51 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537202271.53.0.956365154283.issue34712@psf.upfronthosting.co.za>


Ben Hoyt <benhoyt at gmail.com> added the comment:

GitHub PR link with changes and commit notes attached.

----------

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

From report at bugs.python.org  Mon Sep 17 13:14:05 2018
From: report at bugs.python.org (Nicholas Chammas)
Date: Mon, 17 Sep 2018 17:14:05 +0000
Subject: [docs] [issue34713] csvwriter.writerow()'s return type is
 undocumented
Message-ID: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>


New submission from Nicholas Chammas <nicholas.chammas at gmail.com>:

It _looks_ like csvwriter.writerow() returns the number of bytes (or is it characters?) written. However, there is no documentation of this:

https://docs.python.org/3.7/library/csv.html#csv.csvwriter.writerow

Is this behavior part of the method's "contract"? And if so, shouldn't we document it?

The same goes for csvwriter.writerows().

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 325557
nosy: docs at python, nchammas
priority: normal
severity: normal
status: open
title: csvwriter.writerow()'s return type is undocumented
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 17 13:20:27 2018
From: report at bugs.python.org (Nicholas Chammas)
Date: Mon, 17 Sep 2018 17:20:27 +0000
Subject: [docs] [issue34713] csvwriter.writerow()'s return type is
 undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1537204827.52.0.956365154283.issue34713@psf.upfronthosting.co.za>


Nicholas Chammas <nicholas.chammas at gmail.com> added the comment:

Looks like it's bytes written, not characters:

```
>>> import csv
>>> with open('test.csv', 'w', newline='') as csv_file:
...     csv_writer = csv.writer(
...         csv_file,
...         dialect='unix',
...     )
...     csv_writer.writerow('? ?')  # 3 characters
... 
12
```

----------

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

From report at bugs.python.org  Mon Sep 17 14:31:10 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:31:10 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537209070.82.0.249678724859.issue34712@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 17 14:33:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 17 Sep 2018 18:33:27 +0000
Subject: [docs] [issue34713] csvwriter.writerow()'s return type is
 undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1537209207.26.0.249678724859.issue34713@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 17 14:42:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 18:42:08 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537209728.78.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8788

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

From report at bugs.python.org  Mon Sep 17 15:35:29 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 19:35:29 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537212929.11.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 394374e30c85f6eacddbbfc7471aab62b54ce021 by Yury Selivanov in branch 'master':
bpo-33649: Add low-level APIs index. (GH-9364)
https://github.com/python/cpython/commit/394374e30c85f6eacddbbfc7471aab62b54ce021


----------

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

From report at bugs.python.org  Mon Sep 17 17:13:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:13:57 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
Message-ID: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I'd like to remove the ":numbered:" option from Doc/library/index.rst TOC.  Most standard library modules don't have extensive documentation, but some, for example asyncio, have.  For such modules, numbering makes title to contain too much noise.  Sphinx does not allow to opt-out from sections numbering if it's enabled on the top level.

----------
assignee: docs at python
components: Documentation
files: now_2.png
messages: 325577
nosy: docs at python, yselivanov
priority: normal
severity: normal
status: open
title: docs: disable numbered sections for stdlib in html
type: enhancement
Added file: https://bugs.python.org/file47809/now_2.png

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

From report at bugs.python.org  Mon Sep 17 17:14:09 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:09 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218849.41.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47810/now_1.png

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

From report at bugs.python.org  Mon Sep 17 17:14:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:20 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218860.3.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47811/after_1.png

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

From report at bugs.python.org  Mon Sep 17 17:14:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:25 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218865.88.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


Added file: https://bugs.python.org/file47812/after_2.png

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

From report at bugs.python.org  Mon Sep 17 17:14:40 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:40 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218880.89.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Please refer to the attached screenshots to see the difference.

----------

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

From report at bugs.python.org  Mon Sep 17 17:14:47 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:14:47 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218887.81.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 17 17:15:06 2018
From: report at bugs.python.org (Ned Deily)
Date: Mon, 17 Sep 2018 21:15:06 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218906.69.0.249678724859.issue34717@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 17 17:15:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:15:53 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218953.53.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 17 17:16:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:16:06 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218966.58.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +willingc -mdk
stage: patch review -> 

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

From report at bugs.python.org  Mon Sep 17 17:16:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:16:23 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537218983.59.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 17 17:28:18 2018
From: report at bugs.python.org (Julien Palard)
Date: Mon, 17 Sep 2018 21:28:18 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537219698.17.0.956365154283.issue34717@psf.upfronthosting.co.za>


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

In one hand, I already spotted students exchanging paragraphs numbers, when both have the same page open but one want to point a specific paragraph to the other, it goes like "humm that thing is docuemtented in paragraph 3.17.3.12".

Don't mis-read me, they don't *know* the paragraph number, they read it because it's on their screen at the moment they use it, to temporarily exchange a specific location on the page.

On the other hand the numbering is inconsistent between versions, and I also seen students replying to the first one, it goes like: "oooh got it, it's not 3.17.3.12 but 3.17.3.16 in my version" (Obviously I'm make up numbers, too).

Soo... I'm +1 for this change.

----------

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

From report at bugs.python.org  Mon Sep 17 18:10:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:10:24 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537222224.9.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8798

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

From report at bugs.python.org  Mon Sep 17 18:12:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:12:24 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222344.86.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset c62ab2862db2382808bb2228760eebdda3f608bd by Yury Selivanov in branch 'master':
bpo-34717: Stop numbering stdlib titles/sections in the docs (GH-9370)
https://github.com/python/cpython/commit/c62ab2862db2382808bb2228760eebdda3f608bd


----------

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

From report at bugs.python.org  Mon Sep 17 18:12:34 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 22:12:34 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222354.3.0.249678724859.issue34717@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 17 18:16:13 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:16:13 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222573.13.0.956365154283.issue34717@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks to Julien and Carol for reviews and sharing the opinion!  I'm closing this issue now.

In case someone needs the numbering to be re-enabled for some reason we can re-open this issue and discuss the best approach how to make that happen, while making sure that documentation for modules like asyncio is easy to browse and read.

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

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

From report at bugs.python.org  Mon Sep 17 18:16:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:16:28 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537222588.45.0.249678724859.issue34717@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 17 18:42:04 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 22:42:04 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537224124.87.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 3085534c398e6b181e7a9ac0cb9c80f3c670f2b9 by Yury Selivanov in branch 'master':
bpo-33649: Add a hello world example to asyncio.rst (GH-9374)
https://github.com/python/cpython/commit/3085534c398e6b181e7a9ac0cb9c80f3c670f2b9


----------

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

From report at bugs.python.org  Mon Sep 17 18:42:13 2018
From: report at bugs.python.org (miss-islington)
Date: Mon, 17 Sep 2018 22:42:13 +0000
Subject: [docs] [issue34717] docs: disable numbered sections for stdlib in
 html
In-Reply-To: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>
Message-ID: <1537224133.43.0.956365154283.issue34717@psf.upfronthosting.co.za>


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


New changeset c63d81b3feaa008a6be4c7c83c324174e8d95c24 by Miss Islington (bot) in branch '3.7':
bpo-34717: Stop numbering stdlib titles/sections in the docs (GH-9370)
https://github.com/python/cpython/commit/c63d81b3feaa008a6be4c7c83c324174e8d95c24


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

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

From report at bugs.python.org  Mon Sep 17 18:54:48 2018
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Mon, 17 Sep 2018 22:54:48 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537224888.49.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Elvis Pranskevichus <elvis at magic.io>:


----------
pull_requests: +8800

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

From report at bugs.python.org  Mon Sep 17 19:16:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:16:51 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537226211.13.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 1fa2ec49bec50bea1847b558b883c5c904334734 by Yury Selivanov (Elvis Pranskevichus) in branch 'master':
bpo-33649: A copy-editing pass on asyncio documentation (GH-9376)
https://github.com/python/cpython/commit/1fa2ec49bec50bea1847b558b883c5c904334734


----------

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

From report at bugs.python.org  Mon Sep 17 19:30:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:30:25 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227025.85.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8801

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

From report at bugs.python.org  Mon Sep 17 19:35:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:35:35 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227335.05.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 512d7101098b971837cbb406942215244f636547 by Yury Selivanov in branch '3.7':
bpo-33649: Backport asyncio docs from 'master' to 3.7 (GH-9377)
https://github.com/python/cpython/commit/512d7101098b971837cbb406942215244f636547


----------

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

From report at bugs.python.org  Mon Sep 17 19:38:31 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 23:38:31 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537227511.54.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Wow, we did this!  I've just pushed a backport of the new documentation to 3.7.

Thanks to Carol, Elvis, and Andrew for the help!

I think this issue can now be closed, we'll open new ones for:

1. A high-level intro/tutorial for asyncio.

2. A low-level tutorial (say we implement a micro-library for Redis using only low-level APIs)

3. An asyncio "Architecture" section as suggested by Jim DeLaHunt.

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

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

From report at bugs.python.org  Mon Sep 17 20:30:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:30:11 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537230611.29.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

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

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

From report at bugs.python.org  Mon Sep 17 20:50:35 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:50:35 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537231835.57.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8804

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

From report at bugs.python.org  Mon Sep 17 20:52:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 00:52:32 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537231952.83.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

Never mind, the docs for 3.7 have been updated!

----------

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

From report at bugs.python.org  Mon Sep 17 20:59:12 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 18 Sep 2018 00:59:12 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537232352.77.0.956365154283.issue33649@psf.upfronthosting.co.za>


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

>> Ned, do we auto run docs build for Python 3.7?  Or do we only build them on release?

The online html docs at https://docs.python.org/, like https://docs.python.org/3.7/, are rebuilt every 3 hours from the current branch heads for feature and maintenance releases.  We also make available archive copies of the docs for each release here:
https://www.python.org/doc/versions/

>Never mind, the docs for 3.7 have been updated!

What's up, Doc?

----------

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

From report at bugs.python.org  Mon Sep 17 23:58:06 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 03:58:06 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243086.64.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ac94e38d076aebc56c2ff96a249b5e40f32633ea by Yury Selivanov in branch 'master':
bpo-33649: Note that asyncio.run() calls shutdown_asyncgens() (GH-9380)
https://github.com/python/cpython/commit/ac94e38d076aebc56c2ff96a249b5e40f32633ea


----------

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

From report at bugs.python.org  Mon Sep 17 23:58:15 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 03:58:15 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243095.64.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8807

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

From report at bugs.python.org  Tue Sep 18 00:12:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 04:12:09 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537243929.06.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 1f4ea580675d7b30d3906d78c500997d7d96995d by Miss Islington (bot) in branch '3.7':
bpo-33649: Note that asyncio.run() calls shutdown_asyncgens() (GH-9380)
https://github.com/python/cpython/commit/1f4ea580675d7b30d3906d78c500997d7d96995d


----------

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

From report at bugs.python.org  Tue Sep 18 00:37:34 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:37:34 +0000
Subject: [docs] [issue34718] Syntax error on factorial example
Message-ID: <1537245454.25.0.956365154283.issue34718@psf.upfronthosting.co.za>


New submission from Miguel ?ngel <miguelangel.garcia at gmail.com>:

In the example on https://docs.python.org/3/library/asyncio-task.html#running-tasks-concurrently, there is a double closing parenthesis, but just one is needed for the `gather` method. This makes the example to fail.

----------
assignee: docs at python
components: Documentation
messages: 325614
nosy: docs at python, magmax
priority: normal
severity: normal
status: open
title: Syntax error on factorial example
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 18 00:45:27 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:45:27 +0000
Subject: [docs] [issue34718] Syntax error on factorial example
In-Reply-To: <1537245454.25.0.956365154283.issue34718@psf.upfronthosting.co.za>
Message-ID: <1537245927.36.0.956365154283.issue34718@psf.upfronthosting.co.za>


Miguel ?ngel <miguelangel.garcia at gmail.com> added the comment:

Too trivial to require an issue. Sorry, I'm newbie here :)

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

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

From report at bugs.python.org  Tue Sep 18 00:47:30 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:47:30 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246050.09.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Miguel ?ngel <miguelangel.garcia at gmail.com>:


----------
pull_requests: +8808

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

From report at bugs.python.org  Tue Sep 18 00:48:48 2018
From: report at bugs.python.org (Danny Hermes)
Date: Tue, 18 Sep 2018 04:48:48 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246128.49.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Danny Hermes <daniel.j.hermes at gmail.com>:


----------
pull_requests: +8809

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

From report at bugs.python.org  Tue Sep 18 00:50:12 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 04:50:12 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537246211.99.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8810

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

From report at bugs.python.org  Tue Sep 18 02:01:00 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 06:01:00 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537250460.7.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Miguel ?ngel <miguelangel.garcia at gmail.com>:


----------
pull_requests: +8811

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

From report at bugs.python.org  Tue Sep 18 02:02:10 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 06:02:10 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537250530.62.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8812

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

From report at bugs.python.org  Tue Sep 18 02:41:10 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 06:41:10 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537252870.65.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8813

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

From report at bugs.python.org  Tue Sep 18 02:48:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 06:48:00 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537253280.0.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset b042cf10c6084d14279c55a7e0d2d7595ff4e694 by Yury Selivanov in branch 'master':
bpo-33649: Fix markup; add another note that asyncio.run is 3.7+ (GH-9389)
https://github.com/python/cpython/commit/b042cf10c6084d14279c55a7e0d2d7595ff4e694


----------

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

From report at bugs.python.org  Tue Sep 18 02:48:09 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 06:48:09 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537253289.94.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8814

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

From report at bugs.python.org  Tue Sep 18 03:01:03 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 07:01:03 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537254063.79.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 45452b738b7f94221a94e903fb5975222fbb7a8f by Miss Islington (bot) in branch '3.7':
bpo-33649: Fix markup; add another note that asyncio.run is 3.7+ (GH-9389)
https://github.com/python/cpython/commit/45452b738b7f94221a94e903fb5975222fbb7a8f


----------

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

From report at bugs.python.org  Tue Sep 18 06:37:01 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 18 Sep 2018 10:37:01 +0000
Subject: [docs] [issue34518] Documentation for coroutine objects
In-Reply-To: <1535359488.51.0.56676864532.issue34518@psf.upfronthosting.co.za>
Message-ID: <1537267021.29.0.956365154283.issue34518@psf.upfronthosting.co.za>


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

Since there is work on asyncio docs overhaul I just want to bring this to your attention since I don't know if this has already been resolved with the merged PRs to master and your thoughts on this.

Thanks

----------
nosy: +yselivanov

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

From report at bugs.python.org  Tue Sep 18 14:25:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 18:25:53 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537295153.39.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8826

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

From report at bugs.python.org  Tue Sep 18 17:55:48 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 21:55:48 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537307748.17.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 471503954a91d86cf04228c38134108c67a263b0 by Yury Selivanov in branch 'master':
bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403)
https://github.com/python/cpython/commit/471503954a91d86cf04228c38134108c67a263b0


----------

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

From report at bugs.python.org  Tue Sep 18 17:55:55 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 21:55:55 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537307755.59.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8831

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

From report at bugs.python.org  Tue Sep 18 18:09:55 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 18 Sep 2018 22:09:55 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537308595.64.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 73c0006e71683b7d5b28192f18a2b9796e4195ef by Miss Islington (bot) in branch '3.7':
bpo-33649: Add a high-level section about Futures; few quick fixes (GH-9403)
https://github.com/python/cpython/commit/73c0006e71683b7d5b28192f18a2b9796e4195ef


----------

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

From report at bugs.python.org  Wed Sep 19 03:20:52 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:20:52 +0000
Subject: [docs] [issue32075] Expose ZipImporter Type Object in the include
 header files.
In-Reply-To: <1511121369.3.0.213398074469.issue32075@psf.upfronthosting.co.za>
Message-ID: <1537341652.15.0.956365154283.issue32075@psf.upfronthosting.co.za>


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

zipimport have been rewritten in pure Python (issue25711).

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

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

From report at bugs.python.org  Wed Sep 19 03:43:06 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 07:43:06 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537342986.58.0.956365154283.issue29013@psf.upfronthosting.co.za>


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

I think we should just revert this. The zipfile module can handle ZIP files up to 4 GiB without the ZIP64 extensions, but it requires the ZIP64 extensions for creating ZIP files larger than 2 GiB. The ZIP64 extensions is required also for ZIP files with more than 65535 files.

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

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

From report at bugs.python.org  Wed Sep 19 04:15:57 2018
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 19 Sep 2018 08:15:57 +0000
Subject: [docs] [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1537344957.38.0.956365154283.issue29249@psf.upfronthosting.co.za>


Ronny Pfannschmidt <bugs.python.org at ronnypfannschmidt.de> added the comment:

issue34731 was a duplicate of this

pytest was affected, as we port more bits to pathlib we hit this as well

bruno kindly implemented a local workaround in https://github.com/pytest-dev/pytest/pull/3980/files#diff-63fc5ed688925b327a5af20405bf4b09R19

----------
nosy: +Ronny.Pfannschmidt

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

From report at bugs.python.org  Wed Sep 19 05:28:10 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Wed, 19 Sep 2018 09:28:10 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
Message-ID: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>


New submission from Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:

The search bar is missing from docs.python.org, probably as a result of a minor error in the webpage. This is a quite recent change, as the search bar is still there in a web.archive.org snapshot from the 13th of September (last week). Could someone please fix this? Thanks.

----------
assignee: docs at python
components: Documentation
messages: 325737
nosy: Harrison Chudleigh, docs at python
priority: normal
severity: normal
status: open
title: Missing search bar on docs.python.org
type: behavior

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

From report at bugs.python.org  Wed Sep 19 06:28:31 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 10:28:31 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537352911.86.0.956365154283.issue34712@psf.upfronthosting.co.za>


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


New changeset 3705b9862025705ea60041a9e310f99a164db722 by Miss Islington (bot) (Ben Hoyt) in branch 'master':
bpo-34712: Fix style in examples in "Input and Output" (GH-9361)
https://github.com/python/cpython/commit/3705b9862025705ea60041a9e310f99a164db722


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

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

From report at bugs.python.org  Wed Sep 19 06:28:55 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 10:28:55 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537352935.62.0.249678724859.issue34712@psf.upfronthosting.co.za>


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


----------
pull_requests: +8834

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

From report at bugs.python.org  Wed Sep 19 08:59:53 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 12:59:53 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537361993.89.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

Strange it's present on both 3.8.a0 and for 3.6.6 but not for 3.7.0

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Wed Sep 19 13:02:14 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Sep 2018 17:02:14 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537376534.91.0.249678724859.issue34733@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 13:23:57 2018
From: report at bugs.python.org (R. David Murray)
Date: Wed, 19 Sep 2018 17:23:57 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537377837.85.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 14:45:24 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 19 Sep 2018 18:45:24 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537382724.09.0.956365154283.issue34694@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@Mariatta:
> There will be no further discussion about this.

Mariatta, why do you say that?  As long as the participants in the discussion are respectful I'm not aware of any mechanism in the CPython developer guidelines that would require shutting down the discussion.


@terry.reedy:
> The purpose of the tracker is to facilitate patches to the CPython code and docs.

I'm pretty sure the issue tracker gets used for more than strictly facilitating patches.  And TBH this conversation got a little toxic in other areas online.  I don't think it's hurting anything to have a quiet discussion about it here on the issue tracker.


>  Insults so not solve issues.  [...]  Please consider this a warning and don't repeat.

I agree that insults are bad, and I too hope that nobody engages in being insulting.  But I read Gabriel's post twice and I don't see where he insulted anybody.  I found his remarks aggressive and a bit sarcastic, sure.  But not "insulting".  Can you be specific--what was the remark where he insulted somebody?

Gabriel, I agree that you should try to curb your more inflammatory tendencies in your correspondence.  But that's as much a tactical suggestion as it is a CoC reminder.  I assume that your point in writing is to win people over to your point of view--and that's best achieved by being reasonable and making good points.  As the old saying goes, "you'll attract more flies with honey than with vinegar".

----------

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

From report at bugs.python.org  Wed Sep 19 14:49:23 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 19 Sep 2018 18:49:23 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537382963.29.0.956365154283.issue34694@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the idea here is: don?t feed the trolls.

----------

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

From report at bugs.python.org  Wed Sep 19 14:54:44 2018
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 19 Sep 2018 18:54:44 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383284.41.0.956365154283.issue34694@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

@eric.araujo:
> I think the idea here is: don?t feed the trolls.

I understand this as a general-purpose metaphor.  But I don't understand how that translates into CPython issue tracker policy.  And so far I wouldn't describe anybody corresponding on this issue as "trolling".  Did I miss something?

----------

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

From report at bugs.python.org  Wed Sep 19 15:02:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 19:02:02 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383722.34.0.956365154283.issue34694@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think the idea here is: don?t feed the trolls.

+1.  Please stop this.

Larry, IMHO, if you seriously want to discuss this issue (and bring more attention to it) I think you should email to python-commiters.  Otherwise this is just a pointless distraction to those of us who ended up randomly added to the nosy list and have no interest in this topic.

A restricted (but open) mailing list to discuss controversial topics like this is a common practice.

> But I don't understand how that translates into CPython issue tracker policy.

Selecting all "components" and adding random people to the nosy list goes pretty much against the issue tracker policy.  It should have been closed right from the beginning, because the person who opened it used the wrong medium to convey their message to begin with.

P.S. Please don't add me to the nosy list.

----------

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

From report at bugs.python.org  Wed Sep 19 15:02:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 19:02:25 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383745.79.0.249678724859.issue34694@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy:  -yselivanov

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

From report at bugs.python.org  Wed Sep 19 15:04:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 19:04:17 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383857.52.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 15:05:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 19:05:03 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537383903.46.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 15:11:11 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 19 Sep 2018 19:11:11 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537384271.35.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 15:21:13 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 19:21:13 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537384873.75.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

Confirming that I see the same behavior as reported by @xtreak.

----------
nosy: +willingc
stage:  -> needs patch
versions: +Python 3.7

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

From report at bugs.python.org  Wed Sep 19 15:54:23 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 19:54:23 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537386863.07.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

I can reproduce it locally [1]. The Python logo at the left dissapear to, it goes from "[LOGO] Python ?" to "3.7.0 Documentation ?".

Did not spotted recent changes in the theme / docsbuild-scripts / cpython/Doc for the moment, but now I can inspect locally.

Local reproduction with a fresh clone of docsbuild-scripts:

    $ mkdir -p www logs build_root
    $ python3 -m venv build_root/venv/
    $ build_root/venv/bin/python -m pip install -r requirements.txt
    $ python3 ./build_docs.py --quick --build-root build_root --www-root www --log-directory logs --group $(id -g) --branch 3.7
    $ (cd www/3.7/; python3 -m http.server)

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

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

From report at bugs.python.org  Wed Sep 19 16:05:11 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:05:11 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537387511.05.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

I got it back by building with 90f7d455b (7 days ago), so I'm git bisecting...

----------

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

From report at bugs.python.org  Wed Sep 19 16:11:59 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 20:11:59 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537387919.77.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

@mdk The asyncio folks did make a change to the layout in https://github.com/python/cpython/pull/9364 . It's a bit weird that 3.7 is the release that is missing the search bar.

----------

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

From report at bugs.python.org  Wed Sep 19 16:13:44 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:13:44 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388024.28.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

Yes, got it too : 512d7101098b971837cbb406942215244f636547, they literally removed the searchbox:

$ git show 512d7101098b971837cbb406942215244f636547 | grep searchbox
-{%- macro searchbox() %}
-{# modified from sphinx/themes/basic/searchbox.html #}
-        {{ searchbox() }}
-            '<input type="text" value="" id="searchbox" style="width: 50%">',
-            '<input type="submit" id="searchbox-submit" value="Filter"></p>'
-                  var query = new RegExp($('#searchbox').val(), 'i');
-          $('#searchbox').keyup(dofilter);
-          $('#searchbox-submit').click(dofilter);

----------

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

From report at bugs.python.org  Wed Sep 19 16:13:55 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:13:55 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388035.84.0.249678724859.issue34733@psf.upfronthosting.co.za>


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


----------
nosy: +yselivanov

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

From report at bugs.python.org  Wed Sep 19 16:16:57 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 20:16:57 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537388217.73.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


----------
nosy:  -terry.reedy

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

From report at bugs.python.org  Wed Sep 19 16:18:25 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 20:18:25 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537388035.84.0.249678724859.issue34733@psf.upfronthosting.co.za>
Message-ID: <E5BE206C-4B76-47E3-A621-78063B419F4A@gmail.com>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Oh, this is a result of asyncio docs 3.8 -> 3.7 backport. I'll fix this.

----------

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

From report at bugs.python.org  Wed Sep 19 16:19:46 2018
From: report at bugs.python.org (Carol Willing)
Date: Wed, 19 Sep 2018 20:19:46 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388386.07.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

Does master and 3.7 branch build the docs at different times? It's odd to me that master still shows the search box and 3.7 does not.

I'm getting on a flight soon. Yury would be a good person to ping re: changing.

----------

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

From report at bugs.python.org  Wed Sep 19 16:20:24 2018
From: report at bugs.python.org (Julien Palard)
Date: Wed, 19 Sep 2018 20:20:24 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537388424.37.0.956365154283.issue34733@psf.upfronthosting.co.za>


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

Thanks Yuri (and thanks for the rewrite!)

----------

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

From report at bugs.python.org  Wed Sep 19 16:30:47 2018
From: report at bugs.python.org (miss-islington)
Date: Wed, 19 Sep 2018 20:30:47 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537389047.55.0.956365154283.issue34712@psf.upfronthosting.co.za>


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


New changeset d9c89111bd82979ce8716f7ca68c69cf0f46e679 by Miss Islington (bot) in branch '3.7':
bpo-34712: Fix style in examples in "Input and Output" (GH-9361)
https://github.com/python/cpython/commit/d9c89111bd82979ce8716f7ca68c69cf0f46e679


----------

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

From report at bugs.python.org  Wed Sep 19 16:32:40 2018
From: report at bugs.python.org (Ned Deily)
Date: Wed, 19 Sep 2018 20:32:40 +0000
Subject: [docs] [issue34712] Style fixes in examples of "Input and Output"
 tutorial section
In-Reply-To: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>
Message-ID: <1537389160.23.0.956365154283.issue34712@psf.upfronthosting.co.za>


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

Thanks for the improvement!

----------
nosy: +ned.deily
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Wed Sep 19 17:20:42 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 21:20:42 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537392042.42.0.956365154283.issue34694@psf.upfronthosting.co.za>


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

If this issue were not to be immediately closed, then cleaning the components and nosy lists should have been the first response.

I was tempted to do the latter now, to cut short the cavalcade of un-nosy emails, but anticipated that someone would object.  But I will remove myself again after this post.

Larry: Victor's recent issue and action pulled us further into a verbally violent and occasionally physically violent American Cultural war.  The result has already been pretty ugly.  We have been and will be attacked from extremists on both sides if consider changes on a case-by-case basis, accepting some and rejecting others.  I don't want the tracker ruined as a usable workspace.

We have been and will be attacked from extremists on both sides for considering changes on a case-by-case basis, accepting some and rejecting others.  On #34660, Raymond Hettinger merged one PR and I reviewed the other.  Marko called our actions 'madness' and here called us 'irresponsible'.  On the other hand, the OP criticized me for wanting change and huffed away with the claim that like it or not, we will somehow eventually be *forced* to change (as he wishes).  I do not volunteer for this sort of treatment.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Wed Sep 19 17:21:04 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 19 Sep 2018 21:21:04 +0000
Subject: [docs] [issue34694] Dismiss To Avoid Slave/Master wording cause it
 easier for non English spoken programmers
In-Reply-To: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>
Message-ID: <1537392064.53.0.249678724859.issue34694@psf.upfronthosting.co.za>


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


----------
nosy:  -terry.reedy

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

From report at bugs.python.org  Wed Sep 19 17:45:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:45:38 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393538.36.0.249678724859.issue34733@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Wed Sep 19 17:47:28 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:47:28 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393648.86.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> Does master and 3.7 branch build the docs at different times? It's odd to me that master still shows the search box and 3.7 does not.

layout.html was refactored in 3.8: scripts were moved into separate files.  I accidentally copied it from 3.8 to 3.7, where those new scripts are not available.

----------

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

From report at bugs.python.org  Wed Sep 19 17:51:20 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:51:20 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393880.67.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 581890cda36f60cd46185c6e184abe35a95813a2 by Yury Selivanov in branch '3.7':
bpo-34733: Return of the docs search bar (GH-9431)
https://github.com/python/cpython/commit/581890cda36f60cd46185c6e184abe35a95813a2


----------

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

From report at bugs.python.org  Wed Sep 19 17:52:51 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 21:52:51 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537393970.96.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Closing this now, please reopen if there's still no search bar in a few hours.

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

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

From report at bugs.python.org  Wed Sep 19 19:15:10 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:15:10 +0000
Subject: [docs] [issue21702] asyncio: remote_addr of
 create_datagram_endpoint() is not documented
In-Reply-To: <1402385733.37.0.0697912425381.issue21702@psf.upfronthosting.co.za>
Message-ID: <1537398910.53.0.249678724859.issue21702@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 19 19:18:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:18:18 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537399098.9.0.956365154283.issue19431@psf.upfronthosting.co.za>


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

It seems like these functions should be documented, so I close the issue.

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

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

From report at bugs.python.org  Wed Sep 19 19:18:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 19 Sep 2018 23:18:29 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537399109.68.0.249678724859.issue19431@psf.upfronthosting.co.za>


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


----------
resolution: out of date -> wont fix

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

From report at bugs.python.org  Wed Sep 19 19:55:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 19 Sep 2018 23:55:16 +0000
Subject: [docs] [issue34733] Missing search bar on docs.python.org
In-Reply-To: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>
Message-ID: <1537401316.63.0.956365154283.issue34733@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Aaand... it's back.

----------

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

From report at bugs.python.org  Thu Sep 20 00:55:09 2018
From: report at bugs.python.org (lanzhiwang)
Date: Thu, 20 Sep 2018 04:55:09 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
Message-ID: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>


New submission from lanzhiwang <hzhilamp at 163.com>:

https://docs.python.org/3.7/library/asyncio-llapi-index.html

loop.stop() Close the event loop.
fix
loop.close() Close the event loop.

----------
components: asyncio
messages: 325838
nosy: asvetlov, docs at python, hzhilamp at 163.com, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation have a error
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 01:06:59 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:06:59 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420019.79.0.249678724859.issue34746@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep 20 01:17:14 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:17:14 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420634.41.0.956365154283.issue34746@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset ffef50f1f5907e5f0f175b12088d3e509011f126 by Yury Selivanov in branch 'master':
bpo-34746: Fix stop -> close (GH-9437)
https://github.com/python/cpython/commit/ffef50f1f5907e5f0f175b12088d3e509011f126


----------

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

From report at bugs.python.org  Thu Sep 20 01:17:28 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 05:17:28 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420648.81.0.249678724859.issue34746@psf.upfronthosting.co.za>


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


----------
pull_requests: +8852

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

From report at bugs.python.org  Thu Sep 20 01:21:12 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 05:21:12 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537420872.04.0.956365154283.issue34746@psf.upfronthosting.co.za>


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


New changeset 4fe8dc68577f9e22aaf24db08fb6647277c42d4c by Miss Islington (bot) in branch '3.7':
bpo-34746: Fix stop -> close (GH-9437)
https://github.com/python/cpython/commit/4fe8dc68577f9e22aaf24db08fb6647277c42d4c


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

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

From report at bugs.python.org  Thu Sep 20 01:24:41 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:24:41 +0000
Subject: [docs] [issue34746] Asyncio documentation have a error
In-Reply-To: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>
Message-ID: <1537421081.74.0.956365154283.issue34746@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks for filing the bug!

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

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

From report at bugs.python.org  Thu Sep 20 01:58:16 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 05:58:16 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537423096.63.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8853

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

From report at bugs.python.org  Thu Sep 20 07:25:13 2018
From: report at bugs.python.org (xitop)
Date: Thu, 20 Sep 2018 11:25:13 +0000
Subject: [docs] [issue34748] Incorrect HTML link in functools.partial
Message-ID: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>


New submission from xitop <reg.bugs at poti.sk>:

There is a minor issue regarding the page https://docs.python.org/3/library/functools.html

The description of functools.partial starts with text "Return a new partial object" which contains a link. This link does not point to the partial object (#partial-objects anchor) as it should. It points back
to the partial function (#functools.partial anchor) which is not helpful. The partial object docs can be thus easily overseen.

----------
assignee: docs at python
components: Documentation
messages: 325856
nosy: docs at python, xitop
priority: normal
severity: normal
status: open
title: Incorrect HTML link in functools.partial
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 07:25:43 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 11:25:43 +0000
Subject: [docs] [issue34344] Fix the docstring for
 AbstractEventLoopPolicy.get_event_loop
In-Reply-To: <1533549887.39.0.56676864532.issue34344@psf.upfronthosting.co.za>
Message-ID: <1537442743.97.0.249678724859.issue34344@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 20 07:37:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 11:37:09 +0000
Subject: [docs] [issue33545] Docs for uuid don't mention that uuid1 can
 repeat in some circumstances
In-Reply-To: <1526491965.86.0.682650639539.issue33545@psf.upfronthosting.co.za>
Message-ID: <1537443429.87.0.249678724859.issue33545@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 20 08:57:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 12:57:47 +0000
Subject: [docs] [issue33117] asyncio example uses non-existing/documented
 method
In-Reply-To: <1521666406.67.0.467229070634.issue33117@psf.upfronthosting.co.za>
Message-ID: <1537448267.21.0.956365154283.issue33117@psf.upfronthosting.co.za>


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

I think `asyncio.run_coroutine_threadsafe(coro, loop)` returns a concurrent.futures.Future [1] which supports timeout and not asyncio.Future which doesn't support timeout. Please add in if I am missing anything. Since asyncio docs are being rewritten this would be a great time to contribute too if you would like to add more clarification.

Docs at [1] also say the below : 

asyncio.run_coroutine_threadsafe(coro, loop)

    Submit a coroutine to the given event loop. Thread-safe.

    Return a concurrent.futures.Future to wait for the result from another OS thread.


```
# bpo33117.py. This needs to be called from a different thread as docs said but I am using future.result(timeout) just to make sure there is no error with respect to function argument.

import asyncio

loop = asyncio.get_event_loop()
timeout = 4

# Create a coroutine
coro = asyncio.sleep(1, result=3)

# Submit the coroutine to a given loop
future = asyncio.run_coroutine_threadsafe(coro, loop)

# Wait for the result with an optional timeout argument
assert future.result(timeout) == 3
```


?  cpython git:(master) ./python.exe bpo33117.py
Traceback (most recent call last):
  File "../bpo33117.py", line 13, in <module>
    assert future.result(timeout) == 3
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/_base.py", line 438, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

[1] https://docs.python.org/3.8/library/concurrent.futures.html#concurrent.futures.Future



Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 20 09:06:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 20 Sep 2018 13:06:58 +0000
Subject: [docs] [issue19431] Document PyFrame_FastToLocals() and
 PyFrame_FastToLocalsWithError()
In-Reply-To: <1383040535.91.0.284405039579.issue19431@psf.upfronthosting.co.za>
Message-ID: <1537448818.34.0.956365154283.issue19431@psf.upfronthosting.co.za>


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

I closed the issue because we decided to not document the function, but I'm still interested to mark the API is private. Such change is more sensitive, so I added it my larger "New C API" project which works on finding a way to deprecate functions and provide maybe helpers for backward and forward compatibility:
https://pythoncapi.readthedocs.io/bad_api.html#for-internal-use-only

----------

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

From report at bugs.python.org  Thu Sep 20 09:14:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:14:13 +0000
Subject: [docs] [issue32995] Add a glossary entry for context variables
In-Reply-To: <1520244692.22.0.467229070634.issue32995@psf.upfronthosting.co.za>
Message-ID: <1537449253.36.0.249678724859.issue32995@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 20 09:27:19 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 20 Sep 2018 13:27:19 +0000
Subject: [docs] [issue31865] html.unescape does not work as per documentation
In-Reply-To: <1508899606.23.0.213398074469.issue31865@psf.upfronthosting.co.za>
Message-ID: <1537450039.36.0.249678724859.issue31865@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 20 11:22:10 2018
From: report at bugs.python.org (Windson Yang)
Date: Thu, 20 Sep 2018 15:22:10 +0000
Subject: [docs] [issue34753] Use coroutine object or coroutine function
 instead of coroutine
Message-ID: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>


New submission from Windson Yang <wiwindson at gmail.com>:

A PR https://github.com/python/cpython/pull/9408 solved an ambiguous problem about coroutine. Which led me to https://docs.python.org/3/library/asyncio-task.html#awaitables

> Note that in this documentation the term ?coroutine? can be used for two closely related concepts:

> a coroutine function: an async def function;
> a coroutine object: object returned by calling a coroutine function.

This will let people confused. IMO we should use `coroutine object` or `coroutine function` instead of coroutine when it means an object. For instance, L22 in https://github.com/python/cpython/blob/471503954a91d86cf04228c38134108c67a263b0/Doc/library/asyncio-api-index.rst

> Create event loop, run a coroutine, close the loop.
should be
> Create event loop, run a coroutine object, close the loop.

----------
assignee: docs at python
components: Documentation
messages: 325886
nosy: Windson Yang, docs at python
priority: normal
severity: normal
status: open
title: Use coroutine object or coroutine function instead of coroutine
type: enhancement
versions: Python 3.8

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

From bgailer at gmail.com  Thu Sep 20 12:01:29 2018
From: bgailer at gmail.com (bob gailer)
Date: Thu, 20 Sep 2018 12:01:29 -0400
Subject: [docs] Built-in Functions
Message-ID: <8427a453-b5bb-904c-d244-1d3929aff2dc@gmail.com>

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

1 - "always available" add: "except when overridden."
2 - mention these are defined in the builtins module.
3 - "functions and types" but in the individual descriptions we see 
"class"; only later references to "Types".

Bob Gailer

From report at bugs.python.org  Thu Sep 20 12:09:59 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Thu, 20 Sep 2018 16:09:59 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537459799.72.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

> In 3.4, format_list() was documented to accept return values of extract_tb() > and extract_stack() functions and they both were returned lists:
> 
>     def extract_tb(tb, limit=None):
>         return list(_extract_tb_iter(tb, limit=limit))
> 
>     def extract_stack(f=None, limit=None):
>         stack = list(_extract_stack_iter(_get_stack(f), limit=limit))
>         stack.reverse()
>         return stack

I think that?s an unnecessarily and extraordinarily narrow reading - you could use the same reading to make a judgement of ?format_list may only be passed values returned by extract_tb and extract_stack rather than other values of the same type?, and that would be absurd.

I don?t think it?s a wise choice to say ?because the motivation for offering the format_list function was to work with values returned by extract_tb and extract_stack, the allowed inputs to format_list should be restricted to just those types?.

Why not support Iterable[FrameSummary]? A choice to support Iterable[FrameSummary] *is also a choice to support List[FrameSummary]*. It's just a "wider" choice; it?s not a breaking choice to drop support for List[FrameSummary].

> I don't think we support the "pass manually created iterables" case here.

What?s a ?manually created iterable?? What kinds of iterables aren?t ?manually created iterables?? Can their differences be captured in the type system?

> Yes, the old API is still supported for backwards compatibility reasons.

This is a very flat statement that invites questions by what it doesn?t say and by the way it describes something that is true today without saying for how long into the future that thing will remain true. For how long will the old API be supported for backwards compatibility reasons? Is new code encouraged to use the new API? If the new API is better, shouldn?t new code use it? If the new API isn?t better, why was it introduced?

----------

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

From report at bugs.python.org  Thu Sep 20 12:40:44 2018
From: report at bugs.python.org (Elliot Edmunds)
Date: Thu, 20 Sep 2018 16:40:44 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1537461644.03.0.956365154283.issue16438@psf.upfronthosting.co.za>


Elliot Edmunds <edmundselliot at gmail.com> added the comment:

I agree that linking to the precedence table is probably the best solution.

A different option would be to add an extra column listing the "priority" and rank the priorities of the different operations.

----------
nosy: +Elliot Edmunds

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

From report at bugs.python.org  Thu Sep 20 12:44:11 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 16:44:11 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537461850.95.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset e247b46cba4f4d32ea96a15dbc36d73265171106 by Yury Selivanov in branch 'master':
bpo-33649: More improvements (GH-9439)
https://github.com/python/cpython/commit/e247b46cba4f4d32ea96a15dbc36d73265171106


----------

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

From report at bugs.python.org  Thu Sep 20 12:44:17 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 16:44:17 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537461856.99.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8869

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

From report at bugs.python.org  Thu Sep 20 12:57:23 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 20 Sep 2018 16:57:23 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537462643.66.0.956365154283.issue33649@psf.upfronthosting.co.za>


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


New changeset 8e5ef58c10a1154f824d5875c2d89794a800eadc by Miss Islington (bot) in branch '3.7':
bpo-33649: More improvements (GH-9439)
https://github.com/python/cpython/commit/8e5ef58c10a1154f824d5875c2d89794a800eadc


----------

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

From report at bugs.python.org  Thu Sep 20 13:11:02 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 20 Sep 2018 17:11:02 +0000
Subject: [docs] [issue34753] Use coroutine object or coroutine function
 instead of coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537463462.84.0.956365154283.issue34753@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> This will let people confused. IMO we should use `coroutine object` or `coroutine function` instead of coroutine when it means an object.

I'm not sure that it's a good idea to apply this change everywhere, but I think in general this is a good idea.  Do you want to submit a PR?

----------
nosy: +yselivanov

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

From report at bugs.python.org  Thu Sep 20 13:16:37 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 17:16:37 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537463797.8.0.956365154283.issue34648@psf.upfronthosting.co.za>


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

> Why not support Iterable[FrameSummary]?

The question that needs to be answered here is "why we should support Iterable[FrameSummary]?" and you're one the one who needs to answer it instead of saying our design decisions were "absurd" and "not wise", without giving any concrete use cases for your "wider" design choice.

Initial docstring for format_list() were added in 2000: https://github.com/python/cpython/commit/e7b146fb3bdca62a0d5ecc06dbf3348e5a4fe757#diff-e57ff53a569d0ebbe201ad0c102ee27e

    Given a list of tuples as returned by extract_tb() or
    extract_stack(), return a list of strings ready for printing.

There are no tests for iterables other than list at https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py 

So we won't change documentation and docstrings, add more tests without seeing concrete use cases.

> What?s a ?manually created iterable??

I meant an iterable that is extracted from a traceback object manually without using extract_tb() or extract_stack() functions (by using a custom function, an external dependency, or HTTP API) How people can get Iterable[FrameSummary] as an input and pass it to format_list()?

> For how long will the old API be supported for backwards
> compatibility reasons?

I don't remember any plans to remove the support for the old API. And I'm pretty sure we won't do anything until 2.7 is out of maintenance.

> Is new code encouraged to use the new API? If the new API is better,
> shouldn?t new code use it? If the new API isn?t better, why was it
> introduced?

Are you serious? No, we've introduced the new API and spent weeks designing it just to play with people. They should stick with the old one for no reason.

----------

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

From report at bugs.python.org  Thu Sep 20 23:22:22 2018
From: report at bugs.python.org (Windson Yang)
Date: Fri, 21 Sep 2018 03:22:22 +0000
Subject: [docs] [issue34753] Use coroutine object or coroutine function
 instead of coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537500142.28.0.956365154283.issue34753@psf.upfronthosting.co.za>


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

Sure, I found around 7 places may need to change, I can fix some of them right, and I will put the rest links which I'm not sure in the PR comment.

----------

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

From report at bugs.python.org  Fri Sep 21 00:29:38 2018
From: report at bugs.python.org (Ned Deily)
Date: Fri, 21 Sep 2018 04:29:38 +0000
Subject: [docs] [issue34748] Incorrect HTML link in functools.partial
In-Reply-To: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>
Message-ID: <1537504178.72.0.249678724859.issue34748@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.8

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

From report at bugs.python.org  Fri Sep 21 01:41:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 21 Sep 2018 05:41:07 +0000
Subject: [docs] [issue31146] Docs: On non-public translations,
 language picker fallback to "English"
In-Reply-To: <1502206180.29.0.859774070814.issue31146@psf.upfronthosting.co.za>
Message-ID: <1537508467.79.0.249678724859.issue31146@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Sep 21 02:12:18 2018
From: report at bugs.python.org (Monte Davidoff)
Date: Fri, 21 Sep 2018 06:12:18 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537510338.24.0.956365154283.issue29013@psf.upfronthosting.co.za>


Monte Davidoff <md14-python at alluvialsw.com> added the comment:

Serhiy, merely reverting the change would not fix the originally reported problem in the documentation. Based on your additional information, and to prevent the need to describe the ZIP64 extensions in more than one place, I suggest two changes:

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

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

to:

"It can handle ZIP files that use the ZIP64 extensions."

(2) In the description of the zipfile.ZipFile class, change:

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

to:

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

----------

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

From report at bugs.python.org  Fri Sep 21 04:23:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 21 Sep 2018 08:23:32 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537518212.16.0.956365154283.issue29013@psf.upfronthosting.co.za>


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

This would look good too.

To be accurate, zipfile will create ZIP files that use the ZIP64 extensions when:

* It contains more than 65535 files.

* It is larger than 2 GiB. More accurate, when either the offset or the size of the central directory is larger than 2 GiB, so in theory it is possible to exceed the total size of 2 GiB without using ZIP64.

* The original size of any file is larger than 2 GiB.

I'm not sure we should describe the behavior in all details.

----------

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

From report at bugs.python.org  Fri Sep 21 05:22:26 2018
From: report at bugs.python.org (Monte Davidoff)
Date: Fri, 21 Sep 2018 09:22:26 +0000
Subject: [docs] [issue29013] zipfile: inconsistent doc for ZIP64 file size
In-Reply-To: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>
Message-ID: <1537521746.66.0.956365154283.issue29013@psf.upfronthosting.co.za>


Monte Davidoff <md14-python at alluvialsw.com> added the comment:

I agree it may be better if we don't describe all the details of ZIP64. How about this rewording for the second change, so we don't have to give all the details?

(2) In the description of the zipfile.ZipFile class, change:

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

to:

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

----------

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

From silvadabeste8252 at gmail.com  Mon Sep 17 07:58:40 2018
From: silvadabeste8252 at gmail.com (Silva Debest)
Date: Mon, 17 Sep 2018 04:58:40 -0700
Subject: [docs] Quero aprender python
Message-ID: <CA+p==D3N8QL4bBkWmhdCvdMXrjVeUkOTcP3uAceyj9T_5ZomKw@mail.gmail.com>

Tenho sonho de ser um programador penso vossa ajuda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180917/377a385b/attachment.html>

From Darko at web.de  Tue Sep 18 11:33:33 2018
From: Darko at web.de (Dominik Begovic)
Date: Tue, 18 Sep 2018 17:33:33 +0200
Subject: [docs] documentation bug regarding multiprocessing module since
 Python 2.7+
Message-ID: <trinity-f3708d60-ead2-431c-b9e6-a743485af2d3-1537284813551@3c-app-webde-bs15>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180918/3eee80ea/attachment.html>

From fr4nk at mode.net  Thu Sep 20 19:35:09 2018
From: fr4nk at mode.net (Frank Cusack)
Date: Thu, 20 Sep 2018 16:35:09 -0700
Subject: [docs] os.path.basename() bug
Message-ID: <CAMX4NSgcM9t7z6YJoXFrtk=gkQA+tVqsesH171AEY4erq=6Qhg@mail.gmail.com>

os.path.basename(*path*)?
<https://docs.python.org/2/library/os.path.html#os.path.basename>

Return the base name of pathname *path*. This is the second element of the
pair returned by passing *path* to the function split()
<https://docs.python.org/2/library/os.path.html#os.path.split>. Note that
the result of this function is different from the Unix *basename* program;
where *basename* for '/foo/bar/' returns 'bar', the basename()
<https://docs.python.org/2/library/os.path.html#os.path.basename>function
returns an empty string ('').
Clearly 'second element' is wrong, even for the given example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180920/11a64d02/attachment.html>

From report at bugs.python.org  Fri Sep 21 11:41:31 2018
From: report at bugs.python.org (ChrisRands)
Date: Fri, 21 Sep 2018 15:41:31 +0000
Subject: [docs] [issue34764] Improve documentation example for using iter()
 with sentinel value
Message-ID: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>


New submission from ChrisRands <chrisrands0 at gmail.com>:

This arose from this SO question: https://stackoverflow.com/questions/52446415/line-in-iterfp-readline-rather-than-line-in-fp 

The example given in the docs:

with open('mydata.txt') as fp:
    for line in iter(fp.readline, ''):
        process_line(line)

Is exactly equivalent to the following because an empty string is only returned by readline at the EOF:

with open('mydata.txt') as fp:
    for line in fp:
        process_line(line)

The empty string '' sentinel value could be changed to another value to provide a possibly more meaningful example where the 2nd code snippet would not always produce the same result?

----------
assignee: docs at python
components: Documentation
messages: 325995
nosy: ChrisRands, docs at python
priority: normal
severity: normal
status: open
title: Improve documentation example for using iter() with sentinel value

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

From report at bugs.python.org  Fri Sep 21 12:23:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 16:23:08 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537546988.1.0.249678724859.issue33649@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +8888

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

From zachary.ware+pydocs at gmail.com  Fri Sep 21 12:26:34 2018
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 21 Sep 2018 11:26:34 -0500
Subject: [docs] os.path.basename() bug
In-Reply-To: <CAMX4NSgcM9t7z6YJoXFrtk=gkQA+tVqsesH171AEY4erq=6Qhg@mail.gmail.com>
References: <CAMX4NSgcM9t7z6YJoXFrtk=gkQA+tVqsesH171AEY4erq=6Qhg@mail.gmail.com>
Message-ID: <CAKJDb-PZ6MvwJsBaEijscAj+TW0tGcymiYO6LU4zv1osUT8S3g@mail.gmail.com>

Hi Frank,

On Fri, Sep 21, 2018 at 8:44 AM Frank Cusack <fr4nk at mode.net> wrote:
> os.path.basename(path)?
>
> Return the base name of pathname path. This is the second element of the pair returned by passing path to the function split(). Note that the result of this function is different from the Unix basename program; where basename for '/foo/bar/' returns 'bar', the basename()function returns an empty string ('').
>
> Clearly 'second element' is wrong, even for the given example.

Can you demonstrate how it is wrong?  From my own testing everything
looks correct:

   bash-3.2$ basename foo/bar/
   bar
   bash-3.2$ python3
   Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
   [Clang 6.0 (clang-600.0.57)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import os
   >>> os.path.basename('foo/bar/')
   ''
   >>> os.path.split('foo/bar/')
   ('foo/bar', '')

-- 
Zach

From report at bugs.python.org  Fri Sep 21 14:56:19 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 21 Sep 2018 18:56:19 +0000
Subject: [docs] [issue34764] Improve documentation example for using iter()
 with sentinel value
In-Reply-To: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>
Message-ID: <1537556178.97.0.956365154283.issue34764@psf.upfronthosting.co.za>


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

I concur that the readline() example is problematic.  While it succeeds in showing how iter() works, the example itself is not the best way to solve that particular problem.

Here are two possible substitute examples.

1) Simple example that focuses primarily on the behavior of iter() and required little extra knowledge:


    >>> from random import randint
    >>> def roll_dice():
            return randint(1, 6) + randint(1, 6)

    >>> # roll until a seven is seen
    >>> list(iter(roll_dice, 7))
    >>> list(iter(roll_dice, 7))
    [10, 6, 5, 6, 8]

2) Practical application reading binary files in fixed-width blocks for processing with the structure module.  This also teaches how to partial() to produce an arity-zero callable suitable for use with iter().

    >>> Read fixed-width blocks from a database binary file
    >>> from functools import partial
    >>> with open('mydata.db', 'rb') as f:
    	    for block in iter(partial(f.read, 64)):
		print(parse_struct(block))

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

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

From report at bugs.python.org  Fri Sep 21 15:26:19 2018
From: report at bugs.python.org (Benito Kestelman)
Date: Fri, 21 Sep 2018 19:26:19 +0000
Subject: [docs] [issue34768] Add documentation for the purpose of
 __init__.py in packages
Message-ID: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>


New submission from Benito Kestelman <beni.kestel001 at gmail.com>:

I just learned how to make my own package in python and upload it to pypi. I mainly used the documentation here: https://packaging.python.org/tutorials/packaging-projects/

Other than the toy example, there is no explanation of __init__.py, its purpose, or what I should put in it to get my code to work. 

It took me a lot of time and guessing to figure it out, and I had to look at several projects on Github to see how others did it. I found a couple that looked correct because they were concise, but others looked horrendous - one was several thousand lines long. 

A clear explanation of how to use __init__.py when making a package would be extremely helpful.

----------
assignee: docs at python
components: Documentation
messages: 326020
nosy: bkestelman, docs at python
priority: normal
severity: normal
status: open
title: Add documentation for the purpose of __init__.py in packages

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

From report at bugs.python.org  Fri Sep 21 16:23:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 20:23:19 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537561399.63.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset db1a80e97aa7217c561fb3627f70be1882de9534 by Yury Selivanov in branch 'master':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475)
https://github.com/python/cpython/commit/db1a80e97aa7217c561fb3627f70be1882de9534


----------

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

From report at bugs.python.org  Fri Sep 21 16:23:26 2018
From: report at bugs.python.org (miss-islington)
Date: Fri, 21 Sep 2018 20:23:26 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537561406.12.0.249678724859.issue33649@psf.upfronthosting.co.za>


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


----------
pull_requests: +8891

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

From report at bugs.python.org  Fri Sep 21 16:35:37 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 20:35:37 +0000
Subject: [docs] [issue33649] asyncio docs overhaul
In-Reply-To: <1527277722.54.0.682650639539.issue33649@psf.upfronthosting.co.za>
Message-ID: <1537562137.48.0.956365154283.issue33649@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset e45662c28bfc84aa3674463a2995e45da4d63793 by Yury Selivanov (Miss Islington (bot)) in branch '3.7':
bpo-33649: Fix gather() docs; fix title; few other nits. (GH-9475) (GH-9481)
https://github.com/python/cpython/commit/e45662c28bfc84aa3674463a2995e45da4d63793


----------

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

From report at bugs.python.org  Fri Sep 21 17:30:40 2018
From: report at bugs.python.org (ChrisRands)
Date: Fri, 21 Sep 2018 21:30:40 +0000
Subject: [docs] [issue34764] Improve documentation example for using iter()
 with sentinel value
In-Reply-To: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>
Message-ID: <1537565440.85.0.956365154283.issue34764@psf.upfronthosting.co.za>


ChrisRands <chrisrands0 at gmail.com> added the comment:

Thank you Raymond, I like both your examples, although I think I prefer 1) for the simplicity

----------

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

From report at bugs.python.org  Fri Sep 21 19:07:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 21 Sep 2018 23:07:27 +0000
Subject: [docs] [issue30350] devguide suggests to use VS 2008 to build
 Python 2.7, but VS 2008 is no more supported?
In-Reply-To: <1494581567.83.0.310363881682.issue30350@psf.upfronthosting.co.za>
Message-ID: <1537571247.54.0.249678724859.issue30350@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 21 20:10:44 2018
From: report at bugs.python.org (Benito Kestelman)
Date: Sat, 22 Sep 2018 00:10:44 +0000
Subject: [docs] [issue34768] Add documentation explaining __init__.py in
 packages
In-Reply-To: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>
Message-ID: <1537575044.77.0.249678724859.issue34768@psf.upfronthosting.co.za>


Change by Benito Kestelman <beni.kestel001 at gmail.com>:


----------
title: Add documentation for the purpose of __init__.py in packages -> Add documentation explaining __init__.py in packages

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

From report at bugs.python.org  Sat Sep 22 12:35:13 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 16:35:13 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1537634113.0.0.249678724859.issue34476@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Sep 22 13:00:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 17:00:28 +0000
Subject: [docs] [issue33039] int() and math.trunc don't accept objects that
 only define __index__
In-Reply-To: <1520672231.04.0.467229070634.issue33039@psf.upfronthosting.co.za>
Message-ID: <1537635628.34.0.249678724859.issue33039@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Sep 22 13:51:42 2018
From: report at bugs.python.org (Tal Einat)
Date: Sat, 22 Sep 2018 17:51:42 +0000
Subject: [docs] [issue34369] kqueue.control() documentation and
 implementation mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1537638701.77.0.249678724859.issue34369@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep 22 14:52:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 18:52:28 +0000
Subject: [docs] [issue33043] Add a 'Contributing to Docs' link at the bottom
 of docs.python.org
In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>
Message-ID: <1537642348.96.0.249678724859.issue33043@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Sep 22 15:06:26 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 22 Sep 2018 19:06:26 +0000
Subject: [docs] [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1537643186.02.0.956365154283.issue31737@psf.upfronthosting.co.za>


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

Just as an update current docs site uses Sphinx 1.7.6 and the rendering is correct.

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Sat Sep 22 17:21:07 2018
From: report at bugs.python.org (Julien Palard)
Date: Sat, 22 Sep 2018 21:21:07 +0000
Subject: [docs] [issue31737] Documentation renders incorrectly
In-Reply-To: <1507571383.25.0.213398074469.issue31737@psf.upfronthosting.co.za>
Message-ID: <1537651267.7.0.956365154283.issue31737@psf.upfronthosting.co.za>


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

Thanks for the follow up!

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

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

From report at bugs.python.org  Sun Sep 23 10:34:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:34:27 +0000
Subject: [docs] [issue28418] Raise Deprecation warning for
 tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537713267.04.0.956365154283.issue28418@psf.upfronthosting.co.za>


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

I just stumbled upon this issue while triaging. With the related issue https://bugs.python.org/issue12486 closed making generate_tokens public can this issue be closed since the original issue is not valid?

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep 23 10:42:49 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 14:42:49 +0000
Subject: [docs] [issue33340] Inaccurate docs on `import` behaviour
In-Reply-To: <1524477096.11.0.682650639539.issue33340@psf.upfronthosting.co.za>
Message-ID: <1537713769.11.0.249678724859.issue33340@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep 23 12:01:54 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:01:54 +0000
Subject: [docs] [issue33553] Documentation improvement proposal for
 multiprocessing
In-Reply-To: <1526541318.79.0.682650639539.issue33553@psf.upfronthosting.co.za>
Message-ID: <1537718514.38.0.249678724859.issue33553@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep 23 12:07:47 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:07:47 +0000
Subject: [docs] [issue26374] concurrent_futures Executor.map semantics
 better specified in docs
In-Reply-To: <1455711990.13.0.290959896018.issue26374@psf.upfronthosting.co.za>
Message-ID: <1537718867.91.0.956365154283.issue26374@psf.upfronthosting.co.za>


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

There were some improvements made that clarify differences between builtin map with https://bugs.python.org/issue32306 and https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d

Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep 23 12:15:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 23 Sep 2018 16:15:22 +0000
Subject: [docs] [issue24653] Mock.assert_has_calls([]) is surprising for
 users
In-Reply-To: <1437126004.09.0.453747784975.issue24653@psf.upfronthosting.co.za>
Message-ID: <1537719322.55.0.249678724859.issue24653@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Sun Sep 23 12:53:12 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 23 Sep 2018 16:53:12 +0000
Subject: [docs] [issue28418] Raise Deprecation warning for
 tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537721592.52.0.956365154283.issue28418@psf.upfronthosting.co.za>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

Yes, I think this can be closed now.

----------

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

From report at bugs.python.org  Mon Sep 24 01:11:58 2018
From: report at bugs.python.org (Windson Yang)
Date: Mon, 24 Sep 2018 05:11:58 +0000
Subject: [docs] [issue34753] Use coroutine object or coroutine function
 instead of coroutine
In-Reply-To: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>
Message-ID: <1537765918.92.0.249678724859.issue34753@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 24 06:42:44 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 24 Sep 2018 10:42:44 +0000
Subject: [docs] [issue24937] Multiple problems in getters & setters in
 capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1537785764.09.0.956365154283.issue24937@psf.upfronthosting.co.za>


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


New changeset 2d3ff2b5ea6c903973f99d2155c9c1b60591dceb by Petr Viktorin in branch 'master':
bpo-24937: Replace the extension module porting HOWTO by links to external projects (GH-9317)
https://github.com/python/cpython/commit/2d3ff2b5ea6c903973f99d2155c9c1b60591dceb


----------

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

From report at bugs.python.org  Mon Sep 24 06:44:31 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 24 Sep 2018 10:44:31 +0000
Subject: [docs] [issue24937] Multiple problems in getters & setters in
 capsulethunk.h
In-Reply-To: <1440520892.99.0.130273606833.issue24937@psf.upfronthosting.co.za>
Message-ID: <1537785871.13.0.249678724859.issue24937@psf.upfronthosting.co.za>


Change by Petr Viktorin <encukou at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 24 08:32:16 2018
From: report at bugs.python.org (=?utf-8?b?Sm9uaSBLw6Row6Ryw6Q=?=)
Date: Mon, 24 Sep 2018 12:32:16 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
Message-ID: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>


New submission from Joni K?h?r? <joni.kahara at async.fi>:

https://docs.python.org/3.8/library/concurrent.futures.html

"initializer is an optional callable that is called at the start of each worker process; initargs is a tuple of arguments passed to the initializer. Should initializer raise an exception, all currently pending jobs will raise a BrokenThreadPool, as well any attempt to submit more jobs to the pool."

This should be BrokenProcessPool?

----------
assignee: docs at python
components: Documentation
messages: 326226
nosy: Joni K?h?r?, docs at python
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor documentation reports wrong exception being raised
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 08:34:07 2018
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 24 Sep 2018 12:34:07 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537792447.53.0.249678724859.issue34786@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Sep 24 08:47:27 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 12:47:27 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537793247.83.0.249678724859.issue34786@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 24 08:51:52 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 12:51:52 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537793512.12.0.956365154283.issue34786@psf.upfronthosting.co.za>


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

I think it raises BrokenThreadPool . A sample program that I tried as below raising an exception in the initializer. Maybe I am wrong here. Can you please attach a script that triggers BrokenProcessPool?

# bpo34786.py

import concurrent.futures
import time

def bar(i):
    raise Exception(i) # Raise exception from the initializer

def foo(i):
    time.sleep(i)
    return "1"

with concurrent.futures.ThreadPoolExecutor(max_workers=5,
                                           initializer=bar, initargs=(1,)) as executor:
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
    for future in concurrent.futures.as_completed(future_to_url):
        try:
            data = future.result()
        except Exception as exc:
            print('generated an exception: %s' % (exc))
        else:
            print('%d bytes' % (len(data)))

# Run the program

./python.exe ../backups/bpo34786.py
Exception in initializer:
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 69, in _worker
    initializer(*initargs)
  File "../backups/bpo34786.py", line 5, in bar
    raise Exception(i)
Exception: 1
Exception in initializer:
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 69, in _worker
    initializer(*initargs)
  File "../backups/bpo34786.py", line 5, in bar
    raise Exception(i)
Exception: 1
Traceback (most recent call last):
  File "../backups/bpo34786.py", line 13, in <module>
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
  File "../backups/bpo34786.py", line 13, in <dictcomp>
    future_to_url = {executor.submit(foo, i, 60): i for i in range(10)}
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/concurrent/futures/thread.py", line 148, in submit
    raise BrokenThreadPool(self._broken)
concurrent.futures.thread.BrokenThreadPool: A thread initializer failed, the thread pool is not usable anymore



Thanks

----------

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

From report at bugs.python.org  Mon Sep 24 09:24:06 2018
From: report at bugs.python.org (=?utf-8?b?Sm9uaSBLw6Row6Ryw6Q=?=)
Date: Mon, 24 Sep 2018 13:24:06 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537795446.51.0.956365154283.issue34786@psf.upfronthosting.co.za>


Joni K?h?r? <joni.kahara at async.fi> added the comment:

Perhaps I wasn't clear that this considered ProcessPoolExecutor documentation, not ThreadPoolExecutor. Taking the example from documentation and adding an initializer like this:


import concurrent.futures
import math

PRIMES = [
    112272535095293,
    112582705942171,
    112272535095293,
    115280095190773,
    115797848077099,
    1099726899285419]

def is_prime(n):
    if n % 2 == 0:
        return False

    sqrt_n = int(math.floor(math.sqrt(n)))
    for i in range(3, sqrt_n + 1, 2):
        if n % i == 0:
            return False
    return True

def init():
    raise Exception()

def main():
    with concurrent.futures.ProcessPoolExecutor(initializer=init) as executor:
        for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
            print('%d is prime: %s' % (number, prime))

if __name__ == '__main__':
    main()


...yields the following:


Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Exception in initializer:
Traceback (most recent call last):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 219, in _process_worker
    initializer(*initargs)
  File "/tmp/bpo34786.py", line 25, in init
    raise Exception()
Exception
Traceback (most recent call last):
  File "/tmp/bpo34786.py", line 33, in <module>
    main()
  File "/tmp/bpo34786.py", line 29, in main
    for number, prime in zip(PRIMES, executor.map(is_prime, PRIMES)):
  File "/Users/developer/cpython/Lib/concurrent/futures/process.py", line 476, in _chain_from_iterable_of_lists
    for element in iterable:
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 594, in result_iterator
    yield fs.pop().result()
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 436, in result
    return self.__get_result()
  File "/Users/developer/cpython/Lib/concurrent/futures/_base.py", line 388, in __get_result
    raise self._exception
concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.

----------

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

From report at bugs.python.org  Mon Sep 24 09:40:05 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 13:40:05 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537796405.98.0.956365154283.issue34786@psf.upfronthosting.co.za>


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

Got it. Sorry about that I copy pasted the quoted string and assumed ThreadPoolExecutor overlooking the PR. The change is reasonable to me.

Thanks

----------

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

From report at bugs.python.org  Mon Sep 24 10:30:04 2018
From: report at bugs.python.org (Jeremy McMillan)
Date: Mon, 24 Sep 2018 14:30:04 +0000
Subject: [docs] [issue34788] ipaddress module fails on rfc4007 scoped IPv6
 addresses
Message-ID: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>


New submission from Jeremy McMillan <jeremy.mcmillan at gmail.com>:

ipaddress module has no support for scoped IPv6 addresses which prevents the use of ipaddress.ip_address() and ipaddress.IPv6Address() with (always available by default on IPv6 systems) RFC conforming IPv6 link local addresses that specify interface scope.

https://tools.ietf.org/html/rfc4007

This is bad because interface scope is required for connect() and bind() operations on multihomed machines, and virtualized or software defined networking will make this case very common.

eg.

>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff')
IPv6Address('fe80::dead:dead:beef:ffff')
>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'
>>> ipaddress.IPv6Interface('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 2060, in __init__
    IPv6Address.__init__(self, addr[0])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 326240
nosy: Jeremy McMillan, docs at python
priority: normal
severity: normal
status: open
title: ipaddress module fails on rfc4007 scoped IPv6 addresses
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 10:32:25 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Mon, 24 Sep 2018 14:32:25 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537799544.96.0.956365154283.issue34648@psf.upfronthosting.co.za>


Nathaniel Manista <nathaniel at google.com> added the comment:

> The question that needs to be answered here is "why we should support
> Iterable[FrameSummary]?" and you're one the one who needs to answer
> it

Okay, here are a few reasons:
1) A function that requires that an input be a List invites the question ?why is an Iterable, or a Collection, or a Sequence, not sufficient??. Of course the best way to handle that question is to widen the API to accept at least a Sequence so that the question isn?t even asked, but the next-best way to handle the question is with an answer like ?because the function mutates the given List?. But that?s not the answer to the question here (which is a big part of why I opened the bug, asking the question more directly). So far the answer seems to be ?because we wanted to be conservative in our API design? and ?because we didn?t want to support what we weren?t testing?. Those are good answers, but I?d like to persuade you that they are no longer good enough.
2) Because List is invariant in element type whereas Sequence, Collection, and Iterable are covariant (I'm nearly certain) in element type, format_list is hard to use with type-checked code (see the discussion in https://github.com/python/typeshed/pull/2436 if you?re not following it already). Should the typeshed-canonicalized type of format_list?s ?extracted_list? parameter be ?List[FrameSummary]?? If so, then given a subclass MyFrameSummarySubclass of FrameSummary, List[MyFrameSummarySubclass] would *not* be valid to pass to format_list. That seems like a poor developer experience, right? If the type of ?extracted_list? were widened to Sequence[FrameSummary], Collection[FrameSummary], or (ideally) Iterable[FrameSummary], then an expression of type Iterable[MyFrameSummarySubclass] would be perfectly fine to pass for ?extracted_list?.
3) I tried to pass an Iterable[FrameSummary] to traceback.format_list in my own code. My situation is not itself open source but is a bit like this:

    def _FormatFrames(frame) -> str:
        """Generate a traceback of the current position of the thread in the code."""
        frame_tuples = []
        while frame:
            filename = <censored>
            lineno = frame.f_lineno
            line = <censored>
            frame_tuples.append((filename, lineno, frame.f_code.co_name, line,))
            frame = frame.f_back
        formatted_frame_strings = traceback.format_list(
            traceback.FrameSummary(file_name, line_number, frame_name, line=line)
            for file_name, line_number, frame_name, line in frame_tuples)
        return ''.join(formatted_frame_strings)

.

> instead of saying our design decisions were "absurd" and "not wise",
> without giving any concrete use cases for your "wider" design choice.

According to what we?ve learned over the course of the life and use of Python, and according to what we understand as best practices in the year 2018: I believe it is absolutely unwise to have offer an API that requires that a given parameter be a List without documenting the reasons sustaining that extremely limited design. Why won?t a Sequence suffice? Heck, why won?t some other implementation of MutableSequence suffice? Notice that I opened this bug with the question ?wait, really?? rather than the statement ?this is wrong and must be changed? - it might be the case that List is the best choice for the type of the parameter (though I now doubt it even more) but certainly it?s clear that *the documentation does not establish or communicate why a List is required*.

> Initial docstring for format_list() were added in 2000:
> https://github.com/python/cpython/commit/e7b146fb3bdc#diff-e57ff53a569d0ebbe201ad0c102ee27e
>
>     Given a list of tuples as returned by extract_tb() or
>     extract_stack(), return a list of strings ready for printing.

I have no doubt that that?s what was written in 2000, when we didn?t know nearly as much as we do today and when what were considered best practices were radically different. Now we know more - particularly for this case ?never ask for a List where asking for a MutableSequence will do, and never ask for a MutableSequence where asking for a Sequence will do, and never ask for a Sequence where asking for a Collection will do, and never ask for a Collection where asking for an Iterable will do?. The big question for format_list is ?will an Iterable do??. If not, that?s strange and unique by today?s standards and practices and the function?s documentation should at least give some enlightenment as to why it is the case.

> There are no tests for iterables other than list at
> https://github.com/python/cpython/blob/master/Lib/test/test_traceback.py 

I?d be happy to add some? except test_traceback.py doesn?t appear to contain any direct testing of format_list, and I can?t find ?the format_list tests? to which it alludes (https://github.com/python/cpython/search?q=format_list&unscoped_q=format_list). Is there any direct call to traceback.format_list under Lib/test? Where should tests of passing an Iterable to format_list be added?

> So we won't change documentation and docstrings, add more tests without seeing concrete
> use cases.

I wouldn?t be here if I were personally affected in my own use case, and as more and more users start statically verifying their code with mypy and pytype, more and more of them will be affected. This problem is worth solving.

> I meant an iterable that is extracted from a traceback object manually without
> using extract_tb() or extract_stack() functions (by using a custom function, an
> external dependency, or HTTP API) How people can get
> Iterable[FrameSummary] as an input and pass it to format_list()?

FrameSummary is a public class with a public constructor. Anyone can construct instances of it for any reason and aggregate them in any Iterable they please; the question before us is whether or not format_list should accept any such Iterable or should insist that callers re-aggregate their FrameSummarys in a List. I?ve only described here the only use case that I happen personally to have encountered, but I think it?s worth bearing in mind that *public code elements invite public use*, so we shouldn?t be surprised when FrameSummary and format_list get used for purposes for which they appear well-suited, but which weren?t necessarily envisioned.

> Are you serious?

Yes.

> No, we've introduced the new API and spent weeks designing it just
> to play with people. They should stick with the old one for no reason.

Thank you for this very strong affirmation, which is more constructive than I suspect you meant it to be. Note that the documentation of format_list doesn?t mention a preference for passing FrameSummarys over passing Tuples, but that may simply be a consequence of not writing the documentation with passing of caller-constructed-values-that-were-not-returned-by-extract_tb-or-extract_stack in mind. Over in https://github.com/python/typeshed/pull/2436 there?s some back-and-forth over what the *element type* of ?extracted_list? should be, and I?m in favor of going the extra mile and making it FrameSummary in 3.5-and-later rather than Union[Tuple[str, int, str, Optional[str]], FrameSummary]. It?s reasonable to say that if an author is being diligent enough to type-check their code, we can presume that they are diligent enough to use an API according to current best practices rather than making use of a backwards compatibility carve-out, right? It sounds like you might feel similarly?

----------

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

From report at bugs.python.org  Mon Sep 24 11:15:28 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 15:15:28 +0000
Subject: [docs] [issue28418] Raise Deprecation warning for
 tokenize.generate_tokens
In-Reply-To: <1476212697.92.0.408666384378.issue28418@psf.upfronthosting.co.za>
Message-ID: <1537802128.15.0.956365154283.issue28418@psf.upfronthosting.co.za>


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

Since generate_tokens was made public and documented with issue12486 I am closing this issue as won't fix as part of triaging. Feel free to reopen this issue if needed.

Thanks

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

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

From report at bugs.python.org  Mon Sep 24 11:41:06 2018
From: report at bugs.python.org (Jelle Zijlstra)
Date: Mon, 24 Sep 2018 15:41:06 +0000
Subject: [docs] [issue34648] Confirm the types of parameters of
 traceback.format_list and traceback.StackSummary.from_list post-3.5
In-Reply-To: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>
Message-ID: <1537803666.03.0.956365154283.issue34648@psf.upfronthosting.co.za>


Jelle Zijlstra <jelle.zijlstra at gmail.com> added the comment:

> How people can get Iterable[FrameSummary] as an input and pass it to format_list()?

If I want to format a traceback, but omit traceback lines that refer to a particular module (for example, code for a coroutine runner), I could write `format_list(filter(lambda fs: 'asyncio' not in fs.filename, extract_stack())`.

I would also favor broadening the documented argument type for `format_list()` to say it accepts an iterable of FrameSummaries. No code change is necessary and it makes the code more flexible.

----------
nosy: +Jelle Zijlstra

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

From report at bugs.python.org  Mon Sep 24 12:04:07 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 16:04:07 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
Message-ID: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Doc says:

"If parser_list is provided, it must be a *sequence* of strings which name modules that have a function named create_parser()"

but code concatenas parser_list with an existing list:

for parser_name in parser_list + default_parser_list:

Fix this by stating parser_list must be a specific kind of sequence, that is, a list.

----------
assignee: docs at python
components: Documentation
messages: 326261
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc xml.sax.make_parser expects a list not just any sequence
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 12:05:00 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 16:05:00 +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: <1537805100.99.0.249678724859.issue34788@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy: +pmoody

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

From report at bugs.python.org  Mon Sep 24 12:06:06 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 16:06:06 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537805166.84.0.249678724859.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 24 12:24:40 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 16:24:40 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537806280.67.0.956365154283.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

I'm just going to presume this issue has been around a long time, but I think that's a pretty safe presumption.

Accepting a general sequence instead of only a list would reasonable, and I'd support a fix that caused the code to accept a general sequence (or any iterable) by calling list() on the passed-in value, starting with 3.8.

The patch provided looks good for versions in maintenance.  (It would also be fine for 3.8 if there's no interest in generalizing the code to accept arbitrary iterables).

----------
nosy: +fdrake

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

From report at bugs.python.org  Mon Sep 24 12:30:09 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 16:30:09 +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: <1537806609.28.0.249678724859.issue34788@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 24 13:58:52 2018
From: report at bugs.python.org (Mark Diekhans)
Date: Mon, 24 Sep 2018 17:58:52 +0000
Subject: [docs] [issue34792] Tutorial doesn''t discuss / and * function
 arguments
Message-ID: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>


New submission from Mark Diekhans <markd at kermodei.com>:

https://docs.python.org/3/tutorial/controlflow.html doest not discuss / and * arguments (end of positional, keyword required)

----------
assignee: docs at python
components: Documentation
messages: 326277
nosy: diekhans, docs at python
priority: normal
severity: normal
status: open
title: Tutorial doesn''t discuss / and * function arguments
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 24 14:16:20 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 18:16:20 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537812979.96.0.956365154283.issue34789@psf.upfronthosting.co.za>


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

I think it makes sense for make_parser to accept any iterable too. I'll update the PR when I have the testcase ready.

----------

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

From report at bugs.python.org  Mon Sep 24 14:44:54 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 18:44:54 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537814694.61.0.545547206417.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

It probably makes more sense to keep that PR for the maintenance branches, and create a new branch / PR to land on master.

----------

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

From report at bugs.python.org  Mon Sep 24 15:01:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 24 Sep 2018 19:01:51 +0000
Subject: [docs] [issue34792] Tutorial doesn''t discuss / and * function
 arguments
In-Reply-To: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>
Message-ID: <1537815711.87.0.545547206417.issue34792@psf.upfronthosting.co.za>


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

There is a related issue to document / in signatures though : https://bugs.python.org/issue21314

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Sep 24 15:33:47 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 19:33:47 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537817627.26.0.545547206417.issue34789@psf.upfronthosting.co.za>


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

Admittedly, my Git-fu is not strong, but since the PR was opened against master, and given that the PR as is won't be merged to master, can it still be "backported" to 3.7, 3.6, and 2.7?

Shouldn't I update the PR so it can be merged to master (that won't be backported), and then open a new PR against 3.7 that will be backported to 3.6 and 2.7?

----------

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

From report at bugs.python.org  Mon Sep 24 15:40:30 2018
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 24 Sep 2018 19:40:30 +0000
Subject: [docs] [issue34792] Tutorial doesn''t discuss / and * function
 arguments
In-Reply-To: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>
Message-ID: <1537818030.27.0.668975606942.issue34792@psf.upfronthosting.co.za>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


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

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

From report at bugs.python.org  Mon Sep 24 16:51:21 2018
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 24 Sep 2018 20:51:21 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537822281.28.0.545547206417.issue34789@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

The existing PR can be re-targeted to merge to a maintenance branch (I'd be inclined to merge manually, myself, but will have to check the current devguide to make sure that's still allowed).

A new PR can be made for the non-documentation fix for master.

My thought is that a PR is more about the patch than about the workflow; a different patch can be handled in a separate PR, and review & discussion are used to determine which PR should be applied where.

----------

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

From report at bugs.python.org  Mon Sep 24 22:34:31 2018
From: report at bugs.python.org (Jeremy McMillan)
Date: Tue, 25 Sep 2018 02:34:31 +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: <1537842871.9.0.545547206417.issue34788@psf.upfronthosting.co.za>


Jeremy McMillan <jeremy.mcmillan at gmail.com> added the comment:

subclass workaround implementation example

https://github.com/isbm/salt/blob/976fe19d73ca6bf5df375eaa15d77ce4a5a54b7a/salt/_compat.py#L125

----------

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

From report at bugs.python.org  Mon Sep 24 23:33:31 2018
From: report at bugs.python.org (miss-islington)
Date: Tue, 25 Sep 2018 03:33:31 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537846411.67.0.668975606942.issue34786@psf.upfronthosting.co.za>


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


----------
pull_requests: +8957

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

From report at bugs.python.org  Mon Sep 24 23:38:07 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 25 Sep 2018 03:38:07 +0000
Subject: [docs] [issue34786] ProcessPoolExecutor documentation reports wrong
 exception being raised
In-Reply-To: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>
Message-ID: <1537846687.76.0.668975606942.issue34786@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Sep 25 03:16:24 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 07:16:24 +0000
Subject: [docs] [issue31865] html.unescape does not work as per documentation
In-Reply-To: <1508899606.23.0.213398074469.issue31865@psf.upfronthosting.co.za>
Message-ID: <1537859784.21.0.545547206417.issue31865@psf.upfronthosting.co.za>


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

Thanks for the report. The relevant regex to is at https://github.com/python/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/html/__init__.py#L118 added with the commit 4a9ee26750aa8cb37b5072b2bb4dd328819febb4 . As far as I can see from the tests I can confirm this is a doc issue. Would you like to propose a PR for this?

The changes have to be done are at below places : 

* https://github.com/python/cpython/blob/f6c8007a29b95b3ea3ca687a9b4924769a696328/Lib/html/__init__.py#L125
* https://github.com/python/cpython/blob/master/Doc/library/html.rst

I am adding @ezio.melotti for a confirmation of the same.

Thanks

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

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

From report at bugs.python.org  Tue Sep 25 03:52:17 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 07:52:17 +0000
Subject: [docs] [issue34748] Incorrect HTML link in functools.partial
In-Reply-To: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>
Message-ID: <1537861937.31.0.545547206417.issue34748@psf.upfronthosting.co.za>


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

Thanks @xitop for the report. Seems reasonable to me to link to https://docs.python.org/3.8/library/functools.html#partial-objects . Along similar lines I would suggest the below too where "partial objects" could be linked #partial-objects instead of #functools.partial . I will leave it for the reviewers though to decide on this.

"When func is a descriptor (such as a normal Python function, classmethod(), staticmethod(), abstractmethod() or another instance of partialmethod), calls to __get__ are delegated to the underlying descriptor, and an appropriate partial object returned as the result."


Thanks

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep 25 07:42:06 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:42:06 +0000
Subject: [docs] [issue33442] Python 3 doc sidebar dosnt follow page
 scrolling like 2.7 doc sidebar.
In-Reply-To: <1525698362.62.0.682650639539.issue33442@psf.upfronthosting.co.za>
Message-ID: <1537875726.35.0.668975606942.issue33442@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Sep 25 07:55:49 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 25 Sep 2018 11:55:49 +0000
Subject: [docs] [issue33442] Python 3 doc sidebar dosnt follow page
 scrolling like 2.7 doc sidebar.
In-Reply-To: <1525698362.62.0.682650639539.issue33442@psf.upfronthosting.co.za>
Message-ID: <1537876549.1.0.545547206417.issue33442@psf.upfronthosting.co.za>


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

Thanks for the report Pete. The Python documentation theme is maintained at https://github.com/python/python-docs-theme/ and this particular issue is tracked at https://github.com/python/python-docs-theme/issues/20 . Related issues : issue34378, issue28044 . I am closing this as duplicate of issue28044. Feel free to open an issue at GitHub if it's different from the existing issue.

Thanks

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Make the sidebar in the documentation follow the section automatically

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

From report at bugs.python.org  Tue Sep 25 14:40:43 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:40:43 +0000
Subject: [docs] [issue34789] doc xml.sax.make_parser expects a list not just
 any sequence
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537900843.67.0.668975606942.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
pull_requests: +8978

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

From fr4nk at mode.net  Fri Sep 21 12:50:58 2018
From: fr4nk at mode.net (Frank Cusack)
Date: Fri, 21 Sep 2018 09:50:58 -0700
Subject: [docs] os.path.basename() bug
In-Reply-To: <CAKJDb-PZ6MvwJsBaEijscAj+TW0tGcymiYO6LU4zv1osUT8S3g@mail.gmail.com>
References: <CAMX4NSgcM9t7z6YJoXFrtk=gkQA+tVqsesH171AEY4erq=6Qhg@mail.gmail.com>
 <CAKJDb-PZ6MvwJsBaEijscAj+TW0tGcymiYO6LU4zv1osUT8S3g@mail.gmail.com>
Message-ID: <CAMX4NShomNWvewRL53q4QbV=LPJVSzJz4x=H2mbu6oT_oG=Nag@mail.gmail.com>

My mistake! I misread split() as referring to string.split(), as opposed to
os.path.split(). It did seem inconceivable that such an error could have
been there for so long.

Thank you for the response.

On Fri, Sep 21, 2018 at 9:26 AM, Zachary Ware <zachary.ware+pydocs at gmail.com
> wrote:

> Hi Frank,
>
> On Fri, Sep 21, 2018 at 8:44 AM Frank Cusack <fr4nk at mode.net> wrote:
> > os.path.basename(path)?
> >
> > Return the base name of pathname path. This is the second element of the
> pair returned by passing path to the function split(). Note that the result
> of this function is different from the Unix basename program; where
> basename for '/foo/bar/' returns 'bar', the basename()function returns an
> empty string ('').
> >
> > Clearly 'second element' is wrong, even for the given example.
>
> Can you demonstrate how it is wrong?  From my own testing everything
> looks correct:
>
>    bash-3.2$ basename foo/bar/
>    bar
>    bash-3.2$ python3
>    Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
>    [Clang 6.0 (clang-600.0.57)] on darwin
>    Type "help", "copyright", "credits" or "license" for more information.
>    >>> import os
>    >>> os.path.basename('foo/bar/')
>    ''
>    >>> os.path.split('foo/bar/')
>    ('foo/bar', '')
>
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180921/5b67d68a/attachment-0001.html>

From francis at esmonde-white.com  Fri Sep 21 14:34:15 2018
From: francis at esmonde-white.com (Francis Esmonde-White)
Date: Fri, 21 Sep 2018 14:34:15 -0400
Subject: [docs] 2 Bugs: in Python 3 tutorial,
 and in bugs.python.org tracker registration system
Message-ID: <CANr6M_ATwozLWxCBapD3z9hKuZUB9bc9t7aDq8o642hTd-Pk2g@mail.gmail.com>

Hello,

I came to report one bug (in the Python 3 tutorial documentation), and ran
into another (functional in bugs.python.org bug tracker registration
system). I have included details for both bugs below.

Thanks in advance for your assistance, I am loving Python and the
documentation!

Warm regards,
Francis Esmonde-White

###############################

*Bug 1:*
In the Python 3 tutorial section 9.8 for iterators
<https://docs.python.org/3/tutorial/classes.html#iterators>, the example
code for the iterator class Reverse has the iterator self.index defined
only in the __init__. This approach will only allow the iterator to run
once. Would it be better to show an example with the index defined as both
a private field (self._index) and with the index value being populated in
the __index__() function so that the method can be run more than once?

I think that the code example should look like the following:

class Reverse:
    """Iterator for looping over a sequence backwards."""
    def __init__(self, data):
        self.data = data

    def __iter__(self):
        # Define the setup for the iteration here,
        # so that the index is always right when the iteration starts.
        self._index = len(self.data)
        return self

    def __next__(self):
        if self._index == 0:
            raise StopIteration
        self._index = self._index - 1
        return self.data[self._index]


###############################


*Bug 2:*
I received errors when trying to confirm my registration for the bug
tracker at bugs.python.org.

I submitted the registration form, and immediately received the
autogenerated registration confirmation email with the following title:
Complete your registration to Python tracker -- key
6w7gUOVw7AR13ZivbxaDIWedYuNlsiwc
- send a reply to report at bugs.python.org and maintain the subject line as
is (the
reply's additional "Re:" is ok),

- or visit the following URL:

https://bugs.python.org/?@action=confrego&otk=6w7gUOVw7AR13ZivbxaDIWedYuNlsiwc

When I visit the URL, I get an error message:
Invalid URL scheme in homepage URL

[image: image.png]


When I try reply-emailing to the reply-email address, I get an immediate
error response:
Failed issue tracker submission

[image: image.png]

The message header is as follows:

An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: <francis at esmonde-white.com>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from mail-io1-f41.google.com (mail-io1-f41.google.com
[209.85.166.41])
        by psf.upfronthosting.co.za (Postfix) with ESMTPS id 20182575F8
        for <report at bugs.python.org>; Fri, 21 Sep 2018 20:14:55 +0200 (CEST)
Received: by mail-io1-f41.google.com with SMTP id q5-v6so13115080iop.3
        for <report at bugs.python.org>; Fri, 21 Sep 2018 11:14:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=esmonde-white.com; s=google;

h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
        bh=j+2C/XsoJvmbt6nnvO0Fa4MikEbIW3k/zd/YnMGZvuA=;
        b=mZnvJcVfxgR8U2qwjRQ6tQ44enty8yowgK6MU7wvzbNpMQHP7yinlzLAfIwpK1AMzj

 G0dn+xISNwbsXjXG5ECxs+hCVwZ1NNTtDJ9z8lZ6mLuNt56NC9ZdXHV4zuMb+CUjAqQn
         P/G9Ml9JfRumX5RPu38WChj5isbzRPZBKg37E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to;
        bh=j+2C/XsoJvmbt6nnvO0Fa4MikEbIW3k/zd/YnMGZvuA=;
        b=mwJ5HUkpeSaaL1hMQVJcHEx49qxtoncoexsN9kiHHfFS0wLXp4YHQUrQjPj+7TL30f

 HiqcMzApIkK28s3xaY7K4nHMgxVBXYSvGH9IuITyipIMZRXutaLDLVFnmTuGojRhE098

 4zxzYhg7wdb4RzN6ErdBWOIp/lLQpzQVEPjq1ttS8+1G5axx3Hc0IIPSOCm5JhSokMxJ

 7XcOuxEc9dAw3JG35kKqSZL12+Wy4rawCbr4NA3EzMtliNfr6eTrTYaAGQXVvIhDQw21

 AziPw3nk4b4jJTfHUfR//fFevS5Lee6RbEoZkR6WJiEfc0Cf3T7vAmmbUzIyKoq6oukL
         Xcag==
X-Gm-Message-State: APzg51BW8XYEje6RQgooxkKeoCrzW+raQNVcOCW2YGGWJTf85Gpt1AU9
        ZIh4KDClWBI0FbsJic0pBPs3W94iWGAacb03RAaCDrngLgI=
X-Google-Smtp-Source:
ANB0VdZolOd9qeDV+t3/g0FwyhoMl60y57O9uRsfrCdXb+okMXSiUD2SmmQjBol22Lm5Y3pRiKyoRuJGODwAQFgjZr0=
X-Received: by 2002:a6b:90d4:: with SMTP id
s203-v6mr37864717iod.249.1537553692241;
 Fri, 21 Sep 2018 11:14:52 -0700 (PDT)
MIME-Version: 1.0
References: <20180921181200.0F02E578D9 at psf.upfronthosting.co.za>
In-Reply-To: <20180921181200.0F02E578D9 at psf.upfronthosting.co.za>
From: Francis Esmonde-White <francis at esmonde-white.com>
Date: Fri, 21 Sep 2018 14:14:14 -0400
Message-ID: <CANr6M_B0V-C4d2rQ=
UE0VfP8bU9dFxew2tyrs4DvEvRVYyZDyA at mail.gmail.com>
Subject: Re: Complete your registration to Python tracker -- key
Zgn4fuEPaJDpJ9ZV00ClUdj92h7nEkRp
To: report at bugs.python.org
Content-Type: multipart/alternative;
boundary="000000000000a649eb0576659d88"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180921/909cef57/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 11969 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20180921/909cef57/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 34069 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20180921/909cef57/attachment-0003.png>

From yoonghm at gmail.com  Tue Sep 25 03:33:14 2018
From: yoonghm at gmail.com (Hor Meng Yoong)
Date: Tue, 25 Sep 2018 15:33:14 +0800
Subject: [docs] Documentation bug for Process Pools
Message-ID: <CAEKCi_-OYy_C2cDE_TSqFjAg2BBuC4dESkNfMJEu8oA3KwY5CQ@mail.gmail.com>

Hi,

  The argument for multiprocessing.pool.Pool shall be keyword argument
instead of positional. Hence the documentation should be revised from

class multiprocessing.pool.Pool([processes[, initializer[, initargs[,
maxtasksperchild[, context]]]]])

to

class multiprocessing.pool.Pool([processes[, initializer=None[,
initargs=()[, maxtasksperchild=None[, context=None]]]]])


Best regards
Hor Meng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180925/99288419/attachment.html>

From report at bugs.python.org  Tue Sep 25 14:55:51 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:55:51 +0000
Subject: [docs] [issue34789] Make xml.sax.make_parser accept iterables
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537901751.59.0.668975606942.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
components: +Library (Lib) -Documentation
title: doc xml.sax.make_parser expects a list not just any sequence -> Make xml.sax.make_parser accept iterables

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

From report at bugs.python.org  Tue Sep 25 14:56:52 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 25 Sep 2018 18:56:52 +0000
Subject: [docs] [issue34789] Make xml.sax.make_parser accept iterables
In-Reply-To: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>
Message-ID: <1537901812.27.0.668975606942.issue34789@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
components: +XML -Library (Lib)

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

From report at bugs.python.org  Tue Sep 25 16:08:02 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 25 Sep 2018 20:08:02 +0000
Subject: [docs] [issue30964] Mention ensurepip in package installation docs
In-Reply-To: <1500425281.82.0.79058660024.issue30964@psf.upfronthosting.co.za>
Message-ID: <1537906082.18.0.668975606942.issue30964@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Sep 26 01:23:08 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 05:23:08 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
Message-ID: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>


New submission from Aydin <bagiyevaydin at gmail.com>:

In the documentation of Python 3.7.0 there is an error in the usage of the world 'for example'.

----------
assignee: docs at python
components: Documentation
files: Functional Programming HOWTO ? Python 3.7.0 documentation.png
messages: 326418
nosy: docs at python, rarblack
priority: normal
severity: normal
status: open
title: Repetition of 'for example' in documentation
versions: Python 3.7
Added file: https://bugs.python.org/file47825/Functional Programming HOWTO ? Python 3.7.0 documentation.png

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

From report at bugs.python.org  Wed Sep 26 08:55:59 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 26 Sep 2018 12:55:59 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537966559.53.0.545547206417.issue34804@psf.upfronthosting.co.za>


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

Can you provide a link to the occurence of this repetition?

Thanks!

----------
nosy: +pablogsal

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

From report at bugs.python.org  Wed Sep 26 08:59:04 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 12:59:04 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537966744.37.0.545547206417.issue34804@psf.upfronthosting.co.za>


Aydin <bagiyevaydin at gmail.com> added the comment:

https://docs.python.org/3/howto/functional.html

In the 5th paragraph.

----------

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

From report at bugs.python.org  Wed Sep 26 09:25:08 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 26 Sep 2018 13:25:08 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537968308.34.0.668975606942.issue34804@psf.upfronthosting.co.za>


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


----------
nosy: +akuchling

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

From report at bugs.python.org  Wed Sep 26 09:29:14 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 13:29:14 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1537968554.22.0.668975606942.issue34804@psf.upfronthosting.co.za>


Change by Aydin <bagiyevaydin at gmail.com>:


----------
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 02:47:55 2018
From: report at bugs.python.org (Tal Einat)
Date: Thu, 27 Sep 2018 06:47:55 +0000
Subject: [docs] [issue34512] Document platform-specific strftime() behavior
 for non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1538030875.16.0.668975606942.issue34512@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 27 02:55:41 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 06:55:41 +0000
Subject: [docs] [issue34512] Document platform-specific strftime() behavior
 for non-ASCII format strings
In-Reply-To: <1535317582.77.0.56676864532.issue34512@psf.upfronthosting.co.za>
Message-ID: <1538031341.34.0.668975606942.issue34512@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Thu Sep 27 03:14:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 07:14:59 +0000
Subject: [docs] [issue34817] Ellipsis docs has extra dot in the markdown
 that makes it look like .... (four dots)
Message-ID: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I looked up the Ellipsis documentation at https://docs.python.org/dev/library/constants.html#Ellipsis which has the below text : 

> The same as .... Special value used mostly in conjunction with extended slicing syntax for user-defined container data types.

The three dots are marked with backtick and look like codeblock but on a light theme it looks like a CSS issue. The backtick contains the actual ellipsis value (...) but the . at the end makes it look like .... especially since I was also using custom dark theme for https://docs.python.org so I thought it was four dots instead of three dots.

Markdown text at https://github.com/python/cpython/blob/master/Doc/library/constants.rst

> The same as ``...``.  Special used mostly in conjunction with extended slicing syntax for user-defined container data types.

It's very trivial but I thought to add a report and I am fine with a won't fix for this. I thought to add a PR but English is not my first language and I don't know if it can worded better. I can change it to "The same as ... which is a special value used mostly in conjunction with extended slicing syntax for user-defined container data types." to avoid the misleading dot and feedback welcome.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326529
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Ellipsis docs has extra dot in the markdown that makes it look like .... (four dots)
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 14:00:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:00:22 +0000
Subject: [docs] [issue34825] Add more entries to os module to pathlib
 reference table
Message-ID: <1538071222.64.0.545547206417.issue34825@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I found issue33194 where unlink from pathlib can be used to delete a file or symlink similar to os.unlink or os.remove but the visibility for the function was low. I found there is a reference table with os module functions and their equivalent pathlib methods. I think this can be improved by adding an entry for Path.unlink as an equivalent for os.remove and os.unlink. I would suggest adding some more functions to this table. The added functions are as below : 

:func:`os.chmod`                       :meth:`Path.chmod`
:func:`os.mkdir`                       :meth:`Path.mkdir`
:func:`os.rename`                      :meth:`Path.rename`
:func:`os.replace`                     :meth:`Path.replace`
:func:`os.rmdir`                       :meth:`Path.rmdir`
:func:`os.remove`, :func:`os.unlink`   :meth:`Path.unlink` 
:func:`os.path.samefile`               :meth:`Path.samefile`

The only issue is that some functions have a dir_fd=None in os module and I think this table is used for functions that do equivalent actions and not as drop-in replacements with equal type signatures. Feedback welcome. Since the table is present only on 3.7 and master I am leaving 3.6 for versions. I will push a PR shortly for this.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326577
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Add more entries to os module to pathlib reference table
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 14:09:25 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:09:25 +0000
Subject: [docs] [issue34825] Add more entries to os module to pathlib
 reference table
In-Reply-To: <1538071222.64.0.545547206417.issue34825@psf.upfronthosting.co.za>
Message-ID: <1538071765.04.0.668975606942.issue34825@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 27 15:42:03 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:42:03 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077323.12.0.545547206417.issue34802@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I'll make a simple fix for the asyncio.coroutine decorator docs.

> I would suggest below for #coroutines :  

>> Coroutines declared with async/await syntax is the preferred way of writing asyncio applications but asyncio also supports legacy generator-based coroutines.

I don't want to further emphasize generator-based coroutines beyond how they are covered right now.  We'll drop support for them in a just a couple of versions anyways.

----------
assignee:  -> docs at python
components: +Documentation, asyncio
nosy: +docs at python
versions: +Python 3.8

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

From report at bugs.python.org  Thu Sep 27 15:45:42 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 27 Sep 2018 19:45:42 +0000
Subject: [docs] [issue7674] select.select() corner cases: duplicate fds,
 out-of-range fds
In-Reply-To: <1263192751.1.0.719382931138.issue7674@psf.upfronthosting.co.za>
Message-ID: <1538077542.6.0.668975606942.issue7674@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Sep 27 15:48:34 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:48:34 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077714.01.0.545547206417.issue34802@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 59ee5b12938efbf534f2a19300a847bf6b23a77d by Yury Selivanov in branch 'master':
bpo-34802: Fix asyncio.iscoroutine() docs (GH-9611)
https://github.com/python/cpython/commit/59ee5b12938efbf534f2a19300a847bf6b23a77d


----------

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

From report at bugs.python.org  Thu Sep 27 15:48:45 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 19:48:45 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538077725.0.0.668975606942.issue34802@psf.upfronthosting.co.za>


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


----------
pull_requests: +9010

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

From report at bugs.python.org  Thu Sep 27 15:53:22 2018
From: report at bugs.python.org (miss-islington)
Date: Thu, 27 Sep 2018 19:53:22 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538078002.55.0.545547206417.issue34802@psf.upfronthosting.co.za>


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


New changeset 85ccedc5b57ddda198e7176ba787e3896435c504 by Miss Islington (bot) in branch '3.7':
bpo-34802: Fix asyncio.iscoroutine() docs (GH-9611)
https://github.com/python/cpython/commit/85ccedc5b57ddda198e7176ba787e3896435c504


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

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

From report at bugs.python.org  Thu Sep 27 15:57:08 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 27 Sep 2018 19:57:08 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538078228.44.0.668975606942.issue34802@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


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

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

From report at bugs.python.org  Thu Sep 27 16:20:44 2018
From: report at bugs.python.org (Gefn)
Date: Thu, 27 Sep 2018 20:20:44 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538079644.25.0.545547206417.issue34802@psf.upfronthosting.co.za>


Gefn <insomgla at gmail.com> added the comment:

I think it's much clearer

----------

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

From report at bugs.python.org  Thu Sep 27 22:10:14 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 28 Sep 2018 02:10:14 +0000
Subject: [docs] [issue18578] Rename and document test.bytecode_helper as
 test.support.bytecode_helper
In-Reply-To: <1375014946.89.0.0130176350727.issue18578@psf.upfronthosting.co.za>
Message-ID: <1538100614.52.0.545547206417.issue18578@psf.upfronthosting.co.za>


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

@seydou, would you be interested in making a GitHub pull request for your patch?

----------
assignee:  -> docs at python
components: +Documentation, Tests
nosy: +cheryl.sabella, docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.8 -Python 3.4

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

From report at bugs.python.org  Fri Sep 28 05:05:39 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 09:05:39 +0000
Subject: [docs] [issue34369] kqueue.control() documentation and
 implementation mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1538125539.72.0.545547206417.issue34369@psf.upfronthosting.co.za>


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

I think removing all mention of ?None? is a step too far. The ?devpoll?, ?epoll?, and ?poll? documentation all say that ?None? is acceptable for the timeout. Only the ?select? function doesn?t say this.

What about adding to the text:

* ?timeout? in seconds (floats possible); the default is ?None?, to wait forever

----------

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

From report at bugs.python.org  Fri Sep 28 05:20:44 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:20:44 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
Message-ID: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

According to the doc:

    :class:`partial` objects are like :class:`function` objects in that they are callable, weak referencable, and can have attributes.

I don't understand why "weak" here, and it's the only occurence of "weak referencable" in the documentation.

I don't see an object in Python being referencable but NOT weak referencable, do I miss something obvious here?

----------
assignee: docs at python
components: Documentation
messages: 326617
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: functools.partial is weak referncable
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 28 05:36:27 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 28 Sep 2018 09:36:27 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127387.06.0.545547206417.issue34830@psf.upfronthosting.co.za>


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

```

In [1]: import weakref                                                                                                    

In [2]: class A: 
   ...:     __slots__ = ()                                                                                                

In [3]: weakref.ref(A())                                                                                                  
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-3-60f73a442704> in <module>
----> 1 weakref.ref(A())

TypeError: cannot create weak reference to 'A' object

```

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

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

From report at bugs.python.org  Fri Sep 28 05:38:24 2018
From: report at bugs.python.org (Tal Einat)
Date: Fri, 28 Sep 2018 09:38:24 +0000
Subject: [docs] [issue34369] kqueue.control() documentation and
 implementation mismatch
In-Reply-To: <1533882016.89.0.56676864532.issue34369@psf.upfronthosting.co.za>
Message-ID: <1538127504.9.0.545547206417.issue34369@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

I agree Martin, I hadn't noticed that the docs don't otherwise mention the default behavior WRT timeout.

I've added a description as per your suggestion to the PR.

----------

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

From report at bugs.python.org  Fri Sep 28 05:41:07 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 28 Sep 2018 09:41:07 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127667.71.0.668975606942.issue34830@psf.upfronthosting.co.za>


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


----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Sep 28 05:42:26 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:42:26 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127746.06.0.545547206417.issue34830@psf.upfronthosting.co.za>


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

TIL.

So it really make sense in this context to tell a functools.partial is weak referencable?

----------

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

From report at bugs.python.org  Fri Sep 28 05:43:14 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 28 Sep 2018 09:43:14 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127794.41.0.545547206417.issue34830@psf.upfronthosting.co.za>


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

I think yes.

----------

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

From report at bugs.python.org  Fri Sep 28 05:43:58 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:43:58 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538127838.55.0.668975606942.issue34830@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 28 05:50:15 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 28 Sep 2018 09:50:15 +0000
Subject: [docs] [issue34830] functools.partial is weak referncable
In-Reply-To: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>
Message-ID: <1538128215.34.0.545547206417.issue34830@psf.upfronthosting.co.za>


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

Instances of many builtin types are not weak referencable.

>>> weakref.ref(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'int' object
>>> weakref.ref([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create weak reference to 'list' object

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

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

From report at bugs.python.org  Fri Sep 28 07:36:17 2018
From: report at bugs.python.org (Caleb Hattingh)
Date: Fri, 28 Sep 2018 11:36:17 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
Message-ID: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>


New submission from Caleb Hattingh <caleb.hattingh at gmail.com>:

Hi Yury,

As discussed, below is a very rough outline of a proposed TOC for an asyncio tutorial. No content has been written yet (only what you see below). I think we should nail down the TOC first.

Asyncio Tutorial
================

Proposed Table of Contents:

- Why asyncio?
    - Reason #1: thread safety by not using threads at all.
    - Reason #2: very many concurrent socket connections, which threads
      make cumbersome.
    - Demo: concurrency without threads
        - (only goals here are to *briefly* introduce the syntax, and then
          demonstrate concurrency without threads)
        - show two tasks, one prints out integers 0-9, while the other
          prints out letters of the alphabet, A-I.
        - pose the question: "they're running concurrently but we're
          not using threads: how is that possible?"
        - explain that there is a thing called an "event loop" behind
          the scenes that allows execution to switch between the two
          every time one of them "waits".
        - emphasize that you can easily spot where the switch can happen,
          it is where you see the "await" keyword. Switches will occur
          nowhere else.

- The difference between functions and `async def` functions
    - async & await
        - show `async def` functions, compare to `def` functions.  
        - use inspect module to show what things actually are, e.g. function,
          coroutine function, coroutine, generator function, generator,
          asynchronous generator function, asynchronous generator.
        - point out you can only use "await" inside an async def fn
        - point out that `await <x>` is an expression, and you can
          use it in most places any other expression can be used.

- How to run `async def` functions
    - point out there are two different issues: (a) `async def` functions
      can call other functions, and other `async def` functions using
      `await`, but also, (b) how to "get started" with the first
      `async def` function? Answer: run the event loop.
    - show `asyncio.run()`, in particular running an `async def main()`
      function, which itself can call others.

- Dealing with concurrent functions
    - (This is maybe too similar to the new docs in the section
      https://docs.python.org/3/library/asyncio-task.html?highlight=asyncio%20run#coroutines-and-tasks)
    - What if you want to run an `async def` function, but you don't
      want to wait for it? Answer: create a "task" for it.
    - What if you want to run multiple functions concurrently, and you
      do want to wait for all of them to finish? Answer: use `gather`
      or `wait()`

- Case Study: chat server/client (my proposal)
    - (goal is to walk through building a realistic example of using 
      asyncio)
    - (This will be a lot more fun than a web-crawler. Web-crawlers are
      super boring!)
    - (I'm pretty confident the size of the code can be kept small. A 
      lot can be done in under 50 lines, as I showed in the case studies
      in my book)
    - server uses streams API
    - server receives many long-lived connections
    - user can create/join a "room", and then start typing messages.
      Other connected clients in the same room will see the messages.
    - client implementation has some options:
        - could use Tkinter gui, using streams API in an event loop 
          on a separate thread. (This would show how asyncio isn't some 
          alien thing, but is part of python. Would also show how to 
          set up asyncio to work in a separate thread. Finally, would not
          require any external dependencies, only the stdlib is needed
          for the entire case study.)
        - could use a browser client, connecting back to the server 
          over a websocket connection. (This might seem simpler, but 
          in fact introduces a lot more complexity than just using
          tkinter. We need to bring in html, css, probably some js and
          probably also a third-party websockets python library. I feel
          like it isn't a good fit for a stdlib python tutorial, but it 
          is a more modern approach.)
        - there are not a lot of other options. terminal-based client 
          might be possible, but probably hard, not cross-platform, and 
          will be unappealing to many people. 
    - When describing the code, point out:
        - you have to choose a "message protocol" (size-prefixed is fine)
        - you must put `send` and `recv` in separate tasks
        - server will "keep track" of connected clients and the room
          (or rooms?) they've joined
        - startup and shutdown, specific references to the new `run()`
          function
        - <others>?

----------
assignee: docs at python
components: Documentation, asyncio
messages: 326628
nosy: asvetlov, cjrh, docs at python, willingc, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Tutorial
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 28 09:07:11 2018
From: report at bugs.python.org (Martin Panter)
Date: Fri, 28 Sep 2018 13:07:11 +0000
Subject: [docs] [issue34817] Ellipsis docs has extra dot in the markdown
 that makes it look like .... (four dots)
In-Reply-To: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za>
Message-ID: <1538140031.41.0.545547206417.issue34817@psf.upfronthosting.co.za>


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

In these situations, I use quotes or brackets to mention a symbol without using it as punctuation. Using words might also help. What about:

Ellipsis
  The same as the ellipsis literal ?...?. Special value used [etc]

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

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

From report at bugs.python.org  Fri Sep 28 12:21:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 28 Sep 2018 16:21:38 +0000
Subject: [docs] [issue34802] asyncio.iscoroutine() documentation is wrong
In-Reply-To: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>
Message-ID: <1538151698.09.0.668975606942.issue34802@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
pull_requests: +9023

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

From report at bugs.python.org  Fri Sep 28 13:13:36 2018
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 28 Sep 2018 17:13:36 +0000
Subject: [docs] [issue34768] Add documentation explaining __init__.py in
 packages
In-Reply-To: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>
Message-ID: <1538154816.23.0.545547206417.issue34768@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the expectation is that people will know about modules and packages long before they upload things to PyPI.  The import system and the packaging tools are two independent domains.

For example the official tutorial has an intro: https://docs.python.org/3/tutorial/modules.html#packages

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Sep 28 18:17:05 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 28 Sep 2018 22:17:05 +0000
Subject: [docs] [issue9056] Adding additional level of bookmarks and section
 numbers in python pdf documents.
In-Reply-To: <1277175637.31.0.472126376822.issue9056@psf.upfronthosting.co.za>
Message-ID: <1538173025.03.0.668975606942.issue9056@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Sep 28 20:18:05 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 00:18:05 +0000
Subject: [docs] [issue34839] doctest: Change example under warnings section
Message-ID: <1538180284.16.0.545547206417.issue34839@psf.upfronthosting.co.za>


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

The Warnings section of the doctest documentation (https://docs.python.org/3.8/library/doctest.html#warnings) contains an example that the printing order of a dictionary is not guaranteed.  Since it is now guaranteed to be insertion order, perhaps the example should be changed.

----------
assignee: docs at python
components: Documentation
messages: 326663
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: doctest: Change example under warnings section
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 28 20:34:53 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 29 Sep 2018 00:34:53 +0000
Subject: [docs] [issue34831] Asyncio Tutorial
In-Reply-To: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>
Message-ID: <1538181293.27.0.545547206417.issue34831@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I like this, great job!


Couple of thoughts on how we should organize this:

* I think we should stick to your structure and push things to docs.python.org as soon as every next section is somewhat ready.

* Every big section should probably have its own page, linking prev/next tutorial pages.

* I'd organize the tutorial in a dedicated directory like "Doc/library/asyncio-tutorial/".  Context: I wanted to reorganize all current "Doc/library/asyncio*.rst" files under one dir too, but decided to keep the existing file structure to avoid breaking links to the docs from SO/google).  We shouldn't repeat that mistake again.

BTW, maybe we should consider using the new iPythonn async repl: https://blog.jupyter.org/ipython-7-0-async-repl-a35ce050f7f7   What do you think about that?


Some comments on the proposed TOC:

>    - Reason #1: thread safety by not using threads at all.
>    - Reason #2: very many concurrent socket connections, which threads
>      make cumbersome.

This section is super important to get right, as I see people ask the "why and where should I use asyncio" _all_ _the_ _time_.  So I'll expand on this section in a detail.

Reason #1 and #2 are correct, but I think we should really focus on making #1 comprehensive and clear:

* async/await makes all context switches visible; that makes it easy to spot race conditions and reason about your code (think about ORMs that can make 100s of queries to render one web page); you've likely seen https://glyph.twistedmatrix.com/2014/02/unyielding.html

* in general, all datastructures are safe for async (we cannot say same for threads);

* an async/await library means that it's safe to use it in concurrent async/await code (you can never be sure if some library is thread-safe, even if it claims that);

* language constructs like 'async for' and 'async with' enable structured concurrency;

And on #2:

* high-throughput IO or 1000s of long-living connections are only doable with asyncio

* if you don't need to scale your code right now but might need in near future investing in async/await is wise


>- How to run `async def` functions
>    - point out there are two different issues: (a) `async def` functions
>      can call other functions, and other `async def` functions using
>      `await`, but also, (b) how to "get started" with the first
>      `async def` function? Answer: run the event loop.

Just a quick note: I'd try to not mention the low-level loop APIs as long as possible (e.g. no loop.run_until_complete() etc).


- Dealing with concurrent functions
    - (This is maybe too similar to the new docs in the section
      https://docs.python.org/3/library/asyncio-task.html?highlight=asyncio%20run#coroutines-and-tasks)

Right, we'll need to update the asyncio-task.rst file.  I think we'll collapse first two section into one ("Coroutines" and "Awaitables" into "Awaitables") and link the tutorial from that new section.


> - Case Study: chat server/client (my proposal)
> [..]
>     - server uses streams API

Yay for streams!

> [..]
>     - client implementation has some options:

I never use tkinter myself :( I remember trying to use it and it didn't work on my macOS.  So I'd try to either:

* build a simple browser app (that would require us to implement HTTP 0.9 which can be fun);
* build a terminal app;
* use iPython repl to connect to our asyncio server (might end up being more complicated than the first two options).

----------
nosy: +Elvis.Pranskevichus

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

From report at bugs.python.org  Sat Sep 29 03:18:58 2018
From: report at bugs.python.org (Simon Sapin)
Date: Sat, 29 Sep 2018 07:18:58 +0000
Subject: [docs] [issue33698] `._pth` does not allow to populate `sys.path`
 with empty entry
In-Reply-To: <1527700361.05.0.682650639539.issue33698@psf.upfronthosting.co.za>
Message-ID: <1538205538.64.0.668975606942.issue33698@psf.upfronthosting.co.za>


Change by Simon Sapin <simon.sapin at exyr.org>:


----------
nosy: +ssapin

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

From report at bugs.python.org  Sat Sep 29 09:28:22 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:28:22 +0000
Subject: [docs] [issue34843] logging cookbook docs: remove 'recent' when
 referring to multiprocessing
Message-ID: <1538227702.53.0.545547206417.issue34843@psf.upfronthosting.co.za>


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

In the logging cookbook docs, the word 'recent' is used to describe versions of Python containing the multiprocessing module.  Since multiprocessing is 10 years old, I think it may be safe to remove the word 'recent'.

----------
assignee: docs at python
components: Documentation
messages: 326676
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: logging cookbook docs: remove 'recent' when referring to multiprocessing
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 29 09:30:46 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:30:46 +0000
Subject: [docs] [issue34843] logging cookbook docs: remove 'recent' when
 referring to multiprocessing
In-Reply-To: <1538227702.53.0.545547206417.issue34843@psf.upfronthosting.co.za>
Message-ID: <1538227846.98.0.668975606942.issue34843@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Sep 29 12:57:39 2018
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 29 Sep 2018 16:57:39 +0000
Subject: [docs] [issue13407] tarfile doesn't support multistream bzipped tar
 files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538240259.28.0.545547206417.issue13407@psf.upfronthosting.co.za>


Brian Curtin <brian at python.org> added the comment:


New changeset 8d3b0f49021e6cd25030a1eb979218cfceb44061 by Brian Curtin (Andr?s Delfino) in branch '2.7':
[2.7] bpo-13407: Mention that bz2/tarfile doesn't support multi-stream bzip2 files (GH-8428)
https://github.com/python/cpython/commit/8d3b0f49021e6cd25030a1eb979218cfceb44061


----------
nosy: +brian.curtin

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

From report at bugs.python.org  Sat Sep 29 22:03:51 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sun, 30 Sep 2018 02:03:51 +0000
Subject: [docs] [issue13407] tarfile doesn't support multistream bzipped tar
 files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538273030.85.0.545547206417.issue13407@psf.upfronthosting.co.za>


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

I believe this can be closed.

----------

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

From report at bugs.python.org  Sat Sep 29 22:04:09 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sun, 30 Sep 2018 02:04:09 +0000
Subject: [docs] [issue13407] tarfile doesn't support multistream bzipped tar
 files
In-Reply-To: <1321352961.33.0.0944615995053.issue13407@psf.upfronthosting.co.za>
Message-ID: <1538273049.91.0.668975606942.issue13407@psf.upfronthosting.co.za>


Change by Andr?s Delfino <adelfino at gmail.com>:


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

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

From report at bugs.python.org  Sat Sep 29 23:55:38 2018
From: report at bugs.python.org (Dan Snider)
Date: Sun, 30 Sep 2018 03:55:38 +0000
Subject: [docs] [issue34848] range.index only takes one argument when it's
 documented as taking the usual 3
Message-ID: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Unfortunately, it looks like there's no requirement for an abc.Sequence to implement the 3 argument form of seq.index, so I suppose this is technically just a documentation bug...

>>> range(5).index(2, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: index() takes exactly one argument (2 given)

>>> help(range.index)
Help on method_descriptor:

index(...)
    rangeobject.index(value, [start, [stop]]) -> integer -- return index of value.
    Raise ValueError if the value is not present.

----------
assignee: docs at python
components: Argument Clinic, Documentation
messages: 326701
nosy: bup, docs at python, larry
priority: normal
severity: normal
status: open
title: range.index only takes one argument when it's documented as taking the usual 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 30 02:02:51 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 06:02:51 +0000
Subject: [docs] [issue34848] range.index only takes one argument when it's
 documented as taking the usual 3
In-Reply-To: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>
Message-ID: <1538287371.87.0.545547206417.issue34848@psf.upfronthosting.co.za>


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

Thank you for your report Dan. It is easy to fix a docstring.

Related issues are issue28197 and issue31942.

----------
components:  -Argument Clinic
keywords: +easy (C)
nosy: +rhettinger, serhiy.storchaka -larry
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.8 -Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Sep 30 02:26:47 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 06:26:47 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538288807.06.0.545547206417.issue34476@psf.upfronthosting.co.za>


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

`asyncio.sleep()` always pauses the current task and switches execution to another one.
`asyncio.sleep(0)` has no special meaning (but it has internal optimization for the case).

Basically the same as `time.sleep(0)` for multithreaded program.

I doubt if we need to blow the documentation with all possible related details.

----------

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

From report at bugs.python.org  Sun Sep 30 02:58:10 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 30 Sep 2018 06:58:10 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538290690.92.0.545547206417.issue34476@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

The issue is because the current documentation *doesn't* say that "`asyncio.sleep()` always pauses the current task and switches execution to another one", it just says that it "blocks for _delay_ seconds".

With that description a perfectly valid implementation could be further optimized with:

    async def sleep(delay):
        if delay <= 0:
            return
        ...

In which case `await sleep(0)` would *not* cause a task switch. And this is not an unreasonable thing to expect because there are many other potentially-switching situations in asyncio that sometimes don't cause a switch, such as await `queue.get()` from a non-empty queue or await `await stream.readline()` from a socket stream that has a line to provide.

The user who wants to implement a "yield control to event loop" has to look at the source to find out how delay==0 is handled, and then they have to wonder if it's an implementation detail. https://github.com/python/asyncio/issues/284 states that the behavior is explicit and here to stay, but that promise has never made it into the actual documentation.

----------

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

From report at bugs.python.org  Sun Sep 30 03:46:33 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 07:46:33 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538293593.43.0.545547206417.issue34476@psf.upfronthosting.co.za>


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

Adding "`asyncio.sleep()` always pauses the current task and switches execution to another one" sounds totally reasonable to me (without mentioning zero `delay` special case).

Would you make a pull request?

----------

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

From report at bugs.python.org  Sun Sep 30 04:45:54 2018
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 30 Sep 2018 08:45:54 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538297154.62.0.668975606942.issue34476@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Sep 30 04:49:31 2018
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sun, 30 Sep 2018 08:49:31 +0000
Subject: [docs] [issue34476] asyncio.sleep(0) not documented
In-Reply-To: <1535035287.88.0.56676864532.issue34476@psf.upfronthosting.co.za>
Message-ID: <1538297371.15.0.545547206417.issue34476@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Agreed about the special case. Minor change suggestion:

    ``sleep()` always suspends the current task, allowing other tasks to run.

That is, replace "switches execution to another [task]" because there might not be other tasks or they might not be executable - the idea is to allow them to run. Also, replace "pause" with "suspend" (because when delay<=0 there is not really a discernible pause).

https://github.com/python/cpython/pull/9643

If you'd still prefer the previous wording, I'll amend the PR.

----------

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

From report at bugs.python.org  Sun Sep 30 16:54:25 2018
From: report at bugs.python.org (Dan Snider)
Date: Sun, 30 Sep 2018 20:54:25 +0000
Subject: [docs] [issue34848] range.index only takes one argument when it's
 documented as taking the usual 3
In-Reply-To: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>
Message-ID: <1538340865.05.0.545547206417.issue34848@psf.upfronthosting.co.za>


Dan Snider <mr.assume.away at gmail.com> added the comment:

So I also just happened to notice that the "documentation is wrong" for list, tuple, and collections.deque. They use use _PyEval_SliceIndexNotNone whch causes this:

>>> s = 'abcde'
>>> s.index('d', 0, None)
3
>>> [*s].index('d', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
    [*s].index('d', None)
TypeError: slice indices must be integers or have an __index__ method

In 3.6.0, that error message is:
    TypeError: slice indices must be integers or None or have an __index__ method

which means someone else was aware of this behavior and switched from _PyEval_SliceIndex to _PyEval_SliceIndexNotNone but didn't think these inconsistencies were inappropriate?

Anyway, I'll go ahead fix the docs later for accuracy's sake, but I'd much rather update operator.indexOf to use a new abstract api function: "PySequence_IndexOf" or some such, which is also capable of handling starting from the tail like str.rindex. 

If that's something that could be done, after I finish the Python prototype of this sequence ChainMap analog and rewrite it in C, I'll have made my own abstract sequence index function which I'd happily share.

----------

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

From report at bugs.python.org  Sun Sep 30 23:49:27 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Oct 2018 03:49:27 +0000
Subject: [docs] [issue34804] Repetition of 'for example' in documentation
In-Reply-To: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>
Message-ID: <1538365767.29.0.545547206417.issue34804@psf.upfronthosting.co.za>


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

Though stylistically odd, the repeated text is correct.  If Andrew feels like amending it, that would be nice; otherwise, I don't think it is worth the micro-edit.

----------
nosy: +rhettinger
priority: normal -> low

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

From judith.bennett at wilmunimail.org  Fri Sep 28 13:39:36 2018
From: judith.bennett at wilmunimail.org (Judith Bennett)
Date: Fri, 28 Sep 2018 17:39:36 -0000
Subject: [docs] Non-working Resources at dkerr.com
Message-ID: <CACFK9SsGf9ZgC_aWgrzd5CJOY6HoxKiobOLsnwg5nr4xXQrRXg@mail.gmail.com>

Good morning, hope you're doing great.
Not sure if you're the right person, but I was on your guys' website
dkerr.com and there are some links that didn't load.
I made a list of them - do you know who would be the best person to take
care of that and who should I send them to?

Thank you and have a beautiful day!


-- 
Judith Bennett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20180928/37d2b4cd/attachment-0001.html>