From report at bugs.python.org  Wed Jan  1 17:12:00 2014
From: report at bugs.python.org (Mitchell Model)
Date: Wed, 01 Jan 2014 16:12:00 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
Message-ID: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>


New submission from Mitchell Model:

The documentation of itertools.accumulate (10.1) starts out with 2 misleading sentences: "Make an iterator that returns accumulated sums. Elements may be any addable type..." It then goes on to show examples of using the func parameter added in 3.3 that are not additions. It should be changed to something like: "Make an iterator that returns accumulated values. Elements may be any type that can be an argument to func. Func defaults to addition, so by default elements can be any addable types, ..." My wording is awkward, but you get the idea. I think this is a significant documentation issue, not just a nit.

----------
assignee: docs at python
components: Documentation
messages: 207135
nosy: MLModel, docs at python
priority: normal
severity: normal
status: open
title: Documentation of itertools.accumulate is confused
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  1 18:03:10 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 01 Jan 2014 17:03:10 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>
Message-ID: <1388595790.87.0.844118819989.issue20103@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan  2 19:01:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jan 2014 18:01:47 +0000
Subject: [docs] [issue20109] TestProgram is mentioned in the unittest docs
	but is not	documented
Message-ID: <1388685707.72.0.688331916968.issue20109@psf.upfronthosting.co.za>


New submission from R. David Murray:

IMO, TestProgram should either be made anonymous in the docs ('main returns an object that has a results attribute...') or its external API should be formally documented.  If results is the only external API other than its init (which is documented as unittest.main), then I would suggest the former.  In either case exactly what 'results' contains should be clarified.

----------
assignee: docs at python
components: Documentation
messages: 207178
nosy: docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: TestProgram is mentioned in the unittest docs but is not documented
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  2 19:44:50 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Jan 2014 18:44:50 +0000
Subject: [docs] [issue17282] document the defaultTest parameter to
	unittest.main()
In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za>
Message-ID: <3dwJ8128J5z7LjS@mail.python.org>


Roundup Robot added the comment:

New changeset 045e7a587f3c by R David Murray in branch '3.3':
#17282: Document unittest.main defaultTest argument.
http://hg.python.org/cpython/rev/045e7a587f3c

New changeset 69b5f6924553 by R David Murray in branch '2.7':
#17282: Document unittest.main defaultTest argument.
http://hg.python.org/cpython/rev/69b5f6924553

New changeset 1bbf8c263d3c by R David Murray in branch 'default':
Merge and update #17282: Document unittest.main defaultTest argument.
http://hg.python.org/cpython/rev/1bbf8c263d3c

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

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

From report at bugs.python.org  Thu Jan  2 19:46:34 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jan 2014 18:46:34 +0000
Subject: [docs] [issue17282] document the defaultTest parameter to
	unittest.main()
In-Reply-To: <1361664894.83.0.085559336561.issue17282@psf.upfronthosting.co.za>
Message-ID: <1388688394.69.0.574396708464.issue17282@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks Kyle.  I reworded it a bit to clarify the precedence of argv over defaultTest.  (Also FYI your patch had stray spaces at the ends of the lines.)

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jan  2 20:41:53 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Thu, 02 Jan 2014 19:41:53 +0000
Subject: [docs] [issue20110] Misleading word used for __annotations__
Message-ID: <1388691713.84.0.436758245185.issue20110@psf.upfronthosting.co.za>


New submission from Claudiu.Popa:

The documentation for `__annotations__` specify that the dict contains the parameter names ``or`` the return, but this is misleading, because `return` exists even if the parameter keys are present.

----------
assignee: docs at python
components: Documentation
files: doc_annotation.patch
keywords: patch
messages: 207183
nosy: Claudiu.Popa, docs at python
priority: normal
severity: normal
status: open
title: Misleading word used for __annotations__
versions: Python 3.4
Added file: http://bugs.python.org/file33297/doc_annotation.patch

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

From report at bugs.python.org  Thu Jan  2 23:32:32 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 02 Jan 2014 22:32:32 +0000
Subject: [docs] [issue20112] The documentation for http.server
	error_message_format	is inadequate.
Message-ID: <1388701952.2.0.132957137739.issue20112@psf.upfronthosting.co.za>


New submission from R. David Murray:

The description of error_message_format does not give enough information to use it.  The description should talk about how it is used (ie: using % formatting) and the fact that when filled in it should form a complete html document because it will be sent as the error response body.  It should not talk about what "the code key should be", etc, but should instead say what they *will* be, and cross reference the send_error method as the thing that uses it.

----------
assignee: docs at python
components: Documentation
messages: 207194
nosy: docs at python, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: The documentation for http.server error_message_format is inadequate.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan  2 23:48:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 02 Jan 2014 22:48:38 +0000
Subject: [docs] [issue20110] Misleading word used for __annotations__
In-Reply-To: <1388691713.84.0.436758245185.issue20110@psf.upfronthosting.co.za>
Message-ID: <3dwPYL0z4xz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset 203ca77ea819 by Benjamin Peterson in branch '3.3':
correct word for __annotations__ doc (closes #20110)
http://hg.python.org/cpython/rev/203ca77ea819

New changeset 3e75f649e93b by Benjamin Peterson in branch 'default':
merge 3.3 (#20110)
http://hg.python.org/cpython/rev/3e75f649e93b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jan  3 17:14:46 2014
From: report at bugs.python.org (Luca Faustin)
Date: Fri, 03 Jan 2014 16:14:46 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1388765686.83.0.682579395199.issue19023@psf.upfronthosting.co.za>


Changes by Luca Faustin <luca.faustin at ibttn.it>:


----------
nosy: +faustinl

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

From report at bugs.python.org  Sat Jan  4 01:05:52 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2014 00:05:52 +0000
Subject: [docs] [issue20090] slight ambiguity in README.txt instructions for
	building	docs
In-Reply-To: <1388243674.59.0.297728620179.issue20090@psf.upfronthosting.co.za>
Message-ID: <1388793952.72.0.356047054708.issue20090@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  4 01:17:11 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2014 00:17:11 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>
Message-ID: <1388794631.45.0.936910246522.issue20103@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Somewhat orthogonal to Mitchell's suggestion, I would change 'returns' to 'yields' and expand 'elements' to 'elements of *iterable*'.

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

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

From report at bugs.python.org  Sat Jan  4 01:17:24 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 04 Jan 2014 00:17:24 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>
Message-ID: <1388794644.45.0.0515246365388.issue20103@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan  4 01:19:51 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 04 Jan 2014 00:19:51 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>
Message-ID: <1388794791.32.0.24347263446.issue20103@psf.upfronthosting.co.za>


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


----------
keywords: +easy
nosy: +ezio.melotti
type:  -> enhancement

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

From report at bugs.python.org  Sat Jan  4 18:29:34 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 04 Jan 2014 17:29:34 +0000
Subject: [docs] [issue17576] PyNumber_Index() is not int-subclass friendly
	(or	operator.index() docos lie)
In-Reply-To: <1364595911.19.0.826873230127.issue17576@psf.upfronthosting.co.za>
Message-ID: <1388856574.42.0.30717609974.issue17576@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have doubts about this issue, so I have unassigned it from myself.

----------
assignee: serhiy.storchaka -> 

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

From report at bugs.python.org  Sun Jan  5 00:48:56 2014
From: report at bugs.python.org (R. David Murray)
Date: Sat, 04 Jan 2014 23:48:56 +0000
Subject: [docs] [issue20124] The documentation for the atTime parameter
	of	TimedRotatimeFileHandler is confusing
Message-ID: <1388879336.03.0.25076651665.issue20124@psf.upfronthosting.co.za>


New submission from R. David Murray:

The docs say that you can specify 'atTime' with a 'when' of 'midnight', but that makes no sense on the face of it.  atTime with a weekday specification makes sense, but it would also make sense to use atTime with a when of D (and an interval), which is not mentioned as a possibility.  It could also make sense to use it with other intervals (in other words, use the atTime as the starting point for the rotation calculation, instead of the last mod time or 'now').  If that doesn't work it should be stated that atTime will be ignored in those cases.  

Probably all the time related entries should be rewritten with the existence of atTime in mind, in order to clarify all the possible (and not possible) interactions.

----------
assignee: docs at python
components: Documentation
messages: 207323
nosy: docs at python, r.david.murray, vinay.sajip
priority: normal
severity: normal
stage: needs patch
status: open
title: The documentation for the atTime parameter of TimedRotatimeFileHandler is confusing
versions: Python 3.4

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

From report at bugs.python.org  Sun Jan  5 06:30:01 2014
From: report at bugs.python.org (moijes12)
Date: Sun, 05 Jan 2014 05:30:01 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1388899801.7.0.683625033941.issue11681@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


----------
nosy:  -moijes12

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

From report at bugs.python.org  Sun Jan  5 08:12:51 2014
From: report at bugs.python.org (Martin Panter)
Date: Sun, 05 Jan 2014 07:12:51 +0000
Subject: [docs] [issue11681] -b option undocumented
In-Reply-To: <1301100825.87.0.69977993755.issue11681@psf.upfronthosting.co.za>
Message-ID: <1388905971.76.0.623818231163.issue11681@psf.upfronthosting.co.za>


Martin Panter added the comment:

Try this to trigger a warning:

python2 -b -c 'bytearray("3") == u"3"'
-c:1: BytesWarning: Comparison between bytearray and string

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

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

From report at bugs.python.org  Sun Jan  5 14:51:51 2014
From: report at bugs.python.org (Martin Panter)
Date: Sun, 05 Jan 2014 13:51:51 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1388929911.53.0.307323221469.issue19548@psf.upfronthosting.co.za>


Martin Panter added the comment:

Addition to the list of improvements:

* Under codecs.IncrementalEncoder.reset() it mentions calling encode('', final=True). This call does not work as written for the byte encoders in my experience, because they do not accept empty text strings. Perhaps it should just say to use the final=True flag with no data.

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

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

From report at bugs.python.org  Sun Jan  5 16:18:01 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 05 Jan 2014 15:18:01 +0000
Subject: [docs] [issue19548] 'codecs' module docs improvements
In-Reply-To: <1384133353.82.0.173341188397.issue19548@psf.upfronthosting.co.za>
Message-ID: <1388935081.48.0.6206051981.issue19548@psf.upfronthosting.co.za>


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


----------
nosy: +doerwalter

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

From report at bugs.python.org  Mon Jan  6 03:47:59 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 06 Jan 2014 02:47:59 +0000
Subject: [docs] [issue20134] typo: s/coping/copying/
Message-ID: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/unittest.mock-examples.html#coping-with-mutable-arguments
"coping" should be "copying"?

----------
assignee: docs at python
components: Documentation
messages: 207409
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: typo: s/coping/copying/
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan  6 04:53:55 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jan 2014 03:53:55 +0000
Subject: [docs] [issue20135] mutate list
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1388980434.95.0.966114421626.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

Both of these are FAQs, but to my surprise there don't seem to be answers to them in the FAQ list.  We should add some.

Yes, both of these behaviors is intentional.  The first is an important part of the language design: 'variable' names are just pointers to objects, so x and y point to the same object.  The second is the same issue combined with another design feature: the objects on the right side of the = in a def statement are evaluated/created at the time the def statement is executed, not at the time the function is called.  So 'n' points to the same object every time the function is called.

I'm going to leave this open until someone either points me to the FAQ entries I missed, or we add them.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, r.david.murray
versions: +Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon Jan  6 05:17:59 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 06 Jan 2014 04:17:59 +0000
Subject: [docs] [issue20134] typo: s/coping/copying/
In-Reply-To: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za>
Message-ID: <1388981879.0.0.179938268206.issue20134@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

No, see https://en.wiktionary.org/wiki/cope

----------
nosy: +benjamin.peterson
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Mon Jan  6 05:18:09 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 06 Jan 2014 04:18:09 +0000
Subject: [docs] [issue20134] typo: s/coping/copying/
In-Reply-To: <1388976479.8.0.729846608286.issue20134@psf.upfronthosting.co.za>
Message-ID: <1388981889.56.0.28463421484.issue20134@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <bp+pybugs at benjamin-peterson.org>:


----------
resolution: later -> invalid

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

From report at bugs.python.org  Mon Jan  6 14:12:14 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 13:12:14 +0000
Subject: [docs] [issue20141] Argument Clinic: broken support for 'O!'
Message-ID: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

First, the documentation says that syntax for 'O!' conversion is
object(type='name_of_Python_type'), but actually the type argument should be the name of C structure which represents Python type. I.e. object(type='list') is rejected, and object(type='PyList_Type') is accepted.

Second, from this declaration

/*[clinic]
module spam
spam.ham

    items: object(type='PyList_Type')
    /

[clinic]*/

Argument Clinic generates following parsing code:

    if (!PyArg_ParseTuple(args,
        "O!:ham",
        PyList_Type, &items))
        goto exit;

It is wrong, should be &PyList_Type.

----------
assignee: docs at python
components: Build, Documentation
messages: 207430
nosy: docs at python, larry, serhiy.storchaka
priority: release blocker
severity: normal
status: open
title: Argument Clinic: broken support for 'O!'
type: crash
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan  6 14:47:22 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 06 Jan 2014 13:47:22 +0000
Subject: [docs] [issue20141] Argument Clinic: broken support for 'O!'
In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za>
Message-ID: <1389016042.07.0.317942312955.issue20141@psf.upfronthosting.co.za>


Larry Hastings added the comment:

So a documentation error and having to manually specify "&" at the front of your string means it's "broken"?

Nevertheless, I'll take a look at it.

----------

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

From report at bugs.python.org  Mon Jan  6 14:50:27 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 13:50:27 +0000
Subject: [docs] [issue20141] Argument Clinic: broken support for 'O!'
In-Reply-To: <1389016042.07.0.317942312955.issue20141@psf.upfronthosting.co.za>
Message-ID: <5147104.dQgs7oKGiW@raxxla>


Serhiy Storchaka added the comment:

You can't manually specify "&" at the front of the name.

----------

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

From report at bugs.python.org  Mon Jan  6 14:55:57 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 06 Jan 2014 13:55:57 +0000
Subject: [docs] [issue20141] Argument Clinic: broken support for 'O!'
In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za>
Message-ID: <1389016557.63.0.911196906689.issue20141@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file33325/spammodule.c

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

From report at bugs.python.org  Mon Jan  6 16:19:43 2014
From: report at bugs.python.org (Alexandru Gheorghe)
Date: Mon, 06 Jan 2014 15:19:43 +0000
Subject: [docs] [issue20146] UserDict module docs link is obsolete
Message-ID: <1389021583.36.0.157919967896.issue20146@psf.upfronthosting.co.za>


New submission from Alexandru Gheorghe:

FILE
    /usr/lib/python2.7/UserDict.py

MODULE DOCS
    http://docs.python.org/library/UserDict



Reference link to online documentation is invalid. (Probably) Should be: http://docs.python.org/library/userdict.html


Happens on Debian 7 Wheezy x86_64: 
Python 2.7.3 , [GCC 4.7.2] on linux2

----------
assignee: docs at python
components: Documentation
messages: 207441
nosy: docs at python, drunax
priority: normal
severity: normal
status: open
title: UserDict module docs link is obsolete
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Mon Jan  6 17:57:11 2014
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 06 Jan 2014 16:57:11 +0000
Subject: [docs] [issue20141] Argument Clinic: broken support for 'O!'
In-Reply-To: <1389013934.21.0.28397308089.issue20141@psf.upfronthosting.co.za>
Message-ID: <1389027431.19.0.100511652493.issue20141@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Actually, the documentation (the "howto") states:

Note that object() must explicitly support each Python type you specify for the type argument. Currently it only supports str. It should be easy to add more, just edit Tools/clinic/clinic.py, search for O! in the text, and add more entries to the dict mapping types to strings just above it.

Maybe this is a bad API.  But it's not broken.

----------

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

From report at bugs.python.org  Mon Jan  6 19:33:22 2014
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 06 Jan 2014 18:33:22 +0000
Subject: [docs] [issue20150] API change in string formatting with :s option
	should be	documented in What's New.
In-Reply-To: <1389032161.42.0.577933973443.issue20150@psf.upfronthosting.co.za>
Message-ID: <1389033202.17.0.23169831435.issue20150@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops, I missed the "should be documented" part of your message. That's true, and I'll leave this open. But I'll change it to a doc request and assign it accordingly.

----------
assignee: eric.smith -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
resolution: invalid -> 
status: closed -> open
title: API breakage in string formatting with :s option -> API change in string formatting with :s option should be documented in What's New.

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

From report at bugs.python.org  Mon Jan  6 22:58:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 06 Jan 2014 21:58:43 +0000
Subject: [docs] [issue20153] New-in-3.4 weakref finalizer doc section is
	already out	of date.
Message-ID: <1389045523.36.0.692306072283.issue20153@psf.upfronthosting.co.za>


New submission from R. David Murray:

The following discussion section in the weakref docs:

http://docs.python.org/dev/library/weakref.html#comparing-finalizers-with-del-methods

which was added in 3.4, is out of date because of the GC improvements.  It should be tweaked to match the new reality.

(I've already deleted the Note under __callback__.)

----------
assignee: docs at python
components: Documentation
messages: 207489
nosy: docs at python, pitrou, r.david.murray, sbt
priority: normal
severity: normal
stage: needs patch
status: open
title: New-in-3.4 weakref finalizer doc section is already out of date.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Tue Jan  7 14:09:48 2014
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 07 Jan 2014 13:09:48 +0000
Subject: [docs] [issue9307] Py_TPFLAGS_LONG_SUBCLASS is not documented
In-Reply-To: <1279561825.23.0.120090245801.issue9307@psf.upfronthosting.co.za>
Message-ID: <1389100188.09.0.798494152458.issue9307@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan  7 17:52:13 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jan 2014 16:52:13 +0000
Subject: [docs] [issue20096] Mention modernize and future in Python 2/3
	porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <3dzKPm4XBNzSXf@mail.python.org>


Roundup Robot added the comment:

New changeset e4d98ed54c53 by Brett Cannon in branch 'default':
Issue #20096: Update the Python 2/3 porting HOWTO to focus on
http://hg.python.org/cpython/rev/e4d98ed54c53

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

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

From report at bugs.python.org  Tue Jan  7 17:52:37 2014
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 07 Jan 2014 16:52:37 +0000
Subject: [docs] [issue20096] Mention modernize and future in Python 2/3
	porting HOWTO
In-Reply-To: <1388432630.2.0.0690952057164.issue20096@psf.upfronthosting.co.za>
Message-ID: <1389113557.32.0.483219921134.issue20096@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee: docs at python -> brett.cannon
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Jan  7 21:42:28 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 07 Jan 2014 20:42:28 +0000
Subject: [docs] [issue19273] Update PCbuild/readme.txt
In-Reply-To: <1381956724.6.0.425752006149.issue19273@psf.upfronthosting.co.za>
Message-ID: <3dzQWR6jZZz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset e8307cf23af4 by Larry Hastings in branch 'default':
Issue #19273: The marker comments Argument Clinic uses have been changed
http://hg.python.org/cpython/rev/e8307cf23af4

----------

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

From report at bugs.python.org  Tue Jan  7 23:53:10 2014
From: report at bugs.python.org (Roy Smith)
Date: Tue, 07 Jan 2014 22:53:10 +0000
Subject: [docs] [issue20169] random module doc page has broken links
Message-ID: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>


New submission from Roy Smith:

On http://docs.python.org/2/library/random.html, the links to random() go to the module, not the function.  Thus:

Almost all module functions depend on the basic function random(),

If you lick on random(), you get to http://docs.python.org/2/library/random.html#module-random

This looks like the same problem as issue19416.

----------
assignee: docs at python
components: Documentation
messages: 207612
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: random module doc page has broken links
versions: Python 2.7

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

From report at bugs.python.org  Tue Jan  7 23:56:03 2014
From: report at bugs.python.org (Roy Smith)
Date: Tue, 07 Jan 2014 22:56:03 +0000
Subject: [docs] [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1389135363.96.0.082436127176.issue20169@psf.upfronthosting.co.za>


Roy Smith added the comment:

Ugh, that should say, "if you CLICK on random()".  Really wish I was filing this from my phone so I could blame it on autocorrect.

----------

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

From report at bugs.python.org  Wed Jan  8 01:26:09 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jan 2014 00:26:09 +0000
Subject: [docs] [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1389140769.33.0.454608357055.issue20169@psf.upfronthosting.co.za>


R. David Murray added the comment:

I started to make some quick changes to fix this, but it turns out that the Random *class* isn't even documented in the docs except for the introductory paragraphs.  IMO that ought to be fixed, too, since the intro even talks about subclassing it.

----------
nosy: +r.david.murray
stage:  -> needs patch
versions: +Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan  8 05:48:27 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 04:48:27 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1389156507.23.0.271068092772.issue11448@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Is there anything that needs to be done to get this patch applied?

It would be nice if this could be committed together with the patch in issue 7776.

----------
nosy: +Nikratio

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

From report at bugs.python.org  Wed Jan  8 05:48:51 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 04:48:51 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1389156531.69.0.0660174042446.issue11448@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


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

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

From report at bugs.python.org  Wed Jan  8 06:13:54 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 05:13:54 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1389158034.37.0.863573372543.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

*ping*

Any comments on the updated patch? Can it be applied?

----------

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

From report at bugs.python.org  Wed Jan  8 06:25:21 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 05:25:21 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1389158720.04.0.379213664377.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Here's a patch that (I think) incorporates all the comments. If someone could apply it, that would be great :-).

----------
keywords: +patch
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33361/issue6627.diff

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

From report at bugs.python.org  Wed Jan  8 06:45:55 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 05:45:55 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1389159955.6.0.362442645084.issue17811@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

I have attached a patch that takes into account your comments. Would this be suitable for inclusion?

----------
keywords: +patch
Added file: http://bugs.python.org/file33362/issue17811.diff

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

From report at bugs.python.org  Wed Jan  8 06:47:22 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 08 Jan 2014 05:47:22 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1389160042.67.0.301957174614.issue17814@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

*ping*

Is this suitable for inclusion? Or do I need to do anything else?

----------

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

From report at bugs.python.org  Wed Jan  8 07:34:27 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jan 2014 06:34:27 +0000
Subject: [docs] [issue20103] Documentation of itertools.accumulate is
	confused
In-Reply-To: <1388592720.87.0.970906154406.issue20103@psf.upfronthosting.co.za>
Message-ID: <1389162867.28.0.68462235166.issue20103@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jan  8 08:19:39 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 08 Jan 2014 07:19:39 +0000
Subject: [docs] [issue20169] random module doc page has broken links
In-Reply-To: <1389135190.46.0.595431802912.issue20169@psf.upfronthosting.co.za>
Message-ID: <1389165579.85.0.721975585401.issue20169@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/issue20169>
_______________________________________

From report at bugs.python.org  Wed Jan  8 23:51:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jan 2014 22:51:47 +0000
Subject: [docs] [issue18011] Inconsistency between b32decode() documentation,
	docstring and code
In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za>
Message-ID: <1389221507.16.0.85622094674.issue18011@psf.upfronthosting.co.za>


R. David Murray added the comment:

For future reference, because this patch changed the type of an error, it should not have been applied to a maintenance release (3.3).  Since the change has already been released in 3.3.3, it is now better not to revert it.

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

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

From report at bugs.python.org  Thu Jan  9 00:00:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 08 Jan 2014 23:00:44 +0000
Subject: [docs] [issue18011] Inconsistency between b32decode() documentation,
	docstring and code
In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za>
Message-ID: <1389222044.49.0.269332675161.issue18011@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not incompatible change because b32decode() already raised this type of an error. Third-party code which use b32decode() was either incorrect (if it catches only TypeError or binascii.Error when any of them could raised) or is not broken by this change.

----------

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

From report at bugs.python.org  Thu Jan  9 00:02:51 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 08 Jan 2014 23:02:51 +0000
Subject: [docs] [issue18011] Inconsistency between b32decode() documentation,
	docstring and code
In-Reply-To: <1368951549.72.0.00589705304437.issue18011@psf.upfronthosting.co.za>
Message-ID: <1389222171.72.0.423974542193.issue18011@psf.upfronthosting.co.za>


R. David Murray added the comment:

But code could be catching TypeError specifically looking for the alphabet error, since that is how it was documented.

----------

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

From report at bugs.python.org  Thu Jan  9 00:56:32 2014
From: report at bugs.python.org (Richard Oudkerk)
Date: Wed, 08 Jan 2014 23:56:32 +0000
Subject: [docs] [issue20153] New-in-3.4 weakref finalizer doc section is
	already out	of date.
In-Reply-To: <1389045523.36.0.692306072283.issue20153@psf.upfronthosting.co.za>
Message-ID: <1389225392.01.0.35241223466.issue20153@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

The following from the docs is wrong:

> ... module globals are no longer forced to None during interpreter 
> shutdown.

Actually, in 3.4 module globals *sometimes* get forced to None during interpreter shutdown, so the version the __del__ method can still raise an exception.

----------

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

From report at bugs.python.org  Thu Jan  9 03:07:02 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 09 Jan 2014 02:07:02 +0000
Subject: [docs] [issue20199] status of module_for_loader and
	utils._module_to_load
Message-ID: <1389233222.57.0.373422642128.issue20199@psf.upfronthosting.co.za>


New submission from R. David Murray:

The whatsnew currently says that module_for_loader is pending deprecation in favor of utils.module_to_load, but there is no such function.  Instead there is a private function utils._module_to_load...even though there is a news entry that claimed that the non-private name was added (but there are no docs for it, nor any associated issue number).

So, importlib experts, can you clean up the docs and/or code please? :)

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 207723
nosy: brett.cannon, docs at python, eric.snow, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: status of module_for_loader and utils._module_to_load
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan  9 04:34:16 2014
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 09 Jan 2014 03:34:16 +0000
Subject: [docs] [issue20200] Argument Clinic howto: custom self_converter
	example	broken
In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za>
Message-ID: <1389238456.77.0.597711702767.issue20200@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, larry
stage:  -> patch review
versions: +Python 3.4

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

From report at bugs.python.org  Thu Jan  9 04:58:32 2014
From: report at bugs.python.org (Eric Snow)
Date: Thu, 09 Jan 2014 03:58:32 +0000
Subject: [docs] [issue20199] status of module_for_loader and
	utils._module_to_load
In-Reply-To: <1389233222.57.0.373422642128.issue20199@psf.upfronthosting.co.za>
Message-ID: <1389239912.6.0.393562391681.issue20199@psf.upfronthosting.co.za>


Eric Snow added the comment:

utils.module_to_load() has been removed (it was introduced in 3.4) and module_for_loader() remains deprecated.  The import machinery now does the work that both functions did, rendering them unnecessary.  I guess I failed to take a look at whatsnew relative all the PEP 451 changes.

----------

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

From report at bugs.python.org  Thu Jan  9 07:47:42 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Thu, 09 Jan 2014 06:47:42 +0000
Subject: [docs] [issue20202] ArgumentClinic howto: document change in
	Py_buffer	lifecycle management
Message-ID: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

Almost didn't catch that PyBuffer_Release isn't needed. Also we need a verb/adjective for applying AC. Cure?

"zlibmodule has already been cured."

----------
assignee: docs at python
components: Documentation
messages: 207728
nosy: docs at python, larry, rmsr
priority: normal
severity: normal
status: open
title: ArgumentClinic howto: document change in Py_buffer lifecycle management
versions: Python 3.4

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

From report at bugs.python.org  Fri Jan 10 02:27:02 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 10 Jan 2014 01:27:02 +0000
Subject: [docs] [issue20200] Argument Clinic howto: custom self_converter
	example	broken
In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za>
Message-ID: <1389317222.04.0.110079811375.issue20200@psf.upfronthosting.co.za>


Larry Hastings added the comment:

LGTM.  Check it in please!

----------

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

From report at bugs.python.org  Fri Jan 10 02:30:09 2014
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 10 Jan 2014 01:30:09 +0000
Subject: [docs] [issue20202] ArgumentClinic howto: document change in
	Py_buffer	lifecycle management
In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>
Message-ID: <1389317409.84.0.406506733077.issue20202@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I've got a bunch of doc improvements in the rollup patch in #20214.  I invite you to give it a review.  If that looks suitable please close this issue.

As for a verb, I've been using "convert".  "zlibmodule has already been converted to work with Argument Clinic".

----------

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

From report at bugs.python.org  Fri Jan 10 04:41:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 10 Jan 2014 03:41:44 +0000
Subject: [docs] [issue20200] Argument Clinic howto: custom self_converter
	example	broken
In-Reply-To: <1389233870.77.0.302352935939.issue20200@psf.upfronthosting.co.za>
Message-ID: <3f0qkH6x7cz7Ljc@mail.python.org>


Roundup Robot added the comment:

New changeset 5a8301002f5a by Zachary Ware in branch 'default':
Closes #20200: Argument Clinic custom converter example should be in a
http://hg.python.org/cpython/rev/5a8301002f5a

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Jan 10 23:46:19 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 10 Jan 2014 22:46:19 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389393979.41.0.313032507698.issue20135@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
title: mutate list -> FAQ need list mutation answers

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

From report at bugs.python.org  Sat Jan 11 12:14:14 2014
From: report at bugs.python.org (Martin Panter)
Date: Sat, 11 Jan 2014 11:14:14 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1389438854.76.0.818199131881.issue17814@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch specifies the stream types are either BufferedReader/Writer, TextIOWrapper, or None. However they can also be plain FileIO in my experience (Python 3.3 with bufsize=0).

Maybe it would be simpler to defer to the documentation for open(), which already mentions the three possible layers of file wrapping. Although, looking at the code just now, the TextIOWrapper is added separately by the ?subprocess? module, and uses write_through=True.

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

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

From report at bugs.python.org  Sat Jan 11 19:25:49 2014
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 11 Jan 2014 18:25:49 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
Message-ID: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/unittest.mock-examples.html#mocking-chained-calls

> Let?s assume the object it returns is ?file-like?, so we?ll ensure that our response object uses the builtin file as its spec.

and

> >>> mock_response = Mock(spec=file)

----------
assignee: docs at python
components: Documentation
messages: 207908
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: unittest.mock-examples doc uses builtin file which is removed in Python 3
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jan 12 00:23:32 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 11 Jan 2014 23:23:32 +0000
Subject: [docs] [issue16508] include the "object" type in the lists of
	documented	types
In-Reply-To: <1353284081.12.0.684350303879.issue16508@psf.upfronthosting.co.za>
Message-ID: <1389482612.07.0.32176063018.issue16508@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/issue16508>
_______________________________________

From report at bugs.python.org  Sun Jan 12 03:20:28 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 12 Jan 2014 02:20:28 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1389493227.84.0.739393588865.issue17814@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Thanks for looking at this Martin! I have attached an updated patch that includes a reference to open and slightly changed language.


But please, let's not have the best be the enemy of the good here. There will probably always be room for further improvement, but if the patch as-is improves over the status quo - can't it just be applied? It's not as if this is the last and only chance to make changes...

----------
versions: +Python 3.1, Python 3.2, Python 3.5
Added file: http://bugs.python.org/file33421/issue17814.patch

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

From report at bugs.python.org  Sun Jan 12 07:25:11 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 12 Jan 2014 06:25:11 +0000
Subject: [docs] [issue20224] C API docs need a clear "defining custom
	extension	types" section
Message-ID: <1389507911.71.0.277009038491.issue20224@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The main C API docs don't clearly explain how to define new types, so people almost always cargo cult an existing legacy type definition instead (I know I do).

The extending and embedding docs have a guide (http://docs.python.org/3/extending/newtypes.html), but that describes the old legacy method based on static type declarations. New code should instead use the dynamic mechanism defined in PEP 384 (http://www.python.org/dev/peps/pep-0384/#type-objects).

See also http://docs.python.org/3/c-api/type.html#PyType_FromSpec

Note that PyType_Spec isn't defined in the C API docs *at all*.

----------
assignee: docs at python
components: Documentation
messages: 207927
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: C API docs need a clear "defining custom extension types" section
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Jan 12 22:44:44 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sun, 12 Jan 2014 21:44:44 +0000
Subject: [docs] [issue20202] ArgumentClinic howto: document change in
	Py_buffer	lifecycle management
In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>
Message-ID: <1389563084.23.0.897244922995.issue20202@psf.upfronthosting.co.za>


Ryan Smith-Roberts added the comment:

Thank you for including the doc change in your other patch. As the grammar was off, instead of just fixing it I naturally rewrote it. Use this patch or just remove the extraneous "for you" as you prefer.

----------
keywords: +patch
Added file: http://bugs.python.org/file33435/argument_clinic_PyBuffer_release.patch

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

From report at bugs.python.org  Sun Jan 12 23:00:14 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 12 Jan 2014 22:00:14 +0000
Subject: [docs] [issue20202] ArgumentClinic howto: document change in
	Py_buffer	lifecycle management
In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>
Message-ID: <1389564014.16.0.382801443208.issue20202@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Fixed in revision 43e109ca9018.  Well, changed anyway, maybe it's still not wonderful text.

----------

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

From report at bugs.python.org  Mon Jan 13 08:16:44 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 07:16:44 +0000
Subject: [docs] [issue20236] Invalid inline markup in xml document.
Message-ID: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/xml.html#xml-vulnerabilities

> DTD retrieval
>     Some XML libraries like Python?s mod:?xml.dom.pulldom? retrieve document

mod: should be :mod:

----------
assignee: docs at python
components: Documentation
messages: 208012
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Invalid inline markup in xml document.
versions: Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon Jan 13 11:13:46 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 10:13:46 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
Message-ID: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/xml.html#defused-packages

"The courses of action are recommended for any server code that parses untrusted XML data."

What this sentence means?
What "The courses" is?

----------
assignee: docs at python
components: Documentation
messages: 208015
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Ambiguous sentence in document of xml package.
versions: Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 16:25:19 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 15:25:19 +0000
Subject: [docs] [issue20241] Bad reference to RFC in document of ipaddress?
Message-ID: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za>


New submission from INADA Naoki:

http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Address.is_unspecified

>     True if the address is unspecified. See RFC 5375 (for IPv4) or RFC 2373 (for IPv6).

RFC 5375 is "IPv6 Unicast Address Assignment Considerations".

----------
assignee: docs at python
components: Documentation
messages: 208027
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Bad reference to RFC in document of ipaddress?
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 13 16:30:55 2014
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 13 Jan 2014 15:30:55 +0000
Subject: [docs] [issue20241] Bad reference to RFC in document of ipaddress?
In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za>
Message-ID: <1389627055.88.0.249608553026.issue20241@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Is it 5735 ?


Next sentence may be wrong, too.

>     True if the address is otherwise IETF reserved.

Is it "True if the address is IETF reserved." ?

----------

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

From songofacandy at gmail.com  Wed Jan  1 14:11:52 2014
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 1 Jan 2014 22:11:52 +0900
Subject: [docs] (no subject)
Message-ID: <CAEfz+Tz81EMuM2=F0=5AbSSZbci=vzhTKdXjk8Dh-J2AAVca6w@mail.gmail.com>

http://docs.python.org/3.3/library/unittest.mock.html#magic-mock

> The two equality method, __eq__ and __ne__, are special. They do the
default equality comparison on identity, using a side effect, unless you
change their return value to return something else:

What "using a side effect" means?

-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140101/5b9bdc5e/attachment-0001.html>

From larry.dawson at gmail.com  Wed Jan  1 19:56:36 2014
From: larry.dawson at gmail.com (Laurence Dawson)
Date: Wed, 1 Jan 2014 12:56:36 -0600
Subject: [docs] Documentation problem: Confusing references to unicode when
 discussing csv
Message-ID: <CAGq1CuZpxRp9sx1SDDmPd5UTEjVGX=pLvdpbvn-OtVXer_YJ7A@mail.gmail.com>

http://docs.python.org/2/library/csv.html first says that Unicode input is
not supported then seems to suggest that UTF-8 is supported. Since the
UTF-8 encoding supports all of unicode, it's not clear what is meant by
saying it doesn't support unicode. Perhaps it means that there is some
specific encoding for unicode that is not supported (UCS-2, UTF-16)?

Can the documentation be updated to differentiate more carefully between
unicode and the encodings that implement it, and to specify which encodings
are not supported?


Thanks,
Larry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140101/96c1d03b/attachment-0001.html>

From relsqui at chiliahedron.com  Thu Jan  2 09:52:24 2014
From: relsqui at chiliahedron.com (Finn Ellis)
Date: Thu, 2 Jan 2014 00:52:24 -0800
Subject: [docs] Typo on
	http://docs.python.org/2/library/userdict.html#module-UserList
Message-ID: <CAAzA5fdXMnTCNJn55QUz90_HSTwp0gq-VshbMJRE7x7H47fPjQ@mail.gmail.com>

"Subclasses of UserList<http://docs.python.org/2/library/userdict.html#module-UserList>
are
expect to offer a constructor"

... probably meant to be "are expected to offer" :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140102/d9bbdc2f/attachment-0001.html>

From robin.zimm at gmail.com  Thu Jan  2 19:37:20 2014
From: robin.zimm at gmail.com (Robin Zimmermann)
Date: Thu, 2 Jan 2014 13:37:20 -0500
Subject: [docs] import.sys behavior in IDLE re: Modules tutorial section 6.2
Message-ID: <CAHQP3uAX_p3YTfvmx8EBYbyH6a+pzrE_Pjhx6-5=ojNFbGKX+Q@mail.gmail.com>

To whom it may concern:

I've been slowly working through the tutorial in the Python v3.3.3
documentation, and I ran into a weird thing with the first example in
Section 6.2 on http://docs.python.org/3/tutorial/modules.html -
"Standard Modules".

The first command-line example block says:

>>> import sys
>>> sys.ps1
'>>> '
>>> sys.ps2
'... '
>>> sys.ps1 = 'C> '
C> print('Yuck!')
Yuck!
C>

I had just opened a new IDLE window*, typed "import sys", hit enter,
then typed "sys.ps1" and hit enter. The Python shell returned the
following error:

----

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    sys.ps1
AttributeError: 'module' object has no attribute 'ps1'

----

In my confusion, I tried a couple more times; the transcript of
everyhing following the above AttributeError follows:

----

>>> ps1
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    ps1
NameError: name 'ps1' is not defined
>>> sys.ps1
Traceback (most recent call last):
  File "<pyshell#3>", line 1, in <module>
    sys.ps1
AttributeError: 'module' object has no attribute 'ps1'
>>> dir sys
SyntaxError: invalid syntax
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', '__loader__',
'__name__', '__package__', '__stderr__', '__stdin__', '__stdout__',
'_clear_type_cache', '_current_frames', '_debugmallocstats',
'_getframe', '_home', '_mercurial', '_xoptions', 'api_version',
'argv', 'base_exec_prefix', 'base_prefix', 'builtin_module_names',
'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook',
'dllhandle', 'dont_write_bytecode', 'exc_info', 'excepthook',
'exec_prefix', 'executable', 'exit', 'flags', 'float_info',
'float_repr_style', 'getcheckinterval', 'getdefaultencoding',
'getfilesystemencoding', 'getprofile', 'getrecursionlimit',
'getrefcount', 'getsizeof', 'getswitchinterval', 'gettrace',
'getwindowsversion', 'hash_info', 'hexversion', 'implementation',
'int_info', 'intern', 'last_traceback', 'last_type', 'last_value',
'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks',
'path_importer_cache', 'platform', 'prefix', 'setcheckinterval',
'setprofile', 'setrecursionlimit', 'setswitchinterval', 'settrace',
'stderr', 'stdin', 'stdout', 'thread_info', 'version', 'version_info',
'warnoptions', 'winver']

----

Finally, without closing the IDLE window, I opened the Command Prompt**:

----

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Packbat>python
Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.ps1
'>>> '
>>>

----

My best guess is that IDLE is not a perfectly faithful implementation
of the command line; if this is the case, I feel it would be helpful
either to modify the tutorial to note this explicitly or to contact
the developers of IDLE regarding the discrepancy, if not both.

Thank you for your time and trouble!
- Robin Zimmermann

----

Footnotes:

* I had accidentally opened two IDLE windows, and closed one before
continuing, if that would be relevant; that said, when I closed the
program, reopened it, and typed the same commands, the error message
was the same.

** I am running the 32-bit version of Windows 7 Professional, Service
Pack 1, on an HP ProBook 4525s; I can give you more hardware
information if it would be relevant.

From hernan.grecco at gmail.com  Mon Jan  6 04:06:56 2014
From: hernan.grecco at gmail.com (Hernan Grecco)
Date: Mon, 6 Jan 2014 01:06:56 -0200
Subject: [docs] Upgrade to Sphinx 1.2
Message-ID: <CAL6gwWXUzyY-w16DdytN3k765+w5tzui_T60iMHEqWYoPGBRsQ@mail.gmail.com>

Hi,

Not really an error but a suggestion. A year ago, I suggested
improving the search results in the Python Documentation. I am not
going through all the arguments again, you can see the thread here
[0]. For this purpose, I contributed some patches to Sphinx which are
included in Sphinx 1.2 (released last month). It will be great if you
could upgrade the docs in docs.python.org to the new sphinx. It makes
using the docs much easier, specially for newbies. See the comparison
here [1]

thanks for your hard work,

cheers,

Hern?n

[0] https://groups.google.com/forum/#!msg/python-ideas/Xxb4PiTWS3g/ft8w1UftYZ0J
[1] http://hgrecco.github.io/searchpydocs/

From xiaofeng_tan at live.com  Mon Jan  6 18:41:32 2014
From: xiaofeng_tan at live.com (Xiaofeng Tan)
Date: Tue, 7 Jan 2014 01:41:32 +0800
Subject: [docs] Why not have a complete python language reference manual
	describes?
Message-ID: <BAY406-EAS13382C6B28CEDDA96DC00F792B60@phx.gbl>

Dear Python developers,

I am a Chinese college student, I want to learn Python programming language,
but I can't find a documentation about the Python for a complete description
in your website. Python is so popular in China.

I am looking forward to your website can provide Python manual. The same as
PHP manual. Thanks!

 

Form Huanggang Normal University, Huanggang Hubei China.

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

From lauri.hakko at gmail.com  Tue Jan  7 13:34:29 2014
From: lauri.hakko at gmail.com (Lauri Hakko)
Date: Tue, 7 Jan 2014 14:34:29 +0200
Subject: [docs] Typo in upcoming python 3.4 documentation
Message-ID: <CA+6w6z61OC6NWBn7XYO2uNTsyWjj+mSsizOS8W+2xd-Z1-qdsg@mail.gmail.com>

http://docs.python.org/3.4/whatsnew/3.4.html#http

On this page on http paragraph, the new option is said to be "exaplain"
although it should be "explain"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140107/2dec7f86/attachment.html>

From riekanddoug at gmail.com  Wed Jan  8 02:59:25 2014
From: riekanddoug at gmail.com (Doug and Riekie Dorman)
Date: Tue, 07 Jan 2014 17:59:25 -0800
Subject: [docs] Section 4.7.1
Message-ID: <52CCB0FD.3060101@gmail.com>

I am having problems with the example in 4.7.1.  Attached is code with 
comments explaining my problems.

Doug Dorman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ask_ok.py
Type: text/x-python
Size: 943 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20140107/c1a49a73/attachment.py>

From danl at wolfram.com  Mon Jan 13 18:00:28 2014
From: danl at wolfram.com (Daniel Lichtblau)
Date: Mon, 13 Jan 2014 11:00:28 -0600
Subject: [docs] possible dox bug in floating point tutorial
Message-ID: <52D41BAC.4090505@wolfram.com>

(I'm not sure if this is a bug but it seems mysterious.)

http://docs.python.org/2.6/tutorial/floatingpoint.html

Mentions that 0.1, under the hood, is a fairly long decimal.
Specifically:
"On most machines, if Python were to print the true
decimal value of the binary approximation stored for 0.1, it would have to
display

>>>0.1
0.1000000000000000055511151231257827021181583404541015625

instead!"

This seems to be too long for any hardware floating point representation,
even quad. Also the length of that decimal string is 54. While that's not
quite as suspicious as 53, it still makes one wonder if that should be
the length of the corresponding display for a binary representation.

Daniel Lichtblau
Wolfram Research


From fran.bull at gmail.com  Mon Jan 13 19:13:17 2014
From: fran.bull at gmail.com (Fran Bull)
Date: Mon, 13 Jan 2014 10:13:17 -0800
Subject: [docs] How to volunteer?
Message-ID: <CAKk3E5-Wgb8vdaqM9uDqtyYdwa-ryX-mD+ONkpsmtj5PLzjbEQ@mail.gmail.com>

Hello!

I would like to help contribute to the Python docs. Are you accepting
volunteers? This page http://docs.python.org/3.2/about.html says
'Development of the documentation and its toolchain takes place on the
docs at python.org mailing list. We?re always looking for volunteers wanting
to help with the docs, so feel free to send a mail there!'

For example I would propose fixes for this bug
http://bugs.python.org/issue20237 like this:

The paragraph in question reads:

'defusedxml is a pure Python package with modified subclasses of all stdlib
XML parsers that prevent any potentially malicious operation. The courses
of action are recommended for any server code that parses untrusted XML
data. The package also ships with example exploits and an extended
documentation on more XML exploits like xpath injection.'

The complaint is:

'"The courses of action are recommended for any server code that parses
untrusted XML data."

What this sentence means?
What "The courses" is?'

It seems that the original author was either trying to say that:

a) The courses of action that defusedxml implements are those recommended
for any server code that parses untrusted XML data.
or
b) Using defused XML is recommended for any server code that parses
untrusted XML data.

I think b) is more likely. I'd choose a less passive form like:

'You should use defusedxml for any server code that parses untrusted XML
data.'

although I would imagine there's a style guide that would inform that. I
would also restructure the paragraph to make this sentence the first, to
emphasize it. Also there is an extraneous 'an' in the last sentence. So my
proposed fixed paragraph would be:

'You should use defusedxml for any server code that parses untrusted XML
data. defusedxml is a pure Python package with modified subclasses of all
stdlib XML parsers that prevent any potentially malicious operation. The
package also ships with example exploits and extended documentation on more
XML exploits like xpath injection.'

I don't have a lot of time, but I would like to help when I can. Let me
know if and how.

Thanks!

Fran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140113/ca4a5007/attachment.html>

From report at bugs.python.org  Mon Jan 13 19:46:47 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jan 2014 18:46:47 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>
Message-ID: <1389638807.73.0.0612632939363.issue20237@psf.upfronthosting.co.za>


R. David Murray added the comment:

It means that the package suggests what courses of action to take when parsing untrusted data.  I don't know how it goes about doing that, though, so we'll have to ask Christian to clarify.

----------
assignee: docs at python -> 
nosy: +christian.heimes, r.david.murray

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

From report at bugs.python.org  Mon Jan 13 19:47:29 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jan 2014 18:47:29 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>
Message-ID: <1389638849.15.0.816183410938.issue20237@psf.upfronthosting.co.za>


R. David Murray added the comment:

s/courses of action/kinds of actions/ in my explanation, otherwise it might be just as confusing :)

----------

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

From report at bugs.python.org  Mon Jan 13 19:57:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 13 Jan 2014 18:57:46 +0000
Subject: [docs] [issue20236] Invalid inline markup in xml document.
In-Reply-To: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za>
Message-ID: <3f33vt0Z4RzQPC@mail.python.org>


Roundup Robot added the comment:

New changeset fb1dd44d1f76 by R David Murray in branch '3.3':
#20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/fb1dd44d1f76

New changeset 60163fc72017 by R David Murray in branch 'default':
Merge #20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/60163fc72017

New changeset 3481c6f36e55 by R David Murray in branch '2.7':
#20236: Fix sphinx markup.
http://hg.python.org/cpython/rev/3481c6f36e55

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

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

From report at bugs.python.org  Mon Jan 13 20:00:46 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 13 Jan 2014 19:00:46 +0000
Subject: [docs] [issue20236] Invalid inline markup in xml document.
In-Reply-To: <1389597404.75.0.92024373365.issue20236@psf.upfronthosting.co.za>
Message-ID: <1389639646.91.0.00390162099259.issue20236@psf.upfronthosting.co.za>


R. David Murray added the comment:

Fixed, thanks.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From zachary.ware+pydocs at gmail.com  Mon Jan 13 22:53:27 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 13 Jan 2014 15:53:27 -0600
Subject: [docs] Print Command
In-Reply-To: <SNT145-W638DBACECD28B51D7DE813D3CC0@phx.gbl>
References: <SNT145-W638DBACECD28B51D7DE813D3CC0@phx.gbl>
Message-ID: <CAKJDb-NQOLMMqo6g--9EAVbbP0wOaz92V6bhG=sf6QEkwQiz9w@mail.gmail.com>

On Fri, Dec 27, 2013 at 6:33 PM, Camil Kassar <camikasi at msn.com> wrote:
> IN Topic 2 and Topic 3, (maybe later topics) print commands are missing
> parenthesis, for example:
>
>>>> i = 256*256
>>>> print 'The value of i is', i
> The value of i is 65536
>
> Should be
>
>>>> i = 256*256
>>>> print ('The value of i is', i)
> The value of i is 65536

Which version of the docs are you looking at?  It looks to me like
you're using the docs for Python 2.6 or 2.7.  One of the major changes
between Python 2 and Python 3 was the switching of 'print' from a
statement to a function.  In Python 2, since print is a statement, no
parentheses are required (and thus should not be present in the docs).
 In Python 3, the parentheses are required since it is a function call
like any other.

Thanks for checking, though!

--
Zach

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

From zachary.ware+pydocs at gmail.com  Mon Jan 13 23:09:59 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 13 Jan 2014 16:09:59 -0600
Subject: [docs] Typo in upcoming python 3.4 documentation
In-Reply-To: <CA+6w6z61OC6NWBn7XYO2uNTsyWjj+mSsizOS8W+2xd-Z1-qdsg@mail.gmail.com>
References: <CA+6w6z61OC6NWBn7XYO2uNTsyWjj+mSsizOS8W+2xd-Z1-qdsg@mail.gmail.com>
Message-ID: <CAKJDb-P6YORhzH9c3Zjp3DY4weMfHWJaPkYcFi=2W0j1PL50mw@mail.gmail.com>

On Tue, Jan 7, 2014 at 6:34 AM, Lauri Hakko <lauri.hakko at gmail.com> wrote:
> http://docs.python.org/3.4/whatsnew/3.4.html#http
>
> On this page on http paragraph, the new option is said to be "exaplain"
> although it should be "explain"
>

Thanks for the report!  This has been fixed in revision d2366d910386
and will be live soon.

-- 
Zach

From report at bugs.python.org  Tue Jan 14 01:12:40 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 00:12:40 +0000
Subject: [docs] [issue20202] ArgumentClinic howto: document change in
	Py_buffer	lifecycle management
In-Reply-To: <1389250062.45.0.978565094508.issue20202@psf.upfronthosting.co.za>
Message-ID: <1389658359.97.0.787644251974.issue20202@psf.upfronthosting.co.za>


Ryan Smith-Roberts added the comment:

Even more imperative than my version. Excellent!

----------
status: open -> closed

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

From zachary.ware+pydocs at gmail.com  Tue Jan 14 03:40:38 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 13 Jan 2014 20:40:38 -0600
Subject: [docs] Typo on
	http://docs.python.org/2/library/userdict.html#module-UserList
In-Reply-To: <CAAzA5fdXMnTCNJn55QUz90_HSTwp0gq-VshbMJRE7x7H47fPjQ@mail.gmail.com>
References: <CAAzA5fdXMnTCNJn55QUz90_HSTwp0gq-VshbMJRE7x7H47fPjQ@mail.gmail.com>
Message-ID: <CAKJDb-MbsCiNyre0Pz6HVmgePb5cOWQ74d5fTWHnkC5yoREC-Q@mail.gmail.com>

On Thu, Jan 2, 2014 at 2:52 AM, Finn Ellis <relsqui at chiliahedron.com> wrote:
> "Subclasses of UserList are expect to offer a constructor"
>
> ... probably meant to be "are expected to offer" :)
>

Thanks for the report!  This has been fixed in revision 2631d33ee7fb
and will be live soon.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Tue Jan 14 03:57:54 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Mon, 13 Jan 2014 20:57:54 -0600
Subject: [docs] How to volunteer?
In-Reply-To: <CAKk3E5-Wgb8vdaqM9uDqtyYdwa-ryX-mD+ONkpsmtj5PLzjbEQ@mail.gmail.com>
References: <CAKk3E5-Wgb8vdaqM9uDqtyYdwa-ryX-mD+ONkpsmtj5PLzjbEQ@mail.gmail.com>
Message-ID: <CAKJDb-NfWAENKzyuaCFhoEhV-3sqpAVeHizdp8AhfE5Ro8LRSw@mail.gmail.com>

Hi Fran,

On Mon, Jan 13, 2014 at 12:13 PM, Fran Bull <fran.bull at gmail.com> wrote:
> Hello!
>
> I would like to help contribute to the Python docs. Are you accepting
> volunteers?

Always!

> This page http://docs.python.org/3.2/about.html says
> 'Development of the documentation and its toolchain takes place on the
> docs at python.org mailing list. We?re always looking for volunteers wanting to
> help with the docs, so feel free to send a mail there!'

Those directions are somewhat misleading.  Everything stated there is
true (and your mails here are certainly welcome), but development
really just happens on the bug tracker.

> For example I would propose fixes for this bug
> http://bugs.python.org/issue20237 like this:

The best course of action is to sign up for a tracker account and add
a message (and/or attach a patch) to that issue.  You may want to take
a look through the devguide (http://docs.python.org/devguide), it will
help you get set up and ready to create a patch.

> The paragraph in question reads:
>
> 'defusedxml is a pure Python package with modified subclasses of all stdlib
> XML parsers that prevent any potentially malicious operation. The courses of
> action are recommended for any server code that parses untrusted XML data.
> The package also ships with example exploits and an extended documentation
> on more XML exploits like xpath injection.'
>
> The complaint is:
>
> '"The courses of action are recommended for any server code that parses
> untrusted XML data."
>
> What this sentence means?
> What "The courses" is?'
>
> It seems that the original author was either trying to say that:
>
> a) The courses of action that defusedxml implements are those recommended
> for any server code that parses untrusted XML data.
> or
> b) Using defused XML is recommended for any server code that parses
> untrusted XML data.
>
> I think b) is more likely. I'd choose a less passive form like:
>
> 'You should use defusedxml for any server code that parses untrusted XML
> data.'
>
> although I would imagine there's a style guide that would inform that.

There is a chapter in the devguide devoted to documentation and
documentation fixes.

> I would also restructure the paragraph to make this sentence the first, to
> emphasize it. Also there is an extraneous 'an' in the last sentence. So my
> proposed fixed paragraph would be:
>
> 'You should use defusedxml for any server code that parses untrusted XML
> data. defusedxml is a pure Python package with modified subclasses of all
> stdlib XML parsers that prevent any potentially malicious operation. The
> package also ships with example exploits and extended documentation on more
> XML exploits like xpath injection.'

Everything above is a good basis for a message to add to the tracker issue.

> I don't have a lot of time, but I would like to help when I can. Let me know
> if and how.

Your contributions are certainly welcome!  I hope I've been of some
help in pointing you the right direction.  If you have more questions,
feel free to send them here (docs at python.org).  You may also be
interested in the core-mentorship mailing list, which is intended to
be a friendly place to get answers to any and all questions pertaining
to the development of Python (including its documentation) with
non-public archives.

Welcome to Python!

--
Zach

From hernan.grecco at gmail.com  Tue Jan 14 00:51:46 2014
From: hernan.grecco at gmail.com (Hernan Grecco)
Date: Mon, 13 Jan 2014 21:51:46 -0200
Subject: [docs] Upgrade to Sphinx 1.2
In-Reply-To: <CAL6gwWXUzyY-w16DdytN3k765+w5tzui_T60iMHEqWYoPGBRsQ@mail.gmail.com>
References: <CAL6gwWXUzyY-w16DdytN3k765+w5tzui_T60iMHEqWYoPGBRsQ@mail.gmail.com>
Message-ID: <CAL6gwWU_nzSqpHmGzn64fCVSvuN1-hChEbRuKyDP4SfTjFu4tA@mail.gmail.com>

Hi,

I have just seen that you have updated docs.python.org to Sphinx 1.2 Thanks!

cheers,

Hernan

On Mon, Jan 6, 2014 at 12:06 AM, Hernan Grecco <hernan.grecco at gmail.com> wrote:
> Hi,
>
> Not really an error but a suggestion. A year ago, I suggested
> improving the search results in the Python Documentation. I am not
> going through all the arguments again, you can see the thread here
> [0]. For this purpose, I contributed some patches to Sphinx which are
> included in Sphinx 1.2 (released last month). It will be great if you
> could upgrade the docs in docs.python.org to the new sphinx. It makes
> using the docs much easier, specially for newbies. See the comparison
> here [1]
>
> thanks for your hard work,
>
> cheers,
>
> Hern?n
>
> [0] https://groups.google.com/forum/#!msg/python-ideas/Xxb4PiTWS3g/ft8w1UftYZ0J
> [1] http://hgrecco.github.io/searchpydocs/

From report at bugs.python.org  Tue Jan 14 04:14:05 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 03:14:05 +0000
Subject: [docs] [issue20248] docs: socket.recvmsg{,
	_into} are keword-compatible
Message-ID: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

The docs indicate their arguments are positional-only. Trivial patch attached.

----------
assignee: docs at python
components: Documentation
files: docs_socket_recvmsg_args.patch
keywords: patch
messages: 208067
nosy: docs at python, rmsr
priority: normal
severity: normal
status: open
title: docs: socket.recvmsg{,_into} are keword-compatible
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33454/docs_socket_recvmsg_args.patch

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

From report at bugs.python.org  Tue Jan 14 04:16:46 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 03:16:46 +0000
Subject: [docs] [issue20248] docs: socket.recvmsg{,
	_into} are keword-compatible
In-Reply-To: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za>
Message-ID: <1389669405.98.0.219451564681.issue20248@psf.upfronthosting.co.za>


Ryan Smith-Roberts added the comment:

Never mind, it's actually recvfrom{,_into}. Sigh.

----------
status: open -> closed

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

From report at bugs.python.org  Tue Jan 14 04:45:11 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 14 Jan 2014 03:45:11 +0000
Subject: [docs] [issue20248] docs: socket.recvmsg{,
	_into} are keword-compatible
In-Reply-To: <1389669245.17.0.020040143215.issue20248@psf.upfronthosting.co.za>
Message-ID: <1389671111.14.0.198243914445.issue20248@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <bp+pybugs at benjamin-peterson.org>:


----------
resolution:  -> invalid

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

From report at bugs.python.org  Tue Jan 14 06:45:29 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Tue, 14 Jan 2014 05:45:29 +0000
Subject: [docs] [issue20252] Argument Clinic howto: small typo in y#
	translation
Message-ID: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za>


New submission from Ryan Smith-Roberts:

type -> types

----------
assignee: docs at python
components: Documentation
files: argument_clinic_howto_y-hash.patch
keywords: patch
messages: 208076
nosy: docs at python, larry, rmsr
priority: normal
severity: normal
status: open
title: Argument Clinic howto: small typo in y# translation
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33458/argument_clinic_howto_y-hash.patch

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

From report at bugs.python.org  Tue Jan 14 06:59:52 2014
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 14 Jan 2014 05:59:52 +0000
Subject: [docs] [issue20252] Argument Clinic howto: small typo in y#
	translation
In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za>
Message-ID: <1389679192.11.0.34195521538.issue20252@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Same bug for 'y' too.  Will fix in a patch probably Tuesday.  Thanks for pointing it out!

----------

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

From report at bugs.python.org  Tue Jan 14 07:29:21 2014
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 14 Jan 2014 06:29:21 +0000
Subject: [docs] [issue20253] Typo in ipaddress document
Message-ID: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za>


New submission from INADA Naoki:

> http://docs.python.org/3.3/library/ipaddress.html#ipaddress.IPv4Network.broadcast_address

Wrong attribute name: s/host mask/hostmask/

----------
assignee: docs at python
components: Documentation
messages: 208078
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Typo in ipaddress document
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Tue Jan 14 07:31:26 2014
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 14 Jan 2014 06:31:26 +0000
Subject: [docs] [issue20253] Typo in ipaddress document
In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za>
Message-ID: <1389681086.69.0.334376664375.issue20253@psf.upfronthosting.co.za>


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


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

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

From georg at python.org  Tue Jan 14 09:01:00 2014
From: georg at python.org (Georg Brandl)
Date: Tue, 14 Jan 2014 09:01:00 +0100
Subject: [docs] How to volunteer?
In-Reply-To: <CAKJDb-NfWAENKzyuaCFhoEhV-3sqpAVeHizdp8AhfE5Ro8LRSw@mail.gmail.com>
References: <CAKk3E5-Wgb8vdaqM9uDqtyYdwa-ryX-mD+ONkpsmtj5PLzjbEQ@mail.gmail.com>
 <CAKJDb-NfWAENKzyuaCFhoEhV-3sqpAVeHizdp8AhfE5Ro8LRSw@mail.gmail.com>
Message-ID: <52D4EEBC.90906@python.org>

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

Am 14.01.2014 03:57, schrieb Zachary Ware:
> Hi Fran,
> 
> On Mon, Jan 13, 2014 at 12:13 PM, Fran Bull <fran.bull at gmail.com> wrote:
>> Hello!
>> 
>> I would like to help contribute to the Python docs. Are you accepting 
>> volunteers?
> 
> Always!
> 
>> This page http://docs.python.org/3.2/about.html says 'Development of the
>> documentation and its toolchain takes place on the docs at python.org
>> mailing list. We?re always looking for volunteers wanting to help with
>> the docs, so feel free to send a mail there!'
> 
> Those directions are somewhat misleading.  Everything stated there is true
> (and your mails here are certainly welcome), but development really just
> happens on the bug tracker.

True, and we could also direct to core-mentorship. Se #20255.

Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLU7rwACgkQN9GcIYhpnLDNdwCffZu/7KQ03pgzIo1Agx7QlNlZ
eO8AoIeyj+TRks1H6QyW897Xf9c908LN
=yBfg
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Jan 14 09:05:16 2014
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 14 Jan 2014 08:05:16 +0000
Subject: [docs] [issue20241] Bad reference to RFC in document of ipaddress?
In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za>
Message-ID: <1389686716.19.0.301186867571.issue20241@psf.upfronthosting.co.za>


Georg Brandl added the comment:

5735 seems to be correct (see docstring of is_unspecified), although it doesn't talk about "unspecified".

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

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

From lucia.casati at italyseo.com  Tue Jan 14 07:16:34 2014
From: lucia.casati at italyseo.com (Lucia Casati)
Date: Tue, 14 Jan 2014 06:16:34 +0000
Subject: [docs] Scambi di Link - Traffico Vero Gratis
Message-ID: <3f3MsB4xpMzQkT@mail.python.org>


Salve,





Il mio nome &egrave; Lucia,





Vorrei suggerire uno scambio di link gratuito con docs.python.it o con qualunque altro sito di cui lei sia in possesso.


Le far&agrave; piacere sapere che sto lavorando su un ventaglio di progetti di qualit&agrave; per lo scambio di link gratuiti e che sono sicuro che questo scambio possa essere fruttuoso e produttivo per entrambi.





La prego di farmi sapere se &egrave; interessato ad avere pi&ugrave; dettagli, o se ha qualche opinione da riferirmi in materia.





Attendo una sua mail!





Lucia Casati


http://www.italyseo.com/

http://it.linkedin.com/pub/lucia-casati/84/393/92b


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140114/21ed5359/attachment.html>

From davidpesta at gmail.com  Tue Jan 14 12:36:40 2014
From: davidpesta at gmail.com (David Pesta)
Date: Tue, 14 Jan 2014 05:36:40 -0600
Subject: [docs] Misspelled word in tutorial introduction
Message-ID: <CAKFM0AHBjfExZrOV65-tQt-tOkw1y+y4Jb5RHTu5z7Ksog69iQ@mail.gmail.com>

On this page:
http://docs.python.org/3/tutorial/introduction.html

There is no such word "numberic" and should be "numeric" instead.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140114/9d08263a/attachment.html>

From davidpesta at gmail.com  Tue Jan 14 12:53:37 2014
From: davidpesta at gmail.com (David Pesta)
Date: Tue, 14 Jan 2014 05:53:37 -0600
Subject: [docs] Grammar
Message-ID: <CAKFM0AEF=A5OeDQNv=vZL9hj-B+upCCUPjWwGd0UH8iyiFWkLQ@mail.gmail.com>

On this page:
http://docs.python.org/3/tutorial/introduction.html

With Python is possible to use the ** operator to calculate powers

"With Python" is an introductory element, so add a comma and the word "it,"
like so:

With Python, it is possible to use the ** operator to calculate powers

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140114/08cd2fca/attachment.html>

From zachary.ware+pydocs at gmail.com  Tue Jan 14 15:43:33 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 14 Jan 2014 08:43:33 -0600
Subject: [docs] Grammar
In-Reply-To: <CAKFM0AEF=A5OeDQNv=vZL9hj-B+upCCUPjWwGd0UH8iyiFWkLQ@mail.gmail.com>
References: <CAKFM0AEF=A5OeDQNv=vZL9hj-B+upCCUPjWwGd0UH8iyiFWkLQ@mail.gmail.com>
Message-ID: <CAKJDb-O6XbS9WhrJHEC8VCFexptpSOY9rr6TsorL5YWoh3VxMQ@mail.gmail.com>

On Tue, Jan 14, 2014 at 5:53 AM, David Pesta <davidpesta at gmail.com> wrote:
> On this page:
> http://docs.python.org/3/tutorial/introduction.html
>
> With Python is possible to use the ** operator to calculate powers
>
> "With Python" is an introductory element, so add a comma and the word "it,"
> like so:
>
> With Python, it is possible to use the ** operator to calculate powers
>
> Thanks!

Thanks for the report!  This has been fixed in revision 59c7a23d5549
and will be live soon.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Tue Jan 14 15:46:46 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 14 Jan 2014 08:46:46 -0600
Subject: [docs] Misspelled word in tutorial introduction
In-Reply-To: <CAKFM0AHBjfExZrOV65-tQt-tOkw1y+y4Jb5RHTu5z7Ksog69iQ@mail.gmail.com>
References: <CAKFM0AHBjfExZrOV65-tQt-tOkw1y+y4Jb5RHTu5z7Ksog69iQ@mail.gmail.com>
Message-ID: <CAKJDb-OogpMvx8NhfwPxUNtOgLUTywyf+pO8nN+siPd8nYUkjw@mail.gmail.com>

On Tue, Jan 14, 2014 at 5:36 AM, David Pesta <davidpesta at gmail.com> wrote:
> On this page:
> http://docs.python.org/3/tutorial/introduction.html
>
> There is no such word "numberic" and should be "numeric" instead.
>
> Thanks!

Thanks for the report!  This has been fixed in revision 3be65ed4fbe8
and will be live soon.

-- 
Zach

From zachary.ware+pydocs at gmail.com  Tue Jan 14 15:53:32 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 14 Jan 2014 08:53:32 -0600
Subject: [docs] Scambi di Link - Traffico Vero Gratis
In-Reply-To: <3f3MsB4xpMzQkT@mail.python.org>
References: <3f3MsB4xpMzQkT@mail.python.org>
Message-ID: <CAKJDb-N_vfdGNAJAkq3y3dtk-Cfr2uZUg2wQK5mmpkOuRF-QYg@mail.gmail.com>

2014/1/14 Lucia Casati <lucia.casati at italyseo.com>:
> Salve,
>
> Il mio nome ? Lucia,
>
> Vorrei suggerire uno scambio di link gratuito con docs.python.it o con
> qualunque altro sito di cui lei sia in possesso.
> Le far? piacere sapere che sto lavorando su un ventaglio di progetti di
> qualit? per lo scambio di link gratuiti e che sono sicuro che questo scambio
> possa essere fruttuoso e produttivo per entrambi.
>
> La prego di farmi sapere se ? interessato ad avere pi? dettagli, o se ha
> qualche opinione da riferirmi in materia.
>
> Attendo una sua mail!

Hi Lucia,

This is an English list, and as such I wouldn't expect much response
unless you repost in English.  Sorry for the inconvenience.

(Bad automatic translation:)
(Bad traduzione automatica:)

Ciao Lucia,

Questa ? una lista inglese, e come tale non mi aspetto molto di
risposta a meno che non ripubblicare in inglese. Ci scusiamo per
l'inconveniente.

-- 
Zach

From report at bugs.python.org  Tue Jan 14 16:10:58 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 14 Jan 2014 15:10:58 +0000
Subject: [docs] [issue20253] Typo in ipaddress document
In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za>
Message-ID: <3f3Zqk0N57z7LnS@mail.python.org>


Roundup Robot added the comment:

New changeset 4f8ad9a4193f by Zachary Ware in branch '3.3':
Issue #20253: Fixed a typo in the ipaddress docs that advertised an
http://hg.python.org/cpython/rev/4f8ad9a4193f

New changeset 2f54b55fcbfa by Zachary Ware in branch 'default':
Closes #20253: Merge typo fix
http://hg.python.org/cpython/rev/2f54b55fcbfa

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 14 16:11:27 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 14 Jan 2014 15:11:27 +0000
Subject: [docs] [issue20253] Typo in ipaddress document
In-Reply-To: <1389680961.29.0.254286053987.issue20253@psf.upfronthosting.co.za>
Message-ID: <1389712287.03.0.126220797208.issue20253@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Thanks for the report!

----------
assignee: docs at python -> zach.ware

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

From report at bugs.python.org  Tue Jan 14 19:03:49 2014
From: report at bugs.python.org (Fran Bull)
Date: Tue, 14 Jan 2014 18:03:49 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>
Message-ID: <1389722629.17.0.990673059099.issue20237@psf.upfronthosting.co.za>


Fran Bull added the comment:

I think the sentence either means:
1) The courses of action that defusedxml implements are those recommended for any server code that parses untrusted XML data. 
or 
2) Using defused XML is recommended for any server code that parses untrusted XML data. 

And I think 2 is more likely. So the attached patch reflects that.

----------
keywords: +patch
nosy: +Fran.Bull
Added file: http://bugs.python.org/file33465/20237.patch

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

From report at bugs.python.org  Tue Jan 14 19:29:15 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 14 Jan 2014 18:29:15 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>
Message-ID: <1389724155.93.0.268474650338.issue20237@psf.upfronthosting.co.za>


R. David Murray added the comment:

Actually, I think it means that the defusedxml documentation tells you what to do to protect yourself from various attack vectors, which pretty much amounts to importing certain functions from defusedxml and using them instead of the stdlib versions.  Your patch may be sufficient, but let's see what Christian has to say.

----------

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

From report at bugs.python.org  Tue Jan 14 20:46:07 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Jan 2014 19:46:07 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
Message-ID: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

I've been debugging a crash in nose 1.3.0, the root cause of which turned out to be an instance containing an attribute which itself was an instance of the following class (boiled down):

class Picky:
    def __getstate__(self):
        return {}
    def __getattr__(self, attr):
        return None

This crashes with a TypeError in Python 2.7 and Python 3 (albeit with slightly different tracebacks; and Python 3 is more difficult to debug because the TypeError doesn't include any useful information).

TypeError: 'NoneType' object is not callable

The culprit is __getattr__() returning None.  In Python 3 for example, pickle tries to get the object's __reduce_ex__() function and then call it.

The problem is the (IMHO) bogus __getattr__() and I'm not sure why nose has this.  But I wonder if the pickle documentation should warn against this kind of thing.

This isn't a bug in Python - the crash makes sense when you understand the implications, but perhaps a warning in the docs would have helped prevent this nose bug in the first place.  I suppose I could also see improving _pickle.c to provide some additional feedback on the offending attribute, but that's probably more difficult.

It's okay to close this as won't fix if we can't think of appropriate wording.  It's enough that there's a record of this issue for search engines now.

----------
assignee: docs at python
components: Documentation
messages: 208108
nosy: barry, docs at python
priority: normal
severity: normal
status: open
title: Cannot pickle some objects that have a __getattr__()
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/issue20261>
_______________________________________

From report at bugs.python.org  Tue Jan 14 20:54:44 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 14 Jan 2014 19:54:44 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>
Message-ID: <1389729284.21.0.174760794096.issue20261@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Hmm, actually, this is a regression in Python 3.4.  Let's amend the test class to include a __getnewargs__():

class Picky(object):
    """Options container that returns None for all options.
    """
    def __getstate__(self):
        return {}

    def __getnewargs__(self):
        return ()

    def __getattr__(self, attr):
        return None

This class is picklable in Python 2.7 - 3.3, but not in 3.4.

----------
components: +Library (Lib)
keywords: +3.4regression

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

From report at bugs.python.org  Tue Jan 14 23:32:29 2014
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Tue, 14 Jan 2014 22:32:29 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>
Message-ID: <1389738749.68.0.293165981946.issue20261@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Jan 15 00:06:49 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 14 Jan 2014 23:06:49 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>
Message-ID: <1389740809.97.0.917945826695.issue20261@psf.upfronthosting.co.za>


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


----------
nosy: +alexandre.vassalotti, pitrou

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

From report at bugs.python.org  Wed Jan 15 04:41:05 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Jan 2014 03:41:05 +0000
Subject: [docs] [issue20265] Bring Doc/using/windows up to date
Message-ID: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Doc/using/windows still mentions DOS, Windows 3.x, and Python 2.1, and that's just in the first short section.  This is a catch-all issue for making sure that page is up to date.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 208136
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring Doc/using/windows up to date
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed Jan 15 05:00:49 2014
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 15 Jan 2014 04:00:49 +0000
Subject: [docs] [issue20266] Bring Doc/faq/windows up to date
Message-ID: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The Python on Windows faq could use some TLC.  For instance, cx_Freeze should be mentioned in the faq about creating an executable (and py2exe should either mention that it doesn't quite support 3.x yet, or just be removed until it does), and the embedding faq should be cleaned up with proper voice and formatting (and the "undocumented facts" should be documented).

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 208138
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Bring Doc/faq/windows up to date
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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

From zachary.ware+pydocs at gmail.com  Wed Jan 15 05:04:50 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Tue, 14 Jan 2014 22:04:50 -0600
Subject: [docs] Environment Variable Documentation Clarification Needed
In-Reply-To: <CADcJtySmbyAKKcEjxjegGL=rk3zVX+EydJHK2kkyh6vWoYMp0A@mail.gmail.com>
References: <CADcJtySmbyAKKcEjxjegGL=rk3zVX+EydJHK2kkyh6vWoYMp0A@mail.gmail.com>
Message-ID: <CAKJDb-MsKhpMzyh98N8UZ2ny5121cvaZYWO9=vfgzSo5MoV4cQ@mail.gmail.com>

Hi Jeff,

On Sat, Dec 28, 2013 at 2:20 AM, Jeff Bradley <jbradley5000 at gmail.com> wrote:
> On this page: http://docs.python.org/2/using/windows.html#setting-envvars
>
> the instructions mention a pythonpath environment variable (which led me to
> believe I need to create that environment variable).  I wasn't able to get
> this to work.  What did work was adding the following to the end of the
> existing Path variable:
> ;C:\Python27\;C:\Python27\Scripts\

This issue is touched on in the following section:
http://docs.python.org/2/using/windows.html#finding-the-python-executable

PYTHONPATH is a variable used by Python itself, while adding
C:\Python27 to PATH is what makes Windows able to find python.exe when
you ask for it at the command line.

That whole page could stand a good update, though; I've just created
issue 20265 to do just that (http://bugs.python.org/issue20265)

> Once I closed and reopened command prompt, windows recognized the python
> command.

That's the usual with Windows.  You can temporarily make Python
findable with `set PATH=%PATH%;C:\Python27`, but it won't last past a
command prompt restart until you find and fiddle with the Environment
Variables config dialog.

> The path variable is mentioned here: http://docs.python.org/2/faq/windows,
> however I would suggest editing the faq page to say, "Add the following to
> the end of the PATH environment variable:
> ;C:\Python27\;C:\Python27\Scripts\".

That page could also use some care, hence issue 20266
(http://bugs.python.org/issue20266).

Thanks for bringing those pages to attention!

--
Zach

From report at bugs.python.org  Wed Jan 15 06:24:04 2014
From: report at bugs.python.org (Eric Snow)
Date: Wed, 15 Jan 2014 05:24:04 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>
Message-ID: <1389763444.37.0.322002027451.issue20261@psf.upfronthosting.co.za>


Eric Snow added the comment:

This is a duplicate of #16251, no?  Pickle looks up dunder ;) methods on instances rather than on classes, so __getattr__() gets triggered unexpectedly.  I had to work around this in some code of mine by special-casing in __getattr__() names that start with '_'.  I've said my peace over in #16251.

----------
nosy: +eric.snow

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

From riekanddoug at gmail.com  Wed Jan 15 05:48:55 2014
From: riekanddoug at gmail.com (Doug and Riekie Dorman)
Date: Tue, 14 Jan 2014 20:48:55 -0800
Subject: [docs] 4.7.5
Message-ID: <52D61337.5050007@gmail.com>

>>>pairs  =  [(1,  'one'),  (2,  'two'),  (3,  'three'),  (4,  'four')]
>>>pairs.sort(key=lambda  pair:  pair[1])
>>>pairs
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

Should be:

>>>pairs  =  [(1,  'one'),  (2,  'two'),  (3,  'three'),  (4,  'four')]
>>>pairs.sort(key=lambda  pairs:  pairs[1])
>>>pairs
[(4, 'four'), (1, 'one'), (3, 'three'), (2, 'two')]

Doug

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

From g.brandl-nospam at gmx.net  Wed Jan 15 09:13:49 2014
From: g.brandl-nospam at gmx.net (g.brandl-nospam at gmx.net)
Date: Wed, 15 Jan 2014 09:13:49 +0100 (CET)
Subject: [docs] 4.7.5
In-Reply-To: <52D61337.5050007@gmail.com>
References: <52D61337.5050007@gmail.com>
Message-ID: <trinity-028f01c3-ae26-412a-a11b-46689477f569-1389773629310@3capp-gmx-bs44>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140115/5b365622/attachment.html>

From report at bugs.python.org  Wed Jan 15 16:06:37 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 15 Jan 2014 15:06:37 +0000
Subject: [docs] [issue20261] Cannot pickle some objects that have a
	__getattr__()
In-Reply-To: <1389728767.16.0.141259686696.issue20261@psf.upfronthosting.co.za>
Message-ID: <1389798397.81.0.549939592011.issue20261@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'll go ahead and dupe this to 16251, but will note the __getnewargs__() regression in 3.4.

----------
superseder:  -> pickle special methods are looked up on the instance rather than the type

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

From zachary.ware+pydocs at gmail.com  Wed Jan 15 17:25:34 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 15 Jan 2014 10:25:34 -0600
Subject: [docs] Section 4.7.1
In-Reply-To: <52CCB0FD.3060101@gmail.com>
References: <52CCB0FD.3060101@gmail.com>
Message-ID: <CAKJDb-O_oUtcycm6C3QSvKa4ms-mw1dUng38gLBtKtuULw5SoA@mail.gmail.com>

On Tue, Jan 7, 2014 at 7:59 PM, Doug and Riekie Dorman
<riekanddoug at gmail.com> wrote:
> I am having problems with the example in 4.7.1.  Attached is code with
> comments explaining my problems.
>
> Doug Dorman

Hi Doug,

First off, the example is correct, and this is not the best list for
asking how it works.  A better choice would be either
python-list at python.org or tutor at python.org.  That said, I'll still try
to help you here :).

For simplicity, I've quoted your attached code inline, and will
respond within it.

> def ask_ok(prompt, retries=4, complaint = 'Yes or no, please!'):
>     while True:
>         ok = raw_input(prompt)
>              print ok, retries

The above line would give you a syntax error; 'print' is indented
farther than 'ok'.  Whitespace is important in Python, but it's easy
to get right (if you end a line with a colon, the next line needs to
be indented more.  If you don't, the next line should be at the same
level or less indented if the previous block is finished).  Also,
mixing tabs and spaces for indentation is a recipe for disaster.
Since you can't actually see spaces or tabs, two lines may look lined
up when in reality they are at different indentation levels.

>         if ok in ('y', 'ye', 'yes'):
>             return True
>         if ok in ('n', 'no', 'nop', 'nope'):
>             return False
>         retries = retries - 1
>         print retries
>         if retries < 0:
>             raise IOError('refusenik user')
> #        print complaint
>             print complaint

This line would never execute, since it is after a raise statement in
the same block.  'raise' will raise an exception and divert execution,
in this case completely out of the function.  It needs to be outside
the if block, so that if the user's response is not 'yes' or 'no' and
there are still retries left, the 'complaint' message will be printed.

> # I can't get this function to work, if I am guessing correctly what
> # is trying to do.

What do you expect it to do?

> At one point it was refusing to understand what
> # IOError was supposed to be doing.  Finally, it goes through the
> # while just once and quits.

What do you mean by these statements?  How did you call the function,
what did you expect to happen, and what output did you get?

> # Is indentation the ONLY way to indicate the end of a while loop?

Yes and no.  Yes, the only way to indicate the end of the code to be
looped over by the 'while' statement is by indentation.  No, you can
use the 'break' statement to end execution of the loop at any time.
See http://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops.
 You can also raise an exception (like the "raise IOError('refusenik
user')" line above), or, if your while loop is inside a function,
return a value.

> # I changed the commented print complaint statement to the one
> # below it and at least we go through the loop just once.  But
> # then we get:
>
> #Traceback (most recent call last):
> #  File "<stdin>", line 1, in <module>
> #  File "<stdin>", line 12, in ask_ok

This tells me that you were working with this function in the
interactive interpreter, the `>>>` prompt.  That is a great tool for
learning and playing with new things, but it can be very easy for
typos to slip into things as long as this function's definition.  I
would suggest defining the function in a file, then importing it at
the interactive interpreter.  Assuming you're on Windows, try
something like this, after copying and pasting the example directly
into a file (like example.py):

C:\tmp>type example.py
def ask_ok(prompt, retries=4, complaint='Yes or no, please!'):
    while True:
        ok = raw_input(prompt)
        if ok in ('y', 'ye', 'yes'):
            return True
        if ok in ('n', 'no', 'nop', 'nope'):
            return False
        retries = retries - 1
        if retries < 0:
            raise IOError('refusenik user')
        print complaint

C:\tmp>c:\python27\python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
>>> import example
>>> example.ask_ok('Yes or no? ')
Yes or no? y
True
>>> example.ask_ok('Yep or nope? ')
Yep or nope? n
False
>>> example.ask_ok('No or yes? ', 1)
No or yes? a
Yes or no, please!
No or yes? b
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "example.py", line 10, in ask_ok
 IOError: refusenik user
>>>

> #IOError: refusenik user

This IOError is expected, it's raised by the "raise IOError('refusenik
user')" line when retries drops below 0.

I hope I've been of some help.  If you have any more questions, I
would suggest sending an email to tutor at python.org, which is another
mailing list that has several highly experienced and friendly
Pythonistas listening in, ready and willing to help.

Regards,

-- 
Zach

From report at bugs.python.org  Wed Jan 15 19:07:09 2014
From: report at bugs.python.org (Fran Bull)
Date: Wed, 15 Jan 2014 18:07:09 +0000
Subject: [docs] [issue20241] Bad reference to RFC in document of ipaddress?
In-Reply-To: <1389626719.4.0.511378840941.issue20241@psf.upfronthosting.co.za>
Message-ID: <1389809229.03.0.641144594368.issue20241@psf.upfronthosting.co.za>


Fran Bull added the comment:

http://tools.ietf.org/html/rfc5735.html
Special Use IPv4 Addresses

does indeed agree with the docstring

    @property
    def is_unspecified(self):
        """Test if the address is unspecified.

        Returns:
            A boolean, True if this is the unspecified address as defined in
            RFC 5735 3.

        """
        unspecified_address = IPv4Address('0.0.0.0')
        return self == unspecified_address

and makes more sense than http://tools.ietf.org/html/rfc5375.html
IPv6 Unicast Address Assignment Considerations

and so the attached patch will bring them into line.

However it's worth noting that the RFC doesn't say anything about 0.0.0.0 being the 'unspecified' address, (the RFC linked for the IPv6 is_unspecified http://tools.ietf.org/html/rfc2373.html#section-2.5.2 does specifically call it the 'unspecified' address). 5735 3 just says:

3.  Global and Other Specialized Address Blocks

   0.0.0.0/8 - Addresses in this block refer to source hosts on "this"
   network.  Address 0.0.0.0/32 may be used as a source address for this
   host on this network; other addresses within 0.0.0.0/8 may be used to
   refer to specified hosts on this network ([RFC1122], Section
   3.2.1.3).

googling it you can find eg this:

http://en.wikipedia.org/wiki/IPv6_address
says:
 ::/128 ? The address with all zero bits is called the unspecified address (corresponding to 0.0.0.0/32 in IPv4).

so perhaps this bit of the docs could be a bit clearer, although I don't know what it should say, perhaps something like:
'Checks if the address is 0.0.0.0 which corresponds to the unspecified address in IPv6'
someone with better networking knowledge than me could say.

----------
keywords: +patch
nosy: +Fran.Bull
Added file: http://bugs.python.org/file33482/20241.patch

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

From report at bugs.python.org  Wed Jan 15 20:59:37 2014
From: report at bugs.python.org (SilentGhost)
Date: Wed, 15 Jan 2014 19:59:37 +0000
Subject: [docs] [issue20272] chain.from_iterable in the overview table not
	linking to	the function
Message-ID: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za>


New submission from SilentGhost:

chain.from_iterable is not linkified in the overview table at the top of the itertools docs. The patch requires reformat of the table.

----------
assignee: docs at python
components: Documentation
files: linkify.diff
keywords: patch
messages: 208184
nosy: SilentGhost, docs at python, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: chain.from_iterable in the overview table not linking to the function
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file33484/linkify.diff

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

From report at bugs.python.org  Wed Jan 15 21:00:45 2014
From: report at bugs.python.org (SilentGhost)
Date: Wed, 15 Jan 2014 20:00:45 +0000
Subject: [docs] [issue20272] chain.from_iterable in the overview table not
	linking to	the function
In-Reply-To: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za>
Message-ID: <1389816045.96.0.961604549288.issue20272@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jan 16 10:11:32 2014
From: report at bugs.python.org (Richard Philips)
Date: Thu, 16 Jan 2014 09:11:32 +0000
Subject: [docs] [issue20278] Wrong URL to the pysqlite web page
Message-ID: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za>


New submission from Richard Philips:

The reference to the pysqlite web page on:

    http://docs.python.org/3.4/library/sqlite3.html

should be:

    https://github.com/ghaering/pysqlite

----------
assignee: docs at python
components: Documentation
messages: 208261
nosy: Richard.Philips, docs at python
priority: normal
severity: normal
status: open
title: Wrong URL to the pysqlite web page
versions: Python 3.4

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

From report at bugs.python.org  Thu Jan 16 14:25:51 2014
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 16 Jan 2014 13:25:51 +0000
Subject: [docs] [issue20280] add "predicate" to the glossary
Message-ID: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za>


New submission from Florent Xicluna:

This term is used in various places in the documentation.
http://docs.python.org/dev/search.html?q=predicate

Probably it deserves an entry in the glossary, even if it is not specific to Python:
http://en.wikipedia.org/wiki/Predicate_%28mathematical_logic%29

----------
assignee: docs at python
components: Documentation
messages: 208277
nosy: docs at python, flox
priority: low
severity: normal
status: open
title: add "predicate" to the glossary
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Jan 16 15:53:30 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Jan 2014 14:53:30 +0000
Subject: [docs] [issue20278] Wrong URL to the pysqlite web page
In-Reply-To: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za>
Message-ID: <3f4pLd2M52z7Lk1@mail.python.org>


Roundup Robot added the comment:

New changeset b73b35d1c58d by Benjamin Peterson in branch '3.3':
update pysqlite website (closes #20278)
http://hg.python.org/cpython/rev/b73b35d1c58d

New changeset 40289a03569f by Benjamin Peterson in branch '2.7':
update pysqlite website (closes #20278)
http://hg.python.org/cpython/rev/40289a03569f

New changeset e6ecbdb794a9 by Benjamin Peterson in branch 'default':
merge 3.3 (#20278)
http://hg.python.org/cpython/rev/e6ecbdb794a9

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jan 16 15:54:28 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 16 Jan 2014 14:54:28 +0000
Subject: [docs] [issue20278] Wrong URL to the pysqlite web page
In-Reply-To: <1389863492.56.0.743244372152.issue20278@psf.upfronthosting.co.za>
Message-ID: <1389884068.37.0.967071729437.issue20278@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Done. Of course, the Python version of sqlite hasn't been updated in ages (and has probably diverged!), so it might not be that relevant anymore.

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

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

From report at bugs.python.org  Thu Jan 16 16:10:35 2014
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 16 Jan 2014 15:10:35 +0000
Subject: [docs] [issue20272] chain.from_iterable in the overview table not
	linking to	the function
In-Reply-To: <1389815977.04.0.427053880301.issue20272@psf.upfronthosting.co.za>
Message-ID: <3f4pkM089Fz7Ln5@mail.python.org>


Roundup Robot added the comment:

New changeset aa88c8265e94 by Benjamin Peterson in branch '3.3':
linkify chain.from_iterable (closes #20272)
http://hg.python.org/cpython/rev/aa88c8265e94

New changeset 58cac9967cf0 by Benjamin Peterson in branch 'default':
merge 3.3 (#20272)
http://hg.python.org/cpython/rev/58cac9967cf0

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From peter.broecker at uni-koeln.de  Thu Jan 16 09:56:28 2014
From: peter.broecker at uni-koeln.de (=?ISO-8859-1?Q?Peter_Br=F6cker?=)
Date: Thu, 16 Jan 2014 09:56:28 +0100
Subject: [docs] Wrong sample config file for custom module installation?
Message-ID: <52D79EBC.1040009@uni-koeln.de>

Hi,

I have tried to set up the distutils config files for a custom module
installation. Using the suggested snippet  from

http://docs.python.org/2/install/

[install]
install-base=$HOME/python
install-purelib=lib
install-platlib=lib.$PLAT
install-scripts=scripts
install-data=data did not work for me.

Instead, I had to add install-headers and additionally modify all paths
to include $base:

[install]
install-base=/some/dir
install-purelib=$base/lib
install-platlib=$base/lib.$PLAT
install-scripts=$base/scripts
install-headers=$base/include
install-data=$base/data


I'm unsure if this is actually a bug, but I could only resolve this with
the help of this answer on stackoverflow:
http://stackoverflow.com/a/12768721

Best regards,
Peter

From report at bugs.python.org  Thu Jan 16 16:44:12 2014
From: report at bugs.python.org (Christian Aichinger)
Date: Thu, 16 Jan 2014 15:44:12 +0000
Subject: [docs] [issue6128] Consequences of using Py_TPFLAGS_HAVE_GC are
	incompletely	explained
In-Reply-To: <1243457336.14.0.579311647458.issue6128@psf.upfronthosting.co.za>
Message-ID: <1389887052.13.0.301820792404.issue6128@psf.upfronthosting.co.za>


Christian Aichinger added the comment:

I concur that this aspect of writing Python types in C/C++ needs better
documentation. For a new extension writer (like me), it is not obvious when
PyObject_GC_Track/PyObject_GC_UnTrack must be called or not. Similarly, it is
not clear from the current documentation how to ensure that memory is allocated
with PyObject_GC_New.

The gcsupport documentation suffers from being written from the perspective
of the GC, instead of the perspective of extension writers. Thus, I've attached
a patch that tries to shed some light on how to correctly write types
implementing cyclic GC support.

I'd appreciate comments/editing suggestions/advice and would welcome the patch
to go into Python in some form. I myself consider the change to be trivial, but
if necessary I can sign the contributor agreement.

--
PS: Informal explanation about what's really going on:

The Python GC code deals with memory allocation, not with initialization in any
way. For most extension types, allocation is handled by tp_alloc which is
called typically called from tp_new (either the default tp_new or your own
tp_new handler).

The default tp_alloc (PyType_GenericAlloc()) looks at tp_flags, and if
Py_TPFLAGS_HAVE_GC is specified, it uses the appropriate GC malloc function and
calls _PyObject_GC_TRACK when finished). Thus, if you allocate your memory via
tp_alloc, and don't override the tp_alloc handler, you've just fulfilled the
GC's constructor requirements.

Similarly, the GC doesn't care about object destruction. It cares about freeing
memory, that is tp_free, NOT tp_dealloc! Again, if you don't intentionally
provide a custom tp_free handler, the default one will take care to obey the GC
rules.

Thus, most extension writers can get away with 4 simple rules:
* Set Py_TPFLAGS_HAVE_GC in tp_flags.
* Do not specify tp_alloc or tp_free.
* Make sure your object actually allocates it's memory via tp_alloc.
  Three possibilities to achieve this:
    + Do not add a tp_new handler, or
    + Call tp_alloc from your tp_new handler, or
    + Call a base class's tp_new from your own tp_new handler
* Implement tp_traverse and tp_clear. They are usually straight-forward.

And if you really do want a custom allocator, you're screwed anyway, as the
last part of my patch hints at. Custom memory management is just not compatible with the GC at this point.

----------
keywords: +patch
nosy: +Greek0
versions: +Python 3.5
Added file: http://bugs.python.org/file33497/gcsupport-doc.diff

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

From report at bugs.python.org  Thu Jan 16 19:46:55 2014
From: report at bugs.python.org (Fran Bull)
Date: Thu, 16 Jan 2014 18:46:55 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389898015.91.0.299532701045.issue20135@psf.upfronthosting.co.za>


Fran Bull added the comment:

I read the FAQ last night and I couldn't see these answered there either. I would like to try submitting a patch for this one, probably this evening. It will likely be two FAQs in the programming section that go something like:

Why does changing one list change another different list?
This happens:
>>> a = [1, 2, 3]
>>> b = a
>>> b.append(4)
>>> print a
[1, 2, 3, 4]

because variables are just names for things, in this case 'a' is the list we first defined and then b = a says that 'b' is also a name for that list. They are both the same list.

Why are my default args wrong?
This happens:

>>> from datetime import datetime
>>> class A(object):
...   def __init__(self, created_time=datetime.now()):
...     self.created_time = created_time
... 
>>> an_a = A()
>>> another_a = A()
>>> an_a.created_time
datetime.datetime(2014, 1, 16, 10, 40, 54, 33283)
>>> another_a.created_time
datetime.datetime(2014, 1, 16, 10, 40, 54, 33283)

because default arguments are evaluated when they're read for the first time by the interpreter. Usually when the class is imported. A good way to get the above to do what you want is to use a default argument of None and check for it, like:
>>> class B(object):
...   def __init__(self, created_time=None):
...     if created_time is None:
...       created_time=datetime.now()
...     self.created_time = created_time
... 
>>> a_b = B()
>>> another_b = B()
>>> a_b.created_time
datetime.datetime(2014, 1, 16, 10, 44, 44, 956710)
>>> another_b.created_time
datetime.datetime(2014, 1, 16, 10, 44, 51, 71311)

Feedback appreciated, particularly I'm not sure if this:
'default arguments are evaluated when they're read for the first time by the interpreter'
is exactly the right language. I guess I'll look it up.

----------
nosy: +Fran.Bull

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

From report at bugs.python.org  Thu Jan 16 20:06:21 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jan 2014 19:06:21 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389899181.72.0.33025317289.issue20281@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please see the footnote on the 'time' documentation page.  It sounds like Windows is treating %z as if was %Z.

There should be a reference to that footnote from the %z table entry, so that's a doc bug.  Might also be worth explicitly mentioning this weird Windows behavior.

FYI, you can use the strftime functionality of the datetime module to get cross platform %z support.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray
stage:  -> needs patch
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Thu Jan 16 20:14:19 2014
From: report at bugs.python.org (Mike Owens)
Date: Thu, 16 Jan 2014 19:14:19 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389899658.98.0.657381766289.issue20281@psf.upfronthosting.co.za>


Mike Owens added the comment:

Documentation doesn't have a foot note for either %z or %Z but there is generic footnote talking about C lib behavior and that %z is deprecated. I guess if there were a foot note in the table for %z that would save some time for everyone.

----------

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

From report at bugs.python.org  Thu Jan 16 20:26:00 2014
From: report at bugs.python.org (Mike Owens)
Date: Thu, 16 Jan 2014 19:26:00 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389900359.98.0.413085356483.issue20281@psf.upfronthosting.co.za>


Mike Owens added the comment:

The datetime.strftime function produces no output for %z or %Z. Very irritating.

----------

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

From report at bugs.python.org  Thu Jan 16 20:29:50 2014
From: report at bugs.python.org (SilentGhost)
Date: Thu, 16 Jan 2014 19:29:50 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389900590.87.0.451756829383.issue20281@psf.upfronthosting.co.za>


SilentGhost added the comment:

Mike, the note is at the very bottom of the page.

datetime.strftime produces empty strings with this specifiers for na?ve objects, are the object you're testing timezone-aware?

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Thu Jan 16 21:25:43 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jan 2014 20:25:43 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389903943.79.0.34105734447.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for working on this.

Technically, defaults are evaluated when the 'def' statement is executed, which is normally, but not always, at the time that the module is first imported (counterexample: nested function definitions).

The answer should also explicitly cover the more common mistake made with default keyword values of passing a mutable object and having it get persistently modified,and the question phrasing should reflect that.  The datetime example is a great first example before getting to the more common one, though.

----------

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

From report at bugs.python.org  Thu Jan 16 21:31:56 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 16 Jan 2014 20:31:56 +0000
Subject: [docs] [issue20280] add "predicate" to the glossary
In-Reply-To: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za>
Message-ID: <1389904316.24.0.163318112486.issue20280@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-0 To me, this seems like unnecessary noise.  The more random entries we add to the glossary, the less usable it becomes.  There are many computing terms that could be added such as "recursion", "stack overflow", "buffer", "header", "packet", "basic block", "token", "sentinel", "codec", "callback", etc.  We could add all of those but it wouldn't make the glossary better; it would just make it bigger.

The current glossary strikes pretty good balance but could stand a little pruning here and there (i.e. remove the entry for "complex number" and trim the "parameter" entry back to a sentence or two).

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

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

From report at bugs.python.org  Thu Jan 16 21:36:08 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jan 2014 20:36:08 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389904568.95.0.743121185601.issue20281@psf.upfronthosting.co.za>


R. David Murray added the comment:

The %z table entry exists only in the 3.4 (dev) docs, not the 3.3 docs.  There is no doc change needed for 3.3, since it doesn't mention %z except in the footnote.

And yes, I should have mentioned that the datetime versions only work with aware timezones.  You can get an aware local time from email.utils.localtime().  (This localtime function may eventually move to
the datetime module if it can be made more reliable, but it works fine for the use cases the email package needs.)

----------

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

From report at bugs.python.org  Thu Jan 16 21:39:15 2014
From: report at bugs.python.org (Mike Owens)
Date: Thu, 16 Jan 2014 20:39:15 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389904755.1.0.2126216458.issue20281@psf.upfronthosting.co.za>


Mike Owens added the comment:

I'm looking right at the 3.3 docs right now. %z is in the table. 

8.1.8. strftime() and strptime() Behavior

----------

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

From report at bugs.python.org  Thu Jan 16 21:41:26 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 16 Jan 2014 20:41:26 +0000
Subject: [docs] [issue20281] time.strftime %z format specifier is the same
	as %Z
In-Reply-To: <1389897342.88.0.737767593135.issue20281@psf.upfronthosting.co.za>
Message-ID: <1389904886.46.0.900374419219.issue20281@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, you are correct.  I'm not sure what page I was looking at before.  Maybe I hadn't switched away from the python2 page.

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

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

From report at bugs.python.org  Thu Jan 16 22:09:24 2014
From: report at bugs.python.org (Fran Bull)
Date: Thu, 16 Jan 2014 21:09:24 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389906564.87.0.386392793936.issue20135@psf.upfronthosting.co.za>


Fran Bull added the comment:

Perhaps a 3rd FAQ something like this?:

Why is changing a list in one instance of a class also changing it in another instance of the same class?
This happens:
>>> class A(object):
...   def __init__(self, fruit=[]):
...     self.fruit = fruit
... 
>>> an_A = A()
>>> an_A.fruit.append('apple')
>>> another_A = A()
>>> print another_A.fruit
['apple']
>>> another_A.fruit.append('banana')
>>> print another_A.fruit
['apple', 'banana']
>>> print an_A.fruit
['apple', 'banana']
>>> print an_A.fruit is another_A.fruit
True
>>> print an_A.fruit is A().fruit
True

because of a combination of the above two FAQs, first the default argument is evaluated when the 'def' statement is executed and creates an instance of list. After that new instances of A have a variable 'fruit' that is the name for that instance of list.

I'm not sure whether I should be using as general terms as possible for the Q, i.e. 'mutable object' instead of 'list'. I'll reread http://docs.python.org/devguide/documenting.html and the FAQs before writing the patch.

----------

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

From report at bugs.python.org  Fri Jan 17 03:29:07 2014
From: report at bugs.python.org (Reuben Garrett)
Date: Fri, 17 Jan 2014 02:29:07 +0000
Subject: [docs] [issue8557] subprocess PATH semantics and portability
In-Reply-To: <1272451494.53.0.273790888777.issue8557@psf.upfronthosting.co.za>
Message-ID: <1389925747.28.0.8050926997.issue8557@psf.upfronthosting.co.za>


Changes by Reuben Garrett <reubengarrett at gmail.com>:


----------
nosy: +RubyTuesdayDONO

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

From report at bugs.python.org  Fri Jan 17 06:26:14 2014
From: report at bugs.python.org (Fran Bull)
Date: Fri, 17 Jan 2014 05:26:14 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389936374.01.0.673265709605.issue20135@psf.upfronthosting.co.za>


Changes by Fran Bull <fran.bull at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file33502/20135.patch

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

From report at bugs.python.org  Fri Jan 17 15:27:45 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 17 Jan 2014 14:27:45 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389968865.84.0.272449944373.issue20135@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

http://docs.python.org/3/faq/design.html#why-are-default-values-shared-between-objects

----------
nosy: +ezio.melotti

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

From damir.hakimov at gmail.com  Fri Jan 17 13:26:32 2014
From: damir.hakimov at gmail.com (Damir Hakimov)
Date: Fri, 17 Jan 2014 16:26:32 +0400
Subject: [docs] py2exe in Python3.3 documentation
Message-ID: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>

Hello all!

Is it correct to place py2exe in Python3.3 documentation?
http://docs.python.org/3.3/using/windows.html#py2exe

Does py2exe support Python3.3?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140117/56d9ffc6/attachment.html>

From zachary.ware+pydocs at gmail.com  Fri Jan 17 15:37:45 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 17 Jan 2014 08:37:45 -0600
Subject: [docs] py2exe in Python3.3 documentation
In-Reply-To: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>
References: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>
Message-ID: <CAKJDb-Mj7TWSPAM=DLz6utWiEC8YrX1tROgc8LMLD4mebwmdBQ@mail.gmail.com>

Hi, Damir

On Fri, Jan 17, 2014 at 6:26 AM, Damir Hakimov <damir.hakimov at gmail.com> wrote:
> Hello all!
>
> Is it correct to place py2exe in Python3.3 documentation?
> http://docs.python.org/3.3/using/windows.html#py2exe
>
> Does py2exe support Python3.3?

It does not, and there is an open issue
(http://bugs.python.org/issue20266) that will include fixing that
mention of py2exe.

There is an in-development version of py2exe for Python 3 called
'py3exe', but I don't know the status of it for sure beyond it not
having been released.  As an alternative, you can try cx_Freeze
(http://cx-freeze.sourceforge.net/), which I have had some success
with.

Regards,

-- 
Zach

From report at bugs.python.org  Fri Jan 17 16:00:46 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jan 2014 15:00:46 +0000
Subject: [docs] [issue20266] Bring Doc/faq/windows up to date
In-Reply-To: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za>
Message-ID: <3f5QSY6Mnvz7Lkb@mail.python.org>


Roundup Robot added the comment:

New changeset c9706c13a005 by Zachary Ware in branch '3.3':
Issue #20266: Update parts of the Windows FAQ
http://hg.python.org/cpython/rev/c9706c13a005

New changeset 3cb048463ea7 by Zachary Ware in branch 'default':
Issue #20266: Merge with 3.3
http://hg.python.org/cpython/rev/3cb048463ea7

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

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

From report at bugs.python.org  Fri Jan 17 16:36:16 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 17 Jan 2014 15:36:16 +0000
Subject: [docs] [issue20135] FAQ need list mutation answers
In-Reply-To: <1388979444.45.0.0357103143169.issue20135@psf.upfronthosting.co.za>
Message-ID: <1389972976.48.0.497244613063.issue20135@psf.upfronthosting.co.za>


R. David Murray added the comment:

I *thought* there was a FAQ entry for that.  Didn't think to look for it in the design section though :(.  Nor is the title likely to catch the eye of someone wondering why their default argument modifications are being unexpectedly persistent.  Also, the fact that it starts out with the sentence "This type of bug commonly bites neophyte programmers" is, IMO, a clue it should be in the programming section.

----------

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

From report at bugs.python.org  Fri Jan 17 18:24:30 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 17 Jan 2014 17:24:30 +0000
Subject: [docs] [issue20266] Bring Doc/faq/windows up to date
In-Reply-To: <1389758449.02.0.48240700444.issue20266@psf.upfronthosting.co.za>
Message-ID: <1389979470.08.0.639734284329.issue20266@psf.upfronthosting.co.za>


Mark Lawrence added the comment:

The faq doesn't mention the new launcher for Windows.  Rather than write too much I'd simply cross reference this http://docs.python.org/3/using/windows.html#python-launcher-for-windows.  I think this also impacts on the section "How do I make Python scripts executable?".

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

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

From damir.hakimov at gmail.com  Fri Jan 17 19:40:33 2014
From: damir.hakimov at gmail.com (Damir Hakimov)
Date: Fri, 17 Jan 2014 22:40:33 +0400
Subject: [docs] py2exe in Python3.3 documentation
In-Reply-To: <CAKJDb-Mj7TWSPAM=DLz6utWiEC8YrX1tROgc8LMLD4mebwmdBQ@mail.gmail.com>
References: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>
 <CAKJDb-Mj7TWSPAM=DLz6utWiEC8YrX1tROgc8LMLD4mebwmdBQ@mail.gmail.com>
Message-ID: <CABCbbCyTYFmUjkPeADdaz3Ar1jEvzgAEVwFDQQZ_MEkLsca2Mw@mail.gmail.com>

Thanks a lot!
But the question was about including link to not working package py2exe in
Python3 documentation.

>> As an alternative, you can try cx_Freeze
I can't :(  cx_Freeze create exe, which not running on win2k.


On Fri, Jan 17, 2014 at 6:37 PM, Zachary Ware <zachary.ware+pydocs at gmail.com
> wrote:

> Hi, Damir
>
> On Fri, Jan 17, 2014 at 6:26 AM, Damir Hakimov <damir.hakimov at gmail.com>
> wrote:
> > Hello all!
> >
> > Is it correct to place py2exe in Python3.3 documentation?
> > http://docs.python.org/3.3/using/windows.html#py2exe
> >
> > Does py2exe support Python3.3?
>
> It does not, and there is an open issue
> (http://bugs.python.org/issue20266) that will include fixing that
> mention of py2exe.
>
> There is an in-development version of py2exe for Python 3 called
> 'py3exe', but I don't know the status of it for sure beyond it not
> having been released.  As an alternative, you can try cx_Freeze
> (http://cx-freeze.sourceforge.net/), which I have had some success
> with.
>
> Regards,
>
> --
> Zach
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140117/c06a2e20/attachment-0001.html>

From zachary.ware+pydocs at gmail.com  Fri Jan 17 22:04:00 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 17 Jan 2014 15:04:00 -0600
Subject: [docs] py2exe in Python3.3 documentation
In-Reply-To: <CABCbbCyTYFmUjkPeADdaz3Ar1jEvzgAEVwFDQQZ_MEkLsca2Mw@mail.gmail.com>
References: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>
 <CAKJDb-Mj7TWSPAM=DLz6utWiEC8YrX1tROgc8LMLD4mebwmdBQ@mail.gmail.com>
 <CABCbbCyTYFmUjkPeADdaz3Ar1jEvzgAEVwFDQQZ_MEkLsca2Mw@mail.gmail.com>
Message-ID: <CAKJDb-Mr11nC4vqGOYOVEBk18hrJvswfC6p38EqaQerfAmpFSg@mail.gmail.com>

On Fri, Jan 17, 2014 at 12:40 PM, Damir Hakimov <damir.hakimov at gmail.com> wrote:
> Thanks a lot!
> But the question was about including link to not working package py2exe in
> Python3 documentation.

Ahh, I misread your link and missed that there's another place that
mentions py2exe.  That will be fixed shortly.

>> As an alternative, you can try cx_Freeze
> I can't :(  cx_Freeze create exe, which not running on win2k.

What do you mean?  I have used cx_Freeze successfully with Python 3.2,
creating executables on Windows XP and 7 and running those executables
on Win2k without issue.  cx_Freeze for Python 3.3 will not work with
Win2k, because support for Win2k was dropped in Python 3.3.  If you
have to support Win2k, you'll have to stick with Python 3.2.

Hope this helps,

-- 
Zach

From report at bugs.python.org  Fri Jan 17 22:24:53 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 17 Jan 2014 21:24:53 +0000
Subject: [docs] [issue20265] Bring Doc/using/windows up to date
In-Reply-To: <1389757265.26.0.116885263001.issue20265@psf.upfronthosting.co.za>
Message-ID: <3f5Zzm0bKgz7LjN@mail.python.org>


Roundup Robot added the comment:

New changeset fc52b657bcd9 by Zachary Ware in branch '3.3':
Issue #20265: Updated some parts of the Using Windows document.
http://hg.python.org/cpython/rev/fc52b657bcd9

New changeset 5a9171e70573 by Zachary Ware in branch 'default':
Issue #20265: Merge with 3.3
http://hg.python.org/cpython/rev/5a9171e70573

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

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

From report at bugs.python.org  Sat Jan 18 00:39:13 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jan 2014 23:39:13 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>
Message-ID: <1390001953.19.0.318394413741.issue20222@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think /file/open/ would work.

----------
nosy: +michael.foord, terry.reedy

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

From report at bugs.python.org  Sat Jan 18 00:56:41 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 17 Jan 2014 23:56:41 +0000
Subject: [docs] [issue20237] Ambiguous sentence in document of xml package.
In-Reply-To: <1389608026.69.0.492339232238.issue20237@psf.upfronthosting.co.za>
Message-ID: <1390003001.7.0.756185941286.issue20237@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I took the sentence to mean 1) more that 2). I agree that it should be revised.

----------
nosy: +terry.reedy
versions:  -Python 3.2

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

From report at bugs.python.org  Sat Jan 18 03:46:15 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 18 Jan 2014 02:46:15 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1390013175.48.0.980568387703.issue12704@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/issue12704>
_______________________________________

From report at bugs.python.org  Sat Jan 18 03:48:24 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 18 Jan 2014 02:48:24 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1390013304.67.0.181001519198.issue17814@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/issue17814>
_______________________________________

From report at bugs.python.org  Sat Jan 18 03:50:03 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 18 Jan 2014 02:50:03 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1390013403.3.0.369165308595.issue17811@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/issue17811>
_______________________________________

From report at bugs.python.org  Sat Jan 18 05:37:32 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 18 Jan 2014 04:37:32 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <1390019852.24.0.684360812403.issue17814@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Sat Jan 18 06:21:04 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 18 Jan 2014 05:21:04 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1390022464.87.0.925584097126.issue17811@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

IMO, it should just refer to the glossary entry for "bytes-like object".

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

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

From report at bugs.python.org  Sat Jan 18 06:49:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 18 Jan 2014 05:49:38 +0000
Subject: [docs] [issue17814] Popen.stdin/stdout/stderr documentation should
	mention	object type
In-Reply-To: <1366586086.38.0.427506521088.issue17814@psf.upfronthosting.co.za>
Message-ID: <3f5pB925yRz7LjW@mail.python.org>


Roundup Robot added the comment:

New changeset 946257d3c648 by Benjamin Peterson in branch '3.3':
describe type of Popen streams (closes #17814)
http://hg.python.org/cpython/rev/946257d3c648

New changeset 1a7d416c57ff by Benjamin Peterson in branch 'default':
merge 3.3 (#17814)
http://hg.python.org/cpython/rev/1a7d416c57ff

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan 18 20:22:50 2014
From: report at bugs.python.org (Rob Browning)
Date: Sat, 18 Jan 2014 19:22:50 +0000
Subject: [docs] [issue20296] PyArg_ParseTuple 2.X docs mention int for "t#",
	but "Py_ssize_t" for "w#", etc.
Message-ID: <1390072970.58.0.165278841581.issue20296@psf.upfronthosting.co.za>


New submission from Rob Browning:

Here (http://docs.python.org/2/c-api/arg.html), the documentation for "t#" says:

  t# (read-only character buffer) [char *, int]...

while the documentation for "w#" says:

  w# (read-write character buffer) [char *, Py_ssize_t]...

However, from getargs.c, it looks like they're handled the same with respect to the size type.

At a minimum, it seems like it might make sense to change these docs to match, and if "w#" and "t#" are actually handled similarly to "s#", it would be even better to just change their docs to match (or refer to) "s#"'s which are more detailed, i.e. they mention the PY_SSIZE_T_CLEAN issues, etc.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 208410
nosy: docs at python, rlb
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple 2.X docs mention int for "t#", but "Py_ssize_t" for "w#", etc.
versions: Python 2.7

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

From report at bugs.python.org  Sun Jan 19 00:06:06 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 18 Jan 2014 23:06:06 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1390086366.02.0.988735478802.issue17811@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Indeed, this makes most sense. I didn't know that glossary entry existed. I have attached an updated patch. Thanks for reviewing!

----------
Added file: http://bugs.python.org/file33533/issue17811_rev2.patch

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

From report at bugs.python.org  Sun Jan 19 00:06:23 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 18 Jan 2014 23:06:23 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <1390086383.19.0.786736084165.issue17811@psf.upfronthosting.co.za>


Changes by Nikolaus Rath <Nikolaus at rath.org>:


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

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

From report at bugs.python.org  Sun Jan 19 01:37:11 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sun, 19 Jan 2014 00:37:11 +0000
Subject: [docs] [issue20252] Argument Clinic howto: small typo in y#
	translation
In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za>
Message-ID: <1390091831.71.0.341262091467.issue20252@psf.upfronthosting.co.za>


Ryan Smith-Roberts added the comment:

I saw the fix for this in the commit stream. Closing.

----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun Jan 19 01:37:36 2014
From: report at bugs.python.org (Ryan Smith-Roberts)
Date: Sun, 19 Jan 2014 00:37:36 +0000
Subject: [docs] [issue20252] Argument Clinic howto: small typo in y#
	translation
In-Reply-To: <1389678329.15.0.528814981218.issue20252@psf.upfronthosting.co.za>
Message-ID: <1390091856.46.0.578080685957.issue20252@psf.upfronthosting.co.za>


Changes by Ryan Smith-Roberts <rmsr at lab.net>:


----------
status: open -> closed

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

From report at bugs.python.org  Sun Jan 19 04:57:55 2014
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 19 Jan 2014 03:57:55 +0000
Subject: [docs] [issue17811] Improve os.readv() and os.writev()
	documentation and	docstring
In-Reply-To: <1366579468.26.0.0312151391842.issue17811@psf.upfronthosting.co.za>
Message-ID: <3f6Mfp5jJ7z7LjT@mail.python.org>


Roundup Robot added the comment:

New changeset 8b413f813a13 by Benjamin Peterson in branch '3.3':
improve description of buffers argument for readv/writev (closes #17811)
http://hg.python.org/cpython/rev/8b413f813a13

New changeset 4d56006133f1 by Benjamin Peterson in branch 'default':
merge 3.3 (#17811)
http://hg.python.org/cpython/rev/4d56006133f1

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From damir.hakimov at gmail.com  Sat Jan 18 16:41:48 2014
From: damir.hakimov at gmail.com (Damir Hakimov)
Date: Sat, 18 Jan 2014 19:41:48 +0400
Subject: [docs] py2exe in Python3.3 documentation
In-Reply-To: <CAKJDb-Mr11nC4vqGOYOVEBk18hrJvswfC6p38EqaQerfAmpFSg@mail.gmail.com>
References: <CABCbbCzWKvn5_iv9Lxi27QDSGLk-nYQjc-eQo1OL5t709-hG4g@mail.gmail.com>
 <CAKJDb-Mj7TWSPAM=DLz6utWiEC8YrX1tROgc8LMLD4mebwmdBQ@mail.gmail.com>
 <CABCbbCyTYFmUjkPeADdaz3Ar1jEvzgAEVwFDQQZ_MEkLsca2Mw@mail.gmail.com>
 <CAKJDb-Mr11nC4vqGOYOVEBk18hrJvswfC6p38EqaQerfAmpFSg@mail.gmail.com>
Message-ID: <CABCbbCxu5PMX-vuvOfVUprfG7WmDMfxC9241+ncBZheuv2faiA@mail.gmail.com>

Thank You!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140118/eea3cfde/attachment.html>

From report at bugs.python.org  Sun Jan 19 09:06:03 2014
From: report at bugs.python.org (Justin Foo)
Date: Sun, 19 Jan 2014 08:06:03 +0000
Subject: [docs] [issue20301] Correct docs for default access argument for
	DeleteKeyEx
Message-ID: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>


New submission from Justin Foo:

The default access for winreg.DeleteKeyEx is winreg.KEY_WOW64_64KEY (as per the function signature). This the documentation for Python 2.7 has this correct.

Reference: http://hg.python.org/cpython/file/2e32462e4832/PC/winreg.c#l1089

----------
assignee: docs at python
components: Documentation
files: winreg.DeleteKeyEx.docs.patch
keywords: patch
messages: 208462
nosy: docs at python, jfoo
priority: normal
severity: normal
status: open
title: Correct docs for default access argument for DeleteKeyEx
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33544/winreg.DeleteKeyEx.docs.patch

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

From report at bugs.python.org  Sun Jan 19 09:08:26 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 19 Jan 2014 08:08:26 +0000
Subject: [docs] [issue20301] Correct docs for default access argument for
	DeleteKeyEx
In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>
Message-ID: <1390118906.41.0.638358422674.issue20301@psf.upfronthosting.co.za>


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


----------
nosy: +brian.curtin, tim.golden
stage:  -> patch review
type:  -> enhancement

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

From report at bugs.python.org  Sun Jan 19 09:23:11 2014
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 19 Jan 2014 08:23:11 +0000
Subject: [docs] [issue19906] Typo in urllib documentation
In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>
Message-ID: <1390119791.52.0.205795143197.issue19906@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

I think that what the note was trying to say is that urlopen in Python 3 is equivalent to urllib2.urlopen in Python 2, so before switching to Python 3, people might want to move from urllib.urlopen to urllib2.urlopen.
Does the attached patch sound better?

----------
Added file: http://bugs.python.org/file33545/issue19906.diff

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

From ezio.melotti at gmail.com  Sun Jan 19 12:56:30 2014
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Sun, 19 Jan 2014 11:56:30 -0000
Subject: [docs] json module won't parse a float that starts with a decimal
 point (issue 19871)
Message-ID: <20140119115630.25677.16950@psf.upfronthosting.co.za>


http://bugs.python.org/review/19871/diff/10344/Doc/library/json.rst
File Doc/library/json.rst (right):

http://bugs.python.org/review/19871/diff/10344/Doc/library/json.rst#newcode232
Doc/library/json.rst:232: string is tokenized.
I don't find this too clear.  I think it would be better to just state
what happens when the json you are loading contains something like '.5'
(is it recognized and passed to float()? is it not recognized and
treated as a string or something else?)

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

From report at bugs.python.org  Sun Jan 19 20:13:27 2014
From: report at bugs.python.org (Claudiu.Popa)
Date: Sun, 19 Jan 2014 19:13:27 +0000
Subject: [docs] [issue19906] Typo in urllib documentation
In-Reply-To: <1386326764.33.0.520291465102.issue19906@psf.upfronthosting.co.za>
Message-ID: <1390158807.7.0.693271851403.issue19906@psf.upfronthosting.co.za>


Claudiu.Popa added the comment:

Yep, it sounds better. There's an additional warning in urllib.urlopen which states a similar thing:

    warnpy3k("urllib.urlopen() has been removed in Python 3.0 in "
             "favor of urllib2.urlopen()", stacklevel=2)

----------

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

From report at bugs.python.org  Mon Jan 20 05:21:39 2014
From: report at bugs.python.org (Vajrasky Kok)
Date: Mon, 20 Jan 2014 04:21:39 +0000
Subject: [docs] [issue19871] json module won't parse a float that starts
	with a	decimal point
In-Reply-To: <1386058873.01.0.290791588539.issue19871@psf.upfronthosting.co.za>
Message-ID: <1390191699.67.0.985425454931.issue19871@psf.upfronthosting.co.za>


Vajrasky Kok added the comment:

Attached the patch to address Ezio Melotti's concern. Thanks for the review!

----------
Added file: http://bugs.python.org/file33558/parse_non_valid_json_float_with_unit_test_v2.patch

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

From report at bugs.python.org  Mon Jan 20 05:43:05 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 20 Jan 2014 04:43:05 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1390192985.01.0.189309797368.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

(adding the documentation experts from http://docs.python.org/devguide/experts.html to noisy in the hope to push this forward)

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

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

From report at bugs.python.org  Mon Jan 20 05:44:54 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Mon, 20 Jan 2014 04:44:54 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <1390193094.07.0.586493776646.issue6627@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

(adding the documentation and ctypes experts from http://docs.python.org/devguide/experts.html to noisy list in the hope to get this moving again.)

----------
nosy: +belopolsky, eric.araujo, ezio.melotti, georg.brandl, meador.inge
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.5

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

From report at bugs.python.org  Mon Jan 20 06:12:33 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 20 Jan 2014 05:12:33 +0000
Subject: [docs] [issue6627] threading.local() does not work with C-created
	threads
In-Reply-To: <1249243364.61.0.822632396677.issue6627@psf.upfronthosting.co.za>
Message-ID: <3f71GS2mSNzRbX@mail.python.org>


Roundup Robot added the comment:

New changeset f4eade5df217 by Benjamin Peterson in branch '3.3':
document that a new Python thread context is created in ctypes callbacks (closes #6627)
http://hg.python.org/cpython/rev/f4eade5df217

New changeset 9cd2d7a3f9f2 by Benjamin Peterson in branch '2.7':
document that a new Python thread context is created in ctypes callbacks (closes #6627)
http://hg.python.org/cpython/rev/9cd2d7a3f9f2

New changeset fd647825475a by Benjamin Peterson in branch 'default':
merge 3.3 (#6627)
http://hg.python.org/cpython/rev/fd647825475a

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan 20 08:19:58 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Mon, 20 Jan 2014 07:19:58 +0000
Subject: [docs] [issue20310] Recommend using pprint for deterministic doctest
Message-ID: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

I just thought that using pprint.pprint was an elegant solution to the non-deterministic order of repr(dict) in doctest. See for instance http://bugs.python.org/issue3332

Contrary to sorted(foo().items()):

- It provides a nice output that is exactly like a dict.
- It supports any number of nested dicts.
- It can be used in other cases as well to make doctests elegant.

----------
assignee: docs at python
components: Documentation
files: pprint_doctest.patch
keywords: patch
messages: 208526
nosy: charlax, docs at python
priority: normal
severity: normal
status: open
title: Recommend using pprint for deterministic doctest
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file33560/pprint_doctest.patch

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

From report at bugs.python.org  Mon Jan 20 08:45:30 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jan 2014 07:45:30 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1390203930.72.0.77077812032.issue12704@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Hmm, the yield statement is now basically the same as any expression statement -- just like a function call.  The only reason it's a separate grammar symbol is that otherwise yield expressions would have to be parenthesized.

Can the patch be updated to make this a bit clearer?  Otherwise I like the approach of moving the info to the expressions page.

----------

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

From report at bugs.python.org  Mon Jan 20 13:32:13 2014
From: report at bugs.python.org (Michael Foord)
Date: Mon, 20 Jan 2014 12:32:13 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>
Message-ID: <1390221133.64.0.904071353814.issue20222@psf.upfronthosting.co.za>


Michael Foord added the comment:

Thanks for picking this up. /file/open/ should be fine.

----------

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

From report at bugs.python.org  Mon Jan 20 16:35:54 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Jan 2014 15:35:54 +0000
Subject: [docs] [issue20301] Correct docs for default access argument for
	DeleteKeyEx
In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>
Message-ID: <1390232154.41.0.93917163064.issue20301@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Mon Jan 20 16:51:41 2014
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 20 Jan 2014 15:51:41 +0000
Subject: [docs] [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the
	download	page.
Message-ID: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za>


New submission from Marco Buttu:

At the page:

http://www.python.org/getit/releases/3.4.0/

the link:

http://www.python.org/ftp/python/3.4.0/Python-3.4.0b2.tar.bz2

does not work.

----------
assignee: docs at python
components: Documentation
messages: 208545
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: A missing link to Python-3.4.0b2.tar.bz2 in the download page.
versions: Python 3.4

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

From report at bugs.python.org  Mon Jan 20 16:52:53 2014
From: report at bugs.python.org (R. David Murray)
Date: Mon, 20 Jan 2014 15:52:53 +0000
Subject: [docs] [issue20310] Recommend using pprint for deterministic doctest
In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za>
Message-ID: <1390233173.03.0.439984315498.issue20310@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think suggesting pprint is a great idea.  It also has another advantage in 3.4: in many cases it should produce output that is line wrapped such that NORMALIZE_WHITESPACE isn't needed.

However, I'd make it as an *additional* suggestion.  Pedagogically, sort makes it clear that you *must* resolve the problem of the ordering of dict items...then you can suggest pprint as something that also sorts, and has some additional nice properties as well.

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

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

From report at bugs.python.org  Mon Jan 20 18:10:54 2014
From: report at bugs.python.org (Gerrit Holl)
Date: Mon, 20 Jan 2014 17:10:54 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in 6.1.4.
	Template	strings
Message-ID: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>


New submission from Gerrit Holl:

The standard library documentation ?6.1. string ? Common string operations? describes string formatting through the `.format` method and the corresponding mini-language, and the `Template` class.  In the part describing the `Template` class (6.1.4) is the text:

> Instead of the normal %-based substitutions, Templates support $-based substitutions, using the following rules:

This is potentially confusing.  The documentation in this section has not made any mention of %-based substitutions.  Rather, a novel reader may, at this point, think that {}-based substitution is normal.  I would suggest to resolve this issue by simply not mentioning %-based substitutions, replacing the sentence above by:

> Templates support $-based substitutions, using the following rules:

----------
assignee: docs at python
components: Documentation
messages: 208553
nosy: Gerrit.Holl, docs at python
priority: normal
severity: normal
status: open
title: Potentially confusing formulation in 6.1.4. Template strings
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Mon Jan 20 18:18:18 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jan 2014 17:18:18 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in 6.1.4.
	Template	strings
In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>
Message-ID: <1390238298.77.0.20778699417.issue20314@psf.upfronthosting.co.za>


Georg Brandl added the comment:

+1.

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

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

From report at bugs.python.org  Mon Jan 20 18:19:53 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jan 2014 17:19:53 +0000
Subject: [docs] [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the
	download	page.
In-Reply-To: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za>
Message-ID: <1390238393.87.0.810611832575.issue20312@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jan 20 18:22:37 2014
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 20 Jan 2014 17:22:37 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in
	6.1.4.	Template	strings
In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>
Message-ID: <20140120121548.0927bb96@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On Jan 20, 2014, at 05:10 PM, Gerrit Holl wrote:

>This is potentially confusing.  The documentation in this section has not
>made any mention of %-based substitutions.  Rather, a novel reader may, at
>this point, think that {}-based substitution is normal.  I would suggest to
>resolve this issue by simply not mentioning %-based substitutions, replacing
>the sentence above by:
>
>> Templates support $-based substitutions, using the following rules:

+1

PEP 292 templates predate .format().

----------
nosy: +barry
title: Potentially confusing formulation in 6.1.4. Template strings -> Potentially confusing formulation in 6.1.4. Template	strings

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

From report at bugs.python.org  Mon Jan 20 18:34:44 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Jan 2014 17:34:44 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in
	6.1.4.	Template	strings
In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>
Message-ID: <1390239284.35.0.828903006004.issue20314@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I would suggest moving the section "4.7.2. printf-style String Formatting" from stdtypes to string, alongside the other two formatting specifications, or otherwise moving %-formatting and {}-formatting into the same page that is not stdtypes.  4.7.2 is a pretty long section, and it seems odd to me that it is still in that page instead of with the other string formatting specs, though it is the only place that would have made sense in a pre-{}-and-$-formatting world.

On the other hand, Gerrit's proposed solution is a *lot* simpler :)

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

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

From report at bugs.python.org  Mon Jan 20 18:35:57 2014
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 20 Jan 2014 17:35:57 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in
	6.1.4.	Template	strings
In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>
Message-ID: <1390239357.78.0.684378414233.issue20314@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Mon Jan 20 18:43:54 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jan 2014 17:43:54 +0000
Subject: [docs] [issue20314] Potentially confusing formulation in
	6.1.4.	Template	strings
In-Reply-To: <1390237853.97.0.751678212058.issue20314@psf.upfronthosting.co.za>
Message-ID: <1390239834.53.0.893535568313.issue20314@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> I would suggest moving the section "4.7.2. printf-style String
> Formatting" from stdtypes to string

That's something I wanted to do for a long time.  Problem is that non-Intersphinx external links will break (and I guess quite a few people have a bookmark on that section)... so it might be good to keep 4.7.2 with a pointer.

----------

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

From report at bugs.python.org  Mon Jan 20 21:15:39 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 20 Jan 2014 20:15:39 +0000
Subject: [docs] [issue20312] A missing link to Python-3.4.0b2.tar.bz2 in the
	download	page.
In-Reply-To: <1390233101.81.0.508449799289.issue20312@psf.upfronthosting.co.za>
Message-ID: <1390248939.21.0.599675899702.issue20312@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Jan 21 02:07:29 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 21 Jan 2014 01:07:29 +0000
Subject: [docs] [issue20310] Recommend using pprint for deterministic doctest
In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za>
Message-ID: <1390266449.69.0.230252805613.issue20310@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

That's a rather bad idea. pprint output isn't supposed to be identical accross versions; actually, it has recently changed in some cases.

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

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

From report at bugs.python.org  Tue Jan 21 05:11:40 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Tue, 21 Jan 2014 04:11:40 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1390277500.54.0.613447451787.issue12704@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

That makes sense. Attached is an updated patch. It removes most of the duplication, and clearly says that there is no semantic difference between the yield statement and the yield expression at all.

I also moved the "see also" block to follow the description of the yield expression. At least for me, it was rather easy to miss in its current position (at the end of the second example subsection). The rest of the code churn in that section is just removing all the (presumably accidental) links to the yield statement when referring to a yield expression.

----------
Added file: http://bugs.python.org/file33583/yield-docpatch-rev3.diff

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

From report at bugs.python.org  Tue Jan 21 05:56:07 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jan 2014 04:56:07 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>
Message-ID: <1390280167.88.0.794062992197.issue20222@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> terry.reedy
versions:  -Python 3.5

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

From report at bugs.python.org  Tue Jan 21 06:02:38 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jan 2014 05:02:38 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>
Message-ID: <3f7d0Y1vYDz7LjR@mail.python.org>


Roundup Robot added the comment:

New changeset 36c9a233ebf0 by Terry Jan Reedy in branch '3.3':
Issue #20222: file is no longer a builtin in 3.x.
http://hg.python.org/cpython/rev/36c9a233ebf0

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

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

From report at bugs.python.org  Tue Jan 21 06:03:23 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 21 Jan 2014 05:03:23 +0000
Subject: [docs] [issue20222] unittest.mock-examples doc uses builtin file
	which is	removed in Python 3
In-Reply-To: <1389464749.27.0.908623013872.issue20222@psf.upfronthosting.co.za>
Message-ID: <1390280603.3.0.458908818548.issue20222@psf.upfronthosting.co.za>


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


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Tue Jan 21 07:23:30 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jan 2014 06:23:30 +0000
Subject: [docs] [issue20310] Recommend using pprint for deterministic doctest
In-Reply-To: <1390202398.87.0.516795026978.issue20310@psf.upfronthosting.co.za>
Message-ID: <1390285410.14.0.737288522537.issue20310@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's a very good point.  You'd think I'd have thought of it since I mentioned that it had changed in 3.4.  And it will most likely change more in future versions.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 21 16:08:12 2014
From: report at bugs.python.org (Masami HIRATA)
Date: Tue, 21 Jan 2014 15:08:12 +0000
Subject: [docs] [issue20330] PEP 342 is outdated
Message-ID: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za>


New submission from Masami HIRATA:

Although PEP 342 says foo(yield 42) is legal, Lib/test/test_grammar.py says:
>        # Requires parentheses as call argument
>        def g(): f((yield 1))
>        check_syntax_error(self, "def g(): f(yield 1)")

BTW, It seems that foo(yield 42) written in ECMAScript 6 is OK.

----------
assignee: docs at python
components: Documentation
messages: 208650
nosy: docs at python, msmhrt
priority: normal
severity: normal
status: open
title: PEP 342 is outdated
versions: Python 3.3

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

From report at bugs.python.org  Tue Jan 21 16:53:39 2014
From: report at bugs.python.org (R. David Murray)
Date: Tue, 21 Jan 2014 15:53:39 +0000
Subject: [docs] [issue20330] PEP 342 is outdated
In-Reply-To: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za>
Message-ID: <1390319619.56.0.645959046113.issue20330@psf.upfronthosting.co.za>


R. David Murray added the comment:

Most PEPs are historical documents once they are final, so I don't think there is actually anything to fix here.  But I could be wrong.

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

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

From report at bugs.python.org  Tue Jan 21 16:59:07 2014
From: report at bugs.python.org (Martin d'Anjou)
Date: Tue, 21 Jan 2014 15:59:07 +0000
Subject: [docs] [issue9694] argparse required arguments displayed under
	"optional	arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1390319947.6.0.397055766653.issue9694@psf.upfronthosting.co.za>


Martin d'Anjou added the comment:

How about calling required arguments "required arguments"?

required arguments:
  --reqarg REQARG, -r REQARG
                        This is required
optional arguments:
  -h, --help            show this help message and exit
  --optarg OPTARG, -o OPTARG
                        This is optional

Clear and unambiguous. With this approach the user does not have to bloat the help to state "This is required".

We're having the same discussion over at github regarding argparse4j:
https://github.com/tatsuhiro-t/argparse4j/issues/26#issuecomment-32894297

----------
nosy: +Martin.d'Anjou

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

From harley at moonfruit.com  Tue Jan 21 17:30:35 2014
From: harley at moonfruit.com (Harley Faggetter)
Date: Tue, 21 Jan 2014 16:30:35 +0000
Subject: [docs] Bug on http://docs.python.org/2/library/hashlib.html
Message-ID: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>

Hi,

I've noticed an issue with the page http://docs.python.org/2/library/hashlib.html

For the entry hash.update(arg), the end of the entry contains the text "Changed in version 2.7.". However, there appears to be no difference in the documentation between 2.7.6 and 2.6, and there's no link provided to change notes that would explain the change.

If this text is in error, I would suggest its removal, otherwise I'd suggest updating either the 2.6 documentation or the 2.7.6 documentation with the difference, or providing a link to the change notes that explain the change.

Best Regards,

Harley
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140121/bdda73da/attachment.html>

From songofacandy at gmail.com  Tue Jan 21 17:57:39 2014
From: songofacandy at gmail.com (INADA Naoki)
Date: Wed, 22 Jan 2014 01:57:39 +0900
Subject: [docs] Bug on http://docs.python.org/2/library/hashlib.html
In-Reply-To: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>
References: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>
Message-ID: <CAEfz+Tys6OMZmm+fOX4n=T8UB3H372K6rtkr2V-ubEiT49V_zw@mail.gmail.com>

As you can see,
http://docs.python.org/2/_sources/library/hashlib.txtcontains
description
about changes in 2.7

Some directives are broken with Sphinx-1.2.
For example, deprecated-removed directive in following is also broken.
http://docs.python.org/3/library/urllib.request.html#urllib.request.Request.add_data

Shimizukawa (one of committer of Sphinx) pointed out that following change
may break
pyspecific extension.
https://bitbucket.org/birkenfeld/sphinx/pull-request/124/versionmodified-fixes/diff



On Wed, Jan 22, 2014 at 1:30 AM, Harley Faggetter <harley at moonfruit.com>wrote:

>  Hi,
>
> I've noticed an issue with the page
> http://docs.python.org/2/library/hashlib.html
>
> For the entry *hash.update(arg)*, the end of the entry contains the text
> "Changed in version 2.7.". However, there appears to be no difference in
> the documentation between 2.7.6 and 2.6, and there's no link provided to
> change notes that would explain the change.
>
> If this text is in error, I would suggest its removal, otherwise I'd
> suggest updating either the 2.6 documentation or the 2.7.6 documentation
> with the difference, or providing a link to the change notes that explain
> the change.
>
> Best Regards,
>
> Harley
>
> _______________________________________________
> docs mailing list
> docs at python.org
> https://mail.python.org/mailman/listinfo/docs
>
>


-- 
INADA Naoki  <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140122/f4034031/attachment.html>

From harley at moonfruit.com  Tue Jan 21 18:27:38 2014
From: harley at moonfruit.com (Harley Faggetter)
Date: Tue, 21 Jan 2014 17:27:38 +0000
Subject: [docs] Bug on http://docs.python.org/2/library/hashlib.html
In-Reply-To: <CAEfz+Tys6OMZmm+fOX4n=T8UB3H372K6rtkr2V-ubEiT49V_zw@mail.gmail.com>
References: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>,
 <CAEfz+Tys6OMZmm+fOX4n=T8UB3H372K6rtkr2V-ubEiT49V_zw@mail.gmail.com>
Message-ID: <37CCD34F69500742A5D8338BA5B791B71A35474F@Telesto.greekattic.local>

Hi,

Thanks for the information. Still, it'd be nice to be able to see that in the html page itself, as it may not be obvious that it was in the source.

Regards,

Harley

________________________________
From: INADA Naoki [songofacandy at gmail.com]
Sent: 21 January 2014 16:57
To: Harley Faggetter
Cc: docs at python.org
Subject: Re: [docs] Bug on http://docs.python.org/2/library/hashlib.html

As you can see, http://docs.python.org/2/_sources/library/hashlib.txt contains description
about changes in 2.7

Some directives are broken with Sphinx-1.2.
For example, deprecated-removed directive in following is also broken.
http://docs.python.org/3/library/urllib.request.html#urllib.request.Request.add_data

Shimizukawa (one of committer of Sphinx) pointed out that following change may break
pyspecific extension.
https://bitbucket.org/birkenfeld/sphinx/pull-request/124/versionmodified-fixes/diff



On Wed, Jan 22, 2014 at 1:30 AM, Harley Faggetter <harley at moonfruit.com<mailto:harley at moonfruit.com>> wrote:
Hi,

I've noticed an issue with the page http://docs.python.org/2/library/hashlib.html

For the entry hash.update(arg), the end of the entry contains the text "Changed in version 2.7.". However, there appears to be no difference in the documentation between 2.7.6 and 2.6, and there's no link provided to change notes that would explain the change.

If this text is in error, I would suggest its removal, otherwise I'd suggest updating either the 2.6 documentation or the 2.7.6 documentation with the difference, or providing a link to the change notes that explain the change.

Best Regards,

Harley

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




--
INADA Naoki  <songofacandy at gmail.com<mailto:songofacandy at gmail.com>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140121/0b0b25b7/attachment-0001.html>

From georg at python.org  Tue Jan 21 18:46:41 2014
From: georg at python.org (Georg Brandl)
Date: Tue, 21 Jan 2014 18:46:41 +0100
Subject: [docs] Bug on http://docs.python.org/2/library/hashlib.html
In-Reply-To: <37CCD34F69500742A5D8338BA5B791B71A35474F@Telesto.greekattic.local>
References: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>,
 <CAEfz+Tys6OMZmm+fOX4n=T8UB3H372K6rtkr2V-ubEiT49V_zw@mail.gmail.com>
 <37CCD34F69500742A5D8338BA5B791B71A35474F@Telesto.greekattic.local>
Message-ID: <52DEB281.7090302@python.org>

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

Am 21.01.2014 18:27, schrieb Harley Faggetter:
> Hi,
> 
> Thanks for the information. Still, it'd be nice to be able to see that in
> the html page itself, as it may not be obvious that it was in the source.

Of course :) I'm checking in a fix right now, it will be live when the docs next
rebuild.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLesoEACgkQN9GcIYhpnLBLeQCeKArXgAi9wsDoinx/U6B3bOQM
UBEAniKq9SD0o1CStmKfGMDXu06ft4PZ
=HfCw
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Jan 21 18:53:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2014 17:53:22 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1390326802.45.0.623342842592.issue19863@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM, but may be write Py3k compatible names at first place?

----------
stage:  -> commit review
type:  -> behavior

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

From harley at moonfruit.com  Tue Jan 21 18:54:08 2014
From: harley at moonfruit.com (Harley Faggetter)
Date: Tue, 21 Jan 2014 17:54:08 +0000
Subject: [docs] Bug on http://docs.python.org/2/library/hashlib.html
In-Reply-To: <52DEB281.7090302@python.org>
References: <37CCD34F69500742A5D8338BA5B791B71A3546FE@Telesto.greekattic.local>, 
 <CAEfz+Tys6OMZmm+fOX4n=T8UB3H372K6rtkr2V-ubEiT49V_zw@mail.gmail.com>
 <37CCD34F69500742A5D8338BA5B791B71A35474F@Telesto.greekattic.local>,
 <52DEB281.7090302@python.org>
Message-ID: <37CCD34F69500742A5D8338BA5B791B71A354768@Telesto.greekattic.local>

Yay, thanks!
________________________________________
From: Georg Brandl [georg at python.org]
Sent: 21 January 2014 17:46
To: Harley Faggetter; INADA Naoki
Cc: docs at python.org
Subject: Re: [docs] Bug on http://docs.python.org/2/library/hashlib.html

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

Am 21.01.2014 18:27, schrieb Harley Faggetter:
> Hi,
>
> Thanks for the information. Still, it'd be nice to be able to see that in
> the html page itself, as it may not be obvious that it was in the source.

Of course :) I'm checking in a fix right now, it will be live when the docs next
rebuild.

cheers,
Georg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iEYEARECAAYFAlLesoEACgkQN9GcIYhpnLBLeQCeKArXgAi9wsDoinx/U6B3bOQM
UBEAniKq9SD0o1CStmKfGMDXu06ft4PZ
=HfCw
-----END PGP SIGNATURE-----

From report at bugs.python.org  Tue Jan 21 19:22:40 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 21 Jan 2014 18:22:40 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1390328560.41.0.866101573317.issue19863@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jan 21 20:50:24 2014
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 21 Jan 2014 19:50:24 +0000
Subject: [docs] [issue20301] Correct docs for default access argument for
	DeleteKeyEx
In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>
Message-ID: <3f80hv1w5yz7Ljk@mail.python.org>


Roundup Robot added the comment:

New changeset da35a4e724e5 by Zachary Ware in branch '3.3':
Issue #20301: Mention the correct KEY_* value as the default
http://hg.python.org/cpython/rev/da35a4e724e5

New changeset 3baee069c5ff by Zachary Ware in branch 'default':
Issue #20301: Merge with 3.3
http://hg.python.org/cpython/rev/3baee069c5ff

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

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

From report at bugs.python.org  Tue Jan 21 20:51:05 2014
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 21 Jan 2014 19:51:05 +0000
Subject: [docs] [issue20301] Correct docs for default access argument for
	DeleteKeyEx
In-Reply-To: <1390118763.24.0.151649669148.issue20301@psf.upfronthosting.co.za>
Message-ID: <1390333865.41.0.88757984543.issue20301@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed, thanks for the report!

----------
assignee: docs at python -> zach.ware
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jan 21 22:50:09 2014
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 21 Jan 2014 21:50:09 +0000
Subject: [docs] [issue20280] add "predicate" to the glossary
In-Reply-To: <1389878750.92.0.454847187289.issue20280@psf.upfronthosting.co.za>
Message-ID: <1390341009.35.0.566166411089.issue20280@psf.upfronthosting.co.za>


Florent Xicluna added the comment:

Then we can forget it. Thank you for your input.

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

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

From report at bugs.python.org  Wed Jan 22 05:49:16 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Wed, 22 Jan 2014 04:49:16 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1390366156.65.0.813373347499.issue11448@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

The patches look fine to me. They are only docpatches, so no testcase is needed.

I have rebased them on current hg tip to avoid fuzz, but otherwise left them unchanged.

I think this is ready to be committed.

----------
nosy: +ezio.melotti, georg.brandl
versions:  -Python 3.5
Added file: http://bugs.python.org/file33609/issue11448_r2.patch

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

From report at bugs.python.org  Wed Jan 22 07:39:43 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 22 Jan 2014 06:39:43 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1390372783.63.0.869731500191.issue11448@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The first sentence of the second new paragraph is a bit ungrammatical, right?

----------

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

From report at bugs.python.org  Wed Jan 22 08:26:11 2014
From: report at bugs.python.org (karl)
Date: Wed, 22 Jan 2014 07:26:11 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1390375571.72.0.146416296291.issue11448@psf.upfronthosting.co.za>


karl added the comment:

ooops right, my bad.

s/on port 8080. We first/on port 8080, we first/

better?

----------

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

From report at bugs.python.org  Wed Jan 22 15:25:05 2014
From: report at bugs.python.org (Tobias Klausmann)
Date: Wed, 22 Jan 2014 14:25:05 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
	what	shell=True does
Message-ID: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>


New submission from Tobias Klausmann:

The subprocess docs state that the first argument can be either a string or an iterable that contains the program and arguments to run. It also points out that using shell=True allows for shell constructs. It does not mention a subtlety that is introduced by Python's use of sh -c (on Unix):

Using a string that contains the full command line with args and shell=False breaks as expected:

>>> subprocess.check_output("ls foo", shell=False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 576, in check_output
    with Popen(*popenargs, stdout=PIPE, **kwargs) as process:
  File "/usr/lib64/python3.3/subprocess.py", line 824, in __init__
    restore_signals, start_new_session)
  File "/usr/lib64/python3.3/subprocess.py", line 1448, in _execute_child
    raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: 'ls foo'

Using shell=True instead works as expected (since foo does not exist, ls exits with non-0 and a different Exception is raised. This, too is to spec and exactly what the docs describe.

>>> subprocess.check_output("ls foo", shell=True)
ls: cannot access foo: No such file or directory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command 'ls foo' returned non-zero exit status 2

Using shell=False and making the command a list of command and args does the same thing:

>>> subprocess.check_output(["ls", "foo"], shell=False)
ls: cannot access foo: No such file or directory
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.3/subprocess.py", line 589, in check_output
    raise CalledProcessError(retcode, process.args, output=output)
subprocess.CalledProcessError: Command '['ls', 'foo']' returned non-zero exit status 2

But using an iterable _and_ requesting a shell results in something very broken:

>>> subprocess.check_output(["ls", "foo"], shell=True)
[contents of my homedir are returned]
>>>

Note that the argument "foo" completely disappears, apparently. strace() reveals that "foo" is never added to the call to "ls". Instead, it becomes $0 in the shell that ls runs in. This is exactly to spec (i.e. bash is not broken). "bash -c foo bar baz" will start a shell that sets $0 to "bar", $1 to "baz" and then executes "foo". Whereas "bash -c 'foo bar baz'" will run 'foo bar baz'.

I think there are three possible fixes here:
1- Make check_output(list, shell=True) run something like "bash -c '%s'" % " ".join(list)
2- Change the docs to warn of the unintended consequences of combining lists with shell=True
3- Make check_output() throw an Exception if the first argument is a list and shell=True

The first option would make it easiest for people to "just use it", but I fear the string manipulation may become the source of bugs with security implications in the future.

The second option keeps the status quo, but people tend to not read docs, so it may not be as effective as one would like, especially since shell-True already has warnings and people tend to go "yeah I know about unverified input, but it's not a problem for me" and then ignore both warnings.

Option 3 has the disadvantage that existing scripts that _expect_ the behavior may break.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 208811
nosy: docs at python, klausman
priority: normal
severity: normal
status: open
title: subprocess.check_output() docs misrepresent what shell=True does
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Wed Jan 22 15:47:52 2014
From: report at bugs.python.org (R. David Murray)
Date: Wed, 22 Jan 2014 14:47:52 +0000
Subject: [docs] [issue20344] subprocess.check_output() docs misrepresent
	what	shell=True does
In-Reply-To: <1390400705.04.0.503333173013.issue20344@psf.upfronthosting.co.za>
Message-ID: <1390402072.1.0.289425520631.issue20344@psf.upfronthosting.co.za>


R. David Murray added the comment:

This was discussed in issue 6760.  There I advocated (and still advocate) option (3).  Unfortunately it looks like our doc update in that issue actually *lost* the documentation for your option (2) that used to be there, though it wasn't exactly clear what it meant when it was there.

So IMO we should do a doc update to add that info back in a clearer form, and also do a deprecation cycle to disallow shell=True with a sequence.  I haven't ever gotten consensus from the other devs on the latter, though.

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

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

From report at bugs.python.org  Wed Jan 22 16:47:29 2014
From: report at bugs.python.org (Tal Einat)
Date: Wed, 22 Jan 2014 15:47:29 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
	legacy	convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1390405649.54.0.57521307503.issue20346@psf.upfronthosting.co.za>


Changes by Tal Einat <taleinat at gmail.com>:


----------
assignee:  -> docs at python
components: +Build, Demos and Tools, Documentation
nosy: +docs at python
type:  -> enhancement
versions: +Python 3.4

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

From report at bugs.python.org  Wed Jan 22 16:51:44 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 22 Jan 2014 15:51:44 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
	legacy	convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1390405904.7.0.161605001223.issue20346@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
superseder:  -> Argument Clinic does not support the 'l' format

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

From report at bugs.python.org  Wed Jan 22 19:07:57 2014
From: report at bugs.python.org (Charles-Axel Dein)
Date: Wed, 22 Jan 2014 18:07:57 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
Message-ID: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>


New submission from Charles-Axel Dein:

IMO csv.DictWriter and csv.DictReader provides a nicer interface for complex CSV file. I see some people reinventing the DictReader and DictWriter pretty frequently, because when they rapidly scan the documentation all examples are about csv.reader and csv.writer.

This patch adds examples.

----------
assignee: docs at python
components: Documentation
files: add_csvdict_examples.patch
keywords: patch
messages: 208835
nosy: charlax, docs at python
priority: normal
severity: normal
status: open
title: Add doc examples for DictReader and DictWriter
Added file: http://bugs.python.org/file33629/add_csvdict_examples.patch

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

From report at bugs.python.org  Wed Jan 22 19:59:32 2014
From: report at bugs.python.org (Moritz Neeb)
Date: Wed, 22 Jan 2014 18:59:32 +0000
Subject: [docs] [issue20351] Add doc examples for DictReader and DictWriter
In-Reply-To: <1390414077.91.0.281809568509.issue20351@psf.upfronthosting.co.za>
Message-ID: <1390417172.36.0.544166373792.issue20351@psf.upfronthosting.co.za>


Changes by Moritz Neeb <nt4u at kpvn.de>:


----------
nosy: +zormit

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

From report at bugs.python.org  Wed Jan 22 22:26:10 2014
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 22 Jan 2014 21:26:10 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
	legacy	convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1390425970.74.0.843934850168.issue20346@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/issue20346>
_______________________________________

From report at bugs.python.org  Thu Jan 23 11:42:59 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2014 10:42:59 +0000
Subject: [docs] [issue20364] Rename & explain sqlite3.Cursor.execute
	'parameters'	param
Message-ID: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

"execute(sql[, parameters])
    Executes an SQL statement. The SQL statement may be parametrized (i. e. placeholders instead of SQL literals). The sqlite3 module supports two kinds of placeholders: question marks (qmark style) and named placeholders (named style)."

Experimental facts based on experiments with the code example in the doc, using 3.4.b2: 'parameters' is a single subscriptable collection parameter, sequence or dict, that might be called seq_dict. It is positional only, so whatever name is used is a dummy. Only one placeholder style can be used in a given SQL statement string. If question marks are used, seq_dict must be a sequence. If names are used, seq_dict can be either a sequence or dict or subclass thereof. A UserDict is treated as a sequence and raises KeyError(0).

Possible text that encompasses the above, replacing the last sentence:

"A statement may use one of two kinds of placeholders: question marks (qmark style) or named placeholders (named style). For qmark style, seq_dict must be a sequence. For named style, it can be either a sequence or dict instance. Len(seq_dict) must match the number of placeholders."

After cleaning up the test file, I will verify on 2.7 and upload.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 208908
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Rename & explain sqlite3.Cursor.execute 'parameters'  param
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu Jan 23 13:33:05 2014
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 23 Jan 2014 12:33:05 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1390480384.94.0.438696036374.issue19863@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> LGTM, but may be write Py3k compatible names at first place?

Sure;  I don't have strong opinions either way.

----------

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

From report at bugs.python.org  Thu Jan 23 15:04:45 2014
From: report at bugs.python.org (R. David Murray)
Date: Thu, 23 Jan 2014 14:04:45 +0000
Subject: [docs] [issue20364] Rename & explain sqlite3.Cursor.execute
	'parameters'	param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1390485885.1.0.810604341533.issue20364@psf.upfronthosting.co.za>


R. David Murray added the comment:

I wonder if the fact that a sequence is accepted in named mode should actually be considered a bug and not documented.  Also, is it really true that the number of items must match even in named mode?  I think I remember passing a dict with extra elements, but I don't have that code handy to check.

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

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

From report at bugs.python.org  Thu Jan 23 16:10:26 2014
From: report at bugs.python.org (Chris Angelico)
Date: Thu, 23 Jan 2014 15:10:26 +0000
Subject: [docs] [issue20364] Rename & explain sqlite3.Cursor.execute
	'parameters'	param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1390489826.63.0.894151097145.issue20364@psf.upfronthosting.co.za>


Chris Angelico added the comment:

Small quibble: The last sentence capitalizes a Python built-in, which is confusing ("Len(seq_dict) must match..."). Tweak of grammar to have it not at the beginning of the sentence: "Either way, len(seq_dict) must match...".

----------
nosy: +Rosuav

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

From keith.briggs at bt.com  Thu Jan 23 16:42:01 2014
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Thu, 23 Jan 2014 15:42:01 +0000
Subject: [docs] poor wording at http://docs.python.org/2/howto/sorting.html
Message-ID: <BA02A06A22A52C449E4B5EE4CE1DBC3FA01FB035A1@EMV66-UKRD.domain1.systemhost.net>

http://docs.python.org/2/howto/sorting.html:


?  A common pattern is to sort complex objects using some of the object's indices as keys

What is meant is surely "the object's elements" or "the object's components"?!

Keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140123/3c4e36c7/attachment.html>

From report at bugs.python.org  Thu Jan 23 16:55:03 2014
From: report at bugs.python.org (July)
Date: Thu, 23 Jan 2014 15:55:03 +0000
Subject: [docs] [issue20370] Docs error in Library
	reference-17.1.3	threading.Lock.acquire()
Message-ID: <1390492503.52.0.179791157222.issue20370@psf.upfronthosting.co.za>


New submission from July:

In docs of Library reference-17.1.3 :
threading.Lock.acquire(blocking=True,timeout=-1):
line3 said: If a call with blocking set to True would block, return False immediately

Here I suspect the blocking argument ought to be False as described subsequently.
If it's set to True,it would block but return False immediately.


P.S. first try of a non-native English speaker,do not care if any syntax error was made up there,please

----------
assignee: docs at python
components: Documentation
messages: 208962
nosy: docs at python, yonoho
priority: normal
severity: normal
status: open
title: Docs error in Library reference-17.1.3 threading.Lock.acquire()
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Thu Jan 23 17:00:04 2014
From: report at bugs.python.org (July)
Date: Thu, 23 Jan 2014 16:00:04 +0000
Subject: [docs] [issue20370] Docs error in Library
	reference-17.1.3	threading.Lock.acquire()
In-Reply-To: <1390492503.52.0.179791157222.issue20370@psf.upfronthosting.co.za>
Message-ID: <1390492804.57.0.647796071342.issue20370@psf.upfronthosting.co.za>


July added the comment:

a sad story of a non-native English speaker,I just realized that it's me misunderstanding the sentence.

well, close it.

----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Jan 24 00:26:58 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 23 Jan 2014 23:26:58 +0000
Subject: [docs] [issue20364] Rename & explain sqlite3.Cursor.execute
	'parameters'	param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1390519618.77.0.20915598882.issue20364@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I do not know what the intention was for sequences and named placeholders. Thinking of named tuples made me think it ok. The code might have a hint.

Is sqlite3 code maintained here or elsewhere? The current docstring is just 'Executes a SQL statement.', and help gives no signature. .executemany is similar. I suspect the whole module needs better docstrings.

You are correct about dicts and extra key:value pairs. I tried a UserDict with an extra pair and when I got

sqlite3.ProgrammingError: Incorrect number of bindings supplied. The current statement uses 2, and there are 3 supplied

I had not yet realized that they were treated as sequences, not dicts. So replace "Len(seq_dict)" with "The length of sequences". This solves Chris's point also.

----------
nosy: +ghaering

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

From report at bugs.python.org  Fri Jan 24 05:09:05 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 24 Jan 2014 04:09:05 +0000
Subject: [docs] [issue11448] docs for HTTPConnection.set_tunnel are ambiguous
In-Reply-To: <1299636529.48.0.302129596868.issue11448@psf.upfronthosting.co.za>
Message-ID: <1390536545.34.0.23710737216.issue11448@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

Apologies, I missed that. I'll be more careful in the future. I've attached an updated patch that also adds some extra Sphinx markup, but should IMO still be credited to Ryan and Karl.

----------
Added file: http://bugs.python.org/file33674/issue11448_r3.patch

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

From report at bugs.python.org  Fri Jan 24 05:18:42 2014
From: report at bugs.python.org (R. David Murray)
Date: Fri, 24 Jan 2014 04:18:42 +0000
Subject: [docs] [issue20364] Rename & explain sqlite3.Cursor.execute
	'parameters'	param
In-Reply-To: <1390473779.26.0.463818219743.issue20364@psf.upfronthosting.co.za>
Message-ID: <1390537122.05.0.294140927275.issue20364@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't know anything about the current relationship between the external project and the stdlib version.  In the (small) changes I've been part of, we have maintained what is in the stdlib without reference to the external project.

----------

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

From report at bugs.python.org  Fri Jan 24 05:53:36 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Fri, 24 Jan 2014 04:53:36 +0000
Subject: [docs] [issue20375] ElementTree: Document handling processing
	instructions
Message-ID: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za>


New submission from Nikolaus Rath:

(This issue was branched of from #9521).

When parsing XML, etree currently skips over all processing instructions and comments. However, both can be represented in the tree and are also written out when generating XML.

The attached patch documents this (IMO surprising) behavior.

----------
assignee: docs at python
components: Documentation
files: xml.etree_r1.patch
keywords: patch
messages: 209036
nosy: docs at python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, nikolaus.rath, scoder
priority: normal
severity: normal
status: open
title: ElementTree: Document handling processing instructions
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33675/xml.etree_r1.patch

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

From report at bugs.python.org  Sat Jan 25 08:01:22 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jan 2014 07:01:22 +0000
Subject: [docs] [issue20386] Missing docs for SocketType and AddressFamily
	in socket	module
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390633282.14.0.710655330852.issue20386@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Because that's the way enums work (http://docs.python.org/dev/library/enum):

>>> import socket
>>> list(socket.SocketType)
[<SocketType.SOCK_DGRAM: 2>, <SocketType.SOCK_SEQPACKET: 5>, <SocketType.SOCK_NONBLOCK: 2048>, <SocketType.SOCK_CLOEXEC: 524288>, <SocketType.SOCK_RDM: 4>, <SocketType.SOCK_STREAM: 1>, <SocketType.SOCK_RAW: 3>]
>>> list(socket.AddressFamily)
[<AddressFamily.AF_NETLINK: 16>, <AddressFamily.AF_CAN: 29>, <AddressFamily.AF_WANPIPE: 25>, <AddressFamily.AF_UNSPEC: 0>, <AddressFamily.AF_KEY: 15>, <AddressFamily.AF_PPPOX: 24>, <AddressFamily.AF_IPX: 4>, <AddressFamily.AF_UNIX: 1>, <AddressFamily.AF_IRDA: 23>, <AddressFamily.AF_SECURITY: 14>, <AddressFamily.AF_PACKET: 17>, <AddressFamily.AF_AX25: 3>, <AddressFamily.AF_APPLETALK: 5>, <AddressFamily.AF_NETROM: 6>, <AddressFamily.AF_ATMPVC: 8>, <AddressFamily.AF_SNA: 22>, <AddressFamily.AF_INET6: 10>, <AddressFamily.AF_TIPC: 30>, <AddressFamily.AF_RDS: 21>, <AddressFamily.AF_NETBEUI: 13>, <AddressFamily.AF_INET: 2>, <AddressFamily.AF_X25: 9>, <AddressFamily.AF_ECONET: 19>, <AddressFamily.AF_LLC: 26>, <AddressFamily.AF_ROSE: 11>, <AddressFamily.AF_BRIDGE: 7>, <AddressFamily.AF_ASH: 18>, <AddressFamily.AF_ATMSVC: 20>]

Marking as a docs issue, since the fact that these are now enums should be covered in the socket module docs.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, ethan.furman, ncoghlan
stage:  -> needs patch
title: socket.SocketType is different in Python 3.4 -> Missing docs for SocketType and AddressFamily in socket module
type:  -> enhancement

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

From report at bugs.python.org  Sat Jan 25 08:45:36 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jan 2014 07:45:36 +0000
Subject: [docs] [issue20386] Missing docs for SocketType and AddressFamily
	in socket	module
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390635936.18.0.0737642178757.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Um... changing the name "socket.SocketType" from type(socket) to an enum of SOCK_ constants is not a docs issue, but a regression.

Eli, you introduced this change (inadvertently, I think, which can easily happen since SocketType is imported by "*" from _socket).  Please find a better name for the type enum and document the new enums.

----------
assignee: docs at python -> eli.bendersky
nosy: +eli.bendersky, georg.brandl
priority: normal -> high

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

From report at bugs.python.org  Sat Jan 25 08:49:18 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jan 2014 07:49:18 +0000
Subject: [docs] [issue20386] Missing docs for SocketType and AddressFamily
	in socket	module
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390636158.8.0.990095342557.issue20386@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Sorry, I misread Giampaolo's example as indicating that socket.SocketType wasn't there at all in Python 3.3. However, it's there, and with the same name as in Python 2, so I agree this is a regression.

I suggest socket.SocketKind as an alternate name for the enumeration that avoids the name clash, but we also need a test case that ensures that socket.SocketType has the correct value.

----------
components: +Library (Lib) -Documentation
keywords: +3.4regression
stage: needs patch -> test needed
type: enhancement -> behavior

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

From report at bugs.python.org  Sat Jan 25 08:52:28 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jan 2014 07:52:28 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390636348.23.0.543145782445.issue20386@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Missing docs for SocketType and AddressFamily in socket module -> socket.SocketType enum overwrites import of _socket.SocketType

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

From report at bugs.python.org  Sat Jan 25 09:03:40 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 25 Jan 2014 08:03:40 +0000
Subject: [docs] [issue20330] PEP 342 is outdated
In-Reply-To: <1390316892.04.0.132074086139.issue20330@psf.upfronthosting.co.za>
Message-ID: <1390637020.22.0.200302460896.issue20330@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

David is correct, most PEPs are historical records of design decisions that cease to be updated once completed. The language reference is the normative guide for current behaviour.

The exception is "informational" and "process" PEPs, which cover things that are not covered in the language reference, as well the occasional Standards Track PEP which ends up not being incorporated into the language reference properly (for example, until the import section was added to the language reference in Python 3.3, PEP 302 was the best available reference documentation).

----------
nosy: +ncoghlan
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jan 25 11:46:46 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 25 Jan 2014 10:46:46 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
	legacy	convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1390646806.81.0.0530981359629.issue20346@psf.upfronthosting.co.za>


Larry Hastings added the comment:

If two issues are created on the tracker for the same issue, surely it's the *older* issue that is preserved, and the new one marked as duplicate and closed?

----------

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

From report at bugs.python.org  Sat Jan 25 13:12:49 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jan 2014 12:12:49 +0000
Subject: [docs] [issue20346] Argument Clinic: missing entry in table mapping
	legacy	convertors to real AC converters
In-Reply-To: <1390405621.79.0.727900748758.issue20346@psf.upfronthosting.co.za>
Message-ID: <1390651969.9.0.270038457577.issue20346@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Only if the older issue actually has more relevant content, which is not always the case.

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

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

From report at bugs.python.org  Sat Jan 25 16:52:55 2014
From: report at bugs.python.org (Adam Knight)
Date: Sat, 25 Jan 2014 15:52:55 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1390665175.39.0.611287740261.issue19023@psf.upfronthosting.co.za>


Adam Knight added the comment:

Can someone add this in?  What needs to be done to make it happen? Kind of need this for a project I'm working on...

----------
nosy: +ahknight

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

From report at bugs.python.org  Sat Jan 25 20:50:10 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 25 Jan 2014 19:50:10 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390679410.32.0.719957939868.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Here's a patch for the test.

----------
Added file: http://bugs.python.org/file33706/issue20386.stoneleaf.test.patch.01

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

From report at bugs.python.org  Sat Jan 25 21:00:29 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Jan 2014 20:00:29 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390680029.01.0.141914739739.issue20386@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> Please find a better name for the type enum and document the new enums.

Why should new enums be documented and how are they useful?
IMO socket module adopted enum module only to provide a better representation of AF_* and SOCK_* constants on repr(), which is fine.
The fact that in order to do that enum module forces you to create a container is incidental and should not result in polluting socket module API (which is already pretty crowded).
In summary I'd be for renaming those enums to _SocketType and _AddressFamily.

----------

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

From report at bugs.python.org  Sat Jan 25 21:10:54 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jan 2014 20:10:54 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390680654.04.0.963888580695.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> Why should new enums be documented and how are they useful?

Because they are a new public class(-like object) in the module. When renaming them to a non-public name, as you suggest, that could be left out.

----------

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

From report at bugs.python.org  Sat Jan 25 21:20:33 2014
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 25 Jan 2014 20:20:33 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390681233.6.0.937206804167.issue20386@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

But as a user when are you gonna need to use AddressFamily container?
Before enum we didn't have something like:

AddressFamily = (AF_INET, AF_INET6, ...)

Basically because we didn't need it. Sorry if I'm missing something here.

----------

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

From report at bugs.python.org  Sat Jan 25 21:33:59 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 25 Jan 2014 20:33:59 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390682039.15.0.270359419012.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I'm not saying the enums are necessary (argue about that with Eli), but that if they *are* in the module as a public attribute, they *have* to be documented, period.

----------

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

From report at bugs.python.org  Sat Jan 25 21:35:23 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 25 Jan 2014 20:35:23 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390682123.28.0.573975010712.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Complete patch with new test, fixed tests, and regression fix.

Doc patch still needed.

----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file33707/issue20386.stoneleaf.patch.02

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

From report at bugs.python.org  Sat Jan 25 21:40:35 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 25 Jan 2014 20:40:35 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390682435.27.0.757209818983.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The containers are there to help with discoverability.  If you want to know what all the (common) AF values are you can either do

    [name for name in dir(socket) if name.isupper() and name.startswith('AF_')]

or

    list(socket.AddressFamily)

----------

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

From report at bugs.python.org  Sat Jan 25 22:29:29 2014
From: report at bugs.python.org (Zearin)
Date: Sat, 25 Jan 2014 21:29:29 +0000
Subject: [docs] [issue20393] Docs: mark deprecated items in the TOC
Message-ID: <1390685369.63.0.965002484298.issue20393@psf.upfronthosting.co.za>


New submission from Zearin:

When exploring the docs for the standard library, it?s frustrating to have an idea and look for the answer only to find out that an entire module (or package) has been deprecated _after_ I click on it. 

Can we have links to deprecated items on the Standard Library?s TOC page flagged?  

I see you?re using multiple CSS classes on some links.  I propose: 

- add a CSS class to flag links to deprecated items
- use something like the following CSS


----

/*
 * Example 1: color 
 */
.toctree-wrapper a.deprecated {
    color: #933;
}

/* 
 * Example 2: "badge" 
 */
.toctree-wrapper a.deprecated:after {
	display: inline-block;
    content: "deprecated";
	margin: 0 1em;
	padding: 0 1ex !important;
	border-radius: 			1ex !important;
    
	font-size: x-small;
    
	background-color: #f66;
    color: #933;
}

----

Of course, since the CSS class '.deprecated' already exists, there's 2 options: 

1. the examples above are rewritten to use a different classname, or 
2. add the following CSS:

----

/* "Reset" .deprecated in a toctree context */
.toctree-wrapper a.deprecated {
    background: none;
	border: none;
	padding: 0;
}

/* << insert above example CSS here >> */

----

----------
assignee: docs at python
components: Documentation
messages: 209239
nosy: docs at python, zearin
priority: normal
severity: normal
status: open
title: Docs: mark deprecated items in the TOC
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/issue20393>
_______________________________________

From report at bugs.python.org  Sat Jan 25 22:33:59 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 25 Jan 2014 21:33:59 +0000
Subject: [docs] [issue20393] Docs: mark deprecated items in the TOC
In-Reply-To: <1390685369.63.0.965002484298.issue20393@psf.upfronthosting.co.za>
Message-ID: <1390685639.15.0.161814087155.issue20393@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Jan 25 22:42:46 2014
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 25 Jan 2014 21:42:46 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390686166.9.0.801461378858.issue20386@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Yep, the overriding of the type name was inadvertent. Nothing sacred about it, so Ethan's SocketKind is just as good.

----------

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

From report at bugs.python.org  Sat Jan 25 23:07:28 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 25 Jan 2014 22:07:28 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390687648.56.0.457457740849.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

How do we feel about SockType instead?  (Just a short round of bike-shedding, promise! ;)

----------

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

From report at bugs.python.org  Sun Jan 26 01:43:25 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 26 Jan 2014 00:43:25 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390687648.56.0.457457740849.issue20386@psf.upfronthosting.co.za>
Message-ID: <CADiSq7dc8bRZPSNfe_eCX95=oEwdqF+Jp562nJrYxSZsDZwCuw@mail.gmail.com>


Nick Coghlan added the comment:

I strongly prefer SocketKind - SockType is far too close to SocketType and
"type" is too closely associated with the type system in general.

----------

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

From report at bugs.python.org  Sun Jan 26 02:33:09 2014
From: report at bugs.python.org (Nikolaus Rath)
Date: Sun, 26 Jan 2014 01:33:09 +0000
Subject: [docs] [issue20375] ElementTree: Document handling processing
	instructions
In-Reply-To: <1390539216.23.0.0362813865609.issue20375@psf.upfronthosting.co.za>
Message-ID: <1390699989.14.0.137266145646.issue20375@psf.upfronthosting.co.za>


Nikolaus Rath added the comment:

I've also attached a testcase to confirm that the docpatch reflects current behavior, and to make sure that anticipated enhancements in Python 3.5 behave in a backwards compatible way.

----------
Added file: http://bugs.python.org/file33713/etree-testcases.patch

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

From report at bugs.python.org  Sun Jan 26 12:43:35 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Jan 2014 11:43:35 +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: <1390736615.24.0.312171209313.issue15759@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I nominate this text:

**********************************************************************
To make these errors go away, merge the contents of "build/suspicious/suspicious.csv" to "tools/sphinxext/susp-ignored.csv".
**********************************************************************


Alternatively, we could add a "make trustworthy" target that did this work automatically, in which case the text should be

**********************************************************************
To make these errors go away, run "make trustworthy".
**********************************************************************

----------
nosy: +larry

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

From report at bugs.python.org  Sun Jan 26 13:12:08 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Jan 2014 12:12:08 +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: <1390738328.85.0.789241978776.issue15759@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Since Ezio asked me, I guess I wasn't clear:

This message should be displayed at the bottom, after the errors, and only when there are alleged suspicious documentation activities.

----------

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

From report at bugs.python.org  Sun Jan 26 14:31:16 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 13:31:16 +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: <1390743076.14.0.525394788373.issue15759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Try this patch.

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file33726/make_suspicious.patch

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

From report at bugs.python.org  Sun Jan 26 14:43:37 2014
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 26 Jan 2014 13:43:37 +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: <1390743817.02.0.558562922897.issue15759@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good. Maybe Larry will want his line of stars though :)

----------

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

From report at bugs.python.org  Sun Jan 26 15:03:07 2014
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 26 Jan 2014 14:03:07 +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: <1390744987.21.0.537479634494.issue15759@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Can we use unicode characters?  I'd like little ships, or U+1F4A9.

----------

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

From report at bugs.python.org  Sun Jan 26 15:03:10 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 14:03:10 +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: <1390744990.74.0.335596188515.issue15759@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It was not such good. Here is better patch.

----------
Added file: http://bugs.python.org/file33727/make_suspicious.patch

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

From report at bugs.python.org  Sun Jan 26 15:03:22 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 26 Jan 2014 14:03:22 +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: <1390745002.45.0.340149875047.issue15759@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file33726/make_suspicious.patch

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

From report at bugs.python.org  Sun Jan 26 16:26:01 2014
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 26 Jan 2014 15:26:01 +0000
Subject: [docs] [issue19863] Missing function attributes in 2.7 docs.
In-Reply-To: <1386010673.68.0.260580445507.issue19863@psf.upfronthosting.co.za>
Message-ID: <1390749961.94.0.190466924922.issue19863@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> LGTM, but may be write Py3k compatible names at first place?

+1

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

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

From report at bugs.python.org  Sun Jan 26 22:47:22 2014
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 26 Jan 2014 21:47:22 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390772842.73.0.868372649022.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Okay, staying with SocketKind.

This patch also has a very small doc enhancement.

----------
keywords: +patch
Added file: http://bugs.python.org/file33735/issue20386.stoneleaf.03.patch

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

From report at bugs.python.org  Mon Jan 27 01:39:07 2014
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 27 Jan 2014 00:39:07 +0000
Subject: [docs] [issue19023] ctypes docs: Unimplemented and undocumented
	features
In-Reply-To: <1379246270.23.0.998338553474.issue19023@psf.upfronthosting.co.za>
Message-ID: <1390783147.69.0.561349359799.issue19023@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge

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

From report at bugs.python.org  Mon Jan 27 04:24:16 2014
From: report at bugs.python.org (Rob Lanphier)
Date: Mon, 27 Jan 2014 03:24:16 +0000
Subject: [docs] [issue20402] List comprehensions should be noted in for
	loop	documentation
Message-ID: <1390793056.66.0.0906291243976.issue20402@psf.upfronthosting.co.za>


New submission from Rob Lanphier:

The current list comprehension documentation is difficult to find for someone who doesn't know what a list comprehension is.  Example of this problem:
http://www.reddit.com/r/learnprogramming/comments/1w6slm/different_kind_of_for_loop_python/

Since list comprehensions are a riff off of "for" loop syntax, they should at least be noted and linked to from section 4.2 ("for statements" section) and quite possibly 5.6 ("Looping constructs")

----------
assignee: docs at python
components: Documentation
messages: 209380
nosy: docs at python, robla
priority: normal
severity: normal
status: open
title: List comprehensions should be noted in for loop documentation
type: enhancement

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

From report at bugs.python.org  Mon Jan 27 04:58:51 2014
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 27 Jan 2014 03:58:51 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <3fCHJB5MpQz7LjV@mail.python.org>


Roundup Robot added the comment:

New changeset e02da391741f by Benjamin Peterson in branch '3.3':
eliminate redundancy between yield stmt and yield expr docs (closes #12704)
http://hg.python.org/cpython/rev/e02da391741f

New changeset c6b4a5354c23 by Benjamin Peterson in branch 'default':
merge 3.3 (closes #12704)
http://hg.python.org/cpython/rev/c6b4a5354c23

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jan 27 04:59:48 2014
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 27 Jan 2014 03:59:48 +0000
Subject: [docs] [issue12704] Language Reference: Clarify behaviour of yield
	when	generator is not resumed
In-Reply-To: <1312654346.88.0.619161172388.issue12704@psf.upfronthosting.co.za>
Message-ID: <1390795188.74.0.809343548761.issue12704@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Thank you. In the future, please remember to wrap paragraphs to 80 chars and run "make patchcheck" to cleanup whitespace issues.

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

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

From report at bugs.python.org  Mon Jan 27 07:15:22 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 27 Jan 2014 06:15:22 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390803322.93.0.341521216365.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

"integer enumerations of <enumtype>" sounds weird to me.

Also, here it might be nice to link to IntEnum (use :class:`.IntEnum`).

----------

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

From report at bugs.python.org  Mon Jan 27 07:30:11 2014
From: report at bugs.python.org (Christopher Welborn)
Date: Mon, 27 Jan 2014 06:30:11 +0000
Subject: [docs] [issue19620] tokenize documentation contains typos (argment
	instead	of argument)
In-Reply-To: <1384569112.62.0.796047767365.issue19620@psf.upfronthosting.co.za>
Message-ID: <1390804211.54.0.9570653761.issue19620@psf.upfronthosting.co.za>


Christopher Welborn added the comment:

I should've made the patch, sorry about that. I got really busy and by the time I came back it had been fixed already. (fast turnaround :)
I'm just glad it got fixed. I'm removing myself from the nosy-list.

----------

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

From report at bugs.python.org  Mon Jan 27 07:30:47 2014
From: report at bugs.python.org (Christopher Welborn)
Date: Mon, 27 Jan 2014 06:30:47 +0000
Subject: [docs] [issue19620] tokenize documentation contains typos (argment
	instead	of argument)
In-Reply-To: <1384569112.62.0.796047767365.issue19620@psf.upfronthosting.co.za>
Message-ID: <1390804247.93.0.596708190345.issue19620@psf.upfronthosting.co.za>


Changes by Christopher Welborn <cjwelborn at live.com>:


----------
nosy:  -cjwelborn

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

From francismb at email.de  Sun Jan 26 16:20:18 2014
From: francismb at email.de (francismb at email.de)
Date: Sun, 26 Jan 2014 15:20:18 -0000
Subject: [docs] Add doc examples for DictReader and DictWriter (issue
	20351)
Message-ID: <20140126152018.14660.44314@psf.upfronthosting.co.za>

LGTM

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

From report at bugs.python.org  Mon Jan 27 20:15:32 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2014 19:15:32 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390850132.8.0.980537791023.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Well, so far I have tried:

  :class:`IntEnum`
  :class:`.IntEnum`
  :class:`~IntEnum`
  :class:`enum.IntEnum`
  :class:`.enum.IntEnum`
  :class:`~enum.IntEnum`
  :class:`~.enum.IntEnum`

and probably some others I have forgotten; nothing is giving me a link to enum.IntEnum.

Any ideas?

----------

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

From report at bugs.python.org  Mon Jan 27 20:20:41 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 27 Jan 2014 19:20:41 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390850441.72.0.346210426245.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Well, IntEnum is nowhere documented as a class.  IOW,

.. class:: IntEnum

is missing if you want these references to work.

----------

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

From report at bugs.python.org  Mon Jan 27 20:33:11 2014
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 27 Jan 2014 19:33:11 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390851191.22.0.820851809651.issue20386@psf.upfronthosting.co.za>


Ethan Furman added the comment:

IntEnum is not a class in the socket module.

How do I make a link into another rst document?

----------

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

From report at bugs.python.org  Mon Jan 27 21:28:14 2014
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 27 Jan 2014 20:28:14 +0000
Subject: [docs] [issue20386] socket.SocketType enum overwrites import
	of	_socket.SocketType
In-Reply-To: <1390603701.84.0.039670998795.issue20386@psf.upfronthosting.co.za>
Message-ID: <1390854494.21.0.835741614854.issue20386@psf.upfronthosting.co.za>


Georg Brandl added the comment:

IntEnum is not a class in the enum module either, as far as the docs are concerned ;)

Otherwise :class:`enum.IntEnum` or :class:`.IntEnum` would work, no matter the source and target documents.

----------

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

From report at bugs.python.org  Mon Jan 27 21:41:06 2014
From: report at bugs.python.org (RalfM)
Date: Mon, 27 Jan 2014 20:41:06 +0000
Subject: [docs] [issue20413] Errors in documentation of standard codec error
	handlers
Message-ID: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za>


New submission from RalfM:

The standard library documentation lists the standard codec error handlers in three places:

(a) 2. Build-in Functions, section open()
(b) 7.2 codecs - Codec registry and base classes
(c) 7.2.1 Codec Base Classes

As far as I can judge these lists, (c) looks ok, but (a) and (b) contain two errors:
1. 'surrogatepass' is not mentioned.
2. 'surrogateescape' is described as: 
   'on decoding, replace with code points in the Unicode Private
   Use Area ranging from U+DC80 to U+DCFF. These private code points
   will ...' 
   This is incorrect in so far as U+DC80 to U+DCFF are not private 
   code points, but (low-)surrogate code points. This is correctly
   explained in (c) and in PEP383 (and, of course, in the Unicode 
   standard, chapter 16).

I suggest to correct (a) and (b) by
* adding 'surrogatepass' with the description given in (c),
* changing the description of 'surrogateescape' to something like: 
  'on decoding, replace with surrogate code points ranging from 
  U+DC80 to U+DCFF. These surrogate code points will ...'.

These errors are present in the documentation (more precisely, the .chm files) of at least 
- Python 3.3.3
- Python 3.3.4rc1
- Python 3.4.0b3.

----------
assignee: docs at python
components: Documentation
messages: 209477
nosy: RalfM, docs at python
priority: normal
severity: normal
status: open
title: Errors in documentation of standard codec error handlers
type: enhancement
versions: Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jan 27 23:04:22 2014
From: report at bugs.python.org (Moritz Neeb)
Date: Mon, 27 Jan 2014 22:04:22 +0000
Subject: [docs] [issue20030] unittest.TestLoader.discover return value
	incorrectly	documented.
In-Reply-To: <1387530145.58.0.951879545916.issue20030@psf.upfronthosting.co.za>
Message-ID: <1390860262.49.0.842705661295.issue20030@psf.upfronthosting.co.za>


Changes by Moritz Neeb <nt4u at kpvn.de>:


----------
nosy: +zormit

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

From report at bugs.python.org  Tue Jan 28 06:43:55 2014
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 28 Jan 2014 05:43:55 +0000
Subject: [docs] [issue20413] Errors in documentation of standard codec error
	handlers
In-Reply-To: <1390855266.06.0.0688884977578.issue20413@psf.upfronthosting.co.za>
Message-ID: <1390887835.58.0.297372145338.issue20413@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I plan to take a look at the codec docs in general in the next week or so, I'll tackle this as well.

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

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

From report at bugs.python.org  Tue Jan 28 20:24:38 2014
From: report at bugs.python.org (couplewavylines)
Date: Tue, 28 Jan 2014 19:24:38 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
Message-ID: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>


New submission from couplewavylines:

In io.StringIO, the newline argument's default is currently documented as "newline=None" in the section header. However, it's described this way:  "The default is to do no newline translation."  The behavior of io.StringIO is consistent with this description (NO newline translation). 
The header should actually read "newline=''".
"newline=None" would mean there IS newline translation by default, which is not the case. Code sample attached as no_translation.py.

----------
assignee: docs at python
components: Documentation
files: no_translation.py
messages: 209577
nosy: couplewavylines, docs at python
priority: normal
severity: normal
status: open
title: io.StringIO newline param has wrong default
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file33779/no_translation.py

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

From report at bugs.python.org  Tue Jan 28 20:26:20 2014
From: report at bugs.python.org (couplewavylines)
Date: Tue, 28 Jan 2014 19:26:20 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>
Message-ID: <1390937180.7.0.320430801818.issue20423@psf.upfronthosting.co.za>


Changes by couplewavylines <couplewavylines at gmail.com>:


Added file: http://bugs.python.org/file33780/no_translation_output.txt

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

From report at bugs.python.org  Tue Jan 28 20:37:24 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2014 19:37:24 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>
Message-ID: <1390937843.96.0.682710358648.issue20423@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, actual default is '\n'.

>>> io.StringIO('abc\r\ndef\nghi\rklm').readlines()
['abc\r\n', 'def\n', 'ghi\rklm']
>>> io.StringIO('abc\r\ndef\nghi\rklm', newline=None).readlines()
['abc\n', 'def\n', 'ghi\n', 'klm']
>>> io.StringIO('abc\r\ndef\nghi\rklm', newline='').readlines()
['abc\r\n', 'def\n', 'ghi\r', 'klm']
>>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\n').readlines()
['abc\r\n', 'def\n', 'ghi\rklm']
>>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\r').readlines()
['abc\r', '\r', 'def\r', 'ghi\r', 'klm']
>>> io.StringIO('abc\r\ndef\nghi\rklm', newline='\r\n').readlines()
['abc\r\r\n', 'def\r\n', 'ghi\rklm']

----------
keywords: +easy
nosy: +serhiy.storchaka
stage:  -> needs patch
versions: +Python 2.7

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

From report at bugs.python.org  Tue Jan 28 20:44:20 2014
From: report at bugs.python.org (couplewavylines)
Date: Tue, 28 Jan 2014 19:44:20 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>
Message-ID: <1390938260.26.0.413484710825.issue20423@psf.upfronthosting.co.za>


couplewavylines added the comment:

Serhiy, you're right, I now see the default behavior is "newline='\n'".

So, the header is still wrong, and the text is "The default is to do no newline translation" may be incorrect too?  Or just unclear (to me anyway)?

----------

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

From report at bugs.python.org  Tue Jan 28 20:51:05 2014
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 28 Jan 2014 19:51:05 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>
Message-ID: <1390938664.94.0.197345244035.issue20423@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On other hand, may be the behavior of io.StringIO is wrong. Because it is different from io.TextIOWrapper.

>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm')).readlines()
['abc\n', 'def\n', 'ghi\n', 'klm']
>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline=None).readlines()
['abc\n', 'def\n', 'ghi\n', 'klm']
>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='').readlines()
['abc\r\n', 'def\n', 'ghi\r', 'klm']
>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\n').readlines()
['abc\r\n', 'def\n', 'ghi\rklm']
>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\r').readlines()
['abc\r', '\ndef\nghi\r', 'klm']
>>> io.TextIOWrapper(io.BytesIO(b'abc\r\ndef\nghi\rklm'), newline='\r\n').readlines()
['abc\r\n', 'def\nghi\rklm']

----------
nosy: +benjamin.peterson, hynek, pitrou, stutzbach

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

From report at bugs.python.org  Tue Jan 28 22:35:28 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Jan 2014 21:35:28 +0000
Subject: [docs] [issue19573] Fix the docstring of inspect.Parameter and
	the	implementation of _ParameterKind
In-Reply-To: <1384371223.06.0.467962768293.issue19573@psf.upfronthosting.co.za>
Message-ID: <1390944928.79.0.427634663023.issue19573@psf.upfronthosting.co.za>


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


----------
nosy: +yselivanov
versions: +Python 3.5 -Python 3.4

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

From report at bugs.python.org  Tue Jan 28 22:42:10 2014
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 28 Jan 2014 21:42:10 +0000
Subject: [docs] [issue20423] io.StringIO newline param has wrong default
In-Reply-To: <1390937078.16.0.885697814935.issue20423@psf.upfronthosting.co.za>
Message-ID: <1390945330.1.0.552773082155.issue20423@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Using '\n' as default is normal: StringIOs are not stored on disk so there's no point in converting newlines by default (it's only slower while not improving interoperability). '\n' is the default line separator in Python.

So we should just fix the docs here.

The bug when using '\r' or '\r\n' should probably be fixed though (that would be a separate issue).

----------

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

From report at bugs.python.org  Tue Jan 28 22:42:18 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 28 Jan 2014 21:42:18 +0000
Subject: [docs] [issue19573] Fix the docstring of inspect.Parameter and
	the	implementation of _ParameterKind
In-Reply-To: <1384371223.06.0.467962768293.issue19573@psf.upfronthosting.co.za>
Message-ID: <1390945338.81.0.11906474838.issue19573@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Antony, the docstrings are fixed. Could you please provide a patch just for the _ParameterKind-Enum refactoring? I'll incorporate it into 3.5 then.

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

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

From bbayles at gmail.com  Tue Jan 28 03:45:23 2014
From: bbayles at gmail.com (Bo Bayles)
Date: Mon, 27 Jan 2014 20:45:23 -0600
Subject: [docs] Missing word or typo in library/xml.txt
Message-ID: <CALqAb4zcJa5cxNzbco-oVd8jo2Otx6JVYmV=V0eGPtJ-0R==XA@mail.gmail.com>

To whom it may concern,

I noticed that the documentation at
http://docs.python.org/3.4/_sources/library/xml.txt has a missing word
or phrase.

It says:
    * :mod:`xml.etree.EementTree`: the ElementTree API, a simple and lightweight

It should probably say something like:
    * :mod:`xml.etree.EementTree`: the ElementTree API, a simple and
lightweight processor

If "processor" is not the right completion there should at least be
some noun at the end.

Regards,
-Bo Bayles

From meisterplanlos at gmx.de  Wed Jan 29 14:53:43 2014
From: meisterplanlos at gmx.de (meisterplanlos at gmx.de)
Date: Wed, 29 Jan 2014 14:53:43 +0100
Subject: [docs] Python Doc: Usage of politically incorrect terms
Message-ID: <CAE48n-+5TN32HU=iTY4hznf01XcoEA=xgX0F6tAOCd28KmnKuA@mail.gmail.com>

Dear Pythonians,

Please do not use the term "refusenik" in the python tutorial (
http://docs.python.org/2/tutorial/controlflow.html#default-argument-values).
It could offend people (http://en.wikipedia.org/wiki/Refusenik) which
should not be the intention of Python.

Thanks,
Holger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140129/16b11f1d/attachment.html>

From report at bugs.python.org  Wed Jan 29 19:53:50 2014
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 29 Jan 2014 18:53:50 +0000
Subject: [docs] [issue17727] document that some distributions change site.py
	defaults
In-Reply-To: <1365929014.79.0.72904930991.issue17727@psf.upfronthosting.co.za>
Message-ID: <1391021629.9.0.979645425756.issue17727@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Matthias and I agreed this isn't necessary since on the relevant distribution it's already documented.

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

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

From shangonichols at sbcglobal.net  Wed Jan 29 19:39:45 2014
From: shangonichols at sbcglobal.net (shangonichols at sbcglobal.net)
Date: Wed, 29 Jan 2014 18:39:45 +0000
Subject: [docs] =?utf-8?q?Won=27t_open_new_file?=
Message-ID: <693902.12783.bm@smtp229.mail.gq1.yahoo.com>

My python shell keeps closing when I attempt to open a new file. What is going wrong?






Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140129/00ab6da8/attachment-0001.html>

From shangonichols at sbcglobal.net  Wed Jan 29 20:10:43 2014
From: shangonichols at sbcglobal.net (shangonichols at sbcglobal.net)
Date: Wed, 29 Jan 2014 19:10:43 +0000
Subject: [docs] =?utf-8?q?Python_won=27t_open_IDLE?=
Message-ID: <449489.44247.bm@smtp234.mail.gq1.yahoo.com>

 I tried to open a file and nothing happened. If I tried to open a .py file (any .py file) from an existing instance of IDLE, it briefly flashed up a new window and then closed both the new window and the existing window (normally it opens the requested in a new window leaving the existing window untouched).

If I launch the Python GUI it opens a Python Shell fine. But as soon as I try to open a file (including a "new" file), it closes the Shell.

I rebooted the machine. Same problem.

I repaired the Python installation and rebooted. Same problem.

I uninstalled Python. Rebooted. Deleted the Python33 directory entirely. Rebooted. Installed Python. Rebooted. Same problem.

Everything else on the system appears to be working just fine.

Any ideas what the problem might be or how else I might go about fixing things?






Sent from Windows Mail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140129/3100e0ed/attachment-0001.html>

From zachary.ware+pydocs at gmail.com  Wed Jan 29 21:27:44 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Wed, 29 Jan 2014 14:27:44 -0600
Subject: [docs] Python won't open IDLE
In-Reply-To: <449489.44247.bm@smtp234.mail.gq1.yahoo.com>
References: <449489.44247.bm@smtp234.mail.gq1.yahoo.com>
Message-ID: <CAKJDb-NdGDqenNXhgb82X1-OfzFh=nhFEz17=R4H4ngUpvsfGQ@mail.gmail.com>

Hi,

On Wed, Jan 29, 2014 at 1:10 PM,  <shangonichols at sbcglobal.net> wrote:
>  I tried to open a file and nothing happened. If I tried to open a .py file
> (any .py file) from an existing instance of IDLE, it briefly flashed up a
> new window and then closed both the new window and the existing window
> (normally it opens the requested in a new window leaving the existing window
> untouched).
>
> If I launch the Python GUI it opens a Python Shell fine. But as soon as I
> try to open a file (including a "new" file), it closes the Shell.
>
> I rebooted the machine. Same problem.
>
> I repaired the Python installation and rebooted. Same problem.
>
> I uninstalled Python. Rebooted. Deleted the Python33 directory entirely.
> Rebooted. Installed Python. Rebooted. Same problem.
>
> Everything else on the system appears to be working just fine.
>
> Any ideas what the problem might be or how else I might go about fixing
> things?

This list is not the correct venue for your question; docs at python.org
is meant for questions, comments, and discussion about the
documentation of Python.  Please send your question to
python-list at python.org or tutor at python.org, either of which has
several people listening in who would be happy to try to help with
your problem.

When you send your question to one of those lists, be sure to include
which version of Python you are using and which version of Windows you
are on, as one or both of those data points may play into the
resolution of your issue.

Regards,

-- 
Zach

From report at bugs.python.org  Wed Jan 29 23:32:38 2014
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 29 Jan 2014 22:32:38 +0000
Subject: [docs] [issue14512] Pydocs module docs server not working on
	Windows.
In-Reply-To: <1333645625.74.0.578211515784.issue14512@psf.upfronthosting.co.za>
Message-ID: <1391034758.87.0.60082978869.issue14512@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

On current 3.3.4 and 3.4.0 start menus, clicking Module Docs does nothing that I can see except add a useless entry to the Frequent Programs list. 

I think the entry should be removed from the menu until it is made to work. All it does now is frustrate people and make Python look bad.

----------
nosy: +larry
versions: +Python 3.4 -Python 3.2

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

From report at bugs.python.org  Fri Jan 31 17:51:28 2014
From: report at bugs.python.org (OSAMU NAKAMURA)
Date: Fri, 31 Jan 2014 16:51:28 +0000
Subject: [docs] [issue20460] Wrong markup in c-api/arg.rst
Message-ID: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za>


New submission from OSAMU NAKAMURA:

":func:`bytes`" in description for ``y`` format 
should be ":class:`bytes`".

----------
assignee: docs at python
components: Documentation
files: mywork.patch
keywords: patch
messages: 209806
nosy: OSAMU.NAKAMURA, docs at python
priority: normal
severity: normal
status: open
title: Wrong markup in c-api/arg.rst
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file33835/mywork.patch

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

From zachary.ware+pydocs at gmail.com  Fri Jan 31 18:33:02 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 11:33:02 -0600
Subject: [docs] Missing word or typo in library/xml.txt
In-Reply-To: <CALqAb4zcJa5cxNzbco-oVd8jo2Otx6JVYmV=V0eGPtJ-0R==XA@mail.gmail.com>
References: <CALqAb4zcJa5cxNzbco-oVd8jo2Otx6JVYmV=V0eGPtJ-0R==XA@mail.gmail.com>
Message-ID: <CAKJDb-M81O45VwgVW5H91WW9hCs7gUibH4_e2hAxTZr8zjvorQ@mail.gmail.com>

Hi Bo,

On Mon, Jan 27, 2014 at 8:45 PM, Bo Bayles <bbayles at gmail.com> wrote:
> To whom it may concern,
>
> I noticed that the documentation at
> http://docs.python.org/3.4/_sources/library/xml.txt has a missing word
> or phrase.
>
> It says:
>     * :mod:`xml.etree.EementTree`: the ElementTree API, a simple and lightweight
>
> It should probably say something like:
>     * :mod:`xml.etree.EementTree`: the ElementTree API, a simple and
> lightweight processor
>
> If "processor" is not the right completion there should at least be
> some noun at the end.

This has been fixed in revision 681c86da0664 and should be live soon.

Thanks for the report and suggestion!

-- 
Zach

From report at bugs.python.org  Fri Jan 31 19:07:44 2014
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 31 Jan 2014 18:07:44 +0000
Subject: [docs] [issue20460] Wrong markup in c-api/arg.rst
In-Reply-To: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za>
Message-ID: <3fG5xq3dTSz7LlF@mail.python.org>


Roundup Robot added the comment:

New changeset 7a611b7aae38 by Zachary Ware in branch '3.3':
Issue #20460: Render 'bytes' as a class, not a function.
http://hg.python.org/cpython/rev/7a611b7aae38

New changeset b56ce3410ca6 by Zachary Ware in branch 'default':
Issue #20460: Merge with 3.3
http://hg.python.org/cpython/rev/b56ce3410ca6

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

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

From report at bugs.python.org  Fri Jan 31 19:08:16 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Jan 2014 18:08:16 +0000
Subject: [docs] [issue20460] Wrong markup in c-api/arg.rst
In-Reply-To: <1391187088.65.0.311524053525.issue20460@psf.upfronthosting.co.za>
Message-ID: <1391191696.26.0.368558764683.issue20460@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Fixed, thanks for the report and patch!

If you intend to ever contribute more than the simplest of patches, please consider signing a contributor's agreement: http://www.python.org/psf/contrib/

Thanks!

----------
nosy: +zach.ware
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From zachary.ware+pydocs at gmail.com  Fri Jan 31 19:27:22 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 12:27:22 -0600
Subject: [docs] possible dox bug in floating point tutorial
In-Reply-To: <52D41BAC.4090505@wolfram.com>
References: <52D41BAC.4090505@wolfram.com>
Message-ID: <CAKJDb-P93ZUZuqzZHAes+AnnfWuMuUruD4Z6Q5DmwsK-72+J7w@mail.gmail.com>

Hi Daniel,

On Mon, Jan 13, 2014 at 11:00 AM, Daniel Lichtblau <danl at wolfram.com> wrote:
> (I'm not sure if this is a bug but it seems mysterious.)
>
> http://docs.python.org/2.6/tutorial/floatingpoint.html
>
> Mentions that 0.1, under the hood, is a fairly long decimal.
> Specifically:
> "On most machines, if Python were to print the true
> decimal value of the binary approximation stored for 0.1, it would have to
> display
>
>>>> 0.1
>
> 0.1000000000000000055511151231257827021181583404541015625
>
> instead!"
>
> This seems to be too long for any hardware floating point representation,
> even quad. Also the length of that decimal string is 54. While that's not
> quite as suspicious as 53, it still makes one wonder if that should be
> the length of the corresponding display for a binary representation.

To understate it slightly, I'm not extremely familiar with the
intricacies of binary floating point.  However, I can tell you that
'0.1000000000000000055511151231257827021181583404541015625' was most
likely obtained like so:

   >>> from decimal import Decimal as d
   >>> str(d(0.1))
   '0.1000000000000000055511151231257827021181583404541015625'

Hopefully that takes some of the mystery out of it!  If you believe
this representation to be incorrect, do please open an issue on the
bug tracker.

Regards,

-- 
Zach

From danl at wolfram.com  Fri Jan 31 19:49:08 2014
From: danl at wolfram.com (Daniel Lichtblau)
Date: Fri, 31 Jan 2014 12:49:08 -0600
Subject: [docs] possible dox bug in floating point tutorial
In-Reply-To: <CAKJDb-P93ZUZuqzZHAes+AnnfWuMuUruD4Z6Q5DmwsK-72+J7w@mail.gmail.com>
References: <52D41BAC.4090505@wolfram.com>
 <CAKJDb-P93ZUZuqzZHAes+AnnfWuMuUruD4Z6Q5DmwsK-72+J7w@mail.gmail.com>
Message-ID: <52EBF024.80906@wolfram.com>


On 01/31/2014 12:27 PM, Zachary Ware wrote:
> Hi Daniel,
>
> On Mon, Jan 13, 2014 at 11:00 AM, Daniel Lichtblau <danl at wolfram.com> wrote:
>> (I'm not sure if this is a bug but it seems mysterious.)
>>
>> http://docs.python.org/2.6/tutorial/floatingpoint.html
>>
>> Mentions that 0.1, under the hood, is a fairly long decimal.
>> Specifically:
>> "On most machines, if Python were to print the true
>> decimal value of the binary approximation stored for 0.1, it would have to
>> display
>>
>>>>> 0.1
>> 0.1000000000000000055511151231257827021181583404541015625
>>
>> instead!"
>>
>> This seems to be too long for any hardware floating point representation,
>> even quad. Also the length of that decimal string is 54. While that's not
>> quite as suspicious as 53, it still makes one wonder if that should be
>> the length of the corresponding display for a binary representation.
> To understate it slightly, I'm not extremely familiar with the
> intricacies of binary floating point.  However, I can tell you that
> '0.1000000000000000055511151231257827021181583404541015625' was most
> likely obtained like so:
>
>     >>> from decimal import Decimal as d
>     >>> str(d(0.1))
>     '0.1000000000000000055511151231257827021181583404541015625'
>
> Hopefully that takes some of the mystery out of it!  If you believe
> this representation to be incorrect, do please open an issue on the
> bug tracker.
>
> Regards,
>

Dear Zachary,

Thank you for showing this. Searching on "from decimal import Decimal"
I then located the link below.

http://docs.python.org/3/library/decimal.html

Documentation there now makes me fairly confident that what I saw
is not a bug. It simply indicates that Python is using extended
precision behind the scenes in some automated manner. Now this is
slightly mysterious in that it shows up in the context of discussion
of Python (hardware) floats, but that does not make it a bug.

The fact that the length was approximately the same as the mantissa
for almost all machine doubles in current hardware is incidental.
Though I suspect not coincidental-- I think this length is needed
in order to one can represent every binary mantissa uniquely in
decimal form.

Thanks again for responding with this explanation for how that
number likely arose.

Best,
Daniel



From zachary.ware+pydocs at gmail.com  Fri Jan 31 20:22:45 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 13:22:45 -0600
Subject: [docs] Python not working properly
In-Reply-To: <BAY404-EAS23945C0583065B3EE380E1FF0AE0@phx.gbl>
References: <BAY404-EAS23945C0583065B3EE380E1FF0AE0@phx.gbl>
Message-ID: <CAKJDb-NGWv+B3-9tXELffwdB5-tjxbFL8=fhbqX3Uai=sEJDVQ@mail.gmail.com>

Hi Dhyan,

On Fri, Jan 31, 2014 at 5:34 PM,  <dhyan.hariprasad at live.com> wrote:
> Respected Sir/Madam,
>
> I am Dhyan Hariprasad from India and I am new to programming. From the
> tutorials given in the internet I tried the print command.
> print ?hello world?
> When I try to execute the command it shows error

When asking a question such as this, it is always helpful to give
which version of Python you are using.  In this case, I would guess
that you are using Python 3.3, but are reading the tutorial found at
docs.python.org/2/tutorial which is meant for Python 2.7.  Use the
tutorial for Python 3, found at http://docs.python.org/3/tutorial and
you should be fine.

'print' was changed from being a statement in Python 2 to being a
function in Python 3, which means to use it in Python 3, you have to
call it like any other function, like so:

   >>> print("Hello, world!")
   Hello, world!

Hope this helps,

-- 
Zach

From zachary.ware+pydocs at gmail.com  Fri Jan 31 20:33:59 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 13:33:59 -0600
Subject: [docs] import.sys behavior in IDLE re: Modules tutorial section
	6.2
In-Reply-To: <CAHQP3uAX_p3YTfvmx8EBYbyH6a+pzrE_Pjhx6-5=ojNFbGKX+Q@mail.gmail.com>
References: <CAHQP3uAX_p3YTfvmx8EBYbyH6a+pzrE_Pjhx6-5=ojNFbGKX+Q@mail.gmail.com>
Message-ID: <CAKJDb-NuVO7V1EMHK+JRCsWgpj4WKRF6BTJLr=2BvxrZPRUTKw@mail.gmail.com>

Hi Robin,

On Thu, Jan 2, 2014 at 12:37 PM, Robin Zimmermann <robin.zimm at gmail.com> wrote:
> To whom it may concern:
>
> I've been slowly working through the tutorial in the Python v3.3.3
> documentation, and I ran into a weird thing with the first example in
> Section 6.2 on http://docs.python.org/3/tutorial/modules.html -
> "Standard Modules".
>
> The first command-line example block says:
>
>>>> import sys
>>>> sys.ps1
> '>>> '
>>>> sys.ps2
> '... '
>>>> sys.ps1 = 'C> '
> C> print('Yuck!')
> Yuck!
> C>
>
> I had just opened a new IDLE window*, typed "import sys", hit enter,
> then typed "sys.ps1" and hit enter. The Python shell returned the
> following error:
>
> ----
>
> Traceback (most recent call last):
>   File "<pyshell#1>", line 1, in <module>
>     sys.ps1
> AttributeError: 'module' object has no attribute 'ps1'
>
> ----
>
> In my confusion, I tried a couple more times; the transcript of
> everyhing following the above AttributeError follows:
>
> ----
>
>>>> ps1
> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in <module>
>     ps1
> NameError: name 'ps1' is not defined
>>>> sys.ps1
> Traceback (most recent call last):
>   File "<pyshell#3>", line 1, in <module>
>     sys.ps1
> AttributeError: 'module' object has no attribute 'ps1'
>>>> dir sys
> SyntaxError: invalid syntax
>>>> dir(sys)
> ['__displayhook__', '__doc__', '__excepthook__', '__loader__',
> '__name__', '__package__', '__stderr__', '__stdin__', '__stdout__',
> '_clear_type_cache', '_current_frames', '_debugmallocstats',
> '_getframe', '_home', '_mercurial', '_xoptions', 'api_version',
> 'argv', 'base_exec_prefix', 'base_prefix', 'builtin_module_names',
> 'byteorder', 'call_tracing', 'callstats', 'copyright', 'displayhook',
> 'dllhandle', 'dont_write_bytecode', 'exc_info', 'excepthook',
> 'exec_prefix', 'executable', 'exit', 'flags', 'float_info',
> 'float_repr_style', 'getcheckinterval', 'getdefaultencoding',
> 'getfilesystemencoding', 'getprofile', 'getrecursionlimit',
> 'getrefcount', 'getsizeof', 'getswitchinterval', 'gettrace',
> 'getwindowsversion', 'hash_info', 'hexversion', 'implementation',
> 'int_info', 'intern', 'last_traceback', 'last_type', 'last_value',
> 'maxsize', 'maxunicode', 'meta_path', 'modules', 'path', 'path_hooks',
> 'path_importer_cache', 'platform', 'prefix', 'setcheckinterval',
> 'setprofile', 'setrecursionlimit', 'setswitchinterval', 'settrace',
> 'stderr', 'stdin', 'stdout', 'thread_info', 'version', 'version_info',
> 'warnoptions', 'winver']
>
> ----
>
> Finally, without closing the IDLE window, I opened the Command Prompt**:
>
> ----
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> C:\Users\Packbat>python
> Python 3.3.3 (v3.3.3:c3896275c0f6, Nov 18 2013, 21:18:40) [MSC v.1600 32 bit (In
> tel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import sys
>>>> sys.ps1
> '>>> '
>>>>
>
> ----
>
> My best guess is that IDLE is not a perfectly faithful implementation
> of the command line; if this is the case, I feel it would be helpful
> either to modify the tutorial to note this explicitly or to contact
> the developers of IDLE regarding the discrepancy, if not both.
>
> Thank you for your time and trouble!

This is a known issue, tracked at http://bugs.python.org/issue13657.
This is a limitation of the way IDLE does things, and should
eventually be fixed (though your suggestion to mention this in the
tutorial may happen first).

Thanks for the report!

-- 
Zach

From zachary.ware+pydocs at gmail.com  Fri Jan 31 20:42:20 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 13:42:20 -0600
Subject: [docs] (no subject)
In-Reply-To: <CAEfz+Tz81EMuM2=F0=5AbSSZbci=vzhTKdXjk8Dh-J2AAVca6w@mail.gmail.com>
References: <CAEfz+Tz81EMuM2=F0=5AbSSZbci=vzhTKdXjk8Dh-J2AAVca6w@mail.gmail.com>
Message-ID: <CAKJDb-Pb_6S-d2aGi4AiXGwMujeUbrANm4Y_kSsYsN4yOArKKQ@mail.gmail.com>

Hi,

On Wed, Jan 1, 2014 at 7:11 AM, INADA Naoki <songofacandy at gmail.com> wrote:
> http://docs.python.org/3.3/library/unittest.mock.html#magic-mock
>
>> The two equality method, __eq__ and __ne__, are special. They do the
>> default equality comparison on identity, using a side effect, unless you
>> change their return value to return something else:
>
> What "using a side effect" means?

This wording does seem a bit odd, and I'm not sure what exactly it
means.  Would you mind opening an issue on the bug tracker and adding
Michael Foord to the nosy list?

Thanks!

-- 
Zach

From zachary.ware+pydocs at gmail.com  Fri Jan 31 21:39:06 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 14:39:06 -0600
Subject: [docs] documentation bug in "embedding python"
In-Reply-To: <CAOVdALyPtnFrsmG8TyNqW69yFVYvFVSrMhca8NOx35kupMiP8Q@mail.gmail.com>
References: <CAOVdALyPtnFrsmG8TyNqW69yFVYvFVSrMhca8NOx35kupMiP8Q@mail.gmail.com>
Message-ID: <CAKJDb-M+5pur_Z6+UQbBJ1JO=PO08aTcsZ+S9B6GUEb76CxmhQ@mail.gmail.com>

Hi Riccardo,

On Tue, Dec 31, 2013 at 11:15 AM, Riccardo Rossi <rrossi at cimne.upc.edu> wrote:
> Dear developers,
>
> i tried the simplest possible embedding described in
>
> http://docs.python.org/3.3/extending/embedding.html#very-high-level-embedding
>
> using python3.
>
> the example code does not compile (from c++) with error:
> /home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp: In function
> ?int main(int, char**)?:
> /home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp:8:28: error:
> cannot convert ?char*? to ?wchar_t*? for argument ?1? to ?void
> Py_SetProgramName(wchar_t*)?
>    Py_SetProgramName(argv[0]);  /* optional but recommended */
>                             ^
>
>
> what is the correct version for this?
>
> if i define the main with wchar_t instead of char i get a warning...

Instead of changing the return type of main, try casting argv[0] to
wchar_t *, like so:

#include <Python.h>

int
main(int argc, char *argv[])
{
  Py_SetProgramName((wchar_t *)argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print('Today is', ctime(time()))\n");
  Py_Finalize();
  return 0;
}

This seems to work using MSVC++ 2010; if it works for you as well, I
will change the documentation page to match.

Thanks for the report!

-- 
Zach

From report at bugs.python.org  Fri Jan 31 21:55:11 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Jan 2014 20:55:11 +0000
Subject: [docs] [issue20464] Update distutils sample config file
	in	Doc/install/index.rst
Message-ID: <1391201711.97.0.184979826347.issue20464@psf.upfronthosting.co.za>


New submission from Zachary Ware:

>From docs@:

On Thu, Jan 16, 2014 at 2:56 AM, Peter Br?cker <peter.broecker at uni-koeln.de> wrote:
> Hi,
>
> I have tried to set up the distutils config files for a custom module
> installation. Using the suggested snippet  from
>
> http://docs.python.org/2/install/
>
> [install]
> install-base=$HOME/python
> install-purelib=lib
> install-platlib=lib.$PLAT
> install-scripts=scripts
> install-data=data did not work for me.
>
> Instead, I had to add install-headers and additionally modify all paths
> to include $base:
>
> [install]
> install-base=/some/dir
> install-purelib=$base/lib
> install-platlib=$base/lib.$PLAT
> install-scripts=$base/scripts
> install-headers=$base/include
> install-data=$base/data
>
>
> I'm unsure if this is actually a bug, but I could only resolve this with
> the help of this answer on stackoverflow:
> http://stackoverflow.com/a/12768721
>
> Best regards,
> Peter

----------
assignee: docs at python
components: Distutils, Documentation
messages: 209829
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: Update distutils sample config file in Doc/install/index.rst
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4

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

From zachary.ware+pydocs at gmail.com  Fri Jan 31 21:56:08 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 14:56:08 -0600
Subject: [docs] Wrong sample config file for custom module installation?
In-Reply-To: <52D79EBC.1040009@uni-koeln.de>
References: <52D79EBC.1040009@uni-koeln.de>
Message-ID: <CAKJDb-MZ6vn1BoG0bLoZDk2=Q1Ne7OTjMaOFP-BBvLX8PCybzA@mail.gmail.com>

On Thu, Jan 16, 2014 at 2:56 AM, Peter Br?cker
<peter.broecker at uni-koeln.de> wrote:
> Hi,
>
> I have tried to set up the distutils config files for a custom module
> installation. Using the suggested snippet  from
>
> http://docs.python.org/2/install/
>
> [install]
> install-base=$HOME/python
> install-purelib=lib
> install-platlib=lib.$PLAT
> install-scripts=scripts
> install-data=data did not work for me.
>
> Instead, I had to add install-headers and additionally modify all paths
> to include $base:
>
> [install]
> install-base=/some/dir
> install-purelib=$base/lib
> install-platlib=$base/lib.$PLAT
> install-scripts=$base/scripts
> install-headers=$base/include
> install-data=$base/data
>
>
> I'm unsure if this is actually a bug, but I could only resolve this with
> the help of this answer on stackoverflow:
> http://stackoverflow.com/a/12768721
>
> Best regards,
> Peter

I'm unsure as well, so I've created an issue to track this:
http://bugs.python.org/issue20464

Thanks for the report!

-- 
Zach

From rougered4 at gmail.com  Fri Jan 31 22:29:15 2014
From: rougered4 at gmail.com (Riccardo Rossi)
Date: Fri, 31 Jan 2014 21:29:15 -0000
Subject: [docs] documentation bug in "embedding python"
In-Reply-To: CAKJDb-M+5pur_Z6+UQbBJ1JO=PO08aTcsZ+S9B6GUEb76CxmhQ@mail.gmail.com
References: <CAOVdALyPtnFrsmG8TyNqW69yFVYvFVSrMhca8NOx35kupMiP8Q@mail.gmail.com>
 <CAKJDb-M+5pur_Z6+UQbBJ1JO=PO08aTcsZ+S9B6GUEb76CxmhQ@mail.gmail.com>
Message-ID: <-223719425907551510@unknownmsgid>

Dear Zach,

I tried what you propose but i think it is not the correct solution, in
particular it does not work in linux. Actually i believed that in win7 one
should try to use wmain instead of main, so that the system already passes
a wchar_t*

Having said this i youcan find the solution we use here:

https://kratos.cimne.upc.es/projects/kratos/repository/changes/kratos/embedded_python/krun_main.cpp

I documenti not want to claim it is the corrections solution, just that it
does work in win7 and Linux.

If you have access to the python gurus, it would be nice to have an expert
opini?n on this...

In any case thx for the attention
Riccardo

Sent from my BlackBerry? PlayBook?
www.blackberry.com

------------------------------
*From:* "Zachary Ware" <zachary.ware+pydocs at gmail.com>
*To:* "docs" <docs at python.org>
*CC:* "Riccardo Rossi" <rrossi at cimne.upc.edu>
*Sent:* January 31, 2014 9:39 PM
*Subject:* Re: [docs] documentation bug in "embedding python"

Hi Riccardo,

On Tue, Dec 31, 2013 at 11:15 AM, Riccardo Rossi  wrote:
> Dear developers,
>
> i tried the simplest possible embedding described in
>
> http://docs.python.org/3.3/extending/embedding.html#very-high-level-embedding
>
> using python3.
>
> the example code does not compile (from c++) with error:
> /home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp: In function
> ?int main(int, char**)?:
> /home/riccardo/scratch/kratospy3/embedded_python/krun_main.cpp:8:28: error:
> cannot convert ?char*? to ?wchar_t*? for argument ?1? to ?void
> Py_SetProgramName(wchar_t*)?
>    Py_SetProgramName(argv[0]);  /* optional but recommended */
>                             ^
>
>
> what is the correct version for this?
>
> if i define the main with wchar_t instead of char i get a warning...

Instead of changing the return type of main, try casting argv[0] to
wchar_t *, like so:

#include

int
main(int argc, char *argv[])
{
  Py_SetProgramName((wchar_t *)argv[0]);  /* optional but recommended */
  Py_Initialize();
  PyRun_SimpleString("from time import time,ctime\n"
                     "print('Today is', ctime(time()))\n");
  Py_Finalize();
  return 0;
}

This seems to work using MSVC++ 2010; if it works for you as well, I
will change the documentation page to match.

Thanks for the report!

-- 
Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20140131/1392264b/attachment.html>

From report at bugs.python.org  Fri Jan 31 23:11:27 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 31 Jan 2014 22:11:27 +0000
Subject: [docs] [issue14911] generator.throw() documentation inaccurate
In-Reply-To: <1337943736.85.0.146138312281.issue14911@psf.upfronthosting.co.za>
Message-ID: <1391206287.57.0.281908307509.issue14911@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Kristjan, can you write a patch for this?

----------
nosy: +yselivanov

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

From report at bugs.python.org  Fri Jan 31 23:14:09 2014
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 31 Jan 2014 22:14:09 +0000
Subject: [docs] [issue20466] Example in Doc/extending/embedding.rst fails to
	compile	cleanly
Message-ID: <1391206449.61.0.838795178148.issue20466@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Reported by Riccardo Rossi on docs@:

The Very High Level Embedding example fails to compile cleanly, due to Py_SetProgramName expecting a wchar_t * argument, while the example passes a char *.

----------
assignee: docs at python
components: Documentation
messages: 209837
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Example in Doc/extending/embedding.rst fails to compile cleanly
type: behavior
versions: Python 3.3, Python 3.4

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

From zachary.ware+pydocs at gmail.com  Fri Jan 31 23:15:04 2014
From: zachary.ware+pydocs at gmail.com (Zachary Ware)
Date: Fri, 31 Jan 2014 16:15:04 -0600
Subject: [docs] documentation bug in "embedding python"
In-Reply-To: <-223719425907551510@unknownmsgid>
References: <CAOVdALyPtnFrsmG8TyNqW69yFVYvFVSrMhca8NOx35kupMiP8Q@mail.gmail.com>
 <CAKJDb-M+5pur_Z6+UQbBJ1JO=PO08aTcsZ+S9B6GUEb76CxmhQ@mail.gmail.com>
 <-223719425907551510@unknownmsgid>
Message-ID: <CAKJDb-MD9wbZez2ZuFKR+c3jSGpnJqK-mCFTWJcXvGwn2idNJg@mail.gmail.com>

On Fri, Jan 31, 2014 at 3:29 PM, Riccardo Rossi <rougered4 at gmail.com> wrote:
> Dear Zach,
>
> I tried what you propose but i think it is not the correct solution, in
> particular it does not work in linux.

You're right; a little bit of research shows that what I tried is
certainly not correct.

I've opened an issue to get this fixed, see http://bugs.python.org/issue20466.

Thanks for the report!

-- 
Zach

From bgailer at gmail.com  Fri Jan 31 23:17:35 2014
From: bgailer at gmail.com (bob gailer)
Date: Fri, 31 Jan 2014 17:17:35 -0500
Subject: [docs] Python not working properly
In-Reply-To: <BAY404-EAS23945C0583065B3EE380E1FF0AE0@phx.gbl>
References: <BAY404-EAS23945C0583065B3EE380E1FF0AE0@phx.gbl>
Message-ID: <52EC20FF.8010407@gmail.com>

On 1/31/2014 6:34 PM, dhyan.hariprasad at live.com wrote:
> Respected Sir/Madam,
> I am Dhyan Hariprasad from India and I am new to programming. From the 
> tutorials given in the internet I tried the print command.
> print ?hello world?
> When I try to execute the command it shows error
Welcome.

docs at python.org is for commenting on Python documentation.

It's better to ask on help or tutor @python.org

Also it is a good idea to tell us what OS you are running, what version 
of Python, and what you do to edit and run a program.

When you get an error (technically an exception) please post the entire 
traceback. For example:

 >>> print ?hello world?
Traceback ( File "<interactive input>", line 1
print ?hello world?
^
SyntaxError: invalid character in identifier

The immediate problem here is the quotes around hello world are not 
ascii quote characters; they are the quotes you'd see in typesetting. 
This could be due to the editor you are using or the email program, in 
which case you retyped the code rather than copy-paste.

If you got:
 >>> print "hello world"
Traceback ( File "<interactive input>", line 1
print "hello world"
^
SyntaxError: invalid syntax

using the correct quotes then you are running Python 3.x in which print 
is a function, and must be called:
print("hello world")

BTW Python does not have commands, it has statements.


From report at bugs.python.org  Fri Jan 31 23:26:19 2014
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 31 Jan 2014 22:26:19 +0000
Subject: [docs] [issue14515] tempfile.TemporaryDirectory documented as
	returning	object but returns name
In-Reply-To: <1333678068.19.0.790451967958.issue14515@psf.upfronthosting.co.za>
Message-ID: <1391207179.82.0.65110787011.issue14515@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

bump?

----------
nosy: +yselivanov

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

From report at bugs.python.org  Fri Jan 31 23:41:34 2014
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 31 Jan 2014 22:41:34 +0000
Subject: [docs] [issue20467] Confusing wording about __init__
Message-ID: <1391208094.95.0.178232051767.issue20467@psf.upfronthosting.co.za>


New submission from Mark Lawrence:

I found the wording here http://docs.python.org/3/reference/datamodel.html#object.__init__ very confusing as it implies that __init__ is the class constructor and not the initialiser.  Specifically it says "As a special constraint on constructors, no value may be returned; doing so will cause a TypeError to be raised at runtime".  Can we please have the wording changed so that it states exactly what this method does?  Possibly changes are also needed in the equivalent section for __new__.

----------
assignee: docs at python
components: Documentation
messages: 209843
nosy: BreamoreBoy, docs at python
priority: normal
severity: normal
status: open
title: Confusing wording about __init__
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4

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