From report at bugs.python.org  Sun Jul  1 01:08:10 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Jun 2012 23:08:10 +0000
Subject: [docs] [issue15034] Devguide should document best practices for
	stdlib	exceptions
In-Reply-To: <1339118524.85.0.923317590244.issue15034@psf.upfronthosting.co.za>
Message-ID: <1341097690.48.0.332302304949.issue15034@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Raymond that this, especially super() is not tutorial material. I agree with David that we need something somewhere else. Just today a commit was pushed about IOException subclasses causing problems because they have an __init__ but don't call super(). (Something like that.) I had no idea about this issue.

The stdlib has things like "class ModException(Exception): pass". Is that okay because it does *not* have __init__ override?

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

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

From report at bugs.python.org  Sun Jul  1 04:34:33 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 01 Jul 2012 02:34:33 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
Message-ID: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I had an issue whereby my reST long_description wasn't getting rendered as HTML when uploaded to PyPI.  Following the instructions here did not work as-is:

http://docs.python.org/dev/distutils/uploading.html#pypi-package-display

It seems that PyPI passes --no-raw (no HTML allowed) to rst2html.py, in which case the guidance would be better updated to read--

$ python setup.py --long-description | rst2html.py --no-raw > output.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164445
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: update PyPI upload doc to say --no-raw passed to rst2html.py
versions: Python 3.3

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

From georg at python.org  Sun Jul  1 09:36:36 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:36:36 +0200
Subject: [docs] error in regular expression howto.
In-Reply-To: <CAMmiQ_QKPwN4rqVayFrppunc2NbFBVz6_-bU-m8V4oKwGTGW3w@mail.gmail.com>
References: <CAMmiQ_QKPwN4rqVayFrppunc2NbFBVz6_-bU-m8V4oKwGTGW3w@mail.gmail.com>
Message-ID: <4FEFFE04.7060001@python.org>

On 21.06.2012 14:41, Jonas Frey wrote:
> Hi,
>
> i think i found a little error in the regular expression howto
> (http://docs.python.org/py3k/howto/regex.html).
>
> Concerning \w, the howto states:
>
> \w
>      Matches any alphanumeric character; this is equivalent to the
> class [a-zA-Z0-9_].
>
> However, \w is *not* equivalent to [a-zA-Z0-9_].
> For example, the latter does not accept letterw with accents ????,
> whereas the former does.

Hi Jonas,

this is explained in the paragraph before the list of classes:

"""
The equivalent classes are for bytes patterns. For a complete list of sequences 
and expanded class definitions for Unicode string patterns, see the last part of 
Regular Expression Syntax.
"""

cheers,
Georg

From georg at python.org  Sun Jul  1 09:40:53 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:40:53 +0200
Subject: [docs] BUG: Bad footnote in library/profile.html
In-Reply-To: <AA4CE0344DEADB4A8776358B70975101FCB77A@HANMBX1.mg.themeganet.com>
References: <AA4CE0344DEADB4A8776358B70975101FCB77A@HANMBX1.mg.themeganet.com>
Message-ID: <4FEFFF05.9000109@python.org>

On 21.06.2012 16:55, aflanagan at mediageneral.com wrote:
> At http://docs.python.org/library/profile.html#id1, the footnote [1] links to
> a note about the documentation. Based on the context, it should be linked to
> the second footnote, which is "Prior to Python 2.2, it was necessary to edit
> the profiler source code to embed the bias as a literal number. You still
> can, but that method is no longer described, because no longer needed."

Hi,

thanks for the report, this is now fixed.

cheers,
Georg

From georg at python.org  Sun Jul  1 09:43:45 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:43:45 +0200
Subject: [docs] bug report: inconsistent use of PyUnicode_FromString and
 PyString_FromString "5.3. Pure Embedding"
In-Reply-To: <CALL-GrfzHhA-YD_8rSQxJ8fe=uhOH5DQJJXBTTYngX_eHb5-FA@mail.gmail.com>
References: <CALL-GrfzHhA-YD_8rSQxJ8fe=uhOH5DQJJXBTTYngX_eHb5-FA@mail.gmail.com>
Message-ID: <4FEFFFB1.9050200@python.org>

On 22.06.2012 08:04, Denver Coneybeare wrote:
> Hello,
>
> I was just perusing the Python docs, reading about extending Python with C.  I
> found a minor typo at
>
> http://docs.python.org/dev/extending/embedding.html#pure-embedding
>
> Line 16 of the code sample is:
>
>       pName = PyUnicode_FromString(argv[1]);
>
> But later on in the section, after the code sample, it shows a snippet of this
> code, but instead uses a different C function:
>
>       pName = PyString_FromString(argv[1]);
>
> I'm not sure if PyUnicode_FromString() is correct or PyString_FromString() is
> correct, or if it doesn't matter at all.  But whatever the choice, these should
> probably be made to be the same.
>
> I am emailing this address as documented at http://docs.python.org/dev/bugs.html
>
> Thanks!

Hi Denver,

thanks for the report, this is now fixed in our repository.

cheers,
Georg

From georg at python.org  Sun Jul  1 09:49:49 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:49:49 +0200
Subject: [docs] small documentation bug in multiprocessing
In-Reply-To: <CAOgNHrPiP3bO5qu6rmotbKTKa3_-+VVre=+PmY7RiqV7OKK_=g@mail.gmail.com>
References: <CAOgNHrPiP3bO5qu6rmotbKTKa3_-+VVre=+PmY7RiqV7OKK_=g@mail.gmail.com>
Message-ID: <4FF0011D.7060300@python.org>

On 27.06.2012 00:32, Matt Woelfel wrote:
> Hello,
>
> I was reading the documentation at:
> http://docs.python.org/library/multiprocessing.html#module-multiprocessing
>
> I came across a bug where the sample code doesn't run:
> Search for "getppid", which should be changed to "getpid".

Hi Matt,

Thanks for the report.  getppid() is certainly the correct function to call
here.  But it is not available on Windows, so I've now made the call
conditional in the example.

cheers,
Georg

From georg at python.org  Sun Jul  1 09:51:52 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:51:52 +0200
Subject: [docs] bug in tutorial 7.Input and Output
In-Reply-To: <CAHvn7K9VcjbTp9S_J28FZMC+1VSvpkOBLwMSVOdmNx9uiRCwoA@mail.gmail.com>
References: <CAHvn7K9VcjbTp9S_J28FZMC+1VSvpkOBLwMSVOdmNx9uiRCwoA@mail.gmail.com>
Message-ID: <4FF00198.8000704@python.org>

On 28.06.2012 15:40, ???(DongHeon Jang) wrote:
> page : http://docs.python.org/tutorial/inputoutput.html
> explanation :
>
>>>>table  =  {'Sjoerd':  4127,  'Jack':  4098,  'Dcab':  7678}
>>>>for  name,  phone  in  table.items():
> ...     print  '{0:10} ==> {1:10d}'.format(name,  phone)
> ...
> Jack       ==>       4098
> Dcab       ==>       7678
> Sjoerd     ==>       4127
>
>
> Above result should be the following. I believe 'table' is dictionary and it's
> sorting the items based on key values.
>
> Dcab       ->       7678
> Jack       ->       4098
> Sjoerd     ->       4127

Hi DongHeon,

a dictionary is not sorted, and when you retrieve the items using items()
or iteritems(), they can appear in any order, depending on your system.

cheers,
Georg


From georg at python.org  Sun Jul  1 09:54:11 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:54:11 +0200
Subject: [docs] Python v3.2.3 - Help me!
In-Reply-To: <20120629163115.Horde.lCUwD3CXF3VP7cpDxRTi1BA@mail.sapo.pt>
References: <20120629163115.Horde.lCUwD3CXF3VP7cpDxRTi1BA@mail.sapo.pt>
Message-ID: <4FF00223.50704@python.org>

On 29.06.2012 17:31, focajoca at sapo.pt wrote:
> Hello, to whom can help me!
>
> I'm a beginner in programming.
> I have a Toshiba Tecra A3 (1.60 GHz Intel Pentium M), and I use python v3.2.3.
> I'm testing the map function,
> /map(function, iterable...)/
> but I do not get the expected result, as you see below:
>
> Test1:
>  >>> m=[10,20,30,40]
>  >>> map(str,m)
> <map object at 0x01007AD0>
> The expected result would be: ['10','20','30','40']
>
> Test2:
>  >>> def double(x):
> return 2*x
>
>  >>> map (double,m)
> <map object at 0x01007A70>
> The expected result would be: [20,40,60,80]
>
> Where am I going wrong? Can you help?

Hi Carlos,

in Python 3 a few functions such as map() and zip() have been changed to
return not whole lists, but iterators.  You can make a list out of them
by wrapping the result in list(), e.g.

 >>> list(map(double, m))
[20, 40, 60, 80]

But in many cases this is not necessary, for example when iterating over
the result, e.g.

 >>> for dbl in map(double, m):
...     print(dbl)
20
40
60
80

and it is usually more efficient without the list().  (That's the reason
the functions were changed in the first place.)

cheers,
Georg

From report at bugs.python.org  Sun Jul  1 09:58:42 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 07:58:42 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
Message-ID: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Currently, the atexit docs state

"The order in which the functions are called is not defined" in the introduction and

"all functions registered are called in last in, first out order" in the docs of the atexit() function.

While the latter is correct, I don't think we should guarantee that behaviour by documenting it.  Suggestions?

----------
assignee: docs at python
components: Documentation
messages: 164454
nosy: docs at python, georg.brandl, loewis, pitrou
priority: normal
severity: normal
status: open
title: atexit: guarantee order of execution of registered functions?
versions: Python 2.7, Python 3.2, Python 3.3

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

From georg at python.org  Sun Jul  1 09:59:43 2012
From: georg at python.org (Georg Brandl)
Date: Sun, 01 Jul 2012 09:59:43 +0200
Subject: [docs] Documentation bug on
	http://docs.python.org/library/atexit.html
In-Reply-To: <CALuYSZUyJJYtO9+pptqDXvikcR3PQJbsVu+nL1hgtjP0HXFHPg@mail.gmail.com>
References: <CALuYSZUyJJYtO9+pptqDXvikcR3PQJbsVu+nL1hgtjP0HXFHPg@mail.gmail.com>
Message-ID: <4FF0036F.8030802@python.org>

On 18.06.2012 20:28, Daniel Moisset wrote:
> Hi. I'm looking at the documentation for the "atexit" module and it
> has an inconsistency
>
> The first paragraph says "The order in which the functions are called
> is not defined". However, the second pargaraph at
> http://docs.python.org/library/atexit.html#atexit.register says "At
> normal program termination (for instance, if sys.exit() is called or
> the main module?s execution completes), all functions registered are
> called in last in, first out order." which contradicts the first
> paragraph stating that order is not defined.
>
> I'd suggest a fix if I knew which one was right :)

Hi Daniel,

that's a good point; I've raised bugs.python.org/15233 to track it.

cheers,
Georg

From report at bugs.python.org  Sun Jul  1 10:01:35 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 01 Jul 2012 08:01:35 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341129695.38.0.75694506158.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There are more checks applied in PyPI than just the refusal to incorporate raw html. I doubt it is possible to perform the exact same check with the rst2html command line.

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Jul  1 10:20:49 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 01 Jul 2012 08:20:49 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341130849.14.0.299738096552.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I believe it should be guaranteed behavior and that code may reasonably want to have a predictable sequence of unwinding behaviors.

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

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

From report at bugs.python.org  Sun Jul  1 11:35:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 01 Jul 2012 09:35:26 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341135326.65.0.842491310611.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks.  Then perhaps the documentation can be updated to make that clear.

Currently, the documentation implies that running the given command is sufficient to catch all errors, which can lead to confusion when warning-free content is not rendered as HTML.

----------

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

From report at bugs.python.org  Sun Jul  1 12:17:29 2012
From: report at bugs.python.org (=?utf-8?q?Charles-Fran=C3=A7ois_Natali?=)
Date: Sun, 01 Jul 2012 10:17:29 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341137849.84.0.0751676027195.issue15233@psf.upfronthosting.co.za>


Charles-Fran?ois Natali <neologix at free.fr> added the comment:

It is guaranteed by libc's atexit(3), and should also be guaranteed here.

----------
nosy: +neologix

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

From report at bugs.python.org  Sun Jul  1 12:20:25 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 01 Jul 2012 10:20:25 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341138025.45.0.43246570336.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

+1 to guaranteeing the order.

----------
nosy: +larry

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

From report at bugs.python.org  Sun Jul  1 13:27:15 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 01 Jul 2012 11:27:15 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341130849.14.0.299738096552.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341141975.3363.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I believe it should be guaranteed behavior and that code may
> reasonably want to have a predictable sequence of unwinding behaviors.

Agreed.

----------

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

From sandro.tosi at gmail.com  Sun Jul  1 18:24:57 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 1 Jul 2012 18:24:57 +0200
Subject: [docs] do you have the Python 2.7.3 Documentation in .EPUB?
 thanks! #EOM
In-Reply-To: <CAA3d0CAQxi8_4iaCA+=kVwAfVjqZgmx21BAbw+ak3yuG=MkERQ@mail.gmail.com>
References: <CAA3d0CAQxi8_4iaCA+=kVwAfVjqZgmx21BAbw+ak3yuG=MkERQ@mail.gmail.com>
Message-ID: <CAB4XWXzXfNqN9FvVvhVRGORoGE-xCcnwVjnkiv_KV8_=a3AEBw@mail.gmail.com>

Hello Ian,
we decided to provide the EPUB files only for Python 3 releases:
http://docs.python.org/py3k/download.html .

You may want to give Python 3 a try - it's the future of Python (and
yes, we're aware that there are places where 2.7 will be used for a
long time).

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From sandro.tosi at gmail.com  Sun Jul  1 19:35:36 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sun, 1 Jul 2012 19:35:36 +0200
Subject: [docs] Sloppy example at sect 8.3 of Python 2.7.3 tutorial
In-Reply-To: <CAPptrgQ3GGs5wXjcz=jetrn19nJ93KwdQfBGpKv3wZwo+=YFmA@mail.gmail.com>
References: <CAPptrgQ3GGs5wXjcz=jetrn19nJ93KwdQfBGpKv3wZwo+=YFmA@mail.gmail.com>
Message-ID: <CAB4XWXwZmt-rvT4-Nx9RprQP7cAeMedi-ML--+WJVJfaWWQSgg@mail.gmail.com>

Hello Greg,
thanks for your email.

On Sat, Jun 23, 2012 at 11:51 PM, Greg Edwards <gedwards2 at gmail.com> wrote:
> Hi,
>
> At   http://docs.python.org/release/2.7.3/tutorial/errors.html    sect 8.3,
> the first example block should ask the user for an "integer", not just a
> "number". I happily entered 1.23 without thikning too much and it failed.

If you enter 1.23 you've just tested the except branch:

>>> while True:
...     try:
...         x = int(raw_input("Please enter a number: "))
...         break
...     except ValueError:
...         print "Oops!  That was no valid number.  Try again..."
...
Please enter a number: 1.23
Oops!  That was no valid number.  Try again...
Please enter a number:


As far as I can see, the example works as expected, and there's
nothing wrong with it (not even the imprecise indication of what
number to enter).

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Mon Jul  2 16:24:42 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 Jul 2012 14:24:42 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341239082.17.0.116906098643.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Here's a patch.  I read the implementation to find out what it does, then documented it.  Happily it does the sane thing.

----------
keywords: +patch
Added file: http://bugs.python.org/file26230/larry.atexit.1.diff

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

From report at bugs.python.org  Mon Jul  2 16:30:22 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 Jul 2012 14:30:22 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341239082.17.0.116906098643.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341239354.3368.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Here's a patch.  I read the implementation to find out what it does,
> then documented it.  Happily it does the sane thing.

Is it tested for?

----------

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

From report at bugs.python.org  Mon Jul  2 21:10:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 02 Jul 2012 19:10:52 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341256252.69.0.270896506924.issue15233@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #9788 for previous discussion.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Jul  2 23:34:36 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 Jul 2012 21:34:36 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341264876.63.0.138527351034.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The patch wording is fine.  However, I would avoid the "note" markup.  It is visually distracting and there isn't a reason to pull this out of the main text.

----------

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

From report at bugs.python.org  Tue Jul  3 02:13:00 2012
From: report at bugs.python.org (Axel Wegen)
Date: Tue, 03 Jul 2012 00:13:00 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1341274380.33.0.898773864462.issue13498@psf.upfronthosting.co.za>


Changes by Axel Wegen <axel.wegen at googlemail.com>:


----------
nosy: +Axel.Wegen

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

From report at bugs.python.org  Tue Jul  3 02:33:56 2012
From: report at bugs.python.org (Axel Wegen)
Date: Tue, 03 Jul 2012 00:33:56 +0000
Subject: [docs] [issue12716] Reorganize os docs for files/dirs/fds
In-Reply-To: <1312900904.97.0.581848486096.issue12716@psf.upfronthosting.co.za>
Message-ID: <1341275636.39.0.0400746246198.issue12716@psf.upfronthosting.co.za>


Changes by Axel Wegen <axel.wegen at googlemail.com>:


----------
nosy: +Axel.Wegen

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

From report at bugs.python.org  Tue Jul  3 06:22:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 03 Jul 2012 04:22:54 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
Message-ID: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I did not find any doc or test for the behavior of the interpreter in virtual mode, only for venv and pyvenv.

A new paragraph in site.py exists, but it?s missing from site.rst, contains what I think is an error (saying that sys.prefix is always the real prefix), and should be somewhere more obvious than the site docs or linked from somewhere more obvious, like the Usage and Setup docs or maybe the tutorial.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164563
nosy: docs at python, eric.araujo, vinay.sajip
priority: normal
severity: normal
status: open
title: venv module and pyvenv script documented, but not python behavior itself
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 06:31:16 2012
From: report at bugs.python.org (moijes12)
Date: Tue, 03 Jul 2012 04:31:16 +0000
Subject: [docs] [issue1660009] continuing problem with httplib multiple
	set-cookie	headers
Message-ID: <1341289876.25.0.664578495205.issue1660009@psf.upfronthosting.co.za>


Changes by moijes12 <moijes12 at gmail.com>:


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

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

From report at bugs.python.org  Tue Jul  3 08:26:20 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 06:26:20 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341296780.03.0.994278148727.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> Is it tested for?

Amusingly enough, yes.  test_order() in Lib/test/test_atexit.py already ensures reverse order.

----------

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

From report at bugs.python.org  Tue Jul  3 08:51:05 2012
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 03 Jul 2012 06:51:05 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341298265.89.0.804062264834.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

> I would avoid the "note" markup.  It is visually distracting
> and there isn't a reason to pull this out of the main text.

I think it's an improvement; it helps draw the eye to an important warning.

Does anyone else have an opinion one way or another?

----------

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

From report at bugs.python.org  Tue Jul  3 11:23:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 Jul 2012 09:23:25 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341307405.39.0.431632679215.issue15233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Does anyone else have an opinion one way or another?

I'm neutral.

----------

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

From report at bugs.python.org  Tue Jul  3 17:08:38 2012
From: report at bugs.python.org (William Schwartz)
Date: Tue, 03 Jul 2012 15:08:38 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
Message-ID: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>


New submission from William Schwartz <wkschwartz at gmail.com>:

Section 3.3.3.2. "Preparing the class namespace" of the documentation (http://docs.python.org/dev/reference/datamodel.html#preparing-the-class-namespace) states that "If the metaclass has a __prepare__ attribute, it is called as ``namespace = metaclass.__prepare__(name, bases, **kwds)``...." This isn't quite true. By just defining a ``__prepare__`` method in a metaclass, the interpreter calls it as it would a static method -- there is no implicit first argument referring to ``metaclass`` as the documentation implies. The documentation should be amended to say that users can decorate ``__prepare__`` as a class method to get ``metaclass`` passed in as the implicit first argument.

----------
assignee: docs at python
components: Documentation, Tests
messages: 164606
nosy: William.Schwartz, docs at python
priority: normal
severity: normal
status: open
title: Misleading documentation for __prepare__
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Tue Jul  3 17:30:13 2012
From: report at bugs.python.org (William Schwartz)
Date: Tue, 03 Jul 2012 15:30:13 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341329413.25.0.815543157319.issue15243@psf.upfronthosting.co.za>


William Schwartz <wkschwartz at gmail.com> added the comment:

Attached a unittest script to demonstrate that __prepare__ is implicitly a staticmethod.

----------
Added file: http://bugs.python.org/file26245/test_metaclass.py

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

From report at bugs.python.org  Tue Jul  3 17:34:25 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 15:34:25 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRTs95ntbzN2J@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 4a39ea2c1b11 by Vinay Sajip in branch 'default':
Issue 15241: Improved site.py documentation relating to venvs.
http://hg.python.org/cpython/rev/4a39ea2c1b11

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

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

From report at bugs.python.org  Tue Jul  3 17:56:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 15:56:58 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRVMF3hG5zNZb@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 18c2519b9114 by Vinay Sajip in branch 'default':
Issue #15241: Added test for venv prefixes.
http://hg.python.org/cpython/rev/18c2519b9114

----------

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

From report at bugs.python.org  Tue Jul  3 17:59:41 2012
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 03 Jul 2012 15:59:41 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <1341331181.56.0.763786441143.issue15241@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Note that the prefix values (and their meanings in venv/non-venv environments) are documented in the sys module.

----------

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

From report at bugs.python.org  Tue Jul  3 18:27:08 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 Jul 2012 16:27:08 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WRW22597NzN1h@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 74fea1763d02 by Vinay Sajip in branch 'default':
Closes #15241: Added information on venv prefixes to pyvenv section.
http://hg.python.org/cpython/rev/74fea1763d02

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jul  3 19:25:37 2012
From: report at bugs.python.org (Daniel Urban)
Date: Tue, 03 Jul 2012 17:25:37 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341336337.92.0.264644772438.issue15243@psf.upfronthosting.co.za>


Changes by Daniel Urban <urban.dani+py at gmail.com>:


----------
nosy: +daniel.urban

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

From report at bugs.python.org  Wed Jul  4 08:10:46 2012
From: report at bugs.python.org (Ramchandra Apte)
Date: Wed, 04 Jul 2012 06:10:46 +0000
Subject: [docs] [issue13801] The Python 3 Docs don't highlight nonlocal
In-Reply-To: <1326720484.97.0.730349515473.issue13801@psf.upfronthosting.co.za>
Message-ID: <1341382246.07.0.612079861503.issue13801@psf.upfronthosting.co.za>


Ramchandra Apte <maniandram01 at gmail.com> added the comment:

What is the status of this bug?

----------

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

From report at bugs.python.org  Wed Jul  4 16:36:07 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 04 Jul 2012 14:36:07 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
Message-ID: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the dircmp class doesn't say that the same_files and diff_files attributes are determined using the "shallow=True" rules described in the filecmp.cmp() and filecmp.cmpfiles().  It should say this.

For example, the documentation describes diff_files as, "Files which are in both a and b, whose contents differ."  But this isn't true since files whose contents differ aren't included if their os.stat() signatures are equal.

See also issue 12932 to allow dircmp to perform non-shallow comparisons.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164646
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document that filecmp.dircmp comparisons are "shallow"
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul  5 00:20:44 2012
From: report at bugs.python.org (Jeffrey Harper)
Date: Wed, 04 Jul 2012 22:20:44 +0000
Subject: [docs] [issue15251] new.code and new.function crashes Python
	iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341440444.33.0.266413351467.issue15251@psf.upfronthosting.co.za>


Jeffrey Harper <jeff1.61803 at gmail.com> added the comment:

Martin,

Thanks for your response.  I didn't know it was possible to pass freevars and cellvars to new.code.  I think the documentation needs to be updated.  The documentation for 2.7.3 located at http://docs.python.org/library/new.html?highlight=new#new.code is as follows:

new.code(argcount, nlocals, stacksize, flags, codestring, constants, names, varnames, filename, name, firstlineno, lnotab)

After I got your reply to this bug report I did help(new.code) and I see that it includes freevars and cellvars as optional arguments.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python

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

From report at bugs.python.org  Thu Jul  5 05:23:59 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 03:23:59 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1341458639.15.0.501936615797.issue15250@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


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

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

From report at bugs.python.org  Thu Jul  5 18:35:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 16:35:52 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341506152.53.0.933582085623.issue15243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ncoghlan
stage:  -> needs patch
versions: +Python 3.2

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

From report at bugs.python.org  Thu Jul  5 18:47:07 2012
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 05 Jul 2012 16:47:07 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341506827.6.0.513952941101.issue15243@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

__prepare__ is not implicitly a staticmethod, and it is called exactly as documented (also in types.prepare_class). There is no implicit first argument because the method is called on the (meta)class object.

----------

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

From report at bugs.python.org  Thu Jul  5 20:49:21 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 05 Jul 2012 18:49:21 +0000
Subject: [docs] [issue8996] Add a default role to allow writing bare `len`
	instead of	:func:`len`
In-Reply-To: <1276528152.92.0.60611534239.issue8996@psf.upfronthosting.co.za>
Message-ID: <1341514161.22.0.412135538752.issue8996@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> for example, as a result of documentation merge it both
> :func:`someref` and :class:`someref` can appear
I think this would cause a warning from Sphinx, as all class/meth/func/mod/etc roles look up in the same namespace (what Georg said).

Benjamin is -1 for explicitness
I am -0 because of the ` vs. `` possible ambiguity?I prefer disabling the default role altogether
Georg, are you still +1 or should we reject this?

----------

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

From report at bugs.python.org  Thu Jul  5 21:59:06 2012
From: report at bugs.python.org (William Schwartz)
Date: Thu, 05 Jul 2012 19:59:06 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341518346.88.0.75057421281.issue15243@psf.upfronthosting.co.za>


William Schwartz <wkschwartz at gmail.com> added the comment:

Daniel, Good point. However it would still be useful for documentation to point out that __prepare__ can be passed the metaclass as the implicit first argument by being decorated by classmethod.

I'll post a small patch when I get a chance to add a sentence saying as much in the documentation and reorganize the test cases in Lib/test/test_metaclass.py to make it part of the narrative of the doctests.

----------

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

From report at bugs.python.org  Thu Jul  5 22:52:19 2012
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 05 Jul 2012 20:52:19 +0000
Subject: [docs] [issue15243] Misleading documentation for __prepare__
In-Reply-To: <1341328118.33.0.670602196671.issue15243@psf.upfronthosting.co.za>
Message-ID: <1341521539.64.0.620484242881.issue15243@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Actually the docs contained a similar sentence ("If the metaclass has a :meth:`__prepare__` attribute (usually implemented as a class or static method), ..."), but it was removed in befd56673c80 when Nick rewrote this section.

----------

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

From report at bugs.python.org  Fri Jul  6 00:41:13 2012
From: report at bugs.python.org (Nefarious CodeMonkey, Jr.)
Date: Thu, 05 Jul 2012 22:41:13 +0000
Subject: [docs] [issue15258] argparse documentation: Improve optparse
	section	regarding allow_interspersed_args
Message-ID: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>


New submission from Nefarious CodeMonkey, Jr. <nejucomo at users.sourceforge.net>:

It was not obvious from the documentation on argparse how to emulate the optparse.OptionParser.allow_interspersed_args feature.

Please add something like the following to the section titled "Upgrading optparse code" (see: http://docs.python.org/library/argparse.html#upgrading-optparse-code )

"""
* If the optparse code sets allow_interspersed_args to False, then add an argparse positional argument with nargs=argparse.REMAINDER
"""

----------
assignee: docs at python
components: Documentation
messages: 164702
nosy: docs at python, nejucomo
priority: normal
severity: normal
status: open
title: argparse documentation: Improve optparse section regarding allow_interspersed_args
type: enhancement
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/issue15258>
_______________________________________

From report at bugs.python.org  Fri Jul  6 02:10:59 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 00:10:59 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1341533459.3.0.325542392169.issue15250@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file26265/issue15250-1.patch

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

From report at bugs.python.org  Fri Jul  6 04:14:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 02:14:26 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341540866.32.0.582500998894.issue15231@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file26268/issue-15231-1.patch

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

From report at bugs.python.org  Fri Jul  6 05:02:26 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 06 Jul 2012 03:02:26 +0000
Subject: [docs] [issue14202] The docs of xml.dom.pulldom are almost
	nonexistent
In-Reply-To: <1330964719.2.0.249901769319.issue14202@psf.upfronthosting.co.za>
Message-ID: <1341543746.62.0.956519374853.issue14202@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


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

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

From report at bugs.python.org  Fri Jul  6 18:27:03 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 06 Jul 2012 16:27:03 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341592023.02.0.905104525167.issue15231@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In 2.7 and newer ?setup.py check? is a better interface than rst2html.  +1 to list all checks performed by PyPI on some wiki or PyPI doc page (and +1 to add the same checks in distutils2?s check command).

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Fri Jul  6 18:40:40 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 16:40:40 +0000
Subject: [docs] [issue15264] PyErr_SetFromErrnoWithFilenameObject()
	undocumented
Message-ID: <1341592840.74.0.991788798601.issue15264@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Title says it all.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 164736
nosy: docs at python, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromErrnoWithFilenameObject() undocumented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul  6 19:28:16 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 17:28:16 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341595696.36.0.530590872412.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

?ric: your request is in passive voice. I'm not aware that anybody volunteered document the tests, but I doubt that this wiki page can reasonably be kept up-to-date. So the wiki page will outdate just as the current documentation got outdated.

Incorporating the check into distutils 2 is more feasible, but would still require someone to incorporate updates when we make them. The code is (currently) at

https://bitbucket.org/loewis/pypi/raw/default/description_utils.py

----------

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

From report at bugs.python.org  Fri Jul  6 19:50:45 2012
From: report at bugs.python.org (Roy Smith)
Date: Fri, 06 Jul 2012 17:50:45 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
Message-ID: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The docs don't say what happens if you call random.sample() with a population smaller than k.  Experimentally, it raises ValueError, but this should be documented.

I would have guessed it would return IndexError, by analogy to random.choice().

----------
assignee: docs at python
components: Documentation
messages: 164742
nosy: docs at python, roysmith
priority: normal
severity: normal
status: open
title: random.sample() docs unclear on k < len(population)
type: enhancement

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

From report at bugs.python.org  Fri Jul  6 19:52:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 17:52:36 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341597156.77.0.836767131563.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Another way to make it easier for users to run the same command as PyPI locally -- also phrased in the passive voice :) -- would be if PyPI packaged its conversion code as a separate module that could also be run as a stand-alone script, and then relied on that.  That would eliminate the need to keep different code bases in synch.

----------

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

From matthew.woelfel at gmail.com  Sun Jul  1 16:00:31 2012
From: matthew.woelfel at gmail.com (Matt Woelfel)
Date: Sun, 1 Jul 2012 09:00:31 -0500
Subject: [docs] small documentation bug in multiprocessing
In-Reply-To: <4FF0011D.7060300@python.org>
References: <CAOgNHrPiP3bO5qu6rmotbKTKa3_-+VVre=+PmY7RiqV7OKK_=g@mail.gmail.com>
	<4FF0011D.7060300@python.org>
Message-ID: <CAOgNHrMrEgSqsk5kxQbGn=fVdrsZ4LDJQ7WXthaRj+++qYH4zg@mail.gmail.com>

Hi Georg,

I see I should have read the example more closely on what it was trying to
show.  Thank you for the clarification.

Kind regards,

Matt
On Jul 1, 2012 2:49 AM, "Georg Brandl" <georg at python.org> wrote:

> On 27.06.2012 00:32, Matt Woelfel wrote:
>
>> Hello,
>>
>> I was reading the documentation at:
>> http://docs.python.org/**library/multiprocessing.html#**
>> module-multiprocessing<http://docs.python.org/library/multiprocessing.html#module-multiprocessing>
>>
>> I came across a bug where the sample code doesn't run:
>> Search for "getppid", which should be changed to "getpid".
>>
>
> Hi Matt,
>
> Thanks for the report.  getppid() is certainly the correct function to call
> here.  But it is not available on Windows, so I've now made the call
> conditional in the example.
>
> cheers,
> Georg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120701/c4445219/attachment-0001.html>

From genij.math at gmail.com  Mon Jul  2 12:55:41 2012
From: genij.math at gmail.com (Yevgen Yampolskiy)
Date: Mon, 2 Jul 2012 06:55:41 -0400
Subject: [docs] missing quotation mark
Message-ID: <CAJR2qAkCx481CspU39Zm2EbNCmxV3_7BsV1LHqwsyJ3LB51zsA@mail.gmail.com>

http://docs.python.org/library/stdtypes.html

Written:
For example, 'ab c\n\nde fg\rkl\r\n'.splitlines() returns ['ab c', '', 'de
fg', 'kl'], while the same call with splitlines(True) returns ['ab c\n', '\n
, 'de fg\r', 'kl\r\n'].

Should be:

For example, 'ab c\n\nde fg\rkl\r\n'.splitlines() returns ['ab c', '', 'de
fg', 'kl'], while the same call with splitlines(True) returns ['ab c\n', '\n
', 'de fg\r', 'kl\r\n'].

Best,
Yevgen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120702/79e436a7/attachment-0001.html>

From KTarbet at usbr.gov  Mon Jul  2 20:43:24 2012
From: KTarbet at usbr.gov (Tarbet, Karl L)
Date: Mon, 2 Jul 2012 12:43:24 -0600
Subject: [docs] broken link to Geany IDE
Message-ID: <FD273C5D4E4AE34A899BC432006340C43EC6FE89D2@IBR5DENMXCMX01.bor.doi.net>

Hello,
The link http://geany.uvena.de/ on the page http://docs.python.org/using/unix.html#editors seems to be broken.
Google suggests to me that you could use  http://www.geany.org/ instead.

Thanks,
Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120702/83d9c57f/attachment-0001.html>

From joshualawless16 at yahoo.co.uk  Tue Jul  3 23:11:17 2012
From: joshualawless16 at yahoo.co.uk (Joshua Lawless)
Date: Tue, 3 Jul 2012 22:11:17 +0100 (BST)
Subject: [docs] What BUGS me
Message-ID: <1341349877.42836.YahooMailNeo@web29406.mail.ird.yahoo.com>

Hi im Josh, I really want to learn your programming language but the tutorial just confuses me the more I know the more I realise I dont know. I feel that it doesnt explain everything clearly as if the person who wrote it had so much on his mind to put on the paper he skipped crucial parts which would make the whole thing make sense. I dont like giving greif or bad comments? or even constructive critisism especially when someone has gone out of their way to make something for a bunch of peope free of charge but to learn your language this I feel this really needs to be addressed so that everybody can earn your programming language. Please read this and hopefully even do something about it, it will benefit a whole bunch of people other than me to try learning your programming language, I know it sounds selfish it kind of is but wouldn't it benefit you more aswell if more people could use your programming language?

thanks for reading this i hope it helps

kind regards Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120703/5560c973/attachment-0001.html>

From david.raimosson at gmail.com  Wed Jul  4 17:46:13 2012
From: david.raimosson at gmail.com (David Raimosson)
Date: Wed, 4 Jul 2012 17:46:13 +0200
Subject: [docs] Inconsistency about .pth files
Message-ID: <CAHfKwN2O5jEHLCxwtOwKngVSPY_4ZVXr72o+0X24BL7OY2h+UQ@mail.gmail.com>

Hi all!

I've found what I believe is an error in the documentation.

When reading about the great .pth files on this site:
http://docs.python.org/install/index.html#modifying-python-s-search-path,
it says that "The most convenient way is to add a path configuration file
to a directory that?s already on Python?s path". That's what reality shows
works as well.

When reading about the same .pth files here:
http://docs.python.org/library/site.html#module-site, it says "A path
configuration file is a file whose name has the form *name*.pth and exists
in one of the four directories mentioned above". It seems to me that the
text states that there are only four valid directories where a .pth file
can reside to be found, which is not true.

Kind regards

David Raimosson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120704/a0c90a7e/attachment-0001.html>

From chrisj at puffin.com  Thu Jul  5 20:10:34 2012
From: chrisj at puffin.com (Chris Jewell)
Date: 5 Jul 2012 18:10:34 -0000
Subject: [docs] an offer of proofreading
Message-ID: <20120705181034.22571.qmail@sjtufted.puffin.com>

Good day,

I propose to read through at least the Library Reference (and perhaps
more of the documentation) for 3.2.3, and send suggested corrections.

Will it be best to send diffs of the .html files (which I would
usually read anyway) or the plain text?  Or are there source files
from which you generate all of the distributed docs, and for which the
diffs would be more useful?

I started the process with the Lib Ref for an earlier version of
Python 3 (as a way of learning the differences between Python 2 and
3), but was interrupted before I got around to sending the
corrections, and never got back to it.  I expect that many of the
issues with the earlier version have been corrected by now, but I'll
see what I can find.

Thank you.

-- 
Chris Jewell      chrisj at puffin.com

From rbarrionuevog at gmail.com  Fri Jul  6 15:43:15 2012
From: rbarrionuevog at gmail.com (Rafael Barrionuevo)
Date: Fri, 6 Jul 2012 15:43:15 +0200
Subject: [docs] zlib error with Plone 4.1.5 and ubuntu 12.04 LTS
Message-ID: <CACg5sDJUEXV0hFxDfH6MJh4j_NV-QmhvU0Sz78JRfEdfKa6GOw@mail.gmail.com>

Root install method chosen. Will install for use by system user plone

Installing Plone 4.1.5 at /usr/local/Plone

User 'plone' already exists. No need to create it.
Compiling and installing jpeg local libraries ...
Skipping zlib build
Compiling and installing readline local libraries ...
Installing Python 2.6.8. This takes a while...
Patching for Debian/Ubuntu Multiarch
Patching for thread size
Patching for disabled ssl2
Traceback (most recent call last):
  File "<string>", line 1, in <module>
LookupError: unknown encoding: zip
Python zlib support is missing; something went wrong in the zlib or python
build.

Installation has failed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120706/9175ae7d/attachment-0001.html>

From report at bugs.python.org  Fri Jul  6 21:34:16 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 19:34:16 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341603256.45.0.908636328629.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Does the proposed patch to the documentation look okay given the way things are today?

I can open an issue on the PyPI tracker to discuss the broader issue or, if you prefer, on the main Python tracker.

----------

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

From report at bugs.python.org  Fri Jul  6 21:45:28 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 19:45:28 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341603928.11.0.76305141344.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Chris, can you please submit a contrib form? Thanks.

----------

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

From report at bugs.python.org  Fri Jul  6 21:56:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 19:56:14 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341604574.89.0.237183722194.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I did yesterday.  I will post here when I receive a response.

----------

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

From report at bugs.python.org  Fri Jul  6 22:02:32 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 06 Jul 2012 20:02:32 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341604951.96.0.24922994622.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah, ok. Processing may take some time.

----------

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

From report at bugs.python.org  Fri Jul  6 22:12:00 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 Jul 2012 20:12:00 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341605520.11.0.647343578426.issue15233@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Raymond. You might, however, emphasize 'normal' in 'normal
interpreter termination'. That is the key point. The 'note' merely explains 'abnormal'.

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

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

From report at bugs.python.org  Fri Jul  6 22:14:23 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 Jul 2012 20:14:23 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341605663.71.0.649796869741.issue15265@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul  6 22:43:02 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 06 Jul 2012 20:43:02 +0000
Subject: [docs] [issue15258] argparse documentation: Improve optparse
	section	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1341607382.66.0.745258358291.issue15258@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

See also issue 14191, which describes the problems of trying to make argparse achieve the goal of the default optparse handling of allow_interspersed_args !

The documentation for that branch of the feature is also seriously incomplete, and the workaround is more than a single line.

----------
nosy: +v+python

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

From report at bugs.python.org  Fri Jul  6 23:00:48 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Fri, 06 Jul 2012 21:00:48 +0000
Subject: [docs] [issue14191] argparse: nargs='*' doesn't get out-of-order
	positional	parameters
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1341608448.8.0.222113785274.issue14191@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

See also issue 15258 which points out issues with the converse case.

Further testing and development also discovered that in certain error cases, the help message produced by t18-equivalent code was incorrect.

t18a.py is an update/rewrite (same concepts, though) that produces a correct help message when errors occur.

----------
Added file: http://bugs.python.org/file26273/t18a.py

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

From report at bugs.python.org  Sat Jul  7 00:46:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 06 Jul 2012 22:46:04 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341614764.85.0.67774431578.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15266 for the broader issue.  The corresponding issue I made earlier on the PyPI tracker is also referenced there.

----------

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

From report at bugs.python.org  Sat Jul  7 04:29:13 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 02:29:13 +0000
Subject: [docs] [issue15251] new.code and new.function crashes Python
	iterpretter
In-Reply-To: <1341422953.77.0.576650378209.issue15251@psf.upfronthosting.co.za>
Message-ID: <1341628153.25.0.56751553888.issue15251@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In Py3, new.code and new.function become types.CodeType and types.FunctionType. The 'documentation' of their signatures is only available with help(types.xxx). So the library doc issue is 2.7 only.

Running with IDLE, 3.3b0, Win7, the converted example does crash after 5 seconds or so even with the missing arg and the pprint gone. The crash is in the new_fun(5) call. I might have gotten something wrong. Or maybe the the help is wrong.

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file26279/tem.py

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

From report at bugs.python.org  Sat Jul  7 04:32:51 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 Jul 2012 02:32:51 +0000
Subject: [docs] [issue15258] argparse documentation: Improve optparse
	section	regarding allow_interspersed_args
In-Reply-To: <1341528073.03.0.435446433545.issue15258@psf.upfronthosting.co.za>
Message-ID: <1341628371.28.0.524200811144.issue15258@psf.upfronthosting.co.za>


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


----------
versions:  -Python 3.1

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

From report at bugs.python.org  Sat Jul  7 06:28:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 04:28:00 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
Message-ID: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation for the filecmp.dircmp class doesn't mention dircmp.left and dircmp.right.

Being aware of this up front would make certain simplifications easier to think of.  For example, knowing about these attributes opens up the possibility of passing dircmp instances around without having to pass the two paths separately (e.g. in certain recursive algorithms involving dircmp).  Knowing this also means you can recover the two paths if using the subdirs attribute (whose values are dircmp instances).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164781
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Document dircmp.left and dircmp.right
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 07:44:50 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 05:44:50 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1341639890.62.0.0513596987572.issue15269@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file26282/issue-15269-1.patch

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

From report at bugs.python.org  Sat Jul  7 08:13:06 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 Jul 2012 06:13:06 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341641586.98.0.452982567612.issue15265@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/issue15265>
_______________________________________

From sandro.tosi at gmail.com  Sat Jul  7 11:06:35 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 7 Jul 2012 11:06:35 +0200
Subject: [docs] zlib error with Plone 4.1.5 and ubuntu 12.04 LTS
In-Reply-To: <CACg5sDJUEXV0hFxDfH6MJh4j_NV-QmhvU0Sz78JRfEdfKa6GOw@mail.gmail.com>
References: <CACg5sDJUEXV0hFxDfH6MJh4j_NV-QmhvU0Sz78JRfEdfKa6GOw@mail.gmail.com>
Message-ID: <CAB4XWXyiWMJY=ew3d6NTiKn84ZnJnkMOxgACuAKFPKMQj1DHvA@mail.gmail.com>

Hello Rafael,
this mailing list is about bugs/enhancements to CPython documentation,
and your email doesn't fit this description. It seems like a Ubuntu
bug, so either ask in their support forum on a generic python user
support forum, such as
http://mail.python.org/mailman/listinfo/python-list

Regards,
Sandro

On Fri, Jul 6, 2012 at 3:43 PM, Rafael Barrionuevo
<rbarrionuevog at gmail.com> wrote:
> Root install method chosen. Will install for use by system user plone
>
> Installing Plone 4.1.5 at /usr/local/Plone
>
> User 'plone' already exists. No need to create it.
> Compiling and installing jpeg local libraries ...
> Skipping zlib build
> Compiling and installing readline local libraries ...
> Installing Python 2.6.8. This takes a while...
> Patching for Debian/Ubuntu Multiarch
> Patching for thread size
> Patching for disabled ssl2
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> LookupError: unknown encoding: zip
> Python zlib support is missing; something went wrong in the zlib or python
> build.
>
> Installation has failed.
>
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Jul  7 11:46:56 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 09:46:56 +0000
Subject: [docs] [issue11908] Weird `slice.stop or sys.maxint`
In-Reply-To: <1303493846.17.0.214651551769.issue11908@psf.upfronthosting.co.za>
Message-ID: <1341654416.09.0.0438552948578.issue11908@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The attached patch fixes this

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file26283/issue11908-islice-docs.patch

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

From report at bugs.python.org  Sat Jul  7 11:57:06 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 Jul 2012 09:57:06 +0000
Subject: [docs] [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341655025.94.0.6648508333.issue15270@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The super() doc is also a good example of unreadable jargon ("dynamic execution environment" ??). Nowhere is it obvious to a beginner what super() is *practically* used for.

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

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

From report at bugs.python.org  Sat Jul  7 12:13:35 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 10:13:35 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341656015.51.0.0157141294979.issue11176@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Is this still an issue? If so, I've created a simpler first example as suggested below. 

If we decide these docs still need a bit more work, I can also continue to provide better examples than the "foo bar" ones.

----------
keywords: +patch
nosy: +groodt
Added file: http://bugs.python.org/file26284/argparse_simple_example.diff

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

From report at bugs.python.org  Sat Jul  7 12:13:58 2012
From: report at bugs.python.org (Dougal Matthews)
Date: Sat, 07 Jul 2012 10:13:58 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1341656038.81.0.0786516459417.issue13498@psf.upfronthosting.co.za>


Changes by Dougal Matthews <dougal85 at gmail.com>:


----------
nosy: +d0ugal

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

From report at bugs.python.org  Sat Jul  7 12:14:00 2012
From: report at bugs.python.org (Eugenio Minardi)
Date: Sat, 07 Jul 2012 10:14:00 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341656040.55.0.853324346314.issue15265@psf.upfronthosting.co.za>


Eugenio Minardi <eugenio.minardi at gmail.com> added the comment:

Added the related line to the documentation describing when the exception is raised.

----------
keywords: +patch
nosy: +kmox83
Added file: http://bugs.python.org/file26285/issue15265-fix-docs.patch

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

From sandro.tosi at gmail.com  Sat Jul  7 12:14:40 2012
From: sandro.tosi at gmail.com (Sandro Tosi)
Date: Sat, 7 Jul 2012 12:14:40 +0200
Subject: [docs] What BUGS me
In-Reply-To: <1341349877.42836.YahooMailNeo@web29406.mail.ird.yahoo.com>
References: <1341349877.42836.YahooMailNeo@web29406.mail.ird.yahoo.com>
Message-ID: <CAB4XWXz4L2EM=Ocp5Fosiv+TBV1U9HXTA4CLx2JUKnhhwy+XoQ@mail.gmail.com>

Hello Joshua,
we listen to and respect everyone's opinion, but your message is too
generic to "do something" to fix our documentation. We need more
detailed points to improve, even better it would be if you can provide
alternative wording for the part you don't like and so on.

I would like to point out that just saying "it's not clear" without
saying explicitly what's not clear won't help you (because we are not
able to help you) nor us (since we can't improve what we don't know).

Regards,
Sandro

On Tue, Jul 3, 2012 at 11:11 PM, Joshua Lawless
<joshualawless16 at yahoo.co.uk> wrote:
> Hi im Josh, I really want to learn your programming language but the
> tutorial just confuses me the more I know the more I realise I dont know. I
> feel that it doesnt explain everything clearly as if the person who wrote it
> had so much on his mind to put on the paper he skipped crucial parts which
> would make the whole thing make sense. I dont like giving greif or bad
> comments  or even constructive critisism especially when someone has gone
> out of their way to make something for a bunch of peope free of charge but
> to learn your language this I feel this really needs to be addressed so that
> everybody can earn your programming language. Please read this and hopefully
> even do something about it, it will benefit a whole bunch of people other
> than me to try learning your programming language, I know it sounds selfish
> it kind of is but wouldn't it benefit you more aswell if more people could
> use your programming language?
>
> thanks for reading this i hope it helps
>
> kind regards Josh
>
> _______________________________________________
> docs mailing list
> docs at python.org
> http://mail.python.org/mailman/listinfo/docs
>



-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

From report at bugs.python.org  Sat Jul  7 12:24:35 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 10:24:35 +0000
Subject: [docs] [issue15130] remove redundant paragraph in socket howto
In-Reply-To: <1340311752.3.0.940656841103.issue15130@psf.upfronthosting.co.za>
Message-ID: <1341656675.91.0.203067331445.issue15130@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Issue confirmed, patch looks good.

----------
nosy: +bbrazil

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

From report at bugs.python.org  Sat Jul  7 12:42:19 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 07 Jul 2012 10:42:19 +0000
Subject: [docs] [issue14879] invalid docs for subprocess exceptions with
	shell=True
In-Reply-To: <1337666994.08.0.287605633225.issue14879@psf.upfronthosting.co.za>
Message-ID: <1341657739.09.0.82313546603.issue14879@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I would add a simple note to the exceptions section:

"Note, when "shell=True", OSError will be raised by the child only if the selected shell itself cannot be found. To determine if the shell failed to find the requested application, it is necessary to check the return code or output from the subprcess."

----------

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

From report at bugs.python.org  Sat Jul  7 12:51:39 2012
From: report at bugs.python.org (Greg Roodt)
Date: Sat, 07 Jul 2012 10:51:39 +0000
Subject: [docs] [issue15183] it should be made clear that the statement in
	the	--setup option and the setup kw arg aren't included in the count
In-Reply-To: <1340647320.14.0.672684715585.issue15183@psf.upfronthosting.co.za>
Message-ID: <1341658299.06.0.0327666649332.issue15183@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

Confirmed that the setup statement is correctly excluded from the overall timed run.

I've updated the docstring and rst to make this clearer.

----------
keywords: +patch
nosy: +groodt
Added file: http://bugs.python.org/file26288/timeit_setup_clarification.diff

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

From report at bugs.python.org  Sat Jul  7 15:38:21 2012
From: report at bugs.python.org (Roy Smith)
Date: Sat, 07 Jul 2012 13:38:21 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341668301.45.0.373785328924.issue15265@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

The docs describe population as a "sequence".  Your patch describes it as a "list".  I would go with:

If *len(population)* is less than *k*, raises :exc:`ValueError`.

----------

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

From report at bugs.python.org  Sat Jul  7 15:45:14 2012
From: report at bugs.python.org (Eugenio Minardi)
Date: Sat, 07 Jul 2012 13:45:14 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341668713.99.0.502612572085.issue15265@psf.upfronthosting.co.za>


Eugenio Minardi <eugenio.minardi at gmail.com> added the comment:

Ok, I have updated the patch

----------
Added file: http://bugs.python.org/file26296/issue15265-fix-docs-update.patch

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

From report at bugs.python.org  Sat Jul  7 16:11:21 2012
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 07 Jul 2012 14:11:21 +0000
Subject: [docs] [issue11786] ConfigParser.[Raw]ConfigParser optionxform()
In-Reply-To: <1302110277.82.0.57770456199.issue11786@psf.upfronthosting.co.za>
Message-ID: <1341670281.18.0.352901374918.issue11786@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
status: pending -> closed

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

From report at bugs.python.org  Sat Jul  7 17:20:52 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:20:52 +0000
Subject: [docs] [issue11796] Comprehensions in a class definition mostly
	cannot	access class variable
In-Reply-To: <1302180921.17.0.22284518515.issue11796@psf.upfronthosting.co.za>
Message-ID: <1341674451.88.0.344757712611.issue11796@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It looks as a duplicate of issue 13557.
I close this one, because a doc patch is attached on the other.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> exec of list comprehension fails on NameError

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

From report at bugs.python.org  Sat Jul  7 17:21:17 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:21:17 +0000
Subject: [docs] [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1341674477.71.0.652501076276.issue13557@psf.upfronthosting.co.za>


Changes by Florent Xicluna <florent.xicluna at gmail.com>:


----------
nosy: +Trundle, anikom15, daniel.urban, flox, jonathan.hartley, josmiley, michael.foord, mjs0, rhettinger

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

From report at bugs.python.org  Sat Jul  7 17:25:43 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 07 Jul 2012 15:25:43 +0000
Subject: [docs] [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <1341674743.35.0.255662528306.issue13557@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Issue #11796 marked as duplicate of this one.

However the issue described in #11796 does not involve exec/execfile.
It is about scopes for list comprehension like this one.

Another doc patch should probably be written to cover the case described in #11796 too.

----------

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

From report at bugs.python.org  Sat Jul  7 18:17:38 2012
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 07 Jul 2012 16:17:38 +0000
Subject: [docs] [issue15228] os.utime() docs not clear on behavior on
	nonexistant	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1341677858.11.0.780541678947.issue15228@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Here's a patch that should clarify this.

----------
keywords: +patch
nosy: +bbrazil
Added file: http://bugs.python.org/file26306/issue15228-utime-touch-doc.patch

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

From report at bugs.python.org  Sat Jul  7 20:15:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 07 Jul 2012 18:15:57 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
Message-ID: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The note at the end of the pkgutil.walk_packages() (and iter_modules()) documentation can be improved somewhat:

http://docs.python.org/dev/library/pkgutil.html#pkgutil.walk_packages

For example, "importers" aren't referenced earlier in the documentation of the function, so it's not immediately clear what they are referring to.  I also think that enough information should be given so that one can run the examples given and have them work.  They currently don't.

I can put together proposed wording.  See the issue 14982 discussion for background.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 164916
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Clarify the pkgutil.walk_packages() note
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul  7 23:15:12 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 Jul 2012 21:15:12 +0000
Subject: [docs] [issue15228] os.utime() docs not clear on behavior on
	nonexistant	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1341695712.26.0.692272196636.issue15228@psf.upfronthosting.co.za>


Changes by Larry Hastings <larry at hastings.org>:


----------
nosy: +larry

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

From report at bugs.python.org  Sun Jul  8 03:44:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 01:44:19 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341711859.62.0.614879638362.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Probably linking the term "importers" into the glossary should be enough.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Sun Jul  8 06:05:23 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Jul 2012 04:05:23 +0000
Subject: [docs] [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341720323.06.0.0757723017784.issue15270@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The point was that the docs shouldn't "write a book" where briefer explanations suffice.  The mention of super() may not be the best example because many "experts" still don't get what it is all about regardless of how much or how little much is written.

FWIW, the original two short paragraphs led to a good deal of confusion resulting in people declaring super() to be either inscrutable, unusable, or both.

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

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

From report at bugs.python.org  Sun Jul  8 06:38:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 08 Jul 2012 04:38:23 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1341722303.66.0.989192099429.issue15233@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, giampaolo.rodola, meador.inge, python-dev

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

From report at bugs.python.org  Sun Jul  8 12:38:20 2012
From: report at bugs.python.org (Anders Hammarquist)
Date: Sun, 08 Jul 2012 10:38:20 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
Message-ID: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>


New submission from Anders Hammarquist <iko at iko.pp.se>:

When testing Eutaxia on PyPy (1.9) I discovered a discrepancy in the path_hooks import hook implementation. In CPython (2.7), if the find_module() method raises ImportError (as imp.find_module() does when it does not find a module in the given path), will cause the search to continue, whereas PyPy would propagate the ImportError.

PyPy has now been changed to behave like CPython.

The documentation is not entirely clear, but it does not explicitly document the import hook mechanism as eating an ImportError in find_module(). It should probably be made explicit, which ever way it should be. It is not obvious what is the correct behaviour, given the implicit relative imports, where the ImportError simply means that the import hook cannot find the module.

Quick testing on CPython 3.3 indicates that it behaves like PyPy did, but as it doesn't do implicit relative imports my test case didn't work as it was. For 3.3, without implicit relative imports, propagating the ImportError feels like the correct behaviour.

The attached demonstration needs a file /tmp/test/foo.py that does a top-level import, e.g. "import errno" to demonstrate the discrepancy.

----------
assignee: docs at python
components: Documentation
files: testimport.py
messages: 164998
nosy: docs at python, iko
priority: normal
severity: normal
status: open
title: import hook behavior documentation improvement
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26315/testimport.py

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

From report at bugs.python.org  Sun Jul  8 12:43:13 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 08 Jul 2012 10:43:13 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341744193.09.0.861269475553.issue15292@psf.upfronthosting.co.za>


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


----------
nosy: +brett.cannon, ncoghlan

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

From report at bugs.python.org  Sun Jul  8 13:33:22 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 11:33:22 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341747202.2.0.101298880199.issue15292@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The PyPy and 3.3 behaviour are actually correct according to the spec, but it's *really* unclear in PEP 302.

sys.meta_path accepts finder objects. These are explicitly documented as returning "None" from find_module() to indicate "try the next one" and raising exceptions solely to report problems.

However, for reasons that are unknown to me, sys.path_hooks entries (which occupy most of the section on registering hooks) use a different protocol to indicate "try the next one": raising ImportError.

Since meta_path and path_hooks are described in the same section, and the meta_path description just says "add finder objects", it's understandable that implementors take the path_hooks protocol description as applying to finders in general :(

I would chalk the 2.x (and likely 3.x for x < 3) behaviour up to the only partial implementation of PEP 302 in CPython (until Brett's success in bootstrapping importlib for 3.3).

----------

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

From report at bugs.python.org  Sun Jul  8 15:40:59 2012
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 Jul 2012 13:40:59 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1341754859.24.0.400322303359.issue15292@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Everything Nick said is right: PyPy did it properly according to the spec and CPython 2.7 got it wrong. Unfortunately fixing this now would break code and so it will simply have to stay a Python 2.7 quirk with Python 3.3 and later doing it correctly.

So documenting the screw-up would be good so that people know that the solution they use in Python 2.7 won't work in Python 3.3 and later.

----------

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

From report at bugs.python.org  Sun Jul  8 16:09:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 08 Jul 2012 14:09:00 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341754859.24.0.400322303359.issue15292@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fh1rfq8xSH4NsudwCvSc3aDea3G=uzPPr1EV-3K5_g6Q@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Perhaps the porting section in the 3.3 What's New?

----------

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

From report at bugs.python.org  Sun Jul  8 23:53:50 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 21:53:50 +0000
Subject: [docs] [issue13557] exec of list comprehension fails on NameError
In-Reply-To: <1323375954.63.0.637699438673.issue13557@psf.upfronthosting.co.za>
Message-ID: <3WVk2j0b81zNPF@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset ab22ffa6fb2e by Terry Jan Reedy in branch '2.7':
Issue #13557: Clarify effect of giving two different namespaces to exec or
http://hg.python.org/cpython/rev/ab22ffa6fb2e

New changeset ea670d71a36d by Terry Jan Reedy in branch '3.2':
Issue #13557: Clarify effect of giving two different namespaces to exec or
http://hg.python.org/cpython/rev/ea670d71a36d

New changeset b47ae7a9e685 by Terry Jan Reedy in branch 'default':
Merge 3.2 closes issue 13557
http://hg.python.org/cpython/rev/b47ae7a9e685

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

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

From report at bugs.python.org  Mon Jul  9 00:18:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 08 Jul 2012 22:18:39 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1341785919.05.0.264787274992.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Martin, FYI, Pat processed my contrib form.

----------

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

From report at bugs.python.org  Mon Jul  9 01:02:02 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 Jul 2012 23:02:02 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <3WVlYP0FwmzNLp@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 72174d8af3ba by Raymond Hettinger in branch 'default':
Issue 15265: document the exception raised for invalid sample sizes.
http://hg.python.org/cpython/rev/72174d8af3ba

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

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

From report at bugs.python.org  Mon Jul  9 01:02:27 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 08 Jul 2012 23:02:27 +0000
Subject: [docs] [issue15265] random.sample() docs unclear on k <
	len(population)
In-Reply-To: <1341597045.34.0.429934948335.issue15265@psf.upfronthosting.co.za>
Message-ID: <1341788547.73.0.276501237428.issue15265@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks, I've added a note.

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

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

From report at bugs.python.org  Mon Jul  9 06:56:52 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 04:56:52 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341809812.38.0.37035834031.issue11176@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yep, this is still open.  Thanks for the patch, I did a review (if you did not get a mail, follow the link in the list of files).

----------
assignee: eric.araujo -> 
nosy: +ezio.melotti, sandro.tosi

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

From report at bugs.python.org  Mon Jul  9 07:00:48 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 09 Jul 2012 05:00:48 +0000
Subject: [docs] [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1341810048.13.0.885651327684.issue15270@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Jul  9 08:11:35 2012
From: report at bugs.python.org (David Lam)
Date: Mon, 09 Jul 2012 06:11:35 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341814294.43.0.316991903348.issue11176@psf.upfronthosting.co.za>


David Lam <d at dlam.me> added the comment:

haha wow, I was working on this bug too!  maybe we can work on the final patch together

I got through about 2/3's of the docs, so I thought it might help to upload what I got so far.  I basically just made stuff up so I'm totally winning to change anything (or everything)

I made a little effort to make the examples mildly amusing, since novelty sorta helps in retention.  So one of the recurring examples I used involves that of a pizza-making-program... hopefully this helps in some way!

----------
nosy: +dlam
Added file: http://bugs.python.org/file26325/issue11165-doc-fix-up-to-section-15.4.4.diff

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

From report at bugs.python.org  Mon Jul  9 19:08:48 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Mon, 09 Jul 2012 17:08:48 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341853728.25.0.938105204849.issue15288@psf.upfronthosting.co.za>


Ronan Lamy <ronan.lamy at gmail.com> added the comment:

It seems that most, if not all, uses of "importer" in pkgutil refer to finders, e.g. ImpImporter is a actually only a finder, not an importer. So s/importer/finder/ is needed, and perhaps also a note explaining that ImpImporter isn't in fact an importer, in addition to glossary links.

----------
nosy: +Ronan.Lamy

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

From report at bugs.python.org  Mon Jul  9 19:44:02 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 09 Jul 2012 17:44:02 +0000
Subject: [docs] [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1341855842.22.0.812428773462.issue15297@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Marking this a documentation issue because the same behavior is also present in 2.7:

Python 2.7.3 (default, Apr 19 2012, 00:55:09) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
>>> from pkgutil import iter_importers
>>> list(iter_importers())[-1]
<pkgutil.ImpImporter instance at 0x10517b710>

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +easy
nosy: +docs at python
versions: +Python 2.7

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

From report at bugs.python.org  Mon Jul  9 20:10:31 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 Jul 2012 18:10:31 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <3WWF2Y6yKMzNxY@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 96f7926ea444 by Brett Cannon in branch 'default':
Issue #15288: Clarify that pkgutil.walk_packages() and friends will no
http://hg.python.org/cpython/rev/96f7926ea444

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

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

From report at bugs.python.org  Mon Jul  9 20:11:21 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 18:11:21 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341857481.12.0.794147585021.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I changed to term to "loader" and linked to the glossary. I also added a versionchanged note for Python 3.3 so people are not too surprised that pkgutil no longer does what it did in Python 3.2.

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

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

From report at bugs.python.org  Mon Jul  9 20:48:42 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 09 Jul 2012 18:48:42 +0000
Subject: [docs] [issue15288] Clarify the pkgutil.walk_packages() note
In-Reply-To: <1341684957.85.0.27089826728.issue15288@psf.upfronthosting.co.za>
Message-ID: <1341859722.71.0.947464308372.issue15288@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Ronan is right that it is all about finders, not importers per-se. I fixed the docs to not say "loader".

----------

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

From report at bugs.python.org  Mon Jul  9 21:02:47 2012
From: report at bugs.python.org (Greg Roodt)
Date: Mon, 09 Jul 2012 19:02:47 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1341814294.43.0.316991903348.issue11176@psf.upfronthosting.co.za>
Message-ID: <CAAD3oiKgbNB-Ne9i0_OCZST6GW=iu-DcoPqh3Lmwf62dBgndQw@mail.gmail.com>


Greg Roodt <groodt at gmail.com> added the comment:

Hi David

Ok, I like the idea of working on a solution together. I like your idea of
the pizza-making more than the current "foo bar" examples.

Should we collaborate outside of the bug tracker?

Greg

On 9 July 2012 07:11, David Lam <report at bugs.python.org> wrote:

>
> David Lam <d at dlam.me> added the comment:
>
> haha wow, I was working on this bug too!  maybe we can work on the final
> patch together
>
> I got through about 2/3's of the docs, so I thought it might help to
> upload what I got so far.  I basically just made stuff up so I'm totally
> winning to change anything (or everything)
>
> I made a little effort to make the examples mildly amusing, since novelty
> sorta helps in retention.  So one of the recurring examples I used involves
> that of a pizza-making-program... hopefully this helps in some way!
>
> ----------
> nosy: +dlam
> Added file:
> http://bugs.python.org/file26325/issue11165-doc-fix-up-to-section-15.4.4.diff
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11176>
> _______________________________________
>

----------

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

From report at bugs.python.org  Mon Jul  9 21:53:24 2012
From: report at bugs.python.org (Greg Roodt)
Date: Mon, 09 Jul 2012 19:53:24 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1341863604.02.0.531803281566.issue11176@psf.upfronthosting.co.za>


Greg Roodt <groodt at gmail.com> added the comment:

I've made the minor edits required after the review to my simplification of the first example.

David, perhaps we combine our efforts? Use my simple first example to explain the very basics, then continue the explanation with the pizza example?

Im happy either way, I quite like your example using the system dictionary.

----------
Added file: http://bugs.python.org/file26334/1176_minor_edits.diff

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

From report at bugs.python.org  Wed Jul 11 17:04:15 2012
From: report at bugs.python.org (florian-rathgeber)
Date: Wed, 11 Jul 2012 15:04:15 +0000
Subject: [docs] [issue12600] Add example of using load_tests to parameterise
	Test	Cases
In-Reply-To: <1311226769.48.0.369455670372.issue12600@psf.upfronthosting.co.za>
Message-ID: <1342019055.73.0.856961312762.issue12600@psf.upfronthosting.co.za>


Changes by florian-rathgeber <florian.rathgeber at gmail.com>:


----------
nosy: +florian-rathgeber

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

From report at bugs.python.org  Thu Jul 12 00:10:44 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 11 Jul 2012 22:10:44 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
Message-ID: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would help to clarify which collections.deque methods are thread-safe:

http://docs.python.org/dev/library/collections.html?highlight=deque#collections.deque

Currently, the documentation says that "Deques support thread-safe, memory efficient appends and pops from either side...," but it isn't obvious if this is meant to apply to all methods, or just the methods named append*() and pop*().

For example, is rotate() thread-safe?  The illustration given of d.appendleft(d.pop()) seems like it could be interleaved.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165275
nosy: cjerdonek, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: clarify which deque methods are thread-safe
versions: Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Jul 12 07:29:21 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 05:29:21 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342070961.79.0.783018219594.issue15329@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 12 08:17:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 06:17:05 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342073825.15.0.242851356401.issue15329@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I think some of the information in the issue 15330 comments would be very helpful to add as well (what thread-safe means in Python, distinction between thread-safe and atomic, and which deque methods are thread-safe and/or atomic).

If some of that information is too general for the collections library, perhaps some of it can go in a section of the Python documentation about multithreading (the glossary?), and then be linked to there.

----------

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

From report at bugs.python.org  Thu Jul 12 17:45:47 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 12 Jul 2012 15:45:47 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342107947.01.0.0483144600568.issue15329@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I think you're over-reaching.   We make almost no guarantees about atomicity.  Having multiple implementations of Python makes that an even harder task.  

In general, critical sections need to be guarded with locks.  If an object claims to be thread-safe, it means that it has used locks (perhaps relying on the GIL) to guard its own critical sections.  

Almost any pure Python class with complex state and without locks is not thread-safe (for example, an insertion into an OrderedDict needs to update the two dicts and a doubly-linked list).

Classes written in C are necessarily thread-safe (they rely on the GIL) or else they would risk segfaulting.  Other implementations are free to make different decisions about which classes are thread-safe. Pypy tends to make fewer guarantees because it implements more classes in pure python.  Jython tends to make strong guarantees because it uses Java's concurrent mappings and other such tools.

For the most part, the docs have done the right thing by not making any promises.  It might be helpful though to have a HOWTO guide explaining the facts-of-life when doing multi-threading (i.e. don't assume anything is atomic or thread-safe unless explicitly promised and don't expect many such promises).

----------
priority: normal -> low

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

From report at bugs.python.org  Thu Jul 12 18:05:12 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 12 Jul 2012 16:05:12 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342109112.94.0.31529022692.issue15329@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Pypy tends to make fewer guarantees because it implements 
> more classes in pure python.

This is not exactly true; in PyPy the _collection module was rewritten in RPython (which is translated to C) for this very reason: to make dequeue.append atomic and thus thread-safe.

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Thu Jul 12 18:10:45 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 16:10:45 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342109445.59.0.192734743932.issue15329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Classes written in C are necessarily thread-safe (they rely on the GIL)

That's not really true. A single Py_DECREF() can release the GIL by way of executing a Python __del__ method (or a weakref callback, or even the tp_dealloc of a file object that happens to release the GIL when close()ing the underlying file descriptor) somewhere along the reference chain, as evidenced by Amaury in http://bugs.python.org/issue15320#msg165253

I think that if the deque documentation makes the claim that some methods are thread-safe, they should be *really* thread-safe (which doesn't necessarily imply a lock, but implies being extra careful). Otherwise it's better to remove the claim from the docs.

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

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

From report at bugs.python.org  Fri Jul 13 00:00:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 22:00:35 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
Message-ID: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think it would be helpful if the Python documentation included certain high-level information about multi-threading in Python.

At minimum, I think it would help for the documentation to provide a definition that can be linked to of what it means when some part of the Python documentation says something is "thread-safe".  In particular, such a definition could clarify that this is different from being atomic.  This might best be addressed by an entry in the glossary for the term "thread-safe".
  
Other documentation possibilities include stating what guarantees one should or should not expect regarding thread-safety, both within and across implementations, and providing centralized guidance on how to approach multi-threaded programming in Python.  A HOWTO is one possibility for addressing these other possibilities.

This issue stems from the discussion in issue 15329, which is more specific.

----------
assignee: docs at python
components: Documentation
messages: 165336
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: document the threading "facts of life" in Python

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

From report at bugs.python.org  Fri Jul 13 00:06:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 12 Jul 2012 22:06:40 +0000
Subject: [docs] [issue15329] clarify which deque methods are thread-safe
In-Reply-To: <1342044644.52.0.376014623438.issue15329@psf.upfronthosting.co.za>
Message-ID: <1342130800.3.0.4304190219.issue15329@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15339 to document the multi-threading "facts of life" in Python (independent of any particular module or package, including this one), along the lines suggested by Raymond.

----------

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

From report at bugs.python.org  Fri Jul 13 00:11:16 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 Jul 2012 22:11:16 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342131076.29.0.0918025694107.issue15339@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This sounds like a good idea. Either a HOWTO or a FAQ would sound appropriate.

----------
nosy: +pitrou
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 13 08:45:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 06:45:48 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <3WYPff6CQBzPCJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset caea3c64442b by Eli Bendersky in branch 'default':
Some fixes for the documentation of multiprocessing (per issue #13686)
http://hg.python.org/cpython/rev/caea3c64442b

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

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

From report at bugs.python.org  Fri Jul 13 08:46:35 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 06:46:35 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1342161995.12.0.764927236856.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Switching this to 3.3 only

Fixes for 1-3 committed in caea3c64442b

----------

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

From report at bugs.python.org  Fri Jul 13 09:10:23 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 07:10:23 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <3WYQBz5lR0zP87@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 1110692aac71 by Eli Bendersky in branch 'default':
Additional fixes to multiprocessing docs (for issue #13686)
http://hg.python.org/cpython/rev/1110692aac71

----------

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

From report at bugs.python.org  Fri Jul 13 09:11:11 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 07:11:11 +0000
Subject: [docs] [issue13686] Some notes on the docs of multiprocessing
In-Reply-To: <1325307613.69.0.259805833126.issue13686@psf.upfronthosting.co.za>
Message-ID: <1342163471.57.0.167934321422.issue13686@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Done (except 5 and 6, which are non-issues on a second look)

----------
status: open -> closed
versions: +Python 3.3 -Python 2.7

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

From report at bugs.python.org  Fri Jul 13 09:23:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 13 Jul 2012 07:23:43 +0000
Subject: [docs] [issue14190] Minor C API documentation bugs
In-Reply-To: <1330841228.13.0.736937779561.issue14190@psf.upfronthosting.co.za>
Message-ID: <1342164222.92.0.0383868616154.issue14190@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Closing, as I don't think it's terribly important to backport this.

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

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

From report at bugs.python.org  Fri Jul 13 15:18:27 2012
From: report at bugs.python.org (Simon Hayward)
Date: Fri, 13 Jul 2012 13:18:27 +0000
Subject: [docs] [issue15345] HOWTOs Argparse tutorial - code example
	raises	SyntaxError
Message-ID: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>


New submission from Simon Hayward <simonhayward at gmail.com>:

HOWTOs - Argparse Tutorial, the code example will raise a syntax error when run. A trailing python3 reference (if called as a function): 'end=""', to suppresses a newline remains.

print "{}^{} == ".format(args.x, args.y), end=""

Should read:

print "{}^{} ==".format(args.x, args.y),

----------
assignee: docs at python
components: Documentation
files: argparse-howto.patch
keywords: patch
messages: 165381
nosy: docs at python, simon.hayward
priority: normal
severity: normal
status: open
title: HOWTOs Argparse tutorial - code example raises SyntaxError
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26374/argparse-howto.patch

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

From report at bugs.python.org  Fri Jul 13 17:26:27 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 15:26:27 +0000
Subject: [docs] [issue15053] imp.lock_held() "Changed in Python 3.3"
	mention	accidentally one function up
In-Reply-To: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>
Message-ID: <3WYdCQ25LHzNb7@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset c09f454af2c6 by Brett Cannon in branch 'default':
Issue #15053: Make sure all functions related to the import lock have
http://hg.python.org/cpython/rev/c09f454af2c6

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

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

From report at bugs.python.org  Fri Jul 13 17:27:19 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:27:19 +0000
Subject: [docs] [issue15053] imp.lock_held() "Changed in Python 3.3"
	mention	accidentally one function up
In-Reply-To: <1339532446.32.0.0402768881162.issue15053@psf.upfronthosting.co.za>
Message-ID: <1342193239.62.0.8044659147.issue15053@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Jul 13 17:32:05 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 13 Jul 2012 15:32:05 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342193525.73.0.203165535729.issue15151@psf.upfronthosting.co.za>


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


----------
nosy: +Yury.Selivanov, larry, yselivanov

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

From report at bugs.python.org  Fri Jul 13 18:47:27 2012
From: report at bugs.python.org (Daniel Swanson)
Date: Fri, 13 Jul 2012 16:47:27 +0000
Subject: [docs] [issue15346] Tkinter dnd has no documentation
Message-ID: <1342198047.2.0.619885102312.issue15346@psf.upfronthosting.co.za>


New submission from Daniel Swanson <popcorn.tomato.dude at gmail.com>:

The title should be self explanatory.
I needed Drag-and-drop for a project I was working on, (maybe I shouldn't be refering to it in the past tense as I haven't started yet) so I checked the documentation for tkinter and found:
3.3.0 b1
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

3.2.2 (and .2.3)
tkinter.dnd 
Drag-and-drop support for tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND. 

2.7.3
Tkdnd 
Drag-and-drop support for Tkinter. This is experimental and should become deprecated when it is replaced with the Tk DND.

I think that tkinter.dnd needs some documentation, whether or not it is replaced with Tk DND.

----------
assignee: docs at python
components: Documentation
messages: 165392
nosy: docs at python, weirdink13
priority: normal
severity: normal
status: open
title: Tkinter dnd has no documentation
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 13 20:09:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 13 Jul 2012 18:09:08 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342202948.31.0.603217981786.issue15339@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

If no one gets to it first, I'll write-up a draft when I get a chance.

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

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

From report at bugs.python.org  Fri Jul 13 20:19:50 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:19:50 +0000
Subject: [docs] [issue15345] HOWTOs Argparse tutorial - code example
	raises	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <1342203590.45.0.789252636347.issue15345@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Jul 13 20:52:35 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 18:52:35 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342205554.99.0.926243211283.issue15339@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Jul 13 21:01:43 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 13 Jul 2012 19:01:43 +0000
Subject: [docs] [issue15270] "Economy of Expression" section outdated
In-Reply-To: <1341641029.42.0.551889407429.issue15270@psf.upfronthosting.co.za>
Message-ID: <1342206103.19.0.853211233227.issue15270@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Jul 13 21:40:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 19:40:48 +0000
Subject: [docs] [issue15345] HOWTOs Argparse tutorial - code example
	raises	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <3WYkrv44tqzNHC@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset de18c4470ff1 by Ezio Melotti in branch '2.7':
#15345: fix SyntaxError in argparse tutorial example.  Patch by Simon Hayward.
http://hg.python.org/cpython/rev/de18c4470ff1

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

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

From report at bugs.python.org  Fri Jul 13 21:41:51 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 13 Jul 2012 19:41:51 +0000
Subject: [docs] [issue15345] HOWTOs Argparse tutorial - code example
	raises	SyntaxError
In-Reply-To: <1342185507.58.0.724353170011.issue15345@psf.upfronthosting.co.za>
Message-ID: <1342208511.56.0.626554306114.issue15345@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed, thanks for the patch!

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

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

From report at bugs.python.org  Sat Jul 14 00:49:18 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 Jul 2012 22:49:18 +0000
Subject: [docs] [issue15241] venv module and pyvenv script documented,
	but not python behavior itself
In-Reply-To: <1341289374.35.0.678239476605.issue15241@psf.upfronthosting.co.za>
Message-ID: <3WYq2P0rblzPBD@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 0dbffd3c1317 by Ned Deily in branch 'default':
Issue #15241: Fix test_prefixes failure in test_venv due to symlink in
http://hg.python.org/cpython/rev/0dbffd3c1317

----------

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

From report at bugs.python.org  Sat Jul 14 09:19:11 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 07:19:11 +0000
Subject: [docs] [issue15331] Codecs docs should explain that the
	bytes-bytes	shorthand aliases are missing
In-Reply-To: <1342091074.63.0.386956250979.issue15331@psf.upfronthosting.co.za>
Message-ID: <1342250351.73.0.994637545781.issue15331@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

While you're right about that, the docs shouldn't be claiming they're available as long as that is the case.

Updated the issue to make it clear this is a problem with the current docs and the change in the nature of the encode() and decode() methods for Python 3.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage: test needed -> needs patch
title: Missing codec aliases for bytes-bytes codecs -> Codecs docs should explain that the bytes-bytes shorthand aliases are missing

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

From report at bugs.python.org  Sat Jul 14 09:38:57 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 14 Jul 2012 07:38:57 +0000
Subject: [docs] [issue15339] document the threading "facts of life" in Python
In-Reply-To: <1342130435.62.0.0784000861923.issue15339@psf.upfronthosting.co.za>
Message-ID: <1342251537.64.0.965891381169.issue15339@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given the scope of the issue, a concurrent programming howto that lists some of the available options and the caveats associated with each of them seems worthwhile.

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

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

From report at bugs.python.org  Sat Jul 14 19:14:34 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 14 Jul 2012 17:14:34 +0000
Subject: [docs] [issue15228] os.utime() docs not clear on behavior on
	nonexistant	files
In-Reply-To: <1341086123.85.0.135321380132.issue15228@psf.upfronthosting.co.za>
Message-ID: <1342286074.1.0.43572270194.issue15228@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I don't think this needs clarifying.  If you think the reference to "touch" currently only muddles the issue, let's remove it entirely.

----------

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

From report at bugs.python.org  Sun Jul 15 02:31:01 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 00:31:01 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
Message-ID: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I think the generator.__next__() documentation should say that it raises an exception if the generator is already executing:

http://docs.python.org/dev/reference/expressions.html#generator.__next__

I don't think this is currently mentioned anywhere in the section on yield expressions.

I think this is worth mentioning because this is different from the general situation for iterators, for example.  One consequence of this is that, unlike for iterators, using a bare generator in a multithreaded situation will always result in a critical section (since an iterator can be made to take care of its own locking, etc).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 165476
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: generator.__next__() docs should mention exception if already executing
versions: Python 3.3

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

From report at bugs.python.org  Sun Jul 15 03:16:13 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:16:13 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342314973.26.0.376477742012.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Okay, I'll remove the ".. note".  Checking in shortly.

----------

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

From report at bugs.python.org  Sun Jul 15 03:21:16 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 Jul 2012 01:21:16 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <3WZVMG6NkfzP42@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f8b520b6f654 by Larry Hastings in branch 'default':
- Issue #15233: Python now guarantees that callables registered with
http://hg.python.org/cpython/rev/f8b520b6f654

----------

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

From report at bugs.python.org  Sun Jul 15 03:22:23 2012
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 Jul 2012 01:22:23 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342315343.11.0.329603786914.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

So, it's checked in to trunk.  Shall I also backport to 2.7 and 3.2 as the issue suggests?

----------

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

From report at bugs.python.org  Sun Jul 15 05:20:58 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:20:58 +0000
Subject: [docs] [issue9458] xml.etree.ElementTree.ElementTree.write():
	encoding	handling problems
In-Reply-To: <1280782925.67.0.136452249646.issue9458@psf.upfronthosting.co.za>
Message-ID: <1342322458.93.0.731985565555.issue9458@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree with Serhiy that this is more of a documentation/understanding issue than a real bug. I've clarified the doc of ElementTree.write a bit to make it explicit what stream is expected for 'write'.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Jul 15 05:35:40 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:35:40 +0000
Subject: [docs] [issue13823] xml.etree.ElementTree.ElementTree.write -
	argument	checking
In-Reply-To: <1326963107.43.0.928827185581.issue13823@psf.upfronthosting.co.za>
Message-ID: <1342323340.07.0.267970309887.issue13823@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

About (1):

It's customary for Python to accept "truthful" values (like non-empty strings) as True. I see no harm in that. Strict type-checking to boolean True in each and every place is not necessary.

About (2):

Similarly, this isn't productive. ET may not know about all encodings underlying the system. The warning is clearly documented - it's up for the user to make sure it's valid.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Sun Jul 15 05:56:05 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:56:05 +0000
Subject: [docs] [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342324565.22.0.672693876009.issue14332@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

ping

----------

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

From report at bugs.python.org  Sun Jul 15 05:56:18 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:56:18 +0000
Subject: [docs] [issue13386] Document documentation conventions for optional
	args
In-Reply-To: <1321078121.18.0.541430257552.issue13386@psf.upfronthosting.co.za>
Message-ID: <1342324578.86.0.76888905509.issue13386@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

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

From report at bugs.python.org  Sun Jul 15 05:58:19 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 15 Jul 2012 03:58:19 +0000
Subject: [docs] [issue13997] Clearly explain the bare minimum Python 3 users
	should	know about Unicode
In-Reply-To: <1329021187.19.0.262146289648.issue13997@psf.upfronthosting.co.za>
Message-ID: <1342324699.49.0.817566660555.issue13997@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy:  -eli.bendersky

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

From report at bugs.python.org  Sun Jul 15 07:21:23 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 Jul 2012 05:21:23 +0000
Subject: [docs] [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342329683.64.0.0242776304007.issue14332@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I guess I should try to come up with something that is an improvement, even if not perfect.

----------

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

From dursolab at gmail.com  Fri Jul  6 21:57:23 2012
From: dursolab at gmail.com (Brian D'Urso)
Date: Fri, 6 Jul 2012 15:57:23 -0400
Subject: [docs] floating point conversion error
Message-ID: <CAOoo_a-a_J7Kw_Q__WSCxvRdjAsuEJKDC+ney=fBfW1oQKQsLA@mail.gmail.com>

Converting from a string to a float (for example, after having read in data
from a file) encounter a "value error: invalid literal" error when given
'00E', which is part of '00E+00', the representation used by several
spreadsheet programs for 0 when a cell is set to scientific notation. This
renders all python programs unable to work with any data input from files
created by a program that adheres to this convention, most notably EXCEL
and Calc, without specific user intervention, either on the spreadsheet or
pythons sides. his should properly translate to 0.0 as a float when
encountered.

Example code:

#expects data of this form (a CSV file):
        #,,Height Comparison (mm),,,Tilt Comparison (degrees),,,

#6,1.2,0.260936375,0.246329669,0.014606706,0.147779582,2.70248E-10,c,asdfj,
234,,

#7,1.4,0.30234927,0.287927142,0.014422127,1.042261298,1.45951E-08,cdv128,sgaoda,dga,kjadodf,,

#8,1.4,0.245442271,0.308505346,-0.063063075,0.745239509,0,1234891,13E-89,sdfglksj,,

dat =
re.findall("([-]?[\.\d]*),([-]?[\.\d]*),([-]?[\.\d]*),([-]?[\.\d]*),[-]?[\.\d]*,([-]?[\.\d]*),([-]?[\.\d]*[E]?[-]?[\.\d]*)",info)
    for x in dat:

stuff=[float(x[0]),float(x[1]),float(x[2]),float(x[3]),float(x[4]),float(x[5])]
#will fail here if any value is 00E+00
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120706/00bf6fa2/attachment.html>

From dxpublica at telefonica.net  Sat Jul  7 20:18:05 2012
From: dxpublica at telefonica.net (Xan)
Date: Sat, 07 Jul 2012 20:18:05 +0200
Subject: [docs] A bug in documentation in argparse
Message-ID: <4FF87D5D.9010201@telefonica.net>

Hi,

Just a comment, please put in argparse documentation that in 
add_argument we could not combine with success type and nargs='?'. For 
example:
parser.add_argument("-m", "--mostrar", nargs='+', type=int)

does not check if all elements in list (1 or more) are integers or not.

I don't know if it's a bug in argparse or if this behaviour is 
intentionally this way. In last case, please upgrade the documentation.

Thanks in advance,
Xan.


From ezio.melotti at gmail.com  Mon Jul  9 10:23:56 2012
From: ezio.melotti at gmail.com (ezio.melotti at gmail.com)
Date: Mon, 09 Jul 2012 08:23:56 -0000
Subject: [docs] give more meaningful argument names in argparse
 documentation (issue 11176)
Message-ID: <20120709082356.8056.9896@psf.upfronthosting.co.za>


http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst
File Doc/library/argparse.rst (right):

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode40
Doc/library/argparse.rst:40: parser.add_argument('-f', '--file',
type=str, default="/usr/share/dict/words",
Not sure it's a good idea to provide a default here (especially one that
doesn't work on all the operative systems).

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode70
Doc/library/argparse.rst:70:
text_file_lines.extend(text_file.readlines())     # start at "line 1"
I would keep the lines starting from 0, and use the with statement:
with open(args.file) as f:
    lines = list(f)

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode74
Doc/library/argparse.rst:74: lines_to_print =
(text_file_lines[args.line_numbers[0]]),
Did you mean to put the comma inside the ()?

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode78
Doc/library/argparse.rst:78: lines_to_print =
itemgetter(*args.line_numbers)(text_file_lines)
This is a bit tricky, I would use something like:
[line for n,line in enumerate(lines)
 if n in args.line_numbers]?

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode84
Doc/library/argparse.rst:84: print('Line #{0}: 
{1}'.format(args.line_numbers[i], line), end="")
The 0 and 1 are unnecessary.

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode207
Doc/library/argparse.rst:207: >>> pizza_parser =
argparse.ArgumentParser(
/me approves pizza

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode472
Doc/library/argparse.rst:472: ...                     help='the sauce to
use')
This should be indented under the first ' of the previous line.

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode495
Doc/library/argparse.rst:495: ...     help="how man slices the pizza
will be cut up into")
Why a float? can you cut 7.9 slices?

http://bugs.python.org/review/11176/diff/5362/Doc/library/argparse.rst#newcode1125
Doc/library/argparse.rst:1125: >>> pizza_parser.add_argument('slices',
nargs='?', type=int, default=10,
The default here should be 8.

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

From hadwarez at gmail.com  Sat Jul  7 14:35:14 2012
From: hadwarez at gmail.com (Hadrien Titeux)
Date: Sat, 07 Jul 2012 14:35:14 +0200
Subject: [docs] Small error in the "Extending Python with C" page
Message-ID: <4FF82D02.8010304@gmail.com>

Hello,

I've recenty started to try using C code in python using the wonderful
python API, although i have to say the learning curve was non neglectable :P
I've spotted what I believe to be a small mistake in the documentation
from this page:
http://docs.python.org/release/3.2/extending/extending.html

In paragraph 1.8
(http://docs.python.org/release/3.2/extending/extending.html#keyword-parameters-for-extension-functions),
the code example given contains an error, which is actually obsolete
code from python 2.7:

void
initkeywdarg(void)
{
  /* Create the module and add the functions */
  Py_InitModule("keywdarg", keywdarg_methods);
}


This doesn't work in Python3.2. It's supposed to be

static struct PyModuleDef keywdargmodule = {
   PyModuleDef_HEAD_INIT,
   "keywdarg",   /* name of module */
   keywdarg_doc, /* module documentation, may be NULL */
   -1,       /* size of per-interpreter state of the module,
                or -1 if the module keeps state in global variables. */
   keywdarg_methods
};

PyMODINIT_FUNC
PyInit_keywdarg(void)
{
    return PyModule_Create(&keywdargmodule);
}

As explained above (and confirmed by experience).

Thanks for your work,
Hadrien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120707/9a9ae4ce/attachment-0001.html>

From ibirisol at dcc.ufba.br  Sat Jul 14 02:10:47 2012
From: ibirisol at dcc.ufba.br (IBIRISOL FONTES FERREIRA)
Date: Fri, 13 Jul 2012 21:10:47 -0300
Subject: [docs] About documentation
Message-ID: <20120713211047.112863zjquac57gn@webmail.dcc.ufba.br>

Hi there,

I wanna learn python in more specific topics, but i didn't found in  
documentation.

For example, How work the parameter passing in Python? How work the  
name space? How work memory allocation?

I need this documentation for my study, plizzz, help me with  
documentation link...

Bye,


From kishkin at gmail.com  Thu Jul 12 08:46:57 2012
From: kishkin at gmail.com (kishkin)
Date: Thu, 12 Jul 2012 10:46:57 +0400
Subject: [docs] Missing ')' in argparse docs
Message-ID: <CAK=w1zf+tUqhrMz__JZ+ccjqarZCh3MntbFVk=cv65TJ3zo0jg@mail.gmail.com>

Hello,

Just a minor typo here: http://docs.python.org/library/argparse.html#action

"values - The associated command-line arguments, with any type
conversions applied. (Type conversions are specified with the type
keyword argument to add_argument()." - here ')' is missing at the end.

Thanks.

---
Michael

From kishorguptha at gmail.com  Sun Jul 15 04:15:19 2012
From: kishorguptha at gmail.com (Kishor Kp)
Date: Sun, 15 Jul 2012 07:45:19 +0530
Subject: [docs] Python tutorial required.
Message-ID: <CAL803wKGAO-8KDtSjVT5oRLdozAEpi45AcY+4Q6yf_dZCShMEg@mail.gmail.com>

Hi,

  Right now I would be learning Python Programming Language and I was
searching for
the best book on this. I found it to be from the author " Guido van Rossum".

Could you please email the below book?

   - *Title* Python Tutorial
   - *Author(s)* Guido van Rossum
   - *Publisher:* Iuniverse Inc (April 2000); eBook (updated June 11, 2012)
   - *Hardcover/Paperback* 140 pages
   - *eBook* HTML and PDF files
   - *Language:* English
   - *ISBN-10:* 1583483756
   - *ISBN-13:* 978-1475234039

Thanks,
Kishor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120715/80576e66/attachment.html>

From rkern at enthought.com  Thu Jul 12 12:08:41 2012
From: rkern at enthought.com (Robert Kern)
Date: Thu, 12 Jul 2012 11:08:41 +0100
Subject: [docs] New link for CodeTools
Message-ID: <CAKdwa3kBrz-zCh3vs1zJyU0ytPyy1r8AB79HDaLEzwxLOO8QWg@mail.gmail.com>

The Python 3 docs
<http://python.readthedocs.org/en/latest/_sources/library/collections.txt>
link to a file in an old repository.

      * The `MultiContext class
        <http://svn.enthought.com/svn/enthought/CodeTools/trunk/enthought/contexts/multi_context.py>`_
        in the Enthought `CodeTools package
        <https://github.com/enthought/codetools>`_ has options to support
        writing to any mapping in the chain.

Should be this:

      * The `MultiContext class
        <https://github.com/enthought/codetools/blob/4.0.0/codetools/contexts/multi_context.py>`_
        in the Enthought `CodeTools package
        <https://github.com/enthought/codetools>`_ has options to support
        writing to any mapping in the chain.

That link should persist more reliably in the future.

Thank you!

-- 
Robert Kern
Enthought

From sateeshpyper at gmail.com  Tue Jul 10 09:43:09 2012
From: sateeshpyper at gmail.com (Sateesh Kumar)
Date: Tue, 10 Jul 2012 13:13:09 +0530
Subject: [docs] In difflib module name of the parameters for *_diff methods
	can be descriptive
Message-ID: <CALw2s+tyc9Ee034cyprQ6AUO-W5q6d8Fog-8PdqxDSPTjSPkzA@mail.gmail.com>

In the 'difflib' module the signature of the method context_diff is as below:

difflib.context_diff(a, b[, fromfile][, tofile][, fromfiledate][,
tofiledate][, n][, lineterm])

As per the documentation 'fromfile' and 'tofile' are used as names of
the headers
in the report generated.It is expected that the user specifies
names of the files as arguments for optional parameters 'fromfile' and
'tofile'. But name of the parameter 'fromfile' ('tofile') is bit confusing
as it doesn't give a clear indication that what is expected is a name of a file
(and not a fileobject). So it is better to rename these parameters
as 'fromfilename' and 'tofilename' which will also be in sync with
other parameter names ('fromfiledate','tofiledate').

Similar change can be done in method 'difflib.unified_diff'.

I am referring to documentation of this module in Python 2.7.3
http://docs.python.org/library/difflib.html


thanks,
sateesh

From udoyen at gmail.com  Sat Jul  7 05:15:16 2012
From: udoyen at gmail.com (george)
Date: Sat, 07 Jul 2012 04:15:16 +0100
Subject: [docs] Programing issues  [HELP]
Message-ID: <4FF7A9C4.7000501@gmail.com>

Hi,
Guido van Rossum & Fred L. Drake, Jr., editor

I had some problems with the tutorials so i've sent this screen shoot. 
Some of the output didn't match what I saw on your tutorial.

My python version is: Python 3.2.3 and its the 64bit type on my Windows 
7 (64bit) Home Premium.

George
NIgeria





-------------- next part --------------
A non-text attachment was scrubbed...
Name: Ashampoo_Snap_2012.07.06_17h12m26s_001.png
Type: image/png
Size: 204444 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/docs/attachments/20120707/95e4fa69/attachment-0001.png>

From report at bugs.python.org  Sun Jul 15 18:55:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 15 Jul 2012 16:55:58 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342371358.56.0.748827955732.issue15233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Shall I also backport to 2.7 and 3.2 as the issue suggests?

If the tests are there, yes!

----------

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

From report at bugs.python.org  Sun Jul 15 19:25:06 2012
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 15 Jul 2012 17:25:06 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
Message-ID: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>


New submission from Davide Rizzo <sorcio at gmail.com>:

The documentation (at least the obvious places, see Doc/reference/datamodel.rst) says classes and class instances have the '__dict__' attribute, but nothing is said about what happens when assigning to it (like obj.__dict__ = something).

As far as I understand that's undefined behavior and other implementations may not work the same as CPython (and CPython itself behaves differently between versions).

I'd submit a documentation patch if I knew how to specify this matter. Maybe just say the behavior is not defined?

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 165538
nosy: davide.rizzo, docs at python
priority: normal
severity: normal
status: open
title: Behavior of assigning to __dict__ is not documented
versions: Python 2.7, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun Jul 15 19:25:17 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 15 Jul 2012 17:25:17 +0000
Subject: [docs] [issue15297] pkgutil.iter_importers() includes an ImpImporter
In-Reply-To: <1341781980.93.0.099189257301.issue15297@psf.upfronthosting.co.za>
Message-ID: <1342373117.33.0.262559679512.issue15297@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Closing as this is no longer an issue after Nick's pkgutil changes documented in issue 15343.

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

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

From report at bugs.python.org  Mon Jul 16 02:39:40 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 16 Jul 2012 00:39:40 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342399179.8.0.483854185627.issue15151@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

Is anyone working on this?  I could possibly take a stab at it tonight, if I get the evening to myself.

----------

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

From report at bugs.python.org  Mon Jul 16 06:56:27 2012
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 16 Jul 2012 04:56:27 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342414586.93.0.408246161863.issue15233@psf.upfronthosting.co.za>


Larry Hastings <larry at hastings.org> added the comment:

I have been meditating on this, and I'm not sure we should change 2.7.  3.2 might be okay.

The thing is, I fear we're not just talking about CPython implementation details, we're talking about the Python Standard Library.  The existing documentation clearly gives alternative implementations free license to call atexit registered functions in any order they like.  So it's conceivable that other implementations don't guarantee reverse order.

I don't know what the right thing is to do here.  It seems like we could define atexit's behavior for 2.7 *if* all the major alternative implementations happily also implicitly guarantee reverse order.  Failing that we probably shouldn't touch it.  Or we could just document that reverse order is guaranteed in CPython only.

Of course, there are no alternative implementations that support 3.2.  That's why I think 3.2 might be okay.  It does seem strange to redefine part of the implicit language spec more than a year after the release shipped though.

----------

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

From report at bugs.python.org  Mon Jul 16 09:01:15 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 16 Jul 2012 07:01:15 +0000
Subject: [docs] [issue15233] atexit: guarantee order of execution of
	registered	functions?
In-Reply-To: <1341129521.95.0.805489135584.issue15233@psf.upfronthosting.co.za>
Message-ID: <1342422075.65.0.47753663475.issue15233@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for backport.  There's no benefit to leaving ambiguity floating about, nor was there ever any intention for the behavior to have been different.

----------

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

From report at bugs.python.org  Mon Jul 16 15:41:45 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 16 Jul 2012 13:41:45 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
Message-ID: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

The benchmarking tools "pystones" and "pybench" which are shipped with the Python standard distribution are not documented.

The only information is in the what's-new for Python 2.5:
http://docs.python.org/dev/whatsnew/2.5.html?highlight=pybench#new-improved-and-removed-modules

IMHO, they should be mentioned somewhere in the HOWTOs, the FAQ or the standard library documentation ("Development Tools" or "Debugging and Profiling")

----------
assignee: docs at python
components: Benchmarks, Documentation
messages: 165603
nosy: docs at python, flox
priority: normal
severity: normal
status: open
title: pybench and test.pystone poorly documented
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Mon Jul 16 16:22:20 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:22:20 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342448540.74.0.192563878944.issue14787@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

At the very least, the pkgutil docs need to state clearly that walk_packages only works properly with sys.path entries, and the constraint feature may not descend into packages correctly if an entry is shadowed by a sys.modules entry or an entry earlier on sys.meta_path or sys.path.

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

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

From report at bugs.python.org  Mon Jul 16 16:35:18 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 16 Jul 2012 14:35:18 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342449318.01.0.316117733042.issue14787@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I just realised this is going to behave strangely with namespace packages as well: the __import__ step will pick up *every* portion of the namespace package, not just those defined in the identified subset of sys.path.

----------

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

From report at bugs.python.org  Mon Jul 16 17:39:22 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 16 Jul 2012 15:39:22 +0000
Subject: [docs] [issue14787] pkgutil.walk_packages returns extra modules
In-Reply-To: <1336813271.29.0.464157696844.issue14787@psf.upfronthosting.co.za>
Message-ID: <1342453162.64.0.655246850951.issue14787@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> This isn't an easy one to fix - you basically need something along the lines of a PEP 406 style import engine API in order to do the import without having potentially adverse effects on the state in the sys module.

By adverse, do you just mean side effects? If so, since the documentation doesn't explicitly say so, is there any reason for the user to think there shouldn't be side effects?  For example, I tried this in Python 2.7:

>>> import os, sys, pkgutil, unittest
>>> len(sys.modules)
86
>>> g = pkgutil.walk_packages([os.path.dirname(unittest.__file__)])
>>> len(sys.modules)
86
>>> for i in g:
...   pass
... 
>>> len(sys.modules)
95

Or maybe this isn't what you mean. If not, can you provide an example?

----------

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

From report at bugs.python.org  Mon Jul 16 21:13:35 2012
From: report at bugs.python.org (Erik Johansson)
Date: Mon, 16 Jul 2012 19:13:35 +0000
Subject: [docs] [issue14201] Documented caching for shared library's
	__getattr__ and	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1342466014.45.0.104279671475.issue14201@psf.upfronthosting.co.za>


Erik Johansson <erik at ejohansson.se> added the comment:

Document the difference between __getattr__ and __getitem__.

----------
keywords: +patch
Added file: http://bugs.python.org/file26402/issue14201.patch

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

From report at bugs.python.org  Tue Jul 17 04:05:11 2012
From: report at bugs.python.org (Renato Cunha)
Date: Tue, 17 Jul 2012 02:05:11 +0000
Subject: [docs] [issue15375] Trivial for fix in the subprocess documentation
Message-ID: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>


New submission from Renato Cunha <renato at renatocunha.com>:

The word "child" is needlessly repeated in the subprocess documentation. This trivial patch fixes this.

----------
assignee: docs at python
components: Documentation
files: subprocess.diff
keywords: patch
messages: 165670
nosy: docs at python, trovao
priority: normal
severity: normal
status: open
title: Trivial for fix in the subprocess documentation
type: enhancement
versions: Python 2.7
Added file: http://bugs.python.org/file26408/subprocess.diff

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

From report at bugs.python.org  Tue Jul 17 04:31:48 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 Jul 2012 02:31:48 +0000
Subject: [docs] [issue15375] Trivial for fix in the subprocess documentation
In-Reply-To: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>
Message-ID: <3Wblqj5yRPzPJ5@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 227a22288688 by R David Murray in branch '2.7':
#15375: remove duplicated word 'child'
http://hg.python.org/cpython/rev/227a22288688

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

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

From report at bugs.python.org  Tue Jul 17 04:32:59 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 Jul 2012 02:32:59 +0000
Subject: [docs] [issue15375] Trivial for fix in the subprocess documentation
In-Reply-To: <1342490711.26.0.923529626372.issue15375@psf.upfronthosting.co.za>
Message-ID: <1342492378.88.0.081120655622.issue15375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks.  (This error existed on only in the 2.7 docs.)

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

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

From report at bugs.python.org  Tue Jul 17 05:37:43 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 17 Jul 2012 03:37:43 +0000
Subject: [docs] [issue14332] Better explain "junk" concept in difflib doc
In-Reply-To: <1331877125.66.0.103153393744.issue14332@psf.upfronthosting.co.za>
Message-ID: <1342496263.34.0.930916411625.issue14332@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I agree. Any improvement is preferred over just letting this decay in the issue tracker ;-)

----------

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

From report at bugs.python.org  Tue Jul 17 07:31:10 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 05:31:10 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342503070.09.0.989183701483.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

Larry, Brett,

I compiled the documentation from the PEP (attached as inspect.pep362.1.patch).  Please take a look and feel free to add/edit.

----------
keywords: +patch
Added file: http://bugs.python.org/file26410/inspect.pep362.1.patch

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

From report at bugs.python.org  Tue Jul 17 15:02:40 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Jul 2012 13:02:40 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342530160.43.0.580671138049.issue15369@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I disagree. They are outdated benchmarks and probably should either be removed or left undocumented. Proper testing of performance is with the Unladen Swallow benchmarks.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Jul 17 15:36:57 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 17 Jul 2012 13:36:57 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342530160.43.0.580671138049.issue15369@psf.upfronthosting.co.za>
Message-ID: <50056A75.5040407@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brett Cannon wrote:
> 
> Brett Cannon <brett at python.org> added the comment:
> 
> I disagree. They are outdated benchmarks and probably should either be removed or left undocumented. Proper testing of performance is with the Unladen Swallow benchmarks.

I disagree with your statement. Just like every benchmark, they serve
their purpose in their particular field of use, e.g. pybench may not
be useful for the JIT approach originally taken by the Unladden Swallow
project, but it's still useful to test/check changes in the non-JIT
CPython interpreter and it's extensible to take new developments
into account. pystone is useful to get a quick feel the performance
of Python on a machine.

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

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

From report at bugs.python.org  Tue Jul 17 15:50:25 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Tue, 17 Jul 2012 13:50:25 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342533025.73.0.137309811098.issue15369@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Actually, I discovered "python -m test.pystone" during the talk of Mike M?ller at EuroPython. http://is.gd/fasterpy

Even if they are suboptimal for true benchmarks, they should probably be mentioned somewhere.
In the same paragraph, there should be a link to the "Grand Unified Python Benchmark Suite" as best practice:

http://hg.python.org/benchmarks
http://hg.python.org/benchmarks/file/tip
http://hg.python.org/benchmarks/file/tip/README.txt

The last paragraph of this wiki page might be reworded and included in the Python documentation:
http://code.google.com/p/unladen-swallow/wiki/Benchmarks
http://code.google.com/p/unladen-swallow/wiki/Benchmarks#Benchmarks_we_don't_use



BTW, there's also this website which seems not updated anymore?
http://speed.python.org/

----------
nosy: +jnoller

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

From report at bugs.python.org  Tue Jul 17 16:54:36 2012
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 17 Jul 2012 14:54:36 +0000
Subject: [docs] [issue15369] pybench and test.pystone poorly documented
In-Reply-To: <1342446105.53.0.956340794171.issue15369@psf.upfronthosting.co.za>
Message-ID: <1342536876.39.0.516670862448.issue15369@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The Unladen Swallow benchmarks are in no way specific to JITs; it is a set of thorough benchmarks for measuring the overall performance of a Python VM.

As for speed.python.org, we know that it is currently not being updated as we are waiting for people to have the time to move it forward and replace speed.pypy.org for all Python VMs.

----------
nosy:  -jnoller

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

From report at bugs.python.org  Tue Jul 17 17:35:11 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 15:35:11 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342539311.45.0.0243752918596.issue15151@psf.upfronthosting.co.za>


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


----------
nosy:  -Yury.Selivanov

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

From report at bugs.python.org  Tue Jul 17 20:08:11 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 18:08:11 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342548490.82.0.57969536559.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

The new patch version (inspect.pep362.2.patch) includes more examples and includes recommendations to use the Signature Object instead of 'inspect.getfullargsspec'.  Please review.

----------
Added file: http://bugs.python.org/file26419/inspect.pep362.2.patch

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

From report at bugs.python.org  Tue Jul 17 22:02:28 2012
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 Jul 2012 20:02:28 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342555348.42.0.578378487204.issue15151@psf.upfronthosting.co.za>


Yury Selivanov <yselivanov.ml at gmail.com> added the comment:

New patch version - inspect.pep362.3.patch

I decided to put the new doc section above the "Classes and functions". The new section is now called "Introspecting callables with Signature Object".  Aside from that everything is the same as in the 2nd patch.

----------
Added file: http://bugs.python.org/file26420/inspect.pep362.3.patch

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

From report at bugs.python.org  Tue Jul 17 23:49:51 2012
From: report at bugs.python.org (David Lam)
Date: Tue, 17 Jul 2012 21:49:51 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1342561791.33.0.432891402333.issue11176@psf.upfronthosting.co.za>


David Lam <d at dlam.me> added the comment:

yup yup, go for it

----------

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

From report at bugs.python.org  Wed Jul 18 15:36:06 2012
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 Jul 2012 13:36:06 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342618565.86.0.120508197429.issue15360@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What kind of behavior are you referring to?
Are there really differences between versions?

----------
nosy: +amaury.forgeotdarc

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

From report at bugs.python.org  Wed Jul 18 19:02:58 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Wed, 18 Jul 2012 17:02:58 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342630978.41.0.469706059606.issue15360@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/issue15360>
_______________________________________

From report at bugs.python.org  Thu Jul 19 01:44:28 2012
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 Jul 2012 23:44:28 +0000
Subject: [docs] [issue9254] __import__ docstring should
	recommend	importlib.import_module()
In-Reply-To: <1279057769.02.0.398615806235.issue9254@psf.upfronthosting.co.za>
Message-ID: <3Wcw1j2pJkzPGT@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 751f28564a45 by R David Murray in branch '2.7':
Closes #9254: backport __import__ docstring/doc mentions of importlib.
http://hg.python.org/cpython/rev/751f28564a45

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jul 19 20:40:51 2012
From: report at bugs.python.org (Gunnlaugur Thor Briem)
Date: Thu, 19 Jul 2012 18:40:51 +0000
Subject: [docs] [issue15399] processName key is un-/mis-documented in 2.6
	and up
Message-ID: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>


New submission from Gunnlaugur Thor Briem <gunnlaugur at gmail.com>:

The ``processName`` format mapping key in logging formats works in versions 2.6.*, 2.7.* and 3.1.* onwards; in 2.5 and down and in 3.0.1, ``format`` fails when this key is present in the format.

But in 2.6.8 docs, this mapping key is not documented:

http://docs.python.org/release/2.6.8/library/logging.html
http://docs.python.org/release/3.0.1/library/logging.html

and in 2.7.3 and 3.1.5 and 3.2.3 docs, it is documented but there is no note that it is new in any particular version (unlike ``funcName``, for which there is ?Changed in version 2.5: funcName was added?):

http://docs.python.org/release/2.7.3/library/logging.html
http://docs.python.org/release/3.1.5/library/logging.html
http://docs.python.org/release/3.2.3/library/logging.html

Consistent with (what I think are the) version note conventions, these seem like the actions to take:

- In 2.6 docs, add processName, and insert the note ?Changed in version 2.6: processName was added?

- In 2.7 docs, insert that same note

- In docs for 3.1 and up, insert the note ?Changed in version 3.1: processName was added?

----------
assignee: docs at python
components: Documentation
messages: 165852
nosy: docs at python, gthb
priority: normal
severity: normal
status: open
title: processName key is un-/mis-documented in 2.6 and up
type: enhancement
versions: Python 2.6, 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/issue15399>
_______________________________________

From report at bugs.python.org  Thu Jul 19 21:19:59 2012
From: report at bugs.python.org (R. David Murray)
Date: Thu, 19 Jul 2012 19:19:59 +0000
Subject: [docs] [issue15399] processName key is un-/mis-documented in 2.6
	and up
In-Reply-To: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>
Message-ID: <1342725599.56.0.833053191652.issue15399@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

We only update the docs for the active versions, so only 2.7, 3.2, and default (3.3) are going to get updated.

----------
nosy: +r.david.murray, vinay.sajip
versions:  -Python 2.6, Python 3.1, Python 3.4

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

From report at bugs.python.org  Fri Jul 20 05:42:12 2012
From: report at bugs.python.org (Meador Inge)
Date: Fri, 20 Jul 2012 03:42:12 +0000
Subject: [docs] [issue14201] Documented caching for shared library's
	__getattr__ and	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1342755731.67.0.291058234225.issue14201@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

The general wording and example look good;  thanks.  I reworded things a little.  Updated patch attached.

----------
stage: needs patch -> commit review
Added file: http://bugs.python.org/file26443/issue14201-v2.patch

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

From report at bugs.python.org  Fri Jul 20 10:51:37 2012
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 Jul 2012 08:51:37 +0000
Subject: [docs] [issue15399] processName key is un-/mis-documented in 2.6
	and up
In-Reply-To: <1342723251.3.0.517934021782.issue15399@psf.upfronthosting.co.za>
Message-ID: <3Wdm6Z3sshzMjJ@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 204be25f24bd by Vinay Sajip in branch '2.7':
Issue #15399: Added versionchanged for processName.
http://hg.python.org/cpython/rev/204be25f24bd

New changeset 6b771075cfa3 by Vinay Sajip in branch '3.2':
Issue #15399: Added versionchanged for processName.
http://hg.python.org/cpython/rev/6b771075cfa3

New changeset 4b5e8f7d1ac4 by Vinay Sajip in branch 'default':
Closes #15399: merged documentation fix from 3.2.
http://hg.python.org/cpython/rev/4b5e8f7d1ac4

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

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

From report at bugs.python.org  Fri Jul 20 19:06:22 2012
From: report at bugs.python.org (Chris Rebert)
Date: Fri, 20 Jul 2012 17:06:22 +0000
Subject: [docs] [issue14674] Link to & explain deviations from RFC 4627 in
	json	module docs
In-Reply-To: <1335449712.62.0.988063979534.issue14674@psf.upfronthosting.co.za>
Message-ID: <1342803981.95.0.852280150121.issue14674@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

Pinging on this, since it's been just short of a month since ?ric's "last call" comment.

----------

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

From report at bugs.python.org  Fri Jul 20 19:50:49 2012
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 20 Jul 2012 17:50:49 +0000
Subject: [docs] [issue15292] import hook behavior documentation improvement
In-Reply-To: <1341743900.84.0.0628684352519.issue15292@psf.upfronthosting.co.za>
Message-ID: <1342806649.51.0.941785228018.issue15292@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

So I can't reproduce the problem under Python 2.7.3, Python 3.2.3, or a fresh checkout of Python 3.3. This is with both your script, Anders, and writing my own class that defined find_module() to just raise ImportError that I set in either sys.meta_path or in sys.path_importer_cache (both ways let the ImportError propagate).

This means I'm not sure exactly what problem you are encountering. Is this on an older version of Python 2.7? Do you have a unit test that can be run  which shows the test failing under Python 2.7 but passing under Python 3.3?

----------
status: open -> pending

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

From report at bugs.python.org  Sat Jul 21 00:37:53 2012
From: report at bugs.python.org (Davide Rizzo)
Date: Fri, 20 Jul 2012 22:37:53 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342823873.36.0.576466728664.issue15360@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

Amaury, I don't honestly know, I would have proposed something otherwise.

I have been advised on #python (Freenode) not to assign to obj.__dict__ because its behaviour changes between versions and implementations, but I wouldn't know what has changed between CPython version.

One obscure thing is what can be assigned to __dict__. For class dicts no assignment is allowed. Object dicts can be assigned dict objects. If you try to assign a non-dict mapping it will complain.

However you can assign a dict-derived object, something like:

class SillyDict(dict):
    def __getitem__(self, key):
        return "hello"

obj.__dict__ = SillyDict()

Unfortunately accessing the attributes of obj will still use PyDict_* functions, thus ignoring any magic methods.

PyPy's behavior is slightly different. A class __dict__ attribute still is read only, but you can assign any mapping object to an object __dict__.

----------

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

From report at bugs.python.org  Sat Jul 21 06:48:10 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 04:48:10 +0000
Subject: [docs] [issue15063] Source code links for JSON documentation
In-Reply-To: <1339648255.05.0.789234331886.issue15063@psf.upfronthosting.co.za>
Message-ID: <1342846090.1.0.570482968709.issue15063@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I am with ?ric on this. Looking at json/decoder.py and json/encoder.py, I too feel that source link may not be helpful as much as it is helpful for others. Docs are best here. I am closing this report. Thanks!

----------
nosy: +orsenthil
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Sat Jul 21 11:41:58 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 21 Jul 2012 09:41:58 +0000
Subject: [docs] [issue15412] Note in documentation for weakrefs
Message-ID: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>


New submission from Richard Oudkerk <shibturn at gmail.com>:

In the documentation on weakrefs there is the following quote

    Note: Weak references to an object are cleared before the object?s
    __del__() is called, to ensure that the weak reference callback 
    (if any) finds the object still alive.

But I think the weakref is always dead by the time the callback is invoked.  The first paragraph from the documentation for weakref.ref(object[, callback]) contains the following:

    If callback is provided and not None, and the returned weakref 
    object is still alive, the callback will be called when the object 
    is about to be finalized; the weak reference object will be passed 
    as the only parameter to the callback; **the referent will no longer 
    be available**.

Which does prompt a question: what use is there for the weakref argument to the callback if it already dead?

(Compare http://bugs.python.org/issue14933)

----------
assignee: docs at python
components: Documentation
messages: 166002
nosy: docs at python, pitrou, sbt
priority: normal
severity: normal
status: open
title: Note in documentation for weakrefs

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

From report at bugs.python.org  Sat Jul 21 12:23:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:23:53 +0000
Subject: [docs] [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342866122.3492.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In the documentation on weakrefs there is the following quote
> 
>     Note: Weak references to an object are cleared before the object?s
>     __del__() is called, to ensure that the weak reference callback 
>     (if any) finds the object still alive.
> 
> But I think the weakref is always dead by the time the callback is
> invoked.

It's true, the doc needs fixing.

> Which does prompt a question: what use is there for the weakref
> argument to the callback if it already dead?

The weakref is "dead" but it's still a weakref, and it can be used to
e.g. index a container of existing weakrefs (cf. WeakSet,
WeakKeyDictionary, WeakValueDictionary).

----------

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

From report at bugs.python.org  Sat Jul 21 12:58:22 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sat, 21 Jul 2012 10:58:22 +0000
Subject: [docs] [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342863718.26.0.49587627068.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342868302.42.0.824683171539.issue15412@psf.upfronthosting.co.za>


Richard Oudkerk <shibturn at gmail.com> added the comment:

> The weakref is "dead" but it's still a weakref, and it can be used to
> e.g. index a container of existing weakrefs (cf. WeakSet,
> WeakKeyDictionary, WeakValueDictionary).

Ah.

I had assumed that since dead weakrefs were unhashable you couldn't safely use them as keys in a dict.  (Presumably removal of a no longer hashable key from a dict is O(n)?)

I also hadn't realize that weakrefs were subclassable.

----------

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

From report at bugs.python.org  Sat Jul 21 12:59:29 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 21 Jul 2012 10:59:29 +0000
Subject: [docs] [issue15412] Note in documentation for weakrefs
In-Reply-To: <1342868302.42.0.824683171539.issue15412@psf.upfronthosting.co.za>
Message-ID: <1342868258.3492.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I had assumed that since dead weakrefs were unhashable you couldn't
> safely use them as keys in a dict.  (Presumably removal of a no longer
> hashable key from a dict is O(n)?)

They are unhashable if you didn't hash them alive. Otherwise they retain
their old hash value (which is quite useful :-)).

----------

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

From report at bugs.python.org  Sat Jul 21 16:27:57 2012
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 21 Jul 2012 14:27:57 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1342880877.86.0.169053037316.issue15151@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Docs issues won't block b2.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Sat Jul 21 17:23:38 2012
From: report at bugs.python.org (Florent Xicluna)
Date: Sat, 21 Jul 2012 15:23:38 +0000
Subject: [docs] [issue9708] cElementTree iterparse does not support "parser"
	argument
In-Reply-To: <1283032296.54.0.54816594665.issue9708@psf.upfronthosting.co.za>
Message-ID: <1342884218.13.0.202539845237.issue9708@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Either the documentation or the implementation should be fixed in 3.3, because they do not match.

----------
nosy: +eli.bendersky
versions: +Python 3.3

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

From report at bugs.python.org  Sat Jul 21 22:09:07 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sat, 21 Jul 2012 20:09:07 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342901347.16.0.170584163884.issue14489@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at bugs.python.dobrogost.net> added the comment:

As of today the link is still not fixed although I guess it should have been due to the patch mentioned in http://bugs.python.org/issue14489#msg157543

----------
nosy: +piotr.dobrogost

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

From report at bugs.python.org  Sat Jul 21 22:13:23 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 20:13:23 +0000
Subject: [docs] [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <1342901603.06.0.70901290226.issue14391@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The patch supplied was in reverse, but the bug report was correct. You can't pass "type=string" since there's no string callable, only a str callable.

The docstring is confusing because the quotes make it looks like we mean the string 'str', when we actually mean the callable 'str'. Maybe they should be `str` or ``str``? Not sure what the syntax for code, not string literals, is for docstrings.

Anyway, this should be an easy fix for a doc person.

----------
keywords: +easy
resolution: out of date -> 
status: closed -> open

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

From report at bugs.python.org  Sat Jul 21 22:41:08 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 20:41:08 +0000
Subject: [docs] [issue15414] os.path.join behavior on Windows (ntpath.join)
	is	unexpected and not well documented
Message-ID: <1342903268.21.0.193498975528.issue15414@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

In looking at another os.path.join documentation issue I tried the Windows join to see if it matched the docs, and found that it was very unclear.   I searched the tracker and found Issue 1669539, which contains much relevant discussion but also much discussion of possible enhancements.  So I'm opening a new issue *just* about what I see as the current bugs in the os.path.join docs and ntpath.join implementation.

I'm not qualified to fix this, not being a Windows user, but it is clear to me that the documentation of os.path.join for Windows is unclear (it does not indicate what is considered an absolute path on Windows) and wrong (\foo will *not* restart the path if it is the second element and follows a drive specification, but it does any other time), and that the current behavior may have a bug if, as seems to be implied by the issue 1669539 discussion, something that looks like a drive specification in the middle of a path is invalid on Windows.  If this last is not a bug, it should be mentioned in the documentation, since the actual behavior is counter-intuitive.

----------
assignee: docs at python
components: Documentation, Windows
keywords: easy
messages: 166065
nosy: brian.curtin, christian.heimes, docs at python, eckhardt, ezio.melotti, jorend, mhammond, r.david.murray, terry.reedy, tim.golden
priority: normal
severity: normal
status: open
title: os.path.join behavior on Windows (ntpath.join) is unexpected and not well documented
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 21 23:07:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 Jul 2012 21:07:04 +0000
Subject: [docs] [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <3WfhNl2fwpzPQm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset e7f205ce080e by R David Murray in branch '3.2':
#14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/e7f205ce080e

New changeset 3d1ea33611c1 by R David Murray in branch 'default':
Merge #14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/3d1ea33611c1

New changeset 905d9bdae970 by R David Murray in branch '2.7':
#14391: clarify docstring discussion of Action's 'type' argument's value.
http://hg.python.org/cpython/rev/905d9bdae970

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

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

From report at bugs.python.org  Sat Jul 21 23:08:41 2012
From: report at bugs.python.org (R. David Murray)
Date: Sat, 21 Jul 2012 21:08:41 +0000
Subject: [docs] [issue14391] misc TYPO in argparse.Action docstring
In-Reply-To: <1332483933.58.0.148840583117.issue14391@psf.upfronthosting.co.za>
Message-ID: <1342904921.75.0.192247468758.issue14391@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I reworded it so that it is clear we are talking about types and not strings.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sat Jul 21 23:59:41 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 21 Jul 2012 21:59:41 +0000
Subject: [docs] [issue11807] Documentation of add_subparsers lacks
	information about	parametres
In-Reply-To: <1302340872.99.0.0231583237732.issue11807@psf.upfronthosting.co.za>
Message-ID: <1342907981.36.0.69313135077.issue11807@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks good. There was one typo in "parametres" that I've fixed. Should be ready to apply.

----------
Added file: http://bugs.python.org/file26469/11807_3.patch

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

From report at bugs.python.org  Sun Jul 22 00:09:29 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 22:09:29 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1342908569.81.0.0960236701232.issue15269@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Given that we have self.left_list and self.left_only ( and self.right_list and self.right_only), I am not sure how adding self.left/self.right is going to add more meaning? It would simply point to the dir1 and dir2 arguments that are being passed. 

Also, it may not be a helpful feature. If it is a must, then we can just rename self.left to self._left within the *code*, but otherwise, I do not see any change which is required here.  I suggest closing this report as wont-fix.

----------
nosy: +orsenthil

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

From report at bugs.python.org  Sun Jul 22 01:11:37 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 21 Jul 2012 23:11:37 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1342912297.29.0.610297250273.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

> Given that we have self.left_list and self.left_only ( and self.right_list and self.right_only), I am not sure how adding self.left/self.right is going to add more meaning?

It adds more meaning because you can't construct self.left and self.right from self.left_list, self.left_only, etc.  The latter are children inside the two directories (expressed relatively), while the former are the parent directories.  So it's strictly different information.

As I said, there are cases where being able to access the left and right directories simplifies the calling code in a way that is not otherwise possible.

For example, if you are recursively comparing directories, it is natural to recurse on the dircmp.subdirs attribute, whose values are dircmp instances.  The caller did not construct these instances, so there is no other way to obtain the left and right directories that were used to construct those instances.  Otherwise, the caller has to construct the dircmp instances manually from common_dirs, which reduces the usefulness of the subdirs attribute and the scenarios in which it can be used.

Secondly, there are cases where it is natural to pass dircmp instances around between functions.  If one cannot recover the left and right directories from the dircmp instances, then one would also have to pass the left and right directories to those functions, along with the dircmp instances, or else pass just the left and right directories and then reconstruct the dircmp instances from those arguments, which leads to uglier code.

Thirdly, it is better to reuse existing dircmp instances where possible rather than create new ones, because of the penalty after creating a new instance of needing to recalculate the attributes.  As the documentation notes, attributes are computed lazily and cached using __getattr__(), so it's better to hold onto existing instances.

If you are still not convinced, I would like the opportunity to provide actual code examples before you close this issue.  Then you can tell me if there is an equally simple alternative that does not involve accessing left and right.

I don't see how it hurts to be able to access left and right as attributes and why you would consider concealing this information from the caller behind private attributes.  It's a common idiom for constructor arguments to be stored as public attributes.

In this case, I think it's worth documenting because the names of the attributes ("left" and "right") used to store the constructor arguments don't match the names of the constructor arguments themselves ("a" and "b").

----------

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

From report at bugs.python.org  Sun Jul 22 01:41:39 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 21 Jul 2012 23:41:39 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1342914099.23.0.908269871636.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for this report. I saw that filecmp.rst could be improved a bit further too. I added some additional improvements to the docs in addition to the one you mentioned in the patch.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil
Added file: http://bugs.python.org/file26473/Issue15250.patch

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

From report at bugs.python.org  Sun Jul 22 02:14:00 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 22 Jul 2012 00:14:00 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1342916033.24.0.772134315457.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

For attribution purposes and to keep the issue focused, shouldn't those other changes be added as part of a separate issue?

The changes you added are much larger than mine, and address cosmetic issues and other issues unrelated to the original point about dircmp comparisons being "shallow".

----------

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

From report at bugs.python.org  Sun Jul 22 04:30:15 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 22 Jul 2012 02:30:15 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1342916033.24.0.772134315457.issue15250@psf.upfronthosting.co.za>
Message-ID: <CAPOVWOT1WhoKWg67_zk4p4UwA8oB8S8KxdBDX+ktL8_a1Q3fmg@mail.gmail.com>


Senthil Kumaran <senthil at uthcode.com> added the comment:

If by attribution, if you mean, proper mention of credits/ acks, during the
commit, I shall add it. Also, I agree that "shallow" should be documented.
But there were few more places which were lacking, so I ended up with
expanding docs after reading the code. I can commit in two phases, if it is
desired or commit yours and then make the other  documentation
improvements. Thanks!

----------

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

From report at bugs.python.org  Sun Jul 22 04:46:35 2012
From: report at bugs.python.org (H Xu)
Date: Sun, 22 Jul 2012 02:46:35 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342925195.71.0.709085516608.issue14489@psf.upfronthosting.co.za>


H Xu <xuhdev at gmail.com> added the comment:

I think this has been fixed. Where did you see the incorrect link?

----------

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

From report at bugs.python.org  Sun Jul 22 10:14:27 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 08:14:27 +0000
Subject: [docs] [issue15418] 2to3 docs should mention setup.py fixes
	required to	install compatible packages in Python 3
Message-ID: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

http://docs.python.org/py3k/library/2to3.html

   should mention the practice of running 2to3 in setup.py for codebase compatible with both Python 2 and Python 3.

----------
assignee: docs at python
components: Documentation
messages: 166108
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: 2to3 docs should mention setup.py fixes required to install compatible packages in Python 3
versions: Python 3.1, Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 22 14:46:36 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 22 Jul 2012 12:46:36 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1342961196.21.0.315629760303.issue15041@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Add all recommended resources into seealso section.

If it's ok I will commit it next week.

----------
keywords: +patch
Added file: http://bugs.python.org/file26477/issue15041.diff

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

From report at bugs.python.org  Sun Jul 22 18:40:54 2012
From: report at bugs.python.org (Piotr Dobrogost)
Date: Sun, 22 Jul 2012 16:40:54 +0000
Subject: [docs] [issue14489] repr() function link on the built-in
	function	documentation is incorrect
In-Reply-To: <1333520679.63.0.90940412535.issue14489@psf.upfronthosting.co.za>
Message-ID: <1342975254.23.0.0180274356535.issue14489@psf.upfronthosting.co.za>


Piotr Dobrogost <pd at bugs.python.dobrogost.net> added the comment:

The wrong link is still at http://docs.python.org/library/functions.html

----------

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

From report at bugs.python.org  Sun Jul 22 18:53:12 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 16:53:12 +0000
Subject: [docs] [issue11776] types.MethodType() params and usage is not
	documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1342975991.9.0.0744509898832.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Still not documented..

----------

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

From report at bugs.python.org  Sun Jul 22 19:24:58 2012
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 22 Jul 2012 17:24:58 +0000
Subject: [docs] [issue11776] types.MethodType() params and usage is not
	documented
In-Reply-To: <1302036805.33.0.506634428921.issue11776@psf.upfronthosting.co.za>
Message-ID: <1342977898.54.0.708385873938.issue11776@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Another 4 complains about missing references: http://stackoverflow.com/questions/1015307/python-bind-an-unbound-method

----------

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

From report at bugs.python.org  Sun Jul 22 22:03:38 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 22 Jul 2012 20:03:38 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342987418.83.0.160803048229.issue15360@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Jul 23 00:12:34 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:12:34 +0000
Subject: [docs] [issue15427] Describe use of args parameter
	of	argparse.ArgumentParser.parse_args
Message-ID: <1342995154.12.0.902919829048.issue15427@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From http://bugs.python.org/issue14191#msg155202:

ArgumentParser.parse_args(args=None, namespace=None)
...
However, nowhere is the args= parameter explained.  One example is given at the end of 15.4.4.6 showing the use of args= which apparently accepts a list of parameters, similar to the positional list of parameters that are used in all the other examples.  It might be nice to clarify that.

----------
assignee: docs at python
components: Documentation
messages: 166174
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: Describe use of args parameter of argparse.ArgumentParser.parse_args
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 23 00:16:22 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 22:16:22 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1342995382.19.0.520849761123.issue14191@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I created Issue 15427 for the parse_args documentation bug. So let's make this issue just about parsing intermixed arguments.

Yes, if someone would like to provide a patch for this, please create a method "parse_intermixed_args" rather than adding a boolean flag parameter. It should be basically equivalent to this code:

args, remaining_args = optionals.parse_known_args()
args = positionals.parse_args(remaining_args, args)

Except that it should give proper error messages. There should be some tests to make sure both that it parses things as expected and that it gives error messages as expected.

----------
assignee: docs at python -> 
components:  -Documentation
title: argparse: nargs='*' doesn't get out-of-order positional parameters -> argparse doesn't allow optionals within positionals
versions: +Python 3.4 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 23 00:25:06 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 22 Jul 2012 22:25:06 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1342995906.13.0.793878656521.issue15360@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo

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

From report at bugs.python.org  Mon Jul 23 01:27:31 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:27:31 +0000
Subject: [docs] [issue15125] argparse: positional arguments containing - in
	name not	handled well
In-Reply-To: <1340292847.64.0.123942573403.issue15125@psf.upfronthosting.co.za>
Message-ID: <1342999650.95.0.202813867708.issue15125@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm sympathetic to the idea that '-' should be translated similarly for optional and positional arguments, but as you've noted, it would be a risky patch because it's already possible for people to use getattr on hyphenated arguments. So I think this isn't possible without a long deprecation process first.

> But patching the module to allow explicitly setting dest via keyword 
> argument shouldn't hurt anybody.

I agree that it wouldn't hurt anybody. If you can find a way to do this, feel free to provide a patch.

However, the correct way to have one name for the attribute (i.e. dest=) and one name for the help (i.e. metavar=) is to use the metavar argument like so:

    parser.add_argument('positional_args', metavar='positional-args')

That said, this is not the first time I've seen someone run into this problem. I think the documentation could be improved in a few ways:

(1) In the "name or flags" section, describe how the flags (for optional arguments) are translated into both a default "dest" (stripping initial '-' and converting '-' to '_') and into a default "metavar" (stripping initial '-' and uppercasing). Part of this is in the "dest" and "metavar" documentation, but probably belongs up in the "name or flags" documentation. Add cross-references to "dest" and "metavar" sections.

(2) In the "name or flags" section, describe how the name (for positional arguments) are translated into the same default "dest" and "metavar" (no string munging at all). Again, move stuff from the "dest" and "metavar" sections as necessary. Add cross-references to "dest" and "metavar" sections.

(3) In the "dest" section and somewhere in the "parse_args" section, describe how "getattr" can be used to get attributes whose names aren't valid Python identifiers. Maybe cross-reference this section from the edits in (2).

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

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

From report at bugs.python.org  Mon Jul 23 01:37:08 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:37:08 +0000
Subject: [docs] [issue11176] give more meaningful argument names in
	argparse	documentation
In-Reply-To: <1297352937.46.0.470038569364.issue11176@psf.upfronthosting.co.za>
Message-ID: <1343000227.99.0.258414035185.issue11176@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Thanks for working on this! I think keeping the first example as simple is possible is probably a good idea. And I didn't have time to read through the whole patch, but as far as I went, the pizza examples looked great.

----------

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

From report at bugs.python.org  Mon Jul 23 01:40:56 2012
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 22 Jul 2012 23:40:56 +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: <1343000456.85.0.247846194864.issue9694@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm changing the title because I keep seeing duplicates.

Documentation patches still welcome!

----------
title: argparse: Default Help Message Lists Required Args As Optional -> argparse required arguments displayed under "optional arguments"
versions: +Python 3.4

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

From report at bugs.python.org  Mon Jul 23 02:00:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 00:00:32 +0000
Subject: [docs] [issue15428] add "Name Collision" section to argparse docs
Message-ID: <1343001632.52.0.429837248023.issue15428@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

Several bugs (e.g. Issue 15327 and Issue 15271) have been filed suggesting that people aren't really clear on how argparse handles argument name collisions or how they can get it to do what they want.

I think these problems could probably be solved by a "Name Collision" section (or something like that) in the argparse documentation. It would give a few example problems and show how to resolve them. Some things to include:

* What happens when two arguments have the same dest (Issue 15271), with solutions including action='append' or different dest= values combined with identical metavar= values.

* What happens when a parser and a sub-parser share some of the same argument names (Issue 15327), with solutions including specifying different dest= values for the parser and sub-parser

* A brief mention and cross-reference to the "conflict_handler" section.

----------
assignee: docs at python
components: Documentation
messages: 166185
nosy: bethard, docs at python
priority: normal
severity: normal
status: open
title: add "Name Collision" section to argparse docs
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon Jul 23 02:19:35 2012
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 23 Jul 2012 00:19:35 +0000
Subject: [docs] [issue15429] types.NoneType missing
Message-ID: <1343002775.58.0.953858152557.issue15429@psf.upfronthosting.co.za>


Changes by Anders Kaseorg <andersk at mit.edu>:


----------
assignee: docs at python
components: Documentation
nosy: andersk, docs at python
priority: normal
severity: normal
status: open
title: types.NoneType missing
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Jul 23 02:20:37 2012
From: report at bugs.python.org (Anders Kaseorg)
Date: Mon, 23 Jul 2012 00:20:37 +0000
Subject: [docs] [issue15429] types.NoneType missing
Message-ID: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

http://docs.python.org/py3k/library/constants.html#None says that None is the sole value type types.NoneType.  However, NoneType was removed from the types module with Python 3.

----------

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

From report at bugs.python.org  Mon Jul 23 02:44:07 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 00:44:07 +0000
Subject: [docs] [issue15429] types.NoneType missing
In-Reply-To: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>
Message-ID: <3WgP8j33wHzPQ2@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 84b577567fab by R David Murray in branch '3.2':
#15429: Fix invalid mention of types.NoneType from None docs.
http://hg.python.org/cpython/rev/84b577567fab

New changeset c43d73277756 by R David Murray in branch 'default':
Merge #15429: Fix invalid mention of types.NoneType from None docs.
http://hg.python.org/cpython/rev/c43d73277756

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

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

From report at bugs.python.org  Mon Jul 23 02:45:04 2012
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 Jul 2012 00:45:04 +0000
Subject: [docs] [issue15429] types.NoneType missing
In-Reply-To: <1343002837.2.0.031540132971.issue15429@psf.upfronthosting.co.za>
Message-ID: <1343004304.61.0.0742429564644.issue15429@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the report.  Fixed.

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.3

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

From report at bugs.python.org  Mon Jul 23 02:55:52 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 00:55:52 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343004952.15.0.0443076336563.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks, Senthil.  I would prefer if you created a new issue in the tracker for your additional changes, and then committed your changes as part of that issue.  By attribution, I was referencing the "Patch by Chris Jerdonek" which can go in the commit message and Misc/NEWS for this issue.  I am already listed in Misc/ACKS.

To keep things simple, can you perhaps review my original patch as is?  If you would like, I would be happy to provide feedback separately on your own changes.

----------

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

From report at bugs.python.org  Mon Jul 23 03:49:24 2012
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 23 Jul 2012 01:49:24 +0000
Subject: [docs] [issue14191] argparse doesn't allow optionals within
	positionals
In-Reply-To: <1330843053.88.0.983162018395.issue14191@psf.upfronthosting.co.za>
Message-ID: <1343008164.93.0.221768726142.issue14191@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So my t18a.py wraps Argparse, because the externals are documented and I could understand that. Given enough time, I might be able to understand the internals too... it is just Python...

Seems like the internals separate positionals and optionals into two subparsers, the logic needed is to save the positionals, temporarily replace them with an empty group, and call parse_known_args, then restore the positionals, and call parse_known_args again.

What I haven't figured out, is how that would affect the help message building, and how to make the empty group of positionals without affecting the help message.

It's also not clear that it is possible, with current internals, to substitute an empty group... the only features for creating a group seem to always add it to a list of _action_groups.  So that muddies the water, just like the help message... everything seems intertwined internally.

A little guidance here, would let me code... I could probably whack and slash, and keep extra lists of arguments and sort of make it work like my wrapper does, but I doubt that would be an acceptable patch. So I would be happy, with guidance, to try to create the code, and I can do a "diff", but beyond that, I'm sort of at a loss.

So I'd be happy to work with someone to create the patch, but I've also never created a patch, nor test cases, for Python (or any other open source project). Theoretically, it is straightforward, and documented; as a practical matter, it isn't likely that I'll find time to figure out all that methodology and actually create a patch, in the near future (although it is on my list of things to learn, in the fullness of time, and after the first one, I'm sure subsequent ones would be easier).

Or if someone else wants to code it, I'd be happy to look it over, test it with my environment and applications that I'm currently using with my wrapper.

Given this guidance, I've tweaked my wrapper to have parse_intermixed_args rather than changing the behavior of parse_args as I have been, and will tweak the apps correspondingly, so I'll be in a position to test any code created for this issue.

----------

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

From report at bugs.python.org  Mon Jul 23 03:50:25 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 01:50:25 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343008225.58.0.946956005382.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Hi Chris, your patch looks good. I shall commit it now. The rest of the documentation changes can go in another patch. Thanks!

----------

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

From report at bugs.python.org  Mon Jul 23 04:33:38 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 02:33:38 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <3WgRb51Pq8zPCm@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset f6ce142c2fce by Senthil Kumaran in branch '3.2':
- Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/f6ce142c2fce

New changeset d2a49ee77b6f by Senthil Kumaran in branch 'default':
- Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/d2a49ee77b6f

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

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

From report at bugs.python.org  Mon Jul 23 04:36:58 2012
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 Jul 2012 02:36:58 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <3WgRfw5jZXzPKt@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset 3921d3c71e64 by Senthil Kumaran in branch '2.7':
Issue #15250: Document that filecmp.dircmp compares files shallowly. Patch contributed by Chris Jerdonek.
http://hg.python.org/cpython/rev/3921d3c71e64

----------

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

From report at bugs.python.org  Mon Jul 23 04:40:23 2012
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 23 Jul 2012 02:40:23 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343011223.3.0.934558749882.issue15250@psf.upfronthosting.co.za>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is taken care. Rest of documentation improvements could be dealt with in Issue15430. Thanks, Chris.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Jul 23 05:58:06 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 03:58:06 +0000
Subject: [docs] [issue15250] document that filecmp.dircmp comparisons are
	"shallow"
In-Reply-To: <1341412567.68.0.918159350909.issue15250@psf.upfronthosting.co.za>
Message-ID: <1343015885.97.0.52330063955.issue15250@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot for committing this for me Senthil.  And thanks also for creating a separate issue for the other changes.  I appreciate it.

----------

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

From report at bugs.python.org  Mon Jul 23 11:29:31 2012
From: report at bugs.python.org (Geir Ove Myhr)
Date: Mon, 23 Jul 2012 09:29:31 +0000
Subject: [docs] [issue15432] gzip.py: mtime argument only since python 2.7
Message-ID: <1343035771.6.0.0683574772688.issue15432@psf.upfronthosting.co.za>


New submission from Geir Ove Myhr <gomyhr at gmail.com>:

In the gzip documentation (http://docs.python.org/library/gzip.html) a note should be added that the mtime option was added in Python 2.7. 

The patch which adds the option (http://svn.python.org/view?view=revision&revision=68319) is not included in Python 2.6.5.

----------
assignee: docs at python
components: Documentation
messages: 166214
nosy: docs at python, gomyhr
priority: normal
severity: normal
status: open
title: gzip.py: mtime argument only since python 2.7
versions: Python 2.6

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

From report at bugs.python.org  Mon Jul 23 20:44:04 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 18:44:04 +0000
Subject: [docs] =?utf-8?b?W2lzc3VlOTE4Ml0gZG9jdW1lbnQg4oCcLS3igJ0gYXMgYSB3?=
 =?utf-8?q?ay_to_distinguish_option_w/_narg=3D=27+=27_from_positional_argu?=
 =?utf-8?q?ment_in_argparse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1343069044.46.0.343941001411.issue9182@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Ok, here's what I think needs to go into the documentation here:

(1) Add a separate section to the argparse docs about '--'. Give examples like the ones in this issue, and show how '--' can solve them

(2) Cross-reference the section on '--' from nargs='?', nargs='*', nargs='+' and the "Arguments containing -" sections (and any other places where people are likely to run into the need for '--').

All of these changes should be on Doc/library/argparse.rst - I don't think we want to change the code at the moment.

----------

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

From report at bugs.python.org  Mon Jul 23 21:15:32 2012
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 23 Jul 2012 19:15:32 +0000
Subject: [docs] [issue13249] argparse.ArgumentParser() lists arguments in
	the wrong	order
In-Reply-To: <1319394759.74.0.692830705102.issue13249@psf.upfronthosting.co.za>
Message-ID: <1343070932.2.0.819384158547.issue13249@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I've updated the patch for the current trunk. Should be ready to commit.

----------
Added file: http://bugs.python.org/file26490/Issue13249-4.patch

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

From report at bugs.python.org  Mon Jul 23 21:54:42 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jul 2012 19:54:42 +0000
Subject: [docs] [issue15436] __sizeof__ is not documeneted
Message-ID: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

__sizeof__ is not mentioned on page Doc/reference/datamodel.rst together with other special methods. There is no __sizeof__ in index.

----------
assignee: docs at python
components: Documentation
messages: 166245
nosy: docs at python, storchaka
priority: normal
severity: normal
status: open
title: __sizeof__ is not documeneted
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Mon Jul 23 21:57:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 Jul 2012 19:57:46 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343073466.19.0.0396482701286.issue15436@psf.upfronthosting.co.za>


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


----------
title: __sizeof__ is not documeneted -> __sizeof__ is not documented

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

From report at bugs.python.org  Mon Jul 23 22:07:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 20:07:34 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
Message-ID: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to merge the Doc/ACKS and Misc/ACKS files as discussed here:

http://mail.python.org/pipermail/python-dev/2012-July/121096.html

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166247
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: Merge Doc/ACKS and Misc/ACKS

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

From report at bugs.python.org  Mon Jul 23 22:32:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 23 Jul 2012 20:32:39 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343075559.71.0.591845961914.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I would be happy to prepare a patch.  I can upload a script to this issue that the committer can then run on the latest Misc/ACKS and Doc/ACKS.txt.

The script would preserve the ordering of Misc/ACKS.  It would iterate through the names in Doc/ACKS.txt and insert them in Misc/ACKS at the appropriate location.  Duplicates would not be inserted.

----------

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

From report at bugs.python.org  Mon Jul 23 22:41:37 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 23 Jul 2012 20:41:37 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343076097.07.0.198453769504.issue15437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Georg, do you think this is ok for all 3 branches?

----------
nosy: +georg.brandl, pitrou
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Jul 24 00:29:30 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 23 Jul 2012 22:29:30 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343082570.16.0.206887414404.issue15437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This was indeed proposed once or twice before; I can?t search my archive right now but I think I remember Georg saying that he was OK as long as the docs displayed Misc/ACKS.  This means checking the rst syntax of Misc/ACKS and using the right include directive.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Tue Jul 24 01:10:01 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 23:10:01 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343085001.32.0.00108272866133.issue15436@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could you possibly write a patch for 2.7, 3.2 and 3.3?

----------
nosy: +jcea

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

From report at bugs.python.org  Tue Jul 24 01:12:15 2012
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 23 Jul 2012 23:12:15 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343085135.61.0.203306377556.issue15437@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

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

From report at bugs.python.org  Tue Jul 24 01:15:00 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 23 Jul 2012 23:15:00 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343085300.2.0.638795931468.issue15437@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Jul 24 04:41:20 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 02:41:20 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343097680.48.0.876967009657.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attached is a script that seems to do the job (except for the rst formatting, which can be added later.  This was so that you can see by the diff what has changed).

In the process of doing this, I found that Jeff McNeil is far out of order in Misc/ACKS, and possibly also Hugo Lopes Tavares and Xavier de Gaye, depending on what alphabetization rules should be used.

The script contains logic to collect the non-ascii characters that appear in people's names, so that non-ascii characters can be approximated by ascii characters for ordering purposes (which seems to be how it is done now in some cases).

In a subsequent comment, I will attach a diff that results from running the script, so you can see what effect it has on Misc/ACKS.

----------
Added file: http://bugs.python.org/file26493/merge-acks.py

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

From report at bugs.python.org  Tue Jul 24 04:44:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 02:44:28 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS and Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343097867.07.0.798827342462.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching sample output of running the script.

----------
keywords: +patch
Added file: http://bugs.python.org/file26494/issue-15437-sample-output.patch

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

From report at bugs.python.org  Tue Jul 24 07:45:14 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 05:45:14 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343085001.32.0.00108272866133.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207240845.01012.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Could you possibly write a patch for 2.7, 3.2 and 3.3?

No, not for documentation.

----------

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

From report at bugs.python.org  Tue Jul 24 08:11:45 2012
From: report at bugs.python.org (Eric Snow)
Date: Tue, 24 Jul 2012 06:11:45 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343110305.21.0.184893226326.issue15436@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

is __sizeof__ part of the language or just an implementation detail?

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

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

From report at bugs.python.org  Tue Jul 24 08:58:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 06:58:46 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343110305.21.0.184893226326.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207240958.30230.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

See issue2898.

----------

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

From report at bugs.python.org  Tue Jul 24 13:51:40 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 11:51:40 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
Message-ID: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to include the names in Misc/ACKS into the documentation --
in place of the names from Doc/ACKS.txt.  This was mentioned in the
discussion for issue 15437, which is to add the names from Doc/ACKS.txt
into Misc/ACKS.

This issue should be done shortly after issue 15437.  The current issue
can include (1) converting Misc/ACKS into rst format, (2) deleting
DOC/ACKS.txt (after confirming that any changes since issue 15437 are
reflected in Misc/ACKS), and (3) resolving the intros in the two files
with about.rst's surrounding text so that the text makes sense when
included into the main documentation.

Should Guido's note of acknowledgment in Misc/ACKS be included as is?
And should a new "Python Acknowledgments" section be added to the docs,
or is it okay for this more general acknowledgment to be included in the
section called "About these documents"?  If the former, the "About these
documents" section could link to the more general "Python
Acknowledgments" section to reference documentation contributors.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166279
nosy: cjerdonek, docs at python, eric.araujo, ezio.melotti, georg.brandl, jcea, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Include Misc/ACKS names into the documentation

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

From report at bugs.python.org  Tue Jul 24 13:53:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 11:53:26 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343130806.91.0.940845115521.issue15439@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


----------
dependencies: +Merge Doc/ACKS and Misc/ACKS

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

From report at bugs.python.org  Tue Jul 24 13:58:25 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 11:58:25 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343131105.37.0.711152230421.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. Misc/ACKS is fine where it is. No need to include it into the docs.

----------
nosy: +loewis

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

From report at bugs.python.org  Tue Jul 24 14:01:34 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 12:01:34 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343131294.59.0.459638466935.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created a new issue 15439 for including the combined Misc/ACKS into the documentation (as ?ric mentioned) because the nature of that discussion is different, and because the changes will be easier to observe and understand if committed separately.

----------
title: Merge Doc/ACKS and Misc/ACKS -> Merge Doc/ACKS.txt names into Misc/ACKS

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

From report at bugs.python.org  Tue Jul 24 14:10:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 12:10:36 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343131836.16.0.768896870389.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Martin, just to be sure, this is to be done after issue 15437 (a dependency), and the location of Misc/ACKS will not change.  Have you already read the discussion there?  ?ric said that he recalled it was Georg's preference to do this if Doc/ACKS.txt is removed.  (I personally have no opinion.)

----------

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

From report at bugs.python.org  Tue Jul 24 15:45:36 2012
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 Jul 2012 13:45:36 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343137536.53.0.956304009397.issue15437@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not clear if your script is trying to do this, but there is no way to automatically alphabetize the file.  That's why it says "rough" alphabetic order.  The issue is that different languages alphabetize different letters in different places.  We try to respect the alphabetization of the source language as much as practical...which means there is no algorithm that can do the sorting, since the names in the file do not carry explicit language information.

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

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

From report at bugs.python.org  Tue Jul 24 16:02:59 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 14:02:59 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343138579.64.0.956134166036.issue15437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, the script output looks good (apart from a few duplicates which can be resolved by hand, e.g. "Terry Reedy" vs. "Terry J. Reedy").

----------

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

From report at bugs.python.org  Tue Jul 24 16:15:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 14:15:04 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139303.92.0.980855901028.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I did think through those issues and made a special effort to address them in the script.

For starters, the script does not change the order of any names in Misc/ACKS.  This is to preserve the existing rough alphabetical ordering, and to ensure that the diff consists only of insertions (for easier manual checking, if desired).

As for inserting new names in rough alphabetical order, I dealt with different language characters as follows.  The script has a translation table to map non-ascii characters to ascii characters for sorting purposes.  Currently, that table is as follows (I'm not sure if all of these characters will render on the page):

NON_ASCII = "?????????????????????????????????????"
ASCII_SUB = 'AEOaaaaceeinooouuuceLnZKMCabrekhopw""'

This mapping can easily be modified if my initial choices are not the best.  As an early step, the script collects all non-ascii characters that appear in all names to make sure the translation table is up to date (exiting with a message otherwise).

When I said "Jeff McNeil" is out of order, that was because the name appears after "Jeff Epler" but before "Tom Epperly".  The script maintains a list of "out of order" names like this to skip when inserting, to prevent insertions from being out of rough alphabetical order.

If different languages use a different ordering on the word level, the script will not handle that, however.  It only orders lexicographically by last name, and then first name(s).

Much of this information is spelled out in the script's docstring.

----------

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

From report at bugs.python.org  Tue Jul 24 16:20:12 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 14:20:12 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139612.58.0.291575986021.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

That is correct, Antoine.  Duplicates need to be removed by hand.

To assist in this process, the script currently prints "possible duplicates" to stdout after running.  However, the script could easily be modified to display an in-line indicator before possible duplicates to make this manual step easier, e.g.:

 John Redford
 Terry Reedy
+>>> Terry J. Reedy
 Gareth Rees

Currently, possible duplicates are determined based on whether the last name matches an already existing last name.

----------

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

From report at bugs.python.org  Tue Jul 24 16:22:36 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 14:22:36 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343139612.58.0.291575986021.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343139634.3405.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> To assist in this process, the script currently prints "possible
> duplicates" to stdout after running.  However, the script could easily
> be modified to display an in-line indicator before possible duplicates
> to make this manual step easier, e.g.:
> 
>  John Redford
>  Terry Reedy
> +>>> Terry J. Reedy
>  Gareth Rees

Well, no need to be perfectionist IMO. The merging will only be done
once (thrice if we count all branches :-)).

----------

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

From report at bugs.python.org  Tue Jul 24 17:57:08 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 24 Jul 2012 15:57:08 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343145428.7.0.113979906455.issue15436@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

It is part of runtime services and is mentioned in the documentation for 'sys.getsizeof' [1]:

"""
getsizeof() calls the object?s __sizeof__ method and adds an additional garbage collector overhead if the object is managed by the garbage collector.
"""

[1] http://docs.python.org/library/sys.html?highlight=__sizeof__#sys.getsizeof.

----------
nosy: +meador.inge

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

From report at bugs.python.org  Tue Jul 24 18:29:30 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:29:30 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343147370.13.0.742288318542.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Yes, code samples would help clarifying the rationale for this request

----------
nosy: +eli.bendersky
versions: +Python 3.4 -Python 3.3

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

From report at bugs.python.org  Tue Jul 24 18:34:34 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 16:34:34 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343147674.25.0.288143843473.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

The patch looks reasonable to me. Martin/?ric - any objections to committing?

----------
nosy: +eli.bendersky

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

From report at bugs.python.org  Tue Jul 24 18:40:29 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 16:40:29 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343148029.04.0.44484664849.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

LGTM

----------

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

From report at bugs.python.org  Tue Jul 24 18:51:45 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 16:51:45 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343145428.7.0.113979906455.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207241951.27040.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> It is part of runtime services and is mentioned in the documentation for
> 'sys.getsizeof' [1]:

Yes, but it is not mentioned in the index.

----------

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

From report at bugs.python.org  Tue Jul 24 19:01:50 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 24 Jul 2012 17:01:50 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343149310.22.0.972789099338.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Committed in f315cfa22630

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Jul 24 19:12:43 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 17:12:43 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343149963.06.0.697377578737.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot, Eli.

----------

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

From report at bugs.python.org  Tue Jul 24 19:31:56 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 24 Jul 2012 17:31:56 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343151116.75.0.349241222764.issue15231@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me there are missing words in the text, and it needs porting to the packaging docs.

Proposal: [...] being able to run the command above without warnings is not sufficient to be sure that PyPI will convert the content successfully.

----------
components: +Distutils, Distutils2
nosy: +alexis, tarek
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open
versions: +Python 2.7, Python 3.2, Python 3.4

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

From report at bugs.python.org  Tue Jul 24 21:03:45 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:03:45 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343156625.66.0.030974871637.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, please rephrase: what do you mean by "inlude ... into ..."? If the place of Misc/ACKS doesn't change, in what way is it being included into something? And which "documentation" is it being included into, if it doesn't change its location?

----------

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

From report at bugs.python.org  Tue Jul 24 21:09:42 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:09:42 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343156981.95.0.122054944674.issue15437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Also, if you want to do phonetic translation of non-ASCII, then ???????? really matches abgeknor, and ? is transliterated to "sh" in English (IIUC) (to "sch" in German).

But I agree that this is best done manually. What matters is what the script produces; the script certainly won't make it into Python's source code. I'm sure Chris had fun writing it.

----------
keywords:  -easy
nosy: +loewis

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

From report at bugs.python.org  Tue Jul 24 21:21:11 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 19:21:11 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343157671.71.0.0891944018464.issue15439@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> Ok, please rephrase: what do you mean by "inlude ... into ..."?

http://docs.python.org/about.html#contributors-to-the-python-documentation

----------
nosy: +storchaka

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

From report at bugs.python.org  Tue Jul 24 21:29:09 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:29:09 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343158149.85.0.57534628587.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see; I'm changing my vote to -0 then. I don't think this list of names should have been included in the documentation in the first place. Since it is, providing the full list of contributors is just as fine.

----------

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

From report at bugs.python.org  Tue Jul 24 21:37:26 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 19:37:26 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343158646.72.0.402261213753.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The second sense of the word "include" is in the possible implementation.  ?ric pointed out in the other issue's thread that this can be achieved by modifying the existing include directive, for example--

--- a/Doc/about.rst
+++ b/Doc/about.rst
@@ -30,7 +30,7 @@
 documentation, or Python itself.
 
 .. including the ACKS file here so that it can be maintained separately
-.. include:: ACKS.txt
+.. include:: ../Misc/ACKS

The details of the surrounding text still need to be worked out though so that it reads right.

----------

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

From report at bugs.python.org  Tue Jul 24 21:48:48 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 19:48:48 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343159328.09.0.702520129395.issue15437@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Yes, I did. Even though it is throw-away.

By the way, I'm taking Antoine's advice to avoid perfectionism on this. Otherwise I'd include your suggestion re: the special characters. :)

----------

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

From report at bugs.python.org  Tue Jul 24 21:57:19 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 24 Jul 2012 19:57:19 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343159839.05.0.368454901313.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think Guido's wording should be included literally in the online version. It very much explains what this list really is and how to interpret it. The post scriptum should be converted into a ReST comment, since it is primarily a note to maintainers.

----------

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

From report at bugs.python.org  Tue Jul 24 22:25:12 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 Jul 2012 20:25:12 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
Message-ID: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka at gmail.com>:

Some contributor's names written incorrectly (in ASCII) in documentation:

Jes?s Cea Avi?n as Jes?s Cea Avion
Lars Gust?bel as Lars Gustaebel
Gerhard H?ring as Gerhard Haering
Marc-Andr? Lemburg as Marc-Andre Lemburg
Martin von L?wis as Martin von Loewis
Charles-Fran?ois Natali as Charles-Francois Natali
?iga Seilnach as Ziga Seilnacht

The proposed patch restores natural spelling (based on Doc/ACKS and Misc/ACKS).

I'm not sure about how to write right: ?iga Seilnach or Seilnacht?

----------
assignee: docs at python
components: Documentation
files: doc-nonascii-names.patch
keywords: patch
messages: 166330
nosy: docs at python, ghaering, jcea, lars.gustaebel, lemburg, loewis, neologix, storchaka, zseil
priority: normal
severity: normal
status: open
title: Incorrectly writen contributor's names
Added file: http://bugs.python.org/file26504/doc-nonascii-names.patch

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

From report at bugs.python.org  Tue Jul 24 22:27:53 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 24 Jul 2012 20:27:53 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343161673.19.0.0655960084087.issue15444@psf.upfronthosting.co.za>


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


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Wed Jul 25 01:21:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 23:21:23 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343172082.97.0.327273299728.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks for taking the time to look at this, Eli.

In response to your question, here is one illustrated rationale.

When recursing through a directory using dircmp, it is simplest and cleanest to be able to recurse on the subdirs attribute without having to pass pairs of paths around or reconstruct dircmp instances.  You can see this for example in filecmp's own very concise implementation of dircmp.report_full_closure():

    def report_full_closure(self): # Report on self and subdirs recursively
        self.report()
        for sd in self.subdirs.values():
            print()
            sd.report_full_closure()

However, dircmp's reporting functionality is self-admittedly "lousy":

    def report(self): # Print a report on the differences between a and b
        # Output format is purposely lousy
        print('diff', self.left, self.right)
        ...

(Incidentally, observe above that dircmp.report() itself uses the 'left' and 'right' attributes.)

Given the limitations of report_full_closure(), etc, it is natural that one might want to write a custom or replacement reporting function with nicer formatting.  When doing this, it would be nice to be able to follow that same clean and concise recursion pattern.  For example--

    def diff(dcmp):
        for sd in dcmp.subdirs.values():
            diff(sd)
        for name in dcmp.diff_files:
            print("%s differs in %s and %s" % (name, dcmp.left, dcmp.right))

    dcmp = dircmp('dir1', 'dir2')
    diff(dcmp)

If one isn't able to access 'left' and 'right' (or if one simply isn't aware of those attributes, which was the case for me at one point), the alternative would be to do something like the following, which is much uglier and less DRY:

    import os

    def diff2(dcmp, dir1, dir2):
        for name, sd in dcmp.subdirs.items():
            subdir1 = os.path.join(dir1, name)
            subdir2 = os.path.join(dir2, name)
            diff2(sd, subdir1, subdir2)
        for name in dcmp.diff_files:
            print("%s differs in %s and %s" % (name, dir1, dir2))

    dcmp = dircmp('dir1', 'dir2')
    diff2(dcmp, dir1='dir1', dir2='dir2')

An example like diff() above might even be worth including in the docs as an example of how subdirs can be used to avoid having to manually call os.path.join(...), etc.

There are also non-recursive situations in which being able to access dircmp.left and dircmp.right makes for cleaner code.

----------

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

From report at bugs.python.org  Wed Jul 25 01:34:51 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 Jul 2012 23:34:51 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343172891.74.0.00861586434788.issue15439@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I agree with Martin and don't think the ACKS list should be exposed further than it already is.

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

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

From report at bugs.python.org  Wed Jul 25 01:40:23 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 24 Jul 2012 23:40:23 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343173223.03.0.373576202784.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

It seems to be the latter: ?iga Seilnacht

http://mail.python.org/pipermail/python-dev/2007-March/071786.html

----------
nosy: +cjerdonek

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

From report at bugs.python.org  Wed Jul 25 02:18:39 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 00:18:39 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343175519.35.0.885325411565.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Is that a -0 then, Raymond?

I think either the combined Misc/ACKS list should be included in the docs, or it should be removed entirely.  If what Meador said is true (that people already in Misc/ACKS who contribute documentation should not be added)--

> Doc/ACKS.txt is *only* for acknowledging documentation contributions.  Serhiy is already in Misc/ACKS.  No need to add him to Doc/ACKS.txt.

http://mail.python.org/pipermail/python-dev/2012-July/121093.html

Then it's not clear to me why the current docs list is meaningful and what exactly it represents.  At the least, the description of the list on the page doesn't match the stated practice.

----------

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

From report at bugs.python.org  Wed Jul 25 03:56:17 2012
From: report at bugs.python.org (Meador Inge)
Date: Wed, 25 Jul 2012 01:56:17 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343181377.51.0.744082359618.issue15439@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

What I meant by that was that Serhiy contributed a code change and was already in Misc/ACKS, therefore no ACKS file should have been updated.  I didn't mean to imply that someone can't be in both files.  My impression is that Misc/ACKS is for code contributions and Docs/ACKS.txt is for documentation contributions.

----------
nosy: +meador.inge

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

From report at bugs.python.org  Wed Jul 25 04:34:10 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Wed, 25 Jul 2012 02:34:10 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343183650.86.0.183967844083.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Makes sense. I agree that publicly exposing the left/right attributes makes sense. But let's do it properly:

1. Add an example to the documentation
2. Add some tests to Lib/test/test_filecmp.py that verify these attributes behave as expected

In addition, I think it makes a lot of sense to add an optional "stream" argument to the report() and report_*() methods, to at leas allow reporting to some custom channel and not solely stdout. The report() method does a lot more than your simple example demonstrates, and it's not very easy to replace its functionality.

Would you like to submit a full patch for this?

----------

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

From report at bugs.python.org  Wed Jul 25 06:52:21 2012
From: report at bugs.python.org (Eric Snow)
Date: Wed, 25 Jul 2012 04:52:21 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343191941.32.0.349320923884.issue15436@psf.upfronthosting.co.za>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

issue2898 smells like an implementation detail to me. Also, sys.getsizeof() isn't necessarily authoritative here, since the sys module is full of all sorts of implementation details.

I'm not saying __sizeof__ shouldn't be made an official part of the language, but we should be careful before we effectively etch something in stone for all Python implementations.  It may be worth getting feedback from python-dev, particularly from the major Python implementers.

----------

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

From report at bugs.python.org  Wed Jul 25 07:58:18 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 05:58:18 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343195898.84.0.889400296668.issue15439@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Okay, thanks for clarifying.  Then I have no strong opinion.

However, if Doc/ACKS.txt is retained, then I think the Dev Guide should mention Doc/ACKS.txt just as it mentions Misc/ACKS:

http://docs.python.org/devguide/patch.html#preparation

And it should include instructions for when to update which files, and the patchcheck script should be suitably modified.  With only ~230 names versus Misc/ACKS's ~1160 , I'm surprised that Doc/ACKS.txt does not have more names -- especially given that it's not uncommon for documentation changes to accompany code changes (or so one might think).

----------

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

From report at bugs.python.org  Wed Jul 25 08:18:02 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 06:18:02 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343197081.96.0.0412258021097.issue15444@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

> It seems to be the latter: ?iga Seilnacht

Then Misc/ACKS should be corrected too.

----------

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

From report at bugs.python.org  Wed Jul 25 08:25:15 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 06:25:15 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343197515.4.0.31462018664.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Is there a reason not to correct that spelling in this issue?  Otherwise, we could create a new issue.

----------

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

From report at bugs.python.org  Wed Jul 25 08:39:42 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 06:39:42 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343198381.97.0.260152784271.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't know how Doc ACKS is maintained, but I think the devguide is fine as it stands, whether or not Doc ACKS is preserved or not. People should put themselves into Misc/ACKS if they made a contribution, period.

If people need to be acknowledged separately for contributing to the documentation, I think only major contributions (such as writing the documentation for a yet-undocumented module) should be explicitly acknowledged.

I think this all started from the documentation having initially Guido van Rossum given as its sole author, and then later Fred Drake. So Doc/ACKS.txt may have been an attempt to correct the impression that these two are the authors, but I think it went into the wrong direction (eventually leading to the creation of issues such as this one)

----------

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

From report at bugs.python.org  Wed Jul 25 09:21:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 07:21:55 +0000
Subject: [docs] [issue15444] Incorrectly writen contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343200915.25.0.241236707755.issue15444@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

There was a long-standing opposition by Guido to use UTF-8 in that file, and also complaints about legibility. Not sure what the current status is.

It doesn't matter much to me, even though the spelling of my name is affected.

----------

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

From report at bugs.python.org  Wed Jul 25 09:45:25 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 07:45:25 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343202324.71.0.474003959923.issue15444@psf.upfronthosting.co.za>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

Well, here is updated patch. Also fixed names of Walter D?rwald (was Walter D?rwald) and Martin von L?wis in Misc/HISTORY.

All changed files (documentation, ACK-files, Misc/HISTORY) already in UTF-8 and contains non-ASCII names.

L?wis written as Loewis in some other places: Lib/idlelib/NEWS.txt, Tools/README, source comments. Same for Marc-Andre (without ?) Lemburg. I?do not think, that it matter in comments, but not sure about NEWS- and README-files.

----------
title: Incorrectly writen contributor's names -> Incorrectly written contributor's names
Added file: http://bugs.python.org/file26509/doc-nonascii-names-2.patch

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

From report at bugs.python.org  Wed Jul 25 10:44:42 2012
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 25 Jul 2012 08:44:42 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343202324.71.0.474003959923.issue15444@psf.upfronthosting.co.za>
Message-ID: <500FB1F5.9070709@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thank you for taking the initiative. Regarding use of UTF-8 for text files:

I think we ought to acknowledge that UTF-8 has become the defacto standard
for non-ASCII text files by now and with Python 3 being all Unicode, it
feels silly not make use of it in Python source files.

Regarding my name: I have no issue with the apostrophe missing on the e.
I've long given up using it in source code or emails :-)

----------

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

From report at bugs.python.org  Wed Jul 25 17:59:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 15:59:29 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343231969.52.0.664252258377.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

To be clear on this issue's scope, I would state in a single comment a white list of which directories or individual files are being corrected (or if necessary, the rules to determine such a list, e.g. any file whose name root is "NEWS", etc).

I would also recommend being systematic about this by creating a script to search the above files, along with a configuration section containing the list of replacements: e.g. correct spelling -> list of misspellings for that name.  And upload the script to this issue.  That way people can see what misspellings have already been accounted for, more could be added easily, and it could be used again if necessary.

Because this may grow in scope (e.g. into source files) and because it affects people's names, it may be worth raising on python-dev.  At the least, people would have the chance to contribute known misspellings.

----------

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

From report at bugs.python.org  Wed Jul 25 18:10:53 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 16:10:53 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343232653.3.0.224179250425.issue15444@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Make sure that it's still possible to generate the pdf of the docs (with `make latex` and then `make all-pdf` in build/latex/).
Latin1 should be fine, but IIRC non-latin1 will break (sorry ?iga).

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

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

From report at bugs.python.org  Wed Jul 25 18:29:39 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 16:29:39 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343233779.55.0.369301463553.issue15439@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW including Misc/ACKS in the doc will probably break the generation of the pdf version of the doc, since it contains non-latin1 characters (see msg166408).  I don't think it's necessary to include the names in the doc.

> I don't know how Doc ACKS is maintained, but I think the devguide is
> fine as it stands, whether or not Doc ACKS is preserved or not. 
> People should put themselves into Misc/ACKS if they made a 
> contribution, period.

In my experience Doc/ACKS.txt is mostly ignored/unmaintained.  I did a lot of work on the docs and my name is not in there, and I don't think I ever added anyone there.

> If people need to be acknowledged separately for contributing to the
> documentation, I think only major contributions (such as writing the 
> documentation for a yet-undocumented module) should be explicitly 
> acknowledged.

It's already possible to give credit directly in the docs using directives like "sectionauthor".

----------

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

From report at bugs.python.org  Wed Jul 25 18:37:22 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:37:22 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343234241.96.0.669829229239.issue15439@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

OK, I propose to completely drop the Doc/ACKS.txt from the documentation, and replace it with the words

"Many people have contributed to the Python language, the Python standard library, and the Python documentation. See Misc/ACKS in the Python source distribution for a partial list of contributors"

----------

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

From report at bugs.python.org  Wed Jul 25 18:42:00 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:42:00 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343234520.2.0.824656133434.issue15437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't think the docs should display Misc/ACKS. Instead, I propose the following wording

"Many people have contributed to the Python language, the Python standard library, and the Python documentation. See Misc/ACKS in the Python source distribution for a partial list of contributors"

It might be useful to link "Misc/ACKS" to http://hg.python.org/cpython/file/default/Misc/ACKS
(http://hg.python.org/cpython/raw-file/default/Misc/ACKS would be better if hgweb wouldn't declare that application/octet-stream)

----------

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

From report at bugs.python.org  Wed Jul 25 18:54:11 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 25 Jul 2012 16:54:11 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343235251.02.0.999783324997.issue15444@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Indeed, PDF rendering is important. OTOH, Latex T1 does support ?. Untested, \v{Z} should generate that character. If this doesn't work, the build process needs to be fixed.

----------

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

From report at bugs.python.org  Wed Jul 25 20:26:35 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 18:26:35 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343240794.89.0.451499786623.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot, Eli, and for the suggestions.  I would be happy to prepare a full patch.

Regarding the stream argument, I think there are other changes to dircmp that would be more useful (e.g. issue 12932), but I agree that some form of your suggestion makes sense.  Would you mind if I created a separate issue for it to discuss there?  I have some suggestions on it, and I would be happy to work on it there.

----------

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

From report at bugs.python.org  Wed Jul 25 20:42:04 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 18:42:04 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343241724.38.0.415429810219.issue15444@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> Indeed, PDF rendering is important. OTOH, Latex T1 does support ?.

I tried to put a ? directly in an rst source and indeed the pdf has been created correctly.

----------

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

From report at bugs.python.org  Wed Jul 25 20:55:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 25 Jul 2012 18:55:23 +0000
Subject: [docs] [issue15437] Merge Doc/ACKS.txt names into Misc/ACKS
In-Reply-To: <1343074054.0.0.16855130631.issue15437@psf.upfronthosting.co.za>
Message-ID: <1343242523.61.0.317780329826.issue15437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We can just use :source:`Misc/ACKS` and it will created a link to hgweb (the colored HTML page, not the raw file).

----------

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

From report at bugs.python.org  Wed Jul 25 21:38:46 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 Jul 2012 19:38:46 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343232653.3.0.224179250425.issue15444@psf.upfronthosting.co.za>
Message-ID: <201207252238.26355.storchaka@gmail.com>


Serhiy Storchaka <storchaka at gmail.com> added the comment:

All names interpreted correctly except cyrillic (Alexander ?????? Belopolsky 
and ???? ?????????). I think it's just because of lack of some non-installed 
package (of course, Latex supports cyrillic).

----------

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

From report at bugs.python.org  Thu Jul 26 00:50:45 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:50:45 +0000
Subject: [docs] [issue13525] Tutorial: Example of Source Code Encoding
	triggers error
In-Reply-To: <1322918242.84.0.309365391343.issue13525@psf.upfronthosting.co.za>
Message-ID: <1343256646.0.0.914886191126.issue13525@psf.upfronthosting.co.za>


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


----------
type:  -> enhancement

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

From report at bugs.python.org  Thu Jul 26 00:58:31 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 25 Jul 2012 22:58:31 +0000
Subject: [docs] [issue13538] Improve doc for str(bytesobject)
In-Reply-To: <1323176202.72.0.939593464127.issue13538@psf.upfronthosting.co.za>
Message-ID: <1343257111.03.0.365408774546.issue13538@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 26 01:03:08 2012
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 Jul 2012 23:03:08 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343257388.78.0.412104304984.issue15436@psf.upfronthosting.co.za>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This may be CPython specific.

Also, sys.getsizeof() hasn't proved to be very useful (I never see anyone use it or see it in production code).  Worse, it doesn't even make sense in the case of shared-key dictionaries and whatnot.  Accordingly, there is little reason to make this more public than it already is.  I would be happy to see it written-off as an implementation detail.

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

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

From report at bugs.python.org  Thu Jul 26 01:05:31 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 25 Jul 2012 23:05:31 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343257531.93.0.571099850008.issue15436@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

sys.getsizeof() is not for production code, it's for experimenting and getting information at the command prompt. It's quite useful when you know its limitations.

I'd argue that implementing __sizeof__ for user types doesn't make much sense (except C extension types, which are CPython-specific).

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

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

From report at bugs.python.org  Thu Jul 26 01:49:10 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 25 Jul 2012 23:49:10 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343260150.65.0.678943444999.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching a patch to address Eli's requests (1) and (2).

Since this patch merely adds documentation and tests for existing functionality, is there any reason why this cannot go into Python 3.3?  Thanks.

----------
Added file: http://bugs.python.org/file26516/issue-15269-2.patch

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

From report at bugs.python.org  Thu Jul 26 06:02:03 2012
From: report at bugs.python.org (Meador Inge)
Date: Thu, 26 Jul 2012 04:02:03 +0000
Subject: [docs] [issue14201] Documented caching for shared library's
	__getattr__ and	__getitem__ is incorrect
In-Reply-To: <1330957421.08.0.5889949548.issue14201@psf.upfronthosting.co.za>
Message-ID: <1343275322.98.0.370360712711.issue14201@psf.upfronthosting.co.za>


Meador Inge <meadori at gmail.com> added the comment:

Any comments on this one?  I plan on committing the changes tomorrow unless I hear something otherwise.

----------

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

From report at bugs.python.org  Thu Jul 26 07:59:26 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 Jul 2012 05:59:26 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343282366.98.0.0257315435704.issue15436@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Thu Jul 26 08:35:35 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 26 Jul 2012 06:35:35 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343284534.95.0.0890672085481.issue15269@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I think it can go into 3.3 but only if it gets reviewed by another core dev (we're in release candidate stage now). Senthil - can you review the patch together with me?

As for customizing the stream, yes, go ahead and open a new issue for it, and add me there as nosy.

----------

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

From report at bugs.python.org  Thu Jul 26 08:44:08 2012
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 26 Jul 2012 06:44:08 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1343285048.4.0.896335278813.issue15360@psf.upfronthosting.co.za>


Changes by Chris Rebert <pybugs at rebertia.com>:


----------
nosy: +cvrebert

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

From report at bugs.python.org  Thu Jul 26 09:51:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 07:51:47 +0000
Subject: [docs] [issue15269] Document dircmp.left and dircmp.right
In-Reply-To: <1341635280.22.0.709109531165.issue15269@psf.upfronthosting.co.za>
Message-ID: <1343289107.05.0.990278039103.issue15269@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Sounds good.  And for the record, new issue created here: issue 15454

----------

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

From chris.jerdonek at gmail.com  Thu Jul 26 10:44:41 2012
From: chris.jerdonek at gmail.com (Chris Jerdonek)
Date: Thu, 26 Jul 2012 01:44:41 -0700
Subject: [docs] index directives for section text
Message-ID: <CAOTb1wdtC6O1aZarrXJzM+V2LJsCXRjKCw0XFWkDeFZFZ3EjGA@mail.gmail.com>

When marking section text for inclusion in the index, is there a
preference for whether the index directive should occur immediately
before or after the section header?

For example, "generator, function" in the index links here:

http://docs.python.org/dev/reference/datamodel.html#index-36

But the "Generator functions" header is not visible after clicking the
link without scrolling (at least for me) because the directive appears
after the header in reference/datamodel.rst:

    Generator functions
       .. index::
          single: generator; function
          single: generator; iterator

This seems like common practice in some areas of the documentation,
but it seems like the result might be less desirable.

Thanks,
--Chris

From report at bugs.python.org  Thu Jul 26 10:55:36 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 08:55:36 +0000
Subject: [docs] [issue15455] index entries not showing up in glossary
Message-ID: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

I haven't tracked down the reason for this, but certain index entries seem to be getting skipped in the Glossary.  If you view source on the Glossary page and search for "index-":

http://docs.python.org/dev/glossary.html

You will find that it skips from 'index-2' to 'index-5'.  Only :pep: index entries are getting included even though the Glossary's rst file contains explicit index directives (where 'index-3' and 'index-4' would otherwise be).

I tried some experiments, and this seems to occur even if the index directive text does not match the name of the Glossary term.

----------
assignee: docs at python
components: Documentation
messages: 166467
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: index entries not showing up in glossary
type: behavior
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 26 12:30:25 2012
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 26 Jul 2012 10:30:25 +0000
Subject: [docs] [issue15455] index entries not showing up in glossary
In-Reply-To: <1343292936.36.0.839564467916.issue15455@psf.upfronthosting.co.za>
Message-ID: <1343298625.75.0.630338456764.issue15455@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Jul 26 13:00:27 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:00:27 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343300426.95.0.328151054789.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

This is a very simple patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26525/issue-15355-1.patch

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

From report at bugs.python.org  Thu Jul 26 13:37:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:37:56 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
Message-ID: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

The documentation on generators (outside of PEP 255) does not currently educate the reader on the more specific  "generator function" and "generator iterator" terminology, or at least not in any consistent or systematic way.

For example, the glossary includes only a single entry for "generator," and that entry does not mention the two more specific forms.

I think it would help for general discourse purposes if this distinction were made clearer, while still continuing to allow for the use of the generic word "generator" when the context makes it clear.

There are also cases where index entries can be improved in this regard, and where references to the section containing details about generators can still be added.  I am in the process of completing a proposed patch.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166474
nosy: cjerdonek, docs at python
priority: normal
severity: normal
status: open
title: consistent treatment of generator terminology
versions: Python 3.3

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

From report at bugs.python.org  Thu Jul 26 13:39:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 11:39:28 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343302768.52.0.166108937072.issue15355@psf.upfronthosting.co.za>


Changes by Chris Jerdonek <chris.jerdonek at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul 26 14:28:05 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Thu, 26 Jul 2012 12:28:05 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343305685.48.0.921224867794.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file26526/issue-15457-1.patch

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

From report at bugs.python.org  Thu Jul 26 14:50:03 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 12:50:03 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343307003.64.0.999779860803.issue15457@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul 26 14:50:34 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 Jul 2012 12:50:34 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343307034.79.0.0617635704989.issue15355@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Thu Jul 26 16:20:04 2012
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 Jul 2012 14:20:04 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <3Wjb6q2FLkzPHF@mail.python.org>


Roundup Robot <devnull at psf.upfronthosting.co.za> added the comment:

New changeset aa296d685e02 by Andrew Svetlov in branch '3.2':
Issue #15041: update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/aa296d685e02

New changeset e2ab56295b56 by Andrew Svetlov in branch 'default':
Issue #15041: update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/e2ab56295b56

New changeset c947f493ccec by Andrew Svetlov in branch '2.7':
Issue #15041: Update "see also" list in tkinter documentation.
http://hg.python.org/cpython/rev/c947f493ccec

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

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

From report at bugs.python.org  Thu Jul 26 18:14:58 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 26 Jul 2012 16:14:58 +0000
Subject: [docs] [issue15360] Behavior of assigning to __dict__ is not
	documented
In-Reply-To: <1342373106.65.0.0254375505566.issue15360@psf.upfronthosting.co.za>
Message-ID: <1343319298.69.0.599817826643.issue15360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think assigning to __dict__ is an implementation detail; we shouldn't document it before it is clearly agreed what it should do (which probably deserves asking on python-dev).

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

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

From report at bugs.python.org  Thu Jul 26 21:31:09 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 26 Jul 2012 19:31:09 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343331069.16.0.381468936879.issue15041@psf.upfronthosting.co.za>


Changes by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Jul 26 23:16:23 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 26 Jul 2012 21:16:23 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343337383.07.0.0379983478078.issue15041@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, there is no need to add a Misc/NEWS entry for such small doc changes (and especially not in the Library section :)  The Documentation section of Misc/NEWS is used for important changes to the doc or the toolchain, not the everyday changes we do.

----------
nosy: +eric.araujo

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

From report at bugs.python.org  Thu Jul 26 23:24:06 2012
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 Jul 2012 21:24:06 +0000
Subject: [docs] [issue15151] Documentation for Signature,
	Parameter and signature in inspect module
In-Reply-To: <1340432030.73.0.594662136445.issue15151@psf.upfronthosting.co.za>
Message-ID: <1343337846.79.0.200768619314.issue15151@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/issue15151>
_______________________________________

From report at bugs.python.org  Fri Jul 27 05:58:03 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 27 Jul 2012 03:58:03 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343361483.58.0.712633176745.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric - what is missing?

----------

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

From report at bugs.python.org  Fri Jul 27 09:05:25 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 07:05:25 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
Message-ID: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As far as I can tell, the only mentions of the C API version macros are:

1. In the prose for the stable ABI section (incidentally: this section has a typo in the title)

2. In the documentation for sys.hexversion

There should be a clear "API and ABI Versioning" section in the C API docs that covers:

PY_LIMITED_API
PY_HEX_VERSION
PY_MAJOR_VERSION
PY_MINOR_VERSION
PY_MICRO_VERSION
PY_RELEASE_LEVEL
PY_RELEASE_SERIAL

----------
assignee: docs at python
components: Documentation
messages: 166546
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Improved documentation for C API version info
type: enhancement

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

From report at bugs.python.org  Fri Jul 27 09:05:35 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 27 Jul 2012 07:05:35 +0000
Subject: [docs] [issue15465] Improved documentation for C API version info
In-Reply-To: <1343372725.26.0.84225170505.issue15465@psf.upfronthosting.co.za>
Message-ID: <1343372735.53.0.686037373004.issue15465@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 27 13:49:42 2012
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 27 Jul 2012 11:49:42 +0000
Subject: [docs] [issue15041] tkinter documentation: update "see also" list
In-Reply-To: <1339289373.86.0.533963789483.issue15041@psf.upfronthosting.co.za>
Message-ID: <1343389782.65.0.697036583452.issue15041@psf.upfronthosting.co.za>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Ok

----------

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

From report at bugs.python.org  Fri Jul 27 16:05:24 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 14:05:24 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343397924.03.0.648422435138.issue15231@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Compare:

running the command above without warnings is not sufficient for PyPI to convert the content successfully.

being able to run the command above without warnings is not sufficient to be sure that PyPI will convert the content successfully.

----------

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

From report at bugs.python.org  Fri Jul 27 20:23:54 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 18:23:54 +0000
Subject: [docs] [issue15472] Itertools doc summary table misdocuments some
	arguments
Message-ID: <1343413434.71.0.36910737273.issue15472@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In the tables near the top of http://docs.python.org/library/itertools , some functions like cycle have an example that uses ?seq?, which is interpreted as ?sequence? but the functions do work with any iterable.

----------
assignee: docs at python
components: Documentation
messages: 166594
nosy: docs at python, eric.araujo, rhettinger
priority: normal
severity: normal
status: open
title: Itertools doc summary table misdocuments some arguments
versions: Python 2.7

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

From report at bugs.python.org  Fri Jul 27 20:43:27 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:43:27 +0000
Subject: [docs] [issue15460] SQLite cursor.description is not DB-API
	compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343414607.9.0.637178738535.issue15460@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, tshepang

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

From report at bugs.python.org  Fri Jul 27 20:50:28 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:50:28 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343415028.05.0.257405298464.issue15439@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Jul 27 20:51:25 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 18:51:25 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343415085.47.0.482401040416.issue15439@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> OK, I propose to completely drop the Doc/ACKS.txt from the documentation, and replace it with the words

Sounds good to me.

----------

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

From report at bugs.python.org  Fri Jul 27 20:51:49 2012
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 27 Jul 2012 18:51:49 +0000
Subject: [docs] [issue15460] SQLite cursor.description is not DB-API
	compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343415109.21.0.54092565565.issue15460@psf.upfronthosting.co.za>


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


----------
nosy: +ghaering

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

From report at bugs.python.org  Fri Jul 27 20:54:19 2012
From: report at bugs.python.org (Tshepang Lekhonkhobe)
Date: Fri, 27 Jul 2012 18:54:19 +0000
Subject: [docs] [issue15418] 2to3 docs should mention setup.py fixes
	required to	install compatible packages in Python 3
In-Reply-To: <1342944867.41.0.426616116312.issue15418@psf.upfronthosting.co.za>
Message-ID: <1343415259.97.0.526509810992.issue15418@psf.upfronthosting.co.za>


Changes by Tshepang Lekhonkhobe <tshepang at gmail.com>:


----------
nosy: +tshepang

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

From report at bugs.python.org  Fri Jul 27 21:10:07 2012
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 27 Jul 2012 19:10:07 +0000
Subject: [docs] [issue15474] Differentiate decorator and decorator factory
	in docs
Message-ID: <1343416207.69.0.71696747041.issue15474@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Some of the confusion encountered when writing decorators arise from the difference between a decorator (@something) and a decorator factory (@something(args)).  It would help to adopt this clearer terminology in our docs: a decorator takes the decorated function as argument and does its business, a decorator factory takes some arguments and returns a decorator which wraps the decorated function.

(I think it was Nick who suggested this in a recent-ish mailing list thread.)

----------
assignee: docs at python
components: Documentation
messages: 166600
nosy: docs at python, eric.araujo, ncoghlan
priority: normal
severity: normal
status: open
title: Differentiate decorator and decorator factory in docs
versions: Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Fri Jul 27 21:32:30 2012
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Fri, 27 Jul 2012 19:32:30 +0000
Subject: [docs] [issue15460] SQLite cursor.description is not DB-API
	compatible
In-Reply-To: <1343327941.65.0.811204153568.issue15460@psf.upfronthosting.co.za>
Message-ID: <1343417550.63.0.214854989792.issue15460@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

SQLite's columns aren't typed, only SQLite values are. So it's entirely possible for the same column to have different types, like the NULL type, the INTEGER type and the TEXT type.

It's thus impossible to give meaningful type information in a SQLite3 DB-API module. That's why it's set to None instead.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri Jul 27 23:07:59 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 21:07:59 +0000
Subject: [docs] [issue15439] Include Misc/ACKS names into the documentation
In-Reply-To: <1343130700.15.0.452973615172.issue15439@psf.upfronthosting.co.za>
Message-ID: <1343423279.05.0.643387009377.issue15439@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I agree with Martin also. A short paragraph and link to the (combined) online file is quite sufficient. There is no need for the file to be in offline copies. And I would make the change in all current versions.

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

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

From report at bugs.python.org  Sat Jul 28 00:03:27 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 22:03:27 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343426607.2.0.161741066047.issue15444@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I basically agree with Marc-Andr?. Indeed, I think Acks, at least, should contain names in native spelling plus, if that is not Latin-based, a romanization. Three reasons:
1. I want English-speaking Python programmers to feel welcome to contribute and be acknowledged with what is visibly their native name.
2. I want people to be able to looks at the contributors list and see that Python is an international project.
3. Transliterations are ofter lossy, and in both directions. Romanizations do not necessarily tell contributors' compatriots how to address them in their mutual native language.

If stdlib .py files are still restricted to romanizations, those could at least be looked up in Acks. But Python does come with an utf-8 unicode editor, Idle, that handles at least the BMP just fine (because tcl/tk does).

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

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

From report at bugs.python.org  Sat Jul 28 01:36:56 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Fri, 27 Jul 2012 23:36:56 +0000
Subject: [docs] [issue15444] Incorrectly written contributor's names
In-Reply-To: <1343161512.09.0.0619646494936.issue15444@psf.upfronthosting.co.za>
Message-ID: <1343432216.5.0.345229867592.issue15444@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

The idea also to include a romanization is a good one.

While working on issue 15437, it occurred to me that storing the names in a structured form might come in handy.  This would let us do things like list the username(s) associated with each contributor alongside their name (and access this information programmatically).  And perhaps also include information like the following: http://www.python.org/dev/committers

----------

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

From report at bugs.python.org  Sat Jul 28 01:48:54 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 27 Jul 2012 23:48:54 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343432934.42.0.704753701284.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think the current entry calling a generator function a generator is wrong, so I appreciate your patch. Generator functions return instances of class 'generator'*. I personally refer to generators as generator-iterators about as often as I refer to lists as list-sequences. (Generators implement the iterator protocol; lists implement the sequence protocol.)

* I personally think of a generator function as defining a virtual subclass of class generator and returning instances of that (vitual) subclass. The gf does this# by setting the gi_code attribute of instances to the code object compiled from its body. (Or perhaps it calls the generator class with its code object as parameter. In any case, this is what the special gf.__call__ method does instead of executing its code attribute. The call protocol makes this magic easy.) The generator subclass, then, is all instances with the same gi_code attribute. The name of the 'subclass' is the name of the generator function, which is also g.gi_code.co_name.

# Although 'gi_code' does not have a leading underscore, I am not sure whether it is intended to be public or if the mechanism is CPython specific. It *is' the only way to get the gf/subclass name from the generator.

What I think still needs correction is "generator then controls the execution of a generator function". The generator function has already run to create the generator. What is controlled is the execution of the code object compiled from the body of a gf. And the 'generator function' in question is not just 'a generator function' but 'the generator function that created the generator'.

So I suggest as more correct something like "generator then controls the execution of the [code object compiled from the] body of the generator function that created it" The part in [] is true but might be omitted if it seems too much in the context.

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

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

From report at bugs.python.org  Sat Jul 28 02:11:29 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 00:11:29 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343434289.05.0.621315676048.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Thanks a lot for the excellent feedback.  I'll update the patch to incorporate it.

One background note: I tried not to be too strict about using "generator iterator" or "generator function" in place of "generator" in the general docs in deference to this remark in PEP 255:  "Note that when the intent is clear from context, the unqualified name "generator" may be used to refer either to a generator-function or a generator-iterator."

----------

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

From report at bugs.python.org  Sat Jul 28 03:45:04 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 01:45:04 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343439903.28.0.855329979378.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

Attaching updated patch incorporating feedback.

It would be nice to have a good term for "the generator function code object associated with a generator" to distinguish it from the original generator function as you point out.

There are many places in the docs where this distinction is blurred, for example throughout the subsection describing generator methods:

"generator.__next__(): Starts the execution of a generator function or resumes it at the last executed yield expression..."

http://docs.python.org/dev/reference/expressions.html#generator.__next__

By the way, I think it would be a good idea to add "code object" to the glossary as it is not currently listed.  In particular, the entry could link to the section of the docs that discuss code objects in more detail:

http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
specifically: http://docs.python.org/dev/reference/datamodel.html#index-52

----------
Added file: http://bugs.python.org/file26552/issue-15457-2.patch

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

From report at bugs.python.org  Sat Jul 28 06:48:06 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 28 Jul 2012 04:48:06 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343450886.5.0.71283555914.issue15231@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Feel free to change it, I don't mind. I think the intention is clear anyway.

----------

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

From report at bugs.python.org  Sat Jul 28 08:54:53 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Jul 2012 06:54:53 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343458493.46.0.79123635734.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Up until today, I had assumed that it was the generator.__next__ method that was associated with the compiled body. But in writing my response, I investigated and discovered

>>> def gf(): yield None

>>> gf().gi_code is gf.__code__
True

Then i realized that the simple call protocal -- a callable is an object with an executable __call__ method -- makes the magic simpler than I thought. Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code).

Since code objects are referred to in various places (compile(), exec(), probably def statement doc), I agree that there should be a minimal glossary entry. One can't really understand generator functions and generators without knowing that def statements create both a function object and an attached code object, but that they can operate somewhat separately.

----------

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

From report at bugs.python.org  Sat Jul 28 08:56:31 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 Jul 2012 06:56:31 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343458591.65.0.175401451692.issue15457@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I will try to read your new patch when I am fresher.

----------

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

From report at bugs.python.org  Sat Jul 28 09:11:11 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:11:11 +0000
Subject: [docs] [issue15476] Add "code object" to glossary
Message-ID: <1343459471.56.0.370073010984.issue15476@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to add "code object" to the documentation glossary, as discussed in issue 15457 regarding the documentation around generators.

This can be a minimal entry that links to the details here, for example--

http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy
specifically: http://docs.python.org/dev/reference/datamodel.html#index-52

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 166633
nosy: cjerdonek, docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add "code object" to glossary
type: enhancement
versions: Python 3.3

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

From report at bugs.python.org  Sat Jul 28 09:26:28 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 07:26:28 +0000
Subject: [docs] [issue15457] consistent treatment of generator terminology
In-Reply-To: <1343302676.51.0.168761959505.issue15457@psf.upfronthosting.co.za>
Message-ID: <1343460388.87.0.35358990965.issue15457@psf.upfronthosting.co.za>


Chris Jerdonek <chris.jerdonek at gmail.com> added the comment:

I created issue 15476 to add "code object" to the glossary.

> Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code).

Just to be sure, is this the same as what you were saying in your previous comment?

"The gf does this# by setting the gi_code attribute of instances to the code object compiled from its body. (Or perhaps it calls the generator class with its code object as parameter. In any case, this is what the special gf.__call__ method does instead of executing its code attribute."

Since you're not sure whether the gi_code attribute is meant to be public, it may be best not to mention it explicitly in the docs.  This is consistent with what I have done in the latest patch.  Thanks in advance for reviewing the update.

----------

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

From bjorn.madsen at operationsresearchgroup.com  Wed Jul 25 11:22:57 2012
From: bjorn.madsen at operationsresearchgroup.com (Bjorn Madsen)
Date: Wed, 25 Jul 2012 10:22:57 +0100
Subject: [docs] addon/missing to section on dictionary in python 3.2.3
Message-ID: <CALCPZ6dobMFoT4SZn-qzUObi9q9tX0OAObfr4p9nS+wrqSJcdQ@mail.gmail.com>

Hi,
Is it possible to add a very brief section/sentence in the documentation on
dictionaries
http://docs.python.org/py3k/tutorial/datastructures.html#dictionaries
that an efficient way of for example managing graphs is *to use joint
key-value pairs*?

I looked into the usage of graphs and found the common habit is to create
graphs as:
    G = {'s':{'u':10, 'x':5}, 'u':{'v':1, 'x':2}, 'v':{'y':4}, 'x':{'u':3,
'v':9, 'y':2}, 'y':{'s':7, 'v':6}}
   source:
http://code.activestate.com/recipes/119466-dijkstras-algorithm-for-shortest-paths/

However by using joint keys *d[key1,key2,...,keyN] = value* one may
actually set up pretty sophisticated data structures, which is brilliant
whenever m:n-relationships may occur.

I have put an example below:

def graph(vertices, connectivity):
    """This function produces a graph using joint keypairs in the returned
dictionary.
        Vertices must be integer.
        Connectivity is a floating point value between 0 and 1.
        A random number is produced.
        If the random number is less than or equal
        to the connectivity, then a node is added to the graph."""
    from random import random, randint
    d={}
    for i in range(1,vertices+1):
        for j in range(1,vertices+1):
            if random()<=connectivity:
                d[i,j]=randint(1,10)    # dict uses joint key-pair!
    return d

Further discussion could of course be how to lookup keys "if the graph is
bidirectional?" This however may easily be solved using multiple
assignments such as:
if keyA>keyB:
    keyA, keyB = keyB, keyA
...where these two lines reduces the otherwise redundant part of the
dictionary to half the size.

Finally I assume that the performance of using joint keys is the same (or
perhaps slightly faster) than using Eppstein's method (top example), as it
is not necessary to parse the result value from the first dictionary into
the second. However please correct me if I'm wrong on this matter.


PS. If this subject has been evaluated before, please accept my apologies;
I only started with python 3 three weeks ago and haven't gotten my head
around the PEP yet, but thought it could be advantageous to know this since
it was absent in the documentation.

Kind Regards,
-- 
Bjorn Madsen
*Researcher Complex Systems Research*
Ph.: (+44) 0 7792 030 720
bjorn.madsen at operationsresearchgroup.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120725/ba63053f/attachment.html>

From devel at antoneliasson.se  Wed Jul 18 15:34:17 2012
From: devel at antoneliasson.se (Anton Eliasson)
Date: Wed, 18 Jul 2012 15:34:17 +0200
Subject: [docs] Bug in part 5 of the Python 3 tutorial
Message-ID: <5006BB59.5050008@antoneliasson.se>

Hi!
In the Python 3 tutorial about data structures, in the section about 
nested list comprehensions 
(http://docs.python.org/py3k/tutorial/datastructures.html#nested-list-comprehensions); 
the zip function is described differently than it works in my 
installation (Ubuntu 12.04). I'm fairly new to Python so the issue is 
probably described best using an example:

     $ python3
     Python 3.2.3 (default, May  3 2012, 15:51:42)
     [GCC 4.6.3] on linux2
     Type "help", "copyright", "credits" or "license" for more information.
     >>> matrix = [
     ...     [1, 2, 3, 4],
     ...     [5, 6, 7, 8],
     ...     [9, 10, 11, 12],
     ... ]
     >>> zip(*matrix)
     <zip object at 0x1053098>

However, in the tutorial the zip function returns a list of tuplets like 
this:

     >>> zip(*matrix)
     [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)]

In order to get that result, I have to do this in my installation:

     >>> list(zip(*matrix))
     [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)]

-- 
Med v?nliga h?lsningar / Kindest Regards
Anton Eliasson


From duebel13 at gmx.de  Wed Jul 25 09:04:49 2012
From: duebel13 at gmx.de (duebel13 at gmx.de)
Date: Wed, 25 Jul 2012 09:04:49 +0200
Subject: [docs] (no subject)
Message-ID: <20120725070449.33850@gmx.net>

Hi,

the page http://docs.python.org/using/windows.html contains this sentence beneath "3.1. Installing Python":

Up to 2.5, Python was still compatible with Windows 95, 98 and ME (but already raised a deprecation warning on installation). For Python 2.6 (and all following releases), this support was dropped and new releases are just expected to work on the Windows NT family.

I'd consider this misleading if not false and suggest to rephrase it like this:

Up to 2.5, Python was still compatible with Windows 95, 98, ME, and NT 4.0 (but already raised a deprecation warning on installation). For Python 2.6 (and all following releases), this support was dropped and new releases are just expected to work on Windows operating systems that are supported by Microsoft at the time of release.

(Note that Python 2.6 was the last release to support Windows 2000 which of no doubt is part of the Windows NT family.)

Regards

From ellisd23 at gmail.com  Wed Jul 25 21:35:26 2012
From: ellisd23 at gmail.com (Daniel Ellis)
Date: Wed, 25 Jul 2012 15:35:26 -0400
Subject: [docs] Adding Examples to Documentation
Message-ID: <CAJGew6mWfg03fmnyyj-NNbRHBJF4HvEDXDSvXb4xhtpd0dBt4Q@mail.gmail.com>

Hello all,

A bit ago, after talking with Guido on the the core developers group, I was
working on examples for areas of the documentation that I felt would be
helpful to have examples for (particularly itertools, but also functools
and os).  I received some feedback from the group once I submitted some new
documentation, but it never moved much further.

I was hoping to start a discussion here to see whether others felt that
examples of code usage would be worthwhile, and if so, how we could
organize these into sections.

Taking itertools <http://docs.python.org/library/itertools.html> as an
example, there are a lot of great implementation details, as well as
recipes that combine the various functions, but the actual examples of how
to use the library are small and potentially confusing for someone using
the library for the first time.  I know people go to the documentation for
various reasons, so I don't think removing these sections would be wise,
but what do you all think about adding an "Example Usage" section that
lists some concise and easy ways to get up and running with the library?

Thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120725/709148c3/attachment.html>

From gaston.fiore at gmail.com  Mon Jul 23 17:58:39 2012
From: gaston.fiore at gmail.com (Gaston Fiore)
Date: Mon, 23 Jul 2012 11:58:39 -0400
Subject: [docs] Typo
Message-ID: <CAAx7R0QgirERKW0Farkj05k4Omky6hm7nW7Xu4W2_L94DK0Dtg@mail.gmail.com>

Hello,

There's a typo in the 3.2.3 Documentation, The Python Tutorial, 6.2.
Standard Modules. In line 3 of that section, there's a . missing right
after the word "platform". The tutorial currently reads:

"The set of such modules is a configuration option which also depends
on the underlying platform For example, the winreg module is only
provided on Windows systems."

It should read:

"The set of such modules is a configuration option which also depends
on the underlying platform. For example, the winreg module is only
provided on Windows systems."

Best,

-Gaston

From james at lnls.br  Tue Jul 24 21:58:35 2012
From: james at lnls.br (James Rezende Piton - LNLS)
Date: Tue, 24 Jul 2012 16:58:35 -0300
Subject: [docs] Doc bug in Python Tutorial
Message-ID: <CANkBPeHPfTA8=Hfrcm35xjeQDufmnRAXpsOdmav1j4j4UmPw9Q@mail.gmail.com>

Hi,

Today I started learning Python through the Tutorial and I found a mistake at

       http://docs.python.org/tutorial/introduction.html

Its 3.1.2 section (Strings) states:

>>> '"Isn\'t," she said.'
'"Isn\'t," she said.'

But in fact, it should be:

>>> '"Isn\'t," she said.'
'"Isn't," she said.'

as one could expect from the slashed apostrophe.

Regards,

James Piton (no, it's not a joke; my family beared the name 200 years
before "Monty Python"!)
Brazil

From james at lnls.br  Wed Jul 25 17:07:17 2012
From: james at lnls.br (James Rezende Piton - LNLS)
Date: Wed, 25 Jul 2012 12:07:17 -0300
Subject: [docs] Doc bug in Python Tutorial
In-Reply-To: <CANkBPeHPfTA8=Hfrcm35xjeQDufmnRAXpsOdmav1j4j4UmPw9Q@mail.gmail.com>
References: <CANkBPeHPfTA8=Hfrcm35xjeQDufmnRAXpsOdmav1j4j4UmPw9Q@mail.gmail.com>
Message-ID: <CANkBPeGzm_XOEi1WdQRo4qj8y9QV2TJ99bg0LHB4cQCAFhC2mQ@mail.gmail.com>

Sorry, forget that previous message. I have made a mistake by typing

>>> 'Isn\'t, she said.'
"Isn't, she said."

and then, without the ", the slash will be interpreted...

James


2012/7/24 James Rezende Piton - LNLS <james at lnls.br>:
> Hi,
>
> Today I started learning Python through the Tutorial and I found a mistake at
>
>        http://docs.python.org/tutorial/introduction.html
>
> Its 3.1.2 section (Strings) states:
>
>>>> '"Isn\'t," she said.'
> '"Isn\'t," she said.'
>
> But in fact, it should be:
>
>>>> '"Isn\'t," she said.'
> '"Isn't," she said.'
>
> as one could expect from the slashed apostrophe.
>
> Regards,
>
> James Piton (no, it's not a joke; my family beared the name 200 years
> before "Monty Python"!)
> Brazil

From keith.briggs at bt.com  Fri Jul 27 12:54:44 2012
From: keith.briggs at bt.com (keith.briggs at bt.com)
Date: Fri, 27 Jul 2012 11:54:44 +0100
Subject: [docs] Layout problems at http://docs.python.org/library/re.html
Message-ID: <BA02A06A22A52C449E4B5EE4CE1DBC3F99C9E2EB63@EMV66-UKRD.domain1.systemhost.net>

At section 7.2.5.2, everything goes black to the end of the document.   Tried on several different browsers and OSs.
Keith

[cid:image001.png at 01CD6BEE.7B3016B0]



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120727/ab3941de/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 195824 bytes
Desc: image001.png
URL: <http://mail.python.org/pipermail/docs/attachments/20120727/ab3941de/attachment-0001.png>

From mboyarskiy at thumbtack.net  Fri Jul 27 11:16:18 2012
From: mboyarskiy at thumbtack.net (Maxim Boyarskiy)
Date: Fri, 27 Jul 2012 16:16:18 +0700
Subject: [docs] http://docs.python.org/howto/urllib2.html#headers - error
Message-ID: <CAOkFWfEyPKtOJme=jqG79BQBY0mV6ra1EQTdrN-YT-mgCKOw6Q@mail.gmail.com>

Hello,


There is an error on: http://docs.python.org/howto/urllib2.html#headers

There is :

headers = { 'User-Agent' : user_agent }
req = urllib2.Request(url, data, *headers*)


If you want to add header, you should use request.add_header method:


req = urllib2.Request(url, data, headers)
*req.add_header(**'User-Agent', user_agent**)*



Maxim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120727/19c0ef63/attachment.html>

From sabbatini.luca at gmail.com  Wed Jul 25 21:24:29 2012
From: sabbatini.luca at gmail.com (Luca Sabbatini)
Date: Wed, 25 Jul 2012 12:24:29 -0700
Subject: [docs] where to get documentation source
Message-ID: <501047ED.3080606@gmail.com>

I see that the python documentation is generated from reStructuredText 
sources. Where can I get the source files? Online I can only see PDF, 
HTML, and Plain Text output.


thank you much,

Luca Sabbatini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/docs/attachments/20120725/03663a25/attachment.html>

From steve at holdenweb.com  Tue Jul 24 09:15:19 2012
From: steve at holdenweb.com (Steve Holden)
Date: Tue, 24 Jul 2012 00:15:19 -0700
Subject: [docs] Tiny docs bug
Message-ID: <160B5C19-E27F-497C-8FBA-40C1202E90E3@holdenweb.com>

In

http://docs.python.org/py3k/library/smtpd.html 

the received_lines attribute of the SMTPChannel object uses "rn" for "\r\n" and "n" for "\n". Probably just a stropping error.

regards
 Steve
--
Steve Holden steve at holdenweb.com,  Holden Web, LLC http://holdenweb.com/
Python classes (and much more) through the web http://oreillyschool.com/
Conferences and technical event management at http://theopenbastion.com/
Next:           DjangoCon US Sep 6-8, Washington DC http://djangocon.us/

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

From report at bugs.python.org  Sat Jul 28 22:20:21 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 20:20:21 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343506821.82.0.75517765529.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Terry, if when reviewing my patch for issue 15457, you also have time to review this much simpler patch (also in the documentation on generators), I would appreciate it.  If not, that's okay.

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

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

From report at bugs.python.org  Sat Jul 28 22:27:47 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 20:27:47 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343507267.19.0.859902346623.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Is there any way I could assist in closing this, perhaps by preparing patches for the Distutils and Distutils2 components?  Can someone point me to where the changes to those components should be made (e.g. where they are located)?

----------

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

From report at bugs.python.org  Sat Jul 28 23:06:55 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 21:06:55 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343509615.11.0.849503494244.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

distutils are in Lib/distutils. Distutils2 has been removed from Python.

----------

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

From report at bugs.python.org  Sat Jul 28 23:37:09 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 21:37:09 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343511429.44.0.214671533701.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, Martin.  Should Distutils2 be removed from the "Components" list of the tracker form, then?  Or was ?ric referencing a third-party location?

----------

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

From report at bugs.python.org  Sat Jul 28 23:40:17 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 21:40:17 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343511617.18.0.585168528932.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

> Should Distutils2 be removed from the "Components" list of the tracker form, then? 

No. Please stick to one issue at a time, and distutils2 may come back (google for details).

----------

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

From report at bugs.python.org  Sun Jul 29 01:05:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sat, 28 Jul 2012 23:05:14 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343516714.3.0.780096493871.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> No. Please stick to one issue at a time, and distutils2 may come back (google for details).

I was asking only to determine whether to create a new issue -- not to have that issue addressed here.

> It seems to me there are missing words in the text, and it needs porting to the packaging docs.

Okay, I misunderstood and thought there was more to do.  Since Martin said packaging has been removed, all that is left is to add ?ric's requested modifications to 3.3 (and make the collected change to 2.7 and 3.2).

Patch attached.  The commit message can be something like:

Issue #15231: minor adjustment to prior fix committed in f315cfa22630 regarding, "update PyPI upload doc to say --no-raw passed to rst2html.py."

I included a Misc/NEWS entry since that was left out of the previous commit.

Also, incidentally, there was a typo in the issue number of the commit message for the previous commit, which explains why Roundup did not post here.

----------
Added file: http://bugs.python.org/file26556/issue-15231-2.patch

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

From report at bugs.python.org  Sun Jul 29 01:58:39 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 23:58:39 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343519919.65.0.69619522721.issue15231@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I won't be able to work on this for the next few months. This took too much time already.

----------

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

From report at bugs.python.org  Sun Jul 29 01:58:54 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 28 Jul 2012 23:58:54 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343519934.79.0.0326691969962.issue15231@psf.upfronthosting.co.za>


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


----------
nosy:  -loewis

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

From report at bugs.python.org  Sun Jul 29 04:26:40 2012
From: report at bugs.python.org (Meador Inge)
Date: Sun, 29 Jul 2012 02:26:40 +0000
Subject: [docs] [issue15355] generator.__next__() docs should mention
	exception if	already executing
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343528800.38.0.609944617048.issue15355@psf.upfronthosting.co.za>


Meador Inge added the comment:

Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods.  From looking at the code it seems that the patch is correct and that '__next__', 'send', 'throw', and 'close' can all raise the "already executing" exception via 'gen_send_ex'.  Documenting this behavior seems reasonable, but you should probably mention what exception gets raises.

BTW, you don't need to make the Misc/NEWS changes a part of your patches.  A core dev will write that for you and since Misc/NEWS is changed so much it might conflict and make patches harder to apply across similar branches (say 3.2 and 3.3).

----------
nosy: +meador.inge

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

From report at bugs.python.org  Sun Jul 29 04:55:10 2012
From: report at bugs.python.org (Ronan Lamy)
Date: Sun, 29 Jul 2012 02:55:10 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
Message-ID: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>


New submission from Ronan Lamy:

I noticed a change in the behaviour of __import__() between 3.2 and 3.3. It looks like in 3.2 __import__() does a Py2-style combo relative/absolute import. Here's a minimal test case:

$ ls foo
bar.py  __init__.py  __pycache__
$ cat foo/__init__.py
__import__('bar', globals(), locals())
$ python3.3 -c "import foo"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "./foo/__init__.py", line 1, in <module>
    __import__('bar', globals(), locals())
ImportError: No module named 'bar'
$ python3.2 -c "import foo"
$

I believe that 3.3 is correct and that 3.2 is wrong but can't be changed now, so I suppose that 3.2 should just document the actual behaviour of __import__() and 3.3 should document the change. 

(The context is that I encountered issue 15434. This looks related, but I'm not sure it is.)

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 166706
nosy: Ronan.Lamy, brett.cannon, docs at python, ncoghlan
priority: normal
severity: normal
status: open
title: __import__() change between 3.2 and 3.3
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 29 05:31:09 2012
From: report at bugs.python.org (Eric Snow)
Date: Sun, 29 Jul 2012 03:31:09 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343532669.65.0.466665947725.issue15482@psf.upfronthosting.co.za>


Eric Snow added the comment:

See issue14592 (particularly msg158466).

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

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

From report at bugs.python.org  Sun Jul 29 05:35:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 03:35:00 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343532900.72.0.413159692026.issue15482@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The specific bug is that, in 3.2, the claimed default (level=0) is not accurate: the default is actually (level=-1), as it was in 2.x. The import statement passes level=0 explicitly (as it does in 2.x when "from __future__ import absolute_import" is in effect).

The docstring in 3.2 is accurate, the prose documentation is incorrect.

In 3.3, the docstring is currently wrong, but the prose documentation is correct. However, it should have a "versionchanged: 3.3" not added, indicating that the default import level has finally been brought into compliance with the documentation.

----------

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

From report at bugs.python.org  Sun Jul 29 05:47:00 2012
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 29 Jul 2012 03:47:00 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343533620.6.0.411638252355.issue15482@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

s/not added/note added/

----------

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

From report at bugs.python.org  Sun Jul 29 05:54:57 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Sun, 29 Jul 2012 03:54:57 +0000
Subject: [docs] [issue15355] generator docs should mention already-executing
	exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343534097.46.0.771177267135.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

> Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods.

Thanks, Meador.  Yes, I realized that later.  Retitling now.  I will also add the exception type.  I wasn't sure if that was implementation-specific.

> BTW, you don't need to make the Misc/NEWS changes

Certainly -- will do from now on.  Thanks for telling me.  I had thought I was helping.  New patch attached.

----------
title: generator.__next__() docs should mention exception if already executing -> generator docs should mention already-executing exception
Added file: http://bugs.python.org/file26560/issue-15355-2.patch

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

From report at bugs.python.org  Sun Jul 29 11:58:44 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 09:58:44 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343555924.3.0.235800550091.issue15482@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

So should 3.2 be changed to adjust the default value to match the documentation?

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Jul 29 13:44:57 2012
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 29 Jul 2012 11:44:57 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343530510.61.0.113197969687.issue15482@psf.upfronthosting.co.za>
Message-ID: <1343562297.61.0.385176516648.issue15482@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/issue15482>
_______________________________________

From report at bugs.python.org  Sun Jul 29 18:18:05 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 16:18:05 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343073282.53.0.774447573036.issue15436@psf.upfronthosting.co.za>
Message-ID: <1343578685.01.0.787516894062.issue15436@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

rhettinger: users frequently need sys.getsizeof. See, for example,

http://stackoverflow.com/questions/1331471/in-memory-size-of-python-stucture
http://stackoverflow.com/questions/449560/how-do-i-determine-the-size-of-an-object-in-python
http://stackoverflow.com/questions/2117255/python-deep-getsizeof-list-with-contents
http://stackoverflow.com/questions/11301295/measure-object-size-accurately-in-python-sys-getsizeof-not-functioning
[and so on]

In what cases, do you think, it generates meaningless results? I find the results for the shared-keys dictionary quite meaningful and natural.

sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not just an implementation detail of sys.getsizeof, just as __len__ is not an implementation detail of len(). Authors of extension types are supposed to implement it if object.__sizeof__ is incorrect.

----------
nosy: +loewis

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

From report at bugs.python.org  Sun Jul 29 18:57:21 2012
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 Jul 2012 16:57:21 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <1343578685.01.0.787516894062.issue15436@psf.upfronthosting.co.za>
Message-ID: <201207291957.09566.storchaka@gmail.com>


Serhiy Storchaka added the comment:

> sys.getsizeof is certainly CPython-specific. However, __sizeof__ is not
> just an implementation detail of sys.getsizeof, just as __len__ is not an
> implementation detail of len(). Authors of extension types are supposed to
> implement it if object.__sizeof__ is incorrect.

I think there is one difference between __len__ and __sizeof__. __sizeof__ 
should be overloaded only for C-implemented classes. IMHO, it is a part of C 
API.

----------

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

From report at bugs.python.org  Sun Jul 29 19:31:58 2012
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 29 Jul 2012 17:31:58 +0000
Subject: [docs] [issue15436] __sizeof__ is not documented
In-Reply-To: <201207291957.09566.storchaka@gmail.com>
Message-ID: <5015738C.9020105@v.loewis.de>


Martin v. L?wis added the comment:

> I think there is one difference between __len__ and __sizeof__. __sizeof__ 
> should be overloaded only for C-implemented classes. IMHO, it is a part of C 
> API.

That is a reasonable point. So documenting it along with the type slots
might be best.

----------

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

From report at bugs.python.org  Sun Jul 29 21:09:33 2012
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 Jul 2012 19:09:33 +0000
Subject: [docs] [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343588973.14.0.0692320068902.issue15451@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

What I understand you two as saying is that there seems to be an undocumented difference in execxxe between unix and windows which has been carried over to subprocess. In particular, for both, the PATH component of the env parameter is used to search for the file on *nix but not on windows, even though this is not part of posix behavior. So reopening -- as a doc issue -- unless an os expert like Martin declares this to be a behavior bug.

Grissiom, can you verify that the difference still exists in 3.2/3?

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, loewis
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
versions: +Python 3.2, Python 3.3

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

From report at bugs.python.org  Sun Jul 29 23:51:12 2012
From: report at bugs.python.org (Richard Oudkerk)
Date: Sun, 29 Jul 2012 21:51:12 +0000
Subject: [docs] [issue15451] PATH is not honored in subprocess.Popen in win32
In-Reply-To: <1343264230.45.0.645552285699.issue15451@psf.upfronthosting.co.za>
Message-ID: <1343598672.49.0.465838337108.issue15451@psf.upfronthosting.co.za>


Richard Oudkerk added the comment:

> What I understand you two as saying is that there seems to be an 
> undocumented difference in execxxe between unix and windows which has been 
> carried over to subprocess.

No.  There is no difference between the platforms in the behaviour of os.execvpe().  os.execvpe() is simply implemented by trying execve() with a list of candidate executable paths until one of them works -- see _execvpe() in os.py.

Whether this difference from the behaviour of Posix's execvpe() was deliberate, I don't know.

The difference between the platforms in Python 2.x is caused by the fact that subprocess uses os.execvpe() on Unix and CreateProcess() on Windows.

In Python 3.x, os.execvpe() is no longer used on Unix, but the old behaviour has been deliberately maintained.  So the difference in behaviour is still present in Python 3.x.

----------

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

From report at bugs.python.org  Mon Jul 30 02:13:08 2012
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 Jul 2012 00:13:08 +0000
Subject: [docs] [issue15482] __import__() change between 3.2 and 3.3
In-Reply-To: <1343555924.3.0.235800550091.issue15482@psf.upfronthosting.co.za>
Message-ID: <CAP1=2W7NSvoEHw5V9xUu+XULEhZwo8ZPhGy3minW+5=ngFPvGQ@mail.gmail.com>


Brett Cannon added the comment:

On Jul 29, 2012 5:58 AM, "Martin v. L?wis" <report at bugs.python.org> wrote:
>
>
> Martin v. L?wis added the comment:
>
> So should 3.2 be changed to adjust the default value to match the
documentation?

It is probably safe to do so.

-brett

>
> ----------
> nosy: +loewis
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15482>
> _______________________________________

----------

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

From report at bugs.python.org  Mon Jul 30 06:10:41 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Mon, 30 Jul 2012 04:10:41 +0000
Subject: [docs] [issue15497] correct characters in
	TextWrapper.replace_whitespace docs
Message-ID: <1343621441.45.0.427004155003.issue15497@psf.upfronthosting.co.za>


New submission from Chris Jerdonek:

This issue is to correct the list of whitespace characters to replace in the documentation for the textwrap module's TextWrapper.replace_whitespace attribute.

The documentation says this list is string.whitespace:

http://docs.python.org/dev/library/textwrap.html#textwrap.TextWrapper.replace_whitespace

However, the code deliberately avoids using string.whitespace and uses a hard-coded list of characters instead.  For example, see this code comment:

# Hardcode the recognized whitespace characters to the US-ASCII
# whitespace characters.  The main reason for doing this is that in
# ISO-8859-1, 0xa0 is non-breaking whitespace, so in certain locales
# that character winds up in string.whitespace....

http://hg.python.org/cpython/file/917295aaad76/Lib/textwrap.py#l12

Patch attached.

----------
assignee: docs at python
components: Documentation
files: issue-textwrap-whitespace.patch
keywords: easy, patch
messages: 166855
nosy: cjerdonek, docs at python
priority: normal
severity: normal
stage: patch review
status: open
title: correct characters in TextWrapper.replace_whitespace docs
versions: Python 2.7, Python 3.3
Added file: http://bugs.python.org/file26591/issue-textwrap-whitespace.patch

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

From report at bugs.python.org  Mon Jul 30 13:13:07 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 11:13:07 +0000
Subject: [docs] [issue14966] Fully document subprocess.CalledProcessError
In-Reply-To: <1338446762.96.0.360332771622.issue14966@psf.upfronthosting.co.za>
Message-ID: <1343646787.05.0.781061429099.issue14966@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


----------
nosy: +anton.barkovsky

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

From report at bugs.python.org  Mon Jul 30 15:31:43 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:31:43 +0000
Subject: [docs] [issue15501] Document exception classes in subprocess module
Message-ID: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>


New submission from Anton Barkovsky:

Exception classes from subprocess module are mentioned in the doc but do
not have their own entries.

I'm attaching patches for 3.3, 3.2 and 2.7

This issue supersedes #14966.

----------
assignee: docs at python
components: Documentation
files: subprocess_doc_3.3.patch
keywords: patch
messages: 166895
nosy: anton.barkovsky, docs at python
priority: normal
severity: normal
status: open
title: Document exception classes in subprocess module
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26598/subprocess_doc_3.3.patch

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

From report at bugs.python.org  Mon Jul 30 15:31:56 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:31:56 +0000
Subject: [docs] [issue15501] Document exception classes in subprocess module
In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>
Message-ID: <1343655116.16.0.87771656112.issue15501@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26599/subprocess_doc_3.2.patch

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

From report at bugs.python.org  Mon Jul 30 15:32:02 2012
From: report at bugs.python.org (Anton Barkovsky)
Date: Mon, 30 Jul 2012 13:32:02 +0000
Subject: [docs] [issue15501] Document exception classes in subprocess module
In-Reply-To: <1343655102.86.0.835171642678.issue15501@psf.upfronthosting.co.za>
Message-ID: <1343655122.11.0.0363997310241.issue15501@psf.upfronthosting.co.za>


Changes by Anton Barkovsky <swarmer.pm at gmail.com>:


Added file: http://bugs.python.org/file26600/subprocess_doc_2.7.patch

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

From report at bugs.python.org  Tue Jul 31 02:26:14 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 00:26:14 +0000
Subject: [docs] [issue15355] generator docs should mention already-executing
	exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343694373.78.0.629195403456.issue15355@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Meador, does this language look okay to you now that it states the exception type?

----------

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

From report at bugs.python.org  Tue Jul 31 05:00:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 03:00:30 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343703629.84.0.386776706773.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Since Martin is busy, is there anything I can do to help close this very minor change?  It seems to be in a half-committed state right now.

----------

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

From report at bugs.python.org  Tue Jul 31 05:15:19 2012
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 31 Jul 2012 03:15:19 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <3WmN7T5zQszPYJ@mail.python.org>


Roundup Robot added the comment:

New changeset 3a08d766eee3 by Eli Bendersky in branch 'default':
Issue #15231: rephrase the last paragraph slightly
http://hg.python.org/cpython/rev/3a08d766eee3

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

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

From report at bugs.python.org  Tue Jul 31 05:17:54 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 03:17:54 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343704674.04.0.444707528155.issue15231@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

I've committed a rephrase [the Misc/NEWS entry is IMHO unnecessary for tiny documentation clarifications].

Since there's no distutils2/packaging in 3.3 at the moment, I think we're done. ?ric - would you like to keep this issue alive to remember applying the fix to packaging, once it's back?

----------

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

From report at bugs.python.org  Tue Jul 31 05:23:30 2012
From: report at bugs.python.org (Chris Jerdonek)
Date: Tue, 31 Jul 2012 03:23:30 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343705010.86.0.964916931604.issue15231@psf.upfronthosting.co.za>


Chris Jerdonek added the comment:

Thanks, Eli.  I know ?ric had marked in the tracker for the change to be done in 2.7 and 3.2 as well.

----------

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

From report at bugs.python.org  Tue Jul 31 05:28:44 2012
From: report at bugs.python.org (Eli Bendersky)
Date: Tue, 31 Jul 2012 03:28:44 +0000
Subject: [docs] [issue15231] update PyPI upload doc to say --no-raw passed
	to	rst2html.py
In-Reply-To: <1341110073.6.0.573832115517.issue15231@psf.upfronthosting.co.za>
Message-ID: <1343705324.3.0.507991332961.issue15231@psf.upfronthosting.co.za>


Eli Bendersky added the comment:

Yes, if the new phrasing looks OK I will backport to 3.2 & 2.7

----------

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

From report at bugs.python.org  Tue Jul 31 05:30:19 2012
From: report at bugs.python.org (Meador Inge)
Date: Tue, 31 Jul 2012 03:30:19 +0000
Subject: [docs] [issue15355] generator docs should mention already-executing
	exception
In-Reply-To: <1342312261.31.0.534711044354.issue15355@psf.upfronthosting.co.za>
Message-ID: <1343705419.0.0.933103800623.issue15355@psf.upfronthosting.co.za>


Meador Inge added the comment:

Hi Chris, it seems reasonable to me, but I would feel more comfortable if someone (like Nick) that is more familiar with the generator implementation can comment on this as well.

----------

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

From eliben at gmail.com  Tue Jul 31 06:52:04 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:52:04 +0300
Subject: [docs] where to get documentation source
In-Reply-To: <501047ED.3080606@gmail.com>
References: <501047ED.3080606@gmail.com>
Message-ID: <CAF-Rda8Fa-oe+vS5qncbEuhzyd6vn8oZfxCH_GZ1-yCnVWzyVA@mail.gmail.com>

On Wed, Jul 25, 2012 at 10:24 PM, Luca Sabbatini
<sabbatini.luca at gmail.com> wrote:
> I see that the python documentation is generated from reStructuredText
> sources. Where can I get the source files? Online I can only see PDF, HTML,
> and Plain Text output.
>

Hi Luca,

It's in the Doc/ directory of the Python source distribution.

Eli

From eliben at gmail.com  Tue Jul 31 06:55:11 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:55:11 +0300
Subject: [docs] Adding Examples to Documentation
In-Reply-To: <CAJGew6mWfg03fmnyyj-NNbRHBJF4HvEDXDSvXb4xhtpd0dBt4Q@mail.gmail.com>
References: <CAJGew6mWfg03fmnyyj-NNbRHBJF4HvEDXDSvXb4xhtpd0dBt4Q@mail.gmail.com>
Message-ID: <CAF-Rda9MGyGWmWXhws4+4DadPPaNdxs8n=ST7ePikwPR+P+fdA@mail.gmail.com>

> A bit ago, after talking with Guido on the the core developers group, I was
> working on examples for areas of the documentation that I felt would be
> helpful to have examples for (particularly itertools, but also functools and
> os).  I received some feedback from the group once I submitted some new
> documentation, but it never moved much further.
>
> I was hoping to start a discussion here to see whether others felt that
> examples of code usage would be worthwhile, and if so, how we could organize
> these into sections.
>
> Taking itertools as an example, there are a lot of great implementation
> details, as well as recipes that combine the various functions, but the
> actual examples of how to use the library are small and potentially
> confusing for someone using the library for the first time.  I know people
> go to the documentation for various reasons, so I don't think removing these
> sections would be wise, but what do you all think about adding an "Example
> Usage" section that lists some concise and easy ways to get up and running
> with the library?
>

Many documentation pages have "example" sections with usage samples.
When these make sense and can be made sufficiently small and
expressive, they're very helpful. So I suggest to propose something
more concrete. I.e. create an issue in the bug tracker and add a patch
with some examples for the module you want to document. Add relevant
persons to the nosy list
(http://docs.python.org/devguide/experts.html), and hopefully someone
will take a look.

Eli

From eliben at gmail.com  Tue Jul 31 06:56:38 2012
From: eliben at gmail.com (Eli Bendersky)
Date: Tue, 31 Jul 2012 07:56:38 +0300
Subject: [docs] Bug in part 5 of the Python 3 tutorial
In-Reply-To: <5006BB59.5050008@antoneliasson.se>
References: <5006BB59.5050008@antoneliasson.se>
Message-ID: <CAF-Rda8PL-+v9FHoEwve-wR_LrU0LL3+Z4yP5JMHXGh59jrx8A@mail.gmail.com>

> In the Python 3 tutorial about data structures, in the section about nested
> list comprehensions
> (http://docs.python.org/py3k/tutorial/datastructures.html#nested-list-comprehensions);
> the zip function is described differently than it works in my installation
> (Ubuntu 12.04). I'm fairly new to Python so the issue is probably described
> best using an example:
>
>     $ python3
>     Python 3.2.3 (default, May  3 2012, 15:51:42)
>     [GCC 4.6.3] on linux2
>     Type "help", "copyright", "credits" or "license" for more information.
>     >>> matrix = [
>     ...     [1, 2, 3, 4],
>     ...     [5, 6, 7, 8],
>     ...     [9, 10, 11, 12],
>     ... ]
>     >>> zip(*matrix)
>     <zip object at 0x1053098>
>
> However, in the tutorial the zip function returns a list of tuplets like
> this:
>
>     >>> zip(*matrix)
>     [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)]
>
> In order to get that result, I have to do this in my installation:
>
>     >>> list(zip(*matrix))
>     [(1, 5, 9), (2, 6, 10), (3, 7, 11), (4, 8, 12)]
>

Without looking too deep into it, it appears that the example has not
been ported to Python 3. Please open an issue in the bug tracker for
this.

Eli

From report at bugs.python.org  Tue Jul 31 11:23:45 2012
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 31 Jul 2012 09:23:45 +0000
Subject: [docs] [issue13498] os.makedirs exist_ok documentation is incorrect,
	as is some of the behavior
In-Reply-To: <1322574123.12.0.756700598965.issue13498@psf.upfronthosting.co.za>
Message-ID: <1343726625.19.0.329565614025.issue13498@psf.upfronthosting.co.za>


Hynek Schlawack added the comment:

So, IMHO if someone calls os.makedirs with a mode != 0o777, they expect to have the directories having those modes afterward. So raising no error if they exist and have the wrong mode would be a plain bug.

Python 3.3 already has a helpful error message:

FileExistsError: [Errno 17] File exists (mode 777 != expected mode 755): 'foo'

and it also handles the sticky issue gracefully: http://hg.python.org/cpython/file/3a08d766eee3/Lib/os.py#l270 

So this are an non-issues for 3.3. I'm not sure if it's severe enough to be back ported to 3.2.

So there?s only one thing left: the docs are wrong and should be fixed about exist_ok's behavior for both 3.2 & 3.3.


That said, I see the rationale for fixing the permissions but we can't just change os.makedirs at this point.

So I'd propose to add a "fix_permissions" bool flag that would allow the "no matter what the state is now, I want dir x with permissions y, do whatever is necessary workflow."

Opinions?

----------

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