From report at bugs.python.org  Tue Jul  1 00:00:38 2014
From: report at bugs.python.org (Karl Richter)
Date: Mon, 30 Jun 2014 22:00:38 +0000
Subject: [docs]
	[issue21889]	https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions	doesn't
	explain exception
Message-ID: <1404165638.91.0.279596288902.issue21889@psf.upfronthosting.co.za>


New submission from Karl Richter:

Although the section https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions (of the multiprocessing module documentation) is titled "... and exceptions" it doesn't say anything about exceptions. I assume that it behaves like the thread API (as stated and referenced in the introduction of the module doc). This implies though that either the reference is limited to that statement (-> remove "and exceptions" from the header as there's no special section on them because everything can be found in thread API) or add an explicit reference to the thread API. If this assumption is wrong the section is badly organized or doesn't make any sense at all.

I'm not yet sure about exception handling in the multiprocessing module in case it's different from threads, but that shouldn't matter for this doc issue report. 

I'd also like to suggest a more detailed section on exceptions with usage of queues to pass them as objects to the parent or another process.

----------
assignee: docs at python
components: Documentation
messages: 221987
nosy: docs at python, krichter
priority: normal
severity: normal
status: open
title: https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions doesn't explain exception
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue Jul  1 05:15:07 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Jul 2014 03:15:07 +0000
Subject: [docs] [issue21202] Naming a file` io.py` causes cryptic error
	message
In-Reply-To: <1397239551.94.0.578791540537.issue21202@psf.upfronthosting.co.za>
Message-ID: <1404184507.27.0.640061843312.issue21202@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> test needed

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

From report at bugs.python.org  Tue Jul  1 08:10:52 2014
From: report at bugs.python.org (Ned Deily)
Date: Tue, 01 Jul 2014 06:10:52 +0000
Subject: [docs]
	[issue21889]	https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions	doesn't
	explain exception
In-Reply-To: <1404165638.91.0.279596288902.issue21889@psf.upfronthosting.co.za>
Message-ID: <1404195052.01.0.857034522819.issue21889@psf.upfronthosting.co.za>


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


----------
nosy: +sbt

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

From report at bugs.python.org  Tue Jul  1 14:20:17 2014
From: report at bugs.python.org (Andy Maier)
Date: Tue, 01 Jul 2014 12:20:17 +0000
Subject: [docs] [issue17904] bytes should be listed as built-in function for
	2.7
In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za>
Message-ID: <1404217217.3.0.0862870548271.issue17904@psf.upfronthosting.co.za>


Andy Maier added the comment:

Ezio, what do you mean with "string signature"?

For me, the patch looks fine as it is.

----------
nosy: +andymaier

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

From report at bugs.python.org  Tue Jul  1 14:25:35 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 01 Jul 2014 12:25:35 +0000
Subject: [docs] [issue17904] bytes should be listed as built-in function for
	2.7
In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za>
Message-ID: <1404217535.11.0.997489213928.issue17904@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I mean here: https://docs.python.org/2/library/functions.html#str

----------

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

From report at bugs.python.org  Tue Jul  1 18:00:46 2014
From: report at bugs.python.org (Andy Maier)
Date: Tue, 01 Jul 2014 16:00:46 +0000
Subject: [docs] [issue17904] bytes should be listed as built-in function for
	2.7
In-Reply-To: <1367663679.93.0.0164308850832.issue17904@psf.upfronthosting.co.za>
Message-ID: <1404230446.6.0.987489447542.issue17904@psf.upfronthosting.co.za>


Andy Maier added the comment:

Your patch right now generates the line:

  New in version 2.6: bytes() has been added as an alias for str()

at the end of the paragraph for str().

To me, that is sufficient for the description of str().

If anything, we could add a separate paragraph for bytes(), after the paragraph for bytearray(), e.g. like this:

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

.. function:: bytes()

   Alias for :func:`str`.

   .. versionadded:: 2.6

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

If that is what you had in mind, I think it is a good idea to add it.

Andy

----------

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

From report at bugs.python.org  Tue Jul  1 19:43:43 2014
From: report at bugs.python.org (Andy Maier)
Date: Tue, 01 Jul 2014 17:43:43 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1404236623.28.0.189748022017.issue14097@psf.upfronthosting.co.za>


Andy Maier added the comment:

Zach, I reviewed your 2.7 backport, including a comparison with the latest 3.x patch.

Comments on the 2.7 backport:

1. In "3.1.1 Numbers", on "If both operands are ints,":
The "ints" is a link labeled "int" followed by a normal font "s". I think it would be better to avoid concatenating them, and to say something like: "If both operands are of type int,".

Comments on both the 2.7 backport and on the latest 3.x patch:

2. In the last paragraph of "3.1.1 Numbers" ("In addition to int and float, Python supports..:":
The long type could be mentioned here as well, only with a link and no explanation, consistent with how Decimal and Fraction are mentioned.

Comments on just the latest 3.x patch:

3. In "3.1.2. Strings", I am missing a mentioning that the characters in strings are Unicode characters. I think quite a bit of the unicode subclause of the 2.x patch would be appropriate. I would also mention byte strings at this point, but only the fact that they exist and with a link.

----------
nosy: +andymaier

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

From zamons at gmail.com  Tue Jul  1 00:10:17 2014
From: zamons at gmail.com (Zainal Abidin)
Date: Tue, 01 Jul 2014 05:10:17 +0700
Subject: [docs] Broken Links
Message-ID: <53B1E049.2080107@gmail.com>

I try to download Python 2.7 documentation in these url 
https://docs.python.org/2/download.html, but everytime I try to download 
pdf, html or chm is always say 404 not found. Please fix these errors.

From imagenesis at gmail.com  Tue Jul  1 18:33:49 2014
From: imagenesis at gmail.com (imagenesis at gmail.com)
Date: Tue, 1 Jul 2014 12:33:49 -0400
Subject: [docs] Contents index column scrolls with the browser window
	non-sensically
Message-ID: <CABxodt9tiNFOJ--y9sBbML7OJ9ArJTEiMYP+4_buzF1t7cZk3g@mail.gmail.com>

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

It would appear that the contents index column (left column) should
presumably scroll independently, instead it scrolls with the main window in
which the content resides until it reaches it's end. This is extremely
annoying as it removes the ability to scroll the contents index to jump to
a portion of the contents and breaks the convention of user convenience
afforded by an independent scrollable index as available for large indexes
like APIs.

You are intending to maintain visibility of the column when the content is
scrolled past the header.

As this is the case, in that you are attempting to provide this column for
visibility regardless of the scrolling position of the content, as
specified, it should:

*cease scrolling this column when the content column is scrolled past the
header instead of as it is now, when the bottom of the index column is
reached.*

In addition, independent scrolling functionality to said column in the form
of a scroll component or iframe is required.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140701/c1d208d7/attachment.html>

From report at bugs.python.org  Tue Jul  1 21:31:12 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 01 Jul 2014 19:31:12 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <3h2wfR5HWtz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 438da6ae38fa by Zachary Ware in branch '2.7':
Issue #14097: Backport 796d1371605d and subsequent changes.
http://hg.python.org/cpython/rev/438da6ae38fa

----------

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

From report at bugs.python.org  Tue Jul  1 21:37:45 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 01 Jul 2014 19:37:45 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1404243465.76.0.207150177786.issue14097@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the reviews, Ezio and Andy.  Committed with most of your points addressed, though I did leave out the link to `long` since I could not come up with a good wording for adding it, and `long` is easily findable from `int`.  Also, the link for 'complex numbers' also explains `long`, so it should be easy to find without burdening newbies with another name that they may not need for some time.

Andy: in future, please use the 'review' link to post reviews, it makes it much easier for the patch author to keep track of where your comments are meant to apply, and you can leave comments on multiple versions of a patch if you like.

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

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

From report at bugs.python.org  Wed Jul  2 05:49:21 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jul 2014 03:49:21 +0000
Subject: [docs] [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1404272961.3.0.232241255955.issue10224@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

?ric, I think you should open a separate issue for this.

----------

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

From report at bugs.python.org  Wed Jul  2 06:47:39 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jul 2014 04:47:39 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404276459.78.0.867535267485.issue21902@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Do you want to propose a patch?
https://docs.python.org/3/library/math.html#hyperbolic-functions should be updated as well.

----------
assignee:  -> docs at python
components: +Documentation
keywords: +easy
nosy: +docs at python, ezio.melotti, mark.dickinson, rhettinger, stutzbach
stage:  -> needs patch
type:  -> enhancement
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul  2 07:40:36 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jul 2014 05:40:36 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1404279636.12.0.999986273387.issue14097@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for backporting this!

----------

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

From report at bugs.python.org  Wed Jul  2 08:24:38 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 06:24:38 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404282278.27.0.899426290501.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

How about simply 'inverse hyperbolic cosine', etc.  I think that's more likely to be immediately obvious to readers.

----------

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

From report at bugs.python.org  Wed Jul  2 08:26:14 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 06:26:14 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404282374.35.0.318208741469.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

and the 'radians' bit is obviously nonsense.

----------

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

From report at bugs.python.org  Wed Jul  2 09:10:47 2014
From: report at bugs.python.org (Kevin Davies)
Date: Wed, 02 Jul 2014 07:10:47 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404276459.78.0.867535267485.issue21902@psf.upfronthosting.co.za>
Message-ID: <53B3B072.40704@yahoo.com>


Kevin Davies added the comment:

Unfortunately I'm not currently set up with Mercurial and I'm not sure 
that it makes sense to get that going just for this.

On 07/01/2014 06:47 PM, Ezio Melotti wrote:
> Ezio Melotti added the comment:
>
> Do you want to propose a patch?
> https://docs.python.org/3/library/math.html#hyperbolic-functions should be updated as well.
>
> ----------
> assignee:  -> docs at python
> components: +Documentation
> keywords: +easy
> nosy: +docs at python, ezio.melotti, mark.dickinson, rhettinger, stutzbach
> stage:  -> needs patch
> type:  -> enhancement
> versions: +Python 2.7, Python 3.4, Python 3.5
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue21902>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jul  2 09:12:22 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:12:22 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404285142.14.0.766490665283.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's a patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file35825/acosh_docstring.patch

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

From report at bugs.python.org  Wed Jul  2 09:13:09 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:13:09 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404285189.92.0.297422770998.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Ezio:

> https://docs.python.org/3/library/math.html#hyperbolic-functions should be updated as well.

It looks fine to me.  What do you think should be changed?

----------

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

From report at bugs.python.org  Wed Jul  2 09:14:23 2014
From: report at bugs.python.org (Kevin Davies)
Date: Wed, 02 Jul 2014 07:14:23 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404282278.27.0.899426290501.issue21902@psf.upfronthosting.co.za>
Message-ID: <53B3B10E.7090007@yahoo.com>


Kevin Davies added the comment:

Yes, 'inverse' is probably more obvious to understand than 'area', 
although it doesn't tie into the 'a' of 'acosh', etc.

On 07/01/2014 08:24 PM, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> How about simply 'inverse hyperbolic cosine', etc.  I think that's more likely to be immediately obvious to readers.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue21902>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jul  2 09:16:14 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:16:14 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404285374.01.0.525416765573.issue21902@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> mark.dickinson

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

From report at bugs.python.org  Wed Jul  2 09:44:24 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:44:24 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404287064.6.0.334391627122.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Kevin: does the attached patch look okay to you?

----------

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

From report at bugs.python.org  Wed Jul  2 09:46:40 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:46:40 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404287200.71.0.376977804449.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Updated patch, fixing an accidental double space in the previous one.

----------
Added file: http://bugs.python.org/file35827/acosh_docstring_v2.patch

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

From report at bugs.python.org  Wed Jul  2 09:53:33 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 02 Jul 2014 07:53:33 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404287613.1.0.472512476768.issue21902@psf.upfronthosting.co.za>


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


----------
stage: needs patch -> patch review
type: enhancement -> behavior

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

From report at bugs.python.org  Wed Jul  2 09:56:26 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 02 Jul 2014 07:56:26 +0000
Subject: [docs] [issue12600] Add example of using load_tests to parameterise
	Test	Cases
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1404287786.33.0.121942355121.issue12600@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Any volunteers to do this?  I'd do it myself but by the time somebody explains the detail, it'd probably be easier just to write a patch.  

@Robert just FTR do you know the issue number for "the use of __str__ by the stdlib [which isn't easily overridable - there is a separate issue on that]" which you mention in msg177328?

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

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

From report at bugs.python.org  Wed Jul  2 11:14:49 2014
From: report at bugs.python.org (Dan O'Donovan)
Date: Wed, 02 Jul 2014 09:14:49 +0000
Subject: [docs] [issue21903] ctypes documentation MessageBoxA example
	produces error
Message-ID: <1404292489.9.0.647841786316.issue21903@psf.upfronthosting.co.za>


New submission from Dan O'Donovan:

There is an example in the ctypes python3 documentation for producing a native Windows MessageBoxA 

https://docs.python.org/3.3/library/ctypes.html#ctypes.PYFUNCTYPE

Try as I might, I cannot get this example to run under python 3 (it is in the python3 documentation) - it always produces an error

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type

I apologise for not attaching a fix, I have tried and cannot find one.

----------
assignee: docs at python
components: Documentation
messages: 222088
nosy: Dan.O'Donovan, docs at python
priority: normal
severity: normal
status: open
title: ctypes documentation MessageBoxA example produces error
type: behavior
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jul  2 11:18:25 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 02 Jul 2014 09:18:25 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404292705.03.0.113136530863.issue21902@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

>> https://docs.python.org/3/library/math.html#hyperbolic-functions should be updated as well.
>
> It looks fine to me.  What do you think should be changed?

I just meant to say that the docs and the docstrings should be kept in sync (especially if they are short like in this case).  If the definition in the docs is better it could be used for the docstrings; if something gets improved in the docstring that is not already in the docs it should be added to the docs as well.  If either one is fine there's no need to update it.

----------

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

From report at bugs.python.org  Wed Jul  2 11:18:39 2014
From: report at bugs.python.org (Dan O'Donovan)
Date: Wed, 02 Jul 2014 09:18:39 +0000
Subject: [docs] [issue21903] ctypes documentation MessageBoxA example
	produces error
In-Reply-To: <1404292489.9.0.647841786316.issue21903@psf.upfronthosting.co.za>
Message-ID: <1404292719.77.0.745404195609.issue21903@psf.upfronthosting.co.za>


Dan O'Donovan added the comment:

Additional note, this code snippet does work in python 2. There is a note that all snippets are tested with 'doctest' so I have added the 'tests' tag to this ticket.

----------
components: +Tests

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

From report at bugs.python.org  Wed Jul  2 11:41:28 2014
From: report at bugs.python.org (Kevin Davies)
Date: Wed, 02 Jul 2014 09:41:28 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404287064.6.0.334391627122.issue21902@psf.upfronthosting.co.za>
Message-ID: <53B3D3C4.8010403@yahoo.com>


Kevin Davies added the comment:

Mark: The patch looks good.  Thanks!

----------

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

From report at bugs.python.org  Wed Jul  2 11:55:54 2014
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 02 Jul 2014 09:55:54 +0000
Subject: [docs] [issue12600] Add example of using load_tests to parameterise
	Test	Cases
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1404294954.79.0.489392400527.issue12600@psf.upfronthosting.co.za>


Changes by Jean-Paul Calderone <jean-paul at hybridcluster.com>:


----------
nosy:  -exarkun

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

From report at bugs.python.org  Wed Jul  2 12:50:32 2014
From: report at bugs.python.org (Dan O'Donovan)
Date: Wed, 02 Jul 2014 10:50:32 +0000
Subject: [docs] [issue21903] ctypes documentation MessageBoxA example
	produces error
In-Reply-To: <1404292489.9.0.647841786316.issue21903@psf.upfronthosting.co.za>
Message-ID: <1404298232.12.0.75770869801.issue21903@psf.upfronthosting.co.za>


Dan O'Donovan added the comment:

Ok, this fail is happening because we're using python3 unicode strings to call the ANSI MessageBoxA function. A possible fix;

Encode strings before passing the MessageBoxA (ctypes.txt.diff attached)

Alternatively, calls could be made to the unicode MessageBoxW function, but someone who knows about ctypes / Win32 magic numbers would have to look at that.

(Inspiration take from this stack overflow question http://stackoverflow.com/questions/18164994/the-ctypes-wraps-messageboxa-example-didnt-work-in-python33)

----------
keywords: +patch
Added file: http://bugs.python.org/file35828/ctypes.txt.diff

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

From martineau at linxure.net  Wed Jul  2 15:51:05 2014
From: martineau at linxure.net (Martin Miller)
Date: Wed, 02 Jul 2014 06:51:05 -0700
Subject: [docs] ctypes Module Documentation Bug
Message-ID: <53B40E49.9030502@linxure.net>

   There's a long standing error in one of one examples in section
16.17.2.4 Function Prototypes
<https://docs.python.org/3/library/ctypes.html?highlight=ctypes#function-prototypes>
of the documentation for the ctypes module. It's where there's an
example demonstrating how to wrap the Windows MessageBoxA function.

Please see stackoverflow.com question titled /The ctypes wraps
?MessageBoxA? example didn't work in python33/
<http://stackoverflow.com/questions/18164994/the-ctypes-wraps-messageboxa-example-didnt-work-in-python33/18165271#18165271>
for more details and a possible fix.

-- 
Martin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140702/32dbd59f/attachment.html>

From zachary.ware+pydocs at gmail.com  Wed Jul  2 16:13:23 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 2 Jul 2014 09:13:23 -0500
Subject: [docs] ctypes Module Documentation Bug
In-Reply-To: <53B40E49.9030502@linxure.net>
References: <53B40E49.9030502@linxure.net>
Message-ID: <CAKJDb-OGpJFGUroMJm=J37Z5u+T5yraBdPpwRh0SsZQ0H3_RTQ@mail.gmail.com>

Hi Martin,

On Wed, Jul 2, 2014 at 8:51 AM, Martin Miller <martineau at linxure.net> wrote:
>
> There's a long standing error in one of one examples in section 16.17.2.4 Function Prototypes of the documentation for the ctypes module. It's where there's an example demonstrating how to wrap the Windows MessageBoxA function.
>
> Please see stackoverflow.com question titled The ctypes wraps ?MessageBoxA? example didn't work in python33 for more details and a possible fix.

Thanks for the report!  Interestingly, someone else opened a bug
report for this issue just this morning [1].

-- 
Zach

[1] http://bugs.python.org/issue21903

From report at bugs.python.org  Wed Jul  2 18:19:00 2014
From: report at bugs.python.org (Andy Maier)
Date: Wed, 02 Jul 2014 16:19:00 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1329975473.84.0.795852636525.issue14097@psf.upfronthosting.co.za>
Message-ID: <1404317940.54.0.961530833429.issue14097@psf.upfronthosting.co.za>


Andy Maier added the comment:

> Andy: in future, please use the 'review' link to post reviews,...

Will do ... I just now discovered the "Start Review" link (I'm new here, so thanks for telling me...)

Andy

----------

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

From report at bugs.python.org  Wed Jul  2 18:27:46 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 02 Jul 2014 16:27:46 +0000
Subject: [docs] [issue14097] Improve the "introduction" page of the tutorial
In-Reply-To: <1404317940.54.0.961530833429.issue14097@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-N9ZgUfnk-bQ-8sK0WTqo3W43ew6ErG5_Y=bgaUTKChPA@mail.gmail.com>


Zachary Ware added the comment:

You're both welcome :)

----------

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

From report at bugs.python.org  Wed Jul  2 21:32:53 2014
From: report at bugs.python.org (Jeremy Fusco)
Date: Wed, 02 Jul 2014 19:32:53 +0000
Subject: [docs] [issue21908] Grammatical error in 3.4 tutorial
Message-ID: <1404329572.95.0.36748102404.issue21908@psf.upfronthosting.co.za>


New submission from Jeremy Fusco:

https://docs.python.org/3/tutorial/controlflow.html

Sentence states 'most such' where either would suffice.

current: In most such cases, however, it is convenient to use the enumerate() function, see Looping Techniques

Proposed: In most cases

----------
assignee: docs at python
components: Documentation
messages: 222120
nosy: Jeremy.Fusco, docs at python
priority: normal
severity: normal
status: open
title: Grammatical error in 3.4 tutorial
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Wed Jul  2 23:11:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 02 Jul 2014 21:11:44 +0000
Subject: [docs] [issue21908] Grammatical error in 3.4 tutorial
In-Reply-To: <1404329572.95.0.36748102404.issue21908@psf.upfronthosting.co.za>
Message-ID: <1404335504.04.0.210821000401.issue21908@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is correct English as written.  If you said just 'most cases', it would be ambiguous (most cases of using...something not quite clear from context, it could be range, or looping, or...), whereas if you said 'such cases', that would be wrong, since not all cases where you could use range and an index are served by using enumerate.  'most such' correctly refers specifically to the preceding example, and qualifies it that not all such cases can use enumerate.  (See what I did there? :)

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

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

From report at bugs.python.org  Wed Jul  2 23:18:29 2014
From: report at bugs.python.org (Jeremy Fusco)
Date: Wed, 02 Jul 2014 21:18:29 +0000
Subject: [docs] [issue21908] Grammatical error in 3.4 tutorial
In-Reply-To: <1404329572.95.0.36748102404.issue21908@psf.upfronthosting.co.za>
Message-ID: <1404335909.43.0.779638633399.issue21908@psf.upfronthosting.co.za>


Jeremy Fusco added the comment:

I do, however I feel I'm not the only one that would be thrown by this wording. Perhaps wording such as 'In cases like the above it is more convenient to utilize the enumerate()'.

Thanks for the quick response!

----------

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

From report at bugs.python.org  Thu Jul  3 00:12:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Jul 2014 22:12:28 +0000
Subject: [docs] [issue11776] Constructor signatures missing in types
	module	documentation
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1404339148.87.0.0149196962512.issue11776@psf.upfronthosting.co.za>


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


----------
nosy:  -techtonik
versions: +Python 3.4, Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Jul  3 00:30:14 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Jul 2014 22:30:14 +0000
Subject: [docs] [issue19024] Document asterisk (*), splat or star operator
In-Reply-To: <1379251118.66.0.684713404389.issue19024@psf.upfronthosting.co.za>
Message-ID: <1404340214.52.0.653745263154.issue19024@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have started indexing symbol uses on other issue and will continue after GSOC. I am closing this as there is nothing specific to do.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jul  3 00:41:57 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Jul 2014 22:41:57 +0000
Subject: [docs] [issue11389] unittest: no way to control verbosity of
	doctests from	cmd
In-Reply-To: <1299182245.29.0.387603597674.issue11389@psf.upfronthosting.co.za>
Message-ID: <1404340917.72.0.38867369729.issue11389@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> TextTestRunner methods are not documented

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

From cocoatomo77 at gmail.com  Thu Jul  3 04:03:03 2014
From: cocoatomo77 at gmail.com (tomo cocoa)
Date: Thu, 3 Jul 2014 11:03:03 +0900
Subject: [docs] Where is a "Tools" menu that mentioned from "Python on
	Windows FAQ"?
Message-ID: <CAN_7T0Lt6u1FEBpgpimR0uvK84FA-YTjnaesM6AjuSxW5GiojA@mail.gmail.com>

Hello,

I am a Japanese translator on Python documents.
Now I am trying to work with the item "How do I run a Python program under
Windows?"
in "Python on Windows FAQ".
https://docs.python.org/3.4/faq/windows.html#how-do-i-run-a-python-program-under-windows

This FAQ contains words "use Tools ? Find" ("use :menuselection:`Tools -->
Find`" as a reST source),
but I could not find "Tools" menu on Windows 7.
Of course, I use the "Japanese version" Windows 7 so I might miss that menu.

What GUI menu is indicated with the word "Tools menu"?
(I am happy to be shown with a screen shot.)
Or, only older Windows has "Tools menu"?

Regards,
cocoatomo

-- 
class Cocoatomo:
    name = 'cocoatomo'
    email_address = 'cocoatomo77 at gmail.com'
    twitter_id = '@cocoatomo'
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140703/c9df1b95/attachment.html>

From report at bugs.python.org  Thu Jul  3 10:17:01 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 03 Jul 2014 08:17:01 +0000
Subject: [docs] [issue13784] Documentation of
	xml.sax.xmlreader:	Locator.getLineNumber() and
	Locator.getColumnNumber()
In-Reply-To: <1326542534.95.0.205057982858.issue13784@psf.upfronthosting.co.za>
Message-ID: <1404375421.87.0.369253002141.issue13784@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@patrick please accept our apologies for the delay in getting back to you.

----------
nosy: +BreamoreBoy, christian.heimes
versions: +Python 3.4, Python 3.5 -Python 3.2

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

From report at bugs.python.org  Thu Jul  3 10:43:06 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 08:43:06 +0000
Subject: [docs] [issue10031] Withdraw anti-recommendation of relative
	imports from	documentation
In-Reply-To: <1286309891.2.0.339569302596.issue10031@psf.upfronthosting.co.za>
Message-ID: <1404376986.51.0.383746527582.issue10031@psf.upfronthosting.co.za>


Andy Maier added the comment:

Hi, I would like to revive this issue, and have a few comments:

1. In Darren's original proposal, I suggest to say "implicit (old-style) relative imports" instead of "old-style relative imports", because that is the term used in the Python Tutorial (the description of the ?import? statement in 2.7 does not mention implicit relative imports at all).

2. It seems to me that David's suggestion is already reflected in the original proposal. Or maybe I don't understand it right...

3. I agree with ?ric's comment that implicit relative imports should still be explained. However, I'm not sure that needs to be done in the FAQ. After all, the FAQ does not explain absolute or explicit relative imports either, and spending more words on the discouraged approach than on the recommended approaches does not seem appropriate to me.

4. I have to say that I'm generally unhappy if I see PEPs mentioned as a specification ("See PEP 328 for details"). I have sympathy for referencing PEPs as background information and for the rationales they usually contain. Could we reference the description of the ?import? statement for details, instead of referencing the PEP (in both FAQs)?

Andy

----------
nosy: +andymaier

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

From andreas.r.maier at gmx.de  Thu Jul  3 11:04:47 2014
From: andreas.r.maier at gmx.de (andreas.r.maier at gmx.de)
Date: Thu, 03 Jul 2014 09:04:47 -0000
Subject: [docs] Fix doctest runable examples in python manual (issue 10225)
Message-ID: <20140703090447.1963.27498@psf.upfronthosting.co.za>

Hi, I would like to revive this issue and have added the following
comment to Lib/collections.py within issue10225-py3k.diff:

The \n at the end of this line (and others in this docstring) is used to
create an empty line after this line. Is there a reason to use \n
instead of simply having the empty line? That makes it more readable.

Otherwise, I have reviewed the changes in both diffs and think they are
good to go.

Andy



http://bugs.python.org/review/10225/diff/1884/Lib/collections.py
File Lib/collections.py (right):

http://bugs.python.org/review/10225/diff/1884/Lib/collections.py#newcode294
Lib/collections.py:294: '%(typename)s(%(argtxt)s)'\n
The \n at the end of this line (and others in this docstring) is used to
create an empty line after this line. Is there a reason to use \n
instead of simply having the empty line? That makes it more readable.

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

From report at bugs.python.org  Thu Jul  3 11:06:58 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 09:06:58 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1404378418.43.0.227485594136.issue10225@psf.upfronthosting.co.za>


Andy Maier added the comment:

Hi, I would like to revive this issue and have added a review comment to issue10225-py3k.diff.

Otherwise, I have reviewed the changes in both diffs and think they are good to go.

Andy

----------
nosy: +andymaier

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

From andreas.r.maier at gmx.de  Thu Jul  3 11:17:32 2014
From: andreas.r.maier at gmx.de (andreas.r.maier at gmx.de)
Date: Thu, 03 Jul 2014 09:17:32 -0000
Subject: [docs] Enhancements to gettext docs (issue 10536)
Message-ID: <20140703091732.32365.1729@psf.upfronthosting.co.za>

Added a minor comment on using the context handler approach for opening
a file in example code.


http://bugs.python.org/review/10536/diff/1792/Doc/library/gettext.rst
File Doc/library/gettext.rst (right):

http://bugs.python.org/review/10536/diff/1792/Doc/library/gettext.rst#newcode446
Doc/library/gettext.rst:446: fp.close()
The fp.close() is not needed, because the context handler exit closes
the file (see
https://docs.python.org/2.7/library/stdtypes.html#file.close). I fully
agree with the change to use the context handler approach for opening
the file, and if we use it we should be consequent and rely on it fully.

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

From report at bugs.python.org  Thu Jul  3 11:38:29 2014
From: report at bugs.python.org (Jan Kanis)
Date: Thu, 03 Jul 2014 09:38:29 +0000
Subject: [docs] [issue21910] File protocol should document if writelines
	must handle	generators sensibly
Message-ID: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>


New submission from Jan Kanis:

The resolution of issue 5445 should be documented somewhere properly, so people can depend on it or not.

IOBase.writelines handles generator arguments without problems, i.e. without first draining the entire generator and then writing the result in one go. That would require large amounts of memory if the generator is large, and fail entirely if the generator is infinite. 

codecs.StreamWriter.writelines uses self.write(''.join(argument)) as implementation, which fails on very large or infinite arguments.

According to issue 5445 it is not part of the file protocol that .writelines must handle (large/infinite) generators, only list-like iterables. However as far as I know this is not documented anywhere, and sometimes people assume that writelines is meant for this case. E.g. jinja (https://github.com/mitsuhiko/jinja2/blob/master/jinja2/environment.py#L1153, the dump method is explicitly documented to stream). The guarantees that .writelines makes or does not make in this regard should be documented somewhere, so that either .writeline implementations that don't handle large generators can be pointed out as bugs, or code that makes assumptions on .writeline handling large generators can be.

I personally think .writelines should handle large generators, since in the python 3 world a lot of apis were iterator-ified and it is wat a lot of people would probably expect. But having a clear and documented decision on this is more important. 

(note: I've copied most of the nosy list from #5445)

----------
assignee: docs at python
components: Documentation, IO
messages: 222165
nosy: JanKanis, benjamin.peterson, dlesco, docs at python, hynek, lemburg, pitrou, stutzbach, terry.reedy
priority: normal
severity: normal
status: open
title: File protocol should document if writelines must handle generators sensibly
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul  3 11:51:54 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 09:51:54 +0000
Subject: [docs] [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <1404381114.83.0.578120424573.issue10536@psf.upfronthosting.co.za>


Andy Maier added the comment:

?ric,
I have reviewed the patch, and have one minor comment on it (see review page). Otherwise, I think it is good to go into v3 (The version list for this issue also shows 2.7, and the 2.7 version of this file is quite different from the v3 tip version, so a backport is still needed).

Barry's review I think is also still needed :-)

My 2 cents on your questions to Barry:

On 3): I like your proposal.

On a): Can you be more specific on where it is POSIX specific, and what the issue is with that?

On b): After understanding that your comment is about the v3 version, I agree with the comment in general. However, the set of functions changes between 2.7 and 3.x tip (for example, ugettext() from v2 is no longer in v3 because gettext() now returns Unicode strings), and if people try to understand what changed, I think it would be helpful to be more explicit, particularly because the v2 text is also explicit. So I would leave the "Unicode string" verbiage unchanged. But I don't have a strong opinion on this and can go either way.

Andy

----------
nosy: +andymaier

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

From report at bugs.python.org  Thu Jul  3 15:09:29 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 03 Jul 2014 13:09:29 +0000
Subject: [docs] [issue12842] Docs: first parameter of tp_richcompare()
	always has the	correct type
In-Reply-To: <1314304285.47.0.471516118599.issue12842@psf.upfronthosting.co.za>
Message-ID: <1404392969.24.0.992267137346.issue12842@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in 71a0743f36db and 06bdd7e8fffd

----------
nosy: +asvetlov
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  3 16:02:54 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 03 Jul 2014 14:02:54 +0000
Subject: [docs] [issue14124] _pickle.c comment/documentation improvement
In-Reply-To: <1330203362.98.0.289163571674.issue14124@psf.upfronthosting.co.za>
Message-ID: <1404396174.81.0.667503001607.issue14124@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can we have a patch review on this please

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Thu Jul  3 16:05:47 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 03 Jul 2014 14:05:47 +0000
Subject: [docs] [issue14189] Documentation for some C APIs is missing
	clear	specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1404396347.1.0.55672705717.issue14189@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Can someone comment please as I'm not brave enough to touch the C code or docs.

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

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

From report at bugs.python.org  Thu Jul  3 17:23:11 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 15:23:11 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404400990.98.0.603566496709.issue14050@psf.upfronthosting.co.za>


Andy Maier added the comment:

Just out of curiosity: Why do the patches attached to this issue not have a "review" link?

Also, both (2.7 and 3.2) patches do not line up with the current 2.7 and 3.x tip, both hunks get rejected.

Comments on both patches:

1. It would be helpful if the text "Each item needs to define an ordering relationship." was followed by a statement about what happens when that is not the case (that is what Ezio also suggested), and where to look for details on how to define an ordering relationship. The problem with that is that there is no good place that is devoted to exactly that. The relatively best place for defining comparison I found so far is: https://docs.python.org/2.7/tutorial/datastructures.html#comparing-sequences-and-other-types and its 3.x equivalent.

2. The example that raises the TypeError is not needed, IMHO. This puts too much focus on the case that does not work. If we mention in the description that a TypeError is raised, that should be sufficient.

Andy

----------
nosy: +andymaier

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

From report at bugs.python.org  Thu Jul  3 18:07:44 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 03 Jul 2014 16:07:44 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404403664.17.0.124113444108.issue14050@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Why do the patches attached to this issue not have a "review" link?

because

> both (2.7 and 3.2) patches do not line up with the current
> 2.7 and 3.x tip, both hunks get rejected.

The "review" link only appears if the patch applies cleanly on the "default" branch.  Preparing a new patch against "default" should make the link appear.

----------
type:  -> enhancement
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Jul  3 20:19:36 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 18:19:36 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404411576.15.0.195397865568.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Hi, I'd like to revive this issue.

IMHO, the changes in issue12067-expressions_v2.diff go too far. I don't think that deleting the entire section about the details of comparing objects of the same type makes sense.

I agree with Terry's statement in msg170936 that the chapter is about the operators and not about the ways to customize them, so some of what the patch introduces in that area should not be introduced.

So far, that means that I'm pretty much against that patch entirely...

Having said that, I do believe that there are still issues:

1. both the 2.7 and 3.x sections about the comparison operators are sufficiently convoluted and could be organized better by grouping the various statements that are made, into categories like this:

- comparisons involving objects of user-defined types
- comparing objects of same built-in type
- comparing objects of differing built-in type

2. There are still some errors, ambiguities and omissions that need to be fixed. For example, in the 3.x version:

a) omission about treatment of NaN for numbers of different type (could in theory be implied from the statement "are converted to same type", but that statement is problematic as was pointed out in Mark's comment on this issue).

b) Amgiguous statement "Most numeric types [of same type] can be compared with one another.". I think what is true is that all built-in numeric types (including Fraction and Decimal) compare mathematically correct in 3.x, and that the only non-support is that complex numbers are not considered orderable and an attempt to use an ordering operator raises TypeError.

c) Ambiguous statement "When cross-type comparison is not supported, the comparison method returns NotImplemented.". If this is about the customization methods, it should not be here, but there. Here, it is relevant that a TypeError is raised when using the operator.

d) Terminology in "Bytes objects are compared lexicographically using the numeric values of their elements.": Chapter [4.8.1. Bytes] defines bytes objects as immutable sequences of single bytes (not elements).

e) Terminology in "Tuples and lists are compared lexicographically using comparison of corresponding elements.": lists and tuples contain "items" not "elements", and an item-wise comparison should not be called "lexicographically" because that makes sense only when the items are characters.

f) Ambiguity in "If not equal, the sequences are ordered the same as their first differing elements.": "Are ordered" could be interpreted (e.g. by non-native speakers) to mean that the sequence is changed to achieve that ordering, which is not the case of course.

g) Editorial: In the list item about sets and froze sets, the example set {2,3} is not in example font.

h) Omission: Range types are not covered.

i) Omission: The section "Comparison of objects of differing types..." is silent about which built-in types support comparison across types (except for numeric types where that is covered). I think that should be explicitly listed for those built-in types that are also listed explicitly in the section about comparing objects of same type.

I'll try to come up with a patch for 3.x, and once that is agreed, with one for 2.x.

Andy

----------
nosy: +andymaier

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

From report at bugs.python.org  Thu Jul  3 20:57:47 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 18:57:47 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404413867.66.0.66584426421.issue14050@psf.upfronthosting.co.za>


Andy Maier added the comment:

Ah! I was somehow suspecting that. Thanks for clarifying!

I'll prepare a patch.

To correct my earlier message, the best place to link for comparisons is probably the Conparisons subchapter of the Expressions chapter in the reference. See also issue12067.

----------

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

From report at bugs.python.org  Thu Jul  3 21:04:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 03 Jul 2014 19:04:44 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404414284.2.0.506723574363.issue14050@psf.upfronthosting.co.za>


R. David Murray added the comment:

The review link will also appear if the patch is generated via hg diff with diff.git turned *off*.  You will note that both existing patches use --git, which omits parent changeset information, so our system can't figure out what to apply them against in order to generate the review link.

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

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

From report at bugs.python.org  Thu Jul  3 21:34:32 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 19:34:32 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404416072.49.0.571363955882.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


----------
versions: +Python 3.5 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file35843/issue12067-expressions_v3.diff

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

From report at bugs.python.org  Thu Jul  3 21:35:35 2014
From: report at bugs.python.org (Andy Maier)
Date: Thu, 03 Jul 2014 19:35:35 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404416135.02.0.483351588901.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded issue12067-expressions_v3.diff for the 3.5 tip.
Please review.

----------

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

From report at bugs.python.org  Thu Jul  3 23:09:36 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Jul 2014 21:09:36 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404421776.28.0.402451505033.issue12067@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul  3 23:11:09 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Jul 2014 21:11:09 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404421869.95.0.51623602943.issue14050@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul  3 23:30:59 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 03 Jul 2014 21:30:59 +0000
Subject: [docs] [issue11924] Pickle and copyreg modules don't document the
	interface
In-Reply-To: <1303766863.75.0.154822649898.issue11924@psf.upfronthosting.co.za>
Message-ID: <1404423059.35.0.100307362621.issue11924@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Jes?s can you provide a patch for this?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  4 01:13:29 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 03 Jul 2014 23:13:29 +0000
Subject: [docs] [issue14345] Document socket.SOL_SOCKET
In-Reply-To: <1331962982.1.0.381278454339.issue14345@psf.upfronthosting.co.za>
Message-ID: <1404429209.06.0.255857063951.issue14345@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I think this would be worth doing.  All I could find out about SOL_SOCKET is that it's an int and has a value of 65535, at least on 3.4.1, Windows 7 32 bit.

----------
nosy: +BreamoreBoy
type:  -> behavior
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul  4 02:01:52 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 04 Jul 2014 00:01:52 +0000
Subject: [docs] [issue14418] Document differences in SocketServer between
	Python 2.6	and 2.7
In-Reply-To: <1332795225.64.0.202093290254.issue14418@psf.upfronthosting.co.za>
Message-ID: <1404432112.31.0.234693545799.issue14418@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Geoffrey sorry about the delay in getting back to you.

----------
nosy: +BreamoreBoy, pitrou

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

From report at bugs.python.org  Fri Jul  4 02:39:31 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 04 Jul 2014 00:39:31 +0000
Subject: [docs] [issue14189] Documentation for some C APIs is missing
	clear	specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1404434371.56.0.586553012778.issue14189@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

If any of these actually return borrowed references, I'd consider it a serious documentation bug to not mention it. New reference semantics are the default, and while it's best to call them out, it can be assumed in most cases. Returning borrowed references without a big honking "not a normal function" flag in the docs causes a big problem.

Heck, the lack of such a big warning flag on PyDict_Next (which doesn't return a PyObject, but populates via a double pointer) caused me a major headache recently when I DECREF-ed the resulting objects. Totally my fault (the description says they're borrowed), but I rely on that "Returns: Borrowed Reference" header so much that I made a dumb mistake.

----------
nosy: +josh.rosenberg

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

From report at bugs.python.org  Fri Jul  4 02:48:40 2014
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 04 Jul 2014 00:48:40 +0000
Subject: [docs] [issue21910] File protocol should document if writelines
	must handle	generators sensibly
In-Reply-To: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>
Message-ID: <1404434920.04.0.948257323929.issue21910@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

+1. I've been assuming writelines handled arbitrary generators without an issue; guess I've gotten lucky and only used the ones that do. I've fed stuff populated by enormous (though not infinite) generators created from stuff like itertools.product and the like into it on the assumption that it would safely write it without generating len(seq) ** repeat values in memory.

I'd definitely appreciate a documented guarantee of this. I don't need it to explicitly guarantee that each item is written before the next item is pulled off the iterator or anything; if it wants to buffer a reasonable amount of data in memory before triggering a real I/O that's fine (generators returning mutable objects and mutating them when the next object comes along are evil anyway, and forcing one-by-one output can prevent some useful optimizations). But anything that uses argument unpacking, collection as a list, ''.join (or at the C level, PySequence_Fast and the like), forcing the whole generator to exhaust before writing byte one, is a bad idea.

----------
nosy: +josh.rosenberg

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

From report at bugs.python.org  Fri Jul  4 03:15:11 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 01:15:11 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404436511.69.0.488312619896.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded issue12067-expressions_v4.diff to improve the unicode footnote 3, and to revert to using the term "lexicographical" for sequences (after learning that it applies there as well). Also, this version was produced using "hg diff" to make it properly reviewable.

Please review.

----------
Added file: http://bugs.python.org/file35845/issue12067-expressions_v4.diff

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

From report at bugs.python.org  Fri Jul  4 03:46:07 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 01:46:07 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404438367.26.0.087996442184.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

PS: The v4 patch does not address comments f) and h) from msg222204, and it seems to me they do not need to be addressed.

----------

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

From report at bugs.python.org  Fri Jul  4 05:02:55 2014
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 04 Jul 2014 03:02:55 +0000
Subject: [docs] [issue21915] telnetlib.Telnet constructor does not
	match	telnetlib.Telnet.__init__ docstring
Message-ID: <1404442975.51.0.177790858493.issue21915@psf.upfronthosting.co.za>


New submission from Garrett Cooper:

telnetlib.Telnet.__init__ supports keyword arguments, but the documentation for 2.7.8 ( https://docs.python.org/2/library/telnetlib.html ) claims they're non-keyword arguments.

The py3k docs are much better ( https://docs.python.org/3/library/telnetlib.html ), but unfortunately they still claim that timeout is a non-keyword argument.

----------
assignee: docs at python
components: Documentation
messages: 222263
nosy: docs at python, yaneurabeya
priority: normal
severity: normal
status: open
title: telnetlib.Telnet constructor does not match telnetlib.Telnet.__init__ docstring

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

From report at bugs.python.org  Fri Jul  4 05:03:01 2014
From: report at bugs.python.org (Garrett Cooper)
Date: Fri, 04 Jul 2014 03:03:01 +0000
Subject: [docs] [issue21915] telnetlib.Telnet constructor does not
	match	telnetlib.Telnet.__init__ docstring
In-Reply-To: <1404442975.51.0.177790858493.issue21915@psf.upfronthosting.co.za>
Message-ID: <1404442981.51.0.553364080445.issue21915@psf.upfronthosting.co.za>


Changes by Garrett Cooper <yanegomi at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  4 10:08:11 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 08:08:11 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404461291.9.0.407027483922.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Terry,
I'd like to comment on your statement:
> 3. By default, == and /= compare identities.
in msg148774.

What experiment lead you to that conclusion?

Here is one that contradicts it (using cpython 3.4.1):

>>> i1 = 42
>>> f1 = 42.0
>>> i1 == f1
True
>>> i1 is f1
False

Is it possible, that your experiment got influenced by the optimization that attempts to reuse existing objects of immutable types?
Like in this:

>>> i1 = 42
>>> i2 = 40 + 2
>>> i1 == i2
True
>>> i1 is i2
True

Andy

----------

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

From report at bugs.python.org  Fri Jul  4 10:13:39 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Jul 2014 08:13:39 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404461619.2.0.160061864693.issue21902@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> inverse' is probably more obvious to understand than 'area', 
> although it doesn't tie into the 'a' of 'acosh', etc.

Please don't make this gratuitous change.  The decision about whether to use "inverse" or "arc" was cast in stone when the functions were named "acosh" etc.   The documentation for C's math.h uses "arc".  The docs for my hand calculators all use the term "arc" in the description of what the keys do.  Why create unnecessary divergence?  

If you truly think users of acosh can't cope with "arc", then add a clarifying parenthetical for "inverse".  But don't make the function name "acosh" more opaque by not showing what it actually stands for.

----------

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

From report at bugs.python.org  Fri Jul  4 12:47:59 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 10:47:59 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404470879.25.0.692813696053.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded v5 of the patch.

Changes:

1. The statement that comparison of different built-in types (always) raises TypeError, was too general. Changed to distinguish equal and order operators, as summarized by Ezio in items 3) and 4) of msg148760.

2. Ensured max line length of 80, in text areas affected by the patch.

Andy

----------
versions: +Python 3.4
Added file: http://bugs.python.org/file35850/issue12067-expressions-py34_v5.diff

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

From report at bugs.python.org  Fri Jul  4 12:57:28 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 10:57:28 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404471448.44.0.117494045895.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

It seems I still need to practice creating patches ... uploading v6 which should create a review link. No other changes.
Sorry for that.
Andy

----------
Added file: http://bugs.python.org/file35851/issue12067-expressions-py34_v6.diff

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

From report at bugs.python.org  Fri Jul  4 13:27:30 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 11:27:30 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404473249.95.0.624775124857.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Another attempt. Really sorry...

----------
Added file: http://bugs.python.org/file35853/issue12067-expressions-py34_v7.diff

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

From berker.peksag at gmail.com  Fri Jul  4 14:09:35 2014
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Fri, 4 Jul 2014 15:09:35 +0300
Subject: [docs]
	=?utf-8?q?Wrong_link_in_Python_3=2E3_documentation_index_?=
	=?utf-8?b?4oCTIGV4ZWM=?=
In-Reply-To: <CACvLUa=FHuq2o94AmFFrER2awA-+s49GDu2O4eDw3DbCkY2+DA@mail.gmail.com>
References: <CACvLUa=FHuq2o94AmFFrER2awA-+s49GDu2O4eDw3DbCkY2+DA@mail.gmail.com>
Message-ID: <CAF4280Lu6zUViFG47g__28V1u98cRTmUnhfsVrCU5_o84Q2oeg@mail.gmail.com>

On Sat, Aug 24, 2013 at 5:54 PM, Draic Kin <drekin at gmail.com> wrote:
> In Python 3.3 documentation index, the link on exec leads to
> http://docs.python.org/3/reference/simple_stmts.html#index-42 which is
> incorrect.

Hi,

Fixed. Thanks for the report!

--Berker

>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>

From report at bugs.python.org  Fri Jul  4 14:16:18 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 12:16:18 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404476178.28.0.967664116445.issue14050@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded patch version py34_v2, which contains the following changes relative to 3.4:

1. The changes in the description of list.sort() from "default" in list.sort(), by adding this text:
  (the arguments can be used for sort customization, see :func:`sorted` for their explanation)

2. The proposed extension of the description of list.sort() from patch version py32.

3. A statement that TypeError is raised if the ordering relationship is not established.

4. A reference where to look in order to establish ordering relationship for user-defined classes. (referencing the Basic customization section of the Language Reference).

5. A reference where the ordering relationships for built-in types are described (referencing the Comparison chapter of the Language Reference).

-> Please review.

Andy

----------
Added file: http://bugs.python.org/file35854/issue14050-list_sort-py34_v2.diff

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

From report at bugs.python.org  Fri Jul  4 14:38:26 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 12:38:26 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404477506.17.0.244276190435.issue14050@psf.upfronthosting.co.za>


Andy Maier added the comment:

uploaded patch version py27_v2, which contains the same changes as py34_v2, relative to 2.7, except for this differences:

1. The change from "default" was already in 2.7.

2. The reference to defining ordering methods for user-defined classes includes a reference to object.__cmp__(), in addition.

-> Please review

Andy

----------
Added file: http://bugs.python.org/file35855/issue14050-list_sort-py27_v2.diff

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

From report at bugs.python.org  Fri Jul  4 15:42:19 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 04 Jul 2014 13:42:19 +0000
Subject: [docs] [issue21915] telnetlib.Telnet constructor does not
	match	telnetlib.Telnet.__init__ docstring
In-Reply-To: <1404442975.51.0.177790858493.issue21915@psf.upfronthosting.co.za>
Message-ID: <1404481339.15.0.202020123772.issue21915@psf.upfronthosting.co.za>


R. David Murray added the comment:

There are reasons for both of these things.  In 2.7 we generally used the [] notation for keyword arguments.  In both, the timeout doesn't have a default that it is possible to document using our standard notation, so we use the [] notation.  If you can think of a better way to document this, there are several other places where we have similar timeout arguments that could also be improved (but we haven't thought of an acceptable way to improve it yet).

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

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

From report at bugs.python.org  Fri Jul  4 16:12:07 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Jul 2014 14:12:07 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404483127.05.0.193419821061.issue21902@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Raymond: I don't think it's gratuitous.  I'd be happy to replace the 'inverse' by 'area' if that's what people prefer.  But "hyperbolic arc cosine" is just plain incorrect.  (And the "in radians" bit is utterly nonsensical.)

----------

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

From report at bugs.python.org  Fri Jul  4 17:26:17 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 04 Jul 2014 15:26:17 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404487577.1.0.734188243061.issue10289@psf.upfronthosting.co.za>


Andy Maier added the comment:

I have reviewed the descriptions of the built-in functions in Python 3.4, and found only the following issues w.r.t. missing __special__functions:

1. getattr(), setattr(), delattr(): They only refer to object attributes and miss to mention the fallback to object.__getattr__(), etc. Because hasattr() calls getattr() to test for the presence, the __getattr__() is relevant for hasattr() as well.

2. len() misses to describe that it uses s.__len__().

3. sorted() misses to describe how rich comparison methods can be used. I think we can integrate the changes to list.sort() proposed in issue14050.

4. str() delegates the description to stdtypes.html#str, which in turn does describe obj.__str__(). Not sure we need to do something for str().

I did not check 2.7 yet.

Andy

----------
nosy: +andymaier
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Jul  4 18:59:12 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 04 Jul 2014 16:59:12 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1404493152.06.0.752172991335.issue12954@psf.upfronthosting.co.za>


paul j3 added the comment:

The documentation currently warns
https://docs.python.org/2/library/multiprocessing.html#windows

> Safe importing of main module

> Make sure that the main module can be safely imported by a new Python interpreter without causing unintended side effects (such a starting a new process).

The logging duplication that I mentioned here is one of those side effects.  So there's probably no need for further warnings.

----------

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

From report at bugs.python.org  Fri Jul  4 21:24:07 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Jul 2014 19:24:07 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404501847.28.0.512469831564.issue12067@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In py3, *everything* is an instance of class object. This makes like simple than in 2.x. The default comparison rules are set by the rich comparison methods of object. 'By experiment' meant by experiments with instances of object, which use those default methods, rather than by inspection of the relevant .c source code. Instances of subclasses taht do not override the defaults would act the same. Here is what seem to be the default code, from object.c, do_compare.  It verifies what I said (v, w are pointers, which represent identity):

    /* If neither object implements it, provide a sensible default
       for == and !=, but raise an exception for ordering. */
    switch (op) {
    case Py_EQ:
        res = (v == w) ? Py_True : Py_False;
        break;
    case Py_NE:
        res = (v != w) ? Py_True : Py_False;
        break;
    default:
        /* XXX Special-case None so it doesn't show as NoneType() */
        PyErr_Format(PyExc_TypeError,
                     "unorderable types: %.100s() %s %.100s()",
                     v->ob_type->tp_name,
                     opstrings[op],
                     w->ob_type->tp_name);
        return NULL;
    }
    Py_INCREF(res);
    return res;

Subclasses can and ofter do override the default methods. In particular, the number subclasses compare by value, across number types.

----------

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

From report at bugs.python.org  Sat Jul  5 03:36:03 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Jul 2014 01:36:03 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404524163.02.0.192249553775.issue21902@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I'd be happy to replace the 'inverse' by 'arc' 
> if that's what people prefer.

Yes, please.

> And the "in radians" bit is utterly nonsensical

Yes, again.

----------

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

From report at bugs.python.org  Sat Jul  5 05:48:12 2014
From: report at bugs.python.org (Kevin Davies)
Date: Sat, 05 Jul 2014 03:48:12 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404532092.38.0.0675020730724.issue21902@psf.upfronthosting.co.za>


Changes by Kevin Davies <daviesk24 at yahoo.com>:


Added file: http://bugs.python.org/file35863/TI-89.png

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

From report at bugs.python.org  Sat Jul  5 06:47:54 2014
From: report at bugs.python.org (Kevin Davies)
Date: Sat, 05 Jul 2014 04:47:54 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <53B774D7.4040303@yahoo.com>
Message-ID: <53B78376.9050103@yahoo.com>


Kevin Davies added the comment:

I'm not sure what the resolution is (the patch was 'inverse', Mark said 
he'd be happy to use 'area', and Raymond quoted 'arc').  I didn't know 
this would be a big deal, and I'm sorry that I caused trouble.  But 
since one of the concerns was divergence, I thought I'd send some info 
on how the tools I've used describe it -- universally as 'inverse' in 
those that I found:

- Mathematica: ArcCosh[z] "gives the inverse hyperbolic cosine [...]" 
(http://reference.wolfram.com/mathematica/ref/ArcCosh.html)
- Modelica Standard Library: acosh "Inverse of cosh (area hyperbolic 
cosine)" 
(http://reference.wolfram.com/system-modeler/libraries/Modelica/Modelica_Math_acosh.html)
- Maple: arccosh, but unknown description 
(http://www.maplesoft.com/support/help/Maple/view.aspx?path=invtrig)
- MATLAB: acosh " Inverse hyperbolic cosine" 
(http://www.mathworks.com/help/matlab/ref/acosh.html)
- TI-89 calculator: cosh-1 "returns the inverse hyperbolic cosine [...]" 
(from manual)

Respectfully,
Kevin

----------

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

From report at bugs.python.org  Sat Jul  5 08:12:27 2014
From: report at bugs.python.org (Tim Peters)
Date: Sat, 05 Jul 2014 06:12:27 +0000
Subject: [docs] [issue21902] Docstring of math.acosh, asinh, and atanh
In-Reply-To: <1404275479.79.0.0199370909465.issue21902@psf.upfronthosting.co.za>
Message-ID: <1404540747.81.0.882210322053.issue21902@psf.upfronthosting.co.za>


Tim Peters added the comment:

One more useless ;-) data point, from Macsyma:

? acosh;
 -- Function: acosh (<x>)
     - Hyperbolic Arc Cosine.

I don't like "area" - while accurate, nobody else uses it.  Gratuitous novelty is no virtue ;-)  I like "inverse" better than "arc", because it's all of accurate, common, and nearly self-evident.

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

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

From report at bugs.python.org  Sat Jul  5 10:01:27 2014
From: report at bugs.python.org (Stefan Tatschner)
Date: Sat, 05 Jul 2014 08:01:27 +0000
Subject: [docs] [issue21920] Fixed missing colon in the docs
Message-ID: <1404547287.88.0.816542299349.issue21920@psf.upfronthosting.co.za>


New submission from Stefan Tatschner:

Hi,
i just discovered a missing colon in the docs. I have created a patch for this.

Stefan

----------
assignee: docs at python
components: Documentation
files: fixed-missing-colon.patch
keywords: patch
messages: 222341
nosy: docs at python, rumpelsepp
priority: normal
severity: normal
status: open
title: Fixed missing colon in the docs
versions: Python 3.4
Added file: http://bugs.python.org/file35865/fixed-missing-colon.patch

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

From report at bugs.python.org  Sat Jul  5 10:07:19 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 05 Jul 2014 08:07:19 +0000
Subject: [docs] [issue21920] Fixed missing colon in the docs
In-Reply-To: <1404547287.88.0.816542299349.issue21920@psf.upfronthosting.co.za>
Message-ID: <1404547639.7.0.584030657384.issue21920@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag
versions: +Python 3.5

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

From report at bugs.python.org  Sat Jul  5 10:11:04 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Jul 2014 08:11:04 +0000
Subject: [docs] [issue21920] Fixed missing colon in the docs
In-Reply-To: <1404547287.88.0.816542299349.issue21920@psf.upfronthosting.co.za>
Message-ID: <3h55Mq2WZpz7LqK@mail.python.org>


Roundup Robot added the comment:

New changeset 6094aa25b33c by Berker Peksag in branch '3.4':
Issue #21920: Add a missing colon to the __main__ doc.
http://hg.python.org/cpython/rev/6094aa25b33c

New changeset e22d0ff286f9 by Berker Peksag in branch 'default':
Issue #21920: Merge from 3.4.
http://hg.python.org/cpython/rev/e22d0ff286f9

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

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

From report at bugs.python.org  Sat Jul  5 10:12:11 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 05 Jul 2014 08:12:11 +0000
Subject: [docs] [issue21920] Fixed missing colon in the docs
In-Reply-To: <1404547287.88.0.816542299349.issue21920@psf.upfronthosting.co.za>
Message-ID: <1404547931.67.0.479224765049.issue21920@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Stefan!

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

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

From report at bugs.python.org  Sat Jul  5 10:45:13 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Sat, 05 Jul 2014 08:45:13 +0000
Subject: [docs] [issue21921] Example in asyncio event throws resource usage
	warning
Message-ID: <1404549913.45.0.543657172277.issue21921@psf.upfronthosting.co.za>


New submission from Vajrasky Kok:

These examples coming from:
https://docs.python.org/3/library/asyncio-eventloop.html#example-hello-world-callback

and

https://docs.python.org/3/library/asyncio-eventloop.html#example-set-signal-handlers-for-sigint-and-sigterm

throw resource usage warning.

One of them gives this output:
Event loop running forever, press CTRL+c to interrupt.
pid 3075: send SIGINT or SIGTERM to exit.
^Cgot signal SIGINT: exit
sys:1: ResourceWarning: unclosed <socket object at 0x7f7124783448>
sys:1: ResourceWarning: unclosed <socket object at 0x7f7124c230e8>

The patch adds closing the loop code in the examples.

----------
assignee: docs at python
components: Documentation, asyncio
files: close_loop_on_example.patch
keywords: patch
messages: 222344
nosy: docs at python, gvanrossum, haypo, vajrasky, yselivanov
priority: normal
severity: normal
status: open
title: Example in asyncio event throws resource usage warning
type: resource usage
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35866/close_loop_on_example.patch

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

From report at bugs.python.org  Sat Jul  5 15:41:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 05 Jul 2014 13:41:28 +0000
Subject: [docs] [issue21921] Example in asyncio event throws resource usage
	warning
In-Reply-To: <1404549913.45.0.543657172277.issue21921@psf.upfronthosting.co.za>
Message-ID: <3h5Dj33mmkz7Lp4@mail.python.org>


Roundup Robot added the comment:

New changeset f6827c6b1164 by Victor Stinner in branch '3.4':
Closes #21921: Fix ResourceWarning in the asyncio examples: close the event
http://hg.python.org/cpython/rev/f6827c6b1164

New changeset 0533f148fb49 by Victor Stinner in branch 'default':
(Merge 3.4) Closes #21921: Fix ResourceWarning in the asyncio examples: close
http://hg.python.org/cpython/rev/0533f148fb49

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

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

From report at bugs.python.org  Sat Jul  5 15:43:20 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Jul 2014 13:43:20 +0000
Subject: [docs] [issue21921] Example in asyncio event throws resource usage
	warning
In-Reply-To: <1404549913.45.0.543657172277.issue21921@psf.upfronthosting.co.za>
Message-ID: <1404567800.39.0.355453144553.issue21921@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the fix. I already suggested it to Guido van Rossum a few months ago, but he preferred the keep the example simple. I made the same fix in the 2 hello world examples of the Tulip project last Tuesday, so it's fair to apply the same fix to asyncio examples.

Thanks for the fix Vajrasky.

----------

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

From report at bugs.python.org  Sun Jul  6 00:09:01 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 05 Jul 2014 22:09:01 +0000
Subject: [docs] [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1404598141.37.0.651633193966.issue12602@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
type:  -> behavior
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  6 17:43:41 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 06 Jul 2014 15:43:41 +0000
Subject: [docs] [issue16438] Numeric operator predecence confusing
In-Reply-To: <1352384371.29.0.086289583253.issue16438@psf.upfronthosting.co.za>
Message-ID: <1404661421.29.0.775145686638.issue16438@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I find the numeric operator predecence simply wrong, not confusing, so +1 from me for applying the attached patch from ktt3ja.  It's as simple as possible but no simpler :)

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul  6 19:58:07 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 06 Jul 2014 17:58:07 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <3h5yLk6gsCz7LmN@mail.python.org>


Roundup Robot added the comment:

New changeset 3881c12fa3ae by Ezio Melotti in branch '2.7':
#20135: move FAQ about mutable default arguments to the programming FAQs page.
http://hg.python.org/cpython/rev/3881c12fa3ae

New changeset 3b7b0f5aac1e by Ezio Melotti in branch '3.4':
#20135: move FAQ about mutable default arguments to the programming FAQs page.
http://hg.python.org/cpython/rev/3b7b0f5aac1e

New changeset f2a36b01ac02 by Ezio Melotti in branch 'default':
#20135: merge with 3.4.
http://hg.python.org/cpython/rev/f2a36b01ac02

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

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

From report at bugs.python.org  Sun Jul  6 21:15:04 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2014 19:15:04 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1404674104.46.0.373845958568.issue20135@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I moved the FAQ about mutable default arguments to the programming FAQs page.  I was going to do a review about new FAQ, but it since I had several comments I just tried to rewrite it and make a new patch.
Do you think this is clear enough?

----------
Added file: http://bugs.python.org/file35875/issue20135.diff

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

From report at bugs.python.org  Sun Jul  6 21:34:41 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 06 Jul 2014 19:34:41 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1404675281.82.0.129077381535.issue20135@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

+1 from me, I thought it was crystal clear.

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Jul  6 21:35:50 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2014 19:35:50 +0000
Subject: [docs] [issue1581182] Definition of a "character" is wrong
Message-ID: <1404675350.33.0.285125851018.issue1581182@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: languishing -> closed
superseder:  -> Issues in Unicode HOWTO

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

From report at bugs.python.org  Sun Jul  6 21:36:28 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2014 19:36:28 +0000
Subject: [docs] [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1404675388.09.0.492595594756.issue20906@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #1581182.

----------
stage:  -> needs patch
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Sun Jul  6 21:45:06 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 06 Jul 2014 19:45:06 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1404675906.38.0.0693154942275.issue1660009@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg179391 states this is fixed in Python 3 so we can close this as "out of date".

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

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

From report at bugs.python.org  Sun Jul  6 22:51:19 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 06 Jul 2014 20:51:19 +0000
Subject: [docs] [issue12602] Missing cross-references in Doc/using
In-Reply-To: <1311249393.53.0.190511112739.issue12602@psf.upfronthosting.co.za>
Message-ID: <1404679879.68.0.792297727894.issue12602@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Patch LGTM.

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

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

From report at bugs.python.org  Mon Jul  7 02:05:51 2014
From: report at bugs.python.org (Dustin Oprea)
Date: Mon, 07 Jul 2014 00:05:51 +0000
Subject: [docs] [issue21928] Incorrect reference to partial() in
	functools.wraps	documentation
Message-ID: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>


New submission from Dustin Oprea:

functools.wraps docs say "This is a convenience function for invoking partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated) as a function decorator when defining a wrapper function." The referenced function should be update_wrapper(), not partial().

----------
assignee: docs at python
components: Documentation
messages: 222426
nosy: Dustin.Oprea, docs at python
priority: normal
severity: normal
status: open
title: Incorrect reference to partial() in functools.wraps documentation
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Jul  7 09:11:08 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 07 Jul 2014 07:11:08 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1404717068.56.0.0319664450317.issue20135@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM.

----------
nosy: +berker.peksag
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Jul  7 10:12:32 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 08:12:32 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1404720752.53.0.29322956692.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

I see.
But I don't think it is a sensible default, as the source code states.

The Python doc (v2 and v3) is quite consistent in stating that `==` compares the values of two objects, while `is` compares object identity.

Having a default implementation on the object type that implements `==` by comparing object identity is not consistent with that.

-> Can someone please elaborate what the reason for that is?

-> Where is the discrepancy between the documentation of == and its default implementation on object documented?

To me, a sensible default implementation for == on object would be (in Python):

  if v is w:
    return True;
  elif type(v) != type(w):
    return False
  else:
    raise ValueError("Equality cannot be determined in default implementation")

Andy

----------

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

From report at bugs.python.org  Mon Jul  7 11:57:13 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 07 Jul 2014 09:57:13 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1404727033.95.0.125532016007.issue20135@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
assignee: docs at python -> ezio.melotti
nosy: +rhettinger
stage: patch review -> commit review

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

From report at bugs.python.org  Mon Jul  7 12:31:32 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 10:31:32 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404729091.94.0.023401629837.issue10289@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded a patch for Python 3.4, and for merging into "default".

The patch addresses items 1) to 3) from my previous post; item 4) does not need to be addressed IMHO.

Andy

----------
keywords: +patch
Added file: http://bugs.python.org/file35879/issue10289-magic-py34_v1.diff

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

From report at bugs.python.org  Mon Jul  7 12:50:04 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 10:50:04 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404730204.11.0.987461204908.issue10289@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded v2 of the 3.4/default patch, which removes the comment line at the top of Doc/library/functions.rst (mentioned by ?ric in the original message of this issue).

-> Please review the patch.

-> Please also double check whether there are any additional built-in functions in 3.x that have a need to document their underlying __special__ functions.

Andy

----------
Added file: http://bugs.python.org/file35881/issue10289-magic-py34_v2.diff

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

From report at bugs.python.org  Mon Jul  7 12:59:06 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 10:59:06 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1404730746.39.0.891487284428.issue14050@psf.upfronthosting.co.za>


Andy Maier added the comment:

Comments on v2 of both patches:

1. The paragraph "Each item needs to ..." describes the requirement in terms of "ordering relationships between items". It would be both simpler and less ambiguous to describe the requirement in terms of "type must be orderable". See the text added to sorted() as part of the patch for issue10289, for details.

----------

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

From report at bugs.python.org  Mon Jul  7 14:01:25 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Jul 2014 12:01:25 +0000
Subject: [docs] [issue21929] Rounding properly
In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za>
Message-ID: <1404734485.27.0.487283442529.issue21929@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

There may be an opportunity for a documentation improvement here: it would be helpful if the Python 2.7 documentation for the "round" function explained that its input is converted to float.

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

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

From jresins at gmail.com  Sat Jul  5 16:05:59 2014
From: jresins at gmail.com (Jresins)
Date: Sat, 5 Jul 2014 22:05:59 +0800
Subject: [docs] Could you please supply amazon kindle format(mobi) for the
	docs?
Message-ID: <CACQuNpTX2FH4GwC2E6sd0+0qr9S6PnBmUa6Nh9EN60e310STeA@mail.gmail.com>

You know,there are many people read docs with amazon kindle.
And some times the epub format is hard to transform into mobi format.
For this reason, could you please kindly supply an amazon kindle edition
for the python docs?

Thanks!

BRs,
jresins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140705/49861525/attachment.html>

From report at bugs.python.org  Mon Jul  7 18:00:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2014 16:00:44 +0000
Subject: [docs] [issue21680] asyncio: document event loops
In-Reply-To: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>
Message-ID: <1404748843.93.0.936816117701.issue21680@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, it looks like the proactor event loop doesn't support datagram protocol.

----------

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

From report at bugs.python.org  Mon Jul  7 19:07:41 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 17:07:41 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404752861.7.0.411961511794.issue10289@psf.upfronthosting.co.za>


Andy Maier added the comment:

Comments on the patch py34_v2:

1. On complex(): It delegates to object.__complex__(); that should also be described.

2. On hex(): The use of "__index__()" is text and should be changed to a hyperlink.

Andy

----------

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

From report at bugs.python.org  Mon Jul  7 19:11:06 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Jul 2014 17:11:06 +0000
Subject: [docs] [issue9267] Update pickle opcode documentation in
	pickletools for 3.x
In-Reply-To: <1279217581.88.0.294098163632.issue9267@psf.upfronthosting.co.za>
Message-ID: <1404753066.64.0.454595048753.issue9267@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
nosy: +docs at python -serhiy.storchaka
versions: +Python 3.4, Python 3.5 -Python 3.2

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

From report at bugs.python.org  Mon Jul  7 19:16:51 2014
From: report at bugs.python.org (Andy Maier)
Date: Mon, 07 Jul 2014 17:16:51 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404753411.19.0.190295803485.issue10289@psf.upfronthosting.co.za>


Andy Maier added the comment:

I reviewed the description of the built-in functions in Python 2.7, and found these issues:

1. The following built-in functions do not mention their underyling __special__ functions:
- cmp()
- delattr(), getattr(), hasattr(), setattr()
- complex(), int(), long(), float()
- hash()
- len()
- str()
- int(), oct()

2. The following built-in functions list the __special__ functions they invoke as text that is not a hyperlink:
- dir()
- format()
- hex()

3. The following built-in functions could be improved from the description of the 3.x version:
- bool(): References and links from 3.x version could be added.
- bytearray(): References from last line of 3.x version could be added.
- callable(): Wording "if they have a..." could be improved by using 3.x wording.

4. The codepage of the ASCII string for chr() is not documented.

Andy

----------

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

From report at bugs.python.org  Mon Jul  7 20:05:31 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Jul 2014 18:05:31 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404756331.52.0.918973864933.issue10289@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Should the Python 2.7 delegation of `round` to `__float__` for its input also be described as part of this issue?

>>> class A(object):
...     def __float__(self): return 1729.1
... 
>>> round(A())
1729.0

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

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

From report at bugs.python.org  Mon Jul  7 20:13:11 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 07 Jul 2014 18:13:11 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1404756791.41.0.977200497731.issue10289@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Could #15436 "__sizeof__ is not documented" also be covered by this?

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

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

From report at bugs.python.org  Mon Jul  7 21:26:33 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 07 Jul 2014 19:26:33 +0000
Subject: [docs] [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1404761193.67.0.416520919195.issue10583@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I don't see this in 3.4.1.

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

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

From report at bugs.python.org  Mon Jul  7 22:19:21 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 07 Jul 2014 20:19:21 +0000
Subject: [docs] [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1404764361.26.0.285045692359.issue10583@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I do in 2.7.8, though.  This appears to have been a Sphinx issue (likely caused by HTML Help's lack of Unicode support), introduced sometime between Sphinx versions 0.6.5 and 0.6.7, and fixed sometime between versions 1.1.3 and 1.2.2.

----------
nosy: +zach.ware

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

From Scott.Hinton at Honeywell.com  Mon Jul  7 21:52:43 2014
From: Scott.Hinton at Honeywell.com (Hinton, Scott (ESEA Space))
Date: Mon, 7 Jul 2014 19:52:43 +0000
Subject: [docs] documentation typo
Message-ID: <63EC325C5190FF4CBC44EB63354C987E22608741@az18ex3002.global.ds.honeywell.com>

Hello,

Just a quick FYI, in the Python 2.7.8 documentation, section 15.3 on 'time' has a minor typo:

Under strftime() it has the line

Changed in version 2.5: 0 is now a legal argument for any position in the time tuple; if it is normally illegal the value is forced to a correct one..
There are two periods at the end of the line.

Enjoy,
Scott Hinton

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

From zachary.ware+pydocs at gmail.com  Mon Jul  7 22:33:27 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 7 Jul 2014 15:33:27 -0500
Subject: [docs] documentation typo
In-Reply-To: <63EC325C5190FF4CBC44EB63354C987E22608741@az18ex3002.global.ds.honeywell.com>
References: <63EC325C5190FF4CBC44EB63354C987E22608741@az18ex3002.global.ds.honeywell.com>
Message-ID: <CAKJDb-PVaKqasDH=YQo36AHFd2XFpXoFZRXGU1GUgvco3xL34A@mail.gmail.com>

Hi Scott,

On Mon, Jul 7, 2014 at 2:52 PM, Hinton, Scott (ESEA Space)
<Scott.Hinton at honeywell.com> wrote:
> Hello,
>
> Just a quick FYI, in the Python 2.7.8 documentation, section 15.3 on ?time?
> has a minor typo:
>
> Under strftime() it has the line
>
> Changed in version 2.5: 0 is now a legal argument for any position in the
> time tuple; if it is normally illegal the value is forced to a correct one..
>
> There are two periods at the end of the line.

Thanks for the report, this has been fixed in
http://hg.python.org/cpython/rev/8ebda8114e97 and will be live soon.

Regards,
-- 
Zach

From report at bugs.python.org  Tue Jul  8 00:41:49 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Jul 2014 22:41:49 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1404772909.81.0.0858256519228.issue6916@psf.upfronthosting.co.za>


STINNER Victor added the comment:

asynchat.fifo is now explicitly marked as deprecated and scheduled for removal in Python 3.6. I consider that the issue is done and so I'm closing it. Reopen a more specific issue if you consider that there is still something to do.

@Berker: You may apply use-assertwarns.diff yourself, I have no opinion, but your patch doesn't apply cleanly anymore.

----------
nosy: +haypo
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Jul  8 06:47:43 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Jul 2014 04:47:43 +0000
Subject: [docs] [issue21929] Rounding properly
In-Reply-To: <1404729306.28.0.45044219182.issue21929@psf.upfronthosting.co.za>
Message-ID: <1404794863.45.0.217602981489.issue21929@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the FAQ in the decimal docs shows how to round Decimal objects using the quantize() method:  https://docs.python.org/2.7/library/decimal.html#decimal-faq

Unfortunately, only it Python 3 does the one-obvious-way-to-do-it work.

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

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

From report at bugs.python.org  Tue Jul  8 12:57:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2014 10:57:52 +0000
Subject: [docs] [issue21365] asyncio.Task reference misses the most
	important fact	about it,
	related info spread around intros and example commentary instead
In-Reply-To: <1398613098.75.0.265677522517.issue21365@psf.upfronthosting.co.za>
Message-ID: <1404817072.86.0.68550398592.issue21365@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi,

I pushed my change to add a new BaseEventLoop.create_task() method. For that, I also updated the documentation:
http://hg.python.org/cpython/rev/66f06fbf8a2f

I rewrote the documentation of the Task method, and more generally all places describing how to create a Task object. I changed the first sentence to "Schedule the execution of a coroutine object" to be the most explicit.

The documentation will be readable online in a few hours:
https://docs.python.org/dev/library/asyncio-task.html#task

Thanks for your report.

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

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

From techtonik at gmail.com  Tue Jul  8 09:29:15 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Tue, 8 Jul 2014 10:29:15 +0300
Subject: [docs] Improved documentation for re.findall()
Message-ID: <CAPkN8xJ6Gu2oo_5NycC3+Df9RjV50mSsiH=MfAbE_LxgarFMfg@mail.gmail.com>

Hi,

The documentation on findall() requires full reading
to understand that return type is not only list of strings.
https://docs.python.org/2/library/re.html#re.findall


I propose to change from:

Return all non-overlapping matches of pattern in string, as a list of strings.
The string is scanned left-to-right, and matches are returned in the
order found.
If one or more groups are present in the pattern, return a list of groups; this
will be a list of tuples if the pattern has more than one group. Empty matches
are included in the result unless they touch the beginning of another match.


To:

Find all non-overlapping matches of pattern in string. The string is scanned
left-to-right, and matches are returned in the order found. Returns list of
strings if no groups or one group is present in the pattern. It there are
more groups - returns list of tuples. Empty matches are included in the result
unless they touch the beginning of another match.


-- 
anatoly t.

From keith.briggs at bt.com  Tue Jul  8 12:03:48 2014
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Tue, 8 Jul 2014 11:03:48 +0100
Subject: [docs] punctuation errors at
 https://docs.python.org/3/tutorial/classes.html#generators
Message-ID: <BA02A06A22A52C449E4B5EE4CE1DBC3FA125F5960D@EMV66-UKRD.domain1.systemhost.net>

There are a couple of punctuation errors at https://docs.python.org/3/tutorial/classes.html#generators:

1. "left-off" should be "left off" (it's pronounced as two words, so should not be hyphenated)

2. "class based iterators" should be "class-based iterators".

Keith



From report at bugs.python.org  Tue Jul  8 16:00:53 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 08 Jul 2014 14:00:53 +0000
Subject: [docs] [issue15759] "make suspicious" doesn't display instructions
	in case	of failure
In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>
Message-ID: <1404828053.33.0.417626408427.issue15759@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Serhiy, your patch LGTM.
Can you apply a similar fix for the linkcheck and doctest target and commit it?

FWIW the patch produces a slightly different output (in addition to showing the missing message), but I don't think it's a problem:
Without patch:
  ...
  build finished with problems, 8 warnings.
  make: *** [build] Error 1
With patch:
  ...
  build finished with problems, 8 warnings.
  make[1]: *** [build] Error 1
  make[1]: Leaving directory `/home/wolf/dev/py/py3k/Doc'
  Suspicious check complete; ...
  make: *** [suspicious] Error 1

----------
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Tue Jul  8 16:46:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 08 Jul 2014 14:46:12 +0000
Subject: [docs] [issue15759] "make suspicious" doesn't display instructions
	in case	of failure
In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>
Message-ID: <1404830772.73.0.79027291589.issue15759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot about this patch.

Here is more correct patch. It now works with non-default make command and "make suspicious" now returns success return code if no suspicious markups were found. Made similar fix for the linkcheck and doctest target.

----------
Added file: http://bugs.python.org/file35901/make_suspicious_2.patch

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

From pbialy at pbialy.eu  Tue Jul  8 20:35:46 2014
From: pbialy at pbialy.eu (=?UTF-8?Q?Przemys=C5=82aw_Bia=C5=82y?=)
Date: Tue, 08 Jul 2014 20:35:46 +0200
Subject: [docs] super - take the Note higher pls
Message-ID: <749fc4d736e0d76b8d1366110cbc751f@localhost>

Hi


I would like to propose putting the note "Note super() only works for 
new-style classes." right after "super(type[, object-or-type])" here:

https://docs.python.org/2/library/functions.html#super


Reason - I was just making the tutorial, read first few lines and tried 
to make my own class + subclass + method then, which wasnt working for 
like 15mins until i recognised that my class must have "(object)".

Of course You may just say that I'm blind and I should read more before 
trying something. True :P
But still putting the Note higher may safe others time in the future :)


Regards
Przemys?aw Bia?y


From report at bugs.python.org  Tue Jul  8 23:43:20 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Jul 2014 21:43:20 +0000
Subject: [docs] [issue21680] asyncio: document event loops
In-Reply-To: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>
Message-ID: <3h7HFg4Xw3z7LjX@mail.python.org>


Roundup Robot added the comment:

New changeset 3f1381e3a68f by Victor Stinner in branch '3.4':
Issue #21680: Document asyncio event loops
http://hg.python.org/cpython/rev/3f1381e3a68f

New changeset 2c9d5f32f6c5 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #21680: Document asyncio event loops
http://hg.python.org/cpython/rev/2c9d5f32f6c5

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

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

From report at bugs.python.org  Tue Jul  8 23:43:54 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2014 21:43:54 +0000
Subject: [docs] [issue21680] asyncio: document event loops
In-Reply-To: <1402058495.48.0.977334805226.issue21680@psf.upfronthosting.co.za>
Message-ID: <1404855834.69.0.213149834428.issue21680@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul  8 23:44:42 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Jul 2014 21:44:42 +0000
Subject: [docs] [issue21437] document that asyncio.ProactorEventLoop doesn't
	support	SSL
In-Reply-To: <1399296732.42.0.791038898639.issue21437@psf.upfronthosting.co.za>
Message-ID: <1404855882.17.0.772554237759.issue21437@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Done in these commits:

New changeset 3f1381e3a68f by Victor Stinner in branch '3.4':
Issue #21680: Document asyncio event loops
http://hg.python.org/cpython/rev/3f1381e3a68f

New changeset 2c9d5f32f6c5 by Victor Stinner in branch 'default':
(Merge 3.4) Issue #21680: Document asyncio event loops
http://hg.python.org/cpython/rev/2c9d5f32f6c5

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

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

From report at bugs.python.org  Wed Jul  9 02:03:46 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 09 Jul 2014 00:03:46 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <1404864226.38.0.741711627977.issue6916@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jul  9 02:12:41 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Jul 2014 00:12:41 +0000
Subject: [docs] [issue6916] Remove deprecated items from asynchat
In-Reply-To: <1252994156.96.0.167712988312.issue6916@psf.upfronthosting.co.za>
Message-ID: <3h7LYz68y8z7LmP@mail.python.org>


Roundup Robot added the comment:

New changeset 486c1a81ee32 by Berker Peksag in branch 'default':
Issue #6916: Use assertWarns in test_asynchat.
http://hg.python.org/cpython/rev/486c1a81ee32

----------

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

From ezio.melotti at gmail.com  Wed Jul  9 13:58:36 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Wed, 9 Jul 2014 14:58:36 +0300
Subject: [docs] [issue19608] devguide needs pictures
In-Reply-To: <CAPkN8x+-k6f3qiVms6cJd2sqeEik12h4HHW1A91VrA6LxNwB8Q@mail.gmail.com>
References: <1384510390.93.0.961404476169.issue19608@psf.upfronthosting.co.za>
 <1404824996.52.0.487450681845.issue19608@psf.upfronthosting.co.za>
 <CAPkN8x+-k6f3qiVms6cJd2sqeEik12h4HHW1A91VrA6LxNwB8Q@mail.gmail.com>
Message-ID: <CACBhJdFk3abPWaWUhRNqPj-jgcqyLt8pK5s7Q_9_xt2Kack3aw@mail.gmail.com>

What does "some immediate intro picture at the top of front page
illustrating transformation of Python code through the toolchain to
machine execution instructions" mean exactly?
If you are talking about pictures that illustrate how a Python source
code is parsed and converted to bytecode it doesn't belong to the
front page of the devguide.  If you are talking about using
configure/make to compile python, at the top of the front page there's
already the quick start, which is a simple bullet list with useful
links.  You could turn that to an image but it won't get much easier
to understand, and you won't be able to add links to the image.

Can you link to a specific section of the devguide that you think
should be converted to an image, and suggest what things should be in
the image (and/or propose an ASCII-art version of the image you are
suggesting)?

On Wed, Jul 9, 2014 at 9:44 AM, anatoly techtonik <techtonik at gmail.com> wrote:
> I am banned and can not reply to tracker. The reply to your question -
> what kind of picture I want and where it should be is in the first message.
>
> Another aspect is that Devguide should contain this as guideline, so
> that people can know what is missing and can contribute.
>
>
> On Tue, Jul 8, 2014 at 4:09 PM, Ezio Melotti <report at bugs.python.org> wrote:
>>
>> Changes by Ezio Melotti <ezio.melotti at gmail.com>:
>>
>>
>> ----------
>> resolution:  -> works for me
>> stage:  -> resolved
>> status: open -> closed
>> type:  -> enhancement
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue19608>
>> _______________________________________
>
>
>
> --
> anatoly t.

From report at bugs.python.org  Wed Jul  9 14:37:55 2014
From: report at bugs.python.org (LtWorf)
Date: Wed, 09 Jul 2014 12:37:55 +0000
Subject: [docs] [issue21945] Wrong grammar in documentation
Message-ID: <1404909475.04.0.739880818459.issue21945@psf.upfronthosting.co.za>


New submission from LtWorf:

[Note: Long-time users of Cookie.py will remember using
    Cookie.Cookie() to create an Cookie object.


I think it should be "a Cookie".


This is from the documentation of the Cookie module.

----------
assignee: docs at python
components: Documentation
messages: 222610
nosy: docs at python, tiposchi
priority: normal
severity: normal
status: open
title: Wrong grammar in documentation
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul  9 14:44:17 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 09 Jul 2014 12:44:17 +0000
Subject: [docs] [issue21945] Wrong grammar in documentation
In-Reply-To: <1404909475.04.0.739880818459.issue21945@psf.upfronthosting.co.za>
Message-ID: <3h7gFD5Mlxz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset c3ec90a6526e by Ezio Melotti in branch '2.7':
#21945: fix typo in Cookie module docstring.
http://hg.python.org/cpython/rev/c3ec90a6526e

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

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

From report at bugs.python.org  Wed Jul  9 14:46:01 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 09 Jul 2014 12:46:01 +0000
Subject: [docs] [issue21945] Wrong grammar in documentation
In-Reply-To: <1404909475.04.0.739880818459.issue21945@psf.upfronthosting.co.za>
Message-ID: <1404909961.3.0.189708019899.issue21945@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From techtonik at gmail.com  Wed Jul  9 08:44:35 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Wed, 9 Jul 2014 09:44:35 +0300
Subject: [docs] [issue19608] devguide needs pictures
In-Reply-To: <1404824996.52.0.487450681845.issue19608@psf.upfronthosting.co.za>
References: <1384510390.93.0.961404476169.issue19608@psf.upfronthosting.co.za>
 <1404824996.52.0.487450681845.issue19608@psf.upfronthosting.co.za>
Message-ID: <CAPkN8x+-k6f3qiVms6cJd2sqeEik12h4HHW1A91VrA6LxNwB8Q@mail.gmail.com>

I am banned and can not reply to tracker. The reply to your question -
what kind of picture I want and where it should be is in the first message.

Another aspect is that Devguide should contain this as guideline, so
that people can know what is missing and can contribute.


On Tue, Jul 8, 2014 at 4:09 PM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Changes by Ezio Melotti <ezio.melotti at gmail.com>:
>
>
> ----------
> resolution:  -> works for me
> stage:  -> resolved
> status: open -> closed
> type:  -> enhancement
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue19608>
> _______________________________________



-- 
anatoly t.

From jacek.pliszka at gmail.com  Wed Jul  9 15:00:00 2014
From: jacek.pliszka at gmail.com (Jacek Pliszka)
Date: Wed, 9 Jul 2014 15:00:00 +0200
Subject: [docs] Please add note for operator precedence
Message-ID: <CABg-ORuQNAU3cY8OTyKa-_wL8_FAoDwrxGojax65_dLTMzZbZw@mail.gmail.com>

Hi!

Lawrence D'Oliveiro
<https://www.linkedin.com/profile/view?id=287199707&goback=%2Egde_25827_member_5892214849378729987>
in his linkedin post noticed that operator precedence for bitwise ops and
comparisions is reversed in Python
with respect to C:

e.g. compare & and == in Python:

https://docs.python.org/2/reference/expressions.html#operator-precedence

and in C:

http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B

I believe it is worth to add comment about this in python docs:

https://docs.python.org/2/reference/expressions.html#operator-precedence

and:

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

What do you think?

Best Regards,

Jacek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140709/c75bd560/attachment.html>

From bgailer at gmail.com  Wed Jul  9 18:54:40 2014
From: bgailer at gmail.com (bob gailer)
Date: Wed, 09 Jul 2014 12:54:40 -0400
Subject: [docs] Where is a "Tools" menu that mentioned from "Python on
 Windows FAQ"?
In-Reply-To: <CAN_7T0Lt6u1FEBpgpimR0uvK84FA-YTjnaesM6AjuSxW5GiojA@mail.gmail.com>
References: <CAN_7T0Lt6u1FEBpgpimR0uvK84FA-YTjnaesM6AjuSxW5GiojA@mail.gmail.com>
Message-ID: <53BD73D0.3050506@gmail.com>

On 7/2/2014 10:03 PM, tomo cocoa wrote:
> Hello,
>
> I am a Japanese translator on Python documents.
> Now I am trying to work with the item "How do I run a Python program 
> under Windows?"
> in "Python on Windows FAQ".
> https://docs.python.org/3.4/faq/windows.html#how-do-i-run-a-python-program-under-windows
>
> This FAQ contains words "use Tools ? Find" ("use :menuselection:`Tools 
> --> Find`" as a reST source),
> but I could not find "Tools" menu on Windows 7.
What version of Python?

From report at bugs.python.org  Wed Jul  9 21:44:44 2014
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Jul 2014 19:44:44 +0000
Subject: [docs] [issue21949] Document the Py_SIZE() macro.
Message-ID: <1404935084.68.0.420259951718.issue21949@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

The Py_SIZE() macro is not documented.  It should be.  It is very useful along with PyList_New(positive_number) after using PyList_SET_ITEM() to fill in up to the first positive_number elements of a list object in the most optimal manner by avoiding numerous redundant array resizes and error checks along the away.

The Py_SIZE() macro was introduced (in 2.6 I believe) and is specifically intended for use as an lvalue (see http://bugs.python.org/issue1724 to confirm that).  It currently has uses in several places in CPython's core and modules as well as within some third party extension modules and tools such as Cython).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 222633
nosy: docs at python, gregory.p.smith
priority: normal
severity: normal
status: open
title: Document the Py_SIZE() macro.
type: performance
versions: Python 2.7, Python 3.4, Python 3.5

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

From fulemulevera at gmail.com  Thu Jul 10 00:45:25 2014
From: fulemulevera at gmail.com (=?ISO-8859-2?Q?F=FClem=FCle_Vera?=)
Date: Thu, 10 Jul 2014 00:45:25 +0200
Subject: [docs] time.strftime
Message-ID: <53BDC605.6050706@gmail.com>

Hi,

I have noticed a mistake in the 2.7.8 Documentation about time.strftime 
return types.
According to the documentation the time.strftime("%m") and 
time.strftime("%d") are "zero-padded decimal number" but their return 
types are string.
URL: 
https://docs.python.org/2/library/datetime.html#strftime-strptime-behavior

Best regards,
Vera


From ezio.melotti at gmail.com  Thu Jul 10 16:13:46 2014
From: ezio.melotti at gmail.com (Ezio Melotti)
Date: Thu, 10 Jul 2014 17:13:46 +0300
Subject: [docs] [issue19608] devguide needs pictures
In-Reply-To: <CAPkN8xLtm-UxRNfUC+_5OzBkkGC2yLQ7bHpTwkJhAomBMZmb8Q@mail.gmail.com>
References: <1384510390.93.0.961404476169.issue19608@psf.upfronthosting.co.za>
 <1404824996.52.0.487450681845.issue19608@psf.upfronthosting.co.za>
 <CAPkN8x+-k6f3qiVms6cJd2sqeEik12h4HHW1A91VrA6LxNwB8Q@mail.gmail.com>
 <CACBhJdFk3abPWaWUhRNqPj-jgcqyLt8pK5s7Q_9_xt2Kack3aw@mail.gmail.com>
 <CAPkN8xLtm-UxRNfUC+_5OzBkkGC2yLQ7bHpTwkJhAomBMZmb8Q@mail.gmail.com>
Message-ID: <CACBhJdHUrUqmk0xoW95AE7YF+czOFdqNk_XW8YyW7HebG5g1ag@mail.gmail.com>

On Thu, Jul 10, 2014 at 3:39 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Wed, Jul 9, 2014 at 2:58 PM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
>> What does "some immediate intro picture at the top of front page
>> illustrating transformation of Python code through the toolchain to
>> machine execution instructions" mean exactly?
>> If you are talking about pictures that illustrate how a Python source
>> code is parsed and converted to bytecode it doesn't belong to the
>> front page of the devguide.
>
> Yes. This is what I have in mind. Do you have any objective arguments
> against this? Why are you so sure there is no place for it? Do you have
> the specific picture that I can apply and see that it really doesn't fit
> here, so I can adjust it or just say what is conceptually wrong and leave
> the work for people who are more proficient in this?
>

If this is the picture you want, when you reported the issue you
should have said that you find
https://docs.python.org/devguide/compiler.html#abstract unclear and
that you think a flow chart would make things clearer.  Adding a flow
chart on that page might be ok, but it definitely doesn't belong on
the frontpage.  The reason why it doesn't belong there is that 99% of
the people who starts contributing aren't there to hack on the
compiler (and if they are, they likely know already how it works), and
while having an idea of how it works is useful, there are things that
are much more important (e.g. where to find the code, how to use the
different tools, etc.).
The compiler page already has a quite clear list of 4 steps, and lying
them horizontal and wrap them into boxes connected by arrows is not
going to make it much clearer, so a similar proposal could still be
rejected.

> Do you think that coders can not draw pictures, and the reason for you
> to close this issue is because you think that neither me, nor you can
> draw one? Should all bugs that neither me nor you can fix be closed?
>

That's not the reason, the main reasons are that the report is/was
vague and that request seems to have an arguably marginal benefit (the
list is already clear, adding a drawing/image/flow chart won't change
much).
If you take a look at e.g.
https://issues.apache.org/bugwritinghelp.html you should see how any
bug report/RFE should have at least these two qualities:
 * Reproducible: we need to be able to see that there are unclear
parts in the devguide that will benefit from an image;
 * Specific: we need to know exactly where are these parts.
As that page says, if your report lacks these qualities (and your
does) it will be closed (as it happened).

>> If you are talking about using
>> configure/make to compile python, at the top of the front page there's
>> already the quick start, which is a simple bullet list with useful
>> links.  You could turn that to an image but it won't get much easier
>> to understand, and you won't be able to add links to the image.
>
> No.
>
>> Can you link to a specific section of the devguide that you think
>> should be converted to an image, and suggest what things should be in
>> the image (and/or propose an ASCII-art version of the image you are
>> suggesting)?
>
> Read the subject again. `devguide needs pictures` is an issue. It is
> about means that devguide is not attractive, not that there is not enough
> information.

Attractiveness is subjective.  I used the devguide several times,
alone and during sprints, and improved things that were not clear, but
never felt the need for drawings (not saying that they are useless,
just not essential).  The quick start on the front page was added
after a sprint because I noticed that people were having problems
finding all the right steps scattered through different pages.  I
don't think anyone read the compiler page during the sprints, and if
they did no one complained about the fact that it's difficult to
understand without images.

> Just that this information is hard to read.

Again, can you quote exactly the part(s) that are hard to read?

> I am the user, I report bug. You ask me to be a design guy and developer.

In open source people tend to scratch their own itches (more or less
indirectly).  Especially in the case of RFEs, unless you manage to
convince other people that they should scratch your itch, no one is
going to do it for you.
This means that either you do it, or you find someone to do it for
you, or you leave the issue languishing there forever.
Also note that it's different with bugs -- the set of bugs is limited
while the set of potential improvement is infinite.

> I am sure
> that there are professionals who are not only interested, but could do
> this professionally and much better than me - identify the place and
> illustrate the process.

I don't think that's the issue, I could have done the flowchart myself
but it's not clear to me what flowchart do you want and how would that
make things better than a bullet list.

> Closing bugs, because they are reported by users is bad indicator.

That's not the reason why it was closed.  I explained the reason above.

> Knowing that I possess the skills to draw and
> develop is not a reason to assume that I am not a user and can do this.
>
> The picture that absolutely needs to be present is an overview of what
> Python is from inside

This is still very vague.  Even if I had artistic skills I wouldn't
know what to do with this request (unless you wanted a piece of
abstract modern art (possibly involving snake entrails?)).

>, a concept, an art, sketch - anything that draws
> interest and is based on real things inside, not a lie and not a compete
> fantasy.

Above you only mentioned a flow chart to explain the steps from code
-> parsing -> ast -> control flow graph -> bytecode.  I'm going to
assume that here you are expanding/generalizing the issue to other
potential (but still undefined) places.
That said, I think the only form of "art" that might belong in the
devguide is either ASCII-art, or some sort of flow chart.
I'm not sure what kind of art you are requesting now.

> The correct approach for it is to organize an art competition.

Do you seriously think that spending time and money to make an art
competition to make flow charts is "the correct approach"?  Do you
think that artists will flock and compete to make the best flow chart
for the Python devguide?
Do you think that the resulting flow charts will be significantly
better than the current bullet lists, enough to justify all the
effort?
Even if you find some artist willing to spend their time improving
Python, I think it would be better to use their time to do something
like http://learnyouahaskell.com/introduction#about-this-tutorial,
which will reach a far wider audience and be more useful for the
Python ecosystem.

> I think that organization that specifically created to "promote, protect,
> and advance the Python programming language" should somehow
> jump in and say something about this.

From report at bugs.python.org  Thu Jul 10 17:34:16 2014
From: report at bugs.python.org (ingrid)
Date: Thu, 10 Jul 2014 15:34:16 +0000
Subject: [docs] [issue20265] Bring Windows docs up to date
In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za>
Message-ID: <1405006456.14.0.681195832902.issue20265@psf.upfronthosting.co.za>


ingrid added the comment:

Hi Kathleen, I was just curious why you dropped the changes from Doc/using/windows.rst on your latest patch as they looked useful to me. I know there's some review going on outside this thread, so apologies if I'm missing something you already went over.

----------
nosy: +ingrid, jesstess

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

From report at bugs.python.org  Thu Jul 10 19:52:07 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 10 Jul 2014 17:52:07 +0000
Subject: [docs] [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1405014727.8.0.211149266338.issue13081@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


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

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

From report at bugs.python.org  Thu Jul 10 20:05:29 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 10 Jul 2014 18:05:29 +0000
Subject: [docs] [issue15418] 2to3 docs should mention setup.py fixes
	required to	install compatible packages in Python 3
In-Reply-To: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>
Message-ID: <1405015528.98.0.767130240814.issue15418@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I disagree with this on two grounds.  First 2to3 can be run by anybody needing it, not just from setup.py.  Second the recommended mechanism for writing new code is to use libraries such as six so that the one code base can run on 2 and 3.

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

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

From report at bugs.python.org  Fri Jul 11 05:46:15 2014
From: report at bugs.python.org (Dev Player)
Date: Fri, 11 Jul 2014 03:46:15 +0000
Subject: [docs] [issue12902] help("modules") executes module code
In-Reply-To: <1315251083.43.0.259542197646.issue12902@psf.upfronthosting.co.za>
Message-ID: <1405050375.01.0.812469430679.issue12902@psf.upfronthosting.co.za>


Dev Player added the comment:

Mentioned for informational purposes only.

I too experience the running of external packages with a different library when doing help('modules') in the interpreter. This is a fresh install of Python 3.4 on WinXP.

The text I get in the python.exe interpreter is:
"Expected Tk Togl installation in C:\Python\Python34\lib\site-packages\OpenGl\Tk\togl-win32"

Then I get an empty TK popup window.

Although this other issue was ages ago and was with a different machine, Python version and set of libraries I'm giving reference to this only because of mention of help(). http://bugs.python.org/issue10060

Although there is a command line option to prevent the import of site, while I may not want "help" to be imported, I usually want "site" to be imported. It would be nice to exclude the "help" import only via a command line.

I wonder if the interpreter could be given a command line option just to parse modules/scripts/packages/librarys to only compile the lines containing def and class without anything within the namespace except implicitly declared docstrings  (it not __doc__ = """...""")

In other words if you had source like:
def somefunc(arg=None):
   """here is the func __doc__"""
   x = value
   callme()

the interpreter could basically compile that into:

def somefunc(arg-None):
    """here is the func __doc__"""
    return None

or perhaps shortcircuit any non def/class/ """ """ to be tokenized as the pass statement would be.

Those would be feature/enhance kind thing I suppose.

----------
nosy: +devplayer

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

From report at bugs.python.org  Fri Jul 11 15:07:11 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 11 Jul 2014 13:07:11 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405084031.23.0.0152130556005.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


----------
nosy: +benjamin.peterson, steven.daprano

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

From report at bugs.python.org  Fri Jul 11 15:07:43 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Fri, 11 Jul 2014 13:07:43 +0000
Subject: [docs] [issue21956] Deleted document should not appear in 3.4 docs
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405084063.07.0.871907629003.issue21956@psf.upfronthosting.co.za>


Changes by Brandon Rhodes <brandon at rhodesmill.org>:


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

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

From report at bugs.python.org  Fri Jul 11 15:07:46 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 11 Jul 2014 13:07:46 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405084066.84.0.931845469078.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


----------
nosy: +ethan.furman

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

From report at bugs.python.org  Fri Jul 11 16:23:07 2014
From: report at bugs.python.org (Andy Maier)
Date: Fri, 11 Jul 2014 14:23:07 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405088584.9.0.174438283781.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded v8 of the patch for 3.4 and default.

It reflects hopefully everything that was said in this issue thread, and on the python-dev mailing list (subject: == on object tests identity in 3.x), at least to the extent it was related to comparisons.

Besides the doc changes it contained previously, it now also contains improvements for the test suite for comparisons (lib/test/test_compare.py).

-> Please review both.
 
Andy

----------
Added file: http://bugs.python.org/file35924/issue12067-expressions-py34_v8.diff

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

From report at bugs.python.org  Fri Jul 11 16:39:59 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jul 2014 14:39:59 +0000
Subject: [docs] [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1405089599.54.0.354072216657.issue13081@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy implemented the FileIO class in pure Python: see the issue #21859 (patch under review).

----------

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

From report at bugs.python.org  Fri Jul 11 16:40:23 2014
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 11 Jul 2014 14:40:23 +0000
Subject: [docs] [issue13081] Crash in Windows with unknown cause
In-Reply-To: <1317417665.11.0.474916583341.issue13081@psf.upfronthosting.co.za>
Message-ID: <1405089623.42.0.32727553267.issue13081@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul 11 17:03:17 2014
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 11 Jul 2014 15:03:17 +0000
Subject: [docs] [issue21956] Deleted document should not appear in 3.4 docs
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405090997.64.0.837142463377.issue21956@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

> in many cases flat-out wrong

What advice is "flat-out wrong"? All the advice seems excellent to me:

* avoid "from spam import *" (with a very few exceptions)
* be cautious about "from spam import eggs"
* avoid bare "except" clauses
* watch out for "time from check to time to use" race conditions
  (e.g. prefer EAFP over LBYL when opening files)
* don't reinvent the wheel poorly when the std lib already solves
  your problem
* avoid backslash as line continuation


> It should be deleted as soon as possible.

Why delete it rather than fix any (alleged) problems with it?


> The advice is currently being debated on Twitter and people 
> are sad that they are supposed to stop using ?from foo import bar?

Debated on Twitter. Why am I not surprised that they've misunderstood it?

The document explains why "from foo import bar" can *sometimes* be harmful. The wording could be improved, and isn't as clear as it should be, but the advice is broadly correct: "from foo import bar" injects the object bar into the current namespace, not the name, which means that if foo rebinds bar, that change will not be seen in the current namespace. If foo never rebinds bar, then there is no problem, but if bar is a *variable* rather than a (pseudo-)constant, you may run into subtle and tricky problems.

-1 on deleting.

If the consensus is to keep it, I'll look at rewording and improving some of the weaker descriptions.

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

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

From report at bugs.python.org  Fri Jul 11 17:16:38 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Fri, 11 Jul 2014 15:16:38 +0000
Subject: [docs] [issue21956] Deleted document should not appear in 3.4 docs
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405091798.89.0.799000038321.issue21956@psf.upfronthosting.co.za>


Brandon Rhodes added the comment:

The question of whether the document ought to be removed is not at issue here. The document was already deleted, in 2011, by Raymond Hettinger, with the consent of its author. I told that story merely as background.

The issue here is that the Python web site is out of date with the documentation in the Mercurial source repository, which is clear because what is clearly marked as an old 3.3-alpha document is being served out of the /3.4/ directory. This is probably because the documentation ?push? script does not remove documents from the site, and can be corrected through a simple "rm" by anyone with access to the server.

----------

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

From report at bugs.python.org  Fri Jul 11 17:21:13 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jul 2014 15:21:13 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405092073.06.0.178695613992.issue21956@psf.upfronthosting.co.za>


R. David Murray added the comment:

The file no longer exists in the 3.5 tree on the server.  Since it isn't linked from the 3.4 index, it may be more effort than it is worth to get someone to delete the file from the 3.4 tree on the server.  On the other hand, fixing the publication process to delete files is something the doc team should probably tackle (note: it might be a sphinx issue, but as Brandon says is more likely an issue with the script that publishes the pages to the server).

As for revising the howto and re-adding it, that is a separate issue and should be discussed on the original issue 7391, where the possibility was already raised and got some support.

----------
nosy: +r.david.murray
title: Deleted document should not appear in 3.4 docs -> Doc files deleted from repo are not deleted from docs.python.org.
versions: +Python 2.7, Python 3.5

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

From shompol at gmail.com  Fri Jul 11 00:34:46 2014
From: shompol at gmail.com (Boris Zyranov)
Date: Thu, 10 Jul 2014 18:34:46 -0400
Subject: [docs] Python 3.3 and 3.4 bug
Message-ID: <CADGH9qODk2sSg5NiW_gbFxp3ukfRkvoj0Y+LJQETeoAO4yzYpg@mail.gmail.com>

I found a bug where a string returned by pyodbc exhibits and unstable
behavior when used with format()

After many failed attempts to create an account on (http://bugs.python.org/)
I submitted a bug report to pyodbc list instead:

https://code.google.com/p/pyodbc/issues/detail?id=375

Please refer to the above link for a detailed description.

Thank you
- Boris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140710/817f1f5d/attachment.html>

From report at bugs.python.org  Fri Jul 11 19:48:17 2014
From: report at bugs.python.org (Audrey Roy)
Date: Fri, 11 Jul 2014 17:48:17 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405100897.58.0.728928387819.issue21956@psf.upfronthosting.co.za>


Audrey Roy added the comment:

> Since it isn't linked from the 3.4 index, it may be more effort than 
> it is worth to get someone to delete the file from the 3.4 tree on the
> server.

It would be worthwhile to delete or fix it in the 2.7 and 3.4 tree.

It accidentally gets linked, still causing confusion to 2.7 and 3.4 users:
https://twitter.com/audreyr/status/487446878837944320

----------
nosy: +audreyr

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

From report at bugs.python.org  Fri Jul 11 20:29:42 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Jul 2014 18:29:42 +0000
Subject: [docs] [issue13574] refresh example in doc for Extending and
	Embedding
In-Reply-To: <1323546725.7.0.960922330938.issue13574@psf.upfronthosting.co.za>
Message-ID: <1405103382.7.0.433570810227.issue13574@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

https://docs.python.org/3/extending/newtypes.html still refers to PyInstanceObject, I'm sorry but I've no idea what the replacement is called, so I'll leave this to someone in the know.

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 11 21:05:33 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Jul 2014 19:05:33 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405105533.16.0.65574478566.issue21956@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The docs state 'from module import name1, name2. - This is a ?don?t? which is much weaker than the previous ?don?t?s but is still something you should not do if you don?t have good reasons to do that.'  How does that translate into 'The Python docs say that "from module import name1, name2" is an anti-idiom' ?

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

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

From report at bugs.python.org  Fri Jul 11 20:15:42 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Jul 2014 18:15:42 +0000
Subject: [docs] [issue10175] vs version for win32 compilation of extension
	modules is	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1405102542.59.0.244727234848.issue10175@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

There's a table here https://docs.python.org/X/using/windows.html#compiling-python-on-windows which shows what versions you need, where X can be 2 or 3.

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 11 20:13:00 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 11 Jul 2014 18:13:00 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405102380.41.0.1132489152.issue12067@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+  In other words, the following expressions should have the same result:
+
+    ``x == y`` and ``not x != y``
+
+    ``x < y`` and ``not x >= y``
+
+    ``x > y`` and ``not x <= y``

I think the second and third items here go too far: sets don't obey these rules, for example.  Not all uses of comparisons need to force a total ordering.

OTOH, you leave out a more fundamental relation, namely that `x < y` and `y > x` should ordinarily give the same result, as should `x <= y` and `y >= x`.

----------

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

From report at bugs.python.org  Fri Jul 11 21:48:44 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 11 Jul 2014 19:48:44 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1405108124.75.0.352270967726.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think the example would be clarified by speaking about mutation operations versus non-mutation operations.  After all:

>>> x = [1]
>>> y = x
>>> x = x + [2]
>>> x
[1, 2]
>>> y
[1]

At that point including a list += operation would also be beneficial.

----------

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

From report at bugs.python.org  Fri Jul 11 21:58:31 2014
From: report at bugs.python.org (Audrey Roy)
Date: Fri, 11 Jul 2014 19:58:31 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405108711.43.0.929702865541.issue21956@psf.upfronthosting.co.za>


Audrey Roy added the comment:

Mark, I and a number of others simply misinterpreted the text in that section.

----------

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

From report at bugs.python.org  Fri Jul 11 21:20:32 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 11 Jul 2014 19:20:32 +0000
Subject: [docs] [issue12217] Cross-link docs for faulthandler,
	traceback and pdb
In-Reply-To: <1306770313.4.0.799430970978.issue12217@psf.upfronthosting.co.za>
Message-ID: <1405106432.26.0.624301932708.issue12217@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Who has the technical knowledge to write a patch for this?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Fri Jul 11 22:11:17 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Fri, 11 Jul 2014 20:11:17 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405084031.97.0.312909906567.issue21956@psf.upfronthosting.co.za>
Message-ID: <1405109476.93.0.094929814012.issue21956@psf.upfronthosting.co.za>


Brandon Rhodes added the comment:

I do not find it unreasonable, on a page of Python idioms, the we would call an example that explicitly says "Don't" in its title an "anti-idiom."

----------

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

From report at bugs.python.org  Sat Jul 12 01:31:55 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 11 Jul 2014 23:31:55 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1405121515.23.0.115486651722.issue20135@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Good point, I'll try to add that to the FAQ.

----------

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

From report at bugs.python.org  Sat Jul 12 18:51:50 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 12 Jul 2014 16:51:50 +0000
Subject: [docs] [issue15414] os.path.join behavior on Windows (ntpath.join)
	is	unexpected and not well documented
In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>
Message-ID: <1405183910.37.0.877217389519.issue15414@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

ntpath.join() was fixed in issue19456 so I think all we need here is a commit review of the attached documentation patch.

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

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

From report at bugs.python.org  Sat Jul 12 18:56:51 2014
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 12 Jul 2014 16:56:51 +0000
Subject: [docs] [issue15414] os.path.join behavior on Windows (ntpath.join)
	is	unexpected and not well documented
In-Reply-To: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>
Message-ID: <1405184211.88.0.370899427379.issue15414@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Sat Jul 12 18:59:03 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jul 2014 16:59:03 +0000
Subject: [docs] [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1405184343.01.0.541655601042.issue15849@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I added "documentation" to the components list because this in the main purpose of this module - to serve as a template for extension module writers.

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

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

From report at bugs.python.org  Sat Jul 12 18:59:14 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jul 2014 16:59:14 +0000
Subject: [docs] [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1405184354.92.0.944812809051.issue15849@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Sat Jul 12 19:20:50 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 12 Jul 2014 17:20:50 +0000
Subject: [docs] [issue21928] Incorrect reference to partial() in
	functools.wraps	documentation
In-Reply-To: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>
Message-ID: <1405185650.49.0.202542022626.issue21928@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The docstring is correct, as this is how wraps is implemented (see Lib/functools.py#l73).
partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated) will return a partial version of update_wrapper() where only the wrapper argument is missing.  The missing argument is the function decorated with wraps().

For example, this code:

def my_decorator(f):
    @wraps(f)
    def wrapper(*args, **kwds):
        return f(*args, **kwds)
    return wrapper

is equivalent to:

def my_decorator(f):
    def wrapper(*args, **kwds):
        return f(*args, **kwds)
    wrapper = wraps(f)(wrapper)
    return wrapper

Here wraps(f) creates a partial version of update_wrapper, with only the "wrapped" argument (i.e. f) set.  When the partial object returned by wrap(f) gets called, the missing "wrapper" argument is received, thus making wraps(f)(wrapper) equivalent to:

def my_decorator(f):
    def wrapper(*args, **kwds):
        return f(*args, **kwds)
    wrapper = update_wrapper(wrapper, f)
    return wrapper


That said, I agree that the sentence you quoted is not too clear/intuitive, but the following example is quite clear, so I'm not sure it's worth to removing/rephrasing the first part.

Maybe it could say something like "This is a convenience function for invoking update_wrapper() (by using partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated)) as a function decorator when defining a wrapper function." instead?

----------
nosy: +ezio.melotti, r.david.murray, rhettinger, terry.reedy
status: open -> pending
type:  -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Sat Jul 12 19:49:17 2014
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 12 Jul 2014 17:49:17 +0000
Subject: [docs] [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1405187357.75.0.0325529597179.issue15849@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I think we should perhaps leave the xxmodule as an example for
static types and create another pep-384 version that mentions
*potential* performance traps.

Of course many modules won't suffer from this, but first-time
extension writers tend to paste from the examples and should
know the alternatives if they happen to write a performance
sensitive application.

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

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

From report at bugs.python.org  Sat Jul 12 20:15:45 2014
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Jul 2014 18:15:45 +0000
Subject: [docs] [issue15849] PEP 3121, 384 Refactoring applied to xx module
In-Reply-To: <1346596353.57.0.974507844943.issue15849@psf.upfronthosting.co.za>
Message-ID: <1405188945.93.0.0478365233085.issue15849@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> create another pep-384 version

+1 - and with a more descriptive name than xxmodule.c

Suggestions:

* pep384module.c
* pep384demo.c
* pep384.c
* abidemo.c

----------

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

From report at bugs.python.org  Sat Jul 12 20:34:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 12 Jul 2014 18:34:43 +0000
Subject: [docs] [issue14050] Tutorial, list.sort() and items comparability
In-Reply-To: <1329584329.12.0.545057513034.issue14050@psf.upfronthosting.co.za>
Message-ID: <1405190083.57.0.358735839749.issue14050@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unless I'm misremembering, it is exactly __lt__ (or __gt__, if __lt__ returns NotImplemented) that sorting depends on.  Since I'm sure there is code out there that depends on this fact, I wonder if it should be part of the language definition.

Also, the comparison documentation (https://docs.python.org/3/reference/expressions.html#comparisons) speaks about "total ordering" as being the requirement, which has a specific mathematical meaning (which sets, for example, do not satisfy, even though they have a __lt__ method).  Whether or not the distinction is worth explaining in the tutorial is a open question.

----------

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

From report at bugs.python.org  Sun Jul 13 05:49:36 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Sun, 13 Jul 2014 03:49:36 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
Message-ID: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>


New submission from Fran?ois-Ren? Rideau:

The lexer documentation says that the u prefix works on strings since 3.3, but doesn't explain what or how, which is all the more problematic since it explicitly mentions difference from the behavior documented in Python 2.

It also doesn't specify the ELLIPSIS token or the <> future token mentioned in the grammar (that should probably be removed, for PEP 401 is a joke ? unless that's intentional, in which case a smiley might be useful).

https://docs.python.org/3.5/reference/lexical_analysis.html

----------
assignee: docs at python
components: Documentation
messages: 222906
nosy: Fran?ois-Ren?.Rideau, docs at python
priority: normal
severity: normal
status: open
title: Bugs in the lexer and parser documentation
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun Jul 13 06:09:29 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 13 Jul 2014 04:09:29 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1405224569.2.0.608403850067.issue21972@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I don't understand. It says "it is possible again to prefix unicode strings with a u prefix" which seems to include both what ("prefix unicode strings") and how ("with a u prefix").

Can you propose specific wording that you want to see included?

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Jul 13 14:17:22 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 13 Jul 2014 12:17:22 +0000
Subject: [docs] [issue15962] Windows STDIN/STDOUT Redirection is actually
	FIXED
In-Reply-To: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za>
Message-ID: <1405253842.49.0.870398634796.issue15962@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

This can be closed as "out of date" as extensive changes made to the Windows FAQ have removed the wording referenced in the patch.

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

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

From report at bugs.python.org  Sun Jul 13 15:23:38 2014
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 13 Jul 2014 13:23:38 +0000
Subject: [docs] [issue15962] Windows STDIN/STDOUT Redirection is actually
	FIXED
In-Reply-To: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za>
Message-ID: <1405257818.12.0.830540229735.issue15962@psf.upfronthosting.co.za>


Changes by Brian Curtin <brian at python.org>:


----------
nosy:  -brian.curtin

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

From report at bugs.python.org  Sun Jul 13 15:46:45 2014
From: report at bugs.python.org (Quan Nguyen)
Date: Sun, 13 Jul 2014 13:46:45 +0000
Subject: [docs] [issue21974] Typo in "Set" in PEP 289
Message-ID: <1405259205.91.0.354050943878.issue21974@psf.upfronthosting.co.za>


New submission from Quan Nguyen:

This statement in the Rationale section:

"s = Set(word  for line in page  for word in line.split())"

"Set" should be "set" (lowercase 's')

----------
assignee: docs at python
components: Documentation
messages: 222924
nosy: Quan.Nguyen, docs at python
priority: normal
severity: normal
status: open
title: Typo in "Set" in PEP 289

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

From report at bugs.python.org  Sun Jul 13 16:00:08 2014
From: report at bugs.python.org (Andy Maier)
Date: Sun, 13 Jul 2014 14:00:08 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405260008.96.0.932867156069.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


Added file: http://bugs.python.org/file35938/try_eq.py

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

From report at bugs.python.org  Sun Jul 13 16:00:53 2014
From: report at bugs.python.org (Andy Maier)
Date: Sun, 13 Jul 2014 14:00:53 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405260053.33.0.782933228814.issue12067@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


Added file: http://bugs.python.org/file35939/try_eq.out

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

From report at bugs.python.org  Sun Jul 13 17:03:19 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Sun, 13 Jul 2014 15:03:19 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1405263799.03.0.724108717148.issue21972@psf.upfronthosting.co.za>


Fran?ois-Ren? Rideau added the comment:

Actually, my reading was buggy, and the "u" part is well-documented enough. Apologies for this part of the bug report.

The lexer documentation is still missing the ellipsis, though

Other bug I found in the lexer documentation: missing @=

And the parser documentation of <> is probably a bug.

----------

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

From report at bugs.python.org  Sun Jul 13 17:16:00 2014
From: report at bugs.python.org (Andy Maier)
Date: Sun, 13 Jul 2014 15:16:00 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405264560.3.0.685444737931.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Mark: Both are good points!

Would you add the cases from your second comment under "symmetry"?

----------

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

From report at bugs.python.org  Sun Jul 13 17:25:15 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 13 Jul 2014 15:25:15 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1405265114.96.0.863582508372.issue8519@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

My understanding is that we can't use the patches as the originator has never signed the CLA.  Am I correct or does this only apply to code, or what?

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

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

From report at bugs.python.org  Sun Jul 13 20:35:46 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 13 Jul 2014 18:35:46 +0000
Subject: [docs] [issue15962] Windows STDIN/STDOUT Redirection is actually
	FIXED
In-Reply-To: <1347970794.78.0.910609008076.issue15962@psf.upfronthosting.co.za>
Message-ID: <1405276546.74.0.0766069014406.issue15962@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Jul 13 23:12:52 2014
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 13 Jul 2014 21:12:52 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405285972.44.0.226152848295.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Here's a draft patch against the default branch that updates the json module's docs accordingly.

Note that under "Implementation Limitations", the statement "This module does not impose any such limits beyond those of the relevant Python datatypes themselves or the Python interpreter itself." is just a guess; I need someone who's familiar with the implementation to verify/correct this.

----------
keywords: +patch
Added file: http://bugs.python.org/file35945/json-rfc-7159_1.patch

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

From report at bugs.python.org  Sun Jul 13 23:47:06 2014
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 13 Jul 2014 21:47:06 +0000
Subject: [docs] [issue10289] Document magic methods called by built-in
	functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1405288026.75.0.862952081853.issue10289@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Mon Jul 14 02:37:52 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 00:37:52 +0000
Subject: [docs] [issue21974] Typo in "Set" in PEP 289
In-Reply-To: <1405259205.91.0.354050943878.issue21974@psf.upfronthosting.co.za>
Message-ID: <1405298272.45.0.14243698314.issue21974@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

To modern eyes, that might look like a typo, but it is correct.  It refers to the Set() class in the sets.py module, the pure python implementation of sets which pre-dates the c-implementation of the set() built-in type.

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

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

From techtonik at gmail.com  Thu Jul 10 14:39:15 2014
From: techtonik at gmail.com (anatoly techtonik)
Date: Thu, 10 Jul 2014 15:39:15 +0300
Subject: [docs] [issue19608] devguide needs pictures
In-Reply-To: <CACBhJdFk3abPWaWUhRNqPj-jgcqyLt8pK5s7Q_9_xt2Kack3aw@mail.gmail.com>
References: <1384510390.93.0.961404476169.issue19608@psf.upfronthosting.co.za>
 <1404824996.52.0.487450681845.issue19608@psf.upfronthosting.co.za>
 <CAPkN8x+-k6f3qiVms6cJd2sqeEik12h4HHW1A91VrA6LxNwB8Q@mail.gmail.com>
 <CACBhJdFk3abPWaWUhRNqPj-jgcqyLt8pK5s7Q_9_xt2Kack3aw@mail.gmail.com>
Message-ID: <CAPkN8xLtm-UxRNfUC+_5OzBkkGC2yLQ7bHpTwkJhAomBMZmb8Q@mail.gmail.com>

On Wed, Jul 9, 2014 at 2:58 PM, Ezio Melotti <ezio.melotti at gmail.com> wrote:
> What does "some immediate intro picture at the top of front page
> illustrating transformation of Python code through the toolchain to
> machine execution instructions" mean exactly?
> If you are talking about pictures that illustrate how a Python source
> code is parsed and converted to bytecode it doesn't belong to the
> front page of the devguide.

Yes. This is what I have in mind. Do you have any objective arguments
against this? Why are you so sure there is no place for it? Do you have
the specific picture that I can apply and see that it really doesn't fit
here, so I can adjust it or just say what is conceptually wrong and leave
the work for people who are more proficient in this?

Do you think that coders can not draw pictures, and the reason for you
to close this issue is because you think that neither me, nor you can
draw one? Should all bugs that neither me nor you can fix be closed?

> If you are talking about using
> configure/make to compile python, at the top of the front page there's
> already the quick start, which is a simple bullet list with useful
> links.  You could turn that to an image but it won't get much easier
> to understand, and you won't be able to add links to the image.

No.

> Can you link to a specific section of the devguide that you think
> should be converted to an image, and suggest what things should be in
> the image (and/or propose an ASCII-art version of the image you are
> suggesting)?

Read the subject again. `devguide needs pictures` is an issue. It is
about means that devguide is not attractive, not that there is not enough
information. Just that this information is hard to read. I am the user, I
report bug. You ask me to be a design guy and developer. I am sure
that there are professionals who are not only interested, but could do
this professionally and much better than me - identify the place and
illustrate the process. Closing bugs, because they are reported by
users is bad indicator. Knowing that I possess the skills to draw and
develop is not a reason to assume that I am not a user and can do this.

The picture that absolutely needs to be present is an overview of what
Python is from inside, a concept, an art, sketch - anything that draws
interest and is based on real things inside, not a lie and not a compete
fantasy. The correct approach for it is to organize an art competition. I
think that organization that specifically created to "promote, protect,
and advance the Python programming language" should somehow
jump in and say something about this.

From tgmiller5 at hotmail.com  Sat Jul 12 21:38:44 2014
From: tgmiller5 at hotmail.com (Tammy Miller)
Date: Sat, 12 Jul 2014 15:38:44 -0400
Subject: [docs] Interested in contributing to documentation
Message-ID: <COL125-W45354ECE03C0BD439882B3FA080@phx.gbl>

My name is Tammy and I am interested in contributing to documentation for Python. 

Thank you, 
Tammy 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140712/48db3d95/attachment-0001.html>

From jhernancanom at hotmail.com  Mon Jul 14 00:58:30 2014
From: jhernancanom at hotmail.com (=?iso-8859-1?B?SGVybuFuIENhbm8gTWFydO1uZXo=?=)
Date: Sun, 13 Jul 2014 17:58:30 -0500
Subject: [docs] About wxBasic
Message-ID: <BLU174-W50FDBEFEAEBB1BC10CBE1BD50B0@phx.gbl>


Hi, boys & girls.
My native speech-language is Spanish; sorry if this text sounds strange/rare.
These days I am reading --and asking for-- a lot about wxWidgets because I want to write an interpreter for a prog-language that yet there is not in wxWidgets.
I have found that there is wxPython, wxLua, wxUnderC, wxCINT and wxBasic.I consider that wxBasic is similar to the one I need.
I am with my son in an implementation of wxLuaFreeze and I like it. And I see that wxBasic is similar (in execution from console).
I would like to get wxBasic sources and read them for knowing about what do I need for writing an interpreter for the prog-language I need.
I want some guidance about wxBasic: the first (main) program I need to edit, if every command/function/property is in a text-file then how must be structured this text-file.
I can see in a .BAT that (1) first we must execute REDIR and BISON for detecting syntax errors, then (2) we execute QBASIC for creating the wrappers (??), and then (3) we execute MAKE for compiling the program.In this case I ask you: (a) how can I get REDIR and BISON?, (b) why is needed to create wrappers?, (3) what is the structure of the source files of the project --or how can I get it-- for me to explore addequately the project? (4) is wxEditor the only IDE for "design" the frames and controls? or is the best for wxBasic? could I use VisualWx or wxFormBuilder or CodeBlocks or wxDevC++? I ask this... not for changing something, but for knowing about the raising of wxWidgets or these utilities.
If I could get --for the interpreter I need-- the same scenario than current wxBasic, it could be enough.
Something else:One answer --that I received-- indicated me that "wxWidgets sources can be compiled for my prog-language" because this way I can call the wxWidget functions for creating controls. But I consider that any wxWidgets DLL --compiled by a mate or a colleague for Windows-- could be used by my Win-machine: I think that if the DLL runs for a .Net language, it would run for "any" Win-programming language.Why that colleague said me that I must compile it if any other compilation (to DLL) serves me? In what am I wrong? If somebody already compiles wxWidgets to DLL, I think I could use it copying it to my machine and writing a program (in any prog-language) for using that wxWidgets DLL.
Thanks and that God blesses you and me.
HERNAN CANO MARTINEZSystems Analyst - Programmer
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140713/94ab8bf8/attachment-0001.html>

From report at bugs.python.org  Mon Jul 14 09:23:21 2014
From: report at bugs.python.org (py.user)
Date: Mon, 14 Jul 2014 07:23:21 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
Message-ID: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>


New submission from py.user:

https://docs.python.org/3/library/re.html#writing-a-tokenizer

There are redundant escapes in the regex:

('OP',      r'[+*\/\-]'),    # Arithmetic operators

Sequence -+*/ is sufficient.

It makes the loop to do all steps on every 4 spaces:

('SKIP',    r'[ \t]'),       # Skip over spaces and tabs

Sequence [ \t]+ is faster.


Applied patch.

----------
assignee: docs at python
components: Documentation, Regular Expressions
files: re_ex_tok.diff
keywords: patch
messages: 223000
nosy: docs at python, ezio.melotti, mrabarnett, py.user
priority: normal
severity: normal
status: open
title: In the re's token example OP and SKIP regexes can be improved
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file35951/re_ex_tok.diff

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

From report at bugs.python.org  Mon Jul 14 10:32:21 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 08:32:21 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
In-Reply-To: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>
Message-ID: <1405326741.29.0.362409539378.issue21977@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul 14 10:38:22 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 08:38:22 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
In-Reply-To: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>
Message-ID: <1405327102.01.0.699449899901.issue21977@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I will keep the \- because the - at the front of the character range is a non-obvious special case.  The other changes look reasonable.

----------
priority: normal -> low
stage:  -> commit review
type: enhancement -> performance
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Jul 14 10:52:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 14 Jul 2014 08:52:51 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
In-Reply-To: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>
Message-ID: <3hBdst56YKz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset bb28542af060 by Raymond Hettinger in branch '3.4':
Issue 21977:  Minor improvements to the regexes in the tokenizer example.
http://hg.python.org/cpython/rev/bb28542af060

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

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

From report at bugs.python.org  Mon Jul 14 10:53:36 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 08:53:36 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
In-Reply-To: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>
Message-ID: <1405328016.54.0.321524657554.issue21977@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Mon Jul 14 10:56:48 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 08:56:48 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405328208.28.0.191726645799.issue21514@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> bob.ippolito
nosy: +bob.ippolito

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

From report at bugs.python.org  Mon Jul 14 17:23:42 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 14 Jul 2014 15:23:42 +0000
Subject: [docs] [issue21977] In the re's token example OP and SKIP regexes
	can be	improved
In-Reply-To: <1405322601.6.0.312118432344.issue21977@psf.upfronthosting.co.za>
Message-ID: <1405351422.45.0.631871712526.issue21977@psf.upfronthosting.co.za>


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


----------
stage: commit review -> resolved

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

From report at bugs.python.org  Mon Jul 14 17:58:43 2014
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 14 Jul 2014 15:58:43 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405353523.71.0.526392638772.issue21514@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

This patch looks reasonable to me as-is.

With regard to "Infinite and NaN number values are accepted and output;" there's an option for that (allow_nan=False in encoding, parse_constant=some_function_that_raises in decoding). Since an exception can't be raised in a lambda there's no simple one-liner to ensure compliant decode.

----------

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

From report at bugs.python.org  Mon Jul 14 18:14:59 2014
From: report at bugs.python.org (Chris Rebert)
Date: Mon, 14 Jul 2014 16:14:59 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405354499.64.0.940669742732.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

Thanks for the speedy review!

Those NaN-related arguments are already mentioned in the docs (see last 2 sentences of https://docs.python.org/3/library/json.html#infinite-and-nan-number-values ), and this patch doesn't touch that subsection.

----------

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

From report at bugs.python.org  Mon Jul 14 18:22:54 2014
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 14 Jul 2014 16:22:54 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405354974.65.0.308714927428.issue21514@psf.upfronthosting.co.za>


Bob Ippolito added the comment:

Good call, I was just doing a quick review of the patch in isolation. Now I don't have anything at all to comment on :)

----------

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

From report at bugs.python.org  Mon Jul 14 19:21:41 2014
From: report at bugs.python.org (Brandon Rhodes)
Date: Mon, 14 Jul 2014 17:21:41 +0000
Subject: [docs] [issue21956] Doc files deleted from repo are not deleted
	from	docs.python.org.
In-Reply-To: <1405105533.16.0.65574478566.issue21956@psf.upfronthosting.co.za>
 (Mark Lawrence's message of "Fri, 11 Jul 2014 19:05:33 +0000")
Message-ID: <871ttng8kc.fsf@asaph.rhodesmill.org>


Brandon Rhodes added the comment:

Now that I am back at a full keyboard, I see that my previous response
to @BreamoreBoy about this issue is too short and too cryptic to really
serve as a fair answer to his question.  And, with some embarrassment, I
note that my words did not even achieve the dignity of forming an actual
English sentence.  Alas for cramped travel laptop keyboards and airport
wi-fi!

Might I be allowed another try?  If so, then: @BreamoreBoy, I think that
your confusion ("How does that translate?") can be blamed squarely on
the document in question.  Instead of introducing and maintaining a
consistent terminology, it manages to burden the reader with two
parallel and redundant sets of terms for exactly the same idea.

In short, the document title does not match the document itself.

The title of the document sets forth the terms "Idiom" and "Anti-idiom"
as its subject.  But then it completely drops the ball.  The terms are
not defined in the document itself.  They are not clarified anywhere in
its text.  Nor are they even *used* anywhere in its body, with a single
lonely exception buried down somewhere around the middle (second
paragraph under "Exceptions").

Instead, the body uses the simpler phrases "Do", "do not", and "should
not."  It is running in its "do not" / "don't" mode when it reaches the
sentence you quote, Mark, about "from...import" statements.

So the answer to your "How does that translate" question is that what
the title promises as "Idioms" and "Anti-idioms" actually come out
verbally in the text as "do" and "don't" instead.  When someone jumps
into the middle of the document without context, they see only "do" or
"don't" and are left wondering where the terminology of "idioms" is even
coming from.  But it comes directly from the title, as the only possible
mapping between the document's terms and those of its title.

So when the document says:

    from module import name1, name2. - This is a "don?t"...

the careful reader who has noticed and remembered the title will
simultaneously read:

    from module import name1, name2. - This is an anti-idiom...

Which is almost exactly the text of Audrey's tweet.

----------

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

From report at bugs.python.org  Mon Jul 14 21:48:10 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 14 Jul 2014 19:48:10 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405367290.15.0.908886897083.issue21514@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks Bob.  If you want me to apply the patch, just assign this back to me.

----------

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

From report at bugs.python.org  Mon Jul 14 21:53:23 2014
From: report at bugs.python.org (Bob Ippolito)
Date: Mon, 14 Jul 2014 19:53:23 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1405367603.97.0.314509398375.issue21514@psf.upfronthosting.co.za>


Changes by Bob Ippolito <bob at redivi.com>:


----------
assignee: bob.ippolito -> rhettinger

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

From report at bugs.python.org  Mon Jul 14 22:11:12 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Jul 2014 20:11:12 +0000
Subject: [docs] [issue12955] urllib.request example should use "with ... as:"
In-Reply-To: <1315650628.73.0.673162910121.issue12955@psf.upfronthosting.co.za>
Message-ID: <1405368672.82.0.883899803508.issue12955@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul 14 22:28:00 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 14 Jul 2014 20:28:00 +0000
Subject: [docs] [issue14379] Several traceback docs improvements
In-Reply-To: <1332328007.08.0.704590425302.issue14379@psf.upfronthosting.co.za>
Message-ID: <1405369680.81.0.185705717425.issue14379@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As nobody has even commented on this, let alone proposed a patch, I'd be inclined to close as "won't fix" or "out of date".

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

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

From report at bugs.python.org  Mon Jul 14 22:31:30 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 14 Jul 2014 20:31:30 +0000
Subject: [docs] [issue15117] Please document top-level sqlite3 module
	variables
In-Reply-To: <1340205684.94.0.46461654189.issue15117@psf.upfronthosting.co.za>
Message-ID: <1405369890.12.0.133300968207.issue15117@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@wchlm sorry about the delay in responding, but would you like to propose a patch for this?

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

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

From report at bugs.python.org  Tue Jul 15 04:03:21 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Jul 2014 02:03:21 +0000
Subject: [docs] [issue8519] doc: termios and ioctl reference links
In-Reply-To: <1272125391.54.0.0119716465224.issue8519@psf.upfronthosting.co.za>
Message-ID: <1405389801.27.0.511095725512.issue8519@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

In this case I think there is no legal issue. All you have to do is take the link from the patch and come up with a fresh patch of your own.

(However I think Georg's objection against a Linux-specific link stands. You can probably find a POSIX link that would be acceptable.)

----------
nosy: +Guido.van.Rossum

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

From report at bugs.python.org  Tue Jul 15 10:50:14 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Jul 2014 08:50:14 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405414214.48.0.596099581978.issue12067@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/issue12067>
_______________________________________

From report at bugs.python.org  Tue Jul 15 17:07:00 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 15 Jul 2014 15:07:00 +0000
Subject: [docs] [issue16242] Pickle and __getattr__
In-Reply-To: <1350324673.62.0.567343854306.issue16242@psf.upfronthosting.co.za>
Message-ID: <1405436820.72.0.11212093212.issue16242@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Joseph please accept our apologies for the delay in getting back to you.

----------
nosy: +BreamoreBoy, alexandre.vassalotti, pitrou
versions: +Python 3.4, Python 3.5 -Python 2.6

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

From report at bugs.python.org  Tue Jul 15 17:09:42 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 15 Jul 2014 15:09:42 +0000
Subject: [docs] [issue16237] bdist_rpm SPEC files created with distutils may
	be	distro specific
In-Reply-To: <1350267871.71.0.392371801371.issue16237@psf.upfronthosting.co.za>
Message-ID: <1405436981.94.0.716234421241.issue16237@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Who is best placed to produce a patch for this?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 15 19:00:41 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 15 Jul 2014 17:00:41 +0000
Subject: [docs] [issue16652] socket.getfqdn docs are not explicit enough
	about the	algorithm.
In-Reply-To: <1355089481.55.0.645096435972.issue16652@psf.upfronthosting.co.za>
Message-ID: <1405443641.85.0.167671350971.issue16652@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm assuming that this still needs doing.

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 15 19:02:28 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 15 Jul 2014 17:02:28 +0000
Subject: [docs] [issue16663] Poor documentation for METH_KEYWORDS
In-Reply-To: <1355242591.45.0.999993608815.issue16663@psf.upfronthosting.co.za>
Message-ID: <1405443747.95.0.605912246848.issue16663@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@r3m0t we're sorry about the delay in getting back to you.  Could you write a patch that covers this?

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 2.6, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 15 19:12:13 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 15 Jul 2014 17:12:13 +0000
Subject: [docs] [issue21928] Incorrect reference to partial() in
	functools.wraps	documentation
In-Reply-To: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>
Message-ID: <1405444333.04.0.344559355003.issue21928@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would rewrite it as:

This is a convenience function for invoking update_wrapper() as a function decorator when defining a wrapper function.  It is equivalent to partial(update_wrapper, wrapped=wrapped, assigned=assigned, updated=updated).  For example:

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

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

From report at bugs.python.org  Tue Jul 15 19:18:02 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 15 Jul 2014 17:18:02 +0000
Subject: [docs] [issue16834] ioctl mutate_flag behavior in regard to the
	buffer size	limit
In-Reply-To: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>
Message-ID: <1405444682.05.0.484297254061.issue16834@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Yuval sorry about the delay in replying.  Can a *nix person comment on this please as I stick with Windows.

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

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

From report at bugs.python.org  Wed Jul 16 04:15:26 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 16 Jul 2014 02:15:26 +0000
Subject: [docs] [issue16237] bdist_rpm SPEC files created with distutils may
	be	distro specific
In-Reply-To: <1350267871.71.0.392371801371.issue16237@psf.upfronthosting.co.za>
Message-ID: <1405476926.63.0.254675995964.issue16237@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Actually, with RHEL and CentOS 7 out the door, I believe we could potentially just rip the whole mess out of the upstream project.

Slavek, this is about a hack Dave and I put into bdist_rpm to get Python 3 packages building correctly on RHEL 6. I believe the underlying issue with not specifying the interpreter version has been fixed for 7,so can we just get rid of the workaround now? Or at least double check the non-portability issue only affects 6 and close this as wontfix?

----------
nosy: +bkabrda

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

From report at bugs.python.org  Wed Jul 16 09:09:53 2014
From: report at bugs.python.org (Bohuslav "Slavek" Kabrda)
Date: Wed, 16 Jul 2014 07:09:53 +0000
Subject: [docs] [issue16237] bdist_rpm SPEC files created with distutils may
	be	distro specific
In-Reply-To: <1350267871.71.0.392371801371.issue16237@psf.upfronthosting.co.za>
Message-ID: <1405494593.31.0.516209062582.issue16237@psf.upfronthosting.co.za>


Bohuslav "Slavek" Kabrda added the comment:

Hi, so I'm not sure I understand this correctly. AFAICS there are two patches in issue 14443 that are, to certain degree, independent. As for the patch that overrides __os_install_post [1], that is no longer needed in RHEL 7, since the line

    /usr/lib/rpm/brp-python-bytecompile \

in RHEL 6 RPM has been replaced by

    /usr/lib/rpm/brp-python-bytecompile %{__python} %{?_python_bytecompile_errors_terminate_build} \

in RHEL 7 RPM. The other patch referenced from that issue that defines macro __python to self.python (meaning either sys.executable or "python3") [2] is still needed, I believe.

I hope that this answers the question.

[1] http://hg.python.org/cpython/rev/a9a12ad553f0
[2] http://hg.python.org/cpython/rev/3d61e27cc570

----------

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

From report at bugs.python.org  Wed Jul 16 13:17:44 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 16 Jul 2014 11:17:44 +0000
Subject: [docs] [issue16237] bdist_rpm SPEC files created with distutils may
	be	distro specific
In-Reply-To: <1350267871.71.0.392371801371.issue16237@psf.upfronthosting.co.za>
Message-ID: <1405509464.51.0.621240983324.issue16237@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks Slavek. That means this bug doesn't affect RHEL 7 or CentOS 7, and if it affects the Python 3 software collections on RHEL/CentOS 6, we can potentially deal with it on the collection side of things.

Accordingly, closing this as a problem for downstream to deal with.

Thanks for the prompt, Mark.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jul 16 14:40:19 2014
From: report at bugs.python.org (SylvainDe)
Date: Wed, 16 Jul 2014 12:40:19 +0000
Subject: [docs] [issue21989] Missing (optional) argument `start` and `end`
	in	documentation for list.index
Message-ID: <1405514419.16.0.727549411971.issue21989@psf.upfronthosting.co.za>


New submission from SylvainDe:

>From :

https://docs.python.org/2/tutorial/datastructures.html and
https://docs.python.org/3.4/tutorial/datastructures.html (and all other versions) :

----------------------------
    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.
----------------------------

>From `help(list)` :

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

Thus, second and third parameter are undocumented.

----------
assignee: docs at python
components: Documentation
files: list_index_start_end.patch
keywords: patch
messages: 223195
nosy: SylvainDe, docs at python
priority: normal
severity: normal
status: open
title: Missing (optional) argument `start` and `end` in documentation for list.index
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35967/list_index_start_end.patch

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

From louthompsonca at gmail.com  Wed Jul 16 04:27:43 2014
From: louthompsonca at gmail.com (Lou Thompson)
Date: Tue, 15 Jul 2014 19:27:43 -0700
Subject: [docs] https://docs.python.org/3/contents.html
Message-ID: <000001cfa09d$8827c0d0$98774270$@gmail.com>

The subject page appears "fully expanded".  Because of the large amount of
information, this makes it VERY user-unfriendly (obviously).  Please provide
a simple "button-click' method to control the level of expansion.  No, I
don't mean that you should provide some arcane path to some third-party
documentation tool that may or may not work for this problem, and that might
take so much effort to figure out that the hapless user forgets what his
original question was before he gets to the answer.  The way it IS serves as
a "weeder" to turn away those whom are less than truly obsessed.  Thanks,
and I hope you feel entertained.



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140715/b418ce72/attachment.html>

From Timmhay at hotmail.com  Mon Jul  7 03:13:47 2014
From: Timmhay at hotmail.com (Tim Elliott)
Date: Mon, 7 Jul 2014 11:13:47 +1000
Subject: [docs] Suggestion
Message-ID: <BLU404-EAS1538F93AACC125C9AD8E7D4A2F70@phx.gbl>

Is it possible to get the python documentation published in the Visual
studio help interface?

 

Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140707/8c9ae499/attachment.html>

From report at bugs.python.org  Wed Jul 16 16:56:18 2014
From: report at bugs.python.org (Andy Maier)
Date: Wed, 16 Jul 2014 14:56:18 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1405522575.88.0.513720779634.issue12067@psf.upfronthosting.co.za>


Andy Maier added the comment:

Uploaded v9 of the patch for 3.4 and default.

It reflects Marc's comment, plus the result of the recent discussion on python-dev since v8 of th epatch, up to 2014-07-15 (subject: == on object tests identity in 3.x).

-> Please review the patch.

----------
Added file: http://bugs.python.org/file35971/issue12067-expressions-py34_v9.diff

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

From report at bugs.python.org  Wed Jul 16 17:00:47 2014
From: report at bugs.python.org (Andy Maier)
Date: Wed, 16 Jul 2014 15:00:47 +0000
Subject: [docs] [issue11945] Adopt and document consistent semantics for
	handling NaN	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1405522847.97.0.69747127114.issue11945@psf.upfronthosting.co.za>


Changes by Andy Maier <andreas.r.maier at gmx.de>:


----------
nosy: +andymaier

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

From report at bugs.python.org  Wed Jul 16 17:38:34 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 15:38:34 +0000
Subject: [docs] [issue14149] argparse: Document how to use argument names
	that are	not Python identifiers
In-Reply-To: <1330431835.85.0.549489798388.issue14149@psf.upfronthosting.co.za>
Message-ID: <1405525114.43.0.131873587007.issue14149@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

#11076 was closed as a duplicate of #8982 which was closed as fixed so can this also be closed as a duplicate?

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

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

From report at bugs.python.org  Wed Jul 16 18:09:25 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 16 Jul 2014 16:09:25 +0000
Subject: [docs] [issue21989] Missing (optional) argument `start` and `end`
	in	documentation for list.index
In-Reply-To: <1405514419.16.0.727549411971.issue21989@psf.upfronthosting.co.za>
Message-ID: <1405526965.59.0.562813750562.issue21989@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 16 19:37:51 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 17:37:51 +0000
Subject: [docs] [issue10048] urllib.request documentation confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1405532270.96.0.428774102431.issue10048@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Senthil do you still intend to run with this or could somebody else pick it up?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 16 19:43:56 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 17:43:56 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405532636.92.0.388364453285.issue13540@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Paul what is your opinion of this documentation patch?

----------
nosy: +BreamoreBoy, paul.j3
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 16 19:51:15 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 17:51:15 +0000
Subject: [docs] [issue17057] Data model documentation grammar
In-Reply-To: <1359332657.03.0.048046509713.issue17057@psf.upfronthosting.co.za>
Message-ID: <1405533075.54.0.724475900847.issue17057@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm not particularly interested in 2.7 documentation but is there anybody out there who could review this please.

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

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

From report at bugs.python.org  Wed Jul 16 20:22:34 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 18:22:34 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1405534954.68.0.697889415301.issue16509@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Daniel could you provide a patch for this?

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

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

From report at bugs.python.org  Wed Jul 16 20:48:44 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 18:48:44 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1405536524.02.0.799181567756.issue13850@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

At a quick glance the patch looks okay to me so as there's been a lot of positive comments can we have a formal patch review please.

----------
nosy: +BreamoreBoy
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 16 20:53:55 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 18:53:55 +0000
Subject: [docs] [issue17243] The changes made for issue 4074 should be
	documented
In-Reply-To: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>
Message-ID: <1405536835.31.0.873285593063.issue17243@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Presumably the responsibility for this lies with the person who made the changes for #4074 ?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 16 21:44:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 19:44:04 +0000
Subject: [docs] [issue17924] Deprecate stat.S_IF* integer constants
In-Reply-To: <1367928320.73.0.37418131168.issue17924@psf.upfronthosting.co.za>
Message-ID: <1405539844.81.0.922535623241.issue17924@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Should this have the same nosy list as #11016 ?

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

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

From brandonpassmore at gmail.com  Wed Jul 16 21:43:44 2014
From: brandonpassmore at gmail.com (Brandon Passmore)
Date: Wed, 16 Jul 2014 15:43:44 -0400
Subject: [docs] small typo
Message-ID: <CAKEr2AjCfkv3rRNAM9gv_t0HKHo+cH6hUbf6=nfYqc_k_fMM7g@mail.gmail.com>

Hello,
     On https://docs.python.org/2/library/turtle.html there is a typo in
the .setup parameter's list.  The second startx should be starty.  Thanks
for the great pages.

Thanks,
     Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140716/288ed924/attachment.html>

From zachary.ware+pydocs at gmail.com  Wed Jul 16 21:49:52 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 16 Jul 2014 14:49:52 -0500
Subject: [docs] small typo
In-Reply-To: <CAKEr2AjCfkv3rRNAM9gv_t0HKHo+cH6hUbf6=nfYqc_k_fMM7g@mail.gmail.com>
References: <CAKEr2AjCfkv3rRNAM9gv_t0HKHo+cH6hUbf6=nfYqc_k_fMM7g@mail.gmail.com>
Message-ID: <CAKJDb-N1y2WbLe2gzUop+-zAjY2qKMTnJ8XraE2BqPa-9XwMJQ@mail.gmail.com>

Hi Brandon,

On Wed, Jul 16, 2014 at 2:43 PM, Brandon Passmore
<brandonpassmore at gmail.com> wrote:
> Hello,
>      On https://docs.python.org/2/library/turtle.html there is a typo in the
> .setup parameter's list.  The second startx should be starty.  Thanks for
> the great pages.

Thanks for the report!  This has now been fixed and should be live soon.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Wed Jul 16 22:05:23 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 16 Jul 2014 15:05:23 -0500
Subject: [docs] Interested in contributing to documentation
In-Reply-To: <COL125-W45354ECE03C0BD439882B3FA080@phx.gbl>
References: <COL125-W45354ECE03C0BD439882B3FA080@phx.gbl>
Message-ID: <CAKJDb-OVd5ByBc8i3UPVo1n5BjQq2cnfA2v7gHDexHEdDY16Pg@mail.gmail.com>

Hi Tammy,

On Sat, Jul 12, 2014 at 2:38 PM, Tammy Miller <tgmiller5 at hotmail.com> wrote:
> My name is Tammy and I am interested in contributing to documentation for
> Python.

Glad to hear that you're interested!  You can get started by taking a
look at the Reporting Bugs page[1] of the docs, which contains some
suggestions for how to get started, links to more resources, and in
particular a link to open documentation bugs on the Python bug
tracker.  Feel free to dive in wherever you feel comfortable, and
don't hesitate to ask questions.  You may be interested in the
core-mentorship mailing list (mentioned at the bottom of the page I
linked to) for quick help from friendly people, or you can use this
list for documentation issues (though there are significantly fewer
people actively listening here).

If there's anything that can be done to help you along the way, do let us know!

Welcome to Python, we hope you enjoy your stay :)

-- 
Zach

[1] http://docs.python.org/3/bugs.html

From report at bugs.python.org  Wed Jul 16 22:39:39 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 20:39:39 +0000
Subject: [docs] [issue14945] Setup & Usage documentation for selected stdlib
	modules
In-Reply-To: <1338256259.22.0.129056676976.issue14945@psf.upfronthosting.co.za>
Message-ID: <1405543179.17.0.484061578565.issue14945@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Where do we stand with this and #11260 ?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jul 16 22:39:55 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 20:39:55 +0000
Subject: [docs] [issue11260] smtpd-as-a-script feature should be documented
	and	should use argparse
In-Reply-To: <1298232231.08.0.088023732748.issue11260@psf.upfronthosting.co.za>
Message-ID: <1405543195.63.0.819442651327.issue11260@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Where do we stand with this and #14945 ?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.3

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

From report at bugs.python.org  Wed Jul 16 22:39:58 2014
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 16 Jul 2014 20:39:58 +0000
Subject: [docs] [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1405543198.84.0.500912721226.issue13850@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jul 16 22:42:47 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 20:42:47 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1405543367.03.0.919978071627.issue18355@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Raymond what is your opinion on this proposal?

----------
nosy: +BreamoreBoy
type:  -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Wed Jul 16 22:54:04 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 Jul 2014 20:54:04 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405544044.34.0.648322350706.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

That's interesting that there's activity on this again. I had forgotten I'd filed it. It's particularly timely, as I just yesterday had this experience again. I looked at the documentation and found it inadequate for me to understand how to implement a custom action, so I went to the source to figure it out. The action I ended up creating was this one:

class SandboxAction(argparse.Action):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, nargs=0, **kwargs)

    def __call__(self, *args, **kwargs):
        cls.use()

Where 'cls' is defined in the same scope where SandboxAction was defined. I'm not sure if my documentation patch would have been sufficient to allow me to write that Action without consulting the source, but this example represents another case where that should be possible.

I haven't made any tweaks to the patch as a result of Steven's comments, so I probably could do that. I don't now when I'll have the time to do that, but I'll keep a tab to remind me to revisit the issue again.

----------

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

From report at bugs.python.org  Wed Jul 16 23:24:01 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 16 Jul 2014 21:24:01 +0000
Subject: [docs] [issue18392] Doc: PyObject_Malloc() is not documented
In-Reply-To: <1373156816.39.0.0842066311974.issue18392@psf.upfronthosting.co.za>
Message-ID: <1405545841.19.0.0706241609566.issue18392@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Any volunteers to document what appears to be a relatively obscure function :)

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Thu Jul 17 00:46:59 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Wed, 16 Jul 2014 22:46:59 +0000
Subject: [docs] [issue21994] Syntax error in the ssl module documentation
Message-ID: <1405550819.52.0.585557894887.issue21994@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

This can be seen at https://docs.python.org/3.4/library/ssl.html#ssl.SSLContext.check_hostname

It looks like the colon should be omitted, and the next line un-indented.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 223291
nosy: alex, christian.heimes, docs at python, dstufft, giampaolo.rodola, janssen, pitrou
priority: normal
severity: normal
status: open
title: Syntax error in the ssl module documentation
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 17 00:47:30 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 16 Jul 2014 22:47:30 +0000
Subject: [docs] [issue21995] Idle: pseudofiles have no buffer attribute.
Message-ID: <1405550850.77.0.279876996055.issue21995@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

sys.stdin on 3.4.1 is also 'missing' (among public names) 'line_buffering' (True) and 'mode' ('r'). It seems that these could be trivially added, so the focus of this issue is 'buffer'. The associated 
.detach method is a no-op, (It is also a bit dangerous for interactive operation.)

3.4.1 Console interpreter:
>>> import sys; b = sys.stdin.buffer.readline()
a line
>>> b
b'a line\r\n'

3.4.1 Idle:
>>> import sys; b = sys.stdin.buffer.readline()
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    import sys; b = sys.stdin.buffer.readline()
AttributeError: 'PseudoInputFile' object has no attribute 'buffer'

https://docs.python.org/3/library/sys.html#sys.stdin
presents the idiom. It also warns (too narrowly -- 'if you are writing a library ...') that it might not.

As far as I could find, the Idle doc does not mention the standard streams, let alone Idle specific limitations.

I intentionally wrote the title as a statement of a problematical situation, rather than as a proposed solution, as there are two: change code and change doc.

Code: add .buffer as a bytes-oriented Pseudofile.

Doc: at least mention that standard streams are replaced by objects that ship text between processes, and use gui for input and display, and the consiquences of this.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 223292
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Idle: pseudofiles have no buffer attribute.
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 17 02:26:28 2014
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 17 Jul 2014 00:26:28 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1405556787.93.0.0665483615049.issue16509@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

The module docs do mention "Older SQLite versions had issues with sharing connections between threads." Presumably that means that sharing the connection between threads is safe so long as you're not using 'older versions', but it would be nice to have some more clarity about how old those versions are.

----------

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

From report at bugs.python.org  Thu Jul 17 02:29:03 2014
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 17 Jul 2014 00:29:03 +0000
Subject: [docs] [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1405556943.56.0.861631064406.issue16509@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

This page also looks relevant: sqlite can be compiled or used in three different threading modes. Presumably Python compiles/initialises it in the serialised mode, which makes it safe to use a connection from different threads.

http://www.sqlite.org/threadsafe.html

----------

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

From report at bugs.python.org  Thu Jul 17 04:01:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 17 Jul 2014 02:01:46 +0000
Subject: [docs] [issue21994] Syntax error in the ssl module documentation
In-Reply-To: <1405550819.52.0.585557894887.issue21994@psf.upfronthosting.co.za>
Message-ID: <3hDJc960cqz7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset 0045eec1e247 by Berker Peksag in branch '3.4':
Issue #21994: Fix SyntaxError in the SSLContext.check_hostname documentation.
http://hg.python.org/cpython/rev/0045eec1e247

New changeset 8039a20b18cc by Berker Peksag in branch 'default':
Issue #21994: Merge with 3.4.
http://hg.python.org/cpython/rev/8039a20b18cc

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

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

From report at bugs.python.org  Thu Jul 17 04:03:15 2014
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 17 Jul 2014 02:03:15 +0000
Subject: [docs] [issue21994] Syntax error in the ssl module documentation
In-Reply-To: <1405550819.52.0.585557894887.issue21994@psf.upfronthosting.co.za>
Message-ID: <1405562595.02.0.440054173536.issue21994@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Fixed. Thanks for the report.

----------
assignee: docs at python -> berker.peksag
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Jul 17 04:56:08 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Jul 2014 02:56:08 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1405565768.49.0.167115185347.issue18355@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll translate it into a How-to guide when I get a chance.  Right now, the content is in great shape, but the tone is somewhat "blog-posty".  For now, the external link will have to suffice.

----------
priority: normal -> low

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

From report at bugs.python.org  Thu Jul 17 04:56:20 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Jul 2014 02:56:20 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1405565780.8.0.712637162739.issue18355@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 17 10:34:54 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 17 Jul 2014 08:34:54 +0000
Subject: [docs] [issue17243] The changes made for issue 4074 should be
	documented
In-Reply-To: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>
Message-ID: <1405586094.57.0.721528386355.issue17243@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

No. There is no "responsibility" to do anything in an open source project.

----------
nosy: +loewis

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

From report at bugs.python.org  Thu Jul 17 10:54:41 2014
From: report at bugs.python.org (Carol Willing)
Date: Thu, 17 Jul 2014 08:54:41 +0000
Subject: [docs] [issue18392] Doc: PyObject_Malloc() is not documented
In-Reply-To: <1373156816.39.0.0842066311974.issue18392@psf.upfronthosting.co.za>
Message-ID: <1405587281.5.0.540705008638.issue18392@psf.upfronthosting.co.za>


Carol Willing added the comment:

Looks as if there is a patch for this on Issue 20064. http://bugs.python.org/issue20064

----------
nosy: +willingc

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

From report at bugs.python.org  Thu Jul 17 12:50:07 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 17 Jul 2014 10:50:07 +0000
Subject: [docs] [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1405594207.11.0.574759216059.issue20064@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

As the patch is short can we have a commit review please.  Can we also close issue 18392 as a duplicate of this.

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

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

From report at bugs.python.org  Thu Jul 17 14:08:39 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 17 Jul 2014 12:08:39 +0000
Subject: [docs] [issue15629] Add to regrtest the ability to run Lib and Doc
	doctests
In-Reply-To: <1344779660.84.0.741331364071.issue15629@psf.upfronthosting.co.za>
Message-ID: <1405598919.7.0.148482156646.issue15629@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

It appears, especially from the later messages, that this is not wanted.  However noting msg170616 should we close this with #10967 to supersede it?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Thu Jul 17 20:38:32 2014
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 17 Jul 2014 18:38:32 +0000
Subject: [docs] [issue22000] cross type comparisons clarification
Message-ID: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>


New submission from Jim Jewett:

https://docs.python.org/3.5/library/stdtypes.html
says "Objects of different types, except different numeric types, never compare equal."  

Despite the location, this seems to strong a statement, because of subclasses and classes which define __eq__.

A first attempt at rewording:

Existing: """
Objects of different types, except different numeric types, never compare equal. Furthermore, some types (for example, function objects) support only a degenerate notion of comparison where any two objects of that type are unequal. The <, <=, > and >= operators will raise a TypeError exception when comparing a complex number with another built-in numeric type, when the objects are of different types that cannot be compared, or in other cases where there is no defined ordering.

Non-identical instances of a class normally compare as non-equal unless the class defines the __eq__() method.

Instances of a class cannot be ordered with respect to other instances of the same class, or other types of object, unless the class defines enough of the methods __lt__(), __le__(), __gt__(), and __ge__() (in general, __lt__() and __eq__() are sufficient, if you want the conventional meanings of the comparison operators).

The behavior of the is and is not operators cannot be customized; also they can be applied to any two objects and never raise an exception.

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

-->

"""
The is and is not operators can be applied to any pair of objects, and will never raise an exception.  They cannot be customized, as they refer to implementation details.  (For example, "abc" is "abc" may or may not be true.)

Other comparisons refer to an object's meaning, and therefore must be defined by the object's own class.  "abc" == "abc" is always True, because the str class defines equality that way.

The default implementation uses is (object identity) for equality and  raises a TypeError for the ordering comparisons.  Defining the __eq__ method allows different instances to be equivalent; also defining the __lt__ method allows them to be ordered in the normal way.  Some classes will also define __le__, __ne__, __ge__, and __gt__, either for efficiency or to provide unusual behavior.  

Except for numbers, instances of two different standard classes will be unequal, and will raise a TypeError when compared for ordering.

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

----------
assignee: docs at python
components: Documentation
messages: 223353
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: cross type comparisons clarification
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu Jul 17 21:39:21 2014
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 17 Jul 2014 19:39:21 +0000
Subject: [docs] [issue22001] containers "same" does not always mean "__eq__".
Message-ID: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za>


New submission from Jim Jewett:

https://docs.python.org/3.5/reference/expressions.html#not-in

Containers are permitted to (and generally do) read "same as" as "is or __eq__), which can be confusing -- particularly in the section defining __eq__.

Several suggested changes:

"""
The values float('NaN') and Decimal('NaN') are special. The are identical to themselves, x is x but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False.
"""
--> ("the" -> "they"; add a comma; add a final sentence) -->
"""
The values float('NaN') and Decimal('NaN') are special. They are identical to themselves, x is x, but are not equal to themselves, x != x. Additionally, comparing any value to a not-a-number value will return False. For example, both 3 < float('NaN') and float('NaN') < 3 will return False.  Note, however, that containers will normally implement item equality as "a is b or a==b", so that [f]==[f] and f in [f] may be true even when f!=f.
"""

also:

"""
Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, each element must compare equal and the two sequences must be of the same type and have the same length.
"""
--> (re-order; add the NaN workaround) -->
"""
Tuples and lists are compared lexicographically using comparison of corresponding elements. This means that to compare equal, two sequences must be of the same type and have the same length, and each pair of corresponding elements must be identical or compare equal.  (Sequences can assume that identical elements are equal, despite odd cases like float('NaN').)
"""

I *think* it is OK to leave that caveat out of the mapping case, because "have the same (key, value) pairs" would now refer to the above.

----------
assignee: docs at python
components: Documentation
messages: 223362
nosy: Jim.Jewett, docs at python
priority: normal
severity: normal
status: open
title: containers "same" does not always mean "__eq__".
type: enhancement

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

From report at bugs.python.org  Thu Jul 17 22:20:59 2014
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Thu, 17 Jul 2014 20:20:59 +0000
Subject: [docs] [issue12970] os.walk() consider some symlinks as dirs
	instead of	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1405628459.1.0.827845109344.issue12970@psf.upfronthosting.co.za>


Uwe Kleine-K?nig added the comment:

I like the function as it is documented, i.e. "filenames is a list of the names of the non-directory files in dirpath.". This includes all symlinks (in the followlinks=False cast at least).

I'd say not including symlinks to directories but symlinks to files is a magnitude more surprising than treating a symlink to a directory as a file. And if you consider this as a short comming of the documentation this isn't (IMHO) a subtlety. The (my?) intuition says: all entries of a root (apart from . and .. as documented) are included in either dirnames or filenames.

Yes, changing behaviour here might break some code, but this applies to all changes.

For some usecases it might be right to just skip over symlinks-to-dirs, but if it's not you have to opendir + read all root entries again in the loop to find all symlinks which effectively means reimplementing os.walk.

----------
nosy: +ukl

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

From report at bugs.python.org  Fri Jul 18 00:22:03 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 17 Jul 2014 22:22:03 +0000
Subject: [docs] [issue17210] documentation of PyUnicode_Format() states
	wrong	argument type requirements
In-Reply-To: <1360934426.3.0.547345278452.issue17210@psf.upfronthosting.co.za>
Message-ID: <1405635723.55.0.40103890791.issue17210@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Stefan could you provide a patch for this?

----------
nosy: +BreamoreBoy
versions: +Python 3.5 -Python 2.6, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 18 00:27:29 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 17 Jul 2014 22:27:29 +0000
Subject: [docs] [issue17286] Make subprocess handling text output
	with	universal_newlines more obious
In-Reply-To: <1361708455.88.0.426093416103.issue17286@psf.upfronthosting.co.za>
Message-ID: <1405636049.34.0.301492774278.issue17286@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Baptiste can you provide a patch for this?

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

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

From report at bugs.python.org  Fri Jul 18 05:33:15 2014
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 18 Jul 2014 03:33:15 +0000
Subject: [docs] [issue22001] containers "same" does not always mean "__eq__".
In-Reply-To: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za>
Message-ID: <20140718033203.GI9112@ando>


Steven D'Aprano added the comment:

On Thu, Jul 17, 2014 at 07:39:21PM +0000, Jim Jewett wrote:

> Note, however, that containers will normally implement item equality 
> as "a is b or a==b"

We can't say "will normally", since we don't know about the infinite 
number of possible container types that people might create. The most we 
can say is that *builtin* container types will [assuming that this is 
the intent] or that general containers *may*.

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

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

From report at bugs.python.org  Fri Jul 18 08:25:17 2014
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 18 Jul 2014 06:25:17 +0000
Subject: [docs] [issue22004] io documentation refers to newline as newlines
Message-ID: <1405664717.39.0.472140939197.issue22004@psf.upfronthosting.co.za>


New submission from Andrew Barnert:

In at least one place in the io module documentation (io.IOBase.readline), and in the corresponding docstring, the newline parameter to open (and io.open, and io.Foo.__init__) is referred to as "newlines":

> The line terminator is always b'\n' for binary files; for text files, 
> the newlines argument to open() can be used to select the line 
> terminator(s) recognized.

(The newline parameter is closely related to the newlines attribute of the TextIOWrapper that gets created by the open call, but they're not the same thing, and I think were named differently intentionally.)

----------
assignee: docs at python
components: Documentation
messages: 223398
nosy: abarnert, docs at python
priority: normal
severity: normal
status: open
title: io documentation refers to newline as newlines
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 18 08:28:19 2014
From: report at bugs.python.org (Andrew Barnert)
Date: Fri, 18 Jul 2014 06:28:19 +0000
Subject: [docs] [issue22004] io documentation refers to newline as newlines
In-Reply-To: <1405664717.39.0.472140939197.issue22004@psf.upfronthosting.co.za>
Message-ID: <1405664899.55.0.622933131228.issue22004@psf.upfronthosting.co.za>


Andrew Barnert added the comment:

Searching the source and the help page, it looks like the one example I gave is the only place it's wrong in each of the two, not one of multiple places.

----------

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

From report at bugs.python.org  Fri Jul 18 16:15:49 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 18 Jul 2014 14:15:49 +0000
Subject: [docs] [issue22004] io documentation refers to newline as newlines
In-Reply-To: <1405664717.39.0.472140939197.issue22004@psf.upfronthosting.co.za>
Message-ID: <3hFDrh5RNyz7LjQ@mail.python.org>


Roundup Robot added the comment:

New changeset 4c98086194d5 by Zachary Ware in branch '2.7':
Issue #22004: Correct an argument name.
http://hg.python.org/cpython/rev/4c98086194d5

New changeset 252cd056d1cf by Zachary Ware in branch '3.4':
Issue #22004: Correct an argument name.
http://hg.python.org/cpython/rev/252cd056d1cf

New changeset f83adc06f486 by Zachary Ware in branch 'default':
Closes #22004: Merge with 3.4
http://hg.python.org/cpython/rev/f83adc06f486

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

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

From report at bugs.python.org  Fri Jul 18 16:16:45 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 18 Jul 2014 14:16:45 +0000
Subject: [docs] [issue22004] io documentation refers to newline as newlines
In-Reply-To: <1405664717.39.0.472140939197.issue22004@psf.upfronthosting.co.za>
Message-ID: <1405693005.06.0.798737313063.issue22004@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed! Thanks for the report.

----------
nosy: +zach.ware
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 18 16:29:05 2014
From: report at bugs.python.org (David Halter)
Date: Fri, 18 Jul 2014 14:29:05 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1405693745.14.0.520643674509.issue12855@psf.upfronthosting.co.za>


David Halter added the comment:

I would vote for the inclusion of that patch. I just stumbled over this.

----------
nosy: +davidhalter

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

From willingc at willingconsulting.com  Fri Jul 18 19:42:01 2014
From: willingc at willingconsulting.com (willingc at willingconsulting.com)
Date: Fri, 18 Jul 2014 17:42:01 -0000
Subject: [docs] PyObject_Malloc is not documented (issue 20064)
Message-ID: <20140718174201.13614.37835@psf.upfronthosting.co.za>

+1 on this doc addition. The documentation of the function reflects the
actual source code definition of function PyObject_Malloc. Tests ran
cleanly, and make patchcheck was fine (with the exception of Misc/ACKS
and Misc/NEWS not updated).

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

From report at bugs.python.org  Fri Jul 18 20:21:38 2014
From: report at bugs.python.org (Carol Willing)
Date: Fri, 18 Jul 2014 18:21:38 +0000
Subject: [docs] [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1405707698.28.0.749258593338.issue20064@psf.upfronthosting.co.za>


Carol Willing added the comment:

I've reviewed this patch. It's my first patch review for this project so I'm not sure that I submitted the review correctly in Rietveld.

----------
nosy: +willingc

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

From report at bugs.python.org  Fri Jul 18 20:24:08 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 18 Jul 2014 18:24:08 +0000
Subject: [docs] [issue18392] Doc: PyObject_Malloc() is not documented
In-Reply-To: <1373156816.39.0.0842066311974.issue18392@psf.upfronthosting.co.za>
Message-ID: <1405707848.03.0.649414445093.issue18392@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> PyObject_Malloc is not documented

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

From report at bugs.python.org  Fri Jul 18 21:53:27 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Fri, 18 Jul 2014 19:53:27 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions release the GIL
Message-ID: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>


New submission from Dan O'Reilly:

Currently, the caveats section of the thread/_thread module has this statement in it:

"Not all built-in functions that may block waiting for I/O allow other threads to run. (The most popular ones (time.sleep(), file.read(), select.select()) work as expected.)"

As far as I know, this isn't the case; all built-in functions that do blocking I/O release the GIL, and therefore do indeed allow other threads to run.

I asked a question about this on stackoverflow recently (http://stackoverflow.com/q/24831458/2073595), and Mark Dickinson helpfully pointed out that this statement was added by Guido way back in 1994, which suggests it's probably just obsolete. If that's the case, the statement should be removed to avoid confusion.

----------
assignee: docs at python
components: Documentation
messages: 223428
nosy: dan.oreilly, docs at python
priority: normal
severity: normal
status: open
title: thread module documentation erroneously(?) states not all built-in functions release the GIL
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Jul 18 21:55:54 2014
From: report at bugs.python.org (Dan O'Reilly)
Date: Fri, 18 Jul 2014 19:55:54 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405713354.01.0.114344586539.issue22006@psf.upfronthosting.co.za>


Changes by Dan O'Reilly <oreilldf at gmail.com>:


----------
title: thread module documentation erroneously(?) states not all built-in functions release the GIL -> thread module documentation erroneously(?) states not all built-in functions that do blocking I/O release the GIL

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

From report at bugs.python.org  Fri Jul 18 22:00:49 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 18 Jul 2014 20:00:49 +0000
Subject: [docs] [issue17401] io.FileIO closefd parameter is not documented
	nor shown	in repr
In-Reply-To: <1363057927.36.0.00381165430664.issue17401@psf.upfronthosting.co.za>
Message-ID: <1405713649.52.0.291679990085.issue17401@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

>From the 3.5 docs.

io.open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None)
This is an alias for the builtin open() function.

There is a description for closefd at the open() function link.  So how about adding to the sentence above " where all the above parameters are described" ?

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

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

From report at bugs.python.org  Fri Jul 18 23:03:36 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 18 Jul 2014 21:03:36 +0000
Subject: [docs] [issue21989] Missing (optional) argument `start` and `end`
	in	documentation for list.index
In-Reply-To: <1405514419.16.0.727549411971.issue21989@psf.upfronthosting.co.za>
Message-ID: <1405717416.9.0.338680927634.issue21989@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's a tutorial, not API documentation.  You will note that the 'key' and 'reverse' arguments to sort are not mentioned either.

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

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

From report at bugs.python.org  Sat Jul 19 00:45:50 2014
From: report at bugs.python.org (A Kaptur)
Date: Fri, 18 Jul 2014 22:45:50 +0000
Subject: [docs] [issue22008] Symtable's syntax warning should contain the
	word	"because"
Message-ID: <1405723549.99.0.479599106625.issue22008@psf.upfronthosting.co.za>


New submission from A Kaptur:

The symbol table's syntax error about unqualified exec is missing the word "because".

>>> def foo():
...     exec "a = 1"
...     def bar():
...         print a
... 
  File "<stdin>", line 2
SyntaxError: unqualified exec is not allowed in function 'foo' it contains a nested function with free variables

----------
assignee: docs at python
components: Documentation
files: issue.patch
keywords: patch
messages: 223447
nosy: akaptur, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Symtable's syntax warning should contain the word "because"
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file35992/issue.patch

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

From report at bugs.python.org  Sat Jul 19 00:57:17 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 18 Jul 2014 22:57:17 +0000
Subject: [docs] [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1405724237.22.0.893559631265.issue11001@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Given the comments in msg126979 do we formally review this, close as "won't fix" or what?

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

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

From report at bugs.python.org  Sat Jul 19 03:24:45 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Jul 2014 01:24:45 +0000
Subject: [docs] [issue22001] containers "same" does not always mean "__eq__".
In-Reply-To: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za>
Message-ID: <1405733085.17.0.253041040133.issue22001@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 19 04:32:35 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jul 2014 02:32:35 +0000
Subject: [docs] [issue11001] Various obvious errors in cookies documentation
In-Reply-To: <1295908065.55.0.221906287574.issue11001@psf.upfronthosting.co.za>
Message-ID: <1405737155.72.0.204623729531.issue11001@psf.upfronthosting.co.za>


R. David Murray added the comment:

My suggestion was that the help text from the doc strings be used to update the ReST documentation.

----------

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

From report at bugs.python.org  Sat Jul 19 09:46:37 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jul 2014 07:46:37 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405755997.84.0.148819988481.issue22006@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

It seems likely that this information is just out of date.  But even if there *are* still built-in functions lurking somewhere that don't release the GIL during I/O, the statement in the docs isn't really helpful in finding them.  Either way, I'd recommend simply removing it.

Adding Guido to the nosy in case he can provide a pre-Python 1.0 historical perspective.

----------
nosy: +gvanrossum, mark.dickinson
versions:  -Python 3.1, Python 3.2

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

From report at bugs.python.org  Sat Jul 19 09:47:26 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jul 2014 07:47:26 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405756046.53.0.0429191705708.issue22006@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jul 19 16:46:40 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 19 Jul 2014 14:46:40 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405781200.02.0.284328485704.issue22006@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It all depends what you call "I/O". What is true is that not all functions doing system calls release the GIL, AFAIR. If you mean I/O as in actual disk or network I/O then yes, all such functions whould release the GIL.

That said, I agree that the statement isn't very helpful.

----------
nosy: +pitrou

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

From report at bugs.python.org  Sat Jul 19 21:53:06 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Jul 2014 19:53:06 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405799586.37.0.833786730348.issue22006@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Not in my wildest dreams could I have expected that that claim would still be in the docs 20 years later. :-)  Please get rid of it.

----------

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

From report at bugs.python.org  Sat Jul 19 22:38:51 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 19 Jul 2014 20:38:51 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
In-Reply-To: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>
Message-ID: <1405802331.84.0.872433825573.issue17709@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I don't understand this at all, but if this is a Sphinx bug shouldn't it be reported on the appropriate bug tracker and not here?

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

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

From report at bugs.python.org  Sat Jul 19 22:46:09 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jul 2014 20:46:09 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <3hG1Sc63rQz7LrY@mail.python.org>


Roundup Robot added the comment:

New changeset 855ff9182a07 by Mark Dickinson in branch '3.4':
Issue #22006: Remove outdated _thread caveat.  Thanks Dan O'Reilly for the report.
http://hg.python.org/cpython/rev/855ff9182a07

New changeset 3b6b905ae229 by Mark Dickinson in branch 'default':
Issue #22006: Merge from 3.4.
http://hg.python.org/cpython/rev/3b6b905ae229

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

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

From report at bugs.python.org  Sat Jul 19 22:47:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jul 2014 20:47:35 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <3hG1VG6Rs9z7LrV@mail.python.org>


Roundup Robot added the comment:

New changeset 4f359c631bb0 by Mark Dickinson in branch '2.7':
Issue #22006: Remove outdated thread module caveat.  Thanks Dan O'Reilly for the report.
http://hg.python.org/cpython/rev/4f359c631bb0

----------

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

From report at bugs.python.org  Sat Jul 19 22:48:49 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 19 Jul 2014 20:48:49 +0000
Subject: [docs] [issue22006] thread module documentation erroneously(?)
	states not	all built-in functions that do blocking I/O
	release the GIL
In-Reply-To: <1405713207.82.0.735431960595.issue22006@psf.upfronthosting.co.za>
Message-ID: <1405802929.16.0.878633179332.issue22006@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

It's gone.

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

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

From report at bugs.python.org  Sat Jul 19 23:06:45 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 19 Jul 2014 21:06:45 +0000
Subject: [docs] [issue21996] gettarinfo method does not handle files without
	text	string names
In-Reply-To: <1405583528.37.0.553699872308.issue21996@psf.upfronthosting.co.za>
Message-ID: <1405804005.86.0.819525959087.issue21996@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agreed, the documentation should be modified to say "(using os.fstat on its file descriptor, and its 'name' attribute if arcname is not specified").

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Sun Jul 20 01:35:32 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 19 Jul 2014 23:35:32 +0000
Subject: [docs] [issue17210] documentation of PyUnicode_Format() states
	wrong	argument type requirements
In-Reply-To: <1360934426.3.0.547345278452.issue17210@psf.upfronthosting.co.za>
Message-ID: <3hG5D32Dmqz7LkH@mail.python.org>


Roundup Robot added the comment:

New changeset 9cd3ab7c09d1 by Benjamin Peterson in branch '2.7':
args doesn't need to be a tuple (closes #17210)
http://hg.python.org/cpython/rev/9cd3ab7c09d1

New changeset ffbbd43d7342 by Benjamin Peterson in branch '3.4':
args doesn't need to be a tuple (closes #17210)
http://hg.python.org/cpython/rev/ffbbd43d7342

New changeset 2fc379ce5762 by Benjamin Peterson in branch 'default':
merge 3.4 (#17210)
http://hg.python.org/cpython/rev/2fc379ce5762

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

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

From report at bugs.python.org  Sun Jul 20 09:00:24 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Jul 2014 07:00:24 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
Message-ID: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

It would be handy if the main OS exception docs at https://docs.python.org/3/library/exceptions.html#os-exceptions included a summary table mapping between exception types and errno names, akin to the one in the original PEP (http://www.python.org/dev/peps/pep-3151/#new-exception-classes)

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 223499
nosy: docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Add summary table for OS exception <-> errno mapping
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jul 20 09:02:45 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 20 Jul 2014 07:02:45 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1405839765.61.0.960996785371.issue22014@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Another idea would be to include fragments of the ASCII art hierarchy throughout the doc, but that's trickier than it sounds, since we just use literalinclude to generate the current one.

----------

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

From report at bugs.python.org  Sun Jul 20 17:00:25 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Jul 2014 15:00:25 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405868424.16.0.722553206884.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file36001/9ac347a7f375.diff

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

From report at bugs.python.org  Sun Jul 20 17:22:27 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Jul 2014 15:22:27 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405869747.49.0.209306816934.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Added file: http://bugs.python.org/file36003/b8c09b766e20.diff

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

From report at bugs.python.org  Sun Jul 20 17:27:11 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Jul 2014 15:27:11 +0000
Subject: [docs] [issue22000] cross type comparisons clarification
In-Reply-To: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>
Message-ID: <1405870031.66.0.840559957923.issue22000@psf.upfronthosting.co.za>


R. David Murray added the comment:

'type' and 'class' are two different names for the same concept in python3, so this paragraph simply appears to be out of date and indeed in need of complete rewording.

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

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

From report at bugs.python.org  Sun Jul 20 17:29:00 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Jul 2014 15:29:00 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405870140.36.0.28429619964.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've made another commit to capture Steven's recommendations. I've also merged the work with the latest 2.7 tip, the result of which is the latest diff. I'll commit this in a week or two if there aren't any objections, though I would appreciate a review and especially any suggestions on how I might test the correctness of the syntax.

----------

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

From report at bugs.python.org  Sun Jul 20 17:33:41 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 20 Jul 2014 15:33:41 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405870421.56.0.781577332553.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've tried building the docs, but it appears to rely on a local build of Python as well as subversion, neither of which my system can do currently, so I'm hoping someone has a suitable environment to help test the building of the docs.

----------

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

From report at bugs.python.org  Sun Jul 20 17:34:07 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 20 Jul 2014 15:34:07 +0000
Subject: [docs] [issue22001] containers "same" does not always mean "__eq__".
In-Reply-To: <1405625961.78.0.30088981548.issue22001@psf.upfronthosting.co.za>
Message-ID: <1405870447.13.0.975356540008.issue22001@psf.upfronthosting.co.za>


R. David Murray added the comment:

"must be identical" sounds like "identical twins".  I think what you mean is "must be references to the same object or to objects that compare equal".  If you don't want to get into the concept of 'references' here, I suppose it could read "must be the same object or objects that compare equal".  What I'm saying is that "same object" is stronger than "identical"..."identical" is much closer to "equal" in English.

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

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

From report at bugs.python.org  Sun Jul 20 18:57:58 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 20 Jul 2014 16:57:58 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1405875478.66.0.288379245632.issue13540@psf.upfronthosting.co.za>


paul j3 added the comment:

I think you want to unlink 9ac347a7f375.diff 

It's from a different project

----------

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

From report at bugs.python.org  Mon Jul 21 01:30:53 2014
From: report at bugs.python.org (Jim Jewett)
Date: Sun, 20 Jul 2014 23:30:53 +0000
Subject: [docs] [issue22001] containers "same" does not always mean "__eq__".
In-Reply-To: <1405870447.13.0.975356540008.issue22001@psf.upfronthosting.co.za>
Message-ID: <CA+OGgf7-FO2KYUxHvyALZ9RKae28=Z-jwHkk0po1e75eCga6vQ@mail.gmail.com>


Jim Jewett added the comment:

Ah... "be the same object or compare equal" sounds much better.

I don't want "same" to sound like an informal  wording for equal,  because
getting rid of the confusion over NaN and similar objects is the whole
point of the revision.  On the other hand, I don't want the language spec
to imply that a more careful custom container is non-conforming.

----------

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

From report at bugs.python.org  Mon Jul 21 06:38:02 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Jul 2014 04:38:02 +0000
Subject: [docs] [issue11945] Adopt and document consistent semantics for
	handling NaN	values in containers
In-Reply-To: <1303962145.0.0.00759154980454.issue11945@psf.upfronthosting.co.za>
Message-ID: <1405917481.77.0.310428821724.issue11945@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Closing for the reasons listed and also because there is another pair of tracker items 22000 and 22001 pursuing related documentation updates.

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

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

From report at bugs.python.org  Mon Jul 21 08:20:27 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 21 Jul 2014 06:20:27 +0000
Subject: [docs] [issue22020] tutorial 9.10. Generators statement error
In-Reply-To: <1405922600.06.0.736556450587.issue22020@psf.upfronthosting.co.za>
Message-ID: <1405923627.29.0.826672186786.issue22020@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

The "reverse" function is defined just above the example that uses it.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> behavior

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

From report at bugs.python.org  Mon Jul 21 13:04:26 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 21 Jul 2014 11:04:26 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1405940666.06.0.0133345896307.issue22021@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe this is working as designed, although the documentation does not make that clear.  root dir is the root directory of the *created archive*, it has nothing to do with where the archive file itself is placed.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray

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

From zachary.ware at gmail.com  Mon Jul 21 19:24:56 2014
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Mon, 21 Jul 2014 17:24:56 -0000
Subject: [docs] PyObject_Malloc is not documented (issue 20064)
Message-ID: <20140721172456.8358.55466@psf.upfronthosting.co.za>


http://bugs.python.org/review/20064/diff/10412/Doc/c-api/memory.rst
File Doc/c-api/memory.rst (right):

http://bugs.python.org/review/20064/diff/10412/Doc/c-api/memory.rst#newcode326
Doc/c-api/memory.rst:326: .. c:function:: void* PyObject_Malloc(size_t
n)
I'm not sure this is the right section for this function, this section
is about customizing the PyObject Arena Allocator.  I think it would be
better to add a new section for PyObject_(Malloc|Realloc|Free) just
under the "Memory Interface" section, and probably steal most of the
first paragraph of this section to head the new one.

http://bugs.python.org/review/20064/diff/10412/Doc/c-api/memory.rst#newcode328
Doc/c-api/memory.rst:328: if *n* is less than 512, allocates *n* bytes
with *pymalloc* allocator and
"if" should be capitalized.

http://bugs.python.org/review/20064/diff/10412/Doc/c-api/memory.rst#newcode331
Doc/c-api/memory.rst:331: Falls back to :c:func:`PyMem_RawMalloc` for
allocations larger than 512 bytes.
If this sentence is meant to be part of the same paragraph, it should
continue the previous line.  If it is meant to be separate, there should
be a blank line before it.  The way this is, Sphinx considers it to be
part of the previous paragraph.

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

From report at bugs.python.org  Mon Jul 21 19:27:14 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 21 Jul 2014 17:27:14 +0000
Subject: [docs] [issue20064] PyObject_Malloc is not documented
In-Reply-To: <1387913960.58.0.680621486861.issue20064@psf.upfronthosting.co.za>
Message-ID: <1405963634.56.0.272164758447.issue20064@psf.upfronthosting.co.za>


Zachary Ware added the comment:

It appears that PyObject_Realloc and PyObject_Free are also not documented; they should be along with PyObject_Malloc.

I also left a couple of comments on Rietveld.

----------
nosy: +zach.ware
stage: needs patch -> patch review
versions: +Python 3.5 -Python 3.3

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

From brandonkvaughan at gmail.com  Sun Jul 20 01:04:13 2014
From: brandonkvaughan at gmail.com (Brandon Vaughan)
Date: Sat, 19 Jul 2014 16:04:13 -0700
Subject: [docs] Problem searching local HTML python docs in Chrome
Message-ID: <CAM09NUUsPXtEFEEOgO65HuuhHZdMpWVTai_q-9c_nU01=QYqvw@mail.gmail.com>

Hello,

Is the inability to search local HTML python docs with Chrome a known
issue? Although I am able to navigate the help docs just fine, the search
function just seems to spin its wheels forever (see pic). I'm assuming this
is an issue with Chrome because the search function works perfectly in
Firefox. Can anyone provide any help getting this to work on Chrome?


?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140719/78e27355/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-07-19 at 3.34.27 PM.png
Type: image/png
Size: 36259 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20140719/78e27355/attachment-0001.png>

From report at bugs.python.org  Mon Jul 21 22:12:55 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 21 Jul 2014 20:12:55 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1405973575.59.0.495962429348.issue12855@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> patch review
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 22 04:06:16 2014
From: report at bugs.python.org (Weinan Li)
Date: Tue, 22 Jul 2014 02:06:16 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1405994776.49.0.170134505156.issue22021@psf.upfronthosting.co.za>


Weinan Li added the comment:

I don't think so.

In source code, it just change work dir to root_dir, do nothing, and then the change word dir back.

If it works as design, the "root_dir" will be meaningless. should be remove.

----------

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

From report at bugs.python.org  Tue Jul 22 05:14:20 2014
From: report at bugs.python.org (Weinan Li)
Date: Tue, 22 Jul 2014 03:14:20 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1405998860.08.0.211855538666.issue22021@psf.upfronthosting.co.za>


Weinan Li added the comment:

Here's the path

----------
keywords: +patch
Added file: http://bugs.python.org/file36022/Issue22021.patch

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

From report at bugs.python.org  Tue Jul 22 06:27:15 2014
From: report at bugs.python.org (Martin Panter)
Date: Tue, 22 Jul 2014 04:27:15 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1406003235.18.0.850434655042.issue22021@psf.upfronthosting.co.za>


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


----------
nosy: +vadmium

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

From report at bugs.python.org  Tue Jul 22 10:05:55 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 22 Jul 2014 08:05:55 +0000
Subject: [docs] [issue15759] "make suspicious" doesn't display instructions
	in case	of failure
In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>
Message-ID: <3hHXS22cCXz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 10b83036c723 by Serhiy Storchaka in branch '3.4':
Issue #15759: "make suspicious", "make linkcheck" and "make doctest" in Doc/
http://hg.python.org/cpython/rev/10b83036c723

New changeset c755a3b58fa6 by Serhiy Storchaka in branch 'default':
Issue #15759: "make suspicious", "make linkcheck" and "make doctest" in Doc/
http://hg.python.org/cpython/rev/c755a3b58fa6

New changeset a61c3d17fe4f by Serhiy Storchaka in branch '2.7':
Issue #15759: "make suspicious", "make linkcheck" and "make doctest" in Doc/
http://hg.python.org/cpython/rev/a61c3d17fe4f

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

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

From report at bugs.python.org  Tue Jul 22 10:36:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 08:36:49 +0000
Subject: [docs] [issue15759] "make suspicious" doesn't display instructions
	in case	of failure
In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>
Message-ID: <1406018209.11.0.0145161501057.issue15759@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Jul 22 14:11:03 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 22 Jul 2014 12:11:03 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1406031063.59.0.208497881677.issue22021@psf.upfronthosting.co.za>


R. David Murray added the comment:

The point *should* be that if you have something like:

   /home/me/some/directory/my/stuff/a
   /home/me/some/directory/my/stuff/b
   /home/me/some/other/directory

and you set rootdir to '/home/me/some' and base_dir='/home/me/some/directory/my' then the file paths in the archive will be:

    directory/my/stuff/a
    directory/my/stuff/b

At least, that's how I read the docs, though as I said they are *not* clear.  (I can't otherwise imagine any reason to have the root_dir parameter, with that name.)

Is this not what happens?

----------

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

From report at bugs.python.org  Tue Jul 22 18:51:51 2014
From: report at bugs.python.org (Aaron Hill)
Date: Tue, 22 Jul 2014 16:51:51 +0000
Subject: [docs] [issue22037] Poor grammar in asyncio TCP echo client example
Message-ID: <1406047911.63.0.907095249067.issue22037@psf.upfronthosting.co.za>


New submission from Aaron Hill:

The last sentence in the explanation of the TCP echo client currently reads: 

"At run_until_complete() exit, the loop is no more running, so there is no need to stop the loop in case of an error".

The grammar should be improved to something like "...the loop is no longer running", or "...the loop has stopped running"

The current documentation can be found here: https://docs.python.org/3/library/asyncio-protocol.html#echo-client

----------
assignee: docs at python
components: Documentation
messages: 223673
nosy: Aaron1011, docs at python
priority: normal
severity: normal
status: open
title: Poor grammar in asyncio TCP echo client example

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

From report at bugs.python.org  Tue Jul 22 19:56:30 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 22 Jul 2014 17:56:30 +0000
Subject: [docs] [issue22039] PyObject_SetAttr doesn't mention value = NULL
Message-ID: <1406051790.64.0.0676928180206.issue22039@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

PyObject_SetAttr, when called with value == NULL, actually deletes the attribute, but the documentation doesn't say it. It mentions PyObject_DelAttr, but it is only a macro and can therefore not be looked up using e.g. ctypes.

----------
assignee: docs at python
components: Documentation
messages: 223678
nosy: docs at python, pitrou
priority: normal
severity: normal
status: open
title: PyObject_SetAttr doesn't mention value = NULL
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From Scott.Hinton at Honeywell.com  Tue Jul 22 18:01:32 2014
From: Scott.Hinton at Honeywell.com (Hinton, Scott (ESEA Space))
Date: Tue, 22 Jul 2014 16:01:32 +0000
Subject: [docs] minor docs typo
Message-ID: <63EC325C5190FF4CBC44EB63354C987E22614A2A@az18ex3002.global.ds.honeywell.com>

Hello,

I found a minor typo near the end of this paragraph:
https://docs.python.org/2.7/library/functions.html?highlight=round#round

Inside the last parenthetical phrase it says
(so. for example,

I would venture to guess that we don't want the period after the "so".  Maybe a comma, maybe nothing, but probably not a period.

Enjoy,
Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140722/6d67c89b/attachment.html>

From zachary.ware+pydocs at gmail.com  Tue Jul 22 20:18:33 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 22 Jul 2014 13:18:33 -0500
Subject: [docs] minor docs typo
In-Reply-To: <63EC325C5190FF4CBC44EB63354C987E22614A2A@az18ex3002.global.ds.honeywell.com>
References: <63EC325C5190FF4CBC44EB63354C987E22614A2A@az18ex3002.global.ds.honeywell.com>
Message-ID: <CAKJDb-Nz8WByRi=61zd4eS0QRSFGE9_6L-PRR59CsbJn4kKqsA@mail.gmail.com>

Hi Scott,

On Tue, Jul 22, 2014 at 11:01 AM, Hinton, Scott (ESEA Space)
<Scott.Hinton at honeywell.com> wrote:
> Hello,
>
> I found a minor typo near the end of this paragraph:
> https://docs.python.org/2.7/library/functions.html?highlight=round#round
>
> Inside the last parenthetical phrase it says
> (so. for example,
>
> I would venture to guess that we don?t want the period after the ?so?.
> Maybe a comma, maybe nothing, but probably not a period.

Thanks for the report!  This has been fixed and will be live soon.

-- 
Zach

From report at bugs.python.org  Tue Jul 22 22:52:32 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Jul 2014 20:52:32 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <1406062352.93.0.477287421746.issue21860@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jul 23 10:29:25 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Jul 2014 08:29:25 +0000
Subject: [docs] [issue22037] Poor grammar in asyncio TCP echo client example
In-Reply-To: <1406047911.63.0.907095249067.issue22037@psf.upfronthosting.co.za>
Message-ID: <1406104165.53.0.121559648784.issue22037@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Fixed in d19c58e13ac9
Thanks

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 23 10:41:47 2014
From: report at bugs.python.org (Chris Rebert)
Date: Wed, 23 Jul 2014 08:41:47 +0000
Subject: [docs] [issue18355] Merge super() guide into documentation
In-Reply-To: <1372901200.41.0.725969821731.issue18355@psf.upfronthosting.co.za>
Message-ID: <1406104907.32.0.596662280762.issue18355@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Wed Jul 23 10:50:26 2014
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Jul 2014 08:50:26 +0000
Subject: [docs] [issue22037] Poor grammar in asyncio TCP echo client example
In-Reply-To: <1406047911.63.0.907095249067.issue22037@psf.upfronthosting.co.za>
Message-ID: <1406105426.76.0.86754800324.issue22037@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks for the patch Aaron. I wrote the documentation and I'm not a native english speaker. Please don't hesitate to report other grammar issues like that. You may group all of them in a single issue.

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

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

From report at bugs.python.org  Wed Jul 23 12:11:30 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Jul 2014 10:11:30 +0000
Subject: [docs] [issue17709] http://docs.python.org/2.7/objects.inv doesn't
	support	:func:`repr` or :exc:`Exception`
In-Reply-To: <1365837524.98.0.624427340429.issue17709@psf.upfronthosting.co.za>
Message-ID: <1406110290.61.0.854150025397.issue17709@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Cannot reproduce.

----------
nosy: +asvetlov
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Jul 23 14:20:23 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 23 Jul 2014 12:20:23 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
Message-ID: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>


New submission from Jason Heeris:

As per issue 5701, the zipfile.ZipFile.read() method will throw a NotImplementedError if the compression scheme is not supported. However, there is no mention of this possibility in the documentation for the read() method. I would suggest, say, "Calling read() on a ZipFile that uses an unsupported compression scheme (eg. implode) will raise a NotImplementedError."

It looks like you can use the testzip() method to check that this won't happen (ie. after you open the file but before you extract an entry). If that is really the expected way to check for this kind of condition, it would be nice to mention that too (under either method).

----------
assignee: docs at python
components: Documentation
messages: 223737
nosy: detly, docs at python
priority: normal
severity: normal
status: open
title: ZipFile.read() should mention that it might throw NotImplementedError
type: enhancement
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Wed Jul 23 17:23:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Jul 2014 15:23:09 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406128989.6.0.771922611599.issue21580@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jul 23 20:20:10 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jul 2014 18:20:10 +0000
Subject: [docs] [issue22049] argparse: type=<callable> doesn't honor nargs >
	1
In-Reply-To: <1406135782.37.0.476079892774.issue22049@psf.upfronthosting.co.za>
Message-ID: <1406139610.06.0.792865478723.issue22049@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nope.  The documentation says:

    N (an integer). N arguments from the command line will be gathered together into a list

The type function is applied to each argument independently.  It would be easy enough to make this explicit in one of the nargs multi-argument examples by using type as well.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Jul 23 23:03:30 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Jul 2014 21:03:30 +0000
Subject: [docs] [issue22052] Comparison operators called in reverse order
	for	subclasses with no override.
Message-ID: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

As reported in a StackOverflow question [1]: the order in which the special comparison methods are called seems to be contradictory to the docs [2].  In the following snippet, __eq__ is called with reversed operands first:

>>> class A:
...     def __eq__(self, other):
...         print(type(self), type(other))
...         return True
... 
>>> class B(A):
...     pass
... 
>>> A() == B()
<class '__main__.B'> <class '__main__.A'>
True

However, the docs note that:

"""If the right operand?s type is a subclass of the left operand?s type and that subclass provides the reflected method for the operation, this method will be called before the left operand?s non-reflected method. This behavior allows subclasses to override their ancestors? operations."""

... which suggests that this reversal should only happen when the subclass B *overrides* A's definition of __eq__ (and indeed that's the usual behaviour for arithmetic operations like __add__).

Looking more closely, that statement in the docs is in the 'numeric-types' section, so it's not clear that its rules should apply to the comparison operators.  But either way, some doc clarification could be useful.


[1] http://stackoverflow.com/q/24919375/270986
[2] https://docs.python.org/3.5/reference/datamodel.html#emulating-numeric-types

----------
assignee: docs at python
components: Documentation
messages: 223778
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Comparison operators called in reverse order for subclasses with no override.
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 24 00:22:09 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 23 Jul 2014 22:22:09 +0000
Subject: [docs] [issue22052] Comparison operators called in reverse order
	for	subclasses with no override.
In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
Message-ID: <1406154128.99.0.306387445256.issue22052@psf.upfronthosting.co.za>


R. David Murray added the comment:

"the subclass provides" doesn't actually imply anything about overriding, I think.  For __eq__, though, that means that *every* class "provides" it.  Indeed, I've always thought of the rule as "the subclass goes first" with no qualification, but that's only true for __eq__.

It looks like the "subclass goes first" note is missing from the __eq__ section.

But see issue 21408.  I find it hard to reason about this algorithm, so I could be completely wrong :)

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

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

From Scott.Hinton at Honeywell.com  Wed Jul 23 23:55:46 2014
From: Scott.Hinton at Honeywell.com (Hinton, Scott (ESEA Space))
Date: Wed, 23 Jul 2014 21:55:46 +0000
Subject: [docs] minor grammar error
Message-ID: <63EC325C5190FF4CBC44EB63354C987E22614B8F@az18ex3002.global.ds.honeywell.com>

Hello,

I was reading through the Python tutorial and found a minor grammatical error near the end of the section on raising exceptions
(https://docs.python.org/2.7/tutorial/errors.html#handling-exceptions)

Here is the line of interest, look closely at the comment:

...    print inst           # __str__ allows args to printed directly
My English teachers would tell me that "printed" is incorrectly conjugated.  It would probably sound better if we said "to be printed".

-Scott

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

From report at bugs.python.org  Thu Jul 24 05:07:59 2014
From: report at bugs.python.org (Weinan Li)
Date: Thu, 24 Jul 2014 03:07:59 +0000
Subject: [docs] [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1406171279.49.0.295613394763.issue22021@psf.upfronthosting.co.za>


Weinan Li added the comment:

that sounds reasonable

----------

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

From andrew.svetlov at gmail.com  Thu Jul 24 07:09:34 2014
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Thu, 24 Jul 2014 08:09:34 +0300
Subject: [docs] minor grammar error
In-Reply-To: <63EC325C5190FF4CBC44EB63354C987E22614B8F@az18ex3002.global.ds.honeywell.com>
References: <63EC325C5190FF4CBC44EB63354C987E22614B8F@az18ex3002.global.ds.honeywell.com>
Message-ID: <CAL3CFcVV5UsJsTZ=3QDizyUQxp4BhY3BLvwmTfkCcxUQssRrqQ@mail.gmail.com>

Fixed. Thanks.

On Thu, Jul 24, 2014 at 12:55 AM, Hinton, Scott (ESEA Space)
<Scott.Hinton at honeywell.com> wrote:
> Hello,
>
>
>
> I was reading through the Python tutorial and found a minor grammatical
> error near the end of the section on raising exceptions
>
> (https://docs.python.org/2.7/tutorial/errors.html#handling-exceptions)
>
>
>
> Here is the line of interest, look closely at the comment:
>
> ...    print inst           # __str__ allows args to printed directly
>
> My English teachers would tell me that ?printed? is incorrectly conjugated.
> It would probably sound better if we said ?to be printed?.
>
>
>
> -Scott
>
>
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>



-- 
Thanks,
Andrew Svetlov

From report at bugs.python.org  Thu Jul 24 08:29:17 2014
From: report at bugs.python.org (Saimadhav Heblikar)
Date: Thu, 24 Jul 2014 06:29:17 +0000
Subject: [docs] [issue22055] Incomplete sentence in asyncio BaseEventLoop doc
Message-ID: <1406183357.83.0.748743023409.issue22055@psf.upfronthosting.co.za>


Changes by Saimadhav Heblikar <saimadhavheblikar at gmail.com>:


----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio-eventloop-doc-incomplete-sent.diff
keywords: patch
nosy: docs at python, gvanrossum, haypo, sahutd, yselivanov
priority: normal
severity: normal
status: open
title: Incomplete sentence in asyncio BaseEventLoop doc
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36060/asyncio-eventloop-doc-incomplete-sent.diff

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

From report at bugs.python.org  Thu Jul 24 09:04:37 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Jul 2014 07:04:37 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406185477.19.0.181152718123.issue21580@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I will try test the problem and fix on Windows within a day.

----------

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

From report at bugs.python.org  Thu Jul 24 09:19:35 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Jul 2014 07:19:35 +0000
Subject: [docs] [issue22052] Comparison operators called in reverse order
	for	subclasses with no override.
In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
Message-ID: <1406186375.86.0.694825382533.issue22052@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> "the subclass provides" doesn't actually imply anything about overriding, I think.

Yes, that was the thrust of one of the SO answers.  Unfortunately, that explanation doesn't work for arithmetic operators, though: there an explicit override is necessary.  Here's another example, partly to get away from the extra complication of __eq__ being its own inverse.  After:

    class A(object):
        def __lt__(self, other): return True
        def __gt__(self, other): return False
        def __add__(self, other): return 1729
        def __radd__(self, other): return 42

    class B(A): pass

we get:

    >>> A() + B()
    1729
    >>> A() < B()
    False

So the addition is calling the usual __add__ method first (the special exception in the docs doesn't apply: while B *is* a subclass of A, it doesn't *override* A's __radd__ method).  But the comparison is (surprisingly) calling the __gt__ method first.

So we've got two different rules being followed: one for arithmetic operators, and a different one for comparisons.

This isn't a big deal behaviour-wise: I'm certainly not advocating a behaviour change here.  But it would be nice to document it.

----------

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

From report at bugs.python.org  Thu Jul 24 10:38:04 2014
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 24 Jul 2014 08:38:04 +0000
Subject: [docs] [issue22055] Incomplete sentence in asyncio BaseEventLoop doc
Message-ID: <1406191084.4.0.954616040636.issue22055@psf.upfronthosting.co.za>


New submission from Andrew Svetlov:

Fixed in f578e1d717b7 and f578e1d717b7.
Thanks.

----------
nosy: +asvetlov
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Jul 24 12:44:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 24 Jul 2014 10:44:38 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
In-Reply-To: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>
Message-ID: <3hJqtF6C4Jz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 833325d45113 by Victor Stinner in branch '3.4':
Issue #21813: Enhance documentation of the os.stat_result class.
http://hg.python.org/cpython/rev/833325d45113

New changeset 5d70ac83d104 by Victor Stinner in branch 'default':
Issue #21813: Enhance documentation of the os.stat_result class.
http://hg.python.org/cpython/rev/5d70ac83d104

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

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

From report at bugs.python.org  Thu Jul 24 12:45:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 24 Jul 2014 10:45:33 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
In-Reply-To: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>
Message-ID: <1406198733.0.0.134838553707.issue21813@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thanks Zachary Ware for your review. I'm not sure that I addressed all your comments, but I'm not interested to spend too much time on the documentation. Please open an issue if your saw other things that can be improved.

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

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

From report at bugs.python.org  Thu Jul 24 15:46:46 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jul 2014 13:46:46 +0000
Subject: [docs] [issue21813] Enhance doc of os.stat_result
In-Reply-To: <1403255902.92.0.811638089523.issue21813@psf.upfronthosting.co.za>
Message-ID: <1406209606.2.0.651887007948.issue21813@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The only comments you didn't address you were right not to (sorry for the noise about path_fd, I completely missed that it was just a link reference); what you committed looks fine to me.

Thanks for your work on this, it looks like a big improvement to me!

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

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

From victor.stinner at gmail.com  Thu Jul 24 12:44:37 2014
From: victor.stinner at gmail.com (victor.stinner at gmail.com)
Date: Thu, 24 Jul 2014 10:44:37 -0000
Subject: [docs] Enhance doc of os.stat_result (issue 21813)
Message-ID: <20140724104437.29019.43431@psf.upfronthosting.co.za>

Reviewers: Zach Ware,


http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst
File Doc/library/os.rst (right):

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1883
Doc/library/os.rst:1883: :ref:`not following symlinks
<follow_symlinks>`.
On 2014/06/20 15:42:33, Zach Ware wrote:
> This paragraph confuses me: path_fd is not a parameter, but specifying
a file
> descriptor has already been mentioned; follow_symlinks has already
been
> mentioned as well.  The dir_fd parameter hasn't been mentioned,
though.

<path_fd> is used in a link to a different section of the documentation.

The dir_fd parameter is documented in the section pointed by path_fd:
https://docs.python.org/dev/library/os.html#files-and-directories

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1892
Doc/library/os.rst:1892: posix.stat_result(st_mode=33188,
st_ino=7876932, st_dev=234881026,
On 2014/06/20 15:42:33, Zach Ware wrote:
> Is this still accurate? On Windows, at least, stat_result reprs show
> "os.stat_result" rather than "<platform os module name>.stat_result".

You're right, I changed it to os.stat_result().

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1904
Doc/library/os.rst:1904: .. versionadded:: 3.3
On 2014/06/20 15:42:33, Zach Ware wrote:
> Kind of late on this, but shouldn't this be a versionchanged rather
than
> versionadded?  The note on st_file_attributes probably should be, too.

This is unrelated to my change. I think that versionadded is correct.
The result in the HTML doc is "New in version 3.3: Added the ...". Open
a new issue if you want to change these notes.

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode1951
Doc/library/os.rst:1951: .. st_atime
On 2014/06/20 15:42:33, Zach Ware wrote:
> attribute:: 

Done.

http://bugs.python.org/review/21813/diff/12221/Doc/library/os.rst#newcode2043
Doc/library/os.rst:2043: Create of the file.
On 2014/06/20 15:42:33, Zach Ware wrote:
> Creator

Done.



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

Affected files:
  Doc/library/os.rst
  Doc/whatsnew/3.5.rst



From report at bugs.python.org  Thu Jul 24 15:53:37 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jul 2014 13:53:37 +0000
Subject: [docs] [issue22055] Incomplete sentence in asyncio BaseEventLoop doc
In-Reply-To: <1406191084.4.0.954616040636.issue22055@psf.upfronthosting.co.za>
Message-ID: <1406210017.58.0.871585162528.issue22055@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Misposted to #20055:

New changeset 84f26a437893 by Victor Stinner in branch '3.4':
Issue #20055: Fix BaseEventLoop.stop() docstring, incomplete sentence.
http://hg.python.org/cpython/rev/84f26a437893

New changeset f657b64c67ab by Victor Stinner in branch 'default':
(Merge 3.4) Issue #20055: Fix BaseEventLoop.stop() docstring, incomplete
http://hg.python.org/cpython/rev/f657b64c67ab

----------
nosy: +zach.ware

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

From report at bugs.python.org  Thu Jul 24 15:59:50 2014
From: report at bugs.python.org (Alon Mishne)
Date: Thu, 24 Jul 2014 13:59:50 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
Message-ID: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>


New submission from Alon Mishne:

According to the documentation of eval():

> If the globals dictionary is present and lacks '__builtins__', the current globals are copied into globals before expression is parsed.

However in practice only the __builtins__ items are copied, see:

http://hg.python.org/cpython/file/2.7/Python/bltinmodule.c#l655

See http://stackoverflow.com/q/24934908/242762

----------
assignee: docs at python
components: Documentation
messages: 223837
nosy: amishne, docs at python
priority: normal
severity: normal
status: open
title: The doc say all globals are copied on eval(), but only __builtins__ is copied
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jul 24 16:08:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 24 Jul 2014 14:08:43 +0000
Subject: [docs] [issue22052] Comparison operators called in reverse order
	for	subclasses with no override.
In-Reply-To: <1406149410.09.0.756154064568.issue22052@psf.upfronthosting.co.za>
Message-ID: <1406210923.66.0.959969059458.issue22052@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah yes.  I remember there being a discussion somewhere about the differences between comparison operator inverses and the arithmetic 'r' methods, but I can't find it at the moment.  I *thought* there was a full discussion of the logic involved in these cases, but I can't find that either.  We need one somewhere that we can crosslink to if it doesn't already exist.

----------

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

From report at bugs.python.org  Thu Jul 24 17:11:48 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jul 2014 15:11:48 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1406214708.23.0.816696943222.issue19980@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Mark, would you like to update your patch to address my review comments?

----------

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

From report at bugs.python.org  Thu Jul 24 22:41:49 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 24 Jul 2014 20:41:49 +0000
Subject: [docs] [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1406234508.98.0.53591182535.issue21314@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Apologies for the delay in answering, Emily.  And, unfortunately, I don't have a good answer.  If you would like to write a patch, I would suggest just sticking the documentation wherever you think is best and make sure there is a link to it from the Symbols index page.  Whoever commits your patch will either agree with your placement or have a better idea of where to put it, and will either move it themselves or work with you to move it.

Here are a few possible places it could go, off the top of my head and without really looking:
- in the pydoc docs
- in the help() builtin docs
- in or near the inspect.Signature docs
- in the Clinic HOWTO
- somewhere in the tutorial (though I'm not sure where would be good)

----------

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

From tgmiller5 at hotmail.com  Thu Jul 24 23:58:04 2014
From: tgmiller5 at hotmail.com (Tammy Miller)
Date: Thu, 24 Jul 2014 17:58:04 -0400
Subject: [docs] Interested in contributing to documentation
In-Reply-To: <CAKJDb-OVd5ByBc8i3UPVo1n5BjQq2cnfA2v7gHDexHEdDY16Pg@mail.gmail.com>
References: <COL125-W45354ECE03C0BD439882B3FA080@phx.gbl>,
 <CAKJDb-OVd5ByBc8i3UPVo1n5BjQq2cnfA2v7gHDexHEdDY16Pg@mail.gmail.com>
Message-ID: <COL125-W41E989E7404EB14486626BFAFF0@phx.gbl>

 I have been reading the documentation and would like to make changes/modifications to the documentation issues but it is not that clear to me on how to proceed. I have downloaded Mercuial and TortosieHG and the repository but I do not know how to go in and edit the changes and like upload the changes(I am not sure if I should use the commit). I do apologize for being slow at this but would like to contribute. 


Thank you, 
Tammy
> From: zachary.ware+pydocs at gmail.com
> Date: Wed, 16 Jul 2014 15:05:23 -0500
> Subject: Re: [docs] Interested in contributing to documentation
> To: docs at python.org
> CC: tgmiller5 at hotmail.com
> 
> Hi Tammy,
> 
> On Sat, Jul 12, 2014 at 2:38 PM, Tammy Miller <tgmiller5 at hotmail.com> wrote:
> > My name is Tammy and I am interested in contributing to documentation for
> > Python.
> 
> Glad to hear that you're interested!  You can get started by taking a
> look at the Reporting Bugs page[1] of the docs, which contains some
> suggestions for how to get started, links to more resources, and in
> particular a link to open documentation bugs on the Python bug
> tracker.  Feel free to dive in wherever you feel comfortable, and
> don't hesitate to ask questions.  You may be interested in the
> core-mentorship mailing list (mentioned at the bottom of the page I
> linked to) for quick help from friendly people, or you can use this
> list for documentation issues (though there are significantly fewer
> people actively listening here).
> 
> If there's anything that can be done to help you along the way, do let us know!
> 
> Welcome to Python, we hope you enjoy your stay :)
> 
> -- 
> Zach
> 
> [1] http://docs.python.org/3/bugs.html
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140724/8b7f854f/attachment.html>

From report at bugs.python.org  Fri Jul 25 05:42:03 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 25 Jul 2014 03:42:03 +0000
Subject: [docs] [issue22049] argparse: type=<callable> doesn't honor nargs >
	1
In-Reply-To: <1406135782.37.0.476079892774.issue22049@psf.upfronthosting.co.za>
Message-ID: <1406259723.26.0.0398775751208.issue22049@psf.upfronthosting.co.za>


paul j3 added the comment:

Note that 

    '-t 1 2 3'.split()

becomes

    ['-t', '1', '2', '3']

Your 'type' function sees those 3 strings individually.  Try printing 'string' the first thing in your function to see what we mean.

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

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

From report at bugs.python.org  Fri Jul 25 19:08:55 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Jul 2014 17:08:55 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1406308135.83.0.853488912085.issue22057@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for noticing this.  Do you want to propose a patch?

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
stage:  -> needs patch
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 25 19:29:46 2014
From: report at bugs.python.org (Chris Bruner)
Date: Fri, 25 Jul 2014 17:29:46 +0000
Subject: [docs] [issue22049] argparse: type=<callable> doesn't honor nargs >
	1
In-Reply-To: <1406259723.26.0.0398775751208.issue22049@psf.upfronthosting.co.za>
Message-ID: <D7370F46-3EA7-4AA1-BBFA-CA901B14A09C@gmail.com>


Chris Bruner added the comment:

Yes, I know. My function just sees '1', but I think it should see '1 2 3' so that it can figure out what to do. That's impossible (well, impossible without saving state between calls) when it sees the arguments piecemeal. 

Sent from my iPhone

> On Jul 24, 2014, at 9:42 PM, paul j3 <report at bugs.python.org> wrote:
> 
> 
> paul j3 added the comment:
> 
> Note that 
> 
>    '-t 1 2 3'.split()
> 
> becomes
> 
>    ['-t', '1', '2', '3']
> 
> Your 'type' function sees those 3 strings individually.  Try printing 'string' the first thing in your function to see what we mean.
> 
> ----------
> nosy: +paul.j3
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22049>
> _______________________________________

----------

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

From report at bugs.python.org  Fri Jul 25 20:27:17 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 25 Jul 2014 18:27:17 +0000
Subject: [docs] [issue22072] Fix typos in SSL's documentation
Message-ID: <1406312837.87.0.669904436457.issue22072@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

Attached patch fixes a pair of typos.

----------
assignee: docs at python
components: Documentation
files: ssl-docs.diff
keywords: easy, needs review, patch
messages: 223982
nosy: alex, docs at python
priority: normal
severity: normal
status: open
title: Fix typos in SSL's documentation
versions: Python 3.5
Added file: http://bugs.python.org/file36091/ssl-docs.diff

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

From report at bugs.python.org  Fri Jul 25 20:32:07 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 25 Jul 2014 18:32:07 +0000
Subject: [docs] [issue22072] Fix typos in SSL's documentation
In-Reply-To: <1406312837.87.0.669904436457.issue22072@psf.upfronthosting.co.za>
Message-ID: <3hKfCC1mZGz7LjP@mail.python.org>


Roundup Robot added the comment:

New changeset 1c7567ec6292 by Zachary Ware in branch '3.4':
Issue #22072: Fix a couple of SSL doc typos.  Patch by Alex Gaynor.
http://hg.python.org/cpython/rev/1c7567ec6292

New changeset 967311e6c0d2 by Zachary Ware in branch 'default':
Closes #22072: Merge typo fixes from 3.4
http://hg.python.org/cpython/rev/967311e6c0d2

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

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

From report at bugs.python.org  Fri Jul 25 20:32:48 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 25 Jul 2014 18:32:48 +0000
Subject: [docs] [issue22072] Fix typos in SSL's documentation
In-Reply-To: <1406312837.87.0.669904436457.issue22072@psf.upfronthosting.co.za>
Message-ID: <1406313168.85.0.375524235666.issue22072@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks, Alex!

----------
nosy: +zach.ware
versions: +Python 3.4

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

From report at bugs.python.org  Sat Jul 26 00:17:03 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 25 Jul 2014 22:17:03 +0000
Subject: [docs] [issue22049] argparse: type=<callable> doesn't honor nargs >
	1
In-Reply-To: <1406135782.37.0.476079892774.issue22049@psf.upfronthosting.co.za>
Message-ID: <1406326623.31.0.332890989494.issue22049@psf.upfronthosting.co.za>


paul j3 added the comment:

What you want is a custom Action rather than a custom Type.  

from the documentation:

    >>> class FooAction(argparse.Action):
    ...     def __call__(self, parser, namespace, values, option_string=None):
    ...         print('%r %r %r' % (namespace, values, option_string))
    ...         setattr(namespace, self.dest, values)

'values' will be the list ['1','2','3'], which you test and manipulate, before finally saving it to the 'namespace'.

    ret = (int(values[0]), int(values[1]), float(values[2]))
    setattr(namespace, self.dest, ret)

Setting 'nargs=3' ensures that this action will always get a 3 item list.  If the parser can't give it 3 items, it will raise an error rather than call your Action.

'optparse' passed the remaining argument strings to Option's callback, which could consume as many as it wanted.  'argparse' does not give the Actions that power.  There is a fundamental difference in the parsing algorithm.

----------

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

From report at bugs.python.org  Sat Jul 26 11:57:32 2014
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 26 Jul 2014 09:57:32 +0000
Subject: [docs] [issue12243] getpass.getuser works on OSX
In-Reply-To: <1307029704.02.0.858553376312.issue12243@psf.upfronthosting.co.za>
Message-ID: <1406368652.79.0.222573609114.issue12243@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

The issue still is present, wouldn't it be better to just remove the availability annotation from the docs (2.7, 3.4 and trunk) while waiting for a better solution? 

That would at least remove confusion for these docs. At the very least the "Macintosh" availability note should be removed, that was used to document that a function is available on MacOS 9, which hasn't been supported in a long time now.

----------
nosy: +ronaldoussoren
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 26 19:11:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Jul 2014 17:11:57 +0000
Subject: [docs] [issue22069] TextIOWrapper(newline="\n",
	line_buffering=True) mistakenly treat \r as a newline
In-Reply-To: <1406306623.81.0.633771356606.issue22069@psf.upfronthosting.co.za>
Message-ID: <1406394717.5.0.488912869007.issue22069@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Looks as this behavior is intentional. Documentation should be corrected.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +benjamin.peterson, docs at python, hynek, pitrou, stutzbach

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

From willingc at willingconsulting.com  Sat Jul 26 19:39:08 2014
From: willingc at willingconsulting.com (Carol Willing)
Date: Sat, 26 Jul 2014 10:39:08 -0700
Subject: [docs] Interested in contributing to documentation
In-Reply-To: <COL125-W41E989E7404EB14486626BFAFF0@phx.gbl>
References: <COL125-W45354ECE03C0BD439882B3FA080@phx.gbl>,
 <CAKJDb-OVd5ByBc8i3UPVo1n5BjQq2cnfA2v7gHDexHEdDY16Pg@mail.gmail.com>
 <COL125-W41E989E7404EB14486626BFAFF0@phx.gbl>
Message-ID: <53D3E7BC.9070105@willingconsulting.com>

Hi Tammy,

It's awesome that you would like to contribute. The first patch is 
challenging since you are learning the process, tools, and community 
norms simultaneously. Your first steps in getting Mercurial and reading 
the docs are good steps. Let's see if I can help guide you further 
through the process.

Here's a link to the Python Developer's Guide: 
https://docs.python.org/devguide/

The Python Developer's Guide should give you a detailed overview on how 
to contribute to documentation. Sections 7 and 8 were particularly 
helpful to me when I made my first documentation change. Section 27 
(FAQ) also answers general questions.

Please feel free to email me directly with questions or via IRC (nick: 
willingc). I'm sure that we can work through any questions that you may 
have on understanding how to submit your first documentation patch.

Warmly,
Carol


On 7/24/14, 2:58 PM, Tammy Miller wrote:
>  I have been reading the documentation and would like to make 
> changes/modifications to the documentation issues but it is not that 
> clear to me on how to proceed.
> I have downloaded Mercuial and TortosieHG and the repository but I do 
> not know how to go in and edit the changes and like upload the 
> changes(I am not sure if I should use the commit). I do apologize for 
> being slow at this but would like to contribute.
>
>
>
> Thank you,
>
> Tammy
> > From: zachary.ware+pydocs at gmail.com
> > Date: Wed, 16 Jul 2014 15:05:23 -0500
> > Subject: Re: [docs] Interested in contributing to documentation
> > To: docs at python.org
> > CC: tgmiller5 at hotmail.com
> >
> > Hi Tammy,
> >
> > On Sat, Jul 12, 2014 at 2:38 PM, Tammy Miller 
> <tgmiller5 at hotmail.com> wrote:
> > > My name is Tammy and I am interested in contributing to 
> documentation for
> > > Python.
> >
> > Glad to hear that you're interested! You can get started by taking a
> > look at the Reporting Bugs page[1] of the docs, which contains some
> > suggestions for how to get started, links to more resources, and in
> > particular a link to open documentation bugs on the Python bug
> > tracker. Feel free to dive in wherever you feel comfortable, and
> > don't hesitate to ask questions. You may be interested in the
> > core-mentorship mailing list (mentioned at the bottom of the page I
> > linked to) for quick help from friendly people, or you can use this
> > list for documentation issues (though there are significantly fewer
> > people actively listening here).
> >
> > If there's anything that can be done to help you along the way, do 
> let us know!
> >
> > Welcome to Python, we hope you enjoy your stay :)
> >
> > --
> > Zach
> >
> > [1] http://docs.python.org/3/bugs.html
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs


-- 
*Carol Willing*
Developer | Willing Consulting
+1 760 456 9366 | https://willingconsulting.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140726/45a67e0f/attachment.html>

From report at bugs.python.org  Sat Jul 26 20:59:03 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 26 Jul 2014 18:59:03 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1406401143.84.0.57215707345.issue22014@psf.upfronthosting.co.za>


?ric Araujo added the comment:

literalinclude lets you select only some lines of the file: http://sphinx-doc.org/markup/code.html#includes

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Sun Jul 27 00:44:09 2014
From: report at bugs.python.org (Julian Berman)
Date: Sat, 26 Jul 2014 22:44:09 +0000
Subject: [docs] [issue22088] base64 module still ignores non-alphabet
	characters
Message-ID: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>


New submission from Julian Berman:

The base64 module documentation claims that decode methods raise exceptions for non-base64 input, but they do not.

There was a patch for Py3 done in issue1466065, but the documentation was not updated for Py2. I have not read that ticket carefully enough to be able to tell what the expected resolution was for Py2 (fixing the bug or just updating the docs).

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 224089
nosy: Julian, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: base64 module still ignores non-alphabet characters
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Jul 27 03:53:58 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 27 Jul 2014 01:53:58 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1406426038.28.0.587569584121.issue22014@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Oh, nice - the "start-after" and "end-before" options look like they might be the way to go.

If I'm reading the docs right, a block like the following would include the OSError section of the tree:

   .. literalinclude exceptions.txt
      :start-after: OSError
      :end-before: ReferenceError
      :prepend:

I think that's really the section that could most benefit from showing the structure inline.

----------

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

From report at bugs.python.org  Sun Jul 27 11:55:55 2014
From: report at bugs.python.org (Alon Mishne)
Date: Sun, 27 Jul 2014 09:55:55 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1406454955.16.0.414272703243.issue22057@psf.upfronthosting.co.za>


Alon Mishne added the comment:

Patch for 2.7.8.

The patch is just changing "globals are" to "mapping of ?__builtins__? is", and subsequent paragraph reformatting.

----------
keywords: +patch
Added file: http://bugs.python.org/file36128/evalglobals2.patch

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

From report at bugs.python.org  Sun Jul 27 11:57:43 2014
From: report at bugs.python.org (Alon Mishne)
Date: Sun, 27 Jul 2014 09:57:43 +0000
Subject: [docs] [issue22057] The doc say all globals are copied on eval(),
	but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1406455063.28.0.122205342147.issue22057@psf.upfronthosting.co.za>


Alon Mishne added the comment:

Patch for 3.5.x

The patch is just changing "globals are" to "mapping of ?__builtins__? is", and subsequent paragraph reformatting.

Nearly identical to 2.7.8 patch.

----------
Added file: http://bugs.python.org/file36129/evalglobals3.patch

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

From report at bugs.python.org  Mon Jul 28 15:06:14 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Jul 2014 13:06:14 +0000
Subject: [docs] [issue12970] os.walk() consider some symlinks as dirs
	instead of	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1406552774.15.0.441833058907.issue12970@psf.upfronthosting.co.za>


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


----------
nosy: +benhoyt

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

From report at bugs.python.org  Mon Jul 28 15:50:22 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Mon, 28 Jul 2014 13:50:22 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1406555422.02.0.579604185009.issue20351@psf.upfronthosting.co.za>


Charles-Axel Dein added the comment:

Anything else I need to do?

----------

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

From report at bugs.python.org  Mon Jul 28 16:16:39 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 28 Jul 2014 14:16:39 +0000
Subject: [docs] [issue12970] os.walk() consider some symlinks as dirs
	instead of	non-dirs
In-Reply-To: <1315918932.02.0.810529185276.issue12970@psf.upfronthosting.co.za>
Message-ID: <1406556998.97.0.373868428284.issue12970@psf.upfronthosting.co.za>


Akira Li added the comment:

I've updated os.walk() documentation to mention that *dirnames* list
includes symlinks to directories.

To imitate the other two cases:

- treat the symlinks as files:

    for dirpath, dirnames, files in os.walk(top):
        dirs = []
        for name in dirnames:
            (files if islink(join(dirpath, name)) else dirs).append(name)
        dirnames = dirs

- don't include in either of the lists:

    for dirpath, dirnames, files in os.walk(top):
        dirnames[:] = [name for name in dirnames
                       if not islink(join(dirpath, name))]

where islink = os.path.islink and join = os.path.join.

I've uploaded the documentation patch. Please, review.

----------
nosy: +akira
Added file: http://bugs.python.org/file36138/docs-walk-issue12970.patch

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

From report at bugs.python.org  Mon Jul 28 20:03:18 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Jul 2014 18:03:18 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1406570598.57.0.809956965803.issue20351@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Anything else I need to do?

Nothing else.  I've got it from here :-)

----------

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

From ezio.melotti at gmail.com  Mon Jul 28 20:30:42 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 28 Jul 2014 18:30:42 -0000
Subject: [docs] Add doc examples for DictReader and DictWriter (issue
	20351)
Message-ID: <20140728183042.28966.56574@psf.upfronthosting.co.za>

LGTM

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

From report at bugs.python.org  Mon Jul 28 20:43:15 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 28 Jul 2014 18:43:15 +0000
Subject: [docs] [issue19980] Improve help('non-topic') response
In-Reply-To: <1386984892.27.0.919528696836.issue19980@psf.upfronthosting.co.za>
Message-ID: <1406572995.64.0.821568600483.issue19980@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I suppose that technically this can only go into 3.5, but is there any real reason that this couldn't be backported?

----------
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file36141/Issue19980.diff

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

From report at bugs.python.org  Tue Jul 29 21:53:26 2014
From: report at bugs.python.org (Chris Bruner)
Date: Tue, 29 Jul 2014 19:53:26 +0000
Subject: [docs] [issue22049] argparse: type=<callable> doesn't honor nargs >
	1
In-Reply-To: <1406326623.31.0.332890989494.issue22049@psf.upfronthosting.co.za>
Message-ID: <CAEdEUw7pE=j-MTip3iGJmV1ju+6WB+q2H7qFm8Yu=7trFWzMKA@mail.gmail.com>


Chris Bruner added the comment:

Just had a chance to try this, and this does exactly what I wanted from
"type=". Thank you!

On Fri, Jul 25, 2014 at 4:17 PM, paul j3 <report at bugs.python.org> wrote:

>
> paul j3 added the comment:
>
> What you want is a custom Action rather than a custom Type.
>
> from the documentation:
>
>     >>> class FooAction(argparse.Action):
>     ...     def __call__(self, parser, namespace, values,
> option_string=None):
>     ...         print('%r %r %r' % (namespace, values, option_string))
>     ...         setattr(namespace, self.dest, values)
>
> 'values' will be the list ['1','2','3'], which you test and manipulate,
> before finally saving it to the 'namespace'.
>
>     ret = (int(values[0]), int(values[1]), float(values[2]))
>     setattr(namespace, self.dest, ret)
>
> Setting 'nargs=3' ensures that this action will always get a 3 item list.
>  If the parser can't give it 3 items, it will raise an error rather than
> call your Action.
>
> 'optparse' passed the remaining argument strings to Option's callback,
> which could consume as many as it wanted.  'argparse' does not give the
> Actions that power.  There is a fundamental difference in the parsing
> algorithm.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22049>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Jul 30 00:30:45 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Jul 2014 22:30:45 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <1406673045.09.0.454388364717.issue21860@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The patch looks good to me.

----------

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

From report at bugs.python.org  Wed Jul 30 09:42:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Jul 2014 07:42:59 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406706179.95.0.655308573848.issue21580@psf.upfronthosting.co.za>


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


----------
nosy: +loewis

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

From report at bugs.python.org  Wed Jul 30 12:24:14 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Jul 2014 10:24:14 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406715854.14.0.569949737441.issue21580@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The 3.4 patch looks fine, please apply.

I'm -1 on the 2.7 patch. I think it would be better to add a _tkinter helper function to create Tcl byte array objects. Alternatively, the "binary format" command might help. OTOH, I don't care about 2.7, so feel free to do whatever you consider appropriate.

----------

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

From report at bugs.python.org  Wed Jul 30 12:47:09 2014
From: report at bugs.python.org (Charles Newey)
Date: Wed, 30 Jul 2014 10:47:09 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
Message-ID: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>


New submission from Charles Newey:

URL: https://docs.python.org/2/tutorial/controlflow.html#pass-statements

Quoted verbatim:
"""
The pass statement does nothing. It can be used when a statement is required syntactically but the program requires no action. For example:
>>>

>>> while True:
...     pass  # Busy-wait for keyboard interrupt (Ctrl+C)
...

"""

While the example illustrates the point, it *may* give bad ideas to novice programmers reading it - "while True: pass" is an antipattern as it's very inefficient.

----------
assignee: docs at python
components: Documentation
messages: 224296
nosy: Charles.Newey, docs at python
priority: normal
severity: normal
status: open
title: Python 2 docs 'control flow/pass' section contains bad example
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed Jul 30 12:59:33 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jul 2014 10:59:33 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406717973.67.0.408025989551.issue22106@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Do you have any suggestion?
The section already includes examples about empty classes and as placeholder inside functions, and the only other "realistic" situations I can think of is inside an except to ignore errors -- but that might be considered an anti-pattern too.
It could be used with "for" loops if you want to e.g. consume an iterator, or with the "with" statement if you want to create an empty file, but these cases are not very common.

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

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

From report at bugs.python.org  Wed Jul 30 13:16:42 2014
From: report at bugs.python.org (Charles Newey)
Date: Wed, 30 Jul 2014 11:16:42 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406719002.36.0.277664269973.issue22106@psf.upfronthosting.co.za>


Charles Newey added the comment:

Your point about using "pass" with the "with" statement sounds like a better example than using "pass" in a loop.

Perhaps even something like adding a note to the example to clarify it:
"""
# Don't use this in Python code - it is for illustrative purposes only
while True:
    pass  # Busy-wait for keyboard interrupt (Ctrl+C)
"""

On the other hand -- one could argue that the documentation should not show "incorrect" uses of Python syntax at all.

----------

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

From report at bugs.python.org  Wed Jul 30 14:23:18 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 30 Jul 2014 12:23:18 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406722998.85.0.683021583106.issue22106@psf.upfronthosting.co.za>


R. David Murray added the comment:

How about something like:

   for x in my_generator():
       pass   # Exhaust co-routine generator to make sure all data is processed.

I have no idea if you'd ever actually do that in a well-structured co-routine context, though, not having written very much of that kind of code.

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

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

From report at bugs.python.org  Wed Jul 30 15:49:26 2014
From: report at bugs.python.org (Charles Newey)
Date: Wed, 30 Jul 2014 13:49:26 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406728166.0.0.848812795527.issue22106@psf.upfronthosting.co.za>


Charles Newey added the comment:

@David I have no idea either (no having written much of that sort of code myself either), but that looks more sensible.

I'm just nitpicking really, anyway.

----------

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

From report at bugs.python.org  Wed Jul 30 15:57:53 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jul 2014 13:57:53 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406728673.09.0.425339319416.issue22106@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Keep in mind that this is in one of the first sections of the tutorial, where try/except, with, and generators have not been introduced yet.
Maybe the comment could be changed to a simpler "loop forever (use ctrl+c to stop)" so that it doesn't suggest that this is the way to wait for keyboard interrupts and/or a note like "note that this will use 100% of the CPU" could be added as well.

----------

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

From report at bugs.python.org  Wed Jul 30 17:34:18 2014
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 30 Jul 2014 15:34:18 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <3hNf1j4ggzz7Ljd@mail.python.org>


Roundup Robot added the comment:

New changeset 9474f2971855 by Serhiy Storchaka in branch '3.4':
Issue #21580: Now Tkinter correctly handles bytes arguments passed to Tk.
http://hg.python.org/cpython/rev/9474f2971855

New changeset b9d249316f29 by Serhiy Storchaka in branch 'default':
Issue #21580: Now Tkinter correctly handles bytes arguments passed to Tk.
http://hg.python.org/cpython/rev/b9d249316f29

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

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

From report at bugs.python.org  Wed Jul 30 17:48:09 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Jul 2014 15:48:09 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406735289.28.0.335152084213.issue21580@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin for your reviews. Here is updated 2.7 patch which implements your suggestion.

The disadvantage of this patch in comparison with first version is that it will not work with statically compiled embedded Python, when only stdlib is updated. I once broke re in bugfix release in such manner (by moving one constant from Python sources to C sources). On other hand, it is very unlikely that anyone uses Tkinter in such circumstances, and in any case this part of code is broken for now, so patch should not introduce new regression.

----------
Added file: http://bugs.python.org/file36167/tkinter_bytes-2.7_2.patch

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

From report at bugs.python.org  Wed Jul 30 18:09:38 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 30 Jul 2014 16:09:38 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406736578.27.0.372105411407.issue21580@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The 2.7_2 patch looks good to me. I won't rule on the backwards compatibility implications, although I agree that this is unlikely to cause a regression (it would only if somebody updated the standard library only, *and* would use data= for PhotoImage). I'm unsure whether it was possible at all so far to use data= (with whatever argument); if you could have passed a non-buffer object successfully, this would break now.

----------

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

From report at bugs.python.org  Wed Jul 30 20:05:36 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Jul 2014 18:05:36 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406743536.59.0.443736990451.issue22106@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry Charles, this is a non-issue.  The section does a great job communicating what "pass" does.  It has been in the docs since 2007 and no harm has come of it.

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

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

From report at bugs.python.org  Wed Jul 30 20:06:08 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 30 Jul 2014 18:06:08 +0000
Subject: [docs] [issue22106] Python 2 docs 'control flow/pass' section
	contains bad	example
In-Reply-To: <1406717229.88.0.0475217386951.issue22106@psf.upfronthosting.co.za>
Message-ID: <1406743568.79.0.953804553538.issue22106@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
stage:  -> resolved

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

From report at bugs.python.org  Thu Jul 31 04:40:18 2014
From: report at bugs.python.org (Daniel Greenfeld)
Date: Thu, 31 Jul 2014 02:40:18 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
Message-ID: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>


New submission from Daniel Greenfeld:

Problem
========

The documentation on asyncio provides an example of a parallel execution of tasks. The code is at: https://docs.python.org/3/library/asyncio-task.html#example-parallel-execution-of-tasks

``` python
import asyncio
 
@asyncio.coroutine
def factorial(name, number):
    f = 1
    for i in range(2, number+1):
        print("Task %s: Compute factorial(%s)..." % (name, i))
        yield from asyncio.sleep(1)
        f *= i
    print("Task %s: factorial(%s) = %s" % (name, number, f))
 
loop = asyncio.get_event_loop()
tasks = [
    loop.create_task(factorial("A", 2)),
    loop.create_task(factorial("B", 3)),
    loop.create_task(factorial("C", 4))]
loop.run_until_complete(asyncio.wait(tasks))
loop.close()
```

Unfortunately, when I try to run this sample code on Python 3.4.1, I run into an error. Specifically, the `loop.create_task()` method does not exist:

``` python
Traceback (most recent call last):
  File "what_me_asynicio.py", line 14, in <module>
    loop.create_task(factorial("A", 2)),
AttributeError: '_UnixSelectorEventLoop' object has no attribute 'create_task'
```

When I perform a dir() on the `loop` object, no `create_task` item is in the result.

System Information
====================

Python Version: 3.4.1
Operating System: OSX 10.9.3
(Also confirmed on Python 3.4.0 in Ubuntu 14.04)

----------
assignee: docs at python
components: Documentation, Macintosh, asyncio
messages: 224374
nosy: docs at python, gvanrossum, haypo, pydanny, yselivanov
priority: normal
severity: normal
status: open
title: '_UnixSelectorEventLoop' object has no attribute 'create_task'
versions: Python 3.4

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

From report at bugs.python.org  Thu Jul 31 04:47:33 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jul 2014 02:47:33 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406774853.23.0.686358581071.issue22112@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks for reporting a doc bug!

The code should use asyncio.async() instead of loop.create_task().

----------

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

From report at bugs.python.org  Thu Jul 31 05:10:56 2014
From: report at bugs.python.org (Daniel Greenfeld)
Date: Thu, 31 Jul 2014 03:10:56 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406776256.48.0.857680489024.issue22112@psf.upfronthosting.co.za>


Daniel Greenfeld added the comment:

This has been fixed in 3.4.2, but shows up in the 3.4.1 documentation.

How do I fix the 3.4.1 documentation so this doesn't show up?

----------
Added file: http://bugs.python.org/file36173/Screen Shot 2014-07-30 at 8.13.12 PM.png

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

From report at bugs.python.org  Thu Jul 31 05:48:18 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jul 2014 03:48:18 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406778498.29.0.914878278399.issue22112@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I honestly don't know; ask Benjamin. :-)

Personally, I'd say that ship has sailed.

----------

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

From report at bugs.python.org  Thu Jul 31 06:57:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 31 Jul 2014 04:57:13 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <3hNzr90QFyz7Ljg@mail.python.org>


Roundup Robot added the comment:

New changeset 818989a48e96 by Serhiy Storchaka in branch '2.7':
Issue #21580: Now Tkinter correctly handles binary "data" and "maskdata"
http://hg.python.org/cpython/rev/818989a48e96

----------

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

From report at bugs.python.org  Thu Jul 31 09:33:13 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Jul 2014 07:33:13 +0000
Subject: [docs] [issue21580] PhotoImage(data=...) apparently has to be UTF-8
	or	Base-64 encoded
In-Reply-To: <1401083544.46.0.470654104454.issue21580@psf.upfronthosting.co.za>
Message-ID: <1406791993.95.0.793377409472.issue21580@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 31 11:04:33 2014
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Jul 2014 09:04:33 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406797473.6.0.804797806084.issue22112@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This has been fixed in 3.4.2, but shows up in the 3.4.1 documentation.

Well, I didn't want to change Python 3.4.1 documentation, but it looks like https://docs.python.org/3.4/ is updated after each commit into the 3.4 branch. For example, new asyncio functions added in 3.4.2 are already documented:

https://docs.python.org/3.4/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_task

I changeed all examples to use create_task() instaed of async() or the Task contructor:

changeset:   91609:66f06fbf8a2f
branch:      3.4
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Jul 08 12:39:10 2014 +0200
files:       Doc/library/asyncio-dev.rst Doc/library/asyncio-eventloop.rst Doc/library/asyncio-stream.r
description:
Update asyncio documentation

- Document the new create_task() method
- "Hide" the Task class: point to the create_task() method for interoperability
- Rewrite the documentation of the Task class
- Document the "Pending task destroyed"
- Update output in debug mode of examples in the dev section
- Replace Task() with create_task() in examples


Maybe I should revert this change in the 3.4 branch, but mention that Python 3.4.2 and 3.5 have a new create_task() which is now the recommanded way to schedule a coroutine (to create a task object).

----------

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

From lyndelllilly at gmail.com  Mon Jul 28 08:04:42 2014
From: lyndelllilly at gmail.com (Marie Markert)
Date: Sun, 27 Jul 2014 23:04:42 -0700
Subject: [docs] bug
Message-ID: <CAEpcq9GFMFUQKw=9H9T-ceq4NTPjREH-08w-3d18fg45-D6tsg@mail.gmail.com>

i have 520 builtin bugs?
marie markert @ Lyndelllilly at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140727/f5977413/attachment.html>

From John.Robinson at sdstate.edu  Thu Jul 31 02:02:40 2014
From: John.Robinson at sdstate.edu (Robinson, John)
Date: Thu, 31 Jul 2014 00:02:40 +0000
Subject: [docs] Bug report python 2.7.8 documentation Section 7.2.2 "saving
 structured data with json"
Message-ID: <4709DB66-8D5B-45C0-9C8A-DB13D9029655@sdstate.edu>

User must ?import json? module.

---------------------------------------------------------------------------------------------------------------------
John Robinson MD, PhD  |  Assistant Professor  |  South Dakota State University
Dept. Chemistry & Biochemistry  |  SAV371, Box 2202  |  Brookings SD 57007-0896  |  USA
Tel: 605-688-6954  |  Skype: johnmrobinson  |  john.robinson at sdstate.edu<mailto:john.robinson at sdstate.edu>  |  www.myofilament.org<http://www.myofilament.org/>




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

From report at bugs.python.org  Thu Jul 31 18:51:32 2014
From: report at bugs.python.org (Daniel Greenfeld)
Date: Thu, 31 Jul 2014 16:51:32 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406825492.88.0.379500360702.issue22112@psf.upfronthosting.co.za>


Daniel Greenfeld added the comment:

First, if there is documentation that says, "3.4.1", doesn't it make sense that the documentation should only be for 3.4.1? Which means that this create_task documentation should be reverted in the 3.4.1 documentation to match the 3.4.1 specification.

Second and most respectfully, why is a feature being added in 3.4.2? I thought this kind of release (3.4.1 to 3.4.2) was for bug fixes and security issues, not new features. Unless create_task was in the original 3.4 specification, I argue that create_task belongs in 3.5. In it's place, a recipe of running tasks in parallel fashion per gvanrossum's suggestion of asyncio.async() could be added.

----------

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

From report at bugs.python.org  Thu Jul 31 19:11:15 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jul 2014 17:11:15 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406825492.88.0.379500360702.issue22112@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+KgTsmvade=X6gp9wxzQkMnAH1y8UL-XsZN94i6Ar2sg@mail.gmail.com>


Guido van Rossum added the comment:

asyncio has an explicit exemption from the general rule that bugfixes
should not add new features. This is because of the "provisional" status of
the PEP. We'll stop doing this once 3.5 is out.

I don't know what's up with the online docs.

On Thu, Jul 31, 2014 at 9:51 AM, Daniel Greenfeld <report at bugs.python.org>
wrote:

>
> Daniel Greenfeld added the comment:
>
> First, if there is documentation that says, "3.4.1", doesn't it make sense
> that the documentation should only be for 3.4.1? Which means that this
> create_task documentation should be reverted in the 3.4.1 documentation to
> match the 3.4.1 specification.
>
> Second and most respectfully, why is a feature being added in 3.4.2? I
> thought this kind of release (3.4.1 to 3.4.2) was for bug fixes and
> security issues, not new features. Unless create_task was in the original
> 3.4 specification, I argue that create_task belongs in 3.5. In it's place,
> a recipe of running tasks in parallel fashion per gvanrossum's suggestion
> of asyncio.async() could be added.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22112>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Jul 31 20:54:20 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Jul 2014 18:54:20 +0000
Subject: [docs] [issue21860] Correct FileIO docstrings
In-Reply-To: <1403610592.56.0.388497950887.issue21860@psf.upfronthosting.co.za>
Message-ID: <1406832860.32.0.569666483968.issue21860@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> haypo
stage: needs patch -> commit review

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