From report at bugs.python.org  Fri May  1 00:03:21 2015
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 30 Apr 2015 22:03:21 +0000
Subject: [docs] [issue24088] yield expression confusion
Message-ID: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>


New submission from Jim Jewett:

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

Current:
"""
When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator?s methods is called.
"""

At a minimum, that seems to be using "generator function" in two different ways, but I think there are other problems.

Proposed:
"""
When a generator function is called, it returns a special kind of iterator known as a generator. The iteration starts when one of the generator?s methods is called.
"""

----------
assignee: docs at python
components: Documentation, asyncio
messages: 242289
nosy: Jim.Jewett, docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: yield expression confusion
type: enhancement

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

From report at bugs.python.org  Fri May  1 00:24:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 30 Apr 2015 22:24:28 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <1430432668.19.0.747372005539.issue24088@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You can't just drop the middle sentence. Awkward though it is, it is attempting to describe that the generator object controls suspension and resumption of the stack frame representing execution of the generator function's body.

----------

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

From report at bugs.python.org  Fri May  1 04:56:37 2015
From: report at bugs.python.org (Jaivish Kothari)
Date: Fri, 01 May 2015 02:56:37 +0000
Subject: [docs] [issue24005] Documentation Error: Extra line Break
In-Reply-To: <1429439369.0.0.722585874502.issue24005@psf.upfronthosting.co.za>
Message-ID: <1430448996.9.0.594155034463.issue24005@psf.upfronthosting.co.za>


Jaivish Kothari added the comment:

Thank you Tim.

----------

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

From report at bugs.python.org  Fri May  1 21:38:50 2015
From: report at bugs.python.org (Keith Gray)
Date: Fri, 01 May 2015 19:38:50 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
Message-ID: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>


New submission from Keith Gray:

The documentation for optparse states it has been deprecated in favor of argparse since 2.7. However, the library documentation for difflib still uses optparse in the example.

https://docs.python.org/2/library/difflib.html#a-command-line-interface-to-difflib

https://docs.python.org/3.5/library/difflib.html#a-command-line-interface-to-difflib

I am willing to update the documentation if there is agreement that it is needed.

----------
assignee: docs at python
components: Documentation
messages: 242347
nosy: docs at python, idahogray
priority: normal
severity: normal
status: open
title: Documentation for difflib uses optparse
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  1 22:16:47 2015
From: report at bugs.python.org (Merlijn van Deen)
Date: Fri, 01 May 2015 20:16:47 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za>
Message-ID: <1430511406.97.0.334570684006.issue24108@psf.upfronthosting.co.za>


Merlijn van Deen added the comment:

They are subtly different; the new regex also matches filenames with newlines, the old one doesn't (see Issue #6665 [1]).

Patch (although crazily minor) attached. With some fuzz, it applies on everything from 2.6..default.

[1] https://bugs.python.org/issue6665

----------
assignee:  -> docs at python
components: +Documentation -asyncio
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file39261/default.diff

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

From report at bugs.python.org  Fri May  1 22:58:11 2015
From: report at bugs.python.org (Christophe BAL)
Date: Fri, 01 May 2015 20:58:11 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <1430511406.97.0.334570684006.issue24108@psf.upfronthosting.co.za>
Message-ID: <CAAb4jGnZ_Sgdr5PTXigBWqwkX8OvUx8evpMFjbFGR_HaQGJrHA@mail.gmail.com>


Christophe BAL added the comment:

You're totally wrong and I am wrong.

There is still the tiny problem of the documentation.

Thanks for all.

*Christophe BAL*
*Enseignant de math?matiques en Lyc?e **et d?veloppeur Python amateur*
*---*
*French math teacher in a "Lyc?e" **and **Python **amateur developer*

2015-05-01 22:16 GMT+02:00 Merlijn van Deen <report at bugs.python.org>:

>
> Merlijn van Deen added the comment:
>
> They are subtly different; the new regex also matches filenames with
> newlines, the old one doesn't (see Issue #6665 [1]).
>
> Patch (although crazily minor) attached. With some fuzz, it applies on
> everything from 2.6..default.
>
> [1] https://bugs.python.org/issue6665
>
> ----------
> assignee:  -> docs at python
> components: +Documentation -asyncio
> keywords: +patch
> nosy: +docs at python
> Added file: http://bugs.python.org/file39261/default.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue24108>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri May  1 23:04:12 2015
From: report at bugs.python.org (Christophe BAL)
Date: Fri, 01 May 2015 21:04:12 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <CAAb4jGnZ_Sgdr5PTXigBWqwkX8OvUx8evpMFjbFGR_HaQGJrHA@mail.gmail.com>
Message-ID: <CAAb4jGmeZmtBfDq8NsdqQo223YUXW-HSPxhRtAH7p=qF+iQ_Qw@mail.gmail.com>


Christophe BAL added the comment:

Oups, sorry I want to say that you are totally RIGHT, and I am definitely
WRONG. :-)

----------

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

From report at bugs.python.org  Fri May  1 23:14:30 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 May 2015 21:14:30 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za>
Message-ID: <1430514870.0.0.4407955121.issue24108@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri May  1 23:30:04 2015
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 01 May 2015 21:30:04 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
Message-ID: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>


New submission from July Tikhonov:

In documentation of zipfile.ZipFile.write() there is following notice:

"There is no official file name encoding for ZIP files. If you have unicode file names, you must convert them to byte strings in your desired encoding before passing them to write()."

I understand it as that 'arcname' argument to write() shouldn't be of type str, but rather bytes.

But it is str that works, and bytes that does not:

$ ./python
Python 3.5.0a4+ (default:6f6e78931875, May  1 2015, 23:18:40) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> zf = zipfile.ZipFile('foo.zip', 'w')
>>> zf.write('python', 'a')
>>> zf.write('python', b'b')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/july/source/python/Lib/zipfile.py", line 1442, in write
    zinfo = ZipInfo(arcname, date_time)
  File "/home/july/source/python/Lib/zipfile.py", line 322, in __init__
    null_byte = filename.find(chr(0))
TypeError: a bytes-like object is required, not 'str'

(ZipInfo ostensibly attempts to find a zero byte in the filename, but searches instead for a unicode character chr(0). There are several other places in ZipInfo class that assume filename being str rather than bytes.)

I consider this a documentation issue: the notice is misleading. Although maybe there is someone who wants to fix the behavior of ZipInfo to allow bytes filename.

----------
assignee: docs at python
components: Documentation
messages: 242355
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: zipfile.ZipFile.write() does not accept bytes arcname
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  1 23:31:23 2015
From: report at bugs.python.org (July Tikhonov)
Date: Fri, 01 May 2015 21:31:23 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1430515883.41.0.857402161251.issue24110@psf.upfronthosting.co.za>


Changes by July Tikhonov <july.tikh at gmail.com>:


----------
components: +Library (Lib)

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

From report at bugs.python.org  Fri May  1 23:41:52 2015
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 01 May 2015 21:41:52 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <C1150691-9851-4467-A666-DF97C0D95A99@wirtel.be>


St?phane Wirtel added the comment:

This documentation is correct for python2 but maybe not for python3.

To check.

----------
nosy: +matrixise

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

From report at bugs.python.org  Sat May  2 03:50:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 01:50:00 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430531399.96.0.795876970956.issue24081@psf.upfronthosting.co.za>


R. David Murray added the comment:

This generally comes up in the context of a module importing another module, and *that* module fails to import.  The first module is left in sys.modules as a stub.  Try that experiment, I'm pretty sure that is still true.

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

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

From report at bugs.python.org  Sat May  2 03:55:46 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 01:55:46 +0000
Subject: [docs] [issue24082] Obsolete note in argument parsing
	(c-api/arg.rst)
In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za>
Message-ID: <1430531746.18.0.96843573311.issue24082@psf.upfronthosting.co.za>


R. David Murray added the comment:

The note is still valid concerning the length.  (Perhaps Victor should have deprected u instead of fixing it.)

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

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

From report at bugs.python.org  Sat May  2 04:08:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 02:08:50 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>
Message-ID: <1430532529.95.0.853929462797.issue24060@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds good to me.

----------

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

From report at bugs.python.org  Sat May  2 04:15:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 02:15:04 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <1430532904.05.0.102413823653.issue24088@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, and it is not using generator function in two different ways: it is literally the case that calling the generator function returns a generator object, which in turn controls the execution of the generator function.  The text then goes on to explain how this works.

I think it would make sense to change "controls execution of a generator function" to "controls execution of the generator function", but I can't think of any other change that would make things clearer.

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

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

From report at bugs.python.org  Sat May  2 04:28:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 02:28:00 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>
Message-ID: <1430533680.37.0.831595844165.issue24109@psf.upfronthosting.co.za>


R. David Murray added the comment:

It wouldn't be a bad idea.  Of course, you'd also need to update Tools/script/diff.py.  Tests should be added as well, since we have started adding tests for things in Tools.   The tests should be written first, to make sure that the behavior of 'diff' does not change, since I know there are people actively using it (on Windows).

I think it would also be a good idea to change the docs so that the actual diff script is embedded in the docs (sphinx has a directive for doing that), rather that duplicating the code.

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

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

From report at bugs.python.org  Sat May  2 04:36:20 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 02:36:20 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1430534180.83.0.474931850236.issue24110@psf.upfronthosting.co.za>


R. David Murray added the comment:

We should either make it work with byte filenames, or allow control of the filename encoding.  See also issue 20329.  Unfortunately that part is probably a new feature.  In the meantime the docs should be fixed: I believe we automatically encode the filename using the default zip filename codec (but someone should check).

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

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

From report at bugs.python.org  Sat May  2 06:30:28 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 May 2015 04:30:28 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1430541028.26.0.88236344501.issue24110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, the note is outdated and incorrect. First, general unicode filename are allowed. They are encoded with UTF-8 internally. Second, currently there is no way to create an entry without encoding the filename to UTF-8 (if it is not ASCII-only). So you can't create ZIP file with arbitrary encoding (e.g. cp866) for old DOS/Windows unzippers.

Adding support of bytes filenames is different issue (issue10757).

----------
nosy: +serhiy.storchaka
stage:  -> needs patch
versions:  -Python 3.6

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

From report at bugs.python.org  Sat May  2 06:59:52 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 02 May 2015 04:59:52 +0000
Subject: [docs] [issue24082] Obsolete note in argument parsing
	(c-api/arg.rst)
In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za>
Message-ID: <1430542792.72.0.905441479543.issue24082@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

About wording see also issue23088.

About possible deprecating see issue24009.

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

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

From report at bugs.python.org  Sat May  2 09:34:36 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 02 May 2015 07:34:36 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430552076.06.0.469206723616.issue24081@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

Not true (on 3.3 & 2.7).

>>> import sys
>>> import x
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/x.py", line 1, in <module>
    import y
  File "/tmp/y.py", line 1, in <module>
    1/0
ZeroDivisionError: division by zero
>>> sys.modules['x']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'x'
>>> sys.modules['y']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'y'

For 3.4, PEP 451 explicitly specifies ``del sys.modules[spec.name]`` if ``loader.exec_module`` fails [0].

[0] https://www.python.org/dev/peps/pep-0451/#how-loading-will-work

----------

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

From report at bugs.python.org  Sat May  2 10:47:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 May 2015 08:47:46 +0000
Subject: [docs] [issue24060] Clearify necessities for logging with timestamps
In-Reply-To: <1429996624.15.0.693068386122.issue24060@psf.upfronthosting.co.za>
Message-ID: <20150502084743.11922.69219@psf.io>


Roundup Robot added the comment:

New changeset 5ce760e2cc59 by Vinay Sajip in branch '2.7':
Issue #24060: Made logging.Formatter documentation a little clearer.
https://hg.python.org/cpython/rev/5ce760e2cc59

New changeset 88c141233d1e by Vinay Sajip in branch '3.4':
Issue #24060: Made logging.Formatter documentation a little clearer.
https://hg.python.org/cpython/rev/88c141233d1e

New changeset 1c72e9c1b3b4 by Vinay Sajip in branch 'default':
Closes #24060: Merged documentation update from 3.4.
https://hg.python.org/cpython/rev/1c72e9c1b3b4

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

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

From report at bugs.python.org  Sat May  2 14:31:29 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 12:31:29 +0000
Subject: [docs] [issue24110] zipfile.ZipFile.write() does not accept bytes
	arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1430569889.79.0.904967743329.issue24110@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I *thought* there was an issue for that, but I didn't find it when I searched.  So this is just a doc issue to fix the docs to reflect current reality.

----------

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

From report at bugs.python.org  Sat May  2 17:21:24 2015
From: report at bugs.python.org (Keith Gray)
Date: Sat, 02 May 2015 15:21:24 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>
Message-ID: <1430580084.26.0.188873183116.issue24109@psf.upfronthosting.co.za>


Keith Gray added the comment:

I took a look at Tools/scripts/diff.py and it looks like it got converted to use argparse 9 months ago. I think I should be able to just include that in the difflib documentation directly.

My next question is which branches need to have this changed? Do I just make the documentation change to the default branch or do I need to change it in 2.7, 3.2, 3.3, and 3.4 as well?

----------

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

From report at bugs.python.org  Sat May  2 17:50:38 2015
From: report at bugs.python.org (Keith Gray)
Date: Sat, 02 May 2015 15:50:38 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>
Message-ID: <1430581838.28.0.828848008871.issue24109@psf.upfronthosting.co.za>


Keith Gray added the comment:

Here is the patch. I have tested it against tip. Let me know if you need anything else.

----------
keywords: +patch
Added file: http://bugs.python.org/file39268/issue-24109.patch

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

From report at bugs.python.org  Sat May  2 18:46:22 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 16:46:22 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>
Message-ID: <1430585182.89.0.707415205292.issue24109@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since the Tools script was only changed in 3.5 (I was looking at the wrong branch), I think the docs should only be changed for 3.5.

----------
stage:  -> commit review
versions:  -Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat May  2 18:46:27 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 16:46:27 +0000
Subject: [docs] [issue24109] Documentation for difflib uses optparse
In-Reply-To: <1430509130.15.0.798081297108.issue24109@psf.upfronthosting.co.za>
Message-ID: <1430585187.08.0.135143559832.issue24109@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.5 -Python 3.6

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

From report at bugs.python.org  Sat May  2 19:15:11 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 17:15:11 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430586911.08.0.358907290196.issue24081@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, I can't reproduce it either, neither in python3 nor python2.  Brett, is this left over from a long time ago?

Heh.  I just tried another experiment and got an interesting result:

rdmurray at pydev:~/python/p34>cat temp1.py
import temp2
foo = 1
rdmurray at pydev:~/python/p34>cat temp2.py
import temp1

badval

rdmurray at pydev:~/python/p34>./python
Python 3.4.3+ (3.4:b53cfcfdfe47, May  2 2015, 12:51:46) 
[GCC 4.8.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import temp2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rdmurray/python/p34/temp2.py", line 3, in <module>
    badval
NameError: name 'badval' is not defined
>>> import sys
>>> sorted(sys.modules.keys())
['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport']
>>> import temp1
>>> temp1.temp2
<module 'temp2' from '/home/rdmurray/python/p34/temp2.py'>
>>> sorted(sys.modules.keys())
['__main__', '_codecs', '_collections_abc', '_frozen_importlib', '_imp', '_io', '_sitebuiltins', '_stat', '_sysconfigdata', '_thread', '_warnings', '_weakref', '_weakrefset', 'abc', 'atexit', 'builtins', 'codecs', 'encodings', 'encodings.aliases', 'encodings.latin_1', 'encodings.utf_8', 'errno', 'genericpath', 'io', 'marshal', 'os', 'os.path', 'posix', 'posixpath', 'readline', 'rlcompleter', 'signal', 'site', 'stat', 'sys', 'sysconfig', 'temp1', 'zipimport']


More or less the reverse of the passage in question.

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

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

From report at bugs.python.org  Sat May  2 19:22:00 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 17:22:00 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430587320.72.0.0919565315533.issue24081@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that calling reload on temp1.temp2 will fail with an error that temp2 is not in sys.modules.  So maybe the caveat needs rewording rather than deletion.

----------

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

From report at bugs.python.org  Sat May  2 19:36:34 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 May 2015 17:36:34 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430588194.17.0.418903370028.issue24081@psf.upfronthosting.co.za>


Eric Snow added the comment:

Either the docs are out-of-date or they are really poorly worded.  Most likely it's the former, but I'm taking a look.

----------

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

From report at bugs.python.org  Sat May  2 19:53:42 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 17:53:42 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1430589222.53.0.0752883811341.issue23088@psf.upfronthosting.co.za>


R. David Murray added the comment:

Added some review comments.

----------

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

From report at bugs.python.org  Sat May  2 20:01:04 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 May 2015 18:01:04 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430589664.05.0.0739090622747.issue24081@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've verified that the documentation is correct under Python 2.3.  The behavior changed under Python 2.4 (and the docs were not updated).  I expect that the change in behavior is an unintended consequence of a change in the import system for 2.4.  There were 7 in 2.4, so I'm checking to see which did it.

FYI, our backward-compatibility policy would preclude a change like this, which is why I think it was unintentional.  That no one noticed implies that we did not have a unit test for the case and that folks really weren't relying on the behavior anyway (at least not enough to open a bug). :)  I suppose there could be an old bug on this, but if that the case then someone decided not to change it back.

Regardless, the docs should be fixed by removing the referenced paragraph.

----------

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

From report at bugs.python.org  Sat May  2 20:03:15 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 18:03:15 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430589795.1.0.0980389478048.issue24081@psf.upfronthosting.co.za>


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


----------
stage:  -> commit review

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

From report at bugs.python.org  Sat May  2 20:14:53 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 May 2015 18:14:53 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430590493.65.0.595171442387.issue24081@psf.upfronthosting.co.za>


Eric Snow added the comment:

I'm pretty sure this is the culprit:

changeset:   32882:331e60d8ce6da19b168849418776fea0940787ec
branch:      legacy-trunk
user:        Tim Peters <tim.peters at gmail.com>
date:        Mon Aug 02 03:52:12 2004 +0000
summary:     PyImport_ExecCodeModuleEx():  remove module from sys.modules in error cases.

----------

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

From report at bugs.python.org  Sat May  2 20:17:16 2015
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 May 2015 18:17:16 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430590636.64.0.473938660129.issue24081@psf.upfronthosting.co.za>


Eric Snow added the comment:

patch LGTM for the 3 branches.

----------

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

From report at bugs.python.org  Sat May  2 21:02:55 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 May 2015 19:02:55 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <20150502190252.8141.18095@psf.io>


Roundup Robot added the comment:

New changeset 3cdeafd18e61 by R David Murray in branch '3.4':
#24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/3cdeafd18e61

New changeset d57e0c6d292d by R David Murray in branch 'default':
Merge: #24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/d57e0c6d292d

New changeset fd1549dd8065 by R David Murray in branch '2.7':
#24081: Remove obsolete caveat from import docs.
https://hg.python.org/cpython/rev/fd1549dd8065

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

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

From report at bugs.python.org  Sat May  2 21:03:50 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 19:03:50 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430403154.98.0.829139703368.issue24081@psf.upfronthosting.co.za>
Message-ID: <1430593430.74.0.126309976053.issue24081@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Petr.  (And Eric.)

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

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

From report at bugs.python.org  Sat May  2 21:09:49 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 May 2015 19:09:49 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za>
Message-ID: <20150502190946.98679.95278@psf.io>


Roundup Robot added the comment:

New changeset c5c65ef84a77 by R David Murray in branch '3.4':
#24108: Update fnmatch.translate example to show correct output.
https://hg.python.org/cpython/rev/c5c65ef84a77

New changeset cc6aed8ecb0d by R David Murray in branch 'default':
Merge: #24108: Update fnmatch.translate example to show correct output.
https://hg.python.org/cpython/rev/cc6aed8ecb0d

New changeset 5d356223f075 by R David Murray in branch '2.7':
#24108: Update fnmatch.translate example to show correct output.
https://hg.python.org/cpython/rev/5d356223f075

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

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

From report at bugs.python.org  Sat May  2 21:10:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 May 2015 19:10:55 +0000
Subject: [docs] [issue24108] fnmatch.translate('*.txt') fails
In-Reply-To: <1430509015.84.0.479562940364.issue24108@psf.upfronthosting.co.za>
Message-ID: <1430593855.68.0.489599797167.issue24108@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks Christophe and Merlijn.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun May  3 01:26:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 02 May 2015 23:26:59 +0000
Subject: [docs] [issue24081] Obsolete caveat in reload() docs
In-Reply-To: <1430590493.65.0.595171442387.issue24081@psf.upfronthosting.co.za>
Message-ID: <CADiSq7d3jcBx-vgTj1M2U_+iFMHUP6HYVWnp7c5UdRrghr8bOQ@mail.gmail.com>


Nick Coghlan added the comment:

I vaguely recall discussing that change, and my recollection is that it was
deliberate in order to evict improperly configured modules - we didn't
count it as a significant compatibility break because it solely affected an
error handling path.

I guess we never thought to check if the old misbehaviour was formally
documented.

----------

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

From rdmurray at bitdance.com  Sat May  2 19:53:26 2015
From: rdmurray at bitdance.com (rdmurray at bitdance.com)
Date: Sat, 02 May 2015 17:53:26 -0000
Subject: [docs] Document that PyUnicode_AsUTF8() returns a
 null-terminated string (issue 23088)
Message-ID: <20150502175326.9072.20684@psf.upfronthosting.co.za>


http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytearray.rst
File Doc/c-api/bytearray.rst (right):

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytearray.rst#newcode68
Doc/c-api/bytearray.rst:68: null byte appended, even when the array
already contains null bytes.
Based on the other changes, I think you should drop the "even when"
clause.  There is always an extra null byte appended to whatever the
Python content of the object is, and it actually makes it more confusing
to add that extra clause, IMO.

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst
File Doc/c-api/bytes.rst (right):

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode139
Doc/c-api/bytes.rst:139: Return the contents of *o*.  The pointer refers
to the internal buffer of
Return a pointer to the contents of *o*.

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode141
Doc/c-api/bytes.rst:141: bytes object already contains null bytes.  The
data must not be
OK, this makes no sense to me.  What exactly is the object here?  It
sounds like it is a bytes object, in which case it makes no logical
sense to say "even when the bytes object already contains null bytes". 
Is the internal buffer of the object N+1 bytes, where the first N bytes
comprise the "bytes object" from the point of view of Python, but
internally the buffer that holds those bytes has an additional
(len(bytesobject)+1) position that contains a null byte?  If that is the
case, I think this should read "The pointer refers to the internal
buffer of *o*, which consists of len(o)+1 bytes, the last of which is
always a null byte (regardless of whether or not there are any other
null bytes in the buffer)."

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode155
Doc/c-api/bytes.rst:155: Return a null-terminated representation of the
contents of the object *obj*
If you removed 'representation' above, you should do it here to (and
that seems to make sense to me).

http://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode162
Doc/c-api/bytes.rst:162: The buffer refers to an internal buffer of
*obj*, not a copy. The data
If I'm right in my comment above, this should probably say "buffer of
*obj*, which includes an additional null byte after the bytes that
constitute the content of the bytes object".

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

From report at bugs.python.org  Sun May  3 07:55:39 2015
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 May 2015 05:55:39 +0000
Subject: [docs] [issue24045] Behavior of large returncodes  (sys.exit(nn))
In-Reply-To: <1429836429.07.0.888331603842.issue24045@psf.upfronthosting.co.za>
Message-ID: <1430632539.17.0.40531666285.issue24045@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sun May  3 08:50:15 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 May 2015 06:50:15 +0000
Subject: [docs] [issue20749] shutil.unpack_archive(): security concerns not
	documented
In-Reply-To: <1393190017.96.0.0939250007559.issue20749@psf.upfronthosting.co.za>
Message-ID: <1430635815.47.0.164756961896.issue20749@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

If there is an agreed standard for security warnings I'll prepare a patch for this.

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

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

From report at bugs.python.org  Sun May  3 16:39:28 2015
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 03 May 2015 14:39:28 +0000
Subject: [docs] [issue24118] http.client example is no longer valid
Message-ID: <1430663968.45.0.585003367103.issue24118@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

The example code for http.client shows www.python.org/parrot.spam return a 404:

https://docs.python.org/3/library/http.client.html#examples

>>> # Example of an invalid request
>>> conn.request("GET", "/parrot.spam")
>>> r2 = conn.getresponse()
>>> print(r2.status, r2.reason)
404 Not Found


However it no longer does that, instead it returns a 301 Moved Permanently.

----------
assignee: docs at python
components: Documentation
messages: 242483
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: http.client example is no longer valid
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  3 18:14:46 2015
From: report at bugs.python.org (Carol Willing)
Date: Sun, 03 May 2015 16:14:46 +0000
Subject: [docs] [issue10965] dev task of documenting undocumented APIs
In-Reply-To: <1295566423.14.0.859020697485.issue10965@psf.upfronthosting.co.za>
Message-ID: <1430669686.22.0.108730305204.issue10965@psf.upfronthosting.co.za>


Carol Willing added the comment:

Add key points from linked email in msg126662 to documentation section of the devguide. 

* provide developers guidance on how to document undocumented APIs
* when and how to use __all__
* include rules from the linked email
* highlight "do no harm" to existing users as discussed in email

----------
assignee:  -> docs at python
components: +Devguide
nosy: +docs at python, ezio.melotti, willingc

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

From report at bugs.python.org  Sun May  3 18:21:19 2015
From: report at bugs.python.org (Petr Viktorin)
Date: Sun, 03 May 2015 16:21:19 +0000
Subject: [docs] [issue24082] Obsolete note in argument parsing
	(c-api/arg.rst)
In-Reply-To: <1430403570.61.0.800757161817.issue24082@psf.upfronthosting.co.za>
Message-ID: <1430670078.99.0.846870637073.issue24082@psf.upfronthosting.co.za>


Petr Viktorin added the comment:

The note is *correct* concerning the length, but I don't think it's relevant: in a NUL-terminated string without embedded NULs, the length is unambiguous.

The other issues are about "u" itself, not the note. (I have nothing against the "it is recommended to use u# or U instead" part, but the reasons the note gives are wrong and irrelevant, respectively.)

----------

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

From report at bugs.python.org  Sun May  3 19:00:46 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 May 2015 17:00:46 +0000
Subject: [docs] [issue24118] http.client example is no longer valid
In-Reply-To: <1430663968.45.0.585003367103.issue24118@psf.upfronthosting.co.za>
Message-ID: <20150503170043.8938.96763@psf.io>


Roundup Robot added the comment:

New changeset 71ec881d8347 by Benjamin Peterson in branch '3.4':
update example, since python.org is HTTPS-only now (closes #24118)
https://hg.python.org/cpython/rev/71ec881d8347

New changeset 376c2d81d0e2 by Benjamin Peterson in branch '2.7':
update example, since python.org is HTTPS-only now (closes #24118)
https://hg.python.org/cpython/rev/376c2d81d0e2

New changeset 07571d2968b0 by Benjamin Peterson in branch 'default':
merge 3.4 (#24118)
https://hg.python.org/cpython/rev/07571d2968b0

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

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

From report at bugs.python.org  Sun May  3 20:58:14 2015
From: report at bugs.python.org (lf)
Date: Sun, 03 May 2015 18:58:14 +0000
Subject: [docs] [issue24121] collections page doesn't
Message-ID: <1430679494.06.0.338700980096.issue24121@psf.upfronthosting.co.za>


Changes by lf <thereallucasfink at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, lf
priority: normal
severity: normal
status: open
title: collections page doesn't
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  3 20:58:37 2015
From: report at bugs.python.org (lf)
Date: Sun, 03 May 2015 18:58:37 +0000
Subject: [docs] [issue24121] collections page doesn't mention that deques
	are mutable
Message-ID: <1430679517.22.0.598692540788.issue24121@psf.upfronthosting.co.za>


Changes by lf <thereallucasfink at gmail.com>:


----------
title: collections page doesn't -> collections page doesn't mention that deques are mutable

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

From report at bugs.python.org  Mon May  4 02:09:40 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 May 2015 00:09:40 +0000
Subject: [docs] [issue24121] collections page doesn't mention that deques
	are mutable
Message-ID: <1430698180.76.0.211782329748.issue24121@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Mutability is conferred by the presence of mutating methods.  Deques are documented to have append, pop, extend, appendleft, popleft, extendleft, and rotate.   Also the examples all show mutations.

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon May  4 15:01:36 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Mon, 04 May 2015 13:01:36 +0000
Subject: [docs] [issue24124] Two versions of instructions for installing
	Python	modules
Message-ID: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za>


New submission from Skip Montanaro:

I was hunting around the current website for notes on installing Python. Couldn't find any (BTW), so I looked in the Python source. Imagine my surprise to find two apparently overlapping files describing how to build Python modules:

./Doc/install/index.rst
./Doc/installing/index.rst

The former is marked "Legacy version." The latter seems to cover mostly installation of third-party modules using tools like pip. The former covers distutils.  Oddly enough, the "legacy" version seems to have been updated more recently than the presumably current version. Do we really need to keep both versions around at this point? Should they be merged into a single document? If they are to both be retained, should the legacy version be marked as such more clearly and refer readers to the pip/pyvenv/virtualenv version?

----------
assignee: docs at python
components: Documentation
messages: 242555
nosy: docs at python, skip.montanaro
priority: normal
severity: normal
status: open
title: Two versions of instructions for installing Python modules
versions: Python 3.5

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

From report at bugs.python.org  Mon May  4 16:10:50 2015
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 04 May 2015 14:10:50 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <1430748650.29.0.345720111007.issue24088@psf.upfronthosting.co.za>


Jim Jewett added the comment:

OK, then how about

Current:
"""
When a generator function is called, it returns an iterator known as a generator. That generator then controls the execution of a generator function. The execution starts when one of the generator?s methods is called.
"""

Proposed:
"""
When a generator function is called, it does not complete its execution immediately.  Instead, it keeps its execution frame intact, and returns a special kind of iterator known as a generator. The iteration starts when one of the generator?s methods is called, and the generator executes within the existing generator frame, rather than creating a new one.
"""

This still seems to suggest that the generator uses the same frame as the generator function that created it; I was not aware that this was a guarantee.  (Reusing the same frame, yes.  Reusing that particular frame, no.)

----------

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

From report at bugs.python.org  Mon May  4 16:22:31 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 May 2015 14:22:31 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <1430749351.41.0.731297950498.issue24088@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think anything about frames is guaranteed as part of the language, so I'm not sure that mention of it belongs in the description.  Personally, I find your reformulation more confusing that the original with 'a' replaced by 'the'.

----------

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

From report at bugs.python.org  Tue May  5 21:03:50 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 May 2015 19:03:50 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <20150505190346.76602.20910@psf.io>


Roundup Robot added the comment:

New changeset b87d96e0708e by Guido van Rossum in branch '3.4':
Issue 24088: Clarify semantics of yield expression.
https://hg.python.org/cpython/rev/b87d96e0708e

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

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

From report at bugs.python.org  Tue May  5 21:04:43 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 May 2015 19:04:43 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <20150505190441.7810.12616@psf.io>


Roundup Robot added the comment:

New changeset 6e59d82d3d09 by Guido van Rossum in branch 'default':
Issue 24088: Clarify semantics of yield expression (merge from 3.4).
https://hg.python.org/cpython/rev/6e59d82d3d09

----------

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

From report at bugs.python.org  Tue May  5 21:04:56 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 May 2015 19:04:56 +0000
Subject: [docs] [issue24088] yield expression confusion
In-Reply-To: <1430431401.04.0.279681216808.issue24088@psf.upfronthosting.co.za>
Message-ID: <1430852696.26.0.412866421415.issue24088@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  5 21:24:44 2015
From: report at bugs.python.org (levkivskyi)
Date: Tue, 05 May 2015 19:24:44 +0000
Subject: [docs] [issue24128] Documentation links are forwarded to Python 2
Message-ID: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za>


New submission from levkivskyi:

Links to Python library documentation such as:
http://docs.python.org/library/functions.html
http://docs.python.org/library/itertools.html
http://docs.python.org/library/functools.html
etc.
are automatically forwarded to the Python 2 versions, namely to:
https://docs.python.org/2/library/functions.html
https://docs.python.org/2/library/itertools.html
https://docs.python.org/2/library/functools.html

At the same time docs.python.org is forwarded to Python 3 version https://docs.python.org/3/

I believe that all the documentation links should be forwarded to the current version that is Python 3.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 242613
nosy: docs at python, levkivskyi
priority: normal
severity: normal
status: open
title: Documentation links are forwarded to Python 2
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Tue May  5 21:27:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2015 19:27:37 +0000
Subject: [docs] [issue24128] Documentation links are forwarded to Python 2
In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za>
Message-ID: <1430854057.57.0.306507344117.issue24128@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe that this is intentional, so that old "deep" links do not break.  Georg can say for sure.

----------
nosy: +georg.brandl, r.david.murray

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

From report at bugs.python.org  Tue May  5 21:35:29 2015
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 05 May 2015 19:35:29 +0000
Subject: [docs] [issue24128] Documentation links are forwarded to Python 2
In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za>
Message-ID: <55491B71.3070405@egenix.com>


Marc-Andre Lemburg added the comment:

On 05.05.2015 21:24, levkivskyi wrote:
> 
> Links to Python library documentation such as:
> http://docs.python.org/library/functions.html
> http://docs.python.org/library/itertools.html
> http://docs.python.org/library/functools.html
> etc.
> are automatically forwarded to the Python 2 versions, namely to:
> https://docs.python.org/2/library/functions.html
> https://docs.python.org/2/library/itertools.html
> https://docs.python.org/2/library/functools.html
> 
> At the same time docs.python.org is forwarded to Python 3 version https://docs.python.org/3/
> 
> I believe that all the documentation links should be forwarded to the current version that is Python 3.

This is intentional. All new links to Python documentation
should include the version number. To keep existing old
links to the documentation working, they redirect to the
Python 2 version of the documentation.

----------
nosy: +lemburg

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

From report at bugs.python.org  Tue May  5 21:44:10 2015
From: report at bugs.python.org (levkivskyi)
Date: Tue, 05 May 2015 19:44:10 +0000
Subject: [docs] [issue24128] Documentation links are forwarded to Python 2
In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za>
Message-ID: <1430855050.09.0.345768385698.issue24128@psf.upfronthosting.co.za>


levkivskyi added the comment:

Is it possible to check whether the Python 3 version exists and redirect to it and if not (like for http://docs.python.org/library/fpformat.html) then redirect to Python 2 ?

----------

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

From report at bugs.python.org  Tue May  5 21:52:04 2015
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 May 2015 19:52:04 +0000
Subject: [docs] [issue24128] Documentation links are forwarded to Python 2
In-Reply-To: <1430853884.35.0.631016737369.issue24128@psf.upfronthosting.co.za>
Message-ID: <1430855524.89.0.167358799235.issue24128@psf.upfronthosting.co.za>


R. David Murray added the comment:

That would defeat the purpose.  Existing links are intending to point to python2, not python3.

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

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

From report at bugs.python.org  Tue May  5 22:31:46 2015
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 May 2015 20:31:46 +0000
Subject: [docs] [issue24124] Two versions of instructions for installing
	Python	modules
In-Reply-To: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za>
Message-ID: <1430857906.35.0.252045619159.issue24124@psf.upfronthosting.co.za>


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


----------
nosy: +ncoghlan

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

From report at bugs.python.org  Tue May  5 22:44:35 2015
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 05 May 2015 20:44:35 +0000
Subject: [docs] [issue18713] Clearly document the use of PYTHONIOENCODING to
	set	surrogateescape
In-Reply-To: <1376320774.07.0.703505392881.issue18713@psf.upfronthosting.co.za>
Message-ID: <1430858675.74.0.807589860414.issue18713@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

The first thing that would come to my mind when reading Nick's proposed document (without first reading this bug report) is "So why the heck is this not the default?".

It would probably save a lot of people a lot of anger if there was also a brief explanation addressing this obvious first response :-).

----------
nosy: +nikratio

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

From report at bugs.python.org  Tue May  5 22:51:59 2015
From: report at bugs.python.org (levkivskyi)
Date: Tue, 05 May 2015 20:51:59 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
	execution model	documentation
Message-ID: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>


New submission from levkivskyi:

The documentation on execution model https://docs.python.org/3/reference/executionmodel.html contains the statement
"""
A class definition is an executable statement that may use and define names. These references follow the normal rules for name resolution. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods.
"""
However, the following code (taken from http://lackingrhoticity.blogspot.ch/2008/08/4-python-variable-binding-oddities.html):

x = "xtop"
y = "ytop"
def func():
    x = "xlocal"
    y = "ylocal"
    class C:
        print(x)
        print(y)
        y = 1
func()

prints

xlocal
ytop

In case of "normal rules for name resolution" it should rise UnboundLocalError.

I suggest replacing the mentioned statement with the following:
"""
A class definition is an executable statement that may use and define names. Free variables follow the normal rules for name resolution, bound variables are looked up in the global namespace. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods.
"""
or a similar one.

----------
assignee: docs at python
components: Documentation
messages: 242619
nosy: docs at python, levkivskyi
priority: normal
severity: normal
status: open
title: Incorrect (misleading) statement in the execution model documentation
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May  6 10:01:24 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 May 2015 08:01:24 +0000
Subject: [docs] [issue24124] Two versions of instructions for installing
	Python	modules
In-Reply-To: <1430744496.1.0.475235677565.issue24124@psf.upfronthosting.co.za>
Message-ID: <1430899284.72.0.714287613711.issue24124@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As far as I'm aware, it's only confusing if you're poking around in the source tree, rather than using the built docs at docs.python.org (where the link to the legacy docs is now hidden away inside the distutils module docs).

The legacy docs remain in place to preserve existing deep links and because they're the only current documentation of various distutils details that are needed to *implement* tools like pip and setuptools.

In a more ideal world, we'd have a distutils expert with the time to go through the legacy docs, cull the outdated stuff, and lift the rest up into the distutils module documentation, but all the folks that might plausibly have the expertise to do that also have far more interesting things to do with their time :(

----------

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

From report at bugs.python.org  Wed May  6 15:18:47 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 May 2015 13:18:47 +0000
Subject: [docs] [issue24136] document PEP 448
Message-ID: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

PEP 448 has been implemented (#2292), but the documentation hasn't been updated. Updating the documentation will improve looking through

Doc/reference/*

and making sure the documentation (and grammar) for calls and assignments is updated for PEP 448's new syntax.

I'm marking this as "easy" because it might be a good first bug.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 242668
nosy: benjamin.peterson, docs at python
priority: high
severity: normal
stage: needs patch
status: open
title: document PEP 448
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu May  7 22:09:24 2015
From: report at bugs.python.org (Geoff Shannon)
Date: Thu, 07 May 2015 20:09:24 +0000
Subject: [docs] [issue22865] Document how to make pty.spawn not copy data
In-Reply-To: <1415901686.09.0.50650588621.issue22865@psf.upfronthosting.co.za>
Message-ID: <1431029363.98.0.544658122152.issue22865@psf.upfronthosting.co.za>


Geoff Shannon added the comment:

Okay, I just found another way to achieve the same effect of letting the _read function ignore data but not inadvertantly close the stream.  It relies on the fact that terminals will ignore null bytes fed to them.

Now there are no code changes required, just an addition to the documentation.

----------
components:  -Library (Lib)
title: Allow pty.spawn to ignore data to copy -> Document how to make pty.spawn not copy data
Added file: http://bugs.python.org/file39313/pty.patch

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

From report at bugs.python.org  Fri May  8 00:10:35 2015
From: report at bugs.python.org (Devin Jeanpierre)
Date: Thu, 07 May 2015 22:10:35 +0000
Subject: [docs] [issue24144] Docs discourage use of binascii.unhexlify etc.
Message-ID: <1431036635.15.0.698772318331.issue24144@psf.upfronthosting.co.za>


New submission from Devin Jeanpierre:

Maybe the functions should be split up into those you shouldn't need to call directly, and those you should? I find it unlikely that you're supposed to use codecs.encode(..., 'hex') and codecs.decode(..., 'hex') instead of binascii (the only other thing, AFAIK, that works in both 2 and 3).

Relevant quote starts with: "Normally, you will not use these functions directly"

https://docs.python.org/2/library/binascii
https://docs.python.org/3/library/binascii

----------
assignee: docs at python
components: Documentation
messages: 242737
nosy: Devin Jeanpierre, docs at python
priority: normal
severity: normal
status: open
title: Docs discourage use of binascii.unhexlify etc.
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  8 00:51:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 May 2015 22:51:21 +0000
Subject: [docs] [issue24144] Docs discourage use of binascii.unhexlify etc.
In-Reply-To: <1431036635.15.0.698772318331.issue24144@psf.upfronthosting.co.za>
Message-ID: <1431039081.3.0.401648322698.issue24144@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, actually, using codecs would be the most straightforward way to achieve portability.  The usual way to get hex in python2 was encode('hex'), which uses the codec.  But if you want to use hexlify instead, I don't see any reason not to.  There's no reason to change the binascii module description, though, since it is talking about normal code, not 2/3 shared source code (where you do sometimes have to jump through somewhat awkward hoops).

(The One Obvious Way starting with 3.5 will be b'abcde'.hex(), but of course that isn't python2 compatible.)

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

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

From kxepal at gmail.com  Fri May  8 01:25:12 2015
From: kxepal at gmail.com (Alexander Shorin)
Date: Fri, 8 May 2015 02:25:12 +0300
Subject: [docs] asyncio.Semaphore.release is not a coroutine
Message-ID: <CAHdjipJWVawj83X+bWHOMzEAAhD5PJ9Rvb1X58RBwUNCGc-Ahw@mail.gmail.com>

Hi docs@ team!

Basically, asyncio.Semaphore.release method has a coroutine prefix in docs:
https://docs.python.org/3/library/asyncio-sync.html#asyncio.Semaphore.release

But in the code it has not such wrapper:
https://hg.python.org/cpython/file/b4cbecbc0781/Lib/asyncio/locks.py#l431

The exact type of .release() method is very important as coroutines
cannot be used in Future's on done callbacks and according
documentation it's not possible to do with Semaphore.release while
it's not a true.

--
,,,^..^,,,

From andrew.svetlov at gmail.com  Fri May  8 13:16:30 2015
From: andrew.svetlov at gmail.com (Andrew Svetlov)
Date: Fri, 8 May 2015 14:16:30 +0300
Subject: [docs] asyncio.Semaphore.release is not a coroutine
In-Reply-To: <CAHdjipJWVawj83X+bWHOMzEAAhD5PJ9Rvb1X58RBwUNCGc-Ahw@mail.gmail.com>
References: <CAHdjipJWVawj83X+bWHOMzEAAhD5PJ9Rvb1X58RBwUNCGc-Ahw@mail.gmail.com>
Message-ID: <CAL3CFcUuikPEqHvqedNHjE9jvxE29OZFcoJ+-h0QfGnsnQq74w@mail.gmail.com>

Fixed in 7eb524cbe6e5.
Thanks for report!

On Fri, May 8, 2015 at 2:25 AM, Alexander Shorin <kxepal at gmail.com> wrote:
> Hi docs@ team!
>
> Basically, asyncio.Semaphore.release method has a coroutine prefix in docs:
> https://docs.python.org/3/library/asyncio-sync.html#asyncio.Semaphore.release
>
> But in the code it has not such wrapper:
> https://hg.python.org/cpython/file/b4cbecbc0781/Lib/asyncio/locks.py#l431
>
> The exact type of .release() method is very important as coroutines
> cannot be used in Future's on done callbacks and according
> documentation it's not possible to do with Semaphore.release while
> it's not a true.
>
> --
> ,,,^..^,,,
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs



-- 
Thanks,
Andrew Svetlov

From gerben at treora.com  Fri May  8 13:49:02 2015
From: gerben at treora.com (Gerben)
Date: Fri, 08 May 2015 14:49:02 +0300
Subject: [docs] small errors in grammar definition
Message-ID: <2017786.PiSvK2bNs0@tok>

Hi, something looks wrong in the syntax definition of function definitions (python 3). At least, there is one unmatched closing parethesis at the end of parameter_list, but I think somebody should check the whole thing.
See it annotated here: https://via.hypothes.is/https://docs.python.org/3/reference/compound_stmts.html#function-definitions
Cheers,

Gerben


From report at bugs.python.org  Fri May  8 16:03:49 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 May 2015 14:03:49 +0000
Subject: [docs] [issue16392] import crashes on circular imports in ext
	modules
In-Reply-To: <1351946554.54.0.101006341814.issue16392@psf.upfronthosting.co.za>
Message-ID: <1431093829.53.0.159656063992.issue16392@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, the resolution of this issue will be to add documentation.  Someone should turn Stefan's comment into a patch.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 3.5 -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May  8 22:51:20 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 May 2015 20:51:20 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
	execution model	documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1431118280.67.0.622407875563.issue24129@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May  9 13:02:34 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 09 May 2015 11:02:34 +0000
Subject: [docs] [issue18789] XML Vunerability Table Unclear
In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>
Message-ID: <1431169353.99.0.998570717592.issue18789@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Joe The latest documentation has an additional sentence above the table "The following table gives an overview of the known attacks and whether the various modules are vulnerable to them." and the table has been changed to say Yes or No.  Is this okay with you?

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

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

From report at bugs.python.org  Sat May  9 17:19:17 2015
From: report at bugs.python.org (ramiro)
Date: Sat, 09 May 2015 15:19:17 +0000
Subject: [docs] [issue24148] 'cum' not a valid sort key for
	pstats.Stats.sort_stats
Message-ID: <1431184757.15.0.93515789631.issue24148@psf.upfronthosting.co.za>


New submission from ramiro:

On the documentation page "The Python Profilers" https://docs.python.org/3.4/library/profile.html#instant-user-s-manual the following example is given:

p.sort_stats('time', 'cum').print_stats(.5, 'init')

This raises a KeyError, because 'cum' is not available as a sort key to pstats.Stats.sort_stats. As per the documentation of this method (https://docs.python.org/3.4/library/profile.html#the-stats-class) you can either use 'cumulative' or 'cumtime', which both work as expected.

Since 'cumulative' is used a few examples earlier I suggest to use that for consistency.

Tested with the following Python version:

Python 3.4.3 on Ubuntu 15.04

----------
assignee: docs at python
components: Documentation
messages: 242812
nosy: docs at python, ramiro
priority: normal
severity: normal
status: open
title: 'cum' not a valid sort key for pstats.Stats.sort_stats
type: enhancement
versions: Python 3.4

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

From report at bugs.python.org  Mon May 11 03:33:30 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2015 01:33:30 +0000
Subject: [docs] [issue24161] PyIter_Check returns false positive for objects
	of type	instance
In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za>
Message-ID: <1431308010.41.0.831246479822.issue24161@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> but then, what would be the use case of PyIter_Check
> outside of python core?

You could still use it anywhere.  It will give a correct result in the cases of extension modules, builtin types, and new-style classes.  It will give a false positive in the case of old-style classes.  The latter case doesn't seem to be of much consequence (there is a still a TypeError raised when next() is called), so you just find out a bit later than you otherwise would (I believe that is why this is why we haven't gotten a bug report in the 13+ years this code has existed).

The feature is imperfect, incomplete and not as useful as it could be.
But this ship sailed a long time ago.  It is far too late for redesign (and risking unintended breakage).

FWIW, PyIter_Check() is used several times in the Python core: sqlite, cPickle, and iter().  In those examples, there seem to be no adverse consequences for the false positive because we still get a TypeError downstream when the actual call is made to next().

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
priority: normal -> low
stage:  -> needs patch

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

From report at bugs.python.org  Mon May 11 05:11:00 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2015 03:11:00 +0000
Subject: [docs] [issue24161] PyIter_Check returns false positive for objects
	of type	instance
In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za>
Message-ID: <1431313860.67.0.90120434408.issue24161@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file39338/doc_iter_check.diff

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

From report at bugs.python.org  Mon May 11 06:08:31 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2015 04:08:31 +0000
Subject: [docs] [issue18789] XML Vunerability Table Unclear
In-Reply-To: <1377008574.91.0.12100936862.issue18789@psf.upfronthosting.co.za>
Message-ID: <1431317311.33.0.51037256638.issue18789@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The table would still be more clear with "safe" and "vulnerable" entries.

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

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

From audition2007 at 163.com  Mon May 11 05:26:06 2015
From: audition2007 at 163.com (=?GBK?B?t6K8/sjL?=)
Date: Mon, 11 May 2015 11:26:06 +0800 (CST)
Subject: [docs] Question
Message-ID: <5d472d4d.978e.14d41021aac.Coremail.audition2007@163.com>

Hi,
why couldn't I download Python 2.7.10rc1 Documentation from this site https://docs.python.org/2/download.html now?
Thanks very much!


Allen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150511/9b1ceb52/attachment.html>

From report at bugs.python.org  Mon May 11 19:22:35 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 11 May 2015 17:22:35 +0000
Subject: [docs] [issue24161] PyIter_Check returns false positive for objects
	of type	instance
In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za>
Message-ID: <20150511172231.76621.59091@psf.io>


Roundup Robot added the comment:

New changeset 0f7795edca65 by Raymond Hettinger in branch '2.7':
Issue #24161:  Document that PyIter_Check() returns false positives for old-style instances.
https://hg.python.org/cpython/rev/0f7795edca65

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

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

From report at bugs.python.org  Mon May 11 19:24:49 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 May 2015 17:24:49 +0000
Subject: [docs] [issue24161] PyIter_Check returns false positive for objects
	of type	instance
In-Reply-To: <1431291334.61.0.842611161748.issue24161@psf.upfronthosting.co.za>
Message-ID: <1431365089.03.0.779539787435.issue24161@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May 12 08:31:59 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 May 2015 06:31:59 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1431412319.59.0.927953500342.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

script_helper was moved to the test.support package in issue 9517, so this issue is just about adding the docs now.

----------
dependencies: +Make test.script_helper more comprehensive, and use it in the test suite -Refactor the test_runpy walk_package support code into a common location
title: Rename and document test.script_helper as test.support.script_helper -> Document test.support.script_helper
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Tue May 12 08:34:27 2015
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 May 2015 06:34:27 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1431412467.38.0.861121954069.issue18576@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Also noting that my draft docs are over a year old now, so they need to be reviewed against the current state of the helper module.

----------

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

From chukwuemekaigwe5 at gmail.com  Tue May 12 04:03:45 2015
From: chukwuemekaigwe5 at gmail.com (Emeka Igwe)
Date: Tue, 12 May 2015 02:03:45 +0000
Subject: [docs] Error: 404 not found
Message-ID: <1101593251-1431396641-cardhu_decombobulator_blackberry.rim.net-292221181-@b17.c3.bise7.blackberry>

I receive an error: 404 not found, when I try to download documentation
Sent from my BlackBerry wireless device from MTN

From gabofer82 at gmail.com  Tue May 12 14:07:05 2015
From: gabofer82 at gmail.com (gabriel fernandez)
Date: Tue, 12 May 2015 09:07:05 -0300
Subject: [docs] 404 on python docs page
Message-ID: <CAHRS2TrVxX5kDVR5+k-rWrhYp7e5dFRSWGq-6+ENC96HzmfyPg@mail.gmail.com>

Hi!

all links for downloads on https://docs.python.org/2/download.html get a
404 page.

Greetings!

-- 
Gabriel Fern?ndez
Desrrollador Web
www.openweb.com.uy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150512/f3a6a558/attachment.html>

From report at bugs.python.org  Tue May 12 16:25:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 12 May 2015 14:25:30 +0000
Subject: [docs] [issue23983] Update example in the pty documentation
In-Reply-To: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za>
Message-ID: <20150512142527.66039.34952@psf.io>


Roundup Robot added the comment:

New changeset e656bece13fa by Berker Peksag in branch '3.4':
Issue #23983: Update the pty module example.
https://hg.python.org/cpython/rev/e656bece13fa

New changeset 0be7c8f46378 by Berker Peksag in branch 'default':
Issue #23983: Update the pty module example.
https://hg.python.org/cpython/rev/0be7c8f46378

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

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

From report at bugs.python.org  Tue May 12 16:26:15 2015
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 12 May 2015 14:26:15 +0000
Subject: [docs] [issue23983] Update example in the pty documentation
In-Reply-To: <1429233448.23.0.72580455628.issue23983@psf.upfronthosting.co.za>
Message-ID: <1431440775.01.0.526415192963.issue23983@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May 13 06:06:07 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 May 2015 04:06:07 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1431489967.71.0.728294946612.issue24079@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another problem with tostring() is that it seems you have to call it with encoding="unicode". Perhaps it would be better to suggest code like "".join(element.itertext())?

I would also improve on J?r?me?s version by making the None case more explicit. And perhaps both attributes can be defined together, rather than giving a half-hearted definition linking between them:

.. attribute:: text
.. attribute:: tail

   The *text* attribute holds any text between the element's begin tag and the next tag. The *tail* attribute holds any text between the element's end tag and the next tag. These attributes are set to ``None`` if there is no text. For example, in the XML data ``<a><b>1<c>2<d/>3</c></b>4</a>``, the *a* element has ``None`` for both *text* and *tail* attributes, the *b* element has *text* ``"1"`` and *tail* ``"4"``, the *c* element has *text* ``"2"`` and *tail* ``None``, the *d* element has *text* ``None`` and *tail* ``"3"``.
   
   To collect the inner text of an element, use :meth:`itertext`, for example ``"".join(element.itertext())``.
   
   Applications may store arbitrary objects in these attributes.

----------
nosy: +vadmium

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

From elim at elinkage.net  Wed May 13 00:54:58 2015
From: elim at elinkage.net (elim)
Date: Tue, 12 May 2015 16:54:58 -0600
Subject: [docs] python 2.7 doc downooad page is broken
Message-ID: <20150512225458.baf1bd4c@elinkage.net>

python 2.7 doc downooad page is broken

From sviltodorov at gmail.com  Tue May 12 19:29:36 2015
From: sviltodorov at gmail.com (Svilen Todorov)
Date: Tue, 12 May 2015 18:29:36 +0100
Subject: [docs] Download links don't work
Message-ID: <CACR6kOywWcS8yYwMrMu0XamwgLy8pp=Uwb00cv29LamX7WyG_A@mail.gmail.com>

Hello,

The links for downloading the documentation at
https://docs.python.org/2/download.html don't seem to be functional.

Kind regards,
Svilen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150512/7700b99a/attachment.html>

From ymichaeld at yahoo.com  Tue May 12 17:54:22 2015
From: ymichaeld at yahoo.com (Michael Durbin)
Date: Tue, 12 May 2015 11:54:22 -0400
Subject: [docs] Broken links
Message-ID: <5552222E.6080506@yahoo.com>

on page https://docs.python.org/2/download.html

All of the download links return 404

From report at bugs.python.org  Wed May 13 08:21:32 2015
From: report at bugs.python.org (Mahmoud Hashemi)
Date: Wed, 13 May 2015 06:21:32 +0000
Subject: [docs] [issue24172] Errors in resource.getpagesize module
	documentation
Message-ID: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za>


New submission from Mahmoud Hashemi:

The resource module's description of resource.getpagesize is woefully misguiding. Reproduced in full for convenience:

resource.getpagesize()

    Returns the number of bytes in a system page. (This need not be the same as the hardware page size.) This function is useful for determining the number of bytes of memory a process is using. The third element of the tuple returned by getrusage() describes memory usage in pages; multiplying by page size produces number of bytes.

Besides being vague by not referring to the third element as ru_maxrss, the peak RSS for the process (i.e., not the current memory usage), tests on Linux, Darwin, and FreeBSD show the following:

  * Linux: ru_maxrss is in kilobytes
  * Darwin (OS X): ru_maxrss is in bytes
  * FreeBSD: ru_maxrss is in kilobytes (same as Linux)

Knowing the page size is probably useful to someone, but the misinformation has definitely sent more than one person down the wrong path here. Additionally, the correct information should be up in the getrusage() method documentation, closer to relevant field descriptions.

Mahmoud

----------
assignee: docs at python
components: Documentation
messages: 243043
nosy: docs at python, mahmoud
priority: normal
severity: normal
status: open
title: Errors in resource.getpagesize module documentation
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From mmmmmcclxxvii at gmail.com  Wed May 13 08:42:05 2015
From: mmmmmcclxxvii at gmail.com (MMMMMCCLXXVII)
Date: Wed, 13 May 2015 14:42:05 +0800
Subject: [docs] Can't download the doc
Message-ID: <047BD6A8-2212-4D71-966E-CA46C42A22FE@gmail.com>


I can?t download doc 2.7.9 from https://docs.python.org/2/download.html <https://docs.python.org/2/download.html>

It shows me the following window at all format .




Please fix it. Thank you





============================================================
Crayon Chaney



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/522af10c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2015-05-13 at 2.39.51 PM.png
Type: image/png
Size: 20773 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/522af10c/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: big-data-in-malaysia-19-638.jpg
Type: image/jpeg
Size: 99458 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/522af10c/attachment-0001.jpg>

From report at bugs.python.org  Wed May 13 09:42:20 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 May 2015 07:42:20 +0000
Subject: [docs] [issue24136] document PEP 448
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1431502940.59.0.0173046064439.issue24136@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/issue24136>
_______________________________________

From report at bugs.python.org  Wed May 13 10:42:10 2015
From: report at bugs.python.org (White_Rabbit)
Date: Wed, 13 May 2015 08:42:10 +0000
Subject: [docs] [issue24173] curses HOWTO/implementation disagreement
Message-ID: <1431506529.99.0.82682445605.issue24173@psf.upfronthosting.co.za>


New submission from White_Rabbit:

Similarly to issue 6771?, the curses HOWTO? talks about the curses.wrapper module and its curses.wrapper.wrapper function, but with python 2.7.5-ubuntu3 I already have the curses.wrapper function.

? https://bugs.python.org/issue6771
? https://docs.python.org/2/howto/curses.html

----------
assignee: docs at python
components: Documentation
messages: 243058
nosy: White_Rabbit, docs at python
priority: normal
severity: normal
status: open
title: curses HOWTO/implementation disagreement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 13 11:34:48 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 May 2015 09:34:48 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <20150513093444.82453.77245@psf.io>


Roundup Robot added the comment:

New changeset f7d82e40e472 by Raymond Hettinger in branch 'default':
Issue #23695:  Explain the  zip() example for clustering a data series into n-length groups.
https://hg.python.org/cpython/rev/f7d82e40e472

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

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

From report at bugs.python.org  Wed May 13 11:35:03 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 May 2015 09:35:03 +0000
Subject: [docs] [issue23695] idiom for clustering a data series into
	n-length groups
In-Reply-To: <1426637882.4.0.0938827316057.issue23695@psf.upfronthosting.co.za>
Message-ID: <1431509703.81.0.963369774154.issue23695@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May 13 11:48:30 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 May 2015 09:48:30 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <20150513094827.11928.58828@psf.io>


Roundup Robot added the comment:

New changeset 8440dda28ffe by Raymond Hettinger in branch '3.4':
Issue #19934:  Document *None* as an acceptable input to Counter.most_common([n])
https://hg.python.org/cpython/rev/8440dda28ffe

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

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

From report at bugs.python.org  Wed May 13 11:51:07 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 May 2015 09:51:07 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <20150513095104.11950.23886@psf.io>


Roundup Robot added the comment:

New changeset df708898f27b by Raymond Hettinger in branch '2.7':
Issue #19934:  Document *None* as an acceptable input to Counter.most_common([n])
https://hg.python.org/cpython/rev/df708898f27b

----------

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

From report at bugs.python.org  Wed May 13 11:51:38 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 May 2015 09:51:38 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <1431510698.0.0.827634230782.issue19934@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for pointing out the omission.

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

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

From report at bugs.python.org  Wed May 13 14:08:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 13 May 2015 12:08:49 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1431518929.29.0.406110315832.issue23088@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for looking at this David. I am posting utf8-null.v5.patch, which tweaks some of the wording.

----------
Added file: http://bugs.python.org/file39357/utf8-null.v5.patch

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

From vadmium+py at gmail.com  Wed May 13 13:43:54 2015
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 13 May 2015 11:43:54 -0000
Subject: [docs] Document that PyUnicode_AsUTF8() returns a
 null-terminated string (issue 23088)
Message-ID: <20150513114354.28558.1586@psf.upfronthosting.co.za>


https://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytearray.rst
File Doc/c-api/bytearray.rst (right):

https://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytearray.rst#newcode68
Doc/c-api/bytearray.rst:68: null byte appended, even when the array
already contains null bytes.
On 2015/05/02 19:53:26, r.david.murray wrote:
> Based on the other changes, I think you should drop the "even when"
clause. 
> There is always an extra null byte appended to whatever the Python
content of
> the object is, and it actually makes it more confusing to add that
extra clause,
> IMO.

Okay, will also do this for PyUnicode_AsUCS4Copy().

https://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst
File Doc/c-api/bytes.rst (right):

https://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode141
Doc/c-api/bytes.rst:141: bytes object already contains null bytes.  The
data must not be
On 2015/05/02 19:53:26, r.david.murray wrote:
> . . .  If that is
> the case, I think this should read "The pointer refers to the internal
buffer of
> *o*, which consists of len(o)+1 bytes, the last of which is always a
null byte
> (regardless of whether or not there are any other null bytes in the
buffer)."

Yes this is right. New patch will have wording based on this.

https://bugs.python.org/review/23088/diff/14381/Doc/c-api/bytes.rst#newcode162
Doc/c-api/bytes.rst:162: The buffer refers to an internal buffer of
*obj*, not a copy. The data
On 2015/05/02 19:53:26, r.david.murray wrote:
> If I'm right in my comment above, this should probably say "buffer of
*obj*,
> which includes an additional null byte after the bytes that constitute
the
> content of the bytes object".

I will probably put something like ?. . . buffer of *obj*, which
includes an additional null byte at the end (not counted in the
length).?

https://bugs.python.org/review/23088/

From report at bugs.python.org  Wed May 13 14:31:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2015 12:31:30 +0000
Subject: [docs] [issue24172] Errors in resource.getpagesize module
	documentation
In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za>
Message-ID: <1431520290.23.0.53339533218.issue24172@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed, we should probably be referring people to their system's man pages for the authoritative definition of most of these fields.

According to the man pages project getpagesize is no longer a POSIX API, and that should probably be noted as well (ie: it isn't present on all systems, and furthermore it is isn't accurate on all systems where it is present...apparently older GCCs got it wrong).

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

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

From report at bugs.python.org  Wed May 13 14:31:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 13 May 2015 12:31:51 +0000
Subject: [docs] [issue24172] Errors in resource.getpagesize module
	documentation
In-Reply-To: <1431498092.42.0.745658320728.issue24172@psf.upfronthosting.co.za>
Message-ID: <1431520311.48.0.588296900356.issue24172@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions:  -Python 3.2, Python 3.3, Python 3.6

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

From sigurdm at google.com  Wed May 13 15:06:13 2015
From: sigurdm at google.com (Sigurd Meldgaard)
Date: Wed, 13 May 2015 15:06:13 +0200
Subject: [docs] Logic operators description not general.
Message-ID: <CAGB19a0xpAxSvg0=Us9ouRYfrddL2LJsmnS60M440V8CBYMf_w@mail.gmail.com>

Both on
https://docs.python.org/2/library/stdtypes.html
https://docs.python.org/3/library/stdtypes.html

in the part: 4.2. Boolean Operations ? and, or, not
Says: This is a short-circuit operator, so it only evaluates the second
argument if the first one is False.
And several similar formulations.

It would be more correct to say:
This is a short-circuit operator, so it only evaluates the second argument
if the first one tests to a false value.

Thanks
Sigurd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/7e35ce3d/attachment.html>

From rjljr2 at gmail.com  Wed May 13 17:14:17 2015
From: rjljr2 at gmail.com (Ronald Legere)
Date: Wed, 13 May 2015 08:14:17 -0700
Subject: [docs] Python documentation missing
Message-ID: <CAEjkP-LQjy2q6o-kd2=GnBUTh-HHLrT+p_7qSAEFOq707GjAFQ@mail.gmail.com>

The links to the downloadable documentation for python 2.7 are 404 on this
page:

https://docs.python.org/2/download.html

Are they available somewhere????

-- 
Ron Legere (rjljr2 at gmail.com)
 *C'est le temps que tu as perdu pour ta rose qui fait ta rose si
importante*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/ece000e6/attachment.html>

From report at bugs.python.org  Wed May 13 17:25:51 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 May 2015 15:25:51 +0000
Subject: [docs] [issue19934] collections.Counter.most_common does not
	document `None`	as acceptable input.
In-Reply-To: <1386564878.42.0.684487648829.issue19934@psf.upfronthosting.co.za>
Message-ID: <20150513152548.25445.9402@psf.io>


Roundup Robot added the comment:

New changeset 68d653f9a2c9 by Andrew Kuchling in branch '2.7':
#19934: fix mangled wording
https://hg.python.org/cpython/rev/68d653f9a2c9

----------

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

From jackcbtricker at gmail.com  Wed May 13 17:40:42 2015
From: jackcbtricker at gmail.com (Jack Tricker)
Date: Wed, 13 May 2015 16:40:42 +0100
Subject: [docs] Cannot download Documentation?
Message-ID: <CAEcWN=DtOEfXJcsC08P=WNDjYp9aWt5Oro5PA1DyVP_3XHy=7A@mail.gmail.com>

File not found!

https://docs.python.org/2/download.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150513/0a5d7a7b/attachment.html>

From report at bugs.python.org  Wed May 13 19:02:35 2015
From: report at bugs.python.org (Eric Radman)
Date: Wed, 13 May 2015 17:02:35 +0000
Subject: [docs] [issue21791] Proper return status of os.WNOHANG is not
	always (0, 0)
In-Reply-To: <1403022188.82.0.702725813338.issue21791@psf.upfronthosting.co.za>
Message-ID: <1431536555.56.0.162968839129.issue21791@psf.upfronthosting.co.za>


Eric Radman added the comment:

Thanks for posting some simple examples. 

Here is the commit that I wrote to solve this problem when I encountered it in the wild:

https://bitbucket.org/tk0miya/testing.postgresql/commits/3f145860cfd91e3f03f24b87c4b3b41c3a974037

Closing since I am also not able to reproduce this using a simple example.

----------
resolution:  -> works for me
status: pending -> closed

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

From report at bugs.python.org  Wed May 13 23:36:24 2015
From: report at bugs.python.org (ppperry)
Date: Wed, 13 May 2015 21:36:24 +0000
Subject: [docs] [issue10977] Concrete obect C API considered harmful to
	subclasses of	builtin typesje
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1431552984.52.0.238982416363.issue10977@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: Concrete object C API considered harmful to subclasses of builtin types -> Concrete obect C API considered harmful to subclasses of builtin typesje

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

From report at bugs.python.org  Wed May 13 23:36:45 2015
From: report at bugs.python.org (ppperry)
Date: Wed, 13 May 2015 21:36:45 +0000
Subject: [docs] [issue10977] Concrete object C API considered harmful to
	subclasses	of builtin typesje
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1431553005.64.0.494712549051.issue10977@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: Concrete obect C API considered harmful to subclasses of builtin typesje -> Concrete object C API considered harmful to subclasses of builtin typesje

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

From report at bugs.python.org  Wed May 13 23:37:51 2015
From: report at bugs.python.org (ppperry)
Date: Wed, 13 May 2015 21:37:51 +0000
Subject: [docs] [issue10977] Concrete object C API considered harmful to
	subclasses	of builtin types
In-Reply-To: <1295653779.62.0.836506069174.issue10977@psf.upfronthosting.co.za>
Message-ID: <1431553071.32.0.274317759649.issue10977@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: Concrete object C API considered harmful to subclasses of builtin typesje -> Concrete object C API considered harmful to subclasses of builtin types

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

From report at bugs.python.org  Thu May 14 02:32:33 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 May 2015 00:32:33 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <20150514003229.25431.42930@psf.io>


Roundup Robot added the comment:

New changeset 99d2f83290c0 by R David Murray in branch '3.4':
#23088: Clarify null termination of bytes and strings in C API.
https://hg.python.org/cpython/rev/99d2f83290c0

New changeset 863f7c57081b by R David Murray in branch 'default':
Merge: #23088: Clarify null termination of bytes and strings in C API.
https://hg.python.org/cpython/rev/863f7c57081b

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

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

From report at bugs.python.org  Thu May 14 02:35:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 May 2015 00:35:21 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1431563721.11.0.755891176722.issue23088@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I just realized I committed this without checking how it rendered...

----------

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

From report at bugs.python.org  Thu May 14 02:41:12 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 May 2015 00:41:12 +0000
Subject: [docs] [issue23088] Document that PyUnicode_AsUTF8() returns
	a	null-terminated string
In-Reply-To: <1418964154.65.0.595903967697.issue23088@psf.upfronthosting.co.za>
Message-ID: <1431564072.79.0.16192623316.issue23088@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, I didn't see anything obvious at least :)

Thanks, Martin.

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

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

From report at bugs.python.org  Thu May 14 08:37:23 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Thu, 14 May 2015 06:37:23 +0000
Subject: [docs] [issue24136] document PEP 448
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1431585443.41.0.785151640204.issue24136@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Just updated the "what's new".  Also, thank you for adding my name to Misc/Acks.  Should we also add Joshua Landau's name?  He helped me quite a bit with the implementation, and he wrote the PEP.

----------
keywords: +patch
nosy: +neil.g
Added file: http://bugs.python.org/file39370/whatsnew.diff

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

From k.woebber at gmail.com  Thu May 14 01:13:48 2015
From: k.woebber at gmail.com (=?UTF-8?Q?Karsten_W=C3=B6bber?=)
Date: Thu, 14 May 2015 01:13:48 +0200
Subject: [docs] Py-Docs 2.7.1 not downloadable
Message-ID: <CAMu6TVvvKueBbAXwtrT+G568Rpwpq+27pk6A6Yi=DHhVW_n5cQ@mail.gmail.com>

for all links on this ( https://docs.python.org/2/download.html ) page, the
attached screen appears.

KR
Karsten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150514/f9e93549/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2015-05-14 01:09:15.png
Type: image/png
Size: 45597 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150514/f9e93549/attachment-0001.png>

From report at bugs.python.org  Thu May 14 11:32:49 2015
From: report at bugs.python.org (Jon)
Date: Thu, 14 May 2015 09:32:49 +0000
Subject: [docs] [issue24187] del statement documentation doesn't mention
	name binding	behaviour
Message-ID: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za>


New submission from Jon:

The documentation for the del keyword in the language reference doesn't mention the name binding behaviour:

https://docs.python.org/3/reference/simple_stmts.html#grammar-token-del_stmt

It is mentioned in section 4.1 where it says: 

"A target occurring in a del statement is also considered bound for this purpose"

But it's really not obvious to look there when trying to understand what del does.

It would be great if this information were added or a reference made to the other section.

----------
assignee: docs at python
components: Documentation
messages: 243163
nosy: docs at python, jc13
priority: normal
severity: normal
status: open
title: del statement documentation doesn't mention name binding behaviour
type: enhancement

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

From report at bugs.python.org  Thu May 14 11:47:40 2015
From: report at bugs.python.org (Anand B Pillai)
Date: Thu, 14 May 2015 09:47:40 +0000
Subject: [docs] [issue23698] Multiprocessing.Manager: fix behavior and
	doc	inconsistencies
In-Reply-To: <1426660385.12.0.0389729473261.issue23698@psf.upfronthosting.co.za>
Message-ID: <1431596860.75.0.139209382485.issue23698@psf.upfronthosting.co.za>


Anand B Pillai added the comment:

@sbt - Any comments on this ?

----------

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

From report at bugs.python.org  Thu May 14 12:21:10 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 May 2015 10:21:10 +0000
Subject: [docs] [issue24191] BoundArguments.signature not documented
Message-ID: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

The "signature" property on BoundArguments seems to be deliberately public (since there's also a private "_signature" attribute), but it's not documented.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 243168
nosy: docs at python, pitrou, yselivanov
priority: normal
severity: normal
status: open
title: BoundArguments.signature not documented
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 14 13:27:51 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 14 May 2015 11:27:51 +0000
Subject: [docs] [issue24187] del statement documentation doesn't mention
	name binding	behaviour
In-Reply-To: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za>
Message-ID: <1431602871.51.0.522656386114.issue24187@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't understand, what do you think is missing from the description?  It certainly talks about name binding.  Also, can you provide a link to the other statement, as I can't find it, and out of context I have no idea what it is talking about.

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

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

From report at bugs.python.org  Thu May 14 14:47:21 2015
From: report at bugs.python.org (Joshua Landau)
Date: Thu, 14 May 2015 12:47:21 +0000
Subject: [docs] [issue21593] Clarify re.search documentation first match
In-Reply-To: <1401287966.38.0.860641123785.issue21593@psf.upfronthosting.co.za>
Message-ID: <1431607641.75.0.287656912455.issue21593@psf.upfronthosting.co.za>


Joshua Landau added the comment:

This should also be applied to regex.search's docstring.

https://docs.python.org/3.5/library/re.html#re.regex.search

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

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

From report at bugs.python.org  Thu May 14 17:28:56 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 May 2015 15:28:56 +0000
Subject: [docs] [issue24191] BoundArguments.signature not documented
In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za>
Message-ID: <1431617336.66.0.315296701194.issue24191@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Good catch!  Please take a look at the attached patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file39371/sig_ba_docs.patch

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

From report at bugs.python.org  Thu May 14 20:14:37 2015
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 14 May 2015 18:14:37 +0000
Subject: [docs] [issue24191] BoundArguments.signature not documented
In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za>
Message-ID: <20150514181423.1939.55659@psf.io>


Roundup Robot added the comment:

New changeset 1012a8138fcb by Yury Selivanov in branch '3.4':
Issue 24191: Document BoundArguments.signature
https://hg.python.org/cpython/rev/1012a8138fcb

New changeset 970454df99cd by Yury Selivanov in branch 'default':
Issue 24191: Document BoundArguments.signature
https://hg.python.org/cpython/rev/970454df99cd

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

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

From report at bugs.python.org  Thu May 14 20:15:00 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 14 May 2015 18:15:00 +0000
Subject: [docs] [issue24191] BoundArguments.signature not documented
In-Reply-To: <1431598870.49.0.134760304526.issue24191@psf.upfronthosting.co.za>
Message-ID: <1431627300.22.0.667290773519.issue24191@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri May 15 01:22:23 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 14 May 2015 23:22:23 +0000
Subject: [docs] [issue23227] Generator's finally block not run if close()
	called	before first iteration
In-Reply-To: <1421134546.13.0.154248882029.issue23227@psf.upfronthosting.co.za>
Message-ID: <1431645743.26.0.782826950295.issue23227@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri May 15 09:13:14 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 15 May 2015 07:13:14 +0000
Subject: [docs] [issue24013] Improve os.scandir() and DirEntry documentation
In-Reply-To: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za>
Message-ID: <20150515071307.113160.94223@psf.io>


Roundup Robot added the comment:

New changeset e7c7431f91b2 by Victor Stinner in branch 'default':
Closes #24013: Improve os.scandir() and DirEntry documentation
https://hg.python.org/cpython/rev/e7c7431f91b2

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

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

From report at bugs.python.org  Fri May 15 09:14:50 2015
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 May 2015 07:14:50 +0000
Subject: [docs] [issue24013] Improve os.scandir() and DirEntry documentation
In-Reply-To: <1429473711.62.0.571757122461.issue24013@psf.upfronthosting.co.za>
Message-ID: <1431674090.43.0.84559871679.issue24013@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> 8. Added "Availability: Unix, Windows." to scandir docs like listdir and most other os functions have.

That's wrong: availability should only be explained when a function is not always available. os.listdir() and os.scandir() are always available. I made the opposite change: I removed the availability information from os.listdir() and many other os functions in the changeset 77ebd3720284.

Thanks Ben, I applied your patch (except of the Availability line).

----------

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

From pitrou at free.fr  Thu May 14 18:30:21 2015
From: pitrou at free.fr (pitrou at free.fr)
Date: Thu, 14 May 2015 16:30:21 -0000
Subject: [docs] BoundArguments.signature not documented (issue 24191)
Message-ID: <20150514163021.21831.69628@psf.upfronthosting.co.za>

Reviewers: ,

Message:
Looks good to me!



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

Affected files:
  Doc/library/inspect.rst


diff -r 07b88b324243 Doc/library/inspect.rst
--- a/Doc/library/inspect.rst	Thu May 14 08:51:09 2015 -0400
+++ b/Doc/library/inspect.rst	Thu May 14 11:28:25 2015 -0400
@@ -699,6 +699,10 @@
       A dict of keyword arguments values.  Dynamically computed from the
       :attr:`arguments` attribute.
 
+   .. attribute:: BoundArguments.signature
+
+      A reference to the parent :class:`Signature` object.
+
    The :attr:`args` and :attr:`kwargs` properties can be used to invoke
    functions::
 



From report at bugs.python.org  Fri May 15 09:32:45 2015
From: report at bugs.python.org (Jon)
Date: Fri, 15 May 2015 07:32:45 +0000
Subject: [docs] [issue24187] del statement documentation doesn't mention
	name binding	behaviour
In-Reply-To: <1431595969.01.0.32289440375.issue24187@psf.upfronthosting.co.za>
Message-ID: <1431675165.06.0.588894626733.issue24187@psf.upfronthosting.co.za>


Jon added the comment:

Sorry, I think I just misread this section.  I was confused by the fact that del binds names like assignment does, so that the following tries to delete a local name and fails:

  x = 1
  def f():
    del x
  f()

In fact the documentation does say that there must be global statement in the block for del to delete a global name, so my bad.

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

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

From report at bugs.python.org  Fri May 15 10:44:09 2015
From: report at bugs.python.org (levkivskyi)
Date: Fri, 15 May 2015 08:44:09 +0000
Subject: [docs] [issue24129] Incorrect (misleading) statement in the
	execution model	documentation
In-Reply-To: <1430859119.42.0.185221847455.issue24129@psf.upfronthosting.co.za>
Message-ID: <1431679449.23.0.346535933144.issue24129@psf.upfronthosting.co.za>


levkivskyi added the comment:

Since no one proposed alternative ideas, I am submitting my proposal as a patch, with the following wording:

"""
A class definition is an executable statement that may use and define names. Free variables follow the normal rules for name resolution, while unbound local variables are looked up in the global namespace. The namespace of the class definition becomes the attribute dictionary of the class. Names defined at the class scope are not visible in methods
"""

----------
keywords: +patch
Added file: http://bugs.python.org/file39383/classdoc.patch

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

From report at bugs.python.org  Fri May 15 22:49:36 2015
From: report at bugs.python.org (Jim)
Date: Fri, 15 May 2015 20:49:36 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
Message-ID: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>


New submission from Jim:

This probably applies to all versions with the strip() method, but I'm using 3.4. Section 4.7.1 of the documentation has a poorly worded description/example for the behaviour of string.strip([chars]).

A casual reading of "The chars argument is not a prefix or suffix; rather, all combinations of its values are stripped" lead me to believe this

>>> '0.0'.strip('.')
'0.0'

should be equivalent to the solution I found later

>>> '0.0'.replace('.', '')
'00'

The bit about [chars] requires recursive thinking ("are _stripped_") and clouds the fact that strip() iterates from beginning and end, discarding characters until it reaches a character that isn't in [chars].

In the example, it's not obvious (or wasn't to me) that the 'm' wasn't removed from 'example', and the missing periods gave the impression that they had been removed from the middle of the string instead of iterated to from the ends.

I can't think of a good way to rewrite the description, but perhaps you could borrow an example from rstrip() and add/replace:

>>> 'mississippi'.strip('mip')
'ssiss'

The glaring existence of that 'i' in the middle, when all others have been removed makes the limitation clear.

>>> '    hello world    '.strip()
'hello world'

Makes another good example.

Just trying to save someone else 20 minutes of confusion.

----------
assignee: docs at python
components: Documentation
messages: 243283
nosy: PhoenixofMT, docs at python
priority: normal
severity: normal
status: open
title: string.strip() documentation is misleading
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Fri May 15 23:28:19 2015
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 May 2015 21:28:19 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1431725299.68.0.921956930805.issue24204@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

https://docs.python.org/3/library/stdtypes.html#str.strip first sentence "Return a copy of the string with the leading and trailing characters removed."  How can that be reworded to make it clearer?

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

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

From report at bugs.python.org  Sat May 16 02:14:37 2015
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 May 2015 00:14:37 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1431735276.65.0.549169265022.issue24204@psf.upfronthosting.co.za>


R. David Murray added the comment:

Indeed, the sentence that confused you was added because people were continually confused by the fact that doing:

   'foo.boo'.strip('.boo')

would result in 'f' rather than 'foo'.

We would welcome an improvement, but apparently this is very hard to make clear.

Repeating the mississippi example is probably a good idea.

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

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

From report at bugs.python.org  Sat May 16 02:30:11 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 May 2015 00:30:11 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1431736211.15.0.778643261566.issue9694@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is there any interest in my or Ryan?s patches, which change the default heading away from ?optional arguments?? Changing the default is my preferred fix, but if others don?t like it (e.g. compatibility concerns), I am happy to work on a documentation patch according to <https://bugs.python.org/issue9694#msg132327>.

I don?t see how adding an extra help groups API is very helpful though. The problem here is that the default help group headings are wrong (or at least misleading to many people).

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

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

From report at bugs.python.org  Sat May 16 14:35:16 2015
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 16 May 2015 12:35:16 +0000
Subject: [docs] [issue17045] Improve C-API doc for PyTypeObject
In-Reply-To: <1359245485.06.0.557532055897.issue17045@psf.upfronthosting.co.za>
Message-ID: <1431779716.66.0.472322673536.issue17045@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/issue17045>
_______________________________________

From report at bugs.python.org  Sat May 16 15:43:19 2015
From: report at bugs.python.org (Jim)
Date: Sat, 16 May 2015 13:43:19 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1431783799.68.0.677328788867.issue24204@psf.upfronthosting.co.za>


Jim added the comment:

Maybe, "... all combinations of its values are stripped from the beginning and end."

It is rather difficult to be both clear AND concise. Heck, I'm having trouble just trying to explain it.

Mark, that part is clear, but I think somehow reiterating how the method works would be helpful to someone who is only familiar with a handful of the string methods, knows strip() removes characters, sees that several characters can be specified, and assumes that all such characters will be removed.

As it is, it's sort of like a puzzle that's glaringly obvious once you figure it out, but frustrating in proportion to the amount of time spent figuring. Almost more trouble to figure out how to explain it without turning it into a tutorial than it is to sort it out on your own at the console.

----------

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

From report at bugs.python.org  Sat May 16 20:16:50 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 16 May 2015 18:16:50 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1431800210.75.0.718768391084.issue24204@psf.upfronthosting.co.za>


Carol Willing added the comment:

Additional text added about stripping characters from the leading end and trailing end of the string. An additional example that illustrates the outer characters being stripped while the inner string characters, even though matching the chars set of characters, remain.

----------
keywords: +patch
nosy: +willingc
stage:  -> patch review
Added file: http://bugs.python.org/file39392/iss24204.patch

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

From report at bugs.python.org  Sun May 17 09:23:16 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 17 May 2015 07:23:16 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <1431847396.51.0.541188211337.issue22155@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch which moves the documentation from the FAQ into a new section at the bottom of the main ?tkinter? reference manual page, and updates it. I also mentioned lack of Windows support. Let me know what you think!

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file39402/file-handlers.patch

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

From report at bugs.python.org  Sun May 17 09:59:48 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 17 May 2015 07:59:48 +0000
Subject: [docs] [issue24216] Typo in bytes.join/bytearray.join documentation
Message-ID: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

This

    if there are any values in iterable that are note bytes-like objects

should be

    if there are any values in iterable that are not bytes-like objects

Here's a micropatch...

----------
assignee: docs at python
components: Documentation
files: bytes_join.diff
keywords: patch
messages: 243389
nosy: docs at python, vlth
priority: normal
severity: normal
status: open
title: Typo in bytes.join/bytearray.join documentation
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39403/bytes_join.diff

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

From report at bugs.python.org  Sun May 17 15:18:29 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 May 2015 13:18:29 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1431868709.37.0.905473366167.issue24147@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, I think the documentation should be improved.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
resolution: not a bug -> 
stage:  -> needs patch
status: closed -> open
title: doublequote are not well recognized with Dialect class -> Dialect class defaults are not documented.
versions: +Python 3.4, Python 3.5 -Python 2.7

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

From report at bugs.python.org  Sun May 17 16:17:47 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 May 2015 14:17:47 +0000
Subject: [docs] [issue24216] Typo in bytes.join/bytearray.join documentation
In-Reply-To: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za>
Message-ID: <20150517141744.26578.60203@psf.io>


Roundup Robot added the comment:

New changeset ba271f116f94 by R David Murray in branch '3.4':
#24216: fix typo
https://hg.python.org/cpython/rev/ba271f116f94

New changeset 91ac3040a28d by R David Murray in branch 'default':
Merge: #24216: fix typo
https://hg.python.org/cpython/rev/91ac3040a28d

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

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

From report at bugs.python.org  Sun May 17 16:18:21 2015
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 May 2015 14:18:21 +0000
Subject: [docs] [issue24216] Typo in bytes.join/bytearray.join documentation
In-Reply-To: <1431849588.53.0.583435577111.issue24216@psf.upfronthosting.co.za>
Message-ID: <1431872301.72.0.887431668373.issue24216@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, Dmitry.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun May 17 16:50:32 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 17 May 2015 14:50:32 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1431874232.39.0.885978525558.issue24147@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

The defaults for the Dialect class are documented:

https://docs.python.org/2/library/csv.html#dialects-and-formatting-parameters

I think the problem is mostly that csv.Dialect must be subclassed. You can't use it directly, and if you subclass it as MiK did, you have to supply all the missing parameters. The default dialect is actually csv.excel, which does provide a suitable set of values for all attributes.

There actually might be a bug lurking in the code as well. The value of csv.Dialect.doublequote is None, which will evaluate to False in a boolean context. The module docstring has this to say about that attribute:

        * doublequote - controls the handling of quotes inside fields.  When
            True, two consecutive quotes are interpreted as one during read,
            and when writing, each quote character embedded in the data is
            written as two quotes

Since the valid values of that attribute are actually only True and False, using None as a default value is an invitation to problems. It appears in this case that's what happened.

csv.Dialect.__init__ doesn't seem to check that the overriding class properly sets all the required parameters. It checks to see if the class is Dialect. If not, and if the validate() call passes, all is assumed to be well. But digging a bit under the surface, it appears the validate step drops into C where the doublequote attribute of Dialog_Type is 0.

I'm not sure the bug should be fixed in 2.7, but it's worth taking a look at the 3.5 code to see if that validation step can be improved.

----------

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

From report at bugs.python.org  Sun May 17 17:58:53 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 May 2015 15:58:53 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <1431878333.16.0.273878191778.issue22155@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Assuming that the details are correct, which I cannot check on Windows :-(, this looks good to me. If the tkinter doc is expanded and reorganized, that section might move but I cannot see a better place for it now. Martin, have you used that code (with Tkinter/tkinter) on both 2.7 and 3.x?  Serhiy, if you want me to apply this, after you check it, I will.

----------

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

From report at bugs.python.org  Sun May 17 18:43:24 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 May 2015 16:43:24 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <1431881004.46.0.294493730962.issue22155@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not sure that this is right place to document these functions (they are methods of undocumented class), but the patch looks correct to me.

If you will commit the patch, Terry, note that tkinter should be replaced with Tkinter in 2.7.

----------

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

From report at bugs.python.org  Sun May 17 20:10:51 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sun, 17 May 2015 18:10:51 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
Message-ID: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

One of the integers under "Some examples of integer literals" is repeated twice:

    7     2147483647                        0o177    0b100110111
    3     79228162514264337593543950336     0o377    0x100000000
          79228162514264337593543950336              0xdeadbeef

I believe this comes from the old docs: https://docs.python.org/2.7/reference/lexical_analysis.html#integer-and-long-integer-literals (the L suffix was removed).

----------
assignee: docs at python
components: Documentation
files: intliteral.diff
keywords: patch
messages: 243418
nosy: docs at python, vlth
priority: normal
severity: normal
status: open
title: Repeated integer in Lexical analysis/Integer literals section
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39410/intliteral.diff

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

From report at bugs.python.org  Sun May 17 20:50:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 May 2015 18:50:24 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <20150517185021.10810.53425@psf.io>


Roundup Robot added the comment:

New changeset e8dd65c7fb6b by Terry Jan Reedy in branch '2.7':
Issue #22155: Add File Handlers subsection with createfilehandler to Tkinter
https://hg.python.org/cpython/rev/e8dd65c7fb6b

New changeset 1efcb7b6ec8a by Terry Jan Reedy in branch '3.4':
Issue #22155: Add File Handlers subsection with createfilehandler to tkinter
https://hg.python.org/cpython/rev/1efcb7b6ec8a

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

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

From report at bugs.python.org  Sun May 17 20:56:34 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 17 May 2015 18:56:34 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <20150517185631.26566.12190@psf.io>


Roundup Robot added the comment:

New changeset 8bd9da5635fe by Terry Jan Reedy in branch '3.4':
Issue #22155: News entry.
https://hg.python.org/cpython/rev/8bd9da5635fe

New changeset 850cbd54cc73 by Terry Jan Reedy in branch 'default':
Issue #22155: News entry.
https://hg.python.org/cpython/rev/850cbd54cc73

----------

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

From report at bugs.python.org  Sun May 17 20:59:52 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 May 2015 18:59:52 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <1431889192.21.0.606352211572.issue22155@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Martin, thanks for the nice patch.

----------
assignee: docs at python -> terry.reedy
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun May 17 23:58:24 2015
From: report at bugs.python.org (Arnon Yaari)
Date: Sun, 17 May 2015 21:58:24 +0000
Subject: [docs] [issue20769] Reload() description is unclear
In-Reply-To: <1393345435.57.0.757218905385.issue20769@psf.upfronthosting.co.za>
Message-ID: <1431899904.62.0.30581470649.issue20769@psf.upfronthosting.co.za>


Changes by Arnon Yaari <wiggin15 at gmail.com>:


----------
nosy: +wiggin15

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

From report at bugs.python.org  Mon May 18 00:13:16 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 May 2015 22:13:16 +0000
Subject: [docs] [issue19737] Documentation of globals() and locals() should
	be	improved
In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za>
Message-ID: <1431900796.89.0.44838982821.issue19737@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My succinct version:

Return the dictionary implementing the current module namespace. For code within functions, this is set when the function is defined and remains the same regardless of where a function is called.

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

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

From report at bugs.python.org  Mon May 18 01:39:03 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 May 2015 23:39:03 +0000
Subject: [docs] [issue10170] Relationship between turtle speed setting and
	actual	speed is not documented
In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>
Message-ID: <1431905943.64.0.0619231463777.issue10170@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

After looking at these results in relation to the qualitative 'speed' documentation, I cannot think of any any enhancement appropriate for turtle doc audience.  So I withdraw my request.

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

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

From report at bugs.python.org  Mon May 18 02:07:17 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 May 2015 00:07:17 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandler
In-Reply-To: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>
Message-ID: <1431907637.03.0.123927847921.issue22155@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, I have used this code in 2.7 in the past (though I mainly use Python 3). The Python 2 version of the changes look fine to me.

----------

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

From report at bugs.python.org  Mon May 18 07:15:51 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 18 May 2015 05:15:51 +0000
Subject: [docs] [issue24220] ast.Call signature changed
In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za>
Message-ID: <1431926151.46.0.827541948261.issue24220@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

Hi Carol, 

> Matthias, Did you wish to mark this issue for additional Documentation and as a behavior change request (warning of signature change until 3.6) in addition to Devguide?

Hum, probably, I'm not super familiar with this bug tracker and it use, I've tried to select both Devguide and Docs now.

> a) Should `ast` shim the old signature and raise a warning until 3.6?

>From Guido's comment on linked issue, I guess not: 

> "There is no compatibility guarantee for the ast module"


> b) What additional items should be added to Documentation or Porting Guide?

I guess that Call api changed in the what's new. A link to a rough implementation that show how to get code compatible on 3.5 and below would be nice, it is kind of painful to iterate through the new AST structure and figure things out.

> c) What items should be added to Devguide?

I can talk to Thomas Kluyver tomorrow about merging green tree snake into the devguide, or maybe into ast docs. Would that be useful/more acceptable than linking to external docs ?

Thanks.

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

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

From report at bugs.python.org  Mon May 18 14:18:38 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 May 2015 12:18:38 +0000
Subject: [docs] [issue24220] ast.Call signature changed
In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za>
Message-ID: <1431951518.14.0.510559593089.issue24220@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Matthias.

> I can talk to Thomas Kluyver tomorrow about merging green tree snake into the devguide,

devguide isn't the correct place for such documentation.

> or maybe into ast docs. Would that be useful/more acceptable than linking to external docs ?

There is an open issue for that: issue 16544. I've talked to Thomas about merging greentreesnakes to the AST documentation last year and already have a WIP patch at https://gist.github.com/berkerpeksag/0be9bb0ada548185d9ef (I have more complete patch, but couldn't find it now :))

If you have time to work on it, I can upload it to the tracker item and we can work together.

----------
components:  -Devguide
nosy: +berker.peksag

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

From jesper.tragardh at gmail.com  Mon May 18 15:12:02 2015
From: jesper.tragardh at gmail.com (=?UTF-8?B?SmVzcGVyIFRyw6Rnw6VyZGg=?=)
Date: Mon, 18 May 2015 15:12:02 +0200
Subject: [docs] 2.7.10rc1 operator precedence table order
Message-ID: <CAAKkRQjFLZ_KBZ0v7wG7JWzDWkzgLWB6xJ1cVRXg+ZJ9bL+k9Q@mail.gmail.com>

??

?Hi Doc Maintainers,



Although I couldn't find a matching issue in the tracker, I thought the
mailing list could be a more appropriate place for this discussion.



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

for Python version 2.7.10rc1 it is stated

The following table summarizes the operator precedences in Python, *from
lowest precedence (least binding) to highest precedence (most binding)*.
(emphasis mine)



I think many programmers coming from other languages actually expect this
table to be in the opposite order, from highest prio to lowest. My
not-so-well-reasearched guess is that how the documentation is layed out in
most other language reference texts and programmers expect to see the
operator evaluated first on the top.



Despite the text I stared for some time at the table trying to understand
why Python would swap the priority of addition and multiplication compared
to the languages with C-like syntax I'm used to. After experimenting with
the interpretor and reading the text again I felt relieved that, actually
it doesn't.



Just my two cents - I don't have a suggestion for how to fix this without
breaking documentation for those already used the current table order.



    Best regards, Jesper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150518/227e75ba/attachment.html>

From report at bugs.python.org  Mon May 18 15:22:34 2015
From: report at bugs.python.org (Matthias Bussonnier)
Date: Mon, 18 May 2015 13:22:34 +0000
Subject: [docs] [issue24220] ast.Call signature changed
In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za>
Message-ID: <1431955354.59.0.235106541659.issue24220@psf.upfronthosting.co.za>


Matthias Bussonnier added the comment:

> There is an open issue for that: issue 16544. I've talked to Thomas about merging greentreesnakes to the AST documentation last year and already have a WIP patch

Ah, Thanks for the link, I see if I can rotate my chair 120deg clockwise and give a nudge to Thomas.

I'll probably have a hard time working on that this week, but can try to push it forward to be up to date with 3.5.

----------

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

From report at bugs.python.org  Mon May 18 15:44:56 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 May 2015 13:44:56 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1431956696.43.0.663040918492.issue16544@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/issue16544>
_______________________________________

From report at bugs.python.org  Mon May 18 16:54:23 2015
From: report at bugs.python.org (Carol Willing)
Date: Mon, 18 May 2015 14:54:23 +0000
Subject: [docs] [issue24220] ast.Call signature changed
In-Reply-To: <1431893438.07.0.469229426161.issue24220@psf.upfronthosting.co.za>
Message-ID: <1431960863.01.0.73731926104.issue24220@psf.upfronthosting.co.za>


Carol Willing added the comment:

Thanks Berker for pointing out the WIP patch for issue 16544. Issue 16544 seems a better place than this issue for addressing the ast documentation.

There does not seem to be any additional action items left on this issue so I recommend closing this issue and moving discussion for ast documentation to Issue 16544.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Mon May 18 17:02:39 2015
From: report at bugs.python.org (Carol Willing)
Date: Mon, 18 May 2015 15:02:39 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1431961359.49.0.922992067922.issue16544@psf.upfronthosting.co.za>


Carol Willing added the comment:

Matthias, I've added you to the nosy list for this ast doc enhancements issue. Reference: msg243484 on Issue 24220.

----------
nosy: +mbussonn, willingc
versions: +Python 3.5

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

From report at bugs.python.org  Mon May 18 19:17:06 2015
From: report at bugs.python.org (Thomas Kluyver)
Date: Mon, 18 May 2015 17:17:06 +0000
Subject: [docs] [issue16544] Add external link to ast docs
In-Reply-To: <1353702032.57.0.687396127567.issue16544@psf.upfronthosting.co.za>
Message-ID: <1431969426.4.0.0713235885732.issue16544@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Here's a simple patch that links to Green Tree Snakes from the ast module docs, using the 'sidebar' directive (that's what the logging module uses to link to tutorials, which seemed analogous).

I'm still happy to contribute these docs to CPython if people want that, but I'm also happy to keep maintaining them as a separate resource. I can see advantages to both approaches.

----------
keywords: +patch
Added file: http://bugs.python.org/file39420/link-gts.patch

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

From report at bugs.python.org  Mon May 18 21:46:35 2015
From: report at bugs.python.org (Christie)
Date: Mon, 18 May 2015 19:46:35 +0000
Subject: [docs] [issue18576] Document test.support.script_helper
In-Reply-To: <1375014764.64.0.152576599022.issue18576@psf.upfronthosting.co.za>
Message-ID: <1431978395.54.0.279465078265.issue18576@psf.upfronthosting.co.za>


Christie added the comment:

I'm going to take a look at bringing these docs up to date and including the changes from issue24033.

----------
nosy: +bobcatfish

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

From report at bugs.python.org  Mon May 18 23:28:40 2015
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Mon, 18 May 2015 21:28:40 +0000
Subject: [docs] [issue24232] Speling fixes
Message-ID: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Various doc spelling fixes in the attached patch.

----------
assignee: docs at python
components: Documentation
files: spelling.patch
keywords: patch
messages: 243536
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Speling fixes
type: enhancement
Added file: http://bugs.python.org/file39423/spelling.patch

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

From report at bugs.python.org  Mon May 18 23:35:44 2015
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Mon, 18 May 2015 21:35:44 +0000
Subject: [docs] [issue24233] Link to getfqdn rather than "see above"
Message-ID: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Would be nice to link to getfqdn() instead of saying "see above" for it in socket.gethostname() docs.

----------
assignee: docs at python
components: Documentation
files: getfqdnlink.patch
keywords: patch
messages: 243537
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Link to getfqdn rather than "see above"
type: enhancement
Added file: http://bugs.python.org/file39424/getfqdnlink.patch

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

From report at bugs.python.org  Tue May 19 00:31:26 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 May 2015 22:31:26 +0000
Subject: [docs] [issue24233] Link to getfqdn rather than "see above"
In-Reply-To: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za>
Message-ID: <20150518223123.10806.50452@psf.io>


Roundup Robot added the comment:

New changeset f6e7953b5431 by Berker Peksag in branch '3.4':
Issue #24233: Add a proper link to socket.getfqdn() documentation.
https://hg.python.org/cpython/rev/f6e7953b5431

New changeset 0d6902537062 by Berker Peksag in branch 'default':
Issue #24233: Add a proper link to socket.getfqdn() documentation.
https://hg.python.org/cpython/rev/0d6902537062

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

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

From report at bugs.python.org  Tue May 19 00:33:04 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 May 2015 22:33:04 +0000
Subject: [docs] [issue24233] Link to getfqdn rather than "see above"
In-Reply-To: <1431984944.05.0.247984271227.issue24233@psf.upfronthosting.co.za>
Message-ID: <1431988384.06.0.704953489411.issue24233@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Ville.

----------
nosy: +berker.peksag
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/issue24233>
_______________________________________

From report at bugs.python.org  Tue May 19 00:38:06 2015
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 May 2015 22:38:06 +0000
Subject: [docs] [issue24232] Speling fixes
In-Reply-To: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za>
Message-ID: <20150518223803.26840.84987@psf.io>


Roundup Robot added the comment:

New changeset fd7ef3972215 by Berker Peksag in branch '3.4':
Issue #24232: Fix typos. Patch by Ville Skytt?.
https://hg.python.org/cpython/rev/fd7ef3972215

New changeset fc2eed9fc2d0 by Berker Peksag in branch 'default':
Issue #24232: Fix typos. Patch by Ville Skytt?.
https://hg.python.org/cpython/rev/fc2eed9fc2d0

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

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

From report at bugs.python.org  Tue May 19 00:39:10 2015
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 May 2015 22:39:10 +0000
Subject: [docs] [issue24232] Speling fixes
In-Reply-To: <1431984520.8.0.717388899903.issue24232@psf.upfronthosting.co.za>
Message-ID: <1431988750.77.0.749258009915.issue24232@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Ville.

----------
nosy: +berker.peksag
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/issue24232>
_______________________________________

From report at bugs.python.org  Tue May 19 00:46:45 2015
From: report at bugs.python.org (Martin Panter)
Date: Mon, 18 May 2015 22:46:45 +0000
Subject: [docs] [issue19737] Documentation of globals() and locals() should
	be	improved
In-Reply-To: <1385225461.09.0.671908077084.issue19737@psf.upfronthosting.co.za>
Message-ID: <1431989205.17.0.292186665596.issue19737@psf.upfronthosting.co.za>


Martin Panter added the comment:

Terry?s ?dictionary implementing the namespace? version would work for me.

----------

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

From report at bugs.python.org  Tue May 19 15:20:21 2015
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 19 May 2015 13:20:21 +0000
Subject: [docs] [issue24240] PEP 448: Update the language reference
In-Reply-To: <1432041544.18.0.803437691236.issue24240@psf.upfronthosting.co.za>
Message-ID: <1432041621.07.0.754136419894.issue24240@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5

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

From report at bugs.python.org  Wed May 20 00:51:09 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 May 2015 22:51:09 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
	what	shell=True does
In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>
Message-ID: <1432075869.9.0.338672542715.issue20344@psf.upfronthosting.co.za>


Martin Panter added the comment:

?Only the first element . . . will be executed on Unix? is a bit simplistic. The behaviour is already described more fully in the ?shell? documentation under <https://docs.python.org/dev/library/subprocess.html#subprocess.Popen>.

Also, ?args? is allowed to be a _sequence_, but an _iterable_ is a more general concept.

----------
nosy: +vadmium

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

From report at bugs.python.org  Wed May 20 00:52:03 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 19 May 2015 22:52:03 +0000
Subject: [docs] [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1432075923.16.0.307592672333.issue12020@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation already says that ?stdout? and friends are meant to be text files, and that they may be replaced with file-like objects like StringIO. Perhaps the documentation could be more explicit about what text file API is required internally (either TextIOBase, or list the required subset of methods).

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

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

From report at bugs.python.org  Wed May 20 03:30:25 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 May 2015 01:30:25 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
	what	shell=True does
In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>
Message-ID: <1432085425.67.0.0550469600383.issue20344@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can you suggest a better phrasing that is still succinct? (Maybe just 'appear to be executed' would make it accurate enough?)  But, that's why there needs to be a reference of *some* sort to the full explanation.

I'm not sure what the issue is with iterable/sequence.  check_output/Popen accepts an iterable.

----------

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

From report at bugs.python.org  Wed May 20 06:02:42 2015
From: report at bugs.python.org (swanson)
Date: Wed, 20 May 2015 04:02:42 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
Message-ID: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>


New submission from swanson:

Background:
-----------
Perhaps this has been addressed elsewhere, but I couldn't find it.  To me, semantically, the whole idea of finding nothing, whether in something or in nothing is complete and utter nonsense.  I'm a fail-quickly, fail-loudly kind of guy, and I'd prefer that any attempt to find nothing would result in an exception being raised.

But for whatever reason, the following behavior has long existed:
>>> "".index("") == "A".index("") == 0
True
>>> "" in "" and b"" in b"" and b"" in bytearray(b"")
True
>>> "" in "A" and b"" in b"A" and b"" in bytearray(b"A")
True


The Problem:
------------
The various string types (str, bytes, bytearray) all have the following functions: count, find, rfind, index, rindex
Each of these functions accepts optional parameters "start" and "end".  The documentation for each says something like "Optional arguments start and end are interpreted as in slice notation."  This is not the case.

On the one hand:
>>> "".find("") == ""[0:0].find("") == "".find("", 0, 0) == 0
True

Consistent so far, however:
>>> "".find("") == ""[1:0].find("") == 0 and "".find("", 1, 0) == -1
True

So, you see that 'start' and 'end' are NOT in all cases interpreted the same way as slicing.  This problem has been around forever, affecting both Python 3 and 2, so I don't know how many people's code you'd break if you changed the behavior to make it consistent with the docs.  But if it's not going to be changed, it should at least be a well-documented "feature" of the functions with a line or two of explanation in the relevant docs:
https://docs.python.org/3/library/stdtypes.html#bytes-and-bytearray-operations
https://docs.python.org/3/library/stdtypes.html#string-methods

The built-in types bytes, bytearray, and str also have the functions "startswith" and "endswith" that also take optional 'start' and 'end' arguments.  The documentation does not specifically say (as for count, (r)find, and (r)index) that these are "interpreted as in slice notation".  Instead, it says: "With optional start, test string beginning at that position. With optional end, stop comparing string at that position."  That wording is equally confusing and erroneous.  The natural interpretation of that would lead you to believe that, unlike slicing:
"A".startswith("A",0,0) == True
however it's really == False because the 'end' index is like slicing.

Now, as to the interpretation of finding nothing, it's a mixed bag:

For str:
>>> "".startswith("",0,0)
True
>>> "".startswith("",1,0)
True
>>> "".endswith("",0,0)
True
>>> "".endswith("",1,0)
True

For bytes: (and the same for bytearray)
>>> b"".startswith(b"",0,0)
True
>>> b"".startswith(b"",1,0)
False
>>> b"".endswith(b"",0,0)
True
>>> b"".endswith(b"",1,0)
False

----------
assignee: docs at python
components: Documentation
messages: 243640
nosy: docs at python, swanson
priority: normal
severity: normal
status: open
title: behavior for finding an empty string is inconsistent with documentation
type: behavior

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

From report at bugs.python.org  Wed May 20 07:09:42 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 May 2015 05:09:42 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
	what	shell=True does
In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>
Message-ID: <1432098582.7.0.96858124014.issue20344@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually David I didn?t notice your suggested wording <https://bugs.python.org/issue20344#msg214364> before. Adding that last sentence, pointing to the full description of the Popen constructor, would be fine.

My complaint about mentioning ?iterable? is that iterables are not mentioned anywhere else in the documentation. I would rather leave it out or change it to ?sequence?, unless the rest of the documentation is made consistent, e.g. ?args . . . should be a string, or a sequence of program arguments? would also need fixing.

----------

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

From atirla at kcg.com  Wed May 20 11:31:44 2015
From: atirla at kcg.com (Adrian Tirla)
Date: Wed, 20 May 2015 09:31:44 +0000
Subject: [docs] Typos in documentation
Message-ID: <d4a1a0dffe1c4d169277596904ca4898@LN1WSCTSMAIL02.kcg.com>

Hi guys,

I hope you're well.

I was reading the documentation for mocks here:
https://docs.python.org/3.4/library/unittest.mock.html?highlight=mock#module-unittest.mock
http://www.voidspace.org.uk/python/mock/helpers.html#auto-speccing
and I've spotted some typos "assret" instead of "assert".

>>> mock = Mock(name='Thing', return_value=None)
>>> mock(1, 2, 3)
>>> mock.assret_called_once_with(4, 5, 6)

Regards,
Adrian

--
Adrian Tirla
[Description: kcg logo]
KCG Europe Limited
City Place House, 55 Basinghall Street
London, EC2V 5DU
atirla at kcg.com<mailto:atirla at kcg.com>
www.kcg.com<http://www.kcg.com>
+44 (0)20 7997 7876


KCG Europe Limited is authorized and regulated by the Financial Conduct Authority. Registered Office 55 Basinghall Street, London, EC2V 5DU. Registered in England & Wales No. 03632121

This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature. For additional important disclaimers and disclosures regarding KCG's products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150520/c4e3a070/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9320 bytes
Desc: image001.png
URL: <http://mail.python.org/pipermail/docs/attachments/20150520/c4e3a070/attachment.png>

From berker.peksag at gmail.com  Wed May 20 13:25:51 2015
From: berker.peksag at gmail.com (=?UTF-8?Q?Berker_Peksa=C4=9F?=)
Date: Wed, 20 May 2015 14:25:51 +0300
Subject: [docs] Typos in documentation
In-Reply-To: <d4a1a0dffe1c4d169277596904ca4898@LN1WSCTSMAIL02.kcg.com>
References: <d4a1a0dffe1c4d169277596904ca4898@LN1WSCTSMAIL02.kcg.com>
Message-ID: <CAF4280LLRhQiYuu0TF3ajYd-WMcnJWTMuPQfZzBvd2mW6QfzLA@mail.gmail.com>

On Wed, May 20, 2015 at 12:31 PM, Adrian Tirla <atirla at kcg.com> wrote:
>
> Hi guys,
>
>
>
> I hope you?re well.
>
>
>
> I was reading the documentation for mocks here:
>
> https://docs.python.org/3.4/library/unittest.mock.html?highlight=mock#module-unittest.mock
>
> http://www.voidspace.org.uk/python/mock/helpers.html#auto-speccing
>
> and I?ve spotted some typos ?assret? instead of ?assert?.
>
>
>
> >>> mock = Mock(name='Thing', return_value=None)
>
> >>> mock(1, 2, 3)
>
> >>> mock.assret_called_once_with(4, 5, 6)

Hi Adrian,

Thanks for the report, but I think the typos are intentional.

>From https://docs.python.org/3.4/library/unittest.mock.html#autospeccing:

    Because mocks auto-create attributes on demand, and allow you to
call them with arbitrary arguments, if you misspell one of these
assert methods then your assertion is gone:

Then the following snippet proves that the paragraph above is correct:

    [...]
    mock.assret_called_once_with(4, 5, 6)

    Your tests can pass silently and incorrectly because of the typo.

--Berker

From report at bugs.python.org  Wed May 20 14:27:05 2015
From: report at bugs.python.org (Martin Panter)
Date: Wed, 20 May 2015 12:27:05 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432124825.33.0.978796634428.issue24243@psf.upfronthosting.co.za>


Martin Panter added the comment:

There are a few related issues here I think:

1. Empty string search: I think it is completely valid to be able to find an empty string inside another string, at least as long as the slice indexes are within range. Although I remember it was a bit of a revelation the first time I considered this. Anyway, the documentation should explicitly mention this case.

2. "".find("", 1, 0) -> -1: This is inconsistent with startswith() and slicing, but the only reasonable alternative would be to return 1, which would be a strange index for an empty string. Certainly needs documenting though.

3. starts/endswith() slice arguments: I think they should be described equivalently to find() etc. So ?start? points to the first character, ?end? points after the last character, negative indexes from the end, etc.

4. "".startswith("", 1, 0): This is True for str, and False for bytes, which is terribly inconsistent. My gut says both should be False, to match how find() works.

Some other related undocumented quirks:

>>> "abcd".count("")  # Infinity? End of the universe? No!
5
>>> "abcd".replace("", "_", 10)  # Might expect 10 underscores
'_a_b_c_d_'
>>> "abcd".split("", 10)  # Might expect a list of 11 strings
ValueError: empty separator
>>> "abcd".partition("")  # Why not ("", "", "abcd")?
ValueError: empty separator

----------
nosy: +vadmium

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

From report at bugs.python.org  Wed May 20 15:18:42 2015
From: report at bugs.python.org (swanson)
Date: Wed, 20 May 2015 13:18:42 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432127922.77.0.566669584573.issue24243@psf.upfronthosting.co.za>


swanson added the comment:

Thanks for pointing out how count and replace operate.  I don't mind the "ValueError: empty separator" on split and partition - makes sense to me.

re: "at least as long as the slice indexes are within range"
If the slices indexes had to be in range, that would be inconsistent with the behavior of slicing, which is inconsistent with the docs, which was my main point.

----------

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

From atirla at kcg.com  Wed May 20 14:35:35 2015
From: atirla at kcg.com (Adrian Tirla)
Date: Wed, 20 May 2015 12:35:35 +0000
Subject: [docs] Typos in documentation
In-Reply-To: <CAF4280LLRhQiYuu0TF3ajYd-WMcnJWTMuPQfZzBvd2mW6QfzLA@mail.gmail.com>
References: <d4a1a0dffe1c4d169277596904ca4898@LN1WSCTSMAIL02.kcg.com>
 <CAF4280LLRhQiYuu0TF3ajYd-WMcnJWTMuPQfZzBvd2mW6QfzLA@mail.gmail.com>
Message-ID: <9d31864b600b47c6b0d66fda027cdeee@LN1WSCTSMAIL02.kcg.com>

My bad, please excuse me. I've pasted the example and I was wondering why it doesn't fail :)  so I've thought it was a typo.

Good stuff. Sorry once again.

Regards,
Adrian

--
Adrian Tirla

KCG Europe Limited
City Place House, 55 Basinghall Street
London, EC2V 5DU
atirla at kcg.com
www.kcg.com
+44 (0)20 7997 7876



-----Original Message-----
From: Berker Peksa? [mailto:berker.peksag at gmail.com]
Sent: Wednesday, May 20, 2015 12:26 PM
To: Adrian Tirla
Cc: testing-in-python at lists.idyll.org; docs at python.org
Subject: Re: [docs] Typos in documentation

On Wed, May 20, 2015 at 12:31 PM, Adrian Tirla <atirla at kcg.com> wrote:
>
> Hi guys,
>
>
>
> I hope you?re well.
>
>
>
> I was reading the documentation for mocks here:
>
> https://docs.python.org/3.4/library/unittest.mock.html?highlight=mock#
> module-unittest.mock
>
> http://www.voidspace.org.uk/python/mock/helpers.html#auto-speccing
>
> and I?ve spotted some typos ?assret? instead of ?assert?.
>
>
>
> >>> mock = Mock(name='Thing', return_value=None)
>
> >>> mock(1, 2, 3)
>
> >>> mock.assret_called_once_with(4, 5, 6)

Hi Adrian,

Thanks for the report, but I think the typos are intentional.

From https://docs.python.org/3.4/library/unittest.mock.html#autospeccing:

    Because mocks auto-create attributes on demand, and allow you to call them with arbitrary arguments, if you misspell one of these assert methods then your assertion is gone:

Then the following snippet proves that the paragraph above is correct:

    [...]
    mock.assret_called_once_with(4, 5, 6)

    Your tests can pass silently and incorrectly because of the typo.

--Berker
KCG Europe Limited is authorized and regulated by the Financial Conduct Authority. Registered Office 55 Basinghall Street, London, EC2V 5DU. Registered in England & Wales No. 03632121

This e-mail and its attachments are intended only for the individual or entity to whom it is addressed and may contain information that is confidential, privileged, inside information, or subject to other restrictions on use or disclosure. Any unauthorized use, dissemination or copying of this transmission or the information in it is prohibited and may be unlawful. If you have received this transmission in error, please notify the sender immediately by return e-mail, and permanently delete or destroy this e-mail, any attachments, and all copies (digital or paper). Unless expressly stated in this e-mail, nothing in this message should be construed as a digital or electronic signature. For additional important disclaimers and disclosures regarding KCG?s products and services, please click on the following link:

http://www.kcg.com/legal/global-disclosures

From report at bugs.python.org  Wed May 20 16:00:55 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 May 2015 14:00:55 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432130455.39.0.291181134884.issue24243@psf.upfronthosting.co.za>


R. David Murray added the comment:

"If the slices indexes had to be in range, that would be inconsistent with the behavior of slicing"

No, it wouldn't.  Your slice example is two operations: the slice returns an empty string (because that's how the *substring* operation is defined to behave for an out-of-range slice), and *then* the search operation is called on it; but in the call with index arguments, the indicies are specifying the slice to search in using the slice semantics of the indicies, but that substring is invalid for the *search* operation.

I agree that the startswith/endswith difference between string a bytes looks like a bug, and that the bytes case looks to be the correct one, in terms of consistency with the other search operations.  Those operations are a bit different from the other search operations, though, so I could see it argued the other way.

The point is that the slice notation specifies how to compute the substring, but what happens if the substring is out of range depends on the *operation*.

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

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

From report at bugs.python.org  Wed May 20 16:03:18 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 May 2015 14:03:18 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432130598.76.0.388031542143.issue24243@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Changing behavior of such base methods is dangerous and can break existing code. Even if the behavior is wrong, some code can depends on it. We should be very careful with this.

There are several simple invariants for these methods.

s1.index(s2, start, end) (for non-negative indices) returns minimal index i such that start <= i and i + len(s2) <= end and s1[i: i + len(s2)] = s2. Or raise an exception if such index doesn't exist. find() returns -1 instead of an exception. Therefore "".find("", 1, 0) should be -1 and it is. All right.

The only bug is in inconsistency in startswith/endswith between str and bytes (unicode and str in Python 2). The worse, the behavior of str in Python 2 and Python 3 is different.

s1.startswith(s2, start, end) (for non-negative indices and non-tuple s2) is equivalent to start + len(s2) <= end and s2[start: start + len(s2)] == s2. Or to s1.find(s2, start, end) == start. Therefore "".startswith("", 1, 0) should be False, and it is for bytes and str in Python 2. The behavior of "".startswith("", 1, 0) in Python 3 and u"".startswith(u"", 1, 0) in Python 3 is wrong.

The question is can we fix this behavior in default branch (I think rather yes) and should we fix it in maintained releases (doubt)?

----------
components: +Interpreter Core, Unicode
nosy: +benjamin.peterson, ezio.melotti, haypo, lemburg, pitrou, serhiy.storchaka
versions: +Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May 20 16:13:01 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 May 2015 14:13:01 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432131181.09.0.541834308314.issue24243@psf.upfronthosting.co.za>


R. David Murray added the comment:

Serhiy: I agree.  I think the consistency with python2's string is the deciding factor, and we ought to fix it in default.  But not 3.4, because it is a behavior change.  I'd like other people's opinions, though.

----------

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

From report at bugs.python.org  Wed May 20 22:12:23 2015
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 May 2015 20:12:23 +0000
Subject: [docs] [issue24240] PEP 448: Update the language reference
In-Reply-To: <1432041544.18.0.803437691236.issue24240@psf.upfronthosting.co.za>
Message-ID: <1432152744.0.0.517300069968.issue24240@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> document PEP 448

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

From report at bugs.python.org  Thu May 21 03:12:25 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 May 2015 01:12:25 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432170745.53.0.949732139737.issue24243@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> Changing behavior of such base methods is dangerous 
> and can break existing code.

I agree.  The time to argue an API design is before it released not years later after people have written code that relies on the behavior.  

> To me, semantically, the whole idea of finding nothing, 
> whether in something or in nothing is complete and utter nonsense. 

It might not be something you don't agree with, but it isn't nonsense.  There are a number of ways to view it sensibly (empty sets always a subset of other sets).  There a reason that any() and all() are well-defined for empty iterables.  There a reason that math.factorial(0) returns 1.  Those are useful corner cases that save us from writing special case code.

> Empty string search: I think it is completely valid to be able to find an empty string inside another string,

I concur.

I am closing this one as "not a bug".

Primum non nocere.  First Do No Harm".  Don't break existing code because the OP would "prefer that any attempt to find nothing would result in an exception being raised".  That is a terrible reason to break code.  For better or worse, this state of affairs has existed for a long time and no harm seems to have arisen.

Also keep in mind that the current behaviors are tested, meaning that it is not accidental and is guaranteed across implementations.  See Lib/test/string_tests.py.

Though this is closed as not a bug, feel free to add an example or a mention in the documentation.  Keep it short though.  The purpose of the docs for str.count and str.index are to teach how to use the common case rather than getting lost in a discussion of corner case behavior.  Also, the docs should be affirmatively worded (here is how something works and how to use it) rather than negatively worded (omg, finding nothing is something is nonsense).

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Thu May 21 05:17:41 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 May 2015 03:17:41 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432178261.77.0.839594080888.issue24243@psf.upfronthosting.co.za>


R. David Murray added the comment:

Raymond: this is currently marked as a documentation bug, and documentation is mostly what the OP was asking for.  So I'm reopening it.

That said, I think it is very appropriate to discuss fixing the behavior of string's endswith and startswith, because people are still (and will be for a while yet) porting from python2 and supporting single-code-base code, where string behaves the way bytes does in python3.  That should be addressed in a separate issue.  So in fact, history and "code written for the current behavior" comes down, IMO, on the side of fixing this edge case.  I'm willing to be argued out of that, though :)

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

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

From report at bugs.python.org  Thu May 21 08:29:41 2015
From: report at bugs.python.org (John Runyon)
Date: Thu, 21 May 2015 06:29:41 +0000
Subject: [docs] [issue24256] threading.Timer is not a class
Message-ID: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za>


New submission from John Runyon:

the documentation (https://docs.python.org/2/library/threading.html#threading.Timer) lists "threading.Timer" as a class. It is not, which means that (for example) you can not use it in isinstance(). "threading._Timer" is a class. "threading.Timer(...).__class__" is a class. "threading.Timer" is a function.

>>> import threading
>>> threading.Timer
<function Timer at 0x7f99cae23848>

----------
assignee: docs at python
components: Documentation
messages: 243735
nosy: docs at python, jrunyon
priority: normal
severity: normal
status: open
title: threading.Timer is not a class
versions: Python 2.7

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

From report at bugs.python.org  Thu May 21 08:44:41 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 May 2015 06:44:41 +0000
Subject: [docs] [issue24256] threading.Timer is not a class
In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za>
Message-ID: <1432190681.08.0.88316953903.issue24256@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is really a duplicate of Issue5831 which ended up being closed as a duplicate of Issue10968.  The resolution of the latter issue was to change threading.Timer in Python 3.3 to actually be a class, a new feature.  But it appears that along the way the issue of correcting the documentation for 2.7 was never addressed.  Perhaps you could propose wording for a documentation patch?

----------
nosy: +ned.deily
stage:  -> needs patch

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

From heamnath.j at 8kmiles.com  Thu May 21 09:47:28 2015
From: heamnath.j at 8kmiles.com (Heamnath Jayaraman)
Date: Thu, 21 May 2015 13:17:28 +0530
Subject: [docs] Query
Message-ID: <CA+BoX81WMaFKJ-TNtHzFQzpSdHEbRcXSy=JcC_LHMyhTmEVPPQ@mail.gmail.com>

Hello,

Where would '.pyc' files stored in my ubuntu machine

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20150521/6458f539/attachment-0001.html>

From report at bugs.python.org  Thu May 21 12:54:53 2015
From: report at bugs.python.org (John Runyon)
Date: Thu, 21 May 2015 10:54:53 +0000
Subject: [docs] [issue24256] threading.Timer is not a class
In-Reply-To: <1432189781.3.0.318420798275.issue24256@psf.upfronthosting.co.za>
Message-ID: <1432205693.4.0.789421675361.issue24256@psf.upfronthosting.co.za>


John Runyon added the comment:

Concise documentation isn't my forte, but my confusion would've been avoided with a note that "for historical reasons, threading.Timer is actually a factory function for the underlying class threading._Timer" or something along those lines.

----------

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

From report at bugs.python.org  Fri May 22 10:00:25 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Fri, 22 May 2015 08:00:25 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>
Message-ID: <1432281625.52.0.736482205445.issue24219@psf.upfronthosting.co.za>


Dmitry Kazakov added the comment:

Please, do tell me if I'm wrong deleting that literal and it actually serves some purpose...

----------

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

From report at bugs.python.org  Fri May 22 15:53:52 2015
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 May 2015 13:53:52 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>
Message-ID: <1432302832.77.0.617348761899.issue24219@psf.upfronthosting.co.za>


R. David Murray added the comment:

I believe you are correct.

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

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

From report at bugs.python.org  Fri May 22 18:34:54 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 May 2015 16:34:54 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1432312494.36.0.540970719363.issue24204@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

With 'leading end' and 'trailing end' replaced by 'left and 'right', the addition looks good to me.

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

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

From report at bugs.python.org  Sat May 23 00:03:14 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 May 2015 22:03:14 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1432332194.86.0.178369623942.issue24204@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This patch looks reasonable.

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

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

From report at bugs.python.org  Sat May 23 01:29:51 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 May 2015 23:29:51 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>
Message-ID: <1432337391.94.0.26038330336.issue24219@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/issue24219>
_______________________________________

From report at bugs.python.org  Sat May 23 01:38:24 2015
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 22 May 2015 23:38:24 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>
Message-ID: <20150522233821.45367.68685@psf.io>


Roundup Robot added the comment:

New changeset 645a03e93008 by Raymond Hettinger in branch '3.4':
Issue #24219: Remove duplicate literal in docs.
https://hg.python.org/cpython/rev/645a03e93008

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

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

From report at bugs.python.org  Sat May 23 01:40:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 May 2015 23:40:53 +0000
Subject: [docs] [issue24219] Repeated integer in Lexical analysis/Integer
	literals	section
In-Reply-To: <1431886251.68.0.470371931129.issue24219@psf.upfronthosting.co.za>
Message-ID: <1432338053.2.0.954838623167.issue24219@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May 23 09:37:47 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 07:37:47 +0000
Subject: [docs] [issue24195] Add `Executor.filter` to concurrent.futures
In-Reply-To: <1431638802.0.0.167827013304.issue24195@psf.upfronthosting.co.za>
Message-ID: <1432366667.65.0.566372537626.issue24195@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From zvyagin.alexander at gmail.com  Sat May 23 11:29:18 2015
From: zvyagin.alexander at gmail.com (Alexander Zvyagin)
Date: Sat, 23 May 2015 11:29:18 +0200
Subject: [docs] (no subject)
Message-ID: <CAGqvA+txcgQHb6c0dpYNNjw2iv5C3hi+ANjWMFUDPYno9BgOJg@mail.gmail.com>

Sorry if this is a wrong place to send a bug report.

I have a ctype-python code which crashes on PyErr_SetString(). I
checked it on several different machones/OS/gcc versions. More info
here:

http://stackoverflow.com/questions/30347852/segmentation-faut-on-pyerr-setstring

Is it a python/ctype bug or it is me how is doing something wrong?

Alexander

From report at bugs.python.org  Sat May 23 13:23:23 2015
From: report at bugs.python.org (Dmitry Kazakov)
Date: Sat, 23 May 2015 11:23:23 +0000
Subject: [docs] [issue24269] Few improvements to the collections
	documentation
Message-ID: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za>


New submission from Dmitry Kazakov:

collections.Counter: Formatted the code in the "See also" section.

collections.deque.remove: "Removed the first occurrence of value." -> "Remove ..."

collections.deque.index (a followup from issue23704):
    
Changed [, end] to [, stop] in the signature, because the implementation and the docstring of deque.index use 'stop'. Also, adapted the brief explanation from the Common Sequence Operations table.

https://docs.python.org/3/library/stdtypes.html#common-sequence-operations

----------
assignee: docs at python
components: Documentation
files: collections_doc.diff
keywords: patch
messages: 243909
nosy: docs at python, vlth
priority: normal
severity: normal
status: open
title: Few improvements to the collections documentation
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file39473/collections_doc.diff

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

From report at bugs.python.org  Sat May 23 17:36:53 2015
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 23 May 2015 15:36:53 +0000
Subject: [docs] [issue24271] Python site randomly scrolls up when on mobile.
Message-ID: <1432395413.21.0.942984421958.issue24271@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I was trying to read this page:

https://www.python.org/dev/peps/pep-0492/#acceptance

On my mobile. (Nexus 5, chrome.) But when scrolling down the page, the browser sometimes scrolls up to the top of the page. This makes reading very annoying because I have to find the place I was reading at every time it does that.

----------
assignee: docs at python
components: Documentation
messages: 243922
nosy: cool-RR, docs at python
priority: normal
severity: normal
status: open
title: Python site randomly scrolls up when on mobile.
type: behavior

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

From report at bugs.python.org  Sat May 23 17:37:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 15:37:46 +0000
Subject: [docs] [issue24269] Few improvements to the collections
	documentation
In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za>
Message-ID: <1432395466.13.0.0721477131616.issue24269@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/issue24269>
_______________________________________

From report at bugs.python.org  Sat May 23 17:43:01 2015
From: report at bugs.python.org (Ned Deily)
Date: Sat, 23 May 2015 15:43:01 +0000
Subject: [docs] [issue24271] Python site randomly scrolls up when on mobile.
In-Reply-To: <1432395413.21.0.942984421958.issue24271@psf.upfronthosting.co.za>
Message-ID: <1432395781.77.0.121182493306.issue24271@psf.upfronthosting.co.za>


Ned Deily added the comment:

Problems with the python.org website are tracked at https://github.com/python/pythondotorg/issues.  This is a duplicate of https://github.com/python/pythondotorg/issues/531.

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: behavior -> 

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

From report at bugs.python.org  Sat May 23 17:57:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 15:57:46 +0000
Subject: [docs] [issue24269] Few improvements to the collections
	documentation
In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za>
Message-ID: <1432396666.7.0.416709703647.issue24269@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.  I've applied all of it except for the expansion of code in the multiset example where I've keep the style of the itertools recipes.

----------

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

From report at bugs.python.org  Sat May 23 17:58:12 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 May 2015 15:58:12 +0000
Subject: [docs] [issue24269] Few improvements to the collections
	documentation
In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za>
Message-ID: <20150523155809.17927.88223@psf.io>


Roundup Robot added the comment:

New changeset 4d92ce08de6a by Raymond Hettinger in branch 'default':
Issue #24269: Minor doc fixups.
https://hg.python.org/cpython/rev/4d92ce08de6a

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

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

From report at bugs.python.org  Sat May 23 17:58:50 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 15:58:50 +0000
Subject: [docs] [issue24269] Few improvements to the collections
	documentation
In-Reply-To: <1432380203.09.0.901272885626.issue24269@psf.upfronthosting.co.za>
Message-ID: <1432396730.57.0.871769153951.issue24269@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May 23 18:05:32 2015
From: report at bugs.python.org (Carol Willing)
Date: Sat, 23 May 2015 16:05:32 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1432397132.73.0.685591537668.issue24204@psf.upfronthosting.co.za>


Carol Willing added the comment:

Updated patch with Terry's suggested changes. Thanks Terry and Raymond for the review of the initial patch.

----------
Added file: http://bugs.python.org/file39476/iss24204b.patch

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

From report at bugs.python.org  Sat May 23 18:12:04 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 May 2015 16:12:04 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <20150523161200.96200.95797@psf.io>


Roundup Robot added the comment:

New changeset 367e3923532f by Raymond Hettinger in branch 'default':
Issue #24204:  Elaborate of the str.strip() documentation.
https://hg.python.org/cpython/rev/367e3923532f

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

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

From report at bugs.python.org  Sat May 23 18:12:27 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 16:12:27 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1432397547.01.0.290333748999.issue24204@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
resolution:  -> fixed
stage: patch review -> resolved

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

From report at bugs.python.org  Sat May 23 18:12:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 May 2015 16:12:53 +0000
Subject: [docs] [issue24204] string.strip() documentation is misleading
In-Reply-To: <1431722976.33.0.78521103066.issue24204@psf.upfronthosting.co.za>
Message-ID: <1432397573.23.0.705709330031.issue24204@psf.upfronthosting.co.za>


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


----------
status: open -> closed

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

From report at bugs.python.org  Sat May 23 23:09:28 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 23 May 2015 21:09:28 +0000
Subject: [docs] [issue24272] PEP 484 docs
Message-ID: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Would be nice if there were more docs for the typing module (PEP 484). Looking for volunteers. (There's stuff in the PEP that can serve as a starting point.)

Note: support for isinstance() and issubclass() will be withdrawn in beta 2.

----------
assignee: docs at python
components: Documentation
messages: 243945
nosy: docs at python, gvanrossum
priority: normal
severity: normal
status: open
title: PEP 484 docs
versions: Python 3.5

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

From report at bugs.python.org  Sat May 23 23:10:00 2015
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 23 May 2015 21:10:00 +0000
Subject: [docs] [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1432415400.3.0.505343624402.issue24272@psf.upfronthosting.co.za>


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


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

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

From moshe.elitzur at gmail.com  Sun May 24 00:30:34 2015
From: moshe.elitzur at gmail.com (Moshe Elitzur)
Date: Sat, 23 May 2015 15:30:34 -0700
Subject: [docs] problem with power index
Message-ID: <5560FF8A.1080502@gmail.com>

My understanding was that 1./p and 1./float(p) should be he same. 
However, the attached test.py produced the output shown in the attached 
Test.PNG, where the two behave differently.  Version 1 of smallest_in 
bombs out at p=6, but this is somewhat sporadic: changing the input 
array a moves the failure point to another p. Changing np.array(a)**p to 
np.array(a)**float(p) in smallest_in2 solves the problem.

Shouldn't a proper behavior of python mean that there would not be a 
need to use float(p) in the last two lines of the function?

Thanks,
Moshe Elitzur

PS the code was run with Python 2.7.6 64-bit on a PC with windows 7
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Test.PNG
Type: image/png
Size: 99161 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20150523/63faeab8/attachment-0001.png>
-------------- next part --------------
import numpy as np


def smallest_in1(a, p):
    """ Smooth selection of smallest number in array a
    p (> 0) controlls the transition abruptness; 
    the larger is p, the sharper the transition
    """
    for a_ in a:
        if a_ == 0: return 0
    s = sum(1./np.array(a)**p)
    return 1./s**(1./float(p))         

def smallest_in2(a, p):
    """ Smooth selection of smallest number in array a
    p (> 0) controlls the transition abruptness; 
    the larger is p, the sharper the transition
    """
    for a_ in a:
        if a_ == 0: return 0
    s = sum(1./np.array(a)**float(p))
    return 1./s**(1./float(p))         


a = range(3,50)
plist = range(1,20)
fmt = '%3d'+2*'%12.4f'
print '\n  p  smallest_in1  smallest_in2'
for p in plist:
    print fmt %(p, smallest_in1(a, p), smallest_in2(a, p))

From report at bugs.python.org  Sun May 24 13:57:35 2015
From: report at bugs.python.org (Jackmoo)
Date: Sun, 24 May 2015 11:57:35 +0000
Subject: [docs] [issue11029] Crash, 2.7.1,
	Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1432468655.17.0.675376900407.issue11029@psf.upfronthosting.co.za>


Jackmoo added the comment:

Hi there, recently I also encounter this in windows(7), and my python program occasionally crash and the windows pops 'appcrash' message with tcl8.5.dll error c000005 (access violation).

And this end up related to thread safe problem described as above. Since in my program, I have to build the tkinter UI in another thread (main thread was occupied by other module which blocking), so I can't follow the 'build UI in main thread' solution. My work around is, add a handler which using .after() and get_nowait() to call itself periodically to handle the command in queue.

def commandQueueHandler(self):
    try:
        while 1:
            your_command = self.textCommandQueue.get_nowait()
            if your_command is not None:
                # execute the command ....
            self.Text.update_idletasks()
    except Queue.Empty:
        pass
    self.Text.after(100, self.commandQueueHandler)

Once this method is triggered, just build another thread to put() command in textCommandQueue, then it will be executed periodically.
One thing that should mention is the update_idletasks() should be added after each command execution, otherwise the UI refresh will be slower then expected. (in my case, the scrolling of Text widge is a bit 'sticky' when I pull it. After adding update_idletasks(), it becomes smoother.)

TL:DR,
If you have to run tkinter UI in another thread, add a queue and self-called method with after() and get_nowait() in UI thread to handle the queue. If you want to send command to UI at other thread, just put() the command in the queue of UI thread.

----------
nosy: +Jackmoo

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

From report at bugs.python.org  Sun May 24 17:27:38 2015
From: report at bugs.python.org (Martin Blais)
Date: Sun, 24 May 2015 15:27:38 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
Message-ID: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>


New submission from Martin Blais:

Functions that parse arguments like  PyArg_ParseTupleAndKeywords() have several formatters that fill in C strings, e.g. "s".

In the C API doc:
https://docs.python.org/3.5/c-api/arg.html#c.PyArg_ParseTupleAndKeywords

There should be an explicit mention of whether this memory needs to be free (in this case: No) and if not, how this memory is managed (in this case: This refers to a buffer managed by the string object itself). Because of questions of encoding, it raises questions where this memory lies, and what its lifetime is (in this case: That of the owning string object from the caller).

This deserves an explicit mention, even if brief.

----------
assignee: docs at python
components: Documentation
messages: 243987
nosy: blais, docs at python
priority: normal
severity: normal
status: open
title: Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings

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

From report at bugs.python.org  Sun May 24 17:31:13 2015
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 May 2015 15:31:13 +0000
Subject: [docs] [issue11029] Crash, 2.7.1,
	Tkinter and threads and line drawing
In-Reply-To: <1296147664.2.0.443864502869.issue11029@psf.upfronthosting.co.za>
Message-ID: <1432481473.25.0.877765880303.issue11029@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks for the report.

----------

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

From report at bugs.python.org  Sun May 24 17:35:56 2015
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 24 May 2015 15:35:56 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432481755.98.0.169533819705.issue24278@psf.upfronthosting.co.za>


Andrew Svetlov added the comment:

Would you propose a patch for docs?

----------
nosy: +asvetlov
stage:  -> needs patch

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

From report at bugs.python.org  Sun May 24 18:07:56 2015
From: report at bugs.python.org (Martin Blais)
Date: Sun, 24 May 2015 16:07:56 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432483676.1.0.622223022423.issue24278@psf.upfronthosting.co.za>


Martin Blais added the comment:

I don't think I'm the right person to propose a patch for this; I'm just guessing how it works so far, I haven't had time to look into the source code in detail, I'm sure there's a lot more context to it.

----------

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

From report at bugs.python.org  Sun May 24 20:30:48 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Sun, 24 May 2015 18:30:48 +0000
Subject: [docs] [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1432492248.25.0.787140968179.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

A first iteration of the documentation based on the PEP and the module source.

This still needs a lot of work.

----------
keywords: +patch
nosy: +Daniel.Andrade.Groppe
Added file: http://bugs.python.org/file39484/typing_doc.patch

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

From report at bugs.python.org  Mon May 25 00:40:22 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 24 May 2015 22:40:22 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432507222.22.0.193457881846.issue24278@psf.upfronthosting.co.za>


Martin Panter added the comment:

At the top of the list <https://docs.python.org/3.5/c-api/arg.html#strings-and-buffers>, it says which cases have to be freed or not, and also mentions releasing buffers. Are you proposing to add this information to each entry in the list as well?

Or just mention how the pointer lifetime relates to the Python object lifetime at the top? I think you will find most of the cases are the same, except for the ones that explicitly allocate extra memory.

----------
nosy: +vadmium

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

From report at bugs.python.org  Mon May 25 05:47:05 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Mon, 25 May 2015 03:47:05 +0000
Subject: [docs] [issue24272] PEP 484 docs
In-Reply-To: <1432415368.91.0.945654992881.issue24272@psf.upfronthosting.co.za>
Message-ID: <1432525624.44.0.241771403449.issue24272@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

Addressing comments from the review. Here is an updated patch.

----------
Added file: http://bugs.python.org/file39487/typing_doc_v2.patch

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

From report at bugs.python.org  Mon May 25 05:47:41 2015
From: report at bugs.python.org (James Luscher)
Date: Mon, 25 May 2015 03:47:41 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
Message-ID: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>


New submission from James Luscher:

Doc for 3.4: at 6.1.3.1. Format Specification Mini-Language
indicates that:
"The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value"

Yet I find that I get this behavior:

Python 3.4.3 (default, Mar 26 2015, 22:03:40) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> '{:08.3}'.format(12.34)
'000012.3'

When what I am expecting is:  '0012.340'

----------
assignee: docs at python
components: Documentation
messages: 244011
nosy: docs at python, jluscher
priority: normal
severity: normal
status: open
title: String formatting: incorrect number of decimal places
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May 25 05:53:51 2015
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 25 May 2015 03:53:51 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432526031.14.0.0714852126265.issue24281@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


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

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

From report at bugs.python.org  Mon May 25 06:02:58 2015
From: report at bugs.python.org (Christopher Welborn)
Date: Mon, 25 May 2015 04:02:58 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432526578.0.0.445211038392.issue24281@psf.upfronthosting.co.za>


Christopher Welborn added the comment:

You forgot the 'f' to specify that you want float formatting:

```
>>> '{:08.3f}'.format(12.34)

 '0012.340'
```

----------
nosy: +cjwelborn

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

From report at bugs.python.org  Mon May 25 06:22:09 2015
From: report at bugs.python.org (Daniel Andrade Groppe)
Date: Mon, 25 May 2015 04:22:09 +0000
Subject: [docs] [issue24021] Add docstring to urllib.urlretrieve
In-Reply-To: <1429673026.41.0.442066158913.issue24021@psf.upfronthosting.co.za>
Message-ID: <1432527729.36.0.891629883783.issue24021@psf.upfronthosting.co.za>


Daniel Andrade Groppe added the comment:

Adding docstrings for urllib.urlretrieve() and urlib.cleanup() for Python 2.7.

----------
keywords: +patch
nosy: +Daniel.Andrade.Groppe
Added file: http://bugs.python.org/file39488/urllib_2.7.patch

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

From report at bugs.python.org  Mon May 25 06:27:09 2015
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 May 2015 04:27:09 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432528029.19.0.994320025038.issue24281@psf.upfronthosting.co.za>


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


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

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

From guido at python.org  Sun May 24 23:35:16 2015
From: guido at python.org (guido at python.org)
Date: Sun, 24 May 2015 21:35:16 -0000
Subject: [docs] PEP 484 docs (issue 24272)
Message-ID: <20150524213516.11155.59905@psf.upfronthosting.co.za>

Reviewers: ,

Message:
Thank you so much for getting this started! I will try to give a more
detailed review later. For now, I noticed you documented a number of
internal classes, e.g. Final and various metaclasses. While their names
don't start with _, they aren't meant to be part of the interface
exported by the module, and they aren't listed in __all__. Could you
drop anything that's not listed in __all__ from the docs?



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

Affected files:
  Doc/library/typing.rst



From report at bugs.python.org  Mon May 25 13:42:17 2015
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 May 2015 11:42:17 +0000
Subject: [docs] [issue24243] behavior for finding an empty string is
	inconsistent	with documentation
In-Reply-To: <1432094562.27.0.346738352121.issue24243@psf.upfronthosting.co.za>
Message-ID: <1432554136.94.0.126987247718.issue24243@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened separate issue24284 for inconsistency in startswith/endswith.

----------

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

From report at bugs.python.org  Mon May 25 14:32:10 2015
From: report at bugs.python.org (Martin Blais)
Date: Mon, 25 May 2015 12:32:10 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432557130.2.0.785067063599.issue24278@psf.upfronthosting.co.za>


Martin Blais added the comment:

Adding information that tells developers where the memory for those returned areas is stored and as you mention, its lifetime guarantees w.r.t. to the Python object, would go a long way towards making this more clear. The questions that immediately came to my mind were:

- Is this memory attached to the object?

- What if there is a conversion... is it still attached to the object? The converter for "s" says "Unicode objects are converted to C strings using 'utf-8' encoding."  Where is the output of this conversion stored? Does it have the same lifetime as its PyObject as well or does it use a cache of recent conversions (e.g. like re/struct), or just static storage? And if so, is it thread-safe?

I can find all these answers by looking at the source code for C/Python, or I can _guess_ that extra data is attached to some sort of 'extra' field in a PyObject (which would be a sensible thing to do), but my point is that an API user shouldn't have to dig in the source or have to guess for such important concerns. I think we should be a bit more transparent in the docs.

----------

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

From report at bugs.python.org  Mon May 25 15:05:35 2015
From: report at bugs.python.org (Martin Blais)
Date: Mon, 25 May 2015 13:05:35 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432559135.55.0.321270392953.issue24278@psf.upfronthosting.co.za>


Martin Blais added the comment:

Oh, and yes, just adding this info at the top would be fine IMO. It shouldn't have to be repeated.

----------

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

From report at bugs.python.org  Mon May 25 20:40:43 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 May 2015 18:40:43 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432579243.47.0.0930994529891.issue24281@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Just to clarify:

If not specified, the default "presentation type" for floats is "g". Since you didn't specify "f" in your example, it's using "g". For presentation type "g", the precision (3 in your case) is the total number of significant digits. So 12.34 first becomes 12.3, then that's displayed in a field 8 characters wide, which gives you the 4 leading zeros.

See the section of presentation types for floating point at the end of this section:
https://docs.python.org/2/library/string.html#format-specification-mini-language

----------

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

From report at bugs.python.org  Tue May 26 07:22:24 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 May 2015 05:22:24 +0000
Subject: [docs] [issue13341] Incorrect documentation for "u" PyArg_Parse
	format unit
In-Reply-To: <1320412814.48.0.657162308895.issue13341@psf.upfronthosting.co.za>
Message-ID: <1432617744.43.0.18548108642.issue13341@psf.upfronthosting.co.za>


Martin Panter added the comment:

The Python 3 documentation was updated in Issue 8593 (revision 5d4a5655575f). Perhaps some of the wording also applies to Python 2 and you can just copy it.

----------
nosy: +vadmium

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

From report at bugs.python.org  Tue May 26 07:53:04 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 May 2015 05:53:04 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432619584.65.0.186032371362.issue24278@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is my understanding of where the buffers would be managed and what governs their lifetimes, though I haven?t analyzed the code to verify:

s, z: str -> UTF-8 cache -> pointer for object lifetime
s*, z*: str -> UTF-8 cache -> buffer; bytes-like -> buffer; until release
y*: bytes-like -> buffer until release
S: bytes borrowed object
Y: bytearray borrowed object
u, u#, Z, Z#: str -> Py_UNICODE cache -> pointer for object lifetime
U: str borrowed object
w*: writable bytes-like -> buffer until release
es, es#: str -> encoded -> pointer until free (or pre-allocated for es#)
et, et#: str -> encoded -> pointer; bytes, bytearray -> pointer; until free (or pre-allocated for et#)

One open question that has worried me a bit is the ?s#?, ?z#?, ?y?, ?y#? codes, which are documented as requiring immutable bytes-like objects, but do not return a buffer structure. I guess this is designed for objects like bytes(), where the pointer would remain valid for the object?s lifetime, even if it has been released according to the buffer protocol. But how is this guaranteed for arbitrary buffer objects? Some undocumented requirement of the buffer?s ?readonly? flag perhaps?

So I propose to add:

* Lifetime of all Py_buffer return values is until PyBuffer_Release() is called
* Unless otherwise documented, for conversions that return pointers to buffers, the buffer is managed or cached inside the Python object, and the lifetime of that buffer is the same as the whole Python object
* Unconverted Python objects are borrowed references
* For the four immutable bytes-like conversions I mentioned that return pointers, the buffer management and lifetime is not documented (unless somebody comes up with a better explanation)

----------

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

From chenat31 at yahoo.com  Tue May 26 07:29:07 2015
From: chenat31 at yahoo.com (Qi Chen)
Date: Tue, 26 May 2015 07:29:07 +0200
Subject: [docs] A typo. An index,
	not a index in the last line copies here from 3. Informal intro...
Message-ID: <B26878B1-EEF1-47F9-B102-79CB3E420F1F@yahoo.com>

For non-negative indices, the length of a slice is the difference of the indices, if both are within bounds. For example, the length of word[1:3] is 2.

Attempting to use a index that is too large will result in an error:


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

From report at bugs.python.org  Tue May 26 10:10:40 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 May 2015 08:10:40 +0000
Subject: [docs] [issue24278] Docs on Parsing arguments should say something
	about mem	mgmt for formatters returning C strings
In-Reply-To: <1432481258.46.0.49462668629.issue24278@psf.upfronthosting.co.za>
Message-ID: <1432627840.71.0.125332969671.issue24278@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch.

Looking at the code, s#, z#, y and y# are the conversions that call convertbuffer(). These require that the object does not have a PyBufferProcs.bf_releasebuffer() method, which guarantees that the buffer?s lifetime is the same as the underlying object.

In the patch I also removed a contradictory notice about nulls with the ?u? conversion.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39504/buffer-convert.patch

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

From report at bugs.python.org  Tue May 26 13:03:22 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 26 May 2015 11:03:22 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432638202.31.0.0277599276803.issue24281@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

And I just double checked: the entirety of the sentence you quoted is:

The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value formatted with 'f' and 'F', or before and after the decimal point for a floating point value formatted with 'g' or 'G'.

I think that's reasonably clear for 'g' and 'G', but if you think it could be improved, I'm open to suggestions. Maybe the disconnect is that 'g' is the default?

The only reason I'm following up on this is that I'm familiar with all of this, yet it still took me some experimenting to remember what the issue is.

----------

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

From report at bugs.python.org  Tue May 26 15:10:18 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 May 2015 13:10:18 +0000
Subject: [docs] [issue23560] Group the docs of similar methods in
	stdtypes.rst
In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>
Message-ID: <1432645817.29.0.652214354593.issue23560@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch that groups similar methods of the str() class together at various levels.

I added an alphabetical index of the methods, currently as a big paragraph of hyperlinks in the existing String Methods section. Then I added the following seven new sections. Ideally they would be ordered from important to obscure.

* String Formatting
* Searching and Replacing
* Splitting and Joining
* String Classification
* Case Manipulation
* Padding and Stripping
* Translation and Encoding

Within each section, most methods remain separate with no change to their descriptions. Some are grouped under a single description, where a there is an obvious pattern. I have tried put closely related methods nearby, while putting important and simple methods higher up, and moving their obscure and complex counterparts lower down.

Depending on outcome of these changes to the string methods, I may also be interested in doing a similar job to the bytes() and bytearray() methods.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file39506/str-groups.patch

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

From report at bugs.python.org  Tue May 26 15:24:10 2015
From: report at bugs.python.org (James Luscher)
Date: Tue, 26 May 2015 13:24:10 +0000
Subject: [docs] [issue24281] String formatting: incorrect number of decimal
	places
In-Reply-To: <1432525661.76.0.778289488929.issue24281@psf.upfronthosting.co.za>
Message-ID: <1432646650.61.0.401745099966.issue24281@psf.upfronthosting.co.za>


James Luscher added the comment:

Eric,
I am not familiar with the 'g' format and did not know it was the default, but the documentation, read fully, is correct.  It just took the response of Christopher Welborn to "wake me up" (it was a LONG day and I was "struggling" to understand the problem - I would hate to tell you how long I worked on this problem !  {embarrassment!!}).

My programming usually involves text manipulation, data structures and GUIs.  The am familiar with the use of 'precision' as length of the decimal fraction but was thrown by (the equally valid) use of 'precision' as the mathematical idea referring to 'significant digits'. Counting BOTH sides of decimal point was a difficult switch of word meaning to get my head around.

Just because "I" have never(!) used the 'g' format doesn't mean it isn't the proper choice for 'default'.  Language is often a challenge and 'precision' with two meanings (# of digits to right of decimal AND total # of digits {right and left of decimal)) does present a linguistic challenge to one's ability to comprehend what the word means ;-)

I wish I could give you the solution but at least I (finally !) understand the mental issue involved.

Thanks to both of you for your help getting me past my 'mental fugue' ;-)

----------

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

From report at bugs.python.org  Wed May 27 01:20:49 2015
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 May 2015 23:20:49 +0000
Subject: [docs] [issue23756] Tighten definition of bytes-like objects
In-Reply-To: <1427185517.26.0.298293861062.issue23756@psf.upfronthosting.co.za>
Message-ID: <1432682449.76.0.0834857913557.issue23756@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May 27 02:35:57 2015
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 27 May 2015 00:35:57 +0000
Subject: [docs] [issue23560] Group the docs of similar methods in
	stdtypes.rst
In-Reply-To: <1425288490.4.0.288876913126.issue23560@psf.upfronthosting.co.za>
Message-ID: <1432686957.67.0.854711722186.issue23560@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/issue23560>
_______________________________________

From report at bugs.python.org  Wed May 27 14:22:01 2015
From: report at bugs.python.org (Sandy Chapman)
Date: Wed, 27 May 2015 12:22:01 +0000
Subject: [docs] [issue24296] Queue documentation note needed
Message-ID: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za>


New submission from Sandy Chapman:

The example at the bottom of the following page should have a warning added:

https://docs.python.org/2/library/queue.html

The warning should be such that the user is informed that the threads in the example are not cleaned up and will continue to run. Any future additions to the queue will then be processed immediately by those threads.

----------
assignee: docs at python
components: Documentation
messages: 244156
nosy: Sandy Chapman, docs at python
priority: normal
severity: normal
status: open
title: Queue documentation note needed

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

From report at bugs.python.org  Wed May 27 15:27:30 2015
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 May 2015 13:27:30 +0000
Subject: [docs] [issue24296] Queue documentation note needed
In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za>
Message-ID: <1432733250.84.0.270504940836.issue24296@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you know anything about threads you can see that the threads are not explicitly shut down.  As a standalone example it is "correct", in that they get shut down at interpreter shutdown.

I'm not sure it is appropriate to include what is essentially a thread tutorial note in the queue docs.  A crosslink to threading would certainly be a good idea; perhaps the introductory sentence could be tweaked to point people who don't already know threads in the correct direction for enlightenment.

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

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

From report at bugs.python.org  Wed May 27 16:54:44 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 May 2015 14:54:44 +0000
Subject: [docs] [issue24296] Queue documentation note needed
In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za>
Message-ID: <1432738484.71.0.508511964192.issue24296@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/issue24296>
_______________________________________

From report at bugs.python.org  Wed May 27 17:02:02 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 May 2015 15:02:02 +0000
Subject: [docs] [issue24296] Queue documentation note needed
In-Reply-To: <1432729321.3.0.0746320695027.issue24296@psf.upfronthosting.co.za>
Message-ID: <1432738922.48.0.00525454748975.issue24296@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It is normal for daemon threads to not be shut down.   That is why they exist.  The purpose of Queue.join() is to give other threads a way to know when daemons have finished doing their work (i.e. a print manager thread to indicate that it is done printing).  If the worker threads were actually going to terminate, you wouldn't need Queue.join(), you would use a Thread.join().

----------

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

From report at bugs.python.org  Wed May 27 22:05:34 2015
From: report at bugs.python.org (Leonardo Tada)
Date: Wed, 27 May 2015 20:05:34 +0000
Subject: [docs] [issue24304] Documentation broken link to license
Message-ID: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za>


New submission from Leonardo Tada:

In this page https://docs.python.org/3.4/faq/general.html#are-there-copyright-restrictions-on-the-use-of-python
the link for "the PSF license page" is broken.

----------
assignee: docs at python
components: Documentation
messages: 244217
nosy: Leonardo Tada, docs at python
priority: normal
severity: normal
status: open
title: Documentation broken link to license

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

From report at bugs.python.org  Thu May 28 00:39:08 2015
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 May 2015 22:39:08 +0000
Subject: [docs] [issue24304] Documentation broken link to license
In-Reply-To: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za>
Message-ID: <20150527223905.5075.36028@psf.io>


Roundup Robot added the comment:

New changeset d4080f3c0894 by Ned Deily in branch '2.7':
Issue 24304: Fix broken license link in FAQ.
https://hg.python.org/cpython/rev/d4080f3c0894

New changeset 8631d61f6577 by Ned Deily in branch '3.4':
Issue 24304: Fix broken license link in FAQ.
https://hg.python.org/cpython/rev/8631d61f6577

New changeset 892a8bed619d by Ned Deily in branch '3.5':
Issue 24304: Fix broken license link in FAQ.
https://hg.python.org/cpython/rev/892a8bed619d

New changeset e57e37c3986c by Ned Deily in branch 'default':
Issue 24304: Fix broken license link in FAQ.
https://hg.python.org/cpython/rev/e57e37c3986c

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

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

From report at bugs.python.org  Thu May 28 00:40:31 2015
From: report at bugs.python.org (Ned Deily)
Date: Wed, 27 May 2015 22:40:31 +0000
Subject: [docs] [issue24304] Documentation broken link to license
In-Reply-To: <1432757134.25.0.903023321673.issue24304@psf.upfronthosting.co.za>
Message-ID: <1432766431.77.0.868320225556.issue24304@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!

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

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

From report at bugs.python.org  Thu May 28 07:09:07 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 28 May 2015 05:09:07 +0000
Subject: [docs] [issue24310] Idle documentation -- what to do if you do not
	see an	underscore.
Message-ID: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za>


New submission from Laura Creighton:

On some operating systems, for instance a Macbook Pro with Retina, the
bottoms of hanging letters such as 'g' or 'y', as well as underscorces, cannot be seen in IDLE.  The fix is to go to Options -> Configure IDLE, and change the size of the default font to 9 or 11. 

Can we add this line to 25.5.5.2. and 24.6.5.2. ?  It is not obvious, especially to the newbie who is trying to write their first python program that the inability to type underscores is a font problem.

----------
assignee: docs at python
components: Documentation
messages: 244267
nosy: docs at python, lac
priority: normal
severity: normal
status: open
title: Idle documentation -- what to do if you do not see an underscore.
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu May 28 07:13:48 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 May 2015 05:13:48 +0000
Subject: [docs] [issue24310] Idle documentation -- what to do if you do not
	see an	underscore.
In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za>
Message-ID: <1432790027.96.0.870926849353.issue24310@psf.upfronthosting.co.za>


Ned Deily added the comment:

That may be a problem better fixed in Tk itself.  I don't have a Retina display handy.  Assuming you have a current ActiveTcl 8.5 (8.5.18) installed, could you try some of the Tk text widget demos in /usr/local/bin/wish8.5 and see if the problem shows up there, too?  Not sure what the font sizes there are, though.  Thanks!

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

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

From report at bugs.python.org  Thu May 28 07:21:41 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 28 May 2015 05:21:41 +0000
Subject: [docs] [issue24310] Idle documentation -- what to do if you do not
	see an	underscore.
In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za>
Message-ID: <1432790501.95.0.619620008061.issue24310@psf.upfronthosting.co.za>


Laura Creighton added the comment:

I don't have one, alas.  It was a question sent to webmaster.  I just
happened to know that reconfiguring your font size fixes the 'no
underscore' problem, so it occured to me that mentioning this in the
idle documentation might save some grief.

----------

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

From report at bugs.python.org  Thu May 28 07:24:52 2015
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 May 2015 05:24:52 +0000
Subject: [docs] [issue24310] Idle documentation -- what to do if you do not
	see an	underscore.
In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za>
Message-ID: <1432790692.91.0.935278676598.issue24310@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yes, that's probably a good thing to do in any case.  I can add it to the Tcl/Tk info page for OS X as at least an interim measure:

https://www.python.org/download/mac/tcltk/

----------
assignee: docs at python -> ned.deily
components: +IDLE
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu May 28 07:41:34 2015
From: report at bugs.python.org (Laura Creighton)
Date: Thu, 28 May 2015 05:41:34 +0000
Subject: [docs] [issue24310] Idle documentation -- what to do if you do not
	see an	underscore.
In-Reply-To: <1432789747.51.0.656358937266.issue24310@psf.upfronthosting.co.za>
Message-ID: <1432791694.91.0.840899031968.issue24310@psf.upfronthosting.co.za>


Laura Creighton added the comment:

Thank you.  I don't think that this problem is unique to Retina Macbooks -- I had it on an ancient Toshiba laptop I was using about 15 years ago.
It's not something that I have thought of very much recently. :)

----------

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

From report at bugs.python.org  Thu May 28 16:27:14 2015
From: report at bugs.python.org (July Tikhonov)
Date: Thu, 28 May 2015 14:27:14 +0000
Subject: [docs] [issue24314] irrelevant cross-link in documentation of
	user-defined	functions
Message-ID: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za>


New submission from July Tikhonov:

https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

There is a table of "special attributes" of user-defined functions. The __name__ attribute name is a link, but it leads to something quite irrelevant: the description of __name__ attribute of imported modules.

In Doc/reference/datamodel.rst, there is nothing special about __name__ attribute, so it looks like some random spasm of Sphinx creating links here and there. My knowledge of rst is not sufficient to suppress it.

----------
assignee: docs at python
components: Documentation
messages: 244301
nosy: docs at python, july
priority: normal
severity: normal
status: open
title: irrelevant cross-link in documentation of user-defined functions
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu May 28 20:01:38 2015
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 May 2015 18:01:38 +0000
Subject: [docs] [issue24318] Better documentaiton of profile-opt (and
	release builds	in general?)
In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za>
Message-ID: <1432836098.39.0.581829894109.issue24318@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agreed with Greg, this should not be the default.  Changing title and component to reflect that better documentation is the goal here.

----------
assignee:  -> docs at python
components: +Documentation -Build
nosy: +docs at python, r.david.murray
stage:  -> needs patch
title: Make profile-opt the default Make target? -> Better documentaiton of profile-opt (and release builds in general?)
versions: +Python 3.4, Python 3.5 -Python 3.6

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

From report at bugs.python.org  Thu May 28 20:43:42 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 28 May 2015 18:43:42 +0000
Subject: [docs] [issue24318] Better documentaiton of profile-opt (and
	release builds	in general?)
In-Reply-To: <1432830865.51.0.995414707141.issue24318@psf.upfronthosting.co.za>
Message-ID: <1432838622.68.0.175557820584.issue24318@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

Thanks. The doc change occurred to me while I was composing my ticket. It wasn't obvious at that time that profile-opt shouldn't be the default (though I was carrying on an email conversation with Greg at about the same time).

----------

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

From report at bugs.python.org  Thu May 28 22:29:03 2015
From: report at bugs.python.org (Brandon Milam)
Date: Thu, 28 May 2015 20:29:03 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1432844943.46.0.653367913656.issue24147@psf.upfronthosting.co.za>


Brandon Milam added the comment:

Hi all,

I've been looking at this bug and am ready to start putting in some work on it but I have some questions about what is wanting to be done. From what I can tell these are the possible tasks for this issue.

- Add to the docs under the dialect section the excel attributes vs. the dialect class attributes and explain how the excel dialect is the default and this is the functionality you'd be changing by creating a new dialect.

- Add code to make sure that a certain number of attributes are set before the dialect can be accessed. (Though this might be C code and not really a C programmer nor do I know where _Dialect is in the repository)

- Change the defaults in the dialects class because currently the documentation for "double quote" and "skip initial space" says that the default is False when in the code it is None. Also I did not find the "strict" dialect in the module at all. (maybe its part of that C code that I don't know how to find.

- Add an example to the documentation on sub-classing dialect under the example on registering a new dialect

If someone could clarify which of these is the desired direction for this issue it would be much appreciated.

----------
nosy: +jbmilam

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

From report at bugs.python.org  Thu May 28 23:08:43 2015
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 28 May 2015 21:08:43 +0000
Subject: [docs] [issue19270] Document that sched.cancel() doesn't
	distinguish equal	events and can break order
In-Reply-To: <1381913252.24.0.629122693277.issue19270@psf.upfronthosting.co.za>
Message-ID: <1432847323.52.0.00979214743297.issue19270@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

sched has been around for a long time, but it's been useless for so many purposes that it *should* handle (completely unsafe in threaded contexts until 3.3, still can't handle useful threaded scenarios today, e.g. scheduling tasks for short delays when draining the task queue, waiting on a task with a long delay, see #20126 ) that calling it acceptable is more about lack of available uses than acceptable design.

Saying "don't schedule two events for the same time and priority if expect to cancel either of them" is not a reasonable solution; the main reason to schedule two such events in that way would be to have the option to cancel one but not the other; as is, trying to cancel one will (pseudo-)randomly cancel either of them. I don't particularly care how it's fixed (though the proposed fix for #13451 seems like a good one), and the issue with changing event order isn't so important, but cancelling the wrong event is really bad.

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

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

From report at bugs.python.org  Thu May 28 23:24:51 2015
From: report at bugs.python.org (Mik)
Date: Thu, 28 May 2015 21:24:51 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1432848291.57.0.805155440042.issue24147@psf.upfronthosting.co.za>


Mik added the comment:

Hi,

I have just read the documentation once again.

The problem is that it specifies that the default value for Dialect.doublequote is True :
<quote>Controls how instances of quotechar appearing inside a field should be themselves be quoted. When True, the character is doubled. When False, the escapechar is used as a prefix to the quotechar. It defaults to True.</quote>

So it is easy to understand that the class csv.Dialect implements this default value. Although the class Dialect default in the csv.reader calling is "Excel" and thus, implicitly, it is csv.excel the default class whose attributes are described in the above paragraph. 

It would be great in this case to describe the attributes of the base class Dialect or specify that all attributes must be settled when we subclass this.

Optionally it would be good that the code of CSV.Dialect be changed for really Boolean values. But the clarification of documentation is more important I think.

----------

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

From report at bugs.python.org  Thu May 28 23:41:54 2015
From: report at bugs.python.org (Brandon Milam)
Date: Thu, 28 May 2015 21:41:54 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1432849314.34.0.505655704332.issue23659@psf.upfronthosting.co.za>


Brandon Milam added the comment:

I believe this was the requested change. Let me know if more was desired.

----------
keywords: +patch
nosy: +jbmilam
Added file: http://bugs.python.org/file39540/register_dialect_docstring_fix.patch

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

From report at bugs.python.org  Thu May 28 23:53:14 2015
From: report at bugs.python.org (Brandon Milam)
Date: Thu, 28 May 2015 21:53:14 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1432849994.12.0.361209769494.issue23659@psf.upfronthosting.co.za>


Brandon Milam added the comment:

Sorry, I forgot an end parentheses in the doc string of the last patch.

----------
Added file: http://bugs.python.org/file39541/register_dialect_docstring_fix.patch

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

From report at bugs.python.org  Fri May 29 01:48:59 2015
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 May 2015 23:48:59 +0000
Subject: [docs] [issue10344] codecs.open() buffering doc needs fix
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1432856939.76.0.525901262111.issue10344@psf.upfronthosting.co.za>


Martin Panter added the comment:

A couple of specific problems have been raised by Terry here. Checking each against the current Python 3 status, some have already been fixed:

* The codecs.open() signature has been fixed in Issue 19548.

* The StreamReader.readline(size=...) parameter documentation has been fixed to match the docstring in Issue 18336.

So that leaves these three problems, as I see it:

1. The notice about opening in binary mode still needs fixing for encoding=None.

2. The buffering parameter is applied to the underlying builtins.open() call, so should be clarified in the documentation.

3. codecs.open(filename, encoding=...) will by default call builtins.open(filename, "rb", buffering=1), which makes no sense according the the documentation.

----------
nosy: +vadmium
stage:  -> needs patch
title: codecs.StreamReader.readline doc needs fix -> codecs.open() buffering doc needs fix

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

From report at bugs.python.org  Fri May 29 01:49:16 2015
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 May 2015 23:49:16 +0000
Subject: [docs] [issue10344] codecs.open() buffering doc needs fix
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1432856956.55.0.304234229959.issue10344@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

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

From report at bugs.python.org  Fri May 29 06:12:13 2015
From: report at bugs.python.org (Martin Panter)
Date: Fri, 29 May 2015 04:12:13 +0000
Subject: [docs] [issue24314] irrelevant cross-link in documentation of
	user-defined	functions
In-Reply-To: <1432823234.49.0.975414233418.issue24314@psf.upfronthosting.co.za>
Message-ID: <1432872732.65.0.521218277241.issue24314@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the proper way to suppress the link is :attr:`!__name__`.

However I am posting a patch which takes a different approach. I tweaked some of the entries under <https://docs.python.org/dev/library/stdtypes.html#special-attributes> that also apply to functions, etc. I invented the pseudo class name ?definition? for this; better suggestions are welcome!

Then I converted the user-defined functions reference, as well as many other references, to :attr:`~definition.__name__` or similar, for these three attributes:

* definition.__name__
* definition.__qualname__
* object.__dict__

I also moved the index markup so that the index entries for the table of function attributes work.

----------
keywords: +patch
nosy: +vadmium
stage:  -> patch review
Added file: http://bugs.python.org/file39542/special-attr.patch

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

From report at bugs.python.org  Fri May 29 06:19:24 2015
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 29 May 2015 04:19:24 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1432873164.67.0.035883294847.issue23659@psf.upfronthosting.co.za>


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


----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 29 12:44:17 2015
From: report at bugs.python.org (eimista)
Date: Fri, 29 May 2015 10:44:17 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
Message-ID: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>


New submission from eimista:

In section (https://docs.python.org/3.5/library/stdtypes.html#mutable-sequence-types) written "s.pop([i])". But this syntax doesn't work.
Maybe the correct notation will be "s.pop(i)"?

----------
assignee: docs at python
components: Documentation
messages: 244365
nosy: docs at python, eimista
priority: normal
severity: normal
status: open
title: Typo in Mutable Sequence Types documentation.
type: resource usage
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 29 13:56:33 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 May 2015 11:56:33 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1432900593.62.0.00634651308602.issue24323@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It's trying to say that "i" is optional, as stated in the footnote. I agree it would be better written as "s.pop(i)", since square brackets are otherwise used in that section as indexing operators. But the footnote should stay, explaining what happens if you omit the parameter.

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

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

From report at bugs.python.org  Fri May 29 13:57:46 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 May 2015 11:57:46 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1432900666.49.0.151164886266.issue24323@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
versions:  -Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri May 29 15:43:03 2015
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 29 May 2015 13:43:03 +0000
Subject: [docs] [issue23659] csv.register_dialect  doc string
In-Reply-To: <1426260684.99.0.506625154497.issue23659@psf.upfronthosting.co.za>
Message-ID: <1432906983.08.0.420323785404.issue23659@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

LGTM.

----------

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

From report at bugs.python.org  Fri May 29 16:06:05 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 29 May 2015 14:06:05 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1432908365.35.0.867794074423.issue24323@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I think it should be changed to `pop(i=-1)`.

----------
nosy: +yselivanov

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

From report at bugs.python.org  Fri May 29 16:42:23 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 29 May 2015 14:42:23 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1432910543.0.0.457400123887.issue24323@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

s.pop(i=-1) doesn't actually work, but I guess it gets the point across.

For 2.7 it's even more confusing, since it includes:
s.index(x[, i[, j]])
and
s.sort([cmp[, key[, reverse]]])

I'd suggest not changing the 2.7 docs.

----------

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

From report at bugs.python.org  Fri May 29 21:28:39 2015
From: report at bugs.python.org (Brandon Milam)
Date: Fri, 29 May 2015 19:28:39 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1432927719.61.0.46654954205.issue24147@psf.upfronthosting.co.za>


Brandon Milam added the comment:

Here I added on to the Dialects and Formatting Parameters paragraph explaining that the defaults listed are for the excel dialect and that all the attributes need to be specified if the user is wanting to create custom dialects through sub-classing. I will also include the html file this produces for those who do not want to look at the .rst file.

Also I can go in and change the defaults of the Dialect class on the parameters that expect Boolean values if desired but I would open a separate issue for it. 

Let me know if there are any errors or desired changes in document change.

----------
keywords: +patch
Added file: http://bugs.python.org/file39552/csv_dialect_doc_clarify.patch

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

From report at bugs.python.org  Fri May 29 21:29:24 2015
From: report at bugs.python.org (Brandon Milam)
Date: Fri, 29 May 2015 19:29:24 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1432927764.8.0.963213808506.issue24147@psf.upfronthosting.co.za>


Changes by Brandon Milam <jmilam343 at gmail.com>:


Added file: http://bugs.python.org/file39553/csv.html

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

From report at bugs.python.org  Fri May 29 22:03:06 2015
From: report at bugs.python.org (Mik)
Date: Fri, 29 May 2015 20:03:06 +0000
Subject: [docs] [issue24147] Dialect class defaults are not documented.
In-Reply-To: <1431133519.25.0.806037285537.issue24147@psf.upfronthosting.co.za>
Message-ID: <1432929786.9.0.256611544319.issue24147@psf.upfronthosting.co.za>


Mik added the comment:

I think it's clearer that way. Thank you.

----------

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

From report at bugs.python.org  Fri May 29 22:31:04 2015
From: report at bugs.python.org (Brandon Milam)
Date: Fri, 29 May 2015 20:31:04 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
	not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1432931464.48.0.543936459014.issue21297@psf.upfronthosting.co.za>


Brandon Milam added the comment:

This code shows what Daniel Andersson was talking about. I changed the "whitespace" references in the documentation that Daniel mentioned to say spaces. Also I changed "ignore space at the start of the field" to "ignore spaces at the start of the field" due to Terry's confusion.

Let me know of any errors or extra changes that are needed.

----------
nosy: +jbmilam
Added file: http://bugs.python.org/file39558/csv_skipinitialspace_testing.py

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

From report at bugs.python.org  Fri May 29 22:31:58 2015
From: report at bugs.python.org (Brandon Milam)
Date: Fri, 29 May 2015 20:31:58 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
	not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1432931518.13.0.963827639955.issue21297@psf.upfronthosting.co.za>


Changes by Brandon Milam <jmilam343 at gmail.com>:


Added file: http://bugs.python.org/file39559/csv_skipinitialspace_testing.csv

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

From report at bugs.python.org  Fri May 29 22:32:18 2015
From: report at bugs.python.org (Brandon Milam)
Date: Fri, 29 May 2015 20:32:18 +0000
Subject: [docs] [issue21297] csv.skipinitialspace only skips spaces,
	not "whitespace" in general
In-Reply-To: <1397821941.61.0.706896478348.issue21297@psf.upfronthosting.co.za>
Message-ID: <1432931538.87.0.297069663885.issue21297@psf.upfronthosting.co.za>


Changes by Brandon Milam <jmilam343 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file39560/csv_skipinitialspace_docfix.patch

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

From report at bugs.python.org  Fri May 29 23:01:57 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 29 May 2015 21:01:57 +0000
Subject: [docs] [issue24136] document PEP 448
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1432933317.69.0.192662176672.issue24136@psf.upfronthosting.co.za>


Neil Girdhar added the comment:

Simplified functools.partial documentation.

----------
Added file: http://bugs.python.org/file39561/wn2.diff

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

From report at bugs.python.org  Fri May 29 23:04:11 2015
From: report at bugs.python.org (Neil Girdhar)
Date: Fri, 29 May 2015 21:04:11 +0000
Subject: [docs] [issue24136] document PEP 448
In-Reply-To: <1430918327.69.0.579699866453.issue24136@psf.upfronthosting.co.za>
Message-ID: <1432933451.68.0.311375580614.issue24136@psf.upfronthosting.co.za>


Changes by Neil Girdhar <mistersheik at gmail.com>:


Added file: http://bugs.python.org/file39562/wn2.diff

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

From report at bugs.python.org  Sat May 30 03:34:14 2015
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 May 2015 01:34:14 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1432949653.98.0.62788109443.issue24079@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch with my suggestion. Let me know what you think.

----------
components: +XML
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file39565/etree-text.patch

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

From scoder at users.sourceforge.net  Sat May 30 07:35:22 2015
From: scoder at users.sourceforge.net (scoder at users.sourceforge.net)
Date: Sat, 30 May 2015 05:35:22 -0000
Subject: [docs] xml.etree.ElementTree.Element.text does not conform to the
 documentation (issue 24079)
Message-ID: <20150530053522.32006.78885@psf.upfronthosting.co.za>


https://bugs.python.org/review/24079/diff/14986/Doc/library/xml.etree.elementtree.rst
File Doc/library/xml.etree.elementtree.rst (right):

https://bugs.python.org/review/24079/diff/14986/Doc/library/xml.etree.elementtree.rst#newcode657
Doc/library/xml.etree.elementtree.rst:657: and the next tag.  The *tail*
attribute holds any text between the
Not strictly true, e.g. "<tag />abc<next-tag/>" - is "abc" in text or
tail here? Or in both?
Also, I think the usual wording is "opening" and "closing" tag.

https://bugs.python.org/review/24079/diff/14986/Doc/library/xml.etree.elementtree.rst#newcode659
Doc/library/xml.etree.elementtree.rst:659: ``None`` if there is no text.
 For example, in the XML data
Only by the parser. Application code may do with it what it likes.

https://bugs.python.org/review/24079/

From report at bugs.python.org  Sat May 30 07:35:57 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 30 May 2015 05:35:57 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1432964157.76.0.0632449601634.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

IMHO less clear and less correct than the previous suggestions.

----------

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

From report at bugs.python.org  Sat May 30 07:40:18 2015
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 30 May 2015 05:40:18 +0000
Subject: [docs] [issue24079] xml.etree.ElementTree.Element.text does not
	conform to	the documentation
In-Reply-To: <1430350495.43.0.91352789573.issue24079@psf.upfronthosting.co.za>
Message-ID: <1432964418.53.0.390852953196.issue24079@psf.upfronthosting.co.za>


Stefan Behnel added the comment:

Seems like a good idea to explain "text" and "tail" in one section, though. That makes "tail" easier to find for those who are not used to this kind of split (and that's basically everyone who needs to read the docs in the first place).

----------

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

From report at bugs.python.org  Sat May 30 19:55:02 2015
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 May 2015 17:55:02 +0000
Subject: [docs] [issue22357] inspect module documentation makes no reference
	to	__qualname__ attribute
In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>
Message-ID: <20150530175459.24091.38229@psf.io>


Roundup Robot added the comment:

New changeset 943fa0e8b6a4 by Yury Selivanov in branch '3.4':
Issue 22357: Document __qualname__ in inspect.rst
https://hg.python.org/cpython/rev/943fa0e8b6a4

New changeset 1d9131bc0ea4 by Yury Selivanov in branch '3.5':
Issue 22357: Merge from 3.4
https://hg.python.org/cpython/rev/1d9131bc0ea4

New changeset 5621e9a21cc3 by Yury Selivanov in branch 'default':
Issue 22357: Merge from 3.5
https://hg.python.org/cpython/rev/5621e9a21cc3

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

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

From report at bugs.python.org  Sat May 30 19:55:15 2015
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 30 May 2015 17:55:15 +0000
Subject: [docs] [issue22357] inspect module documentation makes no reference
	to	__qualname__ attribute
In-Reply-To: <1410124992.98.0.0231359390306.issue22357@psf.upfronthosting.co.za>
Message-ID: <1433008515.39.0.894552227625.issue22357@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun May 31 12:45:47 2015
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 May 2015 10:45:47 +0000
Subject: [docs] [issue23684] urlparse() documentation does not account for
	default	scheme
In-Reply-To: <1426556382.03.0.776976224321.issue23684@psf.upfronthosting.co.za>
Message-ID: <1433069147.16.0.0822514900635.issue23684@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch changing the table entries to ?*scheme* argument?. Hopefully this is fairly obvious and doesn?t sound like it defaults to itself.

I also made the descriptions of ?scheme? and ?allow_fragments? more specific, and added some unit tests, because there didn?t seem to be any exercising them.

----------
components: +Tests
keywords: +patch
stage:  -> patch review
type:  -> behavior
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file39573/urlparse-scheme.patch

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

From report at bugs.python.org  Sun May 31 17:49:46 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2015 15:49:46 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1433087386.19.0.87466669056.issue24323@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/issue24323>
_______________________________________

From report at bugs.python.org  Sun May 31 18:49:53 2015
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 May 2015 16:49:53 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1433090993.3.0.243753836951.issue24323@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

There isn't much defense against an overly literal reading of the docs.  Both ``s.pop([i])`` and ``s.pop(i=-1)`` fail (the latter because pop doesn't take key word arguments and the docstring calls it "index".  Also, you would have to define *s* and *i*. 

FWIW, there is already a note to the effect, "The optional argument i defaults to -1, so that by default the last item is removed and returned."

The [optional_arg] notation is used in a number of places in the docs and docstrings.  It is also common with other languages as well and it is used in third-party Python references as well.  Eric's initial suggestion of ``s.pop(i)`` is simply wrong and would make the docs worse.

As a starting point, realize that the docs have worked well for a lot of people for a long time so there should be a reluctance to change them on a single misreading.

The tutorial also includes the same notation, (see https://docs.python.org/3/tutorial/datastructures.html#more-on-lists ) and as far as I can tell, this has never been an issue.

One other thought, the most common way to call pop() is without an argument (usually, if you use an argument, it is a performance bug).  We want to make sure the docs don't suggest otherwise.

Unless there is some strong objection, I recommend leaving the docs as-is.

----------

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

From report at bugs.python.org  Sun May 31 19:04:33 2015
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 31 May 2015 17:04:33 +0000
Subject: [docs] [issue24323] Typo in Mutable Sequence Types documentation.
In-Reply-To: <1432896257.15.0.948443934491.issue24323@psf.upfronthosting.co.za>
Message-ID: <1433091873.82.0.384025600568.issue24323@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I don't feel particularly strongly about it. It's mildly more confusing in the 3.x docs than 2.7 because it's the only use in that section of an optional argument.

I disagree that s.pop(i) is wrong, since it agrees with the "Results" column. But I agree it's not an improvement and we shouldn't encourage it.

----------

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