From report at bugs.python.org  Fri Aug  1 07:54:25 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Aug 2014 05:54:25 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1406872464.85.0.0492962386087.issue19023@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is the patch stripped of all the noise and the structure and union stuff, so you can see just the changes related to arrays and pointers. However I have not attempted to apply the patch, nor addressed Georg?s comment about the ?contents? attribute.

----------
nosy: +vadmium
Added file: http://bugs.python.org/file36188/arrays-pointers.patch

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

From report at bugs.python.org  Fri Aug  1 08:30:39 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Aug 2014 06:30:39 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1406874639.02.0.315455672393.issue22046@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Aug  1 11:38:37 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 01 Aug 2014 09:38:37 +0000
Subject: [docs] [issue19055] Regular expressions: * does not match as
	many	repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1406885916.97.0.871406170589.issue19055@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this issue can be closed. Behavior and documentation are correct and match one other. Nothing to do with it.

----------

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

From report at bugs.python.org  Fri Aug  1 15:06:05 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 01 Aug 2014 13:06:05 +0000
Subject: [docs] [issue20466] Example in Doc/extending/embedding.rst fails to
	compile	cleanly
In-Reply-To: <1391206449.61.0.838795178148.issue20466@psf.upfronthosting.co.za>
Message-ID: <1406898365.57.0.417096854069.issue20466@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for your efforts, Saimadhav.  The issue has been fixed in another way, though.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Make _Py_char2wchar() and _Py_wchar2char() public

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

From report at bugs.python.org  Sat Aug  2 00:46:00 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Aug 2014 22:46:00 +0000
Subject: [docs] [issue22088] base64 module still ignores non-alphabet
	characters
In-Reply-To: <1406414649.83.0.15731376973.issue22088@psf.upfronthosting.co.za>
Message-ID: <1406933160.1.0.186037727988.issue22088@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Update the doc. I believe Davis intentionally only applied the 3.2 patch, treating the change as a bit of an enhancement. Can you propose a new wording?

----------
components:  -Library (Lib)
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Aug  2 09:57:51 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Sat, 02 Aug 2014 07:57:51 +0000
Subject: [docs] [issue22122] turtle module examples should all begin "from
	turtle	import *"
Message-ID: <1406966271.25.0.28039955033.issue22122@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

The turtle module is aimed primarily at young beginners to Python. Making them type turtle.this and turtle.that all over the place is tedious and unhelpful.

At the start of the turtle docs there's a nice example that begins
from turtle import *
and the following code is all the better for it.

But none of the other examples do this. I realise that this would make the module's docs inconsistent, but given the target audience and given that we surely want to lower the barrier to entry, it would be a reasonable concession to make?

----------
assignee: docs at python
components: Documentation
messages: 224538
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: turtle module examples should all begin "from turtle import *"
type: enhancement
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug  2 13:19:44 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Aug 2014 11:19:44 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1406978384.42.0.66436631837.issue22112@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Here is a a patch which replaces loop.create_task(coro) with asyncio.async(coro), mention that asyncio.async() can be used to scheduler a coroutine, and make it clear that create_task() is only available in Python 3.4.2 and later.

Does it look better?

If it's possible, I would prefer to have exactly the same documentation in Python 3.4 and 3.5.

----------
keywords: +patch
Added file: http://bugs.python.org/file36203/doc_create_task.patch

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

From report at bugs.python.org  Sat Aug  2 13:22:26 2014
From: report at bugs.python.org (Alexander Grigorievskiy)
Date: Sat, 02 Aug 2014 11:22:26 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
In-Reply-To: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>
Message-ID: <1406978546.41.0.612222547245.issue20402@psf.upfronthosting.co.za>


Alexander Grigorievskiy added the comment:

I have added some clarification following Westley Mart?nez recommendation. I provided references to the list comprehensions and generator expressions. I tried to make the description short.

----------
keywords: +patch
nosy: +AlexGrig
Added file: http://bugs.python.org/file36204/issue20402.diff

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

From report at bugs.python.org  Sat Aug  2 14:12:41 2014
From: report at bugs.python.org (Tuikku Anttila)
Date: Sat, 02 Aug 2014 12:12:41 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1406981561.14.0.805767326679.issue22046@psf.upfronthosting.co.za>


Tuikku Anttila added the comment:

Added to the documentation of zipfile.ZipFile.read() that the method will throw a NotImplementedError when the compression scheme of the ZipFile is something else than ZIP_STORED, ZIP_DEFLATED, ZIP_BZIP2 or ZIP_LZMA.

----------
keywords: +patch
nosy: +Tuikku.Anttila
Added file: http://bugs.python.org/file36206/issue22046.patch

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

From lillz at icloud.com  Fri Aug  1 22:18:05 2014
From: lillz at icloud.com (Tom O'Brien)
Date: Fri, 01 Aug 2014 14:18:05 -0600
Subject: [docs] turtle speed does not work
Message-ID: <EDEFF80A-49EE-49DD-8FF4-8A4B5B46B367@icloud.com>

Hello

In Python 2, an animation in turtle could be turned off, slowed down, or sped up with turtle.speed(). In python 3.4, this isn't the case. The documentation claims turtle.speed should work, but it doesn't change the speed of the animation. It doesn't give an error, but no matter the integer set inside turtle.speed, the speed won't change. 

Sent from my iPhone

From lillz at icloud.com  Fri Aug  1 22:23:28 2014
From: lillz at icloud.com (Tom O'Brien)
Date: Fri, 01 Aug 2014 14:23:28 -0600
Subject: [docs] turtle speed does not work
In-Reply-To: <EDEFF80A-49EE-49DD-8FF4-8A4B5B46B367@icloud.com>
References: <EDEFF80A-49EE-49DD-8FF4-8A4B5B46B367@icloud.com>
Message-ID: <B1D5D68B-01F2-498B-8374-64CE59F5E202@icloud.com>

An example of this can be seen at tinyurl.com/mewv2ne
(Redirects to Stack Overflow)

Sent from my iPhone

> On Aug 1, 2014, at 14:18, Tom O'Brien <lillz at icloud.com> wrote:
> 
> Hello
> 
> In Python 2, an animation in turtle could be turned off, slowed down, or sped up with turtle.speed(). In python 3.4, this isn't the case. The documentation claims turtle.speed should work, but it doesn't change the speed of the animation. It doesn't give an error, but no matter the integer set inside turtle.speed, the speed won't change. 
> 
> Sent from my iPhone

From report at bugs.python.org  Sat Aug  2 18:54:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 02 Aug 2014 16:54:11 +0000
Subject: [docs] [issue22122] turtle module examples should all begin "from
	turtle	import *"
In-Reply-To: <1406966271.25.0.28039955033.issue22122@psf.upfronthosting.co.za>
Message-ID: <1406998451.86.0.153243073486.issue22122@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Aug  2 20:48:49 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Aug 2014 18:48:49 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406978384.42.0.66436631837.issue22112@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK4Nj0sFtg8sAcwgOzDJQ=kw38cuMc=NHfr0v747G1ERA@mail.gmail.com>


Guido van Rossum added the comment:

Looks good!

On Sat, Aug 2, 2014 at 4:19 AM, STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor added the comment:
>
> Here is a a patch which replaces loop.create_task(coro) with
> asyncio.async(coro), mention that asyncio.async() can be used to scheduler
> a coroutine, and make it clear that create_task() is only available in
> Python 3.4.2 and later.
>
> Does it look better?
>
> If it's possible, I would prefer to have exactly the same documentation in
> Python 3.4 and 3.5.
>
> ----------
> keywords: +patch
> Added file: http://bugs.python.org/file36203/doc_create_task.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22112>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Aug  2 23:24:18 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Aug 2014 21:24:18 +0000
Subject: [docs] [issue22122] turtle module examples should all begin "from
	turtle	import *"
In-Reply-To: <1406966271.25.0.28039955033.issue22122@psf.upfronthosting.co.za>
Message-ID: <1407014658.78.0.149149384652.issue22122@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think your suggestion is wrong as is and that this issue should be revised or closed.  The simple initial example is a complete program. PEP8 discourages 'import *' but it is acceptable in this context. The snippets you refer to follow

"24.1.3. Methods of RawTurtle/Turtle and corresponding functions

Most of the examples in this section refer to a Turtle instance called turtle."

Methods are always documented as method calls, and they should be here too. The function interface can only be used for 1 turtle, while drawings often require more than 1.  See turtledemo for examples such as 'forest', which uses 3 Turtle instances.

Nothing says that users have to name an instance 'turtle'.  In practice one might use 't1', 't2', etc, or other short names.  Within a subclass of Turtle, with added methods, the prefix would be 'self.'. The quote above could be, and perhaps should be augmented with a reminder that "If one uses the function interface for one turtle or the first of many turtles, 'turtle.' should be omitted."  As a further concession to beginners, this could even be follows by "If one uses the object interface, replace 'turtle' with the actual name of a particular turtle."

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

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

From report at bugs.python.org  Sun Aug  3 00:33:01 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Aug 2014 22:33:01 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
In-Reply-To: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>
Message-ID: <1407018781.63.0.246151626976.issue20402@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

We do have prominent entries in the glossary and tutorial:

https://docs.python.org/2.7/glossary.html#term-list-comprehension
https://docs.python.org/2.7/tutorial/datastructures.html#list-comprehensions

Moving it earlier in the tutorial is likely to do more harm than help.  In teaching Python, you need some gap between learning for-loops and learning list comprehensions (the former is a prerequisite for the latter).

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
versions:  -Python 3.3

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

From report at bugs.python.org  Sun Aug  3 02:20:26 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 Aug 2014 00:20:26 +0000
Subject: [docs] [issue18423] Document limitations on -m
In-Reply-To: <1373461112.24.0.280779659137.issue18423@psf.upfronthosting.co.za>
Message-ID: <1407025226.77.0.2732938272.issue18423@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Andrew could you put up a patch for this?

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

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

From report at bugs.python.org  Sun Aug  3 02:34:57 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 Aug 2014 00:34:57 +0000
Subject: [docs] [issue18697] Unify arguments names in Unicode object C
	API	documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1407026097.14.0.742659200624.issue18697@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

@Serhiy will you be proposing a patch for this?

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

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

From report at bugs.python.org  Sun Aug  3 08:18:28 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Aug 2014 06:18:28 +0000
Subject: [docs] [issue18697] Unify arguments names in Unicode object C
	API	documentation
In-Reply-To: <1407026097.14.0.742659200624.issue18697@psf.upfronthosting.co.za>
Message-ID: <1663401.1lpINmn1WR@raxxla>


Serhiy Storchaka added the comment:

> @Serhiy will you be proposing a patch for this?

No, I am not. I have no opinion what name is better.

----------

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

From report at bugs.python.org  Sun Aug  3 08:55:09 2014
From: report at bugs.python.org (Mark Summerfield)
Date: Sun, 03 Aug 2014 06:55:09 +0000
Subject: [docs] [issue22122] turtle module examples should all begin "from
	turtle	import *"
In-Reply-To: <1406966271.25.0.28039955033.issue22122@psf.upfronthosting.co.za>
Message-ID: <1407048909.91.0.287175914817.issue22122@psf.upfronthosting.co.za>


Mark Summerfield added the comment:

Ah, we're slightly at cross purposes. I showed them purely in terms of the procedural API. However, I can see now that I could have begun with:

import turtle
...
jane = turtle.Turtle()
jane.fd(100)

So, to "teach" their turtle how to go in a square, I guess they'd do:

def square(who, size=100):
    for n in range(4):
        who.fd(100)
        who.rt(90)

square(jane)

That seems reasonable, but then why isn't the first (and only complete) example done in this OO-ish style?

Anyway, I've marked this closed and will switch to this approach in future.

Thanks.

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

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

From report at bugs.python.org  Sun Aug  3 09:22:24 2014
From: report at bugs.python.org (Wouter van Heyst)
Date: Sun, 03 Aug 2014 07:22:24 +0000
Subject: [docs] [issue18034] Last two entries in the programming FAQ are out
	of date	(import related)
In-Reply-To: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za>
Message-ID: <1407050544.46.0.150494491771.issue18034@psf.upfronthosting.co.za>


Wouter van Heyst added the comment:

The attached patch changes the body of the __import__ faq entry to suggest using `importlib.import_module` instead.

----------
keywords: +patch
nosy: +larstiq
Added file: http://bugs.python.org/file36227/faq-import_module.diff

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

From report at bugs.python.org  Sun Aug  3 15:17:19 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Sun, 03 Aug 2014 13:17:19 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
Message-ID: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>


New submission from Frank van Dijk:

stackoverflow.com has a zillion answers recommending the use of codecs.open() as a unicode capable drop in replacement for open(). This probably means that there is still a lot of code being written that uses codecs.open(). That's bad thing because of codecs.open()'s lack of newline conversion. A lot of that code will 
- have compatibility issues when it is moved between unix and windows
- silently break text files on windows, leading to issues further downstream (confusing other tools, messing up revision control histories)

The problem has been fixed with io.open() in 2.x and open() in 3.x. Unfortunately the 2.7 unicode HOWTO still recommends the use of codecs.open(). The 2.7 and the 3.x documentation of codecs.open() doesn't refer the reader to better alternatives.

The attached patches fix that.

The only downside I see is that newly written code that uses the better alternatives would be incompatible with 2.5 and older. However croaking on a small minority of systems is better than silently disrupting workflows, causing platform incompatibilities, and inviting flaky workarounds.

The 2.7 patch makes the unicode HOWTO recommend io.open() instead of codecs.open(). Both patches change the codecs.open() documentation to refer to io.open() or (on 3.x) open().

Additionally I removed the "data loss" explanation from codecs.open()'s note about its lack of newline conversion. It is not particularly helpful information and it is not entirely correct (data loss could also have been avoided by doing newline conversion before encoding and after decoding)

----------
assignee: docs at python
components: Documentation
files: codecsopen2.patch
keywords: patch
messages: 224632
nosy: Frank.van.Dijk, docs at python
priority: normal
severity: normal
status: open
title: patch: steer people away from codecs.open
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36234/codecsopen2.patch

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

From report at bugs.python.org  Sun Aug  3 15:17:58 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Sun, 03 Aug 2014 13:17:58 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407071878.91.0.784578792358.issue22128@psf.upfronthosting.co.za>


Changes by Frank van Dijk <fwvdijk at gmail.com>:


Added file: http://bugs.python.org/file36235/codecsopen3.patch

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

From report at bugs.python.org  Sun Aug  3 15:20:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Aug 2014 13:20:16 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407072016.44.0.291385355074.issue22128@psf.upfronthosting.co.za>


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


----------
nosy: +doerwalter, haypo, lemburg

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

From report at bugs.python.org  Sun Aug  3 15:23:49 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 Aug 2014 13:23:49 +0000
Subject: [docs] [issue15428] add "Name Collision" section to argparse docs
In-Reply-To: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>
Message-ID: <1407072229.13.0.758749158419.issue15428@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug  3 15:26:20 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 03 Aug 2014 13:26:20 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1407072380.83.0.721734351862.issue20135@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Here is a new patch that includes an additional paragraph about mutation and non-mutation operations.

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

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

From report at bugs.python.org  Sun Aug  3 18:31:43 2014
From: report at bugs.python.org (Francis MB)
Date: Sun, 03 Aug 2014 16:31:43 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1407083503.64.0.87693611118.issue20135@psf.upfronthosting.co.za>


Francis MB added the comment:

A) On the example:

+Also note that some operations (e.g. ``y.append(10)``/``y += [10]`` or
+``y.sort()``) mutate

are you saying:
1) "y.append(10)" divided by "y += [10]" or
2) "y.append(10)" and "y += [10]"

I don't want to split hairs but reading it fast confused me a bit


B) The paragraph:

+  etc.), we can use some specific operations to mutate it and all the variables
+  that refer to it will see
+  the change;

Couldn't be (one newline less):

+  etc.), we can use some specific operations to mutate it and all the variables
+  that refer to it will see the change;

----------
nosy: +francismb

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

From report at bugs.python.org  Sun Aug  3 20:38:11 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 03 Aug 2014 18:38:11 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1407091091.53.0.293838442095.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

@paul.j3, It wasn't from a different project, it's just that the bug tracker when it does a diff always uses the tip of each branch instead of the most recent common ancestor, so it effectively calculated the the diff of the changes plus the inverse of every change since the effort initiated. But yes, it makes sense to remove it.

----------

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

From report at bugs.python.org  Sun Aug  3 20:38:31 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 03 Aug 2014 18:38:31 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1407091111.6.0.454589844612.issue13540@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


Removed file: http://bugs.python.org/file36001/9ac347a7f375.diff

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

From report at bugs.python.org  Sun Aug  3 21:30:55 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Aug 2014 19:30:55 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <3hRC4t2LDmz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 956c6d33a57d by Jason R. Coombs in branch '2.7':
Issue #13540: Expanded argparse documents to clarify the action API
http://hg.python.org/cpython/rev/956c6d33a57d

New changeset 008a5473f300 by Jason R. Coombs in branch '2.7':
Issue #13540: Removed redundant documentation about Action instance attributes. Updated example and documentation per recommendations by Steven Bethard in msg149524.
http://hg.python.org/cpython/rev/008a5473f300

New changeset 7a627bc9d40e by Jason R. Coombs in branch '2.7':
Issue #13540: Update references to Action class to match syntax used for other classes in this file.
http://hg.python.org/cpython/rev/7a627bc9d40e

New changeset b232e937e668 by Jason R. Coombs in branch '2.7':
Issue #13540: Merge commits
http://hg.python.org/cpython/rev/b232e937e668

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

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

From report at bugs.python.org  Sun Aug  3 21:31:48 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 03 Aug 2014 19:31:48 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <3hRC5v2j2nz7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset e2c9e0a3ef02 by Jason R. Coombs in branch '3.2':
Issue #13540: Expanded argparse documents to clarify the action API
http://hg.python.org/cpython/rev/e2c9e0a3ef02

New changeset c10a6ca9cb32 by Jason R. Coombs in branch '3.2':
Issue #13540: Removed redundant documentation about Action instance attributes. Updated example and documentation per recommendations by Steven Bethard in msg149524.
http://hg.python.org/cpython/rev/c10a6ca9cb32

New changeset 634f3fe8cbde by Jason R. Coombs in branch '3.2':
Issue #13540: Update references to Action class to match syntax used for other classes in this file.
http://hg.python.org/cpython/rev/634f3fe8cbde

New changeset a36d469f31c1 by Jason R. Coombs in branch '3.3':
Issue #13540: Merge changes from 3.2
http://hg.python.org/cpython/rev/a36d469f31c1

New changeset c689156580ca by Jason R. Coombs in branch '3.4':
Issue #13540: Merge changes from 3.3
http://hg.python.org/cpython/rev/c689156580ca

New changeset a2d01ed713cb by Jason R. Coombs in branch 'default':
Issue #13540: Merge changes from 3.4
http://hg.python.org/cpython/rev/a2d01ed713cb

----------

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

From report at bugs.python.org  Sun Aug  3 21:34:23 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 03 Aug 2014 19:34:23 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1407094462.93.0.503743724476.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Commits applied to Python 2.7 and 3.2-3.5.

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

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

From report at bugs.python.org  Sun Aug  3 22:35:52 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 03 Aug 2014 20:35:52 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407072016.44.0.291385355074.issue22128@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwadZbwCyY0kZ9JVH+9xMG0rBT4wneDVe6i8fDpk=ga7=w@mail.gmail.com>


STINNER Victor added the comment:

See also my PEP 400:
http://legacy.python.org/dev/peps/pep-0400/

----------

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

From report at bugs.python.org  Sun Aug  3 22:45:50 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 03 Aug 2014 20:45:50 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407098750.65.0.384582388806.issue22128@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Pointing people to io.open() as alternative to codecs.open() is a good idea, but that doesn't make codecs.open() less useful.

The reason why codecs.open() uses binary mode is to avoid issues with automatic newline conversion getting in the way of the file's encoding. Think of e.g. UTF-16 encoded files that use newlines.

Note that codecs allow handling newlines on a line-by-line bases via the .readline() keepends parameter, so issues with Windows vs. Unix can be worked around explicitly. Since default is to keep line ends, no data loss occurs and application code can deal with line ends as it sees fit.

As it stands, I'm -1 on this patch, but would be +1 on mentioning io.open() as alternative to codecs.open() with a slightly different approach to line ends.

I don't think it's useful to tell people:
* use codecs.open() on Python 2.4, 2.5, 2.6
* use io.open() on Python 2.7 (io is too slow on 2.6 to be a real alternative to codecs.open())
* use open() on Python 3.4+

codecs.open() works the same across all these Python versions.

----------

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

From report at bugs.python.org  Sun Aug  3 22:58:23 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 03 Aug 2014 20:58:23 +0000
Subject: [docs] [issue18841] math.isfinite fails with Decimal sNAN
In-Reply-To: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>
Message-ID: <1407099502.93.0.0612488326248.issue18841@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Steven, can you propose a patch for this?

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

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

From report at bugs.python.org  Mon Aug  4 05:57:44 2014
From: report at bugs.python.org (Rob Lanphier)
Date: Mon, 04 Aug 2014 03:57:44 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
In-Reply-To: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>
Message-ID: <1407124664.55.0.95560924828.issue20402@psf.upfronthosting.co.za>


Rob Lanphier added the comment:

> Moving it earlier in the tutorial is likely to do more harm than help.
> In teaching Python, you need some gap between learning for-loops and 
> learning list comprehensions (the former is a prerequisite for the
> latter).

The problem here is that many people get list comprehensions foisted on them by reading code that has them in it.  Since list comprehensions aren't called "list comprehensions" in the code, but rather, they look like funny for loops, many people will turn to the for loop documentation, and as of this writing, they won't find anything.

There doesn't necessarily need to be the full example as in Alex's patch (though Alex's version seems fine to me), I think there should at least be some link to the list comprehension documentation, e.g. "It is also possible to prepend a function onto a 'for' loop.  This is a :ref:`list comprehensions <tut-listcomps>`, and is explained further in the next chapter."

----------

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

From report at bugs.python.org  Mon Aug  4 07:17:38 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Aug 2014 05:17:38 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
In-Reply-To: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>
Message-ID: <1407129458.5.0.685646707459.issue20402@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry, I'm going to close this one because I believe it would make the documentation worse.

I don't believe that making a forward reference from section 4.2 to section 5.6 helps anyone.

----------
resolution:  -> rejected
status: open -> closed

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

From raashidbhatt at gmail.com  Sat Aug  2 17:27:06 2014
From: raashidbhatt at gmail.com (rashid bhat)
Date: Sat, 2 Aug 2014 20:57:06 +0530
Subject: [docs] [BUG] In python Array module
Message-ID: <CALuuq0FsK=pOUA7V+7LONBVCjeoKK_MOxT1BwkyGuq603GwwEA@mail.gmail.com>

Hello

The array object on assignment does not  create a new object instead it
creates a reference to the assigned object  ( As expected it should create
a new object). Following code would be enough to prove it

*import array*

*foo = array.array("c", "hello")*
bar = foo

bar[0]  = "\x00"

print foo[0] gives "\x00" output while it should be hello


-- 
Regards
Raashid Bhat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140802/81401f8c/attachment.html>

From philippe.moreau at outlook.com  Sat Aug  2 23:47:50 2014
From: philippe.moreau at outlook.com (Philippe Moreau)
Date: Sat, 2 Aug 2014 23:47:50 +0200
Subject: [docs] float display in python 3.4
Message-ID: <DUB121-W347EB67BFE21DEE4222AB5E2E40@phx.gbl>

Hi,
I don't know if this is the good place for this metaphysic question...But, I read python docs in each version, but can't find the real answer. 2 days I'm on it :(
Here is the question:
In python docs 3.4 it is written:
"Historically, the Python prompt and built-in repr() function would choose
the one with 17 significant digits, 0.10000000000000001.   Starting with
Python 3.1, Python (on most systems) is now able to choose the shortest of
these and simply display 0.1."
The question is HOW python choose it?
Here are examples I put in the shell:
>>>0.1
Out[1]: 0.1

>>>0.2
Out[2]: 0.2

>>>0.3
Out[3]: 0.3

No problem here...
Now:
>>>0.1+0.2
Out[4]: 0.30000000000000004

The problem is NOT the number 4 that appears at the end. I know it deals with IEEE754 representation and that python displays the 17 first digits as tells in the doc.
The problem is why it appears and why not for 0.2....
Let's see why it is a problem for me:
>>>Decimal(0.1)
Out[10]: Decimal('0.1000000000000000055511151231257827021181583404541015625')

>>>Decimal(0.2)
Out[11]: Decimal('0.200000000000000011102230246251565404236316680908203125')

>>>Decimal(0.1+0.2)
Out[12]: Decimal('0.3000000000000000444089209850062616169452667236328125')

>>>Decimal(0.3)
Out[13]: Decimal('0.299999999999999988897769753748434595763683319091796875')

SO:
the first 17 digits for 0.1 python's display are:
0.10000000000000000
so ok for 0.1 as display

the first 17 digits for 0.1+0.2 python's display are:
0.30000000000000004
so, ok for the display.

BUT:
the first 17 digits for 0.2 python's display are:
0.20000000000000001
so, why just only 0.2 displayed?

and the same for the 17 first digits for 0.3:
0.29999999999999998
so, why python only displayed 0.3?

How python choose the correct display please?

Thank you so much!!!!!!!!!!

Philippe MOREAU
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140802/8d5fb18e/attachment.html>

From drekin at gmail.com  Mon Aug  4 12:09:09 2014
From: drekin at gmail.com (drekin)
Date: Mon, 4 Aug 2014 12:09:09 +0200
Subject: [docs] Could the difference between a function and a macro be
 stressed in Python C API documentation?
Message-ID: <CACvLUanaas638JFZN_imnV=CpaEMhC9j5vTq3-XarY9bGDs_hQ@mail.gmail.com>

Could the difference between a function and a macro be stressed in Python C
API documentation? I wanted to call PyObject_CheckBuffer via ctypes, but
ctypes.pythonapi.PyObject_CheckBuffer raised AttributeError. It took me
some time to find out that it's because PyObject_CheckBuffer is a macro.

Regards, Drekin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140804/f47db1e4/attachment.html>

From report at bugs.python.org  Mon Aug  4 16:02:10 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Aug 2014 14:02:10 +0000
Subject: [docs] [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <3hRgl51mlNz7LmD@mail.python.org>


Roundup Robot added the comment:

New changeset c39457a07caa by Ezio Melotti in branch '3.4':
#18588: update the timeit examples to be consistent.
http://hg.python.org/cpython/rev/c39457a07caa

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

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

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

From report at bugs.python.org  Mon Aug  4 16:02:48 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Aug 2014 14:02:48 +0000
Subject: [docs] [issue18588] timeit examples should be consistent
In-Reply-To: <1375118438.6.0.867422483387.issue18588@psf.upfronthosting.co.za>
Message-ID: <1407160968.91.0.0767831766542.issue18588@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Examples updated, thanks for the report!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions:  -Python 2.7

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

From report at bugs.python.org  Mon Aug  4 16:06:02 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Aug 2014 14:06:02 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
In-Reply-To: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>
Message-ID: <1407161162.64.0.988807701465.issue20402@psf.upfronthosting.co.za>


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


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

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

From zachary.ware+pydocs at gmail.com  Mon Aug  4 16:37:53 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 4 Aug 2014 09:37:53 -0500
Subject: [docs] [BUG] In python Array module
In-Reply-To: <CALuuq0FsK=pOUA7V+7LONBVCjeoKK_MOxT1BwkyGuq603GwwEA@mail.gmail.com>
References: <CALuuq0FsK=pOUA7V+7LONBVCjeoKK_MOxT1BwkyGuq603GwwEA@mail.gmail.com>
Message-ID: <CAKJDb-MHqCKZHxB=NU2KW=LcdhdcCAVJKVQ8zaHGDz6NMvfoXg@mail.gmail.com>

Hi Raashid,

On Sat, Aug 2, 2014 at 10:27 AM, rashid bhat <raashidbhatt at gmail.com> wrote:
> Hello
>
> The array object on assignment does not  create a new object instead it
> creates a reference to the assigned object  ( As expected it should create a
> new object).

Why do you expect that?  If Python were to create a new object at
every assignment, it would very quickly use up huge amounts of memory
for no good reason, and nobody wants that!  Since there's no way to
tell which objects you might want a copy of and which ones you
definitely don't want copied, it takes more than just an assignment to
create a new object.  Assignment simply binds the name on the left to
the result of the expression on the right: in your example below, that
means assigning "bar" to the object bound to "foo".  Have a look at
http://nedbatchelder.com/text/names.html for a more in-depth
explanation.

The bottom line is, if you want a copy of an object, you'll have to
make it yourself, like so:

>>> import array
>>> foo = array.array('c', 'hello')
>>> bar = foo[:]    # this notation means "take a slice of the whole thing"
>>> bar[0] = '\x00'
>>> bar
array('c', '\x00ello')
>>> foo
array('c', 'hello')

Hope this helps,
--
Zach

> Following code would be enough to prove it
>
> import array
>
> foo = array.array("c", "hello")
> bar = foo
>
> bar[0]  = "\x00"
>
> print foo[0] gives "\x00" output while it should be hello
>
>
> --
> Regards
> Raashid Bhat

From report at bugs.python.org  Mon Aug  4 18:36:05 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 04 Aug 2014 16:36:05 +0000
Subject: [docs] [issue18034] Last two entries in the programming FAQ are out
	of date	(import related)
In-Reply-To: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za>
Message-ID: <3hRl8j0jKCz7Ln8@mail.python.org>


Roundup Robot added the comment:

New changeset 815f1a69283e by Ezio Melotti in branch '3.4':
#18034: update FAQ to suggest importlib.import_module instead of __import__.  Patch by Wouter van Heyst.
http://hg.python.org/cpython/rev/815f1a69283e

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

New changeset 46c7a724b487 by Ezio Melotti in branch '2.7':
#18034: update FAQ to suggest importlib.import_module instead of __import__.  Patch by Wouter van Heyst.
http://hg.python.org/cpython/rev/46c7a724b487

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

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

From report at bugs.python.org  Mon Aug  4 18:37:33 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Aug 2014 16:37:33 +0000
Subject: [docs] [issue18034] Last two entries in the programming FAQ are out
	of date	(import related)
In-Reply-To: <1369244115.61.0.298181094271.issue18034@psf.upfronthosting.co.za>
Message-ID: <1407170253.58.0.000981961462751.issue18034@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the patch!
The other FAQ got fixed in #17177/3d3b9d456eb8.

----------
assignee: docs at python -> ezio.melotti
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Mon Aug  4 23:51:01 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Mon, 04 Aug 2014 21:51:01 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407098750.65.0.384582388806.issue22128@psf.upfronthosting.co.za>
Message-ID: <7EBF8E66-CBBE-4237-AB4C-DC645EB4A0B8@gmail.com>


Frank van Dijk added the comment:

> Marc-Andre Lemburg added the comment:
> 
> Pointing people to io.open() as alternative to codecs.open() is a good idea, but that doesn't make codecs.open() less useful.
> 
> The reason why codecs.open() uses binary mode is to avoid issues with automatic newline conversion getting in the way of the file's encoding. Think of e.g. UTF-16 encoded files that use newlines.

disabling text mode on the underlying file handle to keep a UTF-16 code unit like 0x010a from getting mangled works, but no newline conversion is a high price to pay. Newline conversion should (conceptually) be done before encoding and after decoding. io.open() does it right.

> 
> Note that codecs allow handling newlines on a line-by-line bases via the .readline() keepends parameter, so issues with Windows vs. Unix can be worked around explicitly. Since default is to keep line ends, no data loss occurs and application code can deal with line ends as it sees fit.

Trouble is, your average python coder won't do exhaustive research on the pros and cons of the various options for I/O available and the pros and cons of dealing with platform differences at the application level. They'll just use the open() builtin, then realize they need utf-8 output or whatever, google "python write utf-8" or browse the unicode HOWTO, see a very familiar looking API and assume it'll behave just like open()

> 
> As it stands, I'm -1 on this patch, but would be +1 on mentioning io.open() as alternative to codecs.open() with a slightly different approach to line ends.

What would that mean concretely ? Undoing the change to the unicode HOWTO and instead adding a remark along the lines of "The codecs.open() function does not have the automatic newline conversion features that the builtin open() function provides to make reading and writing text files platform independent. If you need automatic newline conversion for the Unicode data you read and write, consider using io.open() instead." ?

I could live with that.

> 
> I don't think it's useful to tell people:
> * use codecs.open() on Python 2.4, 2.5, 2.6
> * use io.open() on Python 2.7 (io is too slow on 2.6 to be a real alternative to codecs.open())
> * use open() on Python 3.4+

The unicode HOWTO already recommends open() on all 3.x versions of the documentation at docs.python.org.

If you run 2.4 and 2.5 and you're adding new python software to your ancient system without upgrading python itself the only thing that could happen is that you'll get a clear-cut error if that new software imports io.

I can't judge how much of a problem slowness of the io module is in 2.6 or how much 'market share' 2.6 has left, but I'll note that correctness trumps performance. I'll also note that we're not changing any code here, nor will there be a rush of coders racing to get their existing apps and frameworks in line with the new decree.

All we're doing is giving average python programmers a better chance to discover what the drop in replacement for open() is or why that helpful tip found on the interwebs left them with a subtly mangled text file that looks really weird in notepad and makes git complain.

> 
> codecs.open() works the same across all these Python versions.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue22128>
> _______________________________________

----------

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

From report at bugs.python.org  Tue Aug  5 01:10:07 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Aug 2014 23:10:07 +0000
Subject: [docs] [issue19055] Regular expressions: * does not match as
	many	repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1407193807.54.0.518500999335.issue19055@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I agree.

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

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

From report at bugs.python.org  Tue Aug  5 01:30:23 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 04 Aug 2014 23:30:23 +0000
Subject: [docs] [issue18069] Subprocess picks the wrong executable on Windows
In-Reply-To: <1369595742.19.0.584828873115.issue18069@psf.upfronthosting.co.za>
Message-ID: <1407195023.1.0.0380771758191.issue18069@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch

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

From report at bugs.python.org  Tue Aug  5 07:02:49 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Aug 2014 05:02:49 +0000
Subject: [docs] [issue15759] "make suspicious" doesn't display instructions
	in case	of failure
In-Reply-To: <1345613663.78.0.519613331574.issue15759@psf.upfronthosting.co.za>
Message-ID: <1407214968.96.0.302307502765.issue15759@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Thanks for fixing this!

----------

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

From report at bugs.python.org  Tue Aug  5 07:15:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Aug 2014 05:15:44 +0000
Subject: [docs] [issue21928] Incorrect reference to partial() in
	functools.wraps	documentation
In-Reply-To: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>
Message-ID: <3hS41C70Y2z7Ljt@mail.python.org>


Roundup Robot added the comment:

New changeset 9e3c367b45a1 by Ezio Melotti in branch '3.4':
#21928: clarify functools.wraps docs.
http://hg.python.org/cpython/rev/9e3c367b45a1

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

New changeset 6cbd08fbdf77 by Ezio Melotti in branch '2.7':
#21928: clarify functools.wraps docs.
http://hg.python.org/cpython/rev/6cbd08fbdf77

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

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

From report at bugs.python.org  Tue Aug  5 07:16:30 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Aug 2014 05:16:30 +0000
Subject: [docs] [issue21928] Incorrect reference to partial() in
	functools.wraps	documentation
In-Reply-To: <1404691551.32.0.43724066382.issue21928@psf.upfronthosting.co.za>
Message-ID: <1407215790.14.0.903481997338.issue21928@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Aug  5 07:31:47 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Aug 2014 05:31:47 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1407216707.31.0.157307960444.issue21972@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Aug  5 07:32:19 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Aug 2014 05:32:19 +0000
Subject: [docs] [issue22000] cross type comparisons clarification
In-Reply-To: <1405622312.02.0.49093151571.issue22000@psf.upfronthosting.co.za>
Message-ID: <1407216739.08.0.818793700278.issue22000@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Tue Aug  5 07:35:55 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 05 Aug 2014 05:35:55 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1407216955.37.0.533193713996.issue22014@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> enhancement

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

From report at bugs.python.org  Tue Aug  5 17:39:28 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 15:39:28 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1407253168.31.0.247822961668.issue21972@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The ellipsis is also mentioned: "A sequence of three periods has a special meaning as an ellipsis literal."

----------

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

From report at bugs.python.org  Tue Aug  5 17:51:49 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 15:51:49 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1407253909.05.0.263264411575.issue21972@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The PEP 401 joke actually works:

>>> from __future__ import barry_as_FLUFL
>>> 3<>4
True

I'll add a smiley

----------

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

From report at bugs.python.org  Tue Aug  5 17:56:54 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 05 Aug 2014 15:56:54 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <3hSLF12nKkz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 57740d19f5c2 by Martin v. L?wis in branch 'default':
Issue #21972: Make it clear that the PEP 401 future import works,
http://hg.python.org/cpython/rev/57740d19f5c2

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

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

From report at bugs.python.org  Tue Aug  5 18:02:50 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 16:02:50 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1407254570.86.0.112515408548.issue21972@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I've moved the @ operator into #22142. With that, it seems to me that all aspects of this report are resolved.

Fran?ois-Ren?, for the future, please submit an individual bug report for each independent issue; this makes it easier tracking what has and hasn't been resolved.

----------

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

From report at bugs.python.org  Tue Aug  5 18:03:12 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 16:03:12 +0000
Subject: [docs] [issue21972] Bugs in the lexer and parser documentation
In-Reply-To: <1405223376.11.0.196375962969.issue21972@psf.upfronthosting.co.za>
Message-ID: <1407254592.34.0.901598771335.issue21972@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Tue Aug  5 18:35:23 2014
From: report at bugs.python.org (=?utf-8?q?Fran=C3=A7ois-Ren=C3=A9_Rideau?=)
Date: Tue, 05 Aug 2014 16:35:23 +0000
Subject: [docs] [issue22145] <> in parser spec but not lexer spec
Message-ID: <1407256523.86.0.758013450113.issue22145@psf.upfronthosting.co.za>


New submission from Fran?ois-Ren? Rideau:

As another follow up to http://bugs.python.org/issue21972

<> is mentioned in the parser spec: https://docs.python.org/3.5/reference/grammar.html
But not in the lexer spec: https://docs.python.org/3.5/reference/lexical_analysis.html

Either is a mistake.

I suggested in issue 21972 that the former was the bug, because it referred to a joke PEP and because <> doesn't actually work as a comparator in Python 3.4. The response by loewis was that the parser documentation was correct ? well then the lexer documentation is incorrect.

----------
assignee: docs at python
components: Documentation
messages: 224856
nosy: Fran?ois-Ren?.Rideau, docs at python, loewis
priority: normal
severity: normal
status: open
title: <> in parser spec but not lexer spec
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Aug  5 19:46:02 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Aug 2014 17:46:02 +0000
Subject: [docs] [issue22142] PEP 465 operators not described in
	lexical_analysis
In-Reply-To: <1407254480.75.0.52462093327.issue22142@psf.upfronthosting.co.za>
Message-ID: <1407260762.63.0.985073737886.issue22142@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


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

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

From report at bugs.python.org  Tue Aug  5 20:06:48 2014
From: report at bugs.python.org (Tuikku Anttila)
Date: Tue, 05 Aug 2014 18:06:48 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407262008.07.0.672592564947.issue22046@psf.upfronthosting.co.za>


Tuikku Anttila added the comment:

Added mention that an error might also be raised if the method is not available.

----------
Added file: http://bugs.python.org/file36270/22046_1.patch

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

From report at bugs.python.org  Tue Aug  5 21:41:09 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Tue, 05 Aug 2014 19:41:09 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407267670.0.0.445462374678.issue22128@psf.upfronthosting.co.za>


Changes by Frank van Dijk <fwvdijk at gmail.com>:


Added file: http://bugs.python.org/file36273/codecsopen2a.patch

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

From report at bugs.python.org  Tue Aug  5 21:42:01 2014
From: report at bugs.python.org (Frank van Dijk)
Date: Tue, 05 Aug 2014 19:42:01 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407267721.84.0.578377194164.issue22128@psf.upfronthosting.co.za>


Changes by Frank van Dijk <fwvdijk at gmail.com>:


Added file: http://bugs.python.org/file36274/codecsopen3a.patch

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

From report at bugs.python.org  Tue Aug  5 22:23:41 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 05 Aug 2014 20:23:41 +0000
Subject: [docs] [issue13553] Tkinter Tk args and Gnome Shell application name
In-Reply-To: <1323306729.26.0.368335158355.issue13553@psf.upfronthosting.co.za>
Message-ID: <1407270220.98.0.255619819468.issue13553@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The resolution of this issue should be to properly document the Tk class. The 3.4 docs currently say:

"class tkinter.Tk(screenName=None, baseName=None, className='Tk', useTk=1)
    The Tk class is instantiated without arguments. This creates a toplevel widget of Tk which usually is the main window of an application. Each instance has its own associated Tcl interpreter."

The signature is incomplete -- see below. The first sentence is wrong; there are arguments, they just all happen to have defaults. The next sentence should be something like "Return a toplevel Tk widget, which is usually the main window of an application."

Tk.__doc__ is 'Toplevel widget of Tk which represents mostly the main window\n    of an application. It has an associated Tcl interpreter.'  This is probably ok.

Tk.__init__ signature and Tk,__init__.__doc__ are

__init__(self, screenName=None, baseName=None, className='Tk', useTk=1, sync=0, use=None)

"Return a new Toplevel widget on screen SCREENNAME. A new Tcl interpreter will
be created. BASENAME will be used for the identification of the profile file (see
readprofile).
It is constructed from sys.argv[0] without extensions if None is given. CLASSNAME
is the name of the widget class."

"Toplevel" should be "toplevel" as in : Tk is not a subclass of Toplevel. Rather Toplevel is similar to Tk but with the BaseWidget signature.

The argument list needs to be completed and perhaps a bit more said about the one documented. Does 'screen' apply to anything other than X11? Could it be used on Windows to put the window on a secondary screen? Is Gnome the only user framework that uses classname?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, serhiy.storchaka, terry.reedy
stage:  -> needs patch
title: Tkinter doesn't set proper application name in Gnome Shell -> Tkinter Tk args and Gnome Shell application name
versions: +Python 3.4, Python 3.5 -Python 3.2

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

From report at bugs.python.org  Tue Aug  5 22:34:23 2014
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Aug 2014 20:34:23 +0000
Subject: [docs] [issue22145] <> in parser spec but not lexer spec
In-Reply-To: <1407256523.86.0.758013450113.issue22145@psf.upfronthosting.co.za>
Message-ID: <1407270863.2.0.17480127177.issue22145@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Neither nor. <> is a conditional token, conditional on the prior future import. This is the nature of PEP 236: some syntax might be part of the language in one module, but not in another, in the same version of the language.

In general, the documentation should refer to future syntax as such (i.e. mention that it is available only if a future import was made). Not so in this case: this specific feature is deliberately undocumented (or: under-documented, given that nothing is truly undocumented in free software). It's an easter egg - you found it.

----------

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

From report at bugs.python.org  Wed Aug  6 04:43:37 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Aug 2014 02:43:37 +0000
Subject: [docs] [issue22128] patch: steer people away from codecs.open
In-Reply-To: <1407071838.74.0.684483503953.issue22128@psf.upfronthosting.co.za>
Message-ID: <1407293017.78.0.666790547595.issue22128@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I don't think it's useful to tell people:
> * use codecs.open() on Python 2.4, 2.5, 2.6
> * use io.open() on Python 2.7 (io is too slow on 2.6 to be a real alternative to codecs.open())
> * use open() on Python 3.4+

Instead we can tell them to use io.open() on all versions from 2.7 and upwards.
2.6 is dead and won't receive any documentation updates anyway.

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Aug  6 05:11:46 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Aug 2014 03:11:46 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407294706.09.0.231245246277.issue22046@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

After further investigation it seems to me that read can't raise NotImplementedError.  ZipFile also won't raise it, but will raise a RuntimeError:
>>> zipfile.ZipFile('spam.zip', 'w', compression=zipfile.ZIP_BZIP2)
RuntimeError: Compression requires the (missing) bz2 module

By looking at the code, ZipFile calls _check_compression (Lib/zipfile.py:904) and _check_compression raises RuntimeError (Lib/zipfile.py:579).
ZipExtFile calls _get_decompressor (Lib/zipfile.py:651) and _get_decompressor raises NotImplemented (Lib/zipfile.py:610).
This behavior seems inconsistent and perhaps should be fixed (in this case a new issue should be created), however this will probably be backward-incompatible.

Regardless of this, it seems that currently NotImplementedError can be raised in some situations, and the zipfile docs don't mention it, so the doc can still be improved.

@Martin
Do you have any opinion on the aforementioned inconsistency?

@Jason
Did you actually manage to get a NotImplementedError from ZipFile.read() or from somewhere else?

----------
assignee: docs at python -> ezio.melotti
nosy: +ezio.melotti, loewis, serhiy.storchaka

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

From report at bugs.python.org  Wed Aug  6 05:14:18 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 03:14:18 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407294858.18.0.658787881014.issue22046@psf.upfronthosting.co.za>


Jason Heeris added the comment:

@Ezio

I am pretty sure it was read(). I couldn't submit the file I used as an example, so I'll see if I can construct a minimal example to post here.

----------

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

From report at bugs.python.org  Wed Aug  6 05:25:18 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 06 Aug 2014 03:25:18 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407295518.04.0.814106338096.issue22046@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

FWIW #5701 has a test zipfile (I haven't tried it though).

If I'm reading the code right, the compression method is specified and checked in the __init__, so we should know if the compression method was available long before we reach .read().  I will be happy to see some tests that prove me wrong (or confirm what I said), so that we know how the documentation should be updated.

----------

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

From report at bugs.python.org  Wed Aug  6 05:40:17 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 03:40:17 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407296417.05.0.291443251868.issue22046@psf.upfronthosting.co.za>


Changes by Jason Heeris <jason.heeris at gmail.com>:


Added file: http://bugs.python.org/file36279/Scheme.zip

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

From report at bugs.python.org  Wed Aug  6 05:40:41 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 03:40:41 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407296441.1.0.571645728749.issue22046@psf.upfronthosting.co.za>


Changes by Jason Heeris <jason.heeris at gmail.com>:


Added file: http://bugs.python.org/file36280/zftest.py

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

From report at bugs.python.org  Wed Aug  6 05:41:26 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 03:41:26 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407296486.94.0.818180252189.issue22046@psf.upfronthosting.co.za>


Jason Heeris added the comment:

Okay, I've attached two files:

1. Scheme.zip, from issue 5701
2. "zftest.py", a script that you run in the same dir as "Scheme.zip" to produce this:

$ python zftest.py 
Extracting: 1!SCHEME.Z64
Traceback (most recent call last):
  File "zftest.py", line 8, in <module>
    child_data = parent.read(zinfo)
  File "/usr/lib/python2.7/zipfile.py", line 931, in read
    return self.open(name, "r", pwd).read()
  File "/usr/lib/python2.7/zipfile.py", line 1006, in open
    close_fileobj=should_close)
  File "/usr/lib/python2.7/zipfile.py", line 530, in __init__
    raise NotImplementedError("compression type %d (%s)" % (self._compress_type, descr))
NotImplementedError: compression type 6 (implode)

----------

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

From report at bugs.python.org  Wed Aug  6 05:42:14 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 03:42:14 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407296534.21.0.265521650758.issue22046@psf.upfronthosting.co.za>


Jason Heeris added the comment:

Sorry, that was run with Python 2.7.5+ on Ubuntu.

----------

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

From report at bugs.python.org  Wed Aug  6 07:00:02 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Aug 2014 05:00:02 +0000
Subject: [docs] [issue22153] There is no standard TestCase.runTest
	implementation
Message-ID: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>


New submission from Martin Panter:

The documentation for "unittest.TestCase" says "the standard implementation of the default 'methodName', runTest(), will run every method starting with 'test' as an individual test". However:

>>> from unittest import *
>>> class Test(TestCase):
...     def test_method(self): pass
... 
>>> t = Test()
>>> t.run()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/unittest/case.py", line 552, in run
    testMethod = getattr(self, self._testMethodName)
AttributeError: 'Test' object has no attribute 'runTest'

After further experimentation, I see that if my test method is called "runTest", it can be automatically discovered, but only if there are no other test- prefixed methods.

Perhaps you could drop the end of the second paragraph for TestCase, so that it just reads:

Each instance of TestCase will run a single base method: the method named "methodName".

I think the details about the test- prefix and counting results are covered elsewhere, and in most uses you wouldn't instantiate a TestCase yourself, so changing the method name is irrelevant.

Also, perhaps under "TestLoader.loadTestsFromTestCase" it should say:

If no methods with the usual name prefix are found, but the "runTest" method is implemented, there will be a single test case using that method.

----------
assignee: docs at python
components: Documentation
messages: 224907
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: There is no standard TestCase.runTest implementation
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug  6 08:53:23 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Aug 2014 06:53:23 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407308003.78.0.469112790598.issue22046@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

ZipFile's constructor and ZipFile.open() can raise NotImplementedError, RuntimeError, EOFError, IOError, OSError or its subclasses, or any exception raised from underlying file object, including TypeError and AttributeError. ZipExtFile.read() can raise zlib.error, lzma.LZMAError, EOFError, IOError, OSError, etc. Any method can raise unexpected exception when used in unusual circumstances (with threads, in signal handler, in destructor, at shutdown stage). I don't think we should document all these exception. Python documentation never document all possible exceptions raised by a method.

----------

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

From report at bugs.python.org  Wed Aug  6 09:01:31 2014
From: report at bugs.python.org (Jason Heeris)
Date: Wed, 06 Aug 2014 07:01:31 +0000
Subject: [docs] [issue22046] ZipFile.read() should mention that it might
	throw	NotImplementedError
In-Reply-To: <1406118023.79.0.0716895014277.issue22046@psf.upfronthosting.co.za>
Message-ID: <1407308491.55.0.1976200691.issue22046@psf.upfronthosting.co.za>


Jason Heeris added the comment:

> Python documentation never document all possible exceptions raised by a method.

No, but clearly *some* exceptions are documented, and presumably there's some reasoning behind which are and aren't.

In this case, the NotImplemented error is there by design. It's not an incidental effect of something else. It's part of the API, and it's used to indicate a common error condition: that the compression format is not supported.

----------

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

From report at bugs.python.org  Wed Aug  6 12:03:36 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Aug 2014 10:03:36 +0000
Subject: [docs] [issue22154] ZipFile.open context manager support
In-Reply-To: <1407311800.94.0.537081542584.issue22154@psf.upfronthosting.co.za>
Message-ID: <1407319416.47.0.1245459437.issue22154@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
priority: normal -> low
resolution: out of date -> 
stage: resolved -> needs patch
status: closed -> open
type: enhancement -> behavior

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

From report at bugs.python.org  Wed Aug  6 12:18:37 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Aug 2014 10:18:37 +0000
Subject: [docs] [issue22155] Out of date code example for tkinter's
	createfilehandle
Message-ID: <1407320317.87.0.0833040424562.issue22155@psf.upfronthosting.co.za>


New submission from Martin Panter:

The only documentation on ?createfilehandle? and friends that I can find looks like it needs updating:

https://docs.python.org/release/3.4.0/faq/gui.html#can-i-have-tk-events-handled-while-waiting-for-i-o

I have been using the equivalent of this instead, for both Python 2 and 3:

import tkinter
widget = tkinter.Tk()
widget.tk.createfilehandler(file, tkinter.READABLE | tkinter.WRITABLE, callback)
...
widget.tk.deletefilehandler(file)

However I have no idea if this is a supported, proper way, if one even still exists. The old way was removed by Issue 3638.

BTW, there is a link to release/3.4.1 documentation but that returned a 404 error for me, so I linked to the 3.4.0 doc instead.

----------
assignee: docs at python
components: Documentation, Tkinter
messages: 224922
nosy: docs at python, vadmium
priority: normal
severity: normal
status: open
title: Out of date code example for tkinter's createfilehandle
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug  6 12:20:34 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 06 Aug 2014 10:20: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: <1407320434.23.0.559587725077.issue22155@psf.upfronthosting.co.za>


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


----------
title: Out of date code example for tkinter's createfilehandle -> Out of date code example for tkinter's createfilehandler

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

From report at bugs.python.org  Wed Aug  6 14:09:12 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 06 Aug 2014 12:09:12 +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: <1407326952.62.0.528522644465.issue22155@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Wed Aug  6 14:18:12 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Aug 2014 12:18:12 +0000
Subject: [docs] [issue18841] math.isfinite fails with Decimal sNAN
In-Reply-To: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>
Message-ID: <1407327492.3.0.843845436223.issue18841@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Mark: it's not really ready for a patch, since there's no agreement yet on how best to solve this.  In fact, I'm tempted to close as "wont fix": the argument is that the math module consists for the most part only of thin wrappers around the platform math library.

The underlying need (as far as I understand it) is to be able to tell whether a given number is a nan or not without having to know in advance whether it's a float, int or Decimal instance.  There may be other ways of achieving this goal (like adding an `is_nan` method to `float` and `int`, for example.)

----------

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

From report at bugs.python.org  Wed Aug  6 21:30:21 2014
From: report at bugs.python.org (Yclept Nemo)
Date: Wed, 06 Aug 2014 19:30:21 +0000
Subject: [docs] [issue16399] argparse: append action with default list adds
	to list	instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1407353421.53.0.734634864601.issue16399@psf.upfronthosting.co.za>


Yclept Nemo added the comment:

Well that won't work. Example:

import argparse

class TestAction(argparse.Action):
    def __call__(self, parser, namespace, values, option_string=None):
        print("default: {}({})\tdest: {}({})".format(self.default, type(self.default), getattr(namespace, self.dest), type(getattr(namespace, self.dest))))
        if getattr(namespace, self.dest) is self.default:
            print("Replacing with: ", values)
            setattr(namespace, self.dest, values)
        # extra logical code not necessary for testcase

parser = argparse.ArgumentParser()

parser.add_argument\
        ( "-o", "--output"
        , type=int
        , action=TestAction
        , default=42
        )

args = parser.parse_args()

$ ./argparse_test -o 42 -o 100
default: 42(<class 'int'>)      dest: 42(<class 'int'>)
Replacing with:  42
default: 42(<class 'int'>)      dest: 42(<class 'int'>)
Replacing with:  100
100

Use this approach:
class ExtendAction(argparse.Action):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        if not isinstance(self.default, collections.abc.Iterable):
            self.default = [self.default]
        self.reset_dest = False
    def __call__(self, parser, namespace, values, option_string=None):
        if not self.reset_dest:
            setattr(namespace, self.dest, [])
            self.reset_dest = True
        getattr(namespace, self.dest).extend(values)

Anyway, this should be properly documented...

----------
nosy: +Yclept.Nemo

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

From report at bugs.python.org  Thu Aug  7 00:13:17 2014
From: report at bugs.python.org (paul j3)
Date: Wed, 06 Aug 2014 22:13:17 +0000
Subject: [docs] [issue16399] argparse: append action with default list adds
	to list	instead of overriding
In-Reply-To: <1351992623.71.0.851432414607.issue16399@psf.upfronthosting.co.za>
Message-ID: <1407363197.11.0.992871288139.issue16399@psf.upfronthosting.co.za>


paul j3 added the comment:

In my suggestion I used 

    if 'current_value is default':

without going into detail.  The use of an 'is' test for integer values is tricky, as discussed in http://bugs.python.org/issue18943

    int("42") is 42    # True
    int("257") is 257  # False

As with your 'self.reset_dest', in 18943 I suggested using a boolean flag instead of the 'is' test.

----------

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

From report at bugs.python.org  Thu Aug  7 07:50:34 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Aug 2014 05:50:34 +0000
Subject: [docs] [issue22142] PEP 465 operators not described in
	lexical_analysis
In-Reply-To: <1407254480.75.0.52462093327.issue22142@psf.upfronthosting.co.za>
Message-ID: <3hTJhT4Dsvz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 0bc58b4c0562 by Benjamin Peterson in branch 'default':
add matrix multiplication operator to correct lists (closes #22142)
http://hg.python.org/cpython/rev/0bc58b4c0562

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

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

From report at bugs.python.org  Thu Aug  7 11:55:45 2014
From: report at bugs.python.org (Daniel Lintott)
Date: Thu, 07 Aug 2014 09:55:45 +0000
Subject: [docs] [issue22162] Actiavting a venv - Dash doesn't understand
	source
Message-ID: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>


New submission from Daniel Lintott:

In the documentation for venv (https://docs.python.org/3.5/library/venv.html) it gives examples for activating the venv under bash/zsh.

For a long time under both Debian and Ubuntu the default shell has been Dash (https://wiki.ubuntu.com/DashAsBinSh)

Dash doesn't undertsand the command 'source' so instead the venv must be activated using the . command (as is done for Fish, but using the bash activate file instead)

----------
assignee: docs at python
components: Documentation
messages: 225001
nosy: dlintott, docs at python
priority: normal
severity: normal
status: open
title: Actiavting a venv - Dash doesn't understand source
type: enhancement

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

From report at bugs.python.org  Thu Aug  7 11:58:00 2014
From: report at bugs.python.org (Daniel Lintott)
Date: Thu, 07 Aug 2014 09:58:00 +0000
Subject: [docs] [issue22162] Actiavting a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407405480.93.0.761435837831.issue22162@psf.upfronthosting.co.za>


Changes by Daniel Lintott <daniel at serverb.co.uk>:


----------
nosy: +eric.araujo, ezio.melotti, georg.brandl

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

From report at bugs.python.org  Thu Aug  7 11:58:56 2014
From: report at bugs.python.org (Daniel Lintott)
Date: Thu, 07 Aug 2014 09:58:56 +0000
Subject: [docs] [issue22162] Activating a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407405536.24.0.458851084741.issue22162@psf.upfronthosting.co.za>


Changes by Daniel Lintott <daniel at serverb.co.uk>:


----------
title: Actiavting a venv - Dash doesn't understand source -> Activating a venv - Dash doesn't understand source

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

From report at bugs.python.org  Thu Aug  7 11:59:06 2014
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 07 Aug 2014 09:59:06 +0000
Subject: [docs] [issue22162] Activating a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407405546.4.0.457636045945.issue22162@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl

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

From report at bugs.python.org  Thu Aug  7 12:21:41 2014
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 07 Aug 2014 10:21:41 +0000
Subject: [docs] [issue22162] Activating a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407406901.9.0.443676410112.issue22162@psf.upfronthosting.co.za>


?ric Araujo added the comment:

dash is the default system shell used to execute scripts (i.e. /bin/sh), not the default shell used for users login shell and terminal emulators.

The venv/scripts/poxis/activate file seems to require bash anyway: running checkbashisms on it warns about ?hash -r?.

----------
assignee: docs at python -> vinay.sajip
nosy: +vinay.sajip

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

From report at bugs.python.org  Thu Aug  7 12:56:05 2014
From: report at bugs.python.org (Daniel Lintott)
Date: Thu, 07 Aug 2014 10:56:05 +0000
Subject: [docs] [issue22162] Activating a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407408965.92.0.380007241263.issue22162@psf.upfronthosting.co.za>


Daniel Lintott added the comment:

Hmm... just double checked this and this time has worked with the source command (previously was telling me it couldn't be found).

Have double checked and indeed the default login shell is bash

So feel free to close this issue

----------

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

From report at bugs.python.org  Thu Aug  7 14:01:39 2014
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Aug 2014 12:01:39 +0000
Subject: [docs] [issue22162] Activating a venv - Dash doesn't understand
	source
In-Reply-To: <1407405345.3.0.0508147883934.issue22162@psf.upfronthosting.co.za>
Message-ID: <1407412898.93.0.59789465903.issue22162@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Was there a reason you couldn't close it yourself?

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

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

From report at bugs.python.org  Thu Aug  7 22:20:44 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 07 Aug 2014 20:20:44 +0000
Subject: [docs] [issue18620] multiprocessing page leaves out important part
	of Pool	example
In-Reply-To: <1375389044.82.0.349700607179.issue18620@psf.upfronthosting.co.za>
Message-ID: <1407442844.57.0.399346269061.issue18620@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Looks as if the v2 and v3 docs need changing.

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

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

From report at bugs.python.org  Fri Aug  8 00:20:19 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 07 Aug 2014 22:20:19 +0000
Subject: [docs] [issue20598] argparse docs: '7'.split() is confusing magic
In-Reply-To: <1392132505.16.0.864715722344.issue20598@psf.upfronthosting.co.za>
Message-ID: <1407450019.69.0.0513588894927.issue20598@psf.upfronthosting.co.za>


paul j3 added the comment:

For documentation, ['this','is','a','test'] might be a bit clearer than 'this is a test'.split().  But generating a list of strings by split is, I think, a pretty basic idiom.

But for testing purposes the split() version is a bit more robust because it is closer to what might appear in sys.argv.

    In [196]: ['this','is','a','test'][-1] is 'test'
    Out[196]: True

    In [198]: 'this is a test'.split()[-1] is 'test'
    Out[198]: False

That is, the 'id' of a string generated by a split is not the same as that of an explicit string.  sys.argv is created by a split in the shell and/or the interpreter, so it too will fail this 'is' test.

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

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

From report at bugs.python.org  Fri Aug  8 01:27:58 2014
From: report at bugs.python.org (paul j3)
Date: Thu, 07 Aug 2014 23:27:58 +0000
Subject: [docs] [issue15428] add "Name Collision" section to argparse docs
In-Reply-To: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>
Message-ID: <1407454078.51.0.049001386073.issue15428@psf.upfronthosting.co.za>


paul j3 added the comment:

On Stackoverflow a couple of posters have asked about nesting namespaces as a way of separating the parser and subparser arguments.

http://stackoverflow.com/questions/15782948
http://stackoverflow.com/questions/18668227

One solution that I rather like http://stackoverflow.com/a/18709860/901925

uses a custom Namespace class that recognizes a 'dest' like

    p.add_argument('--deep', dest='test.doo.deep')

and produces

    Nestedspace(foo='test', test=Nestedspace(bar='baz', doo=Nestedspace(deep='doodod')))

I wonder if a simplified version of this could be added to the Namespace section in the documentation.

There are 2 sides to the name conflict issue:

- what control does the programmer have over names (esp. when using [parents] and subparsers)?

- how does the programmer want to access the arguments in the resulting namespace?

----------

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

From report at bugs.python.org  Fri Aug  8 03:09:01 2014
From: report at bugs.python.org (Roy Smith)
Date: Fri, 08 Aug 2014 01:09:01 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
Message-ID: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>


New submission from Roy Smith:

For background, see:

https://mail.python.org/pipermail/python-list/2014-August/676291.html

In a nutshell, the iglob() docs say, "Return an iterator which yields the same values as glob() without actually storing them all simultaneously."  The problem is, internally, it calls os.listdir(), which apparently *does* store the entire list internally, defeating the whole purpose of iglob()

I recognize that iglob() is not going to get fixed in 2.7, but at least the documentation should be updated to point out that it doesn't really do what it says it does.  Or rather, it doesn't really not do what it says it doesn't :-)

----------
assignee: docs at python
components: Documentation
messages: 225048
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: iglob() has misleading documentation (does indeed store names internally)
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  8 03:24:52 2014
From: report at bugs.python.org (Tim Chase)
Date: Fri, 08 Aug 2014 01:24:52 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>
Message-ID: <1407461092.23.0.8682128768.issue22167@psf.upfronthosting.co.za>


Changes by Tim Chase <python.bugs at tim.thechases.com>:


----------
nosy: +Gumnos

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

From report at bugs.python.org  Fri Aug  8 03:59:25 2014
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 08 Aug 2014 01:59:25 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>
Message-ID: <1407463165.54.0.126138523997.issue22167@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I agree that the documentation could be improved, but it's not really *wrong*. Consider a glob like "spam/[abc]/*.txt". What iglob does is conceptually closer to:

(1) generate the list of files matching "spam/a/*.txt" and yield them;
(2) generate the list of files matching "spam/b/*.txt" and yield them;
(3) generate the list of files matching "spam/c/*.txt" and yield them

rather than:

(1) generate the list of files matching "spam/a/*.txt";
(2) append the files matching "spam/b/*.txt";
(3) append the files matching "spam/c/*.txt";
(4) finally yield them

(see the source code here: http://hg.python.org/cpython/file/3.4/Lib/glob.py ). I think the documentation is trying to say that iglob doesn't *always* store all the matching files, without implying that it *never* stores all the matching files. I can't think of a clean way to explain that, so a doc patch is welcome.

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

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

From report at bugs.python.org  Fri Aug  8 04:28:02 2014
From: report at bugs.python.org (Roy Smith)
Date: Fri, 08 Aug 2014 02:28:02 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>
Message-ID: <1407464882.23.0.751366485564.issue22167@psf.upfronthosting.co.za>


Roy Smith added the comment:

The thread that led to this started out with the use case of a directory that had 200k files in it.  If I ran iglob() on that and discovered that it had internally generated a list of all 200k names in memory at the same time, I would be pretty darn surprised, based on what the docs say now.

We're shooting for principle of least astonishment here.

----------

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

From report at bugs.python.org  Fri Aug  8 05:26:17 2014
From: report at bugs.python.org (Susan Tan)
Date: Fri, 08 Aug 2014 03:26:17 +0000
Subject: [docs] [issue22170] Typo in iterator doc
Message-ID: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>


New submission from Susan Tan:

Typo in last line: 

for line in open("myfile.txt"):
    print line,

Instead there should be no extra "," character in "print line,"

----------
assignee: docs at python
components: Documentation
messages: 225056
nosy: Susan, docs at python
priority: normal
severity: normal
status: open
title: Typo in iterator doc
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug  8 05:26:49 2014
From: report at bugs.python.org (Susan Tan)
Date: Fri, 08 Aug 2014 03:26:49 +0000
Subject: [docs] [issue22170] Typo in iterator doc
In-Reply-To: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>
Message-ID: <1407468409.71.0.699334698455.issue22170@psf.upfronthosting.co.za>


Susan Tan added the comment:

https://docs.python.org/2/tutorial/classes.html#iterators

----------

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

From report at bugs.python.org  Fri Aug  8 09:29:04 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 08 Aug 2014 07:29:04 +0000
Subject: [docs] [issue22170] Typo in iterator doc
In-Reply-To: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>
Message-ID: <1407482944.29.0.369096479458.issue22170@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The comma is needed to prevent blank newlines being printed.  Please try it for yourself.

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

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

From report at bugs.python.org  Fri Aug  8 15:03:05 2014
From: report at bugs.python.org (Roy Smith)
Date: Fri, 08 Aug 2014 13:03:05 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>
Message-ID: <1407502985.29.0.594020874021.issue22167@psf.upfronthosting.co.za>


Roy Smith added the comment:

How about something like this:

Note: The current iglob() implementation is optimized for the case of many files distributed in a large directory tree.  Internally, it iterates over the directory tree, and stores all the names from each directory at once.  This will lead to pathologically inefficient behavior when any individual directory has a large number of files in it.

----------

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

From report at bugs.python.org  Fri Aug  8 15:22:33 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Aug 2014 13:22:33 +0000
Subject: [docs] [issue22167] iglob() has misleading documentation (does
	indeed store	names internally)
In-Reply-To: <1407460141.27.0.298063472331.issue22167@psf.upfronthosting.co.za>
Message-ID: <1407504153.88.0.764149494596.issue22167@psf.upfronthosting.co.za>


R. David Murray added the comment:

IMO the documentation isn't *wrong*, just misleading :)

What it is saying is that *your program* doesn't have to store the full list returned by iglob before being able to use it (ie: iglob doesn't return a list).  It says nothing about what resources are used internally, other than an implied contract that there is *some* efficiency over calling glob; which, as explained above, there is.  The fact that the implementation uses lots of memory if any single directory is large is then a performance bug, which can theoretically be fixed in 3.5 using scandir.

The reason iglob was introduced, if you check the revision history, is that glob used to call itself recursively for each sub-directory, which meant it held *all* of the files in *all* of the scanned tree in memory at one time.  It is literally true that the difference between glob and iglob is that with iglob your program doesn't have to store the full list of matches from all subdirectories, but talking about "your program" is not something we typically do in python docs, it is implied.

Perhaps in 2.7/3.4 we can mention in the module docs that at most one directory's worth of data will be held in memory during the globbing process, but it feels a little weird to document an implementation detail like that.  Still, if someone can come up with improved wording for the docs, we can add it.

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

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

From report at bugs.python.org  Fri Aug  8 15:35:55 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Aug 2014 13:35:55 +0000
Subject: [docs] [issue22170] Typo in iterator doc
In-Reply-To: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>
Message-ID: <1407504955.0.0.897857871082.issue22170@psf.upfronthosting.co.za>


R. David Murray added the comment:

The comma means print doesn't add a newline to what is printed.  This is correct because the lines read from the file already have a newline at the end.  I can see how this example becomes a little confusing in a tutorial section on iterators, but as Mark said, if you try it, you find out that it works, and if you play with removing the comma you learn things about how python works with files (I don't remember how much of that is covered earlier in the tutorial).

In python3 this is clearer, because the equivalent line uses end='', making it clearer that it is intentional and meaningful.

Except...that in the python3 tutorial it currently *doesn't* use end='', so that example is in fact wrong and needs to be fixed :)

----------
nosy: +r.david.murray
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.4, Python 3.5 -Python 2.7

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

From report at bugs.python.org  Fri Aug  8 16:24:43 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 08 Aug 2014 14:24:43 +0000
Subject: [docs] [issue22170] Typo in iterator doc
In-Reply-To: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>
Message-ID: <3hV83G341Jz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 35db84720d8d by Ezio Melotti in branch '3.4':
#22170: avoid printing newlines twice in tutorial example.
http://hg.python.org/cpython/rev/35db84720d8d

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

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

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

From report at bugs.python.org  Fri Aug  8 16:25:13 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 08 Aug 2014 14:25:13 +0000
Subject: [docs] [issue22170] Typo in iterator doc
In-Reply-To: <1407468377.55.0.545687415871.issue22170@psf.upfronthosting.co.za>
Message-ID: <1407507913.6.0.398246878594.issue22170@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Fixed, thanks for the report!

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

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

From report at bugs.python.org  Fri Aug  8 21:38:33 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2014 19:38:33 +0000
Subject: [docs] [issue22153] There is no standard TestCase.runTest
	implementation
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <1407526713.86.0.578550370375.issue22153@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Fri Aug  8 22:44:58 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Aug 2014 20:44:58 +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: <1407530698.16.0.171787755296.issue22155@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The latest x.y docs are available at docs.python.org/x.y, such as
https://docs.python.org/3.4/faq/gui.html

I was not aware of this undocumented method of the undocumented tkapp class.  It is not available on Windows, and the FAQ should say so. From Modules/_tkinter.c:

 /* Tcl_CreateFileHandler() changed several times; these macros deal with the  messiness.  In Tcl 8.0 and later, it is not available on Windows (and on  Unix, only because Jack added it back); when available on Windows, it only applies to sockets. */

Current _tkinter only supports 8.4+. The messiness still appears in the asyncio design.

'createfile' does not appear on the pydoc page for tkinter; directly using createfilehandle seems to be the only access.

----------
nosy: +serhiy.storchaka, terry.reedy

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

From report at bugs.python.org  Fri Aug  8 22:48:59 2014
From: report at bugs.python.org (diana)
Date: Fri, 08 Aug 2014 20:48:59 +0000
Subject: [docs] [issue22174] property doc fixes
Message-ID: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>


New submission from diana:

The property docs are a bit funky.

    https://docs.python.org/3/library/functions.html#property

1) docstrings have zero to do with making a read-only property. It currently says:

"If given, doc will be the docstring of the property attribute. Otherwise, the property will copy fget?s docstring (if it exists). This makes it possible to create read-only properties easily using property() as a decorator:"

2) The 'then' in this sentence is awkward (and incorrect English).

"If then c is an instance of C, c.x will invoke the getter, c.x = value will invoke the setter and del c.x the deleter."

3) This sentence is missing a beginning.

"turns the voltage() method into a ?getter? for a read-only attribute with the same name."

4) This sentence has an extra comma (after del'ing):

"fget is a function for getting an attribute value, likewise fset is a function for setting, and fdel a function for del?ing, an attribute."

Attached is a patch with minimal changes to the property docs, addressing the above four issues. Okay, that's not entirely true -- I did add an example usage because the current docs don't actually show using a property attribute.

>>> p = Parrot()
>>> p.voltage
100000

I've also attached an "after" screenshot of the docs in case it helps with review.

Cheers,

--diana

----------
assignee: docs at python
components: Documentation
files: property_docs.patch
keywords: patch
messages: 225086
nosy: diana, docs at python
priority: normal
severity: normal
status: open
title: property doc fixes
versions: Python 3.5
Added file: http://bugs.python.org/file36318/property_docs.patch

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

From report at bugs.python.org  Fri Aug  8 22:50:16 2014
From: report at bugs.python.org (diana)
Date: Fri, 08 Aug 2014 20:50:16 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407531016.38.0.691946602484.issue22174@psf.upfronthosting.co.za>


Changes by diana <diana.joan.clarke at gmail.com>:


Added file: http://bugs.python.org/file36319/Screen Shot 2014-08-08 at 4.44.07 PM.png

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

From report at bugs.python.org  Sat Aug  9 00:05:53 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Aug 2014 22:05:53 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407535553.01.0.463770345104.issue22174@psf.upfronthosting.co.za>


R. David Murray added the comment:

The docstring discussion is correct in the context.  property can easily be used to create a read only property because when used as a decorator the function that follows the decorator call is passed to it as fget, *and it copies the docstring from the function into the created property*.

The 'then' is indeed redundant (if kept should properly be set of by commas, but there is no reason to keep it).

'turns the voltage' is still part of the previous sentence.  Read it as "create read-only properties easily using property() as a decorator as follows...[this example] turns the voltage() method into a..."  Your reformulation is, however, clearer.

The comma in the 'fget is a function' sentence is in the correct place.  "and fdel a function for del'ing" is phrase...I forget the formal name for the type of phrase.  It's analogous to the structure of this sentence: "She forgot to bring not only her lunch, but also her wallet, to work".  However, the comma after 'value' should technically be a semicolon.  Although correct, I think the whole sentence would read better if it instead said "fget is a function for getting an attribute value, fset is a function for setting an attribute value, and fdel is a function for del'ing an attribute."

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

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

From report at bugs.python.org  Sat Aug  9 03:15:57 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Aug 2014 01:15:57 +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: <1407546957.13.0.437111272225.issue22155@psf.upfronthosting.co.za>


Martin Panter added the comment:

Just about the broken docs link: I was trying to find a permanent version of the docs to link to. The usual docs page links to ?Old versions? <https://www.python.org/doc/versions/>, but top link there, 3.4.1, does not seem to be available.

----------

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

From report at bugs.python.org  Sun Aug 10 01:27:53 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 09 Aug 2014 23:27:53 +0000
Subject: [docs] [issue14944] Setup & Usage documentation for pydoc,
	idle & 2to3
In-Reply-To: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za>
Message-ID: <1407626873.49.0.8878412859.issue14944@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

I'm assuming that this still applies to 3.4 and 2.7.

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

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

From report at bugs.python.org  Sun Aug 10 01:51:09 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 09 Aug 2014 23:51:09 +0000
Subject: [docs] [issue16893] Create IDLE help.txt from Doc/library/idle.rst
In-Reply-To: <1357663512.19.0.739336896498.issue16893@psf.upfronthosting.co.za>
Message-ID: <1407628269.96.0.554331989699.issue16893@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug 10 05:12:03 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 03:12:03 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407640323.05.0.266166151436.issue22174@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Also, please don't add the extra whitespace to the docstring.  It is intentionally compact because of the differing needs of various IDEs and help utlities.

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

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

From report at bugs.python.org  Sun Aug 10 07:17:07 2014
From: report at bugs.python.org (diana)
Date: Sun, 10 Aug 2014 05:17:07 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407647827.11.0.275665640178.issue22174@psf.upfronthosting.co.za>


diana added the comment:

This whitespace? Or did you mean something else?

      class C:
          def __init__(self):
              self._x = None

          def getx(self):
              return self._x

          def setx(self, value):
              self._x = value

          def delx(self):
              del self._x

          x = property(getx, setx, delx, "I'm the 'x' property.")

versus:

      class C:
          def __init__(self):
              self._x = None

          def getx(self):
              return self._x
          def setx(self, value):
              self._x = value
          def delx(self):
              del self._x
          x = property(getx, setx, delx, "I'm the 'x' property.")

I added it to be consistent with the rest of the code snippets in the property docs. For example:

      class C:
          def __init__(self):
              self._x = None

          @property
          def x(self):
              """I'm the 'x' property."""
              return self._x

          @x.setter
          def x(self, value):
              self._x = value

          @x.deleter
          def x(self):
              del self._x

Of the three code snippets in the property docs, that first one is the only one that doesn't have whitespace between the methods. That first code snippet also has inconsistent whitespace within itself (__init__ vs the rest of methods).

Anyhoo, that was my reasoning, but that's largely beside the point. I will happily drop it and leave it as-is. What really prompted me to submit a patch was this paragraph:

"If given, doc will be the docstring of the property attribute. Otherwise, the property will copy fget?s docstring (if it exists). This makes it possible to create read-only properties easily using property() as a decorator:"

I now understand the original intent, but I don't think it's clear as-is. 

I also find it a bit odd that 'fget', 'fset', 'fdel' are all defined in the first sentence of the docs, but 'doc' isn't. It then launches into an example that uses 'doc' (still as of yet undefined), before defining 'doc' later on in the read-only properties part.

I'll think on it a bit some more -- feel free to close this in the mean time. It's been this way for a better part of a decade, so perhaps it's just me ;)

Cheers,

--diana

----------

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

From report at bugs.python.org  Sun Aug 10 10:44:12 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 08:44:12 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407660252.47.0.324335758581.issue22174@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug 10 11:22:52 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 09:22:52 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407662571.96.0.782634525808.issue22174@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Most of the patch looks to be an improvement.  I've massaged it a little and attached a revised patch.

----------
Added file: http://bugs.python.org/file36332/property2.diff

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

From ezio.melotti at gmail.com  Sun Aug 10 11:36:36 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 10 Aug 2014 09:36:36 -0000
Subject: [docs] property doc fixes (issue 22174)
Message-ID: <20140810093636.25947.91494@psf.upfronthosting.co.za>


http://bugs.python.org/review/22174/diff/12675/Doc/library/functions.rst
File Doc/library/functions.rst (right):

http://bugs.python.org/review/22174/diff/12675/Doc/library/functions.rst#newcode1111
Doc/library/functions.rst:1111: value.  And *doc* creates a docstring
for the attribute.
Having 3 small and similar sentences separated by a full stop doesn't
sound too well to me, and neither does starting the last with "And".

What about:
"""
*fget*, *fset*, and *fdel* are functions used respectively to get, set,
and delete an attribute value.  *doc* is used to define the docstring of
the attribute.
"""

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

From report at bugs.python.org  Sun Aug 10 12:30:30 2014
From: report at bugs.python.org (Chris Rebert)
Date: Sun, 10 Aug 2014 10:30:30 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1407666629.93.0.647708641471.issue21514@psf.upfronthosting.co.za>


Chris Rebert added the comment:

So, when might I expect to see this patch merged, since it's now been approved?

----------

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

From report at bugs.python.org  Sun Aug 10 16:18:24 2014
From: report at bugs.python.org (Michael Williamson)
Date: Sun, 10 Aug 2014 14:18:24 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
Message-ID: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>


New submission from Michael Williamson:

The Python docs for the operator module include an example using map and setitem to "Build a dictionary that maps the ordinals from 0 to 255 to their character equivalents.":

    d = {}
    keys = range(256)
    vals = map(chr, keys)
    map(operator.setitem, [d]*len(keys), keys, vals)   

Since map is lazy since Python 3, the dictionary d is never actually changed in this example. I'm not entirely sure what the idiomatic way to fix the example is since it strikes me as being fairly unidiomatic to begin with, but the simplest would be to call list on the result of map to force evaluation (patch attached).

----------
assignee: docs at python
components: Documentation
files: doc-operator-example.patch
keywords: patch
messages: 225141
nosy: docs at python, mwilliamson
priority: normal
severity: normal
status: open
title: operator.setitem example no longer works in Python 3 due to lazy map
versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36333/doc-operator-example.patch

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

From report at bugs.python.org  Sun Aug 10 17:13:11 2014
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Aug 2014 15:13:11 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>
Message-ID: <1407683591.89.0.52787124874.issue22180@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  There was a discussion in issue 22106 about valid examples for using 'pass'.  This case is analogous to the one I came up with.

  for x in map(...):
     pass

that avoids building a list.

Not that any of it is idiomatic, as you say.

----------
nosy: +r.david.murray
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Aug 10 19:10:03 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Aug 2014 17:10:03 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>
Message-ID: <1407690603.33.0.534440184162.issue22180@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The whole example is bad and should be removed or replace with something else:

1. Using map() is an anti-pattern here, since the function results are not used.

2. To "build a dictionary that maps the ordinals from 0 to 255 to their character equivalents", modern Python code should use a dict comprehension and avoid operator.setitem() entirely.

----------
nosy: +pitrou, rhettinger

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

From report at bugs.python.org  Sun Aug 10 19:20:20 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 17:20:20 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>
Message-ID: <1407691220.32.0.201470979898.issue22180@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> The whole example is bad and should be removed 
> or replace with something else:

I'm not sure there are ANY examples of operator.setitem that couldn't be done a better way without it.  How about we remove it and leave the examples for things that people ought to be doing.

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

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

From report at bugs.python.org  Sun Aug 10 19:23:41 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Aug 2014 17:23:41 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407691220.32.0.201470979898.issue22180@psf.upfronthosting.co.za>
Message-ID: <53E7AA98.8030809@free.fr>


Antoine Pitrou added the comment:

Le 10/08/2014 13:20, Raymond Hettinger a ?crit :
>
> Raymond Hettinger added the comment:
>
>> The whole example is bad and should be removed
>> or replace with something else:
>
> I'm not sure there are ANY examples of operator.setitem that
> couldn't
be done a better way without it. How about we remove it and leave the
examples for things that people ought to be doing.

Agreed. operator.setitem() isn't really ever used in my experience.

----------

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

From report at bugs.python.org  Sun Aug 10 19:33:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Aug 2014 17:33:35 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>
Message-ID: <3hWS8H0YqJz7Lld@mail.python.org>


Roundup Robot added the comment:

New changeset 9c250f34bfa3 by Raymond Hettinger in branch '3.4':
Issue #22180:  Remove weak example
http://hg.python.org/cpython/rev/9c250f34bfa3

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

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

From report at bugs.python.org  Sun Aug 10 19:35:07 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 17:35:07 +0000
Subject: [docs] [issue22180] operator.setitem example no longer works in
	Python 3 due	to lazy map
In-Reply-To: <1407680304.87.0.195005785734.issue22180@psf.upfronthosting.co.za>
Message-ID: <1407692107.2.0.936290066004.issue22180@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/issue22180>
_______________________________________

From report at bugs.python.org  Sun Aug 10 19:41:59 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Aug 2014 17:41:59 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <3hWSKy3Sksz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset ebd6f7f7859f by Raymond Hettinger in branch '3.4':
Issue #22174:  Clean-up grammar and ambiguities in property() docs.
http://hg.python.org/cpython/rev/ebd6f7f7859f

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

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

From report at bugs.python.org  Sun Aug 10 19:44:27 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Aug 2014 17:44:27 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <3hWSNq292Gz7LjM@mail.python.org>


Roundup Robot added the comment:

New changeset 98a2e215ff01 by Raymond Hettinger in branch '2.7':
Issue #22174:  Clean-up grammar and ambiguities in property() docs.
http://hg.python.org/cpython/rev/98a2e215ff01

----------

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

From report at bugs.python.org  Sun Aug 10 19:47:09 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Aug 2014 17:47:09 +0000
Subject: [docs] [issue22174] property doc fixes
In-Reply-To: <1407530939.59.0.62498014602.issue22174@psf.upfronthosting.co.za>
Message-ID: <1407692829.35.0.83255923539.issue22174@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Diana, thank you for the patch. Sorry for the bogus comment on whitespace.  I was looking the the docstring at the same time as reviewing the patch.

David, thanks for looking at it as well.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Aug 11 01:11:39 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 10 Aug 2014 23:11:39 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <3hWbfL1l3bz7LkR@mail.python.org>


Roundup Robot added the comment:

New changeset d0ea92701b1e by Victor Stinner in branch '3.4':
Issue #22112, asyncio doc: replace loop.create_task(coro) with
http://hg.python.org/cpython/rev/d0ea92701b1e

New changeset 18a311479e8b by Victor Stinner in branch 'default':
(Merge 3.4) Issue #22112, asyncio doc: replace loop.create_task(coro) with
http://hg.python.org/cpython/rev/18a311479e8b

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

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

From report at bugs.python.org  Mon Aug 11 01:11:53 2014
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Aug 2014 23:11:53 +0000
Subject: [docs] [issue22112] '_UnixSelectorEventLoop' object has no
	attribute	'create_task'
In-Reply-To: <1406774418.2.0.505776361437.issue22112@psf.upfronthosting.co.za>
Message-ID: <1407712313.7.0.46751562535.issue22112@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug 11 05:03:53 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Aug 2014 03:03:53 +0000
Subject: [docs] [issue22145] <> in parser spec but not lexer spec
In-Reply-To: <1407256523.86.0.758013450113.issue22145@psf.upfronthosting.co.za>
Message-ID: <1407726233.27.0.321382762815.issue22145@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug 11 05:03:59 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Aug 2014 03:03:59 +0000
Subject: [docs] [issue22145] <> in parser spec but not lexer spec
In-Reply-To: <1407256523.86.0.758013450113.issue22145@psf.upfronthosting.co.za>
Message-ID: <1407726239.63.0.0587133094797.issue22145@psf.upfronthosting.co.za>


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


----------
stage:  -> resolved

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

From report at bugs.python.org  Mon Aug 11 08:51:49 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 11 Aug 2014 06:51:49 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1407739909.72.0.0711045732709.issue21514@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Soonish.

----------

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

From report at bugs.python.org  Mon Aug 11 11:24:58 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 11 Aug 2014 09:24:58 +0000
Subject: [docs] [issue21514] update json module docs in light of RFC 7159 &
	ECMA-404
In-Reply-To: <1400215968.18.0.723032535405.issue21514@psf.upfronthosting.co.za>
Message-ID: <1407749098.95.0.952105278656.issue21514@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug 11 11:27:32 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 11 Aug 2014 09:27:32 +0000
Subject: [docs] [issue19055] Clarify docs for re module: why * does not
	match as many	repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1407749252.01.0.698615780468.issue19055@psf.upfronthosting.co.za>


Akira Li added the comment:

tl;dr: added patch that clarifies Python re behavior. Please, review.

---

The documented behavior is not clear: why (a|ab)* is not equivalent to
(a|ab)(a|ab) for aba if the docs say "as many repetitions as are
possible"?

And it is not obvious (it is not the only possible behavior) e.g.,
POSIX [1] expects the longest match, PCRE [2] group may be atomic
(/possesive quantifiers), or there is ungreedy repetition:

  $ echo abac | grep -o '\(a\|ab\)* # Basic Regular Expression
  aba
  $ echo abac | grep -Eo '(a|ab)*' # Extended Regular Expression
  aba
  $ echo abac | grep -Po '(a|ab)*' # PCRE (like Python regexes)
  a
  a
  $ echo abac | grep -Po '(a|ab)(a|ab)' # PCRE (two repeats)
  aba
  $ echo abac | grep -Po '(a|ab)*c' # PCRE (re-eval to match the rest)
  abac
  $ echo abAc | grep -iPo '(a|ab)*+c' # PCRE (possessive quantifiers)
  Ac
  $ echo abac | grep -Po '(a|ab)*?' # PCRE (ungreedy, zero repeats)
  # matches nothing

where BREs, EREs are defined in [1] that says:

 If the pattern permits a variable number of matching characters and
 thus there is more than one such sequence starting at that point,
 *the longest such sequence is matched*.

and:

 Consistent with the whole match being the longest of the leftmost
 matches, each subpattern, from left to right, *shall match the
 longest possible string.*

Python regexes work like PCRE [2] that says:

  The matching process tries each alternative in turn, from left to
  right, and *the first one that succeeds is used*.  If the
  alternatives are within a subpattern (defined below), "succeeds"
  means matching the rest of the main pattern as well as the
  alternative in the subpattern.

It explains why (a|ab)* matches only a in aba ("the first one that
succeeds") and why at the same time (a|ab)*c matches abac: (a|ab) may
match ab in the latter case because the main pattern would fail
otherwise i.e., the advanced definition of "succeeds" is used:
""succeeds" means matching the rest of the main pattern ...".

Python docs [3] are similar but do not contain the "advanced"
"succeeds" definition:

   REs separated by ``'|'`` are tried from left to right. When one
   pattern completely matches, that branch is accepted. This means
   that once ``A`` matches, ``B`` will not be tested further, even if
   it would produce a longer overall match.  In other words, the
   ``'|'`` operator is never greedy.

It explains why (a|ab) matches a in aba. 

'*' behavior [2]:

   By default, the quantifiers are "greedy", that is, they match as
   much as possible (up to the maximum number of permitted times),
   without causing the rest of the pattern to fail.

and again Python docs [3] are similar:

  ``'*'`` Causes the resulting RE to match 0 or more repetitions of
   the preceding RE, as many repetitions as are possible.

It implies that (a|ab)* should be equivalent to (a|ab)(a|ab) to match
aba -- TWO REPETITIONS ARE MORE THAN ONE: "as many repetitions as are
possible". But it matches only 'a' i.e., it works as (a|ab) -- only
one repetition instead of two. In reality, (a|ab)* along works like a*.

I've uploaded a documentation patch that makes Python documentation
for '|' more similar to PCRE and clarifies '*' definition as R. David
Murray suggested in msg198126. Please, review.

[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html
[2] http://man7.org/linux/man-pages/man3/pcrepattern.3.html
[3] http://hg.python.org/cpython/file/18a311479e8b/Doc/library/re.rst

----------
components:  -Regular Expressions
keywords: +patch
nosy: +akira
title: Regular expressions: * does not match as many repetitions as possible. -> Clarify docs for re module: why * does not match as many repetitions as possible.
versions: +Python 3.5 -Python 2.7, Python 3.3
Added file: http://bugs.python.org/file36340/re-docs-repetitions.patch

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

From report at bugs.python.org  Mon Aug 11 11:28:54 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 11 Aug 2014 09:28:54 +0000
Subject: [docs] [issue19055] Clarify docs for re module: why * does not
	match as many	repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1407749334.29.0.0890587595573.issue19055@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Removed file: http://bugs.python.org/file36340/re-docs-repetitions.patch

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

From report at bugs.python.org  Mon Aug 11 11:29:02 2014
From: report at bugs.python.org (Akira Li)
Date: Mon, 11 Aug 2014 09:29:02 +0000
Subject: [docs] [issue19055] Clarify docs for re module: why * does not
	match as many	repetitions as possible.
In-Reply-To: <1379629723.54.0.556911663587.issue19055@psf.upfronthosting.co.za>
Message-ID: <1407749342.92.0.510591569269.issue19055@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


Added file: http://bugs.python.org/file36341/re-docs-repetitions.patch

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

From maillist at schwertberger.de  Wed Aug  6 19:28:42 2014
From: maillist at schwertberger.de (Dietmar Schwertberger)
Date: Wed, 06 Aug 2014 19:28:42 +0200
Subject: [docs] asyncio: example for shield and readexactly
Message-ID: <53E265CA.8050202@schwertberger.de>

Hi!

I've recently started using asyncio.
My usage includes code which reads two bytes, but with a timeout.

My naive approach was:
rx = yield from asyncio.wait_for( reader.readexactly(2), 2.0)
But of course this does not work as it could lose a byte if exactly
one byte hasbeen received when the timeout was met.

For asyncio beginners it's not obvious how to fix that and especially
how to use shield().

My code now looks something like that:

readexactly_task = None
while True:
     try:
         if readexactly_task is None:
             # create a task to receive two bytes
             readexactly_task = asyncio.Task( reader.readexactly(2) )
         # give the task two seconds to complete
         # shield it not to be canceled on timeout
         rx = yield from asyncio.wait_for( 
asyncio.shield(readexactly_task), 2.0)
         readexactly_task = None # task has finished
         if not rx:
             break # EOF met
     except asyncio.TimeoutError:
         # asyncio.wait_for was canceled
         # the task readexactly_task is still alive
         rx = None
     if rx:
         # process the received bytes
         print(rx)



I think that it would be helpful to have such an example in the 
documentation for both
StreamReader and shield.


Of course, if readexactly had an argument 'timeout' things would have 
been easier...


Regards,

Dietmar



From tcstory at 163.com  Sun Aug 10 09:00:21 2014
From: tcstory at 163.com (tcstory)
Date: Sun, 10 Aug 2014 15:00:21 +0800 (CST)
Subject: [docs] Found repeated content
Message-ID: <6db5ccd9.afd0.147beb7c9b3.Coremail.tcstory@163.com>

In page https://docs.python.org/3/library/socket.html?highlight=socket#module-socket
the repeated content is "If addr_type is TIPC_ADDR_ID, then v1 is the node, v2 is the reference, and v3 should be set to 0."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140810/98728150/attachment.html>

From dobermiller at gmail.com  Tue Aug 12 03:05:53 2014
From: dobermiller at gmail.com (Daniel Obermiller)
Date: Mon, 11 Aug 2014 20:05:53 -0500
Subject: [docs] Error in the documentation for unittest
Message-ID: <CAKOA+BZePRxjsadthBJ8vAvaXtDreMMZ_1R-S2pYngjxZ4DK6Q@mail.gmail.com>

In the documentation for unittest here
https://docs.python.org/2/library/unittest.html

This segment is not entirely correct

> Instead of unittest.main()
> <https://docs.python.org/2/library/unittest.html#unittest.main>, there
> are other ways to run the tests with a finer level of control, less terse
> output, and no requirement to be run from the command line. For example,
> the last two lines may be replaced with:
>
> suite = unittest.TestLoader().loadTestsFromTestCase(TestSequenceFunctions)unittest.TextTestRunner(verbosity=2).run(suite)
>
> Running the revised script from the interpreter or another script produces
> the following output:
>
>
> test_choice (__main__.TestSequenceFunctions) ... ok
> test_sample (__main__.TestSequenceFunctions) ... ok
> test_shuffle (__main__.TestSequenceFunctions) ... ok
>
> ----------------------------------------------------------------------
> Ran 3 tests in 0.110s
>
> OK
>
> This is not entirely accurate - in order to get that output from the
interpreter or another script I had to provide the stream as well, like so

 unittest.TextTestRunner(sys.stdout, verbosity=2).run(suite)


Regards,

Dan Obermiller
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140811/b662b9f9/attachment.html>

From report at bugs.python.org  Tue Aug 12 10:56:48 2014
From: report at bugs.python.org (Ari Koivula)
Date: Tue, 12 Aug 2014 08:56:48 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1407833808.61.0.93087323191.issue12954@psf.upfronthosting.co.za>


Ari Koivula added the comment:

I encountered this problem on Python 3.2.5 on Windows and don't think a vague warning about initializing modules is a proper solution. A better solution would be to simply not add multiple handlers, even if log_to_stderr is called more than once.

----------
nosy: +Ari.Koivula

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

From report at bugs.python.org  Tue Aug 12 18:57:32 2014
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Tue, 12 Aug 2014 16:57:32 +0000
Subject: [docs] [issue22186] Typos in .py files
Message-ID: <1407862651.37.0.513368911737.issue22186@psf.upfronthosting.co.za>


New submission from F?vry Thibault:

The patch removes several typos found in .py files.

----------
assignee: docs at python
components: Documentation
files: spelling.diff
keywords: patch
messages: 225232
nosy: docs at python, iwontbecreative
priority: normal
severity: normal
status: open
title: Typos in .py files
type: enhancement
Added file: http://bugs.python.org/file36358/spelling.diff

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

From report at bugs.python.org  Tue Aug 12 20:36:17 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Aug 2014 18:36:17 +0000
Subject: [docs] [issue22186] Typos in .py files
In-Reply-To: <1407862651.37.0.513368911737.issue22186@psf.upfronthosting.co.za>
Message-ID: <1407868577.49.0.557894919187.issue22186@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good except for this one:

-        # Remove the 'Current' link, that way we don't accidentally mess
+        # Remove the 'Current' link, that way we don't accidentaly mess

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Tue Aug 12 20:50:28 2014
From: report at bugs.python.org (=?utf-8?q?F=C3=A9vry_Thibault?=)
Date: Tue, 12 Aug 2014 18:50:28 +0000
Subject: [docs] [issue22186] Typos in .py files
In-Reply-To: <1407862651.37.0.513368911737.issue22186@psf.upfronthosting.co.za>
Message-ID: <1407869428.64.0.841476330581.issue22186@psf.upfronthosting.co.za>


F?vry Thibault added the comment:

Right, must have done something wrong at some point.
Here is an updated diff.

----------
Added file: http://bugs.python.org/file36361/spelling.diff

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

From report at bugs.python.org  Tue Aug 12 22:03:21 2014
From: report at bugs.python.org (Jon Poler)
Date: Tue, 12 Aug 2014 20:03:21 +0000
Subject: [docs] [issue22014] Add summary table for OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1407873801.4.0.958884981026.issue22014@psf.upfronthosting.co.za>


Jon Poler added the comment:

I will give this a shot if it is just hard-coding a table with errno names. Dynamically scraping the errno names and inserting them with the exception hierarchy might be beyond me since I've never used Sphinx before.

----------
nosy: +jon.poler

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

From frase at cs.wisc.edu  Tue Aug 12 22:46:17 2014
From: frase at cs.wisc.edu (Alex Frase)
Date: Tue, 12 Aug 2014 15:46:17 -0500
Subject: [docs] surprisingly poor performance of random.sample(set)
Message-ID: <9587f2ec-857c-4cf4-8a88-c176f351604e@email.android.com>

Hi,

I noticed recently that running random.sample() on a set is measurably slower than doing so on a list or tuple with the same contents. I suspect that this is due to the "implementation detail" of converting the population argument to a tuple internally; that may not matter much for a single call, but when doing i.e. permutation testing, it is not unreasonable to call random.sample() on the same population 1000s of times in a tight loop. In that scenario, letting it cast the set to a tuple inside the loop makes it ~50x slower than casting once outside the loop and passing a tuple to random.sample() instead of a set.

Assuming there is no easy way for random.sample() to work efficiently with a set, would it at least be possible to mention this behavior in the documentation? Right now there is no indication that the data structure used for the population makes any difference, which may lead people to just assume that random.sample() is slow, not realizing they could get a 50x boost with a single cast outside their loop.

Regards,
Alex Frase

From romerox.adrian at gmail.com  Wed Aug 13 00:55:10 2014
From: romerox.adrian at gmail.com (=?UTF-8?Q?H=C3=A1drian_R?=)
Date: Wed, 13 Aug 2014 00:55:10 +0200
Subject: [docs] Potential vulnerabilities in python (2.7.8)
Message-ID: <CABV5r3yX+gRek-e0+Dy5PyDb3qL_XfUyUokPT7RijARGvbxeYw@mail.gmail.com>

Hi, I'm H?drien Romero Soria - @Kaiwaiata??, I am a 16 year old boy,
passionate about computer security, since more than 2h searching and
finding various possible vulnerabilities in source code of python..
I will tell you some vulnerabilities now, if they treat me well I will tell
the other..

foolish or important things?

*#* unsafe use of *strcpy()*:

*python.tar\python-2.7.8\modules\zipimport.c*
*lines: 83: strcpy(buf, path);*

*python.tar\python-2.7.8\modules\zipimport.c*
*lines: **437: **strcpy(buf, path);*

*python.tar\python-2.7.8\modules\zipimport.c*
*lines: 704: **strcpy(path, archive);*

*#* if an attacker manages to take control of '*buf, path, archive'*, may
cause a *buffer overflow*, probably if which would be directed toward
*.bss *it's not too dangerous but is a vulnerability.

i hope answer, thanks a lot!,
H?drienR - kaiwaiata.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140813/28cecb49/attachment.html>

From report at bugs.python.org  Wed Aug 13 05:52:43 2014
From: report at bugs.python.org (paul j3)
Date: Wed, 13 Aug 2014 03:52:43 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1407901963.69.0.610288949422.issue12954@psf.upfronthosting.co.za>


paul j3 added the comment:

I added a print line to a 'windows' example from the documentation:

    from multiprocessing import Process
    print 'importing multiprocessing'
    def foo():
        print 'hello'
    p = Process(target=foo)
    p.start()

Run with Python 2.7.0 on linux I get

    importing multiprocessing
    hello

Run with same, but on Windows I get

    importing multiprocessing
    importing multiprocessing
    hello
    importing multiprocessing
    hello
    (recursively)

Now if I put the last part into an if:

    if __name__ == '__main__':
        p = Process(target=foo)
        p.start()

the Windows version no longer recurses, but I still get the double print message.

In linux the child process is created with `os.fork`, which makes a copy of the parent.  The script is only loaded and run once.

In windows, the child is created by issuing a new call to Python with the script.  The script is loaded and run by the child as well as the parent, hence the double print.

So any action that you don't want run when the child is created should be in the 'if __name__' block.

I can picture modifying the log_to_stderr function so that it checks the logger's 'handlers' list for one that already writes to stderr.  It should be easy to add to your own code.  But isn't it easier just to segregate all the 'main' actions from the 'child' ones?

----------

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

From georg at python.org  Wed Aug 13 07:49:01 2014
From: georg at python.org (Georg Brandl)
Date: Wed, 13 Aug 2014 07:49:01 +0200
Subject: [docs] Potential vulnerabilities in python (2.7.8)
In-Reply-To: <CABV5r3yX+gRek-e0+Dy5PyDb3qL_XfUyUokPT7RijARGvbxeYw@mail.gmail.com>
References: <CABV5r3yX+gRek-e0+Dy5PyDb3qL_XfUyUokPT7RijARGvbxeYw@mail.gmail.com>
Message-ID: <53EAFC4D.3040807@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/13/2014 12:55 AM, H?drian R wrote:
> Hi, I'm H?drien Romero Soria - @Kaiwaiata??, I am a 16 year old boy,
> passionate about computer security, since more than 2h searching and
> finding various possible vulnerabilities in source code of python.. I will
> tell you some vulnerabilities now, if they treat me well I will tell the 
> other..
> 
> foolish or important things?
> 
> *#* unsafe use of */strcpy()/*:
> 
> *python.tar\python-2.7.8\modules\zipimport.c* /*lines: 83:* strcpy(buf,
> path);/
> 
> *python.tar\python-2.7.8\modules\zipimport.c* /*lines: */*/437:
> /*/strcpy(buf, path);/
> 
> *python.tar\python-2.7.8\modules\zipimport.c* */lines: 704: /*/strcpy(path,
> archive);/
> 
> *#* if an attacker manages to take control of '*/buf, path, archive/'*,
> may cause a /buffer overflow/, probably if which would be directed toward
> *.bss *it's not too dangerous but is a vulnerability./ /

Hi H?drian,

thanks for your report.  However, this is the wrong mailing list, please report
security considerations to security at python.org.

Thanks,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlPq/E0ACgkQN9GcIYhpnLCAowCfSltzmkWz9qaq5Jc+5tbucGvc
8oYAn12m9fyZRkbnEY4+NXNlZmK7q3aJ
=7Jet
-----END PGP SIGNATURE-----

From georg at python.org  Wed Aug 13 07:50:42 2014
From: georg at python.org (Georg Brandl)
Date: Wed, 13 Aug 2014 07:50:42 +0200
Subject: [docs] surprisingly poor performance of random.sample(set)
In-Reply-To: <9587f2ec-857c-4cf4-8a88-c176f351604e@email.android.com>
References: <9587f2ec-857c-4cf4-8a88-c176f351604e@email.android.com>
Message-ID: <53EAFCB2.5030608@python.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/12/2014 10:46 PM, Alex Frase wrote:
> Hi,
> 
> I noticed recently that running random.sample() on a set is measurably
> slower than doing so on a list or tuple with the same contents. I suspect
> that this is due to the "implementation detail" of converting the
> population argument to a tuple internally; that may not matter much for a
> single call, but when doing i.e. permutation testing, it is not
> unreasonable to call random.sample() on the same population 1000s of times
> in a tight loop. In that scenario, letting it cast the set to a tuple
> inside the loop makes it ~50x slower than casting once outside the loop and
> passing a tuple to random.sample() instead of a set.
> 
> Assuming there is no easy way for random.sample() to work efficiently with
> a set, would it at least be possible to mention this behavior in the 
> documentation? Right now there is no indication that the data structure
> used for the population makes any difference, which may lead people to just
> assume that random.sample() is slow, not realizing they could get a 50x
> boost with a single cast outside their loop.

Hi Alex,

please open an issue on bugs.python.org to discuss this issue with the
maintainers.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlPq/LIACgkQN9GcIYhpnLBoZgCgpyUeE2j5dTR4r4yvSwiZQsNQ
bDUAnR0zMqC1Op/YlP4TotvGfQMCzCqY
=3CY/
-----END PGP SIGNATURE-----

From report at bugs.python.org  Wed Aug 13 09:40:17 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Aug 2014 07:40:17 +0000
Subject: [docs] [issue22014] Improve display of OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1407915617.41.0.218567158487.issue22014@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I'd suggested starting with seeing including of the subsection of the exceptions.txt file looks, and if that's still a bit hard to read, try the explicit table approach.

I'm always wary of having hand maintained mappings in the docs, but this particular one isn't likely to change any time soon.

----------
title: Add summary table for OS exception <-> errno mapping -> Improve display of OS exception <-> errno mapping

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

From report at bugs.python.org  Wed Aug 13 10:29:32 2014
From: report at bugs.python.org (Ari Koivula)
Date: Wed, 13 Aug 2014 08:29:32 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1407918572.51.0.541879820345.issue12954@psf.upfronthosting.co.za>


Ari Koivula added the comment:

Guarding the initialization is indeed correct and works, but log_to_stderr adding the handler multiple times is still annoying. Especially as you probably do want it to be called for child processes (at least on windows) and it might be called during initialization in multiprocessing.forking.prepare (but not on windows).

There is no need to go through the handlers. Just avoid adding the handler again if it has already been added. There actually already is a variable (multiprocessing.util._log_to_stderr) that tracks this, but it isn't used.

----------

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

From report at bugs.python.org  Wed Aug 13 11:46:55 2014
From: report at bugs.python.org (Ari Koivula)
Date: Wed, 13 Aug 2014 09:46:55 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1407923215.19.0.716284196021.issue12954@psf.upfronthosting.co.za>


Ari Koivula added the comment:

Actually, multiprocessing.forking.prepare does call log_to_stderr on windows. While debugging the double handler issue I somehow came to the conclusion that it didn't, but it seems to work just fine now. I must have been doing something weird like creating the processes before setting the log level to cause that.

This issue can probably be closed.

----------

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

From report at bugs.python.org  Wed Aug 13 16:49:51 2014
From: report at bugs.python.org (Jon Poler)
Date: Wed, 13 Aug 2014 14:49:51 +0000
Subject: [docs] [issue22014] Improve display of OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1407941391.23.0.377599656557.issue22014@psf.upfronthosting.co.za>


Jon Poler added the comment:

I'm not entirely sure that I'm interpreting what you are looking for correctly, but here is what the table looks like with literalinclude.

----------
keywords: +patch
Added file: http://bugs.python.org/file36365/OS_exceptions_table.patch

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

From report at bugs.python.org  Wed Aug 13 23:56:35 2014
From: report at bugs.python.org (paul j3)
Date: Wed, 13 Aug 2014 21:56:35 +0000
Subject: [docs] [issue12954] Multiprocessing logging under Windows
In-Reply-To: <1315610809.5.0.0888786272542.issue12954@psf.upfronthosting.co.za>
Message-ID: <1407966995.03.0.988260753188.issue12954@psf.upfronthosting.co.za>


paul j3 added the comment:

I had noticed the `global _log_to_stderr` in `util.log_to_stderr()`, but hadn't taken time to track down where it is used.

Not only is it passed from the 'util' module to the 'forking' one, but it is also passed via a piped pickle from parent to child process.

There's a lot more to simulating 'os.fork' in Windows than I would have guessed.

----------

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

From report at bugs.python.org  Thu Aug 14 17:33:51 2014
From: report at bugs.python.org (Lele Gaifax)
Date: Thu, 14 Aug 2014 15:33:51 +0000
Subject: [docs] [issue22196] namedtuple documentation could/should mention
	the new	Enum type
Message-ID: <1408030431.26.0.145305463203.issue22196@psf.upfronthosting.co.za>


New submission from Lele Gaifax:

The documentation of namedtuple, near the end, talks about implementing enumerated constants and says ?Enumerated constants can be implemented with named tuples, but it is simpler and more efficient to use a simple class declaration?.

Maybe it should mention the recently added Enum type instead/too.

----------
assignee: docs at python
components: Documentation
messages: 225303
nosy: docs at python, lelit
priority: normal
severity: normal
status: open
title: namedtuple documentation could/should mention the new Enum type

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

From report at bugs.python.org  Thu Aug 14 19:28:32 2014
From: report at bugs.python.org (Jim Carroll)
Date: Thu, 14 Aug 2014 17:28:32 +0000
Subject: [docs] [issue22199] Embedding Python documentation error
Message-ID: <1408037312.39.0.0797944753174.issue22199@psf.upfronthosting.co.za>


New submission from Jim Carroll:

On the page https://docs.python.org/2/extending/embedding.html#compiling-and-linking-under-unix-like-systems

The documentation makes the following reference:

"...(use sysconfig.get_makefile_filename() to find its location)..."

But this is incorrect. sysconfig was modified in 3.x (Issue 9877) to use this new name. In 2.x, the function has an underscore prefix:

sysconfig._get_makefile_filename()

----------
assignee: docs at python
components: Documentation
messages: 225307
nosy: docs at python, jamercee
priority: normal
severity: normal
status: open
title: Embedding Python documentation error
versions: Python 2.7

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

From a.grinner at gmail.com  Thu Aug 14 19:36:52 2014
From: a.grinner at gmail.com (Nick)
Date: Thu, 14 Aug 2014 13:36:52 -0400
Subject: [docs] doc bug: PyUnicode_FromStringAndSize missing New Reference
 return tag in Py3
Message-ID: <CAMCN4C=fWy2ikeC4CHMp7b8ZvuR4PQpk2qq8Upfv+4PZ1A=p3w@mail.gmail.com>

Problem for bytes and unicode doc for functions returning new objects
examples are

PyUnicode_FromStringAndSize

and

PyBytes_FromStringAndSize

they are missing the

Return value: New reference.

beneath them, I think.

-Nick

From report at bugs.python.org  Fri Aug 15 08:41:14 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Aug 2014 06:41:14 +0000
Subject: [docs] [issue22196] namedtuple documentation could/should mention
	the new	Enum type
In-Reply-To: <1408030431.26.0.145305463203.issue22196@psf.upfronthosting.co.za>
Message-ID: <1408084874.58.0.471077090566.issue22196@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

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

From report at bugs.python.org  Fri Aug 15 10:41:28 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Aug 2014 08:41:28 +0000
Subject: [docs] [issue22186] Typos in .py files
In-Reply-To: <1407862651.37.0.513368911737.issue22186@psf.upfronthosting.co.za>
Message-ID: <1408092088.52.0.686281759463.issue22186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll apply this shortly.

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

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

From report at bugs.python.org  Sun Aug 17 15:53:29 2014
From: report at bugs.python.org (Jon Poler)
Date: Sun, 17 Aug 2014 13:53:29 +0000
Subject: [docs] [issue22014] Improve display of OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1408283608.84.0.371003450877.issue22014@psf.upfronthosting.co.za>


Jon Poler added the comment:

Here's one way to accomplish this. Please see attached os_exceptions_table_V2.patch.

I wasn't having much luck trying to use ReST, so I took advantage of the fact that the Doc/conf.py file is executed every time sphinx-build is run. conf.py imports and calls the main function from Doc/tools/build_table.py. This script dynamically builds a table by scraping errno values corresponding to an OS exception and inserting them in the appropriate place. Doc/library/exceptions.rst just uses a literalinclude of the new table that gets built to Lib/test/os_exception_hierarchy.txt (the same directory that holds the original exceptions hierarchy).

Error catching is used so that, in the event of an error, a warning will be raised but the sphinx-build command will still succeed.

----------
Added file: http://bugs.python.org/file36392/os_exceptions_table_V2.patch

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

From report at bugs.python.org  Sun Aug 17 22:00:18 2014
From: report at bugs.python.org (evilzero)
Date: Sun, 17 Aug 2014 20:00:18 +0000
Subject: [docs] [issue22153] There is no standard TestCase.runTest
	implementation
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <1408305618.11.0.0557318406829.issue22153@psf.upfronthosting.co.za>


evilzero added the comment:

Updated documentation following suggestion.

----------
keywords: +patch
nosy: +evilzero
Added file: http://bugs.python.org/file36401/myworkdoc.patch

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

From report at bugs.python.org  Sun Aug 17 22:01:10 2014
From: report at bugs.python.org (evilzero)
Date: Sun, 17 Aug 2014 20:01:10 +0000
Subject: [docs] [issue22153] There is no standard TestCase.runTest
	implementation
In-Reply-To: <1407301202.17.0.719208246986.issue22153@psf.upfronthosting.co.za>
Message-ID: <1408305670.4.0.473599346043.issue22153@psf.upfronthosting.co.za>


Changes by evilzero <losvampires at yahoo.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sun Aug 17 23:05:26 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 17 Aug 2014 21:05:26 +0000
Subject: [docs] [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1408309526.07.0.110756234795.issue10583@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

Is there anything to be done here as Sphinx is a third party tool and the root cause is already fixed?

----------

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

From bjd000 at tpg.com.au  Thu Aug 14 02:16:12 2014
From: bjd000 at tpg.com.au (Barry Davenport)
Date: Thu, 14 Aug 2014 08:16:12 +0800
Subject: [docs] Minor PDF doc typo?
Message-ID: <53EBFFCC.4040805@tpg.com.au>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140814/2e525d6c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dggihjdf.png
Type: image/png
Size: 26212 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20140814/2e525d6c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ciejjeeb.png
Type: image/png
Size: 3087 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20140814/2e525d6c/attachment-0003.png>

From report at bugs.python.org  Mon Aug 18 12:57:24 2014
From: report at bugs.python.org (Alexander Patrakov)
Date: Mon, 18 Aug 2014 10:57:24 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
Message-ID: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>


New submission from Alexander Patrakov:

I could not access http://docs.python.org/ from work today. Upon investigation, it appears that the ISP has blocked all sites on the IP address 185.31.17.175, because of the court order unrelated to docs.python.org. Many other ISPs in Russia also don't know any methods of site blocking except by IP address.

Even if the bad site removes the offending materials, the situation is doomed to repeat itself in the future.

To avoid this, please obtain an IPv4 or IPv6 address for docs.python.org that is not shared with any site not controlled by PSF.

----------
assignee: docs at python
components: Documentation
messages: 225487
nosy: Alexander.Patrakov, docs at python
priority: normal
severity: normal
status: open
title: docs.python.org is prone to political blocking in Russia
type: behavior

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

From report at bugs.python.org  Mon Aug 18 13:58:12 2014
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 18 Aug 2014 11:58:12 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408363092.84.0.499935457661.issue22224@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Dmitry Chestnykh has pointed me to https://antizapret.info/site.php?id=5903

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Mon Aug 18 14:48:51 2014
From: report at bugs.python.org (Donald Stufft)
Date: Mon, 18 Aug 2014 12:48:51 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408366131.49.0.671344910341.issue22224@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Just a FYI, I've let Fastly know about this.

----------
nosy: +dstufft

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

From report at bugs.python.org  Mon Aug 18 15:01:34 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 18 Aug 2014 13:01:34 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1408366894.7.0.900454989136.issue12067@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Aug 18 15:43:08 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Aug 2014 13:43:08 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408369388.04.0.478878144909.issue22224@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Not much more we can do from here.

----------
nosy: +georg.brandl
resolution:  -> third party
status: open -> closed

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

From report at bugs.python.org  Mon Aug 18 16:56:16 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Aug 2014 14:56:16 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408373776.48.0.0214847751934.issue22224@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

It looks like the IP address is being used by some viruses/trojans:

https://www.virustotal.com/en/ip-address/185.31.17.175/information/

It may help using e.g. b.global-ssl.fastly.net as CNAME for docs.python.org (e.g. by adding it to the /etc/hosts).

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

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

From report at bugs.python.org  Mon Aug 18 21:50:12 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 18 Aug 2014 19:50:12 +0000
Subject: [docs] [issue7951] Should str.format allow negative indexes when
	used for	__getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1408391411.99.0.162356922904.issue7951@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

msg216038 suggests three options for the doc patch, does anybody have any preference or a better alternative?

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

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

From report at bugs.python.org  Tue Aug 19 12:27:02 2014
From: report at bugs.python.org (Keith Hughitt)
Date: Tue, 19 Aug 2014 10:27:02 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1408444022.05.0.326868330025.issue15125@psf.upfronthosting.co.za>


Keith Hughitt added the comment:

Any progress on this issue? Still persists in Python 3.4.1.

----------
nosy: +khughitt

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

From gert at fenlogic.com  Mon Aug 18 14:47:18 2014
From: gert at fenlogic.com (Gert)
Date: Mon, 18 Aug 2014 13:47:18 +0100
Subject: [docs] flags is not a parameter in open
Message-ID: <53F1F5D6.1050607@fenlogic.com>

https://docs.python.org/3.0/library/os.html.
says this:
The following constants are options for the /flags/ parameter to the 
open() <https://docs.python.org/3.0/library/functions.html#open> function.
...
os.O_NDELAY

When I follow the link to the open function it does NOT have a flags 
parameter:
open(/file/[, /mode='r'/[, /buffering=None/[, /encoding=None/[, 
/errors=None/[, /newline=None/[, /closefd=True/]]]]]])? 
<https://docs.python.org/3.0/library/functions.html#open>


I am trying to solve this:
My C-code uses: fd = open("/dev/ttyAMA0",O_RDW|O_NDELAY)

the equivalent code in python3 (Raspberry-Pi)  gives an error:
fd = open("/dev/ttyAMA0",os.O_RDW|os.O_NDELAY)
open() second argument must be str, not int


-- Gert

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140818/108b8355/attachment.html>

From zachary.ware+pydocs at gmail.com  Wed Aug 20 08:13:47 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 20 Aug 2014 01:13:47 -0500
Subject: [docs] flags is not a parameter in open
In-Reply-To: <53F1F5D6.1050607@fenlogic.com>
References: <53F1F5D6.1050607@fenlogic.com>
Message-ID: <CAKJDb-NaY1bgOjD7-_naDbk4LFV7V17jovRdV1M1MQifA5aB4w@mail.gmail.com>

Hi Gert,

On Mon, Aug 18, 2014 at 7:47 AM, Gert <gert at fenlogic.com> wrote:
> https://docs.python.org/3.0/library/os.html.

Version 3.0 is almost certainly not the version of Python you are
using (and if it is, upgrade now!  3.0 has been unsupported for about
5 years now, 3.4 is current); you would be better served to use the
version of the documentation that matches your version of Python.  You
can either replace the '3.0' in that address with the correct version
number (probably 3.3 or 3.4), or just remove the '.0' to get the
latest Python3 documentation (currently 3.4).

> says this:
> The following constants are options for the flags parameter to the open()
> function.
> ...
> os.O_NDELAY
>
> When I follow the link to the open function it does NOT have a flags
> parameter:
> open(file[, mode='r'[, buffering=None[, encoding=None[, errors=None[,
> newline=None[, closefd=True]]]]]])?

This was a bug in the documentation, the link should have gone to
'os.open' rather than the 'open' built-in function.  It has been fixed
in more recent versions.

Hope this helps,
-- 
Zach

From report at bugs.python.org  Wed Aug 20 09:17:20 2014
From: report at bugs.python.org (Alexander Patrakov)
Date: Wed, 20 Aug 2014 07:17:20 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408519040.65.0.554928348199.issue22224@psf.upfronthosting.co.za>


Alexander Patrakov added the comment:

The site is now accessible. But this case is going to repeat itself.

----------

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

From report at bugs.python.org  Wed Aug 20 09:28:11 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Aug 2014 07:28:11 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408519690.97.0.602583681158.issue22224@psf.upfronthosting.co.za>


Georg Brandl added the comment:

We know, but this will happen to any sites that have content hosted by a CDN such as Fastly.

In this specific case, you can download the docs or build them yourself for offline usage.  Our Mercurial server hg.python.org is (obviously :) not hosted on a CDN, so this scenario can't happen there.

----------

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

From report at bugs.python.org  Wed Aug 20 09:39:57 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 20 Aug 2014 07:39:57 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408520397.12.0.575813483474.issue22224@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

See also #21072.

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

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

From report at bugs.python.org  Wed Aug 20 10:07:49 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Aug 2014 08:07:49 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408519690.97.0.602583681158.issue22224@psf.upfronthosting.co.za>
Message-ID: <53F45750.6030503@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.08.2014 09:28, Georg Brandl wrote:
> 
> We know, but this will happen to any sites that have content hosted by a CDN such as Fastly.

I think we should have additional fallback domains setup
that go to frontend.python.org and then also get mapped to
the right backend server in order to be able to easily
work around this.

This would also help with some other issues such as Fastly
cache invalidation not working properly (which most likely is due
to the website not providing the right information for this work
rather than Fastly's fault).

----------

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

From report at bugs.python.org  Wed Aug 20 16:09:13 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Aug 2014 14:09:13 +0000
Subject: [docs] [issue22014] Improve display of OS exception <-> errno
	mapping
In-Reply-To: <1405839624.34.0.825236607584.issue22014@psf.upfronthosting.co.za>
Message-ID: <1408543753.92.0.171559923468.issue22014@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon

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

From report at bugs.python.org  Wed Aug 20 16:35:50 2014
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 20 Aug 2014 14:35:50 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408545350.76.0.851294108771.issue22224@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Wed Aug 20 16:38:33 2014
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 20 Aug 2014 14:38:33 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408545513.0.0.118375055299.issue22224@psf.upfronthosting.co.za>


Donald Stufft added the comment:

> I think we should have additional fallback domains setup
> that go to frontend.python.org and then also get mapped to
> the right backend server in order to be able to easily
> work around this.

I'm not sure it's worth it tbh. It's certainly going to be error prone to store
the frontend configuration in two locations (Fastly and front.python.org).
There might be additional things we can do on the Fastly side of things, I know
the have the ability to have dedicated IP addresses in all their DCs (typically
this is in use for providing EV SSL certs and the like). We don't have that
and generally this costs like $1500/month for the SSL cert stuff. I can ping
them about it and see if they have any other ideas.

> This would also help with some other issues such as Fastly
> cache invalidation not working properly (which most likely is due
> to the website not providing the right information for this work
> rather than Fastly's fault).

Right, it's basically that there is no cache invalidation as far as I know.
Actually invalidating the cache pretty much always works in my experience.

----------

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

From report at bugs.python.org  Wed Aug 20 18:53:50 2014
From: report at bugs.python.org (Wilfred Hughes)
Date: Wed, 20 Aug 2014 16:53:50 +0000
Subject: [docs] [issue22237] sorted() docs should state that the sort is
	stable
Message-ID: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>


New submission from Wilfred Hughes:

According to https://wiki.python.org/moin/HowTo/Sorting/#Sort_Stability_and_Complex_Sorts and Alex Martelli: http://stackoverflow.com/q/1915376/509706, Python's sorted() is stable. It would be great to update the docs for sorted() to state this.

----------
assignee: docs at python
components: Documentation
messages: 225574
nosy: Wilfred.Hughes, docs at python
priority: normal
severity: normal
status: open
title: sorted() docs should state that the sort is stable
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed Aug 20 19:14:16 2014
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 20 Aug 2014 17:14:16 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408554856.29.0.847159168843.issue22224@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I've heard back from Fastly!

Specific to this particular incident, they've identified a few places where their own internal procedures fell short and they've rectified them. Specifically:

1. Their ticketing software saw the notifications from the Russian government/ISP as spam, most likely due to the Cryllic character set. This lead them to miss seeing the reports initially until later. They've resolved this by whitelisting those domains.
2. They notified the customers and then told the Russian government/ISP that the owner of the content as been notified. Instead they are going to ensure that the content in the future.

In the long term they are evaluating their own policies for how they host customer sites which allow user uploaded content (since those types of sites are the most likely to have these kinds of issues) and determining if it makes sense for them to require dedicated IP addresses for those customers.

For now I think Fastly has sufficiently handled the issue to not require some sort of backup system to need to be put in place. They are going to let me know how they are going to handle it long term and what, if any changes, we can make in our use of their service to help isolate from those kinds of issues.

----------

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

From report at bugs.python.org  Wed Aug 20 19:56:05 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Aug 2014 17:56:05 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408557365.41.0.186382488332.issue22224@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Very nice, thanks for the update.

----------

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

From report at bugs.python.org  Wed Aug 20 20:19:03 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Aug 2014 18:19:03 +0000
Subject: [docs] [issue22237] sorted() docs should state that the sort is
	stable
In-Reply-To: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>
Message-ID: <1408558743.6.0.305609585714.issue22237@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I agree: The docs for list.sort() do guarantee the stability, so sorted() should have the same indication.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Wed Aug 20 20:44:04 2014
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Aug 2014 18:44:04 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408554856.29.0.847159168843.issue22224@psf.upfronthosting.co.za>
Message-ID: <53F4EC70.3090109@egenix.com>


Marc-Andre Lemburg added the comment:

On 20.08.2014 19:14, Donald Stufft wrote:
> 
> For now I think Fastly has sufficiently handled the issue to not require some sort of backup system to need to be put in place. They are going to let me know how they are going to handle it long term and what, if any changes, we can make in our use of their service to help isolate from those kinds of issues.

Sounds good.

----------

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

From report at bugs.python.org  Wed Aug 20 21:55:04 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Aug 2014 19:55:04 +0000
Subject: [docs] [issue22237] sorted() docs should state that the sort is
	stable
In-Reply-To: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>
Message-ID: <1408564504.96.0.0502564060114.issue22237@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/issue22237>
_______________________________________

From report at bugs.python.org  Thu Aug 21 02:41:53 2014
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 21 Aug 2014 00:41:53 +0000
Subject: [docs] [issue22224] docs.python.org is prone to political blocking
	in Russia
In-Reply-To: <1408359444.49.0.206425741793.issue22224@psf.upfronthosting.co.za>
Message-ID: <1408581713.5.0.629997058147.issue22224@psf.upfronthosting.co.za>


Donald Stufft added the comment:

I just heard back from Fastly again. They are going to donate a dedicated IP
address setup on top of the rest of the stuff they are already donating to us.
It's not setup yet and the exact details are not sorted out yet. This should
more or less eliminate this problem (unless of course one of our own services
get banned somewhere).

I believe the sticker cost of this is $1500/month (Normally this is used for
custom SSL certificates, not sure if it'd be cheaper w/o that) on top of the
~$12k/month they already donate to the PSF. So that's incredibly awesome IMO
and a big thanks to them!

----------

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

From gert at fenlogic.com  Wed Aug 20 09:50:04 2014
From: gert at fenlogic.com (Gert)
Date: Wed, 20 Aug 2014 08:50:04 +0100
Subject: [docs] flags is not a parameter in open
In-Reply-To: <CAKJDb-NaY1bgOjD7-_naDbk4LFV7V17jovRdV1M1MQifA5aB4w@mail.gmail.com>
References: <53F1F5D6.1050607@fenlogic.com>
 <CAKJDb-NaY1bgOjD7-_naDbk4LFV7V17jovRdV1M1MQifA5aB4w@mail.gmail.com>
Message-ID: <53F4532C.6030402@fenlogic.com>

Thank you,
I found the documentation.
My program, is now use os.open and os.write and works.

-- Gert van Loo


On 20/08/2014 07:13, Zachary Ware wrote:
> Hi Gert,
>
> On Mon, Aug 18, 2014 at 7:47 AM, Gert <gert at fenlogic.com> wrote:
>> https://docs.python.org/3.0/library/os.html.
> Version 3.0 is almost certainly not the version of Python you are
> using (and if it is, upgrade now!  3.0 has been unsupported for about
> 5 years now, 3.4 is current); you would be better served to use the
> version of the documentation that matches your version of Python.  You
> can either replace the '3.0' in that address with the correct version
> number (probably 3.3 or 3.4), or just remove the '.0' to get the
> latest Python3 documentation (currently 3.4).
>
>> says this:
>> The following constants are options for the flags parameter to the open()
>> function.
>> ...
>> os.O_NDELAY
>>
>> When I follow the link to the open function it does NOT have a flags
>> parameter:
>> open(file[, mode='r'[, buffering=None[, encoding=None[, errors=None[,
>> newline=None[, closefd=True]]]]]])?
> This was a bug in the documentation, the link should have gone to
> 'os.open' rather than the 'open' built-in function.  It has been fixed
> in more recent versions.
>
> Hope this helps,


From report at bugs.python.org  Thu Aug 21 16:55:27 2014
From: report at bugs.python.org (Jon Poler)
Date: Thu, 21 Aug 2014 14:55:27 +0000
Subject: [docs] [issue22242] Doc fix in the Import section in language
	reference.
Message-ID: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>


New submission from Jon Poler:

It looks like there might be a contradiction in the documentation of import in the language reference. In the loading subsection https://docs.python.org/dev/reference/import.html#loading, first bulleted list of the section, it specifies that if a loader fails, it must remove only the failing module from sys.modules, while other side-effect imports by loader will stay in sys.modules.

In the next subsection https://docs.python.org/dev/reference/import.html#loaders, second bulleted list (last bullet), the phrasing is confusing, and possibly contradictory. I believe that it meant to reiterate what was said above (see my previous paragraph).

Attached is a potential patch, but if anyone finds that I am interpreting this wrong, I'll make adjustments accordingly.

----------
assignee: docs at python
components: Documentation
files: import_doc_fix.patch
keywords: patch
messages: 225610
nosy: docs at python, jon.poler
priority: normal
severity: normal
status: open
title: Doc fix in the Import section in language reference.
type: enhancement
versions: Python 3.5
Added file: http://bugs.python.org/file36427/import_doc_fix.patch

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

From report at bugs.python.org  Thu Aug 21 17:55:55 2014
From: report at bugs.python.org (Michael Williamson)
Date: Thu, 21 Aug 2014 15:55:55 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
Message-ID: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>


New submission from Michael Williamson:

In the docs for the try statement [1], part of the grammar is:

try1_stmt ::=  "try" ":" suite
               ("except" [expression ["as" target]] ":" suite)+
               ["else" ":" suite]
               ["finally" ":" suite]

The `target` rule allows any assignable expression (identifier, attributes, etc.). However, CPython appears to only allow identifiers as a target. The abstract grammar in the ast module [2] appears to confirm this.

[1] https://docs.python.org/3.4/reference/compound_stmts.html#the-try-statement
[2] https://docs.python.org/3.4/library/ast.html#abstract-grammar

----------
assignee: docs at python
components: Documentation
messages: 225611
nosy: docs at python, mwilliamson
priority: normal
severity: normal
status: open
title: Documentation on try statement incorrectly implies target of except clause can be any assignable expression
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Aug 21 22:51:56 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Thu, 21 Aug 2014 20:51:56 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408654316.79.0.51876391738.issue22243@psf.upfronthosting.co.za>


Jayanth Koushik added the comment:

Yes. Seems to be a documentation error. The full grammar specification [1] uses 'NAME' instead of 'target'.

[1]: https://docs.python.org/3/reference/grammar.html

----------
nosy: +jayanthkoushik
type:  -> enhancement

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

From report at bugs.python.org  Thu Aug 21 23:18:37 2014
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Aug 2014 21:18:37 +0000
Subject: [docs] [issue22242] Doc fix in the Import section in language
	reference.
In-Reply-To: <1408632927.48.0.574934380183.issue22242@psf.upfronthosting.co.za>
Message-ID: <1408655917.67.0.473716587877.issue22242@psf.upfronthosting.co.za>


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


----------
nosy: +eric.snow

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

From report at bugs.python.org  Fri Aug 22 02:54:17 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 22 Aug 2014 00:54:17 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1408668856.99.0.186226863278.issue15125@psf.upfronthosting.co.za>


paul j3 added the comment:

It still needs a documentation patch.  

And if the documentation was clearer, would sfllaw's patch still be needed?

----------

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

From report at bugs.python.org  Fri Aug 22 03:06:11 2014
From: report at bugs.python.org (paul j3)
Date: Fri, 22 Aug 2014 01:06:11 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408669571.08.0.502633044601.issue13540@psf.upfronthosting.co.za>


paul j3 added the comment:

The formatting of the descriptor line for this class is not consistent with the classes for this module.

It lacks 'class'.

It is all bold

In contrast 

    class argparse.ArgumentParser(prog=None, ...

uses bold for only the name.

----------

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

From report at bugs.python.org  Fri Aug 22 03:20:55 2014
From: report at bugs.python.org (Martin Panter)
Date: Fri, 22 Aug 2014 01:20:55 +0000
Subject: [docs] [issue22237] sorted() docs should state that the sort is
	stable
In-Reply-To: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>
Message-ID: <1408670455.44.0.0361619074912.issue22237@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like a fork of that how-to is actually part of the documentation: <https://docs.python.org/release/3.4.0/howto/sorting.html>. Perhaps the two should be linked better.

If ?sorted? is indeed meant to be stable, that makes the docstring for the ?heapsort? function <https://docs.python.org/release/3.4.0/library/heapq.html#basic-examples> invalid. That function is not stable, for example: heapsort((0, 0, False, 0)) -> [0, False, 0, 0].

Also, the how-to implicitly guarantees that only less-than (__lt__) is required for comparison. This is already documented for ?list.sort?, but it might be good to add that guarantee to the ?sorted? reference. Maybe also clarify if it applies (or not) to other sorting and comparison routines (e.g. heapq, bisect, min, max), though maybe that is straying off scope for this bug.

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

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

From report at bugs.python.org  Fri Aug 22 08:05:46 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Aug 2014 06:05:46 +0000
Subject: [docs] [issue22237] sorted() docs should state that the sort is
	stable
In-Reply-To: <1408553630.26.0.335574291367.issue22237@psf.upfronthosting.co.za>
Message-ID: <1408687546.53.0.754859297327.issue22237@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'll update the docs for sorted().

----------
priority: normal -> low
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 22 08:29:44 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 22 Aug 2014 06:29:44 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408688984.4.0.227569496427.issue22243@psf.upfronthosting.co.za>


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


----------
keywords: +easy
versions: +Python 2.7

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

From report at bugs.python.org  Fri Aug 22 09:38:56 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Fri, 22 Aug 2014 07:38:56 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408693136.04.0.150012492257.issue22243@psf.upfronthosting.co.za>


Jayanth Koushik added the comment:

The whole page on compound statements seems to be rife with inconsistencies.

----------

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

From report at bugs.python.org  Fri Aug 22 13:43:28 2014
From: report at bugs.python.org (Alexander Patrakov)
Date: Fri, 22 Aug 2014 11:43:28 +0000
Subject: [docs] [issue22249] Possibly incorrect example is given
	for	socket.getaddrinfo()
Message-ID: <1408707808.63.0.0809888327352.issue22249@psf.upfronthosting.co.za>


New submission from Alexander Patrakov:

See the example at https://docs.python.org/2/library/socket.html#socket.getaddrinfo

>>> socket.getaddrinfo("www.python.org", 80, 0, 0, socket.SOL_TCP)

As I am primarily a C programmer, it is quite surprising for me to see a SOL_* being passed into the proto argument. I thought that SOL_* is only for setsockopt(), and IPPROTO_* would be suitable. Yes, for TCP and UDP the SOL_* and IPPROTO_* constants are the same, but see e.g. http://msdn.microsoft.com/en-us/library/windows/desktop/ms737530%28v=vs.85%29.aspx which specifically points out that IPPROTO_* constants as acceptable values.

----------
assignee: docs at python
components: Documentation
messages: 225659
nosy: Alexander.Patrakov, docs at python
priority: normal
severity: normal
status: open
title: Possibly incorrect example is given for socket.getaddrinfo()
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Fri Aug 22 22:59:43 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2014 20:59:43 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408741183.9.0.337297730016.issue22243@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think 'target' can just be replaced by 'identifier'.
Using 'expression' (or 'expr' in the ast doc) for what should be 'exceptions: identifier' or paranthesized tuple of identifiers;, is also too broad. However, that must be enforced in the compiler rather than the parser, and compiler restrictions are in the text, not the grammar.

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

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

From report at bugs.python.org  Fri Aug 22 23:10:44 2014
From: report at bugs.python.org (Michael Williamson)
Date: Fri, 22 Aug 2014 21:10:44 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408741844.89.0.409626683629.issue22243@psf.upfronthosting.co.za>


Michael Williamson added the comment:

> Using 'expression' (or 'expr' in the ast doc) for what should be 'exceptions: identifier' or paranthesized tuple of identifiers;, is also too broad. However, that must be enforced in the compiler rather than the parser, and compiler restrictions are in the text, not the grammar.

I would expect any expression to be valid so long as it evaluates at runtime to an exception type (or tuple of exception types), so the use of expression seems correct to me. In other words, the following is valid Python (but would not be allowed if I've understood your statement correctly):

    def f():
        try:
            "".blah
        except some_error():
            print("caught")
            
    def some_error():
        return AttributeError

    f()

----------

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

From report at bugs.python.org  Sat Aug 23 00:54:26 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Aug 2014 22:54:26 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408748066.08.0.948352496741.issue22243@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You are right, only the result, and not the form of 'expression' is constrained. I will let Jayanth propose other errors.

----------

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

From report at bugs.python.org  Sat Aug 23 07:30:43 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Sat, 23 Aug 2014 05:30:43 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408771843.7.0.945861045826.issue22243@psf.upfronthosting.co.za>


Jayanth Koushik added the comment:

The page on compound statements defines compound statements as:

compound_stmt ::=  if_stmt
                   | while_stmt
                   | for_stmt
                   | try_stmt
                   | with_stmt
                   | funcdef
                   | classdef

The full grammar specification on the other hand says:

compound_stmt: if_stmt | while_stmt | for_stmt | try_stmt | with_stmt | funcdef | classdef | decorated

This accordingly leads to different definitions of funcdef and classdef. This is not necessarily 'incorrect', but for the sake of clarity, it might be better if both pages followed the same conventions.

----------

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

From report at bugs.python.org  Sat Aug 23 15:03:01 2014
From: report at bugs.python.org (Keith Hughitt)
Date: Sat, 23 Aug 2014 13:03:01 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1408798981.41.0.300454325537.issue15125@psf.upfronthosting.co.za>


Keith Hughitt added the comment:

Although it would be nice if the behavior were normalized between positional and optional args, it seems like doc patch would be the most straight-forward at this point. The down-side is that I suspect many people will assume the behavior for optional args, have it fail, and then consults the docs to see what happened.

I would suggest making the note pretty obvious or early on in the docs for argparse.

----------

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

From report at bugs.python.org  Sat Aug 23 19:36:36 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Aug 2014 17:36:36 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408815396.07.0.666183065883.issue22243@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The grammar presented in the doc is intentionally slightly simplified from the one actually used by the LL(1) parser.  The parser has to know what type of statement it is parsing after the first token or so, so it needs a separate production (concept) for statements that start with '@'.  Human readers are more capable and can look backwards from 'def' and 'class'.

A separate section on 'Decorated statements' would be possible, but not necessarily better. A section of 'Decorators' (without calling them 'statements') would be slightly different and also possible.  Discussion would have to start on Python ideas and any action a separate issue.

----------

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

From report at bugs.python.org  Sat Aug 23 19:46:00 2014
From: report at bugs.python.org (Jayanth Koushik)
Date: Sat, 23 Aug 2014 17:46:00 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408815960.51.0.443418998199.issue22243@psf.upfronthosting.co.za>


Jayanth Koushik added the comment:

Oh ok. That makes sense.

----------

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

From report at bugs.python.org  Sat Aug 23 20:41:56 2014
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 23 Aug 2014 18:41:56 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408819315.94.0.472307097316.issue13540@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I have no idea why that would be. I used the same syntax for the Action class as ArgumentParser. From the latest tip:

.. class:: ArgumentParser(prog=None, usage=None, description=None, \
                          epilog=None, parents=[], \
                          ...

.. class:: Action(option_strings, dest, nargs=None, const=None, default=None,
                  type=None, choices=None, required=False, help=None,
                  metavar=None)


I don't know what would cause those to render differently. Perhaps you're suggesting a difference elsewhere. In any case, I don't see any action I can take to address your concern.

----------

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

From report at bugs.python.org  Sat Aug 23 21:17:19 2014
From: report at bugs.python.org (paul j3)
Date: Sat, 23 Aug 2014 19:17:19 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408821439.88.0.659963809554.issue13540@psf.upfronthosting.co.za>


paul j3 added the comment:

Maybe the problem is with the latest documentation build, not your patch.

----------

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

From report at bugs.python.org  Sun Aug 24 01:12:15 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Aug 2014 23:12:15 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1408835535.23.0.736048665379.issue22232@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Glossary fixed. I changed the components to Documention as you will handle email elsewhere.

For library references: The key sentence currently used in all entries is "This method uses the universal newlines approach to splitting lines.", where *universal newlines* is linked to the glossary.

2.x has one entry for str and unicode. I propose to add "Unicode.splitlines also splits on '\x0b' ('\v'), '\x0c' ('\f'), '\x1c', '\x1d', '\x1e', '\x85', '\u2028', and '\u2029'." 

3.x bytes entry is good as is.

3.x str entry is wrong. Replace with "This method splits on universal newlines and also on '\x0b' ('\v'), '\x0c' ('\f'), '\x1c', '\x1d', '\x1e', '\x85', '\u2028', and '\u2029'." 

The docstrings now contain about the same as the docs, minus the key line above.
"   Return a list of the lines in S, breaking at line boundaries.
    Line breaks are not included in the resulting list unless keepends
    is given and true."

Between the sentences, I propose to add:
"Boundaries are indicated by 'universal newlines' ('\x0a' ('\n'), '\x0d' ('\r'), and '\x0d\x0a' ('\r\n'))." for bytes,
 with the addition of "and '\x0b' ('\v'), '\x0c' ('\f'), '\x1c', '\x1d', '\x1e', '\x85', '\u2028', and '\u2029'" for unicode.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib), Unicode, email
nosy: +docs at python
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Sun Aug 24 01:30:53 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 23 Aug 2014 23:30:53 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <3hgbSY1gwYz7Ljb@mail.python.org>


Roundup Robot added the comment:

New changeset 5496bf8972b6 by Terry Jan Reedy in branch '2.7':
Issue #22243: fix except grammar in reference.
http://hg.python.org/cpython/rev/5496bf8972b6

New changeset a249f1f879be by Terry Jan Reedy in branch '3.4':
Issue #22243: fix except grammar in reference.
http://hg.python.org/cpython/rev/a249f1f879be

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

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

From report at bugs.python.org  Sun Aug 24 01:31:28 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Aug 2014 23:31:28 +0000
Subject: [docs] [issue22243] Documentation on try statement incorrectly
	implies	target of except clause can be any assignable expression
In-Reply-To: <1408636555.03.0.716837203109.issue22243@psf.upfronthosting.co.za>
Message-ID: <1408836688.27.0.603448175863.issue22243@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Aug 24 03:33:01 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 24 Aug 2014 01:33:01 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408843981.31.0.148607337202.issue13540@psf.upfronthosting.co.za>


paul j3 added the comment:

You need line continuation characters '\'


.. class:: Action(option_strings, dest, nargs=None, const=None, default=None, \
                  type=None, choices=None, required=False, help=None, \
                  metavar=None)

----------

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

From report at bugs.python.org  Sun Aug 24 03:40:33 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 24 Aug 2014 01:40:33 +0000
Subject: [docs] [issue22261] Concurrent Build when using MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408844433.83.0.299457740973.issue22261@psf.upfronthosting.co.za>


Zachary Ware added the comment:

On the other hand, I did fail to document that little gem.  It should be added to the section about build.bat in PCbuild/readme.txt.

----------
assignee:  -> docs at python
components: +Documentation -Build
nosy: +docs at python
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Sun Aug 24 03:41:48 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 24 Aug 2014 01:41:48 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408844508.71.0.759973422867.issue22261@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +Windows
title: Concurrent Build when using MsBuild -> Document how to use Concurrent Build when using MsBuild

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

From report at bugs.python.org  Sun Aug 24 03:42:35 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 01:42:35 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408844555.87.0.608415231425.issue22261@psf.upfronthosting.co.za>


sbspider added the comment:

Would you mind letting me do the honors? First time contributing and all that :P

----------

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

From report at bugs.python.org  Sun Aug 24 03:45:51 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 24 Aug 2014 01:45:51 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408844555.87.0.608415231425.issue22261@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-OSbd0GPvQ539DK5gaRR30tjG_kRTgF3XiygruRiM4aBg@mail.gmail.com>


Zachary Ware added the comment:

Of course, I'll be happy to review and commit for you.

----------

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

From report at bugs.python.org  Sun Aug 24 03:52:02 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 01:52:02 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408845122.62.0.881577528388.issue22261@psf.upfronthosting.co.za>


Changes by sbspider <rajshorya at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file36449/readme.patch

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

From report at bugs.python.org  Sun Aug 24 04:23:02 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 24 Aug 2014 02:23:02 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <3hggH96lLkz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 4a6b71d8575e by Terry Jan Reedy in branch '3.4':
Issue #13540: add missing markup.
http://hg.python.org/cpython/rev/4a6b71d8575e

----------

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

From report at bugs.python.org  Sun Aug 24 04:25:03 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Aug 2014 02:25:03 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408847103.22.0.123005678191.issue13540@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I don't understand why, but the change worked, and is consistent with similar constructs in the same file. Pushed.

Jason -- security-fix-only versions do not get doc patches. They are released as source only.

----------

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

From report at bugs.python.org  Sun Aug 24 04:26:44 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 02:26:44 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408847204.02.0.0765760336284.issue22261@psf.upfronthosting.co.za>


sbspider added the comment:

I uploaded the file, just checking if it hasn't come through.

----------

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

From report at bugs.python.org  Sun Aug 24 05:57:30 2014
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 24 Aug 2014 03:57:30 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408847204.02.0.0765760336284.issue22261@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MZW9-F0LaXZRsMcEC00G=ob7JHEYAjst_Cg+tLNNhB+A@mail.gmail.com>


Zachary Ware added the comment:

Patch came through fine; you've done perfectly process-wise.  I'll
post a review of the patch soon.

----------

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

From report at bugs.python.org  Sun Aug 24 07:14:28 2014
From: report at bugs.python.org (paul j3)
Date: Sun, 24 Aug 2014 05:14:28 +0000
Subject: [docs] [issue13540] Document the Action API in argparse
In-Reply-To: <1323183395.55.0.489132691311.issue13540@psf.upfronthosting.co.za>
Message-ID: <1408857268.42.0.0231257961125.issue13540@psf.upfronthosting.co.za>


paul j3 added the comment:

While we are talking the Action class, the documentation isn't clear that the 'add_argument' method returns an Action object, specifically one the subclasses.  More than once, when answering Stackoverflow questions I've recommended assigning this object to a variable for use later in the script. 

    a = parser.add_argument(...)
    ...
    print a.dest
    a.help = 'change the help'
    a.required = True
    ...

The doc mentions that 'add_subparsers' 'returns a special action object.'

In sum, I think the documentation needs a sentence or two that describe what add_argument returns.  I'm less sure whether it should include an example of using that return.

----------

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

From report at bugs.python.org  Sun Aug 24 10:38:17 2014
From: report at bugs.python.org (sbspider)
Date: Sun, 24 Aug 2014 08:38:17 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1408869497.1.0.785186362769.issue22261@psf.upfronthosting.co.za>


sbspider added the comment:

Ok, thank you. Just wanted to confirm this, as I plan to help out on the code/documentation as well (and hence want to understand the process beforehand). I look forward to working on Python in the future.

----------

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

From report at bugs.python.org  Mon Aug 25 01:33:46 2014
From: report at bugs.python.org (Jonas Jelten)
Date: Sun, 24 Aug 2014 23:33:46 +0000
Subject: [docs] [issue22270] cache version selection for documentation
Message-ID: <1408923226.6.0.0114591743234.issue22270@psf.upfronthosting.co.za>


New submission from Jonas Jelten:

The Python version selection for the documentation should be cached.
It's very annoying having to select the preferred version each time one follows a link, e.g. search result, irc post, etc.

I'd like to see caching the preferred version in a cookie and automatically switching to this python version when opening doc pages.

----------
assignee: docs at python
components: Documentation
messages: 225847
nosy: docs at python, thejj
priority: normal
severity: normal
status: open
title: cache version selection for documentation
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Aug 25 01:37:38 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2014 23:37:38 +0000
Subject: [docs] [issue22270] cache version selection for documentation
In-Reply-To: <1408923226.6.0.0114591743234.issue22270@psf.upfronthosting.co.za>
Message-ID: <1408923458.08.0.542202959864.issue22270@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't think that makes much sense. People often link to a particular version of the documentation and making the version "sticky" to a particular user could be confusing.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Aug 25 01:39:51 2014
From: report at bugs.python.org (Jonas Jelten)
Date: Sun, 24 Aug 2014 23:39:51 +0000
Subject: [docs] [issue22270] cache version selection for documentation
In-Reply-To: <1408923226.6.0.0114591743234.issue22270@psf.upfronthosting.co.za>
Message-ID: <1408923591.1.0.359611120069.issue22270@psf.upfronthosting.co.za>


Jonas Jelten added the comment:

it should rather be a opt-in feature. and when the redirection triggered, one should be able do click (you know it from wikipedia) back to page where one was redireced from.

----------

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

From report at bugs.python.org  Mon Aug 25 01:42:25 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Aug 2014 23:42:25 +0000
Subject: [docs] [issue22270] cache version selection for documentation
In-Reply-To: <1408923591.1.0.359611120069.issue22270@psf.upfronthosting.co.za>
Message-ID: <1408923742.412129.156261865.5AC04069@webmail.messagingengine.com>


Benjamin Peterson added the comment:

On Sun, Aug 24, 2014, at 16:39, Jonas Jelten wrote:
> 
> Jonas Jelten added the comment:
> 
> it should rather be a opt-in feature. and when the redirection triggered,
> one should be able do click (you know it from wikipedia) back to page
> where one was redireced from.

That would interact poorly with linking to particular sections with a #.

----------

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

From report at bugs.python.org  Mon Aug 25 16:35:53 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Aug 2014 14:35:53 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1408977353.71.0.950378254912.issue22232@psf.upfronthosting.co.za>


R. David Murray added the comment:

The existing related open doc issue issue 12855.

----------

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

From report at bugs.python.org  Mon Aug 25 16:40:09 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Aug 2014 14:40:09 +0000
Subject: [docs] [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1408977608.97.0.0891158496732.issue22232@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ideally str.splitlines would split on whatever the unicode database says are mandatory line break characters.  I take it this is currently not true?  That is, that the list is hardcoded?

----------

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

From report at bugs.python.org  Tue Aug 26 01:00:00 2014
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Aug 2014 23:00:00 +0000
Subject: [docs] [issue22275] asyncio: enhance documentation of OS support
Message-ID: <1409007600.34.0.690702465035.issue22275@psf.upfronthosting.co.za>


New submission from STINNER Victor:

When reading asyncio documentation, it's not easy to catch limitations of each operating system and event loop. I propose to mention in each mention if the method is not supported in some cases. See attached patch.

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio_os_support.patch
keywords: patch
messages: 225902
nosy: docs at python, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: enhance documentation of OS support
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36474/asyncio_os_support.patch

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

From report at bugs.python.org  Wed Aug 27 01:25:28 2014
From: report at bugs.python.org (Martin Panter)
Date: Tue, 26 Aug 2014 23:25:28 +0000
Subject: [docs] [issue12855] linebreak sequences should be better documented
In-Reply-To: <1314654150.68.0.797504547224.issue12855@psf.upfronthosting.co.za>
Message-ID: <1409095528.06.0.926913448096.issue12855@psf.upfronthosting.co.za>


Martin Panter added the comment:

Any reason why characters 1C?1E are excluded?

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

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

From report at bugs.python.org  Wed Aug 27 08:08:51 2014
From: report at bugs.python.org (Martin Panter)
Date: Wed, 27 Aug 2014 06:08:51 +0000
Subject: [docs] [issue12067] Doc: remove errors about mixed-type comparisons.
In-Reply-To: <1305237573.86.0.646542413513.issue12067@psf.upfronthosting.co.za>
Message-ID: <1409119731.04.0.594193479748.issue12067@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/issue12067>
_______________________________________

From report at bugs.python.org  Wed Aug 27 12:55:55 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 10:55:55 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
Message-ID: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>


New submission from Martijn Pieters:

The changes for issue #3473 introduced a documentation bug. The Call expression grammar implies that f(*[1, 2], *[3, 4]) is allowed:

| "*" `expression` ["," "*" `expression`] ["," "**" `expression`]

I think Benjamin meant to use:

| "*" `expression` ["," `keyword_arguments `] ["," "**" `expression`]

instead, see the corresponding commit for Python 3.x: http://hg.python.org/cpython/diff/6abada05c313/Doc/reference/expressions.rst

----------
assignee: docs at python
components: Documentation
messages: 225970
nosy: docs at python, mjpieters
priority: normal
severity: normal
status: open
title: Incorrect Call grammar in documentation
versions: Python 2.7

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

From report at bugs.python.org  Wed Aug 27 14:42:13 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 12:42:13 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409143333.66.0.819198174145.issue22288@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Proposed fix added in my fork.

----------
hgrepos: +270

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

From report at bugs.python.org  Wed Aug 27 14:44:30 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 12:44:30 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409143470.96.0.664933307727.issue22288@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file36487/ffe77dc2979a.diff

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

From report at bugs.python.org  Wed Aug 27 14:45:07 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 12:45:07 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409143507.41.0.649146957587.issue22288@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


Removed file: http://bugs.python.org/file36487/ffe77dc2979a.diff

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

From report at bugs.python.org  Wed Aug 27 14:47:51 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 12:47:51 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409143670.98.0.322942683089.issue22288@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Sigh, patch creation fails against a remove repository; I guess this only works for the default branch.

Attached as a patch file instead.

----------
Added file: http://bugs.python.org/file36488/issue22288.patch

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

From report at bugs.python.org  Wed Aug 27 14:47:57 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Wed, 27 Aug 2014 12:47:57 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409143677.73.0.775780619051.issue22288@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


----------
hgrepos:  -270

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

From report at bugs.python.org  Wed Aug 27 17:17:31 2014
From: report at bugs.python.org (Ben Rodrigue)
Date: Wed, 27 Aug 2014 15:17:31 +0000
Subject: [docs] [issue22291] Typo in docs - Lib/random
Message-ID: <1409152651.69.0.302549196397.issue22291@psf.upfronthosting.co.za>


New submission from Ben Rodrigue:

Small typo: 

In the documentation for the random module. The documentation refers to the semi-open range and then gives an example using a left bracket and then a curved parenthesis on the right. 

Link to page:https://docs.python.org/3.4/library/random.html

>From text:"which generates a random float uniformly in the semi-open range [0.0, 1.0)"  

I am new to programming but I believe this to be incorrect. If there is a way to submit a patch for the documentation, I am happy to do so.

----------
assignee: docs at python
components: Documentation
messages: 225990
nosy: benrodrigue, docs at python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Typo in docs - Lib/random
versions: Python 3.4

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

From report at bugs.python.org  Wed Aug 27 17:30:33 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Aug 2014 15:30:33 +0000
Subject: [docs] [issue22291] Typo in docs - Lib/random
In-Reply-To: <1409152651.69.0.302549196397.issue22291@psf.upfronthosting.co.za>
Message-ID: <1409153433.9.0.432448016609.issue22291@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's mathematical notation, not python syntax.  Note that in the html it is *not* styled as a literal code snippet.

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

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

From report at bugs.python.org  Thu Aug 28 04:29:14 2014
From: report at bugs.python.org (Martin Panter)
Date: Thu, 28 Aug 2014 02:29:14 +0000
Subject: [docs] [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1409192954.92.0.906073675125.issue21611@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/issue21611>
_______________________________________

From SthankiD at us.panasonic.com  Tue Aug 26 23:27:23 2014
From: SthankiD at us.panasonic.com (Sthanki, Dinesh)
Date: Tue, 26 Aug 2014 21:27:23 +0000
Subject: [docs] How to embed python in python ?
Message-ID: <84E6ECC757A7FB4EBF27F13B25208FC972D4D1BB@PTCPASAEXMB05.pasa.pas.local>

Sorry, 'docs', I did not know who to submit this to.

I need to write an IDE to run some Python Scripts,  I could attempt  that in  C#,  but , why not write the actual IDE in python, to run python code ?

Here is some not very successful attempt run Python script (one liner) from python
This is an assortment of things I found on the web, mind you, no one is  attempting to run python in a python script (embed python in a python script, how about that for a twist ?).


from ctypes import *
from sys import getsizeof
from binascii import hexlify

xPyLib = windll.LoadLibrary("python34.dll")                    # This works partially
#xPyLib = windll.LoadLibrary("C:\Python34\DLLs\python3.dll")   # This works partially too

xPyLib.Py_SetProgramName();
xPyLib.Py_Initialize();
status = xPyLib.Py_IsInitialized();    # check If Python is Initialized


if status==1:
    print ("Python is Initialized Successfully")
    vers = xPyLib.Py_GetVersion();                   # CHECK OUT THE GARBAGE VERSION DATA HERE
    Platform = xPyLib.Py_GetPlatform()               # CHECK OUT THE GARBAGE VERSION DATA HERE

    print ("Python Vers: "+str(hexlify(string_at(id(vers), getsizeof(vers)))))
    print ("Platform: "+str(hexlify(string_at(id(Platform), getsizeof(Platform)))))
    #print ("Platform: "+str(xPyLib.Py_GetPlatform()))

    Command = "x=2"
    status = xPyLib.PyRun_String(Command);

    xPyLib.Finalize();
else:
    print ("*** Failed to Initialize Python ***")
    exit()


Oh, one of the FAQ's should be "How do I submit a question ?"
Thank you for your time.


Dinesh Sthanki
Desk:  770-302-1201
Cell:    678-895-6120

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

From wiedeman at gmx.net  Tue Aug 26 15:08:14 2014
From: wiedeman at gmx.net (Christoph Wiedemann)
Date: Tue, 26 Aug 2014 15:08:14 +0200
Subject: [docs] Documentation of urllib.request
Message-ID: <trinity-e60e5fc9-f6d3-41dc-96c7-0f6867e0f21b-1409058494048@3capp-gmx-bs44>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140826/de68b347/attachment.html>

From vadmium+py at gmail.com  Wed Aug 27 07:56:54 2014
From: vadmium+py at gmail.com (vadmium+py at gmail.com)
Date: Wed, 27 Aug 2014 05:56:54 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20140827055654.16806.69006@psf.upfronthosting.co.za>

Some comments on the doc changes


https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1087
Doc/reference/expressions.rst:1087: The behavior of the default equality
comparison that instances with different
Needs a comma between ?comparison, that?

https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1096
Doc/reference/expressions.rst:1096: otherwise, :exc:`TypeError` is
raised:
Everything is an instance of the built-in type ?object?, and ?subtypes
of each other? does not make much sense to me. I think the cases where
TypeError is raised or not by default are already described above. Would
it hurt to just drop the second sentence?

https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1149
Doc/reference/expressions.rst:1149: each other), have the same length,
and each pair of corresponding elements
Again, ?subtypes of each other? does not make sense. Maybe just say you
cannot compare between lists, tuples, and ranges [and byte sequences and
text strings] this way. [I understand comparing the different kinds of
byte sequences is meant to work though.]

https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1156
Doc/reference/expressions.rst:1156: * Mappings (instances of
:class:`dict`) are compared lexicographically using
Not sure ?lexicographical comparison? makes sense unless the items have
an order. Maybe the original wording was better?

https://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1216
Doc/reference/expressions.rst:1216: sequences and mappings, but not to
sets). See also the
Perhaps drop ?mappings?; even OrderedDict does not do ordering
comparisons for me

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

From report at bugs.python.org  Thu Aug 28 11:47:59 2014
From: report at bugs.python.org (Martijn Pieters)
Date: Thu, 28 Aug 2014 09:47:59 +0000
Subject: [docs] [issue22288] Incorrect Call grammar in documentation
In-Reply-To: <1409136955.28.0.79885660635.issue22288@psf.upfronthosting.co.za>
Message-ID: <1409219279.0.0.786131889159.issue22288@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

Fixed by revision 3ae399c6ecf6

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

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

From blckknght at gmail.com  Thu Aug 28 10:17:39 2014
From: blckknght at gmail.com (blckknght at gmail.com)
Date: Thu, 28 Aug 2014 08:17:39 -0000
Subject: [docs] Doc: remove errors about mixed-type comparisons. (issue
	12067)
Message-ID: <20140828081739.11885.96528@psf.upfronthosting.co.za>

I think the patch is great, with the exception of one line (which I have
several issues with).


http://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst
File Doc/reference/expressions.rst (right):

http://bugs.python.org/review/12067/diff/12409/Doc/reference/expressions.rst#newcode1120
Doc/reference/expressions.rst:1120: Strings cannot directly be compared
with binary sequences, and vice versa!
I think the "be" is misplaced in this sentence (it should be "cannot be
directly compared").

Further, the "and" conjunction seemed so jarring to me I wasn't sure it
was even grammatical (though after further consideration I understand it
now). I'd suggest dropping the whole "vice versa" clause, since the
ability to be compared is symmetric (even if the comparisons themselves
are not). It wouldn't make sense to say that A can be compared to B if B
cannot be compared to A.

And finally, the exclamation mark at the end is a bit overemphatic!!1!

tldr, make this sentence: "Strings and binary sequences cannot be
directly compared."

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

From evanjtravis at gmail.com  Thu Aug 28 18:30:41 2014
From: evanjtravis at gmail.com (Evan Travis)
Date: Thu, 28 Aug 2014 11:30:41 -0500
Subject: [docs] Typo Report
Message-ID: <CAC9e8EUKNdc=uq7ZOSLqgNW4ztSE3rkP8CmDbRB-0zoBKETqtg@mail.gmail.com>

Web Page:          https://docs.python.org/2.6/tutorial/classes.html

Section:               9.5.1. Multiple Inheritance

Paragraph:          ?With new-style classes,??

Typo:                    ??(where *one* at least one of the parent
classes?)??



Solution: Remove bolded word ? *one*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140828/d9b1c1db/attachment.html>

From evanjtravis at gmail.com  Thu Aug 28 18:41:27 2014
From: evanjtravis at gmail.com (Evan Travis)
Date: Thu, 28 Aug 2014 11:41:27 -0500
Subject: [docs] Typo Report
Message-ID: <CAC9e8EWrZBB26pH3mf_mcziSaOLmbH0PWhFqeRtVcJdfQn5xPQ@mail.gmail.com>

Web Page:          https://docs.python.org/2.6/tutorial/classes.html

Section:               9.6. Private Variables

Paragraph:          ?Since there is a valid use-case..."

Typo:                    ??(at least *two* leading undercores, at most

                             *one* trailing underscore)??


Solution: Swap bolded words --> *one* and *two*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140828/dc4da999/attachment.html>

From zachary.ware+pydocs at gmail.com  Thu Aug 28 19:42:58 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Thu, 28 Aug 2014 12:42:58 -0500
Subject: [docs] Typo Report
In-Reply-To: <CAC9e8EUKNdc=uq7ZOSLqgNW4ztSE3rkP8CmDbRB-0zoBKETqtg@mail.gmail.com>
References: <CAC9e8EUKNdc=uq7ZOSLqgNW4ztSE3rkP8CmDbRB-0zoBKETqtg@mail.gmail.com>
Message-ID: <CAKJDb-PiROO-EF30k+As4qyUoNkXE0Fv49g_gCU7TnG=QTUCLg@mail.gmail.com>

Hi Evan,

On Thu, Aug 28, 2014 at 11:30 AM, Evan Travis <evanjtravis at gmail.com> wrote:
> Web Page:          https://docs.python.org/2.6/tutorial/classes.html
> Section:               9.5.1. Multiple Inheritance
> Paragraph:          ?With new-style classes,??
> Typo:                    ??(where one at least one of the parent classes?)??
>
> Solution: Remove bolded word ? one

Python 2.6 is no longer supported and this has already been fixed in
2.7.  I would recommend upgrading to 2.7 if at all possible, and
suggest using the 2.7 documentation with 2.6 even if you can't
upgrade--just look out for "New in 2.7" notes.

Thanks for the report, anyway!
-- 
Zach

From report at bugs.python.org  Fri Aug 29 05:35:54 2014
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 29 Aug 2014 03:35:54 +0000
Subject: [docs] [issue21611] int() docstring - unclear what number is
In-Reply-To: <1401440335.97.0.776400017562.issue21611@psf.upfronthosting.co.za>
Message-ID: <1409283354.61.0.127953761892.issue21611@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From zachary.ware at gmail.com  Fri Aug 29 08:07:08 2014
From: zachary.ware at gmail.com (zachary.ware at gmail.com)
Date: Fri, 29 Aug 2014 06:07:08 -0000
Subject: [docs] Document how to use Concurrent Build when using MsBuild
	(issue 22261)
Message-ID: <20140829060708.24459.2462@psf.upfronthosting.co.za>

Sorry it's taken me longer than expected to give you a review.  A couple
of things to be addressed, and then we'll be good to go!


http://bugs.python.org/review/22261/diff/12760/PCbuild/readme.txt
File PCbuild/readme.txt (right):

http://bugs.python.org/review/22261/diff/12760/PCbuild/readme.txt#newcode91
PCbuild/readme.txt:91: Please note that normal msbuild switches can also
be passed. For example,
I think 'MSBuild' is the proper capitalization for 'msbuild'.

And we should say that the MSBuild switches must be passed after any of
those listed above, you're limited to 9 MSbuild switches, and anything
with an = in it must be wrapped in quotes (like
"/p:externalsDir=P:\cpython-externals").

And possibly just personal preference, but I don't like the "Please note
that" at the beginning of the line; the rest of the line stands fine
without it.

http://bugs.python.org/review/22261/diff/12760/PCbuild/readme.txt#newcode92
PCbuild/readme.txt:92: build.bat -e -d /m
This file isn't quite in reST format, but is close; I'd go ahead and
follow the devguide's suggestions for block quoting (blank line before
and after, indent 3 spaces).

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

From report at bugs.python.org  Fri Aug 29 08:08:28 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 29 Aug 2014 06:08:28 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1409292508.04.0.127192305137.issue22261@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I finally managed to get a review posted on Rietveld, which should have sent you an email (sorry for the delay!).

----------

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

From report at bugs.python.org  Fri Aug 29 21:52:21 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 19:52:21 +0000
Subject: [docs] [issue22270] cache version selection for documentation
In-Reply-To: <1408923226.6.0.0114591743234.issue22270@psf.upfronthosting.co.za>
Message-ID: <1409341941.13.0.642066146019.issue22270@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I agree that this is a bad idea.

1. Cookies are generally a nuisance. I like the fact that docs.python.org is (apparently) cookie free and that python sites only use a few short-lived cookies. The complications you propose would be a nuisance to create and maintain.

2. Not too long ago, we created docs.python.org/2/ and /3/ so people can use generic links to the latest docs for the latest released version of either Python 2 or 3. The aim was to reduce the problem of links to stale docs. Both sets of docs have version added notes for changes within a series. Those two docs are not interchangeable and should not be automatically switched.

If someone links now to a fixed version of the docs, they are either ignorant of the new system *or* they have a purpose that should not be over-riden.

If someone quotes or paraphrases a portion of a page (which is a claim about what the page says) or otherwise makes a claim about Python, and posts a link as evidence of the claim, clicking the link should take one to the 'evidence', not one's preferred version.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> needs patch
status: open -> closed
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Aug 29 22:33:03 2014
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 29 Aug 2014 20:33:03 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
Message-ID: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>


New submission from Michele Orr?:

<maker> hello! In <https://docs.python.org/2/library/smtplib.html#smtplib.SMTP.starttls> I read::
<maker> "If keyfile and certfile are provided, these are passed to the socket module?s ssl() function."
<maker> socket.ssl() exists, though it is not documented (not even in /dev/library/socket)
<maker> and furthermore, the link on ssl() points to the ssl module, which is just confusing.
<bitdancer> maker: open an issue.

(I'm noising ap and chris because afaik they were working on the latest ssl security stuff)

----------
assignee: docs at python
components: Documentation, Library (Lib), email
messages: 226074
nosy: barry, christian.heimes, docs at python, maker, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: smtplib.SMTP.starttls' documentation is just confusing
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Aug 29 22:35:55 2014
From: report at bugs.python.org (Alex Gaynor)
Date: Fri, 29 Aug 2014 20:35:55 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
In-Reply-To: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>
Message-ID: <1409344555.32.0.878547837242.issue22301@psf.upfronthosting.co.za>


Alex Gaynor added the comment:

Attached patch fixes this up.

----------
keywords: +needs review, patch
nosy: +alex
Added file: http://bugs.python.org/file36505/t22301.diff

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

From report at bugs.python.org  Fri Aug 29 22:36:50 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 20:36:50 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
In-Reply-To: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>
Message-ID: <1409344610.63.0.396387827675.issue22301@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Aug 29 22:50:19 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Aug 2014 20:50:19 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
In-Reply-To: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>
Message-ID: <1409345419.22.0.110224308633.issue22301@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Or perhaps we should remove the function to wrap_socket(), which is just an implementation detail?

----------

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

From report at bugs.python.org  Fri Aug 29 22:56:52 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Aug 2014 20:56:52 +0000
Subject: [docs] [issue22301] smtplib.SMTP.starttls' documentation is just
	confusing
In-Reply-To: <1409344383.54.0.340854314506.issue22301@psf.upfronthosting.co.za>
Message-ID: <1409345812.89.0.82925514828.issue22301@psf.upfronthosting.co.za>


R. David Murray added the comment:

Remove the reference, you mean?  As in just delete the confusing line?  Since we want to encourage people to use the context, that sounds reasonable for 3.x at least.

----------

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

From report at bugs.python.org  Fri Aug 29 23:24:42 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 21:24:42 +0000
Subject: [docs] [issue17286] Make subprocess handling text output
	with	universal_newlines more obious
In-Reply-To: <1361708455.88.0.426093416103.issue17286@psf.upfronthosting.co.za>
Message-ID: <1409347482.36.0.394619643764.issue17286@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions: +Python 3.4, Python 3.5 -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 30 01:25:39 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 23:25:39 +0000
Subject: [docs] [issue22304] Update multiprocessing examples to Py3 and test
Message-ID: <1409354738.95.0.628176067564.issue22304@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

https://docs.python.org/2/library/multiprocessing.html#examples
contains several examples in Python2 code that need to be updated for Python 3. Richard, if you have them in .py files, perhaps you could run them through 2to3 and then test.

# Example where a pool of http servers share a single listening socket
from BaseHTTPServer import HTTPServer
from SimpleHTTPServer import SimpleHTTPRequestHandler
...
    print 'Serving at http://%s:%d using %d worker processes' % \
          (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES)
    print 'To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32']

#update
from http.server import HTTPServer, SimpleHTTPRequestHandler
...
    print('Serving at http://%s:%d using %d worker processes' % \
          (ADDRESS[0], ADDRESS[1], NUMBER_OF_PROCESSES))
    print('To exit press Ctrl-' + ['C', 'Break'][sys.platform=='win32'])


This still does not run on Windows 
_pickle.PicklingError: Can't pickle <class '_thread.lock'>: attribute lookup lock on _thread failed
but that was true in 2.7 also (#21204).

----------
assignee: docs at python
components: Documentation
messages: 226103
nosy: docs at python, sbt, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Update multiprocessing examples to Py3 and test
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 30 01:27:11 2014
From: report at bugs.python.org (sbspider)
Date: Fri, 29 Aug 2014 23:27:11 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1409354831.39.0.746286980526.issue22261@psf.upfronthosting.co.za>


sbspider added the comment:

How do you want me to about fixing the issues you suggested - another patch?

----------

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

From report at bugs.python.org  Sat Aug 30 01:36:55 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 23:36:55 +0000
Subject: [docs] [issue22304] Update multiprocessing examples to Py3 and test
In-Reply-To: <1409354738.95.0.628176067564.issue22304@psf.upfronthosting.co.za>
Message-ID: <1409355415.33.0.547419413387.issue22304@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Sorry, copied and pasted from the wrong place. Forget this.

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

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

From report at bugs.python.org  Sat Aug 30 01:42:29 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 29 Aug 2014 23:42:29 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1409354831.39.0.746286980526.issue22261@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-NkvzTBXmtwEPpvXE-_zwTiMVsGydeXNSgw+vogSFdcHQ@mail.gmail.com>


Zachary Ware added the comment:

Another patch would be perfect :)

----------

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

From report at bugs.python.org  Sat Aug 30 01:42:32 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Aug 2014 23:42:32 +0000
Subject: [docs] [issue21204] multiprocessing example does not work on Windows
In-Reply-To: <1397267440.3.0.253901505287.issue21204@psf.upfronthosting.co.za>
Message-ID: <1409355752.2.0.530309297553.issue21204@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The same example failing is the subject of #5879.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> multiprocessing - example "pool of http servers " fails on windows "socket has no attribute fromfd"

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

From report at bugs.python.org  Sat Aug 30 03:44:21 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 01:44:21 +0000
Subject: [docs] [issue15418] 2to3 docs should mention setup.py fixes
	required to	install compatible packages in Python 3
In-Reply-To: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>
Message-ID: <1409363061.54.0.78519297931.issue15418@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Aug 30 05:57:49 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 03:57:49 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1409371069.08.0.266891366613.issue1660009@psf.upfronthosting.co.za>


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


----------
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat Aug 30 06:17:48 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 04:17:48 +0000
Subject: [docs] [issue21910] File protocol should document if writelines
	must handle	generators sensibly
In-Reply-To: <1404380309.75.0.473808735546.issue21910@psf.upfronthosting.co.za>
Message-ID: <1409372267.95.0.736763298849.issue21910@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Security fix only versions do not get doc fixes.

----------
versions:  -Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Aug 30 06:21:17 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 04:21:17 +0000
Subject: [docs] [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <1409372477.68.0.884896458576.issue10536@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Aug 30 06:23:25 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 04:23:25 +0000
Subject: [docs] [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1409372604.85.0.00176581642595.issue10225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For whatever difference it makes, the 3.x docs now *are* being built with 3.x.

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

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

From report at bugs.python.org  Sat Aug 30 09:41:40 2014
From: report at bugs.python.org (Shailesh Hegde)
Date: Sat, 30 Aug 2014 07:41:40 +0000
Subject: [docs] [issue22305] Documentation on deepcopy's problems is
	misleading
Message-ID: <1409384500.34.0.359700008646.issue22305@psf.upfronthosting.co.za>


New submission from Shailesh Hegde:

https://docs.python.org/<version>/library/copy.html

"Two problems often exist with deep copy operations that don?t exist with shallow copy operations:

Recursive objects (compound objects that, directly or indirectly, contain a reference to themselves) may cause a recursive loop.
Because deep copy copies everything it may copy too much, e.g., administrative data structures that should be shared even between copies."

I believe the last line in above paragraph is missing a 'not' ahead of 'be shared'. 

It should read:
"administrative data structures that should be not shared even between copies"

----------
assignee: docs at python
components: Documentation
messages: 226123
nosy: docs at python, shlsh
priority: normal
severity: normal
status: open
title: Documentation on deepcopy's problems is misleading
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sat Aug 30 10:10:32 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Aug 2014 08:10:32 +0000
Subject: [docs] [issue21072] Python docs and downloads not available for
	Egypt
In-Reply-To: <1395872823.34.0.614292416852.issue21072@psf.upfronthosting.co.za>
Message-ID: <1409386232.64.0.352589274569.issue21072@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.1, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat Aug 30 12:03:31 2014
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 30 Aug 2014 10:03:31 +0000
Subject: [docs] [issue22305] Documentation on deepcopy's problems is
	misleading
In-Reply-To: <1409384500.34.0.359700008646.issue22305@psf.upfronthosting.co.za>
Message-ID: <1409393011.83.0.681482843903.issue22305@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

> It should read:
> "administrative data structures that should be not shared 
> even between copies"

No. If they should NOT be shared, then making a deep copy is the correct thing to do. The problem with deepcopy is when you actually do want to share some deep data structures, but not others. Then making a copy is the wrong thing, since they will no longer be shared.

The current documentation is correct. I'm going to leave the issue Open for the time being, in case somebody can think of wording that is more clear and less likely to be misunderstood.

----------
nosy: +steven.daprano
resolution:  -> not a bug

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

From report at bugs.python.org  Sat Aug 30 12:16:02 2014
From: report at bugs.python.org (sbspider)
Date: Sat, 30 Aug 2014 10:16:02 +0000
Subject: [docs] [issue22261] Document how to use Concurrent Build when using
	MsBuild
In-Reply-To: <1408840287.23.0.766933762648.issue22261@psf.upfronthosting.co.za>
Message-ID: <1409393762.67.0.873699263276.issue22261@psf.upfronthosting.co.za>


sbspider added the comment:

Uploaded a new patch.

----------
Added file: http://bugs.python.org/file36506/readme.patch

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

From report at bugs.python.org  Sat Aug 30 14:23:21 2014
From: report at bugs.python.org (Carlo)
Date: Sat, 30 Aug 2014 12:23:21 +0000
Subject: [docs] [issue22307] os.getlogin() documentation has misleading side
	note
Message-ID: <1409401401.25.0.41962745955.issue22307@psf.upfronthosting.co.za>


New submission from Carlo:

The documentation for os.getlogin() says:

... ``pwd.getpwuid(os.getuid())[0]`` to get the login name of the currently effective user id

Either, os.getuid() should be changed to os.geteuid(), or the wording should be changed.

----------
assignee: docs at python
components: Documentation
messages: 226139
nosy: Carlo, docs at python
priority: normal
severity: normal
status: open
title: os.getlogin() documentation has misleading side note
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Aug 31 03:06:10 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Aug 2014 01:06:10 +0000
Subject: [docs] [issue22307] os.getlogin() documentation has misleading side
	note
In-Reply-To: <1409401401.25.0.41962745955.issue22307@psf.upfronthosting.co.za>
Message-ID: <3hlxFF17Scz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 59f2edeb8443 by Benjamin Peterson in branch '2.7':
getuid() returns real process id not effective (closes #22307)
http://hg.python.org/cpython/rev/59f2edeb8443

New changeset c30163548f64 by Benjamin Peterson in branch '3.4':
getuid() returns real process id not effective (closes #22307)
http://hg.python.org/cpython/rev/c30163548f64

New changeset 164a17eca081 by Benjamin Peterson in branch 'default':
merge 3.4 (closes #22307)
http://hg.python.org/cpython/rev/164a17eca081

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

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

From report at bugs.python.org  Sun Aug 31 06:42:57 2014
From: report at bugs.python.org (Shailesh Hegde)
Date: Sun, 31 Aug 2014 04:42:57 +0000
Subject: [docs] [issue22305] Documentation on deepcopy's problems is
	misleading
In-Reply-To: <1409384500.34.0.359700008646.issue22305@psf.upfronthosting.co.za>
Message-ID: <1409460177.73.0.608567677509.issue22305@psf.upfronthosting.co.za>


Shailesh Hegde added the comment:

Thanks.

"Because deep copy copies everything it may copy too much, e.g., administrative data structures that need to be shared even between copies, which may not be the desired goal."

helps me understand better.

----------

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

From report at bugs.python.org  Sun Aug 31 09:41:27 2014
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Aug 2014 07:41:27 +0000
Subject: [docs] [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1409470887.78.0.743000983851.issue10240@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/issue10240>
_______________________________________

From report at bugs.python.org  Sun Aug 31 14:48:08 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Aug 2014 12:48:08 +0000
Subject: [docs] [issue22275] asyncio: enhance documentation of OS support
In-Reply-To: <1409007600.34.0.690702465035.issue22275@psf.upfronthosting.co.za>
Message-ID: <3hmDqC20Gyz7Ljj@mail.python.org>


Roundup Robot added the comment:

New changeset 9480287f85a0 by Victor Stinner in branch '3.4':
Closes #22275: asyncio: enhance documentation of OS support
http://hg.python.org/cpython/rev/9480287f85a0

New changeset 9138d60db0e4 by Victor Stinner in branch 'default':
(Merge 3.4) Closes #22275: asyncio: enhance documentation of OS support
http://hg.python.org/cpython/rev/9138d60db0e4

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

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

From report at bugs.python.org  Sun Aug 31 18:02:43 2014
From: report at bugs.python.org (Anthony Mayer)
Date: Sun, 31 Aug 2014 16:02:43 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
Message-ID: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>


New submission from Anthony Mayer:

After discussion about extraneous whitespace around colons in a list slice not being an error on the pep8 checker project (see https://github.com/jcrocholl/pep8/issues/321#issuecomment-53649841), ncoghlan suggested filing a ticket here to get the issue added to PEP8. The issue being that PEP8 doesn't say that

x = [1, 2, 3, 4]
x[1: 3]

is wrong. It should suggest doing

x = [1, 2, 3, 4]
x[1:3]

instead. This rule should probably be added to the "Whitespace In Expressions and Statements" section of PEP8 (http://legacy.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements)

----------
assignee: docs at python
components: Documentation
messages: 226185
nosy: Guido.van.Rossum, anthonymayer, barry, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: Add rule about "extraneous whitespace around colon" to "Whitespace In Expressions and Statements" of PEP8

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

From report at bugs.python.org  Sun Aug 31 22:39:23 2014
From: report at bugs.python.org (Ubik)
Date: Sun, 31 Aug 2014 20:39:23 +0000
Subject: [docs] [issue22317] action argument is not documented in
	argparse	add_subparser() docs
Message-ID: <1409517563.44.0.056496049443.issue22317@psf.upfronthosting.co.za>


New submission from Ubik:

See: https://docs.python.org/2/library/argparse.html#argparse.ArgumentParser.add_subparsers

----------
assignee: docs at python
components: Documentation
messages: 226190
nosy: Ubik, docs at python
priority: normal
severity: normal
status: open
title: action argument is not documented in argparse add_subparser() docs
versions: Python 2.7

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

From report at bugs.python.org  Sun Aug 31 23:02:37 2014
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 31 Aug 2014 21:02:37 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>
Message-ID: <1409518957.68.0.580016983518.issue22316@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Oooh, yes. The colon in a slice should be treated as a binary operator, with equal space before and after.

I think we can add this (as a new bullet following the bullet "Immediately before a comma, semicolon, or colon"):

- However, the colon in a slice acts like a binary operator, and
  should have equal amounts on either side.  In an extended slice,
  both colons must have the same amount of spacing applied. ::

      Yes: ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:]
      Yes: ham[lower + offset : upper + offset], ham[lower : upper : 3]
      No: ham[1: 9], ham[1 :9]


I'm not sure what to recommend for extended slices when one or several of the slots are empty; my intuition?suggests that there should be no spaces around any colons in that case, but I'm not sure what to do if you really have a long expression as one slot. Which is better?

    ham[lower + 1 :: step]

or

    ham[lower + 1 : : step]

similar for other cases, e.g.

    ham[lower + 1 : upper + 1 :]

vs.

    ham[lower + 1 : upper + 1 : ]

To me, *all* of those feel weird.

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

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

From report at bugs.python.org  Sun Aug 31 23:28:04 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 Aug 2014 21:28:04 +0000
Subject: [docs] [issue22316] Add rule about "extraneous whitespace around
	colon" to	"Whitespace In Expressions and Statements" of PEP8
In-Reply-To: <1409500963.42.0.440331342486.issue22316@psf.upfronthosting.co.za>
Message-ID: <1409520484.72.0.896405242865.issue22316@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

> Yes: ham[lower + offset : upper + offset], ham[lower : upper : 3]

This feels a bit weird to me, perhaps because I seldom have expressions in slices and don't feel the need to add further spaces.
For the first case I would definitely not put spaces around the +, and likely not even around the :.
For the second case I also wouldn't put spaces around the :.
In general complex expressions that requires additional spaces around the : to better separate start, stop, and step should be avoided or, if really necessary, additional variables should be used*.
I would be -0.5 if this is kept but with a "Maybe" instead of the "Yes", -0 if the spaces around the + are removed.

* note that I'm not too familiar with bumpy/scipy, where I believe complex slice expressions might be more common.

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

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

From report at bugs.python.org  Sun Aug 31 23:55:54 2014
From: report at bugs.python.org (Tony Flury)
Date: Sun, 31 Aug 2014 21:55:54 +0000
Subject: [docs] [issue22318] unitest documentation on assertItemsEqual
	misleading
Message-ID: <1409522154.37.0.82658213186.issue22318@psf.upfronthosting.co.za>


New submission from Tony Flury:

The notes on assertItemsEqual do not make it clear that the comparison works by using their hash value, and not their __eq__ implementation - i.e. it does an 'is' not an '==' between objects in the sequence.

If the sequences being compared contain user created objects which don't implement their own specific __hash__ method (and therefore inherit their __hash__ from the base object - based on the object id), then the assertion will ALWAYS be false, regardless of their __eq__ value.

This only became clear when trying to use unitest, getting strange results, and I eventually read the code.

----------
assignee: docs at python
components: Documentation
messages: 226193
nosy: TonyFlury, docs at python
priority: normal
severity: normal
status: open
title: unitest documentation on assertItemsEqual misleading
type: behavior
versions: Python 2.7

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