From report at bugs.python.org  Tue Nov  1 03:10:10 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 01 Nov 2016 07:10:10 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <1477984210.37.0.735670720254.issue28513@psf.upfronthosting.co.za>


SilentGhost added the comment:

> Apparently (haven?t tried myself) if you put ?.. program:: zipfile? before the :option: invocations, it changes the default context and you don?t need the <zipfile . . .> bit.

Yes, moving program directive just after "Command Line Interface" heading works fine.

----------

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

From report at bugs.python.org  Tue Nov  1 06:55:12 2016
From: report at bugs.python.org (armando mendoza)
Date: Tue, 01 Nov 2016 10:55:12 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <1477997712.7.0.256492153855.issue28513@psf.upfronthosting.co.za>


Changes by armando mendoza <amendoza0101 at gmail.com>:


----------
components: +XML

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

From report at bugs.python.org  Tue Nov  1 07:28:39 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 01 Nov 2016 11:28:39 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <1477999719.88.0.664430190374.issue28513@psf.upfronthosting.co.za>


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


----------
components:  -XML

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

From report at bugs.python.org  Tue Nov  1 13:20:14 2016
From: report at bugs.python.org (Florian Strzelecki)
Date: Tue, 01 Nov 2016 17:20:14 +0000
Subject: [docs] [issue28499] Logging module documentation needs a rework.
In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za>
Message-ID: <1478020814.27.0.927119044792.issue28499@psf.upfronthosting.co.za>


Florian Strzelecki added the comment:

Hi! Sorry for the delay.

I published my slides on speaker deck: https://speakerdeck.com/exirel/read-and-write-the-doc
It contains only my main ideas and key concepts, since I prefer to talk more than just read slides to the public. I hope Pycon FR's organizers will be able to upload videos soon - it'll need translation for non-French speaker, too.

Thanks for creating this issue and for all your comments. I'll try to talk more here, but I'm not sure how we should proceed - so let's start a conversation?

In my talk, I rant a bit about two documentations: Django's documentation, and Python Logging's documentation. Both have, in my opinion, an issue with their organization: the Django one tend to scatter information around multiple chapters, and the Logging one, albeit properly compacted, fail to quickly answer beginner's questions and advanced user's needs.

Don't get me wrong: there is a lot of content here. Most of the question one may ask have an answer, lying here or there. After all, I was able to use the Configure File Format, once I had read the reference documentation for `logging`, `logging.config`, both tutorials, and the cookbook. My point is: I value a lot this documentation, but my experience as a beginner wasn't that good, and my current experience as an advanced user could be improved.

I remember the first time I read the documentation. I was reading an application's source code that used a `logging.config.dictConfig`, and I couldn't understand how it worked. How does each level in loggers and handlers work? How to change the format of each log? Does it work in multiple threads? In multiple process? Why is there a `logging.getLogger('something')`? How does it know my configuration? How can I output logs in my console and still write them? Can I call `getLogger` before I configure anything?

Take the main page (https://docs.python.org/3.7/library/logging.html):

* Hard to find a "How to configure logging" link,
* No description of the logging flow (it can be found in the advanced tutorial),
* No example of quick usage (the first one is for `Logger.debug`, and that's not a generic one),
* The top-level function are documented at the end of the document, albeit they are the quickest way to use and understand `logging`
* The "See also" part (which provide easy access to more content) is far far away at the bottom of the document.

And I think there are many other small issues regarding content organization.

I think there are (at least) 2 ways to look at these:

* Rework the overall structure,
* Focus on example.

I didn't think a lot about a better structure, so something like that is just a quick draft:

* Introduction to logging (with short example)
* Logging usage (how logging works - the Advanced Tutorial talk a lot about that)
* Configuration (a separated chapter to describe file format, dict schema, and stuff)
* Module references (logging, logging.config, logging.handler, etc.)
* Cookbook & Tutorials

(Each part in a separated chapter/sub-chapter)

I also think that the documentation should be able to answer these questions:

* As a beginner, how do I start? How should I learn logging?
* As experienced, how do I jump directly to what I want to know? (config, format, etc.)
* As advanced, how do I extend logging in my application?

I don't think a beginner needs to know what a LogRecord is, but they'll need to know what keys to use in their formatter in their basicConfig/dictConfig. And an advanced dev shouldn't spend minutes to fetch the documentation to finally found how to use their own LogRecord object in their logger.

---

Welp. That's a lot of text for now. I'm still not sure how to help nor how to begin with that. I never tried to make a push request to Python, and I don't know if I should try to submit a diff or not. Also, there is so much more than just that (I didn't talk about the "focus on example" part).

Last but not least, thanks for your attention!

----------
nosy: +Florian Strzelecki

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

From report at bugs.python.org  Tue Nov  1 15:54:26 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 01 Nov 2016 19:54:26 +0000
Subject: [docs] [issue28499] Logging module documentation needs a rework.
In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za>
Message-ID: <1478030066.27.0.770192815865.issue28499@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'm not sure this issue tracker is the best place to have an extended discussion about documentation - perhaps we should move this to a mailing list such as python-list.

I'm not sure what you read first, but the logging documentation main page has a box marked "Important" right at the top, which says: "This page contains the API reference information. For tutorial information and discussion of more advanced topics, see ..." and then links to the basic and advanced tutorials and cookbook.

The basic tutorial starts with information on when to use logging (including links to the convenient-for-beginners logging.XXX() functions), discusses the different logging levels, and then gives a simple example:

import logging
logging.warning('Watch out!')  # will print a message to the console
logging.info('I told you so')  # will not print anything

So I don't see where your statement "No example of quick usage (the first one is for `Logger.debug`, and that's not a generic one)" comes from, nor "The top-level function are documented at the end of the document, albeit they are the quickest way to use and understand `logging`". Although they are *listed* low down, there are *links* to them very early in the basic tutorial - in the very first paragraph of "When to use logging".

With reference to your rough proposed structure,

"Introduction to logging (with short example)" - the beginning of the basic tutorial does this.

"Configuration (a separated chapter to describe file format, dict schema, and stuff)" - outline is described in the advanced tutorial, details are found in the specific page on the API reference for the logging.config module.

"Module references (logging, logging.config, logging.handler, etc.)" - this is as it is now.

"Cookbook & Tutorials" - these are separated from the reference documentation but otherwise seem to broadly follow what you're referring to here.

Bear in mind that opinions on (and reactions to) documentation are fairly subjective. For example, you seem to find the Django documentation problematic, but I don't, and it's widely regarded as one of the best documentation sets for any Python project, and has contributed a lot to Django's success.

If you really want to take this on, I don't think a patch is the best way to proceed, because there will be a *lot* of changes due to things moving around, etc. and one would need to build the documentation from the changed sources to get the full effect of the changes, unlike when reviewing source code. Instead, you could create a project on ReadTheDocs which takes copies of the logging documentation source pages and changes them to provide your alternative vision of how the documentation should look. This will allow easier side-by-side comparison for anyone who wants to review and compare the alternatives. If it's generally felt (e.g. by people on python-dev) that the new version is better than the current, then bringing the changes back shouldn't be too hard. What do you think?

----------

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

From report at bugs.python.org  Tue Nov  1 23:55:59 2016
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 02 Nov 2016 03:55:59 +0000
Subject: [docs] [issue27779] Sync-up docstrings in C version of the the
 decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1478058959.41.0.841884646105.issue27779@psf.upfronthosting.co.za>


Lisa Roach added the comment:

Thanks for taking a look Stefan! I agree, it is definitely not as easy as it sounds.

Your review and comments are helpful, I will make adjustments to the docstrings. 

If you want, I can continue to try to sync-up the docstrings and submit them for you and Raymond to review? I've been checking the docstrings against the general decimal specification: http://speleotrove.com/decimal/decarith.html, and with additional eyes on readability and best practices hopefully we can write updated, synchronized docstrings.

----------

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

From report at bugs.python.org  Wed Nov  2 05:32:23 2016
From: report at bugs.python.org (ChrisRands)
Date: Wed, 02 Nov 2016 09:32:23 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
Message-ID: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>


New submission from ChrisRands:

In Python 3 and 2 docs https://docs.python.org/3.5/tutorial/datastructures.html, list.index only mentions the first argument:


list.index(x)

    Return the index in the list of the first item whose value is x. It is an error if there is no such item.

However, in reality list.index can take further arguments:

index(...)
    L.index(value, [start, [stop]]) -> integer -- return first index of value.
    Raises ValueError if the value is not present.

----------
assignee: docs at python
components: Documentation
messages: 279913
nosy: ChrisRands, docs at python
priority: normal
severity: normal
status: open
title: list.index documentation missing start and stop arguments

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

From report at bugs.python.org  Wed Nov  2 05:47:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Nov 2016 09:47:19 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <1478080039.39.0.07089133721.issue28513@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Wed Nov  2 06:14:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Nov 2016 10:14:10 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <20161102101407.3656.24330.7B1DA08B@psf.io>


Roundup Robot added the comment:

New changeset feb6e8678512 by Serhiy Storchaka in branch '2.7':
Issue #28513: Documented command-line interface of zipfile.
https://hg.python.org/cpython/rev/feb6e8678512

New changeset b51bf32defb1 by Serhiy Storchaka in branch '3.5':
Issue #28513: Documented command-line interface of zipfile.
https://hg.python.org/cpython/rev/b51bf32defb1

New changeset 843538a4094b by Serhiy Storchaka in branch '3.6':
Issue #28513: Documented command-line interface of zipfile.
https://hg.python.org/cpython/rev/843538a4094b

New changeset 0c8ffa562f3a by Serhiy Storchaka in branch 'default':
Issue #28513: Documented command-line interface of zipfile.
https://hg.python.org/cpython/rev/0c8ffa562f3a

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

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

From report at bugs.python.org  Wed Nov  2 06:16:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Nov 2016 10:16:03 +0000
Subject: [docs] [issue28513] Document zipfile CLI
In-Reply-To: <1477218977.25.0.95260452294.issue28513@psf.upfronthosting.co.za>
Message-ID: <1478081763.73.0.139386930797.issue28513@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Applied both Martin's suggestion. Thank you all!

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

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

From report at bugs.python.org  Wed Nov  2 08:47:45 2016
From: report at bugs.python.org (Florian Strzelecki)
Date: Wed, 02 Nov 2016 12:47:45 +0000
Subject: [docs] [issue28499] Logging module documentation needs a rework.
In-Reply-To: <1477070357.17.0.711656351025.issue28499@psf.upfronthosting.co.za>
Message-ID: <1478090865.67.0.718004801358.issue28499@psf.upfronthosting.co.za>


Florian Strzelecki added the comment:

A project published on RTD looks like a very good idea. I'll give it a try!

Thanks for your feedback. I think we don't have the same opinion on how to organize parts and details, so it's on me to show something worth our times.

> you seem to find the Django documentation problematic

Yes, yet I found it to be one of the best out there too. I can enjoy something and still be critical about it. Even if I'm critical of the current logging documentation, there are plenty of good things here to keep, and if we want to compare, it's still far better than most documentation out there.

----------

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

From report at bugs.python.org  Wed Nov  2 09:05:58 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 02 Nov 2016 13:05:58 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478091958.92.0.216323335788.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Attached is the patch to update the documentation.

Please review. Thanks :)

----------
keywords: +patch
nosy: +Mariatta
Added file: http://bugs.python.org/file45313/issue28587.patch

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

From report at bugs.python.org  Wed Nov  2 09:18:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Nov 2016 13:18:16 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478092696.96.0.356019557958.issue28587@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  2 09:24:19 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 02 Nov 2016 13:24:19 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478093058.96.0.197708384088.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hmm, I did not mean to replace the documentation example like that.
Here's another update.

----------
Added file: http://bugs.python.org/file45314/issue28587.patch

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

From chrisrands0 at gmail.com  Wed Nov  2 09:28:21 2016
From: chrisrands0 at gmail.com (chrisrands0 at gmail.com)
Date: Wed, 02 Nov 2016 13:28:21 -0000
Subject: [docs] list.index documentation missing start and stop arguments
 (issue 28587)
Message-ID: <20161102132821.17666.35851@psf.upfronthosting.co.za>

Reviewers: ,

Message:
Thanks to Mariatta for the patch, which addresses the issue, so I think
it can be applied to the Python 3 and 2 documentation. One point, I do
not know when the start and stop arguments were added to list.count (or
if they always existed). I have only tested them in Python2.7 and
Python3.5.



Please review this at http://bugs.python.org/review/28587/

Affected files:
  Doc/tutorial/datastructures.rst


diff -r 0c8ffa562f3a Doc/tutorial/datastructures.rst
--- a/Doc/tutorial/datastructures.rst	Wed Nov 02 12:13:48 2016 +0200
+++ b/Doc/tutorial/datastructures.rst	Wed Nov 02 06:04:14 2016 -0700
@@ -60,11 +60,12 @@
    Remove all items from the list.  Equivalent to ``del a[:]``.
 
 
-.. method:: list.index(x)
+.. method:: list.index(x[, start[, end]])
    :noindex:
 
    Return the index in the list of the first item whose value is *x*. It is an
-   error if there is no such item.
+   error if there is no such item.  Optional arguments ``start`` and ``end``
+   are interpreted as in slice notation.
 
 
 .. method:: list.count(x)
@@ -101,8 +102,8 @@
    >>> a.append(333)
    >>> a
    [66.25, 333, -1, 333, 1, 1234.5, 333]
-   >>> a.index(333)
-   1
+   >>> a.index(333, 2)
+   3
    >>> a.remove(333)
    >>> a
    [66.25, -1, 333, 1, 1234.5, 333]



From mariatta.wijaya at gmail.com  Wed Nov  2 09:46:05 2016
From: mariatta.wijaya at gmail.com (mariatta.wijaya at gmail.com)
Date: Wed, 02 Nov 2016 13:46:05 -0000
Subject: [docs] list.index documentation missing start and stop
 arguments (issue 28587)
Message-ID: <20161102134605.32477.31743@psf.upfronthosting.co.za>

On 2016/11/02 14:28:21, ChrisRands wrote:
> Thanks to Mariatta for the patch, which addresses the issue, so I
think it can
> be applied to the Python 3 and 2 documentation. One point, I do not
know when
> the start and stop arguments were added to list.count (or if they
always
> existed). I have only tested them in Python2.7 and Python3.5.

Thanks ChrisRands :)
I'm a bit confused with your comment about list.count. list.count does
not take start, stop arguments.
Perhaps you are thinking about str.count which has been documented
correctly
https://docs.python.org/2.7/library/stdtypes.html#str.count

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

From chrisrands0 at gmail.com  Wed Nov  2 10:04:53 2016
From: chrisrands0 at gmail.com (chrisrands0 at gmail.com)
Date: Wed, 02 Nov 2016 14:04:53 -0000
Subject: [docs] list.index documentation missing start and stop
 arguments (issue 28587)
Message-ID: <20161102140453.17666.92555@psf.upfronthosting.co.za>

Sorry I meant list.index and not list.count. Apologies for my mistake.

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

From report at bugs.python.org  Wed Nov  2 11:14:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Nov 2016 15:14:08 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <1478099648.74.0.568744003376.issue28590@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  2 11:21:22 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 02 Nov 2016 15:21:22 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <1478100082.87.0.640767894322.issue28590@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm currently working on an update to PEP-498 to address this. I hope to have it completed after a sprint this weekend.

----------

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

From chrisrands0 at gmail.com  Wed Nov  2 10:00:59 2016
From: chrisrands0 at gmail.com (Chris Rands)
Date: Wed, 2 Nov 2016 15:00:59 +0100
Subject: [docs] list.index documentation missing start and stop
 arguments (issue 28587)
In-Reply-To: <20161102134605.32477.31743@psf.upfronthosting.co.za>
References: <20161102134605.32477.31743@psf.upfronthosting.co.za>
Message-ID: <CAHyWismS6igcYB7PPNV3EcQdLsy4Lu-RvkRjEnuhN4baD0+znw@mail.gmail.com>

Sorry I meant list.index of course not list.count. The issue remains for
list.index. Sorry for my mistake.

Chris

On 2 November 2016 at 14:46, <mariatta.wijaya at gmail.com> wrote:

> On 2016/11/02 14:28:21, ChrisRands wrote:
> > Thanks to Mariatta for the patch, which addresses the issue, so I
> think it can
> > be applied to the Python 3 and 2 documentation. One point, I do not
> know when
> > the start and stop arguments were added to list.count (or if they
> always
> > existed). I have only tested them in Python2.7 and Python3.5.
>
> Thanks ChrisRands :)
> I'm a bit confused with your comment about list.count. list.count does
> not take start, stop arguments.
> Perhaps you are thinking about str.count which has been documented
> correctly
> https://docs.python.org/2.7/library/stdtypes.html#str.count
>
> http://bugs.python.org/review/28587/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161102/5c23a8cd/attachment.html>

From freely.given.org at gmail.com  Wed Nov  2 15:41:13 2016
From: freely.given.org at gmail.com (Freely-Given.org)
Date: Thu, 3 Nov 2016 08:41:13 +1300
Subject: [docs] Small grammatical error
Message-ID: <20fc4858-2a60-db20-2411-247007edd4d7@gmail.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/717f8cbf/attachment.html>

From report at bugs.python.org  Wed Nov  2 16:53:11 2016
From: report at bugs.python.org (Pierre Bousquie)
Date: Wed, 02 Nov 2016 20:53:11 +0000
Subject: [docs] [issue28499] Logging module documentation needs a rework.
In-Reply-To: <1478090865.67.0.718004801358.issue28499@psf.upfronthosting.co.za>
Message-ID: <CAAqRmC984d=36mrAHS8yoQeGzS4fTZK0o5Kw1nXVcxUwvbUcmA@mail.gmail.com>


Pierre Bousquie added the comment:

Thank you Vinay for your feedback.
RTD seems a very good start to me.

Florian thanks for joining :). I'm not leaving you alone on this!
I don't mind closing the "bug" request. It was mainly for St?phane Wirtel
:)... but it's still "committing" :)

2016-11-02 13:47 GMT+01:00 Florian Strzelecki <report at bugs.python.org>:

>
> Florian Strzelecki added the comment:
>
> A project published on RTD looks like a very good idea. I'll give it a try!
>
> Thanks for your feedback. I think we don't have the same opinion on how to
> organize parts and details, so it's on me to show something worth our times.
>
> > you seem to find the Django documentation problematic
>
> Yes, yet I found it to be one of the best out there too. I can enjoy
> something and still be critical about it. Even if I'm critical of the
> current logging documentation, there are plenty of good things here to
> keep, and if we want to compare, it's still far better than most
> documentation out there.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28499>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Nov  2 17:22:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Nov 2016 21:22:34 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <1478121754.8.0.697123972532.issue28088@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LGTM too. Can someone add this to the asyncio docs (starting at the 3.5 branch please)?

----------

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

From report at bugs.python.org  Wed Nov  2 23:31:08 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 03 Nov 2016 03:31:08 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1478143868.54.0.609949359743.issue26980@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi, I updated the documentation explaining the path argument.

Let me know if this works. Thanks :)

----------
keywords: +patch
nosy: +Mariatta
Added file: http://bugs.python.org/file45329/issue26980.patch

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

From report at bugs.python.org  Thu Nov  3 07:46:08 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Nov 2016 11:46:08 +0000
Subject: [docs] [issue27779] Sync-up docstrings in C version of the the
 decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1478173567.95.0.254318782065.issue27779@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Okay great.  I think it's probably best to produce an initial patch with the verbatim Python docstrings (you can of course address the comments that I already made), then we mark the passages that are clearly not valid for _decimal or outdated for _pydecimal, then we go for extra clarity.

----------

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

From report at bugs.python.org  Thu Nov  3 07:46:53 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Nov 2016 11:46:53 +0000
Subject: [docs] [issue27779] Sync-up docstrings in C version of the the
 decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1478173613.91.0.827150722383.issue27779@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
keywords:  -easy, patch

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

From report at bugs.python.org  Thu Nov  3 07:47:10 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 03 Nov 2016 11:47:10 +0000
Subject: [docs] [issue27779] Sync-up docstrings in C version of the the
 decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1478173630.6.0.491098627116.issue27779@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


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

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

From report at bugs.python.org  Thu Nov  3 09:43:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Nov 2016 13:43:31 +0000
Subject: [docs] [issue28597] f-string behavior is conflicting with its
 documentation
In-Reply-To: <1478179854.9.0.231732113134.issue28597@psf.upfronthosting.co.za>
Message-ID: <1478180611.29.0.913045477975.issue28597@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, eric.smith
type:  -> behavior
versions: +Python 3.7

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

From report at bugs.python.org  Thu Nov  3 09:47:14 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Nov 2016 13:47:14 +0000
Subject: [docs] [issue28597] f-string behavior is conflicting with its
 documentation
In-Reply-To: <1478179854.9.0.231732113134.issue28597@psf.upfronthosting.co.za>
Message-ID: <1478180834.5.0.401541919417.issue28597@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This is a duplicate of issue 28590.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> fstring's '{' from escape sequences does not start an expression

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

From report at bugs.python.org  Thu Nov  3 17:15:17 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Nov 2016 21:15:17 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1478207717.33.0.583717070907.issue26980@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

LGTM, will apply shortly.

----------

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

From report at bugs.python.org  Thu Nov  3 17:18:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Nov 2016 21:18:50 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <20161103211847.7195.36366.D35C60A1@psf.io>


Roundup Robot added the comment:

New changeset b97b0201c2f4 by Guido van Rossum in branch '3.5':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta.
https://hg.python.org/cpython/rev/b97b0201c2f4

New changeset ddbba4739ef4 by Guido van Rossum in branch '3.6':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.5->3.6)
https://hg.python.org/cpython/rev/ddbba4739ef4

New changeset d6f4c1b864e6 by Guido van Rossum in branch 'default':
Issue #26980: Improve docs for create_unix_connection(). By Mariatta. (3.6->3.7)
https://hg.python.org/cpython/rev/d6f4c1b864e6

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

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

From report at bugs.python.org  Thu Nov  3 17:19:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 03 Nov 2016 21:19:32 +0000
Subject: [docs] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1478207972.63.0.761329665964.issue26980@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  4 03:35:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2016 07:35:42 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <20161104073538.7662.61338.7AE381BF@psf.io>


Roundup Robot added the comment:

New changeset 3f5af4a25995 by INADA Naoki in branch '3.5':
Issue #28088: Document Transport.set_protocol and get_protocol
https://hg.python.org/cpython/rev/3f5af4a25995

New changeset a5e52b7be71f by INADA Naoki in branch '3.6':
Issue #28088: Document Transport.set_protocol and get_protocol.
https://hg.python.org/cpython/rev/a5e52b7be71f

New changeset a0299574a733 by INADA Naoki in branch 'default':
Issue #28088: Document Transport.set_protocol and get_protocol.
https://hg.python.org/cpython/rev/a0299574a733

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

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

From report at bugs.python.org  Fri Nov  4 03:36:18 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 04 Nov 2016 07:36:18 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <1478244978.76.0.734564218846.issue28088@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov  4 13:02:34 2016
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 04 Nov 2016 17:02:34 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
Message-ID: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>


New submission from Jim Jewett:

One commonly needed string transformation is stripping out certain characters (or only keeping certain characters).  This is common enough that it might be worth a dedicated method, except, that, as Stephen J. Turnbull wrote in https://mail.python.org/pipermail/python-ideas/2016-November/043501.html

"""
So really translate with defaultdict is a specialized loop that
marries an algorithmic body (which could do things like look up the
original script or other character properties to decide on the
replacement for the generic case) with a (usually "small") table of
exceptions.  That seems like inspired design to me.
"""

Alas, while inspired, it isn't obvious to someone who isn't yet used to the power of python custom classes.

The documentation (such as https://docs.python.org/3/library/stdtypes.html?highlight=translate#str.translate ) should include such an example.

One possible example would be a defaultdict that says to discard any characters except lower case ASCII lettersI.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 280061
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: str.translate needs a mapping example
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Nov  4 14:20:24 2016
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 04 Nov 2016 18:20:24 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1478283623.98.0.774355713545.issue28612@psf.upfronthosting.co.za>


Jim Jewett added the comment:

https://mail.python.org/pipermail/python-ideas/2016-November/043539.html by Chris Barker points out that a custom object (which doesn't ever store the missing "keys") may be better still... though I'm not sure it is better enough to complicate the docs.

----------

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

From report at bugs.python.org  Fri Nov  4 15:04:44 2016
From: report at bugs.python.org (airwin)
Date: Fri, 04 Nov 2016 19:04:44 +0000
Subject: [docs] [issue28614] Slice limit documentation is incorrect
Message-ID: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>


New submission from airwin:

Note 5 (at <https://docs.python.org/2/library/stdtypes.html#sequence-types-str-unicode-list-tuple-bytearray-buffer-xrange> for Python 2 and at <https://docs.python.org/3/library/stdtypes.html#common-sequence-operations> for Python 3) concerning s[i:j:k] (the slice of s from i to j with step k) contains the following two sentences:

"The slice of s from i to j with step k is defined as the sequence of items with index x = i + n*k such that 0 <= n < (j-i)/k. In other words, the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)."

That limit, "(j-i)/k" is demonstrably wrong when the integer division has a non-zero remainder.  For example, for i=0, j=3, and k=2, n must be less than int(3/2) = 1 (i.e., the slice only has one element) according to that limit, but in fact the slice has two elements in agreement with the second sentence and which can be seen from the following python (2 or 3) code example:

>>> x = [0,1,2,3,4,5]
>>> x[0:3:2]
[0, 2]

The following Python result is also instructive for negative steps.

>>> y=[5,4,3,2,1,0]
>>> y[-1:-4:-2]
[0, 2]

For this case as well the result is consistent with the second sentence of the documentation but inconsistent with the first sentence since according to that limit = int((len-4 - (len-1))/-2) = int(3/2) = 1 implying only one element in the slice in contradiction to the above result.

Therefore, I suggest removing the incorrect mathematical limit "(j-i)/k" from note 5 by replacing the above two sentences as follows:

"The slice of s from i to j with positive or negative step k is defined as the sequence of items with index x = i + n*k such that the indices are i, i+k, i+2*k, i+3*k and so on, stopping when j is reached (but never including j)."

Alternatively, one could replace the current incorrect limit by the correct mathmatical expression.  My guess is the limit should be "(j-i)/k" when there is a zero remainder for that division, and "(j-i)/k + 1" when there is a non-zero remainder.  That limit works for the above two examples, but I don't know how to prove that in general for this integer limit case.  Furthermore, even if somebody else can provide that proof, I still think the above single sentence documents the slice limits exactly, is simpler, and therefore is preferred.

N.B. I am formally reporting this issue as a Python 3 bug but as shown above the same two sentences occur in the Python 2 documentation so when this bug is fixed for the Python 3 documentation it should also be consistently fixed for Python 2.

----------
assignee: docs at python
components: Documentation
messages: 280068
nosy: airwin, docs at python
priority: normal
severity: normal
status: open
title: Slice limit documentation is incorrect
versions: Python 3.7

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

From report at bugs.python.org  Fri Nov  4 15:09:32 2016
From: report at bugs.python.org (David.Johnston)
Date: Fri, 04 Nov 2016 19:09:32 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
Message-ID: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>


New submission from David.Johnston:

Section 5.4: Numeric Types

Second paragraph reads: 
Appending 'j' or 'J' to a numeric literal yields a complex number with a zero real part.

After reading the table following the paragraphs I thought that the sentence needed revised to the following:
Appending 'j' or 'J' to a numeric literal yields a complex number with a zero imaginary part.

Table in same section for complex(re, im) indicates possible required doc change.

But after testing the use of J and complex I see there is no error here, but perhaps a little better clarification would help others reading the information without access to an editor to test against.

----------
assignee: docs at python
components: Documentation
messages: 280069
nosy: David.Johnston, docs at python
priority: normal
severity: normal
status: open
title: Document clarification: Section 5.4 Complex Number

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

From report at bugs.python.org  Fri Nov  4 15:12:27 2016
From: report at bugs.python.org (Chris Barker)
Date: Fri, 04 Nov 2016 19:12:27 +0000
Subject: [docs] [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1478286747.38.0.731751607278.issue28612@psf.upfronthosting.co.za>


Chris Barker added the comment:

Agreed:

the custom dict type would be nice for a recipe or blog post or...

but not for the docs.

I'll note that the other trick to this recipe is that you need to know to use lambda to make a "None factory" for defaultdict -- though maybe that's a ToDo for the defaultdict docs...

----------
nosy: +ChrisBarker

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

From report at bugs.python.org  Fri Nov  4 15:17:58 2016
From: report at bugs.python.org (Anish Tambe)
Date: Fri, 04 Nov 2016 19:17:58 +0000
Subject: [docs] [issue28616] sys.version_info.releaselevel - 'final' or
 'release'
Message-ID: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za>


New submission from Anish Tambe:

help(sys.version_info) suggests releaselevel is one among - 

 |  releaselevel
 |      'alpha', 'beta', 'candidate', or 'release'

Notice that the last one is 'release'.

But the implementation says current value is - 'final'.

$ python
Python 2.7.12 (default, Oct 11 2016, 05:24:00) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version_info
sys.version_info(major=2, minor=7, micro=12, releaselevel='final', serial=0)
>>> 


$ python3
Python 3.5.2 (default, Oct 11 2016, 05:05:28) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.version_info
sys.version_info(major=3, minor=5, micro=2, releaselevel='final', serial=0)
>>> 


The documentation (https://docs.python.org/3/library/sys.html#sys.version_info or Doc/library/sys.rst) agrees with the implementation.

The tests also agree with the implementation. 
grep for releaselevel and see - 
Lib/test/test_sys.py:504:        self.assertIn(vi.releaselevel, ("alpha", "beta", "candidate", "final"))

Hence, submitting a patch to change the help documentaion to reflect the correct value for releaselevel.

[Motivation - I tried to print a warning to the user in case my app was not being run on a final release, and I tried to do that by equating releaselevel with 'release' as the help suggested.]

----------
assignee: docs at python
components: Documentation
files: releaselevel.patch
keywords: patch
messages: 280071
nosy: anish.tambe, docs at python
priority: normal
severity: normal
status: open
title: sys.version_info.releaselevel - 'final' or 'release'
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45356/releaselevel.patch

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

From report at bugs.python.org  Fri Nov  4 15:29:16 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Nov 2016 19:29:16 +0000
Subject: [docs] [issue28614] Slice limit documentation is incorrect
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478287756.92.0.145666388396.issue28614@psf.upfronthosting.co.za>


R. David Murray added the comment:

My guess is that the formula is not using integer division.  There are two elements, n=0, and n=1.  1 is less than 1.5.  In python2 it would be a natural assumption that that formula was referring to python2 division, and that should be clarified if I'm right.

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

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

From report at bugs.python.org  Fri Nov  4 15:38:57 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Nov 2016 19:38:57 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478288337.68.0.552673018541.issue28615@psf.upfronthosting.co.za>


R. David Murray added the comment:

For anyone who wants to work on this: this is 5.4 of the python2.7 docs.  The wording in the python3 docs (https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex) is much clearer, if someone wants to prepare a backport patch.

----------
keywords: +easy
nosy: +r.david.murray
stage:  -> needs patch
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Fri Nov  4 16:13:31 2016
From: report at bugs.python.org (airwin)
Date: Fri, 04 Nov 2016 20:13:31 +0000
Subject: [docs] [issue28614] Slice limit documentation is incorrect
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478290411.43.0.465418337088.issue28614@psf.upfronthosting.co.za>


airwin added the comment:

You can easily prove the limit is correct for real numbers.  So I would be willing to accept as a resolution of this issue that the type of division that is going on here is real.  However, that is a bit disquieting since if you try a real slice index you get "TypeError: slice indices must be integers or None or have an __index__ method". Thus, m < real limit test is a comparison of an integer and real which implies m gets changed to real before the comparison. Which obviously gives the correct result in the 1.5 case, but in general I dislike real comparisons where the distinction between < and <=, for example, can get blurred because of potential roundoff issues with reals.  So I think my suggested one-sentence resolution to the issue is better then updating the documentation to clarify what kind of division is occurring in the limit.

----------

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

From report at bugs.python.org  Fri Nov  4 16:30:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Nov 2016 20:30:22 +0000
Subject: [docs] [issue28614] Slice limit documentation is incorrect
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478291422.39.0.52298988518.issue28614@psf.upfronthosting.co.za>


R. David Murray added the comment:

The formula is documenting the behavior, not the implementation.  So the formula is a mathematical formula that assumes infinite precision, not a floating point calculation.  I always thought that was clear by context and phrasing, but perhaps I'm wrong.

----------

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

From report at bugs.python.org  Fri Nov  4 16:36:00 2016
From: report at bugs.python.org (wim glenn)
Date: Fri, 04 Nov 2016 20:36:00 +0000
Subject: [docs] [issue28617] Why isn't "in" called a comparison operation?
Message-ID: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>


New submission from wim glenn:

Regarding 

    https://docs.python.org/3/library/stdtypes.html#comparisons

There is a line at the bottom claiming:

> Two more operations with the same syntactic priority, in and not in, are supported only by sequence types (below).

The claim is incorrect because `in` and `not in` are also supported by non-sequence types such as sets, mappings, etc for membership testing.

Is there any good reason why we don't include them in the table of comparison operations, and say that there are ten comparison operations in python?  They do support comparison chaining in the same way: 

    >>> 'x' in 'xy' in 'xyz'
    True
    >>> 0 in {0} in [{0}]
    True

----------
assignee: docs at python
components: Documentation
files: patch.diff
keywords: patch
messages: 280080
nosy: docs at python, wim.glenn
priority: normal
severity: normal
status: open
title: Why isn't "in" called a comparison operation?
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45359/patch.diff

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

From report at bugs.python.org  Fri Nov  4 16:56:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Nov 2016 20:56:44 +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: <1478293004.11.0.645195205089.issue28617@psf.upfronthosting.co.za>


R. David Murray added the comment:

It should really say "only by types that support iteration".  They are not comparison operations, they are containment predicates.

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

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

From report at bugs.python.org  Fri Nov  4 17:00:21 2016
From: report at bugs.python.org (wim glenn)
Date: Fri, 04 Nov 2016 21:00:21 +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: <1478293221.06.0.672372925414.issue28617@psf.upfronthosting.co.za>


wim glenn added the comment:

Well, that wouldn't be true either.  Because you can easily implement objects which support membership tests but don't support iteration.

----------

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

From report at bugs.python.org  Fri Nov  4 17:02:00 2016
From: report at bugs.python.org (wim glenn)
Date: Fri, 04 Nov 2016 21:02: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: <1478293320.19.0.0507614526588.issue28617@psf.upfronthosting.co.za>


wim glenn added the comment:

I want to add that the grammar explicitly mentions them as comparisons

    https://docs.python.org/3/reference/grammar.html

And they are also listed in the comparisons section of the expressions documentation

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

So the docs seem to be contradicting themselves here.

----------

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

From report at bugs.python.org  Fri Nov  4 17:08:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Nov 2016 21:08:44 +0000
Subject: [docs] [issue28616] sys.version_info.releaselevel - 'final' or
 'release'
In-Reply-To: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za>
Message-ID: <20161104210841.7144.3998.0C94896E@psf.io>


Roundup Robot added the comment:

New changeset 0b4bcd954554 by Ned Deily in branch '2.7':
Issue #28616: Correct help for sys.version_info releaselevel component.
https://hg.python.org/cpython/rev/0b4bcd954554

New changeset 1390bde4b768 by Ned Deily in branch '3.5':
Issue #28616: Correct help for sys.version_info releaselevel component.
https://hg.python.org/cpython/rev/1390bde4b768

New changeset 048870daf397 by Ned Deily in branch '3.6':
Issue #28616: merge from 3.5
https://hg.python.org/cpython/rev/048870daf397

New changeset 87d76ce01217 by Ned Deily in branch 'default':
Issue #28616: merge from 3.6
https://hg.python.org/cpython/rev/87d76ce01217

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

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

From report at bugs.python.org  Fri Nov  4 17:10:17 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 04 Nov 2016 21:10:17 +0000
Subject: [docs] [issue28616] sys.version_info.releaselevel - 'final' or
 'release'
In-Reply-To: <1478287078.75.0.465203808408.issue28616@psf.upfronthosting.co.za>
Message-ID: <1478293817.42.0.703512110004.issue28616@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the patch!

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

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

From report at bugs.python.org  Fri Nov  4 17:11:43 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Nov 2016 21:11:43 +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: <1478293903.43.0.0831854835326.issue28617@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

At a grammar and implementation level, the "in" and "not in" operators are treated like comparisons (same precedence and opcodes), but at a semantic level, I concur with David Murray and don't think of these as being comparisons at all.   Accordingly, I prefer the current presentation
and agree with David that the note should be revised to say "only by types that support iteration".

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

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

From report at bugs.python.org  Fri Nov  4 18:08:35 2016
From: report at bugs.python.org (wim glenn)
Date: Fri, 04 Nov 2016 22:08:35 +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: <1478297315.93.0.153424004861.issue28617@psf.upfronthosting.co.za>


wim glenn added the comment:

Perhaps it's better to call a spade a spade here - if they're implemented as comparisons, then why not document them as comparisons?

A colleague has mentioned one point that sets `in` and `not in` apart from the other comparisons in the table: comparisons are generally made between objects of the same type (with the exception of numbers).  But membership "comparisons" are made between different types (with the exception of substring checks).  

Here is an alternate patch which leaves the table alone, but corrects the inaccuracy in the note.

----------
Added file: http://bugs.python.org/file45360/newpatch.diff

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

From report at bugs.python.org  Fri Nov  4 18:17:24 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Nov 2016 22:17:24 +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: <1478297844.51.0.465330327613.issue28617@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

"in" and "not in" are not comparisons, regardless of implementation mechanics (which could change).

They aren't really dependent on iteration, though they often correlate with iteration.

I'd rather see them described as "containment tests" or something similar.

----------
nosy: +fdrake

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

From report at bugs.python.org  Sat Nov  5 23:17:01 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Nov 2016 03:17:01 +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: <1478402221.68.0.739845117949.issue28617@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

newpatch.diff looks fine.

----------

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

From report at bugs.python.org  Sun Nov  6 07:55:48 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 06 Nov 2016 12:55:48 +0000
Subject: [docs] [issue28543] Incomplete fast path codecs aliases in codecs
 doc
In-Reply-To: <1477578000.23.0.835433953777.issue28543@psf.upfronthosting.co.za>
Message-ID: <1478436948.66.0.563696968239.issue28543@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 28393.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Update encoding lookup docs wrt #27938
type: enhancement -> behavior

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

From report at bugs.python.org  Sun Nov  6 10:45:57 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Nov 2016 15:45:57 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <1478447157.26.0.437226831382.issue28590@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've got a patch ready for this and will be applying it shortly after we update the spec.

----------
assignee: docs at python -> jason.coombs
nosy: +jason.coombs

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

From report at bugs.python.org  Sun Nov  6 11:10:37 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Nov 2016 16:10:37 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <1478448637.07.0.548823447952.issue28590@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

The reason that those test_no_escapes_for_braces assertions pass is because they're only dealing with opening curly braces and in an f-string, they're treated as literal opening braces.

In the example you've given, the error occurs when the f-string handler encounters the closing curly brace without an opening one. It's the same as if you had written:

    >>> f'{{4*10}'
    SyntaxError: f-string: single '}' is not allowed

I will add a test to capture this specific case (backslash-escaped unicode opening bracken).

----------

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

From bbayles at gmail.com  Sat Nov  5 16:05:09 2016
From: bbayles at gmail.com (Bo Bayles)
Date: Sat, 5 Nov 2016 15:05:09 -0500
Subject: [docs] Probable mistake in itertools docs
Message-ID: <CALqAb4zTYByUy+U5Ab6F6b-4CfopXUYdr3TrtQTwN04uNeaumw@mail.gmail.com>

The docs for the itertools module (Python 2.7 and 3.5 at least) start with
a section header and then a table with four columns: Iterator, Arguments,
Results, Example.

The first two sections fit this pattern. However, the third section,
Combinatoric Generators, only has three columns in its table. The Example
column is missing. Furthermore, the values in last four rows don't match
their column header.

It seems like the last four rows should have their values combined and
placed in an Example column like the rest.

Hope that makes sense. Many thanks!
-Bo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161105/32566cf8/attachment.html>

From jgwood at jimwellscad.org  Thu Nov  3 10:53:22 2016
From: jgwood at jimwellscad.org (Juliette Wood)
Date: Thu, 3 Nov 2016 09:53:22 -0500
Subject: [docs] PythonBug
Message-ID: <000301d235e2$06e297c0$14a7c740$@jimwellscad.org>



Hello,

I registered to report a bug but haven't received a confirmation email yet.
I saw that there is a solution, but the solution didn't work for me or I
just need better instructions to solve the problem. 

When I go to install Python 3.5.2 for Windows 10, the message comes up 'The
TARGETDIR variable ust be provided when invoking this installer.' When I
followed the instructions provided, it said that it couldn't the program to
install. Please help and point me in the direction of a place where I can
see step by step instructions to install it. I'm not a programmer or IT
person. I'm learning Python. Thanks for your help. I'm including a screen
shot and log file.

Regards,

Juliette

 

Juliette Wood

Jim Wells County Appraisal District

Mapping/Researcher

361-668-9656  ext. 14

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/c9a36d89/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4222 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/c9a36d89/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.GIF
Type: image/gif
Size: 357515 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/c9a36d89/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Python 3.5.2 (32-bit)_20161103092321.log
Type: application/octet-stream
Size: 64317 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/c9a36d89/attachment-0001.obj>

From sophie.hunt at ctechemail.com  Thu Nov  3 05:03:18 2016
From: sophie.hunt at ctechemail.com (Sophie Hunt)
Date: Thu, 3 Nov 2016 09:03:18 +0000
Subject: [docs] Broken Link
Message-ID: <4352020.or_mail@ctechemail.com>

Hi, 

I know you're busy so I just wanted to follow up on the email I sent you the other day as I noticed the link is still broken. I've included my email below for reference:

		On Fri, Oct 28, 2016 at 8:48 AM, Sophie Hunt <sophie.hunt at ctechemail.com> wrote:
		
			 Hi, 

I recently came across a link on your site which appears to be broken.

Here's the link http://csrc.nist.gov/encryption/tkhash.html, found on this page of your site http://davis.lbl.gov/Manuals/PYTHON-2.5.1/lib/module-sha.html.

I thought that you may wish to check out our guide [https://www.comparitech.com/blog/information-security/cryptography-guide/] as it may make a suitable replacement.

I hope this helps!
Sophie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161103/6699f9d3/attachment.html>

From report at bugs.python.org  Sun Nov  6 11:15:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2016 16:15:02 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <20161106161459.83417.34884.5274DBC5@psf.io>


Roundup Robot added the comment:

New changeset 1d8b8a67b657 by Jason R. Coombs in branch '3.6':
Additionally show that a backslash-escaped opening brace is treated as a literal and thus triggers the single closing brace error, clarifying #28590.
https://hg.python.org/cpython/rev/1d8b8a67b657

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

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

From report at bugs.python.org  Sun Nov  6 11:40:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Nov 2016 16:40:20 +0000
Subject: [docs] [issue21501] submitting mmap example for use in documentation
In-Reply-To: <1400008733.4.0.146542624997.issue21501@psf.upfronthosting.co.za>
Message-ID: <1478450420.49.0.759965851601.issue21501@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Can you say it in the form of a patch?

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

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

From report at bugs.python.org  Sun Nov  6 12:04:26 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 06 Nov 2016 17:04:26 +0000
Subject: [docs] [issue28590] fstring's '{' from escape sequences does not
 start an expression
In-Reply-To: <1478098683.95.0.617891142218.issue28590@psf.upfronthosting.co.za>
Message-ID: <1478451866.35.0.130192629104.issue28590@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Thanks, Jason. I updated the PEP, so now I think the docs and PEP match the implementation.

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

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

From report at bugs.python.org  Sun Nov  6 12:20:56 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 17:20:56 +0000
Subject: [docs] [issue28626] Tutorial: rearrange discussion of output
 formatting to encourage f-strings
Message-ID: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

The 'output formatting' section of the tutorial talks a lot about manual formatting with things like .rjust() and .zfill(), with only a passing reference to 3.6's new f-strings.

The attached patch doesn't drop all of the old material, but it does rearrange the topics into a more modern order: f-strings first, featuring the discussion of formatting specifiers; then calling .format(); finally manual formatting with .ljust().

Open question:

----------
assignee: docs at python
components: Documentation
files: tutorial-patch.txt
keywords: needs review, patch
messages: 280153
nosy: akuchling, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Tutorial: rearrange discussion of output formatting to encourage f-strings
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file45372/tutorial-patch.txt

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

From report at bugs.python.org  Sun Nov  6 12:26:25 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 17:26:25 +0000
Subject: [docs] [issue28626] Tutorial: rearrange discussion of output
 formatting to encourage f-strings
In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za>
Message-ID: <1478453185.6.0.599576465338.issue28626@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Oh, I didn't finish my thought on open questions: should we just drop the discussion of .ljust(), .zfill(), or should it be there so users are aware of it?  Similarly, is it still worth mentioning string.Template?

----------

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

From report at bugs.python.org  Sun Nov  6 12:32:35 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 17:32:35 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
 are classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1478453555.53.0.0394685408368.issue21864@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The patch looks good to me; I think it should just be applied.

----------
nosy: +akuchling

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

From report at bugs.python.org  Sun Nov  6 13:01:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Nov 2016 18:01:03 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
 are classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <20161106180059.111593.88899.FFCA15E6@psf.io>


Roundup Robot added the comment:

New changeset db6d556365d7 by Berker Peksag in branch '3.5':
Issue #21864: Remove outdated section about exceptions from the tutorial
https://hg.python.org/cpython/rev/db6d556365d7

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

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

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

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

From report at bugs.python.org  Sun Nov  6 13:02:38 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 06 Nov 2016 18:02:38 +0000
Subject: [docs] [issue21864] Error in documentation of point 9.8 'Exceptions
 are classes too'
In-Reply-To: <1403653260.15.0.739232303856.issue21864@psf.upfronthosting.co.za>
Message-ID: <1478455358.0.0.993256920735.issue21864@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thank you for the review, Andrew!

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

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

From report at bugs.python.org  Sun Nov  6 13:57:44 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 18:57:44 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478458664.84.0.0360629276989.issue28587@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The patch looks fine, though I suggest clarifying the example for a.index(333, 2)  by adding a comment such as '# begin searching at index 2' to explain what's going on.

----------
nosy: +akuchling

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

From report at bugs.python.org  Sun Nov  6 14:07:18 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 06 Nov 2016 19:07:18 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478459238.64.0.18158908659.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks for the feedback :) Makes sense, I'll work on another patch.

----------

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

From report at bugs.python.org  Sun Nov  6 15:28:31 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 20:28:31 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1478464111.49.0.621045669787.issue8840@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

"Why, this is a simple docstring change.  How difficult can it be?", I thought.

Ah ha ha ha.

Here's a patch against the 3.5 branch. It should also apply cleanly to 3.6 or 3.7, except for a little Argument Clinic noise. 

The patch changes 3 occurrences of the truncate() docstring in Lib/_pyio.py, and 1 each in Modules/_io/{bytesio.c,fileio.c,iobase.c,stringio.c}.  Whew!  Do we want to change all of these occurrences, or just the one specific case of StringIO?  It seemed to me that we want to change them all.

----------
nosy: +akuchling
Added file: http://bugs.python.org/file45375/issue8840.txt

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

From report at bugs.python.org  Sun Nov  6 16:11:39 2016
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 06 Nov 2016 21:11:39 +0000
Subject: [docs] [issue11368] Document why xml.etree.ElementTree.Element has
 no reference to parent
In-Reply-To: <1299031116.52.0.175842807219.issue11368@psf.upfronthosting.co.za>
Message-ID: <1478466699.83.0.920092713312.issue11368@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Closing this old issue.

----------
nosy: +akuchling
status: open -> closed

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

From report at bugs.python.org  Sun Nov  6 16:26:56 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 06 Nov 2016 21:26:56 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478467616.17.0.799892648202.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Here is an updated patch.
Please review :)
Thanks.

----------
Added file: http://bugs.python.org/file45376/issue28587v3.patch

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

From angwerzx at 126.com  Sun Nov  6 21:35:48 2016
From: angwerzx at 126.com (angwerzx at 126.com)
Date: Mon, 07 Nov 2016 02:35:48 -0000
Subject: [docs] Update encoding lookup docs wrt #27938 (issue 28393)
Message-ID: <20161107023548.10569.4310@psf.upfronthosting.co.za>


http://bugs.python.org/review/28393/diff/18859/Doc/library/codecs.rst
File Doc/library/codecs.rst (right):

http://bugs.python.org/review/28393/diff/18859/Doc/library/codecs.rst#newcode974
Doc/library/codecs.rst:974: dashes. Using alternative aliases for these
encodings may result in slower
Lack iso8859-1. And since there is utf8, also lacking utf16 and utf32.

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

From bryan at strategicmissionelements.com  Mon Nov  7 08:19:35 2016
From: bryan at strategicmissionelements.com (Bryan Hutson)
Date: Mon, 7 Nov 2016 08:19:35 -0500
Subject: [docs] example to add to documentation "xml.sax"
Message-ID: <CALZ-hmxu9eAc7FWsRbAoSuXtRV0oGGURx9SjsjUR-f2N6naeUw@mail.gmail.com>

Assuming I'm emailing the right people I found an example that I think
could help out the  "xml.sax" (
https://docs.python.org/2/library/xml.sax.html) documentation. The example
is from stack overflow and will run as is.  I'm not the author but it's a
great sample of code.

http://stackoverflow.com/a/22504625/2601293


thanks,
Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20161107/52ec9f18/attachment.html>

From report at bugs.python.org  Mon Nov  7 10:56:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Nov 2016 15:56:24 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478534184.67.0.786480919157.issue28615@psf.upfronthosting.co.za>


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


----------
status: closed -> open
type:  -> behavior

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

From report at bugs.python.org  Mon Nov  7 11:54:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Nov 2016 16:54:41 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1478537681.21.0.166200438013.issue8840@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch looks good to me, but perhaps we should make these docstrings shorter and refer people to the actual documentation for details? We recently did this in subprocess and venv modules.

----------
nosy: +berker.peksag, martin.panter
stage: needs patch -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Mon Nov  7 15:21:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2016 20:21:42 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <20161107202139.22336.68539.3364CB6D@psf.io>


Roundup Robot added the comment:

New changeset f4e86b1b051e by Berker Peksag in branch '3.5':
Issue #28088: Don't include self in method signature
https://hg.python.org/cpython/rev/f4e86b1b051e

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

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

----------

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

From report at bugs.python.org  Mon Nov  7 15:25:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Nov 2016 20:25:21 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <1478550321.24.0.73009494674.issue28088@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I just removed self from method signatures (we don't usually include it) and updated the versionadded directives to 3.5.3 since it was also backported to 3.5 in f12a59311885. Please let me know if got the 3.5 version wrong, thanks!

----------
nosy: +berker.peksag, larry
versions: +Python 3.5, Python 3.7

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

From report at bugs.python.org  Mon Nov  7 15:25:49 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Nov 2016 20:25:49 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <1478550349.12.0.455485918951.issue28088@psf.upfronthosting.co.za>


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


----------
nosy:  -larry
priority: release blocker -> normal

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

From report at bugs.python.org  Mon Nov  7 16:12:37 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Mon, 07 Nov 2016 21:12:37 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
Message-ID: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>


New submission from Elvis Pranskevichus:

Issue to track edits to "What's New in Python 3.6"

----------
assignee: docs at python
components: Documentation
files: 0001-Inital-pass-on-What-s-New-in-Python-3.6.patch
keywords: patch
messages: 280244
nosy: Elvis.Pranskevichus, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Update What's New for 3.6
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file45384/0001-Inital-pass-on-What-s-New-in-Python-3.6.patch

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

From report at bugs.python.org  Mon Nov  7 16:16:57 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 07 Nov 2016 21:16:57 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478553417.46.0.403642490698.issue28635@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> yselivanov

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

From report at bugs.python.org  Mon Nov  7 16:22:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Nov 2016 21:22:10 +0000
Subject: [docs] [issue28088] Document Transport.set_protocol and get_protocol
In-Reply-To: <1475369173.63.0.247466795846.issue28088@psf.upfronthosting.co.za>
Message-ID: <1478553730.84.0.57485527834.issue28088@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Good point. Thanks Berker!

----------

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

From report at bugs.python.org  Mon Nov  7 16:44:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 07 Nov 2016 21:44:34 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161107214431.22961.93015.643CBE2C@psf.io>


Roundup Robot added the comment:

New changeset 38c806f0943b by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/38c806f0943b

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

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

From report at bugs.python.org  Mon Nov  7 17:55:51 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Nov 2016 22:55:51 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478559351.19.0.912825310434.issue28635@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  8 05:59:27 2016
From: report at bugs.python.org (Armin Ronacher)
Date: Tue, 08 Nov 2016 10:59:27 +0000
Subject: [docs] [issue27589] asyncio doc: issue in as_completed() doc
In-Reply-To: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za>
Message-ID: <1478602767.58.0.664147113322.issue27589@psf.upfronthosting.co.za>


Armin Ronacher added the comment:

I am not even sure what the function is supposed to tell me.  The documentation is very unclear and the example code does not help.  What is "fs" for instance?  And why would it return things that are not from fs?

----------
nosy: +aronacher

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

From report at bugs.python.org  Tue Nov  8 09:37:49 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 08 Nov 2016 14:37:49 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478615869.28.0.728533263032.issue28635@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

What no mention of math.tau? It's a PEP-level change!

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

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

From report at bugs.python.org  Tue Nov  8 09:41:37 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 08 Nov 2016 14:41:37 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478616096.98.0.179236920525.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

The page is a work-in-progress.  We'll surely capture all notable changes.

----------

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

From report at bugs.python.org  Tue Nov  8 09:45:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Nov 2016 14:45:23 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478616323.92.0.315122235416.issue28635@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Holy cow, I missed the PEP 628.

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

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

From report at bugs.python.org  Tue Nov  8 09:50:40 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 08 Nov 2016 14:50:40 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478616640.76.0.872189630481.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

I'm actually working on a tool that parses Misc/NEWS, cpython and peps repos, and roundup to gather and organize the changes to make the news editor's job easier.

----------

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

From report at bugs.python.org  Tue Nov  8 11:12:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Nov 2016 16:12:10 +0000
Subject: [docs] [issue27589] asyncio doc: issue in as_completed() doc
In-Reply-To: <1478602767.58.0.664147113322.issue27589@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+6mGfMx4jQwBvw+T0uWO1H+gdQrC=XB5EAfpOLRskC5Q@mail.gmail.com>


Guido van Rossum added the comment:

However, in general you should use a different pattern. Wrap each future in
a coroutine that does whatever you want to do to the first one ready and
maybe cancel the others. Then gather() all coroutines with the flag that
keeps errors.

--Guido (mobile)

----------

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

From report at bugs.python.org  Tue Nov  8 11:26:18 2016
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 08 Nov 2016 16:26:18 +0000
Subject: [docs] [issue27589] asyncio doc: issue in as_completed() doc
In-Reply-To: <1469182105.52.0.303554063448.issue27589@psf.upfronthosting.co.za>
Message-ID: <1478622378.55.0.352245281074.issue27589@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

Such an idiom is IMHO not the main usefulness of this function tho.

As an (untested) example, something like

async def f(n):
   await asyncio.sleep(n)
   return n

for f in asyncio.as_completed([f(3), f(2), f(1)]):
    print(await f)


will print:

1
2
3

That?s *super* useful if you?re coordinating multiple independent external systems and need to process their results as soon as they arrive (and not once they?re *all* done).

Maybe it always worked by accident for me but it?s my understanding, that that is what this function is for (and I haven?t found another way to achieve it).

That?s why it would be nice if there?d be authoritative docs on what it?s supposed to do. :)

----------

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

From report at bugs.python.org  Tue Nov  8 11:30:27 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Nov 2016 16:30:27 +0000
Subject: [docs] [issue27589] asyncio doc: issue in as_completed() doc
In-Reply-To: <1478622378.55.0.352245281074.issue27589@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJcJ=TZh_mrAZgg8dPsq_-BEjCuxmyzP_aExRMPad5DsA@mail.gmail.com>


Guido van Rossum added the comment:

Well, in that case the idiom will be even simpler: wrap each one in a
coroutine that awaits it and prints the result and then gather() all the
coroutine wrappers.

----------

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

From report at bugs.python.org  Tue Nov  8 15:52:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Nov 2016 20:52:14 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478616640.76.0.872189630481.issue28635@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbaguHE1G6FGmMKiJfxBGbLDmX1B4oDcst1SdM8avjssw@mail.gmail.com>


STINNER Victor added the comment:

Elvis Pranskevichus added the comment:
> I'm actually working on a tool that parses Misc/NEWS, cpython and peps repos, and roundup to gather and organize the changes to make the news editor's job easier.

I don't understand why developers don't do it during the cycle :-/ I'm
trying to keep What's Up In Python X.Y? up to date.

----------

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

From zachary.ware+pydocs at gmail.com  Tue Nov  8 15:50:12 2016
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 8 Nov 2016 14:50:12 -0600
Subject: [docs] Broken Link
In-Reply-To: <4352020.or_mail@ctechemail.com>
References: <4352020.or_mail@ctechemail.com>
Message-ID: <CAKJDb-NJ0y=6+y9e4iudjKrbShDVJBqVC79Qw6jsjAJHWaAMEA@mail.gmail.com>

Hi Sophie,

Thanks for your report, and sorry for the delay in response!  However,
the site you linked to is both not under our control and is serving
documentation for a version of Python that has been out of support for
several years now.  Please find up-to-date documentation for Python
3.5 at https://docs.python.org/ or for Python 2.7 at
https://docs.python.org/2/.

Regards,
-- 
Zach

On Thu, Nov 3, 2016 at 4:03 AM, Sophie Hunt <sophie.hunt at ctechemail.com> wrote:
> Hi,
>
> I know you're busy so I just wanted to follow up on the email I sent you the
> other day as I noticed the link is still broken. I've included my email
> below for reference:
>
>
> On Fri, Oct 28, 2016 at 8:48 AM, Sophie Hunt <sophie.hunt at ctechemail.com>
> wrote:
>
> Hi,
>
> I recently came across a link on your site which appears to be broken.
>
> Here's the link http://csrc.nist.gov/encryption/tkhash.html, found on this
> page of your site
> http://davis.lbl.gov/Manuals/PYTHON-2.5.1/lib/module-sha.html.
>
> I thought that you may wish to check out our guide
> [https://www.comparitech.com/blog/information-security/cryptography-guide/]
> as it may make a suitable replacement.
>
> I hope this helps!
> Sophie

From report at bugs.python.org  Tue Nov  8 19:38:11 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 09 Nov 2016 00:38:11 +0000
Subject: [docs] [issue28644] Document recen changes in typing.py
Message-ID: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

Here is the patch with recent additions/changes in typing.py

Summary: Tuple and Callable are now classes, generic type aliases, added Coroutine, extended docs for get_type_hints.

----------
assignee: docs at python
components: Documentation
files: recent-typing-docs.diff
keywords: patch
messages: 280364
nosy: docs at python, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: Document recen changes in typing.py
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45401/recent-typing-docs.diff

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

From report at bugs.python.org  Tue Nov  8 19:47:23 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 09 Nov 2016 00:47:23 +0000
Subject: [docs] [issue28644] Document recen changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478652443.19.0.566296935855.issue28644@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Sorry, here is the patch with corrected formatting and base classes for Coroutine.

----------
Added file: http://bugs.python.org/file45402/recent-typing-docs-v2.diff

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

From report at bugs.python.org  Tue Nov  8 22:19:19 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Wed, 09 Nov 2016 03:19:19 +0000
Subject: [docs] [issue28644] Document recen changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478661559.25.0.460610773182.issue28644@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi Ivan, I noticed you used two space indentation in your docs patch.

Can you use 3 spaces instead?
More guidelines here:
https://docs.python.org/devguide/documenting.html?#use-of-whitespace

Thanks :)

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

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

From report at bugs.python.org  Wed Nov  9 04:00:43 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 09 Nov 2016 09:00:43 +0000
Subject: [docs] [issue28644] Document recen changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478682043.69.0.43956626667.issue28644@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Thanks Mariatta, here is a new version of patch with indentation fixed.

----------
Added file: http://bugs.python.org/file45405/recent-typing-docs-v3.diff

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

From report at bugs.python.org  Wed Nov  9 09:36:48 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 09 Nov 2016 14:36:48 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478702208.28.0.064676198234.issue28635@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Elvis, please take a look at http://bugs.python.org/issue28641

----------

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

From guido at python.org  Wed Nov  9 11:39:42 2016
From: guido at python.org (guido at python.org)
Date: Wed, 09 Nov 2016 16:39:42 -0000
Subject: [docs] Document recen changes in typing.py (issue 28644)
Message-ID: <20161109163942.18715.48551@psf.upfronthosting.co.za>

Thanks for working on this! Couple of requests.


http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode14
Doc/library/typing.rst:14: fundamental support consists of the type
:data:`Any`, :data:`Union`,
type -> types

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode283
Doc/library/typing.rst:283: def response(query: str) -> Response[str]: #
Same as Union[Iterable[str], int]
Can you break up this line? Long lines in doc examples often look bad or
cause horizontal scrolling. Maybe put the comment on the line before
(adding "Return type here is same as ...").

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode444
Doc/library/typing.rst:444: .. class:: Tuple
I'm not sure I'm comfortable advertising Tuple as a class. While `class
C(Tuple): pass` works, using `class C(Tuple[int, int]): pass` elicits
the error (from mypy) "error: Tuple[...] not supported as a base class
outside a stub file".

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode457
Doc/library/typing.rst:457: .. class:: Callable
This is even more dubious as a class, `class C(Callable)` gives "Invalid
base class" and so does `class C(Callable[..., int])`.

I really want to limit Callable and Tuple to just being types usable in
annotations, not runtime building blocks.

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode463
Doc/library/typing.rst:463: must be a list of types; the return type
must be a single type.
This is contradicted later, the arglist can also be an ellipsis.

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode629
Doc/library/typing.rst:629: .. class:: Coroutine(Awaitable[V_co],
Generic[T_co T_contra, V_co])
This one OTOH *is* a real class and can be subclassed etc. (Even though
in practice it's still most useful in annotations, since few people will
have reason to implement their own coroutines -- they'll just define a
generator.)

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode636
Doc/library/typing.rst:636: c = None # type: Coroutine[List[str], str,
int]
Can you also show an example of how one would create an object of this
type? I think it's what you get when you call an async def.

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode770
Doc/library/typing.rst:770: collected in superclasses following
``obj.__mro__``.
Probably also add that for a class C, it's *not* just C.__annotations__,
but rather a dict constructed by merging all the __annotations__ dicts
along C.__mro__ (in reverse order, if you want to be precise).

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

From report at bugs.python.org  Thu Nov 10 01:45:01 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 10 Nov 2016 06:45:01 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478760301.79.0.220195836766.issue28615@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi, here is the doc update, to be applied to 2.7 branch.

Please review. Thanks :)

----------
keywords: +patch
nosy: +Mariatta
Added file: http://bugs.python.org/file45418/issue28615.patch

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

From levkivskyi at gmail.com  Thu Nov 10 08:59:14 2016
From: levkivskyi at gmail.com (levkivskyi at gmail.com)
Date: Thu, 10 Nov 2016 13:59:14 -0000
Subject: [docs] Document recen changes in typing.py (issue 28644)
Message-ID: <20161110135914.27915.16420@psf.upfronthosting.co.za>

Reviewers: gvanrossum,


http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode444
Doc/library/typing.rst:444: .. class:: Tuple
On 2016/11/09 17:39:42, gvanrossum wrote:
> I'm not sure I'm comfortable advertising Tuple as a class. While
`class
> C(Tuple): pass` works, using `class C(Tuple[int, int]): pass` elicits
the error
> (from mypy) "error: Tuple[...] not supported as a base class outside a
stub
> file".

Everything else in docs is systematized by the actual implementation. I
am marking this simply as :data: (under your responsibility :-) if
someone will complain).

Actually, I think subclassing is also a way of annotating types.
Subclassing Tuple[int, str] means that the class supports a certain
"API". mypy already supports ``class C(Tuple[int, str]): ...`` this way
in stub files.

It looks like mypy rejects this for normal files only because of
previous limitations of typing.py. If I just remove the check, it also
works in normal files as well. Also, it looks like Jukka likes allowing
this, so that I will make a PR for mypy soon.



Please review this at http://bugs.python.org/review/28644/

Affected files:
  Doc/library/typing.rst



From report at bugs.python.org  Thu Nov 10 09:00:15 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 10 Nov 2016 14:00:15 +0000
Subject: [docs] [issue28644] Document recen changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478786415.9.0.94956210514.issue28644@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Guido, here is a new patch with your comments implemented.

----------
Added file: http://bugs.python.org/file45424/recent-typing-docs-v4.diff

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

From report at bugs.python.org  Thu Nov 10 13:21:28 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 10 Nov 2016 18:21:28 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478802088.94.0.032234859115.issue28635@psf.upfronthosting.co.za>


Changes by Elvis Pranskevichus <elvis at magic.io>:


Added file: http://bugs.python.org/file45428/0001-Issue-28635-Fix-a-couple-of-missing-incorrect-versio.patch

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

From report at bugs.python.org  Thu Nov 10 13:21:43 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 10 Nov 2016 18:21:43 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478802102.69.0.810934456591.issue28635@psf.upfronthosting.co.za>


Changes by Elvis Pranskevichus <elvis at magic.io>:


Added file: http://bugs.python.org/file45429/0002-Issue-28635-What-s-New-in-Python-3.6-updates.patch

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

From report at bugs.python.org  Thu Nov 10 13:22:20 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 10 Nov 2016 18:22:20 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478802140.76.0.858666042216.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

Attached patch for another pass on what's new.

----------

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

From report at bugs.python.org  Thu Nov 10 13:26:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2016 18:26:14 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161110182611.124271.98940.BB26F85E@psf.io>


Roundup Robot added the comment:

New changeset bcd4ab982429 by Yury Selivanov in branch '3.6':
Issue #28635: Fix a couple of missing/incorrect versionchanged tags
https://hg.python.org/cpython/rev/bcd4ab982429

New changeset 5c4ce500dd35 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/5c4ce500dd35

----------

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

From report at bugs.python.org  Thu Nov 10 13:28:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2016 18:28:10 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161110182807.26426.79184.98099EB6@psf.io>


Roundup Robot added the comment:

New changeset c0060567f35d by Yury Selivanov in branch '3.6':
Issue #28635: What's New in Python 3.6 updates
https://hg.python.org/cpython/rev/c0060567f35d

New changeset 69bdf8bdfd61 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/69bdf8bdfd61

----------

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

From report at bugs.python.org  Thu Nov 10 14:15:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Nov 2016 19:15:25 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478805325.91.0.345787854614.issue28635@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Patches for following issues was applied in 3.5. They may be bug fixes, not new features.

#13248 #16113 #20476 #22115 #23517 #24764 #25590 #25593 #25913 #26470 #26733 #26754 #26801 #27040 #27041 #27243 #27392 #27598 #27691 #27766 #27850 #27932 #28370 #28613

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

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

From report at bugs.python.org  Thu Nov 10 14:16:31 2016
From: report at bugs.python.org (Ivan Tomilov)
Date: Thu, 10 Nov 2016 19:16:31 +0000
Subject: [docs] [issue28661] Fix code example in Python 3.5 telnetlib
 documentation
Message-ID: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za>


New submission from Ivan Tomilov:

The code sample on page https://docs.python.org/3/library/telnetlib.html is a little confusing. The extra space in string "Password: " before the second quote basically hangs the example program when you try to run it.

Please, check my answer on Stack Overflow for more details:
http://stackoverflow.com/questions/28345839/python3-telnet-code-stays-quiet-after-launching-does-not-initiate-the-command-t/40535049#40535049

I'm sorry if I get something wrong.

Thanks,
Ivan.

----------
assignee: docs at python
components: Documentation
messages: 280536
nosy: docs at python, tiabc
priority: normal
severity: normal
status: open
title: Fix code example in Python 3.5 telnetlib documentation
type: enhancement
versions: Python 3.5

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

From guido at python.org  Thu Nov 10 14:47:36 2016
From: guido at python.org (guido at python.org)
Date: Thu, 10 Nov 2016 19:47:36 -0000
Subject: [docs] Document recen changes in typing.py (issue 28644)
Message-ID: <20161110194736.7912.81942@psf.upfronthosting.co.za>


http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28644/diff/19105/Doc/library/typing.rst#newcode444
Doc/library/typing.rst:444: .. class:: Tuple
On 2016/11/10 14:59:14, levkivskyi wrote:
> On 2016/11/09 17:39:42, gvanrossum wrote:
> > I'm not sure I'm comfortable advertising Tuple as a class. While
`class
> > C(Tuple): pass` works, using `class C(Tuple[int, int]): pass`
elicits the
> error
> > (from mypy) "error: Tuple[...] not supported as a base class outside
a stub
> > file".
> 
> Everything else in docs is systematized by the actual implementation.
I am
> marking this simply as :data: (under your responsibility :-) if
someone will
> complain).
> 
> Actually, I think subclassing is also a way of annotating types.
Subclassing
> Tuple[int, str] means that the class supports a certain "API". mypy
already
> supports ``class C(Tuple[int, str]): ...`` this way in stub files.
> 
> It looks like mypy rejects this for normal files only because of
previous
> limitations of typing.py. If I just remove the check, it also works in
normal
> files as well. Also, it looks like Jukka likes allowing this, so that
I will
> make a PR for mypy soon.

Well, inheriting from Tuple doesn't just inherit the type -- it inherits
the implementation as well. This seems to work (although mypy doesn't
understand enough about `__new__` to make it very useful) but I think
it's still mostly a party trick. So for now classifying Tuple under data
seems right.

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode614
Doc/library/typing.rst:614: async def foo() -> str:
Should be -> int

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode616
Doc/library/typing.rst:616: coro = foo() # type: Coroutine[None, None,
int]
I tested this and it doesn't work, because Coroutine is a subclass of
Awaitable (not the other way around).

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode623
Doc/library/typing.rst:623: chat = bar() # type: Coroutine[str, Any,
int]
Sadly this doesn't work either. I get

__tmp__.py:12: error: Incompatible types in assignment (expression has
type AwaitableGenerator[str, Any, int, Generator[str, Any, int]],
variable has type Coroutine[str, Any, int])

Now that seems to be due to a bug in typing.pyi (AwaitableGenerator
should inherit from Awaitable[_V_co], not _T_co, I think), but after
fixing that I still get an error:

__tmp__.py:12: error: Incompatible types in assignment (expression has
type AwaitableGenerator[str, Any, int, Generator[str, Any, int]],
variable has type Coroutine[str, Any, int])

I could make that go away by replacing Generator with Coroutine in the
definition of AwaitableGenerator, but that feels fishy (and I'd have to
swap in what I was thinking when I implemented async/await in mypy).

I propose that we leave these examples out for now and get back to them
once we've figured out how this actually works...

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode874
Doc/library/typing.rst:874: must be a list of types or ellipsis; the
return type must be
or -> or an

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

From report at bugs.python.org  Thu Nov 10 15:10:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 10 Nov 2016 20:10:30 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478808630.26.0.548993224853.issue28635@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

+The disassembler now decodes ``FORMAT_VALUE`` argument.
+(Contributed by Serhiy Storchaka in :issue:`28317`.)

FORMAT_VALUE is new in 3.6. This change should be considered as a part of PEP 498 and is not deserve special mentioning.

----------

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

From report at bugs.python.org  Thu Nov 10 15:35:43 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Thu, 10 Nov 2016 20:35:43 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478810143.75.0.835941846308.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

Thanks Serhiy.  I removed mentions of things that were indeed fixes backported to 3.5.  Other issue references are valid news, including new features to provisional modules backported to 3.5.  It is customary to include these in the news for the major release.

----------
Added file: http://bugs.python.org/file45430/0001-Issue-28635-what-s-new-in-3.6-remove-mentions-of-bac.patch

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

From report at bugs.python.org  Thu Nov 10 15:39:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 10 Nov 2016 20:39:53 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161110203950.96974.41355.28EF733E@psf.io>


Roundup Robot added the comment:

New changeset 4c81a107ccab by Yury Selivanov in branch '3.6':
Issue #28635: what's new in 3.6: remove mentions of backported fixes.
https://hg.python.org/cpython/rev/4c81a107ccab

New changeset 8ebaa546a033 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/8ebaa546a033

----------

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

From report at bugs.python.org  Thu Nov 10 15:46:49 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Nov 2016 20:46:49 +0000
Subject: [docs] [issue28644] Document recent changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478810809.99.0.189068401979.issue28644@psf.upfronthosting.co.za>


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


----------
title: Document recen changes in typing.py -> Document recent changes in typing.py

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

From report at bugs.python.org  Thu Nov 10 16:59:14 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Nov 2016 21:59:14 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478815154.4.0.723462373042.issue28635@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I spotted a small typo in the "PEP 495: Local Time Disambiguation" section: "The values of the fold attribute have the value 0 all instances ..." should be "The values of the fold attribute have the value 0 *for* all instances ..."

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Nov 10 18:05:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 10 Nov 2016 23:05:04 +0000
Subject: [docs] [issue28661] Fix code example in Python 3.5 telnetlib
 documentation
In-Reply-To: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za>
Message-ID: <1478819104.14.0.122163731272.issue28661@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, the example code is correct for a typical telnet service running on a unix variant.  That will output a space after the colon, so that the user's input is separated from the colon when they start to type.

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

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

From report at bugs.python.org  Fri Nov 11 01:34:37 2016
From: report at bugs.python.org (Ivan Tomilov)
Date: Fri, 11 Nov 2016 06:34:37 +0000
Subject: [docs] [issue28661] Fix code example in Python 3.5 telnetlib
 documentation
In-Reply-To: <1478819104.14.0.122163731272.issue28661@psf.upfronthosting.co.za>
Message-ID: <CAM5S9_2B2se0O+kTnKeLz+Va8Acs0j0dNC1Qcrdr4b2kz5RzKw@mail.gmail.com>


Ivan Tomilov added the comment:

I see, thanks for the clarification.
But in my OS X the things are different and I spent about 1 hour trying
this code to take off.
Maybe it's better to change this code to avoid spending time for such
subtle bugs? Say:
tn.read_until(b"Password:")
tn.read_eager()

Or just add a comment. It's confusing when one takes code from the official
website and it doesn't work.

What do you think?

On 11 November 2016 at 02:05, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Well, the example code is correct for a typical telnet service running on
> a unix variant.  That will output a space after the colon, so that the
> user's input is separated from the colon when they start to type.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28661>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Nov 11 09:55:45 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Nov 2016 14:55:45 +0000
Subject: [docs] [issue28661] Fix code example in Python 3.5 telnetlib
 documentation
In-Reply-To: <1478805391.59.0.11862034954.issue28661@psf.upfronthosting.co.za>
Message-ID: <1478876145.13.0.602332688515.issue28661@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  I'm surprised that OSX would be different.  I didn't actually experiment to confirm it on linux, either.

I could be taken as a "teaching opportunity" to talk about exact match vs read_eager, in a comment before or after the example, if someone wants to propose a doc patch.  I'm not opposed to changing the example, but an explanation would probably be good either way.

Maybe Jack will have an opinion.

----------
assignee: docs at python -> 
nosy: +jackdied
versions: +Python 3.6, Python 3.7

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

From levkivskyi at gmail.com  Fri Nov 11 10:01:49 2016
From: levkivskyi at gmail.com (levkivskyi at gmail.com)
Date: Fri, 11 Nov 2016 15:01:49 -0000
Subject: [docs] Document recen changes in typing.py (issue 28644)
Message-ID: <20161111150149.23366.99754@psf.upfronthosting.co.za>


http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode616
Doc/library/typing.rst:616: coro = foo() # type: Coroutine[None, None,
int]
On 2016/11/10 20:47:36, gvanrossum wrote:
> I tested this and it doesn't work, because Coroutine is a subclass of
Awaitable
> (not the other way around).

It looks like this is a bug in mypy. Awaitable[int] is to wide type for
the result of calling async def.

Future, for example, is Awaitable but is not a Coroutine since Future
doesn't have .send(), while async def always results in Coroutine, it
always has .send().

I think in this example inferred type of foo() should be Coroutine[None,
None, int] (the first argument is questionable, since the coroutine in
example never yields, but we don't have a notation for this).

Anyway, I removed this example.

http://bugs.python.org/review/28644/diff/19123/Doc/library/typing.rst#newcode623
Doc/library/typing.rst:623: chat = bar() # type: Coroutine[str, Any,
int]
On 2016/11/10 20:47:36, gvanrossum wrote:
> Sadly this doesn't work either. I get
> 
> __tmp__.py:12: error: Incompatible types in assignment (expression has
type
> AwaitableGenerator[str, Any, int, Generator[str, Any, int]], variable
has type
> Coroutine[str, Any, int])
> 
> Now that seems to be due to a bug in typing.pyi (AwaitableGenerator
should
> inherit from Awaitable[_V_co], not _T_co, I think), but after fixing
that I
> still get an error:
> 
> __tmp__.py:12: error: Incompatible types in assignment (expression has
type
> AwaitableGenerator[str, Any, int, Generator[str, Any, int]], variable
has type
> Coroutine[str, Any, int])
> 
> I could make that go away by replacing Generator with Coroutine in the
> definition of AwaitableGenerator, but that feels fishy (and I'd have
to swap in
> what I was thinking when I implemented async/await in mypy).
> 
> I propose that we leave these examples out for now and get back to
them once
> we've figured out how this actually works...

It also looks like a bug in mypy. As I understand, now we have three
things:

* Normal generator (Generator): could not be used with await, could be
used with yield from.
* Result of @types.coroutine: could be used with both await and yield
from (this is probably the thing called AwaitableGenerator)
* A coroutine (result of calling async def, Coroutine): could be used
with await, but not with yield from.

This somehow reminds me bytes/str/unicode :-) But I think here the
solution is simple. The second type is just an intersection of two
others:

class AwaitableGenerator(Coroutine[T_co, T_contra, V_co],
Generator[T_co, T_contra, V_co]): ...

Actually, the current definition in typing.pyi could also work if mypy
would treat all these types as ABCs (by structural subtyping). So this
is another +1 for Protocol.

Again, I removed this example.

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

From report at bugs.python.org  Fri Nov 11 10:02:04 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 11 Nov 2016 15:02:04 +0000
Subject: [docs] [issue28644] Document recent changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478876524.27.0.427646989366.issue28644@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Guido, here is the new patch with your corrections. I have some questions in Rietveld, but those are about mypy, you could apply the patch now.

----------
Added file: http://bugs.python.org/file45446/recent-typing-docs-v5.diff

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

From report at bugs.python.org  Fri Nov 11 10:03:49 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 11 Nov 2016 15:03:49 +0000
Subject: [docs] [issue28644] Document recent changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478876629.98.0.415113262234.issue28644@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file45447/recent-typing-docs-v6.diff

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

From report at bugs.python.org  Fri Nov 11 18:45:53 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Nov 2016 23:45:53 +0000
Subject: [docs] [issue28614] Slice limit documentation could be interpreted
 in Python 2.
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478907953.94.0.157081699576.issue28614@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

n < (j-i)/k is a straightforward translation of i + n*k < j, and vice verse, where / is rational division.  It is incorrect to integerize the result and the doc does not say to do so.  In Python 3, there is no ambiguity, and the doc is *not* incorrect, and does not need to be changed.  In Python 2, I think it still clear enough, but we could add "(where / indicates rational division)'.  However, I also think this might be too nitpicky.  I am inclined to think that this should be closed.

----------
nosy: +terry.reedy
title: Slice limit documentation is incorrect -> Slice limit documentation could be interpreted in Python 2.

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

From guido at python.org  Fri Nov 11 18:50:18 2016
From: guido at python.org (guido at python.org)
Date: Fri, 11 Nov 2016 23:50:18 -0000
Subject: [docs] Document recen changes in typing.py (issue 28644)
Message-ID: <20161111235018.23366.27410@psf.upfronthosting.co.za>

OK, I'll merge this. I think you're probably right about the mypy
issues, this is an exceedingly tricky area; PEP 492 is not really using
the right terminology, it's more about implementations...

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

From report at bugs.python.org  Fri Nov 11 18:57:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Nov 2016 23:57:58 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478908678.94.0.657818965987.issue28615@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I don't like the term 'imaginary number' but the usage is standard, and python does not have 'complex literals' (I checked 2.7 chapter 2 on number literals).  So I will apply this.

----------
assignee: docs at python -> terry.reedy
nosy: +terry.reedy

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

From report at bugs.python.org  Fri Nov 11 18:58:08 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Nov 2016 23:58:08 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478908688.0.0.170502934339.issue28615@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 11 18:58:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 11 Nov 2016 23:58:39 +0000
Subject: [docs] [issue28644] Document recent changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <20161111235836.5016.81043.1552344B@psf.io>


Roundup Robot added the comment:

New changeset 5bf2ea0d3830 by Guido van Rossum in branch '3.5':
Issue 28644: Document recent changes in typing.py (Ivan L)
https://hg.python.org/cpython/rev/5bf2ea0d3830

New changeset 72a2c90abdec by Guido van Rossum in branch '3.6':
Issue 28644: Document recent changes in typing.py (Ivan L) (3.5->3.6)
https://hg.python.org/cpython/rev/72a2c90abdec

New changeset c4394da344b7 by Guido van Rossum in branch 'default':
Issue 28644: Document recent changes in typing.py (Ivan L) (3.6->3.7)
https://hg.python.org/cpython/rev/c4394da344b7

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

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

From report at bugs.python.org  Fri Nov 11 18:59:06 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Nov 2016 23:59:06 +0000
Subject: [docs] [issue28644] Document recent changes in typing.py
In-Reply-To: <1478651891.38.0.327376110716.issue28644@psf.upfronthosting.co.za>
Message-ID: <1478908746.91.0.820706765461.issue28644@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 11 19:10:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 12 Nov 2016 00:10:04 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <20161112001001.60889.25367.A61BD338@psf.io>


Roundup Robot added the comment:

New changeset f8d12cb7d0fd by Terry Jan Reedy in branch '2.7':
Issue #28615: Backport imaginary/complex number text from 3.x.
https://hg.python.org/cpython/rev/f8d12cb7d0fd

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

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

From report at bugs.python.org  Fri Nov 11 19:10:41 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Nov 2016 00:10:41 +0000
Subject: [docs] [issue28615] Document clarification: Section 5.4 Complex
 Number
In-Reply-To: <1478286572.26.0.816720776987.issue28615@psf.upfronthosting.co.za>
Message-ID: <1478909441.04.0.912207687329.issue28615@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 11 19:45:55 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Nov 2016 00:45:55 +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: <1478911555.24.0.75307751299.issue28617@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

"Two more operations with the same syntactic priority, in and not in, are supported ..."

could be changed to

The containment tests in and not in have the same priority as comparisons and are supported ..."

----------
nosy: +terry.reedy
stage:  -> commit review
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 11 20:00:03 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Nov 2016 01:00:03 +0000
Subject: [docs] [issue28614] Slice limit documentation could be
 misinterpreted in Python 2.
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478912403.39.0.841335284495.issue28614@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

n < (j-i)/k is a straightforward translation of i + n*k < j, and vice verse, where / is rational division.  It is incorrect to integerize the result and the doc does not say to do so.  In Python 3, there is no ambiguity, and the doc is *not* incorrect, and does not need to be changed.  In Python 2, I think it still clear enough, but we could add "(where / indicates rational division)'.  However, I also think this might be too nitpicky.  I am inclined to think that this should be closed.

----------
title: Slice limit documentation could be interpreted in Python 2. -> Slice limit documentation could be misinterpreted in Python 2.

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

From report at bugs.python.org  Fri Nov 11 20:00:22 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Nov 2016 01:00:22 +0000
Subject: [docs] [issue28614] Slice limit documentation could be
 misinterpreted in Python 2.
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478912422.56.0.0275603613958.issue28614@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov 12 00:44:52 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Nov 2016 05:44:52 +0000
Subject: [docs] [issue28614] Slice limit documentation could be
 misinterpreted in Python 2.
In-Reply-To: <1478286284.13.0.895417928613.issue28614@psf.upfronthosting.co.za>
Message-ID: <1478929492.38.0.498840034945.issue28614@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

>  I am inclined to think that this should be closed.

I concur.

The problem with the nitpick and word-smithing is that over-explaining tends to make the docs harder to read and understand by getting in the way of the basic message.

Given that this passage has worked well enough for users for a very long time, it is likely best to leave in alone.

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

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

From report at bugs.python.org  Sat Nov 12 00:50:12 2016
From: report at bugs.python.org (=?utf-8?q?Jo=C3=A3o_Sebasti=C3=A3o_de_Oliveira_Bueno?=)
Date: Sat, 12 Nov 2016 05:50:12 +0000
Subject: [docs] [issue28672] Explain in the "Data Model" document why
 arguments to __init__ are ok when __new__ is not defined
Message-ID: <1478929812.24.0.930722962265.issue28672@psf.upfronthosting.co.za>


New submission from Jo?o Sebasti?o de Oliveira Bueno:

There is an specific Python behavior on object instantiation that is "expected" but not explicit, even for avanced users:

When a custom class defines `__init__` with extra parameters, but do not overrides `__new__`, it simply works. But if `__new__`is defined it has to match `__init__`s signature.

This behavior is not documented anywhere.

I could found this issue was discussed in this thread earlier this year, starting with this e-mail:
https://mail.python.org/pipermail/python-list/2016-March/704013.html

I propose the following paragraph from a follow up e-mail by "eryksun at gmail.com" to be added to the description of "__new__" in the Data Model documentation page:

"""

[The implementation] knows whether a type overrides the __new__ or
__init__ methods. You're expected to consume additional arguments in
this case. However, excess arguments are ignored in object.__new__ if
a type overrides __init__ without overriding __new__ (i.e. your second
example). Excess arguments are also ignored in object.__init__ if a
type overrides __new__ without overriding __init__.
"""
(Source: https://mail.python.org/pipermail/python-list/2016-March/704024.html)

----------
assignee: docs at python
components: Documentation
messages: 280633
nosy: Jo?o.Sebasti?o.de.Oliveira.Bueno, docs at python
priority: normal
severity: normal
status: open
title: Explain in the "Data Model" document why arguments to __init__ are ok when __new__ is not defined
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Nov 12 01:00:57 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Nov 2016 06:00:57 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478930457.61.0.387270784664.issue28587@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This patch looks very good and I especially like the example.

One nit.  It may be insufficient to say that the start/end arguments are interpreted the same as the slice notation.  While that clear indicates the range being searched, it is silent on whether the index result is relative to index zero or relative to the start argument.

----------

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

From report at bugs.python.org  Sat Nov 12 03:15:12 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Nov 2016 08:15:12 +0000
Subject: [docs] [issue28626] Tutorial: rearrange discussion of output
 formatting to encourage f-strings
In-Reply-To: <1478452855.22.0.932657206329.issue28626@psf.upfronthosting.co.za>
Message-ID: <1478938512.87.0.917854406566.issue28626@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It makes sense to drop zfill() and ljust().  If there is any mention of string.Template, it could be limited to mentioning why you would want to use it (i.e. is a great format to expose to non-programmer end-users) and include a reference to the string.Template docs.

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

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

From report at bugs.python.org  Sat Nov 12 10:57:04 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 12 Nov 2016 15:57:04 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1478966224.03.0.15974786453.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks for the feedback, Raymond :)

I rephrased the docs like the following, what do you think?

Return zero-based index in the list of the first item whose value is *x*.  It is an error if there is no such item.  Optional arguments ``start`` and ``end`` are interpreted as in slice notation.

----------
Added file: http://bugs.python.org/file45460/issue28587v4.patch

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

From report at bugs.python.org  Sat Nov 12 11:29:26 2016
From: report at bugs.python.org (Damian Kotlar)
Date: Sat, 12 Nov 2016 16:29:26 +0000
Subject: [docs] [issue28674] fosa.zd.djkps@gmail.com
Message-ID: <1478968166.78.0.049873407959.issue28674@psf.upfronthosting.co.za>


Changes by Damian Kotlar <fosa.zd.djkps at gmail.com>:


----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Cross-Build, Demos and Tools, Documentation, Extension Modules, Installation, Interpreter Core, Library (Lib), SSL, Tests, XML, email
files: samsungapps.html
nosy: Alex.Willmer, barry, docs at python, fosa.zd.djkps at gmail.com, r.david.murray
priority: normal
severity: normal
status: open
title: fosa.zd.djkps at gmail.com
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45461/samsungapps.html

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

From report at bugs.python.org  Sat Nov 12 16:32:17 2016
From: report at bugs.python.org (Viorel Tabara)
Date: Sat, 12 Nov 2016 21:32:17 +0000
Subject: [docs] [issue28677] difficult to parse sentence structure in "When
 an instance attribute is referenced that isn't a data attribute"
Message-ID: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>


New submission from Viorel Tabara:

Method objects are explained at:

    https://docs.python.org/3/tutorial/classes.html#method-objects

I'd like to suggest a change from:

   When an instance attribute is referenced that isn?t a data attribute, its 
   class is searched. 

to something along this line:

   When an instance attribute --- that isn?t a data attribute --- is 
   referenced, the instance parent class will be searched.

----------
assignee: docs at python
components: Documentation
messages: 280671
nosy: docs at python, viorel
priority: normal
severity: normal
status: open
title: difficult to parse sentence structure in "When an instance attribute is referenced that isn't a data attribute"
type: enhancement

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

From report at bugs.python.org  Sat Nov 12 16:43:18 2016
From: report at bugs.python.org (Lewis McCarthy)
Date: Sat, 12 Nov 2016 21:43:18 +0000
Subject: [docs] [issue28678] tarfile extract docs inconsistent naming of
 parameter numeric_owner or numeric_only
Message-ID: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za>


New submission from Lewis McCarthy:

https://docs.python.org/3/library/tarfile.html#tarfile-objects

Most of the documentation for the extract and extractall methods refers to a parameter named numeric_owner. However, the notes on what changed in v3.5 refer instead to numeric_only. One of these names is incorrect and should be changed to match the other.

Same issue in the 3.6 and 3.7 docs.

https://docs.python.org/3.6/library/tarfile.html#tarfile-objects
https://docs.python.org/3.7/library/tarfile.html#tarfile-objects

----------
assignee: docs at python
components: Documentation
messages: 280673
nosy: docs at python, pseudonym
priority: normal
severity: normal
status: open
title: tarfile extract docs inconsistent naming of parameter numeric_owner or numeric_only
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Nov 12 17:47:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Nov 2016 22:47:32 +0000
Subject: [docs] [issue28678] tarfile extract docs inconsistent naming of
 parameter numeric_owner or numeric_only
In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za>
Message-ID: <1478990852.0.0.581193959061.issue28678@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov 12 17:49:14 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 12 Nov 2016 22:49:14 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1478990954.04.0.468121289834.issue28635@psf.upfronthosting.co.za>


Ned Deily added the comment:

There are now a few markup errors that the Docs buildbots are catching.  See, for example:

http://buildbot.python.org/all/builders/Docs%203.x/builds/2849

----------

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

From report at bugs.python.org  Sat Nov 12 17:52:48 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 12 Nov 2016 22:52:48 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478990954.04.0.468121289834.issue28635@psf.upfronthosting.co.za>
Message-ID: <A6509D9A-8A78-4F92-AF3D-8C80B552B333@gmail.com>


Yury Selivanov added the comment:

I'll go through whatsnew on Monday, fixing errors etc.

----------

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

From report at bugs.python.org  Sat Nov 12 22:36:36 2016
From: report at bugs.python.org (Xue Fuqiao)
Date: Sun, 13 Nov 2016 03:36:36 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
Message-ID: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>


New submission from Xue Fuqiao:

In https://hg.python.org/cpython/file/6fbb7c9d77c6/Doc/tutorial/controlflow.rst#l295 :

   A function definition introduces the function name in the
   current symbol table. The value of the function name has a
   type that is recognized by the interpreter as a user-defined
   function.  This value can be assigned to another name which
   can then also be used as a function.  This serves as a general
   renaming mechanism

Maybe "aliasing" is a better term than "renaming" here, since the original function name can still be used after the "renaming".

----------
assignee: docs at python
components: Documentation
files: renaming.patch
keywords: patch
messages: 280683
nosy: docs at python, xfq
priority: normal
severity: normal
status: open
title: About function renaming in the tutorial
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45468/renaming.patch

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

From report at bugs.python.org  Sat Nov 12 23:29:15 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2016 04:29:15 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479011355.61.0.852403972426.issue28681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 "Aliasing" is more accurate.

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

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

From report at bugs.python.org  Sun Nov 13 00:52:37 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 13 Nov 2016 05:52:37 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479016357.21.0.47973002009.issue28681@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I disagree that "aliasing" is more accurate.

We have a perfectly good name for symbols in Python: "name". A value (and that includes functions) can have multiple names. It seems to me that if we're to start distinguishing between names and aliases, then aliases have to be different from names. And the way I understand "alias" is that it is another symbol for a variable, not another symbol for the same value.

We wouldn't say that

    x = 1
    y = x

makes y an alias for x. y just happens to be a second name for the same value that x currently has. There's no guarantee that they will stay the same. Substitute a function object for the int 1, and you have the situation being discussed in the tutorial.

I would expect that aliases should not be effected by rebinding:

    x = 1
    y = alias(x)  # if such a thing existed
    x = 2
    assert y == 2

Obviously there's nothing in Python like that! This doesn't match Python's name binding model at all.

I think that talking about a "general aliasing" mechanism is exactly wrong. I think that the tutorial should emphasis the reality that functions are just ordinary values, like ints and floats and dicts and lists, and not try to indicate that there is something special or different about names bound to functions:

    def f(): ...
    g = f

is no different from the x = y example earlier.

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

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

From report at bugs.python.org  Sun Nov 13 01:01:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 13 Nov 2016 06:01:02 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479016862.39.0.608372846409.issue28681@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

To me, this is renaming:

     def f(x): pass
     f.__name__ = g

And this is aliasing:

     g = f

----------

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

From report at bugs.python.org  Sun Nov 13 04:04:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 13 Nov 2016 09:04:52 +0000
Subject: [docs] [issue27998] Bytes paths now are supported in os.scandir()
 on Windows
In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za>
Message-ID: <1479027892.18.0.0468867307659.issue27998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch documents bytes paths support on Windows.

----------
keywords: +patch
nosy: +Elvis.Pranskevichus, yselivanov
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45469/doc-scandir-bytes.patch

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

From report at bugs.python.org  Sun Nov 13 05:31:21 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 13 Nov 2016 10:31:21 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479016862.39.0.608372846409.issue28681@psf.upfronthosting.co.za>
Message-ID: <20161113103114.GQ3365@ando.pearwood.info>


Steven D'Aprano added the comment:

> And this is aliasing:
>      g = f

Is it only aliasing if you know that f is a function? I don't mean that 
as a rhetorical question -- I'm asking if we're comfortable with the 
idea of saying that g is an alias when f is (say) a float.

----------

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

From report at bugs.python.org  Sun Nov 13 10:30:16 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 13 Nov 2016 15:30:16 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1479051016.21.0.970050123584.issue28635@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Thank you Yury and Elvis for working on this!

I have few more suggestions for What's New:

* collections.abc.Reversible (http://bugs.python.org/issue25987).

* various ABCs in collections.abc now have means for explicit "anti-registration" by setting a corresponding attribute to None (http://bugs.python.org/issue25958, https://docs.python.org/3.6/reference/datamodel.html#special-method-names).

* implementation improvements (such as caching of generic types) in typing module give up to 30x seep-up and reduce memory footprint.

* typing.py now supports generic type aliases (https://github.com/python/typing/pull/195 and https://github.com/python/typing/pull/308, see mypy docs for usage examples).

* typing.py supports PEP 526 syntax for typed NamedTuple (https://github.com/python/typing/pull/282).

(I see that there are already several items about typing, so please feel free to keep only the most important changes.)

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

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

From report at bugs.python.org  Sun Nov 13 11:43:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Nov 2016 16:43:01 +0000
Subject: [docs] [issue28677] difficult to parse sentence structure in "When
 an instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1479055381.6.0.996322835514.issue28677@psf.upfronthosting.co.za>


R. David Murray added the comment:

"instance parent class" is not terminology used in our docs as far as I remember.  "instance's class" would be more in line with the other docs.  That would solve the pronoun reference problem more succinctly, I think.

How about this version, which also improves the awkward phrasing, but without using em-dashes:

"When a non-data attribute of an instance is referenced, the instance's class is searched."

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

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

From report at bugs.python.org  Sun Nov 13 12:21:19 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Sun, 13 Nov 2016 17:21:19 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1479057679.26.0.692155287071.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

Patch with updates attached.  Thanks for the feedback guys!

----------
Added file: http://bugs.python.org/file45474/0001-Issue-28635-what-s-new-in-3.6-add-a-few-more-notes-o.patch

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

From report at bugs.python.org  Sun Nov 13 12:24:11 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 13 Nov 2016 17:24:11 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479057851.66.0.0126534633545.issue28681@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would rewrite that paragraph as follows:

   A function definition associates the function name with
   the function object in the current symbol table.  The
   interpreter recognizes the object pointed to by that
   name as a user-defined function.  Other names can also
   point to that same function object and can then also
   be used as a function.

You will note that I've dropped the mention of renaming entirely, since the function does know it's __name__, and introducing that topic at this point in the tutorial would be confusing and unnecessary.  (NB: one could also say "referenced" and "reference" rather than "pointed to" and "point to"; I'm not sure which is more in line with the rest of the tutorial).

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

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

From report at bugs.python.org  Sun Nov 13 14:14:21 2016
From: report at bugs.python.org (Viorel Tabara)
Date: Sun, 13 Nov 2016 19:14:21 +0000
Subject: [docs] [issue28677] difficult to parse sentence structure in "When
 an instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1479064461.55.0.577384074812.issue28677@psf.upfronthosting.co.za>


Viorel Tabara added the comment:

David, that sounds clear enough to me, thanks. However, English isn't my first 
language so I can't comment on the grammatical subtleties.

----------

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

From report at bugs.python.org  Sun Nov 13 17:05:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 13 Nov 2016 22:05:39 +0000
Subject: [docs] [issue28678] tarfile extract docs inconsistent naming of
 parameter numeric_owner or numeric_only
In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za>
Message-ID: <1479074739.53.0.182676067545.issue28678@psf.upfronthosting.co.za>


Martin Panter added the comment:

The offending commit is revision 6b70f16d585a. The true name is numeric_owner; numeric_only is wrong. The name also needs fixing in Doc/whatsnew/3.5.rst.

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

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

From report at bugs.python.org  Sun Nov 13 18:53:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 13 Nov 2016 23:53:23 +0000
Subject: [docs] [issue28678] tarfile extract docs inconsistent naming of
 parameter numeric_owner or numeric_only
In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za>
Message-ID: <20161113235320.59692.24171.F7078C48@psf.io>


Roundup Robot added the comment:

New changeset 4aca14dbb66d by Martin Panter in branch '3.5':
Issue #28678: Fix references to numeric_owner parameter
https://hg.python.org/cpython/rev/4aca14dbb66d

New changeset 5efa1a39ee59 by Martin Panter in branch '3.6':
Issue #28678: Merge parameter name from 3.5 into 3.6
https://hg.python.org/cpython/rev/5efa1a39ee59

New changeset 817a003ecdc6 by Martin Panter in branch 'default':
Issue #28678: Merge parameter name from 3.6
https://hg.python.org/cpython/rev/817a003ecdc6

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

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

From report at bugs.python.org  Sun Nov 13 19:29:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Nov 2016 00:29:36 +0000
Subject: [docs] [issue28678] tarfile extract docs inconsistent naming of
 parameter numeric_owner or numeric_only
In-Reply-To: <1478986997.97.0.266901565228.issue28678@psf.upfronthosting.co.za>
Message-ID: <1479083376.82.0.548688009803.issue28678@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Lewis

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

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

From report at bugs.python.org  Sun Nov 13 19:58:47 2016
From: report at bugs.python.org (Joshua Jay Herman)
Date: Mon, 14 Nov 2016 00:58:47 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479085126.62.0.897931113496.issue24459@psf.upfronthosting.co.za>


Joshua Jay Herman added the comment:

ping

----------

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

From report at bugs.python.org  Sun Nov 13 20:45:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 14 Nov 2016 01:45:52 +0000
Subject: [docs] [issue8840] truncate() semantics changed in 3.1.2
In-Reply-To: <1275005546.82.0.0795236723796.issue8840@psf.upfronthosting.co.za>
Message-ID: <1479087951.93.0.504746021883.issue8840@psf.upfronthosting.co.za>


Martin Panter added the comment:

In general I agree with the doc strings giving the main details, and leaving smaller details for the reference documentation. Maybe for concrete implementations like BytesIO, it is not worth saying the expanded contents are undefined. One other way to make them shorter is to drop ?as reported by tell()?.

diff --git a/Lib/_pyio.py b/Lib/_pyio.py
@@ -344,10 +344,12 @@
     def truncate(self, pos=None):
+        """Resize stream to at most size bytes.

Wouldn?t it be more correct to say ?at most ?pos? bytes??

You should avoid mentioning byte sizes for TextIOBase.truncate(); see Issue 25849. Also applies to the StringIO subclasses.

+        Position in the stream is left unchanged.  Size defaults to

I think it should be ?The position in the stream . . .?, to match the other full sentences in these paragraphs.

----------

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

From report at bugs.python.org  Sun Nov 13 20:57:56 2016
From: report at bugs.python.org (Antony Lee)
Date: Mon, 14 Nov 2016 01:57:56 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479088676.99.0.854439713335.issue24459@psf.upfronthosting.co.za>


Changes by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

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

From report at bugs.python.org  Mon Nov 14 00:13:35 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Nov 2016 05:13:35 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1479100415.33.0.795007419691.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The introduction of run() and its presentation as the preferred interface has effectively reversed much of the progress that had been made in actually making the subprocess module approachable for the simplest use cases like https://twitter.com/fuzzychef/status/798025538237382656 (i.e. the exact case that "subprocess.call()" handles)

It does make sense to have run() as an intermediate tier of complexity between the base trio of call/check_call/check_output, and the full configurability of Popen, so it isn't the introduction of the API itself that's problematic, just the way we're currently presenting it.

----------
priority: normal -> high

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

From report at bugs.python.org  Mon Nov 14 00:47:55 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 14 Nov 2016 05:47:55 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1479102475.03.0.625184367612.issue27050@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I still feel that having one function with various options is easier to explain than three separate functions with awkward names and limited use cases (e.g. no capturing output without checking the exit code). The tweeter you replied to said he didn't like subprocess.call(). If you really think the trio is a better starting point, though, you're the one with the power to change the docs ;-)

There's more awkwardness in the subprocess API; I suspect that what that tweeter wants is something built around an event loop - like Node - so you can handle output incrementally using events. That's not something that we can easily fix in subprocess, because we don't have a default event loop to attach subprocesses to.

----------

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

From report at bugs.python.org  Mon Nov 14 05:53:18 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 14 Nov 2016 10:53:18 +0000
Subject: [docs] [issue27050] Demote run() below the high level APIs in
 subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1479120798.62.0.265494154834.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Indeed, further discussion showed that what they were after was something more along the lines of sarge.Capture: http://sarge.readthedocs.io/en/latest/overview.html#main-features

That is, the ability to start the subprocess running in the background, and access the output line-by-line, but with the precise mechanics of how that works being a hidden implementation detail (just as concurrent.futures hides the details of the inter-process communication for function calls).

----------

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

From report at bugs.python.org  Mon Nov 14 06:28:39 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 14 Nov 2016 11:28:39 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479122919.52.0.769662122436.issue24459@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the updated patch, Joshua. I will review and commit it this week.

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

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

From report at bugs.python.org  Mon Nov 14 14:49:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Nov 2016 19:49:44 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161114194941.4911.2357.D21927E4@psf.io>


Roundup Robot added the comment:

New changeset 993215342a95 by Yury Selivanov in branch '3.6':
Issue #28635: what's new in 3.6: add a few more notes on typing
https://hg.python.org/cpython/rev/993215342a95

New changeset c3b4eea73615 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/c3b4eea73615

----------

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

From report at bugs.python.org  Tue Nov 15 11:03:31 2016
From: report at bugs.python.org (Ulrich Petri)
Date: Tue, 15 Nov 2016 16:03:31 +0000
Subject: [docs] [issue28697] asyncio.Lock, Condition,
 Semaphore docs don't mention `async with` syntax
Message-ID: <1479225811.34.0.0222578393475.issue28697@psf.upfronthosting.co.za>


New submission from Ulrich Petri:

The docs for asyncio's Lock, Condition and Semaphore should use the new clean `async with lock:` syntax instead of the older (and IMO rather ugly) `with (yield from lock):` version.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 280861
nosy: docs at python, gvanrossum, ulope, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Nov 15 13:53:12 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 15 Nov 2016 18:53:12 +0000
Subject: [docs] [issue28698] Python 3.x ctypes c_wchar_p return is different
 from official documentation example
In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za>
Message-ID: <1479235992.16.0.561556781345.issue28698@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The repr can't automatically dereference the string at the address because it may be an invalid pointer. ctypes was developed on Windows, for which, in Python 2, it (ab)uses the obsolete IsBadStringPtr[A|W] function [1]. This function should never be used in a multithreaded process. 

On POSIX systems, the repr of c_char_p was special-cased to avoid dereferencing the pointer, but c_wchar_p was overlooked, and you can still easily crash Python 2 like this:

    Python 2.7.12 (default, Jul  1 2016, 15:12:24) 
    [GCC 5.4.0 20160609] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import ctypes
    >>> ctypes.c_wchar_p(1)
    Segmentation fault (core dumped

A while back the bogus use of WinAPI IsBadStringPtr was removed from the Python 3 branch, but apparently the docs weren't updated to reflect this change. I'm changing this to a documentation issue.

[1]: https://msdn.microsoft.com/en-us/library/aa366714

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, eryksun
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Nov 15 13:57:57 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 15 Nov 2016 18:57:57 +0000
Subject: [docs] [issue28698] Python 3.x ctypes c_wchar_p return is different
 from official documentation example
In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za>
Message-ID: <1479236277.21.0.0574855895966.issue28698@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 15 14:24:19 2016
From: report at bugs.python.org (Alex Wang)
Date: Tue, 15 Nov 2016 19:24:19 +0000
Subject: [docs] [issue28698] Python 3.x ctypes c_wchar_p return is different
 from official documentation example
In-Reply-To: <1479236277.21.0.0574855895966.issue28698@psf.upfronthosting.co.za>
Message-ID: <CABs28K+HstwaoFEc_9+S5metfVnu-xYfVdC6D98VT5jS1F+=6g@mail.gmail.com>


Alex Wang added the comment:

Hi Eryk,

Thanks a lot for quick reply~

This is about the bug I filed: http://bugs.python.org/issue28698#

I may still need your help to have a look the original case when I caught
this issue:

?I am writing some test automation which call C DLL from Python, the C
function is something like:

MEASURE_API int InitTester(char *ipAddress)

?So I need to pass an IP address string (for example, 192.168.100.100) from
Python in ctypes to this function. For non-const char in C, I used

c_ipAddress = create_string_buffer(b'192.168.100.100')
lib.InitTester(c_ipAddress)

?But error code returned indicate that the parameter passing is incorrect,
then I traced back and found then reported the c_char_p/c_wchar_p issue.?

Also tried
?c_ipAddress = create_unicode_buffer('192.168.100.100')
c_ipAddress = c_char_p(b'192.168.100.100')
c_ipAddress = c_wchar_p('192.168.100.100')?

?But none of them working... I had called other function to this C DLL
passing c_int(). c_bool(), c_void_p() and etc. they are all working as
expected, only string related have this issue.

Therefore, any idea how write the correct assignment and pass it to ?C DLL
for this case in Python 3.5? Any hint would be great helpful.

Thank you in advance~

BR,
Alex

On Tue, Nov 15, 2016 at 10:57 AM, Eryk Sun <report at bugs.python.org> wrote:

>
> Changes by Eryk Sun <eryksun+pybugs at gmail.com>:
>
>
> ----------
> keywords: +easy
> stage:  -> needs patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28698>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Nov 15 14:40:47 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 15 Nov 2016 19:40:47 +0000
Subject: [docs] [issue28698] Python 3.x ctypes c_wchar_p return is different
 from official documentation example
In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za>
Message-ID: <1479238847.72.0.604964927179.issue28698@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The issue tracker isn't a forum to answer general programming questions. Please ask this on python-list, and I'll try to help you there.

----------

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

From report at bugs.python.org  Tue Nov 15 14:53:32 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 15 Nov 2016 19:53:32 +0000
Subject: [docs] [issue28698] Python 3.x ctypes c_wchar_p return is different
 from official documentation example
In-Reply-To: <1479230636.43.0.863548306007.issue28698@psf.upfronthosting.co.za>
Message-ID: <1479239612.2.0.450913459825.issue28698@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


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

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

From report at bugs.python.org  Tue Nov 15 19:59:42 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Wed, 16 Nov 2016 00:59:42 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
Message-ID: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>


New submission from Patrick Lehmann:

Why does e.g. configparser.ConfigParser contain doc strings with Sphinx incompatible markup?

The markup starts with back-tick, but ends with a single quote.

Example:
https://github.com/python/cpython/blob/master/Lib/configparser.py?ts=2#L26

Sphinx writes these messages:
D:\git\PoC\py\lib\ExtendedConfigParser\__init__.py:docstring of lib.ExtendedConfigParser.ExtendedConfigParser.read_file:3: WARNING: Inline interpreted text or phrase reference start-str
ing without end-string.

Note: ExtendedConfigParser is class derived from configparser.ConfigParser. Inherited methods get documented too.

------------------------
Btw. I have some improvements for this class, how can I contribute them? Who is the maintainer for this class? Please contact me: Patrick.Lehmann at tu-dresden.de

The improved version is available at GitHub: https://github.com/Paebbels/ExtendedConfigParser?ts=2

----------
assignee: docs at python
components: Documentation
messages: 280907
nosy: Patrick Lehmann, docs at python
priority: normal
severity: normal
status: open
title: Sphinx incompatible markup in configparser.ConfigParser.
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Nov 16 01:53:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Nov 2016 06:53:54 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479279234.91.0.782349063105.issue28710@psf.upfronthosting.co.za>


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


----------
keywords: +easy
stage:  -> needs patch
versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Wed Nov 16 02:37:22 2016
From: report at bugs.python.org (Daisuke Miyakawa)
Date: Wed, 16 Nov 2016 07:37:22 +0000
Subject: [docs] [issue28713] Recent tutorial for recent Python3 still uses
 IOError.
Message-ID: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za>


New submission from Daisuke Miyakawa:

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


for arg in sys.argv[1:]:
    try:
        f = open(arg, 'r')
    except IOError:
        print('cannot open', arg)
    else:
        print(arg, 'has', len(f.readlines()), 'lines')
        f.close()


Although IOError is still available as an alias to OSError, it should not be used in the tutorial, I believe.

----------
assignee: docs at python
components: Documentation
messages: 280924
nosy: dmiyakawa, docs at python
priority: normal
severity: normal
status: open
title: Recent tutorial for recent Python3 still uses IOError.
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 16 02:43:24 2016
From: report at bugs.python.org (Daisuke Miyakawa)
Date: Wed, 16 Nov 2016 07:43:24 +0000
Subject: [docs] [issue28713] Recent tutorial for recent Python3 still uses
 IOError.
In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za>
Message-ID: <1479282204.74.0.517545870351.issue28713@psf.upfronthosting.co.za>


Changes by Daisuke Miyakawa <d.miyakawa at gmail.com>:


----------
versions: +Python 3.6

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

From report at bugs.python.org  Wed Nov 16 10:00:35 2016
From: report at bugs.python.org (George Fischhof)
Date: Wed, 16 Nov 2016 15:00:35 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write() documentaion
Message-ID: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>


New submission from George Fischhof:

Hi There, 

I used configparser.ConfigParser.write() to update a config file.
And I found that my config wa duplicated.

The file was opened with mode 'r+' 
I figured out that write (I mean the write method of configparser) writes at actual file position.

I issued a file.seek(0) command before write and the result was good.


So I think documentaion should advice to user to reopen the file with mode 'w' or to issue a file.seek(0) command before using the ConfigParser.write()


I used the following python version on windows:
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit (Intel)] on win32

affected documentation:
https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser.write

Best Regards,
George Fischhof

----------
assignee: docs at python
components: Documentation
messages: 280960
nosy: docs at python, georgefischhof
priority: normal
severity: normal
status: open
title: Addition to Documentation of configparser.ConfigParser.write() documentaion
versions: Python 3.5

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

From report at bugs.python.org  Wed Nov 16 10:02:21 2016
From: report at bugs.python.org (George Fischhof)
Date: Wed, 16 Nov 2016 15:02:21 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write()
In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>
Message-ID: <1479308541.06.0.0187198609227.issue28714@psf.upfronthosting.co.za>


Changes by George Fischhof <george at fischhof.hu>:


----------
title: Addition to Documentation of configparser.ConfigParser.write() documentaion -> Addition to Documentation of configparser.ConfigParser.write()

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

From report at bugs.python.org  Wed Nov 16 10:22:23 2016
From: report at bugs.python.org (Kushal Das)
Date: Wed, 16 Nov 2016 15:22:23 +0000
Subject: [docs] [issue28713] Recent tutorial for recent Python3 still uses
 IOError.
In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za>
Message-ID: <1479309743.19.0.00288711575138.issue28713@psf.upfronthosting.co.za>


Kushal Das added the comment:

This following one line change should fix this one.

----------
keywords: +patch
nosy: +kushal.das
Added file: http://bugs.python.org/file45504/issue28713.patch

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

From report at bugs.python.org  Wed Nov 16 10:49:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Nov 2016 15:49:34 +0000
Subject: [docs] [issue28713] Recent tutorial for recent Python3 still uses
 IOError.
In-Reply-To: <1479281842.16.0.362729785805.issue28713@psf.upfronthosting.co.za>
Message-ID: <20161116154930.89451.65871.1D3EB9AD@psf.io>


Roundup Robot added the comment:

New changeset 3375c111d1ff by Kushal Das in branch '3.6':
Closes #28713 uses OSError in the tutorial
https://hg.python.org/cpython/rev/3375c111d1ff

New changeset 15e5e476e4a1 by Kushal Das in branch 'default':
Closes #28713 uses OSError in the tutorial
https://hg.python.org/cpython/rev/15e5e476e4a1

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

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

From report at bugs.python.org  Wed Nov 16 17:50:03 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Wed, 16 Nov 2016 22:50:03 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479336603.01.0.694269379468.issue28710@psf.upfronthosting.co.za>


Patrick Lehmann added the comment:

How can I supply a fix?

I have a branch with lots of fixes.
https://github.com/Paebbels/cpython/tree/paebbels/issue-28710?ts=2

Why don't you accept pull requests via GitHub?


Kind regards
    Patrick

----------

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

From report at bugs.python.org  Wed Nov 16 18:00:51 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 16 Nov 2016 23:00:51 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479337250.97.0.953010738142.issue28710@psf.upfronthosting.co.za>


R. David Murray added the comment:

We will accept github pull requests in the future (the transition is underway).

For now, you can create a diff file (using hg diff by preference, but git diff will work) and uploaded it to the issue.  For this issue, please only upload the docstring changes.  For other enhancement suggestions, open separate issues.  (This would be true even if we were accepting pull requests).

The existing docstring markup is probably a remnant of the days when the documentation was written in LaTeX.

Lukasz Langa is the current maintainer of this module.

----------
nosy: +lukasz.langa, r.david.murray

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

From report at bugs.python.org  Wed Nov 16 18:23:34 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Wed, 16 Nov 2016 23:23:34 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479338614.44.0.635081562082.issue28710@psf.upfronthosting.co.za>


Patrick Lehmann added the comment:

Here is the patch file created with:
PS> git diff > docstring_markup.patch

This patchfile effects all files with this markup in the CPython repository.


Kind regards
    Patrick

----------
keywords: +patch
Added file: http://bugs.python.org/file45515/docstring_markup.patch

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

From report at bugs.python.org  Wed Nov 16 20:19:42 2016
From: report at bugs.python.org (Rajiv Bakulesh Shah)
Date: Thu, 17 Nov 2016 01:19:42 +0000
Subject: [docs] [issue28722] doctest example exit status
Message-ID: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za>


New submission from Rajiv Bakulesh Shah:

It might be nice if the doctest example set the appropriate exit status.  Apologies if this is beyond the scope of the example, but I thought it might be good practice.

Here is the file:
https://github.com/python/cpython/blob/master/Doc/library/doctest.rst

Here is the example as written:
if __name__ == "__main__":
    import doctest
    doctest.testmod()

Here is my proposal:
if __name__ == '__main__':
    import doctest
    import sys
    results = doctest.testmod()
    sys.exit(bool(results.failed))

I'm happy to fork the repo and submit a PR, if that makes things easier.  I'm not familiar with the protocol here.  Thanks for the great work!

----------
assignee: docs at python
components: Documentation
messages: 281015
nosy: Brainix, docs at python
priority: normal
severity: normal
status: open
title: doctest example exit status
versions: Python 3.6

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

From report at bugs.python.org  Fri Nov 18 08:17:52 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Fri, 18 Nov 2016 13:17:52 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
Message-ID: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>


New submission from Micha? Bultrowicz:

Documentation of mock_open doesn't say how to use it in real-life test situations (when you're probably not mocking in __main__). I've spent some time scratching my head and googling for the way to mock-out the "open" function, want to spare other people the hassle.

The thing is that "open" needs to be mocked out from the magical "builtins" module, and not from the place of usage (like when mocking everything that's not built-in). So it's not obvious how to do that, especially that the example with __main__ makes it look like the normal mocking approach should work.

I still don't fully understand why mocking "__main__.open" can work from interpreter, but that's a different thing...

----------
assignee: docs at python
components: Documentation
files: mock_open_doc.patch
keywords: patch
messages: 281114
nosy: butla, docs at python
priority: normal
severity: normal
status: open
title: Show how to use mock_open in modules other that __main__
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45533/mock_open_doc.patch

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

From report at bugs.python.org  Fri Nov 18 11:32:34 2016
From: report at bugs.python.org (Eric Leadbetter)
Date: Fri, 18 Nov 2016 16:32:34 +0000
Subject: [docs] [issue28736] multiprocessing.Lock() no longer has .acquire()
Message-ID: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za>


New submission from Eric Leadbetter:

The documentation on the multiprocessing library in Python 3 uses Lock.acquire()/Lock.release() in the example for primitive synchronization (https://docs.python.org/3/library/multiprocessing.html#synchronization-between-processes). Lock() has been changed in Python 3 to use coroutines and so the documentation should replace the call to Lock.acquire() with an appropriate yield statement.

----------
assignee: docs at python
components: Documentation
messages: 281141
nosy: Eric Leadbetter, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.Lock() no longer has .acquire()
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Nov 18 11:47:36 2016
From: report at bugs.python.org (Sam Gross)
Date: Fri, 18 Nov 2016 16:47:36 +0000
Subject: [docs] [issue28737] Document that tp_dealloc handler must call
 PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Message-ID: <1479487656.43.0.616591816842.issue28737@psf.upfronthosting.co.za>


New submission from Sam Gross:

In general, an a PyTypeObject that has Py_TPFLAGS_HAVE_GC set must call PyObject_GC_UnTrack() before it frees any PyObject* references it owns. The only reference to this requirement I found is in https://docs.python.org/3/c-api/gcsupport.html#c._PyObject_GC_TRACK.

This requirement should be documented in:

1. https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_dealloc
2. https://docs.python.org/3/extending/newtypes.html

A call to PyObject_GC_UnTrack() should also be added to he official "noddy4" example. Currently, the example is incorrect and can crash if a referred-to object triggers a GC from it's destructor. See the following example which segfaults:

https://github.com/colesbury/noddy

It may be worthwhile to have _Py_Dealloc call PyObject_GC_UnTrack() if the PyTypeObject has Py_TPFLAGS_HAVE_GC set. Considering that the official Python extension example is missing the call, it seems likely that extension writers often forget to include it.

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 281146
nosy: colesbury, docs at python
priority: normal
severity: normal
status: open
title: Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
versions: Python 3.5

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

From report at bugs.python.org  Fri Nov 18 12:38:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Nov 2016 17:38:57 +0000
Subject: [docs] [issue28677] difficult to parse sentence structure in "When
 an instance attribute is referenced that isn't a data attribute"
In-Reply-To: <1478986337.93.0.398450030776.issue28677@psf.upfronthosting.co.za>
Message-ID: <1479490737.94.0.446625434602.issue28677@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

David's wording looks good.

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

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

From report at bugs.python.org  Fri Nov 18 12:45:26 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Nov 2016 17:45:26 +0000
Subject: [docs] [issue28736] multiprocessing.Lock() no longer has .acquire()
In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za>
Message-ID: <1479491126.57.0.792219790815.issue28736@psf.upfronthosting.co.za>


R. David Murray added the comment:

What gives you the idea that the multiprocessing Lock implementation has been changed?  Are you confusing the asyncio Lock with the threading Lock?  Is there a documentation crosslink somewhere that is going to the wrong place?

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

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

From report at bugs.python.org  Fri Nov 18 13:25:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Nov 2016 18:25:26 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479493526.39.0.448501167892.issue28681@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It took me a moment to realize that 'value of the function name' meant 'the function object associated with the name'.  I think David's rewrite is a substantial improvement.  I would just change the end 'can be used as a function' to 'can be used to access the function.'

'Renaming' is wrong to me because it implies invalidation of the previous name. 'Alternate name' is more accurate.

I agree that 'alias' is better, but also that it is a bit problematical*.  'Alias' is distinct from 'legal name'. The closest analogy to 'legal name' is 'definition name' (.__name__ attribute).  But definition names are distinct from bound names, only some objects have definition names, and when they do, they can be renamed if and only if the object is coded in Python. 

I don't understand the relevance of the middle sentence
   "The interpreter recognizes the object pointed to by that
   name as a user-defined function."
All objects can be given multiple names.  In this context, the difference between C and Python coded names is whether the .__name__ attribute can be rebound, and that attribute is not part of the discussion here.  The paragraph introduces this code example, which has nothing to do with .__name__.

   >>> fib
   <function fib at 10042ed0>
   >>> f = fib
   >>> f(100)
   0 1 1 2 3 5 8 13 21 34 55 89

(* Steven, I would say that both 'x' and 'y' in your example are aliases for the int 1.  But I understand the other viewpoint.)

----------
nosy: +terry.reedy
stage:  -> needs patch
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 18 13:45:18 2016
From: report at bugs.python.org (Eric Leadbetter)
Date: Fri, 18 Nov 2016 18:45:18 +0000
Subject: [docs] [issue28736] multiprocessing.Lock() no longer has .acquire()
In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za>
Message-ID: <1479494718.17.0.12950271555.issue28736@psf.upfronthosting.co.za>


Eric Leadbetter added the comment:

It was a typographical error on my part. My mistake.

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

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

From report at bugs.python.org  Fri Nov 18 14:03:43 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 18 Nov 2016 19:03:43 +0000
Subject: [docs] [issue28736] multiprocessing.Lock() no longer has .acquire()
In-Reply-To: <1479486754.06.0.767072130944.issue28736@psf.upfronthosting.co.za>
Message-ID: <1479495823.04.0.377753381942.issue28736@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved

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

From report at bugs.python.org  Fri Nov 18 14:38:36 2016
From: report at bugs.python.org (Wojtek Ruszczewski)
Date: Fri, 18 Nov 2016 19:38:36 +0000
Subject: [docs] [issue28738] Document SIGBREAK as argument for signal()
 under Windows.
Message-ID: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za>


New submission from Wojtek Ruszczewski:

SIGBREAK should be listed as acceptable for signal.signal() under Windows.

Some context. Registering a handler for SIGBREAK may be useful as this is the signal that generating CTRL_BREAK_EVENT results in (and the latter combined with the CREATE_NEW_PROCESS_GROUP flag might be the closest that one can get to terminating a process group).

Some pointers:
* The changed documentation fragment: https://docs.python.org/3/library/signal.html#signal.signal.
* MSDN doesn't say so much about SIGBREAK: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682541(v=vs.85).aspx.
* SIGBREAK was added to the signal module with #466877.
* The signal number check looks as follows: https://github.com/python/cpython/blob/3.6/Modules/signalmodule.c#L402.

----------
assignee: docs at python
components: Documentation, Windows
files: sigbreak.patch
keywords: patch
messages: 281159
nosy: docs at python, paul.moore, steve.dower, tim.golden, wrwrwr, zach.ware
priority: normal
severity: normal
status: open
title: Document SIGBREAK as argument for signal() under Windows.
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45538/sigbreak.patch

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

From report at bugs.python.org  Fri Nov 18 15:16:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Nov 2016 20:16:48 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479500208.09.0.538853289622.issue28710@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As far as I looked, the patch changes `xyz' in docstrings and quotes to ``xyz``.  A rst expert should verify that this is correct.  In printed strings, `zyz' is changed to 'xyz', which I consider to be correct.

Before applying this, I would want to review in Rietveld, with side by side diff and changes color marked.  However, Rietveld does not like the patch and there is no 'review' button.  I thought it might be the git format, but I found another git patch that did have a review button.  When I downloaded and tried to apply (to default), hg says that there is no diff.  I don't see the problem, but we cannot currently use a patch that does not apply in hg.

Patrick, in order to use patches, we require Contributor Agreements.
https://www.python.org/psf/contrib/
There is an electronic form that makes submission easy.
https://www.python.org/psf/contrib/contrib-form/

----------
nosy: +terry.reedy
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Nov 18 15:36:58 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Nov 2016 20:36:58 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479501418.04.0.972905405025.issue28710@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think that we do not generally use ReST markup in our docstrings.  So replacing `x' with 'x' would be more correct, I think.  In many cases the quotes could just be omitted entirely.

The patch command says:

  patch unexpectedly ends in middle of line
  patch: **** Only garbage was found in the patch input.

----------

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

From report at bugs.python.org  Fri Nov 18 16:51:56 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Nov 2016 21:51:56 +0000
Subject: [docs] [issue28741] PEP 498: single '}' is not allowed
Message-ID: <1479505916.83.0.442816788413.issue28741@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

The PEP should document the "single '}' is not allowed" error.

----------
assignee: docs at python
components: Documentation
messages: 281173
nosy: docs at python, eric.smith, yselivanov
priority: normal
severity: normal
status: open
title: PEP 498: single '}' is not allowed
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Nov 18 22:30:48 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Sat, 19 Nov 2016 03:30:48 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479526248.71.0.640863880709.issue28710@psf.upfronthosting.co.za>


Patrick Lehmann added the comment:

Hello,

I used this regexp on all files:
--------------------------------------
match pattern: `([A-Za-z0-9_]+)'
replace pattern ``\1``
--------------------------------------
I assumed that only identifiers where quoted in such way. I think my editor found around 139 matches in the whole CPython repository.

I found some of these markup in non docstring strings, which I reverted as far as I found them by manually reviewing all changed files.

For a colored diff, see my Git branch: https://github.com/Paebbels/cpython/commit/6d3f348f71b5b0ae9fbfcb8fdbba72dc5fac428a?ts=2
There is also a PR-, commit-, and line-based comment feature box GitHub.

How you solve it is up to you, but I would like to get rid of hundreds of warnings in my Sphinx runs, when modules are inherting code (and docstrings) from Python.

Kind regards
    Patrick

----------

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

From report at bugs.python.org  Fri Nov 18 22:39:44 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Sat, 19 Nov 2016 03:39:44 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479526784.67.0.633927937364.issue28710@psf.upfronthosting.co.za>


Patrick Lehmann added the comment:

.... I signed the CLA.

----------

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

From report at bugs.python.org  Sat Nov 19 00:19:37 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 19 Nov 2016 05:19:37 +0000
Subject: [docs] [issue28681] About function renaming in the tutorial
In-Reply-To: <1479008196.92.0.673244295473.issue28681@psf.upfronthosting.co.za>
Message-ID: <1479532777.19.0.779270636267.issue28681@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

Obligatory link: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ :-P
Yes, Python objects are simpler than people, but still not completely trivial. The core issue is "who does the calling".

Even one's native language might subtly (in Orwell sense) alter what they mean the name is. English question "What is your name?" is usually translated into Croatian (and some other Slavic languages) as "Kako se zove??", literally "how do you call yourself". In some other languages, it's "how should I call you". I think you agree those are three different concepts. And I think most disagreements between people in these discussions stem from those cultural differences. (Even people who consider English their native language might still have cultural differences, since English is spoken so widely.)

In Python, the most important distinction is "name as own identity"(1) vs "name as handle for calling"(2). Of course, we all know that each of these concepts have disadvantages, and as such, cannot serve completely. name(1) is not something all objects have (but e.g. functions and classes do), while name(2) is external to the object - each of existing namespaces might or might not have a way (or three, or infinitely many) to refer to it. And all those ways are not considered to be known to the object itself.

Since this concrete example speaks about names of functions defined with a def statement, those concepts coincide, and that's why some people have thought it speaks about name(1) and some others have thought it speaks about name(2). If we want to be completely honest, we should clarify that "name" is used in two ways, and that later text speaks only about name(2). But it might be too much for beginners. In that case, we should probably avoid mention name(1) sense until much later, and speak only of names as "name(2)".

----------
nosy: +veky

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

From report at bugs.python.org  Sat Nov 19 00:56:25 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 19 Nov 2016 05:56:25 +0000
Subject: [docs] [issue28745] Python 3.5.2 "from ... import" statement is
 different from official documentation
Message-ID: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za>


New submission from woo yoo:

I've experiment with the statement,however the result did not match the official description.
I created a namespace package named l007,  within which submodule named l009 was placed.I typed "from l007 import l009" in the interpreter, the execution was ok, while in which case a ImportError should have been raised.
Is my understanding wrong?

----------
assignee: docs at python
components: Documentation
files: ??.PNG
messages: 281202
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Python 3.5.2 "from ... import" statement is different from official documentation
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45544/??.PNG

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

From report at bugs.python.org  Sat Nov 19 01:05:32 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Nov 2016 06:05:32 +0000
Subject: [docs] [issue28745] Python 3.5.2 "from ... import" statement is
 different from official documentation
In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za>
Message-ID: <1479535532.59.0.285206052715.issue28745@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Please don't post screen shots of text. Copy and paste the text into the bug report. Some people (those who are blind, visually impaired or using a screen-reader for some other reason) cannot see the screen shot, and even those who can prefer to deal with text that can be copied and pasted, not pixels.

Please show (in text, not a picture) the layout and contents of your package, the exact Python code you used, the result you expected, and the result you actually got. If an import succeeded that you expected to fail, please print module.__file__ to ensure that you have imported the module you expected to import.

Ideally anyone (fully sighted or not) should be able to copy and paste your code into the Python interpreter and determine whether or not they get the same results as you.

Thank you.

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

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

From report at bugs.python.org  Sat Nov 19 01:07:48 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Nov 2016 06:07:48 +0000
Subject: [docs] [issue28745] Python 3.5.2 "from ... import" statement is
 different from official documentation
In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za>
Message-ID: <1479535668.28.0.0520769336143.issue28745@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

If you're quoting from the docs, its a good idea to give the URL to *which* documentation you are reading, not just a copy of the text.

----------

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

From report at bugs.python.org  Sat Nov 19 01:25:13 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 19 Nov 2016 06:25:13 +0000
Subject: [docs] [issue28745] Python 3.5.2 "from ... import" statement is
 different from official documentation
In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za>
Message-ID: <1479536713.46.0.89905180411.issue28745@psf.upfronthosting.co.za>


woo yoo added the comment:

The link associated with the documentation is https://docs.python.org/3/reference/simple_stmts.html#import.

My package layout is :
  --l007
    --l009.py
My code is :
  >from l007 import l009
The excution was ok, which was not the case i had expected.

----------

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

From report at bugs.python.org  Sat Nov 19 01:52:26 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 19 Nov 2016 06:52:26 +0000
Subject: [docs] [issue28745] Python 3.5.2 "from ... import" statement is
 different from official documentation
In-Reply-To: <1479534985.73.0.593618849184.issue28745@psf.upfronthosting.co.za>
Message-ID: <1479538346.0.0.663519626274.issue28745@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Why is this unexpected? Per the docs, the process is:

    find the module specified in the from clause, loading and initializing it if necessary;
    for each of the identifiers specified in the import clauses:
        check if the imported module has an attribute by that name
***     if not, attempt to import a submodule with that name and then check the imported module again for that attribute
        if the attribute is not found, ImportError is raised.
        otherwise, a reference to that value is stored in the local namespace, using the name in the as clause if it is present, otherwise using the attribute name

The *** is next to where it ends up in the tree; it found the l007 package, determined it had no attribute named l009, determined it did have a module of that name, and imported it. What were you expecting? For the record, it would be nice if you'd used a name that didn't begin with a lowercase L; it makes it look like the module is named entirely with digits (which would be illegal).

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

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

From report at bugs.python.org  Sat Nov 19 12:12:07 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Nov 2016 17:12:07 +0000
Subject: [docs] [issue28741] PEP 498: single '}' is not allowed
In-Reply-To: <1479505916.83.0.442816788413.issue28741@psf.upfronthosting.co.za>
Message-ID: <1479575527.84.0.758911306109.issue28741@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Thanks. Fixed in the pep repo in 4e86033.

----------
assignee: docs at python -> eric.smith
resolution:  -> fixed
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Sat Nov 19 18:33:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Nov 2016 23:33:08 +0000
Subject: [docs] [issue27583] configparser: modifying default_section at
 runtime
In-Reply-To: <1469105653.63.0.572086425799.issue27583@psf.upfronthosting.co.za>
Message-ID: <1479598388.95.0.0612810048164.issue27583@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Nov 19 20:10:18 2016
From: report at bugs.python.org (Antony Lee)
Date: Sun, 20 Nov 2016 01:10:18 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479604218.61.0.0146214470129.issue24459@psf.upfronthosting.co.za>


Antony Lee added the comment:

PYTHONUSERBASE is also missing.

----------
nosy: +Antony.Lee

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

From report at bugs.python.org  Sat Nov 19 20:10:36 2016
From: report at bugs.python.org (Antony Lee)
Date: Sun, 20 Nov 2016 01:10:36 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479604236.28.0.807654108769.issue24459@psf.upfronthosting.co.za>


Changes by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

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

From report at bugs.python.org  Sat Nov 19 22:22:20 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 20 Nov 2016 03:22:20 +0000
Subject: [docs] [issue27998] Bytes paths now are supported in os.scandir()
 on Windows
In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za>
Message-ID: <1479612139.91.0.191514001721.issue27998@psf.upfronthosting.co.za>


Steve Dower added the comment:

Doc change looks good to me.

----------

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

From report at bugs.python.org  Sat Nov 19 22:57:19 2016
From: report at bugs.python.org (Joshua Jay Herman)
Date: Sun, 20 Nov 2016 03:57:19 +0000
Subject: [docs] [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1479614239.02.0.796215763291.issue24459@psf.upfronthosting.co.za>


Joshua Jay Herman added the comment:

Thanks for pointing out that wasn't in the latest patch this has been corrected.

----------
Added file: http://bugs.python.org/file45552/corrected.patch

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

From report at bugs.python.org  Sun Nov 20 01:25:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Nov 2016 06:25:32 +0000
Subject: [docs] [issue27998] Bytes paths now are supported in os.scandir()
 on Windows
In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za>
Message-ID: <20161120062528.5752.48253.09FB70D4@psf.io>


Roundup Robot added the comment:

New changeset ac63c70635db by Serhiy Storchaka in branch '3.6':
Issue #27998: Documented bytes paths support on Windows.
https://hg.python.org/cpython/rev/ac63c70635db

New changeset 26195e07fcc5 by Serhiy Storchaka in branch 'default':
Issue #27998: Documented bytes paths support on Windows.
https://hg.python.org/cpython/rev/26195e07fcc5

----------

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

From report at bugs.python.org  Sun Nov 20 01:26:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 06:26:46 +0000
Subject: [docs] [issue27998] Bytes paths now are supported in os.scandir()
 on Windows
In-Reply-To: <1473236470.81.0.837469962495.issue27998@psf.upfronthosting.co.za>
Message-ID: <1479623206.14.0.684915458605.issue27998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Steve.

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

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

From report at bugs.python.org  Sun Nov 20 05:29:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 10:29:58 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
Message-ID: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds the documentation of PyUnicode_Translate() and fixes the documentation of other mapping codec APIs (it is incorrect in Python 3): PyUnicode_DecodeCharmap(), PyUnicode_AsCharmapString(), PyUnicode_EncodeCharmap(), and PyUnicode_TranslateCharmap().

----------
assignee: docs at python
components: Documentation, Unicode
files: docs-PyUnicode_Translate.patch
keywords: patch
messages: 281259
nosy: docs at python, ezio.melotti, haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fixed the documentation of the mapping codec APIs
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45557/docs-PyUnicode_Translate.patch

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

From report at bugs.python.org  Sun Nov 20 06:10:24 2016
From: report at bugs.python.org (Patrick Lehmann)
Date: Sun, 20 Nov 2016 11:10:24 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479640224.11.0.804778128531.issue28710@psf.upfronthosting.co.za>


Patrick Lehmann added the comment:

I also found some docstrings using double back-tick plus double single quotes.

For example: ``x.y = v'' in builtins.py in function setattr(...).

----------

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

From report at bugs.python.org  Sun Nov 20 07:24:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 12:24:18 +0000
Subject: [docs] [issue28710] Sphinx incompatible markup in
 configparser.ConfigParser.
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1479644658.54.0.731681897214.issue28710@psf.upfronthosting.co.za>


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


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Sun Nov 20 08:58:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 20 Nov 2016 13:58:32 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
Message-ID: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The docs of the encoders of unicode-escape and raw-unicode-escape still tell the result of the encoding is Python string object. It should be Python bytes object.

----------
assignee: docs at python
components: Documentation
files: unicode-escape-doc.patch
keywords: patch
messages: 281263
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Replace string with bytes in doc of unicode-escape an raw-unicode-escape
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45558/unicode-escape-doc.patch

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

From report at bugs.python.org  Sun Nov 20 09:03:20 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 20 Nov 2016 14:03:20 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479650600.44.0.967716694722.issue28750@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry

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

From report at bugs.python.org  Sun Nov 20 09:21:35 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 20 Nov 2016 14:21:35 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479651695.21.0.723640257237.issue28750@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file45559/unicode-escape-doc_v2.patch

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

From report at bugs.python.org  Sun Nov 20 09:23:13 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 20 Nov 2016 14:23:13 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479651793.54.0.462091062262.issue28750@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
stage: patch review -> commit review

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

From report at bugs.python.org  Sun Nov 20 09:43:14 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 14:43:14 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479652994.89.0.898474617487.issue28750@psf.upfronthosting.co.za>


Julien Palard added the comment:

The inconcistencies were introduced in hg changeset 41703:7993f23ad46c, git commit:

commit 40ec96630b96f077c8b5746ab0ec038f95aede8b
Author: Walter D?rwald <walter at livinglogic.de>
Date:   Sat May 12 11:08:06 2007 +0000

    Change PyUnicode_EncodeUnicodeEscape() to return a bytes object.
    However PyUnicode_AsUnicodeEscapeString() (which is used by
    Objects/fileobject.c::file_repr()) still returns a str8 object.
    Give unicode_repr() it's own implementation which returns a str8
    object (it was formerly just calling unicodeescape_string()
    which was used to implement PyUnicode_EncodeUnicodeEscape() too),
    because once repr() is required to return unicode objects it
    needs its own implementation anyway.

(PyUnicode_EncodeUnicodeEscape was the old name for PyUnicode_AsUnicodeEscapeString (since 06ade3ac0d12beacd84382bd5fc8baf1c21c0e74).)

I searched in the documentation for "python string" and it looks like  PyUnicode_EncodeCharmap is documented to return a string, but it returns bytes (same issue), therefore, the same issue happen for PyUnicode_AsCharmapString which uses PyUnicode_EncodeCharmap.

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

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

From report at bugs.python.org  Sun Nov 20 09:45:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 14:45:25 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479653125.74.0.507927936424.issue28750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch Xiang!

But I think the word "Python" in "Python bytes object" is redundant. It was needed in "Python string object" to distinguish from "C string" and "Python Unicode object".

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

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

From report at bugs.python.org  Sun Nov 20 09:46:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 14:46:30 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479653190.13.0.284460192557.issue28750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For PyUnicode_AsCharmapString and PyUnicode_EncodeCharmap see issue28749.

----------

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

From report at bugs.python.org  Sun Nov 20 10:03:24 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 20 Nov 2016 15:03:24 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479654204.08.0.124981719177.issue28750@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> But I think the word "Python" in "Python bytes object" is redundant. It was needed in "Python string object" to distinguish from "C string" and "Python Unicode object".

Make sense. This "Python" actually appears in many places in the docs. I only change the related parts of this issue.

----------
Added file: http://bugs.python.org/file45561/unicode-escape-doc_v3.patch

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

From report at bugs.python.org  Sun Nov 20 10:05:44 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 15:05:44 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479654344.28.0.126339084929.issue28750@psf.upfronthosting.co.za>


Julien Palard added the comment:

So, lgtm.

----------

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

From report at bugs.python.org  Sun Nov 20 10:14:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 15:14:26 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479654866.71.0.315184840739.issue28750@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Sun Nov 20 10:22:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Nov 2016 15:22:02 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <20161120152153.10070.42716.EDCEC1AC@psf.io>


Roundup Robot added the comment:

New changeset 059b8e15b738 by Serhiy Storchaka in branch '3.5':
Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API.
https://hg.python.org/cpython/rev/059b8e15b738

New changeset 0c6fccf04a79 by Serhiy Storchaka in branch '3.6':
Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API.
https://hg.python.org/cpython/rev/0c6fccf04a79

New changeset deff7bf26d00 by Serhiy Storchaka in branch 'default':
Issue #28750: Fixed docs of of unicode-escape an raw-unicode-escape C API.
https://hg.python.org/cpython/rev/deff7bf26d00

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

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

From report at bugs.python.org  Sun Nov 20 10:22:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Nov 2016 15:22:29 +0000
Subject: [docs] [issue28750] Replace string with bytes in doc of
 unicode-escape an raw-unicode-escape
In-Reply-To: <1479650312.85.0.102292696312.issue28750@psf.upfronthosting.co.za>
Message-ID: <1479655349.46.0.461480467335.issue28750@psf.upfronthosting.co.za>


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


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

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

From barry at dadadata.net  Sun Nov 20 09:02:54 2016
From: barry at dadadata.net (barry at dadadata.net)
Date: Sun, 20 Nov 2016 14:02:54 -0000
Subject: [docs] Replace string with bytes in doc of unicode-escape an
 raw-unicode-escape (issue 28750)
Message-ID: <20161120140254.18508.77604@psf.upfronthosting.co.za>

Small wording nit


http://bugs.python.org/review/28750/diff/19218/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (left):

http://bugs.python.org/review/28750/diff/19218/Doc/c-api/unicode.rst#oldcode1299
Doc/c-api/unicode.rst:1299: Encode a Unicode object using Unicode-Escape
and return the result as Python
s/as Python/as a Python/

http://bugs.python.org/review/28750/diff/19218/Doc/c-api/unicode.rst#oldcode1330
Doc/c-api/unicode.rst:1330: Encode a Unicode object using
Raw-Unicode-Escape and return the result as
Same here.

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

From report at bugs.python.org  Sun Nov 20 11:46:29 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 16:46:29 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479660389.31.0.27499995372.issue28753@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Nov 20 12:12:27 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 20 Nov 2016 17:12:27 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479661947.79.0.779177578346.issue28753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

The bit about the "clinic/_" include is a good point.  Care to write a doc patch?

The bit about FASTCALL I don't know anything about because I haven't worked with FASTCALL.  I've added Victor Stinner, the author of the FASTCALL patch, maybe he can address your concerns about FASTCALL.

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

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

From report at bugs.python.org  Sun Nov 20 13:14:48 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 18:14:48 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479665688.52.0.367603784986.issue28753@psf.upfronthosting.co.za>


Julien Palard added the comment:

@Larry: As a french-speaking guy, I typically don't write non-internal doc in english, fearing it sound weird for natives. I prefer translating it back in french (I'm the current leader of https://github.com/afpy/python_doc_fr)

Here, here is a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file45565/issue28753.diff

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

From report at bugs.python.org  Sun Nov 20 13:48:50 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 20 Nov 2016 18:48:50 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479667730.78.0.109852837718.issue28753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I understand your concern as a non-English speaker, but your patch was really pretty good.  I did edit it a little; how's this?

----------
Added file: http://bugs.python.org/file45566/larry.issue28753.diff

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

From report at bugs.python.org  Sun Nov 20 14:28:19 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 19:28:19 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479670099.94.0.0205781031553.issue28753@psf.upfronthosting.co.za>


Julien Palard added the comment:

Thanks for proof-reading my english, your editions are really nice: LGTM.

----------

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

From report at bugs.python.org  Sun Nov 20 14:33:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Nov 2016 19:33:32 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <20161120193329.10307.7670.E28F97F3@psf.io>


Roundup Robot added the comment:

New changeset 0a18d2cfeb52 by Larry Hastings in branch 'default':
Issue 28753: Argument Clinic howto docfix, courtesy Julien Palard.
https://hg.python.org/cpython/rev/0a18d2cfeb52

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

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

From report at bugs.python.org  Sun Nov 20 14:33:49 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 20 Nov 2016 19:33:49 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479670429.13.0.544161579894.issue28753@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


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

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

From report at bugs.python.org  Sun Nov 20 14:35:11 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 19:35:11 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479670511.95.0.309900024815.issue28753@psf.upfronthosting.co.za>


Julien Palard added the comment:

Should we keep this open for the FASTCALL bit?

----------

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

From report at bugs.python.org  Sun Nov 20 14:35:57 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 20 Nov 2016 19:35:57 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479670557.56.0.252599758816.issue28753@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Let's see what Victor has to say.

----------

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

From report at bugs.python.org  Sun Nov 20 17:01:57 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 22:01:57 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
Message-ID: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>


New submission from Julien Palard:

I was reading `howto/clinic.html` and though I'll fix syntax highlighting.

----------
assignee: docs at python
components: Argument Clinic, Documentation
messages: 281304
nosy: docs at python, larry, mdk
priority: normal
severity: normal
status: open
title: Rework syntax highlighing in howto/clinic.rst
versions: Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Nov 20 17:02:16 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 22:02:16 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1479679336.93.0.998100830502.issue28755@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file45573/issue28755.diff

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

From report at bugs.python.org  Sun Nov 20 17:40:25 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 20 Nov 2016 22:40:25 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1479681625.73.0.606019396992.issue28755@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file45575/issue28755-2.diff

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

From report at bugs.python.org  Mon Nov 21 06:34:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Nov 2016 11:34:56 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
Message-ID: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

It is recommended to use an em-dash instead of a hyphen for numerical ranges. It looks better in the rendered document. Python documentation already use it, but not always. Proposed patch adds more en-dashes.

----------
assignee: docs at python
components: Documentation
files: docs-en-dash.patch
keywords: patch
messages: 281347
nosy: docs at python, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use en-dashes for ranges in docs
type: enhancement
Added file: http://bugs.python.org/file45584/docs-en-dash.patch

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

From report at bugs.python.org  Mon Nov 21 09:06:42 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Nov 2016 14:06:42 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479737202.66.0.199467242702.issue28763@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

While you are at it, have you checked how many en-dashes have been used instead of em-dashes?  "--" is commonly used to indicate em-dashes (e.g. in emails), but in rst it renders to an en-dash.

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

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

From report at bugs.python.org  Mon Nov 21 09:25:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Nov 2016 14:25:34 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479738334.72.0.984540408295.issue28763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

353 en-dashes with spaces.
479 em-dashes with spaces.
89 em-dashes without spaces.

And some number of hyphens with spaces. It is hard to automatically distinguish them from minuses in code examples, but in issue18529 I provided large patches that converted all of them to dashes.

----------

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

From report at bugs.python.org  Mon Nov 21 09:41:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Nov 2016 14:41:53 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479739313.16.0.516172020173.issue28763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Some of these double hyphens are in code examples. Thus the actual number of en-dashes that can be changed to em-dashes is smaller.

----------

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

From report at bugs.python.org  Mon Nov 21 12:24:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2016 17:24:14 +0000
Subject: [docs] [issue28172] Upper-case all example enum members
In-Reply-To: <1473966107.03.0.300297915122.issue28172@psf.upfronthosting.co.za>
Message-ID: <20161121172254.12325.25961.7ED826BE@psf.io>


Roundup Robot added the comment:

New changeset b9801dab214a by Ethan Furman in branch '3.6':
close issue28172: Change all example enum member names to uppercase, per Guido; patch by Chris Angelico.
https://hg.python.org/cpython/rev/b9801dab214a

New changeset 5ec8d4c51363 by Ethan Furman in branch 'default':
close issue28172: Change all example enum member names to uppercase, per Guido; patch by Chris Angelico.
https://hg.python.org/cpython/rev/5ec8d4c51363

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

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

From report at bugs.python.org  Mon Nov 21 12:25:11 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 21 Nov 2016 17:25:11 +0000
Subject: [docs] [issue28172] Upper-case all example enum members
In-Reply-To: <1473966107.03.0.300297915122.issue28172@psf.upfronthosting.co.za>
Message-ID: <1479749111.26.0.747634645862.issue28172@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov 21 17:35:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2016 22:35:00 +0000
Subject: [docs] [issue28475] Misleading error on random.sample when k < 0
In-Reply-To: <1476863008.28.0.194554202317.issue28475@psf.upfronthosting.co.za>
Message-ID: <20161121223457.33611.76755.FF23C385@psf.io>


Roundup Robot added the comment:

New changeset 89f95c78e0ab by Raymond Hettinger in branch '3.6':
Issue 28475:  Improve error message for random.sample() with k < 0. (Contributed by Francisco Couzo).
https://hg.python.org/cpython/rev/89f95c78e0ab

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

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

From report at bugs.python.org  Mon Nov 21 17:37:21 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Nov 2016 22:37:21 +0000
Subject: [docs] [issue28475] Misleading error on random.sample when k < 0
In-Reply-To: <1476863008.28.0.194554202317.issue28475@psf.upfronthosting.co.za>
Message-ID: <1479767841.01.0.162045687705.issue28475@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Franscisco.  

I ended-up not modifying the docs because I think it clutters that clarity with an irrelevant side issue.  The more important part was to make sure the error message wasn't misleading and the test that edge case.  I didn't backport to Python 2.7 because I don't think it meets the threshold of being interesting enough to warrant a backport to an old release.

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

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

From report at bugs.python.org  Mon Nov 21 18:13:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 21 Nov 2016 23:13:47 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <20161121231344.33742.70973.D54D3A25@psf.io>


Roundup Robot added the comment:

New changeset 62c16fafa7d4 by Raymond Hettinger in branch '3.6':
Issue 28587:  list.index documentation missing start and stop arguments. (Contributed by Mariatta Wijaya.)
https://hg.python.org/cpython/rev/62c16fafa7d4

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

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

From report at bugs.python.org  Mon Nov 21 18:14:45 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Nov 2016 23:14:45 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479770085.2.0.162481333555.issue28587@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Mariatta, thank you for the patch.  And Chris, thanks for the observant bug report.

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

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

From report at bugs.python.org  Mon Nov 21 18:41:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 21 Nov 2016 23:41:24 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479771684.45.0.378504123862.issue28587@psf.upfronthosting.co.za>


Martin Panter added the comment:

The committed change looks wrong in the new example. I think Mariatta?s patch was right; it the index found is 3, not 2:

>>> a
[66.25, 333, -1, 333, 1, 1234.5, 333]
>>> a.index(333)
1
>>> a.index(333, 2)  # search for 333 starting at index 2
3

----------
nosy: +martin.panter
status: closed -> open
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Nov 21 18:52:01 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 21 Nov 2016 23:52:01 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479772321.89.0.881601094544.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Raymond and Martin :)

Not sure what the procedure is for fixing this. Do I upload another patch?

----------

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

From report at bugs.python.org  Mon Nov 21 18:53:26 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Nov 2016 23:53:26 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479772406.04.0.480427888399.issue28587@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for noticing.   I tested against the original list rather than the subsequently modified version.  I'm starting to think that this whole example section is annoyingly hard to follow and uninformative.

----------

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

From report at bugs.python.org  Mon Nov 21 19:05:47 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Nov 2016 00:05:47 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479773147.86.0.865040902004.issue28587@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Attaching an improved list example:
* Replaced abstract and hard to follow numerical example with fruits
* Demonstrate the non-mutating methods first

----------
Added file: http://bugs.python.org/file45595/new_list_example.diff

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

From report at bugs.python.org  Mon Nov 21 19:14:42 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 22 Nov 2016 00:14:42 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479773682.85.0.586200926692.issue28587@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks Raymond. The new set of examples is much better than the previous one.
+1

----------

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

From report at bugs.python.org  Mon Nov 21 19:32:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2016 00:32:06 +0000
Subject: [docs] [issue27825] Make the documentation for statistics' data
 argument clearer.
In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za>
Message-ID: <20161122003202.130879.40570.6E7597AE@psf.io>


Roundup Robot added the comment:

New changeset 71dd21a3b9cc by Raymond Hettinger in branch '3.6':
Issue #27825: Improve for statistics data arguments. (Contributed by Mariatta Wijaya.)
https://hg.python.org/cpython/rev/71dd21a3b9cc

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

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

From report at bugs.python.org  Mon Nov 21 19:32:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Nov 2016 00:32:06 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <20161122003203.130879.41333.C560A0AE@psf.io>


Roundup Robot added the comment:

New changeset efac7ac53933 by Raymond Hettinger in branch '3.6':
Issue #28587: Improve list examples in the tutorial
https://hg.python.org/cpython/rev/efac7ac53933

----------

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

From report at bugs.python.org  Mon Nov 21 19:32:58 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Nov 2016 00:32:58 +0000
Subject: [docs] [issue27825] Make the documentation for statistics' data
 argument clearer.
In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za>
Message-ID: <1479774778.86.0.498788328155.issue27825@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Mariatta.

As discussed in chat, I dropped the extra fractions examples because they didn't seem to add value.

----------
nosy: +rhettinger
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Mon Nov 21 19:33:28 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Nov 2016 00:33:28 +0000
Subject: [docs] [issue28587] list.index documentation missing start and stop
 arguments
In-Reply-To: <1478079143.84.0.85838744414.issue28587@psf.upfronthosting.co.za>
Message-ID: <1479774808.06.0.679828714369.issue28587@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Okay, applied.

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

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

From report at bugs.python.org  Mon Nov 21 19:33:51 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 22 Nov 2016 00:33:51 +0000
Subject: [docs] [issue27825] Make the documentation for statistics' data
 argument clearer.
In-Reply-To: <1471813007.76.0.49945343113.issue27825@psf.upfronthosting.co.za>
Message-ID: <1479774831.19.0.357809218644.issue27825@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Sounds good. Thanks, Raymond :)

----------

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

From report at bugs.python.org  Mon Nov 21 19:53:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Nov 2016 00:53:42 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479776022.17.0.638545730369.issue28763@psf.upfronthosting.co.za>


Martin Panter added the comment:

Personally I prefer en dashes where practical, but I fear the change may conflict with other people?s styles and preferences. I quickly counted 22 single hyphens (obviously I missed a few that your patch caught) and also 22 existing en dashes.

----------

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

From report at bugs.python.org  Mon Nov 21 20:39:22 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 22 Nov 2016 01:39:22 +0000
Subject: [docs] [issue28738] Document SIGBREAK as argument for signal()
 under Windows.
In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za>
Message-ID: <1479778762.48.0.214003524958.issue28738@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
keywords: +easy
priority: normal -> low
stage:  -> patch review
versions: +Python 3.6

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

From report at bugs.python.org  Mon Nov 21 21:15:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 02:15:07 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479780907.09.0.831054566593.issue28763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The rest single hyphens between digits are meaningful hypens in iso-8859-1, ISDNs, sample outputs, etc.

----------

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

From report at bugs.python.org  Mon Nov 21 21:32:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Nov 2016 02:32:08 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479781928.86.0.300867611395.issue28763@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sure, I was just saying that for whatever reason, 50% of the documentation uses hyphens for number ranges, and 50% uses en dashes.

----------

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

From report at bugs.python.org  Mon Nov 21 23:55:38 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 22 Nov 2016 04:55:38 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1479790537.79.0.0530221421763.issue28635@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I added ``-VV`` option to python command (issue28532).
Which section should I add the entry about it?

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Tue Nov 22 03:56:36 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Nov 2016 08:56:36 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479804996.38.0.232723859286.issue28763@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> It is recommended to use an em-dash instead of a hyphen for numerical ranges.

Who makes that recommendation? Did you mean en-dash rather than em-dash?

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

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

From report at bugs.python.org  Tue Nov 22 04:06:19 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Nov 2016 09:06:19 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479805579.52.0.626068298435.issue28763@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Did you mean en-dash rather than em-dash?

Ah, judging by the title and the patch, you did. :-) Phew!

Now I can delete the long post I had citing multiple sources for using en-dashes (not em-dashes) for numeric ranges...

----------

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

From report at bugs.python.org  Tue Nov 22 04:08:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Nov 2016 09:08:29 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479805709.65.0.971360449545.issue28763@psf.upfronthosting.co.za>


Martin Panter added the comment:

My Australian Style Manual says to use en rules for spans of figures etc. Wikipedia mentions some other guides: <https://en.wikipedia.org/wiki/Dash#Ranges_of_values>; apparently some prefer the hyphen. That is why I said it is a style issue, not a black and white thing.

----------

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

From report at bugs.python.org  Tue Nov 22 04:16:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 09:16:45 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479806205.56.0.904527261657.issue28763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, yes, I meant en-dashes of course. I read this recommendation in many books about TeX, and also in other typographic resources. In modern fonts a hyphen-minus (U+002D) is shorter than digits in modern fonts and is placed lower than the middle of digits. An en-dash (U+2013) has the same width as digits and is placed higher, at the middle of digit's height.

----------

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

From report at bugs.python.org  Tue Nov 22 05:42:55 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Nov 2016 10:42:55 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1479811375.63.0.389016133552.issue28763@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I read this recommendation in many books about TeX, and also in other typographic resources.

Same here. I'd add Apple's Style Guide and the Chicago Manual of Style to that list.

----------

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

From report at bugs.python.org  Tue Nov 22 06:53:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Nov 2016 11:53:08 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
Message-ID: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>


New submission from Martin Panter:

https://docs.python.org/3.7/c-api/typeobj.html#c.PyTypeObject.tp_getattr

tp_getattr and tp_setattr take a non-const char pointer in their signatures, but the documentation points to PyObject_GetAttrString() etc which were changed to take const char pointers a long time ago: revision 2f19b981ac24.

This patch fixes the documentation of those two methods for Python 3. There could be more fixes needed for Python 2.

----------
assignee: docs at python
components: Documentation
files: typeobj-sigs.patch
keywords: patch
messages: 281468
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Update documented signatures of tp_get/setattr
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45600/typeobj-sigs.patch

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

From storchaka+cpython at gmail.com  Tue Nov 22 07:13:41 2016
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Tue, 22 Nov 2016 12:13:41 -0000
Subject: [docs] Update documented signatures of tp_get/setattr (issue 28771)
Message-ID: <20161122121341.16381.15631@psf.upfronthosting.co.za>


http://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst
File Doc/c-api/typeobj.rst (right):

http://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst#newcode204
Doc/c-api/typeobj.rst:204: PyObject * tp_getattr(PyObject *o, char
*attr_name);
Shouldn't we use the ".. code-block:: c" directive?

Please document explicitly that attr_name point't to read-only string,
its content shouldn't be modified.

http://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst#newcode219
Doc/c-api/typeobj.rst:219: PyObject * tp_setattr(PyObject *o, char
*attr_name, PyObject *v);
Please document explicitly that "setting *v* to *NULL* to delete an
attribute must be supported".

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

From report at bugs.python.org  Tue Nov 22 07:13:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 12:13:52 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <1479816832.44.0.369333564526.issue28771@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov 22 09:28:16 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 22 Nov 2016 14:28:16 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1479824896.31.0.674952652681.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

https://docs.python.org/3.6/whatsnew/3.6.html#changes-in-python-command-behavior seems appropriate.

----------

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

From report at bugs.python.org  Tue Nov 22 09:41:52 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Tue, 22 Nov 2016 14:41:52 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1479825712.68.0.22530948424.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

On second thought `-VV` isn't really a porting change, so probably a new section under "Build and C API Changes".  Something like "Other Improvements".

----------

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

From report at bugs.python.org  Tue Nov 22 14:08:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 19:08:06 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479841686.29.0.394877427048.issue28450@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Maybe just remove the phrase "Unknown escapes such as \& are left alone"?

----------

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

From report at bugs.python.org  Tue Nov 22 14:10:59 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 22 Nov 2016 19:10:59 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479841859.21.0.28946334616.issue28450@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I disagree that the documentation is at fault.  This is known to break existing code, e.g. http://bugs.python.org/msg281496

I think it's not correct to change the documentation but leave the error-raising behavior for 3.6 because the deprecation was never documented in 3.5 so this will look like a gratuitous regression.  issue27030 for reference.

I also question whether it makes sense for such escapes to be illegal in the repl argument of re.sub().  I could understand for this limitation in the pattern argument, but that's not what's causing the error.

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

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

From report at bugs.python.org  Tue Nov 22 14:16:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 19:16:45 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479842205.29.0.349772055682.issue28450@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The deprecation was documented in 3.5.

https://docs.python.org/3.5/library/re.html#re.sub

Deprecated since version 3.5, will be removed in version 3.6: Unknown escapes consist of '\' and ASCII letter now raise a deprecation warning and will be forbidden in Python 3.6.

----------

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

From report at bugs.python.org  Tue Nov 22 14:28:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Nov 2016 19:28:56 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479842936.68.0.667608567846.issue28450@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The reason for disallowing some undefined escapes is the same as in pattern strings: this would allow as to introduce new special escape sequences. For example:

* \N{...} for named character escape.
* Perl and extended PCRE use \L and \U for making lower and upper casing of the replacement. \U is already used for other purpose, but you have an idea.

Of course the need in new special escape sequences in template string is much less then in pattern string.

----------

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

From report at bugs.python.org  Tue Nov 22 14:42:41 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 22 Nov 2016 19:42:41 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479843761.03.0.11370280558.issue28450@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

@Barry: repl already supports some escapes, e.g. \g<name> for named groups, although not \xXX et al, so deprecating unknown escapes like in the pattern makes sense to me.

BTW, the regex module already supports \xXX, \N{XXX}, etc.

----------

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

From report at bugs.python.org  Tue Nov 22 15:28:47 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 22 Nov 2016 20:28:47 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1479842936.68.0.667608567846.issue28450@psf.upfronthosting.co.za>
Message-ID: <20161122152843.08aee523@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On Nov 22, 2016, at 07:28 PM, Serhiy Storchaka wrote:

>The reason for disallowing some undefined escapes is the same as in pattern
>strings: this would allow as to introduce new special escape sequences.

I'll note that technically speaking, you can still introduce new escapes for
repl without breaking the documented contract.  All the docs say are that
"unknown escapes such as \& are left alone", but that doesn't list what are
unknown escapes.  So if new escapes are added in Python 3.7, and they are
transformed in repl, that would be allowed.

I'll also note that not *all* unknown sequences are rejected now, only
backslashes followed by an ASCII letter.  So \& is still probably left alone,
while \s is now rejected.  That does add to the confusion, although the
deprecation note in the re.sub() documentation does document the new behavior
correctly.

On Nov 22, 2016, at 07:55 PM, R. David Murray wrote:

>There is still the argument that we shouldn't break 2.7 compatibility
>unnecessarily until 2.7 is out of maintenance.  That is: warnings are good,
>removals are bad.  (I haven't read through this issue, so I may be off base.)

This is also a reasonable argument, but not one I've thought about since I'm
using Python 2 only rarely these days.

On Nov 22, 2016, at 07:34 PM, Serhiy Storchaka wrote:

>If you insist I could revert converting warnings to errors (only in
>replacement string or all?) in 3.6.

pattern is a regular expression string so it already follows the syntax as
described in $6.2.1 Regular Expression Syntax.  But I think a reading of that
section (and the "special sequences" bit that follows) could also argue that
unknown escapes shouldn't throw an error.

>But I think they should left errors in 3.7. The earlier we make undefined
>escapes the errors, the earlier we can define new special escape sequences
>without confusing users. It is bad if the escape sequence is valid in two
>Python versions but has different meaning.

Perhaps so, but I do think this is a tricky question from a compatibility
point of view.  One possible optional, although it's late in the cycle, would
be to introduce a new flag so the user could tell re exactly what behavior
they want.  The default would have to be backward compatible (i.e. leave
unknown sequences alone), but there could be say an re.STRICTESCAPES flag that
would cause the error to be thrown.

----------

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

From report at bugs.python.org  Tue Nov 22 15:50:57 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 22 Nov 2016 20:50:57 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479847857.2.0.145292626133.issue28773@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Manuel. Looks like FrozenSet is in PEP 484 and has been added to typing.__all__ in https://github.com/python/typing/pull/261 (already synced with the stdlib version of typing module)

The patch looks good to me. Adding Guido to nosy list for a commit review.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +berker.peksag, docs at python, gvanrossum
stage:  -> patch review

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

From report at bugs.python.org  Tue Nov 22 16:01:50 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 22 Nov 2016 21:01:50 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1479848510.1.0.0942202656389.issue28450@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry

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

From levkivskyi at gmail.com  Tue Nov 22 17:50:37 2016
From: levkivskyi at gmail.com (levkivskyi at gmail.com)
Date: Tue, 22 Nov 2016 22:50:37 -0000
Subject: [docs] typing.FrozenSet missing in documentation. (issue 28773)
Message-ID: <20161122225037.1929.37763@psf.upfronthosting.co.za>


http://bugs.python.org/review/28773/diff/19258/Doc/library/typing.rst
File Doc/library/typing.rst (right):

http://bugs.python.org/review/28773/diff/19258/Doc/library/typing.rst#newcode587
Doc/library/typing.rst:587: .. class:: FrozenSet(frozenset,
AbstractSet[T])
FrozenSet is covariant in its type variable. PEP 8 recommends using
suffix ``_co`` for such type variables
https://www.python.org/dev/peps/pep-0008/#type-variable-names.

Therefore, I would write ``AbstractSet[T_co]`` instead of
``AbstractSet[T]``

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

From report at bugs.python.org  Tue Nov 22 17:51:00 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Tue, 22 Nov 2016 22:51:00 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479855060.83.0.132897668707.issue28773@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

The patch looks good, I left just one small comment in Rietveld.

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

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

From report at bugs.python.org  Tue Nov 22 18:22:57 2016
From: report at bugs.python.org (Manuel Krebber)
Date: Tue, 22 Nov 2016 23:22:57 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479856977.75.0.2566207479.issue28773@psf.upfronthosting.co.za>


Manuel Krebber added the comment:

I updated the patch to add reflect the covariance.

----------
Added file: http://bugs.python.org/file45606/frozenset-doc.patch

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

From report at bugs.python.org  Wed Nov 23 03:16:58 2016
From: report at bugs.python.org (Mohammad Maaz Khan)
Date: Wed, 23 Nov 2016 08:16:58 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <1479889018.35.0.579424489001.issue16026@psf.upfronthosting.co.za>


Mohammad Maaz Khan added the comment:

Hi ?ric, I think the documentation should be changed to match the arguments' names.

----------
nosy: +maaz92

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

From report at bugs.python.org  Wed Nov 23 03:29:47 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 23 Nov 2016 08:29:47 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479889787.46.0.478461297166.issue28773@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Thank you Manuel!
LGTM.

----------

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

From report at bugs.python.org  Wed Nov 23 05:33:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 23 Nov 2016 10:33:51 +0000
Subject: [docs] [issue16026] csv.DictReader argument names documented
 incorrectly
In-Reply-To: <1348505583.77.0.632308357055.issue16026@psf.upfronthosting.co.za>
Message-ID: <1479897231.02.0.757864475636.issue16026@psf.upfronthosting.co.za>


Berker Peksag added the comment:

James Salt's patch looks good to me, but it doesn't apply cleanly anymore.

For the record, PyPy uses the same parameter name as Lib/csv.py: https://bitbucket.org/pypy/pypy/src/55a9404c80d6557854cac092addd92a6e0b683cc/lib-python/2.7/csv.py?at=default&fileviewer=file-view-default#csv.py-74

----------
keywords: +easy -needs review
nosy: +berker.peksag
priority: normal -> low
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Nov 23 08:32:59 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 23 Nov 2016 13:32:59 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1479907979.32.0.873425620246.issue28753@psf.upfronthosting.co.za>


Julien Palard added the comment:

Reopening to remind @Victor we have a question about METH_FASTCALL.

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

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

From report at bugs.python.org  Wed Nov 23 11:18:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 23 Nov 2016 16:18:59 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write()
In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>
Message-ID: <1479917939.46.0.651580349303.issue28714@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, George.

Using 'r+' means that you don't have to reopen the same file if you want to both read and write to it but it's up to you to check where the cursor is before writing anything to it.

Since the ConfigParser.write() method doesn't have any control over the file object (and this is not the only place that someone can pass a file object in the stdlib), I don't think we should make its documentation more complicated.

I wouldn't strongly object adding a short sentence about the behavior of the + mode if someone wants to write a patch. Doc/tutorial/inputoutput.rst or Doc/library/functions.rst might be a good place to put that information.

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

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

From report at bugs.python.org  Wed Nov 23 11:37:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 23 Nov 2016 16:37:11 +0000
Subject: [docs] [issue28722] doctest example exit status
In-Reply-To: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za>
Message-ID: <1479919031.22.0.277734688829.issue28722@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Hi Rajiv, thanks for the report, but this is already possible by default. I will use the factorial example from https://docs.python.org/3.5/library/doctest.html to demonstrate it:

    $ python -m doctest example.py
    $ echo $?
    0

Now change the following line

    >>> [factorial(n) for n in range(6)]

to

    >>> [factorial(n) for n in range(5)]

and run the script again:

    $ python -m doctest example.py
    [...]
    ***Test Failed*** 1 failures.
    $ echo $?
    1

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> enhancement

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

From report at bugs.python.org  Wed Nov 23 13:06:02 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Nov 2016 18:06:02 +0000
Subject: [docs] [issue28722] doctest example exit status
In-Reply-To: <1479345580.78.0.277825169146.issue28722@psf.upfronthosting.co.za>
Message-ID: <1479924362.56.0.863509247374.issue28722@psf.upfronthosting.co.za>


R. David Murray added the comment:

Rajiv is suggesting an improvement to the documentation.  I think it is a reasonable thought, but probably not a good idea on closer examination.  The example introduces the basic doctest concepts, and goes on to say that this is not the mostly likely way to make use of doctest (and indeed it is not common).  So complicating the example and the explanation would be counterproductive to the intent of the text, in my opinion.

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

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

From report at bugs.python.org  Wed Nov 23 15:57:26 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Wed, 23 Nov 2016 20:57:26 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1479934646.88.0.989475670429.issue10379@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

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

From report at bugs.python.org  Wed Nov 23 17:15:56 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Nov 2016 22:15:56 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1479939356.6.0.729740019593.issue10379@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 23 19:38:00 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 24 Nov 2016 00:38:00 +0000
Subject: [docs] [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1479947880.26.0.240576836095.issue10379@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee: docs at python -> 
keywords: +easy
stage:  -> needs patch
type:  -> behavior

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

From report at bugs.python.org  Wed Nov 23 19:53:02 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Nov 2016 00:53:02 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479948782.54.0.669748526271.issue28773@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Ned: does the ban on non-critical commits to the 3.6 branch also apply to doc patches?

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

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

From report at bugs.python.org  Wed Nov 23 20:06:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 24 Nov 2016 01:06:24 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1479949584.0.0.762705484703.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

The 2.7 patch looks okay to me. I confirmed that sq_ass_slice gets called to delete slices, and I presume the other stuff is similar to Python 3. Do you want to commit this to 2.7 Serhiy?

----------
stage: patch review -> commit review

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

From report at bugs.python.org  Wed Nov 23 20:19:08 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 24 Nov 2016 01:19:08 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1479950347.55.0.658217507055.issue28773@psf.upfronthosting.co.za>


Ned Deily added the comment:

Guido, doc fixes are welcome!

----------

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

From report at bugs.python.org  Wed Nov 23 21:36:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 24 Nov 2016 02:36:45 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <1479955005.21.0.298201834021.issue28771@psf.upfronthosting.co.za>


Martin Panter added the comment:

In Python 2, charbufferproc was changed to use non-const char ** in revision dba6494735d0 (perhaps by accident). Otherwise, this patch is the same as for Python 3. I have added a sentence about using NULL for deletion in the patch.

----------
Added file: http://bugs.python.org/file45616/typeobj-sigs.v2.py2.patch

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

From report at bugs.python.org  Wed Nov 23 21:40:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 24 Nov 2016 02:40:29 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <1479955229.44.0.770911134131.issue28771@psf.upfronthosting.co.za>


Martin Panter added the comment:

Python 2 patch is on top of the patch for Issue 25701

----------
dependencies: +Document that tp_setattro and tp_setattr are used for deleting attributes

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

From storchaka+cpython at gmail.com  Thu Nov 24 00:54:06 2016
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Thu, 24 Nov 2016 05:54:06 -0000
Subject: [docs] Update documented signatures of tp_get/setattr (issue
 28771)
Message-ID: <20161124055406.18229.32021@psf.upfronthosting.co.za>


http://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst
File Doc/c-api/typeobj.rst (right):

http://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst#newcode204
Doc/c-api/typeobj.rst:204: PyObject * tp_getattr(PyObject *o, char
*attr_name);
On 2016/11/24 00:59:49, vadmium wrote:
> On 2016/11/22 13:13:41, storchaka wrote:
> > Shouldn't we use the ".. code-block:: c" directive?
> 
> I don?t think it is needed. At the top of the file there is already
?..
> highlightlang:: c?, and this already comes up highlighted for me. I
copied the
> markup from
>
<https://docs.python.org/3.7/c-api/typeobj.html#c.PyTypeObject.tp_descr_get>
> further down the page.

Nice.

> > Please document explicitly that attr_name point't to read-only
string, its
> > content shouldn't be modified.
> 
> Do you mean the function that implements tp_getattr should not modify
the
> string? I guess I can add that if you want, though it seems to be
going into
> more detail than normal. It seems reasonable to leave it out, along
with other
> details like the string is null-terminated and its lifetime is the
duration of
> the function call.

Left it on you. But this is not a normal case.

It would be simpler to change the signature of tp_getattr by adding
const. But this change should be discussed on Python-Dev.

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

From report at bugs.python.org  Thu Nov 24 00:58:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Nov 2016 05:58:43 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1479967123.9.0.13314102975.issue25701@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please do this yourself. This is mainly your patch.

----------

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

From report at bugs.python.org  Thu Nov 24 02:44:10 2016
From: report at bugs.python.org (Evan)
Date: Thu, 24 Nov 2016 07:44:10 +0000
Subject: [docs] [issue28784] shlex.shlex punctuation_chars documentation
 should use posix=True
Message-ID: <1479973450.22.0.44978748963.issue28784@psf.upfronthosting.co.za>


New submission from Evan:

(This discussion started on issue28595.)

The new punctuation_chars keyword argument is intended to provide "compatibility with the parsing performed by common Unix shells like bash, dash, and sh", however the documentation and examples do not mention that the user should also set posix=True (which defaults to False for shlex.shlex but True for shlex.split).

Longer term (over several releases), perhaps the default for posix could be changed from False to True. Alternatively, the punctuation_chars argument could also be added to shlex.split, which would avoid having to interact with shlex.shlex directly.

----------
assignee: docs at python
components: Documentation
messages: 281612
nosy: docs at python, evan_, r.david.murray, vinay.sajip
priority: normal
severity: normal
status: open
title: shlex.shlex punctuation_chars documentation should use posix=True
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 24 03:14:24 2016
From: report at bugs.python.org (Max)
Date: Thu, 24 Nov 2016 08:14:24 +0000
Subject: [docs] [issue28785] Clarify the behavior of NotImplemented
Message-ID: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za>


New submission from Max:

Currently, there's no clear statement as to what exactly the fallback is in case `__eq__` returns `NotImplemented`.  It would be good to clarify the behavior of `NotImplemented`; at least for `__eq__`, but perhaps also other rich comparison methods. For example: "When `NotImplemented` is returned from a rich comparison method, the interpreter behaves as if the rich comparison method was not defined in the first place." See http://stackoverflow.com/questions/40780004/returning-notimplemented-from-eq for more discussion.

----------
assignee: docs at python
components: Documentation
messages: 281616
nosy: docs at python, max
priority: normal
severity: normal
status: open
title: Clarify the behavior of NotImplemented
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Nov 24 03:42:06 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 24 Nov 2016 08:42:06 +0000
Subject: [docs] [issue28786] Warnings in Misc/NEWS
Message-ID: <1479976926.46.0.685904317893.issue28786@psf.upfronthosting.co.za>


New submission from SilentGhost:

Couple of entries in Misc/NEWS are causing warnings due to use of double quotes instead of backticks for code segments. This patches fixes the formatting.

----------
assignee: docs at python
components: Documentation
files: escape.diff
keywords: patch
messages: 281620
nosy: SilentGhost, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: Warnings in Misc/NEWS
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file45620/escape.diff

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

From report at bugs.python.org  Thu Nov 24 04:46:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 24 Nov 2016 09:46:24 +0000
Subject: [docs] [issue28785] Clarify the behavior of NotImplemented
In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za>
Message-ID: <1479980784.8.0.681804241221.issue28785@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation of this that comes to mind is spread over <https://docs.python.org/3.6/reference/datamodel.html#object.__eq__> and <https://docs.python.org/3.6/reference/expressions.html#value-comparisons>.

My understanding of how it works in general is that NotImplemented is just a simple object like None. It doesn?t have any special behaviour on its own. Similarly, if you call a special method like __eq__() manually, there is no fallback, you just get the NotImplemented object. The interpreter calls special methods like __eq__() when evaluating expressions, but the specific behaviour and how NotImplemented is interpreted varies subtly.

To evaluate a == b, if b?s class is a strict subclass of a?s class, b.__eq__(a) is tried first, otherwise a.__eq__(b) is tried first. If that call returns NotImplemented, the first fallback is to try the call. Failing that, the final fallback is the default behaviour for object() instances.

To evaluate a != b, there is another set of fallbacks in the chain, which is to try ?not a.__eq__(b)?. So for __eq__(), the fallback depends on the class hierarchy, on whether a reversed call has already been made, and on whether you are evaluating == or !=.

The documentation for comparison operations was cleaned up a while ago (Issue 12067). But there is probably more room for improvement. I think the best thing would be to document the above sort of behaviour as being directly associated with operations like as == and !=, and only indirectly associated with the NotImplemented object and the __eq__() method.

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

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

From report at bugs.python.org  Thu Nov 24 05:38:11 2016
From: report at bugs.python.org (Max)
Date: Thu, 24 Nov 2016 10:38:11 +0000
Subject: [docs] [issue28785] Clarify the behavior of NotImplemented
In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za>
Message-ID: <1479983891.05.0.0678444061526.issue28785@psf.upfronthosting.co.za>


Max added the comment:

Martin - what you suggest is precisely what I had in mind (but didn't phrase it as well):

> to document the above sort of behaviour as being directly associated with operations like as == and !=, and only indirectly associated with the NotImplemented object and the __eq__() method

Also a minor typo: you meant "If that call returns NotImplemented, the first fallback is to try the *reverse* call."

----------

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

From storchaka+cpython at gmail.com  Thu Nov 24 06:08:21 2016
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Thu, 24 Nov 2016 11:08:21 -0000
Subject: [docs] Fixed the documentation of the mapping codec APIs (issue
 28749)
Message-ID: <20161124110821.2968.29299@psf.upfronthosting.co.za>

Reviewers: xiang.zhang,


http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1413
Doc/c-api/unicode.rst:1413: decode characters.  The mapping objects
provided must only support the
On 2016/11/24 10:35:22, xiang.zhang wrote:
> I don't understand what the 'only' means. It looks to me except
'__getitem__' no
> other methods could be defined.

This phrase was in the old documentation, and it still is true. It means
that the mapping object needs to define the __getitem__ method. No other
methods are needed.

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1430
Doc/c-api/unicode.rst:1430: cause an error.
On 2016/11/24 10:35:22, xiang.zhang wrote:
> Cause an error or not depends on *errors*.

Is this a question? All these cases mean "undefined mapping". They cause
calling the error handler named *error* if it is provided, as in other
decoders.

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1442
Doc/c-api/unicode.rst:1442: ``None`` are  treated as "undefined mapping"
and cause an error.
On 2016/11/24 10:35:22, xiang.zhang wrote:
>                      ^ redundant space
> 
> One more question about this API, why not allow *mapping* be NULL and
default to
> Latin1? PyUnicode_EncodeCharmap and PyUnicode_DecodeCharmap both get
this
> behaviour.

PyUnicode_EncodeCharmap and PyUnicode_DecodeCharmap have this behavior
for historical reasons. Latin1 was the default encoding in Python 2. No
need of this case in Python 3.



Please review this at http://bugs.python.org/review/28749/

Affected files:
  Doc/c-api/unicode.rst


diff -r 75fe67538905 Doc/c-api/unicode.rst
--- a/Doc/c-api/unicode.rst	Sun Nov 20 12:13:44 2016 +0200
+++ b/Doc/c-api/unicode.rst	Sun Nov 20 12:29:14 2016 +0200
@@ -1410,59 +1410,72 @@ Character Map Codecs
 This codec is special in that it can be used to implement many different codecs
 (and this is in fact what was done to obtain most of the standard codecs
 included in the :mod:`encodings` package). The codec uses mapping to encode and
-decode characters.
-
-Decoding mappings must map single string characters to single Unicode
-characters, integers (which are then interpreted as Unicode ordinals) or ``None``
-(meaning "undefined mapping" and causing an error).
-
-Encoding mappings must map single Unicode characters to single string
-characters, integers (which are then interpreted as Latin-1 ordinals) or ``None``
-(meaning "undefined mapping" and causing an error).
-
-The mapping objects provided must only support the __getitem__ mapping
-interface.
-
-If a character lookup fails with a LookupError, the character is copied as-is
-meaning that its ordinal value will be interpreted as Unicode or Latin-1 ordinal
-resp. Because of this, mappings only need to contain those mappings which map
-characters to different code points.
+decode characters.  The mapping objects provided must only support the
+:meth:`__getitem__` mapping interface; dictionaries and sequences work well.
 
 These are the mapping codec APIs:
 
-.. c:function:: PyObject* PyUnicode_DecodeCharmap(const char *s, Py_ssize_t size, \
+.. c:function:: PyObject* PyUnicode_DecodeCharmap(const char *data, Py_ssize_t size, \
                               PyObject *mapping, const char *errors)
 
-   Create a Unicode object by decoding *size* bytes of the encoded string *s* using
-   the given *mapping* object.  Return *NULL* if an exception was raised by the
-   codec. If *mapping* is *NULL* latin-1 decoding will be done. Else it can be a
-   dictionary mapping byte or a unicode string, which is treated as a lookup table.
-   Byte values greater that the length of the string and U+FFFE "characters" are
-   treated as "undefined mapping".
+   Create a Unicode object by decoding *size* bytes of the encoded string *s*
+   using the given *mapping* object.  Return *NULL* if an exception was raised
+   by the codec.
+
+   If *mapping* is *NULL* Latin-1 decoding will be done.  Else it must map
+   bytes (integers in the range from 0 to 255) to Unicode strings, integers
+   (which are then interpreted as Unicode ordinals) or ``None``.  Unmapped
+   bytes (ones which cause a :exc:`LookupError`) as well as mapped to
+   ``None``, ``0xFFFE`` or ``'\ufffe'`` are treated as "undefined mapping" and
+   cause an error.
 
 
 .. c:function:: PyObject* PyUnicode_AsCharmapString(PyObject *unicode, PyObject *mapping)
 
-   Encode a Unicode object using the given *mapping* object and return the result
-   as Python string object.  Error handling is "strict".  Return *NULL* if an
+   Encode a Unicode object using the given *mapping* object and return the
+   result as a bytes object.  Error handling is "strict".  Return *NULL* if an
    exception was raised by the codec.
 
+   The *mapping* object must map Unicode ordinal integers to bytes objects,
+   integers in the range from 0 to 255 or ``None``.  Unmapped character
+   ordinals (ones which cause a :exc:`LookupError`) as well as mapped to
+   ``None`` are  treated as "undefined mapping" and cause an error.
+
+
+.. c:function:: PyObject* PyUnicode_EncodeCharmap(const Py_UNICODE *s, Py_ssize_t size, \
+                              PyObject *mapping, const char *errors)
+
+   Encode the :c:type:`Py_UNICODE` buffer of the given *size* using the given
+   *mapping* object and return the result as a bytes object.  Return *NULL* if
+   an exception was raised by the codec.
+
+   .. deprecated-removed:: 3.3 4.0
+      Part of the old-style :c:type:`Py_UNICODE` API; please migrate to using
+      :c:func:`PyUnicode_AsCharmapString` or
+      :c:func:`PyUnicode_AsEncodedString`.
+
+
 The following codec API is special in that maps Unicode to Unicode.
 
+.. c:function:: PyObject* PyUnicode_Translate(PyObject *unicode, \
+                              PyObject *mapping, const char *errors)
+
+   Translate a Unicode object using the given *mapping* object and return the
+   resulting Unicode object.  Return *NULL* if an exception was raised by the
+   codec.
+
+   The *mapping* object must map Unicode ordinal integers to Unicode strings,
+   integers (which are then interpreted as Unicode ordinals) or ``None``
+   (causing deletion of the character).  Unmapped character ordinals (ones
+   which cause a :exc:`LookupError`) are left untouched and are copied as-is.
+
 
 .. c:function:: PyObject* PyUnicode_TranslateCharmap(const Py_UNICODE *s, Py_ssize_t size, \
-                              PyObject *table, const char *errors)
+                              PyObject *mapping, const char *errors)
 
    Translate a :c:type:`Py_UNICODE` buffer of the given *size* by applying a
-   character mapping *table* to it and return the resulting Unicode object.  Return
-   *NULL* when an exception was raised by the codec.
-
-   The *mapping* table must map Unicode ordinal integers to Unicode ordinal
-   integers or ``None`` (causing deletion of the character).
-
-   Mapping tables need only provide the :meth:`__getitem__` interface; dictionaries
-   and sequences work well.  Unmapped character ordinals (ones which cause a
-   :exc:`LookupError`) are left untouched and are copied as-is.
+   character *mapping* table to it and return the resulting Unicode object.
+   Return *NULL* when an exception was raised by the codec.
 
    .. deprecated-removed:: 3.3 4.0
       Part of the old-style :c:type:`Py_UNICODE` API; please migrate to using
@@ -1470,19 +1483,6 @@ The following codec API is special in th
       <codec-registry>`
 
 
-.. c:function:: PyObject* PyUnicode_EncodeCharmap(const Py_UNICODE *s, Py_ssize_t size, \
-                              PyObject *mapping, const char *errors)
-
-   Encode the :c:type:`Py_UNICODE` buffer of the given *size* using the given
-   *mapping* object and return a Python string object. Return *NULL* if an
-   exception was raised by the codec.
-
-   .. deprecated-removed:: 3.3 4.0
-      Part of the old-style :c:type:`Py_UNICODE` API; please migrate to using
-      :c:func:`PyUnicode_AsCharmapString` or
-      :c:func:`PyUnicode_AsEncodedString`.
-
-
 MBCS codecs for Windows
 """""""""""""""""""""""
 



From storchaka+cpython at gmail.com  Thu Nov 24 06:28:28 2016
From: storchaka+cpython at gmail.com (storchaka+cpython at gmail.com)
Date: Thu, 24 Nov 2016 11:28:28 -0000
Subject: [docs] Fixed the documentation of the mapping codec APIs (issue
 28749)
Message-ID: <20161124112828.18229.19156@psf.upfronthosting.co.za>


http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1413
Doc/c-api/unicode.rst:1413: decode characters.  The mapping objects
provided must only support the
On 2016/11/24 12:17:54, haypo wrote:
> I suggest to remove the "only" word.

Done.

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

From report at bugs.python.org  Thu Nov 24 06:38:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Nov 2016 11:38:50 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1479987530.56.0.808474524157.issue28749@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Xiang's and Victor's comments.

----------
Added file: http://bugs.python.org/file45623/docs-PyUnicode_Translate-2.patch

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

From report at bugs.python.org  Thu Nov 24 08:04:00 2016
From: report at bugs.python.org (George Fischhof)
Date: Thu, 24 Nov 2016 13:04:00 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write()
In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>
Message-ID: <1479992640.61.0.857113468497.issue28714@psf.upfronthosting.co.za>


George Fischhof added the comment:

Hi Berker, 

It is true, I agree ;-)

But this way ConfigParser works different than xml parsers (for example elementtree from system lib), as when I use elementtree.write it wil create a file with full and valid xml content.

But ConfigParser is "able" ;-) to create file with invalid content (for example (this was my findings) creates duplicated sections.

So it could be a feature request for ConfigParser:
It should be able to write config to a given filename, not only into file object.
(Like xml parser)

Kind regards,
George

----------

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

From report at bugs.python.org  Thu Nov 24 09:42:58 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Nov 2016 14:42:58 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write()
In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>
Message-ID: <1479998578.65.0.351350429267.issue28714@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would be a separate issue (a feature request).  It would make sense, since there is already a read_file method.

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

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

From report at bugs.python.org  Thu Nov 24 10:03:46 2016
From: report at bugs.python.org (George Fischhof)
Date: Thu, 24 Nov 2016 15:03:46 +0000
Subject: [docs] [issue28714] Addition to Documentation of
 configparser.ConfigParser.write()
In-Reply-To: <1479308435.4.0.112292626323.issue28714@psf.upfronthosting.co.za>
Message-ID: <1479999826.63.0.160517007198.issue28714@psf.upfronthosting.co.za>


George Fischhof added the comment:

Hi,

issue 28788 created as feature request

BR,
George

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

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

From report at bugs.python.org  Thu Nov 24 14:56:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Nov 2016 19:56:16 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <20161124195612.844.1748.7F2586EA@psf.io>


Roundup Robot added the comment:

New changeset 5d83b6a9b568 by Guido van Rossum in branch '3.5':
Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber)
https://hg.python.org/cpython/rev/5d83b6a9b568

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

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

From report at bugs.python.org  Thu Nov 24 14:57:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Nov 2016 19:57:20 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <20161124195718.29050.72017.CF13D22C@psf.io>


Roundup Robot added the comment:

New changeset 7059e68db068 by Guido van Rossum in branch '3.6':
Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber) (3.5->3.6)
https://hg.python.org/cpython/rev/7059e68db068

New changeset 00bfe5bd3553 by Guido van Rossum in branch 'default':
Issue #28773: Add typing.FrozenSet docs. (Manuel Krebber) (3.6->3.7)
https://hg.python.org/cpython/rev/00bfe5bd3553

----------

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

From report at bugs.python.org  Thu Nov 24 14:58:38 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Nov 2016 19:58:38 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1480017518.25.0.316659727448.issue28773@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks! I pushed this into 3.5, then merged into 3.6 and default. Is that the right procedure still?

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

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

From report at bugs.python.org  Thu Nov 24 16:42:43 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 24 Nov 2016 21:42:43 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1480023763.37.0.818050957409.issue15533@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Ping. This still isn't fixed several years later, i.e., the documentation still describes the POSIX, but not the Windows behavior.
See also issue20927, which reports this as a bug.

----------
nosy: +wolma
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov 24 17:10:04 2016
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 24 Nov 2016 22:10:04 +0000
Subject: [docs] [issue28794] inspect.isasyncgen and
 inspect.isasyncgenfunction aren't documented
Message-ID: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>


New submission from Nathaniel Smith:

The string "isasync" does not appear to occur on this page: https://docs.python.org/3.6/library/inspect.html

----------
assignee: docs at python
components: Documentation
messages: 281662
nosy: docs at python, njs, yselivanov
priority: normal
severity: normal
status: open
title: inspect.isasyncgen and inspect.isasyncgenfunction aren't documented
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Nov 24 17:25:57 2016
From: report at bugs.python.org (=?utf-8?q?Jan_Veleck=C3=BD?=)
Date: Thu, 24 Nov 2016 22:25:57 +0000
Subject: [docs] [issue28795] Misleading stating,
 that SIGINT handler is installed by default
Message-ID: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za>


New submission from Jan Veleck?:

Hello,
documentation (https://docs.python.org/2/library/signal.html) states, that Python by default installs SIGINT handler which cause KeyboardInterrupt. This is not true everytime according to implementation.
"Python installs a small number of signal handlers by default: SIGPIPE ... and SIGINT is translated into a KeyboardInterrupt exception."
It should also mention this "SIGINT is installed only, when default handler is set at startup.". Because user can run python script from non-interative shell as background task and SIGINT handler is not installed, regardless although user does not change Python default behaviour.

Related SO:
http://stackoverflow.com/questions/40775054/capturing-sigint-using-keyboardinterrupt-exception-works-in-terminal-not-in-scr/40785230?noredirect=1

----------
assignee: docs at python
components: Documentation
messages: 281664
nosy: Jan Veleck?, docs at python
priority: normal
severity: normal
status: open
title: Misleading stating, that SIGINT handler is installed by default
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Nov 24 19:13:05 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 25 Nov 2016 00:13:05 +0000
Subject: [docs] [issue28795] Misleading stating,
 that SIGINT handler is installed by default
In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za>
Message-ID: <1480032785.28.0.517820918689.issue28795@psf.upfronthosting.co.za>


Julien Palard added the comment:

Maybe something like:

> Python installs a small number of signal handlers by default: SIGPIPE is ignored (so write errors on pipes and sockets can be reported as ordinary Python exceptions) and SIGINT (if parent process has not changed it) is translated into a KeyboardInterrupt exception. All of these can be overridden.

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

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

From report at bugs.python.org  Thu Nov 24 19:30:48 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 25 Nov 2016 00:30:48 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1480033848.6.0.299822943821.issue28753@psf.upfronthosting.co.za>


Julien Palard added the comment:

After a discussion with Victor, I propose a patch to update the documentation allowing users strictly following the doc to let Clinic use FASTCALLs, it's a nice performance gain, and it's safe to let clinic use it.

----------
Added file: http://bugs.python.org/file45630/issue28753.fastcall.diff

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

From report at bugs.python.org  Thu Nov 24 19:44:09 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 25 Nov 2016 00:44:09 +0000
Subject: [docs] [issue28796] FIX warnings in documentation build
In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za>
Message-ID: <1480034649.35.0.889612057974.issue28796@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov 24 19:44:26 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 25 Nov 2016 00:44:26 +0000
Subject: [docs] [issue28796] FIX warnings in documentation build
In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za>
Message-ID: <1480034666.51.0.869451443694.issue28796@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file45631/issue28796.diff

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

From report at bugs.python.org  Thu Nov 24 22:34:51 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 25 Nov 2016 03:34:51 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1480044891.13.0.650816574269.issue28749@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

v2 LGTM.

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

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

From report at bugs.python.org  Thu Nov 24 23:29:35 2016
From: report at bugs.python.org (Liang-Bo Wang)
Date: Fri, 25 Nov 2016 04:29:35 +0000
Subject: [docs] [issue28798] Describe character as a string of length one
 instead of size one in tutorial
Message-ID: <1480048175.03.0.163854418884.issue28798@psf.upfronthosting.co.za>


New submission from Liang-Bo Wang:

In Tutorial "An Informal Introduction" section, character is introduced as a string of size one. It may be true for python 2.x, where str can be interpreted as bytes. However in Python 3, strings are unicode thus the size and the length of a string are usually not the same. Also, using size of a string can be confused with the result returned by sys.getsizeof(mystr), where sys.getsizeof('a') != 1. 

Therefore using "a string of length one" to describe a character may be less confusing. The patch attached changes the wording.

----------
assignee: docs at python
components: Documentation
files: docs_tutorial_introduction_str.diff
keywords: patch
messages: 281678
nosy: ccwang002, docs at python
priority: normal
severity: normal
status: open
title: Describe character as a string of length one instead of size one in tutorial
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45634/docs_tutorial_introduction_str.diff

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

From report at bugs.python.org  Fri Nov 25 01:44:45 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Nov 2016 06:44:45 +0000
Subject: [docs] [issue28798] Describe character as a string of length one
 instead of size one in tutorial
In-Reply-To: <1480048175.03.0.163854418884.issue28798@psf.upfronthosting.co.za>
Message-ID: <1480056284.97.0.980403872926.issue28798@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I think the current wording is fine and do not want to start an unnecessary misadventure of finding every place we say size and replacing it with length.   In general, we use either term almost interchangeable (i.e. the size of dictionary is determined by "len(d)").

The name of sys.getsizeof() may not have been apt, but it seems to have caused no confusion in practice.

We do appreciate the suggestion, but will respectfully decline.

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

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

From report at bugs.python.org  Fri Nov 25 02:39:54 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 25 Nov 2016 07:39:54 +0000
Subject: [docs] [issue28794] inspect.isasyncgen and
 inspect.isasyncgenfunction aren't documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1480059594.14.0.14059683903.issue28794@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi, attached is the patch with docs for inspect.isasyncgen and inspect.isasyncgenfunction 

Please review, and let me know if this works.

Thanks :)

----------
keywords: +patch
nosy: +Mariatta
Added file: http://bugs.python.org/file45636/issue28794.patch

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

From report at bugs.python.org  Fri Nov 25 03:15:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Nov 2016 08:15:58 +0000
Subject: [docs] [issue28753] Clinic: Converting Your First Function is not
 up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1480061758.06.0.160285291543.issue28753@psf.upfronthosting.co.za>


STINNER Victor added the comment:

issue28753.fastcall.diff LGTM.

----------

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

From report at bugs.python.org  Fri Nov 25 03:55:54 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 25 Nov 2016 08:55:54 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1480064154.53.0.156012673177.issue15533@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Before I forget again what I've gathered yesterday about this issue, here's a summary of the problem:

When the the first element of args or the executable argument of subprocess.Popen does not specify an absolute path, the way the executable gets discovered is platform-dependent.
On POSIX platforms, if the argument contains a directory part, the executable gets looked for relative to the current working directory. If the argument is just a basename, the PATH is searched.
On Windows, the executable argument and the first element of args are treated in different ways: If the executable is specified through the executable argument, it is always looked for relative to the current working directory only, but if it's specified through args, it's searched for using Windows-specific rules as documented for the underlying CreateProcess function (see https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx).

Now, on top of all this, if the cwd argument of Popen is used, then, in Python3 on POSIX-platforms, the current working directory gets changed to cwd *before* the above interpretation happens, i.e., if executable or args[0] contains a dirname, the executable is looked for relative to cwd.
On Windows, however, cwd becomes the current working directory of the new process, but is *not* used during the executable lookup.

I guess with this being rather complicated it would be nice to have a dedicated section explaining the interpretation of relative paths as arguments instead of trying to get only the cwd wording right.

----------
components: +Library (Lib)
type:  -> behavior

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

From report at bugs.python.org  Fri Nov 25 07:40:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Nov 2016 12:40:53 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1480077653.63.0.709834394657.issue8145@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch needs to be updated to address changes in issue 10740 so I'm moving the stage field back to 'patch review'.

----------
stage: commit review -> patch review
versions: +Python 3.7

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

From report at bugs.python.org  Fri Nov 25 08:15:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 25 Nov 2016 13:15:05 +0000
Subject: [docs] [issue28785] Clarify the behavior of NotImplemented
In-Reply-To: <1479975264.5.0.247033798803.issue28785@psf.upfronthosting.co.za>
Message-ID: <1480079705.7.0.0927221880677.issue28785@psf.upfronthosting.co.za>


Martin Panter added the comment:

Correct, I meant to say the first fallback is the other call.

BTW your suggested text might hold for __eq__(), but for __ne__(), returning NotImplemented seems to bypass the ?not a.__eq__(b)? fallback.

----------

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

From report at bugs.python.org  Fri Nov 25 08:21:46 2016
From: report at bugs.python.org (Florian Schulze)
Date: Fri, 25 Nov 2016 13:21:46 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1480080106.57.0.461428669655.issue8145@psf.upfronthosting.co.za>


Florian Schulze added the comment:

The documentation patch is a definite improvement.

----------
nosy: +fschulze

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

From report at bugs.python.org  Fri Nov 25 09:32:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Nov 2016 14:32:33 +0000
Subject: [docs] [issue28793] Copy-paste error in collections.abc docs for
 AsyncGenerator
In-Reply-To: <1480024866.24.0.433904664953.issue28793@psf.upfronthosting.co.za>
Message-ID: <1480084353.2.0.470841495132.issue28793@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
assignee:  -> docs at python
components: +Documentation
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Fri Nov 25 09:37:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2016 14:37:50 +0000
Subject: [docs] [issue28796] FIX warnings in documentation build
In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za>
Message-ID: <20161125143747.28917.79486.D93EBB2C@psf.io>


Roundup Robot added the comment:

New changeset f16f0500b49b by Berker Peksag in branch 'default':
Issue #28796: Silence Sphinx warnings
https://hg.python.org/cpython/rev/f16f0500b49b

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

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

From report at bugs.python.org  Fri Nov 25 09:38:07 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Nov 2016 14:38:07 +0000
Subject: [docs] [issue28796] FIX warnings in documentation build
In-Reply-To: <1480034638.89.0.480412503325.issue28796@psf.upfronthosting.co.za>
Message-ID: <1480084687.89.0.455885300154.issue28796@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From report at bugs.python.org  Fri Nov 25 11:05:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 25 Nov 2016 16:05:53 +0000
Subject: [docs] [issue28786] Warnings in Misc/NEWS
In-Reply-To: <1479976926.46.0.685904317893.issue28786@psf.upfronthosting.co.za>
Message-ID: <1480089953.89.0.714480551278.issue28786@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Nov 25 11:32:40 2016
From: report at bugs.python.org (=?utf-8?q?Jan_Veleck=C3=BD?=)
Date: Fri, 25 Nov 2016 16:32:40 +0000
Subject: [docs] [issue28795] Misleading stating,
 that SIGINT handler is installed by default
In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za>
Message-ID: <1480091560.08.0.0775338892332.issue28795@psf.upfronthosting.co.za>


Jan Veleck? added the comment:

That's good.

----------

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

From report at bugs.python.org  Fri Nov 25 11:47:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Nov 2016 16:47:51 +0000
Subject: [docs] [issue28738] Document SIGBREAK as argument for signal()
 under Windows.
In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za>
Message-ID: <20161125164741.21336.26802.83E0D3AD@psf.io>


Roundup Robot added the comment:

New changeset dddce0f539dd by Berker Peksag in branch '3.5':
Issue #28738: Document SIGBREAK as an acceptable value on Windows
https://hg.python.org/cpython/rev/dddce0f539dd

New changeset 43856eb83dc1 by Berker Peksag in branch '3.6':
Issue #28738: Merge from 3.6
https://hg.python.org/cpython/rev/43856eb83dc1

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

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

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

From report at bugs.python.org  Fri Nov 25 11:48:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Nov 2016 16:48:31 +0000
Subject: [docs] [issue28738] Document SIGBREAK as argument for signal()
 under Windows.
In-Reply-To: <1479497916.69.0.534558560438.issue28738@psf.upfronthosting.co.za>
Message-ID: <1480092511.73.0.533154986163.issue28738@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the patch, Wojtek!

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

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

From report at bugs.python.org  Fri Nov 25 12:05:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 25 Nov 2016 17:05:50 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480093550.74.0.501635354094.issue28733@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the patch. I think expanding the "Where to patch" [1] section would be better. We can then refer to it from the mock_open() documentation.


[1] https://docs.python.org/3.6/library/unittest.mock.html#where-to-patch

----------
nosy: +berker.peksag, michael.foord
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Nov 25 13:24:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Nov 2016 18:24:28 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1480098268.84.0.0351042429121.issue8145@psf.upfronthosting.co.za>


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


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

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

From vadmium+py at gmail.com  Sun Nov 20 17:29:41 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Sun, 20 Nov 2016 22:29:41 -0000
Subject: [docs] Rework syntax highlighing in howto/clinic.rst (issue 28755)
Message-ID: <20161120222941.18508.17592@psf.upfronthosting.co.za>


https://bugs.python.org/review/28755/diff/19230/Doc/howto/clinic.rst
File Doc/howto/clinic.rst (right):

https://bugs.python.org/review/28755/diff/19230/Doc/howto/clinic.rst#newcode1672
Doc/howto/clinic.rst:1672: .. code-block: none
[2] howto/clinic.rst:1672: comment seems to be intended as a directive

https://bugs.python.org/review/28755/

From vadmium+py at gmail.com  Wed Nov 23 18:59:49 2016
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 23 Nov 2016 23:59:49 -0000
Subject: [docs] Update documented signatures of tp_get/setattr (issue
 28771)
Message-ID: <20161123235949.2968.4561@psf.upfronthosting.co.za>

Reviewers: storchaka,


https://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst
File Doc/c-api/typeobj.rst (right):

https://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst#newcode204
Doc/c-api/typeobj.rst:204: PyObject * tp_getattr(PyObject *o, char
*attr_name);
On 2016/11/22 13:13:41, storchaka wrote:
> Shouldn't we use the ".. code-block:: c" directive?

I don?t think it is needed. At the top of the file there is already ?..
highlightlang:: c?, and this already comes up highlighted for me. I
copied the markup from
<https://docs.python.org/3.7/c-api/typeobj.html#c.PyTypeObject.tp_descr_get>
further down the page.

> Please document explicitly that attr_name point't to read-only string,
its
> content shouldn't be modified.

Do you mean the function that implements tp_getattr should not modify
the string? I guess I can add that if you want, though it seems to be
going into more detail than normal. It seems reasonable to leave it out,
along with other details like the string is null-terminated and its
lifetime is the duration of the function call.

https://bugs.python.org/review/28771/diff/19257/Doc/c-api/typeobj.rst#newcode219
Doc/c-api/typeobj.rst:219: PyObject * tp_setattr(PyObject *o, char
*attr_name, PyObject *v);
On 2016/11/22 13:13:41, storchaka wrote:
> Please document explicitly that "setting *v* to *NULL* to delete an
attribute
> must be supported".

Okay.



Please review this at https://bugs.python.org/review/28771/

Affected files:
  Doc/c-api/typeobj.rst


# HG changeset patch
# Parent  c51045920410a2d63c7e4188a1865ea5c04fc93a
Issue #28769: Update documented signatures of PyTypeObject methods

diff -r c51045920410 Doc/c-api/typeobj.rst
--- a/Doc/c-api/typeobj.rst	Tue Nov 22 19:43:11 2016 +0900
+++ b/Doc/c-api/typeobj.rst	Tue Nov 22 11:44:00 2016 +0000
@@ -199,8 +199,9 @@
 
    This field is deprecated.  When it is defined, it should point to a function
    that acts the same as the :c:member:`~PyTypeObject.tp_getattro` function, but taking a C string
-   instead of a Python string object to give the attribute name.  The signature is
-   the same as for :c:func:`PyObject_GetAttrString`.
+   instead of a Python string object to give the attribute name.  The signature is ::
+
+      PyObject * tp_getattr(PyObject *o, char *attr_name);
 
    This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_getattro`: a subtype
    inherits both :c:member:`~PyTypeObject.tp_getattr` and :c:member:`~PyTypeObject.tp_getattro` from its base type when
@@ -213,9 +214,9 @@
 
    This field is deprecated.  When it is defined, it should point to a function
    that acts the same as the :c:member:`~PyTypeObject.tp_setattro` function, but taking a C string
-   instead of a Python string object to give the attribute name.  The signature is
-   the same as for :c:func:`PyObject_SetAttrString`, but setting
-   *v* to *NULL* to delete an attribute must be supported.
+   instead of a Python string object to give the attribute name.  The signature is ::
+
+      PyObject * tp_setattr(PyObject *o, char *attr_name, PyObject *v);
 
    This field is inherited by subtypes together with :c:member:`~PyTypeObject.tp_setattro`: a subtype
    inherits both :c:member:`~PyTypeObject.tp_setattr` and :c:member:`~PyTypeObject.tp_setattro` from its base type when



From angwerzx at 126.com  Thu Nov 24 04:35:22 2016
From: angwerzx at 126.com (angwerzx at 126.com)
Date: Thu, 24 Nov 2016 09:35:22 -0000
Subject: [docs] Fixed the documentation of the mapping codec APIs (issue
 28749)
Message-ID: <20161124093522.1929.59679@psf.upfronthosting.co.za>


http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1413
Doc/c-api/unicode.rst:1413: decode characters.  The mapping objects
provided must only support the
I don't understand what the 'only' means. It looks to me except
'__getitem__' no other methods could be defined.

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1430
Doc/c-api/unicode.rst:1430: cause an error.
Cause an error or not depends on *errors*.

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1430
Doc/c-api/unicode.rst:1430: cause an error.
Cause an error or not depends on *errors*.

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1442
Doc/c-api/unicode.rst:1442: ``None`` are  treated as "undefined mapping"
and cause an error.
                     ^ redundant space

One more question about this API, why not allow *mapping* be NULL and
default to Latin1? PyUnicode_EncodeCharmap and PyUnicode_DecodeCharmap
both get this behaviour.

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

From victor.stinner at gmail.com  Thu Nov 24 06:17:54 2016
From: victor.stinner at gmail.com (victor.stinner at gmail.com)
Date: Thu, 24 Nov 2016 11:17:54 -0000
Subject: [docs] Fixed the documentation of the mapping codec APIs (issue
 28749)
Message-ID: <20161124111754.2968.56986@psf.upfronthosting.co.za>


http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1413
Doc/c-api/unicode.rst:1413: decode characters.  The mapping objects
provided must only support the
I suggest to remove the "only" word.

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

From angwerzx at 126.com  Thu Nov 24 06:24:21 2016
From: angwerzx at 126.com (angwerzx at 126.com)
Date: Thu, 24 Nov 2016 11:24:21 -0000
Subject: [docs] Fixed the documentation of the mapping codec APIs (issue
 28749)
Message-ID: <20161124112421.1929.90415@psf.upfronthosting.co.za>


http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst
File Doc/c-api/unicode.rst (right):

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1413
Doc/c-api/unicode.rst:1413: decode characters.  The mapping objects
provided must only support the
On 2016/11/24 12:17:54, haypo wrote:
> I suggest to remove the "only" word.

The impression when I read this sentence is that "no other methods could
be defined except __getitem__" instead of "there could be many methods
but here we only care about __getitem__".

http://bugs.python.org/review/28749/diff/19217/Doc/c-api/unicode.rst#newcode1430
Doc/c-api/unicode.rst:1430: cause an error.
On 2016/11/24 12:08:21, storchaka wrote:
> On 2016/11/24 10:35:22, xiang.zhang wrote:
> > Cause an error or not depends on *errors*.
> 
> Is this a question? All these cases mean "undefined mapping". They
cause calling
> the error handler named *error* if it is provided, as in other
decoders.

I mean error is somewhat similar to exception. But I see utf8 codec uses
the same wording. So it's fine.

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

From report at bugs.python.org  Fri Nov 25 17:23:35 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Nov 2016 22:23:35 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1480112615.69.0.0131655518673.issue28763@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I checked the patch with Rietveld and all the changes are '-' to '--' in numeric ranges in text. LGTM.

----------
nosy: +terry.reedy
stage:  -> commit review

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

From report at bugs.python.org  Sat Nov 26 06:08:54 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Nov 2016 11:08:54 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL
Message-ID: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>


New submission from Stefan Krah:

It looks like METH_FASTCALL gives nice speedups (#28754).

Is this an internal interface or can it be documented like
METH_KEYWORDS etc.?

----------
assignee: docs at python
components: Documentation
messages: 281766
nosy: docs at python, haypo, serhiy.storchaka, skrah
priority: normal
severity: normal
stage: needs patch
status: open
title: Add documentation for METH_FASTCALL
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Nov 26 06:50:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 26 Nov 2016 11:50:47 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <20161126115043.81585.65967.66B7F6B7@psf.io>


Roundup Robot added the comment:

New changeset 77307437ae15 by Serhiy Storchaka in branch '3.5':
Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges
https://hg.python.org/cpython/rev/77307437ae15

New changeset 59bd48afa1bc by Serhiy Storchaka in branch '2.7':
Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges
https://hg.python.org/cpython/rev/59bd48afa1bc

New changeset 3434d84efdd4 by Serhiy Storchaka in branch '3.6':
Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges
https://hg.python.org/cpython/rev/3434d84efdd4

New changeset dc407f50e823 by Serhiy Storchaka in branch 'default':
Issue #28763: Use double hyphens (rendered as en-dashes) in numerical ranges
https://hg.python.org/cpython/rev/dc407f50e823

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

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

From report at bugs.python.org  Sat Nov 26 06:51:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 11:51:30 +0000
Subject: [docs] [issue28763] Use en-dashes for ranges in docs
In-Reply-To: <1479728095.62.0.206474714084.issue28763@psf.upfronthosting.co.za>
Message-ID: <1480161090.82.0.661253028992.issue28763@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Terry.

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

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

From report at bugs.python.org  Sat Nov 26 06:59:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 11:59:42 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1480161582.33.0.0686266640963.issue28805@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I suggest to keep it internal. It's meaning may be changed in future. I have some ideas about making it more convenient and faster (but I'm not sure that they would work).

----------

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

From report at bugs.python.org  Sat Nov 26 09:35:00 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 26 Nov 2016 14:35:00 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480170900.75.0.0714267606463.issue26363@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Xavier, thanks for reporting,

Your first point is right, the implementation being:

 if (PyDict_GetItemString(globals, "__builtins__") == NULL) {
     if (PyDict_SetItemString(globals, "__builtins__",
                              PyEval_GetBuiltins()) != 0)
         return NULL;
 }

See proposed diff.


For the second point, it looks right to me in the documentation, literally: "A reference to the dictionary of the builtin module builtins is inserted", so:

It's a dict:

>>> exec('print(type(globals()["__builtins__"]))', {})
<class 'dict'>

It's the reference to the dict of the builtins module:

>>> exec('globals()["__builtins__"]["len"] = "foo"', {})
>>> len
'foo'

If you still think there's inconsistencies, please provide some code to reproduce it.

----------
keywords: +patch
Added file: http://bugs.python.org/file45652/issue26363.patch

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

From report at bugs.python.org  Sat Nov 26 09:59:44 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 26 Nov 2016 14:59:44 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1480172384.5.0.423475699582.issue26483@psf.upfronthosting.co.za>


Julien Palard added the comment:

Proposing a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file45653/issue26483.diff

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

From report at bugs.python.org  Sat Nov 26 10:06:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Nov 2016 15:06:44 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL
In-Reply-To: <CAMpsgwYHE311rnWj9CCGj41aoCSPioAkvQKVVSjRyFF+8A3X-g@mail.gmail.com>
Message-ID: <CAMpsgwZ7pmm0Ngvvf+wYuV2Nvh7gtQ2R6p1D5YQU1tM1H87WcA@mail.gmail.com>


STINNER Victor added the comment:

Is it possible to use Argument Clinic for third party extensions? If yes, I
suggest to use it.

It would also be nice if Cython could use it automatically. So we can
suggest to use Cython. I don't know well Cython, maybe your idea is very
dumb :-)

Serhiy Storchaka added the comment:
> I suggest to keep it internal. It's meaning may be changed in future. I
have some ideas about making it more convenient and faster (but I'm not
sure that they would work).

Ah? Can you please elaborate your secret plan? :-)

----------

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

From report at bugs.python.org  Sat Nov 26 10:18:23 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 26 Nov 2016 15:18:23 +0000
Subject: [docs] [issue8145] Documentation about sqlite3 isolation_level
In-Reply-To: <1268643705.49.0.319902511171.issue8145@psf.upfronthosting.co.za>
Message-ID: <1480173503.26.0.818351246103.issue8145@psf.upfronthosting.co.za>


Changes by Aviv Palivoda <palaviv at gmail.com>:


----------
nosy: +palaviv

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

From report at bugs.python.org  Sat Nov 26 12:32:49 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 26 Nov 2016 17:32:49 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1480181569.7.0.966069831242.issue28805@psf.upfronthosting.co.za>


Stefan Krah added the comment:

There are a couple of problems with using Argument Clinic for third
party projects.

First, it makes no stability promises:

"Currently Argument Clinic is considered internal-only for CPython. ..."


Then, for large projects that already use some generated code (like
NumPy), IMO the result would be unmaintainable.


So it would be nice to have a public stable API -- of course there
is no hurry if Serhiy has plans to improve it.

----------

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

From report at bugs.python.org  Sat Nov 26 12:43:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 17:43:54 +0000
Subject: [docs] [issue28805] Add documentation for METH_FASTCALL
In-Reply-To: <1480158534.61.0.510309261592.issue28805@psf.upfronthosting.co.za>
Message-ID: <1480182233.99.0.782201008628.issue28805@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Ah? Can you please elaborate your secret plan? :-)

I already said about this. Move the part of parsing keyword argument outside of the function. The caller should unpack keyword arguments and pass just a raw array of PyObject*. Missed arguments are set to NULL. This could make _PyArg_ParseStack() simpler and might even allow to inline arguments parsing code.

----------

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

From report at bugs.python.org  Sat Nov 26 13:05:22 2016
From: report at bugs.python.org (Soren Solari)
Date: Sat, 26 Nov 2016 18:05:22 +0000
Subject: [docs] [issue28809] mention asyncio.gather non-deterministic task
 starting order
Message-ID: <1480183522.09.0.687431688906.issue28809@psf.upfronthosting.co.za>


New submission from Soren Solari:

https://github.com/python/asyncio/issues/432

asyncio.gather documentation states:
"the returned future?s result is the list of results (in the order of the original sequence, not necessarily the order of results arrival)"

An additional statement like "tasks are not guaranteed to be started in a predicable order" would aid users and slove the discussion in issue 432 above.

----------
assignee: docs at python
components: Documentation
messages: 281787
nosy: Soren Solari, docs at python
priority: normal
severity: normal
status: open
title: mention asyncio.gather non-deterministic task starting order
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Sat Nov 26 13:24:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 18:24:04 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
Message-ID: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There are many bytecode changes in 3.6, but seems most of them are not documented (besides short line in _bootstrap_external.py).

* The bytecode now uses 16 bit units (wordcode) (issue26647).

* Added FORMAT_VALUE opcode (issue25483).

* Added BUILD_CONST_KEY_MAP opcode (issue27140).

* Added BUILD_STRING opcode (issue27078).

* Added BUILD_TUPLE_UNPACK_WITH_CALL opcode (issue28257).

* Added SETUP_ANNOTATIONS and STORE_ANNOTATION opcodes (issue27985).

* Changed CALL_FUNCTION, CALL_FUNCTION_KW and BUILD_MAP_UNPACK_WITH_CALL opcodes, removed CALL_FUNCTION_VAR, CALL_FUNCTION_VAR_KW opcodes, added CALL_FUNCTION_EX opcode (issue27213).

* Changed MAKE_FUNCTION opcode, removed MAKE_CLOSURE opcode (issue27095).

* Not related to the bytecode itself: lineno delta of code.co_lnotab now is signed (issue26107).

There are third-party projects that need correct information about bytecode changes.

----------
assignee: docs at python
components: Documentation
messages: 281788
nosy: docs at python, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: Document bytecode changes in 3.6
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Nov 26 13:27:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 18:27:53 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1480184872.91.0.417710499176.issue28635@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please take a look at issue28810. Most bytecode changes are not documented.

----------

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

From report at bugs.python.org  Sat Nov 26 14:48:14 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 26 Nov 2016 19:48:14 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1480189694.51.0.568222612534.issue28810@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

SETUP_ANNOTATIONS and STORE_ANNOTATION opcodes are documented in documentation for dis module. Should they be documented also somewhere else?

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

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

From report at bugs.python.org  Sat Nov 26 15:10:11 2016
From: report at bugs.python.org (Elvis Pranskevichus)
Date: Sat, 26 Nov 2016 20:10:11 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1480191011.42.0.495231489933.issue28635@psf.upfronthosting.co.za>


Elvis Pranskevichus added the comment:

Here's a patch to add opcode changes to the What's New document.  Thanks for pointing this out Serhiy.

----------
Added file: http://bugs.python.org/file45657/0001-Issue-28635-Document-Python-3.6-opcode-changes.patch

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

From report at bugs.python.org  Sat Nov 26 15:25:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 20:25:44 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1480191944.39.0.614542998073.issue28635@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thanks Elvis!

----------

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

From report at bugs.python.org  Sat Nov 26 15:29:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Nov 2016 20:29:35 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1480192175.45.0.368023443153.issue28810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think only the mention in What's News is needed. Elvis already provided a patch in issue28635.

But the documentation of other opcodes may be missed or outdated.

----------

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

From report at bugs.python.org  Sun Nov 27 08:07:33 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Nov 2016 13:07:33 +0000
Subject: [docs] [issue28814] Deprecation notice on inspect.getargvalues() is
 incorrect
Message-ID: <1480252052.94.0.16018093739.issue28814@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

inspect.getargvalues() and inspect.formatargvalues() were deprecated in Python 3.5 as part of implementing issue 20438

This is incorrect, as these are *frame* introspection related functions, not callable introspection ones. The documentation and implementation layout is confusing though, as they're interleaved with the callable introspection operations.

----------
assignee: docs at python
components: Documentation
messages: 281824
nosy: docs at python, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Deprecation notice on inspect.getargvalues() is incorrect
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Nov 27 16:31:06 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Nov 2016 21:31:06 +0000
Subject: [docs] [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1480282266.35.0.101624080376.issue28810@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Mon Nov 28 04:46:38 2016
From: report at bugs.python.org (Decorater)
Date: Mon, 28 Nov 2016 09:46:38 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480326398.63.0.235906054705.issue28816@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


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

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

From report at bugs.python.org  Mon Nov 28 05:27:09 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 28 Nov 2016 10:27:09 +0000
Subject: [docs] [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1480328829.18.0.630311419343.issue9938@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

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

From report at bugs.python.org  Mon Nov 28 05:28:34 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Nov 2016 10:28:34 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1480328914.71.0.52811299574.issue28749@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Why are you removing the introductory section on how mappings work ?

Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1".

----------
nosy: +lemburg

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

From report at bugs.python.org  Mon Nov 28 06:24:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Nov 2016 11:24:57 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1480332297.62.0.991320149527.issue28749@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Xiang. I forgot about comments in headers, the updated path updates them too.

> Why are you removing the introductory section on how mappings work ?

Because it is not correct. I copied it to descriptions of concrete functions with correcting it according to the peculiarity of particular function.

> Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1".

The word "bytes" means here not Python bytes object, but is used in more common meaning: an integer in the range from 0 to 255.

----------

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

From report at bugs.python.org  Mon Nov 28 06:25:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Nov 2016 11:25:11 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1479637798.25.0.994184606714.issue28749@psf.upfronthosting.co.za>
Message-ID: <1480332311.15.0.543082958429.issue28749@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file45669/docs-PyUnicode_Translate-3.patch

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

From report at bugs.python.org  Mon Nov 28 06:54:04 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Nov 2016 11:54:04 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <1480332297.62.0.991320149527.issue28749@psf.upfronthosting.co.za>
Message-ID: <583C1AD7.7020206@egenix.com>


Marc-Andre Lemburg added the comment:

On 28.11.2016 12:24, Serhiy Storchaka wrote:
>> Why are you removing the introductory section on how mappings work ?
> 
> Because it is not correct. I copied it to descriptions of concrete functions with correcting it according to the peculiarity of particular function.

The only part that is not correct is "single string characters".
This should read "single bytes" or "bytes strings of length 1".

I also don't see where you copied the description. Without some
description of what "mappings" are in the context of the charmap
codec, it's not easy to understand what the purpose of these
APIs is. Please just fix the bytes wording instead of removing the
whole intro.

>> Also, this wording needs to be corrected: "bytes (integers in the range from 0 to 255)". Bytes are not integers. I'd suggest to use the more correct wording "bytes strings of length 1".
> 
> The word "bytes" means here not Python bytes object, but is used in more common meaning: an integer in the range from 0 to 255.

That's confusing, since we use the term "bytes" as referring
to the bytes object in Python. Please use "integers in the range
0-255".

Aside: The deprecation of PyUnicode_EncodeCharmap() also seems misplaced
in this context, since only the Py_UNICODE version of the API is
deprecated. The functionality still exists and is useful. An API
similar to the _PyUnicode_EncodeCharmap() API should be made publicly
available to accommodate for the deprecation, since the mentioned
PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString()
APIs are not suitable as replacement. PyUnicode_AsCharmapString()
doesn't support error handling (strange, BTW) and
PyUnicode_AsEncodedString() has a completely unrelated meaning (no
idea why it's mentioned here at all).

----------

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

From report at bugs.python.org  Mon Nov 28 07:47:25 2016
From: report at bugs.python.org (Rares Aioanei)
Date: Mon, 28 Nov 2016 12:47:25 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
Message-ID: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>


New submission from Rares Aioanei:

In section 6.4.1. it's said "Although certain modules are designed to export only names that follow certain patterns when you use import *, it is still considered bad practise in production code." "practise" should be "practice", as it's a noun.

----------
assignee: docs at python
components: Documentation
messages: 281870
nosy: Rares Aioanei, docs at python
priority: normal
severity: normal
status: open
title: Typo in section 6 of the Python 3.4 documentation
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon Nov 28 07:51:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Nov 2016 12:51:42 +0000
Subject: [docs] [issue28749] Fixed the documentation of the mapping codec
 APIs
In-Reply-To: <583C1AD7.7020206@egenix.com>
Message-ID: <2044899.0GaGWQQ6m7@xarax>


Serhiy Storchaka added the comment:

> The only part that is not correct is "single string characters".
> This should read "single bytes" or "bytes strings of length 1".

This is not correct. Decoding mappings map not bytes strings, but integers. 
And this is not the only incorrect part. Decoding mappings can map to 
multicharacter Unicode strings, not to single Unicode	 characters. Not just 
None, but the integer 0xfffe and Unicode string '\ufffe' mean "undefined 
mapping".

There are similar incorrectnesses about encoding mappings.

> I also don't see where you copied the description. Without some
> description of what "mappings" are in the context of the charmap
> codec, it's not easy to understand what the purpose of these
> APIs is. Please just fix the bytes wording instead of removing the
> whole intro.

Decoding mappings were desribed in the introduction and in the description of 
PyUnicode_DecodeCharmap() (both are outdated and incomplete). I merged and 
corrected descriptions and left it only in one place, since 
PyUnicode_DecodeCharmap() is the only function that needs this. Same for 
encoding mappings. Both decoding and encoding mappings do not have a relation 
to PyUnicode_Translate(). The paragraph about a LookupError in the 
introduction was totally wrong. I left in the introduction only common part. 
Other details are too different in decoding, encoding and translation mappings.

> >> Also, this wording needs to be corrected: "bytes (integers in the range
> >> from 0 to 255)". Bytes are not integers. I'd suggest to use the more
> >> correct wording "bytes strings of length 1".> 
> > The word "bytes" means here not Python bytes object, but is used in more
> > common meaning: an integer in the range from 0 to 255.
> That's confusing, since we use the term "bytes" as referring
> to the bytes object in Python. Please use "integers in the range
> 0-255".

Okay, I'll remove the word "bytes" here.  But how would you formulate the 
following sentence: "Unmapped bytes (ones which cause a :exc:`LookupError`) as 
well as mapped to ``None``, ``0xFFFE`` or ``'\ufffe'`` are treated as "undefined 
mapping" and cause an error."?

> Aside: The deprecation of PyUnicode_EncodeCharmap() also seems misplaced
> in this context, since only the Py_UNICODE version of the API is
> deprecated. The functionality still exists and is useful. An API
> similar to the _PyUnicode_EncodeCharmap() API should be made publicly
> available to accommodate for the deprecation, since the mentioned
> PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString()
> APIs are not suitable as replacement. PyUnicode_AsCharmapString()
> doesn't support error handling (strange, BTW) and
> PyUnicode_AsEncodedString() has a completely unrelated meaning (no
> idea why it's mentioned here at all).

Only PyUnicode_EncodeCharmap() is deprecated, PyUnicode_AsCharmapString() is 
not deprecated. I placed the deprecated function just after its non-deprecated 
counerpart following the pattern for other deprecated functions. If you prefer 
I'll move both deprecated functions (PyUnicode_EncodeCharmap and 
PyUnicode_TranslateCharmap) together at the end of this section.

I don't know why PyUnicode_AsCharmapString() don't support the errors 
argument. I added PyUnicode_AsEncodedString() as a replacement (issue19569) 
because this is the only public non-deprecated way to do a charmap encoding 
with errors handling. There is no exact equivalent, but 
PyUnicode_AsCharmapString() and PyUnicode_AsEncodedString() cover different 
areas of using PyUnicode_EncodeCharmap().

----------

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

From report at bugs.python.org  Mon Nov 28 08:31:27 2016
From: report at bugs.python.org (Decorater)
Date: Mon, 28 Nov 2016 13:31:27 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480339887.06.0.704726433607.issue28816@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
components:  -Windows

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

From report at bugs.python.org  Mon Nov 28 08:51:03 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 28 Nov 2016 13:51:03 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480341063.8.0.697688228323.issue28820@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Rares thanks for reporting.

While building a patch for this issue I found another occurrence of the error.

----------
keywords: +patch
nosy: +mdk
Added file: http://bugs.python.org/file45672/issue28820.diff

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

From report at bugs.python.org  Mon Nov 28 09:40:13 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 28 Nov 2016 14:40:13 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480344013.15.0.490688420759.issue28816@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan, twouters -steve.dower

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

From report at bugs.python.org  Mon Nov 28 11:46:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 28 Nov 2016 16:46:06 +0000
Subject: [docs] [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161128164602.13835.47205.2113DA2F@psf.io>


Roundup Robot added the comment:

New changeset 52038705827d by Yury Selivanov in branch '3.6':
Issue #28635: Document Python 3.6 opcode changes
https://hg.python.org/cpython/rev/52038705827d

New changeset 48fb6a4cb5f8 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/48fb6a4cb5f8

----------

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

From report at bugs.python.org  Mon Nov 28 16:35:42 2016
From: report at bugs.python.org (Decorater)
Date: Mon, 28 Nov 2016 21:35:42 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480368942.73.0.751074096616.issue28816@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
nosy:  -brett.cannon, eric.snow, ncoghlan, paul.moore, tim.golden, twouters, zach.ware

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

From report at bugs.python.org  Mon Nov 28 16:38:02 2016
From: report at bugs.python.org (Decorater)
Date: Mon, 28 Nov 2016 21:38:02 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480369082.99.0.432694375879.issue28816@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
nosy: +twouters

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

From report at bugs.python.org  Mon Nov 28 17:12:29 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 28 Nov 2016 22:12:29 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480371149.27.0.246720463638.issue14845@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Isn't the difference between generator expressions and comprehensions what's dealt with by PEP479? So it seems this issue is outdated enough to deserve being closed?

----------
nosy: +wolma

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

From report at bugs.python.org  Mon Nov 28 18:30:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 28 Nov 2016 23:30:01 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480375801.62.0.430795656764.issue28820@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, this looks good to me, although let?s not touch the blank line at the end of the file.

----------
nosy: +martin.panter
stage:  -> commit review
versions: +Python 2.7, Python 3.5, Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Mon Nov 28 19:35:32 2016
From: report at bugs.python.org (Decorater)
Date: Tue, 29 Nov 2016 00:35:32 +0000
Subject: [docs] [issue28816] Document if zipimport can respect import hooks
 to load custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1480379732.87.0.548827684903.issue28816@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

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

From report at bugs.python.org  Mon Nov 28 21:21:07 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Nov 2016 02:21:07 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480386067.83.0.773397546679.issue14845@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov 28 22:00:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Nov 2016 03:00:00 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1480388400.85.0.864825554475.issue15533@psf.upfronthosting.co.za>


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


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions:  -Python 3.4

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

From report at bugs.python.org  Mon Nov 28 22:37:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Nov 2016 03:37:15 +0000
Subject: [docs] [issue28773] typing.FrozenSet missing in documentation.
In-Reply-To: <1479818611.82.0.728843423423.issue28773@psf.upfronthosting.co.za>
Message-ID: <1480390635.11.0.624482112761.issue28773@psf.upfronthosting.co.za>


Ned Deily added the comment:

> Is that the right procedure still?

Yes, thanks!

----------
stage: commit review -> resolved

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

From report at bugs.python.org  Mon Nov 28 22:55:32 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 29 Nov 2016 03:55:32 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1480391731.97.0.0456358492603.issue28450@psf.upfronthosting.co.za>


Ned Deily added the comment:

Where do we stand on this issue?  At the moment, 3.6.0 is on track to be released as is.

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

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

From report at bugs.python.org  Tue Nov 29 00:02:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Nov 2016 05:02:15 +0000
Subject: [docs] [issue28450] Misleading/inaccurate documentation about
 unknown escape sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1480395735.2.0.599122284314.issue28450@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we should discuss this on Python-Dev.

----------

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

From report at bugs.python.org  Tue Nov 29 03:30:25 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Nov 2016 08:30:25 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480408225.72.0.659679620715.issue14845@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

@wolma: I don't think PEP 479 is relevant here: we're not raising StopIteration inside a generator function, which is the situation that PEP 479 covers. The behaviour in 3.6 matches that originally reported:

Python 3.6.0b3 (default, Nov  2 2016, 08:15:32) 
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def five(x):
...     for _ in range(5):
...         yield x
... 
>>> F = five('x')
>>> [next(F) for _ in range(10)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
StopIteration
>>> F = five('x')
>>> list(next(F) for _ in range(10))
['x', 'x', 'x', 'x', 'x']

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

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

From report at bugs.python.org  Tue Nov 29 03:34:25 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 29 Nov 2016 08:34:25 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480408465.55.0.764509876525.issue14845@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Mark, PEP479 is not fully in effect in 3.6 yet. 3.7 will raise the RuntimeError, but 3.6 still only gives a DeprecationWarning.

----------

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

From report at bugs.python.org  Tue Nov 29 03:46:42 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 29 Nov 2016 08:46:42 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480409202.63.0.333074302689.issue14845@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

running with "-W always":

>>> def five(x):
...     for _ in range(5):
...         yield x
... 

>>> F = five('x')

>>> [next(F) for _ in range(10)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <listcomp>
StopIteration

>>> list(next(F) for _ in range(10))
__main__:1: DeprecationWarning: generator '<genexpr>' raised StopIteration
[]

----------

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

From report at bugs.python.org  Tue Nov 29 04:06:30 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Nov 2016 09:06:30 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480410390.0.0.365521847945.issue14845@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Wolfgang: ah, thanks, that makes more sense. I misunderstood; sorry for the noise.

----------

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

From report at bugs.python.org  Tue Nov 29 04:12:40 2016
From: report at bugs.python.org (Michael Foord)
Date: Tue, 29 Nov 2016 09:12:40 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480410760.17.0.402814892379.issue28733@psf.upfronthosting.co.za>


Michael Foord added the comment:

open shouldn't always be patched in builtins, it's much better to patch it in the specific namespace it's being called from. So the doc patch here shouldn't be applied as is.

----------

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

From report at bugs.python.org  Tue Nov 29 05:10:10 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 29 Nov 2016 10:10:10 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480414210.17.0.105644497281.issue28820@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Martin,

Removed the removing of the double new line at end of file.

----------
Added file: http://bugs.python.org/file45686/issue28820-2.diff

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

From report at bugs.python.org  Tue Nov 29 05:12:22 2016
From: report at bugs.python.org (Lele Gaifax)
Date: Tue, 29 Nov 2016 10:12:22 +0000
Subject: [docs] [issue28830] Typo in whatsnew entry for 3.6
Message-ID: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za>


New submission from Lele Gaifax:

At https://hg.python.org/cpython/rev/52038705827d#l1.18 there is an "as part" where probably a "are part" was meant.

----------
assignee: docs at python
components: Documentation
messages: 281977
nosy: docs at python, lelit
priority: normal
severity: normal
status: open
title: Typo in whatsnew entry for 3.6
versions: Python 3.6

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

From report at bugs.python.org  Tue Nov 29 05:14:43 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Nov 2016 10:14:43 +0000
Subject: [docs] [issue28830] Typo in whatsnew entry for 3.6
In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za>
Message-ID: <1480414483.15.0.145327564415.issue28830@psf.upfronthosting.co.za>


SilentGhost added the comment:

Reads just fine to me.

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

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

From report at bugs.python.org  Tue Nov 29 06:36:36 2016
From: report at bugs.python.org (Lele Gaifax)
Date: Tue, 29 Nov 2016 11:36:36 +0000
Subject: [docs] [issue28830] Typo in whatsnew entry for 3.6
In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za>
Message-ID: <1480419396.5.0.932715597098.issue28830@psf.upfronthosting.co.za>


Lele Gaifax added the comment:

Ok, thank you.

----------

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

From report at bugs.python.org  Tue Nov 29 06:37:24 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 29 Nov 2016 11:37:24 +0000
Subject: [docs] [issue28830] Typo in whatsnew entry for 3.6
In-Reply-To: <1480414342.52.0.93217667841.issue28830@psf.upfronthosting.co.za>
Message-ID: <1480419444.47.0.350515948617.issue28830@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov 29 09:44:20 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Tue, 29 Nov 2016 14:44:20 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480430660.57.0.601360033042.issue28733@psf.upfronthosting.co.za>


Micha? Bultrowicz added the comment:

Then where it should be patched in? Can you give an example? From what I've checked patching only works in __main__ and builtins.

----------

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

From report at bugs.python.org  Tue Nov 29 10:10:59 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2016 15:10:59 +0000
Subject: [docs] [issue14845] list(<generator expression>) != [<list
 comprehension>]
In-Reply-To: <1337294857.69.0.824992743087.issue14845@psf.upfronthosting.co.za>
Message-ID: <1480432259.66.0.800725783606.issue14845@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, then this issue can be closed unless someone thinks it is worth documenting the lack of PEP 479 in 3.5 and 3.6.

----------

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

From report at bugs.python.org  Tue Nov 29 14:33:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Nov 2016 19:33:12 +0000
Subject: [docs] [issue21818] cookielib documentation references Cookie
 module, not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <1480447992.1.0.919789180378.issue21818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thus the only way to fix links is to specify full names? Does docs_class_links-2.7.patch look good to you?

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

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

From report at bugs.python.org  Tue Nov 29 14:34:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Nov 2016 19:34:51 +0000
Subject: [docs] [issue22039] PyObject_SetAttr doesn't mention value = NULL
In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za>
Message-ID: <1480448091.13.0.754503425538.issue22039@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov 29 15:36:56 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 29 Nov 2016 20:36:56 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480451816.92.0.648785521188.issue28820@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Just OOC, what version of English are the docs supposed to use? In American English, noun vs. verb doesn't matter, it's always "practice" (there is no such word as "practise").

In this case it doesn't matter (it's a noun, and everyone agrees on the spelling), but is there a defined standard?

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

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

From report at bugs.python.org  Tue Nov 29 15:43:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 29 Nov 2016 20:43:32 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480452212.4.0.598146958378.issue28820@psf.upfronthosting.co.za>


R. David Murray added the comment:

We at least used to point to Apple's style guide.  I'm not sure where we point at the moment (it's in the documentation somewhere :).  But yes, it's pretty much formal American English, though I'm sure there are places where other spelling has crept in.

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

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

From report at bugs.python.org  Tue Nov 29 16:17:43 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 29 Nov 2016 21:17:43 +0000
Subject: [docs] [issue28795] Misleading stating,
 that SIGINT handler is installed by default
In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za>
Message-ID: <1480454263.77.0.888548154382.issue28795@psf.upfronthosting.co.za>


Julien Palard added the comment:

Proposed as patches but english is not my native language so please review carefully.

----------
keywords: +patch
Added file: http://bugs.python.org/file45695/issue28795-tip.diff

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

From report at bugs.python.org  Tue Nov 29 16:17:55 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 29 Nov 2016 21:17:55 +0000
Subject: [docs] [issue28795] Misleading stating,
 that SIGINT handler is installed by default
In-Reply-To: <1480026357.5.0.735730414686.issue28795@psf.upfronthosting.co.za>
Message-ID: <1480454275.57.0.466742313604.issue28795@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file45696/issue28795-2.7.diff

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

From report at bugs.python.org  Tue Nov 29 17:26:11 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 29 Nov 2016 22:26:11 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1480458370.87.0.464804467858.issue15533@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Just found issue15451, which reports a similar inconsistency between Windows and POSIX for 'PATH' provided through the Popen env parameter as for cwd. It seems that, on POSIX-platforms, the PATH environment variable passed through env affects the executable lookup if executable does *not* contain a dirname, but on Windows the new PATH never affects executable lookup. So, again, relative executable paths are causing platform-specific behavior.

----------

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

From report at bugs.python.org  Tue Nov 29 18:12:42 2016
From: report at bugs.python.org (Jan Lachnitt)
Date: Tue, 29 Nov 2016 23:12:42 +0000
Subject: [docs] [issue15533] subprocess.Popen(cwd) documentation
In-Reply-To: <1343886272.5.0.825552125397.issue15533@psf.upfronthosting.co.za>
Message-ID: <1480461162.86.0.593170800296.issue15533@psf.upfronthosting.co.za>


Jan Lachnitt added the comment:

Thank Wolfgang Maier for reminding this issue and providing various details and observations. Having taken a look at my old comments (and at others' comments, too), I feel that the cwd issue deserves a clearer description.

Let's use the following simple C program as the callee:

#include <stdio.h>
#include <unistd.h>
int main(int argc, char* argv[]) {
    char cwd[FILENAME_MAX+1];
    for (int i = 0; i < argc; ++i)
        printf("argv[%d] = %s\n", i, argv[i]);
    getcwd(cwd, FILENAME_MAX);
    printf("cwd = %s\n", cwd);
    return 0;
}

As is evident, this program merely prints its arguments and working directory. I have built it using gcc, called it "print_argv+cwd", and placed it in the "subdir" subdirectory of the current directory.

Next, let's use the following Python 3 script for testing:

import os
from subprocess import run  # substitute run->call in Python < 3.5
prg_name = 'print_argv+cwd'
if os.name == 'nt':
    prg_name += '.exe'
else:
    prg_name = os.path.join('.',prg_name)
dir_name = 'subdir'
def execute(path, cwd):
    print('Executing "{}" in "{}":'.format(path,cwd))
    try:
        run([path], cwd=cwd)  # substitute run->call in Python < 3.5
    except Exception as err:
        print(type(err).__qualname__+':', err)
print('Script\'s cwd =', os.getcwd())
execute(prg_name, dir_name)
execute(os.path.join(dir_name,prg_name), dir_name)
execute(os.path.abspath(os.path.join(dir_name,prg_name)), dir_name)

Output on Linux with Python 3.5.2:

Script's cwd = /home/jenda/Bug reports/Python/subprocess
Executing "./print_argv+cwd" in "subdir":
argv[0] = ./print_argv+cwd
cwd = /home/jenda/Bug reports/Python/subprocess/subdir
Executing "subdir/./print_argv+cwd" in "subdir":
FileNotFoundError: [Errno 2] No such file or directory: 'subdir/./print_argv+cwd'
Executing "/home/jenda/Bug reports/Python/subprocess/subdir/print_argv+cwd" in "subdir":
argv[0] = /home/jenda/Bug reports/Python/subprocess/subdir/print_argv+cwd
cwd = /home/jenda/Bug reports/Python/subprocess/subdir

Output on Windows with Python 3.5.2:

Script's cwd = C:\Users\Jenda\Bug reports\Python\subprocess
Executing "print_argv+cwd.exe" in "subdir":
FileNotFoundError: [WinError 2] Syst?m nem??e nal?zt uveden? soubor
Executing "subdir\print_argv+cwd.exe" in "subdir":
argv[0] = subdir\print_argv+cwd.exe
cwd = C:\Users\Jenda\Bug reports\Python\subprocess\subdir
Executing "C:\Users\Jenda\Bug reports\Python\subprocess\subdir\print_argv+cwd.exe" in "subdir":
argv[0] = C:\Users\Jenda\Bug reports\Python\subprocess\subdir\print_argv+cwd.exe
cwd = C:\Users\Jenda\Bug reports\Python\subprocess\subdir

Summary: On Linux, subprocess.run (or call or Popen) behaves correctly, in accordance with current documentation. On Windows, both possible relative paths produce incorrect results. With the first one, relative to "subdir", Python fails to find the executable. With the other one, relative to the script's cwd, Python actually executes the program, but argv[0] is inconsistent with cwd. Imagine that the called program wants to resolve its own path: It joins cwd and argv[0] and gets "C:\Users\Jenda\Bug reports\Python\subprocess\subdir\subdir\print_argv+cwd.exe", which is an incorrect (and nonexistent) path. This is why the cwd issue is not just a documentation issue.

The only option working correctly on Windows is the last one, using absolute path of the executable.

----------

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

From report at bugs.python.org  Tue Nov 29 19:27:39 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Wed, 30 Nov 2016 00:27:39 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480465659.63.0.455369110798.issue26363@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

It is not the dictionary of builtin module, which is inserted in , but the current __builtin__ global which happen to be normally the dictionnary of builtin. Hence in the following code, the builtins propagation works has expected.

>>> eval("""eval('spam("hello world")',{})""",{"__builtins__":{"eval":eval,"spam":print}})
hello world

----------

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

From report at bugs.python.org  Wed Nov 30 05:21:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Nov 2016 10:21:14 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <20161130102111.27153.96982.D28F87D7@psf.io>


Roundup Robot added the comment:

New changeset 4f24641cd030 by Martin Panter in branch '2.7':
Issue #28820: Fix spelling of ?practice? as a noun
https://hg.python.org/cpython/rev/4f24641cd030

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

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

From report at bugs.python.org  Wed Nov 30 05:34:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 30 Nov 2016 10:34:14 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480502053.87.0.0852076039279.issue28820@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m waiting for the 3.6 release candidate before pushing to the Py 3 branches.

----------

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

From report at bugs.python.org  Wed Nov 30 05:55:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 30 Nov 2016 10:55:40 +0000
Subject: [docs] [issue22039] PyObject_SetAttr doesn't mention value = NULL
In-Reply-To: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za>
Message-ID: <1480503340.27.0.349839333598.issue22039@psf.upfronthosting.co.za>


Martin Panter added the comment:

As of Issue 25701, the null-to-delete feature is documented as being deprecated in favour of calling the related Del functions or macros. There was a python-dev thread at <https://marc.info/?i=n32kch$eie$1 at ger.gmane.org>.

I?m not sure if that is good enough, or do we need to e.g. clarify that the deprecation is only at the API (C header) level, and not the ABI level?

----------

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

From report at bugs.python.org  Wed Nov 30 06:06:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Nov 2016 11:06:32 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <20161130110629.31378.53383.7941CC84@psf.io>


Roundup Robot added the comment:

New changeset 83e3c863594c by Martin Panter in branch '2.7':
Issue #25701: Document that some C APIs can both set and delete items
https://hg.python.org/cpython/rev/83e3c863594c

----------

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

From report at bugs.python.org  Wed Nov 30 06:11:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 30 Nov 2016 11:11:14 +0000
Subject: [docs] [issue25701] Document that tp_setattro and tp_setattr are
 used for deleting attributes
In-Reply-To: <1448261904.1.0.459120146493.issue25701@psf.upfronthosting.co.za>
Message-ID: <1480504274.3.0.579101216476.issue25701@psf.upfronthosting.co.za>


Martin Panter added the comment:

I made one minor change: element ? slice

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

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

From report at bugs.python.org  Wed Nov 30 14:37:04 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Wed, 30 Nov 2016 19:37:04 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480534624.21.0.0201346075346.issue28733@psf.upfronthosting.co.za>


Micha? Bultrowicz added the comment:

Ok, I've checked again and now patching "file_writer.open" works. I have no idea what I was doing wrong the last time I checked... So I guess I'll close the issue.

----------

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

From report at bugs.python.org  Wed Nov 30 14:37:19 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Wed, 30 Nov 2016 19:37:19 +0000
Subject: [docs] [issue28733] Show how to use mock_open in modules other that
 __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480534639.49.0.446628742432.issue28733@psf.upfronthosting.co.za>


Changes by Micha? Bultrowicz <michal.bultrowicz at gmail.com>:


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

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

From report at bugs.python.org  Wed Nov 30 16:40:33 2016
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Wed, 30 Nov 2016 21:40:33 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
Message-ID: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>


New submission from Eric N. Vander Weele:

This patch cleans up Misc/README.AIX for addressed known issues.

Issues that have been marked fixed: #11184, #11185
Issues resolved by new AIX version: #1745108
Issues resolved, but not yet marked fixed/closed: #11188

Additionally, it looks like #10709 can be closed out as well.

For #1745108 and #11188, I have verified they are addressed as of Python 3.5.2 on AIX 7.1 locally.  The Python Buildbot is failing to build the curses module, but I believe Setup.local is needed for _curses and _curses_panel.  I have gotten the aforementioned curses modules building locally and will figure out the appropriate channels getting Python's PPC64 AIX Buildbot updated independently.

----------
assignee: docs at python
components: Documentation
files: cleanup-readme-aix.patch
keywords: patch
messages: 282105
nosy: David.Edelsohn, docs at python, ericvw
priority: normal
severity: normal
status: open
title: Clean up known issues for AIX
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45712/cleanup-readme-aix.patch

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

From report at bugs.python.org  Wed Nov 30 16:42:13 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 30 Nov 2016 21:42:13 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480542133.91.0.791322924218.issue28845@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +Michael.Felt
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Nov 30 16:55:01 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 30 Nov 2016 21:55:01 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1480542901.05.0.15877160458.issue28755@psf.upfronthosting.co.za>


Julien Palard added the comment:

Bump, 10 days later, hope this diff is still straightforward to merge.

----------

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

From report at bugs.python.org  Wed Nov 30 17:17:28 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 30 Nov 2016 22:17:28 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480544248.17.0.651044035028.issue26363@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Xavier,

> It is not the dictionary of builtin module, which is inserted in , but the current __builtin__ global 

It looks wrong, I'll even say the exact contrary: It _is_ the dictionary of builtin module which is inserted in, not the current __builtin__ global, with this proof:

$ ./python
Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) 
[GCC 5.4.1 20161019] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> print(id(__builtins__), id(__builtins__.__dict__))
140325888797784 140325888840368
>>> eval("""print(id(__builtins__))""", {})
140325888840368


> the current __builtin__ global which happen to be normally the dictionnary of builtin.

That's not necessarily true, according to [the builtins doc](https://docs.python.org/dev/library/builtins.html):

> The value of __builtins__ is normally either this module or the value of this module?s __dict__ attribute.

Typically:
$ ./python
Python 3.7.0a0 (default, Nov 29 2016, 11:20:17) 
[GCC 5.4.1 20161019] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import builtins
>>> id(builtins), id(builtins.__dict__), id(__builtins__)
(139706743340120, 139706743382704, 139706743340120)

Here, __builtins__ is the module, not its dict.

----------

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

From report at bugs.python.org  Wed Nov 30 17:33:43 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 30 Nov 2016 22:33:43 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480545222.91.0.976203842149.issue28845@psf.upfronthosting.co.za>


Julien Palard added the comment:

You're also removing:

> * Python has not been fully tested on AIX when compiled as a 64 bit
>   application.

I do not have an AIX at hand but can someone at least confirm that all test passes? Having a few issues fixed does not mean that Python has been fully tested.

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

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

From report at bugs.python.org  Wed Nov 30 18:00:47 2016
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Wed, 30 Nov 2016 23:00:47 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480546847.88.0.417651304135.issue28845@psf.upfronthosting.co.za>


Eric N. Vander Weele added the comment:

> Having a few issues fixed does not mean that Python has been fully tested.

I uploaded cleanup-readme-aix2.patch, which revives back the line removed in question and only removes lines which reference issues.

I just noticed the results of Python's tests on my AIX box differ from Python's PPC64 Buildbot.  I'll investigate separately and submit patches for getting the tests to pass, which then it may be more appropriate to remove that line.

----------
Added file: http://bugs.python.org/file45713/cleanup-readme-aix2.patch

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

From report at bugs.python.org  Wed Nov 30 18:26:09 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 30 Nov 2016 23:26:09 +0000
Subject: [docs] [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480548369.37.0.806025862563.issue28845@psf.upfronthosting.co.za>


Julien Palard added the comment:

Look like issue1745108 has only be closed for being "outdated" (msg240919 ), it does not clearly mean that the bug does no longer exists.

Have you been able to test the example in it?

----------

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

From report at bugs.python.org  Wed Nov 30 19:39:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 01 Dec 2016 00:39:41 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480552781.33.0.915874894055.issue28820@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Ned can correct me if I'm wrong, but you can push documentation patches without waiting for 3.6.0rc1.

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

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

From report at bugs.python.org  Wed Nov 30 20:18:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Dec 2016 01:18:21 +0000
Subject: [docs] [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1480555100.9.0.082298810073.issue28755@psf.upfronthosting.co.za>


Martin Panter added the comment:

It will apply to the 3.5 and 3.6 branches if I first backport revision 0a18d2cfeb52 (Issue 28753), which I think is valid. But I would wait until there is a branch for 3.6.1, and then commit to all three branches. (Ned asked for only release-critical changes to go into 3.6 at the moment.)

On the other hand, Larry only applied the other patch to 3.7, so we could just do that again if people prefer.

----------
nosy: +martin.panter
stage:  -> commit review
versions: +Python 3.5 -Python 2.7

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

From report at bugs.python.org  Wed Nov 30 20:33:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Dec 2016 01:33:16 +0000
Subject: [docs] [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <20161201013312.31378.8835.BC83F9B7@psf.io>


Roundup Robot added the comment:

New changeset 2fd070fa6c15 by Martin Panter in branch '2.7':
Issue #28771: Correct documentation of signatures using const
https://hg.python.org/cpython/rev/2fd070fa6c15

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

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

From report at bugs.python.org  Wed Nov 30 21:28:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 01 Dec 2016 02:28:15 +0000
Subject: [docs] [issue28820] Typo in section 6 of the Python 3.4
 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1480559295.8.0.940921942212.issue28820@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yes, there is no restriction on doc changes at the moment as long as they are relevant to 3.6.0.

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

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

From report at bugs.python.org  Wed Nov 30 22:12:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 01 Dec 2016 03:12:45 +0000
Subject: [docs] [issue26483] docs unclear on difference between
 str.isdigit() and str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1480561964.97.0.622378458339.issue26483@psf.upfronthosting.co.za>


Martin Panter added the comment:

?digits which do not form decimal radix forms?

I see you have taken this from a Unicode document, but ?forming a form? seems a long way of saying very little. The difference seems a bit vague, but I gather that digits not in the Unicode ?decimal digit? category are often (always?) still decimal digits, but primarily used for a symbolic or typographical meaning more than in a plain number, e.g. superscripts, subscripts and other fonts, added circles and other decorations.

----------
stage: needs patch -> patch review
versions: +Python 3.7

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

From report at bugs.python.org  Wed Nov 30 22:30:34 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 01 Dec 2016 03:30:34 +0000
Subject: [docs] [issue26363] __builtins__ propagation is misleading
 described in exec and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480563034.74.0.478986569543.issue26363@psf.upfronthosting.co.za>


Eryk Sun added the comment:

As shown above, exec and eval default to calling PyEval_GetBuiltins when the globals dict doesn't define '__builtins__'. PyEval_GetBuiltins uses the current frame's f_builtins. If there isn't a current frame, it defaults to the interpreter's builtins, which should be the dict of the builtins module. 

If exec and eval didn't do this, the default behavior would be to create a minimal f_builtins dict for the new frame. This dict only contains a reference to None, and it doesn't get set as '__builtins__' in globals. For example:

    from inspect import currentframe
    from ctypes import pythonapi, py_object
    g = py_object({'currentframe': currentframe})
    code = py_object(compile('currentframe()', '', 'eval'))
    frame = pythonapi.PyEval_EvalCode(code, g, g)

    >>> frame.f_builtins
    {'None': None}
    >>> frame.f_globals
    {'currentframe': <function currentframe at 0x7f2fa1d6c2f0>}

This minimalist default isn't useful in general. exec and eval are saving people from the tedium of having to manually define a useful __builtins__ when passing a new globals. The frame object uses this __builtins__ to initialize its f_builtins. Also, it knows to look for __builtins__ as a module, as used by __main__:

    g = py_object({'currentframe': currentframe, '__builtins__': __builtins__})
    frame = pythonapi.PyEval_EvalCode(code, g, g)

    >>> frame.f_builtins is vars(__builtins__)
    True

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

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